Re: [PATCH v1] spi: fix client driver can't register success when use GPIO as CS

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Mon, May 10, 2021 at 4:56 PM Sven Van Asbroeck <thesven73@xxxxxxxxx> wrote:
> On Mon, May 10, 2021 at 7:36 AM Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx> wrote:
> > >
> > >       device node     | cs-gpio       | CS pin state active | Note
> > >       ================+===============+=====================+=====
> > >       spi-cs-high     | -             | H                   |
> > >       -               | -             | L                   |
> > >       spi-cs-high     | ACTIVE_HIGH   | H                   |
> > >       -               | ACTIVE_HIGH   | L                   | 1
> > >       spi-cs-high     | ACTIVE_LOW    | H                   | 2
> > >       -               | ACTIVE_LOW    | L                   |
> > >
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/spi/spi-controller.yaml?h=v5.12#n54
> >
> > This table is incompatible with ACPI. So we can't unify them until each of them
> > will play by the same rules. Can't say it won't happen, but it's far from that.
>
> Linus Wallej has added some gpiod OF quirks that checks if the gpio is
> used as a chip-select, and if so forces the gpiod polarity to
> implement the inversion:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpiolib-of.c?h=v5.13-rc1#n175
>
> If as suggested above, we disable that OF quirk and use the polarity
> flag from the SPI mode flags instead, and ignore the built-in gpiod
> polarity, the OF table boils down to:
>
> device node    |  CS pin active state
> =====================================
> -              |  L
> spi-cs-high    |  H
>
> which is exactly the same as the ACPI case:
> SPI mode flag  |  CS pin active state
> =====================================
> -              | L
> SPI_CS_HIGH    | H
>
> Your github commit says:
> > in ACPI case the default polarity
> > is active high and can't be altered

Right. This is the correct statement.

> So if ACPI gpiods are always active-high then unification can happen
> here, correct?

Probably. I really won't dive into OF rabbit hole, if you think it
will work, go for it!

For now I guess my patch is necessary to have. I don't think we may
delay its distribution while developing a better solution, do you
agree on this?

> But if I have misunderstood the ACPI case, and ACPI gpiod chip-selects
> can have any polarity, then I agree that unification cannot happen.
> Like I said earlier, I live mostly in OF-land, so my apologies if I
> have not fully grasped the ACPI case.

-- 
With Best Regards,
Andy Shevchenko