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: <20220823164207.6de6c387@md1za8fc.ad001.siemens.net>
Date:   Tue, 23 Aug 2022 16:42:07 +0200
From:   Henning Schild <henning.schild@...mens.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Pavel Machek <pavel@....cz>, linux-leds@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO
 providing driver

Am Tue, 23 Aug 2022 17:15:15 +0300
schrieb Andy Shevchenko <andriy.shevchenko@...ux.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ