summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2008-09-08sata_mv: don't issue two DMA commands concurrentlyTejun Heo
commit 4bdee6c5103696a2729d3db2f235d202191788e4 upstream sata_mv allowed issuing two DMA commands concurrently which the hardware allows. Unfortunately, libata core layer isn't ready for this yet and spews ugly warning message and malfunctions on this. Don't allow concurrent DMA commands for now. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: Martin Michlmayr <tbm@cyrius.com> Cc: Mark Lord <liml@rtr.ca> Cc: Artem Bokhan <aptem@ngs.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08r8169: balance pci_map / pci_unmap pairFrancois Romieu
commit a866bbf6aacf95f849810079442a20be118ce905 upstream The leak hurts with swiotlb and jumbo frames. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468. Heavily hinted by Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Alistair John Strachan <alistair@devzero.co.uk> Tested-by: Timothy J Fontaine <tjfontaine@atxconsulting.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08tg3: Fix firmware event timeoutsMatt Carlson
patch 4ba526ced990f4d61ee8d65fe8a6f0745e8e455c upstream The git commit 7c5026aa9b81dd45df8d3f4e0be73e485976a8b6 ("tg3: Add link state reporting to UMP firmware") introduced code that waits for previous firmware events to be serviced before attempting to submit a new event. Unfortunately that patch contained a bug that cause the driver to wait 2.5 seconds, rather than 2.5 milliseconds as intended. This patch fixes that bug. This bug revealed that not all firmware versions service driver events though. Since we do not know which versions of the firmware do and don't service these events, the driver needs some way to minimize the effects of the delay. This patch solves the problem by recording a jiffies timestamp when it submits an event to the hardware. If the jiffies counter shows that 2.5 milliseconds have already passed, a wait is not needed and the driver can proceed to submit a new event. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-088250: improve workaround for UARTs that don't re-assert THRE correctlyWill Newton
commit 363f66fe06c75270b669c88e321e6b354ba0201e upstream Recent changes to tighten the check for UARTs that don't correctly re-assert THRE (01c194d9278efc15d4785ff205643e9c0bdcef53: "serial 8250: tighten test for using backup timer") caused problems when such a UART was opened for the second time - the bug could only successfully be detected at first initialization. For users of this version of this particular UART IP it is fatal. This patch stores the information about the bug in the bugs field of the port structure when the port is first started up so subsequent opens can check this bit even if the test for the bug fails. David Brownell: "My own exposure to this is that the UART on DaVinci hardware, which TI allegedly derived from its original 16550 logic, has periodically gone from working to unusable with the mainline 8250.c ... and back and forth a bunch. Currently it's "unusable", a regression from some previous versions. With this patch from Will, it's usable." Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Alex Williamson <alex.williamson@hp.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: David Brownell <david-b@pacbell.net> 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>
2008-09-08rtc_time_to_tm: fix signed/unsigned arithmeticJan Altenberg
commit 73442daf2ea85e2a779396b76b1a39b10188ecb5 upstream commit 945185a69daa457c4c5e46e47f4afad7dcea734f ("rtc: rtc_time_to_tm: use unsigned arithmetic") changed the some types in rtc_time_to_tm() to unsigned: void rtc_time_to_tm(unsigned long time, struct rtc_time *tm) { - register int days, month, year; + unsigned int days, month, year; This doesn't work for all cases, because days is checked for < 0 later on: if (days < 0) { year -= 1; days += 365 + LEAP_YEAR(year); } I think the correct fix would be to keep days signed and do an appropriate cast later on. Signed-off-by: Jan Altenberg <jan.altenberg@linutronix.de> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Cc: Dmitri Vorobiev <dmitri.vorobiev@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>
2008-09-08drivers/char/random.c: fix a race which can lead to a bogus BUG()Andrew Morton
commit 8b76f46a2db29407fed66cf4aca19d61b3dcb3e1 upstream Fix a bug reported by and diagnosed by Aaron Straus. This is a regression intruduced into 2.6.26 by commit adc782dae6c4c0f6fb679a48a544cfbcd79ae3dc Author: Matt Mackall <mpm@selenic.com> Date: Tue Apr 29 01:03:07 2008 -0700 random: simplify and rename credit_entropy_store credit_entropy_bits() does: spin_lock_irqsave(&r->lock, flags); ... if (r->entropy_count > r->poolinfo->POOLBITS) r->entropy_count = r->poolinfo->POOLBITS; so there is a time window in which this BUG_ON(): static size_t account(struct entropy_store *r, size_t nbytes, int min, int reserved) { unsigned long flags; BUG_ON(r->entropy_count > r->poolinfo->POOLBITS); /* Hold lock while accounting */ spin_lock_irqsave(&r->lock, flags); can trigger. We could fix this by moving the assertion inside the lock, but it seems safer and saner to revert to the old behaviour wherein entropy_store.entropy_count at no time exceeds entropy_store.poolinfo->POOLBITS. Reported-by: Aaron Straus <aaron@merfinllc.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Theodore Ts'o <tytso@mit.edu> 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>
2008-09-08atl1: disable TSO by defaultJay Cliburn
commit 82c26a9d117f0178b8c1b33429014b6d99c470f6 upstream The atl1 driver is causing stalled connections and file corruption whenever TSO is enabled. Two examples are here: http://lkml.org/lkml/2008/7/15/325 http://lkml.org/lkml/2008/8/18/543 Disable TSO by default until we can determine the source of the problem. Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08forcedeth: fix checksum flagAyaz Abdulla
commit edcfe5f7e307846e578fb88d69fa27051fded0ab upstream Fix the checksum feature advertised in device flags. The hardware support TCP/UDP over IPv4 and TCP/UDP over IPv6 (without IPv6 extension headers). However, the kernel feature flags do not distinguish IPv6 with/without extension headers. Therefore, the driver needs to use NETIF_F_IP_CSUM instead of NETIF_F_HW_CSUM since the latter includes all IPv6 packets. A future patch can be created to check for extension headers and perform software checksum calculation. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Jeff Garzik <jgarzik@pobox.com> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08S390 dasd: fix data size for PSF/PRSSD commandStefan Weinhuber
commit 49fd38bdaa96f093fcad3176a781a4d0de8f8602 upstream The Perform Subsystem Function/Prepare for Read Subsystem Data command requires 12 bytes of parameter data, but the respective data structure dasd_psf_prssd_data has a length of 16 bytes. Current storage servers ignore the obsolete bytes, but older models fail to execute the command and report an incorrect length error. This causes the device initilization for these devices to fail. To fix this problem we need to correct the dasd_psf_prssd_data structure and shorten it to the correct length. Reported-by: Ivan Warren <ivan@vmfacility.fr> Reviewed-by: Ivan Warren <ivan@vmfacility.fr> Tested-by: Ivan Warren <ivan@vmfacility.fr> Signed-off-by: Stefan Weinhuber <wein@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08USB: cdc-acm: don't unlock acm->mutex on error pathAlexey Dobriyan
commit 74573ee7096a4ffc2f098108d21c85801b9c7434 upstream On Wed, Jul 23, 2008 at 03:52:36PM +0300, Andrei Popa wrote: > I installed gnokii-0.6.22-r2 and gave the command "gnokii --identify" > and the kernel oopsed: > > BUG: unable to handle kernel NULL pointer dereference at 00000458 > IP: [<c0444b52>] mutex_unlock+0x0/0xb > [<c03830ae>] acm_tty_open+0x4c/0x214 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Tested-by: Andrei Popa <andrei.popa@i-neo.ro> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08fbdefio: add set_page_dirty handler to deferred IO FBIan Campbell
commit d847471d063663b9f36927d265c66a270c0cfaab upstream Fixes kernel BUG at lib/radix-tree.c:473. Previously the handler was incidentally provided by tmpfs but this was removed with: commit 14fcc23fdc78e9d32372553ccf21758a9bd56fa1 Author: Hugh Dickins <hugh@veritas.com> Date: Mon Jul 28 15:46:19 2008 -0700 tmpfs: fix kernel BUG in shmem_delete_inode relying on this behaviour was incorrect in any case and the BUG also appeared when the device node was on an ext3 filesystem. v2: override a_ops at open() time rather than mmap() time to minimise races per AKPM's concerns. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Hugh Dickins <hugh@veritas.com> Cc: Johannes Weiner <hannes@saeurebad.de> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Kel Modderman <kel@otaku42.de> Cc: Markus Armbruster <armbru@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> 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>
2008-09-08eeepc-laptop: fix use after freeMatthew Garrett
commit f14413184b1de4dcbd5ec3e7c129c3ce2079f543 upstream Date: Wed, 20 Aug 2008 14:08:57 -0700 Subject: eeepc-laptop: fix use after free eeepc-laptop uses the hwmon struct after unregistering the device, causing an oops on module unload. Flip the ordering to fix. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Karol Kozimor <sziwan@users.sourceforge.net> 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>
2008-09-08PCI: fix reference leak in pci_get_dev_by_id()Greg Kroah-Hartman
commit ebca4f1bce1eb7b91a63c515db66316db9391221 upstream Alex Chiang and Matthew Wilcox pointed out that pci_get_dev_by_id() does not properly decrement the reference on the from pointer if it is present, like the documentation for the function states it will. It fixes a pretty bad leak in the hotplug core (we were leaking an entire struct pci_dev for each function of each offlined card, the first time around; subsequent onlines/offlines were ok). Cc: Matthew Wilcox <matthew@wil.cx> Tested-by: Alex Chiang <achiang@hp.com> Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-08-20crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()Suresh Siddha
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore() [ Upstream commit: e49140120c88eb99db1a9172d9ac224c0f2bbdd2 ] Wolfgang Walter reported this oops on his via C3 using padlock for AES-encryption: ################################################################## BUG: unable to handle kernel NULL pointer dereference at 000001f0 IP: [<c01028c5>] __switch_to+0x30/0x117 *pde = 00000000 Oops: 0002 [#1] PREEMPT Modules linked in: Pid: 2071, comm: sleep Not tainted (2.6.26 #11) EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0 EIP is at __switch_to+0x30/0x117 EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300 ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000) Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046 c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000 c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0 Call Trace: [<c03b5b43>] ? schedule+0x285/0x2ff [<c0131856>] ? pm_qos_requirement+0x3c/0x53 [<c0239f54>] ? acpi_processor_idle+0x0/0x434 [<c01025fe>] ? cpu_idle+0x73/0x7f [<c03a4dcd>] ? rest_init+0x61/0x63 ======================= Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end() around the padlock instructions fix the oops. Suresh wrote: These padlock instructions though don't use/touch SSE registers, but it behaves similar to other SSE instructions. For example, it might cause DNA faults when cr0.ts is set. While this is a spurious DNA trap, it might cause oops with the recent fpu code changes. This is the code sequence that is probably causing this problem: a) new app is getting exec'd and it is somewhere in between start_thread() and flush_old_exec() in the load_xyz_binary() b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is cleared. c) Now we get an interrupt/softirq which starts using these encrypt/decrypt routines in the network stack. This generates a math fault (as cr0.ts is '1') which sets TS_USEDFPU and restores the math that is in the task's xstate. d) Return to exec code path, which does start_thread() which does free_thread_xstate() and sets xstate pointer to NULL while the TS_USEDFPU is still set. e) At the next context switch from the new exec'd task to another task, we have a scenarios where TS_USEDFPU is set but xstate pointer is null. This can cause an oops during unlazy_fpu() in __switch_to() Now: 1) This should happen with or with out pre-emption. Viro also encountered similar problem with out CONFIG_PREEMPT. 2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because kernel_fpu_begin() will manually do a clts() and won't run in to the situation of setting TS_USEDFPU in step "c" above. 3) This was working before the fpu changes, because its a spurious math fault which doesn't corrupt any fpu/sse registers and the task's math state was always in an allocated state. With out the recent lazy fpu allocation changes, while we don't see oops, there is a possible race still present in older kernels(for example, while kernel is using kernel_fpu_begin() in some optimized clear/copy page and an interrupt/softirq happens which uses these padlock instructions generating DNA fault). This is the failing scenario that existed even before the lazy fpu allocation changes: 0. CPU's TS flag is set 1. kernel using FPU in some optimized copy routine and while doing kernel_fpu_begin() takes an interrupt just before doing clts() 2. Takes an interrupt and ipsec uses padlock instruction. And we take a DNA fault as TS flag is still set. 3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts 4. We complete the padlock routine 5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes the optimized copy routine and does kernel_fpu_end(). At this point, we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll set and not cleared. 6. Now kernel resumes its user operation. And at the next context switch, kernel sees it has do a FP save as TS_USEDFPU is still set and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu() will take a DNA fault, as cr0.ts is '1' and now, because we are in __switch_to(), math_state_restore() will get confused and will restore the next task's FP state and will save it in prev tasks's FP state. Remember, in __switch_to() we are already on the stack of the next task but take a DNA fault for the prev task. This causes the fpu leakage. Fix the padlock instruction usage by calling them inside the context of new routines irq_ts_save/restore(), which clear/restore cr0.ts manually in the interrupt context. This will not generate spurious DNA in the context of the interrupt which will fix the oops encountered and the possible FPU leakage issue. Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20PCI: Limit VPD length for Broadcom 5708SDean Hildebrand
commit 35405f256de924be56ea5edaca4cdc627f1bb0f8 upstream BCM5706S wont work correctly unless VPD length truncated to 128 Signed-off-by: Dean Hildebrand <dhildeb@us.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20usb-storage: automatically recognize bad residuesAlan Stern
commit 59f4ff2ecff4cef36378928cec891785b402e80c upstream This patch (as1119b) will help to reduce the clutter of usb-storage's unusual_devs file by automatically detecting some devices that need the IGNORE_RESIDUE flag. The idea is that devices should never return a non-zero residue for an INQUIRY or a READ CAPACITY command unless they failed to transfer all the requested data. So if one of these commands transfers a standard amount of data but there is a positive residue, we know that the residue is bogus and we can set the flag. This fixes the problems reported in Bugzilla #11125. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Matthew Frost <artusemrys@sbcglobal.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20usb-storage: revert DMA-alignment change for Wireless USBAlan Stern
commit f756cbd458ab71c996a069cb3928fb1e2d7cd9cc upstream. This patch (as1110) reverts an earlier patch meant to help with Wireless USB host controllers. These controllers can have bulk maxpacket values larger than 512, which puts unusual constraints on the sizes of scatter-gather list elements. However it turns out that the block layer does not provide the support we need to enforce these constraints; merely changing the DMA alignment mask doesn't help. Hence there's no reason to keep the original patch. The Wireless USB problem will have to be solved a different way. In addition, there is a reason to get rid of the earlier patch. By dereferencing a pointer stored in the ep_in array of struct usb_device, the current code risks an invalid memory access when it runs concurrently with device removal. The members of that array are cleared before the driver's disconnect method is called, so it should not try to use them. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20qla2xxx: Set an rport's dev_loss_tmo value in a consistent manner.Andrew Vasquez
[ Upstream commit 85821c906cf3563a00a3d98fa380a2581a7a5ff1 ] As there's no point in adding a fixed-fudge value (originally 5 seconds), honor the user settings only. We also remove the driver's dead-callback get_rport_dev_loss_tmo function (qla2x00_get_rport_loss_tmo()). Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20qla2xxx: Add dev_loss_tmo_callbk/terminate_rport_io callback support.Seokmann Ju
[ Upstream commit 5f3a9a207f1fccde476dd31b4c63ead2967d934f ] Signed-off-by: Seokmann Ju <seokmann.ju@qlogic.com> Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20rtl8187: Fix lockups due to concurrent access to config routineLarry Finger
With the rtl8187 driver, the config routine is not protected against access before a previous call has completed. When this happens, the TX loopback that is needed to change channels may cause the chip to be locked with a reset needed to restore communications. This patch entered mainline as commit 7dcdd073bf78bb6958bbc12a1a47754a0f3c4721. The problem was found by Herton Ronaldo Krzesinski <herton@mandriva.com.br>, who also suggested this type of fix. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20cs5520: add enablebits checkingBartlomiej Zolnierkiewicz
upstream commit is 24307ffabd5b39bad443641f54b12ee2ba7a38ac Based on sparse comments in OpenFirmware code (no Cx5510/Cx5520 datasheet here). This fixes 2.6.26 regression reported by TAKADA and caused by addition of warm-plug support. Tested-by: TAKADA Yoshihito <takada@mbf.nifty.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20radeon: misc correctionsDavid Miller
Commit efc491814308f89d5ef6c4fe19ae4552a67d4132 upstream radeon: misc corrections I have a new PCI-E radeon RV380 series card (PCI device ID 5b64) that hangs in my sparc64 boxes when the init scripts set the font. The problem goes away if I disable acceleration. I haven't figured out that bug yet, but along the way I found some corrections to make based upon some auditing. 1) The RB2D_DC_FLUSH_ALL value used by the kernel fb driver and the XORG video driver differ. I've made the kernel match what XORG is using. 2) In radeonfb_engine_reset() we have top-level code structure that roughly looks like: if (family is 300, 350, or V350) do this; else do that; ... if (family is NOT 300, OR family is NOT 350, OR family is NOT V350) do another thing; this last conditional makes no sense, is always true, and obviously was likely meant to be "family is NOT 300, 350, or V350". So I've made the code match the intent. Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.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>
2008-08-20ide: it821x in pass-through mode segfaults in 2.6.26-stableDimitri Gorokhovik
commit 84e0f3f6c1e26588fdcb9f1b0f99d0275229bc99 upstream The driver of ITE8212 in pass-through mode (it8212.noraid=1 on cmndline) attempts to use the field `.dma_host_set' of the struct ide_dma_ops in `ide_config_drive_speed' which is set to NULL by default. So give a value to all fields of the struct ide_dma_ops. Signed-off-by: Dimitri Gorokhovik <dimitri.gorokhovik@free.fr> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20i2c: Let users select algorithm drivers manually againJean Delvare
Already in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8d24f8dcb7ead491704e274883b2c627062f6235 In kernel 2.6.26, the ability to select I2C algorithm drivers manually was removed, as all in-kernel drivers do that automatically. However there were some complaints that it was a problem for out-of-tree I2C bus drivers. In order to address these complaints, let's allow manual selection of these drivers again, but still hide them by default for better general user experience. This closes bug #11140: http://bugzilla.kernel.org/show_bug.cgi?id=11140 Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20i2c: Fix NULL pointer dereference in i2c_new_probed_deviceHans Verkuil
Already in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b25b791b13aaa336b56c4f9bd417ff126363f80b Fix a NULL pointer dereference that happened when calling i2c_new_probed_device on one of the addresses for which we use byte reads instead of quick write for detection purpose (that is: 0x30-0x37 and 0x50-0x5f). Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06Marcus Sundberg
commit 77332894c21165404496c56763d7df6c15c4bb09 upstream The magic write to register 0x82 will often cause PCI config space on my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop) to be filled with ones during driver load, and thus breaking NIC operation until reboot. If it does not happen on first driver load it can easily be reproduced by unloading and loading the driver a few times. The magic write was added long ago by this commit: Author: François Romieu <romieu@fr.zoreil.com> Date: Sat Jan 10 06:00:46 2004 -0500 [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one(): - phy capability settings allows lower or equal capability as suggested in Realtek's changes; - I/O voodoo; - no need to s/mdio_write/RTL8169_WRITE_GMII_REG/; - s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/; - rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication of code (yep, the u16 -> int conversions should work as expected); - variable renames and whitepace changes ignored. As the 8168 wasn't supported by that version this patch simply removes the bogus write from mac versions <= RTL_GIGA_MAC_VER_06. [The change above makes sense for the 8101/8102 too -- Ueimor] Signed-off-by: Marcus Sundberg <marcus@ingate.com> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Karsten Keil <kkeil@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20acer-wmi: Fix wireless and bluetooth on early AMW0 v2 laptopsCarlos Corbacho
commit 5c742b45dd5fbbb6cf74d3378341704f4b23c5e8 upstream In the old acer_acpi, I discovered that on some of the newer AMW0 laptops that supported the WMID methods, they don't work properly for setting the wireless and bluetooth values. So for the AMW0 V2 laptops, we want to use both the 'old' AMW0 and the 'new' WMID methods for setting wireless & bluetooth to guarantee we always enable it. This was fixed in acer_acpi some time ago, but I forgot to port the patch over to acer-wmi when it was merged. (Without this patch, early AMW0 V2 laptops such as the Aspire 5040 won't work with acer-wmi, where-as they did with the old acer_acpi). AK: fix compilation Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20USB: ftdi_sio: Add USB Product Id for ELV HS485Andre Schenk
commit b5894a500127fce1db1309db5f9ca8b77a2ac266 upstream USB product id registration for the ELV HS485 USB adapter (www.elv.de) to their home automation bus system. Applies to 2.6.26. Signed-off-by: Andre Schenk <andre@melior.s.bawue.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20USB: ftdi_sio: add support for Luminance Stellaris Evaluation/Development KitsFrederik Kriewitz
commit a00c3cadc2bf50b3c925acdb3d0e5789b1650498 upstream The Patch adds support for Luminance Stellaris Evaluation/Development Kits (FTDI 2232C based). The PIDs were missing. Successfully tested with a Stellaris LM3S8962 Evaluation kit. Signed-off-by: Frederik Kriewitz <frederik@kriewitz.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20usb-serial: don't release unregistered minorsAlan Stern
commit 0282b7f2a874e72c18fcd5a112ccf67f71ba7f5c upstream This patch (as1121) fixes a bug in the USB serial core. When a device is unregistered, the core will give back its minors -- even if the device hasn't been assigned any! The patch reserves the highest minor value (255) to mean that no minor was assigned. It also removes some dead code and does a small style fixup. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20USB: usb-storage: quirk around v1.11 firmware on Nikon D4Dave Jones
commit b9a097f26e55968cbc52e30a4a2e73d32d7604ce upstream usb-storage: quirk around v1.11 firmware on Nikon D40 https://bugzilla.redhat.com/show_bug.cgi?id=454028 Just as in earlier firmware versions, we need to perform this quirk for the latest version too. Speculatively do the entry for the D80 too, as they seem to have the same firmware problems historically. Signed-off-by: Dave Jones <davej@redhat.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20usb-storage: unusual_devs entries for iRiver T10 and Datafab CF+SM readerAlan Stern
commit 368ee6469c327364ea10082a348f91c1f5ba47f7 upstream This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card reader. Apparently these devices provide reasonable residue values for READ and WRITE operations, but not for others like INQUIRY or READ CAPACITY. This fixes the iRiver T10 problem reported in Bugzilla #11125. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20USB: fix interface unregistration logicAlan Stern
commit 1a21175a615ed346e8043f5e9d60a672266b84b4 upstream This patch (as1122) fixes a bug: When an interface is unregistered, its children (sysfs files and endpoint devices) are unregistered after it instead of before. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20USB: pl2023: Remove USB id (4348:5523) handled by ch341Tollef Fog Heen
commit 8c809681ba0289afd0ed7bbb63679a0568dd441d upstream USB ID 4348:5523 is handled by the ch341 driver. Remove it from the pl2023 driver. Reverts 002e8f2c80c6be76bb312940bc278fc10b2b2487. Signed-off-by: Tollef Fog Heen <tfheen@err.no> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20matrox maven: fix a broken error pathJean Delvare
commit 5ede40f87957c6ededf9284c8339722a97b9dfb6 upstream I broke an error path with d03c21ec0be7787ff6b75dcf56c0e96209ccbfbd, sorry about that. The machine will crash if the i2c_attach_client() or maven_init_client() calls fail, although nobody has yet reported this happening. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz> 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>
2008-08-20radeonfb: fix accel engine hangsDavid Miller
commit 969830b2fedf8336c41d6195f49d250b1e166ff8 upstream Some chips appear to have the 2D engine hang during screen redraw, typically in a sequence of copyarea operations. This appear to be solved by adding a flush of the engine destination pixel cache and waiting for the engine to be idle before issuing the accel operation. The performance impact seems to be fairly small. Here is a trace on an RV370 (PCI device ID 0x5b64), it records the RBBM_STATUS register, then the source x/y, destination x/y, and width/height used for the copy: ---------------------------------------- radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10] radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10] radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10] radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10] radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10] radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10] radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10] radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10] radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10] radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10] radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10] ---------------------------------------- When things are going fine the copies complete before the next ROP is even issued, but all of a sudden the 2D unit becomes active (bit 17 in RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit 14) are set as well. The FIFO begins to backup until it becomes full. What happens next is the radeon_fifo_wait() times out, and we access the chip illegally leading to a bus error which usually wedges the box. None of this makes it to the console screen, of course :-) radeon_fifo_wait() should be modified to reset the accelerator when this timeout happens instead of programming the chip anyways. ---------------------------------------- radeonfb: FIFO Timeout ! ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0) ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601] ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248> ERROR(0): M_SYND(0), E_SYND(0), Privileged ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus" ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000] ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\ ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000] ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000] ERROR(0): E-cache idx[800e40] tag[000000000e049f4c] ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000] Ker:xnel panic - not syncing: Irrecoverable deferred error trap. ---------------------------------------- Another quirk is that these copyarea calls will not happen until the first drivers/char/vt.c:redraw_screen() occurs. This will only happen if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen. This seems to happen because until a redraw_screen() the screen scrolling method used by fbcon is not finalized yet. I've seen this with other fb drivers too. So if all you do is boot straight into X you will never see this bug on the relevant chips. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.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>
2008-08-20ide-cd: fix endianity for the error message in cdrom_read_capacityPetr Tesarik
commit 938bb03d188a1e688fb0bcae49788f540193e80a uptream Aesthetic regards aside, commit e8e7b9eb11c34ee18bde8b7011af41938d1ad667 still leaves a bug in the error message, because it uses the unconverted big-endian value for printk. Fix this by using a local variable in machine byte order. The result is correct, more readable, and also produces slightly shorter code on i386. Signed-off-by: Petr Tesarik <ptesarik@suse.cz> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Jan Kara <jack@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@kernel.org> Acked-by: Borislav Petkov <petkovbb@gmail.com> [bart: __u32 -> u32] Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20vt8623fb: fix kernel oopsOndrej Zajicek
commit 594a8819774b09ee5bf72d23300489459ff1f882 upstream commit 20e061fb750d36ec0ffcb2e44ed7dafa9018223b Author: Ondrej Zajicek <santiago@crfreenet.org> Date: Mon Apr 28 02:15:18 2008 -0700 fbdev: framebuffer_alloc() fixes Correct the dev arg of framebuffer_alloc() in arkfb, s3fb and vt8623fb. causes a null-pointer deref because "info->dev is NULL, info was just kzallocated". Signed-off-by: Ondrej Zajicek <santiago@crfreenet.org> Reported-by: "MadLoisae@gmx.net" <MadLoisae@gmx.net> Tested-by: "MadLoisae@gmx.net" <MadLoisae@gmx.net> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> 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>
2008-08-20SCSI: hptiop: add more PCI device IDsHighPoint Linux Team
commit dd07428b44944b42f699408fe31af47977f1e733 upstream Add PCI device ID for new adapter models. Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20SCSI: scsi_transport_spi: fix oops in revalidateJames Bottomley
commit e8bac9e0647dd04c83fd0bfe7cdfe2f6dfb100d0 upstream The class_device->device conversion is causing an oops in revalidate because it's assuming that the device_for_each_child iterator will only return struct scsi_device children. The conversion made all former class_devices children of the device as well, so this assumption is broken. Fix it. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20SCSI: ses: fix VPD inquiry overrunJames Bottomley
commit 671a99c8eb2f1dde08ac5538d8cd912047c61ddf upstream There are a few kerneloops.org reports like this one: http://www.kerneloops.org/search.php?search=ses_match_to_enclosure That seem to imply we're running off the end of the VPD inquiry data (although at 512 bytes, it should be long enough for just about anything). we should be using correctly sized buffers anyway, so put those in and hope this oops goes away. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Ath5k: kill tasklets on shutdownJiri Slaby
commit 10488f8ad62be3b860bad74e60b4fe6ab87aece3 upstream Don't forget to kill tasklets on stop to not panic if they fire after freeing some structures. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Cc: Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Ath5k: fix memory corruptionJiri Slaby
commit 3a0f2c871849f23c1070965bf94dec3f9c0b479d upstream When signal is noisy, hardware can use all RX buffers and since the last entry in the list is self-linked, it overwrites the entry until we link new buffers. Ensure that we don't free this last one until we are 100% sure that it is not used by the hardware anymore to not cause memory curruption as can be seen below. This is done by checking next buffer in the list. Even after that we know that the hardware refetched the new link and proceeded further (the next buffer is ready) we can finally free the overwritten buffer. We discard it since the status in its descriptor is overwritten (OR-ed by new status) too. ============================================================================= BUG kmalloc-4096: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff810067419060-0xffff810067419667. First byte 0x8 instead of 0x6b INFO: Allocated in dev_alloc_skb+0x18/0x30 age=1118 cpu=1 pid=0 INFO: Freed in skb_release_data+0x85/0xd0 age=1105 cpu=1 pid=3718 INFO: Slab 0xffffe200019d0600 objects=7 used=0 fp=0xffff810067419048 flags=0x40000000000020c3 INFO: Object 0xffff810067419048 @offset=4168 fp=0xffff81006741c120 Bytes b4 0xffff810067419038: 4f 0b 02 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a O.......ZZZZZZZZ Object 0xffff810067419048: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff810067419058: 6b 6b 6b 6b 6b 6b 6b 6b 08 42 30 00 00 0b 6b 80 kkkkkkkk.B0...k. Object 0xffff810067419068: f0 5d 00 4f 62 08 a3 64 00 0c 42 16 52 e4 f0 5a 360].Ob.243d..B.R344360Z Object 0xffff810067419078: 68 81 00 00 7b a5 b4 be 7d 3b 8f 53 cd d5 de 12 h...{245264276};.S315325336. Object 0xffff810067419088: 96 10 0b 89 48 54 23 41 0f 4e 2d b9 37 c3 cb 29 ....HT#A.N-2717303313) Object 0xffff810067419098: d1 e0 de 14 8a 57 2a cc 3b 44 0d 78 7a 19 12 15 321340336..W*314;D.xz... Object 0xffff8100674190a8: a9 ec d4 35 a8 10 ec 8c 40 a7 06 0a 51 a7 48 bb 2513543245250.354.@247..Q247H273 Object 0xffff8100674190b8: 3e cf a1 c7 38 60 63 3f 51 15 c7 20 eb ba 65 30 >ϡ3078`c?Q.307.353272e0 Redzone 0xffff81006741a048: bb bb bb bb bb bb bb bb 273273273273273273273273 Padding 0xffff81006741a088: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Pid: 3297, comm: ath5k_pci Not tainted 2.6.26-rc8-mm1_64 #427 Call Trace: [<ffffffff802a7306>] print_trailer+0xf6/0x150 [<ffffffff802a7485>] check_bytes_and_report+0x125/0x180 [<ffffffff802a75dc>] check_object+0xac/0x260 [<ffffffff802a9308>] __slab_alloc+0x368/0x6d0 [<ffffffff80544f82>] ? wireless_send_event+0x142/0x310 [<ffffffff804b1bd4>] ? __alloc_skb+0x44/0x150 [<ffffffff80544f82>] ? wireless_send_event+0x142/0x310 [<ffffffff802aa853>] __kmalloc_track_caller+0xc3/0xf0 [<ffffffff804b1bfe>] __alloc_skb+0x6e/0x150 [... stack snipped] FIX kmalloc-4096: Restoring 0xffff810067419060-0xffff810067419667=0x6b FIX kmalloc-4096: Marking all objects used Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Cc: Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Input: i8042 - add Acer Aspire 1360 to nomux blacklistJiri Kosina
commit 0376bce7b0659fe1e80d045860087072583ab93f upstream. Acer Aspire 1360 needs to be added to nomux blacklist, otherwise its touchpad misbehaves. Reported-by: Clark Tompsett <clarkt@cnsp.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Input: i8042 - add Gericom Bellagio to nomux blacklistJiri Kosina
commit 5b5b43d0b32ea586036638288c31179f00de5443 upstream Gericom Bellagio needs to be added to nomux blacklist, otherwise its touchpad misbehaves. Reported-by: Roland Kletzing <roland.kletzing@materna.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Input: i8042 - add Intel D845PESV to nopnp listJiri Kosina
commit c3a34f4390396a4bede3f8b7bcc5153f50b974bb upstream This patch introduces i8042_dmi_nopnp_table to make it possible to perform DMI matches for systems that need 'i8042.nopnp' to work correctly, and introduces such an entry for Intel D845PESV -- this system doesn't detect PS2 mouse reliably without this option, as reported by Robert Lewis. [dtor@mail.ru - make it compile if CONFIG_PNP is off - reported by Randy Dunlap] Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06SCSI: ch: fix ch_remove oopsFUJITA Tomonori
commit 3d164fb09bb5cb8a223eddf634fc0d355714fcfe upstream. The following commit causes ch_remove oops: commit 24b42566c3fcbb5a9011d1446783d0f5844ccd45 Author: Greg Kroah-Hartman <gregkh@suse.de> Date: Fri May 16 17:55:12 2008 -0700 SCSI: fix race in device_create There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). It fixes the problem in all of the scsi drivers that need it. Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> The problem is ch_probe stores ch's private data at a wrong place. We need to store it at scsi_device->sdev_gendev but the above patch stores it at device struct that device_create_drvdata returns. So we hit an oops when ch_remove accesses scsi_device->sdev_gendev->driver_data, which is NULL. Actually, there wasn't a race because ch doesn't create sysfs files with device struct that device_create returns. This patch puts back dev_set_drvdata() to set ch's private data properly. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06linear: correct disk numbering error checkNikanth Karthikesan
[ Upstream commit 13864515f7bf6cabd60e63c62e09d311386ae1f1 ] From: "Nikanth Karthikesan" <knikanth@novell.com> Correct disk numbering problem check. Signed-off-by: Nikanth Karthikesan <knikanth@suse.de> Signed-off-by: Neil Brown <neilb@suse.de> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Close race in md_probeNeil Brown
[ Upstream commit f48ed538386cb41559282d989354e8f5d442d71c ] There is a possible race in md_probe. If two threads call md_probe for the same device, then one could exit (having checked that ->gendisk exists) before the other has called kobject_init_and_add, thus returning an incomplete kobj which will cause problems when we try to add children to it. So extend the range of protection of disks_mutex slightly to avoid this possibility. Signed-off-by: Neil Brown <neilb@suse.de> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01ath5k: don't enable MSI, we cannot handle it yetPavel Roskin
commit 256b152b005e319f985f50f2a910a75ba0def74f upstream MSI is a nice thing, but we cannot enable it without changing the interrupt handler. If we do it, we break MSI capable hardware, specifically AR5006 chipset. Signed-off-by: Pavel Roskin <proski@gnu.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-04 06:37:58 +0000