[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMRc=Mc4-TUOSJUguT0mPfoMHo3W8JHGscWGga1NwdoHPCdgeg@mail.gmail.com>
Date: Fri, 1 Sep 2023 11:34:20 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
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 11:22 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> 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
Thanks! I will fix the patch and add this link to the commit message.
Bart
Powered by blists - more mailing lists