All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Henning Schild <henning.schild@siemens.com>
Cc: Lee Jones <lee@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Pavel Machek <pavel@ucw.cz>,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver
Date: Tue, 24 Jan 2023 11:46:34 +0200	[thread overview]
Message-ID: <CAHp75VfSHgdikX5=Qba62BwWofVf7gHhS2hq2OuBwHFz9riCWQ@mail.gmail.com> (raw)
In-Reply-To: <20230123214859.725cd1c3@md1za8fc.ad001.siemens.net>

On Mon, Jan 23, 2023 at 10:49 PM Henning Schild
<henning.schild@siemens.com> wrote:
> Am Thu, 19 Jan 2023 21:02:40 +0000
> schrieb Lee Jones <lee@kernel.org>:
> > 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@gmail.com> Signed-off-by: Henning Schild
> > > <henning.schild@siemens.com> ---
> > >  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.
>
> understood!
>
> > Please try to improve the whole situation for you next submission.
>
> When i have to touch this again, which i will, i will propose either
> "depend on all possible GPIO drivers" or introduce "#ifdef CONFIG"s.
> Caring most about big configs as seen in distros like debian, even for
> embedded systems ... i think i would prefer the first option, as it
> will also be easier to maintain.
>
> I do not see the whole infinite loop story on my plate, but if that got
> fixed i would follow up taking the fix into account.

AFAICS another possible (not sure if it's preferable) solution is to
split this driver to subdrivers and each of them will be dependent on
the corresponding pin control in Kconfig. It will satisfy both of your
requirements, right? Something like

simatic-leds-core.c
simatic-leds-127e.c (config ..._127E depends on PINCTRL_BROXTON)
...

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2023-01-24  9:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 15:33 [PATCH v4] leds: simatic-ipc-leds-gpio: make sure we have the GPIO providing driver Henning Schild
2022-12-22 10:19 ` Henning Schild
2022-12-23 11:58 ` Lee Jones
2023-01-02 15:22   ` Henning Schild
2023-01-03 20:20     ` Henning Schild
2023-01-04 14:24       ` Lee Jones
2023-01-04 14:39         ` Henning Schild
2023-01-04 15:51           ` Andy Shevchenko
2023-01-04 19:30             ` Henning Schild
2023-01-05  9:35               ` Andy Shevchenko
2023-01-05 11:23                 ` Henning Schild
2023-01-19 21:02 ` Lee Jones
2023-01-23 20:48   ` Henning Schild
2023-01-24  9:46     ` Andy Shevchenko [this message]
2023-01-24 10:29       ` Lee Jones
2023-01-24 13:52         ` Henning Schild
2023-01-24 14:50           ` Henning Schild
2023-01-24 13:35       ` Henning Schild
2023-01-24 13:46         ` Andy Shevchenko
2023-01-25 17:36           ` Henning Schild
2023-01-25 17:47             ` Andy Shevchenko
2023-02-02 19:57   ` Henning Schild
2023-02-03  7:59     ` Lee Jones
2023-02-03 16:58       ` Henning Schild

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHp75VfSHgdikX5=Qba62BwWofVf7gHhS2hq2OuBwHFz9riCWQ@mail.gmail.com' \
    --to=andy.shevchenko@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=henning.schild@siemens.com \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.