Hi,

On Mon, 5 Aug 2019 12:29:19 +0200
Linus Walleij [off-list ref] wrote:

On Fri, Jul 26, 2019 at 12:43 AM Rob Herring [off-list ref] wrote:

quoted

On Thu, Jul 25, 2019 at 12:23 AM H. Nikolaus Schaller [off-list ref] wrote:  

quoted

quoted

I tried to convince Linus that this is the right way but he convinced
me that a fix that handles all cases does not exist.

There seem to be embedded devices with older DTB (potentially in ROM)
which provide a plain 0 value for a gpios definition. And either with
or without spi-cs-high.

Since "0" is the same as "GPIO_ACTIVE_HIGH", the absence of
spi-cs-high was and must be interpreted as active low for these
devices. This leads to the inversion logic in code.

AFAIR it boils down to the question if gpiolib and the bindings
should still support such legacy devices with out-of tree DTB,
but force in-tree DTS to add the legacy spi-cs-high property.

Or if we should fix the 2 or 3 cases of in-tree legacy cases
and potentially break out-of tree DTBs.  

If it is small number of platforms, then the kernel could handle those
cases explicitly as needed.
 

quoted

IMHO it is more general to keep the out-of-tree DTBs working
and "fix" what we can control (in-tree DTS).  

If we do this, then we need to not call spi-cs-high legacy because
we're stuck with it forever.  

I agree. The background on it is here:
https://lkml.org/lkml/2019/4/2/4

Not using the negatively defined (i.e. if it is no there, the line is
by default active low) spi-cs-high would break
PowerPC, who were AFAICT using this to ship devices.

is this thing now just waiting for someone to do a s/legacy//?

Regards,
Andreas