Hi Linus, On 04.08.19 02:38, Linus Walleij wrote: > This converts the BCM2835 SPI master driver to use GPIO > descriptors for chip select handling. > > The BCM2835 driver was relying on the core to drive the > CS high/low so very small changes were needed for this > part. If it managed to request the CS from the device tree > node, all is pretty straight forward. > > However for native GPIOs this driver has a quite unorthodox > loopback to request some GPIOs from the SoC GPIO chip by > looking it up from the device tree using gpiochip_find() > and then offseting hard into its numberspace. This has > been augmented a bit by using gpiochip_request_own_desc() > but this code really needs to be verified. If "native CS" > is actually an SoC GPIO, why is it even done this way? > Should this GPIO not just be defined in the device tree > like any other CS GPIO? I'm confused. > > Cc: Lukas Wunner <lukas@xxxxxxxxx> > Cc: Stefan Wahren <stefan.wahren@xxxxxxxx> > Cc: Martin Sperl <kernel@xxxxxxxxxxxxxxxx> > Cc: Chris Boot <bootc@xxxxxxxxx> > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > --- > ChangeLog v3->v4: > - Fix the offset of the chipselect line to be 8 - CS > as in the original code. > - Use the modified gpiochip_request_own_desc() to set up > line inversion semantics if need be. Look at the OF > node of the SPI device for flags. > ChangeLog v2->v3: > - Fix unused variable "err" compile-time message. > ChangeLog RFT->v2: > - Rebased on v5.1-rc1 > > I would very much appreciate if someone took this for > a ride on top of linux-next (there are some fixes in > the -rcs you need) and see if all still works as expected. sorry for my late reply, but i was on vacation. Thanks for your efforts on this, but currently i don't have a setup to test this :-(