| Message ID | 20230829213441.310655-1-ulf.hansson@linaro.org (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
| Series | [GIT,PULL] ARM: SoC/genpd driver updates for v6.6 | expand |
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
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
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
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
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
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
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
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!
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
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
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.
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
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
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
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/
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
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
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
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
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