On Wed, Jun 29, 2016 at 07:34:20PM +0300, Mika Westerberg wrote: > On Wed, Jun 29, 2016 at 05:21:27PM +0100, Mark Brown wrote: > > But can that compatible string be spidev and be matched via the paths DT > > uses while still ensuring that enough of the OF matching code is enabled > > to cause the check to warn? That's the problem. > No it can't. The match is done in ACPI code not in DT code. See > drivers/acpi/bus.c::acpi_of_match_device(). And we're *sure* that's going to be maintained? People do use the fallback matching that DT does, I don't trust the ACPI maintainers not to do the same thing. > > Life would be a lot eaiser if Intel would use DT where it's appropriate, > > or if the OF in ACPI stuff were more transparent and needed fewer > > special cases. > I don't get this. We added PRP0001 and properties because then we can > reuse DT bindings in ACPI and thus there is no need to reinvent all > these things for ACPI. Right, but rather than just define a translation from ACPI to DT and use the DT code paths in their entirety for the relevant nodes what's happening is that there's a shim layer between ACPI and DT which sort of emulates bits of the DT interfaces but not quite and can lead to surprises. > This is not a special case at all. I'm merely enabling the same thing to > work in ACPI systems (sans the node name match). The force DT into ACPI layer that exists in the ACPI code is the special case here.
Attachment:
signature.asc
Description: PGP signature
