On Wed, Jun 29, 2016 at 07:31:01PM +0100, Mark Brown wrote: > 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. That fallback matching does not even work in ACPI like I told you already. We have no plans to do anything like that either. That's the reason why we complain if there is PRP0001 without compatible string. > > > 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. Maybe but currently it works fine. And if problems are found they will be fixed as usual. -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html