aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/base
Commit message (Collapse)AuthorAge
* [PATCH] drivers/base/bus.c: fix iteration in driver_detach()Roman Kagan2005-05-05
| | | | | | | | | | | | | | | | | With 2.6.11 and 2.6.12-rc2 (and perhaps a few versions before) usb drivers for multi-interface devices, which do usb_driver_release_interface() in their disconnect(), make rmmod hang. It turns out to be due to a bug in drivers/base/bus.c:driver_detach(), that iterates over the list of attached devices with list_for_each_safe() under an assumption that device_release_driver() only releases the current device, while it may also call device_release_driver() for other devices on the same list. The following patch fixes it. Please consider applying. Signed-off-by: Roman Kagan <rkagan@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Hotplug: Make dev->bus checking consistentAlexander Nyberg2005-05-05
| | | | | | | | | | | Earlier in the same function dev->bus is checked before dereferenced, make consistent although I honestly don't know if dev->bus could ever be NULL Found by the Coverity tool Signed-off-by: Alexander Nyberg <alexn@dsv.su.se> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] DocBook: fix some descriptionsMartin Waitz2005-05-01
| | | | | | | | | Some KernelDoc descriptions are updated to match the current code. No code changes. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] kobject/hotplug split - devices corekay.sievers@vrfy.org2005-04-19
| | | | | | | | | | kobject_add() and kobject_del() don't emit hotplug events anymore. Do it ourselves if we are finished populating the device directory. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] kobject/hotplug split - class corekay.sievers@vrfy.org2005-04-19
| | | | | | | | | | kobject_add() and kobject_del() don't emit hotplug events anymore. Do it ourselves if we are finished populating the device directory. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] export platform_add_devicesRobert Schwebel2005-04-19
| | | | | | | | | | | | | | | | | platform_add_devices can be used from within modules, so it should be exported. This can for example happen if you have hotpluggable firmware in an FPGA on a system on chip processor; in our case the FPGA is probed for devices and the FPGA base code registers the devices it has found with the kernel. (akpm: I think this is reasonable from a licensing POV: it's unlikely that anyone would be interested in merging such specialised modules into mainline, and it's a GPL export). Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] add TIMEOUT to firmware_class hotplug eventkay.sievers@vrfy.org2005-04-19
| | | | | | | | | | | | | | | | On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: > The current implementation of the firmware class breaks a fundamental > assumption in udevd: that the physical device can be initialised fully > prior to executing the next event for that device. Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] pm_message_t: more fixes in common and i386Pavel Machek2005-04-16
| | | | | | | | | | I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that turned out not to be the case as Russel King pointed out. Here are fixes for Documentation and common code (mainly system devices). Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!