Re: [PATCH] RFT: spi: bcm2835: Convert to use CS GPIO descriptors

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Thu, Jan 31, 2019 at 7:17 AM Lukas Wunner <lukas@xxxxxxxxx> wrote:

> The device tree in the downstream (Foundation) kernel tree has the
> cs-gpios property, hence uses GPIO Chip Select by default.
> The upstream (mainline) kernel does not have the cs-gpios property,

That sounds like something that should be fixed, so also upstream
uses cs-gpios. I suppose we have to keep the hack around until
noone in the whole world use the old dts/dtb files. (Which means
I will maybe attempt delete it in some year or two.)

> The code in bcm2835_spi_setup() is broken in that it always assumes that
> GPIO 8 / 7 is used.  It should instead check whether the function of
> GPIO 8 / 7 or GPIO 36 / 35 is "alt0".  If neither of GPIO 8 / 36 (or
> 7 / 35 if "reg" is 1) is set to "alt0", the function should return a
> negative error code.  I'm not sure what the expected behaviour is if
> *both* GPIO 8 / 36 (or 7 / 35) are set to "alt0".  I suspect the correct
> thing to do would be to drive both pins because we don't know which one
> the slave is attached to.  Because the SPI core only supports a single
> CS GPIO per slave, it would be necessary to request both pins in the
> driver and add a ->set_cs() callback which sets either or both pins
> depending on which one is set to "alt0".

This looks like a nightmare. Better just use the GPIOs then.

> So, it's complicated.

Yeah I agree.

Do you think you can take this patch for a test drive on top of
the SPI tree or linux-next and see if it works as expected?

I can reword the comment if need be.

Yours,
Linus Walleij