- 17 Jan, 2013 40 commits
-
-
Axel Lin authored
commit 81d0a6ae upstream. Use DIV_ROUND_UP to prevent truncation by integer division issue. This ensures we return enough delay time. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Axel Lin authored
commit adf6178a upstream. Integer division may truncate. This happens when pdata->buckx_voltagex setting is not align with 1000 uV. Thus use uV in voltage_map_desc, this ensures the selected voltage won't less than pdata buckx_voltagex settings. Signed-off-by:
-
Axel Lin authored
commit bc3b7756 upstream. Current code does integer division (min_vol = min_uV / 1000) before pass min_vol to max8997_get_voltage_proper_val(). So it is possible min_vol is truncated to a smaller value. For example, if the request min_uV is 800900 for ldo. min_vol = 800900 / 1000 = 800 (mV) Then max8997_get_voltage_proper_val returns 800 mV for this case which is lower than the requested voltage. Use uV rather than mV in voltage_map_desc to prevent truncation by integer division. Signed-off-by:
-
Jan Beulich authored
commit 75e1a2ae upstream. Debug port in-use determination must be done before the controller gets reset the first time, i.e. before the call to ehci_setup() as of commit 1a49e2ac. That commit effectively rendered commit 9fa5780b useless. While moving that code around, also fix the BAR determination - the respective capability field is a 3- rather than a 2-bit one -, and use PCI_CAP_ID_DBG instead of the literal 0x0a. It's unclear to me whether the debug port functionality is important enough to warrant fixing this in stable kernels too. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Sarah Sharp authored
commit 55c1945e upstream. A high speed control or bulk endpoint may have bInterval set to zero, which means it does not NAK. If bInterval is non-zero, it means the endpoint NAKs at a rate of 2^(bInterval - 1). The xHCI code to compute the NAK interval does not handle the special case of zero properly. The current code unconditionally subtracts one from bInterval and uses it as an exponent. This causes a very large bInterval to be used, and warning messages like these will be printed: usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes This may cause the xHCI host hardware to reject the Configure Endpoint command, which means the HS device will be unusable under xHCI ports. This patch should be backported to kernels as old as 2.6.31, that contain commit dfa49c4a "USB: xhci - fix math in xhci_get_endpoint_interval()". Reported-by:
Vincent Pelletier <plr.vincent@gmail.com> Suggested-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Oliver Neukum authored
commit 07e72b95 upstream. Some touchscreens have buggy firmware which claims remote wakeup to be enabled after a reset. They nevertheless crash if the feature is cleared by the host. Add a check for reset resume before checking for an enabled remote wakeup feature. On compliant devices the feature must be cleared after a reset anyway. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Acked-by:
-
Sarah Sharp authored
commit c52804a4 upstream. The USB core hub thread (khubd) is designed with external USB hubs in mind. It expects that if a port status change bit is set, the hub will continue to send a notification through the hub status data transfer. Basically, it expects hub notifications to be level-triggered. The xHCI host controller is designed to be edge-triggered on the logical 'OR' of all the port status change bits. When all port status change bits are clear, and a new change bit is set, the xHC will generate a Port Status Change Event. If another change bit is set in the same port status register before the first bit is cleared, it will not send another event. This means that the hub code may lose port status changes because of race conditions between clearing change bits. The user sees this as a "dead port" that doesn't react to device connects. The fix is to turn on port polling whenever a new change bit is set. Once the USB core issues a hub status request that shows that no change bits are set in any USB ports, turn off port polling. We can't allow the USB core to poll the roothub for port events during host suspend because if the PCI host is in D3cold, the port registers will be all f's. Instead, stop the port polling timer, and unconditionally restart it when the host resumes. If there are no port change bits set after the resume, the first call to hub_status_data will disable polling. This patch should be backported to stable kernels with the first xHCI support, 2.6.31 and newer, that include the commit 0f2a7930 "USB: xhci: Root hub support." There will be merge conflicts because the check for HC_STATE_SUSPENDED was moved into xhci_suspend in 3.8. Signed-off-by:
-
Sarah Sharp authored
commit 65bdac5e upstream. An empty port can transition to either Inactive or Compliance Mode if a newly connected USB 3.0 device fails to link train. In that case, we issue a warm reset. Some devices, such as John's Roseweil eusb3 enclosure, slip back into Compliance Mode after the warm reset. The current warm reset code does not check for device connect status on warm reset completion, and it incorrectly reports the warm reset succeeded. This causes the USB core to attempt to send a Set Address control transfer to a port in Compliance Mode, which will always fail. Make hub_port_wait_reset check the current connect status and link state after the warm reset completes. Return a failure status if the device is disconnected or the link state is Compliance Mode or SS.Inactive. Make hub_events disable the port if warm reset fails. This will disable the port, and then bring it back into the RxDetect state. Make the USB core ignore the connect change until the device reconnects. Note that this patch does NOT handle connected devices slipping into the Inactive state very well. This is a concern, because devices can go into the Inactive state on U1/U2 exit failure. However, the fix for that case is too large for stable, so it will be submitted in a separate patch. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72 "usbcore: refine warm reset logic" Signed-off-by:
John Covici <covici@ccs.covici.com> Signed-off-by:
-
Sarah Sharp authored
commit 4f43447e upstream. The port reset code bails out early if the current connect status is cleared (device disconnected). If we're issuing a hot reset, it may also look at the link state before the reset is finished. Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the Error state or Resetting state, the port connection bit retains the value from the previous state. Therefore we can't trust it until the reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software shall ignore the link state while the port is resetting, as it can be in an unknown state. The port state during reset is also unknown for USB 2.0 hubs. The hub sends a reset signal by driving the bus into an SE0 state. This overwhelms the "connect" signal from the device, so the port can't tell whether anything is connected or not. Fix the port reset code to ignore the port link state and current connect bit until the reset finishes, and USB_PORT_STAT_RESET is cleared. Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case, because it's redundant. When the warm reset finishes, the port reset bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set. Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit in the code to deal with the finished reset. This patch should be backported to all stable kernels. Signed-off-by:
-
Sarah Sharp authored
commit 77c7f072 upstream. John's NEC 0.96 xHCI host controller needs a longer timeout for a warm reset to complete. The logs show it takes 650ms to complete the warm reset, so extend the hub reset timeout to 800ms to be on the safe side. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by:
-
Sarah Sharp authored
commit 41e7e056 upstream. If hot and warm reset fails, or a port remains in the Compliance Mode, the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0 ports, once the port is placed into the Disabled link state, it will not report any new device connects. To get device connect notifications, we need to put the link into the Disabled state, and then the RxDetect state. The xHCI driver needs to atomically clear all change bits on USB 3.0 port disable, so that we get Port Status Change Events for future port changes. We could technically do this in the USB core instead of in the xHCI roothub code, since the port state machine can't advance out of the disabled state until we set the link state to RxDetect. However, external USB 3.0 hubs don't need this code. They are level-triggered, not edge-triggered like xHCI, so they will continue to send interrupt events when any change bit is set. Therefore it doesn't make sense to put this code in the USB core. This patch is part of a series to fix several reports of infinite loops on device enumeration failure. This includes John, when he boots with a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96 host controller. The fix requires warm reset support, so it does not make sense to backport this patch to stable kernels without warm reset support. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72 "usbcore: refine warm reset logic" Signed-off-by:
-
Sarah Sharp authored
commit 8b8132bc upstream. When the USB core finishes reseting a USB device, the xHCI driver sends a Reset Device command to the host. The xHC then updates its internal representation of the USB device to the 'Default' device state. If the device was already in the Default state, the xHC will complete the command with an error status. If a device needs to be reset several times during enumeration, the second reset will always fail because of the xHCI Reset Device command. This can cause issues during enumeration. For example, usb_reset_and_verify_device calls into hub_port_init in a loop. Say that on the first call into hub_port_init, the device is successfully reset, but doesn't respond to several set address control transfers. Then the port will be disabled, but the udev will remain in tact. usb_reset_and_verify_device will call into hub_port_init again. On the second call into hub_port_init, the device will be reset, and the xHCI driver will issue a Reset Device command. This command will fail (because the device is already in the Default state), and usb_reset_and_verify_device will fail. The port will be disabled, and the device won't be able to enumerate. Fix this by ignoring the return value of the HCD reset_device callback. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by:
-
Andreas Fleig authored
commit bc009eca upstream. Add device quirk for Microsoft Lifecam VX700 v2.0 webcams. Fixes squeaking noise of the microphone. Signed-off-by:
Andreas Fleig <andreasfleig@gmail.com> Signed-off-by:
-
Sarah Sharp authored
commit 1c7439c6 upstream. USB 3.0 hubs and roothubs will automatically transition a failed hot reset to a warm (BH) reset. In that case, the warm reset change bit will be set, and the link state change bit may also be set. Change hub_port_finish_reset to unconditionally clear those change bits for USB 3.0 hubs. If these bits are not cleared, we may lose port change events from the roothub. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by:
-
Aleksi Torhamo authored
commit 43f78979 upstream. Fixes regression introduced in commit 861d2107 "drm/nouveau/fb: merge fb/vram and port to subdev interfaces" nv50_fb_vram_{new,del} functions were changed to use nouveau_subdev->mutex instead of the old nouveau_mm->mutex. nvc0_fb_vram_new still uses the nouveau_mm->mutex, but nvc0 doesn't have its own fb_vram_del function, using nv50_fb_vram_del instead. Because of this, on nvc0 a different mutex ends up being used to protect additions and deletions to the same list. This patch is a -stable candidate for 3.7. Signed-off-by:
Aleksi Torhamo <aleksi@torhamo.net> Reported-by:
Roy Spliet <r.spliet@student.tudelft.nl> Tested-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Aleksi Torhamo authored
commit d19528a9 upstream. Fixes regression introduced in commit 70790f4f "drm/nouveau/clock: pull in the implementation from all over the place" When code was moved from nv50_crtc_set_clock to nvc0_clock_pll_set, the PLLs it is used for got limited to only the first two VPLLs. nv50_crtc_set_clock was only called to change VPLLs, so it didn't limit what it was used for in any way. Since nvc0_clock_pll_set is used for all PLLs, it has to specify which PLLs the code is used for, and only listed the first two VPLLs. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58735 This patch is a -stable candidate for 3.7. Signed-off-by:
Sean Santos <quantheory@gmail.com> Signed-off-by:
-
Marcin Slusarz authored
commit 4c4101d2 upstream. Fixes memory corruptions, oopses, etc. when multiple gpuobjs are simultaneously created or destroyed. Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
-
Marcin Slusarz authored
commit 92441b22 upstream. Commit 2a44e499 ("drm/nouveau/disp: introduce proper init/fini, separate from create/destroy") started to call display init routines on pre-nv50 hardware on module load. But LVDS init code sets driver state in a way which prevents modesetting code from operating properly. nv04_display_init calls nv04_dfp_restore, which sets encoder->last_dpms to NV_DPMS_CLEARED. drm_crtc_helper_set_mode nv04_dfp_prepare nv04_lvds_dpms(DRM_MODE_DPMS_OFF) nv04_lvds_dpms checks last_dpms mode (which is NV_DPMS_CLEARED) and wrongly assumes it's a "powersaving mode", the new one (DRM_MODE_DPMS_OFF) is too, so it skips calling some crucial lvds scripts. Reported-by:
Chris Paulson-Ellis <chris@edesix.com> Signed-off-by:
-
Marcin Slusarz authored
commit f20ebd03 upstream. Since commit 5e120f6e "drm/nouveau/fence: convert to exec engine, and improve channel sync" nouveau fence sync implementation for nv17-50 and nvc0+ started to rely on state of fence buffer left by previous sync operation. But as pinned bo's (where fence state is stored) are not saved+restored across suspend/resume, we need to do it manually. nvc0+ was fixed by commit d6ba6d21 "drm/nvc0/fence: restore pre-suspend fence buffer context on resume". Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121Signed-off-by:
-
Sergei Shtylyov authored
commit 2ac788f7 upstream. Commit 5c8a86e1 (usb: musb: drop unneeded musb_debug trickery) erroneously removed '\n' from the driver's banner. Concatenate all the banner substrings while adding it back... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 1d16638e upstream. If we do have endpoints named like "ep-a" then bEndpointAddress is counted internally by the gadget framework. If we do have endpoints named like "ep-1" then bEndpointAddress is assigned from the digit after "ep-". If we do have both, then it is likely that after we used up the "generic" endpoints we will use the digits and thus assign one bEndpointAddress to multiple endpoints. This theory can be proofed by using the completely enabled g_multi. Without this patch, the mass storage won't enumerate and times out because it shares endpoints with RNDIS. This patch also adds fills up the endpoints list so we have in total endpoints 1 to 15 in + out available while some of them are restricted to certain types like BULK or ISO. Without this change the nokia gadget won't load because the system does not provide enough (BULK) endpoints but it did before ep-a - ep-f were removed. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
-
Denis N Ladin authored
commit 036915a7 upstream. Adding support "PSC Scanning, Magellan 800i" in cdc-acm Very simple, but very necessary. Suitable for all versions of the kernel > 2.6 Signed-off-by:
Denis N Ladin <denladin@gmail.com> Acked-by:
-
Tomasz Mloduchowski authored
commit 8cf65dc3 upstream. Simple fix to add support for Crucible Technologies COMET Caller ID USB decoder - a device containing FTDI USB/Serial converter chip, handling 1200bps CallerID messages decoded from the phone line - adding correct USB PID is sufficient. Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8 and 3.8.0-rc3 on both amd64 and x86 arches. Signed-off-by:
Tomasz Mloduchowski <q@qdot.me> Signed-off-by:
-
Bjørn Mork authored
commit 5ec00854 upstream. also known as Alcatel One Touch L100V LTE The driver description files gives these names to the vendor specific functions on this modem: Application1: VID_1BBB&PID_011E&MI_00 Application2: VID_1BBB&PID_011E&MI_01 Modem: VID_1BBB&PID_011E&MI_03 Ethernet: VID_1BBB&PID_011E&MI_04 Reported-by:
Thomas Schäfer <tschaefer@t-online.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Quentin.Li authored
commit 94a85b63 upstream. In option.c, add some new MEDIATEK PIDs support for MEDIATEK new products. This is a MEDIATEK inc. release patch. Signed-off-by:
Quentin.Li <snowmanli88@163.com> Signed-off-by:
-
Bjørn Mork authored
commit fab38246 upstream. The driver description files gives these names to the vendor specific functions on this modem: diag: VID_19D2&PID_0284&MI_00 nmea: VID_19D2&PID_0284&MI_01 at: VID_19D2&PID_0284&MI_02 mdm: VID_19D2&PID_0284&MI_03 net: VID_19D2&PID_0284&MI_04 Signed-off-by:
-
Dzianis Kahanovich authored
commit ad86e586 upstream. Hyundai Petatel Inc. Nexpring NP10T terminal (EV-DO rev.A USB modem) ID Signed-off-by:
Denis Kaganovich <mahatma@eu.by> Signed-off-by:
-
Larry Finger authored
commit 5e20a4b5 upstream. Recent versions of udev cause synchronous firmware loading from the probe routine to fail because the request to user space would time out. The original fix for b43 (commit 6b6fa586) moved the firmware load from the probe routine to a work queue, but it still used synchronous firmware loading. This method is OK when b43 is built as a module; however, it fails when the driver is compiled into the kernel. This version changes the code to load the initial firmware file using request_firmware_nowait(). A completion event is used to hold the work queue until that file is available. This driver reads several firmware files - the remainder can be read synchronously. On some test systems, the async read fails; however, a following synch read works, thus the async failure falls through to the sync try. Reported-and-Tested by: Felix Janda <felix.janda@posteo.de> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Bing Zhao authored
commit 9c969d8c upstream. wait_event_interruptible function returns -ERESTARTSYS if it's interrupted by a signal. Driver should check the return value and handle this case properly. In mwifiex_wait_queue_complete() routine, as we are now checking wait_event_interruptible return value, the condition check is not required. Also, we have removed mwifiex_cancel_pending_ioctl() call to avoid a chance of sending second command to FW by other path as soon as we clear current command node. FW can not handle two commands simultaneously. Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Johannes Berg authored
commit a56f992c upstream. This is a very old bug, but there's nothing that prevents the timer from running while the module is being removed when we only do del_timer() instead of del_timer_sync(). The timer should normally not be running at this point, but it's not clearly impossible (or we could just remove this.) Tested-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 97f97b1f upstream. Unfortunately, commit b22cfcfc, intended to speed up roaming by avoiding the synchronize_rcu() broke AP/mesh modes as it moved some code into that work item that will still call into the driver at a time where it's no longer expected to handle this: after the AP or mesh has been stopped. To fix this problem remove the per-station work struct, maintain a station cleanup list instead and flush this list when stations are flushed. To keep this patch smaller for stable, do this when the stations are flushed (sta_info_flush()). This unfortunately brings back the original roaming delay; I'll fix that again in a separate patch. Also, Ben reported that the original commit could sometimes (with many interfaces) cause long delays when an interface is set down, due to blocking on flush_workqueue(). Since we now maintain the cleanup list, this particular change of the original patch can be reverted. Reported-by:
-
Stanislaw Gruszka authored
commit 34bcf715 upstream. Do not scan on no-IBSS and disabled channels in IBSS mode. Doing this can trigger Microcode errors on iwlwifi and iwlegacy drivers. Also rename ieee80211_request_internal_scan() function since it is only used in IBSS mode and simplify calling it from ieee80211_sta_find_ibss(). This patch should address: https://bugzilla.redhat.com/show_bug.cgi?id=883414 https://bugzilla.kernel.org/show_bug.cgi?id=49411Reported-by:
Jesse Kahtava <jesse_kahtava@f-m.fm> Reported-by:
Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit f590dcec upstream. There's a bug in the currently released firmware version, the sequence control in the Tx response isn't updated in all cases. Take it from the packet as a workaround. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 392d4cad upstream. By accident, commit eb647644 ("iwlwifi: protect use_ict with irq_lock") changed the return value of the iwl_pcie_isr() function in case it handles an interrupt -- it now returns IRQ_NONE instead of IRQ_HANDLED. Put back the correct return value. Reviewed-by:
-
Jerome Glisse authored
commit 51861d4e upstream. Those rn50 chip are often connected to console remoting hw and load detection often fails with those. Just don't try to load detect and report connect. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Nitin Gupta authored
commit 397c6066 upstream. Fixes a bug introduced by commit c8f2f0db ("zram: Fix handling of incompressible pages") which caused invalid memory references during disk write. Invalid references could occur in two cases: - Incoming data expands on compression: In this case, reference was made to kunmap()'ed bio page. - Partial (non PAGE_SIZE) write with incompressible data: In this case, reference was made to a kfree()'ed buffer. Fixes bug 50081: https://bugzilla.kernel.org/show_bug.cgi?id=50081Signed-off-by:
Nitin Gupta <ngupta@vflare.org> Reported-by:
Mihail Kasadjikov <hamer.mk@gmail.com> Reported-by:
Tomas M <tomas@slax.org> Reviewed-by:
Minchan Kim <minchan@kernel.org> Signed-off-by:
-
Sergey Senozhatsky authored
commit 37b51fdd upstream. zram_bvec_read() shared decompress functionality with zram_read_before_write() function. Factor-out and make commonly used zram_decompress_page() function, which also simplified error handling in zram_bvec_read(). Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by:
-
Samuel Thibault authored
commit 6102c48b upstream. Check that array index is in-bounds before accessing the synths[] array. Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by:
-
Nickolai Zeldovich authored
commit ae428655 upstream. Check that array index is in-bounds before accessing the synths[] array. Signed-off-by:
Nickolai Zeldovich <nickolai@csail.mit.edu> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by:
-
Larry Finger authored
commit da849a92 upstream. The ISY IWL 1000 USB WLAN stick with USB ID 050d:11f1 is a clone of the Belkin F7D1101 V1 device. Reported-by:
Thomas Hartmann <hartmann@ict.tuwien.ac.at> Signed-off-by:
-
