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

[Rafael J. Wysocki]

On Wed, Aug 30, 2023 at 10:34 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>
> On Wed, 30 Aug 2023 at 03:20, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, 29 Aug 2023 at 17:48, Arnd Bergmann <arnd@xxxxxxxx> 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!