Messages in this thread | | | Date | Tue, 5 Jul 2011 10:29:03 -0700 | From | Greg KH <> | Subject | Re: [PATCH] drivercore: Add driver probe deferral mechanism |
| |
On Tue, Jul 05, 2011 at 11:17:46AM -0600, Grant Likely wrote: > On Tue, Jul 5, 2011 at 10:36 AM, Greg KH <gregkh@suse.de> 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@vrfy.org> wrote: > >> > On Tue, Jul 5, 2011 at 17:50, Greg KH <gregkh@suse.de> 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.
Ok, let's look at your next implementation and see how it goes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |