Thread (101 messages) 101 messages, 22 authors, 2015-10-27

Re: [GIT PULL] On-demand device probing

From: Rob Herring <robh+dt@kernel.org>
Date: 2015-10-19 12:35:37
Also in: dri-devel, linux-clk, linux-devicetree, linux-gpio, linux-i2c, linux-pm, linux-pwm, linux-tegra, lkml

On Mon, Oct 19, 2015 at 4:44 AM, David Woodhouse [off-list ref] wrote:
On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
quoted
On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
quoted
On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
quoted
On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
quoted
quoted
quoted
I can't see adding calls like this all over the tree just to solve a
bus-specific problem, you are adding of_* calls where they aren't
needed, or wanted, at all.
quoted
quoted
This isn't bus specific, I'm not sure what makes you say that?
quoted
You are making it bus-specific by putting these calls all over the tree
in different bus subsystems semi-randomly for all I can determine.
Do you mean firmware rather than bus here?  I think that's the confusion
I have...
Certainly, if it literally is adding of_* calls then that would seem to
be gratuitously firmware-specific. Nothing should be using those these
days; any new code should be using the generic device property APIs
(except in special cases).
See version 2 of the series[1] which did that. It became obvious that
was pointless because the call paths ended up looking like this:

Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
of_probe_device

Rob

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/361137.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help