[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hqWYnkNXVju3U3n-9i8eqtjs197tLLNWv8Qa_N9T=KEw@mail.gmail.com>
Date: Thu, 31 Aug 2023 11:32:57 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>, 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>
Subject: Re: [GIT PULL] ARM: SoC/genpd driver updates for v6.6
On Wed, Aug 30, 2023 at 10:34 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> 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.
If I may suggest something, I would call this "pmdomain" instead of
"genpd". I don't think that /drivers/power/ is a particularly
suitable location for it, because it doesn't really have much to do
with power supplies and more to do with device PM.
Also, I would move drivers/base/power/domain.c to drivers/pmdomain/
(and rename it to something like core.c), because it would be a better
location for that fiile IMO.
I can also handle future pull requests for this if that's fine with everyone.
Cheers!
Powered by blists - more mailing lists