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

[Ulf Hansson]

On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael at kernel.org> wrote:
>
> On Wed, Aug 30, 2023 at 10:34 AM Ulf Hansson <ulf.hansson at linaro.org> wrote:
> >
> > On Wed, 30 Aug 2023 at 03:20, Linus Torvalds
> > <torvalds at linux-foundation.org> wrote:
> > >
> > > On Tue, 29 Aug 2023 at 17:48, Arnd Bergmann <arnd at arndb.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.

"pmdomain" is probably giving a reasonable good hint of what goes on
in this subsystem. This works fine for me, thanks!

>
> 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.

We could certainly do that, let's discuss it a bit more.

Although, at this point I want to focus on the genpd providers, as to
release some of the burden from arm-soc maintainers.

>
> I can also handle future pull requests for this if that's fine with everyone.

Thanks a lot for your offer! However, if a re-route is preferred (I
think not?), this is probably better suited via arm-soc, as most
changes are going to be arm platform specific.

Kind regards
Uffe