- 06 Feb, 2014 40 commits
-
-
Sebastian Andrzej Siewior authored
commit d6a48452 upstream. In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added the PCI ID for NetMOS 9805 based on a Debian bug report from 2k4 which was at the v2.4.26 time frame. The patch made into 2.6.14. Shortly before that patch akpm merged commit 296d3c78 ("[PATCH] Support NetMOS based PCI cards providing serial and parallel ports") which made into v2.6.9-rc1. Now we have two different entries for the same PCI id. I have here the NetMos 9805 which claims to support SPP/EPP/ECP mode. This patch takes Max's entry for titan_1284p1 (base != -1 specifies the ioport for ECP mode) and replaces akpm's entry for netmos_9805 which specified -1 (=none). Both share the same PCI-ID (my card has subsystem 0x1000 / 0x0020 so it should match PCI_ANY). While here I also drop the entry for titan_1284p2 which is the same as netmos_9815. Cc: Maximilian Attems <maks@stro.at> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heiko Carstens authored
commit 4e078146 upstream. With b8668fd0 "s390/uapi: change struct statfs[64] member types to unsigned values" the size of a couple of struct statfs64 member got incorrectly changed from 64 to 32 bit for 32 bit builds. Fix this by changing the type of couple of struct statfs64 members from unsigned long to unsigned long long. The definition of struct compat_statfs64 was correct however. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Dominik Dingel authored
commit ff1f3cb4 upstream. The diagnose 500 subcode 3 contains the 32 bit subchannel id in bits 32-63 (counting from the left). As for other I/O instructions, bits 0-31 should be ignored and thus not be passed to kvm_io_bus_write_cookie(). This fixes a bug where the guest passed non-zero bits 0-31 which the host tried to interpret, leading to ioeventfd notification failures. Signed-off-by:
Dominik Dingel <dingel@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
commit 743db27c upstream. The diagnose code to be used is the contents of the base register (if not zero), plus the displacement. The current code ignores the base register contents. So let's fix that... Reviewed-by:
-
Stephen Warren authored
commit 3685f19e upstream. Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have their MODEM-control signals tied off to a static state. However UARTs A and B can optionally route those signals to/from package pins, depending on the exact pinmux configuration. When these signals are not routed to package pins, false interrupts may trigger either temporarily, or permanently, all while not showing up in the IIR; it will read as NO_INT. This will eventually lead to the UART IRQ being disabled due to unhandled interrupts. When this happens, the kernel may print e.g.: irq 68: nobody cared (try booting with the "irqpoll" option) In order to prevent this, enable UART_BUG_NOMSR. This prevents UART_IER_MSI from being enabled, which prevents the false interrupts from triggering. In practice, this is not needed under any of the following conditions: * On Tegra chips after Tegra30, since the HW bug has apparently been fixed. * On UARTs C..E since their MODEM control signals are tied to the correct static state which doesn't trigger the issue. * On UARTs A..B if the MODEM control signals are routed out to package pins, since they will then carry valid signals. However, we ignore these exceptions for now, since they are only relevant if a board actually hooks up more than a 4-wire UART, and no currently supported board does this. If we ever support a board that does, we can refine the algorithm that enables UART_BUG_NOMSR to take those exceptions into account, and/or read a flag from DT/... that indicates that the board has hooked up and pinmux'd more than a 4-wire UART. Reported-by: Olof Johansson <olof@lixom.net> # autotester Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Jonathan Woithe authored
commit 9c5320f8 upstream. Fix the initialisation of older Quatech serial cards which are fitted with the AMCC PCI Matchmaker interface chip. Signed-off-by: Jonathan Woithe (jwoithe@just42.net) Signed-off-by:
-
Yegor Yefremov authored
commit 48c0247d upstream. Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
-
Sarah Sharp authored
commit f2d9b991 upstream. Commit 35773dac "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix an issue found with USB ethernet adapters, and inadvertently broke USB storage devices. The patch attempts to ensure that transfers never span a segment, and rejects transfers that have more than 63 entries (or possibly less, if some entries cross 64KB boundaries). usb-storage limits the maximum transfer size to 120K, and we had assumed the block layer would pass a scatter-gather list of 4K entries, resulting in no more than 31 sglist entries: http://marc.info/?l=linux-usb&m=138498190419312&w=2 That assumption was wrong, since we've seen the driver reject a write that was 218 sectors long (of probably 512 bytes each): Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63 ... Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00 Limit the number of scatter-gather entries to half a ring segment. That should be margin enough in case some entries cross 64KB boundaries. Increase the number of TRBs per segment from 64 to 256, which should result in ring segments fitting on a 4K page. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: jidanni@jidanni.org References: http://bugs.debian.org/733907 Fixes: 35773dac ('usb: xhci: Link TRB must not occur within a USB payload burst') Signed-off-by:
-
Ben Hutchings authored
commit d6c9ea90 upstream. Currently prepare_ring() returns -ENOMEM if the urb won't fit into a single ring segment. usb_sg_wait() treats this error as a temporary condition and will keep retrying until something else goes wrong. The number of retries should be limited in usb_sg_wait(), but also prepare_ring() should not return an error code that suggests it might be worth retrying. Change it to -EINVAL. Reported-by: jidanni@jidanni.org References: http://bugs.debian.org/733907 Fixes: 35773dac ('usb: xhci: Link TRB must not occur within a USB payload burst') Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Phil Pokorny authored
commit d303b1b5 upstream. Add new PCI ID to support new model "Kaveri" family. Signed-off-by:
Philip Pokorny <ppokorny@penguincomputing.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jean-Jacques Hiblot authored
commit 1588c51c upstream. There was a copy/paste error when reading the nwe_pulse value. Signed-off-by:
Jean-Jacques Hiblot <jjhiblot@traphandler.com> Acked-by:
Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Ludovic Desroches authored
commit 0645b93f upstream. pinctrl-names property was missing from mmc nodes. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Marek Roszko authored
commit 8bc661bf upstream. The uart timer will schedule a tasklet when it fires. It is possible that it can fire inside _shutdown before it is killed in the dma and pdc cleanup routines. This causes a tasklet that exists after the port is shutdown, so when the kernel finally executes it, it panics as the tty port is NULL. This is a somewhat rare condition but its possible if a program keeps on opening/closing the port. It has been observed in particular with systemd boot messages that were causing a kernel panic because of this behavior. Moving the timer deletion to the beginning of the function stops a tasklet from being scheduled unexpectedly. Signed-off-by:
Marek Roszko <mark.roszko@gmail.com> [nicolas.ferre@atmel.com: modify commit message, call setup_timer() in any case] Signed-off-by:
-
Mark Deneen authored
commit bb7e73c5 upstream. When using RX DMA, the driver won't pass any data to the uart layer until the buffer is flipped. When the port is shutdown, the dma buffers are unmapped, but the head and tail of the ring buffer are not reseted. Since the serial console will keep the port open, this will only present itself when the uart is not shared. To reproduce the issue, with an unpatched driver, run a getty on /dev/ttyS0 with no serial console and exit. Getty will exit, and when the new one returns you will be unable to log in. If you hold down a key long enough to fill the DMA buffer and flip it, you can then log in. Signed-off-by:
Mark Deneen <mdeneen@gmail.com> Acked-by:
Leilei Zhao <leilei.zhao@atmel.com> [nicolas.ferre@atmel.com: adapt to mainline kernel, handle !DMA case] Signed-off-by:
-
Marek Roszko authored
commit f50c995f upstream. The _remove callback could be called when a tasklet is scheduled. tasklet_kill was called inside the function in order to free up any scheduled tasklets. However it was called after uart_remove_one_port which destroys tty references needed in the port for atmel_tasklet_func. Simply putting the tasklet_kill at the start of the function will prevent this conflict. Signed-off-by:
-
Marek Roszko authored
commit 0cc7c6c7 upstream. Interrupts were being cleaned up late in the shutdown handler, it is possible that an interrupt can occur and schedule a tasklet that runs after the port is cleaned up. There is a null dereference due to this race condition with the following stacktrace: [<c02092b0>] (atmel_tasklet_func+0x514/0x814) from [<c001fd34>] (tasklet_action+0x70/0xa8) [<c001fd34>] (tasklet_action+0x70/0xa8) from [<c001f60c>] (__do_softirq+0x90/0x144) [<c001f60c>] (__do_softirq+0x90/0x144) from [<c001fa18>] (irq_exit+0x40/0x4c) [<c001fa18>] (irq_exit+0x40/0x4c) from [<c000e298>] (handle_IRQ+0x64/0x84) [<c000e298>] (handle_IRQ+0x64/0x84) from [<c000d6c0>] (__irq_svc+0x40/0x50) [<c000d6c0>] (__irq_svc+0x40/0x50) from [<c0208060>] (atmel_rx_dma_release+0x88/0xb8) [<c0208060>] (atmel_rx_dma_release+0x88/0xb8) from [<c0209740>] (atmel_shutdown+0x104/0x160) [<c0209740>] (atmel_shutdown+0x104/0x160) from [<c0205e8c>] (uart_port_shutdown+0x2c/0x38) Signed-off-by:
-
Tomas Winkler authored
commit 66ae460b upstream. When reset is caused by hbm protocol mismatch or timeout we might end up in an endless reset loop and hbm protocol will never sync Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
-
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:
-
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:
-
