* [PATCH] drm/mediatek: simplify mtk_crtc allocation
From: Rosen Penev @ 2026-03-31 0:23 UTC (permalink / raw)
To: dri-devel
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno,
moderated list:DRM DRIVERS FOR MEDIATEK,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Use a flexible array member to combine allocations.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c b/drivers/gpu/drm/mediatek/mtk_crtc.c
index fcb16f3f7b23..914841d2396e 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -62,7 +62,6 @@ struct mtk_crtc {
struct device *dma_dev;
struct mtk_mutex *mutex;
unsigned int ddp_comp_nr;
- struct mtk_ddp_comp **ddp_comp;
unsigned int num_conn_routes;
const struct mtk_drm_route *conn_routes;
@@ -71,6 +70,8 @@ struct mtk_crtc {
bool config_updating;
/* lock for config_updating to cmd buffer */
spinlock_t config_lock;
+
+ struct mtk_ddp_comp *ddp_comp[];
};
struct mtk_crtc_state {
@@ -1048,18 +1049,12 @@ int mtk_crtc_create(struct drm_device *drm_dev, const unsigned int *path,
}
}
- mtk_crtc = devm_kzalloc(dev, sizeof(*mtk_crtc), GFP_KERNEL);
+ mtk_crtc = devm_kzalloc(dev, struct_size(mtk_crtc, ddp_comp, path_len + (conn_routes ? 1 : 0)), GFP_KERNEL);
if (!mtk_crtc)
return -ENOMEM;
- mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->ddp_comp_nr = path_len;
- mtk_crtc->ddp_comp = devm_kcalloc(dev,
- mtk_crtc->ddp_comp_nr + (conn_routes ? 1 : 0),
- sizeof(*mtk_crtc->ddp_comp),
- GFP_KERNEL);
- if (!mtk_crtc->ddp_comp)
- return -ENOMEM;
+ mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->mutex = mtk_mutex_get(priv->mutex_dev);
if (IS_ERR(mtk_crtc->mutex)) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
From: Jakub Kicinski @ 2026-03-31 0:28 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org>
On Fri, 27 Mar 2026 10:48:21 +0100 Lorenzo Bianconi wrote:
> In order to properly cleanup hw rx QDMA queues and bring the device to
> the initial state, reset rx DMA queue head/tail index. Moreover, reset
> queued DMA descriptor fields.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Tested-by: Madhur Agrawal <Madhur.Agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Take a look at sashiko, please:
https://sashiko.dev/#/patchset/20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org
Looks somewhat orthogonal to the current patch but probably worth
fixing.
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
From: patchwork-bot+netdevbpf @ 2026-03-31 0:40 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev, Madhur.Agrawal
In-Reply-To: <20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 27 Mar 2026 10:48:21 +0100 you wrote:
> In order to properly cleanup hw rx QDMA queues and bring the device to
> the initial state, reset rx DMA queue head/tail index. Moreover, reset
> queued DMA descriptor fields.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Tested-by: Madhur Agrawal <Madhur.Agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
https://git.kernel.org/netdev/net/c/514aac359987
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: lpc_eth: Fix a possible memory leak in lpc_mii_probe()
From: Ma Ke @ 2026-03-31 0:43 UTC (permalink / raw)
To: vz
Cc: alexandre.belloni, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-kernel, make24, netdev, pabeni,
piotr.wojtaszczyk, stable
In-Reply-To: <b44db9e6-f820-439d-a7ed-c1e2514579a8@mleia.com>
On 3/30/26 13:04, Vladimir Zapolskiy wrote:
> On 3/30/26 11:16, Ma Ke wrote:
> > lpc_mii_probe() calls of_phy_find_device() to obtain a phy_device
> > pointer. of_phy_find_device() increments the refcount of the device.
> > The current implementation does not decrement the refcount after using
> > the pointer, which leads to a memory leak.
>
> this is correct, there is an actual detected bug.
>
> >
> > Add phy_device_free() to balance the refcount.
>
> But this does not sound right, you shoud use of_node_put(pldat->phy_node).
>
> >
> > Found by code review.
> >
> > Signed-off-by: Ma Ke <make24@iscas.ac.cn>
> > Cc: stable@vger.kernel.org
> > Fixes: 3503bf024b3e ("net: lpc_eth: parse phy nodes from device tree")
> > ---
> > drivers/net/ethernet/nxp/lpc_eth.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> > index 8b9a3e3bba30..8ce7c9bb6dd6 100644
> > --- a/drivers/net/ethernet/nxp/lpc_eth.c
> > +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> > @@ -751,7 +751,7 @@ static void lpc_handle_link_change(struct net_device *ndev)
> > static int lpc_mii_probe(struct net_device *ndev)
> > {
> > struct netdata_local *pldat = netdev_priv(ndev);
> > - struct phy_device *phydev;
> > + struct phy_device *phydev, *phydev_tmp;
> >
> > /* Attach to the PHY */
> > if (lpc_phy_interface_mode(&pldat->pdev->dev) == PHY_INTERFACE_MODE_MII)
> > @@ -760,17 +760,18 @@ static int lpc_mii_probe(struct net_device *ndev)
> > netdev_info(ndev, "using RMII interface\n");
> >
> > if (pldat->phy_node)
> > - phydev = of_phy_find_device(pldat->phy_node);
> > + phydev_tmp = of_phy_find_device(pldat->phy_node);
> > else
> > - phydev = phy_find_first(pldat->mii_bus);
> > - if (!phydev) {
> > + phydev_tmp = phy_find_first(pldat->mii_bus);
> > + if (!phydev_tmp) {
>
> I didn't get it, why the new phydev_tmp is needed above, please
> restore the original code above.
>
> > netdev_err(ndev, "no PHY found\n");
> > return -ENODEV;
> > }
> >
> > - phydev = phy_connect(ndev, phydev_name(phydev),
> > + phydev = phy_connect(ndev, phydev_name(phydev_tmp),
> > &lpc_handle_link_change,
> > lpc_phy_interface_mode(&pldat->pdev->dev));
> > + phy_device_free(phydev_tmp);
>
> This is plainly wrong and has to be dropped or changed to
>
> if (pldat->phy_node)
> of_node_put(pldat->phy_node);
>
> > if (IS_ERR(phydev)) {
> > netdev_err(ndev, "Could not attach to PHY\n");
> > return PTR_ERR(phydev);
>
> Is it AI generated fix or what?.. The change looks bad, it introduces
> more severe issues than it fixes.
>
> If you think you cannot create a proper change, let me know.
>
> --
> Best wishes,
> Vladimir
Thank you very much for your detailed review and guidance.
Now I think your point probably is: you are saying that the real leak is not from of_phy_find_device(), but from the device node pldat->phy_node which was obtained earlier (probably by of_parse_phandle()) and never freed by of_node_put(). And you suggest to add of_node_put(pldat->phy_node) instead of my wrong phy_device_free().
However, I am still a little confused. In lpc_mii_probe(), of_phy_find_device() is called. From my understanding, this function increases the reference count of the device. To balance it, I thought phy_device_free() (which calls put_device()) should be used.
Could you please kindly advise the correct patch? I will follow your guidance and submit a proper fix.
I apologize again for my previous wrong patch. Thank you very much for your help.
Best regards,
Ma Ke
^ permalink raw reply
* Re: [PATCH net-next v2 00/15] net: stmmac: qcom-ethqos: more cleanups
From: patchwork-bot+netdevbpf @ 2026-03-31 0:50 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-arm-msm, linux-stm32, mohd.anwar, netdev,
pabeni
In-Reply-To: <acZDEg9wdjhBTHlL@shell.armlinux.org.uk>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 27 Mar 2026 08:42:58 +0000 you wrote:
> Further cleanups to qcom-ethqos, mainly concentrating on the RGMII
> code, making it clearer what the differences are for each speed, thus
> making the code more readable.
>
> I'm still not really happy with this. The speed specific configuration
> remains split between ethqos_fix_mac_speed_rgmii() and
> ethqos_rgmii_macro_init(), where the latter is only ever called from
> the former. So, I think further work is needed here - maybe it needs
> restructuring into the various componenet parts of the RGMII block?
>
> [...]
Here is the summary with links:
- [net-next,v2,01/15] net: stmmac: qcom-ethqos: remove ethqos_configure()
https://git.kernel.org/netdev/net-next/c/c3dd3b1e76e0
- [net-next,v2,02/15] net: stmmac: qcom-ethqos: pass ethqos to ethqos_pcs_set_inband()
https://git.kernel.org/netdev/net-next/c/673416fb5b41
- [net-next,v2,03/15] net: stmmac: qcom-ethqos: eliminate configure_func
https://git.kernel.org/netdev/net-next/c/e9ed46a0b129
- [net-next,v2,04/15] net: stmmac: qcom-ethqos: move detection of invalid RGMII speed
https://git.kernel.org/netdev/net-next/c/426ce4677e81
- [net-next,v2,05/15] net: stmmac: qcom-ethqos: move RGMII_CONFIG_DDR_MODE
https://git.kernel.org/netdev/net-next/c/6be23c4c636a
- [net-next,v2,06/15] net: stmmac: qcom-ethqos: move 1G vs 100M/10M RGMII settings
https://git.kernel.org/netdev/net-next/c/82d5fdc82a33
- [net-next,v2,07/15] net: stmmac: qcom-ethqos: move two more RGMII_IO_MACRO_CONFIG2 out
https://git.kernel.org/netdev/net-next/c/dd07f2f9149a
- [net-next,v2,08/15] net: stmmac: qcom-ethqos: move 100M/10M speed programming
https://git.kernel.org/netdev/net-next/c/8b19a9184420
- [net-next,v2,09/15] net: stmmac: qcom-ethqos: move RGMII_CONFIG2_RSVD_CONFIG15 out
https://git.kernel.org/netdev/net-next/c/dae1de3df3e1
- [net-next,v2,10/15] net: stmmac: qcom-ethqos: move RGMII_CONFIG2_RX_PROG_SWAP
https://git.kernel.org/netdev/net-next/c/432c8a9f5528
- [net-next,v2,11/15] net: stmmac: qcom-ethqos: finally eliminate the switch
https://git.kernel.org/netdev/net-next/c/439a27f21ecc
- [net-next,v2,12/15] net: stmmac: qcom-ethqos: simplify prg_rclk_dly programming
https://git.kernel.org/netdev/net-next/c/3df0e86f8f8d
- [net-next,v2,13/15] net: stmmac: qcom-ethqos: move loopback decision next to reg update
https://git.kernel.org/netdev/net-next/c/67343aa24e59
- [net-next,v2,14/15] net: stmmac: qcom-ethqos: correct prg_rclk_dly comment
https://git.kernel.org/netdev/net-next/c/2d350a892aad
- [net-next,v2,15/15] net: stmmac: qcom-ethqos: move phase_shift to register update site
https://git.kernel.org/netdev/net-next/c/7f9f30166005
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v5 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-03-31 0:54 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260331005458.24010-1-jianhua.lin@mediatek.com>
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.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..601fe05b73e7 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,22 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ minItems: 1
+ maxItems: 2
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
+
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
power-domains:
maxItems: 1
@@ -60,6 +69,25 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v5 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-03-31 0:54 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on tag: next-20260327, linux-next/master
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 19 +++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
3 files changed, 93 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v5 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-03-31 0:54 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260331005458.24010-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 8c684756d5fc..786cc2942c3a 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1867,6 +1867,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1898,6 +1902,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1937,6 +1973,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* [PATCH v5 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-03-31 0:54 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260331005458.24010-1-jianhua.lin@mediatek.com>
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.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..19948ed25f98 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,16 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
reg:
maxItems: 1
@@ -34,6 +37,10 @@ properties:
items:
- const: jpgenc
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
+
power-domains:
maxItems: 1
--
2.45.2
^ permalink raw reply related
* Re: [PATCH net-next v2] net: airoha: Delay offloading until all net_devices are fully registered
From: patchwork-bot+netdevbpf @ 2026-03-31 1:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260329-airoha-regiser-race-fix-v2-1-f4ebb139277b@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 29 Mar 2026 12:32:27 +0200 you wrote:
> Netfilter flowtable can theoretically try to offload flower rules as soon
> as a net_device is registered while all the other ones are not
> registered or initialized, triggering a possible NULL pointer dereferencing
> of qdma pointer in airoha_ppe_set_cpu_port routine. Moreover, if
> register_netdev() fails for a particular net_device, there is a small
> race if Netfilter tries to offload flowtable rules before all the
> net_devices are properly unregistered in airoha_probe() error patch,
> triggering a NULL pointer dereferencing in airoha_ppe_set_cpu_port
> routine. In order to avoid any possible race, delay offloading until
> all net_devices are registered in the networking subsystem.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: airoha: Delay offloading until all net_devices are fully registered
https://git.kernel.org/netdev/net/c/cedc1bf327de
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v4] ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
From: Chancel Liu @ 2026-03-31 1:24 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li,
shengjiu.wang, s.hauer, kernel, festevam, linux-sound, devicetree,
imx, linux-arm-kernel, linux-kernel
Currently this binding only lists i2s and dsp_b formats that are used
by existing sound cards. However, DT bindings should describe the full
hardware capabilities rather than only the formats of current usage.
The SAI audio controller of i.MX audio sound card supports multiple DAI
formats, including:
- i2s
- left_j
- right_j
- dsp_a
- dsp_b
- pdm
- msb
- lsb
Complete the full list of formats supported by i.MX audio sound card to
ensure the binding correctly describes hardware.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
Changes in v4:
- Completed the full list of DAI formats (i2s, left_j, right_j, dsp_a,
dsp_b, pdm, msb, lsb) supported by i.MX sound card.
- Rewrote commit message to focus on describing hardware capability
rather than current usage.
Changes in v3:
- Rewrote commit message completely to describe hardware requirements.
Explicitly documented why only dsp_a is added and why other formats
are not included.
- Rebased on latest code base. No functional changes.
Changes in v2:
- Updated commit message to explain current support for i2s and dsp_b
formats and new support for dsp_a. No code changes.
Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
index 5424d4f16f52..950e3eab2942 100644
--- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
+++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
@@ -37,7 +37,13 @@ patternProperties:
items:
enum:
- i2s
+ - left_j
+ - right_j
+ - dsp_a
- dsp_b
+ - pdm
+ - msb
+ - lsb
dai-tdm-slot-num: true
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 1:29 UTC (permalink / raw)
To: James Clark, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <95610981-ad68-4a31-a776-27894b7bca59@linaro.org>
Hi James,
On 3/30/2026 10:55 PM, James Clark wrote:
>
>
> On 25/03/2026 3:10 am, Jie Gan wrote:
>> 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;
>
> You probably need to take the coresight_mutex here otherwise you could
> still return an invalid or stale value despite checking the mode.
>
Acked. I have missed this potential race condition.
> There might also be some value in it returning the last used trace ID
> even if the mode isn't enabled anymore. Because you can still read out
> of the sink after disabling, so it makes more sense for a script to read
> it at that point rather than when it's enabled. Also, you probably don't
> want to be doing other things in your script in the point between
> enabling and disabling.
That's making sense. I shouldnt add such restriction for the read process.
Scenarios for reading:
1. device is enabled -> trace ID is valid
2. device is enabled then disabled -> trace ID is valid for the last
trace event
3. device is never enabled -> invalid trace ID (value 0)
we only need to check the validation of the trace ID.
mutex_lock(&coresight_mutex);
val = drvdata->traceid;
mutex_unlock(&coresight_mutex);
if (!val)
return -EINVAL;
return sysfs_emit(buf, "%#lx\n", val);
Thanks,
Jie
>
>> + 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,
>
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Yaxiong Tian @ 2026-03-31 1:30 UTC (permalink / raw)
To: Jie Zhan, cw00.choi, myungjoo.ham, kyungmin.park
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <1774919144945331.7.seg@mailgw.kylinos.cn>
在 2026/3/30 14:29, Jie Zhan 写道:
>
> On 3/27/2026 10:06 AM, Yaxiong Tian wrote:
>> 在 2026/3/26 21:14, Jie Zhan 写道:
>>> On 3/26/2026 8:34 PM, Jie Zhan wrote:
>>>> When compiled as a kernel module, the governor module can be dynamically
>>>> inserted or removed. 'devfreq->governor' would become NULL if the governor
>>>> module is removed when it's in use, and NULL pointer dereference would be
>>>> triggered. A similar issue was also reported in [1].
>>>>
>>>> To address this issue:
>>>>
>>>> Patch 1-5 rework mutex, factor out a common governor setting function, and
>>>> clean up some unreachable code.
>>>>
>>>> Patch 6-8 prevent a governor module in use from being removed (except for
>>>> force unload) by getting/putting a refcount of the governor's module when
>>>> switching governors.
>>>>
>>>> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
>>>> when a governor module in use is force unloaded.
>>>>
>>>> Note that this series is based on [1] or devfreq-next, otherwise code
>> Sorry, please ignore the "remember to CC me on the patches." in my previous email.
>>
>> In my opinion, it would be better to prioritize the FIX first before proceeding with the lock mechanism optimizations and other work. This would make it easier to backport the patches to lower-version kernels. I noticed the patch is already in the devfreq-testing branch. I hope the FIX work can be moved forward smoothly to resolve the null pointer and other bugs. Thank you!
> Hi Yaxiong,
>
> I don't think this issue is urgent because it can only possibly happen when
> governors are built as loadable modules, which is typically used for
> development rather than production.
No, loading/unloading modules is also a user operational requirement,
not just for development.
>
> For downstream kernels, feel free to go ahead with quick fixes. For the
> upstream kernel, however, I'd prefer to make the devfreq core clean and
> sensible.
I don't think code cleanup should take priority over bug fixes,
especially when you already know there's an issue with the
functionality. In fact, the version users are running is not the
upstream version, but rather individual stable releases.
Most users don't have the time or energy to research and fix kernel
issues themselves; they rely on upstream community patches most of the time.
By the way, although your patch subject says "FIX", I don't see any fix tag.
>
> Your approach is to prevent kernel panics when unloading governor modules
> before changing governors.
>
> This patchset achieves that, and additionally let userspace get a friendly
> warning when trying to remove a governor module in use, e.g.
> "rmmod: ERROR: Module governor_performance is in use".
> This requires using the module refcount stuff, and brings out a set of
> cleanups and refactoring. BTW, cpufreq implements a similar mechanism like
> this.
>
> I may carry your fourth patch that changes the return code of
> governor_show() in v2 and address some Sashiko review comments along the
> way.
>
> Please let me know if this works for you?
So I don't approve of this. Maybe you should ask for others' opinions,
such as Chanwoo Choi.
>
> Regards,
> Jie
>>
>>
>>> sorry, based on [2] or devfreq-next
>>>> would conflict.
>>>>
>>>> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
>>>> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* RE: [PATCH] clk: visconti: pll: use kzalloc_flex
From: nobuhiro.iwamatsu.x90 @ 2026-03-31 1:05 UTC (permalink / raw)
To: rosenp, linux-clk
Cc: mturquette, sboyd, kees, gustavoars, linux-arm-kernel,
linux-kernel, linux-hardening
In-Reply-To: <20260326042317.122536-1-rosenp@gmail.com>
Hi Rosen,
Thanks for your patch.
> -----Original Message-----
> From: Rosen Penev <rosenp@gmail.com>
> Sent: Thursday, March 26, 2026 1:23 PM
> To: linux-clk@vger.kernel.org
> Cc: Michael Turquette <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; iwamatsu nobuhiro(岩松 信洋
> □ＤＩＴＣ○ＣＰＴ) <nobuhiro.iwamatsu.x90@mail.toshiba>; Kees Cook <kees@kernel.org>; Gustavo A. R. Silva
> <gustavoars@kernel.org>; moderated list:ARM/TOSHIBA VISCONTI ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>; open list <linux-kernel@vger.kernel.org>; open list:KERNEL HARDENING (not
> covered by other areas):Keyword:\b__counted_by(_le|_be)?\b <linux-hardening@vger.kernel.org>
> Subject: [PATCH] clk: visconti: pll: use kzalloc_flex
>
> Simplify allocation by using a flexible array member and kzalloc_flex.
>
> Add __counted_by for extra runtime analysis. Assign after allocation as required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
Best regards,
Nobuhiro
> ---
> drivers/clk/visconti/pll.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/clk/visconti/pll.c b/drivers/clk/visconti/pll.c index 6fd02c4b641e..ca29d12f9316 100644
> --- a/drivers/clk/visconti/pll.c
> +++ b/drivers/clk/visconti/pll.c
> @@ -21,9 +21,9 @@ struct visconti_pll {
> void __iomem *pll_base;
> spinlock_t *lock;
> unsigned long flags;
> - const struct visconti_pll_rate_table *rate_table;
> size_t rate_count;
> struct visconti_pll_provider *ctx;
> + struct visconti_pll_rate_table rate_table[] __counted_by(rate_count);
> };
>
> #define PLL_CONF_REG 0x0000
> @@ -255,10 +255,6 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
> size_t len;
> int ret;
>
> - pll = kzalloc_obj(*pll);
> - if (!pll)
> - return ERR_PTR(-ENOMEM);
> -
> init.name = name;
> init.flags = CLK_IGNORE_UNUSED;
> init.parent_names = &parent_name;
> @@ -266,11 +262,13 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
>
> for (len = 0; rate_table[len].rate != 0; )
> len++;
> +
> + pll = kzalloc_flex(*pll, rate_table, len);
> + if (!pll)
> + return ERR_PTR(-ENOMEM);
> +
> pll->rate_count = len;
> - pll->rate_table = kmemdup_array(rate_table,
> - pll->rate_count, sizeof(*pll->rate_table),
> - GFP_KERNEL);
> - WARN(!pll->rate_table, "%s: could not allocate rate table for %s\n", __func__, name);
> + memcpy(pll->rate_table, rate_table, len * sizeof(*pll->rate_table));
>
> init.ops = &visconti_pll_ops;
> pll->hw.init = &init;
> @@ -282,7 +280,6 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
> ret = clk_hw_register(NULL, &pll->hw);
> if (ret) {
> pr_err("failed to register pll clock %s : %d\n", name, ret);
> - kfree(pll->rate_table);
> kfree(pll);
> pll_hw_clk = ERR_PTR(ret);
> }
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH] usb: phy: mxs: manually reset phy regs after a warm reset
From: Xu Yang @ 2026-03-31 1:59 UTC (permalink / raw)
To: Greg KH
Cc: Frank.Li, s.hauer, kernel, festevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <2026033057-sixties-erupt-fea7@gregkh>
On Mon, Mar 30, 2026 at 04:19:24PM +0200, Greg KH wrote:
> On Mon, Mar 30, 2026 at 05:31:33PM +0800, Xu Yang wrote:
> > The usb phy registers are not fully reset on warm reset under stress
> > conditions. We need to manually reset those (CTRL, PWD, DEBUG, PLL_SIC)
> > regs after a warm reset. This will reset DEBUG and PLL_SIC registers.
> > CTRL and PWD register are handled by "SFT" bit in stmp_reset_block().
> >
> > ERR051269: USB PHY registers not fully resetting on warm reset under
> > stress conditions
> >
> > The following USB PHY registers must be written by SW to restore the reset
> > value after a warm reset:
> >
> > Reg: ctrl Addr: 0x29910030 Data: 0xc000_0000
> > Reg: pwd Addr: 0x29910000 Data: 0x001e_1c00
> > Reg: debug0 Addr: 0x29910050 Data: 0x7f18_0000
> > Reg: pll_sic Addr: 0x299100a0 Data: 0x00d1_2000
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> > ---
> > drivers/usb/phy/phy-mxs-usb.c | 32 +++++++++++++++++++++++++++++---
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> > index 7069dd3f4d0d..dd42db8a0829 100644
> > --- a/drivers/usb/phy/phy-mxs-usb.c
> > +++ b/drivers/usb/phy/phy-mxs-usb.c
> > @@ -209,6 +209,9 @@ static const struct mxs_phy_data imx6ul_phy_data = {
> > static const struct mxs_phy_data imx7ulp_phy_data = {
> > };
> >
> > +static const struct mxs_phy_data imx8ulp_phy_data = {
> > +};
> > +
> > static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,imx6sx-usbphy", .data = &imx6sx_phy_data, },
> > { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> > @@ -217,6 +220,7 @@ static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
> > { .compatible = "fsl,imx6ul-usbphy", .data = &imx6ul_phy_data, },
> > { .compatible = "fsl,imx7ulp-usbphy", .data = &imx7ulp_phy_data, },
> > + { .compatible = "fsl,imx8ulp-usbphy", .data = &imx8ulp_phy_data, },
>
> Why can't you use &imx7ulp_phy_data here as it's all just empty?
Thanks for your review.
Because it's imx8ulp specific errata. Let me add more info in the commit message.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH] usb: phy: mxs: manually reset phy regs after a warm reset
From: Xu Yang @ 2026-03-31 2:01 UTC (permalink / raw)
To: Frank Li
Cc: gregkh, s.hauer, kernel, festevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <acqJ0Q_Ux8PvGT7s@lizhi-Precision-Tower-5810>
On Mon, Mar 30, 2026 at 10:33:53AM -0400, Frank Li wrote:
> On Mon, Mar 30, 2026 at 05:31:33PM +0800, Xu Yang wrote:
> > The usb phy registers are not fully reset on warm reset under stress
> > conditions. We need to manually reset those (CTRL, PWD, DEBUG, PLL_SIC)
>
> Avoid the words "we ..."
>
> So need manually reset CTRL, PWD, DEBUG, PLL_SIC ...
OK.
>
> > regs after a warm reset. This will reset DEBUG and PLL_SIC registers.
> > CTRL and PWD register are handled by "SFT" bit in stmp_reset_block().
> >
> > ERR051269: USB PHY registers not fully resetting on warm reset under
> > stress conditions
> >
> > The following USB PHY registers must be written by SW to restore the reset
> > value after a warm reset:
> >
> > Reg: ctrl Addr: 0x29910030 Data: 0xc000_0000
> > Reg: pwd Addr: 0x29910000 Data: 0x001e_1c00
> > Reg: debug0 Addr: 0x29910050 Data: 0x7f18_0000
> > Reg: pll_sic Addr: 0x299100a0 Data: 0x00d1_2000
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> > ---
> > drivers/usb/phy/phy-mxs-usb.c | 32 +++++++++++++++++++++++++++++---
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> > index 7069dd3f4d0d..dd42db8a0829 100644
> > --- a/drivers/usb/phy/phy-mxs-usb.c
> > +++ b/drivers/usb/phy/phy-mxs-usb.c
> > @@ -209,6 +209,9 @@ static const struct mxs_phy_data imx6ul_phy_data = {
> > static const struct mxs_phy_data imx7ulp_phy_data = {
> > };
> >
> > +static const struct mxs_phy_data imx8ulp_phy_data = {
> > +};
> > +
> > static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,imx6sx-usbphy", .data = &imx6sx_phy_data, },
> > { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> > @@ -217,6 +220,7 @@ static const struct of_device_id mxs_phy_dt_ids[] = {
> > { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
> > { .compatible = "fsl,imx6ul-usbphy", .data = &imx6ul_phy_data, },
> > { .compatible = "fsl,imx7ulp-usbphy", .data = &imx7ulp_phy_data, },
> > + { .compatible = "fsl,imx8ulp-usbphy", .data = &imx8ulp_phy_data, },
> > { /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
> > @@ -248,6 +252,11 @@ static inline bool is_imx7ulp_phy(struct mxs_phy *mxs_phy)
> > return mxs_phy->data == &imx7ulp_phy_data;
> > }
> >
> > +static inline bool is_imx8ulp_phy(struct mxs_phy *mxs_phy)
> > +{
> > + return mxs_phy->data == &imx8ulp_phy_data;
>
> don't use this kind check.
>
> Add field 'need_reset_reg' in mxs_phy_data
>
> imx8ulp_phy_data = {
> .need_reset_reg = true;
> }
>
> if (mxs->data->need_reset_reg)
> ...
>
> The same logic for
> if (is_imx7ulp_phy(mxs_phy) || is_imx8ulp_phy(mxs_phy))
> mxs_phy_pll_enable(phy->io_priv, false);
>
> add 'need_phy_pull_enable' in mxs_phy_data. (new patch for it)
> set it true at both imx7ulp_phy_data and imx8ulp_phy_data.
OK.
Thanks,
Xu Yang
^ permalink raw reply
* [GIT PULL] arm64: dts: socfpga: updates for v7.1, version 2
From: Dinh Nguyen @ 2026-03-31 2:36 UTC (permalink / raw)
To: linux-arm-kernel, soc; +Cc: dinguyen
Change from v1:
- Correct the commit message in commit "dt-bindings: intel: Add Agilex5
SoCFPGA modular board"
- Used b4 to apply patch
Thanks,
Dinh
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v7.1_v2
for you to fetch changes up to 625af11fb9885f202e028ea5afa0037f3014e376:
arm64: dts: intel: agilex5: Drop CPU masks from GICv3 PPI interrupts (2026-03-30 21:27:28 -0500)
----------------------------------------------------------------
SoCFPGA DTS updates for v7.1
- dt-bindings updates:
- Document fallback compatible for Stratix10 SoCDK eMMC board
- Document compatible for the Agilex5 SoCFPGA modular board
- Add emmc support for the Stratix10
- Drop CPU masks from the GICv3 PPI interrupts for Agilex5
----------------------------------------------------------------
Dinh Nguyen (1):
dt-bindings: intel: Add Agilex5 SoCFPGA modular board
Geert Uytterhoeven (1):
arm64: dts: intel: agilex5: Drop CPU masks from GICv3 PPI interrupts
Ng Tze Yee (2):
dt-bindings: altera: Add fallback compatible for Stratix 10 SoCDK eMMC variant
arm64: dts: socfpga: stratix10: Add emmc support
Documentation/devicetree/bindings/arm/altera.yaml | 7 ++
arch/arm64/boot/dts/altera/Makefile | 1 +
.../boot/dts/altera/socfpga_stratix10_socdk.dts | 67 +-----------------
.../boot/dts/altera/socfpga_stratix10_socdk.dtsi | 71 +++++++++++++++++++
.../dts/altera/socfpga_stratix10_socdk_emmc.dts | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 8 +--
6 files changed, 166 insertions(+), 69 deletions(-)
create mode 100755 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtsi
create mode 100755 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_emmc.dts
^ permalink raw reply
* Re: [PATCH v3] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Vincent Donnefort @ 2026-03-31 2:41 UTC (permalink / raw)
To: Sebastian Ene
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <20260330105441.3226904-1-sebastianene@google.com>
On Mon, Mar 30, 2026 at 10:54:41AM +0000, Sebastian Ene wrote:
> The ARM Service Calling Convention (SMCCC) specifies that the function
> identifier and parameters should be passed in registers, leaving the
> 16-bit immediate field un-handled in pKVM when an SMC instruction is
> trapped.
> Since the HVC is a private interface between EL2 and the host,
> enforce the host kernel running under pKVM to use an immediate value
> of 0 only when using SMCs to make it clear for non-compliant software
> talking to Trustzone that we only use SMCCC.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> ---
> v2 -> current:
> - move the ESR decoding of the imm16 in the handle_host_smc where it
> was supposed to be
> - updated the commit message to include the reason behind while we are
> not doing for HVCs as well
> - updated the commit message to clarify that pKVM is not handling the
> imm16
>
> v1 -> v2:
> - Dropped injecting an UNDEF and return an error instead
> (SMCCC_RET_NOT_SUPPORTED)
> - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> - Updated the title of the commit message from:
> "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> smc with imm16 != 0"
>
> Link to v2:
> https://lore.kernel.org/all/20260325113138.4171430-1-sebastianene@google.com/
> Link to v1:
> https://lore.kernel.org/all/20260324135728.3532400-1-sebastianene@google.com/
>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index e7790097db93..461cf5cb5ac7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -676,8 +676,14 @@ static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
> static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> + u64 esr = read_sysreg_el2(SYS_ESR);
> bool handled;
>
> + if (esr & ESR_ELx_xVC_IMM_MASK) {
> + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> + goto exit_skip_instr;
> + }
> +
> func_id &= ~ARM_SMCCC_CALL_HINTS;
>
> handled = kvm_host_psci_handler(host_ctxt, func_id);
> @@ -686,6 +692,7 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> if (!handled)
> default_host_smc_handler(host_ctxt);
>
> +exit_skip_instr:
> /* SMC was trapped, move ELR past the current PC. */
> kvm_skip_host_instr();
> }
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Peng Fan @ 2026-03-31 2:49 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <acqjS440STRl2sK2@p14s>
On Mon, Mar 30, 2026 at 10:22:35AM -0600, Mathieu Poirier wrote:
>On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> Cortex-M[7,33] processors use a fixed reset vector table format:
>>
>> 0x00 Initial SP value
>> 0x04 Reset vector
>> 0x08 NMI
>> 0x0C ...
>> ...
>> IRQ[n]
>>
>> In ELF images, the corresponding layout is:
>>
>> reset_vectors: --> hardware reset address
>> .word __stack_end__
>> .word Reset_Handler
>> .word NMI_Handler
>> .word HardFault_Handler
>> ...
>> .word UART_IRQHandler
>> .word SPI_IRQHandler
>> ...
>>
>> Reset_Handler: --> ELF entry point address
>> ...
>>
>> The hardware fetches the first two words from reset_vectors and populates
>> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
>> Reset_Handler.
>>
>> However, the ELF entry point does not always match the hardware reset
>> address. For example, on i.MX94 CM33S:
>>
>> ELF entry point: 0x0ffc211d
>> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>>
>
>But why? Why can't the ELF image be set to the right reset base?
Per zephyr general link script[1]:
ENTRY(CONFIG_KERNEL_ENTRY)
CONFIG_KERNEL_ENTRY(_start) is the first instruction that Cortex-M starts to
execute.
config KERNEL_ENTRY
string "Kernel entry symbol"
default "__start"
help
Code entry symbol, to be set at linking phase.
The hardware reset base is different: it is the address where the hardware
fetches the initial MSP and PC values from the vector table. Hardware uses
this base to initialize the stack pointer and program counter, and only then
does the Cortex‑M begin execution at the reset handler.
Aligning the ELF entry point with the hardware reset base on Cortex‑M systems
is possible, but it comes with several risks.
1, Semantic mismatch (ELF vs. hardware behavior)
2, Debuggers may attempt to set breakpoints or start execution at the entry symbol
[1] https://elixir.bootlin.com/zephyr/v4.4.0-rc1/source/include/zephyr/arch/arm/cortex_m/scripts/linker.ld#L103
Regards
Peng.
>
^ permalink raw reply
* Re: [PATCH 2/2] pwm: meson: Add support for Amlogic S7
From: Xianwei Zhao @ 2026-03-31 2:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic
In-Reply-To: <CAFBinCD-4dwp7pmM_GHK_N1kag_5VBZbP9VAwQOxcyg6aquj3w@mail.gmail.com>
Hi Martin,
Thanks for your review.
On 2026/3/31 05:44, Martin Blumenstingl wrote:
> Hi Xianwei Zhao,
>
> On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> Add support for Amlogic S7 PWM. Amlogic S7 different from the
>> previous SoCs, a controller includes one pwm, at the same time,
>> the controller has only one input clock source.
>>
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>> ---
>> drivers/pwm/pwm-meson.c | 32 ++++++++++++++++++++++++++++++--
>> 1 file changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
>> index 8c6bf3d49753..3d16694e254e 100644
>> --- a/drivers/pwm/pwm-meson.c
>> +++ b/drivers/pwm/pwm-meson.c
>> @@ -113,6 +113,7 @@ struct meson_pwm_data {
>> int (*channels_init)(struct pwm_chip *chip);
>> bool has_constant;
>> bool has_polarity;
>> + bool single_pwm;
> At first I wasn't sure about this and thought we should replace it
> with a num_pwms (or similar) variable.
> However, I think it will be hard to add a third (or even more)
> channels to the PWM controller (not just from driver perspective but
> also from hardware perspective). So I think this is good enough as the
> choice will only be 1 or 2.
> > [...]
This is not a third channel added here.
Compared with the previous controller having two channels, here the
control has only one channel. It's equivalent to the first channel
before, while the second channel is reserved.
>> +static const struct meson_pwm_data pwm_s7_data = {
>> + .channels_init = meson_pwm_init_channels_s7,
> I think you can use .channels_init = meson_pwm_init_channels_s4, if
> you change the code inside that function from:
> for (i = 0; i < MESON_NUM_PWMS; i++) {
> to:
> for (i = 0; i < chip->npwm; i++) {
>
> [...]
The method you suggested was exactly what I did in the first version,
but after my subsequent optimization, it's what you see now.
Since initialization only involves obtaining the clock, I modify the
code less in this way and the logic is also simpler.
>> @@ -650,9 +674,13 @@ static int meson_pwm_probe(struct platform_device *pdev)
>> {
>> struct pwm_chip *chip;
>> struct meson_pwm *meson;
>> + const struct meson_pwm_data *pdata = of_device_get_match_data(&pdev->dev);
>> int err;
>>
>> - chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
>> + if (pdata->single_pwm)
>> + chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*meson));
>> + else
>> + chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
> I don't think this code is too bad for now.
> However, I'm wondering if you want to make "channels" from struct
> meson_pwm a flexible array member in a future patch. In that case it
> will be helpful to have an "unsigned int npwm = pdata->single_pwm ? 1
> : MESON_NUM_PWMS;" (or similar) variable to future-proof your code.
> What do you think?
I considered this, but chose the current implementation. I will switch
to your suggestion in the next version.
^ permalink raw reply
* [PATCH 1/2] acpi: arm64: agdi: fix missing newline in error message
From: Haoyu Lu @ 2026-03-31 2:52 UTC (permalink / raw)
To: Rafael J . Wysocki, Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla,
Catalin Marinas, Will Deacon
Cc: Len Brown, Ilkka Koskinen, Russell King, linux-acpi,
linux-arm-kernel, linux-kernel, Haoyu Lu
Add the missing trailing newline to the dev_err() message
printed when SDEI event registration fails.
This keeps the error output as a properly terminated log line.
Fixes: a2a591fb76e6f5461dfd04715b69c317e50c43a5 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device")
Signed-off-by: Haoyu Lu <hechushiguitu666@gmail.com>
---
drivers/acpi/arm64/agdi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/agdi.c b/drivers/acpi/arm64/agdi.c
index feb4b2cb4618..0c2d9d6c160b 100644
--- a/drivers/acpi/arm64/agdi.c
+++ b/drivers/acpi/arm64/agdi.c
@@ -36,7 +36,7 @@ static int agdi_sdei_probe(struct platform_device *pdev,
err = sdei_event_register(adata->sdei_event, agdi_sdei_handler, pdev);
if (err) {
- dev_err(&pdev->dev, "Failed to register for SDEI event %d",
+ dev_err(&pdev->dev, "Failed to register for SDEI event %d\n",
adata->sdei_event);
return err;
}
--
2.17.1
^ permalink raw reply related
* RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace
From: Maninder Singh @ 2026-03-31 2:59 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: bigeasy@linutronix.de, peterz@infradead.org, kees@kernel.org,
ardb@kernel.org, keithpac@amazon.com, linusw@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, mark.rutland@arm.com,
catalin.marinas@arm.com
In-Reply-To: <aa4Lo30Nq_t7qDqK@shell.armlinux.org.uk>
Hi,
> On Thu, Mar 05, 2026 at 12:35:27PM +0530, Maninder Singh wrote:
>> With Support of THREAD_INFO_IN_TASK, stack of task can be
>> freed earlier than task (even if task's reference is taken),
>> and it needs separate reference with try_get_task_stack()
>> before using the stack.
>> Otherwise if someone calls show_stack() for task, it can oops
>> the kernel like below: (Tried with normal race of show_stack when
>> task still exists, but its stack is freed)
>
> Looking at x86, it also has THREAD_INFO_IN_TASK, but I see nothing like
> this in show_stack(). How come x86 isn't similarly buggy?
>
Thanks for your inputs.
I sent patch for x86 also to report same issue, but no replies :)
https://lkml.org/lkml/2026/3/11/317
So I guess we will never know if it is buggy or not.
and why ARM64 has done the checkings and there is no need for x86 and ARM.
>> 8<--- cut here ---
>> Unable to handle kernel paging request at virtual address f8aebec4 when read
>> [f8aebec4] *pgd=83c2c811, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 7 [#1] SMP ARM
>> ..
>> CPU: 0 UID: 0 PID: 70 Comm: cat Not tainted 7.0.0-rc2-next-20260302+ #26 VOLUNTARY
>> ..
>> PC is at __read_once_word_nocheck+0x0/0x8
>> LR is at unwind_frame+0x6b0/0xa90
>> ...
>> Call trace:
>> __read_once_word_nocheck from unwind_frame+0x6b0/0xa90
>> unwind_frame from unwind_backtrace+0x178/0x1e0
>> unwind_backtrace from show_stack+0x10/0x14
>> ...
>>
>> ARM64 also takes care of it in dump_backtrace(), so same logic
>> is added for ARM also.
>>
>> Fixes: 18ed1c01a7dd ("ARM: smp: Enable THREAD_INFO_IN_TASK")
>> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Thanks,
Maninder Singh
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 3:18 UTC (permalink / raw)
To: James Clark, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <ca1fe6ba-ec56-47a5-99ea-017dcc7a28ed@oss.qualcomm.com>
Hi James,
On 3/31/2026 9:29 AM, Jie Gan wrote:
>
> Hi James,
>
> On 3/30/2026 10:55 PM, James Clark wrote:
>>
>>
>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>> 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;
>>
>> You probably need to take the coresight_mutex here otherwise you could
>> still return an invalid or stale value despite checking the mode.
>>
>
> Acked. I have missed this potential race condition.
>
>> There might also be some value in it returning the last used trace ID
>> even if the mode isn't enabled anymore. Because you can still read out
>> of the sink after disabling, so it makes more sense for a script to
>> read it at that point rather than when it's enabled. Also, you
>> probably don't want to be doing other things in your script in the
>> point between enabling and disabling.
>
> That's making sense. I shouldnt add such restriction for the read process.
>
I missed one point in last message.
Is that acceptable to export the coresight_mutex from the core module?
Currently, the coresight_mutex is used within the module only.
Thanks,
Jie
> Scenarios for reading:
> 1. device is enabled -> trace ID is valid
> 2. device is enabled then disabled -> trace ID is valid for the last
> trace event
> 3. device is never enabled -> invalid trace ID (value 0)
>
> we only need to check the validation of the trace ID.
>
> mutex_lock(&coresight_mutex);
> val = drvdata->traceid;
> mutex_unlock(&coresight_mutex);
>
> if (!val)
> return -EINVAL;
>
> return sysfs_emit(buf, "%#lx\n", val);
>
> Thanks,
> Jie
>
>>
>>> + 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,
>>
>
^ permalink raw reply
* Re: [PATCH v2 05/30] KVM: arm64: Extract stage-2 permission logic in user_mem_abort()
From: Anshuman Khandual @ 2026-03-31 3:30 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-6-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Extract the logic that computes the stage-2 protections and checks for
> various permission faults (e.g., execution faults on non-cacheable
> memory) into a new helper function, kvm_s2_fault_compute_prot(). This
> helper also handles injecting atomic/exclusive faults back into the
> guest when necessary.
>
> This refactoring step separates the permission computation from the
> mapping logic, making the main fault handler flow clearer.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 163 +++++++++++++++++++++++--------------------
> 1 file changed, 87 insertions(+), 76 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1f2c2200ccd8d..d1ffdce18631a 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1809,6 +1809,89 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> return 1;
> }
>
> +static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> +{
> + struct kvm *kvm = fault->vcpu->kvm;
> +
> + /*
> + * Check if this is non-struct page memory PFN, and cannot support
> + * CMOs. It could potentially be unsafe to access as cacheable.
> + */
> + if (fault->vm_flags & (VM_PFNMAP | VM_MIXEDMAP) && !pfn_is_map_memory(fault->pfn)) {
> + if (fault->is_vma_cacheable) {
> + /*
> + * Whilst the VMA owner expects cacheable mapping to this
> + * PFN, hardware also has to support the FWB and CACHE DIC
> + * features.
> + *
> + * ARM64 KVM relies on kernel VA mapping to the PFN to
> + * perform cache maintenance as the CMO instructions work on
> + * virtual addresses. VM_PFNMAP region are not necessarily
> + * mapped to a KVA and hence the presence of hardware features
> + * S2FWB and CACHE DIC are mandatory to avoid the need for
> + * cache maintenance.
> + */
> + if (!kvm_supports_cacheable_pfnmap())
> + return -EFAULT;
> + } else {
> + /*
> + * If the page was identified as device early by looking at
> + * the VMA flags, vma_pagesize is already representing the
> + * largest quantity we can map. If instead it was mapped
> + * via __kvm_faultin_pfn(), vma_pagesize is set to PAGE_SIZE
> + * and must not be upgraded.
> + *
> + * In both cases, we don't let transparent_hugepage_adjust()
> + * change things at the last minute.
> + */
> + fault->s2_force_noncacheable = true;
> + }
> + } else if (fault->logging_active && !fault->write_fault) {
> + /*
> + * Only actually map the page as writable if this was a write
> + * fault.
> + */
> + fault->writable = false;
> + }
> +
> + if (fault->exec_fault && fault->s2_force_noncacheable)
> + return -ENOEXEC;
> +
> + /*
> + * Guest performs atomic/exclusive operations on memory with unsupported
> + * attributes (e.g. ld64b/st64b on normal memory when no FEAT_LS64WB)
> + * and trigger the exception here. Since the memslot is valid, inject
> + * the fault back to the guest.
> + */
> + if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(fault->vcpu))) {
> + kvm_inject_dabt_excl_atomic(fault->vcpu, kvm_vcpu_get_hfar(fault->vcpu));
> + return 1;
> + }
> +
> + if (fault->nested)
> + adjust_nested_fault_perms(fault->nested, &fault->prot, &fault->writable);
> +
> + if (fault->writable)
> + fault->prot |= KVM_PGTABLE_PROT_W;
> +
> + if (fault->exec_fault)
> + fault->prot |= KVM_PGTABLE_PROT_X;
> +
> + if (fault->s2_force_noncacheable) {
> + if (fault->vfio_allow_any_uc)
> + fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> + else
> + fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> + } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> + fault->prot |= KVM_PGTABLE_PROT_X;
> + }
> +
> + if (fault->nested)
> + adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
> +
> + return 0;
> +}
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_s2_trans *nested,
> struct kvm_memory_slot *memslot, unsigned long hva,
> @@ -1863,68 +1946,14 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>
> ret = 0;
>
> - /*
> - * Check if this is non-struct page memory PFN, and cannot support
> - * CMOs. It could potentially be unsafe to access as cacheable.
> - */
> - if (fault->vm_flags & (VM_PFNMAP | VM_MIXEDMAP) && !pfn_is_map_memory(fault->pfn)) {
> - if (fault->is_vma_cacheable) {
> - /*
> - * Whilst the VMA owner expects cacheable mapping to this
> - * PFN, hardware also has to support the FWB and CACHE DIC
> - * features.
> - *
> - * ARM64 KVM relies on kernel VA mapping to the PFN to
> - * perform cache maintenance as the CMO instructions work on
> - * virtual addresses. VM_PFNMAP region are not necessarily
> - * mapped to a KVA and hence the presence of hardware features
> - * S2FWB and CACHE DIC are mandatory to avoid the need for
> - * cache maintenance.
> - */
> - if (!kvm_supports_cacheable_pfnmap())
> - ret = -EFAULT;
> - } else {
> - /*
> - * If the page was identified as device early by looking at
> - * the VMA flags, fault->vma_pagesize is already representing the
> - * largest quantity we can map. If instead it was mapped
> - * via __kvm_faultin_pfn(), fault->vma_pagesize is set to PAGE_SIZE
> - * and must not be upgraded.
> - *
> - * In both cases, we don't let transparent_hugepage_adjust()
> - * change things at the last minute.
> - */
> - fault->s2_force_noncacheable = true;
> - }
> - } else if (fault->logging_active && !fault->write_fault) {
> - /*
> - * Only actually map the page as fault->writable if this was a write
> - * fault.
> - */
> - fault->writable = false;
> + ret = kvm_s2_fault_compute_prot(fault);
> + if (ret == 1) {
> + ret = 1; /* fault injected */
> + goto out_put_page;
> }
> -
> - if (fault->exec_fault && fault->s2_force_noncacheable)
> - ret = -ENOEXEC;
> -
> if (ret)
> goto out_put_page;
>
> - /*
> - * Guest performs atomic/exclusive operations on memory with unsupported
> - * attributes (e.g. ld64b/st64b on normal memory when no FEAT_LS64WB)
> - * and trigger the exception here. Since the fault->memslot is valid, inject
> - * the fault back to the guest.
> - */
> - if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(fault->vcpu))) {
> - kvm_inject_dabt_excl_atomic(fault->vcpu, kvm_vcpu_get_hfar(fault->vcpu));
> - ret = 1;
> - goto out_put_page;
> - }
> -
> - if (fault->nested)
> - adjust_nested_fault_perms(fault->nested, &fault->prot, &fault->writable);
> -
> kvm_fault_lock(kvm);
> pgt = fault->vcpu->arch.hw_mmu->pgt;
> if (mmu_invalidate_retry(kvm, fault->mmu_seq)) {
> @@ -1961,24 +1990,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> }
> }
>
> - if (fault->writable)
> - fault->prot |= KVM_PGTABLE_PROT_W;
> -
> - if (fault->exec_fault)
> - fault->prot |= KVM_PGTABLE_PROT_X;
> -
> - if (fault->s2_force_noncacheable) {
> - if (fault->vfio_allow_any_uc)
> - fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> - else
> - fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> - } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> - fault->prot |= KVM_PGTABLE_PROT_X;
> - }
> -
> - if (fault->nested)
> - adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
> -
> /*
> * Under the premise of getting a FSC_PERM fault, we just need to relax
> * permissions only if fault->vma_pagesize equals fault->fault_granule. Otherwise,
^ permalink raw reply
* RE: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Hongxing Zhu @ 2026-03-31 3:37 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Qiang Yu
In-Reply-To: <5nom7wnhrr57jvb6komumg3fjkbavsq5ecz2pd43rc5tsmnqev@ag6ld453s2lu>
> -----Original Message-----
> From: Manivannan Sadhasivam <mani@kernel.org>
> Sent: 2026年3月30日 18:19
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> lpieralisi@kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> bhelgaas@google.com; s.hauer@pengutronix.de; kernel@pengutronix.de;
> festevam@gmail.com; linux-pci@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev;
> linux-kernel@vger.kernel.org; stable@vger.kernel.org; Qiang Yu
> <qiang.yu@oss.qualcomm.com>
> Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> i.MX7D/i.MX8M
>
> On Mon, Mar 30, 2026 at 09:02:57AM +0000, Hongxing Zhu wrote:
> > > -----Original Message-----
> > > From: Manivannan Sadhasivam <mani@kernel.org>
> > > Sent: 2026年3月30日 15:23
> > > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > > Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> > > lpieralisi@kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> > > bhelgaas@google.com; s.hauer@pengutronix.de;
> kernel@pengutronix.de;
> > > festevam@gmail.com; linux-pci@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org;
> > > imx@lists.linux.dev; linux-kernel@vger.kernel.org;
> > > stable@vger.kernel.org; Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> > > i.MX7D/i.MX8M
> > >
> > > + Qiang
> > >
> > > On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > > > The MSI trigger mechanism for endpoint devices connected to
> > > > i.MX7D, i.MX8MM, and i.MX8MQ PCIe root complex ports depends on
> > > > the MSI capability register settings in the root complex. Removing
> > > > the MSI capability breaks MSI functionality for these endpoints.
> > > >
> > >
> > > What is the relation between Root Port MSI and endpoint MSI?
> > > Endpoint MSIs should be routed to the platform MSI controller (DWC
> > > i.MSI-RX or External like
> > > GIC-ITS) independent of the Root Port MSI state.
> > Hi Mani:
> > Thank for your kindly concern.
> > The MSI controller (DWC i.MSI-RX) on i.MX7D, i.MX8MM, and i.MX8MQ
> > platforms requires the RC's MSI capability to remain enabled. Removing
> > it breaks MSI routing from endpoints to the platform MSI controller.
> >
>
> I understand that MSI is broken on your hardware, but I was trying to
> understand 'why' specifically. Because, Root Port MSI capability doesn't have
> anything to do with the endpoint MSIs. And since you mentioned that this
> issue happens only on one platform, could be that the hardware designers
> have mistakenly wired the Root Port's 'MSI Enable' to iMSI-RX's enable signal
> or something similar?
Yes, that makes sense. Based on the behavior we're seeing, it does appear to
be a hardware wiring issue specific to these platforms, possibly with the Root
Port's MSI Enable incorrectly connected to the iMSI-RX enable signal.
>
> If so, we can introduce a flag 'dw_pcie_rp::keep_rp_msi_en' or something
> similar, set it for affected SoCs and skip the capability removal in
> pcie-designware-host.c
Good idea! I'll implement this approach with the 'dw_pcie_rp::keep_rp_msi_en'
flag and skip the capability removal for affected SoCs in pcie-designware-host.c.
Thanks for the suggestion!
Best Regards
Richard Zhu
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox