Commit Graph

5 Commits

Author SHA1 Message Date
Kay Sievers
187a1a94d6 [PATCH] driver core: restore event order for device_add()
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 <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23 16:08:12 -07:00
David Brownell
0b405a0f7e [PATCH] Driver Core: remove driver model detach_state
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 <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-17 14:54:55 -07:00
Alexander Nyberg
177a432494 [PATCH] Hotplug: Make dev->bus checking consistent
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>
2005-05-04 23:44:37 -07:00
kay.sievers@vrfy.org
e57cd73e2e [PATCH] kobject/hotplug split - devices core
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>
2005-04-18 21:57:36 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00