[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbGdCFb9a5bV_aBMd3eee3N5EdWy+Bkpct-YfHUgHysVw@mail.gmail.com>
Date: Fri, 1 Sep 2023 11:22:33 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
Lukas Wunner <lukas@...ner.de>,
Mark Brown <broonie@...nel.org>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>, linux-spi@...r.kernel.org,
linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [RFT PATCH] spi: bcm2835: reduce the abuse of the GPIO API
On Fri, Sep 1, 2023 at 10:55 AM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
> > 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?
He does!
The background can be found here:
https://www.spinics.net/lists/linux-gpio/msg36218.html
(hm this "spinics" archive should be imported to lore...)
Yours,
Linus Walleij
Powered by blists - more mailing lists