linux-kernel - Re: [PATCH] gpiolib: Avoid side effects in gpio_is

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: <ZGQoZKrEceqlSEtp@sol>
Date:   Wed, 17 May 2023 09:05:40 +0800
From:   Kent Gibson <warthog618@...il.com>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        "brgl@...ev.pl" <brgl@...ev.pl>,
        "johan@...nel.org" <johan@...nel.org>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "maz@...nel.org" <maz@...nel.org>,
        Ben Brown <Ben.Brown@...iedtelesis.co.nz>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpiolib: Avoid side effects in gpio_is_visible()

On Wed, May 17, 2023 at 08:47:13AM +0800, Kent Gibson wrote:
> On Tue, May 16, 2023 at 11:50:42PM +0000, Chris Packham wrote:
> > Hi Kent,
> > 
> > The second application is a userspace driver for a L3 network switch 
> > (actually two of them for different silicon vendors). Again this needs 
> > to deal with resets for PHYs connected to the switch that the kernel has 
> > no visibility of as well as the GPIOs for the SFP cages. Again we have a 
> > slightly less simple kernel module that grabs all these GPIOs and 
> > exports them with known names. This time there are considerably more of 
> > these GPIOs (our largest system currently has 96 SFP+ ports with 4 GPIOs 
> > per port) so we're much more reliant on being able to do things like 
> > `for x in port*tx-dis; do echo 1 >$x; done`
> > 
> 
> Given appropriate line names, that is already something you can do with
> the libgpiod v2 tools.  Something like:
> 
> `for x in gpiochip*; do gpioset -c x tx-dis=1; done`
> 

Of course that may only pulse the tx-dis line, depending on how your
driver behaves when the line is released.
(gpioset has options to control the pulse width, if that works for you)

If you need that to persist, independent of device driver behaviour,
then you need a some process holding the lines that your scripts can
communicate with.

Cheers,
Kent.