| Message ID | 20240612075829.18241-1-brgl@bgdev.pl |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1 | expand |
Hi Bartosz, On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Hi Marcel, Luiz, > > Please pull the following power sequencing changes into the Bluetooth tree > before applying the hci_qca patches I sent separately. > > Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ > > The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: > > Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 > > for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) > > ---------------------------------------------------------------- > Initial implementation of the power sequencing subsystem for linux v6.11 > > ---------------------------------------------------------------- > Bartosz Golaszewski (2): > power: sequencing: implement the pwrseq core > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets Is this intended to go via bluetooth-next or it is just because it is a dependency of another set? You could perhaps send another set including these changes to avoid having CI failing to compile. > 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
Hi Bartosz, On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Bartosz, > > > > On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > Hi Marcel, Luiz, > > > > > > Please pull the following power sequencing changes into the Bluetooth tree > > > before applying the hci_qca patches I sent separately. > > > > > > Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ > > > > > > The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: > > > > > > Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) > > > > > > are available in the Git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 > > > > > > for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) > > > > > > ---------------------------------------------------------------- > > > Initial implementation of the power sequencing subsystem for linux v6.11 > > > > > > ---------------------------------------------------------------- > > > Bartosz Golaszewski (2): > > > power: sequencing: implement the pwrseq core > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > > > > Is this intended to go via bluetooth-next or it is just because it is > > a dependency of another set? You could perhaps send another set > > including these changes to avoid having CI failing to compile. > > > > No, the pwrseq stuff is intended to go through its own pwrseq tree > hence the PR. We cannot have these commits in next twice. Not following you here, why can't we have these commits on different next trees? If that is the case how can we apply the bluetooth specific ones without causing build regressions?
On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Bartosz, > > > > On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > Hi Bartosz, > > > > > > > > On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > > > Hi Marcel, Luiz, > > > > > > > > > > Please pull the following power sequencing changes into the Bluetooth tree > > > > > before applying the hci_qca patches I sent separately. > > > > > > > > > > Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ > > > > > > > > > > The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: > > > > > > > > > > Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 > > > > > > > > > > for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: > > > > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) > > > > > > > > > > ---------------------------------------------------------------- > > > > > Initial implementation of the power sequencing subsystem for linux v6.11 > > > > > > > > > > ---------------------------------------------------------------- > > > > > Bartosz Golaszewski (2): > > > > > power: sequencing: implement the pwrseq core > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > > > > > > > > Is this intended to go via bluetooth-next or it is just because it is > > > > a dependency of another set? You could perhaps send another set > > > > including these changes to avoid having CI failing to compile. > > > > > > > > > > No, the pwrseq stuff is intended to go through its own pwrseq tree > > > hence the PR. We cannot have these commits in next twice. > > > > Not following you here, why can't we have these commits on different > > next trees? If that is the case how can we apply the bluetooth > > specific ones without causing build regressions? > > > > We can't have the same commits twice with different hashes in next > because Stephen Rothwell will yell at us both. > > Just pull the tag I provided and then apply the Bluetooth specific > changes I sent on top of it. When sending to Linus Torvalds/David > Miller (not sure how your tree gets upstream) mention that you pulled > in the pwrseq changes in your PR cover letter. > > Bart Gentle ping. Bart
Hi Bartosz, On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz > > <luiz.dentz@gmail.com> wrote: > > > > > > Hi Bartosz, > > > > > > On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz > > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > > > Hi Bartosz, > > > > > > > > > > On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > > > > > Hi Marcel, Luiz, > > > > > > > > > > > > Please pull the following power sequencing changes into the Bluetooth tree > > > > > > before applying the hci_qca patches I sent separately. > > > > > > > > > > > > Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ > > > > > > > > > > > > The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: > > > > > > > > > > > > Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 > > > > > > > > > > > > for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: > > > > > > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > Initial implementation of the power sequencing subsystem for linux v6.11 > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > Bartosz Golaszewski (2): > > > > > > power: sequencing: implement the pwrseq core > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > > > > > > > > > > Is this intended to go via bluetooth-next or it is just because it is > > > > > a dependency of another set? You could perhaps send another set > > > > > including these changes to avoid having CI failing to compile. > > > > > > > > > > > > > No, the pwrseq stuff is intended to go through its own pwrseq tree > > > > hence the PR. We cannot have these commits in next twice. > > > > > > Not following you here, why can't we have these commits on different > > > next trees? If that is the case how can we apply the bluetooth > > > specific ones without causing build regressions? > > > > > > > We can't have the same commits twice with different hashes in next > > because Stephen Rothwell will yell at us both. > > > > Just pull the tag I provided and then apply the Bluetooth specific > > changes I sent on top of it. When sending to Linus Torvalds/David > > Miller (not sure how your tree gets upstream) mention that you pulled > > in the pwrseq changes in your PR cover letter. By pull the tag you mean using merge commits to merge the trees and not rebase, doesn't that lock us down to only doing merge commits rather than rebases later on? I have never used merge commits before. There is some documentation around it that suggests not to use merges: 'While merges from downstream are common and unremarkable, merges from other trees tend to be a red flag when it comes time to push a branch upstream. Such merges need to be carefully thought about and well justified, or there’s a good chance that a subsequent pull request will be rejected.' https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees But then looking forward in that documentation it says: 'Another reason for doing merges of upstream or another subsystem tree is to resolve dependencies. These dependency issues do happen at times, and sometimes a cross-merge with another tree is the best way to resolve them; as always, in such situations, the merge commit should explain why the merge has been done. Take a moment to do it right; people will read those changelogs.' So I guess that is the reason we want to merge the trees, but what I'm really looking forward to is for the 'proper' commands and commit message to use to make sure we don't have problems in the future. > > Bart > > Gentle ping. > > Bart
On Wed, Jun 19, 2024 at 8:59 PM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Bartosz, > > On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > Hi Bartosz, > > > > > > > > On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz > > > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > > > > > Hi Bartosz, > > > > > > > > > > > > On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > > > > > > > Hi Marcel, Luiz, > > > > > > > > > > > > > > Please pull the following power sequencing changes into the Bluetooth tree > > > > > > > before applying the hci_qca patches I sent separately. > > > > > > > > > > > > > > Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ > > > > > > > > > > > > > > The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: > > > > > > > > > > > > > > Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) > > > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 > > > > > > > > > > > > > > for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: > > > > > > > > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > Initial implementation of the power sequencing subsystem for linux v6.11 > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > Bartosz Golaszewski (2): > > > > > > > power: sequencing: implement the pwrseq core > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > > > > > > > > > > > > Is this intended to go via bluetooth-next or it is just because it is > > > > > > a dependency of another set? You could perhaps send another set > > > > > > including these changes to avoid having CI failing to compile. > > > > > > > > > > > > > > > > No, the pwrseq stuff is intended to go through its own pwrseq tree > > > > > hence the PR. We cannot have these commits in next twice. > > > > > > > > Not following you here, why can't we have these commits on different > > > > next trees? If that is the case how can we apply the bluetooth > > > > specific ones without causing build regressions? > > > > > > > > > > We can't have the same commits twice with different hashes in next > > > because Stephen Rothwell will yell at us both. > > > > > > Just pull the tag I provided and then apply the Bluetooth specific > > > changes I sent on top of it. When sending to Linus Torvalds/David > > > Miller (not sure how your tree gets upstream) mention that you pulled > > > in the pwrseq changes in your PR cover letter. > > By pull the tag you mean using merge commits to merge the trees and > not rebase, doesn't that lock us down to only doing merge commits > rather than rebases later on? I have never used merge commits before. > There is some documentation around it that suggests not to use merges: > > 'While merges from downstream are common and unremarkable, merges from > other trees tend to be a red flag when it comes time to push a branch > upstream. Such merges need to be carefully thought about and well > justified, or there’s a good chance that a subsequent pull request > will be rejected.' > https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees > > But then looking forward in that documentation it says: > > 'Another reason for doing merges of upstream or another subsystem tree > is to resolve dependencies. These dependency issues do happen at > times, and sometimes a cross-merge with another tree is the best way > to resolve them; as always, in such situations, the merge commit > should explain why the merge has been done. Take a moment to do it > right; people will read those changelogs.' > > So I guess that is the reason we want to merge the trees, but what I'm > really looking forward to is for the 'proper' commands and commit > message to use to make sure we don't have problems in the future. > You shouldn't really need to rebase your branch very often anyway. This is really for special cases. But even then you can always use: `git rebase --rebase-merges` to keep the merge commits. The commands you want to run are: git pull git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 git am or b4 shazam on the patches targeting the Bluetooth subsystem git push That's really it, there's not much else to it. Bart > > > Bart > > > > Gentle ping. > > > > Bart > > > > -- > Luiz Augusto von Dentz
On 19/06/2024 20:59, Luiz Augusto von Dentz wrote: > Hi Bartosz, > > On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >> >> On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>> >>> On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz >>> <luiz.dentz@gmail.com> wrote: >>>> >>>> Hi Bartosz, >>>> >>>> On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>> >>>>> On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz >>>>> <luiz.dentz@gmail.com> wrote: >>>>>> >>>>>> Hi Bartosz, >>>>>> >>>>>> On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>>>> >>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>>>>>> >>>>>>> Hi Marcel, Luiz, >>>>>>> >>>>>>> Please pull the following power sequencing changes into the Bluetooth tree >>>>>>> before applying the hci_qca patches I sent separately. >>>>>>> >>>>>>> Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ >>>>>>> >>>>>>> The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: >>>>>>> >>>>>>> Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) >>>>>>> >>>>>>> are available in the Git repository at: >>>>>>> >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 >>>>>>> >>>>>>> for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: >>>>>>> >>>>>>> power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> Initial implementation of the power sequencing subsystem for linux v6.11 >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> Bartosz Golaszewski (2): >>>>>>> power: sequencing: implement the pwrseq core >>>>>>> power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets >>>>>> >>>>>> Is this intended to go via bluetooth-next or it is just because it is >>>>>> a dependency of another set? You could perhaps send another set >>>>>> including these changes to avoid having CI failing to compile. >>>>>> >>>>> >>>>> No, the pwrseq stuff is intended to go through its own pwrseq tree >>>>> hence the PR. We cannot have these commits in next twice. >>>> >>>> Not following you here, why can't we have these commits on different >>>> next trees? If that is the case how can we apply the bluetooth >>>> specific ones without causing build regressions? >>>> >>> >>> We can't have the same commits twice with different hashes in next >>> because Stephen Rothwell will yell at us both. >>> >>> Just pull the tag I provided and then apply the Bluetooth specific >>> changes I sent on top of it. When sending to Linus Torvalds/David >>> Miller (not sure how your tree gets upstream) mention that you pulled >>> in the pwrseq changes in your PR cover letter. > > By pull the tag you mean using merge commits to merge the trees and > not rebase, doesn't that lock us down to only doing merge commits > rather than rebases later on? I have never used merge commits before. > There is some documentation around it that suggests not to use merges: > > 'While merges from downstream are common and unremarkable, merges from > other trees tend to be a red flag when it comes time to push a branch You can rebase, although in a non-automatic way only once you pulled stable tag/branch from other maintainer but why do you rebase public branches anyway? That's allowed by linux-next rules but a bit of pain for everyone so should be avoided. > upstream. Such merges need to be carefully thought about and well > justified, or there’s a good chance that a subsequent pull request > will be rejected.' > https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees And the merge request is justified here. Which part of justification is missing? > > But then looking forward in that documentation it says: > > 'Another reason for doing merges of upstream or another subsystem tree > is to resolve dependencies. These dependency issues do happen at > times, and sometimes a cross-merge with another tree is the best way > to resolve them; as always, in such situations, the merge commit > should explain why the merge has been done. Take a moment to do it > right; people will read those changelogs.' > > So I guess that is the reason we want to merge the trees, but what I'm > really looking forward to is for the 'proper' commands and commit > message to use to make sure we don't have problems in the future. Cross tree merges are something incredibly common for Linux kernel thus I do not understand what is the issue here. Of course obvious rules apply: you cannot rebase such branch, because you would rewrite the merged commits. But that's easy to solve by keeping it in topic branch and then you can perform rebases on own commits and re-merging the tag from Bartosz. Best regards, Krzysztof
Hi Bartosz, On Wed, Jun 19, 2024 at 3:40 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Wed, Jun 19, 2024 at 8:59 PM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Bartosz, > > > > On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz > > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > > > Hi Bartosz, > > > > > > > > > > On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > > > On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz > > > > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > > > > > > > Hi Bartosz, > > > > > > > > > > > > > > On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > > > > > > > > > Hi Marcel, Luiz, > > > > > > > > > > > > > > > > Please pull the following power sequencing changes into the Bluetooth tree > > > > > > > > before applying the hci_qca patches I sent separately. > > > > > > > > > > > > > > > > Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ > > > > > > > > > > > > > > > > The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: > > > > > > > > > > > > > > > > Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) > > > > > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 > > > > > > > > > > > > > > > > for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: > > > > > > > > > > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > Initial implementation of the power sequencing subsystem for linux v6.11 > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > Bartosz Golaszewski (2): > > > > > > > > power: sequencing: implement the pwrseq core > > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > > > > > > > > > > > > > > Is this intended to go via bluetooth-next or it is just because it is > > > > > > > a dependency of another set? You could perhaps send another set > > > > > > > including these changes to avoid having CI failing to compile. > > > > > > > > > > > > > > > > > > > No, the pwrseq stuff is intended to go through its own pwrseq tree > > > > > > hence the PR. We cannot have these commits in next twice. > > > > > > > > > > Not following you here, why can't we have these commits on different > > > > > next trees? If that is the case how can we apply the bluetooth > > > > > specific ones without causing build regressions? > > > > > > > > > > > > > We can't have the same commits twice with different hashes in next > > > > because Stephen Rothwell will yell at us both. > > > > > > > > Just pull the tag I provided and then apply the Bluetooth specific > > > > changes I sent on top of it. When sending to Linus Torvalds/David > > > > Miller (not sure how your tree gets upstream) mention that you pulled > > > > in the pwrseq changes in your PR cover letter. > > > > By pull the tag you mean using merge commits to merge the trees and > > not rebase, doesn't that lock us down to only doing merge commits > > rather than rebases later on? I have never used merge commits before. > > There is some documentation around it that suggests not to use merges: > > > > 'While merges from downstream are common and unremarkable, merges from > > other trees tend to be a red flag when it comes time to push a branch > > upstream. Such merges need to be carefully thought about and well > > justified, or there’s a good chance that a subsequent pull request > > will be rejected.' > > https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees > > > > But then looking forward in that documentation it says: > > > > 'Another reason for doing merges of upstream or another subsystem tree > > is to resolve dependencies. These dependency issues do happen at > > times, and sometimes a cross-merge with another tree is the best way > > to resolve them; as always, in such situations, the merge commit > > should explain why the merge has been done. Take a moment to do it > > right; people will read those changelogs.' > > > > So I guess that is the reason we want to merge the trees, but what I'm > > really looking forward to is for the 'proper' commands and commit > > message to use to make sure we don't have problems in the future. > > > > You shouldn't really need to rebase your branch very often anyway. > This is really for special cases. But even then you can always use: > `git rebase --rebase-merges` to keep the merge commits. > > The commands you want to run are: > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git > tags/pwrseq-initial-for-v6.11 > git am or b4 shazam on the patches targeting the Bluetooth subsystem > git push Not quite working for me:
On 20/06/2024 16:16, Luiz Augusto von Dentz wrote: > Hi Bartosz, > > On Wed, Jun 19, 2024 at 3:40 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >> >> On Wed, Jun 19, 2024 at 8:59 PM Luiz Augusto von Dentz >> <luiz.dentz@gmail.com> wrote: >>> >>> Hi Bartosz, >>> >>> On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>> >>>> On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>> >>>>> On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz >>>>> <luiz.dentz@gmail.com> wrote: >>>>>> >>>>>> Hi Bartosz, >>>>>> >>>>>> On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>>>> >>>>>>> On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz >>>>>>> <luiz.dentz@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Bartosz, >>>>>>>> >>>>>>>> On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>>>>>> >>>>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>>>>>>>> >>>>>>>>> Hi Marcel, Luiz, >>>>>>>>> >>>>>>>>> Please pull the following power sequencing changes into the Bluetooth tree >>>>>>>>> before applying the hci_qca patches I sent separately. >>>>>>>>> >>>>>>>>> Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ >>>>>>>>> >>>>>>>>> The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: >>>>>>>>> >>>>>>>>> Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) >>>>>>>>> >>>>>>>>> are available in the Git repository at: >>>>>>>>> >>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 >>>>>>>>> >>>>>>>>> for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: >>>>>>>>> >>>>>>>>> power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------- >>>>>>>>> Initial implementation of the power sequencing subsystem for linux v6.11 >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------- >>>>>>>>> Bartosz Golaszewski (2): >>>>>>>>> power: sequencing: implement the pwrseq core >>>>>>>>> power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets >>>>>>>> >>>>>>>> Is this intended to go via bluetooth-next or it is just because it is >>>>>>>> a dependency of another set? You could perhaps send another set >>>>>>>> including these changes to avoid having CI failing to compile. >>>>>>>> >>>>>>> >>>>>>> No, the pwrseq stuff is intended to go through its own pwrseq tree >>>>>>> hence the PR. We cannot have these commits in next twice. >>>>>> >>>>>> Not following you here, why can't we have these commits on different >>>>>> next trees? If that is the case how can we apply the bluetooth >>>>>> specific ones without causing build regressions? >>>>>> >>>>> >>>>> We can't have the same commits twice with different hashes in next >>>>> because Stephen Rothwell will yell at us both. >>>>> >>>>> Just pull the tag I provided and then apply the Bluetooth specific >>>>> changes I sent on top of it. When sending to Linus Torvalds/David >>>>> Miller (not sure how your tree gets upstream) mention that you pulled >>>>> in the pwrseq changes in your PR cover letter. >>> >>> By pull the tag you mean using merge commits to merge the trees and >>> not rebase, doesn't that lock us down to only doing merge commits >>> rather than rebases later on? I have never used merge commits before. >>> There is some documentation around it that suggests not to use merges: >>> >>> 'While merges from downstream are common and unremarkable, merges from >>> other trees tend to be a red flag when it comes time to push a branch >>> upstream. Such merges need to be carefully thought about and well >>> justified, or there’s a good chance that a subsequent pull request >>> will be rejected.' >>> https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees >>> >>> But then looking forward in that documentation it says: >>> >>> 'Another reason for doing merges of upstream or another subsystem tree >>> is to resolve dependencies. These dependency issues do happen at >>> times, and sometimes a cross-merge with another tree is the best way >>> to resolve them; as always, in such situations, the merge commit >>> should explain why the merge has been done. Take a moment to do it >>> right; people will read those changelogs.' >>> >>> So I guess that is the reason we want to merge the trees, but what I'm >>> really looking forward to is for the 'proper' commands and commit >>> message to use to make sure we don't have problems in the future. >>> >> >> You shouldn't really need to rebase your branch very often anyway. >> This is really for special cases. But even then you can always use: >> `git rebase --rebase-merges` to keep the merge commits. >> >> The commands you want to run are: >> >> git pull git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git >> tags/pwrseq-initial-for-v6.11 >> git am or b4 shazam on the patches targeting the Bluetooth subsystem >> git push > > Not quite working for me: > > From git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux > * tag pwrseq-initial-for-v6.11 -> FETCH_HEAD > hint: You have divergent branches and need to specify how to reconcile them. > hint: You can do so by running one of the following commands sometime before > hint: your next pull: > hint: > hint: git config pull.rebase false # merge > hint: git config pull.rebase true # rebase > hint: git config pull.ff only # fast-forward only > hint: > hint: You can replace "git config" with "git config --global" to set a default > hint: preference for all repositories. You can also pass --rebase, --no-rebase, > hint: or --ff-only on the command line to override the configured default per > hint: invocation. > fatal: Need to specify how to reconcile divergent branches. > > Perhaps I need to configure pull.rebase to be false? tag goes as last argument. (git help pull) Best regards, Krzysztof
Hi, On Thu, Jun 20, 2024 at 10:16 AM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Bartosz, > > On Wed, Jun 19, 2024 at 3:40 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Wed, Jun 19, 2024 at 8:59 PM Luiz Augusto von Dentz > > <luiz.dentz@gmail.com> wrote: > > > > > > Hi Bartosz, > > > > > > On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz > > > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > > > > > Hi Bartosz, > > > > > > > > > > > > On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > > > > > On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz > > > > > > > <luiz.dentz@gmail.com> wrote: > > > > > > > > > > > > > > > > Hi Bartosz, > > > > > > > > > > > > > > > > On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > > > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > > > > > > > > > > > Hi Marcel, Luiz, > > > > > > > > > > > > > > > > > > Please pull the following power sequencing changes into the Bluetooth tree > > > > > > > > > before applying the hci_qca patches I sent separately. > > > > > > > > > > > > > > > > > > Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ > > > > > > > > > > > > > > > > > > The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: > > > > > > > > > > > > > > > > > > Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) > > > > > > > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 > > > > > > > > > > > > > > > > > > for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: > > > > > > > > > > > > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > Initial implementation of the power sequencing subsystem for linux v6.11 > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > > > > Bartosz Golaszewski (2): > > > > > > > > > power: sequencing: implement the pwrseq core > > > > > > > > > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > > > > > > > > > > > > > > > > Is this intended to go via bluetooth-next or it is just because it is > > > > > > > > a dependency of another set? You could perhaps send another set > > > > > > > > including these changes to avoid having CI failing to compile. > > > > > > > > > > > > > > > > > > > > > > No, the pwrseq stuff is intended to go through its own pwrseq tree > > > > > > > hence the PR. We cannot have these commits in next twice. > > > > > > > > > > > > Not following you here, why can't we have these commits on different > > > > > > next trees? If that is the case how can we apply the bluetooth > > > > > > specific ones without causing build regressions? > > > > > > > > > > > > > > > > We can't have the same commits twice with different hashes in next > > > > > because Stephen Rothwell will yell at us both. > > > > > > > > > > Just pull the tag I provided and then apply the Bluetooth specific > > > > > changes I sent on top of it. When sending to Linus Torvalds/David > > > > > Miller (not sure how your tree gets upstream) mention that you pulled > > > > > in the pwrseq changes in your PR cover letter. > > > > > > By pull the tag you mean using merge commits to merge the trees and > > > not rebase, doesn't that lock us down to only doing merge commits > > > rather than rebases later on? I have never used merge commits before. > > > There is some documentation around it that suggests not to use merges: > > > > > > 'While merges from downstream are common and unremarkable, merges from > > > other trees tend to be a red flag when it comes time to push a branch > > > upstream. Such merges need to be carefully thought about and well > > > justified, or there’s a good chance that a subsequent pull request > > > will be rejected.' > > > https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees > > > > > > But then looking forward in that documentation it says: > > > > > > 'Another reason for doing merges of upstream or another subsystem tree > > > is to resolve dependencies. These dependency issues do happen at > > > times, and sometimes a cross-merge with another tree is the best way > > > to resolve them; as always, in such situations, the merge commit > > > should explain why the merge has been done. Take a moment to do it > > > right; people will read those changelogs.' > > > > > > So I guess that is the reason we want to merge the trees, but what I'm > > > really looking forward to is for the 'proper' commands and commit > > > message to use to make sure we don't have problems in the future. > > > > > > > You shouldn't really need to rebase your branch very often anyway. > > This is really for special cases. But even then you can always use: > > `git rebase --rebase-merges` to keep the merge commits. > > > > The commands you want to run are: > > > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git > > tags/pwrseq-initial-for-v6.11 > > git am or b4 shazam on the patches targeting the Bluetooth subsystem > > git push > > Not quite working for me: > > From git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux > * tag pwrseq-initial-for-v6.11 -> FETCH_HEAD > hint: You have divergent branches and need to specify how to reconcile them. > hint: You can do so by running one of the following commands sometime before > hint: your next pull: > hint: > hint: git config pull.rebase false # merge > hint: git config pull.rebase true # rebase > hint: git config pull.ff only # fast-forward only > hint: > hint: You can replace "git config" with "git config --global" to set a default > hint: preference for all repositories. You can also pass --rebase, --no-rebase, > hint: or --ff-only on the command line to override the configured default per > hint: invocation. > fatal: Need to specify how to reconcile divergent branches. > > Perhaps I need to configure pull.rebase to be false? Looks like I just needed -no-ff, will be pushing it after it finishes compiling. > > That's really it, there's not much else to it. > > > > Bart > > > > > > > Bart > > > > > > > > Gentle ping. > > > > > > > > Bart > > > > > > > > > > > > -- > > > Luiz Augusto von Dentz > > > > -- > Luiz Augusto von Dentz
On 20/06/2024 16:20, Luiz Augusto von Dentz wrote: > Hi, > > On Thu, Jun 20, 2024 at 10:16 AM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> >> Hi Bartosz, >> >> On Wed, Jun 19, 2024 at 3:40 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>> >>> On Wed, Jun 19, 2024 at 8:59 PM Luiz Augusto von Dentz >>> <luiz.dentz@gmail.com> wrote: >>>> >>>> Hi Bartosz, >>>> >>>> On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>> >>>>> On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>>> >>>>>> On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz >>>>>> <luiz.dentz@gmail.com> wrote: >>>>>>> >>>>>>> Hi Bartosz, >>>>>>> >>>>>>> On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>>>>> >>>>>>>> On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz >>>>>>>> <luiz.dentz@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi Bartosz, >>>>>>>>> >>>>>>>>> On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: >>>>>>>>>> >>>>>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>>>>>>>>> >>>>>>>>>> Hi Marcel, Luiz, >>>>>>>>>> >>>>>>>>>> Please pull the following power sequencing changes into the Bluetooth tree >>>>>>>>>> before applying the hci_qca patches I sent separately. >>>>>>>>>> >>>>>>>>>> Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ >>>>>>>>>> >>>>>>>>>> The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: >>>>>>>>>> >>>>>>>>>> Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) >>>>>>>>>> >>>>>>>>>> are available in the Git repository at: >>>>>>>>>> >>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 >>>>>>>>>> >>>>>>>>>> for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: >>>>>>>>>> >>>>>>>>>> power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------- >>>>>>>>>> Initial implementation of the power sequencing subsystem for linux v6.11 >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------- >>>>>>>>>> Bartosz Golaszewski (2): >>>>>>>>>> power: sequencing: implement the pwrseq core >>>>>>>>>> power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets >>>>>>>>> >>>>>>>>> Is this intended to go via bluetooth-next or it is just because it is >>>>>>>>> a dependency of another set? You could perhaps send another set >>>>>>>>> including these changes to avoid having CI failing to compile. >>>>>>>>> >>>>>>>> >>>>>>>> No, the pwrseq stuff is intended to go through its own pwrseq tree >>>>>>>> hence the PR. We cannot have these commits in next twice. >>>>>>> >>>>>>> Not following you here, why can't we have these commits on different >>>>>>> next trees? If that is the case how can we apply the bluetooth >>>>>>> specific ones without causing build regressions? >>>>>>> >>>>>> >>>>>> We can't have the same commits twice with different hashes in next >>>>>> because Stephen Rothwell will yell at us both. >>>>>> >>>>>> Just pull the tag I provided and then apply the Bluetooth specific >>>>>> changes I sent on top of it. When sending to Linus Torvalds/David >>>>>> Miller (not sure how your tree gets upstream) mention that you pulled >>>>>> in the pwrseq changes in your PR cover letter. >>>> >>>> By pull the tag you mean using merge commits to merge the trees and >>>> not rebase, doesn't that lock us down to only doing merge commits >>>> rather than rebases later on? I have never used merge commits before. >>>> There is some documentation around it that suggests not to use merges: >>>> >>>> 'While merges from downstream are common and unremarkable, merges from >>>> other trees tend to be a red flag when it comes time to push a branch >>>> upstream. Such merges need to be carefully thought about and well >>>> justified, or there’s a good chance that a subsequent pull request >>>> will be rejected.' >>>> https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees >>>> >>>> But then looking forward in that documentation it says: >>>> >>>> 'Another reason for doing merges of upstream or another subsystem tree >>>> is to resolve dependencies. These dependency issues do happen at >>>> times, and sometimes a cross-merge with another tree is the best way >>>> to resolve them; as always, in such situations, the merge commit >>>> should explain why the merge has been done. Take a moment to do it >>>> right; people will read those changelogs.' >>>> >>>> So I guess that is the reason we want to merge the trees, but what I'm >>>> really looking forward to is for the 'proper' commands and commit >>>> message to use to make sure we don't have problems in the future. >>>> >>> >>> You shouldn't really need to rebase your branch very often anyway. >>> This is really for special cases. But even then you can always use: >>> `git rebase --rebase-merges` to keep the merge commits. >>> >>> The commands you want to run are: >>> >>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git >>> tags/pwrseq-initial-for-v6.11 >>> git am or b4 shazam on the patches targeting the Bluetooth subsystem >>> git push >> >> Not quite working for me: >> >> From git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux >> * tag pwrseq-initial-for-v6.11 -> FETCH_HEAD >> hint: You have divergent branches and need to specify how to reconcile them. >> hint: You can do so by running one of the following commands sometime before >> hint: your next pull: >> hint: >> hint: git config pull.rebase false # merge >> hint: git config pull.rebase true # rebase >> hint: git config pull.ff only # fast-forward only >> hint: >> hint: You can replace "git config" with "git config --global" to set a default >> hint: preference for all repositories. You can also pass --rebase, --no-rebase, >> hint: or --ff-only on the command line to override the configured default per >> hint: invocation. >> fatal: Need to specify how to reconcile divergent branches. >> >> Perhaps I need to configure pull.rebase to be false? > > Looks like I just needed -no-ff, will be pushing it after it finishes compiling. Ah, so there was a tag. You miss proper config option... Well, I am surprised you do not have default pull.rebase set. How did you manage to pull anything from anyone? Git requires it since some time. Best regards, Krzysztof
Hello: This pull request was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Wed, 12 Jun 2024 09:58:29 +0200 you wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Hi Marcel, Luiz, > > Please pull the following power sequencing changes into the Bluetooth tree > before applying the hci_qca patches I sent separately. > > [...] Here is the summary with links: - [GIT,PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1 https://git.kernel.org/bluetooth/bluetooth-next/c/4c318a2187f8 You are awesome, thank you!
On 20/06/2024 16:30, patchwork-bot+bluetooth@kernel.org wrote: > Hello: > > This pull request was applied to bluetooth/bluetooth-next.git (master) > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > > On Wed, 12 Jun 2024 09:58:29 +0200 you wrote: >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >> >> Hi Marcel, Luiz, >> >> Please pull the following power sequencing changes into the Bluetooth tree >> before applying the hci_qca patches I sent separately. >> >> [...] > > Here is the summary with links: > - [GIT,PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1 > https://git.kernel.org/bluetooth/bluetooth-next/c/4c318a2187f8 Luiz, This pulls looks wrong. Are you sure you have correct base? The diffstat suggests you are merging into rc2, not rc3. This will be confusing in merge commit. It is much safer, including possible feedback from Linus, if you use exactly the same base. Best regards, Krzysztof
Hi Krzysztof, On Thu, Jun 20, 2024 at 10:35 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 20/06/2024 16:30, patchwork-bot+bluetooth@kernel.org wrote: > > Hello: > > > > This pull request was applied to bluetooth/bluetooth-next.git (master) > > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > > > > On Wed, 12 Jun 2024 09:58:29 +0200 you wrote: > >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >> > >> Hi Marcel, Luiz, > >> > >> Please pull the following power sequencing changes into the Bluetooth tree > >> before applying the hci_qca patches I sent separately. > >> > >> [...] > > > > Here is the summary with links: > > - [GIT,PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1 > > https://git.kernel.org/bluetooth/bluetooth-next/c/4c318a2187f8 > > > Luiz, > > This pulls looks wrong. Are you sure you have correct base? The diffstat > suggests you are merging into rc2, not rc3. This will be confusing in > merge commit. It is much safer, including possible feedback from Linus, > if you use exactly the same base. So you are saying I need to rebase? I usually only rebase when it comes the time to do a pull-request using net-next as a base since that is where bluetooth-next normally lands. > Best regards, > Krzysztof >
On Thu, 20 Jun 2024 at 16:44, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Krzysztof, > > On Thu, Jun 20, 2024 at 10:35 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On 20/06/2024 16:30, patchwork-bot+bluetooth@kernel.org wrote: > > > Hello: > > > > > > This pull request was applied to bluetooth/bluetooth-next.git (master) > > > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > > > > > > On Wed, 12 Jun 2024 09:58:29 +0200 you wrote: > > >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > >> > > >> Hi Marcel, Luiz, > > >> > > >> Please pull the following power sequencing changes into the Bluetooth tree > > >> before applying the hci_qca patches I sent separately. > > >> > > >> [...] > > > > > > Here is the summary with links: > > > - [GIT,PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1 > > > https://git.kernel.org/bluetooth/bluetooth-next/c/4c318a2187f8 > > > > > > Luiz, > > > > This pulls looks wrong. Are you sure you have correct base? The diffstat > > suggests you are merging into rc2, not rc3. This will be confusing in > > merge commit. It is much safer, including possible feedback from Linus, > > if you use exactly the same base. > > So you are saying I need to rebase? I usually only rebase when it > comes the time to do a pull-request using net-next as a base since > that is where bluetooth-next normally lands. > Technically you're all set - you pulled rc3 together with my tag. But if you pulled rc3 separately and then my tag, the merge commit for the latter would look much cleaner. And for the record: you don't need to rebase anything. Does net-next require you to? That would be weird. I assume they also are based on one of the RC tags. You almost never should rebase on top of an rc, instead you merge it into your branch and send the PR starting from the latest rc tag. Git is smart and will figure it out. You may be afraid you'll "lose" some commits because you will not see it in the immediate git log. That's true, they will be buried underneath the pile of Merge commits from upstream, but worry not: git will always find all commits missing from upstream when you do `git request-pull`. Bart > > Best regards, > > Krzysztof > > > > > -- > Luiz Augusto von Dentz
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Hi Marcel, Luiz, Please pull the following power sequencing changes into the Bluetooth tree before applying the hci_qca patches I sent separately. Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/ The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670: Linux 6.10-rc3 (2024-06-09 14:19:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11 for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd: power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200) ---------------------------------------------------------------- Initial implementation of the power sequencing subsystem for linux v6.11 ---------------------------------------------------------------- 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