linux-kernel - Re: [GIT PULL] ARM: SoC/genpd driver updates for v6.6

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFrJH-1uaPCwnWZDPi4MRtOm=N2CHSRyvjXRDbQ1y-oOrw@mail.gmail.com>
Date:   Wed, 30 Aug 2023 10:33:37 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>
Cc:     linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Olof Johansson <olof@...om.net>, soc@...nel.org,
        linux-arm-kernel@...ts.infradead.org,
        Sebastian Reichel <sebastian.reichel@...labora.com>,
        "Rafael J . Wysocki" <rafael@...nel.org>
Subject: Re: [GIT PULL] ARM: SoC/genpd driver updates for v6.6

On Wed, 30 Aug 2023 at 03:20, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, 29 Aug 2023 at 17:48, Arnd Bergmann <arnd@...db.de> wrote:
> >
> > How about moving it to drivers/power/domain/ instead?
>
> That sounds like a sensible name and would seem to fit logically with
> our existing tree structure quite well.

I am sincerely sorry if I have annoyed you with picking the name
"genpd" as the directory-name - and especially without further
explanation. The genpd thing certainly deserves to be documented
better, I will try to get some time to do this soon. Anyway, me and
many others in the power/performance areas that have been working with
the genpd interface, have simply gotten comfortable using the "genpd"
acronym. Hence, the naming was a no-brainer to me.

That said, if you feel that the above directory-path/name is a better
fit I can certainly move it over there, np! Although, before you make
the final decision I want to point out a few things for you to
consider.

*) The new subsystem is solely intended for the generic PM domain
providers. Other PM domains providers, like the ACPI PM domains for
example (drivers/acpi/*), don't really belong here, at least in my
opinion. So, maybe "domain" isn't specific enough? Although, if not
using "genpd", I have no better suggestion.

**) Please keep in mind that we have several other power/performance
related subsystems that don't live under drivers/power/*. Moving more
things in there is not really going to help the people that work on
these things. No matter where and what the name of the subsystem is,
one simply needs to dive into the details anyway. Moreover, in this
case, "genpd" isn't just about "power" (idle management) but
performance management too.

>
> > I don't think we can easily rename the interfaces that have been
> > in use for the past 12 years
>
> I actually think the interface names are much less of an issue, since
> anybody using them is presumably familiar with the naming.
>
> It was only with the directory structure that I reacted to it, because
> that kind of exposes the naming to people who definitely are *not*
> familiar with it (ie me, but presumably anybody else who sees the
> diffstats etc fly past).
>
> And yes, we have a number of other pretty obscure driver names in our
> tree (I end up having to remind myself what "ntb" and "hsi" etc mean),
> and I don't tend to love them either, but at least they tend to be
> industry / vendor names.

I get your point. I was indeed trying to obey the current naming
strategy, but I think it's not entirely easy to understand what is
prefered.

Please advise me on how to move forward.

Kind regards
Uffe