linux-kernel - Re: [PATCH 2/4] reset: add GPIO-based reset controller

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: <758c4fe3-1ea1-4a8c-bb6f-3a3df588da75@sirena.org.uk>
Date: Fri, 5 Jan 2024 14:33:21 +0000
From: Mark Brown <broonie@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Sean Anderson <sean.anderson@...o.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Banajit Goswami <bgoswami@...cinc.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org,
	linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, Bartosz Golaszewski <brgl@...ev.pl>
Subject: Re: [PATCH 2/4] reset: add GPIO-based reset controller

On Thu, Jan 04, 2024 at 08:08:50PM +0100, Krzysztof Kozlowski wrote:
> On 04/01/2024 17:30, Sean Anderson wrote:

> > device post-assert delay post-deassert delay
> > ====== ================= ===================
> > A                  500us                 1ms
> > B                    1ms               300us

...

> Now, if we are back to realistic cases - use just the longest reset time.

Isn't the main concern here that when one device probes we don't yet
know the times for the other devices?

> > If we leave things up to the drivers, then whoever probes first will get
> > to decide the reset sequence.

> In current design yes, but it's not a problem to change it. Where is the
> limitation? Just read other values and update the reset time.

We might have already done a reset by that time and earlier devices
might prevent later devices from resetting again.  It shouldn't be such
an issue for the post delay, but might be one for the pre delay.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)