Re: Side effect of SPI GPIO descriptor usage

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, Dec 4, 2019 at 3:46 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:

> I looked it over and most are devices like board files and RTC
> clocks that enforce SPI_CS_HIGH. They seem to be native
> chip selects so it will work as expected but I will look it over so
> I haven't broken any of them.

I looked all over:

drivers/mfd/ezx-pcap.c
Enforces SPI_CS_HIGH if platform data PCAP_CS_AH is
set. Nothing (no board file) in the kernel sets it.
No action.

drivers/mfd/mc13xxx-spi.c
drivers/mfd/motorola-cpcap.c
Hardcodes both SPI_MODE_0 and SPI_CS_HIGH.
Should be patched to |= SPI_MODE_0 and
^= SPI_CS_HIGH. I sent patches.

drivers/rtc/rts-ds1302.c
drivers/rtc/rts-ds1305.c
drivers/rtc/rtc-pcf2123.c
These just have some text comments on the importance of using
an active high chip select. That then gets defined in the boardfile or
the device tree which is fine. Any GPIO lines used for this can be
flagged as active high or low appropriately.

drivers/rtc/rtc-ds1343.c:
Hardcodes SPI_CS_HIGH, has no in-tree users (bo board files
refer to it), does not support device tree. So there is no way
to break it. Sent a patch anyways.

drivers/rtc/rtc-rx6110.c
Prints a warning if not flagged SPI_CS_HIGH, wil print
that warning if used with a GPIO chip select from device
tree. No regression, also no in-tree users.

drivers/staging/fb_uc1611.c
drivers/staging/fb_watterott.c
A staging driver hardcoding SPI_CS_HIGH, sent a patch
for this too so we don't gain any bad examples.

Yours,
Linus Walleij