linux/drivers/base, branch v2.6.12

[PATCH] driver core: restore event order for device_add()

2005-05-23T23:08:12Z

As a result of the split of the kobject-registration and the corresponding hotplug event, the order of events for device_add() has changed. This restores the old order, cause it confused some userspace applications. Signed-off-by: Kay Sievers Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

[PATCH] Driver Core: remove driver model detach_state

2005-05-17T21:54:55Z

The driver model has a "detach_state" mechanism that: - Has never been used by any in-kernel drive; - Is superfluous, since driver remove() methods can do the same thing; - Became buggy when the suspend() parameter changed semantics and type; - Could self-deadlock when called from certain suspend contexts; - Is effectively wasted documentation, object code, and headspace. This removes that "detach_state" mechanism; net code shrink, as well as a per-device saving in the driver model and sysfs. Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman

[PATCH] Driver Core: pm diagnostics update, check for errors

2005-05-17T21:54:54Z

This patch includes various tweaks in the messaging that appears during system pm state transitions: * Warn about certain illegal calls in the device tree, like resuming child before parent or suspending parent before child. This could happen easily enough through sysfs, or in some cases when drivers use device_pm_set_parent(). * Be more consistent about dev_dbg() tracing ... do it for resume() and shutdown() too, and never if the driver doesn't have that method. * Say which type of system sleep state is being entered. Except for the warnings, these only affect debug messaging. Signed-off-by: David Brownell Acked-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman

[PATCH] drivers/base/bus.c: fix iteration in driver_detach()

2005-05-05T06:44:38Z

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 Signed-off-by: Greg Kroah-Hartman

[PATCH] Hotplug: Make dev->bus checking consistent

2005-05-05T06:44:37Z

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 Signed-off-by: Greg Kroah-Hartman

[PATCH] DocBook: fix some descriptions

2005-05-01T15:59:26Z

Some KernelDoc descriptions are updated to match the current code. No code changes. Signed-off-by: Martin Waitz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] kobject/hotplug split - devices core

2005-04-19T04:57:36Z

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 Signed-off-by: Greg Kroah-Hartman

[PATCH] kobject/hotplug split - class core

2005-04-19T04:57:35Z

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 Signed-off-by: Greg Kroah-Hartman

[PATCH] export platform_add_devices

2005-04-19T04:57:32Z

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 Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

[PATCH] add TIMEOUT to firmware_class hotplug event

2005-04-19T04:57:31Z

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 Signed-off-by: Greg Kroah-Hartman