* Re: [PATCH v8 next 00/10] arm_mpam: Introduce Narrow-PARTID feature
From: Zeng Heng @ 2026-04-29 10:59 UTC (permalink / raw)
To: ben.horgan, Dave.Martin, james.morse, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang
In-Reply-To: <20260413085405.1166412-1-zengheng4@huawei.com>
On 2026/4/13 16:53, Zeng Heng wrote:
> Background
> ==========
>
> On x86, the resctrl allows creating up to num_rmids monitoring groups
> under parent control group. However, ARM64 MPAM is currently limited by
> the PMG (Performance Monitoring Group) count, which is typically much
> smaller than the theoretical RMID limit. This creates a significant
> scalability gap: users expecting fine-grained per-process or per-thread
> monitoring quickly exhaust the PMG space, even when plenty of reqPARTIDs
> remain available.
>
> The Narrow-PARTID feature, defined in the ARM MPAM architecture,
> addresses this by associating reqPARTIDs with intPARTIDs through a
> programmable many-to-one mapping. This allows the kernel to present more
> logical monitoring contexts.
>
> Design Overview
> ===============
>
> The implementation extends the RMID encoding to carry reqPARTID
> information:
>
> RMID = reqPARTID * NUM_PMG + PMG
>
> In this patchset, a monitoring group is uniquely identified by the
> combination of reqPARTID and PMG. The closid is represented by intPARTID,
> which is exactly the original PARTID.
>
> For systems with homogeneous MSCs (all supporting Narrow-PARTID), the
> driver exposes the full reqPARTID range directly. For heterogeneous
> systems where some MSCs lack Narrow-PARTID support, the driver utilizes
> PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring
> capability. The sole exception is when any type of MSCs lack Narrow-PARTID
> support, their percentage-based control mechanism prevents the use of
> PARTIDs as reqPARTIDs.
>
> Capability Improvements
> =======================
>
> --------------------------------------------------------------------------
> The maximum | Sub-monitoring groups | System-wide
> number of | under a control group | monitoring groups
> --------------------------------------------------------------------------
> Without reqPARTID | PMG | intPARTID * PMG
> --------------------------------------------------------------------------
> reqPARTID | |
> static allocation | (reqPARTID // intPARTID) * PMG | reqPARTID * PMG
> --------------------------------------------------------------------------
> reqPARTID | |
> dynamic allocation | (reqPARTID - intPARTID + 1) * PMG | reqPARTID * PMG
> --------------------------------------------------------------------------
>
> Note: The number of intPARTIDs can be capped via the boot parameter
> mpam.intpartid_max. Under MPAM, reqPARTID count is always greater than
> or equal to intPARTID count.
>
Thank you for your review. Please find the test report below for this
patch set.
Test Environment:
- Kernel: linux/master (commit: 6596a02b207886e9e00bb0161c7fd59fea53c081)
- Architecture: arm64
- Platform: Kunpeng 950
- MPAM Features: 256 reqPARTIDs, 32 intPARTIDs, 4 PMGs
Functional Test Example:
~~~
# dmesg | grep -i pmg
[ 11.528919] MPAM enabled with 256 reqPARTIDs, 16 intPARTIDs and 4 PMGs
# cat /proc/cmdline
<...> mpam.intpartid_max=15
# cat /sys/module/mpam/parameters/intpartid_max
15
# mount -t resctrl resctrl /sys/fs/resctrl/ -o debug
# cd /sys/fs/resctrl/
# mkdir p1
# cd p1/mon_groups/
# mkdir m{1..963}
# ls m963
cpus cpus_list mon_data mon_hw_id tasks
~~~
Able to create 964 resource groups ((256 - 15) * 4), which matches the
expected result.
MPAM KUnit Test Log:
~~~
[ 11.515338] KTAP version 1
[ 11.515340] 1..2
[ 11.515398] KTAP version 1
[ 11.515400] # Subtest: mpam_devices_test_suite
[ 11.515402] # module: mpam
[ 11.515405] 1..3
[ 11.515497] ok 1 test_mpam_reset_msc_bitmap
[ 11.515568] mpam:__props_mismatch: __props_mismatch took the min cmax_wd
[ 11.515579] mpam:__props_mismatch: cleared cpor_part
[ 11.515581] mpam:__props_mismatch: cleared mbw_part
[ 11.515592] mpam:__props_mismatch: took the min bwa_wd
[ 11.515594] mpam:__props_mismatch: __props_mismatch took the min cmax_wd
[ 11.515613] mpam:__props_mismatch: __props_mismatch took the min cmax_wd
[ 11.515658] ok 2 test_mpam_enable_merge_features
[ 11.515722] ok 3 test__props_mismatch
[ 11.515725] # mpam_devices_test_suite: pass:3 fail:0 skip:0 total:3
[ 11.515726] # Totals: pass:3 fail:0 skip:0 total:3
[ 11.515728] ok 1 mpam_devices_test_suite
[ 11.515730] KTAP version 1
[ 11.515732] # Subtest: mpam_resctrl_test_suite
[ 11.515734] # module: mpam
[ 11.515735] 1..6
[ 11.515792] ok 1 test_get_mba_granularity
[ 11.515795] KTAP version 1
[ 11.515797] # Subtest: test_mbw_max_to_percent
[ 11.515850] ok 1 pc=1, width=8, value=0x01
[ 11.515905] ok 2 pc=1, width=12, value=0x027
[ 11.515959] ok 3 pc=1, width=16, value=0x028e
[ 11.516011] ok 4 pc=25, width=8, value=0x3f
[ 11.516069] ok 5 pc=25, width=12, value=0x3ff
[ 11.516127] ok 6 pc=25, width=16, value=0x3fff
[ 11.516182] ok 7 pc=33, width=8, value=0x53
[ 11.516236] ok 8 pc=33, width=12, value=0x546
[ 11.516290] ok 9 pc=33, width=16, value=0x5479
[ 11.516345] ok 10 pc=35, width=8, value=0x58
[ 11.516401] ok 11 pc=35, width=12, value=0x598
[ 11.516456] ok 12 pc=35, width=16, value=0x5998
[ 11.516511] ok 13 pc=45, width=8, value=0x72
[ 11.516565] ok 14 pc=45, width=12, value=0x732
[ 11.516617] ok 15 pc=45, width=16, value=0x7332
[ 11.516673] ok 16 pc=50, width=8, value=0x7f
[ 11.516726] ok 17 pc=50, width=12, value=0x7ff
[ 11.516781] ok 18 pc=50, width=16, value=0x7fff
[ 11.516835] ok 19 pc=52, width=8, value=0x84
[ 11.516889] ok 20 pc=52, width=12, value=0x850
[ 11.516943] ok 21 pc=52, width=16, value=0x851d
[ 11.516997] ok 22 pc=55, width=8, value=0x8b
[ 11.517073] ok 23 pc=55, width=12, value=0x8cb
[ 11.517139] ok 24 pc=55, width=16, value=0x8ccb
[ 11.517196] ok 25 pc=58, width=8, value=0x93
[ 11.517254] ok 26 pc=58, width=12, value=0x946
[ 11.517309] ok 27 pc=58, width=16, value=0x9479
[ 11.517364] ok 28 pc=75, width=8, value=0xbf
[ 11.517418] ok 29 pc=75, width=12, value=0xbff
[ 11.517474] ok 30 pc=75, width=16, value=0xbfff
[ 11.517529] ok 31 pc=80, width=8, value=0xcb
[ 11.517583] ok 32 pc=80, width=12, value=0xccb
[ 11.517638] ok 33 pc=80, width=16, value=0xcccb
[ 11.517693] ok 34 pc=88, width=8, value=0xe0
[ 11.517750] ok 35 pc=88, width=12, value=0xe13
[ 11.517806] ok 36 pc=88, width=16, value=0xe146
[ 11.517861] ok 37 pc=95, width=8, value=0xf2
[ 11.517918] ok 38 pc=95, width=12, value=0xf32
[ 11.517972] ok 39 pc=95, width=16, value=0xf332
[ 11.518027] ok 40 pc=100, width=8, value=0xff
[ 11.518084] ok 41 pc=100, width=12, value=0xfff
[ 11.518141] ok 42 pc=100, width=16, value=0xffff
[ 11.518144] # test_mbw_max_to_percent: pass:42 fail:0 skip:0 total:42
[ 11.518146] ok 2 test_mbw_max_to_percent
[ 11.518149] KTAP version 1
[ 11.518151] # Subtest: test_percent_to_mbw_max
[ 11.518204] ok 1 pc=1, width=8, value=0x01
[ 11.518259] ok 2 pc=1, width=12, value=0x027
[ 11.518321] ok 3 pc=1, width=16, value=0x028e
[ 11.518380] ok 4 pc=25, width=8, value=0x3f
[ 11.518434] ok 5 pc=25, width=12, value=0x3ff
[ 11.518492] ok 6 pc=25, width=16, value=0x3fff
[ 11.518546] ok 7 pc=33, width=8, value=0x53
[ 11.518603] ok 8 pc=33, width=12, value=0x546
[ 11.518662] ok 9 pc=33, width=16, value=0x5479
[ 11.518718] ok 10 pc=35, width=8, value=0x58
[ 11.518776] ok 11 pc=35, width=12, value=0x598
[ 11.518832] ok 12 pc=35, width=16, value=0x5998
[ 11.518887] ok 13 pc=45, width=8, value=0x72
[ 11.518943] ok 14 pc=45, width=12, value=0x732
[ 11.519000] ok 15 pc=45, width=16, value=0x7332
[ 11.519055] ok 16 pc=50, width=8, value=0x7f
[ 11.519110] ok 17 pc=50, width=12, value=0x7ff
[ 11.519166] ok 18 pc=50, width=16, value=0x7fff
[ 11.519219] ok 19 pc=52, width=8, value=0x84
[ 11.519276] ok 20 pc=52, width=12, value=0x850
[ 11.519331] ok 21 pc=52, width=16, value=0x851d
[ 11.519387] ok 22 pc=55, width=8, value=0x8b
[ 11.519444] ok 23 pc=55, width=12, value=0x8cb
[ 11.519504] ok 24 pc=55, width=16, value=0x8ccb
[ 11.519561] ok 25 pc=58, width=8, value=0x93
[ 11.519616] ok 26 pc=58, width=12, value=0x946
[ 11.519676] ok 27 pc=58, width=16, value=0x9479
[ 11.519730] ok 28 pc=75, width=8, value=0xbf
[ 11.519785] ok 29 pc=75, width=12, value=0xbff
[ 11.519840] ok 30 pc=75, width=16, value=0xbfff
[ 11.519893] ok 31 pc=80, width=8, value=0xcb
[ 11.519946] ok 32 pc=80, width=12, value=0xccb
[ 11.519999] ok 33 pc=80, width=16, value=0xcccb
[ 11.520054] ok 34 pc=88, width=8, value=0xe0
[ 11.520106] ok 35 pc=88, width=12, value=0xe13
[ 11.520161] ok 36 pc=88, width=16, value=0xe146
[ 11.520217] ok 37 pc=95, width=8, value=0xf2
[ 11.520270] ok 38 pc=95, width=12, value=0xf32
[ 11.520323] ok 39 pc=95, width=16, value=0xf332
[ 11.520376] ok 40 pc=100, width=8, value=0xff
[ 11.520428] ok 41 pc=100, width=12, value=0xfff
[ 11.520481] ok 42 pc=100, width=16, value=0xffff
[ 11.520483] # test_percent_to_mbw_max: pass:42 fail:0 skip:0 total:42
[ 11.520485] ok 3 test_percent_to_mbw_max
[ 11.520487] KTAP version 1
[ 11.520488] # Subtest: test_mbw_max_to_percent_limits
[ 11.520540] ok 1 wd=1
[ 11.520594] ok 2 wd=2
[ 11.520647] ok 3 wd=3
[ 11.520700] ok 4 wd=4
[ 11.520752] ok 5 wd=5
[ 11.520807] ok 6 wd=6
[ 11.520858] ok 7 wd=7
[ 11.520909] ok 8 wd=8
[ 11.520962] ok 9 wd=9
[ 11.521017] ok 10 wd=10
[ 11.521078] ok 11 wd=11
[ 11.521138] ok 12 wd=12
[ 11.521193] ok 13 wd=13
[ 11.521245] ok 14 wd=14
[ 11.521296] ok 15 wd=15
[ 11.521346] ok 16 wd=16
[ 11.521348] # test_mbw_max_to_percent_limits: pass:16 fail:0
skip:0 total:16
[ 11.521350] ok 4 test_mbw_max_to_percent_limits
[ 11.521375] # test_percent_to_max_rounding: Round-up rate: 43%
(18/42)
[ 11.521409] ok 5 test_percent_to_max_rounding
[ 11.521411] KTAP version 1
[ 11.521413] # Subtest: test_percent_max_roundtrip_stability
[ 11.521465] ok 1 wd=1
[ 11.521515] ok 2 wd=2
[ 11.521565] ok 3 wd=3
[ 11.521614] ok 4 wd=4
[ 11.521667] ok 5 wd=5
[ 11.521719] ok 6 wd=6
[ 11.521770] ok 7 wd=7
[ 11.521820] ok 8 wd=8
[ 11.521871] ok 9 wd=9
[ 11.521922] ok 10 wd=10
[ 11.521973] ok 11 wd=11
[ 11.522022] ok 12 wd=12
[ 11.522075] ok 13 wd=13
[ 11.522126] ok 14 wd=14
[ 11.522178] ok 15 wd=15
[ 11.522231] ok 16 wd=16
[ 11.522233] # test_percent_max_roundtrip_stability: pass:16
fail:0 skip:0 total:16
[ 11.522235] ok 6 test_percent_max_roundtrip_stability
[ 11.522237] # mpam_resctrl_test_suite: pass:6 fail:0 skip:0 total:6
[ 11.522238] # Totals: pass:118 fail:0 skip:0 total:118
[ 11.522240] ok 2 mpam_resctrl_test_suite
~~~
All 118 MPAM KUnit tests passed.
Tested-by: Zeng Heng <zengheng4@huawei.com>
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH v2 4/6] firmware: samsung: acpm: Fix memory ordering race in RX path
From: Tudor Ambarus @ 2026-04-29 11:05 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, stable
In-Reply-To: <4421c95f-3ee7-40ac-b239-d877709b498a@linaro.org>
On 4/28/26 3:57 PM, Tudor Ambarus wrote:
> Another thing that I thought about was about the reordering of memset
> and set_bit in acpm_prepare_xfer(), but even there, the internal
> execution order doesn't matter. Both are guaranteed to be completed
> before writel (wmb).
I need to correct myself here. While the wmb() inside writel() does
prevent the hardware from seeing incomplete state, my previous
statement was slightly misleading regarding the local CPU pipeline.
The wmb() alone does not prevent the CPU from speculatively trying
to wipe the memory before it actually finds the first zero bit in
the bitmap.
What truly prevents speculative execution here is a strict
Address Dependency (implicit barrier). The CPU mathematically cannot
calculate the destination pointer for the memset() until the bit in
the bitmap is identified. I will add a comment in the code describing
this dependency.
In what concerns that set_bit() in acpm_prepare_xfer(), we only need
to ensure it is visible before the next TX thread tries to allocate
a sequence number. That is completely protected by the tx_lock
boundaries. The RX thread does not care about set_bit() at all — it
only blind-clears bits based on the rx_seqnum it gets back from the
firmware. I'll add a comment documenting the set_bit() safety as well.
Finally, regarding test_bit() and find_next_zero_bit() in
acpm_prepare_xfer(), they are functionally equivalent. Both are
relaxed, barrier-less reads. The non-atomic find_next_zero_bit()
introduces zero concurrency problems because this phase is strictly
a read-only search (if we read the bitmap just before the RX thread
frees a bit, we simply skip to the next available one).
I'll reorder the patches and put this one as last in the set, I want
to have the find_next_zero_bit() before it, to not touch the same
code twice.
Thanks,
ta
^ permalink raw reply
* Re: [DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte
From: Francesco Dolcini @ 2026-04-29 11:22 UTC (permalink / raw)
To: Karel Balej
Cc: Brian Norris, Francesco Dolcini, Johannes Berg, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Duje Mihanović,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Ulf Hansson,
Frank Li, linux-wireless, devicetree, linux-kernel,
linux-arm-kernel, linux-mmc, ~postmarketos/upstreaming,
phone-devel, Jeff Chen, Peng Fan, david
In-Reply-To: <DI5L100Q1RKO.1A68EJIPWYSRC@matfyz.cz>
Hello Karel,
On Wed, Apr 29, 2026 at 12:55:23PM +0200, Karel Balej wrote:
> without the firmware being in linux-firmware?
What's the license of this firmware? Am I wrong saying that if
the license allows it, you could just send a patch to have it integrated
to the linux-firmware repository? Is there any history or documentation
on the topic (please apologize if this is a well known topic, just
answer RTFM if this is the case).
I read a couple of days ago that for example the firmwares for the
various Apple arm64 laptop cannot be redistributed and every single
individual that wants to use those needs to extract those from their
system.
All of that seems just a legal matter, and IANAL ...
Francesco
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: clock: cs2000-cp: document CS2500
From: Geert Uytterhoeven @ 2026-04-29 11:32 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Kieran Bingham,
Krzysztof Kozlowski, Kuninori Morimoto, Laurent Pinchart,
Magnus Damm, Maxime Ripard, Michael Turquette, Rob Herring,
Simona Vetter, Stephen Boyd, Thomas Zimmermann, Tomi Valkeinen,
devicetree, dri-devel, linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260419193718.133174-4-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sun, 19 Apr 2026 at 21:37, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Document backward compatibility support for CS2500 chip, which
> is a drop-in replacement for CS2000 chip.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
> +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
> @@ -11,14 +11,18 @@ maintainers:
>
> description: |
> The CS2000-CP is an extremely versatile system clocking device that
> - utilizes a programmable phase lock loop.
> + utilizes a programmable phase lock loop. CP2500-CP is a compatible
> + drop-in replacement for CP2000-CP.
While CP2000 exists in two variants (-CP and -OTP, cfr. the link below),
there is just "CP2500"[2].
>
> Link: https://www.cirrus.com/products/cs2000/
>
> properties:
> compatible:
> - enum:
> - - cirrus,cs2000-cp
> + oneOf:
> + - items:
> + - const: cirrus,cs2500-cp
cirrus,cs2500
> + - const: cirrus,cs2000-cp
> + - const: cirrus,cs2000-cp
>
> clocks:
> description:
[1] ttps://www.cirrus.com/products/cs2500
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 2/3] drm/exynos: remove bridge when component_add fails
From: Luca Ceresoli @ 2026-04-29 11:43 UTC (permalink / raw)
To: Osama Abdelkader, Inki Dae, Seung-Woo Kim, Kyungmin Park,
David Airlie, Simona Vetter, Krzysztof Kozlowski, Alim Akhtar,
Andrzej Hajda, Hoegeun Kwon, dri-devel, linux-arm-kernel,
linux-samsung-soc, linux-kernel
Cc: stable
In-Reply-To: <20260423200622.325076-2-osama.abdelkader@gmail.com>
On Thu Apr 23, 2026 at 10:06 PM CEST, Osama Abdelkader wrote:
> Use devm_drm_bridge_add() so the bridge is released if probe fails after
> registration, and drop the manual drm_bridge_remove() in remove().
>
> Check the return value of devm_drm_bridge_add().
>
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> Fixes: 576d72fbfb45 ("drm/exynos: mic: add a bridge at probe")
> Cc: stable@vger.kernel.org
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
From: Geert Uytterhoeven @ 2026-04-29 11:44 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-5-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sun, 19 Apr 2026 at 21:38, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
> SoC and the Renesas Geist development board. The Renesas M3Le SoC is
> a register-compatible variant of the R8A77965 (M3-N) with reduced set
> of peripherals. The Geist board is derived from Renesas Salvator-X/XS
> boards, with adjustment for the R8A779MD SoC.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
> @@ -473,6 +473,12 @@ properties:
> - const: renesas,r8a779mb
> - const: renesas,r8a7795
>
> + - description: R-Car M3Le (R8A779MD)
> + items:
> + - const: renesas,geist # M3Le Geist
"Geist (RTP8A779MDASKB0F10S)"
> + - const: renesas,r8a779md
> + - const: renesas,r8a77965
> +
> - description: R-Car X5H (R8A78000)
> items:
> - enum:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/7] soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
From: Geert Uytterhoeven @ 2026-04-29 11:46 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Kieran Bingham,
Krzysztof Kozlowski, Kuninori Morimoto, Laurent Pinchart,
Magnus Damm, Maxime Ripard, Michael Turquette, Rob Herring,
Simona Vetter, Stephen Boyd, Thomas Zimmermann, Tomi Valkeinen,
devicetree, dri-devel, linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260419193718.133174-6-marek.vasut+renesas@mailbox.org>
On Sun, 19 Apr 2026 at 21:38, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add support for identifying the R-Car M3Le (R8A779MD) SoC.
>
> The Renesas R-Car R8A779MD M3Le SoC is a variant of the
> already supported R-Car M3-N SoC with reduced peripherals.
> Enable support for the M3Le SoC through already existing
> ARCH_R8A77965 configuration symbol. PRR reads 0x67c05501 .
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH net v2] net: airoha: Move entries to queue head in case of DMA mapping failure in airoha_dev_xmit()
From: Lorenzo Bianconi @ 2026-04-29 12:02 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jacob Keller, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In order to respect the original descriptor order and avoid any
potential IOMMU fault or memory corruption, move pending queue entries
to the head of hw queue tx_list if the DMA mapping of current inflight
packet fails in airoha_dev_xmit routine.
Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v2:
- Remove leftover airoha_queue_entry initialization inside the loop from
the previous version.
- Link to v1: https://lore.kernel.org/r/20260428-airoha-xmit-unmap-error-path-v1-1-aec44c6765c1@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5effb4a4ae84..fb4f51d67dd7 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2123,14 +2123,12 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
error_unmap:
- while (!list_empty(&tx_list)) {
- e = list_first_entry(&tx_list, struct airoha_queue_entry,
- list);
+ list_for_each_entry(e, &tx_list, list) {
dma_unmap_single(dev->dev.parent, e->dma_addr, e->dma_len,
DMA_TO_DEVICE);
e->dma_addr = 0;
- list_move_tail(&e->list, &q->tx_list);
}
+ list_splice(&tx_list, &q->tx_list);
spin_unlock_bh(&q->lock);
error:
---
base-commit: 0c7a5ba011d336df4fcd1f667fcc16ea5549be12
change-id: 20260428-airoha-xmit-unmap-error-path-8125594efb23
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH 6/7] arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
From: Geert Uytterhoeven @ 2026-04-29 12:16 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Nguyen Tran, Conor Dooley, David Airlie,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc, Wolfram Sang
In-Reply-To: <20260419193718.133174-7-marek.vasut+renesas@mailbox.org>
Hi Marek,
CC wsa
On Sun, 19 Apr 2026 at 21:38, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
>
> Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a variant of the
> R-Car M3-N (R8A77965) SoC. The Renesas M3Le SoC is a register-compatible
> variant of the R8A77965 (M3-N) with reduced set of peripherals.
>
> Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a779md.dtsi
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Device Tree Source for the R-Car M3Le (R8A779MD) SoC
> + *
> + * Copyright (C) 2025-2026 Renesas Electronics Corp.
> + */
> +
> +#include "r8a77965.dtsi"
> +
> +/ {
> + compatible = "renesas,r8a779md", "renesas,r8a77965";
> +};
> +
> +/delete-node/ &csi20;
> +/delete-node/ &drif00;
> +/delete-node/ &drif01;
> +/delete-node/ &drif10;
> +/delete-node/ &drif11;
> +/delete-node/ &drif20;
> +/delete-node/ &drif21;
> +/delete-node/ &drif30;
> +/delete-node/ &drif31;
> +/delete-node/ &hdmi0;
> +/delete-node/ &mlp;
> +/delete-node/ &pciec1;
> +/delete-node/ &sata;
> +/delete-node/ &sdhi3;
I am not sure disabling sdhi3 is correct.
The R-Car M3Le documentation says:
"M3Le does not support MMC1.
M3Le supports one MMC channel (MMC0) only.
SD3 is used only for SDHI and is not used for MMC.
M3Le does not support MMC HS400 class transfer rate."
The main R-Car Gen3 documentation says:
"This LSI has four SD card interfaces (SDHI0 to SDHI3), two of
which can also be used as MMC interfaces (SDHI2 and SDHI3)."
So while MMC1 is indeed sdhi3, sdhi3 can still be used in SD mode?
Do we need a new compatible value, as R-Car M3Le does not support HS400?
> +/delete-node/ &usb3_peri0;
> +/delete-node/ &usb3_phy0;
> +/delete-node/ &vin0csi20;
> +/delete-node/ &vin1csi20;
> +/delete-node/ &vin2csi20;
> +/delete-node/ &vin3csi20;
> +/delete-node/ &vin4csi20;
> +/delete-node/ &vin5csi20;
> +/delete-node/ &vin6csi20;
> +/delete-node/ &vin7csi20;
> +/delete-node/ &xhci0;
Shouldn't the following be disabled, too?
- ohci1, ehci1, and usb2_phy1,
- cmm1 and vspd1 (cfr. DU below).
> +
> +&du {
> + compatible = "renesas,du-r8a779md";
Assuming the DU needs a new compatible value...
> + renesas,cmms = <&cmm0>, <&cmm3>;
> + renesas,vsps = <&vspd0 0>, <&vspd1 0>;
Shouldn't this be
renesas,vsps = <&vspd0 0>, <&vspd0 1>;
? DU1 is unused, but DU3 is used.
> +
> + ports {
> + /delete-node/ port@1;
> + };
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2] arm64: dts: ti: k3-j721s2-som-p0: add bootph-pre-ram property to PMIC-B
From: Thomas Richard (TI) @ 2026-04-29 12:19 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Thomas Petazzoni, linux-arm-kernel, devicetree, linux-kernel,
gregory.clement, richard.genoud, u-kumar1, a-kumar2,
Thomas Richard (TI)
On j721s2, PMIC-B is needed to exit the DDR from retention after
suspend-to-ram. Add bootph-pre-ram property to make PMIC-B available to
the bootloader in the phase that sets up the DDR.
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
For the v2 I just updated the commit title and message to use PMIC-B
instead of pmic@4c.
---
Changes in v2:
- replace pmic@4c by PMIC-B in commit message.
- Link to v1: https://lore.kernel.org/r/20260428-k3-j721s2-som-bootph-pre-ram-pmic-4c-v1-1-e8202ce955a0@bootlin.com
---
arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
index 12a38dd1514b..a19e535f4946 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
@@ -250,6 +250,7 @@ buckb1: buck1 {
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-boot-on;
+ bootph-pre-ram;
};
buckb2: buck2 {
---
base-commit: 59b04cb2325c07ddc1cc7d984bd8c8f89f161746
change-id: 20260427-k3-j721s2-som-bootph-pre-ram-pmic-4c-744fb90b05a3
Best regards,
--
Thomas Richard (TI) <thomas.richard@bootlin.com>
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Francesco Dolcini @ 2026-04-29 12:46 UTC (permalink / raw)
To: Joseph Guo (OSS)
Cc: Daniel Baluta, Joseph Guo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel,
imx, linux-arm-kernel, xinyu.chen, justin.jiang
In-Reply-To: <bde82660-0550-4614-80a2-bf4f49b92063@oss.nxp.com>
On Wed, Apr 29, 2026 at 05:26:02PM +0800, Joseph Guo (OSS) wrote:
> On 4/29/2026 5:26 PM, Daniel Baluta wrote:
> >> +
> >> +&flexcan1 {
> >> + phys = <&flexcan1_phy>;
> >> + pinctrl-0 = <&pinctrl_flexcan1>;
> >> + pinctrl-names = "default";
> >> + status = "disabled";
> >> +};
> >
> > Why add this if it is disabled?
>
> The resource of flexcan1 in System Manager is assign to M7 by default.
I think the correct status in such a case is "reserved", am I wrong?
Francesco
^ permalink raw reply
* Re: [PATCH 09/43] KVM: arm64: gic-v5: Implement VMT/vIST IRS MMIO Ops
From: Joey Gouly @ 2026-04-29 12:50 UTC (permalink / raw)
To: Sascha Bischoff
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, nd, maz@kernel.org, oliver.upton@linux.dev,
Suzuki Poulose, yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260427160547.3129448-10-sascha.bischoff@arm.com>
On Mon, Apr 27, 2026 at 04:09:06PM +0000, Sascha Bischoff wrote:
> GICv5 has rules about which fields of a VMTE (or L1 VMT) may be
> directly written by the host once the table is valid. This ensures
> that no stale state is cached by the hardware, and provides a clear
> interface for making VMs, ISTs, etc, valid.
>
> The hypervisor is responsible for populating the VMTE for a
> VM. However, it is not permitted to write the Valid bit (as the VM
> table is already valid). Instead, the VM is made valid via an IRS MMIO
> Op. The same applies to the ISTs - they must be made valid via the
> host IRS.
>
> This commit adds support for:
>
> * Making level 2 VMTs valid (only), allowing for dynamic level 2 table
> allocation.
> * Making VMTEs (VMs) valid or invalid
> * Making SPI/LPI ISTs valid or invalid for a specific VM
>
> When (successfully) probing for a GICv5, the VMT is allocated, and is
> made valid via the IRS's MMIO interface.
>
> This commit also extends the doorbell domain to allow the doorbells
> themselves to act as a conduit for issuing commands - this is similar
> to what exists for GICv4 support. Effectively, irq_set_vcpu_affinity()
> becomes an ioctl-like interface for issuing commands specific to
> either a VM or the particular VPE that the doorbell belongs to. This
> change adds support for the following via the VPE doorbells:
>
> VMT_L2_MAP - Make a second level VM table valid
> VMTE_MAKE_VALID - Make a single VMTE (and hence VM) valid
> VMTE_MAKE_INVALID - Make a single VMTE (and hence VM) invalid
> SPI_VIST_MAKE_VALID - Make the SPI IST valid
> LPI_VIST_MAKE_VALID - Make the LPI IST valid
> LPI_VIST_MAKE_INVALID - Make the LPI IST invalid
>
> Note: It is intentional that there is no SPI_VIST_MAKE_INVALID - this
> cannot happen while the VM is live, and given that the SPI is
> allocated as part of VM creation, there is no need to make it invalid
> again until the VM is destroyed, at which point the VMTE is
> invalid. Therefore, there's no need to do this via the host's IRS MMIO
> interface, as it can be directly marked as invalid and freed. LPIs, on
> the other hand, are driven by the guest itself, and the guest is
> theoretically free to invalidate and free the LPI IST at any point.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-v5-tables.c | 25 +++
> arch/arm64/kvm/vgic/vgic-v5-tables.h | 2 +
> arch/arm64/kvm/vgic/vgic-v5.c | 236 ++++++++++++++++++++++++++-
> include/linux/irqchip/arm-gic-v5.h | 30 ++++
> 4 files changed, 290 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5-tables.c b/arch/arm64/kvm/vgic/vgic-v5-tables.c
> index de905f37b61a5..0120c3205dea6 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5-tables.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5-tables.c
> @@ -666,6 +666,26 @@ int vgic_v5_vmte_free_vpe(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +phys_addr_t vgic_v5_get_vmt_base(void)
> +{
> + phys_addr_t vmt_base;
> +
> + if (!vgic_v5_vmt_allocated())
> + return -ENXIO;
> +
> + if (!vmt_info->two_level)
> + vmt_base = virt_to_phys(vmt_info->linear.vmt_base);
> + else
> + vmt_base = virt_to_phys(vmt_info->l2.vmt_base);
> +
> + return vmt_base;
> +}
> +
> +u8 vgic_v5_vmt_vpe_id_bits(void)
> +{
> + return fls(vmt_info->max_vpes) - 1;
> +}
> +
> /*
> * Assign an already allocated IST to the VM by populating the fields in the
> * corresponding VMTE. We re-use this code for both an SPI IST and LPI IST, even
> @@ -715,6 +735,11 @@ int vgic_v5_vmte_assign_ist(struct kvm *kvm, phys_addr_t ist_base,
> /* Finally, mark the entry as valid */
> cmd_info.cmd_type = spi_ist ? SPI_VIST_MAKE_VALID : LPI_VIST_MAKE_VALID;
> ret = irq_set_vcpu_affinity(vgic_v5_vpe_db(vcpu0), &cmd_info);
> + if (ret) {
> + WRITE_ONCE(vmte->val[section], 0ULL);
> + vgic_v5_clean_inval(vmte, sizeof(*vmte), true, false);
> + return ret;
> + }
>
> /* Any cached entries we now have are stale! */
> vgic_v5_clean_inval(vmte, sizeof(*vmte), false, true);
> diff --git a/arch/arm64/kvm/vgic/vgic-v5-tables.h b/arch/arm64/kvm/vgic/vgic-v5-tables.h
> index 37e220cda1987..6a024337eba79 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5-tables.h
> +++ b/arch/arm64/kvm/vgic/vgic-v5-tables.h
> @@ -150,6 +150,8 @@ int vgic_v5_vmt_allocate(bool two_level, unsigned int num_entries,
> size_t vmd_size, size_t vped_size,
> unsigned int vpe_id_bits);
> int vgic_v5_vmt_free(void);
> +phys_addr_t vgic_v5_get_vmt_base(void);
> +u8 vgic_v5_vmt_vpe_id_bits(void);
>
> int vgic_v5_allocate_vm_id(struct kvm *kvm);
> void vgic_v5_release_vm_id(struct kvm *kvm);
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 4e0d52b309628..49eb01ca07961 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -36,6 +36,12 @@ static void vgic_v5_get_implemented_ppis(void)
> __assign_bit(GICV5_ARCH_PPI_PMUIRQ, ppi_caps.impl_ppi_mask, system_supports_pmuv3());
> }
>
> +/*
> + * The IRS MMIO interface is shared between all VMs, so make sure we don't do
> + * anything stupid!
> + */
> +static DEFINE_RAW_SPINLOCK(vm_config_lock);
> +
> static void __iomem *irs_base;
>
> static u32 irs_readl_relaxed(const u32 reg_offset)
> @@ -43,6 +49,21 @@ static u32 irs_readl_relaxed(const u32 reg_offset)
> return readl_relaxed(irs_base + reg_offset);
> }
>
> +static void irs_writel_relaxed(const u32 val, const u32 reg_offset)
> +{
> + writel_relaxed(val, irs_base + reg_offset);
> +}
> +
> +static u64 irs_readq_relaxed(const u32 reg_offset)
> +{
> + return readq_relaxed(irs_base + reg_offset);
> +}
> +
> +static void irs_writeq_relaxed(const u64 val, const u32 reg_offset)
> +{
> + writeq_relaxed(val, irs_base + reg_offset);
> +}
> +
> static int gicv5_irs_extract_vm_caps(const struct gic_kvm_info *info)
> {
> u64 idr;
> @@ -84,16 +105,22 @@ static int gicv5_irs_extract_vm_caps(const struct gic_kvm_info *info)
> return 0;
> }
>
> +/* Forward decl for cleaner code layout */
> +static int vgic_v5_irs_assign_vmt(bool two_level, u8 vm_id_bits, phys_addr_t vmt_base);
> +static int vgic_v5_irs_clear_vmt(void);
> +
> /*
> * Probe for a vGICv5 compatible interrupt controller, returning 0 on success.
> */
> int vgic_v5_probe(const struct gic_kvm_info *info)
> {
> + struct vgic_v5_host_ist_caps *ist_caps;
> bool v5_registered = false;
> u64 ich_vtr_el2;
> int ret;
>
> kvm_vgic_global_state.type = VGIC_V5;
> + kvm_vgic_global_state.max_gic_vcpus = VGIC_V5_MAX_CPUS;
>
> kvm_vgic_global_state.vcpu_base = 0;
> kvm_vgic_global_state.vctrl_base = NULL;
> @@ -114,13 +141,53 @@ int vgic_v5_probe(const struct gic_kvm_info *info)
> if (gicv5_irs_extract_vm_caps(info))
> goto skip_v5;
>
> - kvm_vgic_global_state.max_gic_vcpus = VGIC_V5_MAX_CPUS;
> + ist_caps = vgic_v5_host_caps();
> +
> + /*
> + * Even if the HW supports more per-VM vCPUs, artifically cap as we
> + * can't use them all.
> + */
> + kvm_vgic_global_state.max_gic_vcpus = min(ist_caps->max_vpes,
> + VGIC_V5_MAX_CPUS);
> +
> + /*
> + * GICv5 requires a set of tables to be allocated in order to manage
> + * VMs. We allocate them in advance here, which alas means that we
> + * already have to make a decisions regarding the maximum number of VMs
> + * we want to run. For now, we match the maximum number offered by the
> + * hardware, but this might not be a wise choice in the long term.
> + */
> + ret = vgic_v5_vmt_allocate(ist_caps->two_level_vmt_support,
> + ist_caps->max_vms, ist_caps->vmd_size,
> + ist_caps->vped_size,
> + kvm_vgic_global_state.max_gic_vcpus);
> + if (ret) {
> + kvm_err("Failed to allocate the GICv5 VM tables; no GICv5 support\n");
> + goto skip_v5;
> + }
> +
> + /*
> + * We've now allocated the VM table, but the host's IRS doesn't know
> + * about it yet. Provide the base address of the VMT to the IRS, as well
> + * as the number of ID bits that it covers and the structure used
> + * (linear/two-level).
> + */
> + ret = vgic_v5_irs_assign_vmt(ist_caps->two_level_vmt_support,
> + vgic_v5_vmt_vpe_id_bits(),
You're passing vpe_id_bits to vm_id_bits. Should this be vgic_v5_host_caps()->max_vms?
> + vgic_v5_get_vmt_base());
> + if (ret) {
> + kvm_err("Failed to assign the GICv5 VM tables to the IRS; no GICv5 support\n");
> + vgic_v5_vmt_free();
> + goto skip_v5;
> + }
>
> vgic_v5_get_implemented_ppis();
>
> ret = kvm_register_vgic_device(KVM_DEV_TYPE_ARM_VGIC_V5);
> if (ret) {
> kvm_err("Cannot register GICv5 KVM device.\n");
> + vgic_v5_irs_clear_vmt();
> + vgic_v5_vmt_free();
> goto skip_v5;
> }
>
> @@ -148,12 +215,13 @@ int vgic_v5_probe(const struct gic_kvm_info *info)
> ret = kvm_register_vgic_device(KVM_DEV_TYPE_ARM_VGIC_V3);
> if (ret) {
> kvm_err("Cannot register GICv3-legacy KVM device.\n");
> - return ret;
> + /* vGICv5 should still work */
> + return v5_registered ? 0 : ret;
> }
>
> /* We potentially limit the max VCPUs further than we need to here */
> kvm_vgic_global_state.max_gic_vcpus = min(VGIC_V3_MAX_CPUS,
> - VGIC_V5_MAX_CPUS);
> + kvm_vgic_global_state.max_gic_vcpus);
>
> static_branch_enable(&kvm_vgic_global_state.gicv3_cpuif);
> kvm_info("GCIE legacy system register CPU interface\n");
[...]
Thanks,
Joey
^ permalink raw reply
* [PATCH] memory: atmel-ebi: Allow deferred probing
From: Alexander Dahl @ 2026-04-29 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Miquel Raynal, linux-mtd, stable, Krzysztof Kozlowski,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Rob Herring (Arm),
moderated list:ARM/Microchip (AT91) SoC support
After removing of_platform_default_populate() calls the atmel-ebi driver
was affected by deferred probing. platform_driver_probe() is
incompatible with deferred probing. This led to atmel-ebi driver
eventually not being probed on at91 sam9x60-curiosity and other sam9x60
based boards. Subsequently the nand-controller driver (nand-controller
being a child node of ebi) on that platform was not probed and thus raw
NAND flash was inaccessible, preventing devices to boot with rootfs on
raw NAND flash (e.g. with UBI/UBIFS).
Fixes: 0b0f7e6539a7 ("ARM: at91: remove unnecessary of_platform_default_populate calls")
Cc: stable@vger.kernel.org
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Alexander Dahl <ada@thorsis.com>
---
Notes:
Successfully tested on sam9x60-curiosity board,
and on two custom boards based on sam9x60 and sama5d2.
drivers/memory/atmel-ebi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/memory/atmel-ebi.c b/drivers/memory/atmel-ebi.c
index 8db970da9af96..1e8e8aba2542d 100644
--- a/drivers/memory/atmel-ebi.c
+++ b/drivers/memory/atmel-ebi.c
@@ -628,10 +628,11 @@ static __maybe_unused int atmel_ebi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(atmel_ebi_pm_ops, NULL, atmel_ebi_resume);
static struct platform_driver atmel_ebi_driver = {
+ .probe = atmel_ebi_probe,
.driver = {
.name = "atmel-ebi",
.of_match_table = atmel_ebi_id_table,
.pm = &atmel_ebi_pm_ops,
},
};
-builtin_platform_driver_probe(atmel_ebi_driver, atmel_ebi_probe);
+builtin_platform_driver(atmel_ebi_driver);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 3/3] ARM: at91: remove unnecessary of_platform_default_populate calls
From: Alexander Dahl @ 2026-04-29 13:02 UTC (permalink / raw)
To: Miquel Raynal
Cc: Rob Herring (Arm), Richard Weinberger, Vignesh Raghavendra,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Russell King,
linux-mtd, linux-arm-kernel, linux-kernel
In-Reply-To: <87lde6cdc4.fsf@bootlin.com>
Hello Miquel,
Am Wed, Apr 29, 2026 at 11:42:19AM +0200 schrieb Miquel Raynal:
> Hi Alexander,
>
> > [ 0.958298] bus: 'platform': add driver atmel-ebi
> > [ 0.958451] platform 10000000.ebi: bus: 'platform': __driver_probe_device: matched device with driver atmel-ebi
> > [ 0.958566] platform 10000000.ebi: error -EPROBE_DEFER: wait for supplier /ahb/apb/pinctrl@fffff400/ebi/ebi-data-lsb
> > [ 0.958649] platform 10000000.ebi: Added to deferred list
> > [ 0.959429] bus: 'platform': remove driver atmel-ebi
> > [ 0.959540] driver: 'atmel-ebi': driver_release
>
> Interesting.
>
> If you look at the very last line of the driver, the EBI driver does not
> use a standard "module_platform_driver" macro, it uses some kind of
> run-once probe that is kept in an __init section:
> https://elixir.bootlin.com/linux/v7.0.1/source/drivers/memory/atmel-ebi.c#L637
>
> And this seems to be incompatible with probe deferrals:
> https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/platform.c#L948
Indeed. o.O
> I would suggest trying something alone these lines:
>
> --- a/drivers/memory/atmel-ebi.c
> +++ b/drivers/memory/atmel-ebi.c
> @@ -633,5 +633,6 @@ static struct platform_driver atmel_ebi_driver = {
> .of_match_table = atmel_ebi_id_table,
> .pm = &atmel_ebi_pm_ops,
> },
> + .probe = atmel_ebi_probe,
> };
> -builtin_platform_driver_probe(atmel_ebi_driver, atmel_ebi_probe);
> +builtin_platform_driver(atmel_ebi_driver);
>
> Memory taken by the probe function will remain mapped. That seems to be
> the drawback.
This works. Sent a patch, see:
https://lore.kernel.org/all/20260429125930.844790-1-ada@thorsis.com/
Regarding the drawback: This can't be much memory, can it?
Greets
Alex
^ permalink raw reply
* [PATCH v3 0/6] firmware: samsung: acpm: Various fixes for sashiko bug reports
From: Tudor Ambarus @ 2026-04-29 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
Fixes for bugs that were identified by sashiko when proposing the
GS101 ACPM TMU addition.
While the bugs are sane, we haven't hit them yet, maybe because we
don't have enough ACPM clients upstreamed. The fixes can go either
as fixes at -rc phase, or as regular patches for the next merge window.
If the later, we'll need a dedicated branch, as these patches toghether
with the other ACPM thermal preparatory patches will be needed by the
GS101 ACPM thermal driver. I'm thinking a dedicated branch and a tag
will do. I will respin the GS101 ACPM thermal driver series once this
fixes set gets in.
Thanks,
ta
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Changes in v3:
- validate more SRAM parameters and queue pointers (sashiko)
- consider/fix the acquire path (Krzysztof) - patch was moved
last in the series to avoid touching the same code twice.
- Link to v2: https://lore.kernel.org/r/20260427-acpm-fixes-sashiko-reports-v2-0-1ff8de94a997@linaro.org
Changes in v2:
- drop patch "firmware: samsung: acpm: Fix sequence number leak and infinite loop"
The patch freed sequence numbers on mailbox failures or timeouts. Because
the message is already in SRAM and tx.front was advanced, a delayed
firmware wake-up will process that abandoned message, stealing the
sequence number from a new thread and causing silent data corruption.
- fix mailbox channel leak when `acpm_achan_alloc_cmds()` failed. Did it
by moving the `devm_add_action_or_reset()` call.
- new patches, last 3 in the set, they fix some more sashiko reports.
- Link to v1: https://lore.kernel.org/r/20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e@linaro.org
---
Tudor Ambarus (6):
firmware: samsung: acpm: Fix cross-thread RX length corruption
firmware: samsung: acpm: Fix mailbox channel leak on probe error
firmware: samsung: acpm: Fix dummy stubs to return ERR_PTR
firmware: samsung: acpm: Validate SRAM shared memory and queue pointers
firmware: samsung: acpm: Fix infinite loop on sequence number exhaustion
firmware: samsung: acpm: Fix memory ordering races in RX and polling paths
drivers/firmware/samsung/exynos-acpm-dvfs.c | 3 +
drivers/firmware/samsung/exynos-acpm.c | 113 ++++++++++++++++-----
.../linux/firmware/samsung/exynos-acpm-protocol.h | 3 +-
3 files changed, 90 insertions(+), 29 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260423-acpm-fixes-sashiko-reports-ae28b6ed5581
Best regards,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
^ permalink raw reply
* [PATCH v3 2/6] firmware: samsung: acpm: Fix mailbox channel leak on probe error
From: Tudor Ambarus @ 2026-04-29 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad@linaro.org>
Sashiko identified the leak at [1].
The ACPM driver allocates hardware mailbox channels using
`mbox_request_channel()` during `acpm_channels_init()`. However, the
driver lacked a `.remove` callback and did not free these channels on
subsequent error paths inside `acpm_probe()`.
Additionally, if `acpm_achan_alloc_cmds()` failed during the channel
initialization loop, the function returned immediately, bypassing the
manual cleanup and permanently leaking any channels successfully
requested in previous loop iterations.
Fix this by modifying `acpm_free_mbox_chans()` to match the `devres`
action signature and registering it via `devm_add_action_or_reset()`.
Cc: stable@vger.kernel.org
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index e95edc350efa..bd0d48e9d157 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -529,8 +529,9 @@ static int acpm_achan_alloc_cmds(struct acpm_chan *achan)
* acpm_free_mbox_chans() - free mailbox channels.
* @acpm: pointer to driver data.
*/
-static void acpm_free_mbox_chans(struct acpm_info *acpm)
+static void acpm_free_mbox_chans(void *data)
{
+ struct acpm_info *acpm = data;
int i;
for (i = 0; i < acpm->num_chans; i++)
@@ -558,6 +559,10 @@ static int acpm_channels_init(struct acpm_info *acpm)
if (!acpm->chans)
return -ENOMEM;
+ ret = devm_add_action_or_reset(dev, acpm_free_mbox_chans, acpm);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add mbox free action.\n");
+
chans_shmem = acpm->sram_base + readl(&shmem->chans);
for (i = 0; i < acpm->num_chans; i++) {
@@ -579,10 +584,8 @@ static int acpm_channels_init(struct acpm_info *acpm)
cl->dev = dev;
achan->chan = mbox_request_channel(cl, 0);
- if (IS_ERR(achan->chan)) {
- acpm_free_mbox_chans(acpm);
+ if (IS_ERR(achan->chan))
return PTR_ERR(achan->chan);
- }
}
return 0;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v3 4/6] firmware: samsung: acpm: Validate SRAM shared memory and queue pointers
From: Tudor Ambarus @ 2026-04-29 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad@linaro.org>
Sashiko identified multiple missing validation checks [1].
The ACPM driver reads queue pointers (rx_front, rx_rear, tx_front) and
configuration parameters (qlen) directly from shared SRAM without
verifying their validity. Relying blindly on firmware-provided values
leaves the kernel vulnerable to crashes or infinite loops if the
firmware misbehaves.
This patch fixes three specific vulnerabilities:
1. RX path infinite loop and OOB read: The rear pointer ('i') is used
to calculate the MMIO address before the modulo operation is applied.
If 'rx_front' or 'i' are >= achan->qlen, the driver performs an
out-of-bounds read. Furthermore, because 'i' is mathematically capped
by the modulo operator, if 'rx_front' is >= qlen, 'i' will never
equal 'rx_front', causing the CPU to spin forever and deadlock the
polling thread.
2. TX path out-of-bounds: 'tx_front' is used to calculate queue indices.
If it exceeds the queue length, it causes invalid state tracking and
out-of-bounds memory accesses during __iowrite32_copy().
3. Divide-by-zero panics: 'qlen' is read from SRAM during channel
initialization. If 'qlen' is 0, any subsequent modulo operations
(% achan->qlen) will trigger a divide-by-zero kernel panic.
Protect the kernel by strictly validating the initialization parameters
and MMIO queue offsets immediately after reading them.
Cc: stable@vger.kernel.org
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index bd0d48e9d157..e4d8d1120192 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -230,6 +230,13 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer)
rx_front = readl(achan->rx.front);
i = readl(achan->rx.rear);
+ if (rx_front >= achan->qlen || i >= achan->qlen) {
+ dev_err(achan->acpm->dev,
+ "Invalid RX queue pointers from firmware: front=%u rear=%u qlen=%u\n",
+ rx_front, i, achan->qlen);
+ return -EIO;
+ }
+
tx_seqnum = FIELD_GET(ACPM_PROTOCOL_SEQNUM, xfer->txd[0]);
if (i == rx_front) {
@@ -439,6 +446,14 @@ int acpm_do_xfer(struct acpm_handle *handle, const struct acpm_xfer *xfer)
scoped_guard(mutex, &achan->tx_lock) {
tx_front = readl(achan->tx.front);
+
+ if (tx_front >= achan->qlen) {
+ dev_err(achan->acpm->dev,
+ "Invalid TX front pointer from firmware: %u (qlen: %u)\n",
+ tx_front, achan->qlen);
+ return -EIO;
+ }
+
idx = (tx_front + 1) % achan->qlen;
ret = acpm_wait_for_queue_slots(achan, idx);
@@ -574,6 +589,12 @@ static int acpm_channels_init(struct acpm_info *acpm)
acpm_chan_shmem_get_params(achan, chan_shmem);
+ if (!achan->qlen) {
+ dev_err(dev, "Invalid shared memory parameters for channel %d: qlen=%u\n",
+ i, achan->qlen);
+ return -EIO;
+ }
+
ret = acpm_achan_alloc_cmds(achan);
if (ret)
return ret;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v3 3/6] firmware: samsung: acpm: Fix dummy stubs to return ERR_PTR
From: Tudor Ambarus @ 2026-04-29 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad@linaro.org>
Sashiko identified a potential NULL pointer dereference [1].
The dummy stub implementation for devm_acpm_get_by_node() returns NULL
when CONFIG_EXYNOS_ACPM_PROTOCOL is disabled.
However, the active implementation of this function returns an ERR_PTR
on failure, and the consumer driver checks the return value using
IS_ERR(). Because IS_ERR(NULL) evaluates to false, returning NULL from
the stub tricks consumer drivers into treating the NULL return as a
valid handle. Subsequent attempts to access handle->ops result in a
fatal NULL pointer dereference.
Fix this by returning ERR_PTR(-ENODEV) in the disabled configuration
to correctly propagate the disabled state and match the API contract.
Cc: stable@vger.kernel.org
Fixes: 6837c006d4e7 ("firmware: exynos-acpm: add empty method to allow compile test")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
include/linux/firmware/samsung/exynos-acpm-protocol.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index 13f17dc4443b..d4db2796a6fb 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -8,6 +8,7 @@
#ifndef __EXYNOS_ACPM_PROTOCOL_H
#define __EXYNOS_ACPM_PROTOCOL_H
+#include <linux/err.h>
#include <linux/types.h>
struct acpm_handle;
@@ -57,7 +58,7 @@ struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
static inline struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
struct device_node *np)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
#endif
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v3 5/6] firmware: samsung: acpm: Fix infinite loop on sequence number exhaustion
From: Tudor Ambarus @ 2026-04-29 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad@linaro.org>
Sashiko identified a possible infinite loop [1].
ACPM IPC sequence numbers are tracked via a 64-bit bitmap. Previously,
acpm_prepare_xfer() used a do...while loop to search for a free
sequence number.
If all 63 available sequence numbers are leaked due to transient
hardware timeouts or mailbox failures, the bitmap becomes full.
The next call to acpm_prepare_xfer() would enter an infinite loop.
Fix this by utilizing the kernel's optimized bitmap search functions
(find_next_zero_bit / find_first_zero_bit). If the pool is completely
exhausted, log the failure and return -EBUSY to allow the kernel to
fail gracefully instead of hanging.
Cc: stable@vger.kernel.org
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 36 +++++++++++++++++++++++-----------
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index e4d8d1120192..b8a4978b091b 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -12,6 +12,7 @@
#include <linux/container_of.h>
#include <linux/delay.h>
#include <linux/device.h>
+#include <linux/find.h>
#include <linux/firmware/samsung/exynos-acpm-protocol.h>
#include <linux/io.h>
#include <linux/iopoll.h>
@@ -370,29 +371,40 @@ static int acpm_wait_for_queue_slots(struct acpm_chan *achan, u32 next_tx_front)
* TX queue.
* @achan: ACPM channel info.
* @xfer: reference to the transfer being prepared.
+ *
+ * Return: 0 on success, -EBUSY if the sequence number pool is exhausted.
*/
-static void acpm_prepare_xfer(struct acpm_chan *achan,
- const struct acpm_xfer *xfer)
+static int acpm_prepare_xfer(struct acpm_chan *achan,
+ const struct acpm_xfer *xfer)
{
struct acpm_rx_data *rx_data;
u32 *txd = (u32 *)xfer->txd;
+ unsigned long size = ACPM_SEQNUM_MAX - 1;
+ unsigned long bit;
+
+ bit = find_next_zero_bit(achan->bitmap_seqnum, size, achan->seqnum);
+ if (bit >= size) {
+ bit = find_first_zero_bit(achan->bitmap_seqnum, size);
+ if (bit >= size) {
+ dev_err_ratelimited(achan->acpm->dev,
+ "ACPM sequence number pool exhausted\n");
+ return -EBUSY;
+ }
+ }
- /* Prevent chan->seqnum from being re-used */
- do {
- if (++achan->seqnum == ACPM_SEQNUM_MAX)
- achan->seqnum = 1;
- } while (test_bit(achan->seqnum - 1, achan->bitmap_seqnum));
+ /* Flag the index based on seqnum. (seqnum: 1~63, bitmap: 0~62) */
+ achan->seqnum = bit + 1;
+ set_bit(bit, achan->bitmap_seqnum);
txd[0] |= FIELD_PREP(ACPM_PROTOCOL_SEQNUM, achan->seqnum);
/* Clear data for upcoming responses */
- rx_data = &achan->rx_data[achan->seqnum - 1];
+ rx_data = &achan->rx_data[bit];
memset(rx_data->cmd, 0, sizeof(*rx_data->cmd) * rx_data->n_cmd);
/* zero means no response expected */
rx_data->rxcnt = xfer->rxcnt;
- /* Flag the index based on seqnum. (seqnum: 1~63, bitmap: 0~62) */
- set_bit(achan->seqnum - 1, achan->bitmap_seqnum);
+ return 0;
}
/**
@@ -460,7 +472,9 @@ int acpm_do_xfer(struct acpm_handle *handle, const struct acpm_xfer *xfer)
if (ret)
return ret;
- acpm_prepare_xfer(achan, xfer);
+ ret = acpm_prepare_xfer(achan, xfer);
+ if (ret)
+ return ret;
/* Write TX command. */
__iowrite32_copy(achan->tx.base + achan->mlen * tx_front,
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v3 6/6] firmware: samsung: acpm: Fix memory ordering races in RX and polling paths
From: Tudor Ambarus @ 2026-04-29 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad@linaro.org>
Sashiko identified a memory ordering race in the RX path [1].
Sequence numbers are allocated by the TX thread and freed by the RX
thread. Because the TX path is protected by 'tx_lock' and the RX path
is protected by 'rx_lock', the shared 'bitmap_seqnum' is modified
across two separate lock domains. Thus, the operations acting on the
bitmap are effectively lockless and require explicit memory barriers.
This patch addresses missing barriers in two paths:
1. The Release Path (RX thread):
When draining the RX queue, the driver reads the payload and uses a
relaxed clear_bit() to free the sequence number. On weakly ordered
architectures like ARM64, this allows the CPU to make the cleared bit
globally visible before the preceding memory reads (memcpy or
__ioread32_copy) have completed. If a concurrent TX thread allocates
the newly freed sequence number, it can execute memset() and corrupt
the buffer while the RX thread is still actively reading from it.
Fix this by replacing clear_bit() with clear_bit_unlock() to enforce
Release semantics.
2. The Acquire Path (Polling thread):
In polling mode, zero-length messages (rxcnt == 0) can have their bits
cleared by a concurrent thread that happens to be draining the queue.
The polling thread waits on test_bit(). Because test_bit() lacks an
acquire barrier, the CPU can speculatively execute the client driver's
subsequent instructions before the RX thread's memory updates are
globally visible. Fix this by pairing the release with
test_bit_acquire().
Note that the TX allocation path (acpm_prepare_xfer) is safe as-is
and does not require an explicit acquire barrier (like
test_and_set_bit_lock) for two reasons:
* Address Dependency: The CPU mathematically cannot calculate the
destination pointer for the memset() until the non-atomic
find_next_zero_bit() returns the index, naturally preventing
speculative execution of the buffer wipe.
* Lock Boundaries: The visibility of the atomic set_bit() to the next
TX thread is safely protected by the 'tx_lock' boundaries
(specifically the Release semantics of mutex_unlock).
Cc: stable@vger.kernel.org
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Closes: https://sashiko.dev/#/patchset/20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index b8a4978b091b..15627b439838 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -7,7 +7,7 @@
#include <linux/bitfield.h>
#include <linux/bitmap.h>
-#include <linux/bits.h>
+#include <linux/bitops.h>
#include <linux/cleanup.h>
#include <linux/container_of.h>
#include <linux/delay.h>
@@ -207,7 +207,7 @@ static void acpm_get_saved_rx(struct acpm_chan *achan,
if (rx_seqnum == tx_seqnum) {
memcpy(xfer->rxd, rx_data->cmd, xfer->rxcnt * sizeof(*xfer->rxd));
- clear_bit(rx_seqnum - 1, achan->bitmap_seqnum);
+ clear_bit_unlock(rx_seqnum - 1, achan->bitmap_seqnum);
}
}
@@ -268,7 +268,7 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer)
if (rx_seqnum == tx_seqnum) {
__ioread32_copy(xfer->rxd, addr, xfer->rxcnt);
rx_set = true;
- clear_bit(seqnum, achan->bitmap_seqnum);
+ clear_bit_unlock(seqnum, achan->bitmap_seqnum);
} else {
/*
* The RX data corresponds to another request.
@@ -280,7 +280,7 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer)
rx_data->rxcnt);
}
} else {
- clear_bit(seqnum, achan->bitmap_seqnum);
+ clear_bit_unlock(seqnum, achan->bitmap_seqnum);
}
i = (i + 1) % achan->qlen;
@@ -322,7 +322,14 @@ static int acpm_dequeue_by_polling(struct acpm_chan *achan,
if (ret)
return ret;
- if (!test_bit(seqnum - 1, achan->bitmap_seqnum))
+ /*
+ * For zero-length messages (rxcnt == 0), the bit can be
+ * cleared by a concurrent thread draining the queue. Use
+ * test_bit_acquire() to prevent the CPU from speculatively
+ * executing the caller's subsequent instructions before the
+ * hardware transaction is fully synchronized.
+ */
+ if (!test_bit_acquire(seqnum - 1, achan->bitmap_seqnum))
return 0;
/* Determined experimentally. */
@@ -392,13 +399,24 @@ static int acpm_prepare_xfer(struct acpm_chan *achan,
}
}
- /* Flag the index based on seqnum. (seqnum: 1~63, bitmap: 0~62) */
+ /*
+ * Flag the index based on seqnum. (seqnum: 1~63, bitmap: 0~62). We do
+ * not need an explicit acquire barrier here because visibility to the
+ * next TX thread is safely protected by the tx_lock boundaries
+ * (mutex_unlock provides Release semantics). The RX thread only
+ * blind-clears bits and doesn't care about this.
+ */
achan->seqnum = bit + 1;
set_bit(bit, achan->bitmap_seqnum);
txd[0] |= FIELD_PREP(ACPM_PROTOCOL_SEQNUM, achan->seqnum);
- /* Clear data for upcoming responses */
+ /*
+ * Clear data for upcoming responses. Speculative execution of memset()
+ * is prevented by the strict Address Dependency (implicit barrier) on
+ * 'bit'. The CPU mathematically cannot calculate the destination
+ * pointer until find_next/first_zero_bit() returns.
+ */
rx_data = &achan->rx_data[bit];
memset(rx_data->cmd, 0, sizeof(*rx_data->cmd) * rx_data->n_cmd);
/* zero means no response expected */
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v3 1/6] firmware: samsung: acpm: Fix cross-thread RX length corruption
From: Tudor Ambarus @ 2026-04-29 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad@linaro.org>
Sashiko identified a cross-thread RX length corruption bug when
reviewing the thermal addition to ACPM [1].
When multiple threads concurrently send IPC requests, the ACPM polling
mechanism can encounter responses belonging to other threads. To drain
the queue, the driver saves these concurrent responses into an internal
cache (`rx_data->cmd`) to be retrieved later by the owning thread.
Previously, the driver incorrectly used `xfer->rxcnt` (the expected
receive length of the *current* polling thread) when copying data for
*other* threads into this cache. If the threads expected responses of
different lengths, this resulted in buffer underflows (leading to reads
of uninitialized memory) or potential buffer overflows.
Fix this by replacing the boolean `response` flag in
`struct acpm_rx_data` with `rxcnt`, caching the exact expected receive
length for each specific transaction during transfer preparation. Use
this cached length when saving concurrent responses.
Consequently, ensure that `xfer->rxcnt` is explicitly zeroed in driver
helpers (e.g., `acpm_dvfs_set_xfer`) for fire-and-forget messages to
prevent uninitialized stack garbage from being interpreted as a massive
expected receive length.
Cc: stable@vger.kernel.org
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/firmware/samsung/exynos-acpm-dvfs.c | 3 +++
drivers/firmware/samsung/exynos-acpm.c | 15 ++++++++-------
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm-dvfs.c b/drivers/firmware/samsung/exynos-acpm-dvfs.c
index 06bdf62dea1f..fdea7aa24ca0 100644
--- a/drivers/firmware/samsung/exynos-acpm-dvfs.c
+++ b/drivers/firmware/samsung/exynos-acpm-dvfs.c
@@ -31,6 +31,9 @@ static void acpm_dvfs_set_xfer(struct acpm_xfer *xfer, u32 *cmd, size_t cmdlen,
if (response) {
xfer->rxcnt = cmdlen;
xfer->rxd = cmd;
+ } else {
+ xfer->rxcnt = 0;
+ xfer->rxd = NULL;
}
}
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 16c46ed60837..e95edc350efa 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -104,12 +104,12 @@ struct acpm_queue {
*
* @cmd: pointer to where the data shall be saved.
* @n_cmd: number of 32-bit commands.
- * @response: true if the client expects the RX data.
+ * @rxcnt: expected length of the response in 32-bit words.
*/
struct acpm_rx_data {
u32 *cmd;
size_t n_cmd;
- bool response;
+ size_t rxcnt;
};
#define ACPM_SEQNUM_MAX 64
@@ -199,7 +199,7 @@ static void acpm_get_saved_rx(struct acpm_chan *achan,
const struct acpm_rx_data *rx_data = &achan->rx_data[tx_seqnum - 1];
u32 rx_seqnum;
- if (!rx_data->response)
+ if (!rx_data->rxcnt)
return;
rx_seqnum = FIELD_GET(ACPM_PROTOCOL_SEQNUM, rx_data->cmd[0]);
@@ -256,7 +256,7 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer)
seqnum = rx_seqnum - 1;
rx_data = &achan->rx_data[seqnum];
- if (rx_data->response) {
+ if (rx_data->rxcnt) {
if (rx_seqnum == tx_seqnum) {
__ioread32_copy(xfer->rxd, addr, xfer->rxcnt);
rx_set = true;
@@ -268,7 +268,8 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer)
* clear yet the bitmap. It will be cleared
* after the response is copied to the request.
*/
- __ioread32_copy(rx_data->cmd, addr, xfer->rxcnt);
+ __ioread32_copy(rx_data->cmd, addr,
+ rx_data->rxcnt);
}
} else {
clear_bit(seqnum, achan->bitmap_seqnum);
@@ -380,8 +381,8 @@ static void acpm_prepare_xfer(struct acpm_chan *achan,
/* Clear data for upcoming responses */
rx_data = &achan->rx_data[achan->seqnum - 1];
memset(rx_data->cmd, 0, sizeof(*rx_data->cmd) * rx_data->n_cmd);
- if (xfer->rxd)
- rx_data->response = true;
+ /* zero means no response expected */
+ rx_data->rxcnt = xfer->rxcnt;
/* Flag the index based on seqnum. (seqnum: 1~63, bitmap: 0~62) */
set_bit(achan->seqnum - 1, achan->bitmap_seqnum);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte
From: Karel Balej @ 2026-04-29 13:20 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Brian Norris, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Duje Mihanović, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Ulf Hansson, Frank Li, linux-wireless,
devicetree, linux-kernel, linux-arm-kernel, linux-mmc,
~postmarketos/upstreaming, phone-devel, Jeff Chen, Peng Fan,
david
In-Reply-To: <20260429112232.GD17033@francesco-nb>
Hello, Francesco,
Francesco Dolcini, 2026-04-29T13:22:32+02:00:
> On Wed, Apr 29, 2026 at 12:55:23PM +0200, Karel Balej wrote:
>> without the firmware being in linux-firmware?
>
> What's the license of this firmware? Am I wrong saying that if
> the license allows it, you could just send a patch to have it integrated
> to the linux-firmware repository? Is there any history or documentation
> on the topic (please apologize if this is a well known topic, just
> answer RTFM if this is the case).
that's one of the issues, the license is not specified explicitly
anywhere as far as I know. Likely it is the same as the other Marvell
blobs already in linux-firmware (the mrvl directory), but we don't know
for sure.
As far as I know, even if I was to submit the firmware myself, it would
still require a sign-off from someone from NXP [1].
> I read a couple of days ago that for example the firmwares for the
> various Apple arm64 laptop cannot be redistributed and every single
> individual that wants to use those needs to extract those from their
> system.
Are those blobs loaded by the mainline kernel? If so, it would be the
same situation as I'm proposing here I believe.
> All of that seems just a legal matter, and IANAL ...
It is.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/about/#signed-off-by-requirement
Karel
^ permalink raw reply
* [PATCH v4 0/4] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann (TI) @ 2026-04-29 13:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suman Anna, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel, Markus Schneider-Pargmann (TI)
Hi,
Split the firmware memory region in more specific parts so it is better
described where which information is stored. Specifically the LPM metadata
region is important as bootloader software like U-Boot has to know where
that data is to be able to read that data and resume from RAM.
The bindings are already applied. The remaining patches use the new
layout for the platforms that are capable to support IO+DDR. For IO+DDR
the new layout is necessary as it defines the location of the LPM
metadata.
Additionally the two important devicetree nodes for resuming from IO+DDR
have the bootph-pre-ram flag added as this data needs to be read before
the RAM is in use.
The changes in this series were suggested as part of the IO+DDR u-boot series:
https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
Best
Markus
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
Changes in v4:
- Rebased to v7.1-rc1
- Dropped all already applied patches that are the bindings and the
initial introduction of memory-region-names
- Link to v3: https://lore.kernel.org/r/20260318-topic-am62a-ioddr-dt-v6-19-v3-0-c41473cb23c3@baylibre.com
Changes in v3:
- Squash the enforcement of the memory-region-names requirement in the
patch adding the memory-region-names, as suggested.
- Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
Changes in v2:
- Make memory-region-names required if memory-region is present
- Fixup memory-region and memory-region-names conditions. Require either
2 or 6 regions for memory-region and memory-region-names
- Reword and restructure the binding documentation for memory-region and
memory-region-names
- Add memory-region-names to all uses of memory-region
- Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
---
Markus Schneider-Pargmann (TI) (4):
arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 42 +++++++++++++++++++++++++++++++--
arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 42 +++++++++++++++++++++++++++++++--
2 files changed, 80 insertions(+), 4 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260210-topic-am62a-ioddr-dt-v6-19-0da7712081d7
Best regards,
--
Markus Schneider-Pargmann (TI) <msp@baylibre.com>
^ permalink raw reply
* [PATCH v4 2/4] arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
From: Markus Schneider-Pargmann (TI) @ 2026-04-29 13:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suman Anna, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260429-topic-am62a-ioddr-dt-v6-19-v4-0-fc27d6ac753c@baylibre.com>
Split the firmware memory region in more specific parts so it is better
described where to find which information. Specifically the LPM metadata
region is important as bootloader software like U-Boot has to know where
that data is to be able to read that data.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 40 +++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
index b770ed82be9d8f5827c49ed871351a6423db8026..e67489a178f2a2caedf1306e1c1c9dd6a95745e6 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
@@ -55,9 +55,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
no-map;
};
- wkup_r5fss0_core0_memory_region: memory@9c900000 {
+ wkup_r5fss0_core0_ipc_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0xf00000>;
+ reg = <0x00 0x9c900000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_fs_stub_region: memory@9ca00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca00000 0x00 0x8000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca08000 0x00 0x1000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca09000 0x00 0x97000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_dm_region: memory@9caa0000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9caa0000 0x00 0xd60000>;
no-map;
};
@@ -844,3 +868,15 @@ &mcu_uart0 {
};
#include "k3-am62p-ti-ipc-firmware.dtsi"
+
+&wkup_r5fss0_core0 {
+ memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+ <&wkup_r5fss0_core0_ipc_region>,
+ <&wkup_r5fss0_core0_lpm_fs_stub_region>,
+ <&wkup_r5fss0_core0_lpm_metadata_region>,
+ <&wkup_r5fss0_core0_lpm_rest_region>,
+ <&wkup_r5fss0_core0_dm_region>;
+ memory-region-names = "dma", "ipc", "lpm-stub",
+ "lpm-metadata", "lpm-context",
+ "dm-firmware";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/4] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann (TI) @ 2026-04-29 13:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suman Anna, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260429-topic-am62a-ioddr-dt-v6-19-v4-0-fc27d6ac753c@baylibre.com>
Split the firmware memory region in more specific parts so it is better
described where to find which information. Specifically the LPM metadata
region is important as bootloader software like U-Boot has to know where
that data is to be able to read that data.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index c1e9067b3bdd5ab0591541d4685bb17a5dac4f65..6f2ee93c7be141ee5ae3f1e3324d3a060db069f6 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
no-map;
};
- wkup_r5fss0_core0_memory_region: memory@9c900000 {
+ wkup_r5fss0_core0_ipc_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0xf00000>;
+ reg = <0x00 0x9c900000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_fs_stub_region: memory@9ca00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca00000 0x00 0x8000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca08000 0x00 0x1000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca09000 0x00 0x97000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_dm_region: memory@9caa0000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9caa0000 0x00 0xd60000>;
no-map;
};
@@ -933,3 +957,15 @@ &mcu_uart0 {
};
#include "k3-am62a-ti-ipc-firmware.dtsi"
+
+&wkup_r5fss0_core0 {
+ memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+ <&wkup_r5fss0_core0_ipc_region>,
+ <&wkup_r5fss0_core0_lpm_fs_stub_region>,
+ <&wkup_r5fss0_core0_lpm_metadata_region>,
+ <&wkup_r5fss0_core0_lpm_rest_region>,
+ <&wkup_r5fss0_core0_dm_region>;
+ memory-region-names = "dma", "ipc", "lpm-stub",
+ "lpm-metadata", "lpm-context",
+ "dm-firmware";
+};
--
2.53.0
^ permalink raw reply related
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