On Wed, 9 May 2007 02:25:10 -0700 (PDT),
david@xxxxxxx wrote:
makeing up an example
today the process would be
call driver X to initialize it's devices.
driver X follows these steps
1. see if a compatible chipset/device appears to be available
2. initialize the chipset/device (loading firmware)
3. query the now partially initialized chipset/device to see what specific
options are enabled in the hardware
4. for each 'thing' that's enabled in hardware, initialize and register
it.
The sync ->probe() could return after step 1 (when it is clear the
driver wants to bind to the device). The remainder should be done in
the async function, so that the bus could go on with other devices. The
driver should then signal when it is done with its registrations.
to acommodate both of these device models it seems to me that you can't
defice either
async followed by sync
or
sync followed by async
but instead need to support the combined
sync followed by async followed by sync.
now, it's very possible that I'm mistaken and one of the two-part models
can be used for everything, if so then it's definantly simpler to do so.
Hm, maybe I'm dense, but I really don't understand the problem here.
Why should (optional) sync followed by (optional) async followed by bus
synchonization not cover all cases? The async portion can also do some
"sync" stuff and then signal completion, can't it?
If you're worried about notifications to userspace, you could first
suppress the add uevent via uevent_suppress and then generate it when
you signal completion to the bus.