linux-stable.git/include/linux/device.h, branch linux-2.6.20.y

Driver core: proper prototype for drivers/base/init.c:driver_init()

2006-12-20T18:56:45+00:00

Add a prototype for driver_init() in include/linux/device.h.

Also remove a static function of the same name in drivers/acpi/ibm_acpi.c to
ibm_acpi_driver_init() to fix the namespace collision.

Signed-off-by: Adrian Bunk 
Acked-by: Henrique de Moraes Holschuh 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

[PATCH] add numa node information to struct device

2006-12-07T16:39:22+00:00

For node-aware skb allocations we need information about the node in struct
net_device or struct device.  Davem suggested to put it into struct device
which this patch does.

In particular:

 - struct device gets a new int numa_node member if CONFIG_NUMA is set
 - there are two new helpers, dev_to_node and set_dev_node to
   transparently deal with the non-numa case
 - for pci devices the node-info is set to the value we get from
   pcibus_to_node.

Note that for some architectures pcibus_to_node doesn't work yet at the time
we call it currently.  This is harmless and will just mean skb allocations
aren't node-local on this architectures until the implementation of
pcibus_to_node on these architectures have been updated (There are patches for
x86 and x86_64 floating around)

[akpm@osdl.org: cleanup]
Signed-off-by: Christoph Hellwig 
Cc: Christoph Lameter 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

driver core: Introduce device_move(): move a device to a new parent.

2006-12-01T22:52:01+00:00

Provide a function device_move() to move a device to a new parent device. Add
auxilliary functions kobject_move() and sysfs_move_dir().
kobject_move() generates a new uevent of type KOBJ_MOVE, containing the
previous path (DEVPATH_OLD) in addition to the usual values. For this, a new
interface kobject_uevent_env() is created that allows to add further
environmental data to the uevent at the kobject layer.

Signed-off-by: Cornelia Huck 
Acked-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

driver core: Introduce device_find_child().

2006-12-01T22:52:01+00:00

Introduce device_find_child() to match device_for_each_child().

Signed-off-by: Cornelia Huck 
Signed-off-by: Greg Kroah-Hartman

ACPI: Change ACPI to use dev_archdata instead of firmware_data

2006-12-01T22:52:01+00:00

Change ACPI to use dev_archdata instead of firmware_data

This patch changes ACPI to use the new dev_archdata on i386, x86_64
and ia64 (is there any other arch using ACPI ?) to store it's
acpi_handle.

It also removes the firmware_data field from struct device as this
was the only user.

Only build-tested on x86

Signed-off-by: Benjamin Herrenschmidt 
Cc: Len Brown 
Signed-off-by: Greg Kroah-Hartman

Driver core: add dev_archdata to struct device

2006-12-01T22:52:01+00:00

Add arch specific dev_archdata to struct device

Adds an arch specific struct dev_arch to struct device. This enables
architecture to add specific fields to every device in the system, like
DMA operation pointers, NUMA node ID, firmware specific data, etc...

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Andi Kleen 
Acked-By: David Howells 
Signed-off-by: Greg Kroah-Hartman

Driver Core: Move virtual_device_parent() to core.c

2006-12-01T22:51:58+00:00

It doesn't need to be global or in device.h


Cc: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

Driver core: add notification of bus events

2006-12-01T22:51:58+00:00

I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.

That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.

There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.

The usage I have for these are:

 - The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.

 - The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Remove __must_check for device_for_each_child()

2006-10-23T18:01:33+00:00

Eliminate more __must_check madness.

The return code from device_for_each_child() depends on the values
which the helper function returns.  If the helper function always
returns zero, it's utterly pointless to check the return code from
device_for_each_child().

The only code which knows if the return value should be checked is
the caller itself, so forcing the return code to always be checked
is silly.  Hence, remove the __must_check annotation.

Signed-off-by: Russell King 
Signed-off-by: Linus Torvalds

Driver core: Fix potential deadlock in driver core

2006-09-26T04:08:40+00:00

There is a potential deadlock in the driver core.  It boils down to
the fact that bus_remove_device() calls klist_remove() instead of
klist_del(), thereby waiting until the reference count of the
klist_node in the bus's klist of devices drops to 0.  The refcount
can't reach 0 so long as a modprobe process is trying to bind a new
driver to the device being removed, by calling __driver_attach().  The
problem is that __driver_attach() tries to acquire the device's
parent's semaphore, but the caller of bus_remove_device() is quite
likely to own that semaphore already.

It isn't sufficient just to replace klist_remove() with klist_del().
Doing so runs the risk that the device would remain on the bus's klist
of devices for some time, and so could be bound to another driver even
after it was unregistered.  What's needed is a new way to distinguish
whether or not a device is registered, based on a criterion other than
whether its klist_node is linked into the bus's klist of devices.  That
way driver binding can fail when the device is unregistered, even if
it is still linked into the klist.

This patch (as782) implements the solution, by adding a new bitflag to
indiate when a struct device is registered, by testing the flag before
allowing a driver to bind a device, and by changing the definition of
the device_is_registered() inline.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman