Hallo,
David Brownell wrote:
[...]
> + * One typical use for this would be with drivers for controllers integrated
> + * into system-on-chip processors, where the controller devices have been
> + * configured as part of board setup.
> + *
Or every not-on-external-bus (usb/firewire/cardbus) device in laptop.
IMHO it's very good addition to everything-plug device driver model.
It must have its place in Documentation/driver-model/.
--
-o--=O`C /. .\ (+)
#oo'L O o |
<___=E M ^-- | (you're barking up the wrong tree)
--- linux-2.6.18-rc6/Documentation/driver-model/driver.txt~ 2006-09-04 04:19:48.000000000 +0200
+++ linux-2.6.18-rc6/Documentation/driver-model/driver.txt 2006-09-04 16:14:18.551630750 +0200
@@ -105,14 +105,21 @@
It is important that drivers register their driver structure as early as
possible. Registration with the core initializes several fields in the
struct device_driver object, including the reference count and the
lock. These fields are assumed to be valid at all times and may be
used by the device model core or the bus driver.
+int platform_driver_probe(struct platform_driver *drv,
+ int (*probe)(struct platform_device *))
+
+Use this instead of platform_driver_register() when you know the device
+is not hotpluggable and has already been registered, and you want to
+remove its run-once probe() infrastructure from memory after the driver
+has bound to the device.
Transition Bus Drivers
~~~~~~~~~~~~~~~~~~~~~~
By defining wrapper functions, the transition to the new model can be
made easier. Drivers can ignore the generic structure altogether and
let the bus wrapper fill in the fields. For the callbacks, the bus can
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
