linux-kernel - Re: [PATCH v6 4/6] reset: Instantiate reset GPIO controller for shared reset-gpios

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: <CACRpkdZ6GH94EdBsoB61FbEW5dV1+dRCV9O7TUFCMBBdVJBPuQ@mail.gmail.com>
Date: Wed, 31 Jan 2024 13:50:35 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, 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 Wed, Jan 31, 2024 at 10:50 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:

> Nothing is odd - I use get_maintainers.pl which just don't print your
> names. I can add your addresses manually, no problem, but don't blame
> the contributor that get_maintainers.pl has a missing content-regex. If
> you want to be Cced on usage of GPIOs, you need to be sure that
> MAINTAINERS file has appropriate pattern.

I think that is over-reliance on tooling, I think if I author a patch
creating a struct gpio_chip it's natural to CC the GPIO maintainers,
just by intuition. Maybe that's just me.

I guess if one wants to automate maybe get_maintainers should
CC GPIO maintainers on patches that has a + #include <linux/gpio/driver.h>
in the patch body but it seems like stretching it to me, it's just too
much process.

> > reset -> virtual "gpio" -> many physical gpios[0..n]
>
> It does not, there is no single GPIO here. There is a single reset
> controller, though, but still multiple GPIOs in DTS.

Aha so this is problem similar to what regulators are doing,
where they had this problem that a single GPIO can contain a
regulator used by many devices?

There the solution is something along the line that the first
consumer turns on the light when it arrives and the last consumer
turns it off when it leaves, at least that is the idea.

That solution isn't the pretties either :/

But if we find a solution for the reset controller, it appears to
me that the pattern should be re-usable for regulators too?

I think Bartosz says in another reply that *_NONEXCLUSIVE that
the regulators are using is broken so if we are to invent something
new we should make it available for everyone.

> > This supports a 1-to-1 map: one GPIO in, one GPIO out, same offset.
> > So if that is extended to support 1-to-many, this problem is solved.
>
> It does not match the hardware thus I don't know how to implement it in
> DTS while keeping the requirement that we are describing hardware, not
> OS abstractions.

OK fair enough I got it wrong.

(the rest of comments are probably fallouts from the misunderstanding).

> So none of these ideas were posted in previous threads, just because you
> were not CCed (except one thread)?
>
> https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/
> https://lore.kernel.org/all/9eebec9b-e6fd-4a22-89ea-b434f446e061@linaro.org/
> https://lore.kernel.org/all/20231018100055.140847-1-krzysztof.kozlowski@linaro.org/
> https://social.treehouse.systems/@marcan/111268780311634160
>
> Please implement some custom lei filter, so you will get such
> notifications earlier. We keep discussing this for many months on
> various attempts and this specific attempt already reached v6.

Yeah I should really look at lei!

I just haven't had time to get into it, because it appears it appeals
most to people who use local clients like mutt. And I use gmail
(yeah ...) I guess I would have to change my whole workflow to
accomodate for lei, but it may very well be the right thing to do, I
did change everything for b4 already.

Yours,
Linus Walleij