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
