summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2009-07-30NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines.Ralf Baechle
[ Upstream commit adeab1afb7de89555c69aab5ca21300c14af6369 ] Guido Trentalancia reports: I am trying to use the kiss driver in the Linux kernel that is being shipped with Fedora 10 but unfortunately I get the following oops: mkiss: AX.25 Multikiss, Hans Albas PE1AYX mkiss: ax0: crc mode is auto. ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready ------------[ cut here ]------------ WARNING: at kernel/softirq.c:77 __local_bh_disable+0x2f/0x83() (Not tainted) [...] unloaded: microcode] Pid: 0, comm: swapper Not tainted 2.6.27.25-170.2.72.fc10.i686 #1 [<c042ddfb>] warn_on_slowpath+0x65/0x8b [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c04228b4>] ? __enqueue_entity+0xe3/0xeb [<c042431e>] ? enqueue_entity+0x203/0x20b [<c0424361>] ? enqueue_task_fair+0x3b/0x3f [<c041f88c>] ? resched_task+0x3a/0x6e [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16 [<c043255b>] __local_bh_disable+0x2f/0x83 [<c04325ba>] local_bh_disable+0xb/0xd [<c06ab4e2>] _spin_lock_bh+0xb/0x16 [<f8b6f600>] mkiss_receive_buf+0x2fb/0x3a6 [mkiss] [<c0572a30>] flush_to_ldisc+0xf7/0x198 [<c0572b12>] tty_flip_buffer_push+0x41/0x51 [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio] [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio] [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93 [<c05ea290>] uhci_giveback_urb+0xe5/0x15f [<c05eaabf>] uhci_scan_schedule+0x52e/0x767 [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5 [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1 [<c05ec5b0>] uhci_irq+0x110/0x125 [<c05d4834>] usb_hcd_irq+0x40/0xa3 [<c0465313>] handle_IRQ_event+0x2f/0x64 [<c046642b>] handle_level_irq+0x74/0xbe [<c04663b7>] ? handle_level_irq+0x0/0xbe [<c0406e6e>] do_IRQ+0xc7/0xfe [<c0405668>] common_interrupt+0x28/0x30 [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d [<c0617f52>] cpuidle_idle_call+0x60/0x92 [<c0403c61>] cpu_idle+0x101/0x134 [<c069b1ba>] rest_init+0x4e/0x50 ======================= ---[ end trace b7cc8076093467ad ]--- ------------[ cut here ]------------ WARNING: at kernel/softirq.c:136 _local_bh_enable_ip+0x3d/0xc4() [...] Pid: 0, comm: swapper Tainted: G W 2.6.27.25-170.2.72.fc10.i686 [<c042ddfb>] warn_on_slowpath+0x65/0x8b [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c04228b4>] ? __enqueue_entity+0xe3/0xeb [<c042431e>] ? enqueue_entity+0x203/0x20b [<c0424361>] ? enqueue_task_fair+0x3b/0x3f [<c041f88c>] ? resched_task+0x3a/0x6e [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16 [<f8b6f642>] ? mkiss_receive_buf+0x33d/0x3a6 [mkiss] [<c04325f9>] _local_bh_enable_ip+0x3d/0xc4 [<c0432688>] local_bh_enable_ip+0x8/0xa [<c06ab54d>] _spin_unlock_bh+0x11/0x13 [<f8b6f642>] mkiss_receive_buf+0x33d/0x3a6 [mkiss] [<c0572a30>] flush_to_ldisc+0xf7/0x198 [<c0572b12>] tty_flip_buffer_push+0x41/0x51 [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio] [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio] [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93 [<c05ea290>] uhci_giveback_urb+0xe5/0x15f [<c05eaabf>] uhci_scan_schedule+0x52e/0x767 [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5 [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1 [<c05ec5b0>] uhci_irq+0x110/0x125 [<c05d4834>] usb_hcd_irq+0x40/0xa3 [<c0465313>] handle_IRQ_event+0x2f/0x64 [<c046642b>] handle_level_irq+0x74/0xbe [<c04663b7>] ? handle_level_irq+0x0/0xbe [<c0406e6e>] do_IRQ+0xc7/0xfe [<c0405668>] common_interrupt+0x28/0x30 [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d [<c0617f52>] cpuidle_idle_call+0x60/0x92 [<c0403c61>] cpu_idle+0x101/0x134 [<c069b1ba>] rest_init+0x4e/0x50 ======================= ---[ end trace b7cc8076093467ad ]--- mkiss: ax0: Trying crc-smack mkiss: ax0: Trying crc-flexnet The issue was, that the locking code in mkiss was assuming it was only ever being called in process or bh context. Fixed by converting the involved locking code to use irq-safe locks. Review of other networking line disciplines shows that 6pack, both sync and async PPP and STRIP have similar issues. The ppp_async one is the most interesting one as it sorts out half of the issue as far back as 2004 in commit http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=2996d8deaeddd01820691a872550dc0cfba0c37d Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Reported-by: Guido Trentalancia <guido@trentalancia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30E100: work around the driver using streaming DMA mapping for RX descriptors.Krzysztof Halasa
[ Upstream commit 303d67c288319768b19ed8dbed429fef7eb7c275 ] E100 places it's RX packet descriptors inside skb->data and uses them with bidirectional streaming DMA mapping. Unfortunately it fails to transfer skb->data ownership to the device after it reads the descriptor's status, breaking on non-coherent (e.g., ARM) platforms. This have to be converted to use coherent memory for the descriptors. Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30r8169: avoid losing MSI interruptsDavid Dillow
[ Upstream commit f11a377b3f4e897d11f0e8d1fc688667e2f19708 ] The 8169 chip only generates MSI interrupts when all enabled event sources are quiescent and one or more sources transition to active. If not all of the active events are acknowledged, or a new event becomes active while the existing ones are cleared in the handler, we will not see a new interrupt. The current interrupt handler masks off the Rx and Tx events once the NAPI handler has been scheduled, which opens a race window in which we can get another Rx or Tx event and never ACK'ing it, stopping all activity until the link is reset (ifconfig down/up). Fix this by always ACK'ing all event sources, and loop in the handler until we have all sources quiescent. Signed-off-by: David Dillow <dave@thedillows.org> Tested-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30usbnet cdc_subset: fix issues talking to PXA gadgetsDavid Brownell
[ Upstream commit 6be832529a8129c9d90a1d3a78c5d503a710b6fc ] The host-side CDC subset driver is binding more specifically than it should ... only to PXA 210/25x/26x Linux-USB gadgets. Loosen that restriction to match the gadget driver driver. This will various PXA 27x and PXA 3xx devices happier when talking to Linux hosts, potentially others. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Tested-by: Aric D. Blumer <aric@sdgsystems.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30sky2: Fix checksum endiannessAnton Vorontsov
[ Upstream commit b9389796fa4c87fbdff33816e317cdae5f36dd0b ] sky2 driver on PowerPC targets floods kernel log with following errors: eth1: hw csum failure. Call Trace: [ef84b8a0] [c00075e4] show_stack+0x50/0x160 (unreliable) [ef84b8d0] [c02fa178] netdev_rx_csum_fault+0x3c/0x5c [ef84b8f0] [c02f6920] __skb_checksum_complete_head+0x7c/0x84 [ef84b900] [c02f693c] __skb_checksum_complete+0x14/0x24 [ef84b910] [c0337e08] tcp_v4_rcv+0x4c8/0x6f8 [ef84b940] [c031a9c8] ip_local_deliver+0x98/0x210 [ef84b960] [c031a788] ip_rcv+0x38c/0x534 [ef84b990] [c0300338] netif_receive_skb+0x260/0x36c [ef84b9c0] [c025de00] sky2_poll+0x5dc/0xcf8 [ef84ba20] [c02fb7fc] net_rx_action+0xc0/0x144 The NIC is Yukon-2 EC chip revision 1. Converting checksum field from le16 to CPU byte order fixes the issue. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30pegasus usb-net: Fix endianness bugsMichael Buesch
[ Upstream commit e3453f6342110d60edb37be92c4a4f668ca8b0c4 ] This fixes various endianness bugs. Some harmless and some real ones. This is tested on a PowerPC-64 machine. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30Input: wistron_btns - recognize Maxdata Pro 7000 notebooksGiuseppe Mazzotta
commit e705cee427e319665969ef7ac664f3612dec8899 upstream. This patch adds DMI information to automatically load the correct layout for the Maxdata Pro 7000X/DX notebook models. Such notebooks are clones of Fujitsu Amilo V2000, the hook for the v2000 is being used and I have tested that perfectly works. The immediate result of integrating this patch is that the five special buttons will work on these specific notebook models and that the RF killswitch will not be activated after suspend. This patch definitively obsoletes the fsam7400 module which I was still needing to enable wifi and to fix the RF killswitch suspend problem; in the current 2.6.30 kernel it is necessary to load the wistron_btns module with options 'force=1 keymap=1557/MS2141', which was not anyway a complete workaround. Signed-off-by: Giuseppe Mazzotta <g.mazzotta@iragan.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30ACPI: suspend: don't let device _PS3 failure prevent suspendLen Brown
commit 19bde778c1fd2574cc020a618d7d576f260271ca upstream. 6328a57401dc5f5cf9931738eb7268fcd8058c49 "Enable PNPACPI _PSx Support, v3" added a call to acpi_bus_set_power(handle, ACPI_STATE_D3) to pnpacpi_disable_resource() before the existing call to evaluate _DIS on the device. This caused suspend to fail on the system in http://bugzilla.kernel.org/show_bug.cgi?id=13243 because the sanity check to verify we entered _PS3 failed on the serial port. As a work-around, that sanity check can be disabled system-wide with "acpi.power_nocheck=1" Or perhaps we should just shrug off the _PS3 failure and carry on with _DIS like we used to -- which is what this patch does. Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30Enable PNPACPI _PSx Support, v3Witold Szczeponik
commit 6328a57401dc5f5cf9931738eb7268fcd8058c49 upstream. (This is an update to the patch presented earlier in http://lkml.org/lkml/2008/12/8/284, with new error handling.) This patch sets the power of PnP ACPI devices to D0 when they are activated and to D3 when they are disabled. The latter is in correspondence with the ACPI 3.0 specification, whereas the former is added in order to be able to power up a device after it has been previously disabled (or when booting up a system). (As a consequence, the patch makes the PnP ACPI code more ACPI compliant.) Section 6.2.2 of the ACPI Specification (at least versions 1.0b and 3.0a) states: "Prior to running this control method [_DIS], the OS[PM] will have already put the device in the D3 state." Unfortunately, there is no clear statement as to when to put a device in the D0 state. :-( Therefore, the patch executes the method calls as _PS3/_DIS and _SRS/_PS0. What is clear: "If the device is disabled, _SRS enables the device at the specified resources." (From the ACPI 3.0a Specification.) The patch fixes a problem with some IBM ThinkPads (at least the 600E and the 600X) where the serial ports have a dedicated power source that needs to be brought up before the serial port can be used. Without this patch, the serial port is enabled but has no power. (In the past, the tpctl utility had to be utilized to turn on the power, but support for this feature stopped with version 5.9 as it did not support the more recent kernel versions.) The error handlers that handle any errors that can occur during the power up/power down phases return the error codes to the caller directly. Comments welcome! :-) No regressions were observed on hardware that does not require this patch. The patch is applied against 2.6.27.x. Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net> Acked-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30ACPI: EC: Limit workaround for ASUS notebooks even moreAlexey Starikovskiy
commit 235c4a59278eb07e61d909f1f0c233733034a8b3 upstream. References: http://bugzilla.kernel.org/show_bug.cgi?id=11884 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30md: avoid dereferencing NULL pointer when accessing suspend_* sysfs attributes.NeilBrown
commit b8d966efd9a46a9a35beac50cbff6e30565125ef upstream. If we try to modify one of the md/ sysfs files suspend_lo or suspend_hi when the array is not active, we dereference a NULL. Protect against that. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30hwmon: (max6650) Fix lock imbalanceJiri Slaby
commit 025dc740d01f99ccba945df1f9ef9e06b1c15d96 upstream. Add omitted update_lock to one switch/case in set_div. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Acked-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30HID: hiddev, fix lock imbalanceJiri Slaby
commit 4859484b0957ddc7fe3e0fa349d98b0f1c7876bd upstream. Add omitted BKL to one switch/case. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30USB: ti_usb_3410_5052: fix duplicate device ids.Greg Kroah-Hartman
commit 3c43f27bf57b0502df2478253699559ee1d43f6d upstream. commit 1a1fab513734b3a4fca1bee8229e5ff7e1cb873c accidentally added the device id to both tables in the driver, which causes problems as this is only a single port device, not a multiple port device. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30USB: RNDIS gadget, fix issues talking from PXADavid Brownell
commit 4e19f220d4e84f5728cb7edde36352ab425cfba4 upstream. The reworked Ethernet gadget has an RNDIS interop problem when used with the CDC subset driver ... e.g. on PXA 2xx and 3xx hardware, which currently has a hard time talking to MS-Windows hosts. The issue is that Microsoft requires USB_CLASS_COMM. Fix by tweaking the CDC subset driver to not switch to USB_CLASS_VENDOR_SPEC if RNDIS is used in some other device configuration. [ UPDATED: some "statements" were comma-terminated; fix that. ] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Aric Blumer <aric@sdgsystems.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30USB: handle zero-length usbfs submissions correctlyAlan Stern
commit 9180135bc80ab11199d482b6111e23f74d65af4a upstream. This patch (as1262) fixes a bug in usbfs: It refuses to accept zero-length transfers, and it insists that the buffer pointer be valid even if there is no data being transferred. The patch also consolidates a bunch of repetitive access_ok() checks into a single check, which incidentally fixes the lack of such a check for Isochronous URBs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30USB: fix uninitialised variable in ti_do_downloadOliver Neukum
commit 87ea8c887905d8b13ae90b537117592ed027632a upstream. Signed-off-by: Oliver Neukum <oliver@neukum.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30USB: fix memleak in usbfsOliver Neukum
commit d794a02111cd3393da69bc7d6dd2b6074bd037cc upstream. This patch fixes a memory leak in devio.c::processcompl If writing to user space fails the packet must be discarded, as it already has been removed from the queue of completed packets. Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30USB: EHCI: report actual_length for iso transfersAlan Stern
commit ec6d67e39f5638c792eb7490bf32586ccb9d8005 upstream. This patch (as1259b) makes ehci-hcd return the total number of bytes transferred in urb->actual_length for Isochronous transfers. Until now, the actual_length value was unaccountably left at 0. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30SCSI: zalon: fix oops on attach failureJames Bottomley
commit d3a263a8168f78874254ea9da9595cfb0f3e96d7 upstream. I recently discovered on my zalon that if the attachment fails because of a bus misconfiguration (I scrapped my HVD array, so the card is now unterminated) then the system oopses. The reason is that if ncr_attach() returns NULL (signalling failure) that NULL is passed by the goto failed straight into ncr_detach() which oopses. The fix is just to return -ENODEV in this case. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-30gigaset: accept connection establishment messages in any orderTilman Schmidt
commit bceb0f126f25184eaec3f3c8f00c92b0d899e5de upstream. ISDN connection setup failed if the "connection active" and "B channel up" messages from the device arrived in a different order than expected. Modify the state machine to accept them in any order. Impact: bugfix Signed-off-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-24fbmon: work around compiler bug in gcc-4.2.4Linus Torvalds
commit 3730793d457fed79a6d49bae72996d458c8e4f2d upstream. There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent he loop counter is of type 'unsigned char' and it should count to 128. The compiler will incorrectly decide that a trivial loop like this: unsigned char i, ... for (i = 0; i < 128; i++) { .. is endless, and will compile it to a single instruction that just branches to itself. This was triggered by the addition of '-fno-strict-overflow', and we could play games with compiler versions and go back to '-fwrapv' instead, but the trivial way to avoid it is to just make the loop induction variable be an 'int' instead. Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure for digging through assembler differences and finding it. Reported-and-tested-by: Krzysztof Oledzki <olel@ans.pl> Found-by: Troy Moure <twmoure@szypr.net> Gcc-bug-acked-by: Ian Lance Taylor <iant@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-19tulip: Fix for MTU problems with 802.1q tagged framesTomasz Lemiech
commit 1f8ae0a21d83f43006d7f6d2862e921dbf2eeddd upstream. The original patch was submitted last year but wasn't discussed or applied because of missing maintainer's CCs. I only fixed some formatting errors, but as I saw tulip is very badly formatted and needs further work. Original description: This patch fixes MTU problem, which occurs when using 802.1q VLANs. We should allow receiving frames of up to 1518 bytes in length, instead of 1514. Based on patch written by Ben McKeegan for 2.4.x kernels. It is archived at http://www.candelatech.com/~greear/vlan/howto.html#tulip I've adjusted a few things to make it apply on 2.6.x kernels. Tested on D-Link DFE-570TX quad-fastethernet card. Signed-off-by: Tomasz Lemiech <szpajder@staszic.waw.pl> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Ben McKeegan <ben@netservers.co.uk> Acked-by: Grant Grundler <grundler@parisc-linux.org> Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-19floppy: fix lock imbalanceJiri Slaby
commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream. A crappy macro prevents us unlocking on a fail path. Expand the macro and unlock appropriatelly. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-19Fix iommu address space allocationDavid Woodhouse
commit a15a519ed6e5e644f5a33c213c00b0c1d3cfe683 upstream. This fixes kernel.org bug #13584. The IOVA code attempted to optimise the insertion of new ranges into the rbtree, with the unfortunate result that some ranges just didn't get inserted into the tree at all. Then those ranges would be handed out more than once, and things kind of go downhill from there. Introduced after 2.6.25 by ddf02886cbe665d67ca750750196ea5bf524b10b ("PCI: iova RB tree setup tweak"). Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: mark gross <mgross@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-19Revert "dm: sysfs skip output when device is being destroyed"Greg Kroah-Hartman
This reverts commit 9fad9f263a7065be94bf77519346d0d854ff3b92. It is really commit 4d89b7b4e4726893453d0fb4ddbb5b3e16353994 that is being reverted here, it's a patch that should not have been applied to the .27 tree. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02dm: sysfs skip output when device is being destroyedMilan Broz
commit 4d89b7b4e4726893453d0fb4ddbb5b3e16353994 upstream. Do not process sysfs attributes when device is being destroyed. Otherwise code can cause BUG_ON(test_bit(DMF_FREEING, &md->flags)); in dm_put() call. Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02dm mpath: validate table argument countMikulas Patocka
commit 0e0497c0c017664994819f4602dc07fd95896c52 upstream. The parser reads the argument count as a number but doesn't check that sufficient arguments are supplied. This command triggers the bug: dmsetup create mpath --table "0 `blockdev --getsize /dev/mapper/cr0` multipath 0 0 2 1 round-robin 1000 0 1 1 /dev/mapper/cr0 round-robin 0 1 1 /dev/mapper/cr1 1000" kernel BUG at drivers/md/dm-mpath.c:530! Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02dm mpath: validate hw_handler argument countMikulas Patocka
commit e094f4f15f5169526c7200b9bde44b900548a81e upstream. Fix arg count parsing error in hw handlers. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02pcmcia/cm4000: fix lock imbalanceJiri Slaby
commit 69ae59d7d8df14413cf0a97b3e372d7dc8352563 upstream. Don't return from switch/case, break instead, so that we unlock BKL. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02PCI PM: Follow PCI_PM_CTRL_NO_SOFT_RESET during transitions from D3Rafael J. Wysocki
commit f62795f1e892ca9269849fa83de97621da7e02c0 upstream. According to the PCI PM specification (PCI Bus Power Management Interface Specification, Rev. 1.2, Section 5.4.1) we are supposed to reinitialize devices that have PCI_PM_CTRL_NO_SOFT_RESET clear during all transitions from PCI_D3hot to PCI_D0, but we only do it if the device's current_state field is equal to PCI_UNKNOWN. This may lead to problems if a device with PCI_PM_CTRL_NO_SOFT_RESET unset is put into PCI_D3hot at run time by its driver and pci_set_power_state() is used to put it back into PCI_D0, because in that case the device will remain uninitialized after pci_set_power_state() has returned. Prevent that from happening by modifying pci_raw_set_power_state() to reinitialize devices with PCI_PM_CTRL_NO_SOFT_RESET unset during all transitions from D3 to D0. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02PCI PM: Fix handling of devices without PM support by pci_target_state()Rafael J. Wysocki
commit d2abdf62882d982c58e7a6b09ecdcfcc28075e2e upstream. If a PCI device is not power-manageable either by the platform, or with the help of the native PCI PM interface, pci_target_state() will return either PCI_D3hot, or PCI_POWER_ERROR for it, depending on whether or not the device is configured to wake up the system. Alas, none of these return values is correct, because each of them causes pci_prepare_to_sleep() to return error code, although it should complete successfully in such a case. Fix this problem by making pci_target_state() always return PCI_D0 for devices that cannot be power managed. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02parport_pc: set properly the dma_mask for parport_pc deviceFUJITA Tomonori
commit dfa7c4d869b7d3d37b70f1de856f2901b6ebfcf0 upstream. parport_pc_probe_port() creates the own 'parport_pc' device if the device argument is NULL. Then parport_pc_probe_port() doesn't initialize the dma_mask and coherent_dma_mask of the device and calls dma_alloc_coherent with it. dma_alloc_coherent fails because dma_alloc_coherent() doesn't accept the uninitialized dma_mask: http://lkml.org/lkml/2009/6/16/150 Long ago, X86_32 and X86_64 had the own dma_alloc_coherent implementations; X86_32 accepted a device having dma_mask that is not initialized however X86_64 didn't. When we merged them, we chose to prohibit a device having dma_mask that is not initialized. I think that it's good to require drivers to set up dma_mask (and coherent_dma_mask) properly if the drivers want DMA. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Reported-by: Malcom Blaney <malcolm.blaney@maptek.com.au> Tested-by: Malcom Blaney <malcolm.blaney@maptek.com.au> Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02parport_pc: after superio probing restore original register valuesJens Rottmann
commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50 upstream. CONFIG_PARPORT_PC_SUPERIO probes for various superio chips by writing byte sequences to a set of different potential I/O ranges. But the probed ranges are not exclusive to parallel ports. Some of our boards just happen to have a watchdog in one of them. Took us almost a week to figure out why some distros reboot without warning after running flawlessly for 3 hours. For exactly 170 = 0xAA minutes, that is ... Fixed by restoring original values after probing. Also fixed too small request_region() in detect_and_report_it87(). Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de> Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02md/raid5: add missing call to schedule() after prepare_to_wait()Dan Williams
commit 7a3ab908948b6296ee7e81d42f7c176361c51975 upstream. In the unlikely event that reshape progresses past the current request while it is waiting for a stripe we need to schedule() before retrying for 2 reasons: 1/ Prevent list corruption from duplicated list_add() calls without intervening list_del(). 2/ Give the reshape code a chance to make some progress to resolve the conflict. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02IB/mlx4: Add strong ordering to local inval and fast reg work requestsJack Morgenstein
commit 2ac6bf4ddc87c3b6b609f8fa82f6ebbffeac12f4 upstream. The ConnectX Programmer's Reference Manual states that the "SO" bit must be set when posting Fast Register and Local Invalidate send work requests. When this bit is set, the work request will be executed only after all previous work requests on the send queue have been executed. (If the bit is not set, Fast Register and Local Invalidate WQEs may begin execution too early, which violates the defined semantics for these operations) This fixes the issue with NFS/RDMA reported in <http://lists.openfabrics.org/pipermail/general/2009-April/059253.html> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02floppy: request and release only the ports we actually usePhilippe De Muyter
commit 5a74db06cc8d36a325913aa4968ae169f997a466 upstream. The floppy driver requests an I/O port it doesn't need, and sometimes this causes a conflict with a motherboard device reported by PNPBIOS. This patch makes the floppy driver request and release only the ports it actually uses. It also factors out the request/release stuff and the io-ports list so they're all in one place now. The current floppy driver uses only these ports: 0x3f2 (FD_DOR) 0x3f4 (FD_STATUS) 0x3f5 (FD_DATA) 0x3f7 (FD_DCR/FD_DIR) but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port 0x3f3. Some BIOSes report 0x3f3 as a motherboard resource. The PNP system driver reserves that, which causes a conflict when the floppy driver requests 0x3f2-0x3f5 later. Philippe reported that this conflict broke the floppy driver between 2.6.11 and 2.6.22. His PNPBIOS reports these devices: $ cat 00:07/id 00:07/resources # motherboard device PNP0c02 state = active io 0x80-0x80 io 0x10-0x1f io 0x22-0x3f io 0x44-0x5f io 0x90-0x9f io 0xa2-0xbf io 0x3f0-0x3f1 io 0x3f3-0x3f3 $ cat 00:03/id 00:03/resources # floppy device PNP0700 state = active io 0x3f4-0x3f5 io 0x3f2-0x3f2 Reference: http://lkml.org/lkml/2009/1/31/162 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Philippe De Muyter <phdm@macqel.be> Reported-by: Philippe De Muyter <phdm@macqel.be> Tested-by: Philippe De Muyter <phdm@macqel.be> Cc: Adam M Belay <abelay@mit.edu> Cc: Robert Hancock <hancockrwd@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02floppy: provide a PNP device table in the module.Scott James Remnant
commit 83f9ef463bcb4ba7b4fee1d6212fac7d277010d3 upstream. The missing device table means that the floppy module is not auto-loaded, even when the appropriate PNP device (0700) is found. We don't actually use the table in the module, since the device doesn't have a struct pnp_driver, but it's sufficient to cause an alias in the module that udev/modprobe will use. Signed-off-by: Scott James Remnant <scott@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Philippe De Muyter <phdm@macqel.be> Acked-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02ISDN: Fix DMA alloc for hfcpciKarsten Keil
commit 8a745b9d91962991ce87a649a4dc3af3206c2c8b upstream. Replace wrong code with correct DMA API functions. Signed-off-by: Karsten Keil <keil@b1-systems.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02r8169: fix crash when large packets are receivedEric Dumazet
commit fdd7b4c3302c93f6833e338903ea77245eb510b4 upstream. Michael Tokarev reported receiving a large packet could crash a machine with RTL8169 NIC. ( original thread at http://lkml.org/lkml/2009/6/8/192 ) Problem is this driver tells that NIC frames up to 16383 bytes can be received but provides skb to rx ring allocated with smaller sizes (1536 bytes in case standard 1500 bytes MTU is used) When a frame larger than what was allocated by driver is received, dma transfert can occurs past the end of buffer and corrupt kernel memory. Fix is to tell to NIC what is the maximum size a frame can be. This bug is very old, (before git introduction, linux-2.6.10), and should be backported to stable versions. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02PCI: disable ASPM on VIA root-port-under-bridge configurationsShaohua Li
commit 8e822df700694ca6850d1e0c122fd7004b2778d8 upstream. VIA has a strange chipset, it has root port under a bridge. Disable ASPM for such strange chipset. Tested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02firmware_map: fix hang with x86/32bitYinghai Lu
commit 3b0fde0fac19c180317eb0601b3504083f4b9bf5 upstream. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484 Peer reported: | The bug is introduced from kernel 2.6.27, if E820 table reserve the memory | above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000 | (reserved)), system will report Int 6 error and hang up. The bug is caused by | the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit | variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6 | error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this | bug. |====== |static int firmware_map_add_entry(resource_size_t start, resource_size_t end, | const char *type, | struct firmware_map_entry *entry) and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set. it turns out we need to pass u64 instead of resource_size_t for that. [akpm@linux-foundation.org: add comment] Reported-and-tested-by: Peer Chen <pchen@nvidia.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Acked-by: H. Peter Anvin <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02char: mxser, fix ISA board lookupPeter Botha
commit 96050dfb25966612008dcea7d342e91fa01e993c upstream. There's a bug in the mxser kernel module that still appears in the 2.6.29.4 kernel. mxser_get_ISA_conf takes a ioaddress as its first argument, by passing the not of the ioaddr, you're effectively passing 0 which means it won't be able to talk to an ISA card. I have tested this, and removing the ! fixes the problem. Cc: "Peter Botha" <peterb@goldcircle.co.za> Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02char: moxa, prevent opening unavailable portsDirk Eibach
commit a90b037583d5f1ae3e54e9c687c79df82d1d34a4 upstream. In moxa.c there are 32 minor numbers reserved for each device. The number of ports actually available per device is stored in moxa_board_conf->numPorts. This number is not considered in moxa_open(). Opening a port that is not available results in a kernel oops. This patch adds a test to moxa_open() that prevents opening unavailable ports. [akpm@linux-foundation.org: avoid multiple returns] Signed-off-by: Dirk Eibach <eibach@gdsys.de> Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02bonding: fix multiple module load problemStephen Hemminger
[ Upstream commit 130aa61a77b8518f1ea618e1b7d214d60b405f10 ] Some users still load bond module multiple times to create bonding devices. This accidentally was broken by a later patch about the time sysfs was fixed. According to Jay, it was broken by: commit b8a9787eddb0e4665f31dd1d64584732b2b5d051 Author: Jay Vosburgh <fubar@us.ibm.com> Date: Fri Jun 13 18:12:04 2008 -0700 bonding: Allow setting max_bonds to zero Note: sysfs and procfs still produce WARN() messages when this is done so the sysfs method is the recommended API. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02atmel_lcdfb: correct fifo size for some productsNicolas Ferre
commit 53b7479bbdaedcc7846c66fd608fe66f1b5aa35b upstream. Remove wrong fifo size definition for some AT91 products. Due to a misunderstanding of some AT91 datasheets, a fifo size of 2048 (words) has been introduced by mistake. In fact, all products (AT91/AT32) are sharing the same fifo size of 512 words. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Andrew Victor <avictor.za@gmail.com> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-02parport: netmos 9845 & 9855 1P4S fixesPhilippe De Muyter
commit 50db9d8e4ca17974595e3848cb65f9371a304de4 upstream. netmos serial/parallel adapters come in different flavour differing only by the number of parallel and serial ports, which are encoded in the subdevice ID. Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S, and works only by side-effect for the first parallel port of a 2P2S, as this first parallel port is found by reading the second addr entry of (struct parport_pc_pci) cards[netmos_9855], which is not initialized, and hence has value 0, which happens to be the BAR of the first parallel port. netmos_9xx5_combo entry in (struct parport_pc_pci) cards[], which is used for a 9845 1P4S must also be fixed for the parallel port support when there are 4 serial ports because this entry currently gives 2 as BAR index for the parallel port. Actually, in this case, BAR 2 is the 3rd serial port while the parallel port is at BAR 4. I fixed 9845 1P4S and 9855 1P4S support, while preserving 9855 2P2S support, - by creating a netmos_9855_2p entry and using it for 9855 boards with 2 parallel ports : 9855 2P2S and 9855 2P0S boards, - and by allowing netmos_parallel_init to change not only the number of parallel ports (0 or 1), but making it also change the BAR index of the parallel port when the serial ports are before the parallel port. PS: the netmos_9855_2p entry in (struct pciserial_board) pci_parport_serial_boards[] is needed because netmos_parallel_init has no clean way to replace FL_BASE2 by FL_BASE4 in the description of the serial ports in function of the number of parallel ports on the card. Tested with 9845 1P4S, 9855 1P4S and 9855 2P2S boards. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Tested-by: Christian Pellegrin <chripell@fsfe.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-11V4L/DVB (10943): cx88: Prevent general protection fault on rmmodJean Delvare
commit 569b7ec73abf576f9a9e4070d213aadf2cce73cb upstream. V4L/DVB (10943): cx88: Prevent general protection fault on rmmod When unloading the cx8800 driver I sometimes get a general protection fault. Analysis revealed a race in cx88_ir_stop(). It can be solved by using a delayed work instead of a timer for infrared input polling. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-11USB: isp1760: urb_dequeue doesn't always find the urbsWarren Free
commit 0afb20e00b5053170c85298fed842b32d20b4ea9 upstream. The option driver (and presumably others) allocates several URBs when it opens and tries to free them when it closes. The isp1760_urb_dequeue function gets called, but the packet being dequeued is not necessarily at the front of one of the 32 queues. If not, the isp1760_urb_done function doesn't get called for the URB and the process trying to free it hangs forever on a wait_queue. This patch does two things. If the URB being dequeued has others queued behind it, it re-queues them. And it searches the queues looking for the URB being dequeued rather than just looking at the one at the front of the queue. [bigeasy@linutronix] whitespace fixes, reformating Signed-off-by: Warren Free <wfree@ipmn.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-11Avoid ICE in get_random_int() with gcc-3.4.5Linus Torvalds
commit 26a9a418237c0b06528941bca693c49c8d97edbe upstream. Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an internal compiler error (ICE): drivers/char/random.c: In function `get_random_int': drivers/char/random.c:1672: error: unrecognizable insn: (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91]) (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88]) (subreg:DI (reg:SI 6 bp) 0)) (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil) (nil)) drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083 and after some debugging it turns out that it's due to the code trying to figure out the rough value of the current stack pointer by taking an address of an uninitialized variable and casting that to an integer. This is clearly a compiler bug, but it's not worth fighting - while the current stack kernel pointer might be somewhat hard to predict in user space, it's also not generally going to change for a lot of the call chains for a particular process. So just drop it, and mumble some incoherent curses at the compiler. Tested-by: Martin Knoblauch <spamtrap@knobisoft.de> Cc: Matt Mackall <mpm@selenic.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-13 13:23:53 +0000