On Wed, Jun 29, 2016 at 05:21:27PM +0100, Mark Brown wrote: > On Wed, Jun 29, 2016 at 12:13:04PM +0300, Mika Westerberg wrote: > > On Tue, Jun 28, 2016 at 05:18:22PM +0100, Mark Brown wrote: > > > > So you're saying that it's not possible for ACPI to use anything > > > *except* an explicitly listed compatible string to bind? What we want > > > to avoid is any ACPI tables that explicitly list spidev since that's a > > > total abstraction failure. > > > That's exactly what I'm saying. We never match using the node name > > (which is always 32-bit "string" like "SPI0"). For PRP0001 match to > > succeeed you need to have "compatible" property. > > > Without the "compatible" property you get a warning from ACPI core: > > > \_SB.SPI1.SPID requires 'compatible' property > > > and it will not match anything. > > 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(). > 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. 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). -- 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