aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2012-04-02mlx4_core: Fix one more static exported functionRoland Dreier
commit e10903b087e425298fb86c6ad4b1a88735480db7 upstream. Commit 22c8bff6face ("mlx4_core: Exported functions can't be static") fixed most of this up, but forgot about mlx4_is_slave_active(). Fix this one too. Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02IB/iser: Post initial receive buffers before sending the final login requestOr Gerlitz
commit 89e984e2c2cd14f77ccb26c47726ac7f13b70ae8 upstream. An iser target may send iscsi NO-OP PDUs as soon as it marks the iSER iSCSI session as fully operative. This means that there is window where there are no posted receive buffers on the initiator side, so it's possible for the iSER RC connection to break because of RNR NAK / retry errors. To fix this, rely on the flags bits in the login request to have FFP (0x3) in the lower nibble as a marker for the final login request, and post an initial chunk of receive buffers before sending that login request instead of after getting the login response. Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02p54spi: Release GPIO lines and IRQ on error in p54spi_probeMax Filippov
commit 62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream. This makes it possible to reload driver if insmod has failed due to missing firmware. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02rtc: Disable the alarm in the hardware (v2)Rabin Vincent
commit 41c7f7424259ff11009449f87c95656f69f9b186 upstream. Currently, the RTC code does not disable the alarm in the hardware. This means that after a sequence such as the one below (the files are in the RTC sysfs), the box will boot up after 2 minutes even though we've asked for the alarm to be turned off. # echo $((`cat since_epoch`)+120) > wakealarm # echo 0 > wakealarm # poweroff Fix this by disabling the alarm when there are no timers to run. The original version of this patch was reverted. This version disables the irq directly instead of setting a disabled timer in the future. Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com> [Merged in the second revision from Rabin] Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02ath9k: fix going to full-sleep on PS idleFelix Fietkau
commit c1afdaff90538ef085b756454f12b29575411214 upstream. The check for PS_WAIT_FOR_TX_ACK was inverted, the hardware should only go to full sleep if no tx is pending. Reported-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02iwlwifi: always monitor for stuck queuesJohannes Berg
commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912 upstream. If we only monitor while associated, the following can happen: - we're associated, and the queue stuck check runs, setting the queue "touch" time to X - we disassociate, stopping the monitoring, which leaves the time set to X - almost 2s later, we associate, and enqueue a frame - before the frame is transmitted, we monitor for stuck queues, and find the time set to X, although it is now later than X + 2000ms, so we decide that the queue is stuck and erroneously restart the device It happens more with P2P because there we can go between associated/unassociated frequently. Reported-by: Ben Cahill <ben.m.cahill@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02rtlwifi: rtl8192ce: Fix loss of receive performanceJingjun Wu
commit a9b89e2567c743483e6354f64d7a7e3a8c101e9e upstream. Driver rtl8192ce when used with the RTL8188CE device would start at about 20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the symptoms is that the AP would need to retransmit each packet 4 of 5 times before the driver would acknowledge it. Recovery is possible only by unloading and reloading the driver. This problem was reported at https://bugzilla.redhat.com/show_bug.cgi?id=770207. The problem is due to a missing update of the gain setting. Signed-off-by: Jingjun Wu <jingjun_wu@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cuLarry Finger
commit ebecdcc12fed5d3c81853dea61a0a78a5aefab52 upstream. When driver rtl8192cu is used with the debug level set to 3 or greater, the result is "sleeping function called from invalid context" due to an rcu_read_lock() call in the DM refresh routine in driver rtl8192c. This lock is not necessary as the USB driver does not use the struct being protected, thus the lock is set only when a PCI interface is active. This bug is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42775. Reported-by: Ronald Wahl <ronald.wahl@raritan.com> Tested-by: Ronald Wahl <ronald.wahl@raritan.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ronald Wahl <ronald.wahl@raritan.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02rtlwifi: Handle previous allocation failures when freeing device memorySimon Graham
commit 7f66c2f93e5779625c10d262c84537427a2673ca upstream. Handle previous allocation failures when freeing device memory Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02rtlwifi: rtl8192c_common: rtl8192de: Check for allocation failuresLarry Finger
commit 76a92be537f1c8c259e393632301446257ca3ea9 upstream. In https://bugzilla.redhat.com/show_bug.cgi?id=771656, a kernel bug was triggered due to a failed skb allocation that was not checked. This event lead to an audit of all memory allocations in the complete rtlwifi family of drivers. This patch fixes the rest. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02rt2x00: Add support for D-Link DWA-127 to rt2800usb.Gertjan van Wingerde
commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream. This is an RT3070 based device. Reported-by: Mikhail Kryshen <mikhail@kryshen.net> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: serial: mos7840: Fixed MCS7820 device attach problemDonald Lee
commit 093ea2d3a766cb8a4c4de57efec6c0a127a58792 upstream. A MCS7820 device supports two serial ports and a MCS7840 device supports four serial ports. Both devices use the same driver, but the attach function in driver was unable to correctly handle the port numbers for MCS7820 device. This problem has been fixed in this patch and this fix has been verified on x86 Linux kernel 3.2.9 with both MCS7820 and MCS7840 devices. Signed-off-by: Donald Lee <donald@asix.com.tw> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: cp210x: Update to support CP2105 and multiple interface devicesPreston Fick
commit a5360a53a7ccad5ed9ccef210b94fef13c6e5529 upstream. This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb_control_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x_port_private struct created for each port on startup, this struct holds the interface number - Added a cp210x_release function to clean up the cp210x_port_private memory created on startup - Modified usb_get_config and usb_set_config to get a pointer to the cp210x_port_private struct, and use the interface number there in the usb_control_message wIndex param Signed-off-by: Preston Fick <preston.fick@silabs.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb-serial: Add support for the Sealevel SeaLINK+8 2038-ROHS deviceScott Dial
commit 6d161b99f875269ad4ffa44375e1e54bca6fd02e upstream. This patch adds new device IDs to the ftdi_sio module to support the new Sealevel SeaLINK+8 2038-ROHS device. Signed-off-by: Scott Dial <scott.dial@scientiallc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: qcserial: don't grab QMI port on Gobi 1000 devicesDan Williams
commit c192c8e71a2ded01170c1a992cd21aaedc822756 upstream. Gobi 1000 devices have a different port layout, which wasn't respected by the current driver, and thus it grabbed the QMI/net port. In the near future we'll be attaching another driver to the QMI/net port for these devices (cdc-wdm and qmi_wwan) so make sure the qcserial driver doesn't claim them. This patch also prevents qcserial from binding to interfaces 0 and 1 on 1K devices because those interfaces do not respond. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: ums_realtek: do not use stack memory for DMA in __do_config_autodelinkJosh Boyer
commit 4898e07174b79013afd2b422ef6c4336ef8e6783 upstream. __do_config_autodelink passes the data variable to the transport function. If the calling functions pass a stack variable, this will eventually trigger a DMA-API debug backtrace for mapping stack memory in the DMA buffer. Fix this by calling kmemdup for the passed data instead. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: Fix build error due to dma_mask is not at pdev_archdata at ARMPeter Chen
commit e90fc3cb087ce5c5f81e814358222cd6d197b5db upstream. When build i.mx platform with imx_v6_v7_defconfig, and after adding USB Gadget support, it has below build error: CC drivers/usb/host/fsl-mph-dr-of.o drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register': drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata' has no member named 'dma_mask' It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html For PowerPC, there is dma_mask at struct pdev_archdata, but there is no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is related to specific platform, it should NOT be accessed by cross platform drivers, like USB. The code for pdev_archdata should be useless, as for PowerPC, it has already gotten the value for pdev->dev.dma_mask at function arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c. Tested-by: Ramneek Mehresh <ramneek.mehresh@freescale.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: fsl_udc_core: Fix scheduling while atomic dump messagePeter Chen
commit c5cc5ed86667d4ae74fe40ee4ed893f4b46aba05 upstream. When loading g_ether gadget, there is below message: Backtrace: [<80012248>] (dump_backtrace+0x0/0x10c) from [<803cb42c>] (dump_stack+0x18/0x1c) r7:00000000 r6:80512000 r5:8052bef8 r4:80513f30 [<803cb414>] (dump_stack+0x0/0x1c) from [<8000feb4>] (show_regs+0x44/0x50) [<8000fe70>] (show_regs+0x0/0x50) from [<8004c840>] (__schedule_bug+0x68/0x84) r5:8052bef8 r4:80513f30 [<8004c7d8>] (__schedule_bug+0x0/0x84) from [<803cd0e4>] (__schedule+0x4b0/0x528) r5:8052bef8 r4:809aad00 [<803ccc34>] (__schedule+0x0/0x528) from [<803cd214>] (_cond_resched+0x44/0x58) [<803cd1d0>] (_cond_resched+0x0/0x58) from [<800a9488>] (dma_pool_alloc+0x184/0x250) r5:9f9b4000 r4:9fb4fb80 [<800a9304>] (dma_pool_alloc+0x0/0x250) from [<802a8ad8>] (fsl_req_to_dtd+0xac/0x180) [<802a8a2c>] (fsl_req_to_dtd+0x0/0x180) from [<802a8ce4>] (fsl_ep_queue+0x138/0x274) [<802a8bac>] (fsl_ep_queue+0x0/0x274) from [<7f004328>] (composite_setup+0x2d4/0xfac [g_ether]) [<7f004054>] (composite_setup+0x0/0xfac [g_ether]) from [<802a9bb4>] (fsl_udc_irq+0x8dc/0xd38) [<802a92d8>] (fsl_udc_irq+0x0/0xd38) from [<800704f8>] (handle_irq_event_percpu+0x54/0x188) [<800704a4>] (handle_irq_event_percpu+0x0/0x188) from [<80070674>] (handle_irq_event+0x48/0x68) [<8007062c>] (handle_irq_event+0x0/0x68) from [<800738ec>] (handle_level_irq+0xb4/0x138) r5:80514f94 r4:80514f40 [<80073838>] (handle_level_irq+0x0/0x138) from [<8006ffa4>] (generic_handle_irq+0x38/0x44) r7:00000012 r6:80510b1c r5:80529860 r4:80512000 [<8006ff6c>] (generic_handle_irq+0x0/0x44) from [<8000f4c4>] (handle_IRQ+0x54/0xb4) [<8000f470>] (handle_IRQ+0x0/0xb4) from [<800085b8>] (tzic_handle_irq+0x64/0x94) r9:412fc085 r8:00000000 r7:80513f30 r6:00000001 r5:00000000 r4:00000000 [<80008554>] (tzic_handle_irq+0x0/0x94) from [<8000e680>] (__irq_svc+0x40/0x60) The reason of above dump message is calling dma_poll_alloc with can-schedule mem_flags at atomic context. To fix this problem, below changes are made: - fsl_req_to_dtd doesn't need to be protected by spin_lock_irqsave, as struct usb_request can be access at process context. Move lock to beginning of hardware visit (fsl_queue_td). - Change the memory flag which using to allocate dTD descriptor buffer, the memory flag can be from gadget layer. It is tested at i.mx51 bbg board with g_mass_storage, g_ether, g_serial. Signed-off-by: Peter Chen <peter.chen@freescale.com> Acked-by: Li Yang <leoli@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02cdc-wdm: Don't clear WDM_READ unless entire read buffer is emptiedBen Hutchings
commit b7a205545345578712611106b371538992e142ff upstream. The WDM_READ flag is cleared later iff desc->length is reduced to 0. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Tested-by: Bjørn Mork <bjorn@mork.no> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02cdc-wdm: Fix more races on the read pathBen Hutchings
commit 711c68b3c0f7a924ffbee4aa962d8f62b85188ff upstream. We must not allow the input buffer length to change while we're shuffling the buffer contents. We also mustn't clear the WDM_READ flag after more data might have arrived. Therefore move both of these into the spinlocked region at the bottom of wdm_read(). When reading desc->length without holding the iuspin lock, use ACCESS_ONCE() to ensure the compiler doesn't re-read it with inconsistent results. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Tested-by: Bjørn Mork <bjorn@mork.no> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: serial: fix console error reportingJohan Hovold
commit 548dd4b6da8a8e428453d55f7fa7b8a46498d147 upstream. Do not report errors in write path if port is used as a console as this may trigger the same error (and error report) resulting in a loop. Reported-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02TTY: Wrong unicode value copied in con_set_unimap()Liz Clark
commit 4a4c61b7ce26bfc9d49ea4bd121d52114bad9f99 upstream. Bugzilla 40012: PIO_UNIMAP bug: error updating Unicode-to-font map https://bugzilla.kernel.org/show_bug.cgi?id=40012 The unicode font map for the virtual console is a 32x32x64 table which allocates rows dynamically as entries are added. The unicode value increases sequentially and should count all entries even in empty rows. The defect is when copying the unicode font map in con_set_unimap(), the unicode value is not incremented properly. The wrong unicode value is entered in the new font map. Signed-off-by: Liz Clark <liz.clark@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02tty: moxa: fix bit test in moxa_start()Dan Carpenter
commit 58112dfbfe02d803566a2c6c8bd97b5fa3c62cdc upstream. This is supposed to be doing a shift before the comparison instead of just doing a bitwise AND directly. The current code means the start() just returns without doing anything. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02tty: serial: OMAP: Fix oops due to NULL pdata in DT bootCousson, Benoit
commit a5f43138da9beddc46b00ec31d167143a7176683 upstream. The following commit: be4b0281956c5cae4f63f31f11d07625a6988766 (tty: serial: OMAP: block idle while the UART is transferring data in PIO mode), is introducing an oops if OMAP is booted using device tree blob because the pdata will not be initialized. Check if pdata is set before de-referencing it. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: gadget: Make g_hid device class conform to spec.Orjan Friberg
commit 33d2832ab0149a26418d360af3c444969a63fb28 upstream. HID devices should specify this in their interface descriptors, not in the device descriptor. This fixes a "missing hardware id" bug under Windows 7 with a VIA VL800 (3.0) controller. Signed-off-by: Orjan Friberg <of@flatfrog.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: gadgetfs: return number of bytes on ep0 read requestThomas Faber
commit 85b4b3c8c189e0159101f7628a71411af072ff69 upstream. A read from GadgetFS endpoint 0 during the data stage of a control request would always return 0 on success (as returned by wait_event_interruptible) despite having written data into the user buffer. This patch makes it correctly set the return value to the number of bytes read. Signed-off-by: Thomas Faber <thfabba@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: renesas_usbhs: bugfix: add .release function to gpriv->gadget.devKuninori Morimoto
commit 3b2a2e47174cd978258bbb0fdf2e2b1b5ec2144c upstream. This patch fixup below warning on device_unregister() renesas_usbhs renesas_usbhs.1: host probed renesas_usbhs renesas_usbhs.1: gadget probed renesas_usbhs renesas_usbhs.1: irq request err ------------[ cut here ]------------ WARNING: at ${LINUX}/drivers/base/core.c:1) Device 'gadget' does not have a release() function, it is broken and must be fi. Modules linked in: [<c000e25c>] (unwind_backtrace+0x0/0xe4) from [<c0016960>] (warn_slowpath_commo) [<c0016960>] (warn_slowpath_common+0x4c/0x64) from [<c00169f8>] (warn_slowpath_) [<c00169f8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0185b80>] (device_release+0x) [<c0185b80>] (device_release+0x70/0x84) from [<c013e300>] (kobject_cleanup+0x58) [<c013e300>] (kobject_cleanup+0x58/0x6c) from [<c01cba14>] (usbhs_mod_gadget_re) [<c01cba14>] (usbhs_mod_gadget_remove+0x3c/0x6c) from [<c01c8384>] (usbhs_mod_p) [<c01c8384>] (usbhs_mod_probe+0x68/0x80) from [<c01c7f84>] (usbhs_probe+0x1cc/0) ... Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: gadget: Clear usb_endpoint_descriptor inside the struct usb_ep on disableIdo Shayevitz
commit f9c56cdd3905c96c600456203637bd7ec8ec6383 upstream. This fix a bug in f_serial, which expect the ep->desc to be NULL after disabling an endpoint. Signed-off-by: Ido Shayevitz <idos@codeaurora.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: musb: Reselect index reg in interrupt contextSupriya Karanth
commit 39287076e46d2c19aaceaa6f0a44168ae4d257ec upstream. musb INDEX register is getting modified/corrupted during temporary un-locking in a SMP system. Set this register with proper value after re-acquiring the lock Scenario: --------- CPU1 is handling a data transfer completion interrupt received for the CLASS1 EP CPU2 is handling a CLASS2 thread which is queuing data to musb for transfer Below is the error sequence: CPU1 | CPU2 -------------------------------------------------------------------- Data transfer completion inter- | rupt recieved. | | musb INDEX reg set to CLASS1 EP | | musb LOCK is acquired. | | | CLASS2 thread queues data. | | CLASS2 thread tries to acquire musb | LOCK but lock is already taken by | CLASS1, so CLASS2 thread is | spinning. | From Interrupt Context musb | giveback function is called | | The giveback function releases | CLASS2 thread now acquires LOCK LOCK | | ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and lback is called | sets the MUSB INDEX to Class2 EP number | Interrupt handler for CLASS1 EP | tries to acquire LOCK and is | spinning | | Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and the MUSB LOCK | releases the musb LOCK | Interrupt for Class1 EP schedul-| es the next data transfer | but musb INDEX register is still| set to CLASS2 EP | Since the MUSB INDEX register is set to a different endpoint, we read and modify the wrong registers. Hence data transfer will not happen properly. This results in unpredictable behavior So, the MUSB INDEX register is set to proper value again when interrupt re-acquires the lock Signed-off-by: Supriya Karanth <supriya.karanth@stericsson.com> Signed-off-by: Praveena Nadahally <praveen.nadahally@stericsson.com> Reviewed-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-04-02staging: vme: fix section mismatches in linux-next 20120314Gerard Snitselaar
commit bf3a85be67068a0f55804349e6e1dce80008c45c upstream. pio2_gpio_init() annotated with __init, but called by pio2_probe() which is annotated __devinit. pio2_gpio_exit() is annotated __exit, but is called by pio2_probe() and by pio2_remove() which is annotated __devexit. Signed-off-by: Gerard Snitselaar <dev@snitselaar.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: dwc3: use proper function for setting endpoint nameAnton Tikhomirov
commit 27a78d6a283d6782438f72306746afe4bf44c215 upstream. It's wrong to use the size of array as an argument for strncat. Memory corruption is possible. strlcat is exactly what we need here. Signed-off-by: Anton Tikhomirov <av.tikhomirov@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: dwc3: fix bogus test in dwc3_gadget_start_isocPaul Zimmerman
commit 9bafa56c7cee5c6fa68de5924220abb220c7e229 upstream. Zero is a valid value for a microframe number. So remove the bogus test for non-zero in dwc3_gadget_start_isoc(). Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: dwc3: gadget: don't wrap around the TRB poll on non-ISOCPaul Zimmerman
commit 8d62cd65d74d0e241b3a152f7347bb66126b705b upstream. If we have a non-ISOC endpoint, we will not have a Link TRB pointing to the beginning of the TRB pool. On such endpoints, we don't want to let the driver wrap around the TRB pool otherwise controller will hang waiting for a valid TRB. Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02usb: dwc3: make dwc3_get_device_id() return the idDan Carpenter
commit 075cd14d2a8d35afc39ad28fc7b968275881266b upstream. We always return zero instead of the id we found. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02staging: r8712u: Fix regression in signal level after commit c6dc001Larry Finger
commit da3e6ec2f443ac00aa623c5921e3521f5f38efe4 upstream. In commit c6dc001 "staging: r8712u: Merging Realtek's latest (v2.6.6). Various fixes", the returned qual.qual member of the iw_statistics struct was changed. For strong signals, this change made no difference; however for medium and weak signals it results in a low signal that shows considerable fluctuation, When using wicd for a medium-strength AP, the value reported in the status line is reduced from 100% to 60% by this bug. This problem is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42826. Reported-and-tested-by: Robert Crawford <wrc1944@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02staging: r8712u: Fix regression introduced by commit a5ee652Larry Finger
commit 9f4bc8cf3fe750ed093856a5f5d41c11cc12ad22 upstream. In commit a5ee652 "staging: r8712u: Interface-state not fully tracked", the private boolean "bup" was set false when the interface was brought down, as that seemed appropriate. This change has not caused any problems when using NetworkManager or manual control of the device; however, when wicd control is used, there is a locking problem in wpa_supplicant, as shown in https://bugzilla.kernel.org/show_bug.cgi?id=42818. This fix reverts the only code change in commit a5ee652. My analysis is that "bup" is badly named. In its present form, it seems to indicate the up/down state of the device, but its usage is more consistent with an initialized/uninitialized state. That problem will be addressed in a later patch. Note: Commit 8c213fa, which introdued asynchronous firmware loading for this driver, exposed this bug to a greater extent. That bug is addressed in the next patch in this series. This bug is also responsible for the bug in https://bugzilla.kernel.org/show_bug.cgi?id=42815. and this bug is also part of the problems discussed at https://bugs.archlinux.org/task/27996#comment89950. Tested-by: Alberto Lago Ballesteros <saniukeokusainaya@gmail.com> Tested-by: Adrian <agib@gmx.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02powerpc/usb: fix bug of kernel hang when initializing usbShengzhou Liu
commit 28c56ea1431421dec51b7b229369e991481453df upstream. If USB UTMI PHY is not enable, writing to portsc register will lead to kernel hang during boot up. Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: ftdi_sio: new PID: LUMEL PD12Michał Wróbel
commit 57e596f3af88ef52dea9640ed5e34ecd38893a02 upstream. Signed-off-by: Michał Wróbel <michal.wrobel@flytronic.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: ftdi_sio: add support for FT-X series devicesJim Paris
commit dc0827c128c0ee5a58b822b99d662b59f4b8e970 upstream. Add PID 0x6015, corresponding to the new series of FT-X chips (FT220XD, FT201X, FT220X, FT221X, FT230X, FT231X, FT240X). They all appear as serial devices, and seem indistinguishable except for the default product string stored in their EEPROM. The baudrate generation matches FT232RL devices. Tested with a FT201X and FT230X at various baudrates (100 - 3000000). Sample dmesg: ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver usb 2-1: new full-speed USB device number 6 using ohci_hcd usb 2-1: New USB device found, idVendor=0403, idProduct=6015 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: FT230X USB Half UART usb 2-1: Manufacturer: FTDI usb 2-1: SerialNumber: DC001WI6 ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: ftdi_sio_port_probe drivers/usb/serial/ftdi_sio.c: ftdi_determine_type: bcdDevice = 0x1000, bNumInterfaces = 1 usb 2-1: Detected FT-X usb 2-1: Number of endpoints 2 usb 2-1: Endpoint 1 MaxPacketSize 64 usb 2-1: Endpoint 2 MaxPacketSize 64 usb 2-1: Setting MaxPacketSize 64 drivers/usb/serial/ftdi_sio.c: read_latency_timer drivers/usb/serial/ftdi_sio.c: write_latency_timer: setting latency timer = 1 drivers/usb/serial/ftdi_sio.c: create_sysfs_attrs drivers/usb/serial/ftdi_sio.c: sysfs attributes for FT-X usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0 Signed-off-by: Jim Paris <jim@jtan.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: ftdi_sio: new PID: Distortec JTAG-lock-pickMichał Wróbel
commit 47594d5528f28a4c025c2955c68104c75815637c upstream. Signed-off-by: Michał Wróbel <michal.wrobel@flytronic.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: Microchip VID mislabeled as Hornby VID in ftdi_sio.Bruno Thomsen
commit c1cee1d84001815a1b4321c49b995254c0df3100 upstream. Microchip VID (0x04d8) was mislabeled as Hornby VID according to USB-IDs. A Full Speed USB Demo Board PID (0x000a) was mislabeled as Hornby Elite (an Digital Command Controller Console for model railways). Most likely the Hornby based their design on PIC18F87J50 Full Speed USB Demo Board. Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: ftdi_sio: add support for BeagleBone rev A5+Peter Korsgaard
commit 444aa7fa9bd752d19ce472d3e02558b987c3cc67 upstream. BeagleBone changed to the default FTDI 0403:6010 id in rev A5 to make life easier for Windows users, so we need a similar workaround as the Calao board to support it. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: ftdi_sio: fix problem when the manufacture is a NULL stringGreg Kroah-Hartman
commit 656d2b3964a9d0f9864d472f8dfa2dd7dd42e6c0 upstream. On some misconfigured ftdi_sio devices, if the manufacturer string is NULL, the kernel will oops when the device is plugged in. This patch fixes the problem. Reported-by: Wojciech M Zabolotny <W.Zabolotny@elka.pw.edu.pl> Tested-by: Wojciech M Zabolotny <W.Zabolotny@elka.pw.edu.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02staging/octeon: Fix PHY binding in octeon-ethernet driver.David Daney
commit b5c19ca8014aa5151712274d5e70c3666a8918c1 upstream. Commit d6c25be (mdio-octeon: use an unique MDIO bus name.) changed the names used to refer to MDIO buses. The ethernet driver must be changed to match, so that the PHY drivers can be attached. Signed-off-by: David Daney <david.daney@cavium.com> Acked-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02staging: zcache: avoid AB-BA deadlock conditionAndrea Righi
commit cfbc6a92212e74b07aa76c9e2f20c542e36077fb upstream. Commit 9256a47 fixed a deadlock condition, being sure that the buddy list spinlock is always taken before the page spinlock. However in zbud_free_and_delist() locking order is the opposite (page lock -> list lock). Possible unsafe locking scenario (reported by lockdep): CPU0 CPU1 ---- ---- lock(&(&zbpg->lock)->rlock); lock(zbud_budlists_spinlock); lock(&(&zbpg->lock)->rlock); lock(zbud_budlists_spinlock); Fix by grabbing the locks in opposite order in zbud_free_and_delist(). Signed-off-by: Andrea Righi <andrea@betterlinux.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02staging: android/lowmemorykiller: Don't unregister notifier from atomic contextPaul E. McKenney
commit 1eda5166c7640092f512138be6899d050c3d62ed upstream. The lowmemorykiller registers an atomic notifier for notfication of when the task is freed. From this atomic notifier callback, it removes the atomic notifier via task_free_unregister(). This is incorrect because atomic_notifier_chain_unregister() calls syncronize_rcu(), which can sleep, which shouldn't be done from an atomic notifier. Fix this by registering the notifier during init, and only unregister it if the lowmemorykiller is unloaded. Rebased to -next by Paul E. McKenney. Rebased to -next again by Anton Vorontsov. Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com> Signed-off-by: Christian Bejram <christian.bejram@stericsson.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: option: add ZTE MF820DBjørn Mork
commit 5889d3d4209c1050b4a3c96c41faf6c0976a4acf upstream. This device presents a total of 5 interfaces with ff/ff/ff class/subclass/protocol. The last one of these is verified to be a QMI/wwan combined interface which should be handled by the qmi_wwan driver, so we blacklist it here. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: option: make interface blacklist work againBjørn Mork
commit 963940cf472d76eca2d36296e461202cc6997352 upstream. commit 0d905fd "USB: option: convert Huawei K3765, K4505, K4605 reservered interface to blacklist" accidentally ANDed two blacklist tests by leaving out a return. This was not noticed because the two consecutive bracketless if statements made it syntactically correct. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: option driver: adding support for Telit CC864-SINGLE, CC864-DUAL and ↵Daniele Palmas
DE910-DUAL modems commit 7204cf584836c24b4b06e4ad4a8e6bb8ea84908e upstream. Adding PID for Telit CC864-SINGLE, CC864-DUAL and DE910-DUAL modems Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-02USB: option: Add MediaTek MT6276M modem&app interfacesMeng Zhang
commit 0d8520a1d7f43328bc7085d4244d93c595064157 upstream. Add MEDIATEK products to Option driver Signed-off-by: Meng Zhang <meng.zhang@mediatek.com> Signed-off-by: Matthias Urlichs <matthias@urlichs.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>