[PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver

[PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver

[Henning Schild]

If we register a "leds-gpio" platform device for GPIO pins that do not
exist we get a -EPROBE_DEFER and the probe will be tried again later.
If there is not driver to provide that pin we will poll forever and also
create a lot of log messages.

So check if that GPIO driver is configured, if so it will come up
eventually. If not we exit our probe function early and do not even
bother registering the "leds-gpio". This method was chosen over "Kconfig
depends" since this way we can add support for more devices and GPIO
backends more easily without "depends"ing on all GPIO backends.

Signed-off-by: Henning Schild <henning.schild@siemens.com>
---
 drivers/leds/simple/simatic-ipc-leds-gpio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/leds/simple/simatic-ipc-leds-gpio.c b/drivers/leds/simple/simatic-ipc-leds-gpio.c
index 4c9e663a90ba..0c96ba98e338 100644
--- a/drivers/leds/simple/simatic-ipc-leds-gpio.c
+++ b/drivers/leds/simple/simatic-ipc-leds-gpio.c
@@ -57,6 +57,8 @@ static int simatic_ipc_leds_gpio_probe(struct platform_device *pdev)
 	struct gpio_desc *gpiod;
 	int err;
 
+	if (!IS_ENABLED(CONFIG_PINCTRL_BROXTON))
+		return -ENODEV;
 	gpiod_add_lookup_table(&simatic_ipc_led_gpio_table);
 	simatic_leds_pdev = platform_device_register_resndata(NULL,
 		"leds-gpio", PLATFORM_DEVID_NONE, NULL, 0,
-- 
2.35.1

Re: [PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver

[Henning Schild]

This applies on top of
"[PATCH v6 00/12] platform/x86: introduce p2sb_bar() helper"

where it could also be squashed into p12.

Am Fri, 5 Aug 2022 14:03:43 +0200
schrieb Henning Schild <henning.schild@siemens.com>:

> If we register a "leds-gpio" platform device for GPIO pins that do not
> exist we get a -EPROBE_DEFER and the probe will be tried again later.
> If there is not driver to provide that pin we will poll forever and
> also create a lot of log messages.

When i did build a kernel without PINCTRL_BROXTON and booted that, i
quickly filled up my disk with gigabytes of log messages from
"leds-gpio".
 
> So check if that GPIO driver is configured, if so it will come up
> eventually. If not we exit our probe function early and do not even
> bother registering the "leds-gpio". This method was chosen over
> "Kconfig depends" since this way we can add support for more devices
> and GPIO backends more easily without "depends"ing on all GPIO
> backends.

The series "[PATCH 0/4] add support for another simatic board" shows
how a second board would be added, using 

	if (!IS_ENABLED(CONFIG_GPIO_F7188X))
		return -ENODEV;

I am not too happy with the solution. But it is better than "depends"
because we do not need to build all possible GPIO providers if we want
a minimal kernel for a board, while having all simatic gpio based
boards in one led driver.

And we will anyhow need to "name the provider" in case it does not
auto-probe. Also to be seen in that other series where we

	request_module("gpio-f7188x");

regards,
Henning

> Signed-off-by: Henning Schild <henning.schild@siemens.com>
> ---
>  drivers/leds/simple/simatic-ipc-leds-gpio.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/leds/simple/simatic-ipc-leds-gpio.c
> b/drivers/leds/simple/simatic-ipc-leds-gpio.c index
> 4c9e663a90ba..0c96ba98e338 100644 ---
> a/drivers/leds/simple/simatic-ipc-leds-gpio.c +++
> b/drivers/leds/simple/simatic-ipc-leds-gpio.c @@ -57,6 +57,8 @@
> static int simatic_ipc_leds_gpio_probe(struct platform_device *pdev)
> struct gpio_desc *gpiod; int err;
>  
> +	if (!IS_ENABLED(CONFIG_PINCTRL_BROXTON))
> +		return -ENODEV;
>  	gpiod_add_lookup_table(&simatic_ipc_led_gpio_table);
>  	simatic_leds_pdev = platform_device_register_resndata(NULL,
>  		"leds-gpio", PLATFORM_DEVID_NONE, NULL, 0,

Re: [PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver

[Andy Shevchenko]

On Fri, Aug 05, 2022 at 02:19:20PM +0200, Henning Schild wrote:
> This applies on top of
> "[PATCH v6 00/12] platform/x86: introduce p2sb_bar() helper"
> 
> where it could also be squashed into p12.

Can't be squashed, since P2SB series is now part of upstream.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver

[Andy Shevchenko]

On Fri, Aug 05, 2022 at 02:03:43PM +0200, Henning Schild wrote:
> If we register a "leds-gpio" platform device for GPIO pins that do not
> exist we get a -EPROBE_DEFER and the probe will be tried again later.
> If there is not driver to provide that pin we will poll forever and also
> create a lot of log messages.
> 
> So check if that GPIO driver is configured, if so it will come up
> eventually. If not we exit our probe function early and do not even
> bother registering the "leds-gpio". This method was chosen over "Kconfig
> depends" since this way we can add support for more devices and GPIO
> backends more easily without "depends"ing on all GPIO backends.

Not sure what we should do with this patch due to your self-reply on it.
So, if it's still needed, I would expect a new version / resend.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver

[Henning Schild]

Am Tue, 23 Aug 2022 17:15:15 +0300
schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

> On Fri, Aug 05, 2022 at 02:03:43PM +0200, Henning Schild wrote:
> > If we register a "leds-gpio" platform device for GPIO pins that do
> > not exist we get a -EPROBE_DEFER and the probe will be tried again
> > later. If there is not driver to provide that pin we will poll
> > forever and also create a lot of log messages.
> > 
> > So check if that GPIO driver is configured, if so it will come up
> > eventually. If not we exit our probe function early and do not even
> > bother registering the "leds-gpio". This method was chosen over
> > "Kconfig depends" since this way we can add support for more
> > devices and GPIO backends more easily without "depends"ing on all
> > GPIO backends.  
> 
> Not sure what we should do with this patch due to your self-reply on
> it. So, if it's still needed, I would expect a new version / resend.

Ok i did not realize that the P2SB stuff made it in the meantime. This
patch is still relevant and should be picked on top, to deal with the
unlikely case that this driver is enabled where the gpio driver is not
... which would lead to an endless probing loop and a lot of logging.

Why would you expect a new version? I did not try but see no reason it
should not still apply. There has been no review comments, which means
no change needed.

Unless we want to give it a Fixes or something and consider that
probing loop a bug to make sure the patch makes it into all kernels
that carry my LED GPIO stuff based on the P2SB patches.

regards,
Henning

Re: [PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver

[Andy Shevchenko]

On Tue, Aug 23, 2022 at 04:42:07PM +0200, Henning Schild wrote:
> Am Tue, 23 Aug 2022 17:15:15 +0300
> schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > On Fri, Aug 05, 2022 at 02:03:43PM +0200, Henning Schild wrote:
> > > If we register a "leds-gpio" platform device for GPIO pins that do
> > > not exist we get a -EPROBE_DEFER and the probe will be tried again
> > > later. If there is not driver to provide that pin we will poll
> > > forever and also create a lot of log messages.
> > > 
> > > So check if that GPIO driver is configured, if so it will come up
> > > eventually. If not we exit our probe function early and do not even
> > > bother registering the "leds-gpio". This method was chosen over
> > > "Kconfig depends" since this way we can add support for more
> > > devices and GPIO backends more easily without "depends"ing on all
> > > GPIO backends.  
> > 
> > Not sure what we should do with this patch due to your self-reply on
> > it. So, if it's still needed, I would expect a new version / resend.
> 
> Ok i did not realize that the P2SB stuff made it in the meantime. This
> patch is still relevant and should be picked on top, to deal with the
> unlikely case that this driver is enabled where the gpio driver is not
> ... which would lead to an endless probing loop and a lot of logging.
> 
> Why would you expect a new version? I did not try but see no reason it
> should not still apply. There has been no review comments, which means
> no change needed.
> 
> Unless we want to give it a Fixes or something and consider that
> probing loop a bug to make sure the patch makes it into all kernels
> that carry my LED GPIO stuff based on the P2SB patches.

Because it's usually how maintainers work (at least Lee and Greg KH come
to my mind), when new cycle starts, the (potentially rebased) new versions
are expected.

But with powerfulness of `b4` tool it might be that they changed their ways
of maintaining. You need to ask the LED maintainer(s) on how to proceed.

-- 
With Best Regards,
Andy Shevchenko