[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111215065154.GA24248@opensource.wolfsonmicro.com>
Date: Thu, 15 Dec 2011 14:51:55 +0800
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: NeilBrown <neilb@...e.de>
Cc: MyungJoo Ham <myungjoo.ham@...sung.com>,
linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
Mike Lockwood <lockwood@...roid.com>,
Arve Hjønnevåg <arve@...roid.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Donggeun Kim <dg77.kim@...sung.com>, Greg KH <gregkh@...e.de>,
Arnd Bergmann <arnd@...db.de>,
MyungJoo Ham <myungjoo.ham@...il.com>,
Linus Walleij <linus.walleij@...aro.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Morten CHRISTIANSEN <morten.christiansen@...ricsson.com>
Subject: Re: [PATCH v2 0/3] introduce External Connector Class (extcon)
On Thu, Dec 15, 2011 at 01:32:29PM +1100, NeilBrown wrote:
j> 3/ The use of extcon_get_extcon_dev() requires that the port device be
> registered before the device that wants to be notified by it. Ensuring
> correct ordering of device discovery is (I believe) not always easy -
> particularly with module loading.
This is a massive problem throughout the kernel
> Would it make sense to instead have one device register as a
> switch-provider and the other device register as a switch-listener and as
> soon as they both exist they get connected: a bit like how 'devices' and
> 'drivers' can be registered in any order.
> Maybe the same device/driver infrastructure could be reused (an extcon
> bus maybe?) but I'm not really familiar enough with it to say (Greg??).
Grant has a proposal for this which revolves around devices trying to
acquire their resources and returning a "please retry" error code if
they don't have all their dependencies. Half the problem here is that
coming up with the dependency graph (and finding ways to talk about
devices that haven't been enumerated yet) is a very hard problem.
> Are there other examples of inter-device dependencies that can be used as
> a model?
The current solution is to fiddle with initcall order so that drivers
for devices that other devices depend on enumerate first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists