linux-kernel - Re: [PATCH] i2c: muxes: pca954x: Allow sharing reset GPIO

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] [day] [month] [year] [list]

Message-ID: <31a9060a-aef3-4b1a-8db8-ada5e57833cc@linaro.org>
Date: Fri, 7 Jun 2024 08:46:10 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Eddie James <eajames@...ux.ibm.com>,
 Chris Packham <chris.packham@...iedtelesis.co.nz>, peda@...ntia.se,
 p.zabel@...gutronix.de
Cc: linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c: muxes: pca954x: Allow sharing reset GPIO

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