linux-kernel - Re: [PATCH 3/4] leds: simatic-ipc-leds-gpio: add new model 227G

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: <20220729090431.565ed505@md1za8fc.ad001.siemens.net>
Date:   Fri, 29 Jul 2022 09:04:31 +0200
From:   Henning Schild <henning.schild@...mens.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Pavel Machek <pavel@....cz>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Linus Walleij <linus.walleij@...aro.org>,
        Tasanakorn Phaipool <tasanakorn@...il.com>,
        Sheng-Yuan Huang <syhuang3@...oton.com>
Subject: Re: [PATCH 3/4] leds: simatic-ipc-leds-gpio: add new model 227G

Am Thu, 28 Jul 2022 23:41:31 +0200
schrieb Andy Shevchenko <andy.shevchenko@...il.com>:

> On Thu, Jul 28, 2022 at 5:57 PM Henning Schild
> <henning.schild@...mens.com> wrote:
> >
> > This adds support of the Siemens Simatic IPC227G. Its LEDs are
> > connected to GPIO pins provided by the gpio-f7188x module. We make
> > sure that gets loaded, if not enabled in the kernel config no LED
> > support will be available.  
> 
> ...
> 
> > +       switch (plat->devmode) {
> > +       case SIMATIC_IPC_DEVICE_127E:
> > +               simatic_ipc_led_gpio_table =
> > &simatic_ipc_led_gpio_table_127e;
> > +               break;
> > +       case SIMATIC_IPC_DEVICE_227G:  
> 
> > +               if (!IS_ENABLED(CONFIG_GPIO_F7188X))
> > +                       return -ENODEV;  
> 
> Hmm... What is the difference with the 127E model in the sense of the
> driver absence? Why do we need this check?

What happens when the GPIO_LOOKUP_IDX does not find anything is an
endless printing of all missing lookups, actually pretty frequently so
that the kernel log becomes useless. I did not look deeper but i guess
"leds-gpio" will go into some sort of polling and wait for those pins.

The debian configured kernels i used so far for my work always had
PINCTRL_BROXTON, i guess if that was not available i would end up in
the polling/printing loop as well. I never tried without, just found
that polling thing when working on this model.

In fact the 127E will likely also need to check for PINCTRL_BROXTON
somehow. Or maybe the "leds-gpio" platform device needs to be
registered in a way where it will not go into polling/printing. I will
study the code to see if there is a way to go without polling but then
i might need some sort of serialization so i go not try and
register+fail before those pins exist.

Pavel maybe you have an idea what to do here.

> > +               request_module("gpio-f7188x");  
> 
> I'm not sure why you need request_module().

The difference to "pinctrl-broxton" is that it comes up on its own
because it has autoloading support. And this one only probes on
=m + modprobe or =y.

Henning

> > +               simatic_ipc_led_gpio_table =
> > &simatic_ipc_led_gpio_table_227g;
> > +               break;
> > +       default:
> > +               return -ENODEV;
> > +       }  
>