On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:

On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:

quoted

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:

quoted

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

You link to a thread which says that "AT LEAST CURRENTLY, the calling
locations [the 'DT look-up code' you mention above] are DT specific
functions anyway.

But the point I'm making is that we are working towards *fixing* that,
and *not* using DT-specific code in places where we should be using the
generic APIs.

What is the plan for fixing things here?  It's not obvious (at least to
me) that we don't want to have the subsystems having knowledge of how
they are bound to a specific firmware which is what you seem to imply
here.  That seems like it's going to fall down since the different
firmware interfaces do have quite different ideas about how things fit
together at a system level and different compatibility needs which do
suggest that just trying to do a direct mapping from DT into ACPI may
well not make people happy but it sounds like that's the intention.

When it gets to drivers the situation is much more clear since it's
normally just simple properties, it's generally a bit more worrying if
drivers are needing to directly interact with cross-device linkage.
This is all subsystem level code though.

None of that really negates that fact that we are *working* on cleaning
these code paths up to be firmware-agnostic, and the fact that we
haven't got to this one *yet* isn't necessarily a good reason to make
it *worse* by adding new firmware-specificity to it.

It seems like we're going to have to refactor these bits of code when
they get generalised anyway so I'm not sure that the additional cost
here is that big.