aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2005-06-17Merge 'for-linus' branch of ↵Linus Torvalds
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
2005-06-17[PATCH] PCI: don't override drv->shutdown unconditionallyChristoph Hellwig
There are many drivers that have been setting the generic driver model level shutdown callback, and pci thus must not override it. Without this patch we can have really bad data loss on various raid controllers. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-17When cfq I/O scheduler is selected, get_request() in __make_request() callsKiyoshi Ueda
__cfq_get_queue(). __cfq_get_queue() finds an existing queue (struct cfq_queue) of the current process for the device and returns it. If it's not found, __cfq_get_queue() creates and returns a new one if __cfq_get_queue() is called with __GFP_WAIT flag, or __cfq_get_queue() returns NULL (this means that get_request() fails) if no __GFP_WAIT flag. On the other hand, in __make_request(), get_request() is called without __GFP_WAIT flag at the first time. Thus, the get_request() fails when there is no existing queue, typically when it's called for the first I/O request of the process to the device. Though it will be followed by get_request_wait() for general case, __make_request() will just end the I/O with an error (EWOULDBLOCK) when the request was for read-ahead. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com> Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
2005-06-16Merge 'for-linus' branch of ↵Linus Torvalds
master.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block
2005-06-16[PATCH] fix for kaweth broken by changes in the networking layerOliver Neukum
Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-16[PATCH] ALPS: fix enabling hardware tappingDmitry Torokhov
It looks like logic for enabling hardware tapping in ALPS driver was inverted and we enable it only if it was already enabled by BIOS or firmware. I have a confirmation from one user that the patch below fixes the problem for him and it might be beneficial if we could get it into 2.6.12. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-16[PATCH] sbp2 slab corruption fixAlexandre Oliva
This fixed a problem that showed up in the Fedora development tree a few weeks before the Fedora Core 4 release, initially as slab corruption, later as hard crashes on boot up, when slab debugging was disabled for the release. More details on the history at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158424 The problem is caused by sbp2's use of scsi_host->hostdata[0] to hold a scsi_id, without explicitly requesting space for it. Since hostdata is declared as a zero-sized array, we don't get any such space by default, so it must be explicitly requested. The patch below implements just that. Signed-off-by: Alexandre Oliva <aoliva@redhat.com> Cc: Jody McIntyre <scjody@modernduck.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-16 This patch fixes q->unplug_thresh condition check inTejun Heo
__elv_add_request(). rq.count[READ] + rq.count[WRITE] can increase more than one if another thread has allocated a request after the current request is allocated or in_flight could have changed resulting in larger-than-one change of nrq, thus breaking the threshold mechanism. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Tejun Heo <htejun@gmail.com>
2005-06-16This patch kills elevator_global_init() in elevator.c which doesTejun Heo
nothing. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Tejun Heo <htejun@gmail.com>
2005-06-14[PATCH] macmodes: needs a licenseRandy Dunlap
Module needs a license to prevent kernel tainting. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-14[PATCH] i2o: Fix free of event memory in i2o_block_event()Markus Lidel
Fixed freeing of event memory in i2o_block_event() Signed-off-by: Markus Lidel <Markus.Lidel@shadowconnect.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Typo in fbdev sysfs support, virtual_sizeJon Smirl
It prints out x,x instead of x,y. Signed-off-by: Jon Smirl <jonsmirl@gmail.com> Cc: "Antonino A. Daplas" <adaplas@hotpop.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Fix PCI BAR size interpretation on 64-bit archesOlof Johansson
On 64-bit machines, PCI_BASE_ADDRESS_MEM_MASK and other mask constants passed to pci_size() are 64-bit (for example ~0x0fUL). However, pci_size does comparisons between the u32 arguments and the mask, which will fail even though any result from pci_size is still just 32-bit. Changing the mask argument to u32 seems the obvious thing to do, since all arithmetic in the function is 32-bit and having a larger mask makes no sense. This triggered on a PPC64 system here where an adapter (VGA, as it happened) had a memory region base of 0xfe000000 and a sz of the same, matching the if (max == maxbase ...) test at the bottom of pci_size but failing the mask comparison. Quite a corner case which I guess explains why we haven't seen it until now. Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds
2005-06-13[NET]: Move the netdev list to vger.kernel.org.Ralf Baechle
From: Ralf Baechle <ralf@linux-mips.org> There are archives of the old list at http://oss.sgi.com/archives/netdev Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-13[PATCH] spin longer for ehci port reset completionDavid Brownell
This makes the EHCI driver spin a bit longer before concluding that the port reset failed. "Obviously safe." It allows some devices to enumerate that previously didn't. We've seen a bunch of these problem reports recently, this will make some go away. As reported by Michael Zapf <Michael.Zapf@uni-kassel.de>, some EHCI controllers seem to take forever to finish port resets and produce "port N reset error -110" type errors. Spinning a bit longer helps. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] pwc bug fixAlan Cox
The pwc chainsaw session left some setups not working. There is a sanity check on compression buffers that simply isn't right any more as we never allocate one. This doesn't address the email and other changes. I'll do those tomorrow if I get time, but it is the minimal fix for the code and basic feature set. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] radeonfb: don't blow up VGA console on loadBenjamin Herrenschmidt
The current radeonfb memset's the framebuffer to 0 when loaded. This removes occasional artifacts but has the nasty side effect that if you load radeonfb without framebuffer console, you destroy the VGA text buffer, font, etc... radeon must not touch the framebuffer content when it doesn't "own" it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] M68k: Mark Sun-3 NCR5380 SCSI brokenGeert Uytterhoeven
M68k: Mark Sun-3 NCR5380 SCSI broken until NCR5380_abort() and NCR5380_bus_reset() are replaced with real new-style EH routines (the old EH SCSI constants were removed in 2.6.12-rc3). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] IrDA: IrDA: Fix CONFIG_VIA_FIR typo (double `those')Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-10Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds
2005-06-10[PATCH] remove bogus hack from radeon IRQ handlerDave Airlie
This removes a bogus hack from the radeon IRQ handler. There is a better fix from myself and benh in DRM CVS but I'll wait until 2.6.13-rc so it gets more testing. Signed-off-by: Dave Airlie <airlied@linux.ie>
2005-06-10[PATCH] drm add i945G pci idDave Airlie
Add pci identifier for i945G chipset Signed-off-by: Dave Airlie <airlied@linux.ie>
2005-06-09[PATCH] ppc32: Fix nasty sleep/wakeup problemBenjamin Herrenschmidt
Despite all the care lately in making the powermac sleep/wakeup as robust as possible, there is still a nasty related to the use of cpufreq on PMU based machines. Unfortunately, it affects paulus old powerbook so I have to fix it :) We didn't manage to understand what is precisely going on, it leads to memory corruption and might have to do with RAM not beeing properly refreshed when a cpufreq transition is done right before the sleep. The best workaround (and less intrusive at this point) we could come up with is included in this patch. We basically do _not_ force a switch to high speed on suspend anymore (that is what is causing the problem) on those machines. We still force a speed switch on wakeup (since we don't know what speed we are coming back from sleep at, and that seems to work fine). Since, during this short interval, the actual CPU speed might be incorrect, we also hack around by multiplying loops_per_jiffy by 2 (max speed factor on those machines) during early wakeup stage to make sure udelay's during that time aren't too short. For after 2.6.12, we'll change udelay implementation to use the CPU timebase (which is always constant) instead like we do on ppc64 and thus get rid of all those problems. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-09[PATCH] iseries_veth: Supress spurious WARN_ON() at module unloadMichael Ellerman
My patch from a few weeks back (now in mainline), called "Cleanup skbs to prevent unregister_netdevice() hanging", can cause our TX timeout code to fire on machines with lots of VLANs (because it takes > 2 seconds between when we stop the queues and when we're finished stopping the connections). When that happens the TX timeout code freaks out and does a WARN_ON() because as far as it's concerned there shouldn't be a TX timeout happening, which is fair enough. I have a "proper" fix for this, which is to a) do refcounting on connections and b) implement a proper ack timer so we don't keep unacked skbs lying around for ever. But for 2.6.12 I propose just supressing the WARN_ON(). Users will still see the "NETDEV WATCHDOG" warning, but that's not nearly as bad as a WARN_ON() which users interpret as an Oops. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-09Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6Linus Torvalds
2005-06-09[PATCH] PCI: MSI functionality broken on Serverworks GC chipsetNarendra Sankar
MSI functionality is broken on the GC_LE x86 chipset that Serverworks developed and that is being used in various platforms today. Broadcom is going to push out to the kernel MSI enabled Gigabit drivers (in the very near future), and we would like to make sure that MSI does not get enabled on any platforms using the GC_LE chipset (device id 0x17). Following the AMD 8131 example, I am including a patch to disable MSI functionality when a GCNB_LE is detected. Please let me know if there are any issues with this. This is a permanent fix for this chipset, as the hardware will not be updated. Signed-off-by: Narendra Sankar <nsankar@broadcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-09Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6Linus Torvalds
2005-06-09[PATCH] USB: ftdi_sio: avoid losing received data in tty-ldiscIan Abbott
ftdi_sio: Avoid losing bytes at tty-ldisc. This patch was originally developed by Daniel Smertnig. I (Ian Abbott) made a few changes. It has been tested by both Daniel and I, at least for raw, non-canonical receive data processing. Here is Daniel's original description of the patch: === During a project in which I was using a FTDI 232BM to transmit data at relative high speeds (625kBit/s), I noticed a problem where data was lost even if flow control was enabled: The FTDI-Driver receives 512 Bytes of data over USB at a time, which consists of 8 64-Byte packets. Subtracting the 2 bytes of status information included in each packet this gives 496 "real" data bytes per read. This data is passed (indirectly, via the flip buffers) to the tty line discipline which takes care of throttling when there the free buffer space reaches TTY_THRESHOLD_THROTTLE (128). Because the FTDI driver processes up to 496 bytes at a time, throttling won't happen in time and the line discipline will discard the remaining bytes. To avoid this the patch passes data in 62-byte blocks to the tty layer and checks the available space in the ldisc-buffers. If there isn't enough free space, processing the rest of the data is delayed using a workqueue. Note: The original problem should be easily reproducible with a userspace program which does slow & small reads. === Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Daniel Smertnig <daniel.smertnig@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-09[PATCH] USB: fix ub issuesPete Zaitcev
This smoothes two imperfections: - Increase number of LUNs per device from 4 to 9. The best solution would be to remove this limit altogether, but that has to wait until the time when more than 26 hosts are allowed. - Replace mdelay with msleep in a probing routine. Signed-off-by: Pete Zaitcev <zaitcev@yahoo.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-09[PATCH] PCI Hotplug: fix CPCI reference counting bugScott Murray
Here's a patch that fixes up the pci_dev refcounting in the CPCI code. I've done some testing against it and it seems fine here. Signed-off-by: Scott Murray <scottm@somanetworks.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-09[PATCH] sg traverse fix for __atapi_pio_bytes()Albert Lee
Problem: Incorrect md5sum when using ATAPI PIO mode to verify a distro CD. Root cause: sg traverse problem. In __atapi_pio_bytes(), if qc->cursg++ is increased and "goto next_page" is executed, then sg is not updated to the new qc->cursg and the old sg is overwritten with the new data. Changes: - Replace "goto next_page" with "goto next_sg" to make sg updated. Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
2005-06-09[PATCH] sata_sil: Fix FIFO PCI Bus Arbitration kernel oopsJens Axboe
Correct this. diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
2005-06-08Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/tg3-2.6Linus Torvalds
2005-06-08[PATCH] dm: Handle READA requests in dm-mpath.cLars Marowsky-Bree
READA errors failing with EWOULDBLOCK/EAGAIN do not constitute a valid reason for failing the path; this lead to erratic errors on DM multipath devices. This error can be safely propagated upwards without failing the path. Acked-by: Kevin Corry <kevcorry@us.ibm.com> Acked-by: Jens Axboe <axboe@suse.de> Signed-off-by: Lars Marowsky-Bree <lmb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08[TG3]: Update driver version and release date.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-08[TG3]: Fix 5700/5701 DMA corruption on Apple G4.Michael Chan
Fix 5700/5701 DMA write corruption on Apple G4 by detecting the Apple UniNorth PCI 1.5 chipset and adjusting the DMA write boundary to 16. DMA test fails to detect the problem with this chipset. Thanks to Manuel Perez Ayala for reporting the problem and helping to debug it. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-08Merge master.kernel.org:/home/rmk/linux-2.6-serialLinus Torvalds
2005-06-08[PATCH] Serial: remove unused variable in sa1100 driverRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-07Merge of master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgartLinus Torvalds
2005-06-07[PATCH] PCI: do VIA IRQ fixup always, not just in PIC modeBjorn Helgaas
At least some VIA chipsets require the fixup even in IO-APIC mode. This was found and debugged with the patient assistance of Stian Jordet <liste@jordet.nu> on an Asus CUV266-DLS motherboard. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-07[PATCH] input: disable scroll feature on AT keyboardsVojtech Pavlik
This patch disables the scroll feature on AT keyboards by default, because it causes the numbers of mouse devices to shift, breaking user setups. Signed-off-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-07[PATCH] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0).David Mosberger
[AGPGART] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0). As mentioned earlier, the current check_bridge_mode() code assumes that AGP bridges are PCI devices. This isn't always true. Definitely not for HP zx1 chipset and the same seems to be the case for SGI's AGP bridge. The patch below fixes the problem by picking up the AGP_MODE_3_0 bit from bridge->mode. I feel like I may be missing something, since I can't see any reason why check_bridge_mode() wasn't doing that in the first place. According to the AGP 3.0 specs, the AGP_MODE_3_0 bit is determined during the hardware reset and cannot be changed, so it seems to me it should be safe to pick it up from bridge->mode. With the patch applied, I can definitely use AGP acceleration both with AGP 2.0 and AGP 3.0 (one with an Nvidia card, the other with an ATI FireGL card). Unless someone spots a problem, please apply this patch so 3d acceleration can work on zx1 boxes again. This makes AGP work again on machines with an AGP bridge that isn't a PCI device. Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
2005-06-07[PATCH] AGP fix for Xen VMMKeir Fraser
When Linux is running on the Xen virtual machine monitor, physical addresses are virtualised and cannot be directly referenced by the AGP GART. This patch fixes the GART driver for Xen by adding a layer of abstraction between physical addresses and 'GART addresses'. Architecture-specific functions are also defined for allocating and freeing the GATT. Xen requires this to ensure that table really is contiguous from the point of view of the GART. These extra interface functions are defined as 'no-ops' for all existing architectures that use the GART driver. Signed-off-by: Keir Fraser <keir@xensource.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Jones <davej@redhat.com>
2005-06-07[PATCH] sgi-agp: fixes a problem with accessing GART memory in ↵Michael Werner
sgi_tioca_insert_memory and sgi_tioca_remove_memory This patch fixes a problem with accessing GART memory in sgi_tioca_insert_memory and sgi_tioca_remove_memory. sgi-agp.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) Signed-off-by: Mike Werner <werner@sgi.com> Signed-off-by: Dave Jones <davej@redhat.com>
2005-06-07[PATCH] i945G patch for agpgartAlan Hourihane
Attached is a small patch for i945G support against 2.6.11.11. From: Alan Hourihane <alanh@fairlite.demon.co.uk> Signed-off-by: Dave Jones <davej@redhat.com>
2005-06-06Merge of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/tg3-2.6Linus Torvalds
2005-06-06[TG3]: Update driver version and release date.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-06[TG3] Fix link failure in 5701Michael Chan
On some 5701 devices with older bootcode, the LED configuration bits in SRAM may be invalid with value zero. The fix is to check for invalid bits (0) and default to PHY 1 mode. Incorrect LED mode will lead to error in programming the PHY. Thanks to Grant Grundler for debugging the problem. >From Grant: | In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting | programmed and how to determine what to program into LED_CTRL. The new | code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write | to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was | saying MODE_MAC (0x0) and that doesn't work. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-06[TG3]: Add TSO firmware licenseMichael Chan
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>