linux-kernel - Re: [PATCH v2 0/3] introduce External Connector Class (extcon)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111218181550.3fd35f6c@notabene.brown>
Date:	Sun, 18 Dec 2011 18:15:50 +1100
From:	NeilBrown <neilb@...e.de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
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, 15 Dec 2011 14:51:55 +0800 Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:

> 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 

So it seems.  I just tripped over it with regulators. When one is supplied by
another they need to be probed in the right order.
Sounds like we need to find a general solution.

> 
> >    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.

I can see how an -EAGAIN might work ... and it would exercise a lot of error
paths that otherwise never get called - I wonder if that is a good thing :-)

It doesn't feel quite like the right solution though.  Deciding when to retry,
and where to queue the device/driver pairs might be messy.

A possibility I have been thinking about is to multithread do_initcalls() and
have the various request functions (gpio_request, regulator_get, request_irq,
etc) optionally block if the resource isn't available.

We wouldn't create a new thread for every initcall, just when all current
threads are blocked.  And threads that have to block die once they finish
their initcall, so there is only ever one that is allowed to move on to the
'next' initcall.

Do we need to talk about devices that haven't been enumerated yet? or was
that just if we wanted to create an explicit dependency graph?

We would need names for resources that haven't been registered yet but that
seems fairly with with simple string names assigned in the board file (or
eventually the device-tree file I guess).

I might try hacking something together and see how badly it breaks.

> 
> >    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.

:-(  I was afraid of that.

NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)