Am Thu, 19 Jan 2023 21:02:40 +0000
schrieb Lee Jones <lee@xxxxxxxxxx>:
> On Fri, 07 Oct 2022, 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 no 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.
> >
> > Fixes: a6c80bec3c93 ("leds: simatic-ipc-leds-gpio: Add GPIO version
> > of Siemens driver") Reviewed-by: Andy Shevchenko
> > <andy.shevchenko@xxxxxxxxx> Signed-off-by: Henning Schild
> > <henning.schild@xxxxxxxxxxx> ---
> > drivers/leds/simple/simatic-ipc-leds-gpio.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> FYI: I'm going to try my best not to take another one like this.
You will not have to. I now understood how to improve on that as i am
adding more variants needing more gpio controller drivers.
> Please try to improve the whole situation for you next submission.
>
> Applied, thanks.
I hope this is still in the branches for a merge. It should be applied.
It does fix a problem but using a wrong pattern, but a pattern that is
already in use.
So this will fix 6.1 and above in the short term.
In the long term i will restructure to individual drivers which have a
clear dependency chain in Kconfig. I will use inheritance to arrive at
minimal code duplication and will use Kconfig switch default
inheritance to ease configuration.
Such restructuring patches will have to be written first, but they will
come. Either stand-alone or together with the next machine.
regards,
Henning
