overlays: sc16is75x: Fix spi1 cs-gpios

[nbuchwitz]

Native cs is somewhat broken on spi1 (see [1]), so re-add the explicit cs-gpios definition, as was done before in sc16is752-spi1-overlay.

Fixes #6962

[1] torvalds/linux@519f2c2

[nbuchwitz]

This is a potential fix for #6962

[pelwell]

That's not going to work - you can either build up the cs-gpios property one cell at a time, or add a dormant fragment that is enabled by this override (which feels a bit cleaner).

[nbuchwitz]

I've updated the PR with a different approach and tested it successfully with the bespoke waveshare board

[nbuchwitz]

@pelwell can you please re-trigger the builds, so the reporter can verify this too? Thanks.

[nbuchwitz]

Another thought: Do we want to have this fixup in each and every overlay targeting spi1 or would it make more sense to leave it to the spi1-[123]cs overlays? mcp251xfd-overlay.dts for example assumes that spi is correctly configured by the spi overlays.

In case of the sc1675x on spi1:

dtoverlay=spi1-1cs,cs0_spidev=off
dtoverlay=sc16is75x-spi,sc16is752,spi1-0,int_pin=24

(the cs0_spidev=off is probably something which can be done in the downstream overlays though)

[pelwell]

What about 1.1, 1.2, 2.0, etc.?

[nbuchwitz]

What about 1.1, 1.2, 2.0, etc.?

Guess they are broken as before ("backwards compatibility")? I mean they could be added to the overlay, but imho the split between the spi overlays and device overlay would be a cleaner and more maintenance friendly approach? I was also thinking about a dtsi shared between different spi device overlays, but still lots of boilerplate code in each ...

[pelwell]

Having had a proper chance to look at this, I'm not convinced this patch is enough to solve the problem.

As well as enabling CS GPIOs, the old sc16is752-spi1 overlay, like the spi1-<n>cs overlays, enables the SPI1 controller node and selects the correct ALT function on GPIOs 19-21. It also enables the AUX resets block (needed for SPI1 and SPI2).

In an ideal world we would have always required the use of spi1-1cs as well as sc16is752-spi1, but it's too late for that now. I considered generating a new sc16is752-spi1 by combining spi1-1cs and sc16is75x-spi (using ovmerge via the // redo a comment), but that would break the int_pin and xtal parameters.

#6996 is an alternate approach that adds just enough to allow sc16is75x-spi to emulate sc16is752-spi1.

[nbuchwitz]

#6996 looks sane. I will close this one in favor