spi: bcm2835: Restore native CS probing when pinctrl-bcm2835 is absent

The lookup table forces the use of the "pinctrl-bcm2835" GPIO chip
provider and essentially assumes that there is going to be such a
provider, and if not, we will fail to set-up the SPI device.

While this is true on Raspberry Pi based systems (2835/36/37, 2711,
2712), this is not true on 7712/77122 Broadcom STB systems which use the
SPI driver, but not the GPIO driver.

There used to be an early check:

       chip = gpiochip_find("pinctrl-bcm2835", chip_match_name);
       if (!chip)
               return 0;

which would accomplish that nicely, bring something similar back by
checking for the compatible strings matched by the pinctrl-bcm2835.c
driver, if there is no Device Tree node matching those compatible
strings, then we won't find any GPIO provider registered by the
"pinctrl-bcm2835" driver.

Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API")
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
 drivers/spi/spi-bcm2835.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

On Wed, Apr 2, 2025 at 1:37 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
>
> The lookup table forces the use of the "pinctrl-bcm2835" GPIO chip
> provider and essentially assumes that there is going to be such a
> provider, and if not, we will fail to set-up the SPI device.
>

Yeah, the consumer driver itself is an unfortunate place to define the
provider data. This could potentially be moved to gpiolib-of.c quirks.

> While this is true on Raspberry Pi based systems (2835/36/37, 2711,
> 2712), this is not true on 7712/77122 Broadcom STB systems which use the
> SPI driver, but not the GPIO driver.
>
> There used to be an early check:
>
>        chip = gpiochip_find("pinctrl-bcm2835", chip_match_name);
>        if (!chip)
>                return 0;
>
> which would accomplish that nicely, bring something similar back by
> checking for the compatible strings matched by the pinctrl-bcm2835.c
> driver, if there is no Device Tree node matching those compatible
> strings, then we won't find any GPIO provider registered by the
> "pinctrl-bcm2835" driver.
>
> Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API")
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
>  drivers/spi/spi-bcm2835.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
> index a5d621b94d5e..5926e004d9a6 100644
> --- a/drivers/spi/spi-bcm2835.c
> +++ b/drivers/spi/spi-bcm2835.c
> @@ -1226,7 +1226,12 @@ static int bcm2835_spi_setup(struct spi_device *spi)
>         struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
>         struct bcm2835_spidev *target = spi_get_ctldata(spi);
>         struct gpiod_lookup_table *lookup __free(kfree) = NULL;
> -       int ret;
> +       const char *pinctrl_compats[] = {
> +               "brcm,bcm2835-gpio",
> +               "brcm,bcm2711-gpio",
> +               "brcm,bcm7211-gpio",
> +       };
> +       int ret, i;
>         u32 cs;
>
>         if (!target) {
> @@ -1291,6 +1296,14 @@ static int bcm2835_spi_setup(struct spi_device *spi)
>                 goto err_cleanup;
>         }
>
> +       for (i = 0; i < ARRAY_SIZE(pinctrl_compats); i++) {
> +               if (of_find_compatible_node(NULL, NULL, pinctrl_compats[i]))
> +                       break;
> +       }
> +
> +       if (i == ARRAY_SIZE(pinctrl_compats))
> +               return 0;
> +
>         /*
>          * 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
> --
> 2.34.1
>
>

The fix is good for now but I'd still try to move this out of the
driver at some point.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

On Tue, 01 Apr 2025 16:36:03 -0700, Florian Fainelli wrote:
> The lookup table forces the use of the "pinctrl-bcm2835" GPIO chip
> provider and essentially assumes that there is going to be such a
> provider, and if not, we will fail to set-up the SPI device.
> 
> While this is true on Raspberry Pi based systems (2835/36/37, 2711,
> 2712), this is not true on 7712/77122 Broadcom STB systems which use the
> SPI driver, but not the GPIO driver.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: bcm2835: Restore native CS probing when pinctrl-bcm2835 is absent
      commit: e19c1272c80a5ecce387c1b0c3b995f4edf9c525

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

On 4/2/25 04:44, Bartosz Golaszewski wrote:
> On Wed, Apr 2, 2025 at 1:37 AM Florian Fainelli
> <florian.fainelli@broadcom.com> wrote:
>>
>> The lookup table forces the use of the "pinctrl-bcm2835" GPIO chip
>> provider and essentially assumes that there is going to be such a
>> provider, and if not, we will fail to set-up the SPI device.
>>
> 
> Yeah, the consumer driver itself is an unfortunate place to define the
> provider data. This could potentially be moved to gpiolib-of.c quirks.
> 
>> While this is true on Raspberry Pi based systems (2835/36/37, 2711,
>> 2712), this is not true on 7712/77122 Broadcom STB systems which use the
>> SPI driver, but not the GPIO driver.
>>
>> There used to be an early check:
>>
>>         chip = gpiochip_find("pinctrl-bcm2835", chip_match_name);
>>         if (!chip)
>>                 return 0;
>>
>> which would accomplish that nicely, bring something similar back by
>> checking for the compatible strings matched by the pinctrl-bcm2835.c
>> driver, if there is no Device Tree node matching those compatible
>> strings, then we won't find any GPIO provider registered by the
>> "pinctrl-bcm2835" driver.
>>
>> Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API")
>> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
>> ---
>>   drivers/spi/spi-bcm2835.c | 15 ++++++++++++++-
>>   1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
>> index a5d621b94d5e..5926e004d9a6 100644
>> --- a/drivers/spi/spi-bcm2835.c
>> +++ b/drivers/spi/spi-bcm2835.c
>> @@ -1226,7 +1226,12 @@ static int bcm2835_spi_setup(struct spi_device *spi)
>>          struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
>>          struct bcm2835_spidev *target = spi_get_ctldata(spi);
>>          struct gpiod_lookup_table *lookup __free(kfree) = NULL;
>> -       int ret;
>> +       const char *pinctrl_compats[] = {
>> +               "brcm,bcm2835-gpio",
>> +               "brcm,bcm2711-gpio",
>> +               "brcm,bcm7211-gpio",
>> +       };
>> +       int ret, i;
>>          u32 cs;
>>
>>          if (!target) {
>> @@ -1291,6 +1296,14 @@ static int bcm2835_spi_setup(struct spi_device *spi)
>>                  goto err_cleanup;
>>          }
>>
>> +       for (i = 0; i < ARRAY_SIZE(pinctrl_compats); i++) {
>> +               if (of_find_compatible_node(NULL, NULL, pinctrl_compats[i]))
>> +                       break;
>> +       }
>> +
>> +       if (i == ARRAY_SIZE(pinctrl_compats))
>> +               return 0;
>> +
>>          /*
>>           * 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
>> --
>> 2.34.1
>>
>>
> 
> The fix is good for now but I'd still try to move this out of the
> driver at some point.
> 
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Thanks, I will see what I can do on that front, but if you don't hear 
from me in the next few weeks, don't hesitate to ask again :)