Messages in this thread | | | From | Ulf Hansson <> | Date | Thu, 31 Aug 2023 13:37:03 +0200 | Subject | Re: [GIT PULL] ARM: SoC/genpd driver updates for v6.6 |
| |
On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote: > > 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.
"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
| |