* Re: [PATCH] dt-bindings: spi: st,stm32-qspi: Add power-domains property
From: Mark Brown @ 2026-06-29 17:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Christophe Kerello, Patrice Chotard
Cc: linux-spi, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260618-add_power_domain_for_qpsi-v1-1-4d7e57bcfb9a@foss.st.com>
On Thu, 18 Jun 2026 08:46:35 +0200, Patrice Chotard wrote:
> dt-bindings: spi: st,stm32-qspi: Add power-domains property
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.3
Thanks!
[1/1] dt-bindings: spi: st,stm32-qspi: Add power-domains property
https://git.kernel.org/broonie/spi/c/7a0d22e632a6
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v8 6/6] pinctrl: mediatek: Add MT6735 pinctrl driver
From: Linus Walleij @ 2026-06-30 11:17 UTC (permalink / raw)
To: Yassine Oudjana
Cc: Yassine Oudjana, Sean Wang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Andy Teng, linux-mediatek, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <PjcK3j_TxnXwwBQ8ATPAPOO6LJl5b0Laa_6eSBTVfEfqsxIcaeDEVS4q4UkvGQA7CLQbuGxopLF6p3eIh1JAIDTkPFIgwp-hVP-fex_WEqU=@protonmail.com>
On Sat, Jun 13, 2026 at 11:20 AM Yassine Oudjana
<y.oudjana@protonmail.com> wrote:
> On Monday, June 8th, 2026 at 9:41 PM, Linus Walleij <linusw@kernel.org> wrote:
> > > From: Yassine Oudjana <y.oudjana@protonmail.com>
> > >
> > > Add a driver for the MediaTek MT6735 SoC pin controller. This driver
> > > also supports the pin controller on MT6735M, which lacks 6 physical
> > > pins (198-203) used for MSDC2 on MT6735.
> > >
> > > Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> >
> > Sashiko has good comments on this driver, look into them!
>
> Didn't receive any comments and I don't see anything on the mailing list
> archives either. Am I missing something?
https://lore.kernel.org/linux-devicetree/20260530155503.9A6C41F00893@smtp.kernel.org/
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] net: airoha: fix MIB stats collection to be lossless
From: Aniket Negi @ 2026-06-30 11:18 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Christian Marangi, Simon Horman, linux-arm-kernel,
linux-mediatek, netdev, linux-kernel, Aniket Negi
The airoha_dev_get_hw_stats() function had two correctness issues in the
way it collects hardware MIB counters.
Bug 1: Read-clear race causes silent packet loss in statistics
airoha_update_hw_stats() read all MIB registers and then cleared them
via REG_FE_GDM_MIB_CLEAR. There is a time window between the last
register read and the hardware clear. Any packet that the hardware
counts during this window is lost: the register is incremented, then
cleared, without the increment ever being read by software. Under
sustained traffic this causes a permanent and growing undercount in all
reported statistics.
This is particularly misleading for tx_ok_pkts and tx_ok_bytes, which
routers and traffic monitors use to detect packet forwarding loss
between two points in a hardware-accelerated path (e.g., between two
netdevs in the QDMA/PPE fast-path). An inaccurate count makes it
impossible to reliably attribute drops in the forwarding pipeline
without capturing traffic at both ends independently.
Bug 2: 32-bit counter overflow causes stat corruption
Several MIB registers are only 32 bits wide: tx_drops, tx_broadcast,
tx_multicast, rx_drops, rx_broadcast, rx_multicast, rx_errors,
rx_crc_error, rx_over_errors, rx_fragment, rx_jabber, and the runt and
long buckets of the tx_len[]/rx_len[].
The original code relied on MIB_CLEAR to keep register values small
enough that a simple '+= val' per cycle did not lose data across a
wrap. Once clearing is removed (to fix Bug 1), raw '+= val' silently
corrupts the accumulated software counter on overflow.
Fix both issues together:
- 64-bit H+L register pairs (tx_ok_pkts, tx_ok_bytes, tx_len[1..5],
rx_ok_pkts, rx_ok_bytes, rx_len[1..5]): read directly from hardware
without clearing. Hardware accumulates the full running total; a
single direct assignment per poll is correct and lossless.
- 32-bit registers (tx_drops, tx_broadcast, tx_multicast, rx_drops,
rx_broadcast, rx_multicast, rx_errors, rx_crc_error, rx_over_errors,
rx_fragment, rx_jabber, and the runt/long buckets in tx_len[0]/[6]
and rx_len[0]/[6]): track the previous hardware value in a new
hw_prev_stats sub-struct inside airoha_hw_stats and accumulate
(u32)(curr - prev) into the 64-bit software counter. Unsigned
subtraction handles wrap-around transparently:
prev=0xFFFFFF00, curr=0x00000010 -> delta=(u32)(0x10-0xFFFFFF00)=0x110
Remove the REG_FE_GDM_MIB_CLEAR write from airoha_update_hw_stats()
entirely. Because the driver no longer clears hardware counters, the
read-clear race window is eliminated.
The hw_prev_stats fields are zero-initialised by the existing
devm_kzalloc() call in airoha_alloc_gdm_device().
Fixes: 8f4695fb67b2 ("net: airoha: better handle MIBs for GDM ports with multiple devs attached")
Signed-off-by: Aniket Negi <aniket.negi03@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 132 +++++++++++------------
drivers/net/ethernet/airoha/airoha_eth.h | 22 ++++
2 files changed, 86 insertions(+), 68 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 1caf6766f2c0..7ae4e294478e 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1696,133 +1696,133 @@ static void airoha_dev_get_hw_stats(struct airoha_gdm_dev *dev)
u64_stats_update_begin(&dev->stats.syncp);
- /* TX */
+ /* TX - 64-bit H+L registers: hw accumulates the total, read directly. */
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id));
- dev->stats.tx_ok_pkts += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
- dev->stats.tx_ok_pkts += val;
+ dev->stats.tx_ok_pkts = (u64)val << 32;
+ dev->stats.tx_ok_pkts += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_H(port->id));
- dev->stats.tx_ok_bytes += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
- dev->stats.tx_ok_bytes += val;
+ dev->stats.tx_ok_bytes = (u64)val << 32;
+ dev->stats.tx_ok_bytes += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
+ /* TX - 32-bit registers: accumulate delta to handle wrap-around. */
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_DROP_CNT(port->id));
- dev->stats.tx_drops += val;
+ dev->stats.tx_drops += (u32)(val - dev->stats.hw_prev_stats.tx_drops);
+ dev->stats.hw_prev_stats.tx_drops = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_BC_CNT(port->id));
- dev->stats.tx_broadcast += val;
+ dev->stats.tx_broadcast += (u32)(val - dev->stats.hw_prev_stats.tx_broadcast);
+ dev->stats.hw_prev_stats.tx_broadcast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_MC_CNT(port->id));
- dev->stats.tx_multicast += val;
+ dev->stats.tx_multicast += (u32)(val - dev->stats.hw_prev_stats.tx_multicast);
+ dev->stats.hw_prev_stats.tx_multicast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_RUNT_CNT(port->id));
- dev->stats.tx_len[i] += val;
+ dev->stats.tx_len[i] += (u32)(val - dev->stats.hw_prev_stats.tx_len[i]);
+ dev->stats.hw_prev_stats.tx_len[i] = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] += (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_L(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] = (u64)val << 32;
+ dev->stats.tx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_LONG_CNT(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i] += (u32)(val - dev->stats.hw_prev_stats.tx_len[i]);
+ dev->stats.hw_prev_stats.tx_len[i++] = val;
/* RX */
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_H(port->id));
- dev->stats.rx_ok_pkts += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_L(port->id));
- dev->stats.rx_ok_pkts += val;
+ dev->stats.rx_ok_pkts = (u64)val << 32;
+ dev->stats.rx_ok_pkts += airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_H(port->id));
- dev->stats.rx_ok_bytes += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_L(port->id));
- dev->stats.rx_ok_bytes += val;
+ dev->stats.rx_ok_bytes = (u64)val << 32;
+ dev->stats.rx_ok_bytes += airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_DROP_CNT(port->id));
- dev->stats.rx_drops += val;
+ dev->stats.rx_drops += (u32)(val - dev->stats.hw_prev_stats.rx_drops);
+ dev->stats.hw_prev_stats.rx_drops = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_BC_CNT(port->id));
- dev->stats.rx_broadcast += val;
+ dev->stats.rx_broadcast += (u32)(val - dev->stats.hw_prev_stats.rx_broadcast);
+ dev->stats.hw_prev_stats.rx_broadcast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_MC_CNT(port->id));
- dev->stats.rx_multicast += val;
+ dev->stats.rx_multicast += (u32)(val - dev->stats.hw_prev_stats.rx_multicast);
+ dev->stats.hw_prev_stats.rx_multicast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ERROR_DROP_CNT(port->id));
- dev->stats.rx_errors += val;
+ dev->stats.rx_errors += (u32)(val - dev->stats.hw_prev_stats.rx_errors);
+ dev->stats.hw_prev_stats.rx_errors = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_CRC_ERR_CNT(port->id));
- dev->stats.rx_crc_error += val;
+ dev->stats.rx_crc_error += (u32)(val - dev->stats.hw_prev_stats.rx_crc_error);
+ dev->stats.hw_prev_stats.rx_crc_error = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OVERFLOW_DROP_CNT(port->id));
- dev->stats.rx_over_errors += val;
+ dev->stats.rx_over_errors += (u32)(val - dev->stats.hw_prev_stats.rx_over_errors);
+ dev->stats.hw_prev_stats.rx_over_errors = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_FRAG_CNT(port->id));
- dev->stats.rx_fragment += val;
+ dev->stats.rx_fragment += (u32)(val - dev->stats.hw_prev_stats.rx_fragment);
+ dev->stats.hw_prev_stats.rx_fragment = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_JABBER_CNT(port->id));
- dev->stats.rx_jabber += val;
+ dev->stats.rx_jabber += (u32)(val - dev->stats.hw_prev_stats.rx_jabber);
+ dev->stats.hw_prev_stats.rx_jabber = val;
i = 0;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_RUNT_CNT(port->id));
- dev->stats.rx_len[i] += val;
+ dev->stats.rx_len[i] += (u32)(val - dev->stats.hw_prev_stats.rx_len[i]);
+ dev->stats.hw_prev_stats.rx_len[i] = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] += (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
- val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_L(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] = (u64)val << 32;
+ dev->stats.rx_len[i++] += airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_L(port->id));
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_LONG_CNT(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] += (u32)(val - dev->stats.hw_prev_stats.rx_len[i]);
+ dev->stats.hw_prev_stats.rx_len[i++] = val;
u64_stats_update_end(&dev->stats.syncp);
}
@@ -1839,10 +1839,6 @@ static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
airoha_dev_get_hw_stats(port->devs[i]);
}
- /* Reset MIB counters */
- airoha_fe_set(dev->eth, REG_FE_GDM_MIB_CLEAR(port->id),
- FE_GDM_MIB_RX_CLEAR_MASK | FE_GDM_MIB_TX_CLEAR_MASK);
-
spin_unlock(&port->stats_lock);
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 2765244d937c..af12ad6eac17 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -244,6 +244,28 @@ struct airoha_hw_stats {
u64 rx_fragment;
u64 rx_jabber;
u64 rx_len[7];
+
+ struct {
+ /* Previous HW register values for 32-bit counter delta tracking.
+ * Storing the last seen value and accumulating (u32)(curr - prev)
+ * in 64-bit software counter & handles wrap-around transparently
+ * via unsigned arithmetic. These fields are never reported to
+ * userspace.
+ */
+ u32 tx_drops;
+ u32 tx_broadcast;
+ u32 tx_multicast;
+ u32 tx_len[7];
+ u32 rx_drops;
+ u32 rx_broadcast;
+ u32 rx_multicast;
+ u32 rx_errors;
+ u32 rx_crc_error;
+ u32 rx_over_errors;
+ u32 rx_fragment;
+ u32 rx_jabber;
+ u32 rx_len[7];
+ } hw_prev_stats;
};
enum {
--
2.43.0
^ permalink raw reply related
* [PATCH v2] i2c: mt7621: Use dev_err_probe() for clock acquisition failures
From: phucduc.bui @ 2026-06-30 11:19 UTC (permalink / raw)
To: Stefan Roese, Andi Shyti, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-i2c, linux-kernel, linux-arm-kernel, linux-mediatek,
bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Use dev_err_probe() when devm_clk_get_enabled() fails. This correctly
handles -EPROBE_DEFER while simplifying the error handling.
No functional change intended.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
update in v2 :
Add the missing return after dev_err_probe().
drivers/i2c/busses/i2c-mt7621.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt7621.c b/drivers/i2c/busses/i2c-mt7621.c
index 0a288c998419..8ab7a304a02c 100644
--- a/drivers/i2c/busses/i2c-mt7621.c
+++ b/drivers/i2c/busses/i2c-mt7621.c
@@ -280,10 +280,9 @@ static int mtk_i2c_probe(struct platform_device *pdev)
return PTR_ERR(i2c->base);
i2c->clk = devm_clk_get_enabled(&pdev->dev, NULL);
- if (IS_ERR(i2c->clk)) {
- dev_err(&pdev->dev, "Failed to enable clock\n");
- return PTR_ERR(i2c->clk);
- }
+ if (IS_ERR(i2c->clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(i2c->clk),
+ "Failed to enable clock\n");
i2c->dev = &pdev->dev;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 06/16] arm64: dts: st: add i2c1 pins for stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
Add the i2c1 pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v1)
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 456ece7f8ebc..db485b9ed904 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -203,6 +203,25 @@ pins {
};
};
+ /omit-if-no-ref/
+ i2c1_pins_a: i2c1-0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 13, AF9)>, /* I2C1_SCL */
+ <STM32_PINMUX('A', 2, AF10)>; /* I2C1_SDA */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
+ /omit-if-no-ref/
+ i2c1_sleep_pins_a: i2c1-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 13, ANALOG)>, /* I2C1_SCL */
+ <STM32_PINMUX('A', 2, ANALOG)>; /* I2C1_SDA */
+ };
+ };
+
/omit-if-no-ref/
i2c2_pins_a: i2c2-0 {
pins {
--
2.43.0
^ permalink raw reply related
* RE: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Alim Akhtar @ 2026-06-30 11:28 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', 'Peter Griffin'
Cc: 'Denzeel Oliva', 'Sylwester Nawrocki',
'Chanwoo Choi', 'Michael Turquette',
'Stephen Boyd', 'Brian Masney',
'Rob Herring', 'Conor Dooley', linux-samsung-soc,
linux-clk, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <b035916c-e985-4acf-930b-bb74814ae748@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Tuesday, June 30, 2026 4:43 PM
> To: Peter Griffin <peter.griffin@linaro.org>; Alim Akhtar
> <alim.akhtar@samsung.com>
> Cc: Denzeel Oliva <wachiturroxd150@gmail.com>; Sylwester Nawrocki
> <s.nawrocki@samsung.com>; Chanwoo Choi <cw00.choi@samsung.com>;
> Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> <sboyd@kernel.org>; Brian Masney <bmasney@redhat.com>; Rob Herring
> <robh@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-samsung-
> soc@vger.kernel.org; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock
> parents
>
> On 30/06/2026 13:02, Peter Griffin wrote:
> > Hi Alim,
> >
> > On Tue, 30 Jun 2026 at 04:53, Alim Akhtar <alim.akhtar@samsung.com>
> wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Peter Griffin <peter.griffin@linaro.org>
> >>> Sent: Monday, June 29, 2026 6:02 PM
> >>> To: Denzeel Oliva <wachiturroxd150@gmail.com>
> >>> Cc: Krzysztof Kozlowski <krzk@kernel.org>; Sylwester Nawrocki
> >>> <s.nawrocki@samsung.com>; Chanwoo Choi
> <cw00.choi@samsung.com>; Alim
> >>> Akhtar <alim.akhtar@samsung.com>; Michael Turquette
> >>> <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; Brian
> >>> Masney <bmasney@redhat.com>; Rob Herring <robh@kernel.org>;
> Conor
> >>> Dooley <conor+dt@kernel.org>; linux-samsung-soc@vger.kernel.org;
> >>> linux- clk@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> >>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> >>> Subject: Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate
> >>> clock parents
> >>>
> >>> Hi Krysztof & Denzeel,
> >>>
> >>> On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva
> >>> <wachiturroxd150@gmail.com>
> >>> wrote:
> >>>>
> >>>> Correct eight PERIS gate clock parents to match the hardware clock
> >>>> tree and reorder the GIC mux parents so mout_peris_bus_user is the
> >>>> default source.
> >>>>
> >>>> Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
> >>>> ---
> >>>
> >>> Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> >>>
> >>> @Krysztof: I was thinking, maybe we should establish a new rule/best
> >>> practice for Samsung clock upstream submissions whereby patch
> >>> contributors should link to the downstream cal-if code for the SoC
> >>> after the --
> >>> - line. That would make reviewing the patches' correctness a bit
> >>> easier, as the downstream cal-if code would be readily available to the
> reviewer.
> >>>
> >> We can leave this choice to the reviewer if they want to refer to
> downstream cal-if code.
> >
> > Generally I would like to, but I also don't have time to hunt around
> > the internet for a downstream kernel tree. My rationale was that the
> > submitter is most likely to know where the downstream code is, and is
> > likely using it for the upstream clock implementation. So, linking to
> > it as part of the submission should hopefully be fairly easy.
> >
> > If it is a Samsung SoC for which no public code is available that's
> > fine. I didn't intend this to be a hard requirement: "you can't
> > upstream x,y,z unless you link to the cal-if code". I meant it more as
> > "best practice/guidance"; if the cal-if code is publicly available,
> > linking to it would be a useful reference for reviewers.
>
> cal-if as vendor tree? Some contributors just base their work on downstream
> GPL-compliance dumps from opensource.samsung.com, so not sure how
> that link would work.
>
Right, I am not against adding any best practice guideline, but I wonder only few of us will end up reviewing those patches.
And for other reviewer, cal-if will add more confusion as it is completely out of {tree / clk subsystem} interface.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH] PCI: dwc: meson: Fix reset GPIO initial state
From: Manivannan Sadhasivam @ 2026-06-30 11:28 UTC (permalink / raw)
To: Yue Wang, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Remi Pommarel, Ronald Claveau
Cc: linux-pci, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20260616-fix-meson-pcie-reset-gpio-v1-1-fca404b4c8be@aliel.fr>
On Tue, 16 Jun 2026 09:07:25 +0200, Ronald Claveau wrote:
> Commit 4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio
> descriptor") inverted the reset assertion logic to use proper gpio
> descriptor semantics, and moved the polarity configuration to the
> device tree as GPIO_ACTIVE_LOW. However, the initial GPIO state
> "GPIOD_OUT_LOW" was not updated accordingly.
>
> Change GPIOD_OUT_LOW to GPIOD_OUT_HIGH to get the right behaviour.
>
> [...]
Applied, thanks!
[1/1] PCI: dwc: meson: Fix reset GPIO initial state
commit: 702c89eec25a10932bed074cb9adf0fcfcb6652c
Best regards,
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Thorsten Leemhuis @ 2026-06-30 11:29 UTC (permalink / raw)
To: Jiajia Liu, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Ming Yen Hsieh, Leon Yen
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Linux kernel regressions list
In-Reply-To: <20260528033814.46418-1-liujiajia@kylinos.cn>
On 5/28/26 05:38, Jiajia Liu wrote:
> Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
> to avoid reinitializing the wcid->poll_list.
>
> Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
Jiajia Liu, Felox: given that the problem seems to be in 7.1, should we
ask the stable team to pick this regression fix up, as this change was
mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
Ciao, Thorsten
> According to the corruption information, prev->next was changed to itself.
>
> wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
> wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
> wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
> slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
> list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
>
> mt76_wcid_add_poll+0x95/0xd0 [mt76]
> mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
> mt7925_rx_check+0xa7/0xc0 [mt7925_common]
> mt76_dma_rx_poll+0x50d/0x790 [mt76]
> mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
>
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
>
> Changes in v2:
> - use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
> wcid publish check suggested by Sean
> - subject and commit message update
>
> ---
> drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
> index 4ae5e4715a9c..b78b4cd206e0 100644
> --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
> +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
> @@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> {
> struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
> struct mt76_dev *dev = phy->dev;
> + struct mt76_wcid *published;
> int ret;
> int i;
>
> @@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> mtxq->wcid = wcid->idx;
> }
>
> - ewma_signal_init(&wcid->rssi);
> - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> + published = rcu_dereference_protected(dev->wcid[wcid->idx],
> + lockdep_is_held(&dev->mutex));
> + if (published != wcid) {
> + WARN_ON_ONCE(published);
> + ewma_signal_init(&wcid->rssi);
> + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> + mt76_wcid_init(wcid, phy->band_idx);
> + } else {
> + wcid->phy_idx = phy->band_idx;
> + }
> +
> phy->num_sta++;
>
> - mt76_wcid_init(wcid, phy->band_idx);
> out:
> mutex_unlock(&dev->mutex);
>
^ permalink raw reply
* Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Peter Griffin @ 2026-06-30 11:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Denzeel Oliva, Sylwester Nawrocki, Chanwoo Choi,
Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Conor Dooley, linux-samsung-soc, linux-clk, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <b035916c-e985-4acf-930b-bb74814ae748@kernel.org>
Hi Krzysztof,
On Tue, 30 Jun 2026 at 12:12, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/06/2026 13:02, Peter Griffin wrote:
> > Hi Alim,
> >
> > On Tue, 30 Jun 2026 at 04:53, Alim Akhtar <alim.akhtar@samsung.com> wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Peter Griffin <peter.griffin@linaro.org>
> >>> Sent: Monday, June 29, 2026 6:02 PM
> >>> To: Denzeel Oliva <wachiturroxd150@gmail.com>
> >>> Cc: Krzysztof Kozlowski <krzk@kernel.org>; Sylwester Nawrocki
> >>> <s.nawrocki@samsung.com>; Chanwoo Choi <cw00.choi@samsung.com>;
> >>> Alim Akhtar <alim.akhtar@samsung.com>; Michael Turquette
> >>> <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; Brian
> >>> Masney <bmasney@redhat.com>; Rob Herring <robh@kernel.org>; Conor
> >>> Dooley <conor+dt@kernel.org>; linux-samsung-soc@vger.kernel.org; linux-
> >>> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> >>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> >>> Subject: Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock
> >>> parents
> >>>
> >>> Hi Krysztof & Denzeel,
> >>>
> >>> On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva <wachiturroxd150@gmail.com>
> >>> wrote:
> >>>>
> >>>> Correct eight PERIS gate clock parents to match the hardware clock
> >>>> tree and reorder the GIC mux parents so mout_peris_bus_user is the
> >>>> default source.
> >>>>
> >>>> Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
> >>>> ---
> >>>
> >>> Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> >>>
> >>> @Krysztof: I was thinking, maybe we should establish a new rule/best
> >>> practice for Samsung clock upstream submissions whereby patch
> >>> contributors should link to the downstream cal-if code for the SoC after the --
> >>> - line. That would make reviewing the patches' correctness a bit easier, as the
> >>> downstream cal-if code would be readily available to the reviewer.
> >>>
> >> We can leave this choice to the reviewer if they want to refer to downstream cal-if code.
> >
> > Generally I would like to, but I also don't have time to hunt around
> > the internet for a downstream kernel tree. My rationale was that the
> > submitter is most likely to know where the downstream code is, and is
> > likely using it for the upstream clock implementation. So, linking to
> > it as part of the submission should hopefully be fairly easy.
> >
> > If it is a Samsung SoC for which no public code is available that's
> > fine. I didn't intend this to be a hard requirement: "you can't
> > upstream x,y,z unless you link to the cal-if code". I meant it more as
> > "best practice/guidance"; if the cal-if code is publicly available,
> > linking to it would be a useful reference for reviewers.
>
> cal-if as vendor tree? Some contributors just base their work on
> downstream GPL-compliance dumps from opensource.samsung.com, so not sure
> how that link would work.
Urgh, I see. My suggestion kind of assumed the downstream vendor tree
had been pushed to a public Git repository, similar to how Google used
to push their gs101 sources, for example:
https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/drivers/soc/google/cal-if/
A link to a tarball for sure isn't as easy to just click through and
take a look which is what I was hoping to achieve. Thanks for the link
though, maybe that will come in useful at some point.
Peter
^ permalink raw reply
* Re: [PATCH v4] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Vinod Koul @ 2026-06-30 11:34 UTC (permalink / raw)
To: Hongling Zeng
Cc: Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd, dmaengine,
linux-arm-kernel, linux-sunxi, linux-kernel, zhongling0719,
Frank Li
In-Reply-To: <20260618020609.1155962-1-zenghongling@kylinos.cn>
On 18-06-26, 10:06, Hongling Zeng wrote:
> When terminating DMA transfers, active descriptors are not properly
> reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
> descriptors and their LLI chains to be permanently leaked.
>
> Fix by using vchan_terminate_vdesc() which handles both cyclic and
> non-cyclic descriptors by adding them to desc_terminated queue for
> proper cleanup.
>
> Add pchan->desc != pchan->done check to prevent double-adding completed
> descriptors, which would corrupt the list.
Thanks for the patch. Please consider revising the subject which should
describe the changes in the patch and not the fix/issue.
A better one would be "fix reclaim descriptors while terminating"
>
> Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> Suggested-by: Frank Li <Frank.li@oss.nxp.com>
>
> ---
> Change in v2;
> -Add pchan->desc != pchan->done check to prevent race condition
> where completed descriptors could be double-added to desc_completed
> list, causing list corruption
> ---
> Change in v3:
> -Fix by using vchan_terminate_vdesc() as suggested by Frank Li
> ---
> Change in v4:
> -Correct the commit message
> ---
> drivers/dma/sun6i-dma.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 7a79f346250a..134ae840f176 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
>
> spin_lock_irqsave(&vchan->vc.lock, flags);
>
> - if (vchan->cyclic) {
> - vchan->cyclic = false;
> - if (pchan && pchan->desc) {
> - struct virt_dma_desc *vd = &pchan->desc->vd;
> - struct virt_dma_chan *vc = &vchan->vc;
> -
> - list_add_tail(&vd->node, &vc->desc_completed);
> - }
> + if (pchan && pchan->desc && pchan->desc != pchan->done) {
> + struct virt_dma_desc *vd = &pchan->desc->vd;
> +
> + vchan_terminate_vdesc(vd);
> }
>
> + vchan->cyclic = false;
> vchan_get_all_descriptors(&vchan->vc, &head);
>
> if (pchan) {
> --
> 2.25.1
--
~Vinod
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: aspeed: Make AST2700 SoC1 JTAG master TRST optional
From: Linus Walleij @ 2026-06-30 11:52 UTC (permalink / raw)
To: Billy Tsai
Cc: Andrew Jeffery, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, linux-aspeed, openbmc, linux-gpio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260616-pinctrl-fix-v1-0-621036e45c7c@aspeedtech.com>
On Tue, Jun 16, 2026 at 4:30 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> The JTAGM1 pin group of the AST2700 SoC1 includes ball D12, which
> carries the TRST signal. TRST is an optional signal for a JTAG master:
> designs that do not wire it may need the D12 ball for other functions,
> but with TRST embedded in the group they cannot use the JTAG master at
> all.
>
> Split D12 into a new JTAGM1TRST group under the existing JTAGM1
> function, so TRST is only muxed when a board explicitly requests it.
> Patch 1 adds the new group to the device tree binding and patch 2
> splits the group in the driver.
>
> Note that this changes the meaning of the existing JTAGM1 group: boards
> that do use TRST now need to select both the JTAGM1 and JTAGM1TRST
> groups.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Patches applied!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/5] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
This patch set adds the device tree nodes for the Lynx10G SerDes blocks
found on the LS1028A, LS1046A, LS1088A and LS2088A SoCs.
The first patch also transitions the LX2160A SoC dtsi to use the
device-specific Lynx28G SerDes compatible.
Ioana Ciornei (1):
arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
Vladimir Oltean (4):
arm64: dts: lx2160a: transition to device-specific SerDes compatible
strings
arm64: dts: ls1028a: describe the Lynx 10G SerDes
arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 ++++
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 +++++++
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 +++++++
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 ++++++++++++
.../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
.../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 150 +++++++++++++++++-
.../dts/freescale/fsl-lx2162a-clearfog.dts | 2 +-
.../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
.../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 24 +++
10 files changed, 427 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
--
2.25.1
^ permalink raw reply
* Re: [PATCH v4 09/10] riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Wandun @ 2026-06-30 12:00 UTC (permalink / raw)
To: Pratyush Yadav
Cc: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
alex, akpm, pasha.tatashin, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <2vxzechoi8o0.fsf@kernel.org>
On 6/30/26 19:12, Pratyush Yadav wrote:
> On Tue, Jun 30 2026, Wandun Chen wrote:
>
>> From: Wandun Chen <chenwandun@lixiang.com>
>>
>> Apply the same non-dumpable reserved memory filtering to RISC-V kdump
>> as was done for arm64. Use of_reserved_mem_kdump_exclude() to drop
>> flagged regions from the elfcorehdr PT_LOAD segments, and
>> of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.
>>
>> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
>> ---
>> arch/riscv/kernel/machine_kexec_file.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
>> index 59d4bbc848a8..25359d583bc3 100644
>> --- a/arch/riscv/kernel/machine_kexec_file.c
>> +++ b/arch/riscv/kernel/machine_kexec_file.c
>> @@ -10,6 +10,7 @@
>> #include <linux/elf.h>
>> #include <linux/slab.h>
>> #include <linux/of.h>
>> +#include <linux/of_reserved_mem.h>
>> #include <linux/libfdt.h>
>> #include <linux/types.h>
>> #include <linux/memblock.h>
>> @@ -64,6 +65,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>>
>> nr_ranges = 1; /* For exclusion of crashkernel region */
>> walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
>> + nr_ranges += of_reserved_mem_kdump_nr_ranges();
>>
>> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
>> if (!cmem)
>> @@ -77,6 +79,8 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>>
>> /* Exclude crashkernel region */
>> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
>> + if (!ret)
>> + ret = of_reserved_mem_kdump_exclude(cmem);
>> if (!ret)
>> ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>
> Nit: can you do the usual pattern of if (err) goto err; instead?
>
Sure, will fix in the next version.
Best regards,
Wandun
> So this would look like:
>
> /* Exclude crashkernel region */
> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> if (ret)
> goto out;
>
> ret = of_reserved_mem_kdump_exclude(cmem);
> if (ret)
> goto out;
>
> ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> out:
> ...
>
> With this,
>
> Acked-by: Pratyush Yadav <pratyush@kernel.org>
>
^ permalink raw reply
* RE: [EXT] i.MX95: EdgeLock Enclave secure storage
From: Pankaj Gupta @ 2026-06-30 12:06 UTC (permalink / raw)
To: Fabio Estevam
Cc: Schrempf Frieder,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Peng Fan,
Stefano Babic, Frank Li
In-Reply-To: <CAOMZO5DgENq8RU6s2CPnKsf53i=7zoBeO38m_BtV=w54hr2hgQ@mail.gmail.com>
Hi Fabio,
Thank you for your kind words and for your interest in the upstream EdgeLock Enclave (ELE) work.
Regarding the specific areas you mentioned, please find my comments inline below.
Regards,
Pankaj Gupta
NXP Semiconductor
> -----Original Message-----
> From: Fabio Estevam <festevam@gmail.com>
> Sent: 13 June 2026 19:29
> To: Pankaj Gupta <pankaj.gupta@nxp.com>
> Cc: Schrempf Frieder <frieder.schrempf@kontron.de>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-arm-
> kernel@lists.infradead.org>; open list:HARDWARE RANDOM NUMBER
> GENERATOR CORE <linux-crypto@vger.kernel.org>; Peng Fan
> <peng.fan@nxp.com>; Stefano Babic <sbabic@nabladev.com>; Frank Li
> <frank.li@nxp.com>
> Subject: [EXT] i.MX95: EdgeLock Enclave secure storage
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> Hi Pankaj,
>
> First of all, thank you for your work on upstreaming the EdgeLock Enclave (ELE)
> support. It is great to finally see the ELE framework landing upstream after a
> long development effort.
>
> I am currently evaluating the state of i.MX95 secure-boot and storage-security
> support based on current linux-next, with the goal of understanding what can
> already be achieved using upstream software and what pieces are still under
> development.
>
> From my review, it appears that the following infrastructure is already available
> upstream:
>
> - ELE/V2X mailbox support for i.MX95.
The current upstream driver only supports i.MX8ULP. However, it establishes the foundation for ELE/V2X mailbox support on i.MX95.
> - OCOTP/ELE nvmem support for fuse access.
The upstream OCOTP/ELE nvmem support is independent of the recently accepted Secure Enclave driver for i.MX8ULP.
> - Secure-enclave bindings documenting the i.MX95 ELE HSM.
>
> However, I could not find upstream support for several capabilities that would
> be useful for secure storage deployments on i.MX95, including:
>
> - An ELE-backed trusted-key provider for the Linux trusted key framework.
Work in this area is currently ongoing. The intention is to provide an ELE-backed trusted key implementation that can integrate with the Linux trusted key framework.
> - Integration allowing Linux to use ELE as a key-sealing/ unsealing backend.
Support for using ELE as a backend for key sealing and unsealing is also under development and is planned to build on top of the trusted key support.
> - i.MX95-specific crypto acceleration exposed through the Linux crypto API for
> dm-crypt use cases.
ELE itself is not designed to act as a general-purpose cryptographic accelerator.
For dm-crypt use cases, the current direction is to perform the cryptographic operations through OP-TEE using Arm Cryptography Extensions (Arm-CE),
while ensuring that plaintext keys are only present in on-chip OCRAM and never leave the SoC.
Upstream discussions and corresponding RFC patches are expected once the related OP-TEE PTA support is available for review in OP-TEE OS.
>
> Are you aware of any ongoing upstream or planned development activities in
> these areas, particularly for i.MX95?
The activities mentioned above are the primary ongoing efforts related to secure storage and key management on i.MX95.
As these developments progress, they will be proposed and discussed through the relevant upstream mailing lists.
>
> Any information about the upstream roadmap, ongoing development, or
> expected direction for these features would be greatly appreciated.
>
> Thanks again for your work and for any insights you can share.
>
> Regards,
>
> Fabio Estevam
^ permalink raw reply
* Re: [PATCH v11 0/6] gpio: siul2-s32g2: add initial GPIO driver
From: Linus Walleij @ 2026-06-30 11:50 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Dong Aisheng, Jacky Bai, Greg Kroah-Hartman, Rafael J. Wysocki,
Srinivas Kandagatla, Alberto Ruiz, Christophe Lizzi, devicetree,
Enric Balletbo, Eric Chanudet, imx, linux-arm-kernel, linux-gpio,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot
In-Reply-To: <20260610132116.1998140-1-khristineandreea.barbulescu@oss.nxp.com>
On Wed, Jun 10, 2026 at 2:21 PM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
> This patch series adds support for basic GPIO
> operations using gpio-regmap.
Sorry for my confused comment on jun 10, these patches all go to the
pinctrl subsystem so I should merge them.
Can you make a v12 based on v7.2-rc1 and I will apply them.
Pick up ACKs!
I will not apply the device tree patch, this will need to be queued
in the SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 12/17] arm64: dts: nvidia: Add EL2 virtual timer interrupt
From: Jon Hunter @ 2026-06-30 12:09 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
linux-tegra@vger.kernel.org, Lorenzo Pieralisi, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, Rafael J. Wysocki,
Mark Rutland, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Ge Gordon, BST Linux Kernel Upstream Group,
Jesper Nilsson, Lars Persson, Alim Akhtar, Ivaylo Ivanov,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dinh Nguyen, Matthias Brugger, AngeloGioacchino Del Regno,
Thierry Reding, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <86wlvgpacz.wl-maz@kernel.org>
Hi Marc,
On 30/06/2026 11:54, Marc Zyngier wrote:
...
>> Sorry for the delay. I gave this a test because I observed the warning
>> that was added on the Tegra194 and Tegra234 platforms. This change
>> fixes the warning for Tegra234, but on Tegra194 the platforms I tested
>> hang on boot. It appears to be similar to the issue that Marek saw on
>> his platforms and so I am wondering if Tegra194 also doesn't have this
>> wired up?
>
> I think you are in a better position than me to find out. It also
> could be a firmware issue not making the PPI a Group-1 interrupt, and
> therefore not allow Linux to configure the interrupt.
Yes absolutely. I will see what I can find out.
>> Was there any resolution to the issue reported by Marek?
>>
>> FYI, the Tegra194 SoC has the 'NVIDIA Carmel ARM v8.2' CPUs [0].
>
> There is no resolution so far. Florian was going to check what the
> deal is with the Broadcom-related systems, but hasn't come back with
> an answer yet.
>
> The possibilities are as follows:
>
> - remove the interrupt for the EL2 virtual timer and live with the
> warning
>
> - add a patch such as [1], which should document the reason why this
> is now working (and fallback to the EL2 physical timer)
>
> I'm happy either way, as long as we know exactly what we are dealing
> with on each affected platform.
I would like to get the warning fixed for Tegra234. Do you want to split
that part out of your patch and then I can test and we can at least fix
for that device while I see whats up with Tegra194?
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] pinctrl: bcm2835: Don't remove an unregistered GPIO chip
From: Linus Walleij @ 2026-06-30 12:10 UTC (permalink / raw)
To: Daniel McCarthy
Cc: Florian Fainelli, Ray Jui, Scott Branden, linux-gpio,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617220451.15298-1-daniel@dragonzap.com>
On Wed, Jun 17, 2026 at 11:05 PM Daniel McCarthy <daniel@dragonzap.com> wrote:
> If the devm_pinctrl_register() function fails,
> bcm2835_pinctrl_probe() calls gpiochip_remove()
> before gpiochip_add_data() has registered the GPIO chip.
>
> This means that upon failure the gpio_chip.gpiodev
> is NULL resulting in a null pointer dereference
> inside the gpiochip_remove() function.
>
> Remove the unnecessary function call to gpiochip_remove().
> No GPIO cleanup is required because the GPIO chip
> has not yet been registered. Without this change there
> is potential for a kernel panic upon registration failure
>
> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
> Signed-off-by: Daniel McCarthy <daniel@dragonzap.com>
Patch applied as nonurgent fix.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/6] KVM: arm64: ptdump: Undo making the ptdump code mmu aware
From: Wei-Lin Chang @ 2026-06-30 12:10 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene, Wei-Lin Chang
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>
Commit 204f7c018d76 ("KVM: arm64: ptdump: Make KVM ptdump code s2 mmu
aware") changed the ptdump code from storing the kvm pointer to storing
the mmu pointer, in order to reuse code for shadow ptdumps.
This turned out to be buggy as the nested mmus can be freed before the
last access to the ptdump files. To prepare for a new implementation of
the shadow ptdumps which solves this problem, revert the effects of the
commit to avoid this UAF.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/ptdump.c | 32 +++++++++++++++-----------------
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 7c32f1f7772c..d5aa9eff08d1 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -19,7 +19,7 @@
#define KVM_PGTABLE_MAX_LEVELS (KVM_PGTABLE_LAST_LEVEL + 1)
struct kvm_ptdump_guest_state {
- struct kvm_s2_mmu *mmu;
+ struct kvm *kvm;
struct ptdump_pg_state parser_state;
struct addr_marker ipa_marker[MARKERS_LEN];
struct ptdump_pg_level level[KVM_PGTABLE_MAX_LEVELS];
@@ -112,10 +112,10 @@ static int kvm_ptdump_build_levels(struct ptdump_pg_level *level, u32 start_lvl)
return 0;
}
-static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm_s2_mmu *mmu)
+static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
{
struct kvm_ptdump_guest_state *st;
- struct kvm_pgtable *pgtable = mmu->pgt;
+ struct kvm_pgtable *pgtable = kvm->arch.mmu.pgt;
int ret;
st = kzalloc_obj(struct kvm_ptdump_guest_state, GFP_KERNEL_ACCOUNT);
@@ -131,7 +131,7 @@ static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm_s2_mmu
st->ipa_marker[0].name = "Guest IPA";
st->ipa_marker[1].start_address = BIT(pgtable->ia_bits);
- st->mmu = mmu;
+ st->kvm = kvm;
return st;
}
@@ -139,8 +139,8 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
{
int ret;
struct kvm_ptdump_guest_state *st = m->private;
- struct kvm_s2_mmu *mmu = st->mmu;
- struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
+ struct kvm *kvm = st->kvm;
+ struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
.cb = kvm_ptdump_visitor,
.arg = &st->parser_state,
@@ -163,15 +163,14 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
{
- struct kvm_s2_mmu *mmu = m->i_private;
- struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
+ struct kvm *kvm = m->i_private;
struct kvm_ptdump_guest_state *st;
int ret;
if (!kvm_get_kvm_safe(kvm))
return -ENOENT;
- st = kvm_ptdump_parser_create(mmu);
+ st = kvm_ptdump_parser_create(kvm);
if (IS_ERR(st)) {
ret = PTR_ERR(st);
goto err_with_kvm_ref;
@@ -189,7 +188,7 @@ static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
static int kvm_ptdump_guest_close(struct inode *m, struct file *file)
{
- struct kvm *kvm = kvm_s2_mmu_to_kvm(m->i_private);
+ struct kvm *kvm = m->i_private;
void *st = ((struct seq_file *)file->private_data)->private;
kfree(st);
@@ -224,15 +223,14 @@ static int kvm_pgtable_levels_show(struct seq_file *m, void *unused)
static int kvm_pgtable_debugfs_open(struct inode *m, struct file *file,
int (*show)(struct seq_file *, void *))
{
- struct kvm_s2_mmu *mmu = m->i_private;
- struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
+ struct kvm *kvm = m->i_private;
struct kvm_pgtable *pgtable;
int ret;
if (!kvm_get_kvm_safe(kvm))
return -ENOENT;
- pgtable = mmu->pgt;
+ pgtable = kvm->arch.mmu.pgt;
ret = single_open(file, show, pgtable);
if (ret < 0)
@@ -252,7 +250,7 @@ static int kvm_pgtable_levels_open(struct inode *m, struct file *file)
static int kvm_pgtable_debugfs_close(struct inode *m, struct file *file)
{
- struct kvm *kvm = kvm_s2_mmu_to_kvm(m->i_private);
+ struct kvm *kvm = m->i_private;
kvm_put_kvm(kvm);
return single_release(m, file);
@@ -275,11 +273,11 @@ static const struct file_operations kvm_pgtable_levels_fops = {
void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
{
debugfs_create_file("stage2_page_tables", 0400, kvm->debugfs_dentry,
- &kvm->arch.mmu, &kvm_ptdump_guest_fops);
+ kvm, &kvm_ptdump_guest_fops);
debugfs_create_file("ipa_range", 0400, kvm->debugfs_dentry,
- &kvm->arch.mmu, &kvm_pgtable_range_fops);
+ kvm, &kvm_pgtable_range_fops);
debugfs_create_file("stage2_levels", 0400, kvm->debugfs_dentry,
- &kvm->arch.mmu, &kvm_pgtable_levels_fops);
+ kvm, &kvm_pgtable_levels_fops);
if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT))
kvm->arch.debugfs_nv_dentry = debugfs_create_dir("nested", kvm->debugfs_dentry);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/6] KVM: arm64: ptdump: Fix UAF when mmu->pgt is freed
From: Wei-Lin Chang @ 2026-06-30 12:10 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene, Wei-Lin Chang
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>
ptdump files can still be read after the pgt of the canonical mmu is
freed, if they are opened before the VM debugfs directory is removed.
This triggers UAF in places where we cache the pgt pointer or access it
without checking its validity.
Check the pgt is still alive under the mmu_lock before accessing the
pgt.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260623142443.648972-1-weilin.chang@arm.com?part=1
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/ptdump.c | 38 ++++++++++++++++++++++++--------------
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index d5aa9eff08d1..752d8e0cd25c 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -115,13 +115,21 @@ static int kvm_ptdump_build_levels(struct ptdump_pg_level *level, u32 start_lvl)
static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
{
struct kvm_ptdump_guest_state *st;
- struct kvm_pgtable *pgtable = kvm->arch.mmu.pgt;
+ struct kvm_pgtable *pgtable;
int ret;
st = kzalloc_obj(struct kvm_ptdump_guest_state, GFP_KERNEL_ACCOUNT);
if (!st)
return ERR_PTR(-ENOMEM);
+ guard(write_lock)(&kvm->mmu_lock);
+ if (!kvm->arch.mmu.pgt) {
+ kfree(st);
+ return ERR_PTR(-ENXIO);
+ }
+
+ pgtable = kvm->arch.mmu.pgt;
+
ret = kvm_ptdump_build_levels(&st->level[0], pgtable->start_level);
if (ret) {
kfree(st);
@@ -137,7 +145,6 @@ static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
{
- int ret;
struct kvm_ptdump_guest_state *st = m->private;
struct kvm *kvm = st->kvm;
struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
@@ -154,11 +161,11 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
.seq = m,
};
- write_lock(&kvm->mmu_lock);
- ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
- write_unlock(&kvm->mmu_lock);
+ guard(write_lock)(&kvm->mmu_lock);
+ if (mmu->pgt)
+ return kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
- return ret;
+ return 0;
}
static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
@@ -206,17 +213,23 @@ static const struct file_operations kvm_ptdump_guest_fops = {
static int kvm_pgtable_range_show(struct seq_file *m, void *unused)
{
- struct kvm_pgtable *pgtable = m->private;
+ struct kvm *kvm = m->private;
+
+ guard(write_lock)(&kvm->mmu_lock);
+ if (kvm->arch.mmu.pgt)
+ seq_printf(m, "%2u\n", kvm->arch.mmu.pgt->ia_bits);
- seq_printf(m, "%2u\n", pgtable->ia_bits);
return 0;
}
static int kvm_pgtable_levels_show(struct seq_file *m, void *unused)
{
- struct kvm_pgtable *pgtable = m->private;
+ struct kvm *kvm = m->private;
+
+ guard(write_lock)(&kvm->mmu_lock);
+ if (kvm->arch.mmu.pgt)
+ seq_printf(m, "%1d\n", KVM_PGTABLE_MAX_LEVELS - kvm->arch.mmu.pgt->start_level);
- seq_printf(m, "%1d\n", KVM_PGTABLE_MAX_LEVELS - pgtable->start_level);
return 0;
}
@@ -224,15 +237,12 @@ static int kvm_pgtable_debugfs_open(struct inode *m, struct file *file,
int (*show)(struct seq_file *, void *))
{
struct kvm *kvm = m->i_private;
- struct kvm_pgtable *pgtable;
int ret;
if (!kvm_get_kvm_safe(kvm))
return -ENOENT;
- pgtable = kvm->arch.mmu.pgt;
-
- ret = single_open(file, show, pgtable);
+ ret = single_open(file, show, kvm);
if (ret < 0)
kvm_put_kvm(kvm);
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/6] KVM: arm64: ptdump: Shadow ptdump fixes
From: Wei-Lin Chang @ 2026-06-30 12:09 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene, Wei-Lin Chang
Hi,
This is v2 of fixing shadow ptdump debugfs files. Unfortunately I couldn't make
per mmu ptdump files work after all, mainly because there isn't a clean way to
locate the specific nested mmu for each ptdump file as the nested mmus could be
freed when the file gets opened. Therefore in this series a single file
"shadow_page_tables" is created that dumps all valid mmus' page table
information.
An advantage of this is that this new ptdump file have a lifetime identical to
other ptdump files i.e. stage2_page_tables, ipa_range, etc., hence avoiding the
dentry UAF found last time [1].
With this all ptdump files are only removed when the last kvm reference gets
dropped and kvm_destroy_vm_debugfs() is called, in their open(), show()
functions the nested mmu array and mmu->pgt are checked with mmu_lock held to
prevent UAF.
Patch 1-2: Undo previous shadow ptdump implementation.
Patch 3: Fix a mmu->pgt UAF that happens when ptdump files are read after
mmu->pgt is freed.
Patch 4-5: Preparation for the shadow page table dump file.
Patch 6: Implementation of the shadow page table dump file.
The fixes are tested with CONFIG_PROVE_LOCKING,
CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
Thanks!
* Changes from v1 ([2]):
- Move from per mmu ptdump files to one file that will dump all shadow page
tables.
[1]: https://lore.kernel.org/kvmarm/ajty6I7ZqodP4ous@sm-arm-grace07/
[2]: https://lore.kernel.org/kvmarm/20260623142443.648972-1-weilin.chang@arm.com/
Wei-Lin Chang (6):
KVM: arm64: ptdump: Remove shadow ptdump files
KVM: arm64: ptdump: Undo making the ptdump code mmu aware
KVM: arm64: ptdump: Fix UAF when mmu->pgt is freed
KVM: arm64: ptdump: Factor out initialization of
kvm_ptdump_guest_state
KVM: arm64: ptdump: Extract kvm_ptdump_guest_open() from canonical
ptdump path
KVM: arm64: ptdump: Introduce the shadow ptdump file
arch/arm64/include/asm/kvm_host.h | 5 +-
arch/arm64/include/asm/kvm_mmu.h | 4 -
arch/arm64/kvm/nested.c | 18 +--
arch/arm64/kvm/ptdump.c | 185 ++++++++++++++++++++----------
4 files changed, 135 insertions(+), 77 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/6] KVM: arm64: ptdump: Remove shadow ptdump files
From: Wei-Lin Chang @ 2026-06-30 12:10 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene, Wei-Lin Chang
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>
Previously we exposed shadow page tables by creating a debugfs ptdump
file whenever a nested mmu instance gets bound to a new context, and
deleting the debugfs file whose context was getting unbound.
This turned out to be buggy, as the instance<->context binding process
is done with the mmu_lock held, and debugfs creation/deletion can sleep.
Revert most of commit 19e15dc73f0f ("KVM: arm64: nv: Expose shadow page
tables in debugfs"), keep the "nested" debugfs directory for use in a
later patch where we'll expose the shadow ptdump in another way.
Fixes: 19e15dc73f0f ("KVM: arm64: nv: Expose shadow page tables in debugfs")
Reported-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Closes: https://lore.kernel.org/kvmarm/aiuF0KSvvv-ZozI1@sm-arm-grace07/
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 5 +----
arch/arm64/include/asm/kvm_mmu.h | 4 ----
arch/arm64/kvm/nested.c | 6 +-----
arch/arm64/kvm/ptdump.c | 23 -----------------------
4 files changed, 2 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 2faa60df847d..94bced53a323 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -217,10 +217,6 @@ struct kvm_s2_mmu {
*/
bool nested_stage2_enabled;
-#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
- struct dentry *shadow_pt_debugfs_dentry;
-#endif
-
/*
* true when this MMU needs to be unmapped before being used for a new
* purpose.
@@ -424,6 +420,7 @@ struct kvm_arch {
/* Nested virtualization info */
struct dentry *debugfs_nv_dentry;
#endif
+
};
struct kvm_vcpu_fault_info {
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 6eae7e7e2a68..c1e535e3d931 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -392,12 +392,8 @@ static inline bool kvm_supports_cacheable_pfnmap(void)
#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
void kvm_s2_ptdump_create_debugfs(struct kvm *kvm);
-void kvm_nested_s2_ptdump_create_debugfs(struct kvm_s2_mmu *mmu);
-void kvm_nested_s2_ptdump_remove_debugfs(struct kvm_s2_mmu *mmu);
#else
static inline void kvm_s2_ptdump_create_debugfs(struct kvm *kvm) {}
-static inline void kvm_nested_s2_ptdump_create_debugfs(struct kvm_s2_mmu *mmu) {}
-static inline void kvm_nested_s2_ptdump_remove_debugfs(struct kvm_s2_mmu *mmu) {}
#endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
#endif /* __ASSEMBLER__ */
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index faa4a48f265d..6435efd65cb5 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -834,10 +834,8 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
kvm->arch.nested_mmus_next = (i + 1) % kvm->arch.nested_mmus_size;
/* Make sure we don't forget to do the laundry */
- if (kvm_s2_mmu_valid(s2_mmu)) {
- kvm_nested_s2_ptdump_remove_debugfs(s2_mmu);
+ if (kvm_s2_mmu_valid(s2_mmu))
s2_mmu->pending_unmap = true;
- }
/*
* The virtual VMID (modulo CnP) will be used as a key when matching
@@ -851,8 +849,6 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
s2_mmu->tlb_vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
s2_mmu->nested_stage2_enabled = vcpu_read_sys_reg(vcpu, HCR_EL2) & HCR_VM;
- kvm_nested_s2_ptdump_create_debugfs(s2_mmu);
-
out:
atomic_inc(&s2_mmu->refcnt);
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index c9140e22abcf..7c32f1f7772c 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -17,7 +17,6 @@
#define MARKERS_LEN 2
#define KVM_PGTABLE_MAX_LEVELS (KVM_PGTABLE_LAST_LEVEL + 1)
-#define S2FNAMESZ sizeof("0x0123456789abcdef-0x0123456789abcdef-s2-disabled")
struct kvm_ptdump_guest_state {
struct kvm_s2_mmu *mmu;
@@ -273,28 +272,6 @@ static const struct file_operations kvm_pgtable_levels_fops = {
.release = kvm_pgtable_debugfs_close,
};
-void kvm_nested_s2_ptdump_create_debugfs(struct kvm_s2_mmu *mmu)
-{
- struct dentry *dent;
- char file_name[S2FNAMESZ];
-
- snprintf(file_name, sizeof(file_name), "0x%016llx-0x%016llx-s2-%sabled",
- mmu->tlb_vttbr,
- mmu->tlb_vtcr,
- mmu->nested_stage2_enabled ? "en" : "dis");
-
- dent = debugfs_create_file(file_name, 0400,
- mmu->arch->debugfs_nv_dentry, mmu,
- &kvm_ptdump_guest_fops);
-
- mmu->shadow_pt_debugfs_dentry = dent;
-}
-
-void kvm_nested_s2_ptdump_remove_debugfs(struct kvm_s2_mmu *mmu)
-{
- debugfs_remove(mmu->shadow_pt_debugfs_dentry);
-}
-
void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
{
debugfs_create_file("stage2_page_tables", 0400, kvm->debugfs_dentry,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/6] KVM: arm64: ptdump: Extract kvm_ptdump_guest_open() from canonical ptdump path
From: Wei-Lin Chang @ 2026-06-30 12:10 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene, Wei-Lin Chang
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>
Factor out kvm_ptdump_guest_open() so that the shadow ptdump can reuse
kvm_ptdump_guest_open().
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/ptdump.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 0c9647666e65..40f93b7c7ad9 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -156,7 +156,7 @@ static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
return st;
}
-static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
+static int kvm_ptdump_guest_canonical_show(struct seq_file *m, void *unused)
{
struct kvm_ptdump_guest_state *st = m->private;
struct kvm *kvm = st->kvm;
@@ -181,7 +181,8 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
return 0;
}
-static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
+static int kvm_ptdump_guest_open(struct inode *m, struct file *file,
+ int (*show)(struct seq_file *, void *))
{
struct kvm *kvm = m->i_private;
struct kvm_ptdump_guest_state *st;
@@ -196,7 +197,7 @@ static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
goto err_with_kvm_ref;
}
- ret = single_open(file, kvm_ptdump_guest_show, st);
+ ret = single_open(file, show, st);
if (!ret)
return 0;
@@ -206,6 +207,11 @@ static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
return ret;
}
+static int kvm_ptdump_guest_canonical_open(struct inode *m, struct file *file)
+{
+ return kvm_ptdump_guest_open(m, file, kvm_ptdump_guest_canonical_show);
+}
+
static int kvm_ptdump_guest_close(struct inode *m, struct file *file)
{
struct kvm *kvm = m->i_private;
@@ -217,8 +223,8 @@ static int kvm_ptdump_guest_close(struct inode *m, struct file *file)
return single_release(m, file);
}
-static const struct file_operations kvm_ptdump_guest_fops = {
- .open = kvm_ptdump_guest_open,
+static const struct file_operations kvm_ptdump_guest_canonical_fops = {
+ .open = kvm_ptdump_guest_canonical_open,
.read = seq_read,
.llseek = seq_lseek,
.release = kvm_ptdump_guest_close,
@@ -296,7 +302,7 @@ static const struct file_operations kvm_pgtable_levels_fops = {
void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
{
debugfs_create_file("stage2_page_tables", 0400, kvm->debugfs_dentry,
- kvm, &kvm_ptdump_guest_fops);
+ kvm, &kvm_ptdump_guest_canonical_fops);
debugfs_create_file("ipa_range", 0400, kvm->debugfs_dentry,
kvm, &kvm_pgtable_range_fops);
debugfs_create_file("stage2_levels", 0400, kvm->debugfs_dentry,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 6/6] KVM: arm64: ptdump: Introduce the shadow ptdump file
From: Wei-Lin Chang @ 2026-06-30 12:10 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene, Wei-Lin Chang
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>
Create a ptdump file for all shadow page tables. It will dump out all
valid shadow page tables at the time of request, with the mmu's index,
guest VTCR_EL2, VTTBR_EL2, and whether the guest stage-2 is enabled or
not.
Also detach the nested mmu array under the mmu_lock in
kvm_arch_flush_shadow_all() so readers cannot race with the array being
removed, then free the old array after dropping the lock.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/nested.c | 12 ++++++--
arch/arm64/kvm/ptdump.c | 61 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 6435efd65cb5..17a180ddf6ca 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1283,6 +1283,7 @@ void kvm_nested_s2_flush(struct kvm *kvm)
void kvm_arch_flush_shadow_all(struct kvm *kvm)
{
+ struct kvm_s2_mmu *mmus;
int i;
for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
@@ -1291,9 +1292,14 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm)
if (!WARN_ON(atomic_read(&mmu->refcnt)))
kvm_free_stage2_pgd(mmu);
}
- kvfree(kvm->arch.nested_mmus);
- kvm->arch.nested_mmus = NULL;
- kvm->arch.nested_mmus_size = 0;
+
+ scoped_guard(write_lock, &kvm->mmu_lock) {
+ mmus = kvm->arch.nested_mmus;
+ kvm->arch.nested_mmus = NULL;
+ kvm->arch.nested_mmus_size = 0;
+ }
+
+ kvfree(mmus);
kvm_uninit_stage2_mmu(kvm);
}
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 40f93b7c7ad9..1649eaa75798 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -181,6 +181,50 @@ static int kvm_ptdump_guest_canonical_show(struct seq_file *m, void *unused)
return 0;
}
+static int kvm_ptdump_guest_nested_show(struct seq_file *m, void *unused)
+{
+ int ret = 0, i;
+ struct kvm_ptdump_guest_state *st = m->private;
+ struct kvm *kvm = st->kvm;
+ struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
+ .cb = kvm_ptdump_visitor,
+ .arg = &st->parser_state,
+ .flags = KVM_PGTABLE_WALK_LEAF,
+ };
+
+ guard(write_lock)(&kvm->mmu_lock);
+
+ if (!kvm->arch.nested_mmus)
+ return 0;
+
+ for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
+ struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+
+ if (!mmu->pgt)
+ continue;
+
+ if (kvm_s2_mmu_valid(mmu)) {
+ memset(st, 0, sizeof(*st));
+ ret = kvm_ptdump_parser_init(st, kvm, mmu->pgt);
+ if (ret)
+ return ret;
+ st->parser_state = (struct ptdump_pg_state) {
+ .marker = &st->ipa_marker[0],
+ .level = -1,
+ .pg_level = &st->level[0],
+ .seq = m,
+ };
+ seq_printf(m, "nested mmu %d VTCR: 0x%016llx VTTBR: 0x%016llx s2: %s\n",
+ i, mmu->tlb_vtcr, mmu->tlb_vttbr,
+ mmu->nested_stage2_enabled ? "enabled" : "disabled");
+ ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
+ if (ret)
+ return ret;
+ }
+ }
+ return ret;
+}
+
static int kvm_ptdump_guest_open(struct inode *m, struct file *file,
int (*show)(struct seq_file *, void *))
{
@@ -212,6 +256,11 @@ static int kvm_ptdump_guest_canonical_open(struct inode *m, struct file *file)
return kvm_ptdump_guest_open(m, file, kvm_ptdump_guest_canonical_show);
}
+static int kvm_ptdump_guest_nested_open(struct inode *m, struct file *file)
+{
+ return kvm_ptdump_guest_open(m, file, kvm_ptdump_guest_nested_show);
+}
+
static int kvm_ptdump_guest_close(struct inode *m, struct file *file)
{
struct kvm *kvm = m->i_private;
@@ -230,6 +279,13 @@ static const struct file_operations kvm_ptdump_guest_canonical_fops = {
.release = kvm_ptdump_guest_close,
};
+static const struct file_operations kvm_ptdump_guest_nested_fops = {
+ .open = kvm_ptdump_guest_nested_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = kvm_ptdump_guest_close,
+};
+
static int kvm_pgtable_range_show(struct seq_file *m, void *unused)
{
struct kvm *kvm = m->private;
@@ -307,6 +363,9 @@ void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
kvm, &kvm_pgtable_range_fops);
debugfs_create_file("stage2_levels", 0400, kvm->debugfs_dentry,
kvm, &kvm_pgtable_levels_fops);
- if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT))
+ if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT)) {
kvm->arch.debugfs_nv_dentry = debugfs_create_dir("nested", kvm->debugfs_dentry);
+ debugfs_create_file("shadow_page_tables", 0400, kvm->arch.debugfs_nv_dentry,
+ kvm, &kvm_ptdump_guest_nested_fops);
+ }
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/6] KVM: arm64: ptdump: Factor out initialization of kvm_ptdump_guest_state
From: Wei-Lin Chang @ 2026-06-30 12:10 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene, Wei-Lin Chang
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>
Extract the code for initializing kvm_ptdump_guest_state to allow
reusing the same instance for dumping multiple page tables.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/ptdump.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 752d8e0cd25c..0c9647666e65 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -112,6 +112,23 @@ static int kvm_ptdump_build_levels(struct ptdump_pg_level *level, u32 start_lvl)
return 0;
}
+static int kvm_ptdump_parser_init(struct kvm_ptdump_guest_state *st, struct kvm *kvm,
+ struct kvm_pgtable *pgt)
+{
+ int ret;
+
+ ret = kvm_ptdump_build_levels(&st->level[0], pgt->start_level);
+ if (ret)
+ return ret;
+
+ st->ipa_marker[0].name = "Guest IPA";
+ st->ipa_marker[1].start_address = BIT(pgt->ia_bits);
+
+ st->kvm = kvm;
+
+ return 0;
+}
+
static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
{
struct kvm_ptdump_guest_state *st;
@@ -129,17 +146,13 @@ static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
}
pgtable = kvm->arch.mmu.pgt;
+ ret = kvm_ptdump_parser_init(st, kvm, pgtable);
- ret = kvm_ptdump_build_levels(&st->level[0], pgtable->start_level);
if (ret) {
kfree(st);
return ERR_PTR(ret);
}
- st->ipa_marker[0].name = "Guest IPA";
- st->ipa_marker[1].start_address = BIT(pgtable->ia_bits);
-
- st->kvm = kvm;
return st;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 02/13] iio: adc: at91-sama5d2_adc: use cleanup.h for NVMEM buffer
From: Andy Shevchenko @ 2026-06-30 12:12 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
marcelo.schmitt, jorge.marques, mazziesaccount, Jonathan.Santos,
jishnu.prakash, antoniu.miclaus, duje, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630093603.38663-3-varshini.rajendran@microchip.com>
On Tue, Jun 30, 2026 at 03:05:52PM +0530, Varshini Rajendran wrote:
> Use __free(kfree) cleanup helper for the NVMEM data buffer in
> at91_adc_temp_sensor_init() to simplify error handling paths.
>
> Since __free(kfree) requires a valid kfree-able pointer (not an
> ERR_PTR), store nvmem_cell_read() result in a temporary void pointer
> first, check for errors, then assign to the managed buffer.
LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox