* [PATCH V12 11/12] arm64: dts: imx8dxl/qm/qxp: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-10 2:30 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260410023055.2439146-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
.../boot/dts/freescale/imx8-ss-hsio.dtsi | 11 ++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 5 +++++
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 10 +++++++++
.../boot/dts/freescale/imx8qm-ss-hsio.dtsi | 22 +++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 5 +++++
5 files changed, 53 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi
index 469de8b536b5..009990b2e559 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi
@@ -78,6 +78,17 @@ pcieb: pcie@5f010000 {
power-domains = <&pd IMX_SC_R_PCIE_B>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcieb_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcieb_ep: pcie-ep@5f010000 {
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
index bc62ae5ca812..39108a915f96 100644
--- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
@@ -675,6 +675,7 @@ &pcie0 {
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pcieb>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcieb>;
vpcie3v3aux-supply = <®_pcieb>;
@@ -691,6 +692,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcieb_port0 {
+ reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+};
+
&sai0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sai0>;
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
index 011a89d85961..f706c86137c0 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
@@ -810,6 +810,7 @@ &pciea {
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pciea>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pciea>;
vpcie3v3aux-supply = <®_pciea>;
@@ -817,15 +818,24 @@ &pciea {
status = "okay";
};
+&pciea_port0 {
+ reset-gpios = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
+};
+
&pcieb {
phys = <&hsio_phy 1 PHY_TYPE_PCIE 1>;
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pcieb>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio5 0 GPIO_ACTIVE_LOW>;
status = "disabled";
};
+&pcieb_port0 {
+ reset-gpios = <&lsio_gpio5 0 GPIO_ACTIVE_LOW>;
+};
+
&qm_pwm_lvds0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm_lvds0>;
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi
index f2c94cdb682b..2e4fbfe0ca16 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi
@@ -41,6 +41,17 @@ pcie0: pciea: pcie@5f000000 {
power-domains = <&pd IMX_SC_R_PCIE_A>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pciea_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pciea_ep: pcie-ep@5f000000 {
@@ -91,6 +102,17 @@ pcie1: pcieb: pcie@5f010000 {
power-domains = <&pd IMX_SC_R_PCIE_B>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcieb_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
sata: sata@5f020000 {
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 623169f7ddb5..489e174df4c4 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -730,6 +730,7 @@ &pcie0 {
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pcieb>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcieb>;
vpcie3v3aux-supply = <®_pcieb>;
@@ -746,6 +747,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcieb_port0 {
+ reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+};
+
&scu_key {
status = "okay";
};
--
2.37.1
^ permalink raw reply related
* [PATCH V12 12/12] arm64: dts: imx95: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-10 2:30 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260410023055.2439146-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
.../boot/dts/freescale/imx95-15x15-evk.dts | 5 +++++
.../boot/dts/freescale/imx95-19x19-evk.dts | 10 +++++++++
arch/arm64/boot/dts/freescale/imx95.dtsi | 22 +++++++++++++++++++
3 files changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
index e4649d7f9122..7d820a0f80b2 100644
--- a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
@@ -553,6 +553,7 @@ &netcmix_blk_ctrl {
&pcie0 {
pinctrl-0 = <&pinctrl_pcie0>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio5 13 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_m2_pwr>;
vpcie3v3aux-supply = <®_m2_pwr>;
@@ -567,6 +568,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcie0_port0 {
+ reset-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+};
+
&sai1 {
assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
<&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index 041fd838fabb..6f193cf04119 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -540,6 +540,7 @@ &netc_timer {
&pcie0 {
pinctrl-0 = <&pinctrl_pcie0>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcie0>;
vpcie3v3aux-supply = <®_pcie0>;
@@ -554,9 +555,14 @@ &pcie0_ep {
status = "disabled";
};
+&pcie0_port0 {
+ reset-gpios = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>;
+};
+
&pcie1 {
pinctrl-0 = <&pinctrl_pcie1>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_slot_pwr>;
vpcie3v3aux-supply = <®_slot_pwr>;
@@ -570,6 +576,10 @@ &pcie1_ep {
status = "disabled";
};
+&pcie1_port0 {
+ reset-gpios = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>;
+};
+
&sai1 {
#sound-dai-cells = <0>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 71394871d8dd..0cc6644f98bb 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1890,6 +1890,17 @@ pcie0: pcie@4c300000 {
iommu-map-mask = <0x1ff>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie-ep@4c300000 {
@@ -1967,6 +1978,17 @@ pcie1: pcie@4c380000 {
iommu-map-mask = <0x1ff>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie1_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie1_ep: pcie-ep@4c380000 {
--
2.37.1
^ permalink raw reply related
* [PATCH net 1/1] net: stmmac: Update default_an_inband before passing value to phylink_config
From: KhaiWenTan @ 2026-04-10 2:07 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, ovidiu.panait.rb,
vladimir.oltean
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel,
yoong.siang.song, hong.aun.looi, khai.wen.tan, KhaiWenTan
get_interfaces() will update both the plat->phy_interfaces and
mdio_bus_data->default_an_inband based on reading a SERDES register.
Therefore, we moved the priv->plat->get_interfaces() to be executed
first before assigning mdio_bus_data->default_an_inband to
config->default_an_inband to ensure default_an_inband is in correct
value during PHY setup.
Fixes: ca732e990fc8 ("net: stmmac: add get_interfaces() platform method")
Signed-off-by: KhaiWenTan <khai.wen.tan@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 13d3cac056be..c92054648a7e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1345,10 +1345,6 @@ static int stmmac_phylink_setup(struct stmmac_priv *priv)
priv->tx_lpi_clk_stop = priv->plat->flags &
STMMAC_FLAG_EN_TX_LPI_CLOCKGATING;
- mdio_bus_data = priv->plat->mdio_bus_data;
- if (mdio_bus_data)
- config->default_an_inband = mdio_bus_data->default_an_inband;
-
/* Get the PHY interface modes (at the PHY end of the link) that
* are supported by the platform.
*/
@@ -1356,6 +1352,10 @@ static int stmmac_phylink_setup(struct stmmac_priv *priv)
priv->plat->get_interfaces(priv, priv->plat->bsp_priv,
config->supported_interfaces);
+ mdio_bus_data = priv->plat->mdio_bus_data;
+ if (mdio_bus_data)
+ config->default_an_inband = mdio_bus_data->default_an_inband;
+
/* Set the platform/firmware specified interface mode if the
* supported interfaces have not already been provided using
* phy_interface as a last resort.
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH 1/7] media: v4l2-ctrls: Add V4L2_CID_MEMORY_USAGE control
From: Ming Qian(OSS) @ 2026-04-10 2:53 UTC (permalink / raw)
To: Detlev Casanova, Nicolas Dufresne, Frank Li
Cc: linux-media, mchehab, hverkuil-cisco, sebastian.fricke, shawnguo,
s.hauer, kernel, festevam, linux-imx, xiahong.bao, eagle.zhou,
imx, linux-kernel, linux-arm-kernel
In-Reply-To: <9fdca013-32f7-4ce1-a296-f2f36ef31b50@collabora.com>
Hi Detlev,
On 4/9/2026 10:29 PM, Detlev Casanova wrote:
>
>
> On 4/8/26 17:11, Nicolas Dufresne wrote:
>> Le jeudi 02 avril 2026 à 11:14 +0800, Ming Qian(OSS) a écrit :
>>> Hi Nicolas,
>>>
>>> On 4/1/2026 10:23 AM, Ming Qian(OSS) wrote:
>>>> Hi Nicolas,
>>>>
>>>> On 3/31/2026 10:54 PM, Nicolas Dufresne wrote:
>>>>> Le mardi 31 mars 2026 à 10:33 -0400, Frank Li a écrit :
>>>>>> On Tue, Mar 31, 2026 at 03:23:11PM +0800,
>>>>>> ming.qian@oss.nxp.com wrote:
>>>>>>> From: Ming Qian <ming.qian@oss.nxp.com>
>>>>>>>
>>>>>>> Add a new read-only control V4L2_CID_MEMORY_USAGE that allows
>>>>>>> applications to query the total amount of memory currently used
>>>>>>> by a device instance.
>>>>>>>
>>>>>>> This control reports the memory consumption in bytes, including
>>>>>>> internal buffers, intermediate processing data, and other
>>>>>>> driver-managed allocations. Applications can use this information
>>>>>>> for debugging, resource monitoring, or making informed decisions
>>>>>>> about buffer allocation strategies.
>>>>>>>
>>>>>>> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
>>>>>>> ---
>>>>>> Not sure why not export these information by debugfs, or any
>>>>>> benefit vs
>>>>>> debugfs?
>>>>> There is also a on-going proposal that uses fdinfo.
>>>>>
>>>>> Nicolas
>>>>>
>>>> Thanks for the reminder about the ongoing fdinfo proposal.
>>>>
>>>> Just to confirm, you are referring to Detlev’s ongoing fdinfo proposal,
>>>> specifically this series:
>>>> https://lore.kernel.org/lkml/20260212162328.192217-1-
>>>> detlev.casanova@collabora.com/
>>>>
>>>> I will align my work with it and switch to using fdinfo.
>>>> Once the show_fdinfo support from that series is merged, I will prepare
>>>> the next revision of my patch accordingly.
>>>>
>>>> Regards,
>>>> Ming
>>>>
>>> Regarding the discussion about using fdinfo instead of a V4L2 control, I
>>> have two questions:
>>>
>>> 1. Key consistency in fdinfo
>>> fdinfo uses key–value pairs, which is flexible, but if multiple
>>> drivers want to expose the same “memory usage” information,
>>> they need to agree on a common key name and meaning. Otherwise
>>> user‑space must handle each driver differently. A V4L2 control
>>> naturally provides a unified interface without this coordination
>>> effort.
>>>
>>>
>>> 2. Lack of notification in fdinfo
>>> With a control, user‑space can subscribe to control events and
>>> receive notifications when the memory usage changes. fdinfo does
>>> not have a built‑in event mechanism, so users must either poll
>>> or rely on additional eventfd‑like or custom event mechanisms.
>>>
>>> Do you have any suggestions or existing practices to address these two
>>> issues when using fdinfo?
>>>
>>> Thanks again for your time and comments.
>> Added Detlev in CC. You can also refer to his work through:
>>
>> https://lore.kernel.org/all/20260212162328.192217-1-
>> detlev.casanova@collabora.com/
>>
>> Nicolas
> Hi Ming !
>
> One of the reasons for using fdinfo is that it's already being used in
> the drm subsystem and it is working well.
> Of course, in DRM, drivers don't allocate a lot of memory themselves,
> userspace drivers (in mesa) go through the DRM uAPI to allocate buffers,
> making the DRM subsystem aware of all allocated memory.
> That lets DRM show memory stats in a standard way for all drm drivers.
> In v4l2, memory allocation is shared between userspace and the driver.
> We could have drivers report memory usage through a callback and v4l2-
> core can add the standard field based on that.
>
> For notifications, I don't really see a need for that, most tracing
> tools will use polling (I'm thinking perfetto, but also top-like tools).
> We could have a max-mem-usage field if we'd want to make sure we don't
> miss the maximum memory usage between 2 polls.
>
> Finally, I think v4l2 controls should only be used to control, configure
> and exchange data with video devices, not get stat information on what
> the driver is doing.
>
> Detlev.
Thank you for your detailed explanation and suggestions.
Your points make sense, especially regarding fdinfo for standardized
stats reporting, polling being sufficient for tracing tools, and keeping
V4L2 controls focused on device control rather than driver statistics.
I'll revisit the design accordingly.
Regards,
Ming
>>
>>> Regards,
>>> Ming
>>>
>>>>>> Generanlly document should be first patch, then driver change.
>>>>>>
>>>>>> Frank
>>>>>>
>>>>>>> drivers/media/v4l2-core/v4l2-ctrls-defs.c | 8 ++++++++
>>>>>>> include/uapi/linux/v4l2-controls.h | 4 +++-
>>>>>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/
>>>>>>> media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>> index 551426c4cd01..053db78ff661 100644
>>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>> @@ -831,6 +831,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>>>>>> case V4L2_CID_ALPHA_COMPONENT: return "Alpha
>>>>>>> Component";
>>>>>>> case V4L2_CID_COLORFX_CBCR: return "Color Effects,
>>>>>>> CbCr";
>>>>>>> case V4L2_CID_COLORFX_RGB: return "Color
>>>>>>> Effects,
>>>>>>> RGB";
>>>>>>> + case V4L2_CID_MEMORY_USAGE: return "Memory Usage";
>>>>>>>
>>>>>>> /*
>>>>>>> * Codec controls
>>>>>>> @@ -1476,6 +1477,13 @@ void v4l2_ctrl_fill(u32 id, const char
>>>>>>> **name, enum v4l2_ctrl_type *type,
>>>>>>> *min = 0;
>>>>>>> *max = 0xffff;
>>>>>>> break;
>>>>>>> + case V4L2_CID_MEMORY_USAGE:
>>>>>>> + *type = V4L2_CTRL_TYPE_INTEGER64;
>>>>>>> + *flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>>>>>> + *min = 0;
>>>>>>> + *max = S64_MAX;
>>>>>>> + *step = 1;
>>>>>>> + break;
>>>>>>> case V4L2_CID_FLASH_FAULT:
>>>>>>> case V4L2_CID_JPEG_ACTIVE_MARKER:
>>>>>>> case V4L2_CID_3A_LOCK:
>>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/
>>>>>>> linux/v4l2-controls.h
>>>>>>> index 68dd0c4e47b2..02c6f960d38e 100644
>>>>>>> --- a/include/uapi/linux/v4l2-controls.h
>>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
>>>>>>> @@ -110,8 +110,10 @@ enum v4l2_colorfx {
>>>>>>> #define V4L2_CID_COLORFX_CBCR (V4L2_CID_BASE+42)
>>>>>>> #define V4L2_CID_COLORFX_RGB (V4L2_CID_BASE+43)
>>>>>>>
>>>>>>> +#define V4L2_CID_MEMORY_USAGE (V4L2_CID_BASE+44)
>>>>>>> +
>>>>>>> /* last CID + 1 */
>>>>>>> -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+44)
>>>>>>> +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+45)
>>>>>>>
>>>>>>> /* USER-class private control IDs */
>>>>>>>
>>>>>>> --
>>>>>>> 2.53.0
>>>>>>>
>
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-04-10 2:56 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
Still waiting for the device tree review. I'm going to blindly send out
the Sashiko review, please comment if any of it makes sense?
^ permalink raw reply
* Re: [PATCH net-next v3 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-1-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
This commit introduces the ethernet-port property to model a net_device
connected via an external arbiter to the GDM3 or GDM4 ports on EN7581
and AN7583 SoCs.
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909c..ebbd433e9c9fb 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,30 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^ethernet-port@[0-5]$":
The commit message states that GDM1 and GDM2 do not support connection
with the external arbiter. However, since this pattern property appears to
be placed inside the generic ^ethernet@[1-4]$ block, does this allow a
device tree to incorrectly configure ethernet-port subnodes on ethernet@1
or ethernet@2 and still pass schema validation?
Could this be restricted to GDM3 and GDM4, perhaps by splitting the
patternProperties or using an if/then block based on the reg property?
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
Does referencing ethernet-controller.yaml cause a validation conflict here?
The ethernet-controller.yaml schema enforces a strict nodename pattern
of ^ethernet(@.*)?$. Since these new nodes use the -port suffix and are
named ethernet-port@X, will they unconditionally fail the node name
validation enforced by the referenced schema during dt_binding_check?
[ ... ]
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v3 02/12] net: airoha: Set PPE cpu port for GDM2 if loopback is enabled
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-2-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
This commit moves the airoha_qdma pointer from the airoha_gdm_port struct
to the airoha_gdm_dev struct. This ensures the QDMA block used depends on
the specific net_device WAN/LAN configuration.
[ ... ]
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -1497,9 +1498,10 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
> }
> }
>
> -static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> +static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> {
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> u32 val, i = 0;
>
> spin_lock(&port->stats.lock);
This isn't a bug introduced by this patch, but does this spin_lock()
carry a deadlock risk?
Because ndo_get_stats64() can be called from atomic context (e.g., from a
softirq), if a process context caller holds port->stats.lock and is
interrupted by a softirq on the same CPU that also triggers dev_get_stats(),
the softirq could spin forever waiting for the lock.
Should this be upgraded to spin_lock_bh() to ensure local softirqs are
disabled during the critical section?
[ ... ]
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -534,12 +534,12 @@ struct airoha_qdma {
>
> struct airoha_gdm_dev {
> struct airoha_gdm_port *port;
> + struct airoha_qdma *qdma;
> struct net_device *dev;
> struct airoha_eth *eth;
> };
>
> struct airoha_gdm_port {
> - struct airoha_qdma *qdma;
> struct airoha_gdm_dev *dev;
> int id;
This isn't a bug introduced by this patch, but since the qdma pointer
is being moved to better align with the hardware structure, should
qos_sq_bmap, cpu_tx_packets, and fwd_tx_packets be moved to
struct airoha_qdma as well?
Because QDMA1 is shared by all WAN ports (GDM 2, 3, 4) and qos_sq_bmap
is currently tracked per-port instead of per-QDMA, each WAN port
independently allocates QDMA1 channels starting from index 0. Does this
cause different ports to overwrite each other's hardware QoS configurations
in the shared QDMA1 block?
Furthermore, cpu_tx_packets and fwd_tx_packets cache per-channel ETS
hardware counters but are single u64 scalar variables in the port structure.
When querying stats for multiple channels, do these scalar caches get
overwritten with values from completely different channels, resulting in
incorrect delta calculations?
^ permalink raw reply
* Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-4-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Introduce WAN device flag
This commit introduces a WAN flag to specify whether a device is used to
transmit or receive WAN or LAN traffic. It enables specifying multiple LAN
devices but limits the configuration to a single WAN device.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5b0cd37b155e4..9988011dca53f 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1796,36 +1796,77 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
[ ... ]
> +static int airoha_dev_init(struct net_device *netdev)
> +{
> + struct airoha_gdm_dev *dev = netdev_priv(netdev);
> + struct airoha_gdm_port *port = dev->port;
>
> switch (port->id) {
> case AIROHA_GDM3_IDX:
> - case AIROHA_GDM4_IDX:
> - /* If GDM2 is active we can't enable loopback */
> - if (!eth->ports[1]) {
> - int err;
> + case AIROHA_GDM4_IDX: {
> + struct airoha_eth *eth = dev->eth;
>
> - err = airoha_set_gdm2_loopback(dev);
> - if (err)
> - return err;
> - }
> + if (eth->ports[1] || airoha_get_wan_gdm_dev(eth))
> + break;
If a board's Device Tree enables both GDM3 and GDM4, and GDM2 is not present,
does this sequence permanently assign the WAN role to GDM3 since it is
initialized first? Is there a Device Tree property or fallback configuration
mechanism to allow users to specify GDM4 as the WAN port instead?
> + fallthrough;
> + }
> + case AIROHA_GDM2_IDX:
> + /* GDM2 is always used as wan */
> + dev->flags |= PRIV_FLAG_WAN;
> break;
> default:
> break;
> }
>
> - for (i = 0; i < eth->soc->num_ppe; i++)
> - airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
> + airoha_dev_set_qdma(dev);
> + airoha_set_macaddr(dev, netdev->dev_addr);
Since the commit message notes it is possible to specify multiple LAN
devices, does unconditionally calling airoha_set_macaddr() for each
device overwrite the single shared hardware LAN MAC register?
If so, could this cause only the last initialized LAN device to have its MAC
correctly programmed into the hardware, leading to dropped unicast
packets for the other LAN interfaces?
> +
> + if (!airoha_is_lan_gdm_dev(dev) &&
> + (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
> + int err;
[ ... ]
^ permalink raw reply
* Re: [PATCH net-next v3 09/12] net: airoha: Support multiple net_devices for a single FE GDM port
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-9-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Support multiple net_devices for a single FE GDM port
This commit introduces support for mapping multiple net_device interfaces
to a single Frame Engine (FE) GDM port via an external hardware arbiter.
It updates the rx/tx paths, port allocation, and registration logic to
handle the new net_device array.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -615,9 +617,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> struct page *page = virt_to_head_page(e->buf);
> u32 desc_ctrl = le32_to_cpu(desc->ctrl);
> - struct airoha_gdm_port *port;
> - struct net_device *netdev;
> - int data_len, len, p;
> + struct airoha_gdm_dev *dev;
> + int data_len, len;
>
> if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> break;
While looking at this code, I noticed an issue that predates this patch.
Can the lack of a memory barrier after checking the descriptor ownership bit
cause stale reads?
The driver checks QDMA_DESC_DONE_MASK to verify that the hardware has finished
writing the descriptor. However, it reads desc->msg1 before this check and
without a dma_rmb():
u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
struct page *page = virt_to_head_page(e->buf);
u32 desc_ctrl = le32_to_cpu(desc->ctrl);
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
Since weakly ordered architectures can reorder memory reads, could the CPU
prefetch msg1 before the DMA engine writes the new descriptor values, leading
to routing the packet to the wrong gdm_dev?
[ ... ]
> @@ -1764,9 +1765,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
> airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
> airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
>
> - /* XXX: handle XSI_USB_PORT and XSI_PCE1_PORT */
> - nbq = port->id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> - src_port = eth->soc->ops.get_src_port_id(port, nbq);
> + src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
> if (src_port < 0)
> return src_port;
Can configuring the loopback for one device break connectivity for other
devices sharing the same port?
When multiple net_devices (like PCIE0 and PCIE1 on GDM3) open and call
airoha_set_gdm2_loopback(), they modify global hardware registers such as
REG_FE_WAN_PORT.
Since WAN0_MASK is unconditionally updated to track the current device's
src_port:
airoha_fe_rmw(eth, REG_FE_WAN_PORT,
WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
FIELD_PREP(WAN0_MASK, src_port));
won't the last configured device clobber the hardware state for the others?
[ ... ]
> @@ -1987,7 +1986,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> }
>
> fport = airoha_get_fe_port(dev);
> - msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> + msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
> + FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
>
> q = &qdma->q_tx[qid];
Does sharing the hardware QDMA TX queues among multiple net_device instances
introduce a permanent transmit stall?
In airoha_dev_xmit(), if a shared hardware queue is full, the driver stops the
netdev_queue of the specific netdev making the call:
if (q->queued + nr_frags >= q->ndesc) {
/* not enough space in the queue */
netif_tx_stop_queue(txq);
spin_unlock_bh(&q->lock);
return NETDEV_TX_BUSY;
}
However, the TX completion handler (airoha_tx_irq_process()) only wakes the
queue of the netdev attached to the completed packet. If an interface's TX
queue is stopped but it has no pending packets in the hardware queue (because
another interface filled it), will it ever get woken up?
[ ... ]
> @@ -2955,11 +2958,25 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> netdev->dev_addr);
> }
>
> + /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
> + * and PCIE1 respectively.
> + */
> + index = nbq;
> + if (index && airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
> + index -= 4;
> +
> + if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
> + dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
> + return -EINVAL;
> + }
> +
> + netdev->dev.of_node = of_node_get(np);
> dev = netdev_priv(netdev);
Does this code leak the of_node reference?
The node reference is explicitly incremented via of_node_get(np). The networking
core does not automatically drop explicit of_node references on free_netdev().
Without a matching of_node_put() in the error paths or the driver's teardown
function (airoha_remove()), will this reference permanently leak when the device
is destroyed?
[ ... ]
> @@ -3003,7 +3021,43 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> if (err)
> return err;
>
> - return airoha_alloc_gdm_device(eth, port, np);
> + for_each_child_of_node(np, node) {
> + /* Multiple external serdes connected to the FE GDM port via an
> + * external arbiter.
> + */
> + const __be32 *nbq_ptr;
> + int nbq;
> +
> + if (!of_device_is_compatible(node, "airoha,eth-port"))
> + continue;
> +
> + d++;
> + if (!of_device_is_available(node))
> + continue;
> +
> + nbq_ptr = of_get_property(node, "reg", NULL);
> + if (!nbq_ptr) {
> + dev_err(eth->dev, "missing nbq id\n");
> + of_node_put(node);
> + return -EINVAL;
> + }
> +
> + /* Verify the provided nbq parameter is valid */
> + nbq = be32_to_cpup(nbq_ptr);
> + err = eth->soc->ops.get_src_port_id(port, nbq);
> + if (err < 0) {
> + of_node_put(node);
> + return err;
> + }
> +
> + err = airoha_alloc_gdm_device(eth, port, nbq, node);
> + if (err) {
> + of_node_put(node);
> + return err;
> + }
> + }
> +
> + return !d ? airoha_alloc_gdm_device(eth, port, 0, np) : 0;
> }
Does passing 0 for nbq in the fallback path break older device trees on the
EN7581 SoC?
Later, when the interface is brought up, airoha_set_gdm2_loopback() calls
airoha_en7581_get_src_port_id(), which returns -EINVAL for GDM3 if nbq is
not 4 or 5:
switch (port->id) {
case AIROHA_GDM3_IDX:
/* 7581 SoC supports PCIe serdes on GDM3 port */
if (nbq == 4)
return HSGMII_LAN_7581_PCIE0_SRCPORT;
if (nbq == 5)
return HSGMII_LAN_7581_PCIE1_SRCPORT;
break;
If nbq is hardcoded to 0 for legacy DTs, won't this cause interface
initialization to fail unconditionally for GDM3?
^ permalink raw reply
* Re: [PATCH net-next v3 10/12] net: airoha: Do not stop GDM port if it is shared
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-10-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Do not stop GDM port if it is shared
Theoretically, in the current codebase, two independent net_devices can
be connected to the same GDM port so we need to check the GDM port is not
used by any other running net_device before setting the forward
configuration to FE_PSE_PORT_DROP.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index fd27ba13029bd..5b0cd37b155e4 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -1688,18 +1693,18 @@ static int airoha_dev_stop(struct net_device *netdev)
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> struct airoha_qdma *qdma = dev->qdma;
> - int i, err;
> + int i;
>
> netif_tx_disable(netdev);
> - err = airoha_set_vip_for_gdm_port(dev, false);
> - if (err)
> - return err;
> -
> for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> netdev_tx_reset_subqueue(netdev, i);
>
> - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> - FE_PSE_PORT_DROP);
> + if (atomic_dec_and_test(&port->users)) {
> + airoha_set_vip_for_gdm_port(dev, false);
> + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> + REG_GDM_FWD_CFG(port->id),
> + FE_PSE_PORT_DROP);
> + }
>
> if (atomic_dec_and_test(&qdma->users)) {
> airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> GLOBAL_CFG_TX_DMA_EN_MASK |
> GLOBAL_CFG_RX_DMA_EN_MASK);
>
> for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> if (!qdma->q_tx[i].ndesc)
> continue;
>
> airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> }
> }
This problem wasn't introduced by this patch, but does the QDMA teardown
path have a DMA corruption vulnerability here?
When GLOBAL_CFG_TX_DMA_EN_MASK is cleared, it fails to poll
GLOBAL_CFG_TX_DMA_BUSY_MASK, proceeding to unmap memory while the hardware
DMA engine may still be processing in-flight descriptors.
Furthermore, airoha_qdma_cleanup_tx_queue() unmaps the DMA addresses and
frees the SKBs, but it does not appear to clear the physical hardware
descriptors or reset the hardware ring pointers (REG_TX_CPU_IDX /
REG_TX_DMA_IDX).
When the device is later reopened in airoha_dev_open(),
GLOBAL_CFG_TX_DMA_EN_MASK is set again without re-initializing the rings.
Will the hardware DMA engine resume fetching from its previous index,
processing stale descriptors whose backing memory was already unmapped
and freed?
[ ... ]
> @@ -1851,10 +1856,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
> static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> + u32 cur_len, len = ETH_HLEN + mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = dev->port;
> - u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
> struct airoha_eth *eth = dev->eth;
>
> + cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
> + airoha_fe_rr(eth, REG_GDM_LEN_CFG(port->id)));
> + if (len < cur_len) {
> + u8 port_refcnt = atomic_read(&port->users);
> +
> + /* We can decrease the device MTU just if the GDM port is
> + * not shared or if the other device is not running.
> + */
> + if (port_refcnt > 1 || (port_refcnt && !netif_running(netdev)))
> + return -EBUSY;
> + }
> +
Does this MTU decrease validation create a state trap on shared ports?
If both eth0 and eth1 (sharing a port) are up, and a user increases eth0 MTU
to 9000, the hardware MTU updates to 9000. If the user then tries to lower
eth0 MTU back to 1500, len < cur_len evaluates to true. Because eth1 is also
up (port_refcnt > 1), this returns -EBUSY.
This would prevent either interface from decreasing its MTU without fully
bringing down the sibling interface.
Should the software netdev->mtu be decoupled from the hardware validation,
allowing valid MTU changes in software while dynamically programming the
hardware MTU to the maximum of all currently up interfaces on the shared
port?
^ permalink raw reply
* [PATCH net v2] net: ethernet: mtk_eth_soc: initialize PPE per-tag-layer MTU registers
From: Daniel Golle @ 2026-04-10 2:57 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Pablo Neira Ayuso, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
The PPE enforces output frame size limits via per-tag-layer VLAN_MTU
registers that the driver never initializes. The hardware defaults do
not account for PPPoE overhead, causing the PPE to punt encapsulated
frames back to the CPU instead of forwarding them.
Initialize the registers at PPE start and on MTU changes using the
maximum GMAC MTU. This is a conservative approximation -- the actual
per-PPE requirement depends on egress path, but using the global
maximum ensures the limits are never too small.
Fixes: ba37b7caf1ed2 ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2: rebase on top of current net/main
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 22 ++++++++++++++-
drivers/net/ethernet/mediatek/mtk_ppe.c | 30 +++++++++++++++++++++
drivers/net/ethernet/mediatek/mtk_ppe.h | 1 +
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ddc321a02fdae..796f79088f366 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -3566,12 +3566,23 @@ static int mtk_device_event(struct notifier_block *n, unsigned long event, void
return NOTIFY_DONE;
}
+static int mtk_max_gmac_mtu(struct mtk_eth *eth)
+{
+ int i, max_mtu = ETH_DATA_LEN;
+
+ for (i = 0; i < ARRAY_SIZE(eth->netdev); i++)
+ if (eth->netdev[i] && eth->netdev[i]->mtu > max_mtu)
+ max_mtu = eth->netdev[i]->mtu;
+
+ return max_mtu;
+}
+
static int mtk_open(struct net_device *dev)
{
struct mtk_mac *mac = netdev_priv(dev);
struct mtk_eth *eth = mac->hw;
struct mtk_mac *target_mac;
- int i, err, ppe_num;
+ int i, err, ppe_num, mtu;
ppe_num = eth->soc->ppe_num;
@@ -3618,6 +3629,10 @@ static int mtk_open(struct net_device *dev)
mtk_gdm_config(eth, target_mac->id, gdm_config);
}
+ mtu = mtk_max_gmac_mtu(eth);
+ for (i = 0; i < ARRAY_SIZE(eth->ppe); i++)
+ mtk_ppe_update_mtu(eth->ppe[i], mtu);
+
napi_enable(ð->tx_napi);
napi_enable(ð->rx_napi);
mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
@@ -4311,6 +4326,7 @@ static int mtk_change_mtu(struct net_device *dev, int new_mtu)
int length = new_mtu + MTK_RX_ETH_HLEN;
struct mtk_mac *mac = netdev_priv(dev);
struct mtk_eth *eth = mac->hw;
+ int max_mtu, i;
if (rcu_access_pointer(eth->prog) &&
length > MTK_PP_MAX_BUF_SIZE) {
@@ -4321,6 +4337,10 @@ static int mtk_change_mtu(struct net_device *dev, int new_mtu)
mtk_set_mcr_max_rx(mac, length);
WRITE_ONCE(dev->mtu, new_mtu);
+ max_mtu = mtk_max_gmac_mtu(eth);
+ for (i = 0; i < ARRAY_SIZE(eth->ppe); i++)
+ mtk_ppe_update_mtu(eth->ppe[i], max_mtu);
+
return 0;
}
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
index 75f7728fc7962..18279e2a7022e 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@ -973,6 +973,36 @@ static void mtk_ppe_init_foe_table(struct mtk_ppe *ppe)
}
}
+void mtk_ppe_update_mtu(struct mtk_ppe *ppe, int mtu)
+{
+ int base;
+ u32 val;
+
+ if (!ppe)
+ return;
+
+ /* The PPE checks output frame size against per-tag-layer MTU limits,
+ * treating PPPoE and DSA tags just like 802.1Q VLAN tags. The Linux
+ * device MTU already accounts for PPPoE (PPPOE_SES_HLEN) and DSA tag
+ * overhead, but 802.1Q VLAN tags are handled transparently without
+ * being reflected by the lower device MTU being increased by 4.
+ * Use the maximum MTU across all GMAC interfaces so that PPE output
+ * frame limits are sufficiently high regardless of which port a flow
+ * egresses through.
+ */
+ base = ETH_HLEN + mtu;
+
+ val = FIELD_PREP(MTK_PPE_VLAN_MTU0_NONE, base) |
+ FIELD_PREP(MTK_PPE_VLAN_MTU0_1TAG, base + VLAN_HLEN);
+ ppe_w32(ppe, MTK_PPE_VLAN_MTU0, val);
+
+ val = FIELD_PREP(MTK_PPE_VLAN_MTU1_2TAG,
+ base + 2 * VLAN_HLEN) |
+ FIELD_PREP(MTK_PPE_VLAN_MTU1_3TAG,
+ base + 3 * VLAN_HLEN);
+ ppe_w32(ppe, MTK_PPE_VLAN_MTU1, val);
+}
+
void mtk_ppe_start(struct mtk_ppe *ppe)
{
u32 val;
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.h b/drivers/net/ethernet/mediatek/mtk_ppe.h
index 223f709e2704f..ba85e39a155bf 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.h
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.h
@@ -346,6 +346,7 @@ struct mtk_ppe {
struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index);
void mtk_ppe_deinit(struct mtk_eth *eth);
+void mtk_ppe_update_mtu(struct mtk_ppe *ppe, int mtu);
void mtk_ppe_start(struct mtk_ppe *ppe);
int mtk_ppe_stop(struct mtk_ppe *ppe);
int mtk_ppe_prepare_reset(struct mtk_ppe *ppe);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-04-10 2:59 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
Looks like this driver uses page pool.
If you're sharing the same page pool across multiple netdevs
it must not be linked to a netdev.
^ permalink raw reply
* RE: [PATCH V2 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Sherry Sun @ 2026-04-10 3:00 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <omtn42mopdz7igg7jaqwehd67l6xc77zk7zzqwkufgnsycvadg@5kodhpgfesre>
> Subject: Re: [PATCH V2 0/8] PCI: imx6: Integrate pwrctrl API and update device
> trees
>
> On Thu, Apr 02, 2026 at 06:09:59PM +0800, Sherry Sun wrote:
> > Note: This patch set depends on my previous patch set [1] which adds
> > Root Port device tree nodes and support parsing the reset property in
> > new Root Port binding in pci-imx6 driver.
> >
> > This series integrates the PCI pwrctrl framework into the pci-imx6
> > driver and updates i.MX EVK board device trees to support it.
> >
> > Patches 2-8 update device trees for i.MX EVK boards which maintained
> > by NXP to move power supply properties from the PCIe controller node
> > to the Root Port child node, which is required for pwrctrl framework.
> > Affected boards:
> > - i.MX6Q/DL SABRESD
> > - i.MX6SX SDB
> > - i.MX8MM EVK
> > - i.MX8MP EVK
> > - i.MX8MQ EVK
> > - i.MX8DXL/QM/QXP EVK
> > - i.MX95 15x15/19x19 EVK
> >
> > The driver maintains legacy regulator handling for device trees that
> > haven't been updated yet. Both old and new device tree structures are
> > supported.
> >
>
> Thanks for the work! Due to some recently merged patches, this series (Patch
> 1) doesn't apply on top of pci/controller/dwc-imx6 branch. Please rebase and
> resend!
>
> - Mani
Hi Mani, thanks for the reminder.
Actually this patch set depends on my PERST# patch set [1], which adds
support for Root Port dts nodes and correctly adjusts the sequence of PERST#
assert/deassert and regulator/clock enable in pci-imx6 driver.
I will resend this series once the PERST# patch set been accepted.
[1] https://lore.kernel.org/all/20260410023055.2439146-1-sherry.sun@nxp.com/
Best Regards
Sherry
^ permalink raw reply
* RE: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Tian, Kevin @ 2026-04-10 3:13 UTC (permalink / raw)
To: Jason Gunthorpe, Nicolin Chen
Cc: will@kernel.org, robin.murphy@arm.com, bhelgaas@google.com,
joro@8bytes.org, praan@google.com, baolu.lu@linux.intel.com,
miko.lenczewski@arm.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Williams, Dan J,
jonathan.cameron@huawei.com, Vikram Sethi,
linux-cxl@vger.kernel.org
In-Reply-To: <20260409225252.GU3357077@nvidia.com>
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, April 10, 2026 6:53 AM
>
> On Thu, Apr 09, 2026 at 03:45:26PM -0700, Nicolin Chen wrote:
>
> > One question regarding VM case: if a device is ats_always_on, while
> > VM somehow doesn't set nested_domain->enable_ats. Should the kernel
> > at least spit a warning, given that it would surely fail the device?
>
> No, just let break, the resulting failure has to be contained to the
> VM or the platform is broken..
>
> The HV can't turn on ATS because we it can't know what invalidations
> to push so not much other choice.
>
Taking about in theory - host can append a devtlb invalidation cmd
after iotlb invalidation (if vcmdq is not used)?
^ permalink raw reply
* [PATCH v1] clk: imx95-blk-ctl: Add func_out_en clock for i.MX9x PCIe
From: Richard Zhu @ 2026-04-10 3:16 UTC (permalink / raw)
To: abelvesa, peng.fan, mturquette, sboyd, Frank.Li, s.hauer,
festevam
Cc: linux-clk, imx, linux-arm-kernel, linux-kernel, kernel,
Richard Zhu
When internal PLL clock is used as PCIe REF clock, the BIT6(CREF_EN) and
BIT2(FUNC_OUTPUT_EN) control the PCIE_REF_OUT_CLK.
If the default value of BIT6(CREF_EN)&BIT2(FUNC_OUTPUT_EN) is 1b'1.
With the typical 100-ohm termination on the board, this results in
approximately 6mA of power consumption.
When PCIe internal PLL clock is not enabled, these two bits should
be cleared to 1b'0 to eliminate this power consumption.
Add a func_out_en clock for i.MX9x PCIe to serve as the parent gate clock
of the CREF_EN (BIT6) gate clock. Both of these two gate clocks enable
the output of the internal 100MHz differential reference clock.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
drivers/clk/imx/clk-imx95-blk-ctl.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx95-blk-ctl.c b/drivers/clk/imx/clk-imx95-blk-ctl.c
index 56bed4471995..1f9259f45607 100644
--- a/drivers/clk/imx/clk-imx95-blk-ctl.c
+++ b/drivers/clk/imx/clk-imx95-blk-ctl.c
@@ -286,18 +286,28 @@ static const struct imx95_blk_ctl_dev_data netcmix_dev_data = {
static const struct imx95_blk_ctl_clk_dev_data hsio_blk_ctl_clk_dev_data[] = {
[0] = {
.name = "hsio_blk_ctl_clk",
- .parent_names = (const char *[]){ "hsio_pll", },
+ .parent_names = (const char *[]){ "func_out_en", },
.num_parents = 1,
.reg = 0,
.bit_idx = 6,
.bit_width = 1,
.type = CLK_GATE,
.flags = CLK_SET_RATE_PARENT,
+ },
+ [1] = {
+ .name = "func_out_en",
+ .parent_names = (const char *[]){ "hsio_pll", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 2,
+ .bit_width = 1,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
}
};
static const struct imx95_blk_ctl_dev_data hsio_blk_ctl_dev_data = {
- .num_clks = 1,
+ .num_clks = ARRAY_SIZE(hsio_blk_ctl_clk_dev_data),
.clk_dev_data = hsio_blk_ctl_clk_dev_data,
.clk_reg_offset = 0,
};
--
2.37.1
^ permalink raw reply related
* Re: [RFC V1 14/16] arm64/mm: Enable fixmap with 5 level page table
From: Anshuman Khandual @ 2026-04-10 3:22 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm
In-Reply-To: <4382c90a-bc92-470e-9aa7-4666753479ca@kernel.org>
On 08/04/26 5:59 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Enable fixmap with 5 level page table when required. This creates table
>> entries at the PGD level. Add a fallback stub for pgd_page_paddr() when
>> (PGTBALE_LEVELS <= 4) which helps in intercepting any unintended usage.
>
> Can you add the "why" ?
Following reworded commit message should work ?
------------------------------------------------------------------
arm64/mm: Enable fixmap with 5 level page table
FEAT_D128 halves PTRS_PER_PXX thus shrinking the VA range coverage
for each page table level. Hence in order to preserve all existing
VA range configurations, some geometry now need to become 5-level.
Since fixmap is used to build and manipulate page tables early on
during boot the mapping must also gain that additional level which
was not required earlier.
Enable fixmap with 5 level page table when required. This creates table
entries at the PGD level. Add a fallback stub for pgd_page_paddr() when
(PGTBALE_LEVELS <= 4) which helps in intercepting any unintended usage.
-------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH net v3] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
From: Jakub Kicinski @ 2026-04-10 3:35 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Xuegang Lu, Simon Horman, linux-arm-kernel, linux-mediatek,
netdev
In-Reply-To: <20260407-airoha_qdma_rx_process-fix-reordering-v3-1-91c36e9da31f@kernel.org>
On Tue, 07 Apr 2026 08:48:04 +0200 Lorenzo Bianconi wrote:
> Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
> DMA read operations are completed when the NIC reports the processing on
> the current descriptor is done. Moreover, add missing READ_ONCE() in
> airoha_qdma_rx_process() for DMA descriptor control fields in order to
> avoid any compiler reordering.
Sashiko seems to have more orthogonal complaints FWIW
^ permalink raw reply
* Re: [PATCH v14 2/4] asm-generic: Move TIF_SINGLESTEP to generic TIF bits
From: Jinjie Ruan @ 2026-04-10 3:39 UTC (permalink / raw)
To: Mark Rutland
Cc: catalin.marinas, will, chenhuacai, kernel, hca, gor, agordeev,
borntraeger, svens, oleg, tglx, mingo, bp, dave.hansen, hpa, arnd,
shuah, kevin.brodsky, yeoreum.yun, anshuman.khandual, thuth,
ryan.roberts, song, ziyao, linusw, schuster.simon, jremus, akpm,
mathieu.desnoyers, kmal, dvyukov, reddybalavignesh9979, x86,
linux-arm-kernel, linux-kernel, loongarch, linux-s390, linux-arch,
linux-kselftest
In-Reply-To: <addYbV3_9eFZg_b4@J2N7QTR9R3>
On 2026/4/9 15:42, Mark Rutland wrote:
> On Fri, Mar 20, 2026 at 06:42:20PM +0800, Jinjie Ruan wrote:
>> Currently, x86, ARM64, s390, and LoongArch all define and use
>> TIF_SINGLESTEP to track single-stepping state.
>
> Do the architectures actually use the flag in the same way?
As far as I know, the behavior of setting and clearing the
TIF_SINGLESTEP flag is consistent across these architectures, at least
within the ptrace handling logic of user_enable_single_step() and
user_disable_single_step().
>
> I'd expect that this is used subtly differently across those
> architectures, and so isn't necessarily generic.
>
>> Since this flag is shared across multiple major architectures and serves
>> a common purpose in the generic entry/exit paths, move TIF_SINGLESTEP
>> into the generic Thread Information Flags (TIF) infrastructure.
>>
>> This consolidation reduces architecture-specific boilerplate code and
>> ensures consistency for generic features that rely on single-step
>> state tracking.
>
> Is it necessary to make this generic in order to move to generic irq
> flags? I'd expect that generic code cannot make use of this due to the
> different semantics across architectures, as noted abobve.
>
> I think it's probably better to keep this architecture-specific for now,
> where architectures can clearly define how they're using this bit.
Hi Mark,
Thank you for the feedback. You are maybe right, and your concern aligns
with the original intent behind the generic TIF infrastructure.
I noticed that when the generic TIF infrastructure was first introduced
(see commit 29589343488e: "asm-generic: Provide generic TIF
infrastructure"), it explicitly mentioned:
"This could probably be extended by TIF_SINGLESTEP and BLOCKSTEP, but
those are only used in architecture specific code. So leave them alone
for now."
It seems that moving TIF_SINGLESTEP to generic TIF bits at this stage is
indeed premature. Furthermore, in the generic entry implementation, the
single-step exit handling is actually managed by
SYSCALL_WORK_SYSCALL_EXIT_TRAP rather than directly relying on a generic
TIF_SINGLESTEP flag.
Best regards,
Jinjie
>
> Am I missing some reason why it's necessary to make this generic?
>
> Mark.
>
>> Cc: Thomas Gleixner <tglx@kernel.org>
>> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
>> Reviewed-by: Linus Walleij <linusw@kernel.org>
>> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
>> Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/loongarch/include/asm/thread_info.h | 11 +++++------
>> arch/s390/include/asm/thread_info.h | 7 +++----
>> arch/x86/include/asm/thread_info.h | 6 ++----
>> include/asm-generic/thread_info_tif.h | 5 +++++
>> 4 files changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/loongarch/include/asm/thread_info.h b/arch/loongarch/include/asm/thread_info.h
>> index 4d7117fcdc78..a2ec87f18e1d 100644
>> --- a/arch/loongarch/include/asm/thread_info.h
>> +++ b/arch/loongarch/include/asm/thread_info.h
>> @@ -70,6 +70,7 @@ register unsigned long current_stack_pointer __asm__("$sp");
>> */
>> #define HAVE_TIF_NEED_RESCHED_LAZY
>> #define HAVE_TIF_RESTORE_SIGMASK
>> +#define HAVE_TIF_SINGLESTEP
>>
>> #include <asm-generic/thread_info_tif.h>
>>
>> @@ -82,11 +83,10 @@ register unsigned long current_stack_pointer __asm__("$sp");
>> #define TIF_32BIT_REGS 21 /* 32-bit general purpose registers */
>> #define TIF_32BIT_ADDR 22 /* 32-bit address space */
>> #define TIF_LOAD_WATCH 23 /* If set, load watch registers */
>> -#define TIF_SINGLESTEP 24 /* Single Step */
>> -#define TIF_LSX_CTX_LIVE 25 /* LSX context must be preserved */
>> -#define TIF_LASX_CTX_LIVE 26 /* LASX context must be preserved */
>> -#define TIF_USEDLBT 27 /* LBT was used by this task this quantum (SMP) */
>> -#define TIF_LBT_CTX_LIVE 28 /* LBT context must be preserved */
>> +#define TIF_LSX_CTX_LIVE 24 /* LSX context must be preserved */
>> +#define TIF_LASX_CTX_LIVE 25 /* LASX context must be preserved */
>> +#define TIF_USEDLBT 26 /* LBT was used by this task this quantum (SMP) */
>> +#define TIF_LBT_CTX_LIVE 27 /* LBT context must be preserved */
>>
>> #define _TIF_NOHZ BIT(TIF_NOHZ)
>> #define _TIF_USEDFPU BIT(TIF_USEDFPU)
>> @@ -96,7 +96,6 @@ register unsigned long current_stack_pointer __asm__("$sp");
>> #define _TIF_32BIT_REGS BIT(TIF_32BIT_REGS)
>> #define _TIF_32BIT_ADDR BIT(TIF_32BIT_ADDR)
>> #define _TIF_LOAD_WATCH BIT(TIF_LOAD_WATCH)
>> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
>> #define _TIF_LSX_CTX_LIVE BIT(TIF_LSX_CTX_LIVE)
>> #define _TIF_LASX_CTX_LIVE BIT(TIF_LASX_CTX_LIVE)
>> #define _TIF_USEDLBT BIT(TIF_USEDLBT)
>> diff --git a/arch/s390/include/asm/thread_info.h b/arch/s390/include/asm/thread_info.h
>> index 1bcd42614e41..95be5258a422 100644
>> --- a/arch/s390/include/asm/thread_info.h
>> +++ b/arch/s390/include/asm/thread_info.h
>> @@ -61,6 +61,7 @@ void arch_setup_new_exec(void);
>> */
>> #define HAVE_TIF_NEED_RESCHED_LAZY
>> #define HAVE_TIF_RESTORE_SIGMASK
>> +#define HAVE_TIF_SINGLESTEP
>>
>> #include <asm-generic/thread_info_tif.h>
>>
>> @@ -69,15 +70,13 @@ void arch_setup_new_exec(void);
>> #define TIF_GUARDED_STORAGE 17 /* load guarded storage control block */
>> #define TIF_ISOLATE_BP_GUEST 18 /* Run KVM guests with isolated BP */
>> #define TIF_PER_TRAP 19 /* Need to handle PER trap on exit to usermode */
>> -#define TIF_SINGLESTEP 21 /* This task is single stepped */
>> -#define TIF_BLOCK_STEP 22 /* This task is block stepped */
>> -#define TIF_UPROBE_SINGLESTEP 23 /* This task is uprobe single stepped */
>> +#define TIF_BLOCK_STEP 20 /* This task is block stepped */
>> +#define TIF_UPROBE_SINGLESTEP 21 /* This task is uprobe single stepped */
>>
>> #define _TIF_ASCE_PRIMARY BIT(TIF_ASCE_PRIMARY)
>> #define _TIF_GUARDED_STORAGE BIT(TIF_GUARDED_STORAGE)
>> #define _TIF_ISOLATE_BP_GUEST BIT(TIF_ISOLATE_BP_GUEST)
>> #define _TIF_PER_TRAP BIT(TIF_PER_TRAP)
>> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
>> #define _TIF_BLOCK_STEP BIT(TIF_BLOCK_STEP)
>> #define _TIF_UPROBE_SINGLESTEP BIT(TIF_UPROBE_SINGLESTEP)
>>
>> diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
>> index 0067684afb5b..f59072ba1473 100644
>> --- a/arch/x86/include/asm/thread_info.h
>> +++ b/arch/x86/include/asm/thread_info.h
>> @@ -98,9 +98,8 @@ struct thread_info {
>> #define TIF_IO_BITMAP 22 /* uses I/O bitmap */
>> #define TIF_SPEC_FORCE_UPDATE 23 /* Force speculation MSR update in context switch */
>> #define TIF_FORCED_TF 24 /* true if TF in eflags artificially */
>> -#define TIF_SINGLESTEP 25 /* reenable singlestep on user return*/
>> -#define TIF_BLOCKSTEP 26 /* set when we want DEBUGCTLMSR_BTF */
>> -#define TIF_ADDR32 27 /* 32-bit address space on 64 bits */
>> +#define TIF_BLOCKSTEP 25 /* set when we want DEBUGCTLMSR_BTF */
>> +#define TIF_ADDR32 26 /* 32-bit address space on 64 bits */
>>
>> #define _TIF_SSBD BIT(TIF_SSBD)
>> #define _TIF_SPEC_IB BIT(TIF_SPEC_IB)
>> @@ -112,7 +111,6 @@ struct thread_info {
>> #define _TIF_SPEC_FORCE_UPDATE BIT(TIF_SPEC_FORCE_UPDATE)
>> #define _TIF_FORCED_TF BIT(TIF_FORCED_TF)
>> #define _TIF_BLOCKSTEP BIT(TIF_BLOCKSTEP)
>> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
>> #define _TIF_ADDR32 BIT(TIF_ADDR32)
>>
>> /* flags to check in __switch_to() */
>> diff --git a/include/asm-generic/thread_info_tif.h b/include/asm-generic/thread_info_tif.h
>> index da1610a78f92..b277fe06aee3 100644
>> --- a/include/asm-generic/thread_info_tif.h
>> +++ b/include/asm-generic/thread_info_tif.h
>> @@ -48,4 +48,9 @@
>> #define TIF_RSEQ 11 // Run RSEQ fast path
>> #define _TIF_RSEQ BIT(TIF_RSEQ)
>>
>> +#ifdef HAVE_TIF_SINGLESTEP
>> +#define TIF_SINGLESTEP 12 /* reenable singlestep on user return*/
>> +#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
>> +#endif
>> +
>> #endif /* _ASM_GENERIC_THREAD_INFO_TIF_H_ */
>> --
>> 2.34.1
>>
>
^ permalink raw reply
* Re: [PATCH net v3] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
From: patchwork-bot+netdevbpf @ 2026-04-10 3:40 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, xuegang.lu, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260407-airoha_qdma_rx_process-fix-reordering-v3-1-91c36e9da31f@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 07 Apr 2026 08:48:04 +0200 you wrote:
> Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
> DMA read operations are completed when the NIC reports the processing on
> the current descriptor is done. Moreover, add missing READ_ONCE() in
> airoha_qdma_rx_process() for DMA descriptor control fields in order to
> avoid any compiler reordering.
>
> Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net,v3] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
https://git.kernel.org/netdev/net/c/4ae0604a0673
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 v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Taniya Das @ 2026-04-10 3:55 UTC (permalink / raw)
To: Bryan O'Donoghue, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <cb5a40e8-e2e3-4ed9-a9c6-0daa9f408710@nxsw.ie>
On 4/10/2026 12:10 AM, Bryan O'Donoghue wrote:
> On 09/04/2026 19:10, Taniya Das wrote:
>> + videocc: clock-controller@aaf0000 {
>> + compatible = "qcom,eliza-videocc";
>> + reg = <0x0 0xaaf0000 0x0 0x10000>;
>> +
>> + clocks = <&bi_tcxo_div2>,
>> + <&sleep_clk>,
>> + <&gcc GCC_VIDEO_AHB_CLK>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + #power-domain-cells = <1>;
>> + };
>> +
>> + camcc: clock-controller@ade0000 {
>> + compatible = "qcom,eliza-camcc";
>> + reg = <0x0 0x0ade0000 0x0 0x20000>;
>> +
>> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
>> + <&bi_tcxo_div2>,
>> + <&sleep_clk>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + };
>
> This looks odd.
>
> Why do these two controllers have no power-domains ?
Bryan, on Eliza the videocc and camcc are connected on CX and MXA.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [RFC V1 11/16] arm64/mm: Route all pgtable atomics to central helpers
From: Anshuman Khandual @ 2026-04-10 4:02 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm
In-Reply-To: <aeb1972c-57ba-4f21-8289-66424e4e619b@kernel.org>
On 08/04/26 5:58 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Route all cmpxchg() operations performed on various page table entries to a
>> new ptdesc_cmpxchg_relaxed() helper. Similarly route all xchg() operations
>> performed on page table entries to a new ptdesc_xchg_relaxed() helper.
>>
>> Currently these helpers just forward to the same APIs that were previously
>> called direct, but in future we will change the routing for D128 which is
>> too long to use the standard APIs.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/include/asm/pgtable.h | 23 +++++++++++++++++------
>> arch/arm64/mm/fault.c | 2 +-
>> 2 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 42124d2f323d..cf69ce68f951 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -87,6 +87,17 @@ static inline void arch_leave_lazy_mmu_mode(void)
>> #define ptdesc_get(x) READ_ONCE(x)
>> #define ptdesc_set(x, val) WRITE_ONCE(x, val)
>>
>> +static inline ptdesc_t ptdesc_cmpxchg_relaxed(ptdesc_t *ptep, ptdesc_t old,
>> + ptdesc_t new)
>> +{
>> + return cmpxchg_relaxed(ptep, old, new);
>> +}
>> +
>> +static inline ptdesc_t ptdesc_xchg_relaxed(ptdesc_t *ptep, ptdesc_t new)
>> +{
>> + return xchg_relaxed(ptep, new);
>> +}
>> +
>
> We really want the rename of ptdesc_t before this change.
>
Planning to rename ptdesc_t as ptent_t in a pre-requisite
patch early in the series.
^ permalink raw reply
* Re: [RFC V1 12/16] arm64/mm: Abstract printing of pxd_val()
From: Anshuman Khandual @ 2026-04-10 4:05 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm
In-Reply-To: <4290fcdb-47d1-4f74-97f3-51ac581efeaf@kernel.org>
On 08/04/26 5:58 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>
> Subject: you probably mean "pxx_val()" ?
Yes - sounds better will change.
>
>> Ahead of adding support for D128 pgtables, refactor places that print
>> PTE values to use the new __PRIpte format specifier and __PRIpte_args()
>> macro to prepare the argument(s). When using D128 pgtables in future,
>> we can simply redefine __PRIpte and __PTIpte_args().
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/include/asm/pgtable-types.h | 3 +++
>> arch/arm64/include/asm/pgtable.h | 22 +++++++++++-----------
>> arch/arm64/mm/fault.c | 10 +++++-----
>> 3 files changed, 19 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/pgtable-types.h b/arch/arm64/include/asm/pgtable-types.h
>> index 265e8301d7ba..dc3791dc9f14 100644
>> --- a/arch/arm64/include/asm/pgtable-types.h
>> +++ b/arch/arm64/include/asm/pgtable-types.h
>> @@ -11,6 +11,9 @@
>>
>> #include <asm/types.h>
>>
>> +#define __PRIpte "016llx"
>> +#define __PRIpte_args(val) ((u64)val)
>
> Same comment regarding "pte" being misleading.
Sure - will rename __PRIpte as PRIpxx instead.
>
>
^ permalink raw reply
* Re: [RFC V1 01/16] mm: Abstract printing of pxd_val()
From: Anshuman Khandual @ 2026-04-10 4:21 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Linu Cherian, linux-kernel, linux-mm
In-Reply-To: <adeAhYW-hJ7-6-Xy@kernel.org>
On 09/04/26 4:03 PM, Mike Rapoport wrote:
> Hi Anshuman,
>
> On Tue, Feb 24, 2026 at 10:41:38AM +0530, Anshuman Khandual wrote:
>> Ahead of adding support for D128 pgtables, refactor places that print
>> PTE values to use the new __PRIpte format specifier and __PRIpte_args()
>> macro to prepare the argument(s). When using D128 pgtables in future,
>> we can simply redefine __PRIpte and __PTIpte_args().
>>
>> Besides there is also an assumption about pxd_val() being always capped
>> at 'unsigned long long' size but that will not work for D128 pgtables.
>> Just increase its size to u128 if the compiler supports via a separate
>> data type pxdval_t which also defaults to existing 'unsigned long long'.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> include/linux/pgtable.h | 5 +++++
>> mm/memory.c | 29 +++++++++++++++++++----------
>> 2 files changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index a50df42a893f..da17139a1279 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -17,6 +17,11 @@
>> #include <asm-generic/pgtable_uffd.h>
>> #include <linux/page_table_check.h>
>>
>> +#ifndef __PRIpte
>> +#define __PRIpte "016llx"
>> +#define __PRIpte_args(val) ((u64)val)
>> +#endif
>> +
>> #if 5 - defined(__PAGETABLE_P4D_FOLDED) - defined(__PAGETABLE_PUD_FOLDED) - \
>> defined(__PAGETABLE_PMD_FOLDED) != CONFIG_PGTABLE_LEVELS
>> #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 07778814b4a8..cfc3077fc52f 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -532,9 +532,15 @@ static bool is_bad_page_map_ratelimited(void)
>> return false;
>> }
>>
>> +#ifdef __SIZEOF_INT128__
>> + typedef u128 pxdval_t;
>
> I don't think the typedef should be indented.
Sure will drop the indent from pxdval_t.
>
>> +#else
>> + typedef unsigned long long pxdval_t;
>> +#endif
>
> Don't we want this in, say, include/linux/pgtable.h?
>
Sure will move the typedef into the above header.
^ permalink raw reply
* Re: [RFC V1 02/16] mm: Add read-write accessors for vm_page_prot
From: Anshuman Khandual @ 2026-04-10 4:29 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Linu Cherian, linux-kernel, linux-mm
In-Reply-To: <adeBg_eZvmz-ST67@kernel.org>
On 09/04/26 4:07 PM, Mike Rapoport wrote:
> Hi Anshuman,
>
> On Tue, Feb 24, 2026 at 10:41:39AM +0530, Anshuman Khandual wrote:
>> Currently vma->vm_page_prot is safely read from and written to, without any
>> locks with READ_ONCE() and WRITE_ONCE(). But with introduction of D128 page
>> tables on arm64 platform, vm_page_prot grows to 128 bits which can't safely
>> be handled with READ_ONCE() and WRITE_ONCE().
>>
>> Add read and write accessors for vm_page_prot like pgprot_read/write_once()
>> which any platform can override when required, although still defaulting as
>> READ_ONCE() and WRITE_ONCE(), thus preserving the functionality for others.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> include/linux/pgtable.h | 14 ++++++++++++++
>> mm/huge_memory.c | 4 ++--
>> mm/memory.c | 2 +-
>> mm/migrate.c | 2 +-
>> mm/mmap.c | 2 +-
>> 5 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index da17139a1279..8858b8b03a02 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -495,6 +495,20 @@ static inline pgd_t pgdp_get(pgd_t *pgdp)
>> }
>> #endif
>>
>> +#ifndef pgprot_read_once
>> +static inline pgprot_t pgprot_read_once(pgprot_t *prot)
>
> I don't think we need _once in the helper name. Presence of the helper
> already implies that pointer should not be just dereferenced from one side
> and that using the helper will do The Right Thing from the other side.
Makes sense - will drop __once from the helper name.
^ permalink raw reply
* Re: [PATCH v3 4/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Vignesh Raghavendra @ 2026-04-10 4:30 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI), Bjorn Andersson, Mathieu Poirier,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Suman Anna,
Nishanth Menon, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-4-c41473cb23c3@baylibre.com>
Hi Markus
On 18/03/26 20:43, Markus Schneider-Pargmann (TI) wrote:
> Split the firmware memory region in more specific parts so it is better
> described where to find which information. Specifically the LPM metadata
> region is important as bootloader software like U-Boot has to know where
> that data is to be able to read that data.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..c381cc33064ec427751a9ac5bcdff745a9559a89 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
> no-map;
> };
>
> - wkup_r5fss0_core0_memory_region: memory@9c900000 {
> + wkup_r5fss0_core0_ipc_region: memory@9c900000 {
There are still references to wkup_r5fss0_core0_memory_region in
k3-am62a-ti-ipc-firmware.dtsi (same comment applies to next 2 patches as
well)
Dont those need to be updated too?
> compatible = "shared-dma-pool";
> - reg = <0x00 0x9c900000 0x00 0xf00000>;
> + reg = <0x00 0x9c900000 0x00 0x100000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_fs_stub_region: memory@9ca00000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca00000 0x00 0x8000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca08000 0x00 0x1000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca09000 0x00 0x97000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_dm_region: memory@9caa0000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9caa0000 0x00 0xd60000>;
> no-map;
> };
>
> @@ -922,3 +946,15 @@ &mcu_uart0 {
> };
>
> #include "k3-am62a-ti-ipc-firmware.dtsi"
> +
> +&wkup_r5fss0_core0 {
> + memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> + <&wkup_r5fss0_core0_ipc_region>,
> + <&wkup_r5fss0_core0_lpm_fs_stub_region>,
> + <&wkup_r5fss0_core0_lpm_metadata_region>,
> + <&wkup_r5fss0_core0_lpm_rest_region>,
> + <&wkup_r5fss0_core0_dm_region>;
> + memory-region-names = "dma", "ipc", "lpm-stub",
> + "lpm-metadata", "lpm-context",
> + "dm-firmware";
> +};
>
--
Regards
Vignesh
https://ti.com/opensource
^ 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