[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150807121913.GS20873@sirena.org.uk>
Date: Fri, 7 Aug 2015 13:19:13 +0100
From: Mark Brown <broonie@...nel.org>
To: Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc: linux-kernel@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
Stephen Warren <swarren@...dotorg.org>,
Javier Martinez Canillas <javier@....samsung.com>,
Thierry Reding <thierry.reding@...il.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
linux-arm-kernel@...ts.infradead.org,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
devicetree@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
linux-acpi@...r.kernel.org, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v3 02/18] of/platform: add of_platform_probe
On Thu, Aug 06, 2015 at 04:11:39PM +0200, Tomeu Vizoso wrote:
> Walks the OF tree up and finds the closest ancestor that has a platform
> device associated with it, probing it if isn't bound to a driver yet.
> The above should ensure that the dependency represented by the passed OF
> node is available, because probing a platform device should cause its
> descendants to be probed as well.
This sounds like it's going to break in the case where we have MFDs that
represent their functions in DT (not a pattern I'm a fan of but it's a
thing people do). We'll walk back to the platform device for the MFD
function, try to probe it and then give up. Perhaps that's good enough
anyway but it's not clear to me why we don't just try every parent we
find?
I'm also not a fan of the fact that the interface here is explicitly
saying that we want to probe a platform device, that's an implementation
detail that callers shouldn't need to know about. From the point of
view of the callers what they're trying to do is kick any dependencies
into being instantiated, the fact that we currently try to accomplish it
with platform devices isn't something they care about.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists