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.