Re: [PATCH RESEND] spi: spidev: Allow matching DT compatible strings from ACPI

[Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>]

On Tue, Jun 28, 2016 at 12:47:42PM +0100, Mark Brown wrote:
> On Tue, Jun 28, 2016 at 12:22:34PM +0300, Mika Westerberg wrote:
> > On Mon, Jun 27, 2016 at 01:24:48PM +0100, Mark Brown wrote:
> 
> > > Please allow a reasonable time for review, especially for an invasive
> > > change like this which needs a bunch of research to figure out how
> > > sensible the infrastructure to shove DT into ACPI is.
> 
> > Sure.
> 
> The big thing I need to check out here is if this breaks the check for
> directly listing spidev in DT so we end up with the same abstraction
> failures that plague DT since people refuse to describe their hardware.

You are talking about this check, right?

        if (spi->dev.of_node && !of_match_device(spidev_dt_ids, &spi->dev)) {
                dev_err(&spi->dev, "buggy DT: spidev listed directly in DT\n");
                WARN_ON(spi->dev.of_node &&
                        !of_match_device(spidev_dt_ids, &spi->dev));
        } 

As far as I can tell it should work, with the patch applied, just as it worked
before. For ACPI there is no possibility to list the node directly in ASL code
as we always require DT compatible string in _DSD.

In other words we never match using name of the node.

> > The /dev/spi-0 then can be used analogous to /dev/i2c-0. You first need
> > to program wanted chip select using those new ioctls. Then you can use
> > the device as normal spidev (all existing file operations and ioctls
> > still work). You can pick another chip select as needed. If there is an
> > actual SPI device bound to a chip select, that cannot be used through
> > /dev/spi-0.
> 
> The trouble with this is that unlike I2C using SPI devices involves
> toggling signals that we don't definitively know are connected to the
> bus.  It's therefore much less safe than the equivalent thing for DT.
> If we went the extra step and required that a slave be listed in DT then
> that is much less of a concern.

OK, I see.
--
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