lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VfSHgdikX5=Qba62BwWofVf7gHhS2hq2OuBwHFz9riCWQ@mail.gmail.com>
Date:   Tue, 24 Jan 2023 11:46:34 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Henning Schild <henning.schild@...mens.com>
Cc:     Lee Jones <lee@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Pavel Machek <pavel@....cz>, linux-leds@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] leds: simatic-ipc-leds-gpio: make sure we have the
 GPIO providing driver

On Mon, Jan 23, 2023 at 10:49 PM Henning Schild
<henning.schild@...mens.com> wrote:
> Am Thu, 19 Jan 2023 21:02:40 +0000
> schrieb Lee Jones <lee@...nel.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@...il.com> Signed-off-by: Henning Schild
> > > <henning.schild@...mens.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ