* [PATCH] regulator: mt6359: Fix vbbck default internal supply name
From: Chen-Yu Tsai @ 2026-06-09 8:36 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, linux-kernel
This issue was pointed out by Sashiko.
vbbck is fed internally from vio18. For the MT6359, the default supply
name was incorrectly set as "VIO18", instead of the supply's default
"VIO18". In practice this still works, but it causes the regulator
description copy and replace to always happen. For the MT6359P the
name is correct.
Fix the supply name for MT6359 so that both instances are the same and
correct. Also copy the comment about the internal supply from the MT6359
list to the MT6359P list.
Fixes: 10be8fc1d534 ("regulator: mt6359: Add regulator supply names")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/regulator/mt6359-regulator.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index a27427974186..d9afbcc6a97c 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -706,7 +706,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
/* vbbck is fed from vio18 internally. */
- MT6359_LDO("ldo_vbbck", VBBCK, "VIO18", vbbck_voltages,
+ MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359_RG_LDO_VBBCK_EN_ADDR, MT6359_RG_LDO_VBBCK_EN_SHIFT,
MT6359_DA_VBBCK_B_EN_ADDR, MT6359_RG_VBBCK_VOSEL_ADDR,
MT6359_RG_VBBCK_VOSEL_MASK << MT6359_RG_VBBCK_VOSEL_SHIFT,
@@ -947,6 +947,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_DA_VM18_B_EN_ADDR, MT6359P_RG_VM18_VOSEL_ADDR,
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
+ /* vbbck is fed from vio18 internally. */
MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359P_RG_LDO_VBBCK_EN_ADDR, MT6359P_RG_LDO_VBBCK_EN_SHIFT,
MT6359P_DA_VBBCK_B_EN_ADDR, MT6359P_RG_VBBCK_VOSEL_ADDR,
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* Re: -next boot failures during KVM setup
From: Mark Brown @ 2026-06-09 8:36 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Ard Biesheuvel, Marc Zyngier, Will Deacon, Catalin Marinas,
Oliver Upton, Aishwarya.TCV, linux-arm-kernel
In-Reply-To: <20260608232753.GA2993766@ax162>
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
On Mon, Jun 08, 2026 at 04:27:53PM -0700, Nathan Chancellor wrote:
> On Mon, Jun 08, 2026 at 10:56:12PM +0200, Ard Biesheuvel wrote:
> > Given we're at -rc7, I'd lean towards dropping the whole branch for now, or
> > alternatively, only drop/revert "arm64: mm: Unmap kernel data/bss entirely from the
> > linear map" (and its followup fix "arm64: mm: Defer remap of linear alias of
> > data/bss") so that the region always remains readable via the linear map.
> FWIW, I can confirm that "arm64: mm: Unmap kernel data/bss entirely from
> the linear map" is the culprit for this particular issue based on my
> bisect. Reverting those two changes on top of next-20260608 avoids the
> issue.
Yes, same result here.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3] clk: imx: Add audio PLL debugfs for K-divider control
From: Peng Fan @ 2026-06-09 8:33 UTC (permalink / raw)
To: Jacky Bai
Cc: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd,
Brian Masney, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-clk, imx, linux-arm-kernel
In-Reply-To: <20260604-imx8m_pll_debugfs-v3-1-4e331ebc85d7@nxp.com>
On Thu, Jun 04, 2026 at 09:48:01PM +0800, Jacky Bai wrote:
>Add debugfs support for runtime tuning of the audio PLL K divider,
>which enables fine-grained frequency adjustments for audio PLL.
>This is used for:
> - Audio clock calibration and testing
> - Debugging audio synchronization issues
>
>Two debug interfaces are exported to userspace:
> - delta_k: It is used to adjust the K divider in PLL based on small
> steps
> - pll_parameter: It is used for get PLL's current M-divider,
> P-divider, S-divider & K-divider setting in PLL register
>
>Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: Krzysztof Kozlowski @ 2026-06-09 8:30 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260608-shikra-display-v4-1-88a846afdd5d@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 12:31:42PM +0530, Nabige Aala wrote:
> Shikra reuses the same MDSS/DPU 6.5 hardware as QCM2290. Extend
> the existing qcm2290 bindings to cover Shikra by adding fallback
> compatible chains for MDSS, DPU and DSI controller nodes rather
> than introducing a separate binding file.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v6 08/21] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing
From: Atish Patra @ 2026-06-09 6:01 UTC (permalink / raw)
To: James Clark, Rob Herring, Atish Patra, Arnaldo Carvalho de Melo,
Jiri Olsa, Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers
Cc: linux-riscv, linux-kernel, linux-perf-users, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <20260608-counter_delegation-v6-0-285b72ed65a9@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Smcdeleg extension allows the M-mode to delegate selected counters
to S-mode so that it can access those counters and correpsonding
hpmevent CSRs without M-mode.
Ssccfg (‘Ss’ for Privileged architecture and Supervisor-level
extension, ‘ccfg’ for Counter Configuration) provides access to
delegated counters and new supervisor-level state.
This patch just enables these definitions and enable parsing.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/hwcap.h | 2 ++
arch/riscv/kernel/cpufeature.c | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 51ad55b9677a..089353b250b0 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -115,6 +115,8 @@
#define RISCV_ISA_EXT_SSCSRIND 106
#define RISCV_ISA_EXT_SMCSRIND 107
#define RISCV_ISA_EXT_SMCNTRPMF 108
+#define RISCV_ISA_EXT_SSCCFG 109
+#define RISCV_ISA_EXT_SMCDELEG 110
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 1452521d740a..1fe647e03515 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -330,6 +330,27 @@ static const unsigned int riscv_a_exts[] = {
RISCV_ISA_EXT_ZKNE, \
RISCV_ISA_EXT_ZKNH
+static int riscv_ext_smcdeleg_validate(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SSCSRIND) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZIHPM) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZICNTR))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
+static int riscv_ext_ssccfg_validate(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (!riscv_ext_smcdeleg_validate(data, isa_bitmap) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SMCDELEG))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
static const unsigned int riscv_zk_bundled_exts[] = {
RISCV_ISA_EXT_ZKN,
RISCV_ISA_EXT_ZKR,
@@ -576,12 +597,15 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_BUNDLE_VALIDATE(zvksg, riscv_zvksg_bundled_exts, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zvkt, RISCV_ISA_EXT_ZVKT, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+ __RISCV_ISA_EXT_DATA_VALIDATE(smcdeleg, RISCV_ISA_EXT_SMCDELEG,
+ riscv_ext_smcdeleg_validate),
__RISCV_ISA_EXT_DATA(smcntrpmf, RISCV_ISA_EXT_SMCNTRPMF),
__RISCV_ISA_EXT_DATA(smcsrind, RISCV_ISA_EXT_SMCSRIND),
__RISCV_ISA_EXT_DATA(smmpm, RISCV_ISA_EXT_SMMPM),
__RISCV_ISA_EXT_SUPERSET(smnpm, RISCV_ISA_EXT_SMNPM, riscv_xlinuxenvcfg_exts),
__RISCV_ISA_EXT_DATA(smstateen, RISCV_ISA_EXT_SMSTATEEN),
__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+ __RISCV_ISA_EXT_DATA_VALIDATE(ssccfg, RISCV_ISA_EXT_SSCCFG, riscv_ext_ssccfg_validate),
__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
__RISCV_ISA_EXT_DATA(sscsrind, RISCV_ISA_EXT_SSCSRIND),
__RISCV_ISA_EXT_SUPERSET(ssnpm, RISCV_ISA_EXT_SSNPM, riscv_xlinuxenvcfg_exts),
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Vladimir Murzin @ 2026-06-09 8:26 UTC (permalink / raw)
To: Marek Szyprowski, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <6a9c0f55-fe98-4063-864b-8f7e1f4fefd7@samsung.com>
Hi,
On 6/9/26 07:28, Marek Szyprowski wrote:
> On 09.06.2026 08:22, Marek Szyprowski wrote:
>> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> The linear aliases of the kernel text and rodata are also mapped
>>> read-only in the linear map. Given that the contents of these regions
>>> are mostly identical to the version in the loadable image, mapping them
>>> read-only and leaving their contents visible is a reasonable hardening
>>> measure.
>>>
>>> Data and bss, however, are now also mapped read-only but the contents of
>>> these regions are more likely to contain data that we'd rather not leak.
>>> So let's unmap these entirely in the linear map when the kernel is
>>> running normally.
>>>
>>> When going into hibernation or waking up from it, these regions need to
>>> be mapped, so map the region initially, and toggle the valid bit so
>>> map/unmap the region as needed.
>>>
>>> Doing so is required because pages covering the kernel image are marked
>>> as PageReserved, and therefore disregarded for snapshotting by the
>>> hibernate logic unless they are mapped.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
>> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
>> In my tests I found that it breaks booting of RaspberryPi3 and
>> RaspberryPi4 boards with the following kernel panic:
> One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
> change) on top of next-20260608 fixes this issue.
>
Thanks for report! It seems it already has been reported and discussed in
another thread [1].
[1] https://lore.kernel.org/linux-arm-kernel/aicVyebkEMs6w6UV@sirena.co.uk/
Cheers
Vladimir
> Best regards
> -- Marek Szyprowski, PhD Samsung R&D Institute Poland
>
^ permalink raw reply
* Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support
From: Liu Ying @ 2026-06-09 8:26 UTC (permalink / raw)
To: Marek Vasut
Cc: Piyush Patle, dri-devel, imx, linux-arm-kernel, linux-clk,
devicetree, Shawn Guo, Fabio Estevam, Peng Fan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Laurent Pinchart,
Thomas Zimmermann, Abel Vesa, Pengutronix Kernel Team
In-Reply-To: <9ece4e08-a77f-4410-ba16-a77b9bd0aace@mailbox.org>
On Mon, Jun 08, 2026 at 06:29:32PM +0200, Marek Vasut wrote:
> On 6/8/26 9:48 AM, Liu Ying wrote:
>
> Hello everyone,
>
> > > I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
> > > LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
> > > LVDS format handling, and DC enable sequencing which needed rework before
> > > HDMI would come up reliably on the board.
> > >
> > > I don't see a v2 of the series and things seem to have been quiet since
> > > November. Are you planning to post an updated version?
> >
> > My plan was to enable prefetch engine support[1] for i.MX8QXP display
> > controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
> > before adding i.MX95 display controller support.
> >
> > Unfortunately, it seems that Marek is not a big fan of [1]
>
> I am fine with [1] as long as it can be isolated and does not affect every
> SoC that might reuse this driver, which I think it can be done.
How can it be isolated?
>
> > and I'm busy
> > with downstream development so the plan doesn't move forward well. I still
> > think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
> > so I'd like to see review comments on [1] and hopefully people think that
> > the overall idea of [1] is ok.
>
> My only concern is, to keep it isolated to MX8Q, so this driver can be
> reused by MX95.
>
> > > I've accumulated a fair amount of rework while getting this running on the
> > > FRDM. If you're not planning a v2, I can clean things up and send one based
> > > on the current series.
> >
> > I still think that i.MX95 display controller driver should be in a separate
> > driver, rather than sharing the same driver with i.MX8QXP display controller
> > like this patch series does, because the two display controllers are quite
> > different as I mentioned in comments on this patch series and in discussion
> > in [1]. Also, the common part between the two display controllers should
> > be extracted to a common helper library as I mentioned there too.
> Are they really? It seems this series adds support for the MX95 DC without
> that many changes, so are the DCs really that different ? It seems the MX95
> DC is simply a reuse/evolution of the MX8Q DC blocks, so duplicating the
> code seems like the wrong direction, it will only lead to disparate sets of
> bugs in two drivers, which isn't desired.
I pointed out a lot of H/W differences between the two display controllers
during the discussions for this patch series and my i.MX8QXP prefetch engine
patch series[1]. Please take a look at [1], which clearly shows that the
prefetch engine would considerably impact CRTC/plane atomic callback
implementations. Display controller internal blocks would also impact
the implementations, e.g., DomainBlend block in i.MX95 display controller
doesn't present in i.MX8QXP display controller. It makes sense to use
separate drivers for the two display controllers instead of adding 'if/else'
checks to a single driver's atomic callbacks or introducing two pairs of
atomic callbacks to that single driver. I mentioned before, the code to
simply add a DRM driver(struct drm_driver) is fairly limited.
I also mentioned before that separate drivers make them easier to maintain:
we don't have to test both i.MX8QXP and i.MX95 if only one display controller
specific code is changed.
>
> (I might not fully understand what you have in mind with the helper library
> though?)
I said this could be something like imx-ldb-helper.c and plus perhaps some
callbacks like fg->dc_fg_cfg_videomode().
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 30/37] drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline
From: Luca Ceresoli @ 2026-06-09 8:23 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260608-shapeless-opal-ferret-c8b105@houat>
Hi Maxime,
thanks for the review of this long series!
On Mon Jun 8, 2026 at 2:34 PM CEST, Maxime Ripard wrote:
...
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -78,6 +78,19 @@ struct drm_bridge_funcs {
>> int (*attach)(struct drm_bridge *bridge, struct drm_encoder *encoder,
>> enum drm_bridge_attach_flags flags);
>>
>> + /**
>> + * @is_tail:
>> + *
>> + * Returns true if this is a tail bridge, i.e. it does not need a
>> + * next bridge to work. E.g. a panel_bridge is a tail bridge, a
>> + * DSI-to-LVDS bridge is not a tail bridge (no matter whether the
>> + * next bridge is present or not).
>
> Why a DSI-to-LDVS bridge isn't a tail bridge? It only needs a panel
> next, right?
Uhm, good point, but I'd say it can be a tail bridge or not: in the
ATTACH_NO_CONNECTOR case it will need a bridge (a panel_bridge most
likely), no?
However this is possibly irrelevant as the whole .is_tail is meant to
disappear in v2, see below.
>> + * The @is_tail callback is optional but it is required if the
>> + * bridge is part of a pipeline with hot-pluggable components.
>> + */
>> + bool (*is_tail)(struct drm_bridge *bridge);
>> +
>
> I don't think that's the right way to think about it, if only because
> you never really know at the driver level if you're supposed to be last
> or not. A DSI-to-LVDS bridge might just as well be chained with an
> LVDS-to-eDP bridge, or feed the panel directly without any additional
> bridge.
>
> I *think* that what you're trying to find out here is whether the chain
> is complete or not.
You nailed it.
That was the main point discussed during the Display Next Hackfest 2026
(see the report [0]) and we all agreed the .is_tail along with the
-EPROBE_DEFER changes (patches 20+35) are not a good approach.
This is actually the most crucial aspect of the whole work still not having
no well-defined solution.
> I think you can get the same information by checking
> whether you have a connector for that bridge chain. If you don't, you
> know the chain isn't complete, and if you do, it's supposed to be.
There's a checken-egg problem here. Knowing whether the pipeline is
complete or not is needed to know whether we have to create a
connector. See patch 36:
+ if (drm_bridge_connector_pipeline_is_complete(bridge_connector))
+ drm_bridge_connector_add_connector(bridge_connector);
So the question is still open, what I need the most right now is comments
on the overall architecture of this aspecs. Maybe replying to [0] can be
more effective than here.
In a nutshell what we need is:
* when a bridge needs a following element (a bridge, or a panel which
however might/should have a panel_bridge), but that element is not
present, instead of deferring the whole card probe the card should be
allowed to probe but without a connector
* when something is added to an incomplete pipeline we need to know
whether the pipeline has become complete (in order to create the
connector)
How to implement this is still an open point. I'll welcome proposals in
addition to the ones in [0].
[0] https://lore.kernel.org/all/DIXTUCXAU68V.1T7X89LMEUF2F@bootlin.com/
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] arm64: dts: rockchip: fix emmc reset polarity on px30-cobra
From: Jakob Unterwurzacher @ 2026-06-09 8:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Jakob Unterwurzacher, Quentin Schulz
Cc: stable, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
From: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Technically, the reset signal is active low - it's called RST_n after all.
But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
is set in the emmc. It is 0 per default.
For emmcs that have RST_n_FUNCTION=1 we failed like this:
[ 3.074480] mmc1: Failed to initialize a non-removable card
With this change they work normally.
Cc: stable@vger.kernel.org
Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
---
v2: Add correct "From: " line
arch/arm64/boot/dts/rockchip/px30-cobra.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
index b7e669d8ba4d..90751b04f95c 100644
--- a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
@@ -35,7 +35,7 @@ emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
pinctrl-0 = <&emmc_reset>;
pinctrl-names = "default";
- reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_LOW>;
};
gpio-leds {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] i2c: imx-lpi2c: fix resource leaks switching to devm_dma_request_chan()
From: Andi Shyti @ 2026-06-09 8:16 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: aisheng.dong, Frank.Li, s.hauer, kernel, festevam, carlos.song,
linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260520093323.2882070-1-carlos.song@oss.nxp.com>
Hi Carlos,
On Wed, May 20, 2026 at 05:33:23PM +0800, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> The LPI2C driver requests DMA channels using dma_request_chan(), but
> never releases them in lpi2c_imx_remove(), resulting in DMA channel
> leaks every time the driver is unloaded.
>
> Additionally, when lpi2c_dma_init() successfully requests the TX DMA
> channel but fails to request the RX DMA channel, the probe falls back
> to PIO mode and completes successfully. Since probe succeeds, the devres
> framework will not trigger any cleanup, leaving the TX DMA channel and
> the memory allocated for the dma structure held for the lifetime of the
> device even though DMA is never used.
>
> Switch to devm_dma_request_chan() to let the device core manage DMA
> channel lifetime automatically. Wrap all allocations within a devres
> group so that devres_release_group() can release all partially acquired
> resources when DMA init fails and probe continues in PIO mode.
>
> Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C")
> Cc: stable@vger.kernel.org
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
merged to i2c/i2c-host-fixes.
Thanks,
Andi
^ permalink raw reply
* [PATCH] net: ethernet: mediatek: fix refcount leak in mtk_probe()
From: Wentao Liang @ 2026-06-09 8:13 UTC (permalink / raw)
To: nbd, lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno
Cc: netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
Wentao Liang, stable
If mtk_sgmii_init() fails after successfully creating some PCS
instances, it returns an error without cleaning up the partially
created ones. mtk_pcs_lynxi_create() increments the fwnode
refcount for each PCS it creates, but this refcount is never
released because mtk_probe() uses a plain "return err" instead of
a goto to the err_destroy_sgmii label. This leaks both the PCS
devices and their fwnode references.
Fix the leak by jumping to the existing err_destroy_sgmii path
which calls mtk_sgmii_destroy() to safely release all allocated
resources.
Cc: stable@vger.kernel.org
Fixes: 9ffee4a8276c ("net: ethernet: mediatek: Extend SGMII related functions")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8d225bc9f063..0f185462cf85 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -5169,7 +5169,7 @@ static int mtk_probe(struct platform_device *pdev)
err = mtk_sgmii_init(eth);
if (err)
- return err;
+ goto err_destroy_sgmii;
}
if (eth->soc->required_pctl) {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: rockchip: fix emmc reset polarity on px30-cobra
From: Jakob Unterwurzacher @ 2026-06-09 8:10 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Quentin Schulz, Jakob Unterwurzacher
Cc: stable, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <3631825.d7IHhHJzqS@phil>
On 6/2/26 23:08, Heiko Stuebner wrote:
>
> as Quentin remarked, author (@gmail) and signed-off-by do not match.
> While I'm generally open to fixing things, when it touches the DCO this
> isn't the case.
>
> So please resend this with the correct author.
>
> In general "git send-email" will do the correct thing (that From: line),
> when patch author and email-id do not match.
For posterity:
What seems to be happening is that Gmail rewrites the "From: " header on
the server side. git send-email does now know this, so doesn't add the
extra "From: " line.
Making the final "From: " explicit in .gitconfig using
[sendemail]
from = Jakob Unterwurzacher <jakobunt@gmail.com>
now makes git send-email add that extra "From: " line in the email body
as expected.
I'll resend the patch now.
Thanks, Jakob
^ permalink raw reply
* [RESEND PATCH v3] coresight: etm-perf: Fix reference count leak in etm_setup_aux
From: Ma Ke @ 2026-06-09 8:02 UTC (permalink / raw)
To: suzuki.poulose, mike.leach, james.clark, leo.yan,
alexander.shishkin, mathieu.poirier
Cc: coresight, linux-arm-kernel, linux-kernel, akpm, Ma Ke, stable
bus_find_device() returns a device with its reference count
incremented. When a user-selected sink is obtained through
coresight_get_sink_by_id(), etm_setup_aux() keeps using the returned
sink while building the path and allocating the sink buffer.
Therefore the lookup reference must remain valid while etm_setup_aux()
is still using the sink, otherwise the sink could be removed under the
caller. Drop the lookup reference on the common exit path, after
etm_setup_aux() no longer directly uses the user-selected sink.
The CoreSight path code takes the references it needs for built paths,
so the initial lookup reference from coresight_get_sink_by_id() is no
longer needed after setup_aux finishes.
Found by code review.
Signed-off-by: Ma Ke <make24@iscas.ac.cn>
Cc: stable@vger.kernel.org
Fixes: 0e6c20517596 ("coresight: etm-perf: Allow an event to use different sinks")
---
Changes in v3:
- do not drop the lookup reference in coresight_get_sink_by_id(), as
that would return a sink pointer without keeping the device reference
while etm_setup_aux() is still using it.
- dropped the lookup reference in etm_setup_aux on the common exit path,
as suggested by Suzuki.
- updated the commit message to describe why the reference is kept
until etm_setup_aux() finishes using the sink.
Changes in v2:
- modified the patch as suggestions.
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f85dedf89a3f..d5116177c1b9 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -456,6 +456,11 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
goto err;
out:
+ if (user_sink) {
+ put_device(&user_sink->dev);
+ user_sink = NULL;
+ }
+
return event_data;
err:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 00/37] drm bridge hotplug
From: Luca Ceresoli @ 2026-06-09 7:47 UTC (permalink / raw)
To: Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Inki Dae, Jagan Teki, Marek Szyprowski,
Marek Vasut, Stefan Agner, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DIXTUCXAU68V.1T7X89LMEUF2F@bootlin.com>
Hello,
On Mon Jun 1, 2026 at 5:44 PM CEST, Luca Ceresoli wrote:
> Hello,
>
> I presented this series last Friday during the Display Next Hackfest
> 2026. Here's a summary of the discussion.
For the records, the presentation slides are available at
https://bootlin.com/pub/conferences/2026/display-next-hackfest/ceresoli-drm-bridge-hotplug.pdf
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [GIT PULL] Microchip ARM64 device tree updates for v7.2
From: Claudiu Beznea @ 2026-06-09 7:41 UTC (permalink / raw)
To: soc, arm
Cc: claudiu.beznea, nicolas.ferre, alexandre.belloni,
linux-arm-kernel, conor
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-dt64-7.2
for you to fetch changes up to 8071815790141d3f05e32b972a6c79fdbbb88cfa:
arm64: dts: microchip: lan969x: add OTP node (2026-05-25 22:59:07 +0300)
----------------------------------------------------------------
Microchip ARM64 device tree updates for v7.2
This update includes:
- the device tree node for the OTP controller on LAN9691 SoC
----------------------------------------------------------------
Robert Marko (1):
arm64: dts: microchip: lan969x: add OTP node
arch/arm64/boot/dts/microchip/lan9691.dtsi | 5 +++++
1 file changed, 5 insertions(+)
^ permalink raw reply
* [GIT PULL] Microchip AT91 device tree updates for v7.2
From: Claudiu Beznea @ 2026-06-09 7:39 UTC (permalink / raw)
To: soc, arm; +Cc: claudiu.beznea, nicolas.ferre, alexandre.belloni,
linux-arm-kernel
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-dt-7.2
for you to fetch changes up to 96b33938cf783c790036e35860b206cf029f2e2a:
ARM: dts: microchip: add I3C controller (2026-05-25 22:54:37 +0300)
----------------------------------------------------------------
Microchip AT91 device tree updates for v7.2
This update includes:
- I3C controller device tree node for SAMA7D65 SoC
----------------------------------------------------------------
Durai Manickam KR (1):
ARM: dts: microchip: add I3C controller
arch/arm/boot/dts/microchip/sama7d65.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
^ permalink raw reply
* [GIT PULL] Microchip AT91 defconfig updates for v7.2
From: Claudiu Beznea @ 2026-06-09 7:39 UTC (permalink / raw)
To: soc, arm; +Cc: claudiu.beznea, nicolas.ferre, alexandre.belloni,
linux-arm-kernel
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-defconfig-7.2
for you to fetch changes up to ac75ae436723e5fe68dcc8e806f66d0358dd56f7:
ARM: configs: at91: sama7: add sama7d65 i3c-hci (2026-05-25 22:55:30 +0300)
----------------------------------------------------------------
Microchip AT91 defconfig updates for v7.2
This update includes:
- I3C flags for the SAMA7 family of SoCs
----------------------------------------------------------------
Manikandan Muralidharan (1):
ARM: configs: at91: sama7: add sama7d65 i3c-hci
arch/arm/configs/sama7_defconfig | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [PATCH] gpio: zynq: fix runtime PM leak on remove
From: Ruoyu Wang @ 2026-06-09 7:33 UTC (permalink / raw)
To: Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, Linus Walleij,
Bartosz Golaszewski
Cc: Harini Katakam, Soren Brinkmann, linux-gpio, linux-arm-kernel,
linux-kernel, Ruoyu Wang
pm_runtime_get_sync() increments the runtime PM usage counter even when it
returns an error. zynq_gpio_remove() uses it to keep the controller active
while removing the GPIO chip, but never drops the usage counter again.
Balance the get with pm_runtime_put_noidle() after disabling runtime PM.
Fixes: 3242ba117e9b ("gpio: Add driver for Zynq GPIO controller")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
drivers/gpio/gpio-zynq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 571e366624d2a..fafca91128b2e 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -1014,6 +1014,7 @@ static void zynq_gpio_remove(struct platform_device *pdev)
gpiochip_remove(&gpio->chip);
device_set_wakeup_capable(&pdev->dev, 0);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
static struct platform_driver zynq_gpio_driver = {
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
Nvidia Tegra264 SMMUs are affected by an erratum where a TLB entry can
survive an invalidation that races with concurrent traffic targeting
the same entry. The hardware-recommended software workaround is to
issue every CFGI/TLBI command (each followed by CMD_SYNC) twice.
The second issue must execute only after the first issue's CMD_SYNC
has completed, giving the sequence:
TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC
ATC_INV is not affected and must not be doubled.
The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
cannot be detected from hardware ID. Tegra264 is device-tree-only
(no ACPI/IORT support), so detection is purely by compatible string.
This series is structured as a small refactor + detect + apply
sequence so that each step is reviewable in isolation:
1/3 Pure refactor (no functional change): lift the existing
force-sync conditions out of arm_smmu_cmdq_batch_add_cmd_p()
into a new arm_smmu_cmdq_batch_force_sync() helper, so that
adding another condition (in patch 3) is a one-liner.
Authored by Nicolin Chen.
2/3 Detect the erratum and provide the classifier. Adds the
ARM_SMMU_OPT_REPEAT_TLBI_CFGI per-instance option, a global
arm_smmu_erratum_repeat_tlbi_cfgi_key static key, and the
arm_smmu_erratum_cmd_needs_repeating() predicate. The static
key means the wrapper compiles to a single tested branch on
unaffected kernels.
3/3 Apply the workaround: factor arm_smmu_cmdq_issue_cmdlist()
into a thin wrapper around __arm_smmu_cmdq_issue_cmdlist()
that re-issues the cmdlist a second time when the predicate
fires; register the same condition with the batch helper so
full batches of CFGI/TLBI flush with sync=true; and add
arm_vsmmu_can_batch_cmd() so iommufd does not mix command
classes inside a single batch. Also documents the erratum
in silicon-errata.rst.
The series applies cleanly on linux-next/master (base-commit below).
Changes since v3:
- Drop the cmds->num == 0 early-return so the refactor is
truly "no functional change".
- Rename ARM_SMMU_OPT_TLBI_TWICE -> ARM_SMMU_OPT_REPEAT_TLBI_CFGI
and rephrase its kdoc to be hardware-agnostic.
- Rename arm_smmu_cmd_needs_tlbi_twice() ->
arm_smmu_erratum_cmd_needs_repeating() and drop the kdoc
above it.
- Replace the explicit opcode switch with a single range check
opcode >= CMDQ_OP_CFGI_STE && opcode < CMDQ_OP_ATC_INV.
- Introduce arm_smmu_erratum_repeat_tlbi_cfgi_key static key:
the predicate gates on it first so unaffected kernels pay
only a single static_branch_unlikely() check.
- Drop the verbose Tegra264-specific comments above
arm_vsmmu_can_batch_cmd() and inside the batch helper.
- Document the erratum in
Documentation/arch/arm64/silicon-errata.rst.
- Guard the repeat path in arm_smmu_cmdq_issue_cmdlist() with
an n > 0 check so we never inspect cmds[0] on the bare-SYNC
flush emitted by arm_smmu_cmdq_batch_add_cmd_p() when the
next command is unsupported by the batch's pre-selected
cmdq.
- Drop the carried Reviewed-by tags now that the patch
shape has changed; re-review appreciated.
Changes since v2:
- Split into a 3-patch series (refactor / detect / apply) to keep
each step small and bisectable.
- Move the classifier to arm-smmu-v3.h as static inline so the
iommufd file can share it.
- Add arm_vsmmu_can_batch_cmd() to split iommufd batches at
"needs repeating" transitions so the per-batch decision based
on the first command stays correct under mixed user input.
- Spell out in the commit message why detection is via DT and
not via IIDR/ACPI.
Changes since v1:
- Detect the erratum from the existing "nvidia,tegra264-smmu"
compatible instead of adding a new property.
- Centralise the doubling at the CMDQ submission layer and only
apply it to CFGI/TLBI (not ATC_INV).
- Drop the binding/dtsi patches accordingly.
Ashish Mhetre (2):
iommu/arm-smmu-v3: Detect Tegra264 erratum
iommu/arm-smmu-v3: Issue CFGI/TLBI twice on Tegra264
Nicolin Chen (1):
iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
Documentation/arch/arm64/silicon-errata.rst | 2 +
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 15 ++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 65 +++++++++++++++----
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 24 +++++++
4 files changed, 94 insertions(+), 12 deletions(-)
base-commit: 7da7f07112610a520567421dd2ffcb51beaefbcc
--
2.50.1
^ permalink raw reply
* [PATCH v4 3/3] iommu/arm-smmu-v3: Issue CFGI/TLBI twice on Tegra264
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
In-Reply-To: <20260609073204.1760077-1-amhetre@nvidia.com>
Apply the workaround for Tegra264 erratum ARM_SMMU_OPT_REPEAT_TLBI_CFGI
by issuing every CFGI/TLBI cmdlist twice on affected SMMU instances,
with CMD_SYNC after each. The erratum requires this exact sequencing:
TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC
Rename the existing arm_smmu_cmdq_issue_cmdlist() to
__arm_smmu_cmdq_issue_cmdlist() and add a thin wrapper that, on
affected SMMUs and when @sync is true with @n > 0, re-issues the
same cmdlist a second time when arm_smmu_erratum_cmd_needs_repeating()
is true. The @n > 0 gate is needed because arm_smmu_cmdq_batch_add_cmd_p()
can call arm_smmu_cmdq_issue_cmdlist() with @n == 0 and @sync == true
to flush a bare CMD_SYNC when the next command is not supported by
the batch's pre-selected cmdq; the repeat path must not inspect
cmds[0] in that case. The static-key gate inside the predicate means
the wrapper compiles to a single tested branch on unaffected kernels.
For the in-tree batching path, register the new condition with
arm_smmu_cmdq_batch_force_sync() so that a full batch carrying
CFGI/TLBI commands flushes with sync=true.
For the iommufd VSMMU path add an arm_vsmmu_can_batch_cmd() predicate
that splits the iommufd batch at every "needs repeating" transition,
so the wrapper's per-batch decision based on the first command stays
correct even when userspace mixes opcode classes.
Also document the erratum in Documentation/arch/arm64/silicon-errata.rst.
Suggested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
Documentation/arch/arm64/silicon-errata.rst | 2 ++
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 15 +++++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 35 ++++++++++++++++---
3 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 046a7fa47063..96050886a7d6 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -268,6 +268,8 @@ stable kernels.
| | | T241-MPAM-4, | |
| | | T241-MPAM-6 | |
+----------------+-----------------+-----------------+-----------------------------+
+| NVIDIA | T264 SMMU | T264-SMMU-3 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+----------------+-----------------+-----------------+-----------------------------+
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
index 1e9f7d2de344..11d22acae613 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
@@ -350,6 +350,18 @@ static int arm_vsmmu_convert_user_cmd(struct arm_vsmmu *vsmmu,
return 0;
}
+static bool arm_vsmmu_can_batch_cmd(struct arm_smmu_device *smmu,
+ struct arm_vsmmu_invalidation_cmd *last,
+ struct arm_vsmmu_invalidation_cmd *next)
+{
+ struct arm_smmu_cmd next_cmd = {
+ .data[0] = le64_to_cpu(next->ucmd.cmd[0]),
+ };
+
+ return arm_smmu_erratum_cmd_needs_repeating(smmu, &last->cmd) ==
+ arm_smmu_erratum_cmd_needs_repeating(smmu, &next_cmd);
+}
+
int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
struct iommu_user_data_array *array)
{
@@ -382,7 +394,8 @@ int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
/* FIXME work in blocks of CMDQ_BATCH_ENTRIES and copy each block? */
cur++;
- if (cur != end && (cur - last) != CMDQ_BATCH_ENTRIES - 1)
+ if (cur != end && (cur - last) != CMDQ_BATCH_ENTRIES - 1 &&
+ arm_vsmmu_can_batch_cmd(smmu, last, cur))
continue;
/* FIXME always uses the main cmdq rather than trying to group by type */
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 599c835c50d8..041e188b3b30 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -700,10 +700,10 @@ static void arm_smmu_cmdq_write_entries(struct arm_smmu_cmdq *cmdq,
* insert their own list of commands then all of the commands from one
* CPU will appear before any of the commands from the other CPU.
*/
-int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
- struct arm_smmu_cmdq *cmdq,
- struct arm_smmu_cmd *cmds, int n,
- bool sync)
+static int __arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmdq *cmdq,
+ struct arm_smmu_cmd *cmds, int n,
+ bool sync)
{
struct arm_smmu_cmd cmd_sync;
u32 prod;
@@ -822,6 +822,28 @@ int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
return ret;
}
+int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmdq *cmdq,
+ struct arm_smmu_cmd *cmds, int n,
+ bool sync)
+{
+ int ret = __arm_smmu_cmdq_issue_cmdlist(smmu, cmdq, cmds, n, sync);
+
+ /*
+ * arm_smmu_cmdq_batch_add_cmd_p() can flush its current batch with
+ * sync=true and n=0 (bare SYNC) when the next command is not
+ * supported by the batch's pre-selected cmdq, so the repeat path
+ * must not inspect cmds[0].
+ */
+ if (!n || ret || !sync)
+ return ret;
+
+ if (arm_smmu_erratum_cmd_needs_repeating(smmu, &cmds[0]))
+ ret = __arm_smmu_cmdq_issue_cmdlist(smmu, cmdq, cmds, n, sync);
+
+ return ret;
+}
+
static int arm_smmu_cmdq_issue_cmd_p(struct arm_smmu_device *smmu,
struct arm_smmu_cmd *cmd, bool sync)
{
@@ -862,6 +884,11 @@ static bool arm_smmu_cmdq_batch_force_sync(struct arm_smmu_device *smmu,
(smmu->options & ARM_SMMU_OPT_CMDQ_FORCE_SYNC))
return true;
+ /* See ARM_SMMU_OPT_REPEAT_TLBI_CFGI */
+ if (cmds->num == CMDQ_BATCH_ENTRIES &&
+ arm_smmu_erratum_cmd_needs_repeating(smmu, &cmds->cmds[0]))
+ return true;
+
return false;
}
--
2.50.1
^ permalink raw reply related
* [PATCH v4 1/3] iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
In-Reply-To: <20260609073204.1760077-1-amhetre@nvidia.com>
From: Nicolin Chen <nicolinc@nvidia.com>
arm_smmu_cmdq_batch_add_cmd_p() carries two distinct reasons for
flushing the current batch with a CMD_SYNC before appending the
new command:
- The batch's pre-assigned cmdq does not support the new command.
- The Arm erratum 2812531 workaround (ARM_SMMU_OPT_CMDQ_FORCE_SYNC)
forces a SYNC at one entry before the batch is full.
Lift those checks into a new arm_smmu_cmdq_batch_force_sync() helper
so that adding another force-sync condition becomes a one-line
addition. No functional change.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 23 +++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a10affb483a4..76efe479e80f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -847,16 +847,27 @@ static void arm_smmu_cmdq_batch_init_cmd(struct arm_smmu_device *smmu,
cmds->cmdq = arm_smmu_get_cmdq(smmu, cmd);
}
+static bool arm_smmu_cmdq_batch_force_sync(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmdq_batch *cmds,
+ struct arm_smmu_cmd *cmd)
+{
+ /* The batch's pre-assigned cmdq doesn't support the new command */
+ if (!arm_smmu_cmdq_supports_cmd(cmds->cmdq, cmd))
+ return true;
+
+ /* Arm erratum 2812531 */
+ if (cmds->num == CMDQ_BATCH_ENTRIES - 1 &&
+ (smmu->options & ARM_SMMU_OPT_CMDQ_FORCE_SYNC))
+ return true;
+
+ return false;
+}
+
static void arm_smmu_cmdq_batch_add_cmd_p(struct arm_smmu_device *smmu,
struct arm_smmu_cmdq_batch *cmds,
struct arm_smmu_cmd *cmd)
{
- bool force_sync = (cmds->num == CMDQ_BATCH_ENTRIES - 1) &&
- (smmu->options & ARM_SMMU_OPT_CMDQ_FORCE_SYNC);
- bool unsupported_cmd;
-
- unsupported_cmd = !arm_smmu_cmdq_supports_cmd(cmds->cmdq, cmd);
- if (force_sync || unsupported_cmd) {
+ if (arm_smmu_cmdq_batch_force_sync(smmu, cmds, cmd)) {
arm_smmu_cmdq_issue_cmdlist(smmu, cmds->cmdq, cmds->cmds,
cmds->num, true);
arm_smmu_cmdq_batch_init_cmd(smmu, cmds, cmd);
--
2.50.1
^ permalink raw reply related
* [PATCH v4 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
In-Reply-To: <20260609073204.1760077-1-amhetre@nvidia.com>
Tegra264 SMMU is affected by an erratum where a TLB entry can survive
an invalidation that races with concurrent traffic targeting the same
entry. The hardware-recommended software workaround is to issue every
CFGI/TLBI command (each followed by CMD_SYNC) twice. The second issue
is guaranteed to evict the entry. ATC_INV is not affected and must
not be doubled.
The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
cannot be detected from hardware registers. Tegra264 boots from device
tree only and has no ACPI/IORT support, so detection is through device
tree only.
Add the ARM_SMMU_OPT_REPEAT_TLBI_CFGI option and set it on instances
matching the existing "nvidia,tegra264-smmu" compatible. Also add a
matching arm_smmu_erratum_repeat_tlbi_cfgi_key static key that DT
probe enables, so the inline classifier compiles down to a single
test+branch on unaffected kernels. Add an
arm_smmu_erratum_cmd_needs_repeating() helper in arm-smmu-v3.h that
gates on the static key first and then range-checks the opcode
(CFGI_STE .. ATC_INV), so subsequent changes wiring the workaround
into the CMDQ submission and iommufd batching paths can share a
single predicate.
No callers consume the option yet. A subsequent change wires the
workaround into the CMDQ issue paths.
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 +++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 24 +++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 76efe479e80f..599c835c50d8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -42,6 +42,8 @@ MODULE_PARM_DESC(disable_msipolling,
static const struct iommu_ops arm_smmu_ops;
static struct iommu_dirty_ops arm_smmu_dirty_ops;
+DEFINE_STATIC_KEY_FALSE(arm_smmu_erratum_repeat_tlbi_cfgi_key);
+
enum arm_smmu_msi_index {
EVTQ_MSI_INDEX,
GERROR_MSI_INDEX,
@@ -5303,8 +5305,11 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
if (of_dma_is_coherent(dev->of_node))
smmu->features |= ARM_SMMU_FEAT_COHERENCY;
- if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
+ if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu")) {
tegra_cmdqv_dt_probe(dev->of_node, smmu);
+ smmu->options |= ARM_SMMU_OPT_REPEAT_TLBI_CFGI;
+ static_branch_enable(&arm_smmu_erratum_repeat_tlbi_cfgi_key);
+ }
return ret;
}
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index c909c9a88538..c6ea3b8dc761 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -11,6 +11,7 @@
#include <linux/bitfield.h>
#include <linux/iommu.h>
#include <linux/iommufd.h>
+#include <linux/jump_label.h>
#include <linux/kernel.h>
#include <linux/mmzone.h>
#include <linux/sizes.h>
@@ -928,6 +929,12 @@ struct arm_smmu_device {
#define ARM_SMMU_OPT_MSIPOLL (1 << 2)
#define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3)
#define ARM_SMMU_OPT_TEGRA241_CMDQV (1 << 4)
+/*
+ * Repeat every {CFGI,TLBI};CMD_SYNC command sequence so that the second
+ * issue executes only after the first issue's CMD_SYNC has completed.
+ * Does not apply to ATC_INV.
+ */
+#define ARM_SMMU_OPT_REPEAT_TLBI_CFGI (1 << 5)
u32 options;
struct arm_smmu_cmdq cmdq;
@@ -1212,6 +1219,23 @@ int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
struct arm_smmu_cmd *cmds, int n,
bool sync);
+DECLARE_STATIC_KEY_FALSE(arm_smmu_erratum_repeat_tlbi_cfgi_key);
+
+static inline bool
+arm_smmu_erratum_cmd_needs_repeating(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmd *cmd)
+{
+ u8 opcode;
+
+ if (!static_branch_unlikely(&arm_smmu_erratum_repeat_tlbi_cfgi_key))
+ return false;
+ if (!(smmu->options & ARM_SMMU_OPT_REPEAT_TLBI_CFGI))
+ return false;
+
+ opcode = FIELD_GET(CMDQ_0_OP, cmd->data[0]);
+ return opcode >= CMDQ_OP_CFGI_STE && opcode < CMDQ_OP_ATC_INV;
+}
+
#ifdef CONFIG_ARM_SMMU_V3_SVA
bool arm_smmu_sva_supported(struct arm_smmu_device *smmu);
void arm_smmu_sva_notifier_synchronize(void);
--
2.50.1
^ permalink raw reply related
* [PATCH v6 17/21] RISC-V: perf: Add Qemu virt machine events
From: Atish Patra @ 2026-06-09 6:01 UTC (permalink / raw)
To: James Clark, Rob Herring, Atish Patra, Arnaldo Carvalho de Melo,
Jiri Olsa, Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers
Cc: linux-riscv, linux-kernel, linux-perf-users, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <20260608-counter_delegation-v6-0-285b72ed65a9@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Qemu virt machine supports a very minimal set of legacy perf events.
Add them to the vendor table so that users can use them when
counter delegation is enabled.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/vendorid_list.h | 4 ++++
drivers/perf/riscv_pmu_sbi.c | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/riscv/include/asm/vendorid_list.h b/arch/riscv/include/asm/vendorid_list.h
index 7f5030ee1fcf..603aa2b21c0b 100644
--- a/arch/riscv/include/asm/vendorid_list.h
+++ b/arch/riscv/include/asm/vendorid_list.h
@@ -11,4 +11,8 @@
#define SIFIVE_VENDOR_ID 0x489
#define THEAD_VENDOR_ID 0x5b7
+#define QEMU_VIRT_VENDOR_ID 0x000
+#define QEMU_VIRT_IMPL_ID 0x000
+#define QEMU_VIRT_ARCH_ID 0x000
+
#endif
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 00b84b28117a..74acac54328e 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -26,6 +26,7 @@
#include <asm/sbi.h>
#include <asm/cpufeature.h>
#include <asm/vendor_extensions.h>
+#include <asm/vendorid_list.h>
#include <asm/vendor_extensions/andes.h>
#include <asm/hwcap.h>
#include <asm/csr_ind.h>
@@ -453,7 +454,42 @@ struct riscv_vendor_pmu_events {
.hw_event_map = _hw_event_map, .cache_event_map = _cache_event_map, \
.attrs_events = _attrs },
+/* QEMU virt PMU events */
+static const struct riscv_pmu_event qemu_virt_hw_event_map[PERF_COUNT_HW_MAX] = {
+ PERF_MAP_ALL_UNSUPPORTED,
+ [PERF_COUNT_HW_CPU_CYCLES] = {0x01, 0xFFFFFFF8},
+ [PERF_COUNT_HW_INSTRUCTIONS] = {0x02, 0xFFFFFFF8}
+};
+
+static const struct riscv_pmu_event qemu_virt_cache_event_map[PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+ PERF_CACHE_MAP_ALL_UNSUPPORTED,
+ [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = {0x10019, 0xFFFFFFF8},
+ [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)] = {0x1001B, 0xFFFFFFF8},
+
+ [C(ITLB)][C(OP_READ)][C(RESULT_MISS)] = {0x10021, 0xFFFFFFF8},
+};
+
+RVPMU_EVENT_CMASK_ATTR(cycles, cycles, 0x01, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(instructions, instructions, 0x02, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(dTLB-load-misses, dTLB_load_miss, 0x10019, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(dTLB-store-misses, dTLB_store_miss, 0x1001B, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(iTLB-load-misses, iTLB_load_miss, 0x10021, 0xFFFFFFF8);
+
+static struct attribute *qemu_virt_event_group[] = {
+ RVPMU_EVENT_ATTR_PTR(cycles),
+ RVPMU_EVENT_ATTR_PTR(instructions),
+ RVPMU_EVENT_ATTR_PTR(dTLB_load_miss),
+ RVPMU_EVENT_ATTR_PTR(dTLB_store_miss),
+ RVPMU_EVENT_ATTR_PTR(iTLB_load_miss),
+ NULL,
+};
+
static struct riscv_vendor_pmu_events pmu_vendor_events_table[] = {
+ RISCV_VENDOR_PMU_EVENTS(QEMU_VIRT_VENDOR_ID, QEMU_VIRT_ARCH_ID, QEMU_VIRT_IMPL_ID,
+ qemu_virt_hw_event_map, qemu_virt_cache_event_map,
+ qemu_virt_event_group)
};
static const struct riscv_pmu_event *current_pmu_hw_event_map;
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb
From: Marc Zyngier @ 2026-06-09 7:25 UTC (permalink / raw)
To: Yosry Ahmed
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu
In-Reply-To: <aicqzM4W4NN-GndT@google.com>
On Mon, 08 Jun 2026 21:55:25 +0100,
Yosry Ahmed <yosry@kernel.org> wrote:
>
> On Mon, Jun 08, 2026 at 09:11:08AM +0100, Marc Zyngier wrote:
> > Sashiko reports that there is a race between initialising vncr_tlb
> > and making use of it, as we don't hold the mmu_lock at this point.
> >
> > Additionally, it identifies a memory leak, should userspace repeatedly
> > invokes the KVM_RUN ioctl after a failure of kvm_arch_vcpu_run_pid_change(),
> > as we assign vncr_tlb blindly on first run, irrespective of prior
> > allocations.
> >
> > Slap the two bugs in one go by taking the kvm->mmu_lock on assigning
> > vncr_tlb, preventing the race for good, and by checking that vncr_tlb
> > is indeed NULL prior to allocation.
> >
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/r/20260607180815.85FBC1F00893@smtp.kernel.org
> > ---
> > arch/arm64/kvm/nested.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 690b8e8564166..d11e36b3cfcc2 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> > @@ -1253,8 +1253,14 @@ int kvm_vcpu_allocate_vncr_tlb(struct kvm_vcpu *vcpu)
> > if (!kvm_has_feat(vcpu->kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY))
> > return 0;
> >
> > - vcpu->arch.vncr_tlb = kzalloc_obj(*vcpu->arch.vncr_tlb,
> > - GFP_KERNEL_ACCOUNT);
> > + if (!vcpu->arch.vncr_tlb) {
> > + struct vncr_tlb *vt = kzalloc_obj(*vcpu->arch.vncr_tlb,
> > + GFP_KERNEL_ACCOUNT);
> > +
> > + scoped_guard(write_lock, &vcpu->kvm->mmu_lock)
> > + vcpu->arch.vncr_tlb = vt;
> > + }
>
> (I am not familiar with this code at all, so apologies in advance if I
> am making an idiot out of myself here)
>
> IIUC, the point of holding the lock here is *not* to protect against
> concurrent initialization, as in this case the NULL check needs to be
> done under the lock.
>
> Rather, the goal is to prevent re-ordering of zeroing from kzalloc and
> the assignment to vcpu->arch.vncr_tlb, by depending on the barriers
> provided by the lock. The lock is held by the readers so holding it here
> conviently means we do not need to add any barriers to the readers.
>
> Is my understanding correct?
It is correct.
>
> If yes, I think the code looks confusing, at least to a layman like
> myself. It initially seems like the lock protects against concurrent
> initializations, but then the NULL check is not done again under the
> lock. The goal of the lock is not clear without the original report.
>
> Mayeb it's clearer to explicitly use barriers if the goal is preventing
> reordering?
This would require both the initialisation of vncr_tlb to use a store
release, *and* all the other call sites to use a load acquire.
I really don't think it is worth the churn, nor the (very small)
burden on the readers.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH RESEND v4 0/8] can: flexcan: Add NXP S32N79 SoC support
From: Ciprian Marian Costea @ 2026-06-09 7:19 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol
Cc: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, linux-can, devicetree,
linux-kernel, imx, linux-arm-kernel, NXP S32 Linux Team,
Christophe Lizzi, Alberto Ruiz, Eric Chanudet
In-Reply-To: <CALE0LRuqZhm03QbYg-ZOJcKe0XqCLqVZ8j-4o07QuBF-OqX9BA@mail.gmail.com>
On 6/3/2026 1:28 PM, Enric Balletbo i Serra wrote:
> Hi Ciprian,
>
> Sorry in advance for the noise, for some strange reason I didn't get
> or find the cover until now, so I added my tested patch in 1. Doing it
> now properly.
>
> On Wed, Jun 3, 2026 at 11:44 AM Bough Chen <haibo.chen@oss.nxp.com> wrote:
Hello Marc and Vincent,
Sorry for bothering. Do you expect any more changes to this V4 patchset ?
Best Regards,
Ciprian
>>
>> On Wed, Jun 03, 2026 at 09:13:34AM +0200, Ciprian Costea wrote:
>>> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>>>
>>> This patch series adds FlexCAN support for the NXP S32N79 SoC.
>>>
>>> The S32N79 is an automotive-grade processor from NXP with multiple
>>> FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
>>> other SoCs in the interrupt routing - it uses two separate interrupt
>>> lines:
>>> - one interrupt for mailboxes 0-127
>>> - one interrupt for bus error detection and device state changes
>>>
>>> The CAN controllers are connected through an irqsteer interrupt
>>> controller in the RCU (Resource Control Unit) domain.
>>>
>>> This series:
>>> 1. Splits flexcan_irq() into dedicated handlers for multi-IRQ platforms
>>> 2. Adds dt-bindings documentation for S32N79 FlexCAN
>>> 3. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
>>> configuration
>>> 4. Adds S32N79 device data and compatible string to the driver
>>> 5. Adds FlexCAN device tree nodes for S32N79 SoC
>>> 6. Enables FlexCAN devices on the S32N79-RDB board
>>>
>>> Tested on S32N79-RDB board with CAN and CAN FD communication.
>>
>> Tested on imx95-19x19-evk board with CAN and CAN FD communication. No issue found.
>> This means this patch set do not impact the original platforms.
>>
>> For this patch set, feel free to add tag:
>> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
>>
>> Regards
>> Haibo Chen
>
> Tested-by: Enric Balletbo i Serra <eballetb@.redhat.com>
>
> Tested on the NXP S32G399A-RDB3 with loopback and high-rate traffic.
> No regressions observed:
> CAN frames transmit and receive correctly, with no duplicates.
> Frame reception showed no errors during stress testing.
>
> Regards,
> Enric Balletbo
>
>>>
>>> This is a resend of v4 with no changes.
>>>
>>> v4 -> v3
>>> - flexcan_chip_interrupts_enable(): disable/enable all IRQ lines
>>> (not just dev->irq) during IMASK register writes
>>> - Split rx/tx masks per mailbox IRQ line (struct flexcan_mb_irq) so
>>> each handler on S32G2 only processes its own MB range
>>> - Added received Acked-by tag on DT bindings patch
>>>
>>> v3 -> v2
>>> - Split flexcan_irq() into dedicated handlers (flexcan_irq_mb,
>>> flexcan_irq_boff, flexcan_irq_berr) to fix duplicate event
>>> processing when multiple IRQ lines run concurrently (new patch).
>>> - Added flexcan_irq_esr() handler composing state + berr for S32N79
>>> - Ordered quirks used by s32n devtype data by value.
>>>
>>> v2 -> v1
>>> - Renamed FLEXCAN_QUIRK_NR_IRQ_2 to FLEXCAN_QUIRK_IRQ_BERR to better
>>> describe the actual hardware feature
>>> - Appended new quirk at the end
>>> - Switched from platform_get_irq to platform_get_irq_byname usage
>>> - Updated interrupt description in dt-bindings
>>>
>>> Ciprian Marian Costea (8):
>>> can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
>>> can: flexcan: disable all IRQ lines in
>>> flexcan_chip_interrupts_enable()
>>> can: flexcan: split rx/tx masks per mailbox IRQ line
>>> dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
>>> can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
>>> can: flexcan: add NXP S32N79 SoC support
>>> arm64: dts: s32n79: add FlexCAN nodes
>>> arm64: dts: s32n79: enable FlexCAN devices
>>>
>>> .../bindings/net/can/fsl,flexcan.yaml | 30 ++-
>>> arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 +
>>> arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 ++++
>>> drivers/net/can/flexcan/flexcan-core.c | 249 +++++++++++++++---
>>> drivers/net/can/flexcan/flexcan.h | 12 +-
>>> 5 files changed, 316 insertions(+), 37 deletions(-)
>>>
>>> --
>>> 2.43.0
>>>
>>
>
^ 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