Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 17 May 2023 09:05:40 +0800
From:   Kent Gibson <warthog618@gmail.com>
To:     Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        "brgl@bgdev.pl" <brgl@bgdev.pl>,
        "johan@kernel.org" <johan@kernel.org>,
        "andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
        "maz@kernel.org" <maz@kernel.org>,
        Ben Brown <Ben.Brown@alliedtelesis.co.nz>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] gpiolib: Avoid side effects in gpio_is_visible()
Message-ID: <ZGQoZKrEceqlSEtp@sol>
References: <20230512042806.3438373-1-chris.packham@alliedtelesis.co.nz>
 <CACRpkdYz9ipNTo2ORXKWy5Q4uCpKL=9Gd+kK76pestX7Onuz-Q@mail.gmail.com>
 <b36fcdf1-45ab-0c06-efe4-237df0612466@alliedtelesis.co.nz>
 <CACRpkdbiSAFoJP_JB1d_6gQ+Xx7Y+mLAh=C6Za+fpyWuRe6Gbw@mail.gmail.com>
 <31a23398-9b0e-4a19-3576-84fcfd3ce4b5@alliedtelesis.co.nz>
 <ZGQH8/hH0Llx3rzZ@sol>
 <a61415db-fa3f-2fce-9c21-08d8dd026960@alliedtelesis.co.nz>
 <ZGQkEdZ6DoJbgiFh@sol>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZGQkEdZ6DoJbgiFh@sol>
Precedence: bulk

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.