[GIT PULL] bluetooth 2026-09-07

[GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

The following changes since commit 38b6be101006d3e7af972999f45d4f1e8250587a:

  net: macb: fix NULL pointer dereference on unbind with fixed-link (2026-09-05 13:58:52 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-09-07

for you to fetch changes up to 3ffa1008d5018a15163938fa54a99284bbde1c31:

  Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset (2026-09-07 13:13:49 -0400)

----------------------------------------------------------------
bluetooth pull request for net:

Core:

 - hci_sysfs: Fix NULL pointer dereference in device_del()
 - hci_sync: Fix not setting CE length properly
 - btqcomsmd: destroy RPMsg endpoints before freeing hci_dev

Drivers:

 - btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware
 - btusb: mediatek: Fix leaked runtime PM reference in reset
 - btusb: Fix leaked runtime PM reference in btusb_reset
 - btusb: Fix UAF of btusb_data by rx_work
 - btusb: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
 - btintel_pcie: validate packet_len before skb_put_data
 - btintel_pcie: fix tx_handle bounds off-by-one
 - btrtl: Don't leak return code when parsing firmware format v2

----------------------------------------------------------------
Ivan Hu (1):
      Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware

Jiajia Liu (2):
      Bluetooth: btusb: mediatek: Fix leaked runtime PM reference in reset
      Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset

Kiran K (2):
      Bluetooth: btintel_pcie: validate packet_len before skb_put_data
      Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one

Krystian Kaniewski (1):
      Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del()

Luiz Augusto von Dentz (2):
      Bluetooth: btusb: Fix UAF of btusb_data by rx_work
      Bluetooth: hci_sync: Fix not setting CE length properly

Rong Zhang (2):
      Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
      Bluetooth: btrtl: Don't leak return code when parsing firmware format v2

Xu Rao (1):
      Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev

 drivers/bluetooth/btintel_pcie.c |   6 ++-
 drivers/bluetooth/btmtk.c        |  11 +---
 drivers/bluetooth/btmtk.h        |   1 +
 drivers/bluetooth/btqcomsmd.c    |   6 ++-
 drivers/bluetooth/btrtl.c        |   5 +-
 drivers/bluetooth/btusb.c        | 105 +++++++++++++++++++++++++++++++++++----
 net/bluetooth/hci_sync.c         |  38 +++++++++++++-
 net/bluetooth/hci_sysfs.c        |  17 ++++++-
 8 files changed, 159 insertions(+), 30 deletions(-)

Re: [GIT PULL] bluetooth 2026-09-07

[Jakub Kicinski]

On Mon,  7 Sep 2026 13:26:48 -0400 Luiz Augusto von Dentz wrote:
> bluetooth pull request for net:
> 
> Core:
> 
>  - hci_sysfs: Fix NULL pointer dereference in device_del()
>  - hci_sync: Fix not setting CE length properly
>  - btqcomsmd: destroy RPMsg endpoints before freeing hci_dev
> 
> Drivers:
> 
>  - btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware
>  - btusb: mediatek: Fix leaked runtime PM reference in reset
>  - btusb: Fix leaked runtime PM reference in btusb_reset
>  - btusb: Fix UAF of btusb_data by rx_work
>  - btusb: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
>  - btintel_pcie: validate packet_len before skb_put_data
>  - btintel_pcie: fix tx_handle bounds off-by-one
>  - btrtl: Don't leak return code when parsing firmware format v2

You're missing a bunch of your own sign-off tags.

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Jakub,

On Tue, Sep 8, 2026 at 4:57 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon,  7 Sep 2026 13:26:48 -0400 Luiz Augusto von Dentz wrote:
> > bluetooth pull request for net:
> >
> > Core:
> >
> >  - hci_sysfs: Fix NULL pointer dereference in device_del()
> >  - hci_sync: Fix not setting CE length properly
> >  - btqcomsmd: destroy RPMsg endpoints before freeing hci_dev
> >
> > Drivers:
> >
> >  - btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware
> >  - btusb: mediatek: Fix leaked runtime PM reference in reset
> >  - btusb: Fix leaked runtime PM reference in btusb_reset
> >  - btusb: Fix UAF of btusb_data by rx_work
> >  - btusb: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
> >  - btintel_pcie: validate packet_len before skb_put_data
> >  - btintel_pcie: fix tx_handle bounds off-by-one
> >  - btrtl: Don't leak return code when parsing firmware format v2
>
> You're missing a bunch of your own sign-off tags.

Yeah, I will respin it in a moment.

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Tue, Sep 08, 2026 at 01:57:08PM -0700, Jakub Kicinski wrote:

> You're missing a bunch of your own sign-off tags.

FWIW I do keep reporting signoff issues to them:

   https://lore.kernel.org/r/aqQARvWlSUQEHMtw@sirena.org.uk
   https://lore.kernel.org/r/ap6Ze-_ckuTFyCMH@sirena.org.uk
   https://lore.kernel.org/r/04d6aba2-bf5c-4e73-8ba2-1fe57218fbd9@sirena.org.uk

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Mark,

On Tue, Sep 15, 2026 at 1:46 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Sep 08, 2026 at 01:57:08PM -0700, Jakub Kicinski wrote:
>
> > You're missing a bunch of your own sign-off tags.
>
> FWIW I do keep reporting signoff issues to them:
>
>    https://lore.kernel.org/r/aqQARvWlSUQEHMtw@sirena.org.uk
>    https://lore.kernel.org/r/ap6Ze-_ckuTFyCMH@sirena.org.uk
>    https://lore.kernel.org/r/04d6aba2-bf5c-4e73-8ba2-1fe57218fbd9@sirena.org.uk

These have been fixed though:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=8d463624a249b6023e1bac6a5ebb0853a9c96d26
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=be1cc4fae4cb7d506ad01fa7746db363c41dcb6e
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=9ec9d1ade8ae7a3bd3cc061534d767fe305bedb6

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On Tue, Sep 15, 2026 at 02:07:39PM -0400, Luiz Augusto von Dentz wrote:
> On Tue, Sep 15, 2026 at 1:46 PM Mark Brown <broonie@kernel.org> wrote:

> > FWIW I do keep reporting signoff issues to them:

> >    https://lore.kernel.org/r/aqQARvWlSUQEHMtw@sirena.org.uk
> >    https://lore.kernel.org/r/ap6Ze-_ckuTFyCMH@sirena.org.uk
> >    https://lore.kernel.org/r/04d6aba2-bf5c-4e73-8ba2-1fe57218fbd9@sirena.org.uk

> These have been fixed though:

> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=8d463624a249b6023e1bac6a5ebb0853a9c96d26
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=be1cc4fae4cb7d506ad01fa7746db363c41dcb6e
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=9ec9d1ade8ae7a3bd3cc061534d767fe305bedb6

Sure, they do mostly seem to go away eventually but I'm usually sending
reminders, and apparently at least some of these issues are making it
into upstream pull requests so it seems the reports weren't acted on.  I
did ask in the last of those mails if you should be a contact for the
tree given that you seem to be doing a lot of the updates but never
heard back on that - should I make that update?

Given the issues caused by the unusual workflow for the tree I do send a
lot of reports of issues in bluetooth.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Mark,

On Tue, Sep 15, 2026 at 2:26 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Sep 15, 2026 at 02:07:39PM -0400, Luiz Augusto von Dentz wrote:
> > On Tue, Sep 15, 2026 at 1:46 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > FWIW I do keep reporting signoff issues to them:
>
> > >    https://lore.kernel.org/r/aqQARvWlSUQEHMtw@sirena.org.uk
> > >    https://lore.kernel.org/r/ap6Ze-_ckuTFyCMH@sirena.org.uk
> > >    https://lore.kernel.org/r/04d6aba2-bf5c-4e73-8ba2-1fe57218fbd9@sirena.org.uk
>
> > These have been fixed though:
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=8d463624a249b6023e1bac6a5ebb0853a9c96d26
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=be1cc4fae4cb7d506ad01fa7746db363c41dcb6e
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=9ec9d1ade8ae7a3bd3cc061534d767fe305bedb6
>
> Sure, they do mostly seem to go away eventually but I'm usually sending
> reminders, and apparently at least some of these issues are making it
> into upstream pull requests so it seems the reports weren't acted on.  I
> did ask in the last of those mails if you should be a contact for the
> tree given that you seem to be doing a lot of the updates but never
> heard back on that - should I make that update?
>
> Given the issues caused by the unusual workflow for the tree I do send a
> lot of reports of issues in bluetooth.

Are you referring to the unusual workflow where fixes are merged to
bluetooth-next first, then to bluetooth (which changes its ID), and
finally merge to net? Changing the order to have Bluetooth first and
then bluetooth-next would require reworking the CI so it could
determine that it is a fix and then use Bluetooth as a base just to
avoid ID changes.

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
> On Tue, Sep 15, 2026 at 2:26 PM Mark Brown <broonie@kernel.org> wrote:

> > Given the issues caused by the unusual workflow for the tree I do send a
> > lot of reports of issues in bluetooth.

> Are you referring to the unusual workflow where fixes are merged to
> bluetooth-next first, then to bluetooth (which changes its ID), and
> finally merge to net? Changing the order to have Bluetooth first and
> then bluetooth-next would require reworking the CI so it could
> determine that it is a fix and then use Bluetooth as a base just to
> avoid ID changes.

Yes, the routine cherry picking is certainly part of it - it's not so
much the fact that things get moved between branches as the fact that
when you have the same commit is in multiple branches and then build on
top of one or both of them this creates extra conflicts, often harder to
understand, when the branches are merged.  The more normal thing would
be to apply once to the right place, or the standard fallback from that
would be to drop the commit from branch A at the time it is moved to
branch B.

You do seem to end up removing the cherry picked commits from their
original branches at some point as part of your workflow (since there
are hardly any duplicate bluetooth commits in mainline) so they do wind
up being moves AFAICT but the duplicates get left sitting there for
quite a while.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Mark,

On Tue, Sep 15, 2026 at 3:24 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
> > On Tue, Sep 15, 2026 at 2:26 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > Given the issues caused by the unusual workflow for the tree I do send a
> > > lot of reports of issues in bluetooth.
>
> > Are you referring to the unusual workflow where fixes are merged to
> > bluetooth-next first, then to bluetooth (which changes its ID), and
> > finally merge to net? Changing the order to have Bluetooth first and
> > then bluetooth-next would require reworking the CI so it could
> > determine that it is a fix and then use Bluetooth as a base just to
> > avoid ID changes.
>
> Yes, the routine cherry picking is certainly part of it - it's not so
> much the fact that things get moved between branches as the fact that
> when you have the same commit is in multiple branches and then build on
> top of one or both of them this creates extra conflicts, often harder to
> understand, when the branches are merged.  The more normal thing would
> be to apply once to the right place, or the standard fallback from that
> would be to drop the commit from branch A at the time it is moved to
> branch B.

If I merge to bluetooth, then bluetooth-next won't contain the fixes
meant for stable/rc, so I will need to merge them back to
bluetooth-next immediately it order for our CI to stay current with
the fixes.

> You do seem to end up removing the cherry picked commits from their
> original branches at some point as part of your workflow (since there
> are hardly any duplicate bluetooth commits in mainline) so they do wind
> up being moves AFAICT but the duplicates get left sitting there for
> quite a while.

Yep, once before sending the pull request for net-next, bluetooth-next
is rebased on top of net-next which brings all the fixes already
merged back to bluetooth-next. Git is absolutely fine with that, I
don't think I ever run into a conflict doing this. Git detects the
fixes already present in net-next as duplicates and eliminates them,
so it really surprises me when you say you are finding conflicts, not
just duplicates.

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]

On Tue, Sep 15, 2026 at 03:36:50PM -0400, Luiz Augusto von Dentz wrote:
> On Tue, Sep 15, 2026 at 3:24 PM Mark Brown <broonie@kernel.org> wrote:
> > On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:

> > Yes, the routine cherry picking is certainly part of it - it's not so
> > much the fact that things get moved between branches as the fact that
> > when you have the same commit is in multiple branches and then build on
> > top of one or both of them this creates extra conflicts, often harder to
> > understand, when the branches are merged.  The more normal thing would
> > be to apply once to the right place, or the standard fallback from that
> > would be to drop the commit from branch A at the time it is moved to
> > branch B.

> If I merge to bluetooth, then bluetooth-next won't contain the fixes
> meant for stable/rc, so I will need to merge them back to
> bluetooth-next immediately it order for our CI to stay current with
> the fixes.

Or have your CI merge the branches and run on that (that's a fairly
widely deployed approach).

> > You do seem to end up removing the cherry picked commits from their
> > original branches at some point as part of your workflow (since there
> > are hardly any duplicate bluetooth commits in mainline) so they do wind
> > up being moves AFAICT but the duplicates get left sitting there for
> > quite a while.

> Yep, once before sending the pull request for net-next, bluetooth-next
> is rebased on top of net-next which brings all the fixes already
> merged back to bluetooth-next. Git is absolutely fine with that, I
> don't think I ever run into a conflict doing this. Git detects the
> fixes already present in net-next as duplicates and eliminates them,
> so it really surprises me when you say you are finding conflicts, not
> just duplicates.

The issue is not your rebase working, the issue is that until you get
round to doing that rebase anyone that merges both bluetooth and the net
trees (ot Linus' tree for that matter, often the conflicts are with his
tree) sees the duplicated commits and that routinely generates
conflicts.  This obviously comes up an awful lot with -next, I am not
rebasing the trees but rather merging them, but do I gather from some
conversations that other people are seeing this as part of their
workflows.

Anyway, to return to my prior question: should you be a contact for the
bluetooth tree?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Mark,

On Tue, Sep 15, 2026 at 6:54 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Sep 15, 2026 at 03:36:50PM -0400, Luiz Augusto von Dentz wrote:
> > On Tue, Sep 15, 2026 at 3:24 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
>
> > > Yes, the routine cherry picking is certainly part of it - it's not so
> > > much the fact that things get moved between branches as the fact that
> > > when you have the same commit is in multiple branches and then build on
> > > top of one or both of them this creates extra conflicts, often harder to
> > > understand, when the branches are merged.  The more normal thing would
> > > be to apply once to the right place, or the standard fallback from that
> > > would be to drop the commit from branch A at the time it is moved to
> > > branch B.
>
> > If I merge to bluetooth, then bluetooth-next won't contain the fixes
> > meant for stable/rc, so I will need to merge them back to
> > bluetooth-next immediately it order for our CI to stay current with
> > the fixes.
>
> Or have your CI merge the branches and run on that (that's a fairly
> widely deployed approach).

I incorporate the merge back into my workflow:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=967788508ba263e22d856f971c9118dc1a73f6ff

Hopefully this should stop showing conflicting/duplicate IDs at your end.

> > > You do seem to end up removing the cherry picked commits from their
> > > original branches at some point as part of your workflow (since there
> > > are hardly any duplicate bluetooth commits in mainline) so they do wind
> > > up being moves AFAICT but the duplicates get left sitting there for
> > > quite a while.
>
> > Yep, once before sending the pull request for net-next, bluetooth-next
> > is rebased on top of net-next which brings all the fixes already
> > merged back to bluetooth-next. Git is absolutely fine with that, I
> > don't think I ever run into a conflict doing this. Git detects the
> > fixes already present in net-next as duplicates and eliminates them,
> > so it really surprises me when you say you are finding conflicts, not
> > just duplicates.
>
> The issue is not your rebase working, the issue is that until you get
> round to doing that rebase anyone that merges both bluetooth and the net
> trees (ot Linus' tree for that matter, often the conflicts are with his
> tree) sees the duplicated commits and that routinely generates
> conflicts.  This obviously comes up an awful lot with -next, I am not
> rebasing the trees but rather merging them, but do I gather from some
> conversations that other people are seeing this as part of their
> workflows.
>
> Anyway, to return to my prior question: should you be a contact for the
> bluetooth tree?

Yep, you can add me as a contact person for both the bluetooth and
bluetooth-next trees.

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On Wed, Sep 16, 2026 at 02:12:28PM -0400, Luiz Augusto von Dentz wrote:

> I incorporate the merge back into my workflow:

> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=967788508ba263e22d856f971c9118dc1a73f6ff

> Hopefully this should stop showing conflicting/duplicate IDs at your end.

Thanks!

> Yep, you can add me as a contact person for both the bluetooth and
> bluetooth-next trees.

With your luiz.dentz@gmail.com address?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Mark,

On Wed, Sep 16, 2026 at 2:15 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Sep 16, 2026 at 02:12:28PM -0400, Luiz Augusto von Dentz wrote:
>
> > I incorporate the merge back into my workflow:
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=967788508ba263e22d856f971c9118dc1a73f6ff
>
> > Hopefully this should stop showing conflicting/duplicate IDs at your end.
>
> Thanks!
>
> > Yep, you can add me as a contact person for both the bluetooth and
> > bluetooth-next trees.
>
> With your luiz.dentz@gmail.com address?

Yes.

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Wed, Sep 16, 2026 at 02:17:35PM -0400, Luiz Augusto von Dentz wrote:
> On Wed, Sep 16, 2026 at 2:15 PM Mark Brown <broonie@kernel.org> wrote:

> > > Yep, you can add me as a contact person for both the bluetooth and
> > > bluetooth-next trees.

> > With your luiz.dentz@gmail.com address?

> Yes.

Great, you're added for the bluetooth tree now.  I note that I only have
one tree for bluetooth in -next:

   https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
master

so your fixes tree is not covered, I can easily add that if you tell me
where it is?  It'd be good to have it in pending-fixes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Mark,

On Wed, Sep 16, 2026 at 2:27 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Sep 16, 2026 at 02:17:35PM -0400, Luiz Augusto von Dentz wrote:
> > On Wed, Sep 16, 2026 at 2:15 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > > Yep, you can add me as a contact person for both the bluetooth and
> > > > bluetooth-next trees.
>
> > > With your luiz.dentz@gmail.com address?
>
> > Yes.
>
> Great, you're added for the bluetooth tree now.  I note that I only have
> one tree for bluetooth in -next:
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
> master
>
> so your fixes tree is not covered, I can easily add that if you tell me
> where it is?  It'd be good to have it in pending-fixes.

Fixes tree is in:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

On Wed, Sep 16, 2026 at 02:30:30PM -0400, Luiz Augusto von Dentz wrote:

> Fixes tree is in:

> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git

The master branch?  There's also a for-upstream branch, though I see
it's very old.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] bluetooth 2026-09-07

[Luiz Augusto von Dentz]

Hi Mark,

On Wed, Sep 16, 2026 at 2:33 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Sep 16, 2026 at 02:30:30PM -0400, Luiz Augusto von Dentz wrote:
>
> > Fixes tree is in:
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git
>
> The master branch?  There's also a for-upstream branch, though I see
> it's very old.

We only really use the master nowadays.

-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-09-07

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On Wed, Sep 16, 2026 at 02:34:18PM -0400, Luiz Augusto von Dentz wrote:
> On Wed, Sep 16, 2026 at 2:33 PM Mark Brown <broonie@kernel.org> wrote:

> > On Wed, Sep 16, 2026 at 02:30:30PM -0400, Luiz Augusto von Dentz wrote:

> > > Fixes tree is in:

> > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git

> > The master branch?  There's also a for-upstream branch, though I see
> > it's very old.

> We only really use the master nowadays.

OK, that'll be there from tomorrow.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]