Re: [GIT PULL] On-demand device probing

[David Woodhouse]

On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> 
> > 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

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.

Sure, Russell is probably right that there are some places where the
generic APIs need fixing because they don't quite cover all use cases
yet.

And Mark is (unfortunately) right that some people are inventing new
bindings *purely* for ACPI which are different to the DT bindings for
the same device. But still, in those cases you'll theoretically be able
to see the *same* device represented under ACPI with *either* its new
ACPI HID and the ACPI-specific bindings, *or* as a PRP0001 with the DT
bindings. And this was always possible even with just DT â you could
have two incompatible bindings for the *same* hardware, with different
drivers. It was just a bad thing. And still is when one is ACPI and one
is DT, in my opinion.

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.

-- 
dwmw2

Attachment: smime.p7s
Description: S/MIME cryptographic signature