* [PATCH v6 2/7] dt-bindings: clock: qcom: document the Eliza GPU Clock Controller
From: Taniya Das @ 2026-06-09 15:02 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luca Weiss,
Konrad Dybcio, Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Taniya Das, Krzysztof Kozlowski
In-Reply-To: <20260609-b4-eliza_mm_cc_v6-v6-0-17df09e5940c@oss.qualcomm.com>
Add bindings documentation for the Eliza Graphics Clock Controller.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
.../bindings/clock/qcom,sm8450-gpucc.yaml | 3 ++
include/dt-bindings/clock/qcom,eliza-gpucc.h | 51 ++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
index fdbdf605ee695637512ce4f98c9b6fcfacb9154f..734bab762a30800bda94c726f48013679f9ec542 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
@@ -15,6 +15,7 @@ description: |
domains on Qualcomm SoCs.
See also:
+ include/dt-bindings/clock/qcom,eliza-gpucc.h
include/dt-bindings/clock/qcom,glymur-gpucc.h
include/dt-bindings/clock/qcom,kaanapali-gpucc.h
include/dt-bindings/clock/qcom,milos-gpucc.h
@@ -30,6 +31,7 @@ description: |
properties:
compatible:
enum:
+ - qcom,eliza-gpucc
- qcom,glymur-gpucc
- qcom,kaanapali-gpucc
- qcom,milos-gpucc
@@ -71,6 +73,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,eliza-gpucc
- qcom,sm8750-gpucc
then:
required:
diff --git a/include/dt-bindings/clock/qcom,eliza-gpucc.h b/include/dt-bindings/clock/qcom,eliza-gpucc.h
new file mode 100644
index 0000000000000000000000000000000000000000..c3d9b7827325c5b8db696d1d95b4876e17c01c83
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,eliza-gpucc.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GPU_CC_ELIZA_H
+#define _DT_BINDINGS_CLK_QCOM_GPU_CC_ELIZA_H
+
+/* GPU_CC clocks */
+#define GPU_CC_AHB_CLK 0
+#define GPU_CC_CRC_AHB_CLK 1
+#define GPU_CC_CX_ACCU_SHIFT_CLK 2
+#define GPU_CC_CX_FF_CLK 3
+#define GPU_CC_CX_GMU_CLK 4
+#define GPU_CC_CXO_AON_CLK 5
+#define GPU_CC_CXO_CLK 6
+#define GPU_CC_DEMET_CLK 7
+#define GPU_CC_DEMET_DIV_CLK_SRC 8
+#define GPU_CC_FF_CLK_SRC 9
+#define GPU_CC_FREQ_MEASURE_CLK 10
+#define GPU_CC_GMU_CLK_SRC 11
+#define GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK 12
+#define GPU_CC_HUB_AON_CLK 13
+#define GPU_CC_HUB_CLK_SRC 14
+#define GPU_CC_HUB_CX_INT_CLK 15
+#define GPU_CC_MEMNOC_GFX_CLK 16
+#define GPU_CC_MND1X_0_GFX3D_CLK 17
+#define GPU_CC_MND1X_1_GFX3D_CLK 18
+#define GPU_CC_PLL0 19
+#define GPU_CC_PLL1 20
+#define GPU_CC_SLEEP_CLK 21
+#define GPU_CC_XO_CLK_SRC 22
+#define GPU_CC_XO_DIV_CLK_SRC 23
+
+/* GPU_CC power domains */
+#define GPU_CC_CX_GDSC 0
+#define GPU_CC_GX_GDSC 1
+
+/* GPU_CC resets */
+#define GPU_CC_ACD_BCR 0
+#define GPU_CC_CB_BCR 1
+#define GPU_CC_CX_BCR 2
+#define GPU_CC_FAST_HUB_BCR 3
+#define GPU_CC_FF_BCR 4
+#define GPU_CC_GFX3D_AON_BCR 5
+#define GPU_CC_GMU_BCR 6
+#define GPU_CC_GX_BCR 7
+#define GPU_CC_RBCPR_BCR 8
+#define GPU_CC_XO_BCR 9
+
+#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v6 1/7] dt-bindings: clock: qcom: Add video clock controller on Qualcomm Eliza SoC
From: Taniya Das @ 2026-06-09 15:02 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luca Weiss,
Konrad Dybcio, Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Taniya Das
In-Reply-To: <20260609-b4-eliza_mm_cc_v6-v6-0-17df09e5940c@oss.qualcomm.com>
Eliza Video clock controller is on CX and MX rails similar to Milos.
Add compatible string for Eliza video clock controller to the existing
Milos videocc binding and add the dt-bindings header for Eliza.
The video clock controller exposes power domains, so '#power-domain-cells'
must be present in the device node. Add it to the required properties list
to enforce this in binding validation.
There is no ABI breakage and no impact to the existing devices, since the
nodes using this binding already specify the '#power-domain-cells' property
for videocc.
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
.../bindings/clock/qcom,milos-videocc.yaml | 10 ++++--
include/dt-bindings/clock/qcom,eliza-videocc.h | 37 ++++++++++++++++++++++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml
index 14c31efe1308aadbea61eb7be7e56039a923aec5..c0c9e450b8cda53625b6f6bdb1bdfe5f2bfbee25 100644
--- a/Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml
@@ -8,16 +8,21 @@ title: Qualcomm Video Clock & Reset Controller on Milos
maintainers:
- Luca Weiss <luca.weiss@fairphone.com>
+ - Taniya Das <taniya.das@oss.qualcomm.com>
description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Milos.
- See also: include/dt-bindings/clock/qcom,milos-videocc.h
+ See also:
+ include/dt-bindings/clock/qcom,eliza-videocc.h
+ include/dt-bindings/clock/qcom,milos-videocc.h
properties:
compatible:
- const: qcom,milos-videocc
+ enum:
+ - qcom,eliza-videocc
+ - qcom,milos-videocc
clocks:
items:
@@ -29,6 +34,7 @@ properties:
required:
- compatible
- clocks
+ - '#power-domain-cells'
allOf:
- $ref: qcom,gcc.yaml#
diff --git a/include/dt-bindings/clock/qcom,eliza-videocc.h b/include/dt-bindings/clock/qcom,eliza-videocc.h
new file mode 100644
index 0000000000000000000000000000000000000000..1e922250a7fae77f5c996208d50ff372b252aa51
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,eliza-videocc.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_VIDEO_CC_ELIZA_H
+#define _DT_BINDINGS_CLK_QCOM_VIDEO_CC_ELIZA_H
+
+/* VIDEO_CC clocks */
+#define VIDEO_CC_AHB_CLK 0
+#define VIDEO_CC_AHB_CLK_SRC 1
+#define VIDEO_CC_MVS0_CLK 2
+#define VIDEO_CC_MVS0_CLK_SRC 3
+#define VIDEO_CC_MVS0_DIV_CLK_SRC 4
+#define VIDEO_CC_MVS0_SHIFT_CLK 5
+#define VIDEO_CC_MVS0C_CLK 6
+#define VIDEO_CC_MVS0C_DIV2_DIV_CLK_SRC 7
+#define VIDEO_CC_MVS0C_SHIFT_CLK 8
+#define VIDEO_CC_PLL0 9
+#define VIDEO_CC_SLEEP_CLK 10
+#define VIDEO_CC_SLEEP_CLK_SRC 11
+#define VIDEO_CC_XO_CLK 12
+#define VIDEO_CC_XO_CLK_SRC 13
+
+/* VIDEO_CC power domains */
+#define VIDEO_CC_MVS0_GDSC 0
+#define VIDEO_CC_MVS0C_GDSC 1
+
+/* VIDEO_CC resets */
+#define VIDEO_CC_INTERFACE_BCR 0
+#define VIDEO_CC_MVS0_CLK_ARES 1
+#define VIDEO_CC_MVS0_BCR 2
+#define VIDEO_CC_MVS0C_CLK_ARES 3
+#define VIDEO_CC_MVS0C_BCR 4
+#define VIDEO_CC_XO_CLK_ARES 5
+
+#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v6 0/7] Add support for Video, Camera, Graphics clock controllers on Eliza
From: Taniya Das @ 2026-06-09 15:02 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luca Weiss,
Konrad Dybcio, Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Taniya Das, Krzysztof Kozlowski, Konrad Dybcio,
Dmitry Baryshkov
Add driver for Eliza SoC camera, graphics and Video clock controllers.
The camera clock controller supports the cambist clock controller and
the regular camera clock controller.
Eliza camcc and videocc are on CX and MX rails and doesn't have MMCX
and MXC rails dependency. Since CX and MX rails are already ON when APPS
is active, explicit power-domain voting is not required similar to Milos.
Hence extended the Milos camcc & videocc documentation bindings for Eliza.
The patches have been tested on Qualcomm Eliza MTP board.
Changes in v6:
- Update device tree to latest linux-next.
- Update commit text for no ABI breakage for VideoCC and CAMCC
binding [Krzysztof]
- Added the RB-by from patchset v5.
- Link to v5: https://lore.kernel.org/r/20260525-eliza_mm_cc_v2-v5-0-a1d125619a5a@oss.qualcomm.com
Changes in v5:
- Taken care of comments from v3, v4.
- Update milos-videocc and milos-camcc bindings to add '#power-domain-cells'
as required property in bindings.
- Remove duplicate clock 'gpu_cc_gpu_smmu_vote_clk' from driver and
bindings.
- Add '#power-domain-cells' for 'camcc' and 'cambistmclkcc' device node.
- Link to v4: https://lore.kernel.org/r/20260513-eliza_mm_cc_v2-v4-0-e61b5434e8d9@oss.qualcomm.com
Changes in v4:
- Update the clock ordering for camcc and cambistmclkcc in milos.dtsi.
- Link to v3: https://lore.kernel.org/r/20260513-eliza_mm_cc_v2-v3-0-b59c370dc281@oss.qualcomm.com
Changes in v3:
- Dropped new documentation bindings & extended Milos documentation bindings for Eliza videocc & camcc.
- Dropped the defconfig patch and included the drivers as m from Kconfig itself.
- Update the header inclusion in the milos.dtsi.
- Link to v2: https://lore.kernel.org/r/20260409-eliza_mm_cc_v2-v2-0-bc0c6dd77bc5@oss.qualcomm.com
Changes in v2:
- rebased the patches on the latest linux-next.
- Add new bindings for Video and Camcc.
- Remove commented code in GPUCC (limiter code).
- Add device nodes for the corresponding clock controllers.
- Add RB-by tags for VideoCC and CamCC/Cambistmclk from v1.
- Link to v1: https://lore.kernel.org/r/20260317-eliza_mm_clock_controllers_v1-v1-0-4696eeda8cfb@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
Taniya Das (7):
dt-bindings: clock: qcom: Add video clock controller on Qualcomm Eliza SoC
dt-bindings: clock: qcom: document the Eliza GPU Clock Controller
dt-bindings: clock: qcom: Add support for CAMCC for Eliza
clk: qcom: videocc: Add video clock controller driver for Eliza
clk: qcom: gpucc: Add GPU Clock Controller driver for Eliza
clk: qcom: camcc: Add support for camera clock controller for Eliza
arm64: dts: qcom: eliza: Add support for MM clock controllers
.../bindings/clock/qcom,milos-camcc.yaml | 12 +-
.../bindings/clock/qcom,milos-videocc.yaml | 10 +-
.../bindings/clock/qcom,sm8450-gpucc.yaml | 3 +
arch/arm64/boot/dts/qcom/eliza.dtsi | 61 +
drivers/clk/qcom/Kconfig | 31 +
drivers/clk/qcom/Makefile | 3 +
drivers/clk/qcom/cambistmclkcc-eliza.c | 465 ++++
drivers/clk/qcom/camcc-eliza.c | 2803 ++++++++++++++++++++
drivers/clk/qcom/gpucc-eliza.c | 607 +++++
drivers/clk/qcom/videocc-eliza.c | 404 +++
.../dt-bindings/clock/qcom,eliza-cambistmclkcc.h | 32 +
include/dt-bindings/clock/qcom,eliza-camcc.h | 151 ++
include/dt-bindings/clock/qcom,eliza-gpucc.h | 51 +
include/dt-bindings/clock/qcom,eliza-videocc.h | 37 +
14 files changed, 4666 insertions(+), 4 deletions(-)
---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-b4-eliza_mm_cc_v6-64cc35d4a698
Best regards,
--
Taniya Das <taniya.das@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 07/10] ACPI: APEI: introduce GHES helper
From: Ahmed Tiba @ 2026-06-09 14:58 UTC (permalink / raw)
To: Jonathan Cameron
Cc: will, xueshuai, saket.dumbre, mchehab, dave, djbw, bp, tony.luck,
guohanjun, lenb, skhan, vishal.l.verma, rafael, corbet, ira.weiny,
dave.jiang, krzk+dt, robh, catalin.marinas, alison.schofield,
conor+dt, linux-arm-kernel, Michael.Zhao2, linux-doc,
linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree, linux-acpi,
linux-edac, acpica-devel
In-Reply-To: <20260529172113.74c4ca05@jic23-huawei>
On 29/05/2026 17:21, Jonathan Cameron wrote:
> On Fri, 29 May 2026 10:50:47 +0100
> Ahmed Tiba <ahmed.tiba@arm.com> wrote:
>
>> Add a dedicated GHES_CPER_HELPERS Kconfig entry so the shared helper code
>> can be built even when ACPI_APEI_GHES is disabled. Update the build glue
>> and headers to depend on the new symbol.
>>
>> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
> I guess it doesn't matter too much as in practice all exiting CXL systems
> are ACPI based, but is this new symbol sufficient for the
> CONFIG_CXL_RAS dependency?
>
> Rest of this looks fine to me.
CONFIG_CXL_RAS still depends on ACPI_APEI_GHES which in turn selects
GHES_CPER_HELPERS so the existing dependency for CXL RAS is unchanged.
The new symbol is intended as internal build glue under ACPI_APEI_GHES,
rather than a change to the CXL RAS dependency model.
Ahmed
^ permalink raw reply
* Re: [PATCH v5 5/5] arm64: dts: qcom: glymur: Add GPU cooling
From: Konrad Dybcio @ 2026-06-09 14:54 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Sean Paul,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <20260522-glymur-gpu-dt-v5-5-562c406b210c@oss.qualcomm.com>
On 5/22/26 12:12 PM, Akhil P Oommen wrote:
> From: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>
> The GPU does not throttle its speed automatically when it
> reaches high temperatures. Set up GPU cooling by throttling
> the GPU speed when it reaches 95°C.
>
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: power: imx93: Add MIPI PHY power domain
From: Frank Li @ 2026-06-09 14:52 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ulf Hansson,
Peng Fan, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel, linux-pm
In-Reply-To: <20260609-pm_imx93-v1-1-d06c004b0f51@oss.nxp.com>
On Tue, Jun 09, 2026 at 02:26:40PM +0800, Guoniu Zhou wrote:
>
> Add MIPI PHY power domain for shared PHY resources used by both
> MIPI DSI and CSI blocks.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> include/dt-bindings/power/fsl,imx93-power.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/dt-bindings/power/fsl,imx93-power.h b/include/dt-bindings/power/fsl,imx93-power.h
> index 17f9f015bf7d..071221fe5c57 100644
> --- a/include/dt-bindings/power/fsl,imx93-power.h
> +++ b/include/dt-bindings/power/fsl,imx93-power.h
> @@ -11,5 +11,6 @@
> #define IMX93_MEDIABLK_PD_PXP 2
> #define IMX93_MEDIABLK_PD_LCDIF 3
> #define IMX93_MEDIABLK_PD_ISI 4
> +#define IMX93_MEDIABLK_PD_MIPI_PHY 5
>
> #endif
>
> --
> 2.34.1
>
>
^ permalink raw reply
* [PATCH] phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
From: Felix Gu @ 2026-06-09 14:48 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Liu Ying
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, sashiko, Felix Gu
The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get()
with pm_runtime_put(). The asynchronous variant queues a work item
to handle the idle check and potential suspend, which can be cancelled
by a subsequent pm_runtime_disable() call if probe fails after the reset.
Switch to pm_runtime_put_sync() to run the idle check and suspend
synchronously.
Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support")
Reported-by: sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260605-lvds-v2-1-3ce7539d1104%40gmail.com
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
index ece357443521..e2a1645000ae 100644
--- a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
+++ b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
@@ -286,7 +286,7 @@ static int mixel_lvds_phy_reset(struct device *dev)
regmap_write(priv->regmap, PHY_CTRL, CTRL_RESET_VAL);
- pm_runtime_put(dev);
+ pm_runtime_put_sync(dev);
return 0;
}
---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-lvds-phy-6328389a2cf1
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Jason Gunthorpe @ 2026-06-09 14:47 UTC (permalink / raw)
To: Catalin Marinas, Alexey Kardashevskiy
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <aigYbK12D8uKQvJF@arm.com>
On Tue, Jun 09, 2026 at 02:43:08PM +0100, Catalin Marinas wrote:
> On Thu, Jun 04, 2026 at 02:09:39PM +0530, Aneesh Kumar K.V (Arm) wrote:
> > This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
> > dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
> > are handled consistently.
> >
> > Today, the direct DMA path mostly relies on force_dma_unencrypted() for
> > shared/decrypted buffer handling. This series consolidates the
> > force_dma_unencrypted() checks in the top-level functions and ensures
> > that the remaining DMA interfaces use DMA attributes to make the correct
> > decisions.
>
> Please check Sashiko's reports, it has some good points:
>
> https://sashiko.dev/#/patchset/20260604083959.1265923-1-aneesh.kumar@kernel.org
>
> I think the main one is the swiotlb_tbl_map_single() changes which break
> AMD SME host support. There cc_platform_has(CC_ATTR_MEM_ENCRYPT) is true
> but force_dma_unencrypted() is false. Normally you'd not end up on this
> path but you can have swiotlb=force.
IMHO that's an AMD issue, not with the design of this series..
The series is right, a device that is !force_dma_decrypted() must be
considerd to be a trusted device and we must never place any DMA
mappings for a trusted device into shared memory.
That AMD has done somethine insane:
bool force_dma_unencrypted(struct device *dev)
{
/*
* For SEV, all DMA must be to unencrypted addresses.
*/
if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
return true;
/*
* For SME, all DMA must be to unencrypted addresses if the
* device does not support DMA to addresses that include the
* encryption mask.
*/
if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
dev->bus_dma_limit);
if (dma_dev_mask <= dma_enc_mask)
return true;
}
Is an AMD issue. We already have an address mask limit system built
into the DMA API, arch code should not be co-opting the CC mechanism
to create a special pool for address limited devices.
The correct thing is to ensure the DMA API is checking any address
limits on the actual true dma_addr_t, not on an intermediate like a
phys_addr before it is adjusted with any C bit. Then it is a normal
low address swiotlb bounce like any other.
I think we can ignore this Sashiko remark, in real systems the use of
swiotlb for 64 bit devices is very rare. Though it would be good to
remove this code from AMD...
Jason
^ permalink raw reply
* Re: [PATCH v3] clocksource: move NXP timer selection to drivers/clocksource
From: Frank Li @ 2026-06-09 14:45 UTC (permalink / raw)
To: Enric Balletbo i Serra, Thomas Gleixner
Cc: Enric Balletbo i Serra, Russell King, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Lezcano,
Thomas Gleixner, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <CALE0LRtJemHQj7o8iV1GaWJLVfTse6fp-TFvodC=AeWov6s39w@mail.gmail.com>
On Tue, Jun 09, 2026 at 08:57:59AM +0200, Enric Balletbo i Serra wrote:
> Hi all,
>
> On Thu, May 14, 2026 at 1:14 PM Enric Balletbo i Serra
> <eballetbo@kernel.org> wrote:
> >
> > From: Enric Balletbo i Serra <eballetb@redhat.com>
> >
> > The Kconfig logic for selecting the scheduler clocksource on
> > NXP Vybrid (VF610) uses a `choice` block restricted to 32-bit ARM. This
> > prevents 64-bit architectures, such as the NXP S32 family, from enabling
> > the NXP Periodic Interrupt Timer (PIT) driver (CONFIG_NXP_PIT_TIMER).
> >
> > Relocate the NXP clocksource selection from arch/arm/mach-imx/Kconfig to
> > drivers/clocksource/Kconfig. This allows the configuration to be shared
> > across different architectures.
> >
> > Update the selection to include support for ARCH_S32 and add a "None"
> > option restricted to ARCH_S32, since Vybrid lacks the ARM Architected
> > Timer. The Vybrid Global Timer option is restricted to ARCH_MULTI_V7
> > SOC_VF610 platforms to prevent it from being visible on Cortex-M4 builds,
> > which lack the ARM Global Timer hardware.
> >
> > Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support")
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
>
> Now that Frank [1] has created a merge request for Linux 7.1-rc1 and
> the request includes
Thomas:
It touch drivers/clocksource, Is it okay go through Soc tree Or you
can help take care this one?
Frank
>
> arm64: dts: s32g: add PIT support for s32g2 and s32g3
>
> If this patch is ok, would it make sense to pick that patch?
> Otherwise, we won't be able to select the PIT timer for aarch64 only
> builds.
>
> Thanks.,
> Enric
>
> [1] From: Frank.Li@nxp.com
>
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git
> tags/imx-dt64-7.2
>
> for you to fetch changes up to c10cfc952215644956284a42fa7b7860dfbcb5f5:
>
>
>
> > ---
> > Changes in v3:
> > - Restrict VF_TIMER_NONE to ARCH_S32 to prevent selecting it on Vybrid
> > platforms which lack the ARM Architected Timer
> > - Link to v2: https://lore.kernel.org/r/20260513-fix-nxp-timer-v2-1-533b99c57b67@redhat.com
> >
> > Changes in v2:
> > - Fix VF_USE_ARM_GLOBAL_TIMER dependency: use ARCH_MULTI_V7 instead of
> > ARM to prevent the option from being visible on Cortex-M4 builds
> > (Sashiko AI review)
> > - Link to v1: https://lore.kernel.org/r/20260302-fix-nxp-timer-v1-1-af4bc62d4ffa@redhat.com
> > ---
> > arch/arm/mach-imx/Kconfig | 21 ---------------------
> > drivers/clocksource/Kconfig | 31 +++++++++++++++++++++++++++++++
> > 2 files changed, 31 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index 6ea1bd55acf8..a361840d7a04 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -227,27 +227,6 @@ config SOC_VF610
> > help
> > This enables support for Freescale Vybrid VF610 processor.
> >
> > -choice
> > - prompt "Clocksource for scheduler clock"
> > - depends on SOC_VF610
> > - default VF_USE_ARM_GLOBAL_TIMER
> > -
> > - config VF_USE_ARM_GLOBAL_TIMER
> > - bool "Use ARM Global Timer"
> > - depends on ARCH_MULTI_V7
> > - select ARM_GLOBAL_TIMER
> > - select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
> > - help
> > - Use the ARM Global Timer as clocksource
> > -
> > - config VF_USE_PIT_TIMER
> > - bool "Use PIT timer"
> > - select NXP_PIT_TIMER
> > - help
> > - Use SoC Periodic Interrupt Timer (PIT) as clocksource
> > -
> > -endchoice
> > -
> > endif
> >
> > endif
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index d1a33a231a44..d9c76dd443f8 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -793,4 +793,35 @@ config RTK_SYSTIMER
> > this option only when building for a Realtek platform or for compilation
> > testing.
> >
> > +choice
> > + prompt "NXP clocksource for scheduler clock"
> > + depends on SOC_VF610 || ARCH_S32
> > + # Default to Global Timer for Vybrid (32-bit)
> > + default VF_USE_ARM_GLOBAL_TIMER if SOC_VF610
> > + # Default to None for S32 (64-bit)
> > + default VF_TIMER_NONE if ARCH_S32
> > +
> > + config VF_USE_ARM_GLOBAL_TIMER
> > + bool "Use NXP Vybrid Global Timer"
> > + depends on ARCH_MULTI_V7 && SOC_VF610
> > + select ARM_GLOBAL_TIMER
> > + select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
> > + help
> > + Use the NXP Vybrid Global Timer as clocksource.
> > +
> > + config VF_USE_PIT_TIMER
> > + bool "Use NXP PIT timer"
> > + select NXP_PIT_TIMER
> > + help
> > + Use NXP Periodic Interrupt Timer (PIT) as clocksource.
> > +
> > + config VF_TIMER_NONE
> > + bool "None (Use standard Arch Timer)"
> > + depends on ARCH_S32
> > + help
> > + Do not use any specific NXP timer driver. Use the standard
> > + ARM Architected Timer instead.
> > +
> > +endchoice
> > +
> > endmenu
> >
> > ---
> > base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
> > change-id: 20260302-fix-nxp-timer-9cb1fbd7afcd
> >
> > Best regards,
> > --
> > Enric Balletbo i Serra <eballetb@redhat.com>
> >
>
>
^ permalink raw reply
* Re: [PATCH v2 1/6] ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination
From: Sunil V L @ 2026-06-09 14:45 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <aifahCtdj8GpHN/v@lpieralisi>
On Tue, Jun 9, 2026 at 2:49 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> On Mon, Jun 08, 2026 at 09:54:28PM +0530, Sunil V L wrote:
> > Hi Lorenzo,
> >
> > On Wed, Jun 3, 2026 at 1:51 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> > >
[...]
> > Do these fixes need the Fixes tag?
>
> I can add a Fixes: tag but I wanted first some help testing them, it
> is code perusal that got me there.
>
Oh, yes. I tested these changes on the RISC-V virt platform.
So for RISC-V testing,
Tested-by: Sunil V L <sunilvl@oss.qualcomm.com>
> > Otherwise, LGTM.
> > Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
>
> Thanks,
> Lorenzo
^ permalink raw reply
* Re: [PATCH v3 0/3] i2c: xiic: fix SMBus block read and PEC support
From: Michal Simek @ 2026-06-09 14:41 UTC (permalink / raw)
To: Abdurrahman Hussain, Andi Shyti; +Cc: linux-arm-kernel, linux-i2c, linux-kernel
In-Reply-To: <20260513-i2c-xiic-v3-0-ccb3cf70ba03@nexthop.ai>
On 5/13/26 12:09, Abdurrahman Hussain wrote:
> This series fixes three independent bugs in the Xilinx AXI IIC driver
> that together make SMBus block reads with PEC return -EBADMSG or -EIO
> on otherwise clean transfers. They only surface when the client has
> I2C_CLIENT_PEC set; non-PEC block reads happen to mask each issue in
> turn.
>
> The problems were uncovered driving an adm1266 PMBus device behind a
> Xilinx AXI IIC FPGA block and reading its 64-byte blackbox record.
>
> Patch 1 stops xiic_smbus_block_read_setup() from truncating rx_msg->len.
> The i2c core appends a byte to msg->len when PEC is enabled, so
> overwriting the length to "block size + 1" silently drops the PEC byte
> and i2c_smbus_check_pec() then reads the last payload byte as the PEC.
>
> Patch 2 raises the RX_FULL threshold so the interrupt only fires once
> every remaining byte (payload plus optional PEC) is already buffered in
> the FIFO. The previous threshold of rxmsg_len - 2 caused the
> bytes_rem == 1 path in xiic_read_rx() to NACK a byte still on the wire.
> The chunk-vs-defer guard now also accounts for the PEC byte so a
> rxmsg_len == IIC_RX_FIFO_DEPTH PEC-enabled read does not push
> XIIC_RFD_REG_OFFSET past its 4-bit range.
>
> Patch 3 stops the BNB handler from forcing tx_msg->len = 1 to signal
> completion. tx_msg and rx_msg alias the same i2c_msg during a receive,
> so this also clobbered rx_msg->len; and because tx_pos is already at 2
> in the PEC case, the unsigned subtraction in xiic_tx_space() underflowed
> and the STATE_DONE check fell through to STATE_ERROR. Advancing tx_pos
> up to msg->len drives tx_space to zero without touching the length.
>
> All three patches are pure bug fixes; non-PEC behaviour is unchanged.
> Tested on real hardware -- a Xilinx AXI IIC controller talking to an
> adm1266, where 64-byte PEC-checked block reads now complete cleanly.
>
> Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> ---
> Changes in v3 (addresses the sashiko automated review of v2):
> - Patch 1: handle short SMBus block reads where the controller pads
> rx_msg->len up to SMBUS_BLOCK_READ_MIN_LEN for its end-of-message
> workaround. In v2 this branch left the PEC byte at the padded
> offset rather than the actual end-of-payload, so the i2c core's
> PEC validator read past the chip data. Track the on-wire length
> in a new smbus_actual_len field populated in the minlen branch
> of xiic_smbus_block_read_setup(), and trim rx_msg->len back at
> RX_FULL completion before passing the message up. Addresses
> sashiko's v2 note about the pec_len adjustment missing the
> rxmsg_len < 3 padding branch; that branch was indeed the cause
> of pmbus_check_block_register() silently failing on zero-length
> MFR_* fields and skipping debugfs auto-discovery on affected
> hardware.
> - Patch 3: defensively reset smbus_actual_len in the BNB completion
> handler so a subsequent non-SMBus transfer cannot see a stale
> trim value from a completed short block read.
> - Patch 2 is unchanged from v2. sashiko's two other v2 notes were
> investigated and judged not to require code changes: the concern
> about removed padding in the chunked-vs-deferred drain misread
> the patch (the padding survives via the else branch and the new
> PEC-aware guard preserves the original semantics), and the
> flagged unsigned underflow in xiic_tx_space() is unreachable
> because tx_pos is bounded by tx_msg->len at the call site.
> - Link to v2: https://patch.msgid.link/20260511-i2c-xiic-v2-0-c16380cb1594@nexthop.ai
>
> Changes in v2:
> - Patch 2: widen the chunk-vs-defer guard in xiic_smbus_block_read_setup()
> to include pec_len, so a 16-byte PEC-enabled block read routes through
> the chunked drain rather than writing 16 into the 4-bit
> XIIC_RFD_REG_OFFSET register. No tree-level change to patches 1 or 3.
> - Link to v1: https://patch.msgid.link/20260427-i2c-xiic-v1-0-e6207f9aa5ad@nexthop.ai
>
> To: Michal Simek <michal.simek@amd.com>
> To: Andi Shyti <andi.shyti@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-i2c@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
> Abdurrahman Hussain (3):
> i2c: xiic: preserve PEC byte length in SMBus block read setup
> i2c: xiic: defer RX_FULL until all trailing bytes are in FIFO
> i2c: xiic: don't clobber msg->len to signal block-read completion
>
> drivers/i2c/busses/i2c-xiic.c | 67 ++++++++++++++++++++++++++++++++-----------
> 1 file changed, 50 insertions(+), 17 deletions(-)
> ---
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> change-id: 20260427-i2c-xiic-2aeb501ec02a
>
> Best regards,
> --
> Abdurrahman Hussain <abdurrahman@nexthop.ai>
>
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* [RFC PATCH v2 3/3] x86/mm: make pages read-only in the direct map
From: Xueyuan Chen @ 2026-06-09 14:38 UTC (permalink / raw)
To: akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs, liam,
vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh,
Xueyuan Chen
In-Reply-To: <20260609143801.7917-1-xueyuan.chen21@gmail.com>
Implement arch_make_pages_readonly() for x86. Make the corresponding
direct-map range read-only so unexpected writes fault instead of
corrupting shared contents.
Reject highmem pages because they have no permanent direct-map address.
Treat the set_memory_ro() update as best effort. If it fails, leave the
mapping unchanged.
Co-developed-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
---
arch/x86/mm/init.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index fb67217fddcd..ff0a7003eaeb 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -3,6 +3,7 @@
#include <linux/ioport.h>
#include <linux/swap.h>
#include <linux/memblock.h>
+#include <linux/mm.h>
#include <linux/swapfile.h>
#include <linux/swapops.h>
#include <linux/kmemleak.h>
@@ -38,6 +39,14 @@
#include "mm_internal.h"
+bool arch_make_pages_readonly(struct page *page, int nr_pages)
+{
+ if (PageHighMem(page))
+ return false;
+
+ return !set_memory_ro((unsigned long)page_address(page), nr_pages);
+}
+
/*
* Tables translating between page_cache_type_t and pte encoding.
*
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 0/3] i2c: xiic: fix SMBus block read and PEC support
From: Michal Simek @ 2026-06-09 14:39 UTC (permalink / raw)
To: Shubhrajyoti Datta, abdurrahman
Cc: Andi Shyti, linux-arm-kernel, linux-i2c, linux-kernel
In-Reply-To: <CAKfKVtGztJkU_HXZTrb2h3hrTJp0SbRo-sDHM4Sj_1SG8ymOyw@mail.gmail.com>
On 6/9/26 16:26, Shubhrajyoti Datta wrote:
> On Tue, Apr 28, 2026 at 5:48 AM Abdurrahman Hussain via B4 Relay
> <devnull+abdurrahman.nexthop.ai@kernel.org> wrote:
>>
>> This series fixes three independent bugs in the Xilinx AXI IIC driver
>> that together make SMBus block reads with PEC return -EBADMSG or -EIO
>> on otherwise clean transfers. They only surface when the client has
>> I2C_CLIENT_PEC set; non-PEC block reads happen to mask each issue in
>> turn.
>>
>> The problems were uncovered driving an adm1266 PMBus device behind a
>> Xilinx AXI IIC FPGA block and reading its 64-byte blackbox record.
>>
>> Patch 1 stops xiic_smbus_block_read_setup() from truncating rx_msg->len.
>> The i2c core appends a byte to msg->len when PEC is enabled, so
>> overwriting the length to "block size + 1" silently drops the PEC byte
>> and i2c_smbus_check_pec() then reads the last payload byte as the PEC.
>>
>> Patch 2 raises the RX_FULL threshold so the interrupt only fires once
>> every remaining byte (payload plus optional PEC) is already buffered in
>> the FIFO. The previous threshold of rxmsg_len - 2 caused the
>> bytes_rem == 1 path in xiic_read_rx() to NACK a byte still on the wire.
>>
>> Patch 3 stops the BNB handler from forcing tx_msg->len = 1 to signal
>> completion. tx_msg and rx_msg alias the same i2c_msg during a receive,
>> so this also clobbered rx_msg->len; and because tx_pos is already at 2
>> in the PEC case, the unsigned subtraction in xiic_tx_space() underflowed
>> and the STATE_DONE check fell through to STATE_ERROR. Advancing tx_pos
>> up to msg->len drives tx_space to zero without touching the length.
>>
>> All three patches are pure bug fixes; non-PEC behaviour is unchanged.
>> Tested on real hardware -- a Xilinx AXI IIC controller talking to an
>> adm1266, where 64-byte PEC-checked block reads now complete cleanly.
>>
>> Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
>
> LGTM
> Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* [RFC PATCH v2 2/3] arm64/mm: make pages read-only in the linear map
From: Xueyuan Chen @ 2026-06-09 14:38 UTC (permalink / raw)
To: akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs, liam,
vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh,
Xueyuan Chen
In-Reply-To: <20260609143801.7917-1-xueyuan.chen21@gmail.com>
Implement arch_make_pages_readonly() for arm64. Make the corresponding
linear-map range read-only so unexpected writes fault instead of
corrupting shared contents.
Respect can_set_direct_map() before touching the linear map. If arm64
cannot safely update the linear map at page granularity, leave the mapping
unchanged.
Co-developed-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
---
arch/arm64/mm/pageattr.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index ce035e1b4eaf..da97ec7d5195 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -3,6 +3,7 @@
* Copyright (c) 2014, The Linux Foundation. All rights reserved.
*/
#include <linux/kernel.h>
+#include <linux/init.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/mem_encrypt.h>
@@ -147,6 +148,18 @@ static int __change_memory_common(unsigned long start, unsigned long size,
return ret;
}
+bool arch_make_pages_readonly(struct page *page, int nr_pages)
+{
+ unsigned long addr = (unsigned long)page_address(page);
+
+ if (!can_set_direct_map())
+ return false;
+
+ return !__change_memory_common(addr, PAGE_SIZE * nr_pages,
+ __pgprot(PTE_RDONLY),
+ __pgprot(PTE_WRITE));
+}
+
static int change_memory_common(unsigned long addr, int numpages,
pgprot_t set_mask, pgprot_t clear_mask)
{
--
2.47.3
^ permalink raw reply related
* [PATCH v3] soc: samsung: exynos-pmu: fix of_node refcount leak in exynos_get_pmu_regmap()
From: Weigang He @ 2026-06-09 14:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Marek Szyprowski, Tomasz Figa, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Weigang He
exynos_get_pmu_regmap() obtains a device_node via of_find_matching_node()
and passes it to exynos_get_pmu_regmap_by_phandle(np, NULL). With
propname == NULL the callee uses np directly and does not drop a
reference, so the reference taken by of_find_matching_node() is leaked on
every call -- including on each -EPROBE_DEFER retry of the only in-tree
caller, exynos_retention_init() in the Exynos pinctrl driver.
Annotate np with the __free(device_node) cleanup attribute so the
reference is released when the function returns.
Found by static analysis tool CodeQL.
Fixes: 76640b84bd7a ("soc: samsung: pmu: Provide global function to get PMU regmap")
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
---
Changes in v3:
- Only annotate the np declaration with __free(device_node); leave the
rest of the function body unchanged (Krzysztof Kozlowski).
Changes in v2:
- Use the __free(device_node) cleanup attribute instead of an explicit
of_node_put() and the helper refactor (Krzysztof Kozlowski); dropped
the former patch 2/2.
v2: https://lore.kernel.org/linux-samsung-soc/20260609133320.1748882-1-geoffreyhe2@gmail.com/
v1: https://lore.kernel.org/linux-samsung-soc/20260609095224.1706036-2-geoffreyhe2@gmail.com>/
drivers/soc/samsung/exynos-pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index d58376c38179b..f5fcdde9750e2 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -167,8 +167,8 @@ static const struct mfd_cell exynos_pmu_devs[] = {
*/
struct regmap *exynos_get_pmu_regmap(void)
{
- struct device_node *np = of_find_matching_node(NULL,
- exynos_pmu_of_device_ids);
+ struct device_node *np __free(device_node) =
+ of_find_matching_node(NULL, exynos_pmu_of_device_ids);
if (np)
return exynos_get_pmu_regmap_by_phandle(np, NULL);
return ERR_PTR(-ENODEV);
base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
--
2.43.0
^ permalink raw reply related
* [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Xueyuan Chen @ 2026-06-09 14:37 UTC (permalink / raw)
To: akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs, liam,
vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh,
Xueyuan Chen, Dave Hansen
In-Reply-To: <20260609143801.7917-1-xueyuan.chen21@gmail.com>
The huge zero folio is shared globally, and its contents should never
change after initialization. As Jann Horn pointed out[1], the kernel has
had bugs, including security bugs, where read-only pages were later written
to. If the persistent huge zero folio is read-only in the direct map, such
writes fault instead of silently corrupting the shared zero contents.
Add arch_make_pages_readonly() so mm code can request read-only direct-map
protection for a page range. Direct-map protection is
architecture-specific, so the generic weak implementation does nothing.
This was inspired by Jann Horn's read-only zero page work[1] and follow-up
discussion[2] with Yang Shi.
[1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
[2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Suggested-by: David Hildenbrand <david@kernel.org>
Co-developed-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
---
include/linux/mm.h | 2 ++
mm/huge_memory.c | 13 ++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0f2612a70fb1..02d33cf45b01 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2936,6 +2936,8 @@ static inline int arch_make_folio_accessible(struct folio *folio)
}
#endif
+bool arch_make_pages_readonly(struct page *page, int nr_pages);
+
/*
* Some inline functions in vmstat.h depend on page_zone()
*/
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b81d1ecb434b..2e9d01dc1197 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -308,6 +308,11 @@ static unsigned long shrink_huge_zero_folio_scan(struct shrinker *shrink,
return 0;
}
+bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
+{
+ return false;
+}
+
static struct shrinker *huge_zero_folio_shrinker;
#ifdef CONFIG_SYSFS
@@ -982,8 +987,14 @@ static int __init thp_shrinker_init(void)
* that get_huge_zero_folio() will most likely not fail as
* thp_shrinker_init() is invoked early on during boot.
*/
- if (!get_huge_zero_folio())
+ if (!get_huge_zero_folio()) {
pr_warn("Allocating persistent huge zero folio failed\n");
+ return 0;
+ }
+
+ arch_make_pages_readonly(folio_page(huge_zero_folio, 0),
+ HPAGE_PMD_NR);
+
return 0;
}
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2 0/3] make persistent huge zero folio read-only
From: Xueyuan Chen @ 2026-06-09 14:37 UTC (permalink / raw)
To: akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs, liam,
vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh,
Xueyuan Chen
Hi all,
This series makes the persistent huge zero folio read-only in the direct
map where the architecture can support it.
The motivation comes from Jann Horn's read-only zero page work[1] and the
follow-up discussion[2] with Yang Shi. As Jann pointed out, the kernel has
had bugs, including security bugs, where pages taken with read-only
semantics were later written to. For the huge zero folio, making the direct
map read-only turns such writes into faults instead of silently corrupting
shared zero contents.
Patch 1 adds a generic arch_make_pages_readonly() hook and uses it after
the persistent huge zero folio is allocated. Patches 2 and 3 implement the
hook for arm64 and x86.
If the hook is not implemented, or the architecture cannot safely update
the mapping, the existing writable mapping is left in place.
[1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
[2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
RFC v1 -> RFC v2:
- Patch #01: Drop the READONLY_HUGE_ZERO_FOLIO Kconfig option
(per Dave, thanks!).
- Patch #01: Replace the huge-zero-folio-specific hook with a generic
page-range hook (per David, thanks!)
- Patch #02 and #03: Update the arm64 and x86 implementations for the new
hook.
- https://lore.kernel.org/linux-mm/20260527035607.14919-1-xueyuan.chen21@gmail.com/
Xueyuan Chen (3):
mm/huge_memory: make persistent huge zero folio read-only
arm64/mm: make pages read-only in the linear map
x86/mm: make pages read-only in the direct map
arch/arm64/mm/pageattr.c | 13 +++++++++++++
arch/x86/mm/init.c | 9 +++++++++
include/linux/mm.h | 2 ++
mm/huge_memory.c | 13 ++++++++++++-
4 files changed, 36 insertions(+), 1 deletion(-)
--
2.47.3
^ permalink raw reply
* Re: [GIT PULL 4/6] firmware: tegra: Changes for v7.2-rc1
From: Arnd Bergmann @ 2026-06-09 14:38 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Jon Hunter, linux-tegra, linux-arm-kernel, Sasha Levin
In-Reply-To: <20260531060825.1855391-4-thierry.reding@kernel.org>
On Sun, May 31, 2026, at 08:08, Thierry Reding wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
> ----------------------------------------------------------------
> Jon Hunter (2):
> firmware: tegra: bpmp: Propagate debugfs errors
> firmware: tegra: bpmp: Add support for multi-socket platforms
>
> Sasha Levin (1):
> firmware: tegra: Make TEGRA_IVC a hidden Kconfig symbol
I'm merging this, but I would like to point out that the third
patch does not actually solve a real problem and the patch
description is complete nonsense.
Looking through linux-next, I see two more of Sasha's patches
addressing kconfiglint 'K002' warnings. I have not used that
tool and the warning sounds useful in general, but all three
of these patches look like false positives.
Sasha, please try to understand better what the tool is
trying to warn about.
Arnd
^ permalink raw reply
* Re: [PATCH v6 04/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Jason Gunthorpe @ 2026-06-09 14:32 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <20260604083959.1265923-5-aneesh.kumar@kernel.org>
On Thu, Jun 04, 2026 at 02:09:43PM +0530, Aneesh Kumar K.V (Arm) wrote:
> struct page *dma_alloc_from_pool(struct device *dev, size_t size,
> - void **cpu_addr, gfp_t gfp,
> + void **cpu_addr, gfp_t gfp, unsigned long attrs,
> bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t))
> {
> - struct gen_pool *pool = NULL;
> + struct dma_gen_pool *dma_pool = NULL;
> struct page *page;
> bool pool_found = false;
>
> - while ((pool = dma_guess_pool(pool, gfp))) {
> + while ((dma_pool = dma_guess_pool(dma_pool, gfp))) {
> +
> + if (dma_pool->unencrypted != !!(attrs & DMA_ATTR_CC_SHARED))
> + continue;
I don't think you should be overloading DMA_ATTR_CC_SHARED like this.
/*
* DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
* attribute. The direct allocator uses it internally after it has
* decided that the backing pages must be shared/decrypted, so the
* rest of the allocation path can consistently select DMA addresses,
* choose compatible pools and restore encryption on free.
*/
if (attrs & DMA_ATTR_CC_SHARED)
return NULL;
if (force_dma_unencrypted(dev)) {
attrs |= DMA_ATTR_CC_SHARED;
mark_mem_decrypt = true;
}
It is fine to have a bit inside the attrs that is only used by the
internal logic, but it needs to have a clearer name
__DMA_ATTR_REQUIRE_CC_SHARED perhaps.
The sashiko note does look legit though:
if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
!gfpflags_allow_blocking(gfp) && !coherent) {
page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
gfp, attrs, NULL);
if (!page)
return NULL;
I don't see anything doing the force_dma_unencrypted test along this
callchain..
I guess it should be done one step up in dma_alloc_attrs() instead of
in dma_direct_alloc()?
Jason
^ permalink raw reply
* [PATCH v5 8/8] arm64: dts: s32n79: enable FlexCAN devices
From: Ciprian Costea @ 2026-06-09 14:29 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Haibo Chen
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Enable FlexCAN controller instances (can0 and can1) and the required RCU
irqsteer interrupt controller on S32N79-RDB board.
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/s32n79-rdb.dts b/arch/arm64/boot/dts/freescale/s32n79-rdb.dts
index 1feccd61258e..65a595d7535f 100644
--- a/arch/arm64/boot/dts/freescale/s32n79-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/s32n79-rdb.dts
@@ -43,10 +43,22 @@ memory@80000000 {
};
};
+&can0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
&irqsteer_coss {
status = "okay";
};
+&irqsteer_rcu {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 7/8] arm64: dts: s32n79: add FlexCAN nodes
From: Ciprian Costea @ 2026-06-09 14:29 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Andra-Teodora Ilie, Haibo Chen
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
The S32N79 integrates multiple FlexCAN instances connected through the RCU
irqsteer interrupt controller.
Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 +++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/s32n79.dtsi b/arch/arm64/boot/dts/freescale/s32n79.dtsi
index 94ab58783fdc..c1a4fdead91d 100644
--- a/arch/arm64/boot/dts/freescale/s32n79.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32n79.dtsi
@@ -352,6 +352,56 @@ pmu: pmu {
interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
};
+ rcu-bus {
+ compatible = "simple-bus";
+ ranges = <0x54000000 0x0 0x54000000 0x4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ irqsteer_rcu: interrupt-controller@55101000 {
+ compatible = "nxp,s32n79-irqsteer";
+ reg = <0x55101000 0x1000>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 0xf9>;
+ clock-names = "ipg";
+ fsl,channel = <0>;
+ fsl,num-irqs = <512>;
+ status = "disabled";
+ };
+
+ can0: can@55b60000 {
+ compatible = "nxp,s32n79-flexcan";
+ reg = <0x55b60000 0x4000>;
+ interrupt-parent = <&irqsteer_rcu>;
+ interrupts = <0>, <64>;
+ interrupt-names = "mb-0", "berr";
+ clocks = <&clks 0xf9>, <&clks 0xfc>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+ };
+
+ can1: can@55b70000 {
+ compatible = "nxp,s32n79-flexcan";
+ reg = <0x55b70000 0x4000>;
+ interrupt-parent = <&irqsteer_rcu>;
+ interrupts = <1>, <65>;
+ interrupt-names = "mb-0", "berr";
+ clocks = <&clks 0xf9>, <&clks 0xfc>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+ };
+ };
+
timer: timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
--
2.43.0
^ permalink raw reply related
* [PATCH v5 6/8] can: flexcan: add NXP S32N79 SoC support
From: Ciprian Costea @ 2026-06-09 14:29 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Andra-Teodora Ilie, Larisa Grigore,
Haibo Chen
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Add device data and compatible string for NXP S32N79 SoC.
FlexCAN IP integration on S32N79 SoC uses two interrupts:
- one for mailboxes 0-127
- one for signaling bus errors and device state changes
Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
drivers/net/can/flexcan/flexcan-core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index adf3af57fb0a..b43d60fab4b6 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -403,6 +403,15 @@ static const struct flexcan_devtype_data nxp_s32g2_devtype_data = {
FLEXCAN_QUIRK_SECONDARY_MB_IRQ,
};
+static const struct flexcan_devtype_data nxp_s32n_devtype_data = {
+ .quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
+ FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_RX_MAILBOX |
+ FLEXCAN_QUIRK_BROKEN_PERR_STATE | FLEXCAN_QUIRK_SUPPORT_FD |
+ FLEXCAN_QUIRK_SUPPORT_ECC | FLEXCAN_QUIRK_SUPPORT_RX_MAILBOX |
+ FLEXCAN_QUIRK_SUPPORT_RX_MAILBOX_RTR |
+ FLEXCAN_QUIRK_IRQ_BERR,
+};
+
static const struct can_bittiming_const flexcan_bittiming_const = {
.name = DRV_NAME,
.tseg1_min = 4,
@@ -2222,6 +2231,7 @@ static const struct of_device_id flexcan_of_match[] = {
{ .compatible = "fsl,ls1021ar2-flexcan", .data = &fsl_ls1021a_r2_devtype_data, },
{ .compatible = "fsl,lx2160ar1-flexcan", .data = &fsl_lx2160a_r1_devtype_data, },
{ .compatible = "nxp,s32g2-flexcan", .data = &nxp_s32g2_devtype_data, },
+ { .compatible = "nxp,s32n79-flexcan", .data = &nxp_s32n_devtype_data, },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, flexcan_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH v5 5/8] can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
From: Ciprian Costea @ 2026-06-09 14:29 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Larisa Grigore, Haibo Chen
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Introduce FLEXCAN_QUIRK_IRQ_BERR quirk to handle hardware integration
where the FlexCAN module has a dedicated interrupt line for signaling
bus errors and device state changes.
This adds the flexcan_irq_esr() handler which composes
flexcan_do_state() and flexcan_do_berr() to handle platforms where
these events share a single IRQ line.
Also extend flexcan_chip_interrupts_enable() to disable/enable the
new IRQ line during IMASK register writes.
This is required for NXP S32N79 SoC support.
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
drivers/net/can/flexcan/flexcan-core.c | 54 +++++++++++++++++++++-----
drivers/net/can/flexcan/flexcan.h | 2 +
2 files changed, 47 insertions(+), 9 deletions(-)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index 0ed838f0719a..adf3af57fb0a 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -1300,6 +1300,22 @@ static irqreturn_t flexcan_irq_boff(int irq, void *dev_id)
return handled;
}
+/* Combined bus error and state change IRQ handler */
+static irqreturn_t flexcan_irq_esr(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct flexcan_priv *priv = netdev_priv(dev);
+ irqreturn_t handled;
+
+ handled = flexcan_do_state(dev);
+ handled |= flexcan_do_berr(dev);
+
+ if (handled)
+ can_rx_offload_irq_finish(&priv->offload);
+
+ return handled;
+}
+
static void flexcan_set_bittiming_ctrl(const struct net_device *dev)
{
const struct flexcan_priv *priv = netdev_priv(dev);
@@ -1540,10 +1556,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
u64 reg_imask;
disable_irq(dev->irq);
- if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
+ if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
disable_irq(priv->irq_boff);
+ if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
disable_irq(priv->irq_err);
- }
if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
disable_irq(priv->irq_secondary_mb);
@@ -1554,10 +1570,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
enable_irq(dev->irq);
if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
enable_irq(priv->irq_secondary_mb);
- if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
- enable_irq(priv->irq_boff);
+ if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
enable_irq(priv->irq_err);
- }
+ if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
+ enable_irq(priv->irq_boff);
}
static void flexcan_chip_interrupts_disable(const struct net_device *dev)
@@ -1881,7 +1897,8 @@ static int flexcan_open(struct net_device *dev)
can_rx_offload_enable(&priv->offload);
- if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
+ if (priv->devtype_data.quirks &
+ (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
err = request_irq(dev->irq, flexcan_irq_mb,
IRQF_SHARED, dev->name, dev);
else
@@ -1902,6 +1919,13 @@ static int flexcan_open(struct net_device *dev)
goto out_free_irq_boff;
}
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
+ err = request_irq(priv->irq_err,
+ flexcan_irq_esr, IRQF_SHARED, dev->name, dev);
+ if (err)
+ goto out_free_irq_boff;
+ }
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
err = request_irq(priv->irq_secondary_mb,
flexcan_irq_mb, IRQF_SHARED, dev->name, dev);
@@ -1916,7 +1940,8 @@ static int flexcan_open(struct net_device *dev)
return 0;
out_free_irq_err:
- if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
+ if (priv->devtype_data.quirks &
+ (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
free_irq(priv->irq_err, dev);
out_free_irq_boff:
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
@@ -1948,10 +1973,12 @@ static int flexcan_close(struct net_device *dev)
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
free_irq(priv->irq_secondary_mb, dev);
- if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
+ if (priv->devtype_data.quirks &
+ (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
free_irq(priv->irq_err, dev);
+
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
free_irq(priv->irq_boff, dev);
- }
free_irq(dev->irq, dev);
can_rx_offload_disable(&priv->offload);
@@ -2338,12 +2365,21 @@ static int flexcan_probe(struct platform_device *pdev)
if (transceiver)
priv->can.bitrate_max = transceiver->attrs.max_link_rate;
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
+ priv->irq_err = platform_get_irq_byname(pdev, "berr");
+ if (priv->irq_err < 0) {
+ err = priv->irq_err;
+ goto failed_platform_get_irq;
+ }
+ }
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
priv->irq_boff = platform_get_irq(pdev, 1);
if (priv->irq_boff < 0) {
err = priv->irq_boff;
goto failed_platform_get_irq;
}
+
priv->irq_err = platform_get_irq(pdev, 2);
if (priv->irq_err < 0) {
err = priv->irq_err;
diff --git a/drivers/net/can/flexcan/flexcan.h b/drivers/net/can/flexcan/flexcan.h
index 16692a2502eb..bbb1a8dd4777 100644
--- a/drivers/net/can/flexcan/flexcan.h
+++ b/drivers/net/can/flexcan/flexcan.h
@@ -74,6 +74,8 @@
* both need to have an interrupt handler registered.
*/
#define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
+/* Setup dedicated bus error and state change IRQ */
+#define FLEXCAN_QUIRK_IRQ_BERR BIT(19)
struct flexcan_devtype_data {
u32 quirks; /* quirks needed for different IP cores */
--
2.43.0
^ permalink raw reply related
* [PATCH v5 4/8] dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
From: Ciprian Costea @ 2026-06-09 14:29 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Andra-Teodora Ilie, Larisa Grigore,
Conor Dooley, Haibo Chen
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Add NXP S32N79 SoC compatible string and interrupt properties.
On S32N79, FlexCAN IP is integrated with two interrupt lines:
one for the mailbox interrupts (0-127) and one for signaling
bus errors and device state changes.
Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
.../bindings/net/can/fsl,flexcan.yaml | 30 ++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
index f81d56f7c12a..d098a44c2b9c 100644
--- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
+++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
@@ -26,6 +26,7 @@ properties:
- fsl,ls1021ar2-flexcan
- fsl,lx2160ar1-flexcan
- nxp,s32g2-flexcan
+ - nxp,s32n79-flexcan
- items:
- enum:
- fsl,imx53-flexcan
@@ -173,11 +174,38 @@ allOf:
- const: mb-1
required:
- interrupt-names
- else:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,s32n79-flexcan
+ then:
+ properties:
+ interrupts:
+ items:
+ - description: Message Buffer interrupt for mailboxes 0-127
+ - description: Bus Error and Device state change interrupt
+ interrupt-names:
+ items:
+ - const: mb-0
+ - const: berr
+ required:
+ - interrupt-names
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,s32g2-flexcan
+ - nxp,s32n79-flexcan
+ then:
properties:
interrupts:
maxItems: 1
interrupt-names: false
+
- if:
required:
- xceiver-supply
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/8] can: flexcan: split rx/tx masks per mailbox IRQ line
From: Ciprian Costea @ 2026-06-09 14:29 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Haibo Chen
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
On S32G2, which has two mailbox IRQ lines (mb-0 for MBs 0-7, mb-1
for MBs 8-63), both handlers currently process the full rx_mask/tx_mask
range.
Introduce FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK and
FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK to describe the split, and pass
the selected mask to flexcan_do_mb() via a new mb_mask parameter.
In flexcan_irq_mb(), the irq argument selects the correct mask: the
primary MB IRQ uses MB0_MASK and the secondary uses MB1_MASK.
For single-IRQ platforms, mb_mask is ~0ULL with no functional change.
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
drivers/net/can/flexcan/flexcan-core.c | 39 ++++++++++++++++++--------
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index 7dde2e623def..0ed838f0719a 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -182,6 +182,12 @@
#define FLEXCAN_IFLAG_RX_FIFO_WARN BIT(6)
#define FLEXCAN_IFLAG_RX_FIFO_AVAILABLE BIT(5)
+/* On platforms with FLEXCAN_QUIRK_SECONDARY_MB_IRQ, the MB IRQ lines are
+ * split.
+ */
+#define FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK GENMASK_ULL(7, 0)
+#define FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK GENMASK_ULL(63, 8)
+
/* FLEXCAN message buffers */
#define FLEXCAN_MB_CODE_MASK (0xf << 24)
#define FLEXCAN_MB_CODE_RX_BUSY_BIT (0x1 << 24)
@@ -957,14 +963,16 @@ static inline void flexcan_write64(struct flexcan_priv *priv, u64 val, void __io
priv->write(lower_32_bits(val), addr);
}
-static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv)
+static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv,
+ u64 rx_mask)
{
- return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->rx_mask);
+ return flexcan_read64_mask(priv, &priv->regs->iflag1, rx_mask);
}
-static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv)
+static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv,
+ u64 tx_mask)
{
- return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->tx_mask);
+ return flexcan_read64_mask(priv, &priv->regs->iflag1, tx_mask);
}
static inline struct flexcan_priv *rx_offload_to_priv(struct can_rx_offload *offload)
@@ -1071,12 +1079,14 @@ static struct sk_buff *flexcan_mailbox_read(struct can_rx_offload *offload,
}
/* Process mailbox (RX + TX) events */
-static irqreturn_t flexcan_do_mb(struct net_device *dev)
+static irqreturn_t flexcan_do_mb(struct net_device *dev, u64 mb_mask)
{
struct net_device_stats *stats = &dev->stats;
struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->regs;
irqreturn_t handled = IRQ_NONE;
+ u64 rx_mask = priv->rx_mask & mb_mask;
+ u64 tx_mask = priv->tx_mask & mb_mask;
u64 reg_iflag_tx;
/* reception interrupt */
@@ -1084,7 +1094,8 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
u64 reg_iflag_rx;
int ret;
- while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv))) {
+ while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv,
+ rx_mask))) {
handled = IRQ_HANDLED;
ret = can_rx_offload_irq_offload_timestamp(&priv->offload,
reg_iflag_rx);
@@ -1110,10 +1121,10 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
}
}
- reg_iflag_tx = flexcan_read_reg_iflag_tx(priv);
+ reg_iflag_tx = flexcan_read_reg_iflag_tx(priv, tx_mask);
/* transmission complete interrupt */
- if (reg_iflag_tx & priv->tx_mask) {
+ if (reg_iflag_tx & tx_mask) {
u32 reg_ctrl = priv->read(&priv->tx_mb->can_ctrl);
handled = IRQ_HANDLED;
@@ -1125,7 +1136,7 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
/* after sending a RTR frame MB is in RX mode */
priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
&priv->tx_mb->can_ctrl);
- flexcan_write64(priv, priv->tx_mask, ®s->iflag1);
+ flexcan_write64(priv, tx_mask, ®s->iflag1);
netif_wake_queue(dev);
}
@@ -1228,7 +1239,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
struct flexcan_priv *priv = netdev_priv(dev);
irqreturn_t handled;
- handled = flexcan_do_mb(dev);
+ handled = flexcan_do_mb(dev, ~0ULL);
handled |= flexcan_do_state(dev);
handled |= flexcan_do_berr(dev);
@@ -1244,8 +1255,14 @@ static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
struct net_device *dev = dev_id;
struct flexcan_priv *priv = netdev_priv(dev);
irqreturn_t handled;
+ u64 mb_mask = ~0ULL;
+
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
+ mb_mask = (irq == priv->irq_secondary_mb) ?
+ FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK :
+ FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK;
- handled = flexcan_do_mb(dev);
+ handled = flexcan_do_mb(dev, mb_mask);
if (handled)
can_rx_offload_irq_finish(&priv->offload);
--
2.43.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