On Sat, May 08, 2021 at 07:46:13AM -0400, Sven Van Asbroeck wrote: > On Sat, May 8, 2021 at 3:38 AM Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: > >> 2. Drive the gpiod chip select using the raw value, ignoring the > >> built-in polarity, which treats it the same as a gpio_xxx. Nice! > >> > > > > Looks nice (if for now don’t take into account the zillion of drivers to be changed), but IIRC last time discussions about this piece of code, the problem also in DT itself, you may not break boards with already cooked DTs. If you are sure about this, go ahead! > > Yes, you're absolutely right, the zillion of drivers to be changed is > a serious problem. I'm definitely not trying to sweep that under the > carpet... > > The rule table seems to indicate that the gpio's second devicetree > flag is ignored when it's used as a SPI gpio. So changing where the > polarity is stored, should not break DT? It may have repercussions > elsewhere though, not sure. > > (I hope the formatting will come out ok here. If not, use the link below) > 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. -- With Best Regards, Andy Shevchenko