| Message ID | 20240605123850.24857-1-brgl@bgdev.pl (mailing list archive) |
|---|---|
| Headers | show |
| Series | pwrseq: introduce the subsystem and first driver | expand |
On Wed, Jun 5, 2024 at 2:39 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Hi! > > These are the power sequencing patches sent separately after some > improvements suggested by Bjorn Helgaas. I intend to pick them up into a > new branch and maintain the subsystem from now on. I then plan to > provide an immutable tag to the Bluetooth and PCI subsystems so that the > rest of the C changes can be applied. This new branch will then be > directly sent to Linus Torvalds for the next merge window. > > Changelog: > > Since v8: > - split the pwrseq patches out into their own series > - rename incref/decref functions to get/put for consistency > - fix typos > - make it very explicit in docs that arrays of targets and units must be > NULL-terminated > - Link to v8: https://lore.kernel.org/r/20240528-pwrseq-v8-0-d354d52b763c@linaro.org > > Since v7: > - added DTS changes for sm8650-hdk > - added circular dependency detection for pwrseq units > - fixed a KASAN reported use-after-free error in remove path > - improve Kconfig descriptions > - fix typos in bindings and Kconfig > - fixed issues reported by smatch > - fix the unbind path in PCI pwrctl > - lots of minor improvements to the pwrseq core > > Since v6: > - kernel doc fixes > - drop myself from the DT bindings maintainers list for ath12k > - wait until the PCI bridge device is fully added before creating the > PCI pwrctl platform devices for its sub-nodes, otherwise we may see > sysfs and procfs attribute failures (due to duplication, we're > basically trying to probe the same device twice at the same time) > - I kept the regulators for QCA6390's ath11k as required as they only > apply to this specific Qualcomm package > > Since v5: > - unify the approach to modelling the WCN WLAN/BT chips by always exposing > the PMU node on the device tree and making the WLAN and BT nodes become > consumers of its power outputs; this includes a major rework of the DT > sources, bindings and driver code; there's no more a separate PCI > pwrctl driver for WCN7850, instead its power-up sequence was moved > into the pwrseq driver common for all WCN chips > - don't set load_uA from new regulator consumers > - fix reported kerneldoc issues > - drop voltage ranges for PMU outputs from DT > - many minor tweaks and reworks > > v1: Original RFC: > > https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/ > > v2: First real patch series (should have been PATCH v2) adding what I > referred to back then as PCI power sequencing: > > https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/ > > v3: RFC for the DT representation of the PMU supplying the WLAN and BT > modules inside the QCA6391 package (was largely separate from the > series but probably should have been called PATCH or RFC v3): > > https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/ > > v4: Second attempt at the full series with changed scope (introduction of > the pwrseq subsystem, should have been RFC v4) > > https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/ > > v5: Two different ways of handling QCA6390 and WCN7850: > > https://lore.kernel.org/lkml/20240216203215.40870-1-brgl@bgdev.pl/ > > Bartosz Golaszewski (2): > power: sequencing: implement the pwrseq core > power: pwrseq: add a driver for the PMU module on the QCom WCN > chipsets > > MAINTAINERS | 8 + > drivers/power/Kconfig | 1 + > drivers/power/Makefile | 1 + > drivers/power/sequencing/Kconfig | 29 + > drivers/power/sequencing/Makefile | 6 + > drivers/power/sequencing/core.c | 1105 ++++++++++++++++++++ > drivers/power/sequencing/pwrseq-qcom-wcn.c | 336 ++++++ > include/linux/pwrseq/consumer.h | 56 + > include/linux/pwrseq/provider.h | 75 ++ > 9 files changed, 1617 insertions(+) > create mode 100644 drivers/power/sequencing/Kconfig > create mode 100644 drivers/power/sequencing/Makefile > create mode 100644 drivers/power/sequencing/core.c > create mode 100644 drivers/power/sequencing/pwrseq-qcom-wcn.c > create mode 100644 include/linux/pwrseq/consumer.h > create mode 100644 include/linux/pwrseq/provider.h > > -- > 2.40.1 > With no objections, I plan to pick it up into its own pwrseq branch on Wednesday. Review and Ack tags are welcome. Bartosz
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> On Wed, 05 Jun 2024 14:38:48 +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Hi! > > These are the power sequencing patches sent separately after some > improvements suggested by Bjorn Helgaas. I intend to pick them up into a > new branch and maintain the subsystem from now on. I then plan to > provide an immutable tag to the Bluetooth and PCI subsystems so that the > rest of the C changes can be applied. This new branch will then be > directly sent to Linus Torvalds for the next merge window. > > [...] Applied, thanks! [1/2] power: sequencing: implement the pwrseq core commit: 249ebf3f65f8530beb2cbfb91bff1d83ba88d23c [2/2] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets commit: 2f1630f437dff20d02e4b3f07e836f42869128dd Best regards,
Hello: This series was applied to bluetooth/bluetooth-next.git (master) by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: On Wed, 5 Jun 2024 14:38:48 +0200 you wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Hi! > > These are the power sequencing patches sent separately after some > improvements suggested by Bjorn Helgaas. I intend to pick them up into a > new branch and maintain the subsystem from now on. I then plan to > provide an immutable tag to the Bluetooth and PCI subsystems so that the > rest of the C changes can be applied. This new branch will then be > directly sent to Linus Torvalds for the next merge window. > > [...] Here is the summary with links: - [v9,1/2] power: sequencing: implement the pwrseq core https://git.kernel.org/bluetooth/bluetooth-next/c/249ebf3f65f8 - [v9,2/2] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets https://git.kernel.org/bluetooth/bluetooth-next/c/2f1630f437df You are awesome, thank you!
On 2024/6/20 22:30, patchwork-bot+bluetooth@kernel.org wrote: > Hello: > > This series was applied to bluetooth/bluetooth-next.git (master) > by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: > Hi luiz, i am curious why Bartosz is able to merge his changes into bluetooth development tree bluetooth-next directly. 1) his changes should belong to *POWER* scope instead of *Bluetooth* obviously, however, there are *NOT* any SOB tag from either power and bluetooth maintainer. these changes currently only have below Acked-by and Signed-off-by tags: Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> 2) his changes have not merged into linus mainline tree yet. 3) perhaps, it is safer to pull his changes from linus mainline tree when merged than to merge into bluetooth-next firstly. > On Wed, 5 Jun 2024 14:38:48 +0200 you wrote: >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >> >> Hi! >> >> These are the power sequencing patches sent separately after some >> improvements suggested by Bjorn Helgaas. I intend to pick them up into a >> new branch and maintain the subsystem from now on. I then plan to >> provide an immutable tag to the Bluetooth and PCI subsystems so that the >> rest of the C changes can be applied. This new branch will then be >> directly sent to Linus Torvalds for the next merge window. >> >> [...] > > Here is the summary with links: > - [v9,1/2] power: sequencing: implement the pwrseq core > https://git.kernel.org/bluetooth/bluetooth-next/c/249ebf3f65f8 > - [v9,2/2] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > https://git.kernel.org/bluetooth/bluetooth-next/c/2f1630f437df > > You are awesome, thank you!
On Fri, Jun 21, 2024 at 3:14 AM Lk Sii <lk_sii@163.com> wrote: > > > > On 2024/6/20 22:30, patchwork-bot+bluetooth@kernel.org wrote: > > Hello: > > > > This series was applied to bluetooth/bluetooth-next.git (master) > > by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: > > > Hi luiz, > > i am curious why Bartosz is able to merge his changes into bluetooth > development tree bluetooth-next directly. > This conversation is getting progressively worse... > 1) > his changes should belong to *POWER* scope instead of *Bluetooth* > obviously, however, there are *NOT* any SOB tag from either power and > bluetooth maintainer. these changes currently only have below Acked-by > and Signed-off-by tags: > > Acked-by: Krzysztof Kozlowski <krzk@kernel.org> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > It's a new subsystem that has been discussed and reviewed for months and thoroughly tested. Please refer to the cover letter under v8 linked in this thread. It's not related to power-management or power-supply, it's its own thing but IMO the best place to put it is under drivers/power/. And I will maintain it. > 2) > his changes have not merged into linus mainline tree yet. > This is why they are in next! They are scheduled to go in during the upcoming merge window. But since changes belong in multiple trees, we need a cross-tree merge. > 3) > perhaps, it is safer to pull his changes from linus mainline tree when > merged than to merge into bluetooth-next firstly. > It's not safer at all, why would spending less time in next be safer? > > On Wed, 5 Jun 2024 14:38:48 +0200 you wrote: > >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >> > >> Hi! > >> > >> These are the power sequencing patches sent separately after some > >> improvements suggested by Bjorn Helgaas. I intend to pick them up into a > >> new branch and maintain the subsystem from now on. I then plan to > >> provide an immutable tag to the Bluetooth and PCI subsystems so that the > >> rest of the C changes can be applied. This new branch will then be > >> directly sent to Linus Torvalds for the next merge window. > >> > >> [...] > > > > Here is the summary with links: > > - [v9,1/2] power: sequencing: implement the pwrseq core > > https://git.kernel.org/bluetooth/bluetooth-next/c/249ebf3f65f8 > > - [v9,2/2] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > > https://git.kernel.org/bluetooth/bluetooth-next/c/2f1630f437df > > > > You are awesome, thank you! > Why are you top-posting anyway? Bart
On 2024/6/21 14:36, Bartosz Golaszewski wrote: > On Fri, Jun 21, 2024 at 3:14 AM Lk Sii <lk_sii@163.com> wrote: >> >> >> >> On 2024/6/20 22:30, patchwork-bot+bluetooth@kernel.org wrote: >>> Hello: >>> >>> This series was applied to bluetooth/bluetooth-next.git (master) >>> by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: >>> >> Hi luiz, >> >> i am curious why Bartosz is able to merge his changes into bluetooth >> development tree bluetooth-next directly. >> > > This conversation is getting progressively worse... > >> 1) >> his changes should belong to *POWER* scope instead of *Bluetooth* >> obviously, however, there are *NOT* any SOB tag from either power and >> bluetooth maintainer. these changes currently only have below Acked-by >> and Signed-off-by tags: >> >> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >> > > It's a new subsystem that has been discussed and reviewed for months > and thoroughly tested. Please refer to the cover letter under v8 > linked in this thread. It's not related to power-management or > power-supply, it's its own thing but IMO the best place to put it is > under drivers/power/. And I will maintain it. > >> 2) >> his changes have not merged into linus mainline tree yet. >> > > This is why they are in next! They are scheduled to go in during the > upcoming merge window. But since changes belong in multiple trees, we > need a cross-tree merge. > >> 3) >> perhaps, it is safer to pull his changes from linus mainline tree when >> merged than to merge into bluetooth-next firstly. >> > > It's not safer at all, why would spending less time in next be safer? > it seems this patch serial(new subsystem) does not depend on bluetooth and also does not belong to bluetooth subsystem, but have been contained by tip of bluetooth tree. why not follow below merging produce? 1) you send this patch serials to Linus to merge within linus mainline tree 2) luiz then pull your changes from linus mainline tree. >>> On Wed, 5 Jun 2024 14:38:48 +0200 you wrote: >>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>>> >>>> Hi! >>>> >>>> These are the power sequencing patches sent separately after some >>>> improvements suggested by Bjorn Helgaas. I intend to pick them up into a >>>> new branch and maintain the subsystem from now on. I then plan to >>>> provide an immutable tag to the Bluetooth and PCI subsystems so that the >>>> rest of the C changes can be applied. This new branch will then be >>>> directly sent to Linus Torvalds for the next merge window. >>>> >>>> [...] >>> >>> Here is the summary with links: >>> - [v9,1/2] power: sequencing: implement the pwrseq core >>> https://git.kernel.org/bluetooth/bluetooth-next/c/249ebf3f65f8 >>> - [v9,2/2] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets >>> https://git.kernel.org/bluetooth/bluetooth-next/c/2f1630f437df >>> >>> You are awesome, thank you! >> > > Why are you top-posting anyway? > it is caused by my bad mail client settings. thanks for reminder. > Bart
On Fri, Jun 21, 2024 at 11:04 AM Lk Sii <lk_sii@163.com> wrote: > > On 2024/6/21 14:36, Bartosz Golaszewski wrote: > > On Fri, Jun 21, 2024 at 3:14 AM Lk Sii <lk_sii@163.com> wrote: > >> > >> > >> > >> On 2024/6/20 22:30, patchwork-bot+bluetooth@kernel.org wrote: > >>> Hello: > >>> > >>> This series was applied to bluetooth/bluetooth-next.git (master) > >>> by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: > >>> > >> Hi luiz, > >> > >> i am curious why Bartosz is able to merge his changes into bluetooth > >> development tree bluetooth-next directly. > >> > > > > This conversation is getting progressively worse... > > > >> 1) > >> his changes should belong to *POWER* scope instead of *Bluetooth* > >> obviously, however, there are *NOT* any SOB tag from either power and > >> bluetooth maintainer. these changes currently only have below Acked-by > >> and Signed-off-by tags: > >> > >> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> > >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >> > > > > It's a new subsystem that has been discussed and reviewed for months > > and thoroughly tested. Please refer to the cover letter under v8 > > linked in this thread. It's not related to power-management or > > power-supply, it's its own thing but IMO the best place to put it is > > under drivers/power/. And I will maintain it. > > > >> 2) > >> his changes have not merged into linus mainline tree yet. > >> > > > > This is why they are in next! They are scheduled to go in during the > > upcoming merge window. But since changes belong in multiple trees, we > > need a cross-tree merge. > > > >> 3) > >> perhaps, it is safer to pull his changes from linus mainline tree when > >> merged than to merge into bluetooth-next firstly. > >> > > > > It's not safer at all, why would spending less time in next be safer? > > > it seems this patch serial(new subsystem) does not depend on bluetooth > and also does not belong to bluetooth subsystem, but have been contained > by tip of bluetooth tree. > It's the other way around: bluetooth changes (namely the hci_qca driver) depend on the power sequencing changes. > why not follow below merging produce? > 1) you send this patch serials to Linus to merge within linus mainline tree > 2) luiz then pull your changes from linus mainline tree. > I explained this in my previous email. Why would you want these changes to needlessly wait for another release cycle? It makes no sense. It's just a regular cross-tree merge like hundreds that are performed every release. > >>> On Wed, 5 Jun 2024 14:38:48 +0200 you wrote: > >>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >>>> > >>>> Hi! > >>>> > >>>> These are the power sequencing patches sent separately after some > >>>> improvements suggested by Bjorn Helgaas. I intend to pick them up into a > >>>> new branch and maintain the subsystem from now on. I then plan to > >>>> provide an immutable tag to the Bluetooth and PCI subsystems so that the > >>>> rest of the C changes can be applied. This new branch will then be > >>>> directly sent to Linus Torvalds for the next merge window. > >>>> > >>>> [...] > >>> > >>> Here is the summary with links: > >>> - [v9,1/2] power: sequencing: implement the pwrseq core > >>> https://git.kernel.org/bluetooth/bluetooth-next/c/249ebf3f65f8 > >>> - [v9,2/2] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > >>> https://git.kernel.org/bluetooth/bluetooth-next/c/2f1630f437df > >>> > >>> You are awesome, thank you! > >> > > > > Why are you top-posting anyway? > > > it is caused by my bad mail client settings. thanks for reminder. > > Bart > Luiz, Marcel: Am I wasting my time with this person? Is this another Markus Elfring and I unknowingly got pulled into a nonsensical argument? Bart
On 21/06/2024 03:14, Lk Sii wrote: > > > On 2024/6/20 22:30, patchwork-bot+bluetooth@kernel.org wrote: >> Hello: >> >> This series was applied to bluetooth/bluetooth-next.git (master) >> by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: >> > Hi luiz, > > i am curious why Bartosz is able to merge his changes into bluetooth > development tree bluetooth-next directly. > > 1) > his changes should belong to *POWER* scope instead of *Bluetooth* > obviously, however, there are *NOT* any SOB tag from either power and > bluetooth maintainer. these changes currently only have below Acked-by > and Signed-off-by tags: You are trolling us or what? That's a cross tree pull request. > > Acked-by: Krzysztof Kozlowski <krzk@kernel.org> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > 2) > his changes have not merged into linus mainline tree yet. Do you understand the concept of merge windows? > > 3) > perhaps, it is safer to pull his changes from linus mainline tree when > merged than to merge into bluetooth-next firstly. You are joking, right? Best regards, Krzysztof
On 21/06/2024 11:04, Lk Sii wrote: > On 2024/6/21 14:36, Bartosz Golaszewski wrote: >> On Fri, Jun 21, 2024 at 3:14 AM Lk Sii <lk_sii@163.com> wrote: >>> >>> >>> >>> On 2024/6/20 22:30, patchwork-bot+bluetooth@kernel.org wrote: >>>> Hello: >>>> >>>> This series was applied to bluetooth/bluetooth-next.git (master) >>>> by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: >>>> >>> Hi luiz, >>> >>> i am curious why Bartosz is able to merge his changes into bluetooth >>> development tree bluetooth-next directly. >>> >> >> This conversation is getting progressively worse... >> >>> 1) >>> his changes should belong to *POWER* scope instead of *Bluetooth* >>> obviously, however, there are *NOT* any SOB tag from either power and >>> bluetooth maintainer. these changes currently only have below Acked-by >>> and Signed-off-by tags: >>> >>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> >>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>> >> >> It's a new subsystem that has been discussed and reviewed for months >> and thoroughly tested. Please refer to the cover letter under v8 >> linked in this thread. It's not related to power-management or >> power-supply, it's its own thing but IMO the best place to put it is >> under drivers/power/. And I will maintain it. >> >>> 2) >>> his changes have not merged into linus mainline tree yet. >>> >> >> This is why they are in next! They are scheduled to go in during the >> upcoming merge window. But since changes belong in multiple trees, we >> need a cross-tree merge. >> >>> 3) >>> perhaps, it is safer to pull his changes from linus mainline tree when >>> merged than to merge into bluetooth-next firstly. >>> >> >> It's not safer at all, why would spending less time in next be safer? >> > it seems this patch serial(new subsystem) does not depend on bluetooth > and also does not belong to bluetooth subsystem, but have been contained > by tip of bluetooth tree. > > why not follow below merging produce? > 1) you send this patch serials to Linus to merge within linus mainline tree > 2) luiz then pull your changes from linus mainline tree. This is not how Linux kernel development works. Read process documents before interfering with people's work. Best regards, Krzysztof
Hi, On Fri, Jun 21, 2024 at 5:05 AM Lk Sii <lk_sii@163.com> wrote: > > On 2024/6/21 14:36, Bartosz Golaszewski wrote: > > On Fri, Jun 21, 2024 at 3:14 AM Lk Sii <lk_sii@163.com> wrote: > >> > >> > >> > >> On 2024/6/20 22:30, patchwork-bot+bluetooth@kernel.org wrote: > >>> Hello: > >>> > >>> This series was applied to bluetooth/bluetooth-next.git (master) > >>> by Bartosz Golaszewski <bartosz.golaszewski@linaro.org>: > >>> > >> Hi luiz, > >> > >> i am curious why Bartosz is able to merge his changes into bluetooth > >> development tree bluetooth-next directly. > >> > > > > This conversation is getting progressively worse... > > > >> 1) > >> his changes should belong to *POWER* scope instead of *Bluetooth* > >> obviously, however, there are *NOT* any SOB tag from either power and > >> bluetooth maintainer. these changes currently only have below Acked-by > >> and Signed-off-by tags: > >> > >> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> > >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >> > > > > It's a new subsystem that has been discussed and reviewed for months > > and thoroughly tested. Please refer to the cover letter under v8 > > linked in this thread. It's not related to power-management or > > power-supply, it's its own thing but IMO the best place to put it is > > under drivers/power/. And I will maintain it. > > > >> 2) > >> his changes have not merged into linus mainline tree yet. > >> > > > > This is why they are in next! They are scheduled to go in during the > > upcoming merge window. But since changes belong in multiple trees, we > > need a cross-tree merge. > > > >> 3) > >> perhaps, it is safer to pull his changes from linus mainline tree when > >> merged than to merge into bluetooth-next firstly. > >> > > > > It's not safer at all, why would spending less time in next be safer? > > > it seems this patch serial(new subsystem) does not depend on bluetooth > and also does not belong to bluetooth subsystem, but have been contained > by tip of bluetooth tree. > > why not follow below merging produce? > 1) you send this patch serials to Linus to merge within linus mainline tree > 2) luiz then pull your changes from linus mainline tree. This was discussed already, but in case you didn't follow if we need to incorporate changes earlier we can't really wait the merge window for the changes to be merged first into the Linus tree. Anyway Bartosz is the maintainer of Power Sequence subsystem, and several others drivers, so I think it is safe to trust his judgment here.
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Hi! These are the power sequencing patches sent separately after some improvements suggested by Bjorn Helgaas. I intend to pick them up into a new branch and maintain the subsystem from now on. I then plan to provide an immutable tag to the Bluetooth and PCI subsystems so that the rest of the C changes can be applied. This new branch will then be directly sent to Linus Torvalds for the next merge window. Changelog: Since v8: - split the pwrseq patches out into their own series - rename incref/decref functions to get/put for consistency - fix typos - make it very explicit in docs that arrays of targets and units must be NULL-terminated - Link to v8: https://lore.kernel.org/r/20240528-pwrseq-v8-0-d354d52b763c@linaro.org Since v7: - added DTS changes for sm8650-hdk - added circular dependency detection for pwrseq units - fixed a KASAN reported use-after-free error in remove path - improve Kconfig descriptions - fix typos in bindings and Kconfig - fixed issues reported by smatch - fix the unbind path in PCI pwrctl - lots of minor improvements to the pwrseq core Since v6: - kernel doc fixes - drop myself from the DT bindings maintainers list for ath12k - wait until the PCI bridge device is fully added before creating the PCI pwrctl platform devices for its sub-nodes, otherwise we may see sysfs and procfs attribute failures (due to duplication, we're basically trying to probe the same device twice at the same time) - I kept the regulators for QCA6390's ath11k as required as they only apply to this specific Qualcomm package Since v5: - unify the approach to modelling the WCN WLAN/BT chips by always exposing the PMU node on the device tree and making the WLAN and BT nodes become consumers of its power outputs; this includes a major rework of the DT sources, bindings and driver code; there's no more a separate PCI pwrctl driver for WCN7850, instead its power-up sequence was moved into the pwrseq driver common for all WCN chips - don't set load_uA from new regulator consumers - fix reported kerneldoc issues - drop voltage ranges for PMU outputs from DT - many minor tweaks and reworks v1: Original RFC: https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/ v2: First real patch series (should have been PATCH v2) adding what I referred to back then as PCI power sequencing: https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/ v3: RFC for the DT representation of the PMU supplying the WLAN and BT modules inside the QCA6391 package (was largely separate from the series but probably should have been called PATCH or RFC v3): https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/ v4: Second attempt at the full series with changed scope (introduction of the pwrseq subsystem, should have been RFC v4) https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/ v5: Two different ways of handling QCA6390 and WCN7850: https://lore.kernel.org/lkml/20240216203215.40870-1-brgl@bgdev.pl/ Bartosz Golaszewski (2): power: sequencing: implement the pwrseq core power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets MAINTAINERS | 8 + drivers/power/Kconfig | 1 + drivers/power/Makefile | 1 + drivers/power/sequencing/Kconfig | 29 + drivers/power/sequencing/Makefile | 6 + drivers/power/sequencing/core.c | 1105 ++++++++++++++++++++ drivers/power/sequencing/pwrseq-qcom-wcn.c | 336 ++++++ include/linux/pwrseq/consumer.h | 56 + include/linux/pwrseq/provider.h | 75 ++ 9 files changed, 1617 insertions(+) create mode 100644 drivers/power/sequencing/Kconfig create mode 100644 drivers/power/sequencing/Makefile create mode 100644 drivers/power/sequencing/core.c create mode 100644 drivers/power/sequencing/pwrseq-qcom-wcn.c create mode 100644 include/linux/pwrseq/consumer.h create mode 100644 include/linux/pwrseq/provider.h