- 06 Feb, 2014 40 commits
-
-
Malcolm Priestley authored
commit 9acec059 upstream. value uLowNextTBTT yields wrong value. ULL is needed with qwTSF Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Malcolm Priestley authored
commit 8f248dae upstream. byBBPreEDIndex value is initially 0, this means that from cold BBvUpdatePreEDThreshold is never set. This means that sensitivity may be in an ambiguous state, failing to scan any wireless points or at least distant ones. Signed-off-by:
-
Larry Finger authored
commit 3a21f00a upstream. The latest version of NetworkManager does not recognize the device as wireless without this change. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Amir Shehata authored
commit 3c92a0bf upstream. When a system runs out of memory and the function ptlrpc_register_bulk() is called from ptl_send_rpc() the call to LNetMEAttach() fails due to failure to allocate memory. This forces the code into an error path, which most probably previously went untested. The error path: if (rc != 0) { CERROR("%s: LNetMEAttach failed x"LPU64"/%d: rc = %dn", desc->bd_export->exp_obd->obd_name, xid, posted_md, rc); break; } This print assumes that desc->bd_export is not NULL. However, it is. In fact it is expected to be NULL. desc->bd_import is the correct structure to access in this case. Lustre-change: http://review.whamcloud.com/7121 Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3585Signed-off-by:
Amir Shehata <amir.shehata@intel.com> Reviewed-by:
Liang Zhen <liang.zhen@intel.com> Reviewed-by:
Doug Oucharek <doug.s.oucharek@intel.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com> Signed-off-by:
Peng Tao <bergwolf@gmail.com> Signed-off-by:
Andreas Dilger <andreas.dilger@intel.com> Signed-off-by:
-
Sujith Manoharan authored
commit 1e2f9295 upstream. Fast Channel Change across bands was enabled for AR9462 recently, but this is causing baseband issues. Disable it until this feature is tested well. Also, remove the feature bit for AR9565 since it is a single-band card and doesn't support this feature. Reported-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Sujith Manoharan authored
commit ff9a93f2 upstream. Accessing the current channel definition in mac80211 when processing RX packets is problematic because it could have been updated when a scan is issued. Since a channel change involves flushing the existing packets in the RX queue before a chip-reset is done, they would be processed using the wrong band/channel information. To avoid this, use the current channel information maintained in the driver. Reported-by:
-
ZHAO Gang authored
commit 64e5acb0 upstream. Use the right function to update frequency value. If rx skb is probe response or beacon, the wrong frequency value can cause problem that bss info can't be updated when it should be. Fixes: 8318d78a ("cfg80211 API for channels/bitrates, mac80211 and driver conversion") Signed-off-by:
ZHAO Gang <gamerh2o@gmail.com> Acked-by:
-
Larry Finger authored
commit 45202866 upstream. The asyncronous firmware load uses a completion struct to hold firmware processing until the user-space routines are up and running. There is. however, a problem in that the waiter is nevered canceled during teardown. As a result, unloading the driver when firmware is not available causes an oops. Signed-off-by:
-
Larry Finger authored
commit 0673effd upstream. The asyncronous firmware load uses a completion struct to hold firmware processing until the user-space routines are up and running. There is. however, a problem in that the waiter is nevered canceled during teardown. As a result, unloading the driver when firmware is not available causes an oops. To be able to access the completion structure at teardown, it had to be moved into the b43_wldev structure. This patch also fixes a typo in a comment. Signed-off-by:
-
Larry Finger authored
commit 09164043 upstream. In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is reported when b43 is used with hostapd, and rfkill is used to kill the radio output. The lockdep splat (in part) is as follows: ====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0 #1 Not tainted ------------------------------------------------------- rfkill/10040 is trying to acquire lock: (rtnl_mutex){+.+.+.}, at: [<ffffffff8146f282>] rtnl_lock+0x12/0x20 but task is already holding lock: (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa04832ca>] rfkill_fop_write+0x6a/0x170 [rfkill] --snip-- Chain exists of: rtnl_mutex --> misc_mtx --> rfkill_global_mutex The fix is to move the initialization of the hardware random number generator outside the code range covered by the rtnl_mutex. Reported-by:
yury <urykhy@gmail.com> Tested-by:
-
Eliad Peller authored
commit 91b0d119 upstream. Cleanup of iwl_mvm_leds was missing in case of error, resulting in the following warning: WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x210() kobject_add_internal failed for phy0-led with -EEXIST, don't try to register things with the same name in the same directory. which prevents further reloads of the driver. Signed-off-by:
Eliad Peller <eliadx.peller@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 2d93aee1 upstream. Enabling the oscillator consumes slightly more power (100uA) but allows to make sure that we exit from L1 on time. Not doing so might lead to a PCIe specification violation since we might wake up from L1 at the wrong time. This issue has been identified on 3160 and 7260 only. On older NICs L1 off is not enabled, on newer NICs (7265), the issue is fixed. When the bug occurs the user sees that the NIC has disappeared from the PCI bridge, any access to the device returns 0xff. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=64541 and has been extensively discussed here: http://markmail.org/thread/mfmpzqt3r333n4bo Fixes: 99cd4714 ("iwlwifi: add 7000 series device configuration") Reported-and-tested-by:
wzyboy <wzyboy@wzyboy.org> Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Bing Zhao authored
commit 1e202242 upstream. bit 14 is actually reserved and bit 12 & 13 should be used for 11ac capability in fw_cap_info. Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
commit 97952297 upstream. It is u64 data received from firmware. Little endian to cpu conversion is required here. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Larry Finger authored
commit f699273d upstream. The static analyser "cppcheck" shows the following typo: drivers/net/wireless/rtlwifi/rtl8188ee/dm.c:1081]: (style) Same expression on both sides of '!='. Signed-off-by:
David Binderman <dcb314@hotmail.com> Cc: David Binderman <dcb314@hotmail.com> Signed-off-by:
-
Larry Finger authored
commit d82403a9 upstream. Signed-off-by:
-
Larry Finger authored
commit e9b0784b upstream. Signed-off-by:
-
Larry Finger authored
commit 9806eacf upstream. This patch uses the newly introduced power index register routines. Signed-off-by:
-
Larry Finger authored
commit 97204e93 upstream. Signed-off-by:
-
Larry Finger authored
commit dc640571 upstream. The current number of RX buffers queued is 32, which is too small under heavy load. That number is doubled. Signed-off-by:
-
Larry Finger authored
commit c908c74e upstream. Changes in the gain-control mechanism will require some changes in the header. Signed-off-by:
-
Larry Finger authored
commit 619ce76f upstream. The present code fails to set the linked state when an interface is added. Signed-off-by:
-
Larry Finger authored
commit b9a758a8 upstream. The initial USB driver did not use some register save locations in the private data storage. To save some memory, a union was used to overlay these variables with USB I/O components. In an update of the gain-control code, these register save locations are now needed for USB drivers. Signed-off-by:
-
Larry Finger authored
commit 62009b7f upstream. Vendor driver rtl8188C_8192C_8192D_usb_linux_v3.4.2_3727.20120404 introduced new firmware for these chips. The code try for the new file, and fall back to the original firmware if the new file is not available. Signed-off-by:
-
Larry Finger authored
commit 8fd77aec upstream. This driver has a watchdog timer that attempts to reconnect when beacon frames are not seen for 6 seconds. This patch disables that reconnect whenever the device has never been connected. Signed-off-by:
-
Larry Finger authored
commit 65b9cc97 upstream. The USB drivers were not updating the beacon statistics, which led to false beacon loss indications. Signed-off-by:
-
Larry Finger authored
commit f87f960b upstream. Reported-by:
Jan Prinsloo <janroot@gmail.com> Tested-by:
-
Peter Chen authored
commit feffe09f upstream. According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB register error issue", All USB register write operations must use the ARM SWP instruction. So, we implement a special ehci_write for imx28. Discussion for it at below: http://marc.info/?l=linux-usb&m=137996395529294&w=2 Without this patcheset, imx28 works unstable at high AHB bus loading. If the bus loading is not high, the imx28 usb can work well at the most of time. There is a IC errata for this problem, usually, we consider IC errata is a problem not a new feature, and this workaround is needed for that, so we need to add them to stable tree 3.11+. Cc: robert.hodaszi@digi.com Signed-off-by:
Peter Chen <peter.chen@freescale.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Tested-by:
-
Alan Stern authored
commit 543d7784 upstream. There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d6082>] usb_set_device_state+0x92/0x120 [<c16d862b>] usb_disconnect+0x2b/0x1a0 [<c16dd4c0>] usb_remove_hcd+0xb0/0x160 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c1704efc>] ehci_mid_remove+0x1c/0x30 [<c1704f26>] ehci_mid_stop_host+0x16/0x30 [<c16f7698>] penwell_otg_work+0xd28/0x3520 [<c19c945b>] ? __schedule+0x39b/0x7f0 [<c19cdb9d>] ? sub_preempt_count+0x3d/0x50 [<c125e97d>] process_one_work+0x11d/0x3d0 [<c19c7f4d>] ? mutex_unlock+0xd/0x10 [<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270 [<c125f009>] worker_thread+0xf9/0x320 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c125ef10>] ? rescuer_thread+0x2b0/0x2b0 [<c1264ac4>] kthread+0x94/0xa0 [<c19d0f77>] ret_from_kernel_thread+0x1b/0x28 [<c1264a30>] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by:
"Du, Changbin" <changbinx.du@intel.com> Tested-by:
-
Jack Pham authored
commit 9005355a upstream. If CONFIG_PCI is enabled, make sure xhci_cleanup_msix() doesn't try to free a bogus PCI IRQ or dereference an invalid pci_dev when the xHCI device is actually a platform_device. This patch should be backported to kernels as old as 3.9, that contain the commit 52fb6125 "xhci-plat: Don't enable legacy PCI interrupts." Signed-off-by:
Jack Pham <jackp@codeaurora.org> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Mikhail Zolotaryov authored
commit 0e16114f upstream. The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered files are corrupted). A similar issue is described here: http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170 The workaround is (MAX_SECTORS_64): rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m The patch adds the tested device to the unusual list permanently. Signed-off-by:
Mikhail Zolotaryov <lebon@lebon.org.ua> Signed-off-by:
-
Colin Leitner authored
commit c1f15196 upstream. Genuine FTDI chips support only CS7/8. A previous fix in commit 8704211f ("USB: ftdi_sio: fixed handling of unsupported CSIZE setting") enforced this limitation and reported it back to userspace. However, certain types of smartcard readers depend on specific driver behaviour that requests 0 data bits (not 5) to change into a different operating mode if CS5 has been set. This patch reenables this behaviour for all FTDI devices. Tagged to be added to stable, because it affects a lot of users of embedded systems which rely on these readers to work properly. Reported-by:
Heinrich Siebmanns <H.Siebmanns@t-online.de> Tested-by:
Colin Leitner <colin.leitner@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 440ebade upstream. Fix ring-indicator (RI) status-bit definition, which was defined as CTS, effectively preventing RI-changes from being detected while reporting false RI status. This bug predates git. Signed-off-by:
-
Rahul Bedarkar authored
commit 7d5c1b9c upstream. Add support for iBall 3.5G connect usb modem. $lsusb Bus 002 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY $usb-devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=9605 Rev=00.00 S: Manufacturer=USB Modem S: Product=USB Modem S: SerialNumber=1234567890ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by:
Rahul Bedarkar <rahulbedarkar89@gmail.com> Suggested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
张君 authored
commit 4d90b819 upstream. Signed-off-by:
Jun zhang <zhang.jun92@zte.com.cn> Signed-off-by:
-
Johan Hovold authored
commit 623c8263 upstream. Some PL2303 devices are known to lose bytes if you change serial settings even to the same values as before. Avoid this by comparing the encoded settings with the previsouly used ones before configuring the device. The common case was fixed by commit bf5e5834 ("pl2303: Fix mode switching regression"), but this problem was still possible to trigger, for instance, by using the TCSETS2-interface to repeatedly request 115201 baud, which gets mapped to 115200 and thus always triggers a settings update. Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Peter Chen authored
commit 2fc5a7da upstream. We have met a bug that the high bandwidth ISO-TX transfer has failed at the last packet if it is less than 1024, the TD status shows it is "Transaction Error". The root cause of this problem is: the mult value at qh is not correct for current TD's transfer length. We use TD list to queue un-transfer TDs, and change mult for new adding TDs. If new adding TDs transfer length less than 1024, but the queued un-transfer TDs transfer length is larger than 1024, the transfer error will occur, and vice versa. Usually, this problem occurs at the last packet, and the first packet for new frame. We fixed this problem by setting Mult at QH as the largest value (3), and set MultO (Multiplier Override) at TD according to every transfer length. It can cover both hardware version less than 2.3 (the real mult is MultO if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)). Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior unchanged. For stable tree: 3.11+. Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Reported-by:
Matthieu Vanin <b47495@freescale.com> Tested-by:
-
Peter Chen authored
commit 5332ff1f upstream. For otgsc, both enable bits and status bits are in it. So we need to make sure the status bits are not be cleared when write enable bits. It can fix one bug that we plug in/out Micro AB cable fast, and sometimes, the IDIS will be cleared wrongly when handle last ID interrupt (ID 0->1), so the current interrupt will not occur. For stable tree: 3.12+ Signed-off-by:
-
Peter Chen authored
commit 1071055e upstream. Due to imx28 needs ARM swp instruction for writing, we set CI_HDRC_IMX28_WRITE_FIX for imx28. This patch is needed for stable tree 3.11+ Cc: robert.hodaszi@digi.com Signed-off-by:
-
Peter Chen authored
commit ed8f8318 upstream. According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB register error issue", All USB register write operations must use the ARM SWP instruction. So, we implement special hw_write and hw_test_and_clear for imx28. Discussion for it at below: http://marc.info/?l=linux-usb&m=137996395529294&w=2 This patch is needed for stable tree 3.11+. Cc: robert.hodaszi@digi.com Signed-off-by:
-
