Re: [PATCH] drivercore: Add driver probe deferral mechanism

[Grant Likely]

On Tue, Jul 5, 2011 at 10:36 AM, Greg KH <gregkh@xxxxxxx> wrote:
> On Tue, Jul 05, 2011 at 10:28:37AM -0600, Grant Likely wrote:
>> On Tue, Jul 5, 2011 at 10:11 AM, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
>> > On Tue, Jul 5, 2011 at 17:50, Greg KH <gregkh@xxxxxxx> wrote:
>> >
>> >> I wonder if doing this all from a workqueue in the first place is going
>> >> to cause problems as probe isn't normally done this way at all.
>> >
>> > Yeah, I would expect unforeseen problems with the async thread too.
>> > It's probably all solvable, but it sounds troublesome to find out if
>> > things go wrong.
>> >
>> > We have sync hooks (BUS_NOTIFY_*) where any kind of code can subscribe
>> > to when devices get added or get bound to a driver. Can't the code
>> > that relies on later hookups to already existing devices/bindings not
>> > just plug into that?
>>
>> I tried that.  It resulted in a lot of complexity that each driver
>> needs to implement correctly which is why I started looking for a
>> different way to go about it.
>
> No, the bus that wants this just has to do it, not the drivers
> themselves, right?

It's not about the bus_type, and there is nothing that the bus can do
to solve this problem because it the dependencies are completely
orthogonal to the bus.  ie. what does an i2c bus know about the audio
path to a codec?  The problem must be solved at the driver scope.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/