* [PATCH 3/3] ASoC: imx-rpmsg: Set driver_name for snd_soc_card
From: Chancel Liu @ 2026-05-26 5:38 UTC (permalink / raw)
To: broonie, lgirdwood, robh, krzk+dt, conor+dt
Cc: shengjiu.wang, Xiubo.Lee, festevam, nicoleotsuka, perex, tiwai,
Frank.Li, s.hauer, linux-sound, devicetree, linux-arm-kernel, imx,
linux-kernel
In-Reply-To: <20260526053815.140008-1-chancel.liu@nxp.com>
Set driver_name to "imx-audio-rpmsg" for the i.MX RPMSG sound card.
This allows userspace audio configuration tools (e.g., UCM) to match
the card by driver name independently of the card name, which may vary
across board configurations.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
sound/soc/fsl/imx-rpmsg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-rpmsg.c b/sound/soc/fsl/imx-rpmsg.c
index e93ca31e75da..14adf55d9cb1 100644
--- a/sound/soc/fsl/imx-rpmsg.c
+++ b/sound/soc/fsl/imx-rpmsg.c
@@ -241,6 +241,7 @@ static int imx_rpmsg_probe(struct platform_device *pdev)
data->card.dapm_widgets = imx_rpmsg_dapm_widgets;
data->card.num_dapm_widgets = ARRAY_SIZE(imx_rpmsg_dapm_widgets);
data->card.late_probe = imx_rpmsg_late_probe;
+ data->card.driver_name = "imx-audio-rpmsg";
/*
* Inoder to use common api to get card name and audio routing.
* Use parent of_node for this device, revert it after finishing using
--
2.50.1
^ permalink raw reply related
* Re: [PATCH] media: imx-jpeg: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-26 5:52 UTC (permalink / raw)
To: Mirela Rabulea
Cc: Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Hans Verkuil, imx,
linux-media, linux-arm-kernel, linux-kernel
In-Reply-To: <824d2c59-d355-4f8c-a602-bc08e49d52e1@nxp.com>
Hi Mirela,
On Mon, 25 May 2026 at 21:57, Mirela Rabulea <mirela.rabulea@nxp.com> wrote:
>
> > [You don't often get email from lgs201920130244@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
> >
> >
> > mxc_jpeg_probe() allocates a video_device with video_device_alloc() and
> > releases it from the err_vdev_register error path if
> > video_register_device() fails.
> >
> > This can double free the video_device when __video_register_device()
> > reaches device_register() and that call fails:
> >
> > video_register_device()
> > -> __video_register_device()
> > -> device_register() fails
> > -> put_device(&vdev->dev)
> > -> v4l2_device_release()
> > -> vdev->release(vdev)
> > -> video_device_release(vdev)
> >
> > mxc_jpeg_probe()
> > -> err_vdev_register
> > -> video_device_release(jpeg->dec_vdev)
> >
> > Use video_device_release_empty() while registering the device so that
> > registration failure paths do not free jpeg->dec_vdev through
> > vdev->release(). mxc_jpeg_probe() then releases jpeg->dec_vdev exactly
> > once from err_vdev_register. Restore video_device_release() after
> > successful registration so the registered device keeps its normal lifetime
> > handling.
> >
> > This issue was found by a static analysis tool I am developing.
> >
> > Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
>
> Hi Guangshuo,
>
> sorry for the late response, so I assume this patch will be dropped in
> favor of a fix in v4l2-core, as per discussions here?:
>
> https://lore.kernel.org/linux-media/20260519090819.1041314-1-lgs201920130244@gmail.com/
>
> Thanks,
>
> Mirela
>
> > ---
> > drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
> > index b442dcba02e7..fe8a373576ef 100644
> > --- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
> > +++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
> > @@ -2943,7 +2943,7 @@ static int mxc_jpeg_probe(struct platform_device *pdev)
> > jpeg->dec_vdev->fops = &mxc_jpeg_fops;
> > jpeg->dec_vdev->ioctl_ops = &mxc_jpeg_ioctl_ops;
> > jpeg->dec_vdev->minor = -1;
> > - jpeg->dec_vdev->release = video_device_release;
> > + jpeg->dec_vdev->release = video_device_release_empty;
> > jpeg->dec_vdev->lock = &jpeg->lock; /* lock for ioctl serialization */
> > jpeg->dec_vdev->v4l2_dev = &jpeg->v4l2_dev;
> > jpeg->dec_vdev->vfl_dir = VFL_DIR_M2M;
> > @@ -2962,6 +2962,8 @@ static int mxc_jpeg_probe(struct platform_device *pdev)
> > dev_err(dev, "failed to register video device\n");
> > goto err_vdev_register;
> > }
> > + jpeg->dec_vdev->release = video_device_release;
> > +
> > if (mode == MXC_JPEG_ENCODE)
> > v4l2_info(&jpeg->v4l2_dev,
> > "encoder device registered as /dev/video%d (%d,%d)\n",
> > --
> > 2.43.0
> >
Yes, you are right. Please drop this patch.
As discussed in the related thread, this issue should be fixed in
v4l2-core instead of handling it in the imx-jpeg driver.
Thanks for checking.
Best regards,
Guangshuo
^ permalink raw reply
* [RFC PATCH net] netfilter: flowtable: fix offloaded ct timeout never being extended
From: Adrian Bente @ 2026-05-26 6:01 UTC (permalink / raw)
To: pablo, kadlec, fw, netfilter-devel
Cc: phil, davem, edumazet, kuba, pabeni, horms, nbd, sean.wang,
lorenzo, andrew+netdev, matthias.bgg, angelogioacchino.delregno,
daniel, coreteam, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, Adrian Bente
OpenWrt has recently migrated many platforms to kernel 6.18. On the
MediaTek platform, which supports hardware network offloading, WiFi
connections accelerated via the WED path were observed to drop after
roughly 300 seconds.
After several debugging sessions, assisted by the Claude LLM, the
problem was narrowed down as follows:
nf_flow_table_extend_ct_timeout() extends ct->timeout for offloaded
flows using:
cmpxchg(&ct->timeout, expires, new_timeout);
'expires' comes from nf_ct_expires(ct) and is a relative value, while
ct->timeout holds an absolute timestamp. The two are never equal, so
the cmpxchg always fails and the timeout is never extended.
This goes unnoticed for most flows, but a long-lived hardware (WED)
offloaded flow on MediaTek MT7986 eventually has ct->timeout decay to
zero, the conntrack entry is reaped and the connection breaks.
Compare against the current ct->timeout value instead.
This patch is sent as RFC: the diagnosis is verified on hardware and
the fix resolves the drop, but review of the chosen approach is
welcome.
Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout extension logic")
Signed-off-by: Adrian Bente <adibente@gmail.com>
---
net/netfilter/nf_flow_table_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/netfilter/nf_flow_table_core.c
+++ b/net/netfilter/nf_flow_table_core.c
@@ -541,8 +541,10 @@
* after this -- is fine, datapath is authoritative.
*/
if (new_timeout) {
+ u32 old = READ_ONCE(ct->timeout);
+
new_timeout += nfct_time_stamp;
- cmpxchg(&ct->timeout, expires, new_timeout);
+ cmpxchg(&ct->timeout, old, new_timeout);
}
}
--
2.46.0
^ permalink raw reply
* Re: [PATCH v23 5/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Krzysztof Kozlowski @ 2026-05-26 6:08 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, dri-devel,
devicetree, linux-kernel, linux-phy, imx, linux-arm-kernel, linux,
Alexander Stein, Ying Liu
In-Reply-To: <20260519-dcss-hdmi-upstreaming-v23-5-5615524a9c63@oss.nxp.com>
On Tue, May 19, 2026 at 02:42:28PM +0000, Laurentiu Palcu wrote:
> From: Sandor Yu <Sandor.yu@nxp.com>
>
> Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
>
> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/display/bridge/cdns,mhdp8501.yaml | 136 +++++++++++++++++++++
> 1 file changed, 136 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> new file mode 100644
> index 0000000000000..57e7e95199777
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence MHDP8501 DP/HDMI bridge
> +
> +maintainers:
> + - Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> +
> +description:
> + Cadence MHDP8501 DisplayPort/HDMI interface.
> +
> +properties:
> + compatible:
> + enum:
> + - fsl,imx8mq-mhdp8501-hdmi
> + - fsl,imx8mq-mhdp8501-dp
We are at v23 and you will be getting the same questions till you
finally fix that commit msg.
Why bus/connector is part of the compatible? Device is exactly the same.
Please read writing bindings - it covers exactly this case.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] wifi: mt76: mt7925: add wcid publish check in mt76_sta_add
From: Jiajia Liu @ 2026-05-26 6:08 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Michael Lo, Leon Yen
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Jiajia Liu
Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
to avoid reinitializing the wcid->poll_list for mt7925.
Found dev->sta_poll_list corruption when using mt7925 and 7.0-rc4.
According to the corruption information, prev->next was changed to itself.
wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
mt76_wcid_add_poll+0x95/0xd0 [mt76]
mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
mt7925_rx_check+0xa7/0xc0 [mt7925_common]
mt76_dma_rx_poll+0x50d/0x790 [mt76]
mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
---
Reproduced and tested using the script below over ssh. Roam between two
bssids with the same SSID on a router.
#!/bin/bash
set -ex
while :; do
num=$(sudo iw wlan0 scan | grep Polaris | wc -l)
if [ $num -eq 2 ]; then
break
fi
done
for i in $(seq 1 500); do
echo "index $i"
wpa_cli -i wlan0 roam 90:fb:5d:94:8b:e3
sleep 5
wpa_cli -i wlan0 roam 90:fb:5d:94:8b:e2
sleep 5
done
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 11 ++++++++---
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 3 +++
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 4ae5e4715a9c..83f4f941b890 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -1595,11 +1595,16 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
mtxq->wcid = wcid->idx;
}
- ewma_signal_init(&wcid->rssi);
- rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
+ if (!test_bit(MT_WCID_FLAG_DRV_PUBLISH, &wcid->flags)) {
+ ewma_signal_init(&wcid->rssi);
+ rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
+ mt76_wcid_init(wcid, phy->band_idx);
+ } else {
+ wcid->phy_idx = phy->band_idx;
+ }
+
phy->num_sta++;
- mt76_wcid_init(wcid, phy->band_idx);
out:
mutex_unlock(&dev->mutex);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 527bef97e122..8bfce686bff7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -361,6 +361,7 @@ enum mt76_wcid_flags {
MT_WCID_FLAG_PS,
MT_WCID_FLAG_4ADDR,
MT_WCID_FLAG_HDR_TRANS,
+ MT_WCID_FLAG_DRV_PUBLISH,
};
#define MT76_N_WCIDS 1088
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 73d3722739d0..35b5c718475c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -1102,6 +1102,9 @@ int mt7925_mac_sta_add(struct mt76_dev *mdev, struct ieee80211_vif *vif,
&msta->deflink);
}
+ if (!err)
+ set_bit(MT_WCID_FLAG_DRV_PUBLISH, &msta->deflink.wcid.flags);
+
return err;
}
EXPORT_SYMBOL_GPL(mt7925_mac_sta_add);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v23 5/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Krzysztof Kozlowski @ 2026-05-26 6:10 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, dri-devel,
devicetree, linux-kernel, linux-phy, imx, linux-arm-kernel, linux,
Alexander Stein, Ying Liu
In-Reply-To: <20260526-golden-bobcat-of-aurora-fd1fef@quoll>
On 26/05/2026 08:08, Krzysztof Kozlowski wrote:
> On Tue, May 19, 2026 at 02:42:28PM +0000, Laurentiu Palcu wrote:
>> From: Sandor Yu <Sandor.yu@nxp.com>
>>
>> Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
>>
>> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
>> ---
>> .../bindings/display/bridge/cdns,mhdp8501.yaml | 136 +++++++++++++++++++++
>> 1 file changed, 136 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
>> new file mode 100644
>> index 0000000000000..57e7e95199777
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
Filename must match compatible.
>> @@ -0,0 +1,136 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Cadence MHDP8501 DP/HDMI bridge
>> +
>> +maintainers:
>> + - Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
>> +
>> +description:
>> + Cadence MHDP8501 DisplayPort/HDMI interface.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - fsl,imx8mq-mhdp8501-hdmi
>> + - fsl,imx8mq-mhdp8501-dp
>
> We are at v23 and you will be getting the same questions till you
> finally fix that commit msg.
>
> Why bus/connector is part of the compatible? Device is exactly the same.
> Please read writing bindings - it covers exactly this case.
And this was BTW completely different in previous version.
NAK
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v15 0/3] of: parsing of multi #{iommu,msi}-cells in maps
From: Krzysztof Kozlowski @ 2026-05-26 6:12 UTC (permalink / raw)
To: Vijayanand Jitta
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia,
linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260520-parse_iommu_cells-v15-0-b5f99ad4e7e8@oss.qualcomm.com>
On Wed, May 20, 2026 at 01:32:39PM +0530, Vijayanand Jitta wrote:
> So far our parsing of {iommu,msi}-map properties has always blindly
> assumed that the output specifiers will always have exactly 1 cell.
> This typically does happen to be the case, but is not actually enforced
> (and the PCI msi-map binding even explicitly states support for 0 or 1
> cells) - as a result we've now ended up with dodgy DTs out in the field
> which depend on this behaviour to map a 1-cell specifier for a 2-cell
> provider, despite that being bogus per the bindings themselves.
>
> Since there is some potential use[1] in being able to map at least
> single input IDs to multi-cell output specifiers (and properly support
> 0-cell outputs as well), add support for properly parsing and using the
> target nodes' #cells values, albeit with the unfortunate complication of
> still having to work around expectations of the old behaviour too.
> -- Robin.
>
> Unlike single #{}-cell, it is complex to establish a linear relation
> between input 'id' and output specifier for multi-cell properties, thus
> it is always expected that len never going to be > 1.
>
> These changes have been tested on QEMU for the arm64 architecture.
So there is no real user for that. That's unconvincing. I would assume
that at least you have real user where you test it.
If you want to speed up acceptance of your patches, then also I would
prefer to see at least one more user, beside Qualcomm. IOW, show how you
solve other people problems, not only yours.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] clk: samsung: exynos5410: fix refcount leak
From: Alexander A. Klimov @ 2026-05-26 6:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Michael Turquette, Stephen Boyd, Brian Masney,
open list:SAMSUNG SOC CLOCK DRIVERS,
open list:COMMON CLK FRAMEWORK,
moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES,
open list
Cc: Alexander A. Klimov
Every value returned from of_clk_get() is supposed to be cleaned up
via clk_put() once not needed anymore.
Fixes: be95d2c7d918 ("clk: samsung: Add support for EPLL on exynos5410")
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
---
drivers/clk/samsung/clk-exynos5410.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5410.c b/drivers/clk/samsung/clk-exynos5410.c
index baa9988c7bb7..0cd9b0392cf5 100644
--- a/drivers/clk/samsung/clk-exynos5410.c
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -269,8 +269,12 @@ static void __init exynos5410_clk_init(struct device_node *np)
{
struct clk *xxti = of_clk_get(np, 0);
- if (!IS_ERR(xxti) && clk_get_rate(xxti) == 24 * MHZ)
- exynos5410_plls[epll].rate_table = exynos5410_pll2550x_24mhz_tbl;
+ if (!IS_ERR(xxti)) {
+ if (clk_get_rate(xxti) == 24 * MHZ)
+ exynos5410_plls[epll].rate_table =
+ exynos5410_pll2550x_24mhz_tbl;
+ clk_put(xxti);
+ }
samsung_cmu_register_one(np, &cmu);
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/2] gpio: mxc: use BIT() macro
From: Alexander Stein @ 2026-05-26 6:35 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Alexander Stein, linux-gpio, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260526063504.25916-1-alexander.stein@ew.tq-group.com>
Replace the open-code with the BIT() macro.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
* Improved commit message as suggested by Frank
* Collected Frank's
drivers/gpio/gpio-mxc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 12f11a6c96653..7e2690d92df6f 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -330,13 +330,13 @@ static int gpio_set_wake_irq(struct irq_data *d, u32 enable)
ret = enable_irq_wake(port->irq_high);
else
ret = enable_irq_wake(port->irq);
- port->wakeup_pads |= (1 << gpio_idx);
+ port->wakeup_pads |= BIT(gpio_idx);
} else {
if (port->irq_high && (gpio_idx >= 16))
ret = disable_irq_wake(port->irq_high);
else
ret = disable_irq_wake(port->irq);
- port->wakeup_pads &= ~(1 << gpio_idx);
+ port->wakeup_pads &= ~BIT(gpio_idx);
}
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/2] gpio: mxc: fix irq_high handling
From: Alexander Stein @ 2026-05-26 6:35 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Alexander Stein, linux-gpio, imx, linux-arm-kernel, linux-kernel
If port->irq_high is -1 (fsl,imx21-gpio compatible) and gpio_idx is >= 16
enable_irq_wake() is called with -1 which is wrong.
Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
I don't have hardware to test. I just noticed this by code review.
Changes in v2:
* Collected Frank's R-b
drivers/gpio/gpio-mxc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 647b6f4861b74..12f11a6c96653 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -469,7 +469,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
* the handler is needed only once, but doing it for every port
* is more robust and easier.
*/
- port->irq_high = -1;
+ port->irq_high = 0;
port->mx_irq_handler = mx2_gpio_irq_handler;
} else
port->mx_irq_handler = mx3_gpio_irq_handler;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v23 5/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Laurentiu Palcu @ 2026-05-26 6:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, dri-devel,
devicetree, linux-kernel, linux-phy, imx, linux-arm-kernel, linux,
Alexander Stein, Ying Liu
In-Reply-To: <2301c829-5203-47ea-bc26-09f9e3b459a4@kernel.org>
Hi Krzysztof,
On Tue, May 26, 2026 at 08:10:43AM +0200, Krzysztof Kozlowski wrote:
> On 26/05/2026 08:08, Krzysztof Kozlowski wrote:
> > On Tue, May 19, 2026 at 02:42:28PM +0000, Laurentiu Palcu wrote:
> >> From: Sandor Yu <Sandor.yu@nxp.com>
> >>
> >> Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
> >>
> >> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> >> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> >> ---
> >> .../bindings/display/bridge/cdns,mhdp8501.yaml | 136 +++++++++++++++++++++
> >> 1 file changed, 136 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> >> new file mode 100644
> >> index 0000000000000..57e7e95199777
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
>
> Filename must match compatible.
>
> >> @@ -0,0 +1,136 @@
> >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Cadence MHDP8501 DP/HDMI bridge
> >> +
> >> +maintainers:
> >> + - Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> >> +
> >> +description:
> >> + Cadence MHDP8501 DisplayPort/HDMI interface.
> >> +
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - fsl,imx8mq-mhdp8501-hdmi
> >> + - fsl,imx8mq-mhdp8501-dp
> >
> > We are at v23 and you will be getting the same questions till you
> > finally fix that commit msg.
> >
> > Why bus/connector is part of the compatible? Device is exactly the same.
> > Please read writing bindings - it covers exactly this case.
The device is the same but, based on the FW, it can act as DP or HDMI
controller. For 8MQ, the FW is loaded by the ROM. I did look at the writing
bindings doc and I assume you're referring to this exact paragraph:
- DON'T use bus suffixes to encode the type of interface device is using.
The parent bus node already implies that interface. DON'T add the type of
device, if the device cannot be anything else.
I don't see how is this applicable in this particular case. The parent bus node
does not imply the interface and, as I explained previously, the device can be
either DP or HDMI.
>
> And this was BTW completely different in previous version.
It was indeed. However, the problem is that there's no way to detect
from the controller's registers if we're in DP mode or HDMI. In v22 I
added a DT traversal function to detect the connector type from the last
node but it was suggested to me that having 2 compatibles would be a
much cleaner solution and I agree.
--
Thanks,
Laurentiu
^ permalink raw reply
* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
From: Joonwon Kang @ 2026-05-26 6:58 UTC (permalink / raw)
To: jgg
Cc: Alexander.Grest, alexander.shishkin, amhetre, baolu.lu, bp,
dave.hansen, easwar.hariharan, hpa, iommu, jacob.jun.pan,
joonwonkang, joro, jpb, kas, kees, kevin.tian, linux-arm-kernel,
linux-kernel, mingo, nicolinc, peterz, praan, robin.murphy,
ryasuoka, smostafa, sohil.mehta, tglx, will, x86, xin
In-Reply-To: <20260525164715.GA2487554@ziepe.ca>
> On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
>
> > Currently, the only known expected user of the new kAPI is our team. Since
> > I test if the patch resolves our problem before sending it, I believe it
> > should be good enough. Do you mean more than our team by "accompanied
> > users"?
>
> He means you cannot send patches like this that only serve OOT drivers
> to the mainline kernel.
Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
deferring the patch submission until we find a new in-tree user of the
new kAPI? I believe we will not make our module in-tree anytime soon.
Or, is it like I still can send the patch and get it reviewed although we
cannot merge it to the mainline?
Thanks,
Joonwon Kang
^ permalink raw reply
* [PATCH RFC net-next v2] net: airoha: Add TCP LRO support
From: Lorenzo Bianconi @ 2026-05-26 6:58 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
Add hardware TCP Large Receive Offload (LRO) support to the airoha_eth
driver, leveraging the EN7581/AN7583 SoC's 8 dedicated LRO hardware queues
mapped to RX queues 24–31. LRO hw offloading does not support
Scatter-Gather (SG) so it is required to increase the page_pool allocation
order to 2 for RX queues 24–31 (LRO queues).
Performance comparison between GRO and hw LRO has been carried out using
a 10Gbps NIC:
GRO: ~2.7 Gbps
LRO: ~8.1 Gbps
Please note with respect to the previous implementation, page_pool
allocation order has been reduced from 5 to 2.
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in RFC v2:
- Improve performances fixing buf_size computation.
- Fix possible overflow in REG_CDM_LRO_LIMIT() register configuration.
- Require the device to be not running before configuring LRO.
- Fix configuration order in airoha_fe_lro_is_enabled().
- Check skb header length in airoha_qdma_lro_rx_process().
- Do not check net_device feature in airoha_qdma_rx_process() before
executing airoha_qdma_lro_rx_process() but rely on
airoha_qdma_lro_rx_process() logic.
- Fix possible double recycle in airoha_qdma_rx_process() for LRO
packets.
- Always use AIROHA_RXQ_LRO_MAX_AGG_COUNT macro for max LRO aggregated
fragments in airoha_fe_lro_init_rx_queue().
- Link to v1: https://lore.kernel.org/r/20260520-airoha-eth-lro-v1-1-129cc33766e9@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 217 +++++++++++++++++++++++++++---
drivers/net/ethernet/airoha/airoha_eth.h | 24 ++++
drivers/net/ethernet/airoha/airoha_regs.h | 22 ++-
3 files changed, 247 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 6418fe0c9f80..c8e5abe8942a 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -12,6 +12,7 @@
#include <net/dst_metadata.h>
#include <net/page_pool/helpers.h>
#include <net/pkt_cls.h>
+#include <net/tcp.h>
#include <uapi/linux/ppp_defs.h>
#include "airoha_regs.h"
@@ -431,6 +432,48 @@ static void airoha_fe_crsn_qsel_init(struct airoha_eth *eth)
CDM_CRSN_QSEL_Q1));
}
+static void airoha_fe_lro_init_rx_queue(struct airoha_eth *eth, int qdma_id,
+ int lro_queue_index, int qid,
+ int buf_size)
+{
+ int id = qdma_id + 1;
+
+ airoha_fe_rmw(eth, REG_CDM_LRO_LIMIT(id),
+ CDM_LRO_AGG_NUM_MASK | CDM_LRO_AGG_SIZE_MASK,
+ FIELD_PREP(CDM_LRO_AGG_SIZE_MASK, buf_size) |
+ FIELD_PREP(CDM_LRO_AGG_NUM_MASK,
+ AIROHA_RXQ_LRO_MAX_AGG_COUNT));
+ airoha_fe_rmw(eth, REG_CDM_LRO_AGE_TIME(id),
+ CDM_LRO_AGE_TIME_MASK | CDM_LRO_AGG_TIME_MASK,
+ FIELD_PREP(CDM_LRO_AGE_TIME_MASK,
+ AIROHA_RXQ_LRO_MAX_AGE_TIME) |
+ FIELD_PREP(CDM_LRO_AGG_TIME_MASK,
+ AIROHA_RXQ_LRO_MAX_AGG_TIME));
+ airoha_fe_rmw(eth, REG_CDM_LRO_RXQ(id, lro_queue_index),
+ LRO_RXQ_MASK(lro_queue_index),
+ __field_prep(LRO_RXQ_MASK(lro_queue_index), qid));
+ airoha_fe_set(eth, REG_CDM_LRO_EN(id), BIT(lro_queue_index));
+}
+
+static void airoha_fe_lro_disable(struct airoha_eth *eth, int qdma_id)
+{
+ int i, id = qdma_id + 1;
+
+ airoha_fe_clear(eth, REG_CDM_LRO_EN(id), LRO_RXQ_EN_MASK);
+ airoha_fe_clear(eth, REG_CDM_LRO_LIMIT(id),
+ CDM_LRO_AGG_NUM_MASK | CDM_LRO_AGG_SIZE_MASK);
+ airoha_fe_clear(eth, REG_CDM_LRO_AGE_TIME(id),
+ CDM_LRO_AGE_TIME_MASK | CDM_LRO_AGG_TIME_MASK);
+ for (i = 0; i < AIROHA_MAX_NUM_LRO_QUEUES; i++)
+ airoha_fe_clear(eth, REG_CDM_LRO_RXQ(id, i), LRO_RXQ_MASK(i));
+}
+
+static bool airoha_fe_lro_is_enabled(struct airoha_eth *eth, int qdma_id)
+{
+ return airoha_fe_get(eth, REG_CDM_LRO_EN(qdma_id + 1),
+ LRO_RXQ_EN_MASK);
+}
+
static int airoha_fe_init(struct airoha_eth *eth)
{
airoha_fe_maccr_init(eth);
@@ -587,6 +630,85 @@ static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
return port >= ARRAY_SIZE(eth->ports) ? -EINVAL : port;
}
+static int airoha_qdma_lro_rx_process(struct airoha_queue *q,
+ struct airoha_qdma_desc *desc)
+{
+ u32 desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
+ u32 msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
+ u32 msg2 = le32_to_cpu(READ_ONCE(desc->msg2));
+ u32 msg3 = le32_to_cpu(READ_ONCE(desc->msg3));
+ struct sk_buff *skb = q->skb;
+ u32 len, th_off, tcp_ack_seq;
+ u16 tcp_win, l2_len;
+ struct tcphdr *th;
+ bool ipv4, ipv6;
+
+ if (FIELD_GET(QDMA_ETH_RXMSG_AGG_COUNT_MASK, msg2) <= 1)
+ return 0;
+
+ ipv4 = FIELD_GET(QDMA_ETH_RXMSG_IP4_MASK, msg1);
+ ipv6 = FIELD_GET(QDMA_ETH_RXMSG_IP6_MASK, msg1);
+ if (!ipv4 && !ipv6)
+ return -EOPNOTSUPP;
+
+ l2_len = FIELD_GET(QDMA_ETH_RXMSG_L2_LEN_MASK, msg2);
+ len = FIELD_GET(QDMA_DESC_LEN_MASK, desc_ctrl);
+ if (ipv4) {
+ struct iphdr *iph;
+
+ if (!pskb_may_pull(skb, l2_len + sizeof(*iph)))
+ return -EINVAL;
+
+ iph = (struct iphdr *)(skb->data + l2_len);
+ if (iph->protocol != IPPROTO_TCP)
+ return -EOPNOTSUPP;
+
+ iph->tot_len = cpu_to_be16(len - l2_len);
+ iph->check = 0;
+ iph->check = ip_fast_csum((void *)iph, iph->ihl);
+ th_off = l2_len + (iph->ihl << 2);
+ } else {
+ struct ipv6hdr *ip6h;
+
+ if (!pskb_may_pull(skb, l2_len + sizeof(*ip6h)))
+ return -EINVAL;
+
+ ip6h = (struct ipv6hdr *)(skb->data + l2_len);
+ if (ip6h->nexthdr != NEXTHDR_TCP)
+ return -EOPNOTSUPP;
+
+ ip6h->payload_len = cpu_to_be16(len - l2_len - sizeof(*ip6h));
+ th_off = l2_len + sizeof(*ip6h);
+ }
+
+ tcp_win = FIELD_GET(QDMA_ETH_RXMSG_TCP_WIN_MASK, msg3);
+ tcp_ack_seq = le32_to_cpu(READ_ONCE(desc->data));
+
+ if (!pskb_may_pull(skb, th_off + sizeof(*th)))
+ return -EINVAL;
+
+ th = (struct tcphdr *)(skb->data + th_off);
+ th->ack_seq = cpu_to_be32(tcp_ack_seq);
+ th->window = cpu_to_be16(tcp_win);
+
+ /* Check tcp timestamp option */
+ if (th->doff == (sizeof(*th) + TCPOLEN_TSTAMP_ALIGNED) / 4) {
+ __be32 *topt = (__be32 *)(th + 1);
+
+ if (*topt == cpu_to_be32((TCPOPT_NOP << 24) |
+ (TCPOPT_NOP << 16) |
+ (TCPOPT_TIMESTAMP << 8) |
+ TCPOLEN_TIMESTAMP)) {
+ __le32 tcp_ts_reply = READ_ONCE(desc->tcp_ts_reply);
+
+ put_unaligned_be32(le32_to_cpu(tcp_ts_reply),
+ topt + 2);
+ }
+ }
+
+ return 0;
+}
+
static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
{
enum dma_data_direction dir = page_pool_get_dma_dir(q->page_pool);
@@ -634,11 +756,15 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
skb_reserve(q->skb, AIROHA_RX_HEADROOM);
__skb_put(q->skb, len);
- skb_mark_for_recycle(q->skb);
q->skb->dev = port->dev;
- q->skb->protocol = eth_type_trans(q->skb, port->dev);
q->skb->ip_summed = CHECKSUM_UNNECESSARY;
skb_record_rx_queue(q->skb, qid);
+
+ if (airoha_qdma_lro_rx_process(q, desc) < 0)
+ goto free_frag;
+
+ q->skb->protocol = eth_type_trans(q->skb, port->dev);
+ skb_mark_for_recycle(q->skb);
} else { /* scattered frame */
struct skb_shared_info *shinfo = skb_shinfo(q->skb);
int nr_frags = shinfo->nr_frags;
@@ -727,23 +853,18 @@ static int airoha_qdma_rx_napi_poll(struct napi_struct *napi, int budget)
static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
struct airoha_qdma *qdma, int ndesc)
{
- const struct page_pool_params pp_params = {
- .order = 0,
- .pool_size = 256,
+ struct page_pool_params pp_params = {
.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
.dma_dir = DMA_FROM_DEVICE,
- .max_len = PAGE_SIZE,
.nid = NUMA_NO_NODE,
.dev = qdma->eth->dev,
.napi = &q->napi,
};
+ int pp_order, qid = q - &qdma->q_rx[0], thr;
struct airoha_eth *eth = qdma->eth;
- int qid = q - &qdma->q_rx[0], thr;
dma_addr_t dma_addr;
- q->buf_size = PAGE_SIZE / 2;
q->qdma = qdma;
-
q->entry = devm_kzalloc(eth->dev, ndesc * sizeof(*q->entry),
GFP_KERNEL);
if (!q->entry)
@@ -754,6 +875,11 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
if (!q->desc)
return -ENOMEM;
+ pp_order = airoha_qdma_is_lro_queue(q) ? AIROHA_LRO_PAGE_ORDER : 0;
+ pp_params.order = pp_order;
+ pp_params.pool_size = 256;
+ pp_params.max_len = PAGE_SIZE << pp_order;
+
q->page_pool = page_pool_create(&pp_params);
if (IS_ERR(q->page_pool)) {
int err = PTR_ERR(q->page_pool);
@@ -762,6 +888,8 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
return err;
}
+ q->buf_size = airoha_qdma_is_lro_queue(q) ? pp_params.max_len
+ : pp_params.max_len / 2;
q->ndesc = ndesc;
netif_napi_add(eth->napi_dev, &q->napi, airoha_qdma_rx_napi_poll);
@@ -1993,6 +2121,67 @@ int airoha_get_fe_port(struct airoha_gdm_port *port)
}
}
+static int airoha_dev_set_features(struct net_device *dev,
+ netdev_features_t features)
+{
+ netdev_features_t diff = dev->features ^ features;
+ struct airoha_gdm_port *port = netdev_priv(dev);
+ struct airoha_qdma *qdma = port->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int qdma_id = qdma - ð->qdma[0];
+ int i;
+
+ if (!(diff & NETIF_F_LRO))
+ return 0;
+
+ if (netif_running(dev))
+ return -EBUSY;
+
+ /* reset LRO configuration */
+ if (features & NETIF_F_LRO) {
+ int lro_queue_index = 0;
+
+ if (airoha_fe_lro_is_enabled(eth, qdma_id))
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(qdma->q_rx); i++) {
+ struct airoha_queue *q = &qdma->q_rx[i];
+ u32 size;
+
+ if (!q->ndesc)
+ continue;
+
+ if (!airoha_qdma_is_lro_queue(q))
+ continue;
+
+ size = SKB_WITH_OVERHEAD(AIROHA_RX_LEN(q->buf_size));
+ size = min_t(u32, size, CDM_LRO_AGG_SIZE_MASK);
+ airoha_fe_lro_init_rx_queue(eth, qdma_id,
+ lro_queue_index, i, size);
+ lro_queue_index++;
+ }
+ } else {
+ for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
+ struct airoha_gdm_port *p = eth->ports[i];
+
+ if (!p)
+ continue;
+
+ if (p->qdma != qdma)
+ continue;
+
+ if (p->dev == dev)
+ continue;
+
+ if (p->dev->features & NETIF_F_LRO)
+ return 0;
+ }
+ airoha_fe_lro_disable(eth, qdma_id);
+ }
+
+ return 0;
+}
+
static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
struct net_device *dev)
{
@@ -2892,6 +3081,7 @@ static const struct net_device_ops airoha_netdev_ops = {
.ndo_stop = airoha_dev_stop,
.ndo_change_mtu = airoha_dev_change_mtu,
.ndo_select_queue = airoha_dev_select_queue,
+ .ndo_set_features = airoha_dev_set_features,
.ndo_start_xmit = airoha_dev_xmit,
.ndo_get_stats64 = airoha_dev_get_stats64,
.ndo_set_mac_address = airoha_dev_set_macaddr,
@@ -2989,12 +3179,9 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
dev->ethtool_ops = &airoha_ethtool_ops;
dev->max_mtu = AIROHA_MAX_MTU;
dev->watchdog_timeo = 5 * HZ;
- dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
- NETIF_F_TSO6 | NETIF_F_IPV6_CSUM |
- NETIF_F_SG | NETIF_F_TSO |
- NETIF_F_HW_TC;
- dev->features |= dev->hw_features;
- dev->vlan_features = dev->hw_features;
+ dev->hw_features = AIROHA_HW_FEATURES | NETIF_F_LRO;
+ dev->features |= AIROHA_HW_FEATURES;
+ dev->vlan_features = AIROHA_HW_FEATURES;
dev->dev.of_node = np;
SET_NETDEV_DEV(dev, eth->dev);
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index d3781103abb5..aed5077d3db5 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -43,6 +43,18 @@
(_n) == 15 ? 128 : \
(_n) == 0 ? 1024 : 16)
+#define AIROHA_LRO_PAGE_ORDER 2
+#define AIROHA_MAX_NUM_LRO_QUEUES 8
+#define AIROHA_RXQ_LRO_EN_MASK 0xff000000
+#define AIROHA_RXQ_LRO_MAX_AGG_COUNT 64
+#define AIROHA_RXQ_LRO_MAX_AGG_TIME 100
+#define AIROHA_RXQ_LRO_MAX_AGE_TIME 2000 /* 1ms */
+
+#define AIROHA_HW_FEATURES \
+ (NETIF_F_IP_CSUM | NETIF_F_RXCSUM | \
+ NETIF_F_TSO6 | NETIF_F_IPV6_CSUM | \
+ NETIF_F_SG | NETIF_F_TSO | NETIF_F_HW_TC)
+
#define PSE_RSV_PAGES 128
#define PSE_QUEUE_RSV_PAGES 64
@@ -661,6 +673,18 @@ static inline bool airoha_is_7583(struct airoha_eth *eth)
return eth->soc->version == 0x7583;
}
+static inline bool airoha_qdma_is_lro_queue(struct airoha_queue *q)
+{
+ struct airoha_qdma *qdma = q->qdma;
+ int qid = q - &qdma->q_rx[0];
+
+ /* EN7581 SoC supports at most 8 LRO rx queues */
+ BUILD_BUG_ON(hweight32(AIROHA_RXQ_LRO_EN_MASK) >
+ AIROHA_MAX_NUM_LRO_QUEUES);
+
+ return !!(AIROHA_RXQ_LRO_EN_MASK & BIT(qid));
+}
+
int airoha_get_fe_port(struct airoha_gdm_port *port);
bool airoha_is_valid_gdm_port(struct airoha_eth *eth,
struct airoha_gdm_port *port);
diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
index 436f3c8779c1..dfc786583774 100644
--- a/drivers/net/ethernet/airoha/airoha_regs.h
+++ b/drivers/net/ethernet/airoha/airoha_regs.h
@@ -122,6 +122,20 @@
#define CDM_CRSN_QSEL_REASON_MASK(_n) \
GENMASK(4 + (((_n) % 4) << 3), (((_n) % 4) << 3))
+#define REG_CDM_LRO_RXQ(_n, _m) (CDM_BASE(_n) + 0x78 + ((_m) & 0x4))
+#define LRO_RXQ_MASK(_n) GENMASK(4 + (((_n) & 0x3) << 3), ((_n) & 0x3) << 3)
+
+#define REG_CDM_LRO_EN(_n) (CDM_BASE(_n) + 0x80)
+#define LRO_RXQ_EN_MASK GENMASK(7, 0)
+
+#define REG_CDM_LRO_LIMIT(_n) (CDM_BASE(_n) + 0x84)
+#define CDM_LRO_AGG_NUM_MASK GENMASK(23, 16)
+#define CDM_LRO_AGG_SIZE_MASK GENMASK(15, 0)
+
+#define REG_CDM_LRO_AGE_TIME(_n) (CDM_BASE(_n) + 0x88)
+#define CDM_LRO_AGE_TIME_MASK GENMASK(31, 16)
+#define CDM_LRO_AGG_TIME_MASK GENMASK(15, 0)
+
#define REG_GDM_FWD_CFG(_n) GDM_BASE(_n)
#define GDM_PAD_EN_MASK BIT(28)
#define GDM_DROP_CRC_ERR_MASK BIT(23)
@@ -883,9 +897,15 @@
#define QDMA_ETH_RXMSG_SPORT_MASK GENMASK(25, 21)
#define QDMA_ETH_RXMSG_CRSN_MASK GENMASK(20, 16)
#define QDMA_ETH_RXMSG_PPE_ENTRY_MASK GENMASK(15, 0)
+/* RX MSG2 */
+#define QDMA_ETH_RXMSG_AGG_COUNT_MASK GENMASK(31, 24)
+#define QDMA_ETH_RXMSG_L2_LEN_MASK GENMASK(6, 0)
+/* RX MSG3 */
+#define QDMA_ETH_RXMSG_AGG_LEN_MASK GENMASK(31, 16)
+#define QDMA_ETH_RXMSG_TCP_WIN_MASK GENMASK(15, 0)
struct airoha_qdma_desc {
- __le32 rsv;
+ __le32 tcp_ts_reply;
__le32 ctrl;
__le32 addr;
__le32 data;
---
base-commit: 3baa7ba4ab98af452925926ffc2ee58c683e3f28
change-id: 20260520-airoha-eth-lro-a5d1c3631811
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* RE: [PATCH v2 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus
From: Carlos Song (OSS) @ 2026-05-26 7:00 UTC (permalink / raw)
To: Vincent Jardin, Oleksij Rempel, Pengutronix Kernel Team,
Andi Shyti, Frank Li, Sascha Hauer, Fabio Estevam, Wolfram Sang,
Kaushal Butala, Shawn Guo, Stefan Eichenberger
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260525-for-upstream-i2c-lx2160-fix-v1-v2-0-26a3cc8cd055@free.fr>
> -----Original Message-----
> From: Vincent Jardin <vjardin@free.fr>
> Sent: Tuesday, May 26, 2026 12:43 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Andi Shyti <andi.shyti@kernel.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Wolfram Sang <wsa@kernel.org>; Kaushal Butala
> <kaushalkernelmailinglist@gmail.com>; Shawn Guo
> <shawn.guo@freescale.com>; Stefan Eichenberger
> <stefan.eichenberger@toradex.com>
> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Vincent
> Jardin <vjardin@free.fr>; stable@vger.kernel.org
> Subject: [PATCH v2 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus
>
> [You don't often get email from vjardin@free.fr. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> i2c-imx rejects a SMBus Block Read byte count of 0 (valid per SMBus 3.1
> 6.5.7) and it returns without a NACK+STOP, leaving the target holding SDA so the
> bus is stuck until a power cycle occur.
>
> The same bug is occuring with two independently introduced spots, so the fix is
> two patches with their respective Fixes: tags and backport ranges:
>
> 1/2 atomic/polling path Fixes: 8e8782c71595 v3.16+
> 2/2 IRQ-driven state machine Fixes: 5f5c2d4579ca v6.13+
>
Hi Vincent,
Thanks for working on this fix, this looks good to me.
SMBus block reads with a length of 0 seem quite uncommon in practice.
Was this triggered by a specific device behavior, or mainly found
during boundary / compliance testing?
Regarding the handling of len == 0,
I see that the patch sets:
msg->buf[0] = 0;
msg->len = 2;
It relies on the last-byte STOP handling together with TXAK. It will help I2C-IMX generate NACK + STOP and
release the bus, right? len = 0 is a legal behavior, So it go into a successful path.
But len > I2C_SMBUS_BLOCK_MAX is abnormal behavior. So it go into a fail path.
Do I understand it right?
Also, if possible could you briefly describe how you validated this change
(e.g. test setup or steps, with and without the fix)?
Thanks again for the fix.
Carlos
> ---
> Changes in v2:
> - Handle when count > I2C_SMBUS_BLOCK_MAX the same way as count == 0
> Reported by the Sashiko AI review on v1.
>
> ---
> Vincent Jardin (2):
> i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
> i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)
>
> drivers/i2c/busses/i2c-imx.c | 36 +++++++++++++++++++++++++++++++++---
> 1 file changed, 33 insertions(+), 3 deletions(-)
> ---
> base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6
> change-id: 20260525-for-upstream-i2c-lx2160-fix-v1-0cba0a0093e5
>
> Best regards,
> --
> Vincent Jardin <vjardin@free.fr>
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: meson-axg: Fix whitespace issue
From: Neil Armstrong @ 2026-05-26 7:14 UTC (permalink / raw)
To: Jun Yan, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260524154954.385778-1-jerrysteve1101@gmail.com>
On 5/24/26 17:49, Jun Yan wrote:
> Clean up whitespace misalignment in meson-axg-gpio.h
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> include/dt-bindings/gpio/meson-axg-gpio.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/dt-bindings/gpio/meson-axg-gpio.h b/include/dt-bindings/gpio/meson-axg-gpio.h
> index 25bb1fffa97a..a0d42bcd9bd3 100644
> --- a/include/dt-bindings/gpio/meson-axg-gpio.h
> +++ b/include/dt-bindings/gpio/meson-axg-gpio.h
> @@ -23,7 +23,7 @@
> #define GPIOAO_11 11
> #define GPIOAO_12 12
> #define GPIOAO_13 13
> -#define GPIO_TEST_N 14
> +#define GPIO_TEST_N 14
>
> /* Second GPIO chip */
> #define GPIOZ_0 0
> @@ -52,7 +52,7 @@
> #define BOOT_12 23
> #define BOOT_13 24
> #define BOOT_14 25
> -#define GPIOA_0 26
> +#define GPIOA_0 26
> #define GPIOA_1 27
> #define GPIOA_2 28
> #define GPIOA_3 29
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH] drm/meson: clean up KMS polling on register failure
From: Neil Armstrong @ 2026-05-26 7:16 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
dri-devel, linux-amlogic, linux-arm-kernel, linux-kernel, stable,
Ijae Kim
In-Reply-To: <20260524160657.17802-1-mhun512@gmail.com>
On 5/24/26 18:01, Myeonghun Pak wrote:
> meson_drv_bind_master() starts the KMS polling helper before registering
> the DRM device. If drm_dev_register() fails, probe unwinds the IRQ and
> DRM device without stopping the polling helper.
>
> Call drm_kms_helper_poll_fini() on that failure path before freeing the
> IRQ.
>
> This issue was identified during our ongoing static-analysis research while
> reviewing kernel code.
>
> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
> Cc: stable@vger.kernel.org
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> drivers/gpu/drm/meson/meson_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> index 49ff9f1f16..e49de5df73 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -352,12 +352,14 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
>
> ret = drm_dev_register(drm, 0);
> if (ret)
> - goto uninstall_irq;
> + goto uninstall_poll;
>
> drm_client_setup(drm, NULL);
>
> return 0;
>
> +uninstall_poll:
> + drm_kms_helper_poll_fini(drm);
> uninstall_irq:
> free_irq(priv->vsync_irq, drm);
> exit_afbcd:
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
From: Tian, Kevin @ 2026-05-26 7:21 UTC (permalink / raw)
To: Joonwon Kang, jgg@ziepe.ca
Cc: Alexander.Grest@microsoft.com, alexander.shishkin@linux.intel.com,
amhetre@nvidia.com, baolu.lu@linux.intel.com, bp@alien8.de,
dave.hansen@linux.intel.com, easwar.hariharan@linux.microsoft.com,
hpa@zytor.com, iommu@lists.linux.dev,
jacob.jun.pan@linux.intel.com, joro@8bytes.org, jpb@kernel.org,
kas@kernel.org, kees@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, mingo@redhat.com,
nicolinc@nvidia.com, peterz@infradead.org, praan@google.com,
robin.murphy@arm.com, ryasuoka@redhat.com, smostafa@google.com,
Mehta, Sohil, tglx@kernel.org, will@kernel.org, x86@kernel.org,
xin@zytor.com
In-Reply-To: <20260526065822.914216-1-joonwonkang@google.com>
> From: Joonwon Kang <joonwonkang@google.com>
> Sent: Tuesday, May 26, 2026 2:58 PM
>
> > On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> >
> > > Currently, the only known expected user of the new kAPI is our team.
> Since
> > > I test if the patch resolves our problem before sending it, I believe it
> > > should be good enough. Do you mean more than our team by
> "accompanied
> > > users"?
> >
> > He means you cannot send patches like this that only serve OOT drivers
> > to the mainline kernel.
>
> Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
> deferring the patch submission until we find a new in-tree user of the
> new kAPI? I believe we will not make our module in-tree anytime soon.
> Or, is it like I still can send the patch and get it reviewed although we
> cannot merge it to the mainline?
>
It's not chicken-and-egg problem. Just always send them together.
so let's wait until your module is ready for in-tree review...
^ permalink raw reply
* [PATCH RFC v5 0/6] Add Amlogic stateless H.264 video decoder for S4
From: Zhentao Guo @ 2026-05-26 7:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic, Zhentao Guo
Introduce initial driver support for Amlogic's new video acceleration
hardware architecture, designed for video stream decoding.
Compared to the current Amlogic video decoder hardware architecture,
this new implementation eliminates the Esparser hardware component,
enabling direct vb2 buffer input. The driver is designed to support
the V4L2 M2M stateless decoder API. The initial phase includes support
for H.264 decoding on Amlogic S805X2 platform.
The driver needs to work alongside with a signed firmware. The loading process of
the signed fw is as follow.
Stage1: Decypt and decompose the full firmware package when the driver is probed.
+---------------------+ +---------------------+
| Decoder Driver | | TEE Shared Memory |
| (Kernel Space) | | |
| +---------------+ | | +---------------+ |
| | video_ucode | | | | firmware | |
| | .bin | | Copy payload to SHM | | payload | |
| | (from fs) | | ---------------------> | | (Secure RAM) | |
| +---------------+ | | +---------------+ |
+---------------------+ +----------+----------+
|
| PTA Invocation
v
+-------------------------------+
| BL32 |
| +-------------------------+ |
| | Decrypt Firmware | |
| +-----------+-------------+ |
| | |
| v |
| +-------------------------+ |
| | Decompose the full | |
| | firmware pacakge | |
| +-----------+-------------+ |
| | |
| v |
| +-------------------------+ |
| | Store decomposed .bin | |
| | in Secure Memory | |
| +-------------------------+ |
+-------------------------------+
Stage2: When a decode job is scheduled, load decrypted fw via secure monitor.
+---------------------+
| V4L2 M2M Framework |
| +---------------+ |
| | device_run | |
| +------+--------+ |
+---------+-----------+
|
v
+---------------------+ +---------------------+
| Decoder Driver | | Secure Monitor |
| (Kernel Space) | | (bl32) |
| +---------------+ | SMC Call | +---------------+ |
| | Select Codec | | ---------------> | | Select & Load | |
| | Specific FW | | | | firmware.bin | |
| +---------------+ | | | to AMRISC | |
+---------------------+ | +-------+-------+ |
+----------+----------+
|
v
+---------------------+
| AMRISC Core |
| +---------------+ |
| | Running fw on | |
| | AMRISC | |
| +---------------+ |
+---------------------+
The driver is capable of:
- Supporting stateless H.264 decoding up to a resolution 1920x1088(on the S805X2 platform).
- Supporting I/P/B frame handling.
- Supporting vb2 mmap and dma-buf modes.
- Supporting frame-based decode mode. (Note that some H.264 bitstreams require
DPB reordering to generate reference lists, the stateless decoder driver
cannot access reordered reference lists in this mode, requiring the driver
to perform reference list reordering itself)
- Supporting NV12/NV21 output.
- Supporting Annex B start codes.
This driver is tested with Gstreamer.
Example:
gst-launch-1.0 filesrc location=/tmp/video_640x360_mp4_hevc_450kbps_no_b.mp4 !
parsebin ! v4l2slh264dec ! filesink location=/tmp/output.yuv
Retry the compliance test based on kernel 7.1.0:
v4l2-compliance 1.30.1, 64 bits, 64-bit time_t
Compliance test for aml-vdec-drv device /dev/video0:
Driver Info:
Driver name : aml-vdec-drv
Card type : platform:aml-vdec-drv
Bus info : platform:fe320000.video-codec
Driver version : 7.1.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Detected Stateless Decoder
Media Driver Info:
Driver name : aml-vdec-drv
Model : aml-vdec-drv
Serial :
Bus info : platform:fe320000.video-codec
Media version : 7.1.0
Hardware revision: 0x00000000 (0)
Driver version : 7.1.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : aml_dev_drv-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'aml_dev_drv-proc' (Video Decoder): Data, Enabled, Immutable
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video0 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 6 Private Controls: 0
Standard Compound Controls: 4 Private Compound Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK
test blocking wait: OK
Total for aml-vdec-drv device /dev/video0: 49, Succeeded: 49, Failed: 0, Warnings: 0
Fluster test result of JVT-AVC_V1.
Result:
Ran 77/135 tests successfully
- 52 test vectors failed due to interlaced or mbaff clips: The Amlogic stateless
decoder driver only support bitstreams with frame_mbs_only_flags == 1.
Test Vectors:
cabac_mot_fld0_full
cabac_mot_mbaff0_full
cabac_mot_picaff0_full
CABREF3_Sand_D
CAFI1_SVA_C
CAMA1_Sony_C
CAMA1_TOSHIBA_B
cama1_vtc_c
cama2_vtc_b
CAMA3_Sand_E
cama3_vtc_b
CAMACI3_Sony_C
CAMANL1_TOSHIBA_B
CAMANL2_TOSHIBA_B
CAMANL3_Sand_E
CAMASL3_Sony_B
CAMP_MOT_MBAFF_L30
CAMP_MOT_MBAFF_L31
CANLMA2_Sony_C
CANLMA3_Sony_C
CAPA1_TOSHIBA_B
CAPAMA3_Sand_F
cavlc_mot_fld0_full_B
cavlc_mot_mbaff0_full_B
cavlc_mot_picaff0_full_B
CVCANLMA2_Sony_C
CVFI1_Sony_D
CVFI1_SVA_C
CVFI2_Sony_H
CVFI2_SVA_C
CVMA1_Sony_D
CVMA1_TOSHIBA_B
CVMANL1_TOSHIBA_B
CVMANL2_TOSHIBA_B
CVMAPAQP3_Sony_E
CVMAQP2_Sony_G
CVMAQP3_Sony_D
CVMP_MOT_FLD_L30_B
CVNLFI1_Sony_C
CVNLFI2_Sony_H
CVPA1_TOSHIBA_B
FI1_Sony_E
MR6_BT_B
MR7_BT_B
MR8_BT_B
MR9_BT_B
Sharp_MP_Field_1_B
Sharp_MP_Field_2_B
Sharp_MP_Field_3_B
Sharp_MP_PAFF_1r2
Sharp_MP_PAFF_2r
CVMP_MOT_FRM_L31_B
- 3 test vectors failed due to unsupported bitstream.
num_slice_group_minus1 greater than zero is not supported by the
hardware.
Test Vectors:
FM1_BT_B
FM1_FT_E
FM2_SVA_C
- 2 test vectors failed because SP_SLICE type is not supported by the
hardware.
Test Vectors:
SP1_BT_A
sp2_bt_b
One remain failure is CVFC1_Sony_C, which contains crop information. The md5sum of every decoded YUV indicates that original output from the decoder was correct. The YUV was cropped by gstreamer. The correct cropping method for this bitstream should be to crop 30*2 rows of pixels from both the top and bottom of the image, and 13*2 columns of pixels from both the left and right sides.However, gstreamer cropped 13*4 columns of pixels from the right side and 30*4 rows of pixels from the bottom. We are trying to find out the cause of this. Other failuers mentioned in V1 and V2 were resolved.
Changes in v5:
- Rename the compatible and the clock item accroding to Krzysztof's feedback.
- Use tee & meson_sm helpers to decrypt load the signed decoder firmware. Add the meson_sm describsion and reference to dt-binding and dts.
- Link to v4: https://lore.kernel.org/r/20260213-b4-s4-vdec-upstream-v4-0-c7112d00d662@amlogic.com
Changes in v4:
- Use %pad to print dma_addr_t type instead of using %llx.
- Add initial values to some local variables.
- Link to v3: https://lore.kernel.org/r/20260121-b4-s4-vdec-upstream-v3-0-4496aec3d79e@amlogic.com
Changes in v3:
- Fixed the DT check error:
arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dtb: video-codec@fe320000 (amlogic,s4-vcodec-dec): 'amlogic,canvas' does not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/media/amlogic,vcodec-dec.yaml
- Added DOS reset lines to dtsi and dt-binding.
- Fixed the issue where some B-frames were not decoded correctly(The fluster failures mentioned in patch V1 and V2 were mostly caused by this).
- Fixed the issue where canvas_index leaks occurred during the decoding of some bitstreams.
- Rework the src/dst format storage. Use v4l2_pix_format_mplane to store formats that related to bitstreams into the context. Add the reset format function to reset all the formats to default value.
- Store decoding parameters related to chip platforms, such as maximum width/height and alignment requirement, organized by chip platform.
- Link to v2: https://lore.kernel.org/r/20251124-b4-s4-vdec-upstream-v2-0-bdbbce3f11a6@amlogic.com
Changes in v2:
- Fixed incorrect generation of the reference lists for some B-frames.
- Rename or get rid of some properties in DTS and dt-binding.
- Remove some useless code or helper functions, (eg. clk helper functions, reg I/O macros, and some superfluous print messages) replace these functions with existing ones.
- Replace all the printk messages with dev_err/dev_info/dev_dbg
- Use the helper functions from the existing meson-canvas driver.
- Use clk_bulk_data to map clocks from DTS.
- Retry the V4L2 Compliance test on 6.18-rc6, fix a newly introduced bug.
- Link to v1: https://lore.kernel.org/r/20251027-b4-s4-vdec-upstream-v1-0-620401813b5d@amlogic.com
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Kevin Hilman <khilman@baylibre.com>
To: Jerome Brunet <jbrunet@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: linux-media@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Signed-off-by: Zhentao Guo <zhentao.guo@amlogic.com>
---
Zhentao Guo (6):
firmware: meson: sm: Add video firmware loading SMC call
firmware: meson: sm: video firmware loading via secure monitor
media: dt-bindings: Add Amlogic V4L2 video decoder
decoder: Add V4L2 stateless H.264 decoder driver
arm64: dts: amlogic: Add video decoder driver support for S4 SOCs
arm64: defconfig: Enable CONFIG_VIDEO_AMLOGIC_VDEC
.../devicetree/bindings/media/amlogic,s4-vdec.yaml | 103 +
MAINTAINERS | 7 +
arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 34 +
arch/arm64/configs/defconfig | 1 +
drivers/firmware/meson/meson_sm.c | 1 +
drivers/media/platform/amlogic/Kconfig | 1 +
drivers/media/platform/amlogic/Makefile | 1 +
drivers/media/platform/amlogic/vdec/Kconfig | 18 +
drivers/media/platform/amlogic/vdec/Makefile | 4 +
drivers/media/platform/amlogic/vdec/TODO | 7 +
drivers/media/platform/amlogic/vdec/aml_vdec.c | 736 +++++++
drivers/media/platform/amlogic/vdec/aml_vdec.h | 33 +
drivers/media/platform/amlogic/vdec/aml_vdec_drv.c | 239 +++
drivers/media/platform/amlogic/vdec/aml_vdec_drv.h | 172 ++
drivers/media/platform/amlogic/vdec/aml_vdec_hw.c | 538 +++++
drivers/media/platform/amlogic/vdec/aml_vdec_hw.h | 159 ++
.../platform/amlogic/vdec/aml_vdec_platform.c | 81 +
.../platform/amlogic/vdec/aml_vdec_platform.h | 46 +
.../media/platform/amlogic/vdec/aml_vdec_tee_fw.c | 240 +++
.../media/platform/amlogic/vdec/aml_vdec_tee_fw.h | 27 +
drivers/media/platform/amlogic/vdec/h264.c | 2128 ++++++++++++++++++++
drivers/media/platform/amlogic/vdec/h264.h | 299 +++
drivers/media/platform/amlogic/vdec/reg_defines.h | 177 ++
include/linux/firmware/meson/meson_sm.h | 1 +
24 files changed, 5053 insertions(+)
---
base-commit: d387b06f7c15b4639244ad66b4b0900c6a02b430
change-id: 20251027-b4-s4-vdec-upstream-0603c1a4c84a
Best regards,
--
Zhentao Guo <zhentao.guo@amlogic.com>
^ permalink raw reply
* [PATCH RFC v5 1/6] firmware: meson: sm: Add video firmware loading SMC call
From: Zhentao Guo @ 2026-05-26 7:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic, Zhentao Guo
In-Reply-To: <20260526-b4-s4-vdec-upstream-v5-0-c6edebf5ea89@amlogic.com>
Add SM_LOAD_VIDEO_FW at SMC ID 0xb200000f in the command
table to load video firmware.
Signed-off-by: Zhentao Guo <zhentao.guo@amlogic.com>
---
drivers/firmware/meson/meson_sm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 3ab67aaa9e5d..5da6c65d684a 100644
--- a/drivers/firmware/meson/meson_sm.c
+++ b/drivers/firmware/meson/meson_sm.c
@@ -47,6 +47,7 @@ static const struct meson_sm_chip gxbb_chip = {
CMD(SM_GET_CHIP_ID, 0x82000044),
CMD(SM_A1_PWRC_SET, 0x82000093),
CMD(SM_A1_PWRC_GET, 0x82000095),
+ CMD(SM_LOAD_VIDEO_FW, 0xb200000f),
{ /* sentinel */ },
},
};
--
2.42.0
^ permalink raw reply related
* [PATCH RFC v5 2/6] firmware: meson: sm: video firmware loading via secure monitor
From: Zhentao Guo @ 2026-05-26 7:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic, Zhentao Guo
In-Reply-To: <20260526-b4-s4-vdec-upstream-v5-0-c6edebf5ea89@amlogic.com>
Add SM_LOAD_VIDEO_FW to the secure monitor command enum
to allow decoder drivers to load firmware through the meson_sm
interface.
Signed-off-by: Zhentao Guo <zhentao.guo@amlogic.com>
---
include/linux/firmware/meson/meson_sm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/firmware/meson/meson_sm.h b/include/linux/firmware/meson/meson_sm.h
index 8eaf8922ab02..f40867a000f1 100644
--- a/include/linux/firmware/meson/meson_sm.h
+++ b/include/linux/firmware/meson/meson_sm.h
@@ -14,6 +14,7 @@ enum {
SM_GET_CHIP_ID,
SM_A1_PWRC_SET,
SM_A1_PWRC_GET,
+ SM_LOAD_VIDEO_FW,
};
struct meson_sm_firmware;
--
2.42.0
^ permalink raw reply related
* [PATCH RFC v5 3/6] media: dt-bindings: Add Amlogic V4L2 video decoder
From: Zhentao Guo @ 2026-05-26 7:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic, Zhentao Guo
In-Reply-To: <20260526-b4-s4-vdec-upstream-v5-0-c6edebf5ea89@amlogic.com>
Describe the initial support for the V4L2 stateless video decoder
driver used with the Amlogic S4 (S805X2) platform.
Signed-off-by: Zhentao Guo <zhentao.guo@amlogic.com>
---
.../devicetree/bindings/media/amlogic,s4-vdec.yaml | 103 +++++++++++++++++++++
1 file changed, 103 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml
new file mode 100644
index 000000000000..a0f33f6c35a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2025 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/amlogic,s4-vdec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Video Decode Accelerator
+
+maintainers:
+ - Zhentao Guo <zhentao.guo@amlogic.com>
+
+description:
+ The Video Decoder Accelerator present on Amlogic SOCs.
+ It supports stateless h264 decoding.
+
+properties:
+ compatible:
+ const: amlogic,s4-vdec
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: dos
+ - const: dmc
+
+ interrupts:
+ maxItems: 3
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: dos
+ - const: vdec
+ - const: hevcf
+
+ power-domains:
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: vdec
+ - const: hevc
+
+ resets:
+ maxItems: 1
+
+ amlogic,canvas:
+ description: should point to a canvas provider node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ secure-monitor:
+ description: phandle to the secure-monitor node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - power-domain-names
+ - amlogic,canvas
+ - secure-monitor
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/amlogic,s4-pll-clkc.h>
+ #include <dt-bindings/clock/amlogic,s4-peripherals-clkc.h>
+ #include <dt-bindings/power/meson-s4-power.h>
+ #include <dt-bindings/reset/amlogic,meson-s4-reset.h>
+ video-codec@fe320000 {
+ compatible = "amlogic,s4-vdec";
+ reg = <0xfe320000 0x10000>,
+ <0xfe036000 0x20>;
+ amlogic,canvas = <&canvas>;
+ reg-names = "dos",
+ "dmc";
+ interrupts = <GIC_SPI 91 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 92 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc_periphs CLKID_DOS>,
+ <&clkc_periphs CLKID_VDEC_SEL>,
+ <&clkc_periphs CLKID_HEVCF_SEL>;
+ clock-names = "dos",
+ "vdec",
+ "hevcf";
+ power-domains = <&pwrc PWRC_S4_DOS_VDEC_ID>,
+ <&pwrc PWRC_S4_DOS_HEVC_ID>;
+ power-domain-names = "vdec",
+ "hevc";
+ resets = <&reset RESET_DOS>;
+ secure-monitor = <&sm>;
+ };
--
2.42.0
^ permalink raw reply related
* Re: [PATCH 00/10] Add support for A9 family clock controller
From: Jerome Brunet @ 2026-05-26 7:33 UTC (permalink / raw)
To: Jian Hu via B4 Relay
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, jian.hu, linux-kernel, linux-clk, devicetree,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20260511-b4-a9_clk-v1-0-41cb4071b7c9@amlogic.com>
On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
> There are 4 clock controllers in A9 SoC:
> - SCMI clock controller: these clocks are managed by the
> Trusted Firmware-A(TF-A) and handled through SCMI.
> - PLL clock controller.
> - peripheral clock controller.
> - AO clock controller.
>
> There are reserved register regions placed between individual PLLs, so a
> separate driver is implemented for each PLL, similar to T7.
>
> Compared to previous SoCs PLLs, the A9 PLL controller introduces 4 new features:
> 1.PLL l_detect signal supports active-high configuration.
> Previous A7 and T7 l_detect signals are active-low.
> 2.PLL reset signal supports active-low configuration.
> Previous reset signals are active-high.
> 3.Support POWER_OF_TWO for the PLL pre-divider N;
> the N pre-divider follows the same calculation rule as OD.
> 4.The PLL input path includes an inherent divide-by-2 divider.
>
> Implement the first three features in clk-pll.c (verified on A9 and T7),
> with no impact to PLL logic on existing SoCs. Add a fixed divide-by-2 to
> A9 PLL driver for the fourth feature.
>
> A9 PLL is composed as follows:
>
> PLL
> +---------------------------------+
> | |
> | +--+ |
> in/2 >>---[ /2^N ]-->| | +-----+ |
> | | |------| DCO |----->> out
> | +--------->| | +--v--+ |
> | | +--+ | |
> | | | |
> | +--[ *(M + (F/Fmax) ]<--+ |
> | |
> +---------------------------------+
>
> out = in / 2 * (m + frac / frac_max) / 2^n
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> Jian Hu (10):
> dt-bindings: clock: Add Amlogic A9 SCMI clock controller
> dt-bindings: clock: Add Amlogic A9 PLL clock controller
> dt-bindings: clock: Add Amlogic A9 peripherals clock controller
> dt-bindings: clock: Add Amlogic A9 AO clock controller
> clk: amlogic: PLL l_detect signal supports active-high configuration
> clk: amlogic: PLL reset signal supports active-low configuration
> clk: amlogic: Support POWER_OF_TWO for PLL pre-divider
> clk: amlogic: Add A9 PLL clock controller driver
> clk: amlogic: Add A9 peripherals clock controller driver
> clk: amlogic: Add A9 AO clock controller driver
>
> .../bindings/clock/amlogic,a9-aoclkc.yaml | 76 +
> .../clock/amlogic,a9-peripherals-clkc.yaml | 150 ++
> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +
> drivers/clk/meson/Kconfig | 28 +
> drivers/clk/meson/Makefile | 2 +
> drivers/clk/meson/a9-aoclk.c | 494 +++++
> drivers/clk/meson/a9-peripherals.c | 2317 ++++++++++++++++++++
> drivers/clk/meson/a9-pll.c | 831 +++++++
> drivers/clk/meson/clk-pll.c | 79 +-
> drivers/clk/meson/clk-pll.h | 6 +
> include/dt-bindings/clock/amlogic,a9-aoclkc.h | 76 +
> .../clock/amlogic,a9-peripherals-clkc.h | 352 +++
> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +
> include/dt-bindings/clock/amlogic,a9-scmi-clkc.h | 51 +
> 14 files changed, 4609 insertions(+), 18 deletions(-)
For the next version, please split things up.
There is no hard dependency between the different controllers. This will
ease the review.
The PLL controllers are bringing a new contraints in. The global/static
nature of the controllers is something that has been bothering me for a
while but there was no real reason to address it so far. Please give me
some time to think about. Feel free to re-post the other controllers in the
meantime.
> ---
> base-commit: ca89c88bcf69daca829044c638a8163d5ce47af0
> change-id: 20260511-b4-a9_clk-67652c1ae56e
>
> Best regards,
--
Jerome
^ permalink raw reply
* [PATCH] KVM: arm64: PMU: Preserve AArch32 counter low bits
From: Qiang Ma @ 2026-05-26 7:46 UTC (permalink / raw)
To: maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, linux-kernel, Qiang Ma
AArch32 writes to PMU event counters cannot update the top 32 bits,
even when PMUv3p5 makes the counters 64-bit. KVM therefore needs to
preserve the existing high half and only update the low half written by
the guest, unless the caller explicitly forces a full reset through
PMCR.P.
The current code masks @val down to the old high half before taking
lower_32_bits(val), which means the low half is always zero. As a
result, AArch32 writes to event counters discard the guest-provided low
32 bits instead of storing them.
Build the new value from the old high 32 bits and the low 32 bits of
the value supplied by the guest.
Fixes: 26d2d0594d70 ("KVM: arm64: PMU: Do not let AArch32 change the counters' top 32 bits")
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
---
arch/arm64/kvm/pmu-emul.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index e1860acae641..c816db5d6761 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -174,8 +174,8 @@ static void kvm_pmu_set_pmc_value(struct kvm_pmc *pmc, u64 val, bool force)
* action is to use PMCR.P, which will reset them to
* 0 (the only use of the 'force' parameter).
*/
- val = __vcpu_sys_reg(vcpu, reg) & GENMASK(63, 32);
- val |= lower_32_bits(val);
+ val = (__vcpu_sys_reg(vcpu, reg) & GENMASK(63, 32)) |
+ lower_32_bits(val);
}
__vcpu_assign_sys_reg(vcpu, reg, val);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] irqchip/gic-v4: Harden against bogus command line
From: Mostafa Saleh @ 2026-05-26 7:50 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linux-arm-kernel, linux-kernel, tglx
In-Reply-To: <86zf1qv4do.wl-maz@kernel.org>
On Sat, May 23, 2026 at 10:53:23AM +0100, Marc Zyngier wrote:
> On Thu, 21 May 2026 14:05:03 +0100,
> Mostafa Saleh <smostafa@google.com> wrote:
> >
> > When accidentally setting “kvm-arm.vgic_v4_enable=1” on the wrong
> > setup that has no MSI controller device tree node (it exists but
> > not used) and GICv4, it caused a panic as “gic_domain” is NULL and
> > the kernel attempted to access its ops.
>
> When you say "that has no MSI controller device tree node", does it
> mean that the ITS has not been probed at all?
Yes.
>
> >
> > Originally, I hit this on an older kernel, but was able to reproduce
> > it on upstream with Qemu by hacking this unreasonable setup.
> >
> > [ 33.145536] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
> > [ 33.145658] Mem abort info:
> > [ 33.145751] ESR = 0x0000000096000006
> > ...
> > [ 33.154057] CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT
> > [ 33.156922] Hardware name: linux,dummy-virt (DT)
> > [ 33.158780] pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> > [ 33.160340] pc : __irq_domain_instantiate+0x1d4/0x578
> > [ 33.162602] lr : __irq_domain_instantiate+0x1cc/0x578
> >
> > Add a hardening check to avoid the NULL access, and fail the VM
> > creation in that case.
> >
> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > ---
> > drivers/irqchip/irq-gic-v4.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
> > index 8455b4a5fbb0..7e39f7eae85f 100644
> > --- a/drivers/irqchip/irq-gic-v4.c
> > +++ b/drivers/irqchip/irq-gic-v4.c
> > @@ -159,6 +159,9 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
> > {
> > int vpe_base_irq, i;
> >
> > + if (!gic_domain)
> > + return -EINVAL;
> > +
> > vm->fwnode = irq_domain_alloc_named_id_fwnode("GICv4-vpe",
> > task_pid_nr(current));
> > if (!vm->fwnode)
>
> I think this check is a good few levels too late. If you want to fix
> this, I'd rather make sure that kvm_vgic_global_state.has_gicv4 is
> reliable and covers this case. Which means making sure that
> gic_kvm_info::has_v4 is itself reliable.
>
> If my above understanding is correct, I'd expect the following
> (untested) hack to help.
Thanks! That also fixes the crash, the VM will launch with a vGIC with
no ITS in that case.
Thanks,
Mostafa
>
> Thanks,
>
> M.
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8da..e6b9fee1b6786 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -5838,6 +5838,7 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
>
> if (list_empty(&its_nodes)) {
> pr_warn("ITS: No ITS available, not enabling LPIs\n");
> + rdists->has_vlpis = false;
> return -ENXIO;
> }
>
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 1/6] arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE setup
From: Dev Jain @ 2026-05-26 7:56 UTC (permalink / raw)
To: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
akpm, urezki
Cc: baohua, Xueyuan.chen21, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522053146.83209-2-jiangwenxiaomi@gmail.com>
On 22/05/26 11:01 am, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> For sizes aligned to CONT_PTE_SIZE and smaller than PMD_SIZE,
> we can batch CONT_PTE settings instead of handling them individually.
Better wording: "we can handle CONT_PTE_SIZE groups together"
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index a42c05cf56408..c4d8b226126cb 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -110,6 +110,12 @@ static inline int num_contig_ptes(unsigned long size, size_t *pgsize)
> contig_ptes = CONT_PTES;
> break;
> default:
> + if (size > 0 && size < PMD_SIZE &&
> + IS_ALIGNED(size, CONT_PTE_SIZE)) {
> + contig_ptes = size >> PAGE_SHIFT;
> + *pgsize = PAGE_SIZE;
> + break;
> + }
> WARN_ON(!__hugetlb_valid_size(size));
> }
>
> @@ -359,6 +365,10 @@ pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags)
> case CONT_PTE_SIZE:
> return pte_mkcont(entry);
> default:
> + if (pagesize > 0 && pagesize < PMD_SIZE &&
> + IS_ALIGNED(pagesize, CONT_PTE_SIZE))
> + return pte_mkcont(entry);
> +
> break;
> }
> pr_warn("%s: unrecognized huge page size 0x%lx\n",
^ 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