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]
Date: Wed, 31 Jan 2024 14:32:48 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Linus Walleij <linus.walleij@...aro.org>,
 Bartosz Golaszewski <brgl@...ev.pl>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
 Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Banajit Goswami <bgoswami@...cinc.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>, Liam Girdwood
 <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 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>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>, Frank Rowand
 <frowand.list@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
 linux-arm-msm@...r.kernel.org, linux-sound@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org, Chris Packham <chris.packham@...iedtelesis.co.nz>,
 Sean Anderson <sean.anderson@...o.com>
Subject: Re: [PATCH v6 4/6] reset: Instantiate reset GPIO controller for
 shared reset-gpios

On 31/01/2024 14:17, Linus Walleij wrote:
> On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> 
>> [Me]
>>> reset -> virtual "gpio" -> many physical gpios[0..n]
>>
>> This is a different problem: it supports many users enabling the same
>> GPIO (in Krzysztof's patch it's one but could be more if needed) but -
>> unlike the broken NONEXCLUSIVE GPIOs in GPIOLIB - it counts the number
>> of users and doesn't disable the GPIO for as long as there's at least
>> one.
> 
> I don't know if the NONEXCLUSIVE stuff is broken, if you mean reference
> counting isn't working on them, then that is by design because they were
> invented for regulators and such use cases that do their own reference
> counting. It's also used for hacks where people need to look up a desc in
> a second spot, (perhaps we can fix those better).
> 
> As I say in commit b0ce7b29bfcd090ddba476f45a75ec0a797b048a
> "This solution with a special flag is not entirely elegant and should ideally
> be replaced by something more careful as this makes it possible for
> several consumers to enable/disable the same GPIO line to the left
> and right without any consistency."
> 
> I think for regulators (which is the vast majority using it) it isn't broken
> because the regulator reference counting is working.
> 
> So if we solve that problem for reset, we probably should put it in
> drivers/gpio/* somewhere so we can reuse the same solution for
> regulators and get rid of NONEXCLUSIVE altogether I think?
> 
> The NONEXCLUSIVE stuff was prompted by converting regulators to
> gpio descriptors, so it was for the greater good one can say. Or the
> lesser evil :( my judgement can be questioned here.

I discussed the non-exclusive GPIOs with Bartosz quite a lot, who was
Cced since beginning of this patchset, because that was my first
approach, which was rejected:

https://lore.kernel.org/all/b7aeda24-d638-45b7-8e30-80d287f498f8@sirena.org.uk/

The non-exclusive GPIO was made explicitly for regulators, so it is
working fine there, but it is broken everywhere else, where the drivers
do not handle it in sane way as regulator core does.

To make it working, either GPIO should be enable-count-aware, to which
Bartosz was opposing with talks with me, or the subsystem should mimic
regulators approach. In some way, my patchset is the second way here -
reset framework subsystem being aware of shared GPIO and handles the
enable-count, even though it is not using non-exclusive flag.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ