All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Olof Johansson <olof@lixom.net>,
	soc@kernel.org, linux-arm-kernel@lists.infradead.org,
	Sebastian Reichel <sebastian.reichel@collabora.com>
Subject: Re: [GIT PULL] ARM: SoC/genpd driver updates for v6.6
Date: Thu, 31 Aug 2023 13:37:03 +0200	[thread overview]
Message-ID: <CAPDyKFpXLj_2HAgyV_VJf+GPQVmxb_iiDe77Q2MY17MDNqy9fA@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0hqWYnkNXVju3U3n-9i8eqtjs197tLLNWv8Qa_N9T=KEw@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Olof Johansson <olof@lixom.net>,
	soc@kernel.org, linux-arm-kernel@lists.infradead.org,
	 Sebastian Reichel <sebastian.reichel@collabora.com>
Subject: Re: [GIT PULL] ARM: SoC/genpd driver updates for v6.6
Date: Thu, 31 Aug 2023 13:37:03 +0200	[thread overview]
Message-ID: <CAPDyKFpXLj_2HAgyV_VJf+GPQVmxb_iiDe77Q2MY17MDNqy9fA@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0hqWYnkNXVju3U3n-9i8eqtjs197tLLNWv8Qa_N9T=KEw@mail.gmail.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-08-31 11:37 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 21:34 [GIT PULL] ARM: SoC/genpd driver updates for v6.6 Ulf Hansson
2023-08-29 21:34 ` Ulf Hansson
2023-08-30  0:18 ` Linus Torvalds
2023-08-30  0:18   ` Linus Torvalds
2023-08-30  0:31   ` Linus Torvalds
2023-08-30  0:31     ` Linus Torvalds
2023-08-30  0:47     ` Arnd Bergmann
2023-08-30  0:47       ` Arnd Bergmann
2023-08-30  1:19       ` Linus Torvalds
2023-08-30  1:19         ` Linus Torvalds
2023-08-30  8:33         ` Ulf Hansson
2023-08-30  8:33           ` Ulf Hansson
2023-08-30 15:07           ` Linus Torvalds
2023-08-30 15:07             ` Linus Torvalds
2023-08-31  0:08             ` Linus Torvalds
2023-08-31  0:08               ` Linus Torvalds
2023-08-31 11:29               ` Ulf Hansson
2023-08-31 11:29                 ` Ulf Hansson
2023-08-31  9:32           ` Rafael J. Wysocki
2023-08-31  9:32             ` Rafael J. Wysocki
2023-08-31 11:37             ` Ulf Hansson [this message]
2023-08-31 11:37               ` Ulf Hansson
2023-08-31 12:58               ` Rafael J. Wysocki
2023-08-31 12:58                 ` Rafael J. Wysocki
2023-09-11  7:52               ` Geert Uytterhoeven
2023-09-11  7:52                 ` Geert Uytterhoeven
2023-09-11 11:28                 ` Ulf Hansson
2023-09-11 11:28                   ` Ulf Hansson
2023-09-11 11:48                   ` Geert Uytterhoeven
2023-09-11 11:48                     ` Geert Uytterhoeven
2023-09-11 12:06                     ` Ulf Hansson
2023-09-11 12:06                       ` Ulf Hansson
2023-09-11 13:06                       ` Geert Uytterhoeven
2023-09-11 13:06                         ` Geert Uytterhoeven
2023-09-11 13:57                         ` Ulf Hansson
2023-09-11 13:57                           ` Ulf Hansson
2023-09-12 13:57                   ` Arnd Bergmann
2023-09-12 13:57                     ` Arnd Bergmann
2023-09-12 22:19                     ` Ulf Hansson
2023-09-12 22:19                       ` Ulf Hansson
2023-08-31  0:10 ` pr-tracker-bot
2023-08-31  0:10   ` pr-tracker-bot
2023-09-26 21:03 ` patchwork-bot+linux-soc
2023-09-26 21:21 ` patchwork-bot+linux-soc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPDyKFpXLj_2HAgyV_VJf+GPQVmxb_iiDe77Q2MY17MDNqy9fA@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=rafael@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=soc@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.