From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Zhao Dongdong <zhaodongdong@kylinos.cn>,
Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>,
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>,
Sasha Levin <sashal@kernel.org>,
amitkumar.karwar@nxp.com, marcel@holtmann.org,
luiz.dentz@gmail.com, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18] Bluetooth: btnxpuart: Fix use-after-free in probe error path
Date: Mon, 19 Oct 2026 09:51:27 -0400 [thread overview]
Message-ID: <20261019135441.1420968-396-sashal@kernel.org> (raw)
In-Reply-To: <20261019135441.1420968-1-sashal@kernel.org>
From: Zhao Dongdong <zhaodongdong@kylinos.cn>
[ Upstream commit a2b3b4f00403a3a40c5627d1bf537c8fb166e221 ]
In nxp_serdev_probe(), if hci_register_dev() succeeds but ps_setup()
fails, the error path jumps to 'probe_fail' which only calls
hci_free_dev() and asserts the reset GPIO, but does NOT call
hci_unregister_dev() first.
This leaves the HCI device registered in the system with its backing
memory freed, leading to a use-after-free when userspace subsequently
accesses the device (e.g. via hciconfig or bluetoothd).
Fix by adding a 'probe_fail_unregister' label that calls
hci_unregister_dev() before falling through to the existing
'probe_fail' label. The original 'probe_fail' label is preserved
for the case where hci_register_dev() itself fails (device was
never registered, so no unregister is needed).
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Reviewed-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
The local tree is **6.18.53** (`pending-6.18`). The probe-path UAF is
present here, the fix is a 3-line unregister-before-free, and it should
be backported.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: PARSE THE SUBJECT LINE**
Record: **[Bluetooth / btnxpuart] [Fix] [use-after-free in
`nxp_serdev_probe()` when `ps_setup()` fails after a successful
`hci_register_dev()`]**
**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- **Fixes:** none (expected for this review pipeline)
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** Neeraj Sanjay Kale `<neeraj.sanjaykale@nxp.com>`
(listed `MAINTAINERS` co-maintainer of NXP Bluetooth)
- **Acked-by:** none
- **Link:** none
- **Cc: stable:** none (expected; not a negative)
- **Signed-off-by:** Zhao Dongdong `<zhaodongdong@kylinos.cn>` (author);
Luiz Augusto von Dentz `<luiz.von.dentz@intel.com>` (Bluetooth
maintainer)
- Pipeline SOBs (Sasha Levin / Upstream commit markers): ignored per
instructions
Notable: maintainer review + Bluetooth maintainer SOB. No syzbot tag.
**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** After `hci_register_dev()` succeeds, `ps_setup()` failure
jumps to `probe_fail`, which asserts reset and calls `hci_free_dev()`
without `hci_unregister_dev()`.
- **Symptom:** HCI device stays registered after its driver backing is
torn down; userspace (`hciconfig`, bluetoothd) can then UAF.
- **Version info:** none in the message.
- **Root cause (author):** missing unregister on the post-register error
path; `probe_fail` is correct only when registration itself failed.
**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: **Not a hidden fix.** Subject and body explicitly describe a
UAF. The code change matches that description.
---
## PHASE 2: DIFF ANALYSIS - LINE BY LINE
**Step 2.1: INVENTORY THE CHANGES**
Record:
- **File:** `drivers/bluetooth/btnxpuart.c` only
- **Scope:** +3 / −1 (one function)
- **Function:** `nxp_serdev_probe()`
- **Classification:** single-file surgical error-path fix
**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record (verified against this tree at `nxp_serdev_probe()`):
**Before** (local `drivers/bluetooth/btnxpuart.c` lines 1919–1935):
```
if (hci_register_dev(hdev) < 0)
goto probe_fail;
if (ps_setup(hdev))
goto probe_fail; // registered, but treated as never-
registered
...
probe_fail:
reset_control_assert(nxpdev->pdn);
hci_free_dev(hdev);
return -ENODEV;
```
**After:**
- `ps_setup()` failure → `probe_fail_unregister` →
`hci_unregister_dev(hdev)` then fall through
- `hci_register_dev()` failure still goes to `probe_fail` only (never
registered)
**Path affected:** probe error path only, after successful HCI
registration.
**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record:
- **Category:** use-after-free / lifetime bug (error-path cleanup)
- **Mechanism:** `hci_register_dev()` (`net/bluetooth/hci_core.c`) does
`device_add()`, `hci_dev_hold()`, and `queue_work(...,
&hdev->power_on)`. `hci_free_dev()` is only `put_device()`. Skipping
unregister leaves `hdev` on `hci_dev_list` and in sysfs.
- **Worse than the message states (verified):** `nxpdev` is
`devm_kzalloc()` at probe start. Probe returning `-ENODEV` releases
managed resources, so `nxpdev` is freed while a still-registered
`hdev` has `hci_set_drvdata(hdev, nxpdev)`. HCI callbacks
(`btnxpuart_open`, `nxp_setup`, power-on work) then dereference freed
driver state.
- **Fix:** same unregister-then-free order as `nxp_serdev_remove()`
(local lines 1959–1962).
**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: pairs register with unregister; preserves the
never-registered path.
- Minimal: 3 insertions, 1 deletion, no API/struct changes.
- Regression risk: low. `hci_unregister_dev()` is the designed teardown
(cancels `power_on` via `disable_work_sync`). Probe failure means
`remove()` is not called, so no double-unregister.
- Does not call `ps_cleanup()` on this path: correct, because
`ps_setup()`’s only error return is `devm_gpiod_get_optional()`
failure **before** `INIT_WORK` / `timer_setup` / `mutex_init` (local
lines 511–517 vs 557–561). Calling `ps_cleanup()` there would operate
on uninitialized state.
---
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Buggy `if (ps_setup(hdev)) goto probe_fail;` introduced by
**`c135a5bc34a89a75a739d07964ff3d1c4fa1b154`** (“Bluetooth: btnxpuart:
Add GPIO support to power save feature”, Neeraj Sanjay Kale, committer
date 2024-11-14).
- That commit changed `ps_setup()` from `void` to `int` and added the
`probe_fail` label that frees without unregister.
- `git merge-base --is-ancestor c135a5bc34a89a HEAD` → **yes**. Makefile
at that commit is **6.12.0-rc6**; this 6.18.53 tree contains the bug.
- Driver itself: `689ca16e523278` (2023-04-23). Original probe had
`ps_setup()` as void after register, so it could not fail after
register until `c135a5bc34a89`.
**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. The real introducer is `c135a5bc34a89`, not the
original driver add. A later duplicate patch (Myeonghun Pak) incorrectly
tagged `Fixes: 689ca16e5232`. Absence of Fixes here does not change the
local-tree fact: the buggy goto is in this checkout.
**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record:
- Recent `btnxpuart.c` work is firmware dump, OOB, IRQ, baudrate,
coredump — none of it unregisters on the `ps_setup()` fail path.
- `git log --grep="use-after-free" -- drivers/bluetooth/btnxpuart.c` →
empty.
- `probe_fail_unregister` is **not** in this tree.
- Standalone; not “patch X/Y”. v2 changelog was SubjectPrefix; v3 was
gitlint. Same 3-line diff.
**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: `git log --author="Zhao Dongdong" -- drivers/bluetooth/` in this
tree has no btnxpuart commits (author is not the NXP driver maintainer).
Weight comes from **Reviewed-by: Neeraj** (NXP maintainer) and **SOB:
Luiz** (Bluetooth maintainer). Neeraj is the author of the introducing
commit and of most later btnxpuart work.
**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: No new helpers. Uses existing `hci_unregister_dev()`. Local
probe matches the hunk (same `ps_setup` / `hci_devcd_register` /
`probe_fail` sequence). **Can apply standalone.**
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c <msgid>` for v1 msgid
`tencent_05373BA21CEEB5195F2ECCED0C77D0C57108@qq.com` → no matching
**commit** in this tree (expected: candidate not merged here).
- Lore.kernel.org fetches returned **403**.
- Discussion reconstructed from ratatoskr / spinics / lkml.iu.edu:
- v1/v2/v3 by Zhao Dongdong, mid-May 2026, linux-bluetooth
- v3: https://ratatoskr.run/linux-bluetooth/2026/05/9706550
- Luiz replied 2026-05-15; Neeraj reviewed 2026-06-03
- Revisions were cosmetic (prefix, gitlint), not logic changes
- **UNVERIFIED:** exact text of Luiz’s review comment (patchwork
presented a bot wall; lore 403)
**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record: Recipients/maintainers from public threads: Luiz von Dentz,
Marcel Holtmann, Amitkumar Karwar, Neeraj Kale, linux-bluetooth.
Committed form has Neeraj `Reviewed-by` and Luiz SOB. No NAK found.
**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No syzbot/bugzilla link. Independent second patch (Myeonghun Pak
/ Ijae Kim, 2026-06-26, “unregister HCI device on probe failure”)
describes the same bug. Neeraj told them Zhao’s patch was already
approved and waiting on Luiz. Two independent submissions = real issue,
not one-off theory.
**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: Standalone. Duplicate later patch is the same 3-line change with
a different label name (`unregister_dev` vs `probe_fail_unregister`). No
series dependency.
**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: `WebFetch` of lore.kernel.org/stable returned 403.
**UNVERIFIED:** whether stable@ already discussed this specific commit.
No evidence it was rejected for stable.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: `nxp_serdev_probe()` only. Calls added: `hci_unregister_dev()`.
**Step 5.2: TRACE CALLERS**
Record: `.probe = nxp_serdev_probe` in the serdev driver (local ~line
2030). Invoked on UART child-device bind (`compatible =
"nxp,88w8987-bt"` / `"nxp,88w8997-bt"`), not a syscall. Userspace
reaches the **aftermath** via HCI (`bluetoothd`, `hciconfig`) once the
device is left registered.
**Step 5.3: TRACE CALLEES**
Record:
- `hci_register_dev()`: `device_add`, list insert, `hci_dev_hold`,
`queue_work(power_on)`
- `hci_unregister_dev()`: `HCI_UNREGISTER`, `list_del`,
`disable_work_sync(power_on)`, close, mgmt removal
- `hci_free_dev()`: `put_device`
- `ps_setup()`: optional GPIO; only hard-fail is
`IS_ERR(devm_gpiod_get_optional(...))`
**Step 5.4: FOLLOW THE CALL CHAIN**
Record:
1. Serdev probe for NXP UART BT
2. `hci_register_dev` → `hci0` visible; `power_on` queued
3. `ps_setup` fails
4. Probe returns error without unregister → `devm` frees `nxpdev`
5. HCI core / userspace / leftover `power_on` uses `hdev` callbacks →
UAF
Reachable on any board using this driver with `device-wakeup-gpios` that
fails to resolve (property present, GPIO unavailable / `-EPROBE_DEFER`
converted to `-ENODEV`). Binding:
`Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml`
documents that GPIO. In-tree users of the compatible include i.MX
91/93/95 EVKs, i.MX8MP, TI Verdin AM62, Kobo Clara 2E.
**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: Other Bluetooth UART drivers typically only `hci_free_dev()`
when **register** fails. This driver’s bug is specifically “work after
register that can fail.” Remove path already had the correct
unregister/free order.
---
## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: **Yes.** `pending-6.18`, `make kernelversion` = **6.18.53**.
Exact snippet at lines 1924–1935 of `drivers/bluetooth/btnxpuart.c`.
Introduced in `c135a5bc34a89` (~6.13 era); present here. Candidate fix
**not** an ancestor of HEAD.
**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean apply.** Surrounding code matches the supplied hunk
(`hci_register_dev` / `ps_setup` / `hci_devcd_register` / `probe_fail` +
`reset_control_assert`). Line numbers differ slightly from the candidate
blob; context is the same. No conflicting refactor.
**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: No unregister-on-`ps_setup`-fail fix. Other btnxpuart stable-
style fixes in this tree (OOB firmware read, FW dump header length) are
unrelated.
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record:
- **Subsystem:** Bluetooth device driver
(`drivers/bluetooth/btnxpuart.c`)
- **Criticality:** **IMPORTANT** (not core mm/VFS). Real shipping
hardware (NXP 88W8987/8997 on i.MX and TI K3). `CONFIG_BT_NXPUART`
depends on `BT_HCIUART` and `SERIAL_DEV_BUS`.
**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Actively maintained (many 2025 btnxpuart commits in this tree).
Bug is in a 2024 error-path addition that has sat unfixed.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: **Driver-specific / config-specific:** `CONFIG_BT_NXPUART` users
with NXP UART Bluetooth, especially DTs that include `device-wakeup-
gpios`.
**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record:
- Trigger: `ps_setup()` returns non-zero after successful
`hci_register_dev()`.
- In this tree that is `devm_gpiod_get_optional("device-wakeup")`
returning `IS_ERR` (GPIO specified but cannot be acquired). IRQ setup
failures are ignored, not a probe fail.
- Not every boot. GPIO probe deferral / missing controller / bad DT are
realistic.
- Unprivileged userspace does not need to *cause* the probe fail; once
it happens, bluetoothd/hciconfig can trip the UAF. Concurrent
`power_on` work can trip it without userspace.
**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record:
- **Failure mode:** UAF of `btnxpuart_dev` (devm-freed) and/or HCI
object lifetime violation while `hciX` remains registered; possible
oops; `power_on` work not cancelled.
- **Severity: HIGH** (UAF / crash). Not a panic on every boot, but
classically stable-worthy.
**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit:** HIGH for affected hardware — prevents UAF/oops on a real
probe failure.
- **Risk:** VERY LOW — 3 lines, existing API, same order as `remove()`,
error path only.
- **Ratio:** strongly favors backport.
---
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: COMPILE THE EVIDENCE**
**FOR:**
- Confirmed UAF / lifetime bug in this 6.18.53 tree
- Small, obviously correct unregister-before-free
- Matches `nxp_serdev_remove()`
- Cancels `power_on` work that `hci_register_dev()` queued
- NXP driver maintainer Reviewed-by; Bluetooth maintainer SOB
- Independent duplicate patch
- Clean apply; no prerequisites
- Real in-tree hardware (i.MX, TI K3)
**AGAINST:**
- Driver-specific, not core kernel
- Trigger is an error path (`ps_setup` GPIO get fail), not every probe
- No syzbot/CVE/Reported-by
- No Fixes tag (not a reason to reject)
**UNRESOLVED (do not drive the verdict):**
- Exact Luiz review comment text
- Mainline SHA of the candidate (not in this tree)
- stable@ discussion (lore 403)
**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — pairing is the documented
HCI lifetime; reviewed by driver + Bluetooth maintainers.
2. Fixes a real bug that affects users? **PASS** — registered HCI left
after probe fail; UAF via callbacks/userspace.
3. Important issue? **PASS** — UAF / crash, HIGH (not
deadlock/corruption, still stable-class).
4. Small and contained? **PASS** — 3 lines, one function.
5. No new features or APIs? **PASS**
6. Can apply to the local tree? **PASS** — buggy code present; hunk
matches.
**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: Not ID/quirk/DT/build/docs. It is a **normal UAF bugfix**, which
is in-scope without an exception.
**Step 9.4: MAKE YOUR DECISION**
This 6.18.53 tree has the buggy `ps_setup()` → `probe_fail` path from
`c135a5bc34a89`. The fix is the missing `hci_unregister_dev()` before
`hci_free_dev()`. That is required HCI lifetime management, matches
remove(), and prevents UAF of `devm`-managed driver state while `hciX`
stays registered. Scope and risk are appropriate for stable.
---
### What the commit solves for this tree
On NXP UART Bluetooth probe, if HCI registration succeeds and then
power-save GPIO setup fails, 6.18.53 currently frees the HCI object
(and, via `devm`, the driver private data) without unregistering.
Userspace and the queued `power_on` work can then use freed memory. The
backport adds one unregister on that path only.
### Stable rules / risk vs benefit
Meets all six criteria. Benefit is preventing a UAF on a shipping
driver; risk is a 3-line error-path change that uses the existing
unregister helper.
### Concerns
None that block backport. Trigger is uncommon (GPIO get failure), but
the failure mode is severe enough. No extra commits needed.
---
### Verification
- **[Phase 1]** Parsed subject/tags/body: UAF fix; Reviewed-by Neeraj;
SOB Luiz; no Fixes/syzbot/Cc-stable
- **[Phase 2]** Diff: +3/−1 in `nxp_serdev_probe()`; `ps_setup` fail now
unregisters before free
- **[Phase 2]** Read local probe/remove/`ps_setup`: bug and GPIO-only
fail return confirmed
- **[Phase 2]** Read
`hci_register_dev`/`hci_unregister_dev`/`hci_free_dev`: register
queues `power_on` and holds refs; free is `put_device` only
- **[Phase 3]** `git describe HEAD` / `make kernelversion`:
`p-6.18-1-g03b85e06ca9bf`, **6.18.53**
- **[Phase 3]** `git blame -L 1915,1940`: buggy goto from
`c135a5bc34a89`
- **[Phase 3]** `git merge-base --is-ancestor c135a5bc34a89a HEAD`: yes
- **[Phase 3]** `git show c135a5bc34a89a`: introduced int `ps_setup` +
`goto probe_fail` without unregister
- **[Phase 3]** Original driver `689ca16e523278`: `ps_setup` could not
fail after register
- **[Phase 3]** `git log --grep="use-after-free"` on this file: empty;
fix not in tree
- **[Phase 4]** `b4 dig` on v1 msgid: no commit in this tree
- **[Phase 4]** lore.kernel.org: 403 — UNVERIFIED full thread body
- **[Phase 4]** ratatoskr v3 + lkml.iu.edu: v1–v3 standalone; Neeraj
approved; duplicate June 2026 patch
- **[Phase 5]** Callers: serdev `.probe`; `nxpdev` is `devm_kzalloc`
- **[Phase 5]** DTS: `nxp,88w8987-bt` on i.MX and TI boards; binding
documents `device-wakeup-gpios`
- **[Phase 6]** Exact buggy snippet present; `probe_fail_unregister`
absent
- **[Phase 8]** Failure: UAF/oops on probe error after register;
severity HIGH
- **UNVERIFIED:** Luiz comment text; candidate mainline SHA; stable@
archive
The fix is small, surgical, already in the local probe shape, and
addresses a real UAF.
**YES**
drivers/bluetooth/btnxpuart.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
index c7acf6c7efcf6..870ce16ad40b1 100644
--- a/drivers/bluetooth/btnxpuart.c
+++ b/drivers/bluetooth/btnxpuart.c
@@ -1924,13 +1924,15 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
}
if (ps_setup(hdev))
- goto probe_fail;
+ goto probe_fail_unregister;
hci_devcd_register(hdev, nxp_coredump, nxp_coredump_hdr,
nxp_coredump_notify);
return 0;
+probe_fail_unregister:
+ hci_unregister_dev(hdev);
probe_fail:
reset_control_assert(nxpdev->pdn);
hci_free_dev(hdev);
--
2.53.0
next prev parent reply other threads:[~2026-10-19 14:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20261019135441.1420968-1-sashal@kernel.org>
2026-10-19 13:45 ` [PATCH AUTOSEL 6.18-6.1] Bluetooth: hci_event: fix out-of-bounds read in LE PA report reassembly Sasha Levin
2026-10-19 13:45 ` [PATCH AUTOSEL 6.18-5.10] Bluetooth: btrsi: Move set_bt_context after successful HCI registration Sasha Levin
2026-10-19 13:47 ` [PATCH AUTOSEL 6.18] Bluetooth: bfusb: validate received block boundaries Sasha Levin
2026-10-19 13:48 ` [PATCH AUTOSEL 6.18-5.15] Bluetooth: btusb: Add support for 1357:c123 Realtek 8852BE device Sasha Levin
2026-10-19 13:48 ` [PATCH AUTOSEL 6.18-5.10] Bluetooth: hci_bcsp: validate received packet lengths Sasha Levin
2026-10-19 13:48 ` [PATCH AUTOSEL 6.18-5.10] Bluetooth: hci_nokia: validate firmware packet bounds Sasha Levin
2026-10-19 13:50 ` [PATCH AUTOSEL 6.18] Bluetooth: btusb: Add USB ID 13d3:3625 for MediaTek MT7922 Sasha Levin
2026-10-19 13:50 ` [PATCH AUTOSEL 6.18-6.1] Bluetooth: hci_sync: Disable legacy instance's ext adv before setup snapshot Sasha Levin
2026-10-19 13:51 ` Sasha Levin [this message]
2026-10-19 13:52 ` [PATCH AUTOSEL 6.18] Bluetooth: fix BT dependency for submodules Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261019135441.1420968-396-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=amitkumar.karwar@nxp.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=luiz.von.dentz@intel.com \
--cc=marcel@holtmann.org \
--cc=neeraj.sanjaykale@nxp.com \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=zhaodongdong@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox