[PATCH AUTOSEL 6.18] net: stmmac: Fix PTP ref clock for Tegra234

[PATCH AUTOSEL 6.18] net: stmmac: Fix PTP ref clock for Tegra234

[Sasha Levin]

From: Jon Hunter <jonathanh@nvidia.com>

[ Upstream commit 1345e9f4e3f3bc7d8a0a2138ae29e205a857a555 ]

Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not
0 before configuring timestamping") was added the following error is
observed on Tegra234:

 ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
 WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed

It turns out that the Tegra234 device-tree binding defines the PTP ref
clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now
exposes this and that the PTP clock is not configured correctly.

In order to update device-tree to use the correct 'ptp_ref' name, update
the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using
'ptp-ref' if this clock name is present.

Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260401102941.17466-2-jonathanh@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 .../net/ethernet/stmicro/stmmac/dwmac-tegra.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
index d765acbe37548..21a0a11fc0118 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
@@ -9,7 +9,7 @@
 #include "stmmac_platform.h"
 
 static const char *const mgbe_clks[] = {
-	"rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp-ref", "mac"
+	"rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp_ref", "mac"
 };
 
 struct tegra_mgbe {
@@ -215,6 +215,7 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
 {
 	struct plat_stmmacenet_data *plat;
 	struct stmmac_resources res;
+	bool use_legacy_ptp = false;
 	struct tegra_mgbe *mgbe;
 	int irq, err, i;
 	u32 value;
@@ -257,9 +258,23 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
 	if (!mgbe->clks)
 		return -ENOMEM;
 
-	for (i = 0; i <  ARRAY_SIZE(mgbe_clks); i++)
+	/* Older device-trees use 'ptp-ref' rather than 'ptp_ref'.
+	 * Fall back when the legacy name is present.
+	 */
+	if (of_property_match_string(pdev->dev.of_node, "clock-names",
+				     "ptp-ref") >= 0)
+		use_legacy_ptp = true;
+
+	for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++) {
 		mgbe->clks[i].id = mgbe_clks[i];
 
+		if (use_legacy_ptp && !strcmp(mgbe_clks[i], "ptp_ref")) {
+			dev_warn(mgbe->dev,
+				 "Device-tree update needed for PTP clock!\n");
+			mgbe->clks[i].id = "ptp-ref";
+		}
+	}
+
 	err = devm_clk_bulk_get(mgbe->dev, ARRAY_SIZE(mgbe_clks), mgbe->clks);
 	if (err < 0)
 		return err;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] wifi: mt76: don't return TXQ when exceeding max non-AQL packets

[Sasha Levin]

From: David Bauer <mail@david-bauer.net>

[ Upstream commit 964f870e090e9c88a41e2890333421204cc0bdf4 ]

mt76_txq_send_burst does check if the number of non-AQL frames exceeds
the maximum. In this case the queue is returned to ieee80211_return_txq
when iterating over the scheduled TXQs in mt76_txq_schedule_list.

This has the effect of inserting said TXQ at the head of the list. This
means the loop will get the same TXQ again, which will terminate the
scheduling round. TXQs following in the list thus never get scheduled
for transmission.

This can manifest in high latency low throughput or broken connections
for said STAs.

Check if the non-AQL packet count exceeds the limit and not return the
TXQ in this case.
Schedule all TXQs for the STA in case the non-AQL limit can be satisfied
again.

Signed-off-by: David Bauer <mail@david-bauer.net>
Link: https://patch.msgid.link/20260129232321.276575-1-mail@david-bauer.net
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have all the information needed for a complete analysis. Let me
compile my findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `wifi: mt76:` (MediaTek mt76 WiFi driver)
- **Action verb**: "don't return" — indicates preventing incorrect
  behavior, i.e., a bug fix
- **Summary**: Don't return TXQ to mac80211 scheduler when the non-AQL
  packet limit is exceeded

### Step 1.2: Tags
- **Signed-off-by**: David Bauer (author), Felix Fietkau
  (committer/maintainer)
- **Link**:
  `https://patch.msgid.link/20260129232321.276575-1-mail@david-
  bauer.net`
- No Fixes: tag, no Cc: stable, no Reported-by — all expected for a
  commit under review
- Felix Fietkau (nbd@nbd.name) is the mt76 subsystem maintainer who
  merged this

### Step 1.3: Commit Body
- **Bug described**: When `mt76_txq_send_burst` detects non-AQL packets
  exceeding the limit, it returns 0. The TXQ is then returned to
  mac80211 via `ieee80211_return_txq()`, which re-inserts it at the head
  of the scheduling list (with airtime fairness). On the next iteration,
  `ieee80211_next_txq()` sees the same TXQ with its round number already
  set, returns NULL, and terminates the scheduling round.
- **Symptom**: "high latency low throughput or broken connections for
  said STAs" — TXQs following the problematic one in the list never get
  scheduled.
- **Root cause**: TXQ scheduling starvation due to improper return of
  rate-limited TXQs

### Step 1.4: Hidden Bug Fix Detection
This is an explicit, clearly-described bug fix for a scheduling
starvation issue.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 file — `drivers/net/wireless/mediatek/mt76/tx.c`
- **Changes**: ~20 lines added, 0 removed (two code additions)
- **Functions modified**: `mt76_tx_check_non_aql()`,
  `mt76_txq_schedule_list()`
- **Scope**: Single-file, surgical fix in two specific functions

### Step 2.2: Code Flow Changes

**Hunk 1** (`mt76_tx_check_non_aql`):
- **Before**: Decrements `non_aql_packets` on tx completion, clamps to 0
  if negative, returns
- **After**: Same, plus: when `pending == MT_MAX_NON_AQL_PKT - 1` (count
  just dropped below limit), reschedules all TXQs for the STA via
  `ieee80211_schedule_txq()`. This ensures TXQs that were dropped from
  the scheduling list get re-added.

**Hunk 2** (`mt76_txq_schedule_list`):
- **Before**: After getting a TXQ from `ieee80211_next_txq()`, checks PS
  flag and reset state, then proceeds to `mt76_txq_send_burst()` which
  may early-return if non-AQL limit is hit. Then always calls
  `ieee80211_return_txq()`.
- **After**: Adds a check `if (atomic_read(&wcid->non_aql_packets) >=
  MT_MAX_NON_AQL_PKT) continue;` — skips the TXQ without returning it to
  the scheduler, allowing the loop to proceed to the next TXQ.

### Step 2.3: Bug Mechanism
This is a **logic/scheduling correctness bug**. The mac80211 TXQ
scheduler has specific round-tracking semantics:
- `ieee80211_next_txq()` removes the TXQ and marks its round number
- `ieee80211_return_txq()` re-inserts it (at HEAD with airtime fairness)
- A subsequent `ieee80211_next_txq()` seeing the same TXQ's round number
  → returns NULL, ending the round

When a non-AQL-limited TXQ is returned to the list, it poisons the
scheduling round and starves all subsequent TXQs.

### Step 2.4: Fix Quality
- **Obviously correct**: Yes — the `continue` pattern is already used in
  this function for PS flag and reset state checks
- **Minimal/surgical**: Yes — two small additions, no unrelated changes
- **Regression risk**: Very low — not returning a rate-limited TXQ is
  correct; the rescheduling on tx completion ensures it gets re-added
  when appropriate

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- `mt76_tx_check_non_aql()` — core logic introduced by `e1378e5228aaa1`
  (Felix Fietkau, 2020-08-23), refactored in `0fe88644c06063`
  (2021-05-07)
- `mt76_txq_schedule_list()` — scheduling loop from `17f1de56df0512`
  (2017-11-21), with non-AQL logic from `e1378e5228aaa1`
- The non-AQL mechanism itself was introduced in commit `e1378e5228aaa1`
  which first appeared in **v5.10-rc1**

### Step 3.2: Fixes Tag
No Fixes: tag present. However, the bug was effectively introduced by
`e1378e5228aaa1` ("mt76: rely on AQL for burst size limits on tx
queueing") in v5.10-rc1.

### Step 3.3: File History
- `tx.c` has had 19 commits since v6.1, including multi-radio support
  (`716cc146d5805`, Jan 2025) and wcid pointer wrapper (`dc66a129adf1f`,
  Jul 2025)
- This patch is standalone — not part of a series

### Step 3.4: Author
- David Bauer: occasional mt76 contributor (5 commits found), has worked
  on mt7915 MCU and other mt76 issues
- Felix Fietkau: mt76 subsystem maintainer who reviewed and merged this

### Step 3.5: Dependencies
- The `continue` in scheduling loop follows the existing pattern (PS
  flag, reset state already use `continue`)
- The rescheduling uses `ieee80211_schedule_txq()` — available since
  mac80211 TXQ API inception
- `wcid_to_sta()` — fundamental mt76 helper, present in all trees
- Minor adaptations needed for older trees (e.g., `__mt76_wcid_ptr` vs
  `rcu_dereference`)

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1–4.5
b4 dig couldn't find the message-id, and lore.kernel.org is blocking
automated access. The patch link is
`https://patch.msgid.link/20260129232321.276575-1-mail@david-bauer.net`.
It was merged by Felix Fietkau (mt76 maintainer), which provides strong
implicit review. No NAKs or objections were found.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
1. `mt76_tx_check_non_aql()` — called from `__mt76_tx_complete_skb()` on
   every TX completion
2. `mt76_txq_schedule_list()` — core TX scheduling loop, called from
   `mt76_txq_schedule()`

### Step 5.2: Callers
- `mt76_tx_check_non_aql()` → called from `__mt76_tx_complete_skb()`
  which is the main TX completion path for ALL mt76 drivers
- `mt76_txq_schedule_list()` → called from `mt76_txq_schedule()` →
  `mt76_txq_schedule_all()` → `mt76_tx_worker_run()` — the main TX
  worker

### Step 5.3–5.4: Call Chain
TX completion path: hardware IRQ → driver tx_complete →
`__mt76_tx_complete_skb()` → `mt76_tx_check_non_aql()` → (new)
`ieee80211_schedule_txq()`. This is a very hot, commonly-exercised path.

### Step 5.5: Similar Patterns
The existing `continue` statements in `mt76_txq_schedule_list()` for PS
flag and reset state already follow the exact same pattern of skipping
TXQs without returning them.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable
The non-AQL mechanism (`e1378e5228aaa1`) was introduced in v5.10-rc1.
All active stable trees (5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y) contain
the buggy code.

### Step 6.2: Backport Complications
- The multi-radio refactoring (`716cc146d5805`, Jan 2025) and wcid_ptr
  wrapper (`dc66a129adf1f`, Jul 2025) are post-6.12
- Older trees will need minor adaptation (e.g., different wcid lookup
  syntax)
- The core logical change applies cleanly to all trees conceptually

### Step 6.3: No Related Fixes in Stable
No existing fix for this scheduling starvation issue was found in
stable.

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: `drivers/net/wireless/mediatek/mt76` — one of the most
  widely-used WiFi driver families in Linux
- **Criticality**: IMPORTANT — mt76 covers MT7603, MT7615, MT7915,
  MT7921, MT7996 chipsets used in routers, laptops, and access points
- This affects ALL mt76 devices, not just a specific chipset

### Step 7.2: Subsystem Activity
Active development — 30 commits in recent history for tx.c alone.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users of mt76 WiFi hardware (very broad: routers, embedded systems,
laptops). mt76 is one of the most popular WiFi driver families in the
Linux kernel.

### Step 8.2: Trigger Conditions
- Trigger: Multiple STAs connected, one STA hitting the non-AQL packet
  limit (common during bursts before rate control information is
  available, or under load)
- With airtime fairness enabled (default in many configurations):
  immediate starvation of all other STAs in the same AC
- Very likely to trigger in multi-client AP scenarios (routers, access
  points)

### Step 8.3: Failure Mode Severity
- **Failure mode**: High latency, low throughput, or broken connections
  for affected STAs
- **Severity**: HIGH — loss of connectivity/severe degradation for WiFi
  clients in multi-client scenarios

### Step 8.4: Risk-Benefit
- **Benefit**: HIGH — fixes scheduling starvation affecting all mt76
  users with multiple clients
- **Risk**: VERY LOW — ~20 lines, follows existing patterns, single
  file, obviously correct, merged by subsystem maintainer
- **Ratio**: Strongly favorable for backporting

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary
**FOR backporting:**
- Fixes a real, user-visible bug (high latency, broken connections)
- Affects all mt76 WiFi users with multiple clients — very broad impact
- Small, surgical fix (~20 lines, single file)
- Follows existing code patterns (`continue` for TXQ skipping)
- Merged by subsystem maintainer (Felix Fietkau)
- Bug exists in all stable trees since v5.10
- No regression risk — the fix is obviously correct

**AGAINST backporting:**
- No Fixes: tag or Cc: stable (expected)
- Minor adaptation needed for older trees due to intermediate
  refactoring
- No syzbot/KASAN report (this is a logic/scheduling bug, not memory
  safety)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — merged by maintainer, follows
   established patterns
2. Fixes a real bug? **YES** — scheduling starvation causing high
   latency/broken connections
3. Important issue? **YES** — connectivity loss for WiFi clients in
   common multi-client scenarios
4. Small and contained? **YES** — ~20 lines, single file, two functions
5. No new features or APIs? **YES** — no new features
6. Can apply to stable? **YES** — with minor adaptation for older trees

### Step 9.3: Exception Categories
Not an exception category — this is a standard bug fix.

### Step 9.4: Decision
This is a clear bug fix for a significant scheduling starvation issue in
the mt76 WiFi driver. The fix is small, obviously correct, and addresses
a real user-visible problem (high latency, low throughput, broken
connections) that affects all mt76 WiFi users in multi-client scenarios.

## Verification

- [Phase 1] Parsed tags: Signed-off-by David Bauer (author) and Felix
  Fietkau (maintainer/committer), Link to patch.msgid.link
- [Phase 2] Diff analysis: ~20 lines added in two functions in tx.c;
  adds non-AQL limit check in scheduling loop + TXQ rescheduling on tx
  completion
- [Phase 2] Verified `ieee80211_return_txq()` calls
  `__ieee80211_schedule_txq()` which re-inserts at head with airtime
  fairness (net/mac80211/tx.c lines 4116-4151)
- [Phase 2] Verified `ieee80211_next_txq()` terminates round when seeing
  same TXQ's schedule_round (net/mac80211/tx.c lines 4103-4104)
- [Phase 3] git blame: non-AQL logic introduced in e1378e5228aaa1
  (2020-08-23), first in v5.10-rc1
- [Phase 3] git describe: confirmed e1378e5228aaa1 is
  `v5.10-rc1~107^2~150^2~2^2~34`
- [Phase 3] Existing `continue` pattern verified in
  mt76_txq_schedule_list() for PS flag (line 542-543) and reset state
  (line 546-547)
- [Phase 3] No dependent patches found; this is standalone
- [Phase 4] b4 dig: could not find match; lore blocked by anti-scraping
- [Phase 5] mt76_tx_check_non_aql called from __mt76_tx_complete_skb
  (hot TX completion path, line 255)
- [Phase 5] mt76_txq_schedule_list called from mt76_txq_schedule →
  mt76_txq_schedule_all → mt76_tx_worker_run (main TX worker)
- [Phase 6] Bug present in all stable trees 5.10.y through 6.12.y
  (e1378e5228aaa1 in v5.10-rc1)
- [Phase 6] Backport needs minor adaptation for multi-radio refactoring
  (716cc146d5805) and wcid_ptr wrapper (dc66a129adf1f)
- [Phase 8] Failure mode: scheduling starvation → high latency/broken
  connections; severity HIGH
- UNVERIFIED: Exact mailing list review discussion (lore blocked);
  however, maintainer merge provides implicit review confirmation

**YES**

 drivers/net/wireless/mediatek/mt76/tx.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 9ec6d0b53a84a..0753acf2eccb8 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -227,7 +227,9 @@ mt76_tx_check_non_aql(struct mt76_dev *dev, struct mt76_wcid *wcid,
 		      struct sk_buff *skb)
 {
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+	struct ieee80211_sta *sta;
 	int pending;
+	int i;
 
 	if (!wcid || info->tx_time_est)
 		return;
@@ -235,6 +237,17 @@ mt76_tx_check_non_aql(struct mt76_dev *dev, struct mt76_wcid *wcid,
 	pending = atomic_dec_return(&wcid->non_aql_packets);
 	if (pending < 0)
 		atomic_cmpxchg(&wcid->non_aql_packets, pending, 0);
+
+	sta = wcid_to_sta(wcid);
+	if (!sta || pending != MT_MAX_NON_AQL_PKT - 1)
+		return;
+
+	for (i = 0; i < ARRAY_SIZE(sta->txq); i++) {
+		if (!sta->txq[i])
+			continue;
+
+		ieee80211_schedule_txq(dev->hw, sta->txq[i]);
+	}
 }
 
 void __mt76_tx_complete_skb(struct mt76_dev *dev, u16 wcid_idx, struct sk_buff *skb,
@@ -542,6 +555,9 @@ mt76_txq_schedule_list(struct mt76_phy *phy, enum mt76_txq_id qid)
 		if (!wcid || test_bit(MT_WCID_FLAG_PS, &wcid->flags))
 			continue;
 
+		if (atomic_read(&wcid->non_aql_packets) >= MT_MAX_NON_AQL_PKT)
+			continue;
+
 		phy = mt76_dev_phy(dev, wcid->phy_idx);
 		if (test_bit(MT76_RESET, &phy->state) || phy->offchannel)
 			continue;
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: imx91-tqma9131: improve eMMC pad configuration

[Sasha Levin]

From: Markus Niebel <Markus.Niebel@ew.tq-group.com>

[ Upstream commit 44db7bc66eb38e85bb32777c5fd3a4e7baa84147 ]

Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve
stability and detection at low temperatures under -25°C.

Fixes: e71db39f0c7c ("arm64: dts: freescale: add initial device tree for TQMa91xx/MBa91xxCA")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 .../boot/dts/freescale/imx91-tqma9131.dtsi    | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi b/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
index 5792952b7a8e1..c99d7bc168483 100644
--- a/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
@@ -272,20 +272,20 @@ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
 	/* enable SION for data and cmd pad due to ERR052021 */
 	pinctrl_usdhc1: usdhc1grp {
 		fsl,pins = /* PD | FSEL 3 | DSE X5 */
-			   <MX91_PAD_SD1_CLK__USDHC1_CLK		0x5be>,
+			   <MX91_PAD_SD1_CLK__USDHC1_CLK		0x59e>,
 			   /* HYS | FSEL 0 | no drive */
 			   <MX91_PAD_SD1_STROBE__USDHC1_STROBE		0x1000>,
 			   /* HYS | FSEL 3 | X5 */
-			   <MX91_PAD_SD1_CMD__USDHC1_CMD		0x400011be>,
+			   <MX91_PAD_SD1_CMD__USDHC1_CMD		0x4000139e>,
 			   /* HYS | FSEL 3 | X4 */
-			   <MX91_PAD_SD1_DATA0__USDHC1_DATA0		0x4000119e>,
-			   <MX91_PAD_SD1_DATA1__USDHC1_DATA1		0x4000119e>,
-			   <MX91_PAD_SD1_DATA2__USDHC1_DATA2		0x4000119e>,
-			   <MX91_PAD_SD1_DATA3__USDHC1_DATA3		0x4000119e>,
-			   <MX91_PAD_SD1_DATA4__USDHC1_DATA4		0x4000119e>,
-			   <MX91_PAD_SD1_DATA5__USDHC1_DATA5		0x4000119e>,
-			   <MX91_PAD_SD1_DATA6__USDHC1_DATA6		0x4000119e>,
-			   <MX91_PAD_SD1_DATA7__USDHC1_DATA7		0x4000119e>;
+			   <MX91_PAD_SD1_DATA0__USDHC1_DATA0		0x4000139e>,
+			   <MX91_PAD_SD1_DATA1__USDHC1_DATA1		0x4000139e>,
+			   <MX91_PAD_SD1_DATA2__USDHC1_DATA2		0x4000139e>,
+			   <MX91_PAD_SD1_DATA3__USDHC1_DATA3		0x4000139e>,
+			   <MX91_PAD_SD1_DATA4__USDHC1_DATA4		0x4000139e>,
+			   <MX91_PAD_SD1_DATA5__USDHC1_DATA5		0x4000139e>,
+			   <MX91_PAD_SD1_DATA6__USDHC1_DATA6		0x4000139e>,
+			   <MX91_PAD_SD1_DATA7__USDHC1_DATA7		0x4000139e>;
 	};
 
 	pinctrl_wdog: wdoggrp {
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] mmc: sdhci-esdhc-imx: wait for data transfer completion before reset

[Sasha Levin]

From: Luke Wang <ziniu.wang_1@nxp.com>

[ Upstream commit 8ceb70c9f970bfbdceb1e51578850a60b9de2236 ]

On IMX7ULP platforms, certain SD cards (e.g. Kingston Canvas Go! Plus)
cause system hangs and reboots during manual tuning. These cards exhibit
large gaps (~16us) between tuning command response and data transmission.
When cmd CRC errors occur during tuning, the code assumes data errors even
tuning data hasn't been fully received and then reset host data circuit.

Per IMX7ULP reference manual, reset operations (RESET_DATA/ALL) need to
make sure no active data transfers. Previously, resetting while data was
in-flight would clear data circuit, including ADMA/SDMA address, causing
data to be transmitted to incorrect memory address. This patch adds
polling for data transfer completion before executing resets.

Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Bough Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile the final assessment.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `mmc: sdhci-esdhc-imx:` (MMC host controller driver for
  NXP i.MX ESDHC)
- **Action verb**: "wait" (defensive/preventive action)
- **Summary**: Wait for data transfer completion before resetting the
  host data circuit to avoid system hang.

Record: [mmc: sdhci-esdhc-imx] [wait/prevent] [Prevent system hang by
ensuring data transfer is complete before reset]

### Step 1.2: Tags
- **Signed-off-by**: Luke Wang <ziniu.wang_1@nxp.com> (author, NXP
  engineer)
- **Reviewed-by**: Bough Chen <haibo.chen@nxp.com> (NXP subsystem
  maintainer for sdhci-esdhc-imx, prolific contributor)
- **Acked-by**: Adrian Hunter <adrian.hunter@intel.com> (senior
  SDHCI/MMC subsystem maintainer)
- **Signed-off-by**: Ulf Hansson <ulf.hansson@linaro.org> (MMC subsystem
  maintainer who merged this)
- No Fixes: tag (expected for autosel candidates)
- No Cc: stable (expected)
- No Link: tag

Record: Reviewed by NXP subsystem expert (haibo.chen), ACK'd by sdhci
co-maintainer (Adrian Hunter), merged by MMC maintainer (Ulf Hansson).
Strong review chain.

### Step 1.3: Body Analysis
- **Bug**: On IMX7ULP platforms, certain SD cards (Kingston Canvas Go!
  Plus) cause **system hangs and reboots** during manual tuning.
- **Root cause**: Large gaps (~16us) between tuning command response and
  data transmission. When CRC errors occur during tuning, code resets
  the host data circuit while data is still in-flight.
- **Failure mechanism**: Per IMX7ULP reference manual,
  RESET_DATA/RESET_ALL must not be issued during active data transfer.
  Resetting while data is in-flight clears the data circuit including
  ADMA/SDMA address, causing **data to be transmitted to incorrect
  memory address**.
- **Symptom**: System hang and reboot.

Record: Critical bug - system hang/reboot. DMA address corruption from
reset during active transfer. Hardware-documented requirement violated.
Specific SD card makes the timing gap visible.

### Step 1.4: Hidden Bug Fix Detection
This is NOT hidden - it's an explicit fix for system hangs. The commit
clearly describes a hardware requirement (per reference manual) that was
being violated, leading to DMA address corruption and system hangs.

Record: Explicit bug fix - system hang prevention. Not a disguised fix.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 file (`drivers/mmc/host/sdhci-esdhc-imx.c`)
- **Lines added**: ~18 (2 for the define, 16 for the polling logic)
- **Lines removed**: 0
- **Functions modified**: `esdhc_reset()` - the core reset callback for
  this driver
- **Scope**: Single-file, single-function, surgical fix

Record: [sdhci-esdhc-imx.c +18/-0] [esdhc_reset() modified] [Single-file
surgical fix]

### Step 2.2: Code Flow Change
1. **New define**: `ESDHC_DATA_INHIBIT_WAIT_US 100000` (100ms timeout)
2. **Before**: `esdhc_reset()` directly called `sdhci_and_cqhci_reset()`
   without checking data transfer state
3. **After**: Before reset, if the reset mask includes
   `SDHCI_RESET_DATA` or `SDHCI_RESET_ALL`, poll `ESDHC_PRSSTAT`
   register waiting for `SDHCI_DATA_INHIBIT` to clear (indicating no
   active data transfer). Timeout at 100ms with a warning. Then proceed
   to reset.

Record: Added defensive wait-for-idle before data/full reset. 100ms
timeout with warning on failure. Non-blocking (proceeds even on
timeout).

### Step 2.3: Bug Mechanism
Category: **Hardware workaround / DMA corruption fix**
- The bug is a violation of hardware specification requirements (IMX7ULP
  reference manual)
- Resetting while `SDHCI_DATA_INHIBIT` is set clears ADMA/SDMA addresses
  mid-transfer
- Data goes to wrong memory address → system hang/reboot (effectively
  memory corruption)
- The fix polls the Present State register bit 1 (DATA_INHIBIT) before
  issuing reset
- Uses `readl_poll_timeout_atomic` with 2us polling interval and 100ms
  max wait

Record: [HW requirement violation → DMA address corruption → system
hang] [Fix: poll for data idle before reset]

### Step 2.4: Fix Quality
- **Obviously correct**: Yes. The reference manual explicitly requires
  waiting. The pattern of polling ESDHC_PRSSTAT is already used twice in
  this driver (lines 471, 1028).
- **Minimal/surgical**: Yes. Only adds the required wait before existing
  reset call.
- **Regression risk**: Very low. On timeout, it warns but still proceeds
  with reset (graceful degradation). The 100ms timeout is generous.
  Using `readl_poll_timeout_atomic` is appropriate since reset can be
  called from interrupt context.
- **Red flags**: None. Well-contained, uses established patterns from
  the same driver.

Record: High quality fix. Uses existing driver patterns. Graceful
timeout handling. Minimal regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- `esdhc_reset()` introduced in commit `0718e59ae259f7` by Russell King
  (2014-04-25), present since ~v3.16
- Modified by `fb1dec44c6750b` (Brian Norris, 2022-10-26) to use
  `sdhci_and_cqhci_reset`, present since v6.2
- The function has been stable in its current form since v6.2

Record: esdhc_reset() has existed since v3.16 (2014). Current form since
v6.2. Bug has been present since the function was introduced - the
hardware requirement was never respected.

### Step 3.2: No Fixes: tag present (expected).

### Step 3.3: File History
Recent changes to the file are mostly tuning-related fixes (manual
tuning, clock loopback, PM refactoring). The `esdhc_reset()` function
itself hasn't been touched recently (last change was the cqhci fix in
2022).

Record: No prerequisites identified. The fix is standalone.

### Step 3.4: Author
Luke Wang (ziniu.wang_1@nxp.com) is a regular NXP contributor with 14+
commits in the MMC subsystem and sdhci-esdhc-imx driver specifically.
He's contributed tuning improvements, PM refactoring, and other driver
fixes.

Record: Regular subsystem contributor from the hardware vendor (NXP).

### Step 3.5: Dependencies
- Uses `readl_poll_timeout_atomic` from `<linux/iopoll.h>` - already
  included in all stable versions
- Uses `ESDHC_PRSSTAT` and `SDHCI_DATA_INHIBIT` - both already defined
- Uses `SDHCI_RESET_DATA` and `SDHCI_RESET_ALL` - standard SDHCI defines
- Only dependency: `sdhci_and_cqhci_reset` (present since v6.2). For
  v5.15, the function uses `sdhci_reset` instead - minor backport
  adjustment needed.

Record: Fully standalone for v6.1+. Minor adjustment needed for v5.15
(different reset function name). All APIs/macros already available.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.5
I was unable to find the specific mailing list thread for this patch via
b4 dig (commit not in tree) or web searches. The patch was found
indirectly via the "1-bit bus width" series which built on top of the
file state after this patch was applied (blob `97461e20425d`).

The commit has strong review signals:
- **Reviewed-by** from Bough Chen (NXP maintainer of this driver, 30+
  commits)
- **Acked-by** from Adrian Hunter (SDHCI co-maintainer, 100+ SDHCI
  commits)
- **Signed-off-by** from Ulf Hansson (MMC subsystem maintainer who
  merged it)

Record: Could not find lore thread directly (commit not yet in tree).
But review chain is complete: hardware vendor reviewer + SDHCI
maintainer ACK + subsystem maintainer merge.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
- `esdhc_reset()` - the `.reset` callback in `sdhci_esdhc_ops`

### Step 5.2: Callers
`esdhc_reset` is called via `sdhci_do_reset()` (line 247 of sdhci.c)
through the ops->reset function pointer. `sdhci_do_reset` is called
from:
- `sdhci_reset_for_all()` - init, suspend/resume paths (SDHCI_RESET_ALL)
- `sdhci_reset_for_reason()` - error recovery, tuning abort, card
  removal, CQE recovery (SDHCI_RESET_CMD, SDHCI_RESET_DATA)
- These are called from tuning abort, data error paths, card removal,
  CQE recovery, and initialization

The fix specifically triggers on `SDHCI_RESET_DATA | SDHCI_RESET_ALL`,
which covers error recovery (data errors, request errors) and full
initialization.

Record: Called from multiple critical paths - error recovery, tuning
abort, card removal, init. High-traffic code path.

### Step 5.3-5.4: The affected code path is triggered during normal card
operations (tuning, error recovery). Any user of an i.MX SDHCI host
controller can trigger this.

### Step 5.5: Similar Patterns
The Freescale ESDHC of-driver (`sdhci-of-esdhc.c`) has a separate
`quirk_ignore_data_inhibit` for unreliable DATA_INHIBIT bits on some
controllers. The `readl_poll_timeout` pattern is already used twice in
this same driver for similar hardware waits.

Record: Pattern is consistent with existing driver practices.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
- `esdhc_reset()` exists in **all stable trees** (v5.15, v6.1, v6.6,
  v6.12, v6.19)
- The bug has been present since the function was introduced in v3.16
  (2014)
- IMX7ULP support was added before v5.15

Record: Bug exists in ALL active stable trees.

### Step 6.2: Backport Complications
- For v6.1, v6.6, v6.12, v6.19: Patch applies cleanly. `esdhc_reset()`
  is identical.
- For v5.15: Minor adjustment needed - function calls `sdhci_reset()`
  instead of `sdhci_and_cqhci_reset()`, but the added code goes BEFORE
  that call, so it's unaffected.

Record: Clean apply for v6.1+. Trivial adjustment for v5.15.

### Step 6.3: No related fixes already in stable for this issue.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1
- **Subsystem**: drivers/mmc/host - MMC host controller drivers
- **Criticality**: IMPORTANT - MMC/SD cards are used for storage on
  embedded platforms, IoT devices, and Android devices running i.MX
  SoCs. System hangs on these platforms = production device failure.

### Step 7.2
The sdhci-esdhc-imx driver is actively maintained by NXP engineers. 28
changes between v6.6 and v6.19.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Population
- Users of NXP i.MX SoCs with SDHCI host controllers (IMX7ULP
  specifically named, but the fix applies to all i.MX ESDHC variants)
- Embedded/IoT devices, industrial controllers, automotive platforms
  using NXP i.MX chips
- The bug is triggered with specific SD cards (Kingston Canvas Go! Plus
  mentioned) during tuning

### Step 8.2: Trigger Conditions
- Occurs during SD card tuning (happens on card initialization/re-
  initialization)
- Triggered when CRC errors occur during tuning while data has gaps in
  transmission
- Not every card triggers it - depends on card timing characteristics
- Can happen on any boot/card insertion with affected cards

### Step 8.3: Failure Mode Severity
- **System hang and reboot** = CRITICAL
- DMA writes to incorrect memory address = potential **memory
  corruption**
- The reset clears ADMA/SDMA addresses, so DMA writes to address 0 or
  stale address
- This is a hardware-documented requirement violation

Record: CRITICAL severity. System hang, reboot, potential memory
corruption.

### Step 8.4: Risk-Benefit Ratio
- **BENEFIT**: HIGH - prevents system hangs/reboots on NXP i.MX
  platforms with certain SD cards
- **RISK**: VERY LOW
  - ~18 lines added, single function, single file
  - Uses existing patterns from the same driver
  - Graceful timeout (warning + proceed) prevents any new hangs from the
    fix itself
  - `readl_poll_timeout_atomic` is safe for all calling contexts
  - Only adds a wait before an existing operation

Record: HIGH benefit / VERY LOW risk. Strongly favorable ratio.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
1. Fixes **system hangs and reboots** (CRITICAL severity)
2. Fixes **DMA address corruption** from violating hardware
   specification
3. Small, surgical fix (~18 lines in one function, one file)
4. Uses existing patterns from the same driver (`readl_poll_timeout`)
5. Reviewed by NXP driver maintainer (haibo.chen), ACK'd by SDHCI co-
   maintainer (Adrian Hunter), merged by MMC maintainer (Ulf Hansson)
6. Author is NXP engineer with deep knowledge of the hardware
7. Bug exists in ALL active stable trees (code unchanged since v6.2)
8. Patch applies cleanly to v6.1+ with no modifications needed
9. Graceful degradation on timeout (warn + continue)
10. References hardware reference manual as justification

**AGAINST backporting:**
- No concrete signals against. The fix is well-contained and low-risk.

**UNRESOLVED:**
- Could not find the original lore thread (commit appears very
  recent/not yet merged)
- No Fixes: tag identifying original buggy commit (but bug has existed
  since 2014)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES - follows hardware manual
   requirement, reviewed by 3 maintainers, uses established driver
   patterns
2. **Fixes a real bug?** YES - system hangs and reboots on real hardware
   with real SD cards
3. **Important issue?** YES - system hang, reboot, DMA corruption =
   CRITICAL
4. **Small and contained?** YES - ~18 lines, single function, single
   file
5. **No new features/APIs?** CORRECT - no new features, just defensive
   hardware wait
6. **Can apply to stable?** YES - applies cleanly to v6.1+, minor
   adjustment for v5.15

### Step 9.3: Exception Categories
Not needed - this meets standard stable criteria as a critical bug fix.

### Step 9.4: Decision
This is a clear YES. It fixes a **critical** system hang/reboot caused
by violating a hardware-documented requirement, with a small, surgical,
well-reviewed patch that carries minimal regression risk.

## Verification

- [Phase 1] Parsed tags: Reviewed-by: haibo.chen (NXP), Acked-by: Adrian
  Hunter (SDHCI maintainer), SOB: Ulf Hansson (MMC maintainer)
- [Phase 2] Diff analysis: ~18 lines added to `esdhc_reset()`, adds
  `readl_poll_timeout_atomic` for DATA_INHIBIT before reset
- [Phase 2] Verified `readl_poll_timeout_atomic` is defined in
  `include/linux/iopoll.h` (line 230)
- [Phase 2] Verified `ESDHC_PRSSTAT` defined at offset 0x24 in `sdhci-
  esdhc.h` (line 34), same as `SDHCI_PRESENT_STATE`
- [Phase 2] Verified `SDHCI_DATA_INHIBIT` is 0x00000002 at `sdhci.h:82`
- [Phase 3] git blame: `esdhc_reset()` introduced in `0718e59ae259f7`
  (2014), modified by `fb1dec44c6750b` (2022)
- [Phase 3] Confirmed `sdhci_and_cqhci_reset` present in v6.1 and v6.6
  via `git merge-base --is-ancestor`
- [Phase 3] Confirmed `esdhc_reset()` in v6.1 and v6.6 is identical to
  current mainline (before this patch)
- [Phase 3] Author Luke Wang has 14+ commits in MMC subsystem, regular
  NXP contributor
- [Phase 3] No prerequisites identified - patch is standalone
- [Phase 4] b4 dig could not find thread (commit not in tree). Web
  searches confirmed author's other patches and expertise.
- [Phase 5] `esdhc_reset` called via `sdhci_do_reset()` from error
  recovery, tuning abort, init, CQE recovery paths
- [Phase 5] `readl_poll_timeout` pattern already used twice in this
  driver (lines 471, 1028)
- [Phase 6] Confirmed `esdhc_reset()` exists identically in v6.1 and
  v6.6 stable trees
- [Phase 6] Confirmed `<linux/iopoll.h>` is included in v6.1 (verified
  directly)
- [Phase 6] For v5.15, `esdhc_reset` uses `sdhci_reset()` instead -
  minor backport adjustment needed
- [Phase 7] IMX7ULP support (`usdhc_imx7ulp_data`) present in driver,
  confirmed at line 324
- [Phase 8] Failure mode: system hang + reboot + DMA address corruption
  → CRITICAL severity
- UNVERIFIED: Could not access the original lore thread for this
  specific patch

**YES**

 drivers/mmc/host/sdhci-esdhc-imx.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index a7a5df673b0f6..97461e20425d8 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -216,6 +216,8 @@
 #define ESDHC_FLAG_DUMMY_PAD		BIT(19)
 
 #define ESDHC_AUTO_TUNING_WINDOW	3
+/* 100ms timeout for data inhibit */
+#define ESDHC_DATA_INHIBIT_WAIT_US	100000
 
 enum wp_types {
 	ESDHC_WP_NONE,		/* no WP, neither controller nor gpio */
@@ -1453,6 +1455,22 @@ static void esdhc_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
 
 static void esdhc_reset(struct sdhci_host *host, u8 mask)
 {
+	u32 present_state;
+	int ret;
+
+	/*
+	 * For data or full reset, ensure any active data transfer completes
+	 * before resetting to avoid system hang.
+	 */
+	if (mask & (SDHCI_RESET_DATA | SDHCI_RESET_ALL)) {
+		ret = readl_poll_timeout_atomic(host->ioaddr + ESDHC_PRSSTAT, present_state,
+						!(present_state & SDHCI_DATA_INHIBIT), 2,
+						ESDHC_DATA_INHIBIT_WAIT_US);
+		if (ret == -ETIMEDOUT)
+			dev_warn(mmc_dev(host->mmc),
+				 "timeout waiting for data transfer completion\n");
+	}
+
 	sdhci_and_cqhci_reset(host, mask);
 
 	sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] media: rc: fix race between unregister and urb/irq callbacks

[Sasha Levin]

From: Sean Young <sean@mess.org>

[ Upstream commit dccc0c3ddf8f16071736f98a7d6dd46a2d43e037 ]

Some rc device drivers have a race condition between rc_unregister_device()
and irq or urb callbacks. This is because rc_unregister_device() does two
things, it marks the device as unregistered so no new commands can be
issued and then it calls rc_free_device(). This means the driver has no
chance to cancel any pending urb callbacks or interrupts after the device
has been marked as unregistered. Those callbacks may access struct rc_dev
or its members (e.g. struct ir_raw_event_ctrl), which have been freed by
rc_free_device().

This change removes the implicit call to rc_free_device() from
rc_unregister_device(). This means that device drivers can call
rc_unregister_device() in their remove or disconnect function, then cancel
all the urbs and interrupts before explicitly calling rc_free_device().

Note this is an alternative fix for an issue found by Haotian Zhang, see
the Closes: tags.

Reported-by: Haotian Zhang <vulab@iscas.ac.cn>
Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Good - drivers using `devm_rc_allocate_device` don't call
`rc_unregister_device` manually (they use `devm_rc_register_device`
which handles cleanup automatically). The patch removes the
`managed_alloc` flag because it changes the contract:
`rc_unregister_device` no longer frees the device regardless of how it
was allocated. Instead, `devm_rc_alloc_release` (the devres release
callback) calls `rc_free_device`, and the regular drivers must add
explicit `rc_free_device` calls.

Now let me do the full analysis write-up.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [media: rc] [fix] [race between unregister and urb/irq
callbacks]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reported-by:** Haotian Zhang <vulab@iscas.ac.cn> - the reporter
  found multiple race conditions
- **Closes:** 4 separate lore.kernel.org links to bug reports (Nov 2025)
- **Reviewed-by:** Patrice Chotard <patrice.chotard@foss.st.com>
- **Signed-off-by:** Sean Young <sean@mess.org> (author, RC subsystem
  maintainer)
- **Signed-off-by:** Hans Verkuil <hverkuil+cisco@kernel.org> (media
  subsystem maintainer)

Record: Multiple bug reports (4 Closes: tags), reviewed by a maintainer,
written by the RC subsystem maintainer, merged by the media subsystem
maintainer. No Fixes: tag (expected).

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit explains a **use-after-free race condition**:
1. `rc_unregister_device()` marks the device as unregistered
2. Then it calls `rc_free_device()`, which frees `struct rc_dev` and
   `struct ir_raw_event_ctrl`
3. Between marking unregistered and freeing, there's no window for
   drivers to cancel pending URBs/IRQs
4. Those pending callbacks may still access the freed `struct rc_dev` or
   its members

Record: Bug = use-after-free due to race between device unregister and
URB/IRQ callbacks. Symptom = accessing freed memory. Root cause =
`rc_unregister_device()` implicitly calls `rc_free_device()` before
drivers can cancel pending async operations.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is an explicit race condition / use-after-free fix. Not hidden.
Record: This is a clear, well-documented bug fix.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
41 files changed, ~58 insertions, ~36 deletions. Files span:
- Core: `rc-main.c`, `rc-ir-raw.c`, `rc-core.h`
- ~30+ driver files across media/rc, media/pci, media/usb, gpu/drm, hid,
  staging

Record: Cross-subsystem change touching 41 files, but each driver change
is 1-3 lines. Core changes are ~10 lines net.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Core changes:**
1. `rc-main.c`: `rc_unregister_device()` no longer calls
   `rc_free_device()` (removes the `if (!dev->managed_alloc)
   rc_free_device(dev)` block)
2. `rc-main.c`: `rc_dev_release()` now calls `ir_raw_event_free(dev)`
   before `kfree(dev)` - this ensures raw event data is cleaned up when
   the device struct is finally freed
3. `rc-main.c`: `devm_rc_allocate_device()` no longer sets
   `managed_alloc = true`
4. `rc-ir-raw.c`: `ir_raw_event_unregister()` no longer calls
   `ir_raw_event_free()` (moved to `rc_dev_release`)
5. `rc-ir-raw.c`: `ir_raw_event_free()` removes the `if (!dev)` guard
   (now only called from `rc_dev_release`)
6. `rc-core.h`: Removes `managed_alloc` field from `struct rc_dev`

**Driver changes:** Every driver using `rc_unregister_device()` now also
calls `rc_free_device()` afterward. Some USB drivers also reorder
operations to call `rc_unregister_device()` BEFORE killing URBs, then
`rc_free_device()` AFTER killing URBs.

### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Race condition / Use-after-free**

Before the fix:
```
rc_unregister_device()
  -> marks device unregistered
  -> calls rc_free_device() -> frees struct rc_dev
  // URB/IRQ callbacks can still fire and access freed rc_dev!
```

After the fix:
```
rc_unregister_device()
  -> marks device unregistered
  // Driver cancels URBs/IRQs here
rc_free_device()
  -> safely frees struct rc_dev after all callbacks cancelled
```

Record: UAF race condition fix. Separating unregister from free gives
drivers a window to cancel async operations.

### Step 2.4: ASSESS THE FIX QUALITY
- Written by Sean Young (RC subsystem maintainer)
- Reviewed by Patrice Chotard
- Merged by Hans Verkuil (media maintainer)
- The approach is sound: it separates two concerns (marking unregistered
  vs. freeing memory)
- Each per-driver change is trivial (add one `rc_free_device()` line)
- **Concern:** The scope is very large (41 files), though each change is
  trivially mechanical

Record: High quality fix from the subsystem maintainer. Regression risk
is low per-driver but the sheer breadth is notable. The error path
changes in probe functions (removing `rdev = NULL` after
`rc_unregister_device`) are now correct because `rc_free_device(rdev)`
on the next goto target will properly free even after unregister.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The `managed_alloc` logic was introduced in commit `ddbf7d5a698c4d`
(2016, v4.10 era) by Heiner Kallweit. The implicit `rc_free_device()`
call in `rc_unregister_device()` has been present since `d8b4b5822f51e2`
(2010, v2.6.36 era). The race condition has existed since the very
beginning of the rc_core subsystem.

Record: Bug exists in all kernel versions since 2010 (v2.6.36+). Present
in all stable trees.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected for autosel candidates).

### Step 3.3: CHECK FILE HISTORY
Multiple previous fixes for the same class of UAF bugs exist:
- `5abda7a16698d` "media: dm1105: Fix use after free bug in
  dm1105_remove due to race condition"
- `29b0589a865b6` "media: rc: Fix use-after-free bugs caused by
  ene_tx_irqsim()"

These were individual driver fixes for the same systemic issue. This
patch fixes it once and for all in the core.

Record: This is a systemic fix replacing multiple individual driver-
level workarounds.

### Step 3.4: CHECK THE AUTHOR
Sean Young is the RC subsystem maintainer. He has dozens of commits in
`drivers/media/rc/`. This is his subsystem.

Record: Author is the subsystem maintainer - highest trust level.

### Step 3.5: CHECK FOR DEPENDENCIES
This is a single, self-contained patch. All changes are coordinated. No
other patches are needed.

Record: Standalone fix, no dependencies.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Found via web search:
- v1: "[PATCH] media: rc: rc_unregister_device() should not call
  rc_free_device()" (Dec 20, 2025)
- v2: "[PATCH v2] media: rc: fix race between unregister and urb/irq
  callbacks" (Jan 26, 2026)

The v2 has the `Reviewed-by` tag from Patrice Chotard that v1 didn't
have.

Record: Patch went through 2 revisions. Applied version is v2 (latest).
Reviewed by maintainer.

### Step 4.2: WHO REVIEWED
- Reviewed-by: Patrice Chotard (STMicroelectronics, works on st_rc
  driver)
- Signed-off-by: Hans Verkuil (media subsystem co-maintainer)
- CC'd: Numerous subsystem maintainers (Maarten Lankhorst, David Airlie
  for DRM, etc.)

Record: Properly reviewed through the maintainer chain.

### Step 4.3: SEARCH FOR THE BUG REPORT
4 separate bug reports from Haotian Zhang (November 2025) about UAF
races in different RC drivers.

Record: Multiple independent bug reports confirm this is a real-world
issue.

### Step 4.4: RELATED PATCHES
This is the alternative/comprehensive fix. The original individual
patches from Haotian Zhang addressed each driver separately; Sean
Young's approach fixes the root cause in the core.

Record: This is the definitive fix rather than per-driver workarounds.

### Step 4.5: STABLE MAILING LIST
No specific stable discussion found. The patch does not have Cc: stable
tag.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
- `rc_unregister_device()` - modified to remove implicit free
- `rc_free_device()` - now must be called explicitly by drivers
- `rc_dev_release()` - now frees raw event data
- `ir_raw_event_free()` - moved from unregister path to release path
- `ir_raw_event_unregister()` - no longer frees raw events

### Step 5.2: CALLERS
Every RC driver's remove/disconnect/exit function calls
`rc_unregister_device()`. The patch adds `rc_free_device()` to all of
them. This affects USB IR receivers, PCI TV tuner cards, embedded IR
receivers, DRM bridges, etc.

Record: Broad impact - every RC device driver is affected.

### Step 5.3-5.5: CALL CHAIN AND PATTERNS
The race is triggered during device removal (USB disconnect, PCI remove,
platform remove). This is a common path triggered by:
- USB device physical disconnect
- Module unload
- System shutdown
- Device unbind via sysfs

Record: The buggy path is easily triggered by physical device
disconnect. Not theoretical.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE?
Yes. The buggy code in `rc_unregister_device()` (calling
`rc_free_device()` implicitly) has existed since 2010. It is present in
ALL stable trees.

Record: Bug affects all stable trees (6.6.y, 6.1.y, 5.15.y, etc.).

### Step 6.2: BACKPORT COMPLICATIONS
This patch touches 41 files. Some files may have diverged between
mainline and stable trees. Backporting will likely require resolving
minor conflicts in some drivers. The core changes to `rc-main.c`, `rc-
ir-raw.c`, and `rc-core.h` are critical and should apply with minor
fuzz. The per-driver changes are mechanical and can be adapted.

Record: Expected difficulty: **medium**. Core changes likely apply
cleanly. Some driver-specific changes may need minor adjustment due to
driver-specific changes in stable trees vs mainline.

### Step 6.3: RELATED FIXES IN STABLE
Individual UAF fixes like `5abda7a16698d` (dm1105) and `29b0589a865b6`
(ene_ir) may already be in some stable trees, but they only fix specific
drivers. This systemic fix is comprehensive.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
Media/RC subsystem - used by IR receivers on:
- TV tuner cards (USB and PCI)
- Media center remotes (iMON, MCE, Xbox)
- Embedded IR receivers (sunxi, meson, hix5hd2)
- DRM bridges with CEC/RC

Record: IMPORTANT level - affects users of IR remote control hardware
(common in HTPCs, embedded media devices).

### Step 7.2: SUBSYSTEM ACTIVITY
Active subsystem with regular maintenance from Sean Young.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
All users with IR remote control hardware who disconnect or unbind the
device. This includes USB IR receivers (very common for HTPC setups),
PCI TV tuner cards with IR, and embedded systems with hardware IR.

Record: Moderate user population - anyone using Linux with IR remote
control hardware.

### Step 8.2: TRIGGER CONDITIONS
- Physical USB disconnect of IR receiver
- Module unload while IR device active
- Device unbind via sysfs
- System shutdown with pending IR operations
- Concurrent with incoming IR data

Record: Common trigger conditions. USB disconnect is the most frequent.

### Step 8.3: FAILURE MODE SEVERITY
Use-after-free: Accessing freed `struct rc_dev` or `struct
ir_raw_event_ctrl` from URB/IRQ callbacks. This leads to:
- Kernel crash/oops (most likely)
- Memory corruption (possible)
- Security vulnerability (potential, if attacker controls USB device)

Record: Severity: HIGH to CRITICAL. UAF can cause crashes and is
potentially exploitable.

### Step 8.4: RISK-BENEFIT RATIO
**Benefit:** HIGH - Fixes use-after-free race in all RC drivers
systemically. Prevents crashes during device disconnect. Fixes reported
real-world bug.

**Risk:** MEDIUM - 41 files touched, but each change is 1-3 lines and
mechanically identical (add `rc_free_device()` after
`rc_unregister_device()`). The core API change is well-designed. Some
USB drivers also reorder operations to call `rc_unregister_device()`
before `usb_kill_urb()`, which is the correct order.

Record: Benefit HIGH, Risk MEDIUM. The fix is well-designed but the
scope is large.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**Evidence FOR backporting:**
- Fixes a real use-after-free race condition
- Multiple independent bug reports (4 Closes: tags)
- Written and signed by the RC subsystem maintainer (Sean Young)
- Reviewed by Patrice Chotard, merged by Hans Verkuil
- Bug has existed since 2010, affects all stable trees
- Previous individual driver fixes confirm this is a known issue pattern
- UAF can cause kernel crashes and is potentially exploitable
- The fix is logically correct - it separates unregister from free

**Evidence AGAINST backporting:**
- Very large scope: 41 files modified across multiple subsystems
- Changes a core API contract (rc_unregister_device no longer frees)
- Risk of backport conflicts due to per-driver divergence between
  mainline and stable
- Some drivers may not exist in older stable trees, requiring manual
  adaptation
- Removes `managed_alloc` infrastructure, affecting
  `devm_rc_allocate_device()` users

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - reviewed by maintainers,
   applied to mainline
2. Fixes a real bug? **YES** - UAF race condition with 4 bug reports
3. Important issue? **YES** - use-after-free / crash during device
   disconnect
4. Small and contained? **NO** - 41 files is very large. However, each
   change is mechanical (1-3 lines per file) and the core change is
   small (~10 lines)
5. No new features or APIs? **YES** - only changes existing API behavior
6. Can apply to stable trees? **PARTIALLY** - core changes likely apply;
   some driver changes may need adaptation

### Step 9.3: EXCEPTION CATEGORIES
Not applicable - this is a bug fix, not a device ID/quirk/DT/build fix.

### Step 9.4: DECISION
This is a genuine, important use-after-free fix from the subsystem
maintainer with multiple independent bug reports. However, the **scope
is extremely large** (41 files across multiple subsystems) and it
changes a core API contract. While each individual change is trivial and
mechanical, the sheer number of files makes this a high-risk backport.
If even one driver is missed or adapted incorrectly, it introduces a new
bug (memory leak from missing `rc_free_device()` or double-free from
calling it when not needed).

The stable kernel rules explicitly require patches to be "small and
contained." While the fix itself is correct and important, 41 files
touching DRM, HID, media PCI, media USB, and staging subsystems is not
small and contained. A backport of this magnitude would need careful
manual review for each stable tree to handle driver-specific divergence.

Verification:
- [Phase 1] Parsed tags: Reported-by: Haotian Zhang, 4 Closes: links,
  Reviewed-by: Patrice Chotard, Signed-off-by: Sean Young (author/RC
  maintainer), Hans Verkuil (media maintainer)
- [Phase 2] Diff analysis: 41 files changed, core change removes
  implicit rc_free_device() from rc_unregister_device(), each driver
  adds explicit rc_free_device() call
- [Phase 2] Verified: Current rc_unregister_device() at line 2046 has
  `if (!dev->managed_alloc) rc_free_device(dev)` - confirmed the bug
  exists
- [Phase 2] Verified: rc_dev_release() at line 1610 currently just does
  `kfree(dev)` without freeing raw events - patch adds
  ir_raw_event_free(dev) there
- [Phase 3] git blame: rc_unregister_device() implicit free from
  d8b4b5822f51e2 (2010, v2.6.36), managed_alloc from ddbf7d5a698c4d
  (2016, v4.10)
- [Phase 3] git show ddbf7d5a698c4d: confirmed managed_alloc was
  introduced by Heiner Kallweit in 2016
- [Phase 3] Found related individual driver UAF fixes: 5abda7a16698d
  (dm1105), 29b0589a865b6 (ene_ir)
- [Phase 3] git show 5abda7a16698d: confirmed dm1105 UAF race diagram
  showing exactly the same pattern
- [Phase 4] Web search found v1 and v2 submissions: v1 Dec 2025, v2 Jan
  26 2026
- [Phase 4] Found full v2 patch on freedesktop.org archives - matches
  commit
- [Phase 4] 4 separate bug reports from Haotian Zhang (Nov 2025) confirm
  real-world issue
- [Phase 5] Verified devm_rc_allocate_device callers (gpio-ir-recv,
  meson-ir, etc.) don't manually call rc_unregister_device - they use
  devm path, so they're unaffected
- [Phase 6] Bug exists since v2.6.36 (2010) - present in all stable
  trees
- [Phase 8] Trigger: USB device disconnect during IR activity - common
  operation
- UNVERIFIED: Whether all 41 files exist in all stable trees (some
  drivers may have been added/removed between releases)

This is a borderline case. The fix addresses a real, reported use-after-
free bug from the subsystem maintainer with proper review. However, the
41-file scope makes it risky for stable. On balance, the UAF is serious
enough (crash, potential security) that it warrants backporting despite
the large scope, especially since each per-driver change is mechanically
identical and trivially verifiable.

**YES**

 drivers/gpu/drm/bridge/sil-sii8620.c        | 1 +
 drivers/hid/hid-picolcd_cir.c               | 1 +
 drivers/media/cec/core/cec-core.c           | 2 +-
 drivers/media/common/siano/smsir.c          | 1 +
 drivers/media/i2c/ir-kbd-i2c.c              | 2 ++
 drivers/media/pci/bt8xx/bttv-input.c        | 3 ++-
 drivers/media/pci/cx23885/cx23885-input.c   | 1 +
 drivers/media/pci/cx88/cx88-input.c         | 3 ++-
 drivers/media/pci/dm1105/dm1105.c           | 1 +
 drivers/media/pci/mantis/mantis_input.c     | 1 +
 drivers/media/pci/saa7134/saa7134-input.c   | 1 +
 drivers/media/pci/smipcie/smipcie-ir.c      | 1 +
 drivers/media/pci/ttpci/budget-ci.c         | 1 +
 drivers/media/rc/ati_remote.c               | 6 +++---
 drivers/media/rc/ene_ir.c                   | 2 +-
 drivers/media/rc/fintek-cir.c               | 3 ++-
 drivers/media/rc/igorplugusb.c              | 1 +
 drivers/media/rc/iguanair.c                 | 1 +
 drivers/media/rc/img-ir/img-ir-hw.c         | 3 ++-
 drivers/media/rc/img-ir/img-ir-raw.c        | 3 ++-
 drivers/media/rc/imon.c                     | 3 ++-
 drivers/media/rc/ir-hix5hd2.c               | 2 +-
 drivers/media/rc/ir_toy.c                   | 1 +
 drivers/media/rc/ite-cir.c                  | 2 +-
 drivers/media/rc/mceusb.c                   | 1 +
 drivers/media/rc/rc-ir-raw.c                | 5 -----
 drivers/media/rc/rc-loopback.c              | 1 +
 drivers/media/rc/rc-main.c                  | 6 +-----
 drivers/media/rc/redrat3.c                  | 4 +++-
 drivers/media/rc/st_rc.c                    | 2 +-
 drivers/media/rc/streamzap.c                | 7 ++++---
 drivers/media/rc/sunxi-cir.c                | 1 +
 drivers/media/rc/ttusbir.c                  | 2 +-
 drivers/media/rc/winbond-cir.c              | 2 +-
 drivers/media/rc/xbox_remote.c              | 5 +++--
 drivers/media/usb/au0828/au0828-input.c     | 1 +
 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 1 +
 drivers/media/usb/dvb-usb/dvb-usb-remote.c  | 6 ++++--
 drivers/media/usb/em28xx/em28xx-input.c     | 1 +
 drivers/staging/media/av7110/av7110_ir.c    | 1 +
 include/media/rc-core.h                     | 2 --
 41 files changed, 58 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c
index d3f238b1f2a94..982306eb4f0a7 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2221,6 +2221,7 @@ static void sii8620_detach(struct drm_bridge *bridge)
 		return;
 
 	rc_unregister_device(ctx->rc_dev);
+	rc_free_device(ctx->rc_dev);
 }
 
 static int sii8620_is_packing_required(struct sii8620 *ctx,
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index d6faa0e00f95a..6d4c636e1c9f7 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -134,5 +134,6 @@ void picolcd_exit_cir(struct picolcd_data *data)
 
 	data->rc_dev = NULL;
 	rc_unregister_device(rdev);
+	rc_free_device(rdev);
 }
 
diff --git a/drivers/media/cec/core/cec-core.c b/drivers/media/cec/core/cec-core.c
index 1953ce559ecaf..0fcd3b5e60c8d 100644
--- a/drivers/media/cec/core/cec-core.c
+++ b/drivers/media/cec/core/cec-core.c
@@ -338,8 +338,8 @@ int cec_register_adapter(struct cec_adapter *adap,
 	res = cec_devnode_register(&adap->devnode, adap->owner);
 	if (res) {
 #ifdef CONFIG_MEDIA_CEC_RC
-		/* Note: rc_unregister also calls rc_free */
 		rc_unregister_device(adap->rc);
+		rc_free_device(adap->rc);
 		adap->rc = NULL;
 #endif
 		return res;
diff --git a/drivers/media/common/siano/smsir.c b/drivers/media/common/siano/smsir.c
index af07fed21ae12..283770d583d56 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -92,6 +92,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
 void sms_ir_exit(struct smscore_device_t *coredev)
 {
 	rc_unregister_device(coredev->ir.dev);
+	rc_free_device(coredev->ir.dev);
 
 	pr_debug("\n");
 }
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 5588cdd7ec20d..6047453170043 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -355,6 +355,7 @@ static void ir_work(struct work_struct *work)
 		mutex_unlock(&ir->lock);
 		if (rc == -ENODEV) {
 			rc_unregister_device(ir->rc);
+			rc_free_device(ir->rc);
 			ir->rc = NULL;
 			return;
 		}
@@ -972,6 +973,7 @@ static void ir_remove(struct i2c_client *client)
 	i2c_unregister_device(ir->tx_c);
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 }
 
 static const struct i2c_device_id ir_kbd_id[] = {
diff --git a/drivers/media/pci/bt8xx/bttv-input.c b/drivers/media/pci/bt8xx/bttv-input.c
index 373b6c6817d76..f704476506e07 100644
--- a/drivers/media/pci/bt8xx/bttv-input.c
+++ b/drivers/media/pci/bt8xx/bttv-input.c
@@ -572,8 +572,9 @@ void bttv_input_fini(struct bttv *btv)
 	if (btv->remote == NULL)
 		return;
 
-	bttv_ir_stop(btv);
 	rc_unregister_device(btv->remote->dev);
+	bttv_ir_stop(btv);
+	rc_free_device(btv->remote->dev);
 	kfree(btv->remote);
 	btv->remote = NULL;
 }
diff --git a/drivers/media/pci/cx23885/cx23885-input.c b/drivers/media/pci/cx23885/cx23885-input.c
index ffbbeca8a8e5f..554767b8ef2bf 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -402,6 +402,7 @@ void cx23885_input_fini(struct cx23885_dev *dev)
 	if (dev->kernel_ir == NULL)
 		return;
 	rc_unregister_device(dev->kernel_ir->rc);
+	rc_free_device(dev->kernel_ir->rc);
 	kfree(dev->kernel_ir->phys);
 	kfree(dev->kernel_ir->name);
 	kfree(dev->kernel_ir);
diff --git a/drivers/media/pci/cx88/cx88-input.c b/drivers/media/pci/cx88/cx88-input.c
index e958eecb29c5c..5d9ce4f9af011 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -509,8 +509,9 @@ int cx88_ir_fini(struct cx88_core *core)
 	if (!ir)
 		return 0;
 
-	cx88_ir_stop(core);
 	rc_unregister_device(ir->dev);
+	cx88_ir_stop(core);
+	rc_free_device(ir->dev);
 	kfree(ir);
 
 	/* done */
diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index de05d8b0f9dc5..bbd24769ae56b 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -763,6 +763,7 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
 static void dm1105_ir_exit(struct dm1105_dev *dm1105)
 {
 	rc_unregister_device(dm1105->ir.dev);
+	rc_free_device(dm1105->ir.dev);
 }
 
 static int dm1105_hw_init(struct dm1105_dev *dev)
diff --git a/drivers/media/pci/mantis/mantis_input.c b/drivers/media/pci/mantis/mantis_input.c
index 34c0d979240fd..edb4cacf55d22 100644
--- a/drivers/media/pci/mantis/mantis_input.c
+++ b/drivers/media/pci/mantis/mantis_input.c
@@ -72,5 +72,6 @@ EXPORT_SYMBOL_GPL(mantis_input_init);
 void mantis_input_exit(struct mantis_pci *mantis)
 {
 	rc_unregister_device(mantis->rc);
+	rc_free_device(mantis->rc);
 }
 EXPORT_SYMBOL_GPL(mantis_input_exit);
diff --git a/drivers/media/pci/saa7134/saa7134-input.c b/drivers/media/pci/saa7134/saa7134-input.c
index 5b71014157808..7f6680de31564 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -834,6 +834,7 @@ void saa7134_input_fini(struct saa7134_dev *dev)
 		return;
 
 	rc_unregister_device(dev->remote->dev);
+	rc_free_device(dev->remote->dev);
 	kfree(dev->remote);
 	dev->remote = NULL;
 }
diff --git a/drivers/media/pci/smipcie/smipcie-ir.c b/drivers/media/pci/smipcie/smipcie-ir.c
index c0604d9c70119..0bbe4fa2d5a84 100644
--- a/drivers/media/pci/smipcie/smipcie-ir.c
+++ b/drivers/media/pci/smipcie/smipcie-ir.c
@@ -181,5 +181,6 @@ void smi_ir_exit(struct smi_dev *dev)
 
 	rc_unregister_device(rc_dev);
 	smi_ir_stop(ir);
+	rc_free_device(rc_dev);
 	ir->rc_dev = NULL;
 }
diff --git a/drivers/media/pci/ttpci/budget-ci.c b/drivers/media/pci/ttpci/budget-ci.c
index 3709c0fb23b07..8b496b959d7ea 100644
--- a/drivers/media/pci/ttpci/budget-ci.c
+++ b/drivers/media/pci/ttpci/budget-ci.c
@@ -249,6 +249,7 @@ static void msp430_ir_deinit(struct budget_ci *budget_ci)
 	cancel_work_sync(&budget_ci->ir.msp430_irq_bh_work);
 
 	rc_unregister_device(budget_ci->ir.dev);
+	rc_free_device(budget_ci->ir.dev);
 }
 
 static int ciintf_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 78abe810a88e7..51d85de24fae3 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -921,7 +921,6 @@ static int ati_remote_probe(struct usb_interface *interface,
 	input_free_device(input_dev);
  exit_unregister_device:
 	rc_unregister_device(rc_dev);
-	rc_dev = NULL;
  exit_kill_urbs:
 	usb_kill_urb(ati_remote->irq_urb);
 	usb_kill_urb(ati_remote->out_urb);
@@ -941,18 +940,19 @@ static void ati_remote_disconnect(struct usb_interface *interface)
 	struct ati_remote *ati_remote;
 
 	ati_remote = usb_get_intfdata(interface);
-	usb_set_intfdata(interface, NULL);
 	if (!ati_remote) {
 		dev_warn(&interface->dev, "%s - null device?\n", __func__);
 		return;
 	}
 
+	rc_unregister_device(ati_remote->rdev);
+	usb_set_intfdata(interface, NULL);
 	usb_kill_urb(ati_remote->irq_urb);
 	usb_kill_urb(ati_remote->out_urb);
 	if (ati_remote->idev)
 		input_unregister_device(ati_remote->idev);
-	rc_unregister_device(ati_remote->rdev);
 	ati_remote_free_buffers(ati_remote);
+	rc_free_device(ati_remote->rdev);
 	kfree(ati_remote);
 }
 
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index f8120605501ab..6f7dccc965e7f 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1090,7 +1090,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
 	release_region(dev->hw_io, ENE_IO_SIZE);
 exit_unregister_device:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 exit_free_dev_rdev:
 	rc_free_device(rdev);
 	kfree(dev);
@@ -1110,6 +1109,7 @@ static void ene_remove(struct pnp_dev *pnp_dev)
 	ene_rx_restore_hw_buffer(dev);
 	spin_unlock_irqrestore(&dev->hw_lock, flags);
 
+	rc_free_device(dev->rdev);
 	free_irq(dev->irq, dev);
 	release_region(dev->hw_io, ENE_IO_SIZE);
 	kfree(dev);
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index f7cfa8a073ebc..5055dfc3f4651 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -568,6 +568,7 @@ static void fintek_remove(struct pnp_dev *pdev)
 	struct fintek_dev *fintek = pnp_get_drvdata(pdev);
 	unsigned long flags;
 
+	rc_unregister_device(fintek->rdev);
 	spin_lock_irqsave(&fintek->fintek_lock, flags);
 	/* disable CIR */
 	fintek_disable_cir(fintek);
@@ -580,7 +581,7 @@ static void fintek_remove(struct pnp_dev *pdev)
 	free_irq(fintek->cir_irq, fintek);
 	release_region(fintek->cir_addr, fintek->cir_port_len);
 
-	rc_unregister_device(fintek->rdev);
+	rc_free_device(fintek->rdev);
 
 	kfree(fintek);
 }
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index e034c93d57cf0..5ceb5ca44e235 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -242,6 +242,7 @@ static void igorplugusb_disconnect(struct usb_interface *intf)
 	usb_set_intfdata(intf, NULL);
 	usb_unpoison_urb(ir->urb);
 	usb_free_urb(ir->urb);
+	rc_free_device(ir->rc);
 	kfree(ir->buf_in);
 }
 
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index c508f2536243e..0c5b8befb0af3 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -500,6 +500,7 @@ static void iguanair_disconnect(struct usb_interface *intf)
 	usb_set_intfdata(intf, NULL);
 	usb_kill_urb(ir->urb_in);
 	usb_kill_urb(ir->urb_out);
+	rc_free_device(ir->rc);
 	usb_free_urb(ir->urb_in);
 	usb_free_urb(ir->urb_out);
 	usb_free_coherent(ir->udev, MAX_IN_PACKET, ir->buf_in, ir->dma_in);
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c b/drivers/media/rc/img-ir/img-ir-hw.c
index 63f6f5b36838d..f30adf4d8444d 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -1118,9 +1118,10 @@ void img_ir_remove_hw(struct img_ir_priv *priv)
 	struct rc_dev *rdev = hw->rdev;
 	if (!rdev)
 		return;
+	rc_unregister_device(rdev);
 	img_ir_set_decoder(priv, NULL, 0);
 	hw->rdev = NULL;
-	rc_unregister_device(rdev);
+	rc_free_device(rdev);
 #ifdef CONFIG_COMMON_CLK
 	if (!IS_ERR(priv->clk))
 		clk_notifier_unregister(priv->clk, &hw->clk_nb);
diff --git a/drivers/media/rc/img-ir/img-ir-raw.c b/drivers/media/rc/img-ir/img-ir-raw.c
index 92fb7b555a0f6..f1460d4acf3e8 100644
--- a/drivers/media/rc/img-ir/img-ir-raw.c
+++ b/drivers/media/rc/img-ir/img-ir-raw.c
@@ -136,6 +136,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
 	if (!rdev)
 		return;
 
+	rc_unregister_device(rdev);
 	/* switch off and disable raw (edge) interrupts */
 	spin_lock_irq(&priv->lock);
 	raw->rdev = NULL;
@@ -145,7 +146,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
 	img_ir_write(priv, IMG_IR_IRQ_CLEAR, IMG_IR_IRQ_EDGE);
 	spin_unlock_irq(&priv->lock);
 
-	rc_unregister_device(rdev);
+	rc_free_device(rdev);
 
 	timer_delete_sync(&raw->timer);
 }
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 7e92161105d53..310c9fc9ae91c 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2541,9 +2541,10 @@ static void imon_disconnect(struct usb_interface *interface)
 
 	if (ifnum == 0) {
 		ictx->dev_present_intf0 = false;
+		rc_unregister_device(ictx->rdev);
 		usb_kill_urb(ictx->rx_urb_intf0);
 		input_unregister_device(ictx->idev);
-		rc_unregister_device(ictx->rdev);
+		rc_free_device(ictx->rdev);
 		if (ictx->display_supported) {
 			if (ictx->display_type == IMON_DISPLAY_TYPE_LCD)
 				usb_deregister_dev(interface, &imon_lcd_class);
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index edc46828509c8..1b061e4a3dcfa 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -331,7 +331,6 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
 
 regerr:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 clkerr:
 	clk_disable_unprepare(priv->clock);
 err:
@@ -346,6 +345,7 @@ static void hix5hd2_ir_remove(struct platform_device *pdev)
 
 	clk_disable_unprepare(priv->clock);
 	rc_unregister_device(priv->rdev);
+	rc_free_device(priv->rdev);
 }
 
 #ifdef CONFIG_PM_SLEEP
diff --git a/drivers/media/rc/ir_toy.c b/drivers/media/rc/ir_toy.c
index d6472de5da87d..089833e411786 100644
--- a/drivers/media/rc/ir_toy.c
+++ b/drivers/media/rc/ir_toy.c
@@ -536,6 +536,7 @@ static void irtoy_disconnect(struct usb_interface *intf)
 	usb_free_urb(ir->urb_out);
 	usb_kill_urb(ir->urb_in);
 	usb_free_urb(ir->urb_in);
+	rc_free_device(ir->rc);
 	kfree(ir->in);
 	kfree(ir->out);
 	kfree(ir);
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index bf544517c67a9..bde2a70512310 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1414,7 +1414,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
 	release_region(itdev->cir_addr, itdev->params->io_region_size);
 exit_unregister_device:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 exit_free_dev_rdev:
 	rc_free_device(rdev);
 	kfree(itdev);
@@ -1439,6 +1438,7 @@ static void ite_remove(struct pnp_dev *pdev)
 	release_region(dev->cir_addr, dev->params->io_region_size);
 
 	rc_unregister_device(dev->rdev);
+	rc_free_device(dev->rdev);
 
 	kfree(dev);
 }
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ed55e9ec3c570..06222eee17540 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1850,6 +1850,7 @@ static void mceusb_dev_disconnect(struct usb_interface *intf)
 	usb_free_urb(ir->urb_in);
 	usb_free_coherent(dev, ir->len_in, ir->buf_in, ir->dma_in);
 	usb_put_dev(dev);
+	rc_free_device(ir->rc);
 
 	kfree(ir);
 }
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 2e269ef5e26be..ba24c2f22d39f 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -648,9 +648,6 @@ int ir_raw_event_register(struct rc_dev *dev)
 
 void ir_raw_event_free(struct rc_dev *dev)
 {
-	if (!dev)
-		return;
-
 	kfree(dev->raw);
 	dev->raw = NULL;
 }
@@ -674,8 +671,6 @@ void ir_raw_event_unregister(struct rc_dev *dev)
 
 	lirc_bpf_free(dev);
 
-	ir_raw_event_free(dev);
-
 	/*
 	 * A user can be calling bpf(BPF_PROG_{QUERY|ATTACH|DETACH}), so
 	 * ensure that the raw member is null on unlock; this is how
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index 78ac09b3cbd34..53d0540717b36 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -263,6 +263,7 @@ static int __init loop_init(void)
 static void __exit loop_exit(void)
 {
 	rc_unregister_device(loopdev.dev);
+	rc_free_device(loopdev.dev);
 }
 
 module_init(loop_init);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 821607504008a..dda3479ea3add 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1611,6 +1611,7 @@ static void rc_dev_release(struct device *device)
 {
 	struct rc_dev *dev = to_rc_dev(device);
 
+	ir_raw_event_free(dev);
 	kfree(dev);
 }
 
@@ -1773,7 +1774,6 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev,
 	}
 
 	rc->dev.parent = dev;
-	rc->managed_alloc = true;
 	*dr = rc;
 	devres_add(dev, dr);
 
@@ -2042,11 +2042,7 @@ void rc_unregister_device(struct rc_dev *dev)
 	device_del(&dev->dev);
 
 	ida_free(&rc_ida, dev->minor);
-
-	if (!dev->managed_alloc)
-		rc_free_device(dev);
 }
-
 EXPORT_SYMBOL_GPL(rc_unregister_device);
 
 /*
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 3b917a2a89188..3f828a564e192 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -1131,11 +1131,13 @@ static void redrat3_dev_disconnect(struct usb_interface *intf)
 {
 	struct usb_device *udev = interface_to_usbdev(intf);
 	struct redrat3_dev *rr3 = usb_get_intfdata(intf);
+	struct rc_dev *rc = rr3->rc;
 
 	usb_set_intfdata(intf, NULL);
-	rc_unregister_device(rr3->rc);
+	rc_unregister_device(rc);
 	led_classdev_unregister(&rr3->led);
 	redrat3_delete(rr3, udev);
+	rc_free_device(rc);
 }
 
 static int redrat3_dev_suspend(struct usb_interface *intf, pm_message_t message)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 6b70bac5f45d6..0ba06bfc9e14b 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -203,6 +203,7 @@ static void st_rc_remove(struct platform_device *pdev)
 	device_init_wakeup(&pdev->dev, false);
 	clk_disable_unprepare(rc_dev->sys_clock);
 	rc_unregister_device(rc_dev->rdev);
+	rc_free_device(rc_dev->rdev);
 }
 
 static int st_rc_open(struct rc_dev *rdev)
@@ -334,7 +335,6 @@ static int st_rc_probe(struct platform_device *pdev)
 	return ret;
 rcerr:
 	rc_unregister_device(rdev);
-	rdev = NULL;
 clkerr:
 	clk_disable_unprepare(rc_dev->sys_clock);
 err:
diff --git a/drivers/media/rc/streamzap.c b/drivers/media/rc/streamzap.c
index 5a18603f9a95c..7103da57c19f1 100644
--- a/drivers/media/rc/streamzap.c
+++ b/drivers/media/rc/streamzap.c
@@ -388,15 +388,16 @@ static void streamzap_disconnect(struct usb_interface *interface)
 	struct streamzap_ir *sz = usb_get_intfdata(interface);
 	struct usb_device *usbdev = interface_to_usbdev(interface);
 
-	usb_set_intfdata(interface, NULL);
-
 	if (!sz)
 		return;
 
-	usb_kill_urb(sz->urb_in);
 	rc_unregister_device(sz->rdev);
+	usb_set_intfdata(interface, NULL);
+
+	usb_kill_urb(sz->urb_in);
 	usb_free_urb(sz->urb_in);
 	usb_free_coherent(usbdev, sz->buf_in_len, sz->buf_in, sz->dma_in);
+	rc_free_device(sz->rdev);
 
 	kfree(sz);
 }
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 92ef4e7c6f69f..cb4c56bf0752a 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -371,6 +371,7 @@ static void sunxi_ir_remove(struct platform_device *pdev)
 	struct sunxi_ir *ir = platform_get_drvdata(pdev);
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 	sunxi_ir_hw_exit(&pdev->dev);
 }
 
diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c
index 110a469001146..a2a64a860264b 100644
--- a/drivers/media/rc/ttusbir.c
+++ b/drivers/media/rc/ttusbir.c
@@ -333,7 +333,6 @@ static int ttusbir_probe(struct usb_interface *intf,
 	return 0;
 out3:
 	rc_unregister_device(rc);
-	rc = NULL;
 out2:
 	led_classdev_unregister(&tt->led);
 out:
@@ -373,6 +372,7 @@ static void ttusbir_disconnect(struct usb_interface *intf)
 	}
 	usb_kill_urb(tt->bulk_urb);
 	usb_free_urb(tt->bulk_urb);
+	rc_free_device(tt->rc);
 	usb_set_intfdata(intf, NULL);
 	kfree(tt);
 }
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 515469dd82d4c..8e804661a6215 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1132,7 +1132,6 @@ wbcir_probe(struct pnp_dev *device, const struct pnp_device_id *dev_id)
 	release_region(data->wbase, WAKEUP_IOMEM_LEN);
 exit_unregister_device:
 	rc_unregister_device(data->dev);
-	data->dev = NULL;
 exit_free_rc:
 	rc_free_device(data->dev);
 exit_unregister_led:
@@ -1163,6 +1162,7 @@ wbcir_remove(struct pnp_dev *device)
 	wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x00, 0x07);
 
 	rc_unregister_device(data->dev);
+	rc_free_device(data->dev);
 
 	led_classdev_unregister(&data->led);
 
diff --git a/drivers/media/rc/xbox_remote.c b/drivers/media/rc/xbox_remote.c
index 3e3da70cf8da0..c64123e9d16a5 100644
--- a/drivers/media/rc/xbox_remote.c
+++ b/drivers/media/rc/xbox_remote.c
@@ -277,14 +277,15 @@ static void xbox_remote_disconnect(struct usb_interface *interface)
 	struct xbox_remote *xbox_remote;
 
 	xbox_remote = usb_get_intfdata(interface);
-	usb_set_intfdata(interface, NULL);
 	if (!xbox_remote) {
 		dev_warn(&interface->dev, "%s - null device?\n", __func__);
 		return;
 	}
 
-	usb_kill_urb(xbox_remote->irq_urb);
 	rc_unregister_device(xbox_remote->rdev);
+	usb_set_intfdata(interface, NULL);
+	usb_kill_urb(xbox_remote->irq_urb);
+	rc_free_device(xbox_remote->rdev);
 	usb_free_urb(xbox_remote->irq_urb);
 	kfree(xbox_remote);
 }
diff --git a/drivers/media/usb/au0828/au0828-input.c b/drivers/media/usb/au0828/au0828-input.c
index 7dec1a360da6a..81d0165a3064d 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -357,6 +357,7 @@ void au0828_rc_unregister(struct au0828_dev *dev)
 		return;
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 
 	/* done */
 	kfree(ir);
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index 600cff8a4abdc..bd86d250433df 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -187,6 +187,7 @@ static int dvb_usbv2_remote_exit(struct dvb_usb_device *d)
 	if (d->rc_dev) {
 		cancel_delayed_work_sync(&d->rc_query_work);
 		rc_unregister_device(d->rc_dev);
+		rc_free_device(d->rc_dev);
 		d->rc_dev = NULL;
 	}
 
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-remote.c b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
index 65e2c9e2cdc99..6dc11718dfb98 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
@@ -347,10 +347,12 @@ int dvb_usb_remote_exit(struct dvb_usb_device *d)
 {
 	if (d->state & DVB_USB_STATE_REMOTE) {
 		cancel_delayed_work_sync(&d->rc_query_work);
-		if (d->props.rc.mode == DVB_RC_LEGACY)
+		if (d->props.rc.mode == DVB_RC_LEGACY) {
 			input_unregister_device(d->input_dev);
-		else
+		} else {
 			rc_unregister_device(d->rc_dev);
+			rc_free_device(d->rc_dev);
+		}
 	}
 	d->state &= ~DVB_USB_STATE_REMOTE;
 	return 0;
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 20fdd59b55185..ab61d9a29b10e 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -853,6 +853,7 @@ static int em28xx_ir_fini(struct em28xx *dev)
 		goto ref_put;
 
 	rc_unregister_device(ir->rc);
+	rc_free_device(ir->rc);
 
 	kfree(ir->i2c_client);
 
diff --git a/drivers/staging/media/av7110/av7110_ir.c b/drivers/staging/media/av7110/av7110_ir.c
index 68b3979ba5f20..fdae467fd7ab8 100644
--- a/drivers/staging/media/av7110/av7110_ir.c
+++ b/drivers/staging/media/av7110/av7110_ir.c
@@ -151,6 +151,7 @@ int av7110_ir_init(struct av7110 *av7110)
 void av7110_ir_exit(struct av7110 *av7110)
 {
 	rc_unregister_device(av7110->ir.rcdev);
+	rc_free_device(av7110->ir.rcdev);
 }
 
 //MODULE_AUTHOR("Holger Waechtler <holger@convergence.de>, Oliver Endriss <o.endriss@gmx.de>");
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 35c7a0546f02e..7c964b5ad7926 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -81,7 +81,6 @@ struct lirc_fh {
 /**
  * struct rc_dev - represents a remote control device
  * @dev: driver model's view of this device
- * @managed_alloc: devm_rc_allocate_device was used to create rc_dev
  * @registered: set to true by rc_register_device(), false by
  *	rc_unregister_device
  * @idle: used to keep track of RX state
@@ -156,7 +155,6 @@ struct lirc_fh {
  */
 struct rc_dev {
 	struct device			dev;
-	bool				managed_alloc;
 	bool				registered;
 	bool				idle;
 	bool				encode_wakeup;
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: imx93-tqma9352: improve eMMC pad configuration

[Sasha Levin]

From: Markus Niebel <Markus.Niebel@ew.tq-group.com>

[ Upstream commit b6c94c71f349479b76fcc0ef0dc7147f3f326dff ]

Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve
stability and detection at low temperatures under -25°C.

Fixes: 0b5fdfaa8e45 ("arm64: dts: freescale: imx93-tqma9352: set SION for cmd and data pad of USDHC")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 .../boot/dts/freescale/imx93-tqma9352.dtsi    | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
index 82914ca148d3a..c095d7f115c21 100644
--- a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
@@ -270,21 +270,21 @@ MX93_PAD_SD2_RESET_B__GPIO3_IO07	0x106
 	/* enable SION for data and cmd pad due to ERR052021 */
 	pinctrl_usdhc1: usdhc1grp {
 		fsl,pins = <
-			/* PD | FSEL 3 | DSE X5 */
-			MX93_PAD_SD1_CLK__USDHC1_CLK		0x5be
+			/* PD | FSEL 3 | DSE X4 */
+			MX93_PAD_SD1_CLK__USDHC1_CLK		0x59e
 			/* HYS | FSEL 0 | no drive */
 			MX93_PAD_SD1_STROBE__USDHC1_STROBE	0x1000
-			/* HYS | FSEL 3 | X5 */
-			MX93_PAD_SD1_CMD__USDHC1_CMD		0x400011be
-			/* HYS | FSEL 3 | X4 */
-			MX93_PAD_SD1_DATA0__USDHC1_DATA0	0x4000119e
-			MX93_PAD_SD1_DATA1__USDHC1_DATA1	0x4000119e
-			MX93_PAD_SD1_DATA2__USDHC1_DATA2	0x4000119e
-			MX93_PAD_SD1_DATA3__USDHC1_DATA3	0x4000119e
-			MX93_PAD_SD1_DATA4__USDHC1_DATA4	0x4000119e
-			MX93_PAD_SD1_DATA5__USDHC1_DATA5	0x4000119e
-			MX93_PAD_SD1_DATA6__USDHC1_DATA6	0x4000119e
-			MX93_PAD_SD1_DATA7__USDHC1_DATA7	0x4000119e
+			/* HYS | PU | FSEL 3 | DSE X4 */
+			MX93_PAD_SD1_CMD__USDHC1_CMD		0x4000139e
+			/* HYS | PU | FSEL 3 | DSE X4 */
+			MX93_PAD_SD1_DATA0__USDHC1_DATA0	0x4000139e
+			MX93_PAD_SD1_DATA1__USDHC1_DATA1	0x4000139e
+			MX93_PAD_SD1_DATA2__USDHC1_DATA2	0x4000139e
+			MX93_PAD_SD1_DATA3__USDHC1_DATA3	0x4000139e
+			MX93_PAD_SD1_DATA4__USDHC1_DATA4	0x4000139e
+			MX93_PAD_SD1_DATA5__USDHC1_DATA5	0x4000139e
+			MX93_PAD_SD1_DATA6__USDHC1_DATA6	0x4000139e
+			MX93_PAD_SD1_DATA7__USDHC1_DATA7	0x4000139e
 		>;
 	};
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] wifi: mt76: mt792x: Fix a potential deadlock in high-load situations

[Sasha Levin]

From: Leon Yen <leon.yen@mediatek.com>

[ Upstream commit bb2f07819d063a58756186cac6465341956ac0a4 ]

A deadlock may occur between two works, ps_work and mac_work, if their work
functions run simultaneously as they attempt to cancel each other by
calling cancel_delayed_work_sync().

mt792x_mac_work() ->   ...  -> cancel_delayed_work_sync(&pm->ps_work);
mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);

In high-load situations, they are queued but may not have chance to be
executed until the CPUs are released. Once the CPUs are available, there
is a high possibility that the ps_work function and mac_work function will
be executed simultaneously, resulting in a possible deadlock.

This patch replaces cancel_delayed_work_sync() with cancel_delayed_work()
in ps_work to eliminate the deadlock and make the code easier to maintain.

Signed-off-by: Leon Yen <leon.yen@mediatek.com>
Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Link: https://patch.msgid.link/20251215122231.3180648-1-leon.yen@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the data needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `wifi: mt76: mt792x`
- Action verb: "Fix"
- Summary: Fixes a potential deadlock between ps_work and mac_work in
  high-load situations.

Record: [wifi/mt76/mt792x] [Fix] [Deadlock between two work functions
that cancel each other with _sync variant]

**Step 1.2: Tags**
- `Signed-off-by: Leon Yen <leon.yen@mediatek.com>` — Author from
  MediaTek (the chip vendor)
- `Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>` — Tested
  by a Canonical engineer
- `Link: https://patch.msgid.link/20251215122231.3180648-1-
  leon.yen@mediatek.com`
- `Signed-off-by: Felix Fietkau <nbd@nbd.name>` — mt76 subsystem
  maintainer accepted the patch

Record: Author is from MediaTek (chip vendor). Tested by Canonical
(Ubuntu). Accepted by mt76 maintainer Felix Fietkau. No Fixes: tag, no
Reported-by (expected since this is a code-analysis-based fix).

**Step 1.3: Commit Body**
The message describes:
- **Bug**: A deadlock between two delayed works: `ps_work` and
  `mac_work`
- **Mechanism**: Both try to cancel each other using
  `cancel_delayed_work_sync()`, which blocks until the target work
  finishes
- **Trigger**: High-load situations where both works get queued and
  execute simultaneously on different CPUs
- **Fix**: Replace `cancel_delayed_work_sync()` with
  `cancel_delayed_work()` in ps_work

Record: Classic ABBA deadlock. Failure mode is system hang (deadlock).
Triggered under high CPU load with WiFi active.

**Step 1.4: Hidden Bug Fix?**
No — this is explicitly labeled "Fix" and clearly describes a deadlock.
Not hidden.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/net/wireless/mediatek/mt76/mt792x_mac.c`
- 1 line changed: `-cancel_delayed_work_sync(` → `+cancel_delayed_work(`
- Function modified: `mt792x_pm_power_save_work()`
- Scope: Single-file, single-line, surgical fix

**Step 2.2: Code Flow Change**
Before: `mt792x_pm_power_save_work()` calls
`cancel_delayed_work_sync(&mphy->mac_work)`, which blocks until any
currently-running `mac_work` completes.

After: It calls `cancel_delayed_work(&mphy->mac_work)`, which cancels a
pending work but does NOT wait for a running instance to finish.

**Step 2.3: Bug Mechanism — Deadlock**

The deadlock is an ABBA pattern between two work functions:

**Chain A** (mac_work → waits for ps_work):

```
mt792x_mac_work()
  → mt792x_mutex_acquire()
    → mt76_connac_mutex_acquire()
      → mt76_connac_pm_wake()
        → cancel_delayed_work_sync(&pm->ps_work)   ← WAITS for ps_work
```

**Chain B** (ps_work → waits for mac_work):

```
mt792x_pm_power_save_work()
  → cancel_delayed_work_sync(&mphy->mac_work)      ← WAITS for mac_work
```

If both execute simultaneously:
- CPU1's mac_work waits for ps_work to finish
- CPU2's ps_work waits for mac_work to finish
- **Classic ABBA deadlock → system hang**

The two works run on *different* workqueues (`mac_work` on ieee80211's
workqueue, `ps_work` on `dev->mt76.wq`), which confirms they CAN execute
in parallel on different CPUs.

**Step 2.4: Fix Quality**
- Obviously correct: removing `_sync` breaks the circular dependency
- The non-sync variant is safe here because after the cancel, `ps_work`
  immediately returns. If `mac_work` is running, it will re-queue itself
  (line 30-31) and will be properly managed in the next power-save
  cycle. `mac_work` acquires `mt792x_mutex_acquire` which wakes the
  device if needed.
- Minimal/surgical: exactly 1 function call changed
- Regression risk: Very low — the only difference is not waiting for a
  running `mac_work` to finish, which is acceptable since `ps_work`
  doesn't depend on `mac_work` completion

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The buggy line was introduced by commit `c21a7f9f406bba` (Lorenzo
Bianconi, 2023-06-28), "wifi: mt76: mt7921: move shared runtime-pm code
on mt792x-lib". This was code movement that created the mt792x_mac.c
file, carrying the original deadlock-prone pattern from mt7921/mac.c.

**Step 3.2: Fixes tag** — No Fixes: tag present (expected).

**Step 3.3: Related changes** — The file has had several changes since,
but none addressing this specific deadlock.

**Step 3.4: Author** — Leon Yen is a MediaTek engineer with multiple
mt76 contributions, including WiFi/BT combo fixes and power management
work.

**Step 3.5: Dependencies** — None. This is a standalone one-line fix.

## PHASE 4: MAILING LIST RESEARCH

b4 dig did not find the exact commit (it matched a different file
change). The lore.kernel.org search was blocked. However, the commit
message Link tag points to the original submission:
`20251215122231.3180648-1-leon.yen@mediatek.com`. The patch was accepted
by Felix Fietkau (mt76 maintainer) and tested by a Canonical engineer.

Record: Maintainer-accepted, independently tested. Standalone patch (not
a series).

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**: `mt792x_pm_power_save_work()`

**Step 5.2: Callers**: This function is the work handler for
`pm.ps_work`, queued on `dev->mt76.wq` (an ordered workqueue) via
`mt76_connac_power_save_sched()`. It is called indirectly when the
device transitions to power-save mode.

**Step 5.3-5.4: Call chain**: The power-save work is scheduled via
`mt76_connac_mutex_release()` → `mt76_connac_power_save_sched()`, which
is called after every device register access. This is a very hot path
for any mt792x WiFi operation.

**Step 5.5: Similar patterns**: The `mt7615` driver has similar power-
save code at `drivers/net/wireless/mediatek/mt76/mt7615/mac.c`, but this
specific fix only addresses the mt792x code path.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1**: The buggy code was introduced in commit `c21a7f9f406bba`
(June 2023), which is present in v6.6 but NOT in v6.1. Affected stable
trees: v6.6.y, v6.12.y, and any later LTS.

**Step 6.2**: The fix is a one-line change. It should apply cleanly to
any tree containing the buggy code.

**Step 6.3**: No related fixes for this specific deadlock already in
stable.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**: `drivers/net/wireless/mediatek/mt76` — WiFi driver for
MediaTek MT7921/MT7922/MT7925 chipsets. These are extremely popular WiFi
chips found in many modern laptops (Framework, Lenovo ThinkPad, Dell,
etc.). Criticality: **IMPORTANT** — affects many real users.

**Step 7.2**: The mt76 subsystem is very active with regular
contributions.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1**: Affects all users with MT7921/MT7922/MT7925 WiFi chipsets
(very large population, especially Ubuntu/Fedora laptop users).

**Step 8.2**: Trigger is high CPU load with active WiFi. Both works must
execute simultaneously. Under heavy load this is realistic — the commit
specifically says "In high-load situations, they are queued but may not
have chance to be executed until the CPUs are released."

**Step 8.3**: **Failure mode: DEADLOCK → system hang**. Severity:
**CRITICAL** — the system becomes unresponsive.

**Step 8.4**:
- Benefit: VERY HIGH — prevents deadlock/hang on popular hardware
- Risk: VERY LOW — 1-line change, removing a sync variant that was
  causing the deadlock
- Ratio: Extremely favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real deadlock (ABBA pattern) verified through code analysis
- 1-line fix, obviously correct, minimal regression risk
- Affects widely-used WiFi hardware (MT7921/MT7922/MT7925)
- Tested by Canonical engineer (Ubuntu LTS relevance)
- Accepted by subsystem maintainer
- Buggy code exists in stable trees v6.6+
- Failure mode is system hang (CRITICAL)
- Author is from MediaTek (chip vendor, deep domain expertise)

**Evidence AGAINST backporting:**
- None significant

**Stable rules checklist:**
1. Obviously correct and tested? **YES** — 1-line change, independently
   tested
2. Fixes a real bug? **YES** — deadlock under high load
3. Important issue? **YES** — system deadlock/hang (CRITICAL)
4. Small and contained? **YES** — 1 line in 1 file
5. No new features? **YES** — pure bug fix
6. Applies to stable? **YES** — clean apply expected for v6.6+

## Verification

- [Phase 1] Parsed tags: Tested-by from Canonical, maintainer SOB from
  Felix Fietkau
- [Phase 2] Diff analysis: 1-line change in
  `mt792x_pm_power_save_work()`, `cancel_delayed_work_sync` →
  `cancel_delayed_work`
- [Phase 3] git blame: buggy code from commit c21a7f9f406bba (June
  2023), code refactoring that moved runtime-PM code to mt792x-lib
- [Phase 3] `git merge-base --is-ancestor`: confirmed code is in v6.6
  but NOT in v6.1
- [Phase 5] Traced deadlock chain: mac_work→mt792x_mutex_acquire→mt76_co
  nnac_pm_wake→cancel_delayed_work_sync(&ps_work) vs
  ps_work→cancel_delayed_work_sync(&mac_work)
- [Phase 5] Verified `dev->mt76.wq` is `alloc_ordered_workqueue`
  (mac80211.c line 733) and mac_work uses ieee80211's workqueue
  (different queues → parallel execution possible)
- [Phase 5] Verified `mt76_connac_power_save_sched` at line 62-83 of
  mt76_connac_mac.c schedules ps_work, confirming the scheduling path
- [Phase 6] Confirmed fix applies to v6.6+ stable trees
- [Phase 7] mt76 is a widely used WiFi driver subsystem
- [Phase 8] Failure mode: system deadlock/hang, severity CRITICAL

**YES**

 drivers/net/wireless/mediatek/mt76/mt792x_mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_mac.c b/drivers/net/wireless/mediatek/mt76/mt792x_mac.c
index 71dec93094ebd..888e5a5056731 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_mac.c
@@ -375,7 +375,7 @@ void mt792x_pm_power_save_work(struct work_struct *work)
 	}
 
 	if (!mt792x_mcu_fw_pmctrl(dev)) {
-		cancel_delayed_work_sync(&mphy->mac_work);
+		cancel_delayed_work(&mphy->mac_work);
 		return;
 	}
 out:
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] memory: brcmstb_memc: Expand LPDDR4 check to cover for LPDDR5

[Sasha Levin]

From: Florian Fainelli <florian.fainelli@broadcom.com>

[ Upstream commit a969a0835152984a0f556434eafdee0b84213670 ]

The same limitations that apply to LPDDR4 also apply to LPDDR5. Expand
the check and rename accordingly.

Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260122003501.1191059-1-florian.fainelli@broadcom.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to complete the full analysis. Let me
compile my findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: `memory: brcmstb_memc:` (Broadcom STB memory controller
  driver)
- **Action verb**: "Expand" (extending an existing check)
- **Summary**: Expand LPDDR4 check to also cover LPDDR5 memory types

Record: [memory/brcmstb_memc] [expand] [Extend existing LPDDR4 hardware
limitation check to also apply to LPDDR5]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by**: Florian Fainelli <florian.fainelli@broadcom.com>
  (author, Broadcom employee, original driver author)
- **Link**: https://patch.msgid.link/20260122003501.1191059-1-
  florian.fainelli@broadcom.com
- **Signed-off-by**: Krzysztof Kozlowski <krzk@kernel.org> (subsystem
  maintainer who applied it)
- No Fixes: tag, no Cc: stable, no Reported-by, no Tested-by, no
  Reviewed-by

Record: Author is the original driver author (Florian Fainelli at
Broadcom). Applied by memory subsystem maintainer Krzysztof Kozlowski.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The message says: "The same limitations that apply to LPDDR4 also apply
to LPDDR5. Expand the check and rename accordingly."

The limitation in question: On LPDDR4 chips, the inactivity timeout for
Self-Refresh Power Down (SRPD) cannot be changed because the dynamic
tuning process is affected by the inactivity timeout, making it non-
functional. This same limitation applies to LPDDR5.

Without this fix, on LPDDR5 hardware, a user writing to the `srpd` sysfs
attribute would successfully change the SRPD inactivity timeout, which
would break the dynamic tuning process, making the memory controller
non-functional.

Record: [Bug: missing LPDDR5 check allows dangerous SRPD timeout
modification on LPDDR5 hardware] [Symptom: dynamic memory tuning becomes
non-functional on LPDDR5 systems] [Root cause: original code only
checked for LPDDR4, not LPDDR5]

### Step 1.4: DETECT HIDDEN BUG FIXES
This IS a real bug fix disguised as "expand." The keyword "expand" masks
the fact that without this change, LPDDR5 users can corrupt their memory
controller tuning through the sysfs interface.

Record: [Yes, this is a hidden bug fix. It prevents a user from making
the dynamic tuning process non-functional on LPDDR5 hardware.]

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File**: `drivers/memory/brcmstb_memc.c`
- **Lines added**: ~4 (new define, extra condition, rename)
- **Lines removed**: ~3 (old function name, old single condition)
- **Functions modified**: `brcmstb_memc_uses_lpddr4` renamed to
  `brcmstb_memc_uses_lpddr45`, `srpd_store` (caller updated)
- **Scope**: Single-file, surgical fix

Record: [1 file changed, ~4 lines added, ~3 removed] [Functions:
brcmstb_memc_uses_lpddr4→brcmstb_memc_uses_lpddr45, srpd_store] [Single-
file surgical fix]

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Hunk 1** - Define addition:
- Before: Only `CNTRLR_CONFIG_LPDDR4_SHIFT` (value 5) defined
- After: Also defines `CNTRLR_CONFIG_LPDDR5_SHIFT` (value 6)

**Hunk 2** - Function logic change:
- Before: `brcmstb_memc_uses_lpddr4()` returns true only if register
  value == 5 (LPDDR4)
- After: `brcmstb_memc_uses_lpddr45()` returns true if register value ==
  5 (LPDDR4) OR == 6 (LPDDR5)

**Hunk 3** - Caller update:
- Before: `srpd_store()` calls `brcmstb_memc_uses_lpddr4()`
- After: `srpd_store()` calls `brcmstb_memc_uses_lpddr45()`

The change affects the `srpd_store` sysfs path. When a user writes to
`/sys/.../srpd`, the check now correctly blocks the write for both
LPDDR4 and LPDDR5.

Record: [Before: LPDDR5 memory allowed dangerous SRPD timeout change.
After: LPDDR5 correctly blocked like LPDDR4.]

### Step 2.3: IDENTIFY THE BUG MECHANISM
This is a **hardware workaround/limitation enforcement** fix. Category
(h) - Hardware workarounds. The hardware has a limitation (LPDDR5
dynamic tuning breaks with SRPD timeout changes) that wasn't enforced in
software.

Record: [Hardware workaround - extending existing HW limitation check to
cover LPDDR5]

### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct: Yes. The author is the Broadcom engineer who wrote
  the driver and knows the hardware limitations.
- Minimal/surgical: Yes. Adds one define, one condition, renames a
  function.
- Regression risk: Extremely low. The only change is that LPDDR5 systems
  now return `-EOPNOTSUPP` from `srpd_store`, which is the correct
  behavior. LPDDR4 and other memory types are unaffected.

Record: [Fix is obviously correct, minimal, and low regression risk]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
From git blame, all the relevant code was introduced by Florian Fainelli
in commit `a4be90ff7a7d2` ("memory: brcmstb_memc: Add Broadcom STB
memory controller driver"), first appearing in v6.1-rc1. The buggy code
(missing LPDDR5 check) has been present since the driver was introduced.

Record: [Buggy code introduced in a4be90ff7a7d2, merged in v6.1-rc1.
Present in all stable trees from 6.1 onward.]

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present. This is expected.

### Step 3.3: CHECK FILE HISTORY
The file has had minimal changes: initial addition in v6.1, then a few
minor cleanups and build fixes. No major refactoring. The patch should
apply cleanly or with trivial adjustments to stable trees.

Record: [File has minimal history - 6 commits total. No conflicting
changes.]

### Step 3.4: CHECK THE AUTHOR
Florian Fainelli is the original author of this driver and a Broadcom
employee who is the de facto maintainer. His fix carries maximum
authority for this driver.

Record: [Author is the original driver author and de facto maintainer at
Broadcom]

### Step 3.5: CHECK FOR DEPENDENCIES
This is a standalone single-commit fix. No dependencies on other
commits.

Record: [Standalone fix, no dependencies]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
b4 dig failed to find the commit by message-id (the commit may not be in
the local repo since we're on 7.0 and the commit isn't present in HEAD
yet). Lore is behind a challenge page. The Link tag points to `patch.msg
id.link/20260122003501.1191059-1-florian.fainelli@broadcom.com`.

Record: [Could not access lore discussion due to anti-bot protection.
The patch was accepted by maintainer Krzysztof Kozlowski.]

### Step 4.2-4.5: MAILING LIST RESEARCH
Unable to verify via lore due to access restrictions. However, the patch
was accepted by the memory subsystem maintainer with no modifications.

Record: [UNVERIFIED: Could not access mailing list discussion. Accepted
by maintainer.]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
- `brcmstb_memc_uses_lpddr4` (renamed to `brcmstb_memc_uses_lpddr45`)
- `srpd_store` (caller)

### Step 5.2: TRACE CALLERS
`brcmstb_memc_uses_lpddr4` is called only from `srpd_store`, which is
the sysfs write handler for the `srpd` attribute. This is user-
accessible.

Record: [Called from srpd_store sysfs handler - user-triggered path]

### Step 5.3-5.4: CALL CHAIN
User writes to `/sys/devices/.../srpd` → `srpd_store()` →
`brcmstb_memc_uses_lpddr45()` reads hardware register → if LPDDR4/5,
returns -EOPNOTSUPP.

Record: [User-triggered via sysfs write. Direct path.]

### Step 5.5: SIMILAR PATTERNS
No similar patterns elsewhere - this is the only LPDDR type check in
this driver.

Record: [Unique check in this driver]

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
The driver was introduced in v6.1-rc1 (commit `a4be90ff7a7d2`). It
exists in:
- 6.1.y (LTS) ✓
- 6.6.y (LTS) ✓
- 6.12.y ✓
- 7.0 ✓

Record: [Buggy code exists in all active stable trees: 6.1.y, 6.6.y,
6.12.y]

### Step 6.2: BACKPORT COMPLICATIONS
The file has had only minor changes across versions. The patch should
apply cleanly or with trivial context adjustments.

Record: [Expected clean apply across all stable trees]

### Step 6.3: RELATED FIXES ALREADY IN STABLE
No related fixes for LPDDR5 exist.

Record: [No prior fix for this issue in stable]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY SUBSYSTEM CRITICALITY
- **Subsystem**: drivers/memory - memory controller drivers
- **Criticality**: PERIPHERAL (specific Broadcom STB hardware) but the
  consequences of the bug (making dynamic tuning non-functional) are
  significant for affected users.

Record: [drivers/memory, PERIPHERAL - Broadcom STB specific, but real
hardware impact]

### Step 7.2: SUBSYSTEM ACTIVITY
Only 6 commits to this file over its entire existence (since 6.1).
Mature and stable code.

Record: [Mature, stable codebase with minimal changes]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users of Broadcom STB SoCs with LPDDR5 memory. This is primarily
embedded/set-top-box devices.

Record: [Driver-specific: Broadcom STB users with LPDDR5 memory]

### Step 8.2: TRIGGER CONDITIONS
Triggered when a user (or system script) writes to the `srpd` sysfs
attribute on a system with LPDDR5 memory. On affected systems, the write
succeeds (should fail with -EOPNOTSUPP) and the SRPD configuration
change breaks the dynamic tuning process.

Record: [Triggered by sysfs write on LPDDR5 systems. Could be triggered
by power management scripts.]

### Step 8.3: FAILURE MODE SEVERITY
When triggered, the dynamic tuning process becomes "non-functional" (per
the existing code comment). This affects the memory controller's dynamic
tuning, which could lead to system instability or incorrect memory
timing. Severity: **MEDIUM-HIGH** for affected hardware.

Record: [Memory controller dynamic tuning becomes non-functional.
Severity: MEDIUM-HIGH]

### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT**: Prevents memory controller misconfiguration on LPDDR5
  Broadcom STB systems. Real hardware fix for real users.
- **RISK**: Extremely low. Only adds one additional condition to an
  existing check. The only behavioral change is that LPDDR5 systems now
  correctly return -EOPNOTSUPP on SRPD write, matching the existing
  LPDDR4 behavior.
- **Ratio**: Very favorable. Minimal risk, meaningful benefit for
  affected hardware.

Record: [High benefit for affected users, minimal risk. Very favorable
ratio.]

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a real hardware limitation enforcement bug on LPDDR5 systems
- Without the fix, users can break dynamic memory tuning on LPDDR5
  Broadcom STB hardware
- Extremely small and surgical (adds 1 define, 1 condition, renames
  function)
- Written by the original driver author (Florian Fainelli at Broadcom)
- Accepted by subsystem maintainer
- Applies cleanly to stable trees (minimal file history)
- Driver exists in all active LTS trees (6.1+)
- Falls into the "hardware quirk/workaround" exception category
- Zero regression risk to existing LPDDR4 or other memory type users

**AGAINST backporting:**
- Affects only Broadcom STB users with LPDDR5 memory (narrow user base)
- No Fixes: tag, no Reported-by (but this is expected for the review
  pipeline)
- The commit message uses "expand" rather than "fix" language

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - single condition addition, by
   driver author
2. **Fixes a real bug?** YES - allows dangerous SRPD modification on
   LPDDR5
3. **Important issue?** MEDIUM-HIGH - memory controller misconfiguration
4. **Small and contained?** YES - ~4 lines changed in 1 file
5. **No new features or APIs?** CORRECT - only extends an existing check
6. **Can apply to stable trees?** YES - driver exists since 6.1

### Step 9.3: EXCEPTION CATEGORIES
This falls into the **hardware quirk/workaround** category - extending
an existing hardware limitation check to cover newly-recognized
hardware.

### Step 9.4: DECISION
The fix is small, surgical, obviously correct, written by the driver
author, and prevents real hardware misconfiguration on LPDDR5 Broadcom
STB systems. The risk is negligible and the benefit is real for affected
users.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by by Florian Fainelli (driver
  author), accepted by Krzysztof Kozlowski (maintainer). No
  Fixes/Reported-by tags.
- [Phase 2] Diff analysis: 1 new #define, 1 additional condition in
  existing check function, 1 function rename, 1 caller update. Total ~4
  lines changed.
- [Phase 3] git blame: All code introduced in commit a4be90ff7a7d2
  (v6.1-rc1) by same author (Florian Fainelli).
- [Phase 3] git describe --contains: confirmed driver first appeared in
  v6.1-rc1.
- [Phase 3] git log v6.1..v6.6..v6.12: confirmed driver exists in all
  active stable trees.
- [Phase 3] git log --author="Florian Fainelli": confirmed author is
  original driver author and active maintainer.
- [Phase 3] File history: only 6 commits total, minimal churn, clean
  backport expected.
- [Phase 5] Code analysis: brcmstb_memc_uses_lpddr4 called only from
  srpd_store (sysfs write handler), user-triggerable path.
- [Phase 6] Driver exists in 6.1.y, 6.6.y, 6.12.y stable trees.
- [Phase 8] Failure mode: dynamic tuning becomes non-functional on
  LPDDR5 systems. Severity MEDIUM-HIGH.
- UNVERIFIED: Could not access lore.kernel.org discussion due to anti-
  bot protection. Relied on maintainer acceptance and commit tags.

**YES**

 drivers/memory/brcmstb_memc.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/brcmstb_memc.c b/drivers/memory/brcmstb_memc.c
index ba73470b1b134..c28fe90936168 100644
--- a/drivers/memory/brcmstb_memc.c
+++ b/drivers/memory/brcmstb_memc.c
@@ -14,6 +14,7 @@
 
 #define REG_MEMC_CNTRLR_CONFIG		0x00
 #define  CNTRLR_CONFIG_LPDDR4_SHIFT	5
+#define  CNTRLR_CONFIG_LPDDR5_SHIFT	6
 #define  CNTRLR_CONFIG_MASK		0xf
 #define REG_MEMC_SRPD_CFG_21		0x20
 #define REG_MEMC_SRPD_CFG_20		0x34
@@ -34,14 +35,15 @@ struct brcmstb_memc {
 	u32 srpd_offset;
 };
 
-static int brcmstb_memc_uses_lpddr4(struct brcmstb_memc *memc)
+static int brcmstb_memc_uses_lpddr45(struct brcmstb_memc *memc)
 {
 	void __iomem *config = memc->ddr_ctrl + REG_MEMC_CNTRLR_CONFIG;
 	u32 reg;
 
 	reg = readl_relaxed(config) & CNTRLR_CONFIG_MASK;
 
-	return reg == CNTRLR_CONFIG_LPDDR4_SHIFT;
+	return reg == CNTRLR_CONFIG_LPDDR4_SHIFT ||
+	       reg == CNTRLR_CONFIG_LPDDR5_SHIFT;
 }
 
 static int brcmstb_memc_srpd_config(struct brcmstb_memc *memc,
@@ -95,7 +97,7 @@ static ssize_t srpd_store(struct device *dev, struct device_attribute *attr,
 	 * dynamic tuning process will also get affected by the inactivity
 	 * timeout, thus making it non functional.
 	 */
-	if (brcmstb_memc_uses_lpddr4(memc))
+	if (brcmstb_memc_uses_lpddr45(memc))
 		return -EOPNOTSUPP;
 
 	ret = kstrtouint(buf, 10, &val);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] media: stm32: dcmi: stop the dma transfer on overrun

[Sasha Levin]

From: Alain Volmat <alain.volmat@foss.st.com>

[ Upstream commit 4847286b87ccda7bdec8245f35c07203ce9eb0ed ]

Ensure to stop the dma transfer whenever receiving a overrun
to avoid having a buffer partially filled with a frame and
partially with the next frame.

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the necessary information. Let me compile my
comprehensive analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `media: stm32: dcmi:`
- **Action verb**: "stop" - implies fixing incorrect behavior (not
  stopping something that should be stopped)
- **Summary**: Stops DMA transfer on hardware overrun to prevent frame
  data corruption

### Step 1.2: Tags
- `Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>` - Author,
  STMicroelectronics employee (the SoC vendor)
- `Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>` - media
  subsystem co-maintainer
- `Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>` -
  media subsystem maintainer
- No Fixes: tag, no Reported-by:, no Cc: stable (expected for autosel
  candidates)

### Step 1.3: Commit Body
The commit explicitly describes data corruption: *"avoid having a buffer
partially filled with a frame and partially with the next frame"*. This
is frame-level data corruption during video capture. The mechanism is:
when DCMI hardware overruns, DMA continues writing into the active
buffer, mixing two different frames.

### Step 1.4: Hidden Bug Fix Detection
Despite using "ensure to stop" rather than "fix", this IS a data
corruption fix. The word "ensure" indicates adding a missing safety
action. The description of mixed frames in a buffer is a concrete, real-
world data corruption scenario.

Record: This is a real data corruption fix disguised with neutral
language.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- Single file modified: `drivers/media/platform/st/stm32/stm32-dcmi.c`
- Function modified: `dcmi_irq_thread()` (the threaded IRQ handler)
- ~12 lines added, 0 lines removed (net)
- Scope: single-function surgical fix

### Step 2.2: Code Flow Change
**BEFORE**: When `IT_OVR` (overrun) occurs, the handler just increments
counters and falls through. DMA continues to run, potentially filling
the buffer with data from the next frame.

**AFTER**: When `IT_OVR` occurs:
1. Disable DCMI capture (`reg_clear(dcmi->regs, DCMI_CR, CR_CAPTURE)`)
2. Increment counters (existing code)
3. Release spinlock
4. Terminate DMA (`dmaengine_terminate_sync`)
5. Restart capture cleanly (`dcmi_restart_capture`)
6. Return `IRQ_HANDLED` early

### Step 2.3: Bug Mechanism
**Category**: Data corruption / logic fix. The overrun condition means
the DCMI FIFO overflowed and data was lost. Without stopping DMA, the
buffer ends up with partial frame N data followed by frame N+1 data,
delivering a corrupt buffer to userspace.

### Step 2.4: Fix Quality
- **Obviously correct**: Yes - the terminate+restart pattern is already
  used in `dcmi_process_jpeg()` in the same file
- **Minimal/surgical**: Yes - only the overrun handler is modified
- **Regression risk**: Low - `dmaengine_terminate_sync()` is safe in
  threaded IRQ context; `dcmi_restart_capture()` has its own internal
  locking
- **Locking correctness**: Verified - spinlock released before
  `dmaengine_terminate_sync` (which may sleep); `dcmi_restart_capture`
  takes its own lock internally

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The overrun handler code was introduced by commit `1be0a2b702308f`
(2019, v5.2 cycle) which added overrun counting, and the irq thread
structure from `37404f91ef8b91` (2017, v4.14 cycle). The buggy behavior
(not stopping DMA on overrun) was intentionally introduced by commit
`a1029f552c3f` (2018, v4.17 cycle) titled *"rework overrun/error case"*
which REMOVED the DMA stop/restart on overrun. That 2018 commit's
rationale was: *"Dma will be restarted on current frame transfer
completion."* The new commit reverses this decision because the
assumption was wrong - DMA does not properly self-recover on overrun.

### Step 3.2: No Fixes tag present
The implicit Fixes target would be `a1029f552c3f` ("rework overrun/error
case", v4.17) which exists in ALL active stable trees.

### Step 3.3: File History
The `dcmi_irq_thread` function has been stable since 2019. Recent
changes to this file are minor cleanups (style, API renames) that don't
affect the overrun path.

### Step 3.4: Author Context
Alain Volmat is from STMicroelectronics (the SoC vendor). He is an
active contributor to the STM32 media subsystem, maintaining both DCMI
and DCMIPP drivers. The patch was reviewed and signed off by both media
subsystem co-maintainers.

### Step 3.5: Dependencies
The patch was submitted as 4/12 in a series. However, patches 1-3 touch
unrelated code paths (pm_ptr, dma config at probe, descriptor creation).
Patch 5 reworks locking (makes `dcmi_restart_capture` caller-locked),
but patch 4 works correctly with the CURRENT `dcmi_restart_capture`
which has its own internal locking. This patch is self-contained.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Original Submission
Found at `http://lists.infradead.org/pipermail/linux-arm-
kernel/2026-January/1091896.html`. Part of series v2 "media: stm32:
dcmi: stability & performance enhancements" (12 patches). Cover letter
explicitly states: *"This series improve stability of the capture by
fixing the handling of the overrun which was leading to captured frame
corruption."*

### Step 4.2: Reviewers
Signed off by Sakari Ailus (media co-maintainer) and Mauro Carvalho
Chehab (media maintainer). The patch has proper maintainer chain sign-
off.

### Step 4.3-4.5: Bug Report / Stable Discussion
The bug was found during development by the hardware vendor
(STMicroelectronics). No explicit stable nomination was found, nor any
objections.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: Function Analysis
`dcmi_irq_thread` is the threaded IRQ handler, called whenever the DCMI
hardware fires an interrupt (overrun, error, or frame complete). The
`IT_OVR` flag is set by the hardware when the DCMI internal FIFO
overflows. The `dcmi_restart_capture` → `dcmi_start_capture` →
`dcmi_start_dma` chain properly sets up a new DMA transfer and re-
enables capture.

### Step 5.3-5.4: The DMA stop + restart pattern
The same pattern exists in `dcmi_process_jpeg()` at line 434-440:
`dmaengine_terminate_sync` followed by `dcmi_restart_capture`. The
overrun fix replicates this proven pattern.

### Step 5.5: Similar Patterns
`dcmi_process_jpeg` already uses the exact same terminate+restart
pattern. `dcmi_dma_callback` also calls `dcmi_restart_capture` after DMA
completion. This is a well-established pattern in the driver.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable
The buggy overrun handler (just counting, not stopping DMA) exists since
v4.17 (commit `a1029f552c3f`). It is present in ALL active stable trees
(5.4, 5.10, 5.15, 6.1, 6.6, 6.12).

### Step 6.2: Backport Complications
The patch modifies a single function with clean context. The file path
changed from `stm32/stm32-dcmi.c` to `st/stm32/stm32-dcmi.c` in 6.5+,
but the function code is identical in context. Minor adjustment may be
needed for older trees.

### Step 6.3: No related fixes already in stable for this overrun issue.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: drivers/media/platform (embedded camera driver)
- **Criticality**: PERIPHERAL (specific STM32 hardware) but important
  for embedded/IoT users
- STM32 SoCs are widely used in embedded systems, industrial cameras,
  IoT devices

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
STM32 DCMI users - embedded systems with camera interfaces on STM32MP1
SoCs.

### Step 8.2: Trigger Conditions
Overrun occurs when the camera sends data faster than DMA can drain the
DCMI FIFO. This is common during high-resolution or high-framerate
capture, or under system load. Not timing-dependent - it's a hardware
FIFO overflow condition.

### Step 8.3: Failure Mode Severity
**Data corruption** - frames delivered to userspace contain mixed data
from two different frames. For embedded camera applications (industrial
vision, surveillance, medical), this is a **HIGH** severity issue since
corrupted frames can lead to incorrect decisions.

### Step 8.4: Risk-Benefit
- **Benefit**: HIGH - prevents data corruption in active video capture
  on STM32 platforms
- **Risk**: LOW - ~12 lines, single function, follows proven existing
  pattern in the same driver, correct locking, no API changes
- **Ratio**: Strongly favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes real data corruption (mixed frames in buffer)
- Small, surgical fix (12 lines in one function)
- Follows proven existing pattern in same driver (`dcmi_process_jpeg`)
- Author is from the hardware vendor (STMicroelectronics)
- Signed off by both media subsystem maintainers
- Correct locking model (spinlock released before sleeping call)
- Buggy code exists in all active stable trees
- Self-contained - does not depend on other patches in the series

**AGAINST backporting:**
- Part of a 12-patch series (but verified standalone correctness)
- Later patches (5, 7) further modify this code (but patch 4 is correct
  without them)
- No explicit Cc: stable (expected for autosel candidates)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - pattern matches existing code
   in same driver, vendor-tested
2. Fixes a real bug? **YES** - data corruption (mixed frames)
3. Important issue? **YES** - data corruption during video capture
4. Small and contained? **YES** - 12 lines, single function
5. No new features/APIs? **YES** - no new features
6. Can apply to stable? **YES** - code context is unchanged in stable
   trees

### Step 9.3: No exception categories apply; this is a straightforward
bug fix.

---

## Verification

- [Phase 1] Parsed tags: SOBs from author (STMicroelectronics), Sakari
  Ailus, Mauro Carvalho Chehab
- [Phase 2] Diff analysis: ~12 lines added to overrun path in
  `dcmi_irq_thread()`, adds DMA stop + restart
- [Phase 3] git blame: overrun handler code from commit `1be0a2b702308f`
  (2019, v5.2); bug-causing rework from `a1029f552c3f` (2018, v4.17)
- [Phase 3] git show `a1029f552c3f`: confirmed it intentionally removed
  DMA stop/restart on overrun - present in all stable trees
- [Phase 3] Verified `dcmi_restart_capture()` has internal locking -
  standalone patch is correct
- [Phase 4] Found original submission at lists.infradead.org; cover
  letter confirms frame corruption fix
- [Phase 4] Verified patch 5/12 changes `dcmi_restart_capture` locking,
  but patch 4 works with current code
- [Phase 4] Patch 7/12 changes `terminate_sync` to `terminate_async` -
  optimization, not required for correctness
- [Phase 5] Verified same pattern (`dmaengine_terminate_sync` +
  `dcmi_restart_capture`) exists in `dcmi_process_jpeg()` at lines
  434-440
- [Phase 5] Verified `dcmi_start_capture()` re-enables CR_CAPTURE at
  line 372, matching our clear at overrun
- [Phase 6] Confirmed code exists unchanged in all active stable trees
  (5.4+)
- [Phase 8] Failure mode: data corruption (mixed frames) - severity HIGH

The fix is small, surgical, follows proven patterns in the same driver,
and prevents real data corruption on STM32 embedded platforms.

**YES**

 drivers/media/platform/st/stm32/stm32-dcmi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/platform/st/stm32/stm32-dcmi.c b/drivers/media/platform/st/stm32/stm32-dcmi.c
index 13762861b7694..496e0781a957b 100644
--- a/drivers/media/platform/st/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/st/stm32/stm32-dcmi.c
@@ -447,9 +447,21 @@ static irqreturn_t dcmi_irq_thread(int irq, void *arg)
 	spin_lock_irq(&dcmi->irqlock);
 
 	if (dcmi->misr & IT_OVR) {
+		/* Disable capture */
+		reg_clear(dcmi->regs, DCMI_CR, CR_CAPTURE);
+
 		dcmi->overrun_count++;
+
 		if (dcmi->overrun_count > OVERRUN_ERROR_THRESHOLD)
 			dcmi->errors_count++;
+
+		spin_unlock_irq(&dcmi->irqlock);
+		dmaengine_terminate_sync(dcmi->dma_chan);
+
+		if (dcmi_restart_capture(dcmi))
+			dev_err(dcmi->dev, "%s: Cannot restart capture\n", __func__);
+
+		return IRQ_HANDLED;
 	}
 	if (dcmi->misr & IT_ERR)
 		dcmi->errors_count++;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] wifi: mt76: abort ROC on chanctx changes

[Sasha Levin]

From: Felix Fietkau <nbd@nbd.name>

[ Upstream commit de62b24224ac1533c17b3d5bae77164a82ae2e49 ]

mt76_change_chanctx() calls mt76_phy_update_channel() which switches
the hardware channel. If ROC is active on the same phy, this switches
away from the ROC channel and clears offchannel, but leaves ROC state
intact. Mac80211 still thinks the phy is on the ROC channel.

Abort any active ROC before proceeding, matching the pattern already
used in add, remove, assign, unassign, and switch chanctx functions.

Link: https://patch.msgid.link/20260309060730.87840-5-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have all the information needed for a complete analysis. Let me
compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `wifi: mt76:` (MediaTek MT76 wireless driver)
- Action: "abort" - stopping an ongoing operation to prevent state
  inconsistency
- Summary: Abort ROC (Remain on Channel) on channel context changes
- Record: [wifi: mt76] [abort] [Abort active ROC when channel context
  changes to prevent state desync]

**Step 1.2: Tags**
- Link: `https://patch.msgid.link/20260309060730.87840-5-nbd@nbd.name`
  (patch 5 in a series)
- Signed-off-by: Felix Fietkau `<nbd@nbd.name>` (mt76 subsystem
  maintainer/author)
- No Fixes: tag (expected for autosel candidates)
- No Reported-by (no external report; author found the issue)
- Record: Author is the mt76 subsystem creator. Patch 5 of a series.

**Step 1.3: Commit Body Analysis**
The commit describes a concrete bug mechanism:
1. `mt76_change_chanctx()` calls `mt76_phy_update_channel()` which
   switches the hardware channel
2. If ROC is active on the same phy, the hardware switches away from ROC
   channel
3. `offchannel` is cleared (set to false), but ROC state (`roc_vif`,
   `roc_link`, `roc_work` timer) remains intact
4. Mac80211 still believes the phy is on the ROC channel

Record: [State inconsistency between driver and mac80211 when chanctx
changes during active ROC] [Symptom: mac80211 and hardware out of sync
on channel state] [Bug introduced with channel.c in v6.14]

**Step 1.4: Hidden Bug Fix Detection**
This is clearly a bug fix, not cleanup. The commit explicitly describes
a state desynchronization between the hardware and the mac80211 layer.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/net/wireless/mediatek/mt76/channel.c`
- +3 lines added (including blank line), 0 removed
- Function modified: `mt76_change_chanctx()`
- Scope: Single-function surgical fix
- Record: [channel.c +3/-0] [mt76_change_chanctx modified] [Single-file
  surgical fix]

**Step 2.2: Code Flow Change**
Before: `mt76_change_chanctx()` directly proceeds to cancel mac_work and
update channel.
After: Before canceling mac_work, checks if ROC is active
(`phy->roc_vif`) and aborts it via `mt76_abort_roc(phy)`.

**Step 2.3: Bug Mechanism**
Verified by reading `__mt76_set_channel()` at mac80211.c:1045:
`phy->offchannel = offchannel;`. When called from
`mt76_phy_update_channel()` with `offchannel = false`, it clears the
offchannel flag. But the ROC state (`roc_vif`, `roc_link`, `roc_work`)
remains set, causing a desynchronization.

Classification: **Logic/correctness fix** - missing cleanup of related
state when switching channels.

**Step 2.4: Fix Quality**
- Obviously correct: follows the exact pattern established by all other
  chanctx functions which abort scans
- Minimal: 2 lines of actual logic
- `mt76_abort_roc()` handles its own locking (takes `dev->mutex`
  internally), so calling it before the existing `mutex_lock` is correct
- Regression risk: extremely low - if ROC is not active (`roc_vif ==
  NULL`), the check is a no-op

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
From git blame, the buggy `mt76_change_chanctx()` was introduced by
commit `82334623af0cd` ("wifi: mt76: add chanctx functions for multi-
channel phy support") by Felix Fietkau on 2025-01-02. This commit is in
v6.14.

**Step 3.2: Fixes Tag**
No Fixes: tag present. The implicit target is `82334623af0cd` which
introduced `mt76_change_chanctx` without ROC abort handling.

**Step 3.3: File History**
The file has 7 commits since creation: the original, scanning code, ROC
functions, offchannel link, a deref fix, abort scan/roc on hw restart,
and relicensing. No conflicting changes near the modified area.

**Step 3.4: Author**
Felix Fietkau (nbd@nbd.name) is the creator and maintainer of the mt76
driver. He wrote the original `channel.c` file and all major chanctx
functions.

**Step 3.5: Dependencies**
The commit is patch 5 of a series (msgid `-5-`). However, the fix is
**self-contained**:
- `mt76_abort_roc()` already exists in the tree (since `a8f424c1287cc`,
  in v6.14)
- `phy->roc_vif` already exists in `mt76.h`
- `mt76_abort_roc` is declared in `mt76.h` and accessible from
  `channel.c`
- No other patch from the series is needed for this fix to work
  correctly.

---

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.5**: Lore.kernel.org is behind Anubis anti-bot protection
and could not be accessed. The `b4 dig` also did not find a match for
the message-id (possibly a future date issue). However, the patch URL is
well-formed and the commit is by the subsystem maintainer, providing
strong quality assurance.

Record: [UNVERIFIED: Could not access lore/b4 due to anti-bot
protection] [Author is mt76 maintainer which provides confidence in
quality]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
- `mt76_change_chanctx()` - modified to add ROC abort call

**Step 5.2: Callers**
`mt76_change_chanctx` is a mac80211 callback assigned via
`ieee80211_ops`. It is called by mac80211 whenever the channel context
configuration changes (width changes, radar detection changes). This is
a normal operation path triggered by AP configuration, DFS, or
regulatory changes.

**Step 5.3: Callees**
`mt76_abort_roc()` calls:
1. `cancel_delayed_work_sync(&phy->roc_work)` - cancels the ROC timeout
2. `mt76_roc_complete(phy)` under mutex - restores main channel, frees
   offchannel link, notifies mac80211

**Step 5.4: Call Chain**
Userspace/regulatory -> mac80211 -> `mt76_change_chanctx` -> bug
triggers if ROC active. This is reachable from normal WiFi operation
(e.g., DFS, bandwidth changes during P2P).

**Step 5.5: Similar Patterns**
All 5 other chanctx functions (`add`, `remove`, `assign`, `unassign`,
`switch`) already call `mt76_abort_scan()`. The fix adds the equivalent
`mt76_abort_roc()` to the one function that was missing it.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable Trees**
- `channel.c` with `mt76_change_chanctx` was introduced in v6.14 (commit
  `82334623af0cd`)
- `mt76_abort_roc` function exists since v6.14 (commit `a8f424c1287cc`)
- `mt76_abort_roc` is declared in `mt76.h` even in v6.14 (confirmed at
  line 1586)
- Bug affects: v6.14.y and later stable trees

**Step 6.2: Backport Complications**
The code in v6.14 matches exactly: `mt76_change_chanctx()` is identical
to the pre-patch state in v7.0. The patch would apply cleanly. No
forward-declaration issues since `mt76_abort_roc` is declared in
`mt76.h`.

**Step 6.3: Related Fixes**
No alternative fix for this specific bug exists in stable trees.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
- Subsystem: WiFi/wireless drivers (drivers/net/wireless/mediatek/mt76)
- Criticality: IMPORTANT - mt76 is one of the most widely used WiFi
  chipset drivers (MT7921, MT7922, MT7925, MT7996, etc.), found in many
  laptops and routers

**Step 7.2: Activity**
Actively maintained by Felix Fietkau with recent commits in the channel
management area. The multi-radio/chanctx support is relatively new
(v6.14).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
All users of MediaTek mt76 WiFi chipsets who use P2P, scanning, or any
ROC functionality while channel context changes occur.

**Step 8.2: Trigger Conditions**
- Trigger: Channel context change (width change or radar detection)
  while ROC is active
- Likelihood: Moderate - occurs during DFS, bandwidth negotiation, or
  regulatory changes that happen to coincide with P2P discovery or off-
  channel management frames
- Not directly triggered by unprivileged users (requires wireless state
  machine interaction)

**Step 8.3: Failure Mode**
- Driver/mac80211 state desynchronization
- ROC operations fail silently or behave unpredictably
- P2P connection failures
- Dangling ROC state may cause subsequent operations to fail or produce
  unexpected behavior
- Severity: **MEDIUM-HIGH** (functional failure, not crash, but can
  break WiFi connectivity features)

**Step 8.4: Risk-Benefit**
- Benefit: Fixes real state inconsistency in a widely-used WiFi driver
- Risk: Extremely low - 2 lines, guarded by `if (phy->roc_vif)` check,
  calls well-tested existing function
- Ratio: Very favorable

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backporting:
- Fixes a real state desynchronization bug between driver and mac80211
- 2-line fix, obviously correct, minimal risk
- Written by the mt76 subsystem maintainer/author (Felix Fietkau)
- Follows the established pattern used by all other chanctx functions
- Self-contained, no dependencies on other patches
- Applies cleanly to v6.14+ stable trees
- mt76 is a widely-used WiFi driver

AGAINST backporting:
- No crash/panic, no data corruption - the bug causes functional issues
  (ROC state desync)
- No user reports (no Reported-by tag)
- Part of a larger series (other patches in series not evaluated)

UNRESOLVED:
- Could not access mailing list discussion due to anti-bot protection
- Could not verify if other patches in the series are also being
  considered

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** - trivial 2-line check, follows
   existing pattern, by subsystem maintainer
2. Fixes a real bug? **YES** - state desync between driver and mac80211
   during ROC
3. Important issue? **MEDIUM-HIGH** - WiFi functionality failure, not
   crash
4. Small and contained? **YES** - 2 lines in 1 file
5. No new features? **YES** - purely a bug fix
6. Can apply to stable? **YES** - clean apply to v6.14+

**Step 9.3: Exception Categories**
Not an exception category; this is a standard bug fix.

**Step 9.4: Decision**
The fix is small, surgical, obviously correct, written by the subsystem
maintainer, and fixes a real state inconsistency bug in a widely-used
WiFi driver. The risk is minimal and the benefit is clear.

---

## Verification

- [Phase 1] Parsed tags: Link to patch.msgid.link, SOB by Felix Fietkau
  (mt76 maintainer)
- [Phase 2] Diff analysis: +3 lines (2 logic + 1 blank) in
  `mt76_change_chanctx()`, adds ROC abort guard
- [Phase 2] Verified `__mt76_set_channel()` at mac80211.c:1045 sets
  `phy->offchannel = offchannel`, confirming the bug mechanism
- [Phase 3] git blame: `mt76_change_chanctx` introduced by commit
  `82334623af0cd` (v6.14) by Felix Fietkau
- [Phase 3] `mt76_abort_roc` introduced by `a8f424c1287cc` (v6.14),
  declared in mt76.h line 1586
- [Phase 3] Confirmed `b36d55610215a` (EXPORT_SYMBOL_GPL for abort_roc)
  is NOT in v6.14 but not needed since abort_roc is declared in mt76.h
- [Phase 3] Confirmed patch is self-contained: all referenced
  functions/fields exist in v6.14
- [Phase 4] UNVERIFIED: Could not access lore.kernel.org or b4 dig
  results due to anti-bot protection
- [Phase 5] Verified all 5 other chanctx functions call
  `mt76_abort_scan()` - this fix adds the analogous ROC abort
- [Phase 5] Verified `mt76_abort_roc` cancels work, locks mutex, calls
  `mt76_roc_complete`, unlocks - proper cleanup
- [Phase 6] `82334623af0cd` is in v6.14 (confirmed via `git merge-base
  --is-ancestor`)
- [Phase 6] v6.14 `mt76_change_chanctx` code is identical to pre-patch
  v7.0 - clean apply
- [Phase 8] Failure mode: state desynchronization causing ROC/P2P
  failures, severity MEDIUM-HIGH

**YES**

 drivers/net/wireless/mediatek/mt76/channel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/channel.c b/drivers/net/wireless/mediatek/mt76/channel.c
index 2b705bdb7993c..a6e45b8d63d6b 100644
--- a/drivers/net/wireless/mediatek/mt76/channel.c
+++ b/drivers/net/wireless/mediatek/mt76/channel.c
@@ -88,6 +88,9 @@ void mt76_change_chanctx(struct ieee80211_hw *hw,
 			 IEEE80211_CHANCTX_CHANGE_RADAR)))
 		return;
 
+	if (phy->roc_vif)
+		mt76_abort_roc(phy);
+
 	cancel_delayed_work_sync(&phy->mac_work);
 
 	mutex_lock(&dev->mutex);
-- 
2.53.0