Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Thu, 31 Aug 2023 11:32:57 +0200 | 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@linaro.org> wrote: > > On Wed, 30 Aug 2023 at 03:20, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > On Tue, 29 Aug 2023 at 17:48, Arnd Bergmann <arnd@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.
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!
| |