From: Oleg Verych <olecom@flower.upol.cz>
To: linux-kernel@vger.kernel.org
Cc: David Brownell <david-b@pacbell.net>,
Russell King <rmk@arm.linux.org.uk>, Greg KH <greg@kroah.com>
Subject: Re: [patch/RFC 2.6.18-rc] platform_device_probe(), to conserve memory
Date: Mon, 04 Sep 2006 16:25:45 +0200 [thread overview]
Message-ID: <44FC3769.3060502@flower.upol.cz> (raw)
In-Reply-To: <200609032224.28303.david-b@pacbell.net>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
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)
[-- Attachment #2: doc-platform_driver_probe.patch --]
[-- Type: text/x-patch, Size: 1160 bytes --]
--- 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
prev parent reply other threads:[~2006-09-04 13:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-04 1:23 [patch/RFC 2.6.18-rc] platform_device_probe(), to conserve memory David Brownell
2006-09-04 1:34 ` Dmitry Torokhov
2006-09-04 2:34 ` David Brownell
2006-09-04 5:24 ` David Brownell
2006-09-04 14:25 ` Oleg Verych [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44FC3769.3060502@flower.upol.cz \
--to=olecom@flower.upol.cz \
--cc=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox