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

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

[Ulf Hansson]

Hi Linus,

Here's a pull-request that introduces the genpd provider subsystem.

Most of the changes have been shared via an immutable branch/tag, which has
been pulled in by Arnd Bergmann into the soc tree. However, as I have also
queued up a couple of additional changes on top, I am sending this pull request
for you.

The changes have been tested in linux-next via
git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git next|fixes

Beyond v6.6-rc1, I am planning to keep sending pull-requests with fixes and new
material for new genpd provider subsystem to you. If you prefer another route,
please let us know.

Kind regards
Ulf Hansson


The following changes since commit 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5:

  Linux 6.5-rc1 (2023-07-09 13:53:13 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git tags/genpd-v6.6

for you to fetch changes up to 5e536362f6ab97f709c07bfda962a7bb036c2563:

  genpd: ti: Use for_each_node_with_property() simplify code logic (2023-08-25 12:04:57 +0200)

----------------------------------------------------------------
This pull-request adds a new subsystem for genpd providers in drivers/genpd
and starts moving some of the corresponding code in there.

We have currently ~60 users of the genpd provider interface, which are
sprinkled across various subsystems. To release some burden from the soc
maintainers (Arnd Bergmann, etc) in particular, but also to gain a better
overall view of what goes on in the area, I will help out with maintenance.

----------------------------------------------------------------
Arnd Bergmann (2):
      soc: starfive: remove stale Makefile entry
      genpd: move owl-sps-helper.c from drivers/soc

Lukas Bulwahn (1):
      MAINTAINERS: adjust file entry in STARFIVE JH71XX PMU CONTROLLER DRIVER

Peng Fan (7):
      genpd: Makefile: build imx
      genpd: imx: relocate scu-pd under genpd
      genpd: imx: scu-pd: enlarge PD range
      genpd: imx: scu-pd: add more PDs
      genpd: imx: scu-pd: do not power off console if no_console_suspend
      genpd: imx: scu-pd: Suppress bind attrs
      genpd: imx: scu-pd: initialize is_off according to HW state

Rob Herring (1):
      genpd: Explicitly include correct DT includes

Ulf Hansson (18):
      genpd: Create a new subsystem directory to host genpd providers
      soc: actions: Move power-domain driver to the genpd dir
      soc: amlogic: Move power-domain drivers to the genpd dir
      soc: apple: Move power-domain driver to the genpd dir
      soc: bcm: Move power-domain drivers to the genpd dir
      soc: imx: Move power-domain drivers to the genpd dir
      soc: mediatek: Move power-domain drivers to the genpd dir
      soc: qcom: Move power-domain drivers to the genpd dir
      soc: renesas: Move power-domain drivers to the genpd dir
      soc: rockchip: Mover power-domain driver to the genpd dir
      soc: samsung: Move power-domain driver to the genpd dir
      soc: starfive: Move the power-domain driver to the genpd dir
      soc: sunxi: Move power-domain driver to the genpd dir
      soc: tegra: Move powergate-bpmp driver to the genpd dir
      soc: ti: Mover power-domain drivers to the genpd dir
      soc: xilinx: Move power-domain driver to the genpd dir
      ARM: ux500: Convert power-domain code into a regular platform driver
      ARM: ux500: Move power-domain driver to the genpd dir

Zhang Zekun (1):
      genpd: ti: Use for_each_node_with_property() simplify code logic

 MAINTAINERS                                        |  22 +++-
 arch/arm/mach-ux500/Makefile                       |   1 -
 arch/arm/mach-ux500/cpu-db8500.c                   |   5 -
 arch/arm/mach-ux500/pm_domains.h                   |  17 ---
 drivers/Makefile                                   |   1 +
 drivers/firmware/imx/Makefile                      |   1 -
 drivers/genpd/Makefile                             |  17 +++
 drivers/genpd/actions/Makefile                     |   3 +
 drivers/{soc => genpd}/actions/owl-sps-helper.c    |   0
 drivers/{soc => genpd}/actions/owl-sps.c           |   0
 drivers/genpd/amlogic/Makefile                     |   4 +
 drivers/{soc => genpd}/amlogic/meson-ee-pwrc.c     |   0
 drivers/{soc => genpd}/amlogic/meson-gx-pwrc-vpu.c |   0
 drivers/{soc => genpd}/amlogic/meson-secure-pwrc.c |   0
 drivers/genpd/apple/Makefile                       |   2 +
 .../apple/pmgr-pwrstate.c}                         |   0
 drivers/genpd/bcm/Makefile                         |   5 +
 drivers/{soc/bcm/bcm63xx => genpd/bcm}/bcm-pmb.c   |   0
 drivers/{soc => genpd}/bcm/bcm2835-power.c         |   0
 .../{soc/bcm/bcm63xx => genpd/bcm}/bcm63xx-power.c |   0
 drivers/{soc => genpd}/bcm/raspberrypi-power.c     |   0
 drivers/genpd/imx/Makefile                         |   8 ++
 drivers/{soc => genpd}/imx/gpc.c                   |   0
 drivers/{soc => genpd}/imx/gpcv2.c                 |   0
 drivers/{soc => genpd}/imx/imx8m-blk-ctrl.c        |   0
 drivers/{soc => genpd}/imx/imx8mp-blk-ctrl.c       |   0
 drivers/{soc => genpd}/imx/imx93-blk-ctrl.c        |   0
 drivers/{soc => genpd}/imx/imx93-pd.c              |   0
 drivers/{firmware => genpd}/imx/scu-pd.c           | 138 +++++++++++++++++++--
 drivers/genpd/mediatek/Makefile                    |   3 +
 .../{soc => genpd}/mediatek/mt6795-pm-domains.h    |   0
 .../{soc => genpd}/mediatek/mt8167-pm-domains.h    |   0
 .../{soc => genpd}/mediatek/mt8173-pm-domains.h    |   0
 .../{soc => genpd}/mediatek/mt8183-pm-domains.h    |   0
 .../{soc => genpd}/mediatek/mt8186-pm-domains.h    |   0
 .../{soc => genpd}/mediatek/mt8188-pm-domains.h    |   0
 .../{soc => genpd}/mediatek/mt8192-pm-domains.h    |   0
 .../{soc => genpd}/mediatek/mt8195-pm-domains.h    |   0
 drivers/{soc => genpd}/mediatek/mtk-pm-domains.c   |   2 +-
 drivers/{soc => genpd}/mediatek/mtk-pm-domains.h   |   0
 drivers/{soc => genpd}/mediatek/mtk-scpsys.c       |   2 +-
 drivers/genpd/qcom/Makefile                        |   4 +
 drivers/{soc => genpd}/qcom/cpr.c                  |   0
 drivers/{soc => genpd}/qcom/rpmhpd.c               |   0
 drivers/{soc => genpd}/qcom/rpmpd.c                |   0
 drivers/genpd/renesas/Makefile                     |  30 +++++
 drivers/{soc => genpd}/renesas/r8a7742-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7743-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7745-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a77470-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a774a1-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a774b1-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a774c0-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a774e1-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a7779-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7790-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7791-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7792-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7794-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7795-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a7796-sysc.c      |   0
 drivers/{soc => genpd}/renesas/r8a77965-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a77970-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a77980-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a77990-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a77995-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a779a0-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a779f0-sysc.c     |   0
 drivers/{soc => genpd}/renesas/r8a779g0-sysc.c     |   0
 drivers/{soc => genpd}/renesas/rcar-gen4-sysc.c    |   0
 drivers/{soc => genpd}/renesas/rcar-gen4-sysc.h    |   0
 drivers/{soc => genpd}/renesas/rcar-sysc.c         |   0
 drivers/{soc => genpd}/renesas/rcar-sysc.h         |   0
 drivers/{soc => genpd}/renesas/rmobile-sysc.c      |   0
 drivers/genpd/rockchip/Makefile                    |   2 +
 .../pm_domains.c => genpd/rockchip/pm-domains.c}   |   0
 drivers/genpd/samsung/Makefile                     |   2 +
 .../samsung/exynos-pm-domains.c}                   |   0
 drivers/genpd/st/Makefile                          |   2 +
 .../genpd/st/ste-ux500-pm-domain.c                 |  25 +++-
 drivers/genpd/starfive/Makefile                    |   2 +
 .../jh71xx_pmu.c => genpd/starfive/jh71xx-pmu.c}   |   0
 drivers/genpd/sunxi/Makefile                       |   2 +
 drivers/{soc => genpd}/sunxi/sun20i-ppu.c          |   2 +-
 drivers/genpd/tegra/Makefile                       |   2 +
 drivers/{soc => genpd}/tegra/powergate-bpmp.c      |   0
 drivers/genpd/ti/Makefile                          |   3 +
 drivers/{soc => genpd}/ti/omap_prm.c               |   0
 drivers/{soc => genpd}/ti/ti_sci_pm_domains.c      |   8 +-
 drivers/genpd/xilinx/Makefile                      |   2 +
 .../xilinx/zynqmp-pm-domains.c}                    |   0
 drivers/soc/Makefile                               |   2 -
 drivers/soc/actions/Makefile                       |   4 -
 drivers/soc/amlogic/Makefile                       |   3 -
 drivers/soc/apple/Makefile                         |   2 -
 drivers/soc/bcm/Kconfig                            |  22 +++-
 drivers/soc/bcm/Makefile                           |   3 -
 drivers/soc/bcm/bcm63xx/Kconfig                    |  21 ----
 drivers/soc/bcm/bcm63xx/Makefile                   |   3 -
 drivers/soc/imx/Makefile                           |   7 +-
 drivers/soc/mediatek/Makefile                      |   2 -
 drivers/soc/qcom/Makefile                          |   3 -
 drivers/soc/renesas/Makefile                       |  27 ----
 drivers/soc/rockchip/Makefile                      |   1 -
 drivers/soc/samsung/Makefile                       |   1 -
 drivers/soc/starfive/Makefile                      |   3 -
 drivers/soc/sunxi/Makefile                         |   1 -
 drivers/soc/tegra/Makefile                         |   1 -
 drivers/soc/ti/Makefile                            |   2 -
 drivers/soc/xilinx/Makefile                        |   1 -
 110 files changed, 288 insertions(+), 138 deletions(-)
 delete mode 100644 arch/arm/mach-ux500/pm_domains.h
 create mode 100644 drivers/genpd/Makefile
 create mode 100644 drivers/genpd/actions/Makefile
 rename drivers/{soc => genpd}/actions/owl-sps-helper.c (100%)
 rename drivers/{soc => genpd}/actions/owl-sps.c (100%)
 create mode 100644 drivers/genpd/amlogic/Makefile
 rename drivers/{soc => genpd}/amlogic/meson-ee-pwrc.c (100%)
 rename drivers/{soc => genpd}/amlogic/meson-gx-pwrc-vpu.c (100%)
 rename drivers/{soc => genpd}/amlogic/meson-secure-pwrc.c (100%)
 create mode 100644 drivers/genpd/apple/Makefile
 rename drivers/{soc/apple/apple-pmgr-pwrstate.c => genpd/apple/pmgr-pwrstate.c} (100%)
 create mode 100644 drivers/genpd/bcm/Makefile
 rename drivers/{soc/bcm/bcm63xx => genpd/bcm}/bcm-pmb.c (100%)
 rename drivers/{soc => genpd}/bcm/bcm2835-power.c (100%)
 rename drivers/{soc/bcm/bcm63xx => genpd/bcm}/bcm63xx-power.c (100%)
 rename drivers/{soc => genpd}/bcm/raspberrypi-power.c (100%)
 create mode 100644 drivers/genpd/imx/Makefile
 rename drivers/{soc => genpd}/imx/gpc.c (100%)
 rename drivers/{soc => genpd}/imx/gpcv2.c (100%)
 rename drivers/{soc => genpd}/imx/imx8m-blk-ctrl.c (100%)
 rename drivers/{soc => genpd}/imx/imx8mp-blk-ctrl.c (100%)
 rename drivers/{soc => genpd}/imx/imx93-blk-ctrl.c (100%)
 rename drivers/{soc => genpd}/imx/imx93-pd.c (100%)
 rename drivers/{firmware => genpd}/imx/scu-pd.c (75%)
 create mode 100644 drivers/genpd/mediatek/Makefile
 rename drivers/{soc => genpd}/mediatek/mt6795-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mt8167-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mt8173-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mt8183-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mt8186-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mt8188-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mt8192-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mt8195-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mtk-pm-domains.c (99%)
 rename drivers/{soc => genpd}/mediatek/mtk-pm-domains.h (100%)
 rename drivers/{soc => genpd}/mediatek/mtk-scpsys.c (99%)
 create mode 100644 drivers/genpd/qcom/Makefile
 rename drivers/{soc => genpd}/qcom/cpr.c (100%)
 rename drivers/{soc => genpd}/qcom/rpmhpd.c (100%)
 rename drivers/{soc => genpd}/qcom/rpmpd.c (100%)
 create mode 100644 drivers/genpd/renesas/Makefile
 rename drivers/{soc => genpd}/renesas/r8a7742-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7743-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7745-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a77470-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a774a1-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a774b1-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a774c0-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a774e1-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7779-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7790-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7791-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7792-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7794-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7795-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a7796-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a77965-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a77970-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a77980-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a77990-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a77995-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a779a0-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a779f0-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/r8a779g0-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/rcar-gen4-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/rcar-gen4-sysc.h (100%)
 rename drivers/{soc => genpd}/renesas/rcar-sysc.c (100%)
 rename drivers/{soc => genpd}/renesas/rcar-sysc.h (100%)
 rename drivers/{soc => genpd}/renesas/rmobile-sysc.c (100%)
 create mode 100644 drivers/genpd/rockchip/Makefile
 rename drivers/{soc/rockchip/pm_domains.c => genpd/rockchip/pm-domains.c} (100%)
 create mode 100644 drivers/genpd/samsung/Makefile
 rename drivers/{soc/samsung/pm_domains.c => genpd/samsung/exynos-pm-domains.c} (100%)
 create mode 100644 drivers/genpd/st/Makefile
 rename arch/arm/mach-ux500/pm_domains.c => drivers/genpd/st/ste-ux500-pm-domain.c (75%)
 create mode 100644 drivers/genpd/starfive/Makefile
 rename drivers/{soc/starfive/jh71xx_pmu.c => genpd/starfive/jh71xx-pmu.c} (100%)
 create mode 100644 drivers/genpd/sunxi/Makefile
 rename drivers/{soc => genpd}/sunxi/sun20i-ppu.c (99%)
 create mode 100644 drivers/genpd/tegra/Makefile
 rename drivers/{soc => genpd}/tegra/powergate-bpmp.c (100%)
 create mode 100644 drivers/genpd/ti/Makefile
 rename drivers/{soc => genpd}/ti/omap_prm.c (100%)
 rename drivers/{soc => genpd}/ti/ti_sci_pm_domains.c (97%)
 create mode 100644 drivers/genpd/xilinx/Makefile
 rename drivers/{soc/xilinx/zynqmp_pm_domains.c => genpd/xilinx/zynqmp-pm-domains.c} (100%)
 delete mode 100644 drivers/soc/actions/Makefile
 delete mode 100644 drivers/soc/bcm/bcm63xx/Kconfig
 delete mode 100644 drivers/soc/bcm/bcm63xx/Makefile
 delete mode 100644 drivers/soc/starfive/Makefile

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

[Linus Torvalds]

On Tue, 29 Aug 2023 at 14:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> Here's a pull-request that introduces the genpd provider subsystem.

I was starting to pull this, and then tried to figure out what the
heck "genpd" is.

Absolutely nothing in the pull request explains what it might be.

Even after actually pulling it, I couldn't really find anything useful.

The closest seems to be the MAINTAINERS file entry that says "GENERIC
PM DOMAIN PROVIDERS", which doesn't actually clarify anything.

Ok, so we have a Kconfig option for PM_GENERIC_DOMAINS, so I looked at
that. It has no help-text, as it is entirely an internal generated
one.

End result: I decided that without any kind of explanation at all,
"genpd" is a completely useless name, and that I don't want to
randomly add a new directory with zero explanation for what the heck
it is.

So I ended up unpulling it, because if I had to google what it is, I
wasn't going to pull it.

Can we please agree that

 (a) five random letters in a row does not documentation make

 (b) if we have a new subsystem, it should damn well have some
explanation for it

And even if you send me a new pull request with an actual explanation
for the term, do we really have to use such a horribly nasty name?

This is not some kind of industry standard shorthand.

Yes, google does find the term "genpd" having been used for a few
years in Linux SoC-land, but are we really so short on diskspace that
we can't use more descriptive names?

Now I look at this disaster area with no documentation, and realize
that it ends up also being part of Arnd's series of SoC pulls.

What a horrible thing this is. Please don't use random letter
combinations that have absolutely no meaning to anybody else, and that
aren't even explained.

               Linus

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

[Linus Torvalds]

On Tue, 29 Aug 2023 at 17:18, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Please don't use random letter combinations that have absolutely
> no meaning to anybody else, and that aren't even explained.

Side note: at least to me, 'gen' is short for 'generate'. Looking at
existing kernel naming, that's how we've used it (lots of examples of
that from different areas).

Do we also have "generic"? Yes. And because 'gen' does not mean
'generic' to anybody, we've typically spelled it out - as in
asm-generic, but also 'sound/soc/generic', or in fact a _lot_ of other
examples.

Because we really aren't that close to running out of letters.

As to the 'pd' part, it actually has a fairly widely used meaning in
the industry, but it tends to be 'power delivery', in the USB-C sense.

So I really find that short-hand actively misleading,

I realize that the SoC code has used that shorthand internally, but
once you expose it like this, I really think you should do a much
better job at naming.

                 Linus

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

[Arnd Bergmann]

On Tue, Aug 29, 2023, at 20:31, Linus Torvalds wrote:
> On Tue, 29 Aug 2023 at 17:18, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Please don't use random letter combinations that have absolutely
>> no meaning to anybody else, and that aren't even explained.
>
> Side note: at least to me, 'gen' is short for 'generate'. Looking at
> existing kernel naming, that's how we've used it (lots of examples of
> that from different areas).
>
> Do we also have "generic"? Yes. And because 'gen' does not mean
> 'generic' to anybody, we've typically spelled it out - as in
> asm-generic, but also 'sound/soc/generic', or in fact a _lot_ of other
> examples.

How about moving it to drivers/power/domain/ instead? We already
have some only loosely connected subsystems under drivers/power
today (reset and supply, both maintained by Sebastian Reichel),
moving it there is probably less confusing.

It looks like there are only a couple of dev_pm_domain providers
that are not of the "genpd" variant, so I think drivers/power/domain
can just be the location for the generic drivers without making
that part of the name.

I don't think we can easily rename the interfaces that have been
in use for the past 12 years, but the directory (and MAINTAINERS
file references to it) could easily be changed with another
patch on top of Ulf's series, without interfering with my
pull requests.

       Arnd

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

[Linus Torvalds]

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

            Linus

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

[Ulf Hansson]

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.

Kind regards
Uffe

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

[Linus Torvalds]

On Wed, 30 Aug 2023 at 01:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> *) 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.

I'm perfectly fine spelling out longer names. "drivers/power/generic"
would be fine to me too, for example.

We can even use names that are longer than 8.3 or - this is heretical
- the 14 characters of the original Unix filesystem. So it could be
something even more descriptive.

I personally always use tab-completion when doing filenames, so at
least to me, longer descriptive names that don't all start with the
same thing are perfectly fine. Others may have more of a typing issue,
so maybe 'generic' is better than 'generic-power-domain'.

(On that note, exactly *because* I use tab-completion, I hate things like this:

   drivers/scsi/scsi_{common,debug,error,ioctl,...}.c

which is entirely redundant in how it just repeats the "scsi" part
pointlessly, causes more typing, _and_ then also causes tab-completion
to not work well. But that's a separate issue).

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

It's not like we have any hard rules. Most of our naming ends up being
pretty random, and everybody thinks that *their* TLA is so obvious,
because they've been using it for ages.

But the "please use common and industry-wide TLA's, write things out
otherwise" is a good rule both when it comes to docs and to filenames.

And that "industry-wide" is pretty important. Not some kind of "local
jargon TLA".

We as kernel people hopefully all know what "TLB" or "VM" means, but
every time somebody sends me something like "x86 SEV" patches, I have
to remind myself, and that's despite me being fairly intimate with
x86.

> Please advise me on how to move forward.

Just to not cause pain during the merge window, I think I'll take the
current trees (eventually - I still have other things pending first),
but I would like

 (a) a new pull request message that actually spells things out and
does *not* use 'genpd' as if it was meaningful so that I can at least
have documentation in the merge window

 (b) a plan to rename that directory to something saner and more descriptive

I don't care deeply about what the exact name in (b) is, but it should
be real words that make sense in context. Or a very standard
abbreviations (ie I consider "misc" to be a word, not an abbreviation,
because I'd rather not see everybody butcher the spelling of it).

                   Linus

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

[Linus Torvalds]

On Wed, 30 Aug 2023 at 08:07, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, 30 Aug 2023 at 01:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > Please advise me on how to move forward.
>
> Just to not cause pain during the merge window, I think I'll take the
> current trees (eventually - I still have other things pending first),

I took the existing pull requests since they were next in my pile.

But I hope we can get the naming sorted out still during this merge
window and not leave it pending for some later time.

               Linus

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@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!

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

[Ulf Hansson]

On Thu, 31 Aug 2023 at 02:08, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, 30 Aug 2023 at 08:07, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Wed, 30 Aug 2023 at 01:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > Please advise me on how to move forward.
> >
> > Just to not cause pain during the merge window, I think I'll take the
> > current trees (eventually - I still have other things pending first),
>
> I took the existing pull requests since they were next in my pile.

Thanks!

>
> But I hope we can get the naming sorted out still during this merge
> window and not leave it pending for some later time.

No problem, I will take care of this. Allow me a few days to send you
another pull-request for this.

Would "drivers/pmdomain" be okay for you, as suggested by Rafael?

Kind regards
Uffe

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

[Ulf Hansson]

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

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

[Rafael J. Wysocki]

On Thu, Aug 31, 2023 at 1:37 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> 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:

[cut]

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

That's fine, it's just a suggestion.

The rationale is that the "core" code is used by the providers, so
putting it next to them would be more convenient in case it needs to
be modified along with the providers, for example.

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

Whichever works for you better.

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

[Geert Uytterhoeven]

Hi Ulf,

On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > 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!

Sounds nice!
All of this lives in <linux/pm_domain.h> (with underscore?) anyway,
and "PM Domains" is the usual naming, as it covers both Power and
Clock Domains.

However, although I am quite familiar with genpd, I am still wondering
what is the meaning of the "generic" part in the name? And what is a
non-generic PM Domain?

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

Which brings me to the final question: what is the upstream path
for changes to drivers/genpd/*/ (or whatever it's gonna be called)?
Before, we sent PRs to (arm-)soc.  Do you expect us to send them to
you? There's usually quite some interaction between drivers/soc/reneas/
and drivers/genpd/renesas (and there are DT binding definitions),
but not more than with e.g. drivers/clk/renesas/.

And I just realized you moved the code and Makefiles to drivers/genpd/,
but not the Kconfig symbols and logic, which still lives under
drivers/soc/.  So resolving that (and the name) is something that
should be resolved sooner rather than later...

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Ulf Hansson]

On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ulf,
>
> On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > 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!
>
> Sounds nice!
> All of this lives in <linux/pm_domain.h> (with underscore?) anyway,
> and "PM Domains" is the usual naming, as it covers both Power and
> Clock Domains.
>
> However, although I am quite familiar with genpd, I am still wondering
> what is the meaning of the "generic" part in the name? And what is a
> non-generic PM Domain?

I guess generic here means "works for most cases".

There are certainly a bunch of other "non-generic", like the ACPI,
pm_clk, OMAP2, etc.

Maybe some of them could be converted to genpd, but that's another story.

>
> > > 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.
>
> Which brings me to the final question: what is the upstream path
> for changes to drivers/genpd/*/ (or whatever it's gonna be called)?
> Before, we sent PRs to (arm-)soc.  Do you expect us to send them to
> you? There's usually quite some interaction between drivers/soc/reneas/
> and drivers/genpd/renesas (and there are DT binding definitions),
> but not more than with e.g. drivers/clk/renesas/.

I would be happy to pick this up and funnel this via my new genpd
tree. As long as it's coupled with changes affecting "genpd
providers", of course.

I can certainly also collect patches directly from the
mailing-list/patch-tracker too. Whatever works for you the best. Of
course, in that case I need your acks before I pick up the relevant
patches.

If we need "immutable" branches, let's discuss that on a case by case basis.

>
> And I just realized you moved the code and Makefiles to drivers/genpd/,
> but not the Kconfig symbols and logic, which still lives under
> drivers/soc/.  So resolving that (and the name) is something that
> should be resolved sooner rather than later...

In regards to the name, I am relying on input from Linus to make a
final decision before I send a patch. In regards to this, I have also
started working on a documentation patch for genpd. It needs some more
polishing before I can send it though.

When it comes to the Kconfig move, I will send out a series for it, this week.

[...]

Kind regards
Uffe

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

[Geert Uytterhoeven]

Hi Ulf,

On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > 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.
> >
> > Which brings me to the final question: what is the upstream path
> > for changes to drivers/genpd/*/ (or whatever it's gonna be called)?
> > Before, we sent PRs to (arm-)soc.  Do you expect us to send them to
> > you? There's usually quite some interaction between drivers/soc/reneas/
> > and drivers/genpd/renesas (and there are DT binding definitions),
> > but not more than with e.g. drivers/clk/renesas/.
>
> I would be happy to pick this up and funnel this via my new genpd
> tree. As long as it's coupled with changes affecting "genpd
> providers", of course.
>
> I can certainly also collect patches directly from the
> mailing-list/patch-tracker too. Whatever works for you the best. Of
> course, in that case I need your acks before I pick up the relevant
> patches.
>
> If we need "immutable" branches, let's discuss that on a case by case basis.

At least for Renesas SoCs, every new SoC comes with a DT binding
definitions file under include/dt-bindings/power/, to be shared by genpd
driver and DTS (the same is true for clocks).  So PRs will work best.

> > And I just realized you moved the code and Makefiles to drivers/genpd/,
> > but not the Kconfig symbols and logic, which still lives under
> > drivers/soc/.  So resolving that (and the name) is something that
> > should be resolved sooner rather than later...
>
> In regards to the name, I am relying on input from Linus to make a
> final decision before I send a patch. In regards to this, I have also
> started working on a documentation patch for genpd. It needs some more
> polishing before I can send it though.
>
> When it comes to the Kconfig move, I will send out a series for it, this week.

OK.
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Ulf Hansson]

On Mon, 11 Sept 2023 at 13:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ulf,
>
> On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > 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.
> > >
> > > Which brings me to the final question: what is the upstream path
> > > for changes to drivers/genpd/*/ (or whatever it's gonna be called)?
> > > Before, we sent PRs to (arm-)soc.  Do you expect us to send them to
> > > you? There's usually quite some interaction between drivers/soc/reneas/
> > > and drivers/genpd/renesas (and there are DT binding definitions),
> > > but not more than with e.g. drivers/clk/renesas/.
> >
> > I would be happy to pick this up and funnel this via my new genpd
> > tree. As long as it's coupled with changes affecting "genpd
> > providers", of course.
> >
> > I can certainly also collect patches directly from the
> > mailing-list/patch-tracker too. Whatever works for you the best. Of
> > course, in that case I need your acks before I pick up the relevant
> > patches.
> >
> > If we need "immutable" branches, let's discuss that on a case by case basis.
>
> At least for Renesas SoCs, every new SoC comes with a DT binding
> definitions file under include/dt-bindings/power/, to be shared by genpd
> driver and DTS (the same is true for clocks).  So PRs will work best.

Good point! And Neil pointed out this too [1].

I am going to host an immutable branch for the dt bindings that you
can pull in. Would that be a better option for you?

[...]

Kind regards
Uffe

[1]
https://lore.kernel.org/lkml/4303c141-30df-4a2b-aba7-f11a98db9941@linaro.org/

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

[Geert Uytterhoeven]

Hi Ulf,

On Mon, Sep 11, 2023 at 2:07 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Mon, 11 Sept 2023 at 13:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > > 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.
> > > >
> > > > Which brings me to the final question: what is the upstream path
> > > > for changes to drivers/genpd/*/ (or whatever it's gonna be called)?
> > > > Before, we sent PRs to (arm-)soc.  Do you expect us to send them to
> > > > you? There's usually quite some interaction between drivers/soc/reneas/
> > > > and drivers/genpd/renesas (and there are DT binding definitions),
> > > > but not more than with e.g. drivers/clk/renesas/.
> > >
> > > I would be happy to pick this up and funnel this via my new genpd
> > > tree. As long as it's coupled with changes affecting "genpd
> > > providers", of course.
> > >
> > > I can certainly also collect patches directly from the
> > > mailing-list/patch-tracker too. Whatever works for you the best. Of
> > > course, in that case I need your acks before I pick up the relevant
> > > patches.
> > >
> > > If we need "immutable" branches, let's discuss that on a case by case basis.
> >
> > At least for Renesas SoCs, every new SoC comes with a DT binding
> > definitions file under include/dt-bindings/power/, to be shared by genpd
> > driver and DTS (the same is true for clocks).  So PRs will work best.
>
> Good point! And Neil pointed out this too [1].
>
> I am going to host an immutable branch for the dt bindings that you
> can pull in. Would that be a better option for you?

Yes, that would work for me, too.
Can I conclude you prefer to take patches over PRs?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Ulf Hansson]

On Mon, 11 Sept 2023 at 15:06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ulf,
>
> On Mon, Sep 11, 2023 at 2:07 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Mon, 11 Sept 2023 at 13:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Mon, Sep 11, 2023 at 1:28 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > On Thu, Aug 31, 2023 at 1:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > > > On Thu, 31 Aug 2023 at 11:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > > > 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.
> > > > >
> > > > > Which brings me to the final question: what is the upstream path
> > > > > for changes to drivers/genpd/*/ (or whatever it's gonna be called)?
> > > > > Before, we sent PRs to (arm-)soc.  Do you expect us to send them to
> > > > > you? There's usually quite some interaction between drivers/soc/reneas/
> > > > > and drivers/genpd/renesas (and there are DT binding definitions),
> > > > > but not more than with e.g. drivers/clk/renesas/.
> > > >
> > > > I would be happy to pick this up and funnel this via my new genpd
> > > > tree. As long as it's coupled with changes affecting "genpd
> > > > providers", of course.
> > > >
> > > > I can certainly also collect patches directly from the
> > > > mailing-list/patch-tracker too. Whatever works for you the best. Of
> > > > course, in that case I need your acks before I pick up the relevant
> > > > patches.
> > > >
> > > > If we need "immutable" branches, let's discuss that on a case by case basis.
> > >
> > > At least for Renesas SoCs, every new SoC comes with a DT binding
> > > definitions file under include/dt-bindings/power/, to be shared by genpd
> > > driver and DTS (the same is true for clocks).  So PRs will work best.
> >
> > Good point! And Neil pointed out this too [1].
> >
> > I am going to host an immutable branch for the dt bindings that you
> > can pull in. Would that be a better option for you?
>
> Yes, that would work for me, too.
> Can I conclude you prefer to take patches over PRs?

In general, yes. But, I am fine with both options, as long as it works
for you too!

Kind regards
Uffe

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

[Arnd Bergmann]

On Mon, Sep 11, 2023, at 13:28, Ulf Hansson wrote:
> On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>
>> And I just realized you moved the code and Makefiles to drivers/genpd/,
>> but not the Kconfig symbols and logic, which still lives under
>> drivers/soc/.  So resolving that (and the name) is something that
>> should be resolved sooner rather than later...
>
> In regards to the name, I am relying on input from Linus to make a
> final decision before I send a patch. In regards to this, I have also
> started working on a documentation patch for genpd. It needs some more
> polishing before I can send it though.

I'm fairly sure that Linus was instead waiting for you to send
a patch or pull request for the rename. Please just pick a name
that you like and that Linus hasn't already objected to and send
it so the rename makes it into -rc2 for others to base on.

If anyone has objections to the new name, you'll find out about
it then, but I think we trust your judgement here.

     Arnd

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

[Ulf Hansson]

On Tue, 12 Sept 2023 at 15:58, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Sep 11, 2023, at 13:28, Ulf Hansson wrote:
> > On Mon, 11 Sept 2023 at 09:52, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>
> >> And I just realized you moved the code and Makefiles to drivers/genpd/,
> >> but not the Kconfig symbols and logic, which still lives under
> >> drivers/soc/.  So resolving that (and the name) is something that
> >> should be resolved sooner rather than later...
> >
> > In regards to the name, I am relying on input from Linus to make a
> > final decision before I send a patch. In regards to this, I have also
> > started working on a documentation patch for genpd. It needs some more
> > polishing before I can send it though.
>
> I'm fairly sure that Linus was instead waiting for you to send
> a patch or pull request for the rename. Please just pick a name
> that you like and that Linus hasn't already objected to and send
> it so the rename makes it into -rc2 for others to base on.
>
> If anyone has objections to the new name, you'll find out about
> it then, but I think we trust your judgement here.
>
>      Arnd

Alright. One can interpret silence differently. :-)

Anyway, I have followed your advice and submitted a patch. I have
queued up a couple of patches for "genpd" already, but it's still easy
to rebase them after a rename, so not a big deal for me at the moment.

Kind regards
Uffe