Am 20.09.2019 um 10:55 schrieb Linus Walleij [off-list ref]:

On Tue, Sep 17, 2019 at 4:26 PM H. Nikolaus Schaller [off-list ref] wrote:

quoted

quoted

Am 17.09.2019 um 00:52 schrieb Linus Walleij [off-list ref]:
On Mon, Sep 16, 2019 at 12:59 PM H. Nikolaus Schaller [off-list ref] wrote:

quoted

ping.

Device omap3-gta04 is neither working with v5.3 nor linux-next quite a while and we need a solution.

Can't we just apply the last part of the patch in this thread:

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi

b/arch/arm/boot/dts/omap3-gta04.dtsi
index 9a9a29fe88ec..47bab8e1040e 100644

--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi

@@ -124,6 +124,7 @@
                      spi-max-frequency = <100000>;
                      spi-cpol;
                      spi-cpha;
+                       spi-cs-high;

                      backlight= <&backlight>;
                      label = "lcd";

Surely this fixes the problem?

yes, it is a workaround, but appears to violate some policies.
E.g. the spi-cs-high; is undocumented but DT bindings maintainer
seems to be against documenting it as I had proposed in my
other patch.

It is documented as a boolean in
Documentation/devicetree/bindings/spi/spi-controller.yaml
with the following description:

     spi-cs-high:
       $ref: /schemas/types.yaml#/definitions/flag
       description:
         The device requires the chip select active high.

So I don't think it is about it being undocumented.

Yes, the basic property is documented. But incomplete.

The strange inversion side-effect on the third gpio parameter
is undocumented and not understandable from this description
alone.

quoted

Rather he seems to have proposed a white-list in the driver code.
So that the legacy mode is only becoming active for those systems
which really need the legacy mode instead of everyone.

Yeah that seems like a plausible way forward if we want to
move away from the legacy way of specifying polarity.

quoted

Then, we do not need this patch for GTA04.

We don't need to implement the perfect solution up front.
We can aim for that in the long run. I usually go by the IETF
motto "rough consensus and running code".

quoted

So its up to you to decide which way to go. We are happy with
any one that makes mainline work again asap...

I suggest to go both way:
apply this oneliner and tag for stable so that GTA04 works
again.

Then for the next kernel think about a possible more abitious
whitelist solution and after adding that remove *all* "spi-cs-high"
flags from all device trees in the kernel after fixing them
all up.

Ok, that looks like a viable path.

BR and thanks,
Nikolaus