Re: [patch/RFC 2.6.18-rc] platform_device_probe(), to conserve memory

[Oleg Verych <olecom@flower.upol.cz>]

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