* [PATCH v2 1/5] soc: mediatek: Use pkt_write function pointer for subsys ID compatibility
From: Jason-JH Lin @ 2026-03-25 3:57 UTC (permalink / raw)
To: Jassi Brar, Chun-Kuang Hu, AngeloGioacchino Del Regno,
Nicolas Dufresne, Mauro Carvalho Chehab
Cc: Matthias Brugger, Jason-JH Lin, Nancy Lin, Singo Chang,
Paul-PL Chen, Moudy Ho, Xiandong Wang, Sirius Wang, Fei Shao,
Chen-yu Tsai, Project_Global_Chrome_Upstream_Group, linux-kernel,
dri-devel, linux-mediatek, linux-arm-kernel, linux-media
In-Reply-To: <20260325035836.2110757-1-jason-jh.lin@mediatek.com>
Switch to pkt_write and reg_write_mask function pointers for register
access, enabling compatibility with platforms regardless of subsys ID
support.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/soc/mediatek/mtk-mmsys.c | 8 +++++---
drivers/soc/mediatek/mtk-mutex.c | 5 +++--
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index bb4639ca0b8c..2f3e0778bb17 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -167,9 +167,11 @@ static void mtk_mmsys_update_bits(struct mtk_mmsys *mmsys, u32 offset, u32 mask,
u32 tmp;
if (mmsys->cmdq_base.size && cmdq_pkt) {
- ret = cmdq_pkt_write_mask(cmdq_pkt, mmsys->cmdq_base.subsys,
- mmsys->cmdq_base.offset + offset, val,
- mask);
+ ret = mmsys->cmdq_base.pkt_write_mask(cmdq_pkt,
+ mmsys->cmdq_base.subsys,
+ mmsys->cmdq_base.pa_base,
+ mmsys->cmdq_base.offset + offset,
+ val, mask);
if (ret)
pr_debug("CMDQ unavailable: using CPU write\n");
else
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 38179e8cd98f..eb5d381ff5af 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -990,6 +990,7 @@ int mtk_mutex_enable_by_cmdq(struct mtk_mutex *mutex, void *pkt)
struct mtk_mutex_ctx *mtx = container_of(mutex, struct mtk_mutex_ctx,
mutex[mutex->id]);
struct cmdq_pkt *cmdq_pkt = (struct cmdq_pkt *)pkt;
+ dma_addr_t en_addr = mtx->addr + DISP_REG_MUTEX_EN(mutex->id);
WARN_ON(&mtx->mutex[mutex->id] != mutex);
@@ -998,8 +999,8 @@ int mtk_mutex_enable_by_cmdq(struct mtk_mutex *mutex, void *pkt)
return -ENODEV;
}
- cmdq_pkt_write(cmdq_pkt, mtx->cmdq_reg.subsys,
- mtx->addr + DISP_REG_MUTEX_EN(mutex->id), 1);
+ mtx->cmdq_reg.pkt_write(cmdq_pkt, mtx->cmdq_reg.subsys, en_addr, en_addr, 1);
+
return 0;
}
EXPORT_SYMBOL_GPL(mtk_mutex_enable_by_cmdq);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/5] Migrate soc, drm-mediatek, mdp3 to new CMDQ APIs (series 2/4)
From: Jason-JH Lin @ 2026-03-25 3:57 UTC (permalink / raw)
To: Jassi Brar, Chun-Kuang Hu, AngeloGioacchino Del Regno,
Nicolas Dufresne, Mauro Carvalho Chehab
Cc: Matthias Brugger, Jason-JH Lin, Nancy Lin, Singo Chang,
Paul-PL Chen, Moudy Ho, Xiandong Wang, Sirius Wang, Fei Shao,
Chen-yu Tsai, Project_Global_Chrome_Upstream_Group, linux-kernel,
dri-devel, linux-mediatek, linux-arm-kernel, linux-media
This series migrates the MediaTek SoC, DRM, and MDP3 drivers to the new
CMDQ APIs introduced for MT8196.
Series application order:
1. [Series V2 2/4] Migrate subsystems to new CMDQ APIs (this series)
2. [Series V2 3/4] Remove shift_pa from CMDQ jump functions
3. [Series V2 4/4] Remove deprecated CMDQ APIs
Please apply this series after the MT8196 GCE support series,
and before the following series.
---
Change in v2:
1. Rebase on linux-next
2. Fix build error of -EINVAL in patch2.
---
Jason-JH Lin (5):
soc: mediatek: Use pkt_write function pointer for subsys ID
compatibility
soc: mediatek: mtk-cmdq: Add cmdq_pkt_jump_rel_temp() for removing
shift_pa
drm/mediatek:Use reg_write function pointer for subsys ID
compatibility
media: platform: mtk-mdp3: Refactor CMDQ writes for CMDQ API change
media: platform: mtk-mdp3: Change cmdq_pkt_jump_rel() to
cmdq_pkt_jump_rel_temp()
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 12 +++++-----
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c | 6 ++---
.../platform/mediatek/mdp3/mtk-mdp3-comp.h | 6 ++---
drivers/soc/mediatek/mtk-mmsys.c | 8 ++++---
drivers/soc/mediatek/mtk-mutex.c | 5 ++--
include/linux/soc/mediatek/mtk-cmdq.h | 24 +++++++++++++++++++
6 files changed, 44 insertions(+), 17 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 7/9] drm/bridge: analogix_dp: Rename and simplify is_rockchip()
From: Damon Ding @ 2026-03-25 3:58 UTC (permalink / raw)
To: Luca Ceresoli, hjc, heiko, andy.yan, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
andrzej.hajda, neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
alchark, cristian.ciocaltea, sebastian.reichel, kever.yang,
heiko.stuebner, tomeu, amadeus, michael.riesch, didi.debian,
dmitry.baryshkov, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <42c0641f-2e37-4ca4-a1ae-e8fde24c8460@rock-chips.com>
Hi Luca,
On 3/24/2026 2:12 PM, Damon Ding wrote:
> On 3/24/2026 12:14 AM, Luca Ceresoli wrote:
>> On Thu Mar 19, 2026 at 11:40 AM CET, Damon Ding wrote:
>>> Rename is_rockchip() to analogix_dp_is_rockchip() for naming consistency
>>> and readability, and simplify the code with switch.
>>>
>>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>> Suggested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>
>> The patch content is OK:
>> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>
>> However this won't apply without [0], correct?
>>
>> So, worth mentioning in the cover letter that this series depends on the
>> [0] series.
>>
>> [0] https://lore.kernel.org/all/20260319071452.1961274-8-
>> damon.ding@rock-chips.com/
>>
>
> Yes, I will add it in v3.
>
BTW: Could you also help review the following two patches [0][1] when
you get a chance? Your review would be much appreciated.
[0]
https://lore.kernel.org/all/20251110085823.1197472-1-damon.ding@rock-chips.com/
[1]
https://lore.kernel.org/all/20251111022103.1350183-1-damon.ding@rock-chips.com/
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v3] PCI: dw-rockchip: Enable async probe by default
From: Dmitry Torokhov @ 2026-03-25 3:44 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Robin Murphy, Manivannan Sadhasivam, Manivannan Sadhasivam,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, Heiko Stuebner, Niklas Cassel, Shawn Lin,
Hans Zhang, Nicolas Frattaroli, Wilfred Mallawa, linux-pci,
linux-arm-kernel, linux-rockchip, linux-kernel, Anand Moon,
Grimmauld, Greg Kroah-Hartman, Rafael J. Wysocki, driver-core,
Lukas Wunner
In-Reply-To: <DGZJBMG2Y738.2MU5LXVGEDD47@kernel.org>
On Wed, Mar 11, 2026 at 01:43:15AM +0100, Danilo Krummrich wrote:
> (Cc: Dmitry)
>
> On Tue Mar 10, 2026 at 10:03 PM CET, Robin Murphy wrote:
> > [ +driver-core maintainers - async probe question below ]
>
> <snip>
>
> > I'm guessing it maybe wasn't anticipated to have bus drivers calling
> > device_initial_probe() from within async in the first place?
>
> I think this is not limited to device_initial_probe(), device_attach() or even
> device_add() would have the same problem. I.e. the driver core simply does not
> consider whether it is already running in an async handler when it is requested
> to run probe() synchronously.
>
> A simple workaround to this would be to check whether current_is_async() and in
> case it returns true just defer probing in an PROBE_FORCE_SYNCHRONOUS case. This
> would at least be compatible with the guarantees given by
> PROBE_FORCE_SYNCHRONOUS, but it doesn't sound quite right to me -- guess I have
> to think about it a bit more.
>
> In any case, given that this is not a supported case, this commit seems to be
> wrong and should probably be reverted.
>
> I think a quick workaround in the driver core as mentioned above is not a good
> idea, instead this should be properly thought through.
I think the bigger question is why PCI does something different from
every other bus? Why doesn't it rely on driver core to bind devices to
driver?
>
> > It may not strictly be the fault of this patch - clearly 91703041697c
> > ("PCI: Allow built-in drivers to use async initial probing") is
> > implicated in this too - but the fact is that it *has* exposed a bug
> > that needs fixing one way or another, it can't just be left hanging and
> > impacting end users.
>
> At a side note, I think device_initial_probe() was not meant to be exposed
> outside of the driver core in the first place. As the name suggests it is only
> meant to be called on the initial probe() path (i.e. the initial probe() path of
> the driver core). It seems to me that it ended up in include/linux/device.h
> instead of drivers/base/base.h by accident.
Yes, at the time when async probing was introduced driver core was the
sole caller of device_initial_probe().
>
> The original commit - commit 765230b5f084 ("driver-core: add asynchronous
> probing support for drivers") - introducing the feature even mentions "manual
> binding is still synchronous" in its commit message and I think this has never
> been changed.
Yes, when users "echo" into bind/unbind sysfs attributes they expect
error codes to indicate whether operation has succeeded or not. That is
why even if driver is marked as "prefer asynchronous" in this particular
case the kernel still binds driver synchronously.
>
> So, it seems commit 91703041697c ("PCI: Allow built-in drivers to use async
> initial probing") relies on something that might work by accident. :)
>
> So, I wouldn't rule out any unexpected side effects entirely.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-evk: Specify ADV7535 register addresses
From: Liu Ying @ 2026-03-25 3:24 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <acKi8-prXpnl1Js9@lizhi-Precision-Tower-5810>
Hi Frank,
On Tue, Mar 24, 2026 at 10:42:59AM -0400, Frank Li wrote:
> On Tue, Mar 24, 2026 at 01:52:03PM +0800, Liu Ying wrote:
>> MIPI DSI to HDMI bridge ADV7535 CEC default register address is 0x3c
>> on an I2C bus. And, OV5640 camera uses the same address on the same
>> I2C bus. To resolve this conflict, use 0x3b as ADV7535 CEC register
>> address by specifying all ADV7535 register addresses.
>
> Does cec start address programmable? generally i2c address is fixed or
> controller by some gpio.
Yes, it's programmable. Quote adi,adv7533.yaml:
reg:
description: |
I2C slave addresses.
The ADV7533/35 internal registers are split into four pages
exposed through different I2C addresses, creating four register
maps. Each map has it own I2C address and acts as a standard slave
device on the I2C bus. The main address is mandatory, others are
optional and revert to defaults if not specified.
minItems: 1
maxItems: 4
reg-names:
description:
Names of maps with programmable addresses. It can contain any map
needing a non-default address.
minItems: 1
items:
- const: main
- const: edid
- const: cec
- const: packet
>
> Frank
>>
>> Fixes: 6f6c18cba16f ("arm64: dts: imx8mp-evk: add camera ov5640 and related nodes")
>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>> ---
>> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
>> index aedc09937716..d0a2bd975a18 100644
>> --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
>> +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
>> @@ -602,7 +602,8 @@ ov5640_mipi_0_ep: endpoint {
>>
>> hdmi@3d {
>> compatible = "adi,adv7535";
>> - reg = <0x3d>;
>> + reg = <0x3d>, <0x3f>, <0x3b>, <0x38>;
>> + reg-names = "main", "edid", "cec", "packet";
>> interrupt-parent = <&gpio1>;
>> interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
>> adi,dsi-lanes = <4>;
>>
>> ---
>> base-commit: 09c0f7f1bcdbc3c37a5a760cbec76bf18f278406
>> change-id: 20260324-imx8mp-evk-adv7535-cec-reg-addr-2de67760133a
>>
>> Best regards,
>> --
>> Liu Ying <victor.liu@nxp.com>
>>
--
Regards,
Liu Ying
^ permalink raw reply
* [PATCH 1/2] dt-bindings: spi: Fix clock-names definition
From: Meiker Gao @ 2026-03-25 3:18 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Bayi Cheng, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, linux-spi, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Meiker Gao
In-Reply-To: <20260325031900.2099969-1-ot_meiker.gao@mediatek.com>
Update the device tree binding for the Mediatek.
Signed-off-by: Meiker Gao <ot_meiker.gao@mediatek.com>
---
.../devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
index a453996c13f2..0255e19efc8d 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
@@ -56,14 +56,17 @@ properties:
design, so this is optional.
- description: clock used for controller axi slave bus.
this depends on hardware design, so it is optional.
+ - description: clock used for controller axi_f, axi_h, and
+ axi_p to support the new platform.
clock-names:
minItems: 2
items:
- const: spi
- const: sf
- - const: axi
- - const: axi_s
+ - const: axi_f
+ - const: axi_h
+ - const: axi_p
required:
- compatible
--
2.45.2
^ permalink raw reply related
* [PATCH 0/2] Add nor dt-bindings new clock and modify driver.
From: Meiker Gao @ 2026-03-25 3:18 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Bayi Cheng, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, linux-spi, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Meiker Gao
Changs in v2:
-Modify bindings/spi/mediatek,spi-mtk-nor.yaml,add new clock.
-Modify nor driver new clock gate need to be added.
Meiker Gao (2):
dt-bindings: spi: Fix clock-names definition
spi: spi-mtk-nor: add new clock support
.../bindings/spi/mediatek,spi-mtk-nor.yaml | 7 ++-
drivers/spi/spi-mtk-nor.c | 48 ++++++++++++-------
2 files changed, 37 insertions(+), 18 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH 2/2] spi: spi-mtk-nor: add new clock support
From: Meiker Gao @ 2026-03-25 3:18 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Bayi Cheng, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, linux-spi, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Meiker Gao
In-Reply-To: <20260325031900.2099969-1-ot_meiker.gao@mediatek.com>
one more clock gate need to be added.
Signed-off-by: Meiker Gao <ot_meiker.gao@mediatek.com>
---
drivers/spi/spi-mtk-nor.c | 48 ++++++++++++++++++++++++++-------------
1 file changed, 32 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index 1e5ec0840174..e34b0414372f 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -118,8 +118,9 @@ struct mtk_nor {
dma_addr_t buffer_dma;
struct clk *spi_clk;
struct clk *ctlr_clk;
- struct clk *axi_clk;
- struct clk *axi_s_clk;
+ struct clk *axi_f_clk;
+ struct clk *axi_h_clk;
+ struct clk *axi_p_clk;
unsigned int spi_freq;
bool wbuf_en;
bool has_irq;
@@ -705,8 +706,9 @@ static void mtk_nor_disable_clk(struct mtk_nor *sp)
{
clk_disable_unprepare(sp->spi_clk);
clk_disable_unprepare(sp->ctlr_clk);
- clk_disable_unprepare(sp->axi_clk);
- clk_disable_unprepare(sp->axi_s_clk);
+ clk_disable_unprepare(sp->axi_f_clk);
+ clk_disable_unprepare(sp->axi_h_clk);
+ clk_disable_unprepare(sp->axi_p_clk);
}
static int mtk_nor_enable_clk(struct mtk_nor *sp)
@@ -723,18 +725,27 @@ static int mtk_nor_enable_clk(struct mtk_nor *sp)
return ret;
}
- ret = clk_prepare_enable(sp->axi_clk);
+ ret = clk_prepare_enable(sp->axi_f_clk);
if (ret) {
clk_disable_unprepare(sp->spi_clk);
clk_disable_unprepare(sp->ctlr_clk);
return ret;
}
- ret = clk_prepare_enable(sp->axi_s_clk);
+ ret = clk_prepare_enable(sp->axi_h_clk);
if (ret) {
clk_disable_unprepare(sp->spi_clk);
clk_disable_unprepare(sp->ctlr_clk);
- clk_disable_unprepare(sp->axi_clk);
+ clk_disable_unprepare(sp->axi_f_clk);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(sp->axi_p_clk);
+ if (ret) {
+ clk_disable_unprepare(sp->spi_clk);
+ clk_disable_unprepare(sp->ctlr_clk);
+ clk_disable_unprepare(sp->axi_f_clk);
+ clk_disable_unprepare(sp->axi_h_clk);
return ret;
}
@@ -813,7 +824,7 @@ static int mtk_nor_probe(struct platform_device *pdev)
struct mtk_nor *sp;
struct mtk_nor_caps *caps;
void __iomem *base;
- struct clk *spi_clk, *ctlr_clk, *axi_clk, *axi_s_clk;
+ struct clk *spi_clk, *ctlr_clk, *axi_f_clk, *axi_h_clk, *axi_p_clk;
int ret, irq;
base = devm_platform_ioremap_resource(pdev, 0);
@@ -828,13 +839,17 @@ static int mtk_nor_probe(struct platform_device *pdev)
if (IS_ERR(ctlr_clk))
return PTR_ERR(ctlr_clk);
- axi_clk = devm_clk_get_optional(&pdev->dev, "axi");
- if (IS_ERR(axi_clk))
- return PTR_ERR(axi_clk);
+ axi_f_clk = devm_clk_get_optional(&pdev->dev, "axi_f");
+ if (IS_ERR(axi_f_clk))
+ return PTR_ERR(axi_f_clk);
+
+ axi_h_clk = devm_clk_get_optional(&pdev->dev, "axi_h");
+ if (IS_ERR(axi_h_clk))
+ return PTR_ERR(axi_h_clk);
- axi_s_clk = devm_clk_get_optional(&pdev->dev, "axi_s");
- if (IS_ERR(axi_s_clk))
- return PTR_ERR(axi_s_clk);
+ axi_p_clk = devm_clk_get_optional(&pdev->dev, "axi_p");
+ if (IS_ERR(axi_p_clk))
+ return PTR_ERR(axi_p_clk);
caps = (struct mtk_nor_caps *)of_device_get_match_data(&pdev->dev);
@@ -869,8 +884,9 @@ static int mtk_nor_probe(struct platform_device *pdev)
sp->dev = &pdev->dev;
sp->spi_clk = spi_clk;
sp->ctlr_clk = ctlr_clk;
- sp->axi_clk = axi_clk;
- sp->axi_s_clk = axi_s_clk;
+ sp->axi_f_clk = axi_f_clk;
+ sp->axi_h_clk = axi_h_clk;
+ sp->axi_p_clk = axi_p_clk;
sp->caps = caps;
sp->high_dma = caps->dma_bits > 32;
sp->buffer = dmam_alloc_coherent(&pdev->dev,
--
2.45.2
^ permalink raw reply related
* [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-25 3:10 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Jie Gan
Save the trace ID in drvdata during TPDM enablement and expose it
to userspace to support trace data parsing.
The TPDM device’s trace ID corresponds to the trace ID allocated
to the connected TPDA device.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v3:
1. Only allow user to read the traceid while the TPDM device is enabled.
- Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-for-tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
Changes in V2:
1. Use sysfs_emit instead of sprintf.
Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
---
drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++++++++++++++-
drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
index da77bdaad0a4..c8339b973bfc 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.c
+++ b/drivers/hwtracing/coresight/coresight-tpdm.c
@@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata *drvdata)
static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
enum cs_mode mode,
- __maybe_unused struct coresight_path *path)
+ struct coresight_path *path)
{
struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
}
__tpdm_enable(drvdata);
+ drvdata->traceid = path->trace_id;
drvdata->enable = true;
spin_unlock(&drvdata->spinlock);
@@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
.attrs = tpdm_attrs,
};
+static ssize_t traceid_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ unsigned long val;
+ struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+ if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
+ return -EINVAL;
+
+ val = drvdata->traceid;
+ return sysfs_emit(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(traceid);
+
+static struct attribute *traceid_attrs[] = {
+ &dev_attr_traceid.attr,
+ NULL,
+};
+
+static struct attribute_group traceid_attr_grp = {
+ .attrs = traceid_attrs,
+};
+
static ssize_t dsb_mode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -1367,6 +1391,12 @@ static const struct attribute_group *tpdm_attr_grps[] = {
&tpdm_cmb_patt_grp,
&tpdm_cmb_msr_grp,
&tpdm_mcmb_attr_grp,
+ &traceid_attr_grp,
+ NULL,
+};
+
+static const struct attribute_group *static_tpdm_attr_grps[] = {
+ &traceid_attr_grp,
NULL,
};
@@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev, struct resource *res)
desc.access = CSDEV_ACCESS_IOMEM(base);
if (res)
desc.groups = tpdm_attr_grps;
+ else
+ desc.groups = static_tpdm_attr_grps;
drvdata->csdev = coresight_register(&desc);
if (IS_ERR(drvdata->csdev))
return PTR_ERR(drvdata->csdev);
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
index 2867f3ab8186..11da64e1ade8 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.h
+++ b/drivers/hwtracing/coresight/coresight-tpdm.h
@@ -300,6 +300,7 @@ struct cmb_dataset {
* @cmb Specifics associated to TPDM CMB.
* @dsb_msr_num Number of MSR supported by DSB TPDM
* @cmb_msr_num Number of MSR supported by CMB TPDM
+ * @traceid Trace ID of the path.
*/
struct tpdm_drvdata {
@@ -313,6 +314,7 @@ struct tpdm_drvdata {
struct cmb_dataset *cmb;
u32 dsb_msr_num;
u32 cmb_msr_num;
+ u8 traceid;
};
/* Enumerate members of various datasets */
---
base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v5 08/10] clk: realtek: Add support for MMC-tuned PLL clocks
From: Stephen Boyd @ 2026-03-25 1:54 UTC (permalink / raw)
To: Yu-Chun Lin, afaerber, conor+dt, cylee12, jyanchou, krzk+dt,
mturquette, p.zabel, robh
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260324025332.3416977-9-eleanor.lin@realtek.com>
Quoting Yu-Chun Lin (2026-03-23 19:53:29)
> diff --git a/drivers/clk/realtek/clk-pll-mmc.c b/drivers/clk/realtek/clk-pll-mmc.c
> new file mode 100644
> index 000000000000..017663738c1f
> --- /dev/null
> +++ b/drivers/clk/realtek/clk-pll-mmc.c
> @@ -0,0 +1,399 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2021 Realtek Semiconductor Corporation
> + * Author: Cheng-Yu Lee <cylee12@realtek.com>
> + */
> +
> +#include "clk-pll.h"
Include what you use in this C file, not just this header file. That
makes it simpler to see what is used without following include trails.
> +
> +#define PLL_EMMC1_OFFSET 0x0
> +#define PLL_EMMC2_OFFSET 0x4
> +#define PLL_EMMC3_OFFSET 0x8
> +#define PLL_EMMC4_OFFSET 0xc
> +#define PLL_SSC_DIG_EMMC1_OFFSET 0x0
> +#define PLL_SSC_DIG_EMMC3_OFFSET 0xc
> +#define PLL_SSC_DIG_EMMC4_OFFSET 0x10
> +
> +#define PLL_MMC_SSC_DIV_N_VAL 0x1b
> +
> +#define PLL_PHRT0_MASK BIT(1)
> +#define PLL_PHSEL_MASK GENMASK(4, 0)
> +#define PLL_SSCPLL_RS_MASK GENMASK(12, 10)
> +#define PLL_SSCPLL_ICP_MASK GENMASK(9, 5)
> +#define PLL_SSC_DIV_EXT_F_MASK GENMASK(25, 13)
> +#define PLL_PI_IBSELH_MASK GENMASK(28, 27)
> +#define PLL_SSC_DIV_N_MASK GENMASK(23, 16)
> +#define PLL_NCODE_SSC_EMMC_MASK GENMASK(20, 13)
> +#define PLL_FCODE_SSC_EMMC_MASK GENMASK(12, 0)
> +#define PLL_GRAN_EST_EM_MC_MASK GENMASK(20, 0)
> +#define PLL_EN_SSC_EMMC_MASK BIT(0)
> +#define PLL_FLAG_INITAL_EMMC_MASK BIT(1)
[...]
> diff --git a/drivers/clk/realtek/clk-pll.h b/drivers/clk/realtek/clk-pll.h
> index 2d27a44a270c..9cf219871218 100644
> --- a/drivers/clk/realtek/clk-pll.h
> +++ b/drivers/clk/realtek/clk-pll.h
> @@ -44,4 +44,25 @@ static inline struct clk_pll *to_clk_pll(struct clk_hw *hw)
> extern const struct clk_ops rtk_clk_pll_ops;
> extern const struct clk_ops rtk_clk_pll_ro_ops;
>
> +struct clk_pll_mmc {
> + struct clk_regmap clkr;
> + int pll_ofs;
> + int ssc_dig_ofs;
These offsets should be unsigned?
> + struct clk_hw phase0_hw;
> + struct clk_hw phase1_hw;
> + u32 set_rate_val_53_97_set_ipc: 1;
bool? Doubt we care about this unless we're packing structs (which we
shouldn't be).
> +};
> +
> +#define __clk_pll_mmc_hw(_ptr) __clk_regmap_hw(&(_ptr)->clkr)
> +
> +static inline struct clk_pll_mmc *to_clk_pll_mmc(struct clk_hw *hw)
> +{
> + struct clk_regmap *clkr = to_clk_regmap(hw);
> +
> + return container_of(clkr, struct clk_pll_mmc, clkr);
> +}
^ permalink raw reply
* Re: [PATCH v7 1/5] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
From: Stephen Boyd @ 2026-03-25 2:06 UTC (permalink / raw)
To: Chema Casanova, Dave Stevenson, Florian Fainelli,
Iago Toral Quiroga, Maxime Ripard, Maíra Canal, Melissa Wen,
Michael Turquette, Nicolas Saenz Julienne, Philipp Zabel,
Stefan Wahren
Cc: linux-clk, dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev,
Maíra Canal
In-Reply-To: <20260312-v3d-power-management-v7-1-9f006a1d4c55@igalia.com>
Quoting Maíra Canal (2026-03-12 14:34:23)
> On current firmware versions, RPI_FIRMWARE_SET_CLOCK_STATE doesn't
> actually power off the clock. To achieve meaningful power savings, the
> clock rate must be set to the minimum before disabling. This might be
> fixed in future firmware releases.
>
> Rather than pushing rate management to clock consumers, handle it
> directly in the clock framework's prepare/unprepare callbacks. In
> unprepare, set the rate to the minimum before disabling the clock.
> In prepare, for clocks marked with `maximize` (currently v3d),
> restore the rate to the maximum after enabling.
>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v5 01/10] dt-bindings: clock: Add Realtek RTD1625 Clock & Reset Controller
From: Stephen Boyd @ 2026-03-25 1:59 UTC (permalink / raw)
To: Yu-Chun Lin, afaerber, conor+dt, cylee12, jyanchou, krzk+dt,
mturquette, p.zabel, robh
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260324025332.3416977-2-eleanor.lin@realtek.com>
Quoting Yu-Chun Lin (2026-03-23 19:53:22)
> diff --git a/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> new file mode 100644
> index 000000000000..6fabc2da3975
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/realtek,rtd1625-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek RTD1625 Clock & Reset Controller
> +
> +maintainers:
> + - Yu-Chun Lin <eleanor.lin@realtek.com>
> +
> +description: |
> + The Realtek RTD1625 Clock Controller manages and distributes clock
> + signals to various controllers and implements a Reset Controller for the
> + SoC peripherals.
> +
> + Clocks and resets are referenced by unique identifiers, which are defined as
> + preprocessor macros in include/dt-bindings/clock/realtek,rtd1625-clk.h and
> + include/dt-bindings/reset/realtek,rtd1625.h.
> +
> +properties:
> + compatible:
> + enum:
> + - realtek,rtd1625-crt-clk
> + - realtek,rtd1625-iso-clk
> + - realtek,rtd1625-iso-s-clk
> +
> + reg:
> + maxItems: 1
> +
> + "#clock-cells":
> + const: 1
> +
> + "#reset-cells":
> + const: 1
Are there any input clks for the clk tree?
> +
> +required:
> + - compatible
> + - reg
> + - "#clock-cells"
> + - "#reset-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + clock-controller@98000000 {
> + compatible = "realtek,rtd1625-crt-clk";
> + reg = <98000000 0x1000>;
Should be 0x98000000 to match the unit address.
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
^ permalink raw reply
* Re: [PATCH v3 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Xianwei Zhao @ 2026-03-25 2:48 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260323-add-emmc-t7-vim4-v3-1-5159d90a984c@aliel.fr>
Hi Ronald,
On 2026/3/23 17:55, Ronald Claveau wrote:
> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
> to configure pin muxing at runtime.
>
> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
> - SD card: data, clock, command and clock gate pins
> - SDIO: data, clock, command and clock gate pins
>
> Signed-off-by: Ronald Claveau<linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 6510068bcff92..ac8de8e9b8010 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -250,6 +250,104 @@ gpio: bank@4000 {
> #gpio-cells = <2>;
> gpio-ranges = <&periphs_pinctrl 0 0 157>;
> };
> +
> + emmc_ctrl_pins: emmc-ctrl {
> + mux-0 {
> + groups = "emmc_cmd";
> + function = "emmc";
> + bias-pull-up;
> + };
> +
> + mux-1 {
> + groups = "emmc_clk";
> + function = "emmc";
> + bias-disable;
> + };
> + };
> +
> + emmc_data_4b_pins: emmc-data-4b {
> + mux-0 {
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_data_8b_pins: emmc-data-8b {
> + mux-0 {
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3",
> + "emmc_nand_d4",
> + "emmc_nand_d5",
> + "emmc_nand_d6",
> + "emmc_nand_d7";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_ds_pins: emmc-ds {
> + mux {
> + groups = "emmc_nand_ds";
> + function = "emmc";
> + bias-pull-down;
> + };
> + };
> +
> + emmc_clk_gate_pins: emmc_clk_gate {
Node names should use hyphens ('-') instead of underscores ('_'),
consistent with the following nodes.
> + mux {
> + groups = "GPIOB_8";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdcard_pins: sdcard {
> + mux {
> + groups = "sdcard_d0",
> + "sdcard_d1",
> + "sdcard_d2",
> + "sdcard_d3",
> + "sdcard_clk",
> + "sdcard_cmd";
> + function = "sdcard";
> + bias-pull-up;
> + };
> + };
> +
> + sdcard_clk_gate_pins: sdcard_clk_gate {
> + mux {
> + groups = "GPIOC_4";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdio_pins: sdio {
> + mux-0 {
> + groups = "sdio_d0",
> + "sdio_d1",
> + "sdio_d2",
> + "sdio_d3",
> + "sdio_clk",
> + "sdio_cmd";
> + function = "sdio";
> + bias-pull-up;
> + };
> + };
> +
> + sdio_clk_gate_pins: sdio_clk_gate {
> + mux {
> + groups = "GPIOX_4";
> + function = "gpio_periphs";
> + bias-pull-up;
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
^ permalink raw reply
* Re: [PATCH v3 2/9] dt-bindings: mmc: amlogic: Add compatible for T7 mmc
From: Xianwei Zhao @ 2026-03-25 2:38 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260323-add-emmc-t7-vim4-v3-2-5159d90a984c@aliel.fr>
Hi Ronald,
On 2026/3/23 17:55, Ronald Claveau wrote:
> Add amlogic,t7-mmc compatible string, falling back to amlogic,meson-axg-mmc
> as the T7 MMC controller is compatible with the AXG implementation.
>
> Signed-off-by: Ronald Claveau<linux-kernel-dev@aliel.fr>
> ---
> Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml | 5
> ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
> b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
> index 57646575a13f8..40dccf9715781 100644
> --- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
> @@ -19,7 +19,10 @@ allOf:
> properties:
> compatible:
> oneOf:
> - - const: amlogic,meson-axg-mmc
> + - items:
> + - enum:
> + - amlogic,t7-mmc
> + - const: amlogic,meson-axg-mmc
It seems that break API here.
One item should be added here instead of being replaced.
> - items:
> - const: amlogic,meson-gx-mmc
> - const: amlogic,meson-gxbb-mmc
>
> --
> 2.49.0
^ permalink raw reply
* Re: [PATCH] ACPI: APEI: Handle repeated SEA error interrupts storm scenarios
From: Shuai Xue @ 2026-03-25 2:12 UTC (permalink / raw)
To: hejunhao, Rafael J. Wysocki, Luck, Tony
Cc: bp, guohanjun, mchehab, jarkko, yazen.ghannam, jane.chu, lenb,
Jonathan.Cameron, linux-acpi, linux-arm-kernel, linux-kernel,
linux-edac, shiju.jose, tanxiaofei, Linuxarm
In-Reply-To: <ea31b6d3-fae5-ab5c-c10c-ed6901296498@h-partners.com>
Hi, junhao
On 3/24/26 6:04 PM, hejunhao wrote:
> Hi shuai xue,
>
>
> On 2026/3/3 22:42, Shuai Xue wrote:
>> Hi, junhao,
>>
>> On 2/27/26 8:12 PM, hejunhao wrote:
>>>
>>>
>>> On 2025/11/4 9:32, Shuai Xue wrote:
>>>>
>>>>
>>>> 在 2025/11/4 00:19, Rafael J. Wysocki 写道:
>>>>> On Thu, Oct 30, 2025 at 8:13 AM Junhao He <hejunhao3@h-partners.com> wrote:
>>>>>>
>>>>>> The do_sea() function defaults to using firmware-first mode, if supported.
>>>>>> It invoke acpi/apei/ghes ghes_notify_sea() to report and handling the SEA
>>>>>> error, The GHES uses a buffer to cache the most recent 4 kinds of SEA
>>>>>> errors. If the same kind SEA error continues to occur, GHES will skip to
>>>>>> reporting this SEA error and will not add it to the "ghes_estatus_llist"
>>>>>> list until the cache times out after 10 seconds, at which point the SEA
>>>>>> error will be reprocessed.
>>>>>>
>>>>>> The GHES invoke ghes_proc_in_irq() to handle the SEA error, which
>>>>>> ultimately executes memory_failure() to process the page with hardware
>>>>>> memory corruption. If the same SEA error appears multiple times
>>>>>> consecutively, it indicates that the previous handling was incomplete or
>>>>>> unable to resolve the fault. In such cases, it is more appropriate to
>>>>>> return a failure when encountering the same error again, and then proceed
>>>>>> to arm64_do_kernel_sea for further processing.
>>
>> There is no such function in the arm64 tree. If apei_claim_sea() returns
>
> Sorry for the mistake in the commit message. The function arm64_do_kernel_sea() should
> be arm64_notify_die().
>
>> an error, the actual fallback path in do_sea() is arm64_notify_die(),
>> which sends SIGBUS?
>>
>
> If apei_claim_sea() returns an error, arm64_notify_die() will call arm64_force_sig_fault(inf->sig /* SIGBUS */, , , ),
> followed by force_sig_fault(SIGBUS, , ) to force the process to receive the SIGBUS signal.
So the process is expected to killed by SIGBUS?
>
>>>>>>
>>>>>> When hardware memory corruption occurs, a memory error interrupt is
>>>>>> triggered. If the kernel accesses this erroneous data, it will trigger
>>>>>> the SEA error exception handler. All such handlers will call
>>>>>> memory_failure() to handle the faulty page.
>>>>>>
>>>>>> If a memory error interrupt occurs first, followed by an SEA error
>>>>>> interrupt, the faulty page is first marked as poisoned by the memory error
>>>>>> interrupt process, and then the SEA error interrupt handling process will
>>>>>> send a SIGBUS signal to the process accessing the poisoned page.
>>>>>>
>>>>>> However, if the SEA interrupt is reported first, the following exceptional
>>>>>> scenario occurs:
>>>>>>
>>>>>> When a user process directly requests and accesses a page with hardware
>>>>>> memory corruption via mmap (such as with devmem), the page containing this
>>>>>> address may still be in a free buddy state in the kernel. At this point,
>>>>>> the page is marked as "poisoned" during the SEA claim memory_failure().
>>>>>> However, since the process does not request the page through the kernel's
>>>>>> MMU, the kernel cannot send SIGBUS signal to the processes. And the memory
>>>>>> error interrupt handling process not support send SIGBUS signal. As a
>>>>>> result, these processes continues to access the faulty page, causing
>>>>>> repeated entries into the SEA exception handler. At this time, it lead to
>>>>>> an SEA error interrupt storm.
>>
>> In such case, the user process which accessing the poisoned page will be killed
>> by memory_fauilre?
>>
>> // memory_failure():
>>
>> if (TestSetPageHWPoison(p)) {
>> res = -EHWPOISON;
>> if (flags & MF_ACTION_REQUIRED)
>> res = kill_accessing_process(current, pfn, flags);
>> if (flags & MF_COUNT_INCREASED)
>> put_page(p);
>> action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
>> goto unlock_mutex;
>> }
>>
>> I think this problem has already been fixed by commit 2e6053fea379 ("mm/memory-failure:
>> fix infinite UCE for VM_PFNMAP pfn").
>>
>> The root cause is that walk_page_range() skips VM_PFNMAP vmas by default when
>> no .test_walk callback is set, so kill_accessing_process() returns 0 for a
>> devmem-style mapping (remap_pfn_range, VM_PFNMAP), making the caller believe
>> the UCE was handled properly while the process was never actually killed.
>>
>> Did you try the lastest kernel version?
>>
>
> I retested this issue on the kernel v7.0.0-rc4 with the following debug patch and was still able to reproduce it.
>
>
> @@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>
> /* This error has been reported before, don't process it again. */
> - if (ghes_estatus_cached(estatus))
> + if (ghes_estatus_cached(estatus)) {
> + pr_info("This error has been reported before, don't process it again.\n");
> goto no_work;
> + }
>
> the test log Only some debug logs are retained here.
>
> [2026/3/24 14:51:58.199] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
> [2026/3/24 14:51:58.369] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
> [2026/3/24 14:51:58.458] [ 130.558038][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
> [2026/3/24 14:51:58.459] [ 130.572517][ C40] {1}[Hardware Error]: event severity: recoverable
> [2026/3/24 14:51:58.459] [ 130.578861][ C40] {1}[Hardware Error]: Error 0, type: recoverable
> [2026/3/24 14:51:58.459] [ 130.585203][ C40] {1}[Hardware Error]: section_type: ARM processor error
> [2026/3/24 14:51:58.459] [ 130.592238][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
> [2026/3/24 14:51:58.459] [ 130.598492][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
> [2026/3/24 14:51:58.459] [ 130.607871][ C40] {1}[Hardware Error]: error affinity level: 0
> [2026/3/24 14:51:58.459] [ 130.614038][ C40] {1}[Hardware Error]: running state: 0x1
> [2026/3/24 14:51:58.459] [ 130.619770][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
> [2026/3/24 14:51:58.459] [ 130.627673][ C40] {1}[Hardware Error]: Error info structure 0:
> [2026/3/24 14:51:58.459] [ 130.633839][ C40] {1}[Hardware Error]: num errors: 1
> [2026/3/24 14:51:58.459] [ 130.639137][ C40] {1}[Hardware Error]: error_type: 0, cache error
> [2026/3/24 14:51:58.459] [ 130.645652][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
> [2026/3/24 14:51:58.459] [ 130.652514][ C40] {1}[Hardware Error]: cache level: 1
> [2026/3/24 14:51:58.551] [ 130.658073][ C40] {1}[Hardware Error]: the error has not been corrected
> [2026/3/24 14:51:58.551] [ 130.665194][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
> [2026/3/24 14:51:58.551] [ 130.673097][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
> [2026/3/24 14:51:58.551] [ 130.680744][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 14:51:58.551] [ 130.690471][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 14:51:58.552] [ 130.700198][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 14:51:58.552] [ 130.710083][ T9767] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
> [2026/3/24 14:51:58.638] [ 130.790952][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:51:58.903] [ 131.046994][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:51:58.991] [ 131.132360][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:51:59.969] [ 132.071431][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:00.860] [ 133.010255][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:01.927] [ 134.034746][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:02.906] [ 135.058973][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:03.971] [ 136.083213][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:04.860] [ 137.021956][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:06.018] [ 138.131460][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:06.905] [ 139.070280][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:07.886] [ 140.009147][ C40] This error has been reported before, don't process it again.
> [2026/3/24 14:52:08.596] [ 140.777368][ C40] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
> [2026/3/24 14:52:08.683] [ 140.791921][ C40] {2}[Hardware Error]: event severity: recoverable
> [2026/3/24 14:52:08.683] [ 140.798263][ C40] {2}[Hardware Error]: Error 0, type: recoverable
> [2026/3/24 14:52:08.683] [ 140.804606][ C40] {2}[Hardware Error]: section_type: ARM processor error
> [2026/3/24 14:52:08.683] [ 140.811641][ C40] {2}[Hardware Error]: MIDR: 0x0000000000000000
> [2026/3/24 14:52:08.684] [ 140.817895][ C40] {2}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
> [2026/3/24 14:52:08.684] [ 140.827274][ C40] {2}[Hardware Error]: error affinity level: 0
> [2026/3/24 14:52:08.684] [ 140.833440][ C40] {2}[Hardware Error]: running state: 0x1
> [2026/3/24 14:52:08.684] [ 140.839173][ C40] {2}[Hardware Error]: Power State Coordination Interface state: 0
> [2026/3/24 14:52:08.684] [ 140.847076][ C40] {2}[Hardware Error]: Error info structure 0:
> [2026/3/24 14:52:08.684] [ 140.853241][ C40] {2}[Hardware Error]: num errors: 1
> [2026/3/24 14:52:08.684] [ 140.858540][ C40] {2}[Hardware Error]: error_type: 0, cache error
> [2026/3/24 14:52:08.684] [ 140.865055][ C40] {2}[Hardware Error]: error_info: 0x0000000020400014
> [2026/3/24 14:52:08.684] [ 140.871917][ C40] {2}[Hardware Error]: cache level: 1
> [2026/3/24 14:52:08.684] [ 140.877475][ C40] {2}[Hardware Error]: the error has not been corrected
> [2026/3/24 14:52:08.764] [ 140.884596][ C40] {2}[Hardware Error]: physical fault address: 0x0000001351811800
> [2026/3/24 14:52:08.764] [ 140.892499][ C40] {2}[Hardware Error]: Vendor specific error info has 48 bytes:
> [2026/3/24 14:52:08.766] [ 140.900145][ C40] {2}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 14:52:08.767] [ 140.909872][ C40] {2}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 14:52:08.767] [ 140.919598][ C40] {2}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 14:52:08.768] [ 140.929346][ T9767] Memory failure: 0x1351811: already hardware poisoned
> [2026/3/24 14:52:08.768] [ 140.936072][ T9767] Memory failure: 0x1351811: Sending SIGBUS to busybox:9767 due to hardware memory corruption
Did you cut off some logs here?
The error log also indicates that the SIGBUS is delivered as expected.
>
>
> Apply the patch:
>
> @@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>
> /* This error has been reported before, don't process it again. */
> - if (ghes_estatus_cached(estatus))
> + if (ghes_estatus_cached(estatus)) {
> + pr_info("This error has been reported before, don't process it again.\n");
> + rc = -ECANCELED;
> goto no_work;
> + }
>
> [2026/3/24 16:45:40.084] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
> [2026/3/24 16:45:40.272] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
> [2026/3/24 16:45:40.362] [ 112.279324][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
> [2026/3/24 16:45:40.362] [ 112.293797][ C40] {1}[Hardware Error]: event severity: recoverable
> [2026/3/24 16:45:40.362] [ 112.300139][ C40] {1}[Hardware Error]: Error 0, type: recoverable
> [2026/3/24 16:45:40.363] [ 112.306481][ C40] {1}[Hardware Error]: section_type: ARM processor error
> [2026/3/24 16:45:40.363] [ 112.313516][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
> [2026/3/24 16:45:40.363] [ 112.319771][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
> [2026/3/24 16:45:40.363] [ 112.329151][ C40] {1}[Hardware Error]: error affinity level: 0
> [2026/3/24 16:45:40.363] [ 112.335317][ C40] {1}[Hardware Error]: running state: 0x1
> [2026/3/24 16:45:40.363] [ 112.341049][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
> [2026/3/24 16:45:40.363] [ 112.348953][ C40] {1}[Hardware Error]: Error info structure 0:
> [2026/3/24 16:45:40.363] [ 112.355119][ C40] {1}[Hardware Error]: num errors: 1
> [2026/3/24 16:45:40.363] [ 112.360418][ C40] {1}[Hardware Error]: error_type: 0, cache error
> [2026/3/24 16:45:40.363] [ 112.366932][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
> [2026/3/24 16:45:40.363] [ 112.373795][ C40] {1}[Hardware Error]: cache level: 1
> [2026/3/24 16:45:40.453] [ 112.379354][ C40] {1}[Hardware Error]: the error has not been corrected
> [2026/3/24 16:45:40.453] [ 112.386475][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
> [2026/3/24 16:45:40.453] [ 112.394378][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
> [2026/3/24 16:45:40.453] [ 112.402027][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 16:45:40.453] [ 112.411754][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 16:45:40.453] [ 112.421480][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
> [2026/3/24 16:45:40.453] [ 112.431639][ T9769] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
> [2026/3/24 16:45:40.531] [ 112.512520][ C40] This error has been reported before, don't process it again.
> [2026/3/24 16:45:40.757] Bus error (core dumped)
>
Thanks.
Shuai
^ permalink raw reply
* RE: [PATCH V2] arm64: dts: imx8mp-evk: Disable PCIe bus in the default dts
From: Sherry Sun @ 2026-03-25 2:08 UTC (permalink / raw)
To: Frank Li
Cc: s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Hongxing Zhu, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <acKj4sWpzyAYExrK@lizhi-Precision-Tower-5810>
> On Tue, Mar 24, 2026 at 02:45:39AM +0000, Sherry Sun wrote:
> > > > Subject: Re: [PATCH V2] arm64: dts: imx8mp-evk: Disable PCIe bus
> > > > in the default dts
> > > >
> > > > On Fri, Mar 20, 2026 at 05:03:53PM +0800, Sherry Sun wrote:
> > > > > Disable the PCIe bus in the default device tree to avoid shared
> > > > > regulator conflicts between SDIO and PCIe buses. The
> > > > > non-deterministic probe order between these two buses can break
> > > > > the PCIe initialization sequence, causing PCIe devices to fail
> > > > > detection
> > > intermittently.
> > > > >
> > > > > On i.MX8MP EVK board, the M.2 connector is physically wired to
> > > > > both
> > > > > USDHC1 and PCIe0, however the out-of-box module is SDIO IW612
> > > > > WiFi, so enable the SDIO WiFi in the default imx8mp-evk.dts, and
> > > > > provide a separate device tree overlay (imx8mp-evk-pcie.dtso) to
> > > > > enable the PCIe bus when needed.
> > > > >
> > > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > > ---
> > > > > Chanegs in V2:
> > > > > 1. Improve the commit message to clarify SDIO WiFi is the
> > > > > out-of-box
> > > > module on
> > > > > i.MX8MP EVK board.
> > > > > ---
> > > > > arch/arm64/boot/dts/freescale/Makefile | 4 +++-
> > > > > .../boot/dts/freescale/imx8mp-evk-pcie.dtso | 19
> > > +++++++++++++++++++
> > > > > arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
> > > > > 3 files changed, 24 insertions(+), 3 deletions(-) create mode
> > > > > 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > > > > b/arch/arm64/boot/dts/freescale/Makefile
> > > > > index 780682258e71..107ca270ef32 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/Makefile
> > > > > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > > > > @@ -333,12 +333,14 @@ imx8mp-evk-lvds0-imx-lvds-hdmi-dtbs +=
> > > > > imx8mp-evk.dtb imx8mp-evk-lvds0-imx-lvds-
> > > > > imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0-dtbs += imx8mp-evk.dtb
> > > > > imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtbo
> > > > > imx8mp-evk-lvds1-imx-lvds-hdmi-dtbs += imx8mp-evk.dtb
> > > > > imx8mp-evk-lvds1-imx-lvds-hdmi.dtbo
> > > > > imx8mp-evk-mx8-dlvds-lcd1-dtbs += imx8mp-evk.dtb
> > > > > imx8mp-evk-mx8-dlvds-lcd1.dtbo -imx8mp-evk-pcie-ep-dtbs +=
> > > > > imx8mp-evk.dtb imx-pcie0-ep.dtbo
> > > > > +imx8mp-evk-pcie-dtbs := imx8mp-evk.dtb imx8mp-evk-pcie.dtbo
> > > > > +imx8mp-evk-pcie-ep-dtbs += imx8mp-evk-pcie.dtb
> > > > > +imx-pcie0-ep.dtbo
> > > > > dtb-$(CONFIG_ARCH_MXC) +=
> > > > > imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds0-imx-lvds-hdmi.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) +=
> > > > > imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds1-imx-lvds-hdmi.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-mx8-dlvds-lcd1.dtb
> > > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-pcie.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-pcie-ep.dtb
> > > > >
> > > > > imx8mp-tqma8mpql-mba8mpxl-lvds-tm070jvhg33-dtbs +=
> > > > > imx8mp-tqma8mpql-mba8mpxl.dtb
> > > > > imx8mp-tqma8mpql-mba8mpxl-lvds-tm070jvhg33.dtbo
> > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > > > b/arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > > > new file mode 100644
> > > > > index 000000000000..4f6546d442bf
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-pcie.dtso
> > > > > @@ -0,0 +1,19 @@
> > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > +/*
> > > > > + * Copyright 2026 NXP
> > > > > + */
> > > > > +
> > > > > +/dts-v1/;
> > > > > +/plugin/;
> > > > > +
> > > > > +&pcie_phy {
> > > > > + status = "okay";
> > > > > +};
> > > > > +
> > > > > +&pcie0 {
> > > > > + status = "okay";
> > > > > +};
> > > > > +
> > > > > +&usdhc1 {
> > > > > + status = "disabled";
> > > > > +};
> > > >
> > > > Please use one overlay for both imx95 and imx8mp to enable pcie0
> > > > and disable usdhc1.
> > >
> > > Hi Frank,
> > >
> > > imx8mp has a specific pcie_phy, I disabled it in the default
> > > imx8mp-evk.dts
>
> Suppose, you needn't disable phy.
>
> > > and enabled it in xxx-pcie.dtso, if we use one overlay for both
> > > imx95 and imx8mp, is it acceptable that we need to keep the 8mp
> > > pcie_phy enabled even in non-PCIe usage scenarios?
> > >
> >
> > In addition, another difference between imx8mp and imx95 is that imx8mp
> connects usdhc1 to the M.2 connector, while imx95 connects usdhc3 to the
> M.2 connector. The usdhc interfaces are different, so we cannot use the same
> DTSO file.
>
> you use addtional label.
>
> for example
>
> m2_usdhc: &usdhc1 {
> ...
> };
>
> in overlay file
>
> &m2_usdhc {
> status = "disabled";
> }
>
Ok, thanks for the suggestion, will try this in next version.
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Miguel Ojeda @ 2026-03-25 1:58 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Miguel Ojeda, Robin Murphy, Danilo Krummrich, Abdiel Janulgue,
Daniel Almeida, Andreas Hindborg, Christoph Hellwig, iommu,
driver-core, acourbot, akpm, aliceryhl, anton.ivanov, bjorn3_gh,
boqun.feng, david, gary, johannes, justinstitt, linux-arm-kernel,
linux-kbuild, linux-kernel, linux-mm, linux-um, linux, llvm,
lossin, mark.rutland, mmaurer, morbo, nathan,
nick.desaulniers+lkml, nicolas.schier, nsc, peterz, richard,
rust-for-linux, tmgross, urezki, will
In-Reply-To: <1c4e429b-f30c-42a9-8de1-71cb2cbbc114@samsung.com>
On Mon, Mar 23, 2026 at 9:49 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> Yes please, this looks like an oversight.
https://lore.kernel.org/rust-for-linux/20260325015548.70912-1-ojeda@kernel.org/
I hope that helps!
Cheers,
Miguel
^ permalink raw reply
* RE: [PATCH v2 net-next 08/14] net: enetc: add multiple command BD rings support
From: Wei Fang @ 2026-03-25 1:56 UTC (permalink / raw)
To: Simon Horman
Cc: Frank Li, devicetree@vger.kernel.org, andrew+netdev@lunn.ch,
conor+dt@kernel.org, Vladimir Oltean,
linux-arm-kernel@lists.infradead.org, kuba@kernel.org,
Claudiu Manoil, andrew@lunn.ch, krzk+dt@kernel.org,
linux@armlinux.org.uk, edumazet@google.com,
linux-kernel@vger.kernel.org, pabeni@redhat.com,
f.fainelli@gmail.com, imx@lists.linux.dev, chleroy@kernel.org,
netdev@vger.kernel.org, robh@kernel.org,
linuxppc-dev@lists.ozlabs.org, Clark Wang, davem@davemloft.net
In-Reply-To: <20260324165804.245011-1-horms@kernel.org>
> > +static struct netc_cbdr *netc_select_cbdr(struct ntmp_user *user)
> > +{
> > + int cpu, i;
> > +
> > + for (i = 0; i < user->cbdr_num; i++) {
> > + if (spin_is_locked(&user->ring[i].ring_lock))
> > + continue;
> > +
> > + return &user->ring[i];
> > + }
>
> Frank Li raised a concern about the use of spin_is_locked() here. Is this
> lockless check reliable across all architectures? spin_is_locked() behavior
> varies across configurations - it can return false negatives on UP builds and
> may not provide the ordering guarantees needed for lockless checks.
>
> Would spin_trylock() be more appropriate here? Or if this racy check is
> intentional and acceptable, should it be documented why the potential race is
> safe in this context?
I missed this comment in v1 for some reasons, I will improve this, thanks
^ permalink raw reply
* RE: [PATCH v2 net-next 09/14] net: dsa: add NETC switch tag support
From: Wei Fang @ 2026-03-25 1:54 UTC (permalink / raw)
To: Simon Horman
Cc: devicetree@vger.kernel.org, robh@kernel.org, andrew@lunn.ch,
Vladimir Oltean, Frank Li, pabeni@redhat.com, conor+dt@kernel.org,
Clark Wang, davem@davemloft.net, krzk+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
kuba@kernel.org, edumazet@google.com,
linux-kernel@vger.kernel.org, linux@armlinux.org.uk,
andrew+netdev@lunn.ch, f.fainelli@gmail.com, Claudiu Manoil,
netdev@vger.kernel.org, chleroy@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20260324165415.243214-1-horms@kernel.org>
> > +static struct sk_buff *netc_rcv(struct sk_buff *skb,
> > + struct net_device *ndev)
> > +{
> > + struct netc_tag_cmn *tag_cmn = dsa_etype_header_pos_rx(skb);
> > + int tag_len = netc_get_rx_tag_len(tag_cmn->type);
> ^^^^^^^^^^^^
>
> Is the tag header guaranteed to be in the linear region of the skb?
> Looking at other EtherType-based DSA tag drivers (tag_ar9331, tag_lan9303,
> tag_dsa, tag_edsa, tag_a5psw, tag_brcm_legacy, tag_mxl-gsw1xx,
> tag_gswip, and tag_mtk), they all call pskb_may_pull() before accessing
> tag data to ensure the header is linearized.
>
I will add this check, thanks
^ permalink raw reply
* RE: [PATCH v2 net-next 13/14] net: dsa: netc: initialize buffer bool table and implement flow-control
From: Wei Fang @ 2026-03-25 1:53 UTC (permalink / raw)
To: Simon Horman
Cc: Clark Wang, netdev@vger.kernel.org, linux@armlinux.org.uk,
krzk+dt@kernel.org, kuba@kernel.org, andrew+netdev@lunn.ch,
chleroy@kernel.org, andrew@lunn.ch, conor+dt@kernel.org,
edumazet@google.com, linux-arm-kernel@lists.infradead.org,
Frank Li, robh@kernel.org, devicetree@vger.kernel.org,
Claudiu Manoil, f.fainelli@gmail.com, Vladimir Oltean,
linuxppc-dev@lists.ozlabs.org, pabeni@redhat.com,
davem@davemloft.net, linux-kernel@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <20260324164234.238201-1-horms@kernel.org>
> > +static u32 netc_get_buffer_pool_num(struct netc_switch *priv)
> > +{
> > + return netc_base_rd(&priv->regs, NETC_BPCAPR) & BPCAPR_NUM_BP;
> > +}
> > +
> > +static void netc_port_set_pbpmcr(struct netc_port *np, u64 mapping)
> > +{
> > + u32 pbpmcr0 = lower_32_bits(mapping);
> > + u32 pbpmcr1 = upper_32_bits(mapping);
> > +
> > + netc_port_wr(np, NETC_PBPMCR0, pbpmcr0);
> > + netc_port_wr(np, NETC_PBPMCR1, pbpmcr1);
> > +}
> > +
> > +static void netc_ipv_to_buffer_pool_mapping(struct netc_switch *priv)
> > +{
> > + int num_port_bp = priv->num_bp / priv->info->num_ports;
> > + int q = NETC_IPV_NUM / num_port_bp;
> > ^^^^
>
> Can this cause a division by zero? If netc_get_buffer_pool_num() reads
From hardware perspective, num_bp is more than num_ports, so num_port_bp
will not be zero. Let me think how to improve it to avoid such false positive.
> the hardware register NETC_BPCAPR and returns 0, then num_port_bp would
> be
> 0 and this division would crash the kernel.
>
> The call chain is:
>
> netc_setup()
> netc_switch_bpt_default_config()
> priv->num_bp = netc_get_buffer_pool_num()
> netc_ipv_to_buffer_pool_mapping()
> num_port_bp = priv->num_bp / priv->info->num_ports;
> q = NETC_IPV_NUM / num_port_bp; <- division by zero
>
> Should netc_switch_bpt_default_config() validate that priv->num_bp is
> non-zero before proceeding?
>
> > + int r = NETC_IPV_NUM % num_port_bp;
> > + int num = q + r;
> > +
> > + /* IPV-to-buffer-pool mapping per port:
>
> [ ... ]
>
> > +static int netc_switch_bpt_default_config(struct netc_switch *priv)
> > +{
> > + priv->num_bp = netc_get_buffer_pool_num(priv);
> > + priv->bpt_list = devm_kcalloc(priv->dev, priv->num_bp,
> > + sizeof(struct bpt_cfge_data),
> > + GFP_KERNEL);
> > + if (!priv->bpt_list)
> > + return -ENOMEM;
> > +
> > + /* Initialize the maximum threshold of each buffer pool entry */
> > + for (int i = 0; i < priv->num_bp; i++) {
> > + struct bpt_cfge_data *cfge = &priv->bpt_list[i];
> > + int err;
> > +
> > + cfge->max_thresh = cpu_to_le16(NETC_BP_THRESH);
> > + err = ntmp_bpt_update_entry(&priv->ntmp, i, cfge);
> > + if (err)
> > + return err;
> > + }
> > +
> > + netc_ipv_to_buffer_pool_mapping(priv);
> > +
> > + return 0;
> > +}
> > +
>
> [ ... ]
>
> > @@ -1224,6 +1313,40 @@ static void netc_port_set_hd_flow_control(struct
> netc_port *np, bool en)
> > en ? PM_CMD_CFG_HD_FCEN : 0);
> > }
> >
> > +static void netc_port_set_tx_pause(struct netc_port *np, bool tx_pause)
> > +{
> > + struct netc_switch *priv = np->switch_priv;
> > + int port = np->dp->index;
> > + int i, j, num_bp;
> > +
> > + num_bp = priv->num_bp / priv->info->num_ports;
> > + for (i = 0, j = port * num_bp; i < num_bp; i++, j++) {
> > + struct bpt_cfge_data *cfge;
> > +
> > + cfge = &priv->bpt_list[j];
> > + if (tx_pause) {
> > + cfge->fc_on_thresh = cpu_to_le16(NETC_FC_THRESH_ON);
> > + cfge->fc_off_thresh = cpu_to_le16(NETC_FC_THRESH_OFF);
> > + cfge->fccfg_sbpen = FIELD_PREP(BPT_FC_CFG,
> > + BPT_FC_CFG_EN_BPFC);
> > + cfge->fc_ports = cpu_to_le32(BIT(port));
> > + } else {
> > + cfge->fc_on_thresh = cpu_to_le16(0);
> > + cfge->fc_off_thresh = cpu_to_le16(0);
> > + cfge->fccfg_sbpen = 0;
> > + cfge->fc_ports = cpu_to_le32(0);
> > + }
> > +
> > + ntmp_bpt_update_entry(&priv->ntmp, j, cfge);
> > ^^^^
>
> Should the return value of ntmp_bpt_update_entry() be checked here?
>
> Simon Horman noted in v1 review that other NTMP table operations in the
> driver propagate errors from the update functions. While this was fixed
> in netc_switch_bpt_default_config() in v2, the same issue remains here.
>
> If the hardware update fails (for example, DMA allocation failure or
> hardware timeout), the driver's bpt_list will have flow control values that
> do not match the actual hardware state, potentially causing incorrect flow
> control behavior.
Okay, I will improve it.
^ permalink raw reply
* Re: [PATCH v27 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and transfer-mode properties
From: Rob Herring (Arm) @ 2026-03-25 1:46 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, devicetree, Conor Dooley, Andrew Jeffery, Krzysztof Kozlowski,
Joel Stanley, Rayn Chen, linux-arm-kernel, linux-i2c, Andi Shyti,
andriy.shevchenko, Philipp Zabel, linux-kernel, openbmc,
linux-aspeed, Benjamin Herrenschmidt
In-Reply-To: <20260324-upstream_i2c-v27-2-f19b511c8c28@aspeedtech.com>
On Tue, 24 Mar 2026 11:06:27 +0800, Ryan Chen wrote:
> The AST2600 I2C controller supports three transfer modes (byte, buffer,
> DMA). Add "aspeed,transfer-mode" so DT can select the preferred transfer
> method per controller instance. Also add the "aspeed,global-regs"
> phandle to reference the AST2600 global registers syscon/regmap used by
> the controller.
>
> These properties apply only to the AST2600 binding and are not part of
> the legacy binding, which uses a mixed controller/target register layout
> and does not have the split register blocks or these new configuration
> registers. Legacy DTs remain unchanged.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v27:
> - change aspeed,transfer-mode to aspeed,enable-dma.
> ---
> .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.example.dtb: i2c@80 (aspeed,ast2600-i2c-bus): Unevaluated properties are not allowed ('aspeed,transfer-mode' was unexpected)
from schema $id: http://devicetree.org/schemas/i2c/aspeed,ast2600-i2c.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260324-upstream_i2c-v27-2-f19b511c8c28@aspeedtech.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Rob Herring (Arm) @ 2026-03-25 1:03 UTC (permalink / raw)
To: Jianhua Lin
Cc: krzk+dt, vince-wl.liu, linux-mediatek, angelogioacchino.delregno,
nicolas, Project_Global_Chrome_Upstream_Group, mchehab,
linux-kernel, conor+dt, devicetree, linux-arm-kernel,
matthias.bgg, linux-media, sirius.wang, jh.hsu
In-Reply-To: <20260324095455.1437-3-jianhua.lin@mediatek.com>
On Tue, 24 Mar 2026 17:54:54 +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG encoder block found in the
> MediaTek MT8189 SoC.
>
> Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
> address space support. Therefore, it is added as a standalone compatible
> string without falling back to the generic "mediatek,mtk-jpgenc" to
> ensure the driver applies the correct hardware-specific configurations.
>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-encoder.yaml | 20 ++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Rob Herring @ 2026-03-25 1:03 UTC (permalink / raw)
To: Jianhua Lin
Cc: nicolas, mchehab, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu
In-Reply-To: <20260324095455.1437-2-jianhua.lin@mediatek.com>
On Tue, Mar 24, 2026 at 05:54:53PM +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG decoder block found in the
> MediaTek MT8189 SoC.
>
> Compared to previous generation ICs, the MT8189 JPEG decoder requires
> 34-bit IOVA address space support and only needs a single clock
> ("jpgdec") instead of two. Therefore, it is added as a standalone
> compatible string without falling back to older SoCs.
>
> Update the binding schema to include the new compatible string and add
> an `allOf` block with conditional checks. This enforces the single clock
> requirement for MT8189 while preserving the two-clock requirement
> ("jpgdec-smi", "jpgdec") for older SoCs.
>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 39 ++++++++++++++++---
> 1 file changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> index a4aacd3eb189..91c9b2a4687b 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> @@ -17,13 +17,14 @@ properties:
> oneOf:
> - items:
> - enum:
> - - mediatek,mt8173-jpgdec
> - mediatek,mt2701-jpgdec
> + - mediatek,mt8173-jpgdec
> - items:
> - enum:
> - mediatek,mt7623-jpgdec
> - mediatek,mt8188-jpgdec
> - const: mediatek,mt2701-jpgdec
> + - const: mediatek,mt8189-jpgdec
This goes in the 1st oneOf entry along with 8173.
^ permalink raw reply
* Re: [PATCH v8 2/5] dt-bindings: PCI: imx6q-pcie: Add i.MX94 and i.MX943 PCIe compatible strings
From: Rob Herring (Arm) @ 2026-03-25 0:54 UTC (permalink / raw)
To: Richard Zhu
Cc: kernel, linux-kernel, krzk+dt, l.stach, s.hauer, imx, devicetree,
festevam, frank.li, linux-arm-kernel, lpieralisi, linux-pci,
conor+dt, kwilczynski, mani, bhelgaas
In-Reply-To: <20260324023036.784466-3-hongxing.zhu@nxp.com>
On Tue, 24 Mar 2026 10:30:33 +0800, Richard Zhu wrote:
> Add i.MX94 and i.MX943 PCIe compatible strings and fallback to
> i.MX95 PCIe compatible string.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
> .../bindings/pci/fsl,imx6q-pcie-ep.yaml | 18 ++++++++-----
> .../bindings/pci/fsl,imx6q-pcie.yaml | 26 ++++++++++++-------
> 2 files changed, 28 insertions(+), 16 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH 3/3] KVM: arm64: selftests: Enable stage-2 in NV preparation functions
From: Wei-Lin Chang @ 2026-03-25 0:36 UTC (permalink / raw)
To: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel
Cc: Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-1-weilin.chang@arm.com>
Introduce library functions for setting up guest stage-2 page tables,
then use that to give L2 an identity mapped stage-2 and enable it.
The translation and stage-2 page table built is simple, start level 0,
4 levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
The nested page table code is adapted from lib/x86/vmx.c.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
.../selftests/kvm/include/arm64/nested.h | 7 ++
.../selftests/kvm/include/arm64/processor.h | 9 ++
.../testing/selftests/kvm/lib/arm64/nested.c | 97 ++++++++++++++++++-
3 files changed, 111 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
index 739ff2ee0161..0be10a775e48 100644
--- a/tools/testing/selftests/kvm/include/arm64/nested.h
+++ b/tools/testing/selftests/kvm/include/arm64/nested.h
@@ -6,6 +6,13 @@
#ifndef SELFTEST_KVM_NESTED_H
#define SELFTEST_KVM_NESTED_H
+uint64_t get_l1_vtcr(void);
+
+void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint64_t nested_paddr, uint64_t paddr, uint64_t size);
+void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint32_t memslot);
+
void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
diff --git a/tools/testing/selftests/kvm/include/arm64/processor.h b/tools/testing/selftests/kvm/include/arm64/processor.h
index ac97a1c436fc..5de2e932d95a 100644
--- a/tools/testing/selftests/kvm/include/arm64/processor.h
+++ b/tools/testing/selftests/kvm/include/arm64/processor.h
@@ -104,6 +104,15 @@
#define TCR_HA (UL(1) << 39)
#define TCR_DS (UL(1) << 59)
+/* VTCR_EL2 specific flags */
+#define VTCR_EL2_T0SZ_BITS(x) ((UL(64) - (x)) << VTCR_EL2_T0SZ_SHIFT)
+
+#define VTCR_EL2_SL0_LV0_4K (UL(2) << VTCR_EL2_SL0_SHIFT)
+#define VTCR_EL2_SL0_LV1_4K (UL(1) << VTCR_EL2_SL0_SHIFT)
+#define VTCR_EL2_SL0_LV2_4K (UL(0) << VTCR_EL2_SL0_SHIFT)
+
+#define VTCR_EL2_PS_40_BITS (UL(2) << VTCR_EL2_PS_SHIFT)
+
/*
* AttrIndx[2:0] encoding (mapping attributes defined in the MAIR* registers).
*/
diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
index 111d02f44cfe..910f8cd30f96 100644
--- a/tools/testing/selftests/kvm/lib/arm64/nested.c
+++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
@@ -1,8 +1,11 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * ARM64 Nested virtualization helpers
+ * ARM64 Nested virtualization helpers, nested page table code adapted from
+ * ../x86/vmx.c.
*/
+#include <linux/sizes.h>
+
#include "kvm_util.h"
#include "nested.h"
#include "processor.h"
@@ -18,6 +21,87 @@ static void hvc_handler(struct ex_regs *regs)
regs->pc = (u64)after_hvc;
}
+uint64_t get_l1_vtcr(void)
+{
+ return VTCR_EL2_PS_40_BITS | VTCR_EL2_TG0_4K | VTCR_EL2_ORGN0_WBWA |
+ VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LV0_4K | VTCR_EL2_T0SZ_BITS(48);
+}
+
+static void __nested_pg_map(struct kvm_vm *vm, uint64_t guest_pgd,
+ uint64_t nested_paddr, uint64_t paddr, uint64_t flags)
+{
+ uint8_t attr_idx = flags & (PTE_ATTRINDX_MASK >> PTE_ATTRINDX_SHIFT);
+ uint64_t pg_attr;
+ uint64_t *ptep;
+
+ TEST_ASSERT((nested_paddr % vm->page_size) == 0,
+ "L2 IPA not on page boundary,\n"
+ " nested_paddr: 0x%lx vm->page_size: 0x%x", nested_paddr, vm->page_size);
+ TEST_ASSERT((paddr % vm->page_size) == 0,
+ "Guest physical address not on page boundary,\n"
+ " paddr: 0x%lx vm->page_size: 0x%x", paddr, vm->page_size);
+ TEST_ASSERT((paddr >> vm->page_shift) <= vm->max_gfn,
+ "Physical address beyond maximum supported,\n"
+ " paddr: 0x%lx vm->max_gfn: 0x%lx vm->page_size: 0x%x",
+ paddr, vm->max_gfn, vm->page_size);
+
+ ptep = addr_gpa2hva(vm, guest_pgd) + ((nested_paddr >> 39) & 0x1ffu) * 8;
+ if (!*ptep)
+ *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PGD_TYPE_TABLE | PTE_VALID;
+ ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 30) & 0x1ffu) * 8;
+ if (!*ptep)
+ *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PUD_TYPE_TABLE | PTE_VALID;
+ ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 21) & 0x1ffu) * 8;
+ if (!*ptep)
+ *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PMD_TYPE_TABLE | PTE_VALID;
+ ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 12) & 0x1ffu) * 8;
+
+ pg_attr = PTE_AF | PTE_ATTRINDX(attr_idx) | PTE_TYPE_PAGE | PTE_VALID;
+ pg_attr |= PTE_SHARED;
+
+ *ptep = (paddr & GENMASK(47, 12)) | pg_attr;
+}
+
+void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint64_t nested_paddr, uint64_t paddr, uint64_t size)
+{
+ size_t npages = size / SZ_4K;
+
+ TEST_ASSERT(nested_paddr + size > nested_paddr, "Vaddr overflow");
+ TEST_ASSERT(paddr + size > paddr, "Paddr overflow");
+
+ while (npages--) {
+ __nested_pg_map(vm, guest_pgd, nested_paddr, paddr, MT_NORMAL);
+ nested_paddr += SZ_4K;
+ paddr += SZ_4K;
+ }
+}
+
+/*
+ * Prepare an identity shadow page table that maps all the
+ * physical pages in VM.
+ */
+void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint32_t memslot)
+{
+ sparsebit_idx_t i, last;
+ struct userspace_mem_region *region =
+ memslot2region(vm, memslot);
+
+ i = (region->region.guest_phys_addr >> vm->page_shift) - 1;
+ last = i + (region->region.memory_size >> vm->page_shift);
+ for (;;) {
+ i = sparsebit_next_clear(region->unused_phy_pages, i);
+ if (i > last)
+ break;
+
+ nested_map(vm, guest_pgd,
+ (uint64_t)i << vm->page_shift,
+ (uint64_t)i << vm->page_shift,
+ 1 << vm->page_shift);
+ }
+}
+
void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
{
size_t l2_stack_size;
@@ -32,7 +116,16 @@ void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
{
- vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW);
+ vm_paddr_t guest_pgd;
+
+ guest_pgd = vm_phy_pages_alloc(vm, 1,
+ KVM_GUEST_PAGE_TABLE_MIN_PADDR,
+ vm->memslots[MEM_REGION_PT]);
+ nested_map_memslot(vm, guest_pgd, 0);
+
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW | HCR_EL2_VM);
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTTBR_EL2), guest_pgd);
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTCR_EL2), get_l1_vtcr());
}
void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc)
--
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