Hi,
On Mon, 5 Aug 2019 12:29:19 +0200 Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Jul 26, 2019 at 12:43 AM Rob Herring robh@kernel.org wrote:
On Thu, Jul 25, 2019 at 12:23 AM H. Nikolaus Schaller hns@goldelico.com wrote:
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.
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