linux-kernel - Re: [GIT PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABBYNZ+7SrLSDeCLF0WDM01prRgAEHMD=9mhu5MfWOuGwoAkNQ@mail.gmail.com>
Date: Wed, 19 Jun 2024 14:59:23 -0400
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Marcel Holtmann <marcel@...tmann.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [GIT PULL] Immutable tag between the Bluetooth and pwrseq
 branches for v6.11-rc1

Hi Bartosz,

On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> >
> > On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz
> > <luiz.dentz@...il.com> wrote:
> > >
> > > Hi Bartosz,
> > >
> > > On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > > >
> > > > On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz
> > > > <luiz.dentz@...il.com> wrote:
> > > > >
> > > > > Hi Bartosz,
> > > > >
> > > > > On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > > > > >
> > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.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



-- 
Luiz Augusto von Dentz