- 11 Nov, 2011 39 commits
-
-
Antonio Ospite authored
commit 6123b0e2 upstream. When calling the hardware blinking function implemented by blink_set(), the delay_on and delay_off values are not preserved across calls. Fix that and make the "timer" trigger work as expected when hardware blinking is available. BEFORE the fix: $ cd /sys/class/leds/someled $ echo timer > trigger $ cat delay_on delay_off 0 0 $ echo 100 > delay_on $ cat delay_on delay_off 0 0 $ echo 100 > delay_off $ cat delay_on delay_off 0 0 AFTER the fix: $ cd /sys/class/leds/someled $ echo timer > trigger $ cat delay_on delay_off 0 0 $ echo 100 > delay_on $ cat delay_on delay_off 100 0 $ echo 100 > delay_off $ cat delay_on delay_off 100 100 Signed-off-by:
Antonio Ospite <ospite@studenti.unina.it> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Nelson Elhage authored
commit d8805e63 upstream. epoll can acquire recursively acquire ep->mtx on multiple "struct eventpoll"s at once in the case where one epoll fd is monitoring another epoll fd. This is perfectly OK, since we're careful about the lock ordering, but it causes spurious lockdep warnings. Annotate the recursion using mutex_lock_nested, and add a comment explaining the nesting rules for good measure. Recent versions of systemd are triggering this, and it can also be demonstrated with the following trivial test program: --------------------8<-------------------- int main(void) { int e1, e2; struct epoll_event evt = { .events = EPOLLIN }; e1 = epoll_create1(0); e2 = epoll_create1(0); epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt); return 0; } --------------------8<-------------------- Reported-by:
Paul Bolle <pebolle@tiscali.nl> Tested-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Nelson Elhage <nelhage@nelhage.com> Acked-by:
Jason Baron <jbaron@redhat.com> Cc: Dave Jones <davej@redhat.com> Cc: Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Josh Stone authored
commit 315eb8a2 upstream. When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I noticed a warning about the asm operand for test_bit in kprobes' can_boost. I discovered that this caused only the first long of twobyte_is_boostable[] to be output. Jakub filed and fixed gcc PR50571 to correct the warning and this output issue. But to solve it for less current gcc, we can make kprobes' twobyte_is_boostable[] non-const, and it won't be optimized out. Before: CC arch/x86/kernel/kprobes.o In file included from include/linux/bitops.h:22:0, from include/linux/kernel.h:17, from [...]/arch/x86/include/asm/percpu.h:44, from [...]/arch/x86/include/asm/current.h:5, from [...]/arch/x86/include/asm/processor.h:15, from [...]/arch/x86/include/asm/atomic.h:6, from include/linux/atomic.h:4, from include/linux/mutex.h:18, from include/linux/notifier.h:13, from include/linux/kprobes.h:34, from arch/x86/kernel/kprobes.c:43: [...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’: [...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input without lvalue in asm operand 1 is deprecated [enabled by default] $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt 551: 0f a3 05 00 00 00 00 bt %eax,0x0 554: R_386_32 .rodata.cst4 $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o arch/x86/kernel/kprobes.o: file format elf32-i386 Contents of section .data: 0000 48000000 00000000 00000000 00000000 H............... Contents of section .rodata.cst4: 0000 4c030000 L... Only a single long of twobyte_is_boostable[] is in the object file. After, without the const on twobyte_is_boostable: $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt 551: 0f a3 05 20 00 00 00 bt %eax,0x20 554: R_386_32 .data $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o arch/x86/kernel/kprobes.o: file format elf32-i386 Contents of section .data: 0000 48000000 00000000 00000000 00000000 H............... 0010 00000000 00000000 00000000 00000000 ................ 0020 4c030000 0f000200 ffff0000 ffcff0c0 L............... 0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77 ....;.......&..w Now all 32 bytes are output into .data instead. Signed-off-by:
Josh Stone <jistone@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Jakub Jelinek <jakub@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jack Steiner authored
commit 6a469e46 upstream. This is a workaround for a UV2 hub bug that affects the format of system global addresses. The GRU API for UV2 was inadvertently broken by a hardware change. The format of the physical address used for TLB dropins and for addresses used with instructions running in unmapped mode has changed. This change was not documented and became apparent only when diags failed running on system simulators. For UV1, TLB and GRU instruction physical addresses are identical to socket physical addresses (although high NASID bits must be OR'ed into the address). For UV2, socket physical addresses need to be converted. The NODE portion of the physical address needs to be shifted so that the low bit is in bit 39 or bit 40, depending on an MMR value. It is not yet clear if this bug will be fixed in a silicon respin. If it is fixed, the hub revision will be incremented & the workaround disabled. Signed-off-by:
Jack Steiner <steiner@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Nicholas Bellinger authored
commit 6b20fa9a upstream. This patch fixes a bug with the handling of REPORT TARGET PORT GROUPS containing a smaller allocation length than the payload requires causing memory writes beyond the end of the buffer. This patch checks for the minimum 4 byte length for the response payload length, and also checks upon each loop of T10_ALUA(su_dev)->tg_pt_gps_list to ensure the Target port group and Target port descriptor list is able to fit into the remaining allocation length. If the response payload exceeds the allocation length length, then rd_len is still increments to indicate to the initiator that the payload has been truncated. Reported-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@risingtidesystems.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Henningsson authored
commit cc667a72 upstream. The revision 0x100300 was found for ALC662. It seems to work well with patch_alc662. BugLink: http://bugs.launchpad.net/bugs/877373Tested-by:
Shengyao Xue <Shengyao.xue@canonical.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Acked-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Charles Chin authored
commit 6c5c04e5 upstream. The purpose of this patch is to remove a section of "bad" code that assigns the last DAC to ports E or F in order to support notebooks with docking in earlier days, around ALSA 1.0.19 - 21. This is not necessary now and actually breaks some configurations that use these ports as other devices. This have been tested on several different configurations to make sure that it is working for different combinations. Signed-off-by:
Charles Chin <Charles.Chin@idt.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jeff Skirvin authored
commit 983d3fdd upstream. Needed to jump to scic_lock unlock. Also spotted by coccicheck. Signed-off-by:
Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Williams authored
commit 54b5e3a4 upstream. Kill the local smp response buffer. Besides being unnecessary, it is too small (currently truncates responses to 60 bytes). The mid-layer will have already allocated a sufficiently sized buffer, just kmap and copy into it directly. Reported-by:
Derick Marks <derick.w.marks@intel.com> Tested-by:
Derick Marks <derick.w.marks@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jack Wang authored
commit bb041a0e upstream. Libsas forget to set the sas_address and device type of rphy lead to file under /sys/class/sas_x show wrong value, fix that. Signed-off-by:
Jack Wang <jack_wang@usish.com> Tested-by:
Crystal Yu <crystal_yu@usish.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Anton Blanchard authored
commit 5d7c20b7 upstream. During kdump testing I noticed timeouts when initialising each IPR adapter. While the driver has logic to detect an adapter in an indeterminate state, it wasn't triggering and each adapter went through a 5 minute timeout before finally going operational. Some analysis showed the needs_hard_reset flag wasn't getting set. We can check the reset_devices kernel parameter which is set by kdump and force a full reset. This fixes the problem. Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
adam radford authored
commit f575c5d3 upstream. The following patch for megaraid_sas will fix a potential bad pointer access in megasas_reset_timer(), when a MegaRAID 9265/9285 or 9360/9380 gets a timeout. megasas_build_io_fusion() sets SCp.ptr to be a struct megasas_cmd_fusion *, but then megasas_reset_timer() was casting SCp.ptr to be a struct megasas_cmd *, then trying to access cmd->instance, which is invalid. Just loading instance from scmd->device->host->hostdata in megasas_reset_timer() fixes the issue. Signed-off-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Josh Boyer authored
commit 3e309cdf upstream. Commit 15bed0f2 added a quirk for the e823 Ricoh card reader to lower the base frequency. However, the quirk first checks to see if the proprietary MMC controller is disabled, and returns if so. On some devices, such as the Lenovo X220, the MMC controller is already disabled by firmware it seems, but the frequency change is still needed so sdhci-pci can talk to the cards. Since the MMC controller is disabled, the frequency fixup was never being run on these machines. This moves the e823 check above the MMC controller check so that it always gets run. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=722509Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andrei Warkentin authored
commit 5238acbe upstream. f39b2dd9 ("mmc: core: Bus width testing needs to handle suspend/resume") added code to only compare read-only ext_csd fields in bus width testing code, yet it's comparing some fields that are never set. The affected fields are ext_csd.raw_erased_mem_count and ext_csd.raw_partition_support. Signed-off-by:
Andrei Warkentin <andrey.warkentin@gmail.com> Acked-by:
Philip Rakity <prakity@marvell.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ulf Hansson authored
commit 7f7e4129 upstream. During a rescan operation mmc_attach(sd|mmc|sdio) functions are called. The error handling in these function can trigger a detach of the bus, which also meant a power off. This is not notified by the rescan operation which then continues to the next attach function. If a power off has been done, the framework must never send any new commands to the host driver, without first doing a new power up. This will most likely trigger any host driver to hang. Moving power off out of detach and instead handle power off separately when it is actually needed, solves the issue. Signed-off-by:
Ulf Hansson <ulf.hansson@stericsson.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
commit 286e0c94 upstream. Commit 9b9fe724 accidentally used RADEON_GPIO_EN_* where RADEON_GPIO_MASK_* was intended. This caused improper initialization of I2C buses, mostly visible when setting i2c_algo_bit.bit_test=1. Using the right constants fixes the problem. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Jerome Glisse <j.glisse@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Deucher authored
commit d0d0a225 upstream. When force == false, we don't do load detection in the connector detect functions. Unforunately, we also return the previous connector state so we never get disconnect events for DVI-I, DVI-A, or VGA. Save whether we detected the monitor via load detection previously and use that to determine whether we return the previous state or not. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41561Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Deucher authored
commit 5f0a2612 upstream. DVI-D and HDMI-A are digital only, so there's no need to attempt analog load detect. Also, skip bail before the !force check, or we fail to get a disconnect events. The next patches in the series attempt to fix disconnect events for connectors with analog support (DVI-I, HDMI-B, DVI-A). Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41561Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Takashi Iwai authored
commit f52c619a upstream. The commit 47356eb6 introduced a mechanism to record the backlight level only at disabling time, but it also introduced a regression. Since intel_lvds_enable() may be called without disabling (e.g. intel_lvds_commit() calls it unconditionally), the backlight gets back to the last recorded value. For example, this happens when you dim the backlight, close the lid and open the lid, then the backlight suddenly goes to the brightest. This patch fixes the bug by recording the backlight level always when changed via intel_panel_set_backlight(). And, intel_panel_{enable|disable}_backlight() call the internal function not to update the recorded level wrongly. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Keith Packard authored
commit 8c241fef upstream. Talking to the eDP DDC channel requires that the panel be powered up. Wrap both the EDID and modes fetch code with calls to turn the vdd power on and back off. Signed-off-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andiry Xu authored
commit 7e393a83 upstream. Setting the chain (CH) bit in the link TRB of isochronous transfer rings is required by AMD 0.96 xHCI host controller to successfully transverse multi-TRB TD that span through different memory segments. When a Missed Service Error event occurs, if the chain bit is not set in the link TRB and the host skips TDs which just across a link TRB, the host may falsely recognize the link TRB as a normal TRB. You can see this may cause big trouble - the host does not jump to the right address which is pointed by the link TRB, but continue fetching the memory which is after the link TRB address, which may not even belong to the host, and the result cannot be predicted. This causes some big problems. Without the former patch I sent: "xHCI: prevent infinite loop when processing MSE event", the system may hang. With that patch applied, system does not hang, but the host still access wrong memory address and isoc transfer will fail. With this patch, isochronous transfer works as expected. This patch should be applied to kernels as old as 2.6.36, which was when the first isochronous support was added for the xHCI host controller. Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kautuk Consul authored
commit 0e6c7f74 upstream. There are 2 situations wherein the xhci_ring* might not get freed: - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and we goto the fail: label in xhci_ring_alloc. In this case, the ring will not get kfreed. - When the num_segs argument to xhci_ring_alloc is passed as 0 and we try to free the rung after that. ( This doesn't really happen as of now in the code but we seem to be entertaining num_segs=0 in xhci_ring_alloc ) This should be backported to kernels as old as 2.6.31. Signed-off-by:
Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
commit 68aa95d5 upstream. This patch (as1489) works around a hardware bug in MosChip EHCI controllers. Evidently when one of these controllers increments the frame-index register, it changes the three low-order bits (the microframe counter) before changing the higher order bits (the frame counter). If the register is read at just the wrong time, the value obtained is too low by 8. When the appropriate quirk flag is set, we work around this problem by reading the frame-index register a second time if the first value's three low-order bits are all 0. This gives the hardware a chance to finish updating the register, yielding the correct value. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Jason N Pitt <jpitt@fhcrc.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Harro Haan authored
commit 276532ba upstream. The Kirkwood gave an unaligned memory access error on line 742 of drivers/usb/host/echi-hcd.c: "ehci->last_periodic_enable = ktime_get_real();" Signed-off-by:
Harro Haan <hrhaan@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Matthieu CASTET authored
commit 2093c6b4 upstream. This allow to clean duplicated code in most of SOC driver. Signed-off-by:
Matthieu CASTET <castet.matthieu@free.fr> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ning Jiang authored
commit 94abc56f upstream. The following patch removed uart_change_pm() in uart_resume_port(): commit 5933a161 Author: Yin Kangkai <kangkai.yin@linux.intel.com> serial-core: reset the console speed on resume It will break the pxa serial driver when the system resumes from suspend mode as it will try to set baud rate divider register in set_termios but with clock off. The register value can not be set correctly on some platform if the clock is disabled. The pxa driver will check the value and report the following warning: ------------[ cut here ]------------ WARNING: at drivers/tty/serial/pxa.c:545 serial_pxa_set_termios+0x1dc/0x250() Modules linked in: [<c0281f30>] (unwind_backtrace+0x0/0xf0) from [<c029341c>] (warn_slowpath_common+0x4c/0x64) [<c029341c>] (warn_slowpath_common+0x4c/0x64) from [<c029344c>] (warn_slowpath_null+0x18/0x1c) [<c029344c>] (warn_slowpath_null+0x18/0x1c) from [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) from [<c044a840>] (uart_resume_port+0x128/0x2dc) [<c044a840>] (uart_resume_port+0x128/0x2dc) from [<c044bbe0>] (serial_pxa_resume+0x18/0x24) [<c044bbe0>] (serial_pxa_resume+0x18/0x24) from [<c0454d34>] (platform_pm_resume+0x40/0x4c) [<c0454d34>] (platform_pm_resume+0x40/0x4c) from [<c0457ebc>] (pm_op+0x68/0xb4) [<c0457ebc>] (pm_op+0x68/0xb4) from [<c0458368>] (device_resume+0xb0/0xec) [<c0458368>] (device_resume+0xb0/0xec) from [<c04584c8>] (dpm_resume+0xe0/0x194) [<c04584c8>] (dpm_resume+0xe0/0x194) from [<c0458588>] (dpm_resume_end+0xc/0x18) [<c0458588>] (dpm_resume_end+0xc/0x18) from [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) from [<c02c5278>] (enter_state+0xac/0xdc) [<c02c5278>] (enter_state+0xac/0xdc) from [<c02c48ec>] (state_store+0xa0/0xbc) [<c02c48ec>] (state_store+0xa0/0xbc) from [<c0408f7c>] (kobj_attr_store+0x18/0x1c) [<c0408f7c>] (kobj_attr_store+0x18/0x1c) from [<c034a6a4>] (sysfs_write_file+0x108/0x140) [<c034a6a4>] (sysfs_write_file+0x108/0x140) from [<c02fb798>] (vfs_write+0xac/0x134) [<c02fb798>] (vfs_write+0xac/0x134) from [<c02fb8cc>] (sys_write+0x3c/0x68) [<c02fb8cc>] (sys_write+0x3c/0x68) from [<c027c700>] (ret_fast_syscall+0x0/0x2c) ---[ end trace 88289eceb4675b04 ]--- This patch fix the problem by adding the power on opertion back for uart console when console_suspend_enabled is true. Signed-off-by:
Ning Jiang <ning.jiang@marvell.com> Tested-by:
Mayank Rana <mrana@codeaurora.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Marcus Folkesson authored
commit e44aabd6 upstream. Errata E20: UART: Character Timeout interrupt remains set under certain software conditions. Implication: The software servicing the UART can be trapped in an infinite loop. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rigbert Hamisch authored
commit 1bfac90d upstream. add device ID for "HP un2430 Mobile Broadband Module" Signed-off-by:
Rigbert Hamisch <rigbert@gmx.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Richard Hartmann authored
commit 68c79e57 upstream. Simple patch to make qcserial recognize the USB id of the Sierra Wireless MC8355 which is based on the Gobi 3000 chip. Both UMTS and GPS work fine. Signed-off-by:
Richard Hartmann <richih.mailinglist@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mike Sterling authored
commit cf55f4a8 upstream. If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc. Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue. Reported-by:
Robert Scheck <robert.scheck@etes.de> Signed-off-by:
Mike Sterling <mike.sterling@microsoft.com> Signed-off-by:
K.Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kautuk Consul authored
commit e8df1674 upstream. If the usermode app does an ioctl over this serial device by using TIOCMIWAIT, then the code will wait by setting the current task state to TASK_INTERRUPTIBLE and then calling schedule(). This will be woken up by the qt2_process_modem_status on URB completion when the port_extra->shadowMSR is set to the new modem status. However, this could result in a lost wakeup scenario due to a race in the logic in the qt2_ioctl(TIOCMIWAIT) loop and the URB completion for new modem status in qt2_process_modem_status. Due to this, the usermode app's task will continue to sleep despite a change in the modem status. Signed-off-by:
Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Bill Pemberton authored
commit 7cbf3c7c upstream. The serqt_usb2 driver will not work properly with the ssu100 device even though it claims to support it. The ssu100 is supported by the ssu100 driver in mainline so there is no need to have it claimed by serqt_usb2. Signed-off-by:
Bill Pemberton <wfp5p@virginia.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jim Wylder authored
commit c5a48592 upstream. A return value of -EINPROGRESS from pm_runtime_get indicates that the device is already resuming due to a previous call. Internally, usb_autopm_get_interface_async doesn't treat this as an error and increments the usage count, but passes the error status along to the caller. The logical assumption of the caller is that any negative return value reflects the device not resuming and the pm_usage_cnt not being incremented. Since the usage count is being incremented and the device is resuming, return success (0) instead. Signed-off-by:
James Wylder <james.wylder@motorola.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit 1177c0ef upstream. Mistakenly, commit 64ba3dc3 (tty: never hold BTM while getting tty_mutex) switched one fail path in ptmx_open to not free the newly allocated tty. Fix that by jumping to the appropriate place. And rename the labels so that it's clear what is going on there. Introduced-in: v2.6.36-rc2 Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit fa90e1c9 upstream. If tty_add_file fails at the point it is now, we have to revert all the changes we did to the tty. It means either decrease all refcounts if this was a tty reopen or delete the tty if it was newly allocated. There was a try to fix this in v3.0-rc2 using tty_release in 0259894c (TTY: fix fail path in tty_open). But instead it introduced a NULL dereference. It's because tty_release dereferences filp->private_data, but that one is set even in our tty_add_file. And when tty_add_file fails, it's still NULL/garbage. Hence tty_release cannot be called there. To circumvent the original leak (and the current NULL deref) we split tty_add_file into two functions, making the latter non-failing. In that case we may do the former early in open, where handling failures is easy. The latter stays as it is now. So there is no change in functionality. The original bug (leak) was introduced by f573bd17 (tty: Remove __GFP_NOFAIL from tty_add_file()). Thanks Dan for reporting this. Later, we may split tty_release into more functions and call only some of them in this fail path instead. (If at all possible.) Introduced-in: v2.6.37-rc2 Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit c290f835 upstream. When tty_driver_lookup_tty fails in tty_open, we forget to drop a reference to the tty driver. This was added by commit 4a2b5fdd (Move tty lookup/reopen to caller). Fix that by adding tty_driver_kref_put to the fail path. I will refactor the code later. This is for the ease of backporting to stable. Introduced-in: v2.6.28-rc2 Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
WANG Cong authored
commit 2f7861de upstream. This patch fixes the following build error: drivers/tty/serial/crisv10.c:4453: error: 'if_ser0' undeclared (first use in this function): 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig drivers/tty/serial/crisv10.c:4453: error: (Each undeclared identifier is reported only once: 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig drivers/tty/serial/crisv10.c:4453: error: for each function it appears in.): 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig "if_ser0" is a typo, it should be "if_serial_0". Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Pavel Shilovsky authored
commit 42274bb2 upstream. We should call cifs_all_info_to_fattr in rc == 0 case only. Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Pavel Shilovsky authored
commit 94443f43 upstream. ..the length field has only 17 bits. Acked-by:
Jeff Layton <jlayton@samba.org> Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 25 Oct, 2011 1 commit
-
-
Greg Kroah-Hartman authored
-