On Fri, Sep 01, 2023 at 09:40:11AM +0200, Bartosz Golaszewski wrote: > On Fri, Sep 1, 2023 at 1:25 AM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > On Thu, Aug 31, 2023 at 09:49:34PM +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > > > Currently the bcm2835 SPI driver uses functions meant for GPIO providers > > > exclusively to locate the GPIO chip it gets its CS pins from and request > > > the relevant pin. I don't know the background and what bug forced this. ... > > > /* > > > + * TODO: The code below is a slightly better alternative to the utter > > > + * abuse of the GPIO API that I found here before. It creates a > > > + * temporary lookup table, assigns it to the SPI device, gets the GPIO > > > + * descriptor and then releases the lookup table. > > > * > > > + * Still the real problem is unsolved. Looks like the cs_gpiods table > > > + * is not assigned correctly from DT? > > > */ > > > > I'm not sure why this quirk is here. AFAIR the SPI CS quirks are located in > > gpiolib-of.c. > > > > I'm not sure this is a good candidate for the GPIOLIB quirks. This is > the SPI setup callback (which makes me think - I should have used > gpiod_get(), not devm_gpiod_get() and then put the descriptor in > .cleanup()) and not probe. It would be great to get some background on > why this is even needed in the first place. The only reason I see is > booting the driver with an invalid device-tree that doesn't assign the > GPIO to the SPI controller. Maybe Lukas knows more? -- With Best Regards, Andy Shevchenko