On 06/06/2024 23:58, Eddie James wrote: > > On 3/10/24 23:14, Chris Packham wrote: >> Some hardware designs with multiple PCA954x devices use a reset GPIO >> connected to all the muxes. Support this configuration by making use of >> the reset controller framework which can deal with the shared reset >> GPIOs. Fall back to the old GPIO descriptor method if the reset >> controller framework is not enabled. > > > Hello Chris, Krzysztof, > > > This change makes it so that the reset subsystem reset doesn't behave in > the same way as the fallback gpio reset. The gpio, as part of acquiring > it, gets set high, and then set low in the mux driver. So, the device > reset is toggled. In the case of the reset subsystem option, the reset > is only de-asserted (so the device is taken out of reset). > > > I'm interested in preserving the previous behavior but with the shared > reset line. This can't be done just by doing "assert" first because the > shared reset subsystem doesn't allow that. So the reset-gpio driver > would have to implement the reset operation - no problem. However, how > to specify the wait time for the reset-gpio driver here? Something like > the simple reset driver maybe? Or a function call from the reset > consumer driver to specify the wait time for that reset? You can check my slides from EOSS/OSSNA this year: https://ossna2024.sched.com/event/1aPvr?iframe=no maybe links to original work will help you. Best regards, Krzysztof
