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: <c3c8e68f-ee7e-430b-b890-011573e809b1@linaro.org>
Date: Sat, 6 Jan 2024 16:32:35 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Mark Brown <broonie@...nel.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 05/01/2024 15:33, Mark Brown wrote:
> 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?

You can never know when second device will appear. It might come from
modules, DTB overlay etc. If we want to satisfy all users, then we need
to wait till all users appear, which I think is not even possible,
considering runtime loaded overlays.

> 
>>> 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.

If the reset deassert (or assert, depending what's the default state) is
triggered in the probe, then it will happen with the probe of the first
device. If the delays of that reset are not suitable for the second -
not yet probed - then what do you propose? I have the answer: do not use
the simple, generic solution. The simple and generic solutions work for
simple and generic cases.

Best regards,
Krzysztof