mbox series

[v9,0/2] pwrseq: introduce the subsystem and first driver

Message ID 20240605123850.24857-1-brgl@bgdev.pl
Headers show
Series pwrseq: introduce the subsystem and first driver | expand

Message

Bartosz Golaszewski June 5, 2024, 12:38 p.m. UTC
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

Comments

Bartosz Golaszewski June 10, 2024, 2:07 p.m. UTC | #1
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
Bartosz Golaszewski June 12, 2024, 7:24 a.m. UTC | #2
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,
Lk Sii June 21, 2024, 1:14 a.m. UTC | #3
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!
Bartosz Golaszewski June 21, 2024, 6:36 a.m. UTC | #4
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
Lk Sii June 21, 2024, 9:04 a.m. UTC | #5
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
Bartosz Golaszewski June 21, 2024, 1:23 p.m. UTC | #6
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
Krzysztof Kozlowski June 21, 2024, 2:50 p.m. UTC | #7
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
Krzysztof Kozlowski June 21, 2024, 2:51 p.m. UTC | #8
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
Luiz Augusto von Dentz June 24, 2024, 3:30 p.m. UTC | #9
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.