* [PATCH 0/4] staging: vc04_services: vchiq-mmal: fix multiple memory safety issues
From: Sebastian Josue Alba Vives @ 2026-03-29 6:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives
This series fixes four memory safety issues in the MMAL VCHIQ driver
which handles multimedia message passing between the ARM CPU and the
VideoCore GPU on all Raspberry Pi models.
Patch 1: OOB array access in event_to_host_cb()
Patch 2: Missing buffer size check in inline_receive()
Patch 3: Missing bounds check in port_parameter_set()
Patch 4: Integer underflow in port_parameter_get()
All four issues affect both ARM32 and ARM64 Raspberry Pi kernels.
Found through manual source code auditing.
I would like to request separate CVE assignments for each
independently exploitable vulnerability.
Reported-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
^ permalink raw reply
* [PATCH 2/2] staging: vc04_services: vc-sm-cma: add address validation in clean_invalid_contig_2d()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062004.492812-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
clean_invalid_contig_2d() performs cache maintenance operations
(dmac_inv_range, dmac_clean_range, dmac_flush_range) on a user-supplied
virtual address without verifying that it falls within the user address
space. A local attacker can pass a kernel virtual address via the
VC_SM_CMA_CMD_CLEAN_INVALID2 ioctl, causing the kernel to execute cache
maintenance operations on arbitrary kernel memory, potentially leading
to data corruption or information disclosure.
Add access_ok() validation to verify the entire address range falls
within userspace before performing any cache operations. Also add
overflow checks using check_mul_overflow()/check_add_overflow() for the
range computation to prevent size_t wraparound.
The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
reachable by any unprivileged local user on 32-bit Raspberry Pi
kernels.
Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
.../staging/vc04_services/vc-sm-cma/vc_sm.c | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
index d597d41b4..29aa5a939 100644
--- a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
+++ b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
@@ -40,6 +40,7 @@
#include <linux/module.h>
#include <linux/mm.h>
#include <linux/of_device.h>
+#include <linux/overflow.h>
#include <linux/platform_device.h>
#include <linux/proc_fs.h>
#include <linux/slab.h>
@@ -1263,6 +1264,8 @@ static int clean_invalid_contig_2d(const void __user *addr,
const unsigned int cache_op)
{
size_t i;
+ size_t last_block_offset;
+ size_t total_range;
void (*op_fn)(const void *start, const void *end);
if (!block_size) {
@@ -1270,11 +1273,27 @@ static int clean_invalid_contig_2d(const void __user *addr,
return -EINVAL;
}
+ if (!block_count)
+ return 0;
+
op_fn = cache_op_to_func(cache_op);
if (!op_fn)
return -EINVAL;
- for (i = 0; i < block_count; i ++, addr += stride)
+ /*
+ * Validate that the entire user-supplied address range falls
+ * within userspace. Without this check, an attacker could
+ * invoke cache maintenance operations on kernel addresses.
+ */
+ if (check_mul_overflow((size_t)(block_count - 1), stride,
+ &last_block_offset))
+ return -EOVERFLOW;
+ if (check_add_overflow(last_block_offset, block_size, &total_range))
+ return -EOVERFLOW;
+ if (!access_ok(addr, total_range))
+ return -EFAULT;
+
+ for (i = 0; i < block_count; i++, addr += stride)
op_fn(addr, addr + block_size);
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062004.492812-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
compute the allocation size passed to kmalloc(). Since ioparam.op_count
is a __u32 supplied directly by userspace via ioctl, an attacker can
choose a value that causes the multiplication to overflow on 32-bit
platforms, resulting in a small allocation followed by a large
copy_from_user() and out-of-bounds heap reads in the subsequent loop.
Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
Also add an early return for op_count == 0 to avoid a zero-size
allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
correctly indicate out of memory.
The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
reachable by any unprivileged local user.
Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vc-sm-cma/vc_sm.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
index 34155d62a..d597d41b4 100644
--- a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
+++ b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
@@ -1292,9 +1292,13 @@ static int vc_sm_cma_clean_invalid2(unsigned int cmdnr, unsigned long arg)
__func__, cmdnr);
return -EFAULT;
}
- block = kmalloc(ioparam.op_count * sizeof(*block), GFP_KERNEL);
+
+ if (!ioparam.op_count)
+ return 0;
+
+ block = kmalloc_array(ioparam.op_count, sizeof(*block), GFP_KERNEL);
if (!block)
- return -EFAULT;
+ return -ENOMEM;
if (copy_from_user(block, (void *)(arg + sizeof(ioparam)),
ioparam.op_count * sizeof(*block)) != 0) {
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] staging: vc04_services: vc-sm-cma: fix security issues in clean_invalid2 ioctl
From: Sebastian Josue Alba Vives @ 2026-03-29 6:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, Dave Stevenson, kernel-list,
Sebastián Alba Vives
This series fixes two security issues in the VideoCore shared memory CMA
driver (vc-sm-cma), accessible via /dev/vc-sm-cma which is created with
mode 0666 (world-accessible, no authentication required).
Both bugs are in vc_sm_cma_clean_invalid2(), reachable via the
VC_SM_CMA_CMD_CLEAN_INVALID2 ioctl on 32-bit ARM kernels.
Patch 1: Integer overflow in kmalloc size computation
Patch 2: Missing address validation in cache maintenance operations
Both issues affect 32-bit Raspberry Pi kernels (RPi 1/2/3/Zero and
32-bit RPi 4/5 configurations) running the rpi-6.6.y kernel series.
Both issues were found through manual source code auditing.
I would like to request separate CVE assignments for each patch as they
are independent vulnerabilities.
Reported-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-1-krishnagopi487@gmail.com>
st,thermal-flags is a required property in SPEAr Thermal Sensor node,
which is incorrectly written as thermal_flags in spear13xx.dtsi.
Rename thermal_flags to st,thermal-flags to fix the property name
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v1:
- Reword the commit message and subject
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
arch/arm/boot/dts/st/spear13xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 159e941708ca..97357680dd51 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -332,7 +332,7 @@ wdt@ec800620 {
thermal@e07008c4 {
compatible = "st,thermal-spear1340";
reg = <0xe07008c4 0x4>;
- thermal_flags = <0x7000>;
+ st,thermal-flags = <0x7000>;
};
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-1-krishnagopi487@gmail.com>
Convert the SPEAr Thermal Sensor bindings to DT schema.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v1:
- Changed unevaluatedProperties to additionalProperties
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
2 files changed, 36 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt
deleted file mode 100644
index 93e3b67c102d..000000000000
--- a/Documentation/devicetree/bindings/thermal/spear-thermal.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* SPEAr Thermal
-
-Required properties:
-- compatible : "st,thermal-spear1340"
-- reg : Address range of the thermal registers
-- st,thermal-flags: flags used to enable thermal sensor
-
-Example:
-
- thermal@fc000000 {
- compatible = "st,thermal-spear1340";
- reg = <0xfc000000 0x1000>;
- st,thermal-flags = <0x7000>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
new file mode 100644
index 000000000000..e3462a974691
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr Thermal Sensor
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+
+properties:
+ compatible:
+ const: st,thermal-spear1340
+
+ reg:
+ maxItems: 1
+
+ st,thermal-flags:
+ description: flags used to enable thermal sensor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - st,thermal-flags
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal@fc000000 {
+ compatible = "st,thermal-spear1340";
+ reg = <0xfc000000 0x1000>;
+ st,thermal-flags = <0x7000>;
+ };
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
This patch series converts SPEAr Thermal Sensor bindings to DT schema
and corrects the thermal_flags property in spear13xx.dtsi to
st,thermal-flags.
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Gopi Krishna Menon (2):
dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
arch/arm/boot/dts/st/spear13xx.dtsi | 2 +-
3 files changed, 37 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
--
2.52.0
^ permalink raw reply
* Re: [PATCH v2 3/4] elf: align ET_DYN base to max folio size for PTE coalescing
From: WANG Rui @ 2026-03-29 4:37 UTC (permalink / raw)
To: usama.arif
Cc: Liam.Howlett, ajd, akpm, apopple, baohua, baolin.wang, brauner,
catalin.marinas, david, dev.jain, jack, kees, kevin.brodsky,
lance.yang, linux-arm-kernel, linux-fsdevel, linux-kernel,
linux-mm, lorenzo.stoakes, mhocko, npache, pasha.tatashin, r,
rmclure, rppt, ryan.roberts, surenb, vbabka, viro, willy
In-Reply-To: <0725ce97-b8a3-47c9-952f-7b512873cc35@linux.dev>
> mapping_max_folio_size() reflects what the page cache will actually
> allocate for a given filesystem, since readahead caps folio allocation
> at mapping_max_folio_order() (in page_cache_ra_order()). If btrfs
> reports PAGE_SIZE, readahead won't allocate large folios for it, so
> there are no large folios to coalesce PTEs for, aligning the binary
> beyond that would only reduce ASLR entropy for no benefit.
>
> I don't think we should over-align binaries on filesystems that can't
> take advantage of it.
Ah, it looks like this might be overlooking another path that can create
huge page mappings for read-only code segments: even when the filesystem
(e.g. btrfs without experimental) didn't support large folios,
READ_ONLY_THP_FOR_FS still allowed read-only file-backed code segments
to be collapsed into huge page mappings via khugepaged.
As Wilcox pointed out, it may take quite some time for many filesystems
to gain full large folio support? So what I'm trying to clarify is that
using mapping_max_folio_size() on this path is not favorable for
khugepaged-based optimizations.
Thanks,
Rui
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Andrew Lunn @ 2026-03-29 3:20 UTC (permalink / raw)
To: Anirudh Srinivasan
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <CAJ13v3S7ucjd-ifmKFBDGtsg32MbOar2OBeiGMVEJBsH8+JP7Q@mail.gmail.com>
On Sat, Mar 28, 2026 at 07:14:04PM -0500, Anirudh Srinivasan wrote:
> Hi Andrew
>
> On Sat, Mar 28, 2026 at 7:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Sat, Mar 28, 2026 at 06:39:59PM -0500, Anirudh Srinivasan wrote:
> > > Adds the DT nodes needed for ethernet support for Asus Kommando, with
> > > phy mode set to rgmii-id.
> > >
> > > When this DT was originally added, the phy mode was set to rgmii (which
> > > was incorrect). It was suggested to remove networking support from the
> > > DT till the Aspeed networking driver was patched so that the correct phy
> > > mode could be used.
> > >
> > > The discussion in [1] mentions that u-boot was inserting clk delays that
> > > weren't needed, which resulted in needing to set the phy mode in linux
> > > to rgmii incorrectly. The solution suggested there was to patch u-boot to
> > > no longer insert these clk delays and use rgmii-id as the phy mode for
> > > any future DTs added to linux.
> > >
> > > This DT was tested with a u-boot DT modified to insert clk delays of 0
> > > (instead of patching u-boot itself). [2] adds a u-boot DT for this
> > > device (without networking) and describes how to patch it to add
> > > networking support. If this patched DT is used, then networking works
> > > with rgmii-id phy mode in both u-boot and linux.
> >
> > I've been looking at
> >
> > https://elixir.bootlin.com/u-boot/v2026.04-rc5/source/drivers/clk/aspeed/clk_ast2600.c
> >
> > And i don't see where mac2-clk-delay is implemented. Could you point
> > out the code?
>
> I'm testing against the u-boot version that openbmc uses for its
> builds. I don't think upstream u-boot is used by openbmc.
>
> https://github.com/openbmc/u-boot/blob/v2019.04-aspeed-openbmc/drivers/clk/aspeed/clk_ast2600.c#L999
Please include in the commit message that you need to use a fork of
u-boot.
Andrew
^ permalink raw reply
* [PATCH] ARM: rpc: ecard: bound variable-length chunk reads
From: Pengpeng Hou @ 2026-03-29 3:09 UTC (permalink / raw)
To: linux; +Cc: linux-arm-kernel, linux-kernel, pengpeng
ecard_readchunk() reads variable-length string chunk payloads into a fixed 256-byte local buffer without checking whether the encoded chunk length actually fits.
Treat overlong string chunks as invalid and terminate accepted ones before copying them into the exported chunk directory buffer.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/mach-rpc/ecard.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-rpc/ecard.c b/arch/arm/mach-rpc/ecard.c
index 972465840548..1340ef0364f8 100644
--- a/arch/arm/mach-rpc/ecard.c
+++ b/arch/arm/mach-rpc/ecard.c
@@ -367,9 +367,12 @@ int ecard_readchunk(struct in_chunk_dir *cd, ecard_t *ec, int id, int num)
if (c_id(&excd) & 0x80) {
switch (c_id(&excd) & 0x70) {
case 0x70:
+ if (c_len(&excd) >= sizeof(excd.d.string))
+ return 0;
ecard_readbytes((unsigned char *)excd.d.string, ec,
(int)c_start(&excd), c_len(&excd),
useld);
+ excd.d.string[c_len(&excd)] = '\0';
break;
case 0x00:
break;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Anirudh Srinivasan @ 2026-03-29 0:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <ed3d39df-0a0e-427b-86cf-b9b2d2094b51@lunn.ch>
Hi Andrew
On Sat, Mar 28, 2026 at 7:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Sat, Mar 28, 2026 at 06:39:59PM -0500, Anirudh Srinivasan wrote:
> > Adds the DT nodes needed for ethernet support for Asus Kommando, with
> > phy mode set to rgmii-id.
> >
> > When this DT was originally added, the phy mode was set to rgmii (which
> > was incorrect). It was suggested to remove networking support from the
> > DT till the Aspeed networking driver was patched so that the correct phy
> > mode could be used.
> >
> > The discussion in [1] mentions that u-boot was inserting clk delays that
> > weren't needed, which resulted in needing to set the phy mode in linux
> > to rgmii incorrectly. The solution suggested there was to patch u-boot to
> > no longer insert these clk delays and use rgmii-id as the phy mode for
> > any future DTs added to linux.
> >
> > This DT was tested with a u-boot DT modified to insert clk delays of 0
> > (instead of patching u-boot itself). [2] adds a u-boot DT for this
> > device (without networking) and describes how to patch it to add
> > networking support. If this patched DT is used, then networking works
> > with rgmii-id phy mode in both u-boot and linux.
>
> I've been looking at
>
> https://elixir.bootlin.com/u-boot/v2026.04-rc5/source/drivers/clk/aspeed/clk_ast2600.c
>
> And i don't see where mac2-clk-delay is implemented. Could you point
> out the code?
I'm testing against the u-boot version that openbmc uses for its
builds. I don't think upstream u-boot is used by openbmc.
https://github.com/openbmc/u-boot/blob/v2019.04-aspeed-openbmc/drivers/clk/aspeed/clk_ast2600.c#L999
>
> Thanks
> Andrew
--
Regards
Anirudh Srinivasan
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: stmmac: TSO fixes/cleanups
From: Russell King (Oracle) @ 2026-03-29 0:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
On Sat, Mar 28, 2026 at 09:36:21PM +0000, Russell King (Oracle) wrote:
> Hot off the press from reading various sources of dwmac information,
> this series attempts to fix the buggy hacks that were previously
> merged, and clean up the code handling this.
>
> I'm not sure whether "TSO" or "GSO" should be used to describe this
> feature - although it primarily handles TCP, dwmac4 appears to also
> be able to handle UDP.
>
> In essence, this series adds a .ndo_features_check() method to handle
> whether TSO/GSO can be used for a particular skbuff - checking which
> queue the skbuff is destined for and whether that has TBS available
> which precludes TSO being enabled on that channel.
>
> I'm also adding a check that the header is smaller than 1024 bytes,
> as documented in those sources which have TSO support - this is due
> to the hardware buffering the header in "TSO memory" which I guess
> is limited to 1KiB. I expect this test never to trigger, but if
> the headers ever exceed that size, the hardware will likely fail.
>
> I'm also moving the VLAN insertion for TSO packets into core code -
> with the addition of .do_Features_check(), this can be done and
> unnecessary code removed from the stmmac driver.
>
> I've changed the hardware initialisation to always enable TSO support
> on the channels even if the user requests TSO/GSO to be disabled -
> this fixes another issue as pointed out by Jakub in a previous review
> of the two patches (now patches 5 and 6.)
>
> I'm moving the setup of the GSO features, cleaning those up, and
> adding a warning if platform glue requests this to be enabled but the
> hardware has no support. Hopefully this will never trigger if everyone
> got the STMMAC_FLAG_TSO_EN flag correct.
>
> Also move the "TSO supported" message to the new
> stmmac_set_gso_features() function so keep all this TSO stuff together.
There are a few more issues that I would like to fix in this driver
in respect of the TSO support.
STM32MP151 and STM32MP25xx both state that when the TSE bit is set
in the channel Tx control register, TxPBL must be >= 4. We don't
check that is the case. Sadly, the documentation doesn't say whether
it's the TxPBL field value or the burst limit itself (there's the PBLx8
bit which multiplies the values in the field by 8.) Given the unknowns
here, I don't have a solution for this yet.
The other restriction is that the MSS[13:0] value must be greater than
the dwmac core's configured data width in bytes, with a recommendation
that it is 64 bytes or more. MSS[13:0] comes from
skb_shinfo(skb)->gso_size. However, the header plus the MSS size must
not exceed 16383 bytes. I think this can be catered for by adding
another test in the new stmmac_features_check() function:
if (skb_is_gso(skb)) {
headlen = skb_headlen(skb);
gso_size = skb_shinfo(skb)->gso_size;
...
if (headlen > 1023 || gso_size < 64 ||
gso_size + headlen > 16383)
features &= ~NETIF_F_GSO_MASK;
What I haven't worked out yet is whether any of these conditions
just "can't happen" with our networking layers - I suspect the
gso_size < 64 would be one such case.
Next, the hardware has a maximum size for segmentation, which is 256KiB.
I think that needs netif_set_tso_max_size(dev, 256KiB). We're currently
safe, because the default is 64KiB, and I'd worry about whether we'd
overflow the space in the TX descriptor ring.
If anyone has any comments on the above, that would be good. Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Andrew Lunn @ 2026-03-29 0:05 UTC (permalink / raw)
To: Anirudh Srinivasan
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260328-asus-kommando-networking-v1-1-66d308b88536@gmail.com>
On Sat, Mar 28, 2026 at 06:39:59PM -0500, Anirudh Srinivasan wrote:
> Adds the DT nodes needed for ethernet support for Asus Kommando, with
> phy mode set to rgmii-id.
>
> When this DT was originally added, the phy mode was set to rgmii (which
> was incorrect). It was suggested to remove networking support from the
> DT till the Aspeed networking driver was patched so that the correct phy
> mode could be used.
>
> The discussion in [1] mentions that u-boot was inserting clk delays that
> weren't needed, which resulted in needing to set the phy mode in linux
> to rgmii incorrectly. The solution suggested there was to patch u-boot to
> no longer insert these clk delays and use rgmii-id as the phy mode for
> any future DTs added to linux.
>
> This DT was tested with a u-boot DT modified to insert clk delays of 0
> (instead of patching u-boot itself). [2] adds a u-boot DT for this
> device (without networking) and describes how to patch it to add
> networking support. If this patched DT is used, then networking works
> with rgmii-id phy mode in both u-boot and linux.
I've been looking at
https://elixir.bootlin.com/u-boot/v2026.04-rc5/source/drivers/clk/aspeed/clk_ast2600.c
And i don't see where mac2-clk-delay is implemented. Could you point
out the code?
Thanks
Andrew
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Anirudh Srinivasan @ 2026-03-28 23:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: Andrew Lunn, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Anirudh Srinivasan
Adds the DT nodes needed for ethernet support for Asus Kommando, with
phy mode set to rgmii-id.
When this DT was originally added, the phy mode was set to rgmii (which
was incorrect). It was suggested to remove networking support from the
DT till the Aspeed networking driver was patched so that the correct phy
mode could be used.
The discussion in [1] mentions that u-boot was inserting clk delays that
weren't needed, which resulted in needing to set the phy mode in linux
to rgmii incorrectly. The solution suggested there was to patch u-boot to
no longer insert these clk delays and use rgmii-id as the phy mode for
any future DTs added to linux.
This DT was tested with a u-boot DT modified to insert clk delays of 0
(instead of patching u-boot itself). [2] adds a u-boot DT for this
device (without networking) and describes how to patch it to add
networking support. If this patched DT is used, then networking works
with rgmii-id phy mode in both u-boot and linux.
[1] https://lore.kernel.org/linux-aspeed/ef88bb50-9f2c-458d-a7e5-dc5ecb9c777a@lunn.ch/
[2] https://lore.kernel.org/openbmc/20260328-asus-kommando-v2-1-2a656f8cd314@gmail.com/
Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
---
This patch is based off aspeed/arm/dt from bmc tree
---
.../dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
index ab7ad320067c1ddc0fea9ac386fd488c8ef28184..e0f7d92efa18ccbad2c336236c3b9d01b7de1bba 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
@@ -107,6 +107,24 @@ &gpio1 {
/*18E0 32*/ "","","","","","","","";
};
+&mac2 {
+ status = "okay";
+
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii3_default>;
+};
+
+&mdio2 {
+ status = "okay";
+
+ ethphy2: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
&vhub {
status = "okay";
};
---
base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
change-id: 20260328-asus-kommando-networking-5c0612aa6b8c
Best regards,
--
Anirudh Srinivasan <anirudhsriniv@gmail.com>
^ permalink raw reply related
* Re: [PATCH] net: stmmac: dwmac-rk: Fix typo in comment
From: Russell King (Oracle) @ 2026-03-28 22:26 UTC (permalink / raw)
To: 谢致邦 (XIE Zhibang)
Cc: linux-rockchip, Heiko Stuebner, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Alexandre Torgue, linux-arm-kernel, netdev, linux-stm32,
linux-kernel
In-Reply-To: <tencent_833D2AD6577F21CF38ED1C3FE8814EB4B308@qq.com>
On Sat, Mar 28, 2026 at 01:43:31PM +0000, 谢致邦 (XIE Zhibang) wrote:
> Correct the typo "rk3520" to "rk3528" in comment.
>
> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v4 5/6] drm/mediatek: Support multiple CCORR component
From: kernel test robot @ 2026-03-28 22:05 UTC (permalink / raw)
To: Jay Liu, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: llvm, oe-kbuild-all, dri-devel, linux-mediatek, devicetree,
linux-kernel, linux-arm-kernel, Jay Liu
In-Reply-To: <20260324125315.4715-6-jay.liu@mediatek.com>
Hi Jay,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next pza/reset/next linus/master v7.0-rc5 next-20260327]
[cannot apply to pza/imx-drm/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Jay-Liu/dt-bindings-display-mediatek-gamma-Add-support-for-MT8196/20260328-083359
base: https://gitlab.freedesktop.org/drm/misc/kernel.git drm-misc-next
patch link: https://lore.kernel.org/r/20260324125315.4715-6-jay.liu%40mediatek.com
patch subject: [PATCH v4 5/6] drm/mediatek: Support multiple CCORR component
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260329/202603290611.fr83Gu7M-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 054e11d1a17e5ba88bb1a8ef32fad3346e80b186)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260329/202603290611.fr83Gu7M-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603290611.fr83Gu7M-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/mediatek/mtk_ddp_comp.c:461:3: error: use of undeclared identifier 'DDP_COMPONENT_CCORR0'; did you mean 'DDP_COMPONENT_CCORR'?
461 | [DDP_COMPONENT_CCORR0] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
| ^~~~~~~~~~~~~~~~~~~~
| DDP_COMPONENT_CCORR
include/linux/soc/mediatek/mtk-mmsys.h:27:2: note: 'DDP_COMPONENT_CCORR' declared here
27 | DDP_COMPONENT_CCORR,
| ^
>> drivers/gpu/drm/mediatek/mtk_ddp_comp.c:462:3: error: use of undeclared identifier 'DDP_COMPONENT_CCORR1'; did you mean 'DDP_COMPONENT_CCORR'?
462 | [DDP_COMPONENT_CCORR1] = { MTK_DISP_CCORR, 1, &ddp_ccorr },
| ^~~~~~~~~~~~~~~~~~~~
| DDP_COMPONENT_CCORR
include/linux/soc/mediatek/mtk-mmsys.h:27:2: note: 'DDP_COMPONENT_CCORR' declared here
27 | DDP_COMPONENT_CCORR,
| ^
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:462:28: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
462 | [DDP_COMPONENT_CCORR1] = { MTK_DISP_CCORR, 1, &ddp_ccorr },
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:461:28: note: previous initialization is here
461 | [DDP_COMPONENT_CCORR0] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning and 2 errors generated.
vim +461 drivers/gpu/drm/mediatek/mtk_ddp_comp.c
456
457 static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_DRM_ID_MAX] = {
458 [DDP_COMPONENT_AAL0] = { MTK_DISP_AAL, 0, &ddp_aal },
459 [DDP_COMPONENT_AAL1] = { MTK_DISP_AAL, 1, &ddp_aal },
460 [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
> 461 [DDP_COMPONENT_CCORR0] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
> 462 [DDP_COMPONENT_CCORR1] = { MTK_DISP_CCORR, 1, &ddp_ccorr },
463 [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
464 [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
465 [DDP_COMPONENT_DITHER0] = { MTK_DISP_DITHER, 0, &ddp_dither },
466 [DDP_COMPONENT_DP_INTF0] = { MTK_DP_INTF, 0, &ddp_dpi },
467 [DDP_COMPONENT_DP_INTF1] = { MTK_DP_INTF, 1, &ddp_dpi },
468 [DDP_COMPONENT_DPI0] = { MTK_DPI, 0, &ddp_dpi },
469 [DDP_COMPONENT_DPI1] = { MTK_DPI, 1, &ddp_dpi },
470 [DDP_COMPONENT_DRM_OVL_ADAPTOR] = { MTK_DISP_OVL_ADAPTOR, 0, &ddp_ovl_adaptor },
471 [DDP_COMPONENT_DSC0] = { MTK_DISP_DSC, 0, &ddp_dsc },
472 [DDP_COMPONENT_DSC1] = { MTK_DISP_DSC, 1, &ddp_dsc },
473 [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, &ddp_dsi },
474 [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, &ddp_dsi },
475 [DDP_COMPONENT_DSI2] = { MTK_DSI, 2, &ddp_dsi },
476 [DDP_COMPONENT_DSI3] = { MTK_DSI, 3, &ddp_dsi },
477 [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
478 [DDP_COMPONENT_MERGE0] = { MTK_DISP_MERGE, 0, &ddp_merge },
479 [DDP_COMPONENT_MERGE1] = { MTK_DISP_MERGE, 1, &ddp_merge },
480 [DDP_COMPONENT_MERGE2] = { MTK_DISP_MERGE, 2, &ddp_merge },
481 [DDP_COMPONENT_MERGE3] = { MTK_DISP_MERGE, 3, &ddp_merge },
482 [DDP_COMPONENT_MERGE4] = { MTK_DISP_MERGE, 4, &ddp_merge },
483 [DDP_COMPONENT_MERGE5] = { MTK_DISP_MERGE, 5, &ddp_merge },
484 [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
485 [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
486 [DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, &ddp_ovl },
487 [DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, &ddp_ovl },
488 [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L, 0, &ddp_ovl },
489 [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L, 1, &ddp_ovl },
490 [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L, 2, &ddp_ovl },
491 [DDP_COMPONENT_POSTMASK0] = { MTK_DISP_POSTMASK, 0, &ddp_postmask },
492 [DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
493 [DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
494 [DDP_COMPONENT_PWM2] = { MTK_DISP_PWM, 2, NULL },
495 [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, &ddp_rdma },
496 [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, &ddp_rdma },
497 [DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, &ddp_rdma },
498 [DDP_COMPONENT_RDMA4] = { MTK_DISP_RDMA, 4, &ddp_rdma },
499 [DDP_COMPONENT_UFOE] = { MTK_DISP_UFOE, 0, &ddp_ufoe },
500 [DDP_COMPONENT_WDMA0] = { MTK_DISP_WDMA, 0, NULL },
501 [DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
502 };
503
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net-next 10/10] net: stmmac: move "TSO supported" message to stmmac_set_gso_features()
From: Russell King (Oracle) @ 2026-03-28 21:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
Move the "TSO supported" message to stmmac_set_gso_features() so that
we group all probe-time TSO stuff in one place.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c61ce1282368..d281793cd0f9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4385,6 +4385,9 @@ static void stmmac_set_gso_features(struct net_device *ndev)
{
struct stmmac_priv *priv = netdev_priv(ndev);
+ if (priv->dma_cap.tsoen)
+ dev_info(priv->device, "TSO supported\n");
+
if (!(priv->plat->flags & STMMAC_FLAG_TSO_EN))
return;
@@ -7432,9 +7435,6 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
devm_pm_set_wake_irq(priv->device, priv->wol_irq);
}
- if (priv->dma_cap.tsoen)
- dev_info(priv->device, "TSO supported\n");
-
if (priv->dma_cap.number_rx_queues &&
priv->plat->rx_queues_to_use > priv->dma_cap.number_rx_queues) {
dev_warn(priv->device,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 08/10] net: stmmac: make stmmac_set_gso_features() more readable
From: Russell King (Oracle) @ 2026-03-28 21:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
Make stmmac_set_gso_features() more readable by adding some whitespace
and getting rid of the indentation.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4442358e8280..3bfa4bbe857f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4385,13 +4385,19 @@ static void stmmac_set_gso_features(struct net_device *ndev)
{
struct stmmac_priv *priv = netdev_priv(ndev);
- if ((priv->plat->flags & STMMAC_FLAG_TSO_EN) && (priv->dma_cap.tsoen)) {
- ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
- if (priv->plat->core_type == DWMAC_CORE_GMAC4)
- ndev->hw_features |= NETIF_F_GSO_UDP_L4;
- stmmac_set_gso_types(priv, true);
- dev_info(priv->device, "TSO feature enabled\n");
- }
+ if (!(priv->plat->flags & STMMAC_FLAG_TSO_EN))
+ return;
+
+ if (!priv->dma_cap.tsoen)
+ return;
+
+ ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
+ if (priv->plat->core_type == DWMAC_CORE_GMAC4)
+ ndev->hw_features |= NETIF_F_GSO_UDP_L4;
+
+ stmmac_set_gso_types(priv, true);
+
+ dev_info(priv->device, "TSO feature enabled\n");
}
/**
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 09/10] net: stmmac: add warning when TSO is requested but unsupported
From: Russell King (Oracle) @ 2026-03-28 21:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
Add a warning message if TSO is requested by the platform glue code but
the core wasn't configured for TSO.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3bfa4bbe857f..c61ce1282368 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4388,8 +4388,10 @@ static void stmmac_set_gso_features(struct net_device *ndev)
if (!(priv->plat->flags & STMMAC_FLAG_TSO_EN))
return;
- if (!priv->dma_cap.tsoen)
+ if (!priv->dma_cap.tsoen) {
+ dev_warn(priv->device, "platform requests unsupported TSO\n");
return;
+ }
ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
if (priv->plat->core_type == DWMAC_CORE_GMAC4)
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 06/10] net: stmmac: simplify GSO/TSO test in stmmac_xmit()
From: Russell King (Oracle) @ 2026-03-28 21:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
The test in stmmac_xmit() to see whether we should pass the skbuff to
stmmac_tso_xmit() is more complex than it needs to be. This test can
be simplified by storing the mask of GSO types that we will pass, and
setting it according to the enabled features.
Note that "tso" is a mis-nomer since commit b776620651a1 ("net:
stmmac: Implement UDP Segmentation Offload"). Also note that this
commit controls both via the TSO feature. We preserve this behaviour
in this commit.
Also, this commit unconditionally accessed skb_shinfo(skb)->gso_type
for all frames, even when skb_is_gso() was false. This access is
eliminated.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 28 +++++++++++--------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 919a93a52390..8ba8f03e1ce0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -265,8 +265,9 @@ struct stmmac_priv {
u32 rx_coal_frames[MTL_MAX_RX_QUEUES];
int hwts_tx_en;
+ /* skb_shinfo(skb)->gso_type types that we handle */
+ unsigned int gso_enabled_types;
bool tx_path_in_lpi_mode;
- bool tso;
bool sph_active;
bool sph_capable;
u32 sarc_type;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9730535d2dd8..8991da2f96a9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4369,6 +4369,18 @@ static void stmmac_flush_tx_descriptors(struct stmmac_priv *priv, int queue)
stmmac_set_queue_tx_tail_ptr(priv, tx_q, queue, tx_q->cur_tx);
}
+static void stmmac_set_gso_types(struct stmmac_priv *priv, bool tso)
+{
+ if (!tso) {
+ priv->gso_enabled_types = 0;
+ } else {
+ /* Manage oversized TCP frames for GMAC4 device */
+ priv->gso_enabled_types = SKB_GSO_TCPV4 | SKB_GSO_TCPV6;
+ if (priv->plat->core_type == DWMAC_CORE_GMAC4)
+ priv->gso_enabled_types |= SKB_GSO_UDP_L4;
+ }
+}
+
/**
* stmmac_tso_xmit - Tx entry point of the driver for oversized frames (TSO)
* @skb : the socket buffer
@@ -4671,7 +4683,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
u32 queue = skb_get_queue_mapping(skb);
int nfrags = skb_shinfo(skb)->nr_frags;
unsigned int first_entry, tx_packets;
- int gso = skb_shinfo(skb)->gso_type;
struct stmmac_txq_stats *txq_stats;
struct dma_desc *desc, *first_desc;
struct stmmac_tx_queue *tx_q;
@@ -4683,14 +4694,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
if (priv->tx_path_in_lpi_mode && priv->eee_sw_timer_en)
stmmac_stop_sw_lpi(priv);
- /* Manage oversized TCP frames for GMAC4 device */
- if (skb_is_gso(skb) && priv->tso) {
- if (gso & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
- return stmmac_tso_xmit(skb, dev);
- if (priv->plat->core_type == DWMAC_CORE_GMAC4 &&
- (gso & SKB_GSO_UDP_L4))
- return stmmac_tso_xmit(skb, dev);
- }
+ if (skb_is_gso(skb) &&
+ skb_shinfo(skb)->gso_type & priv->gso_enabled_types)
+ return stmmac_tso_xmit(skb, dev);
if (priv->est && priv->est->enable &&
priv->est->max_sdu[queue]) {
@@ -6128,7 +6134,7 @@ static int stmmac_set_features(struct net_device *netdev,
stmmac_enable_sph(priv, priv->ioaddr, sph_en, chan);
}
- priv->tso = !!(features & NETIF_F_TSO);
+ stmmac_set_gso_types(priv, features & NETIF_F_TSO);
if (features & NETIF_F_HW_VLAN_CTAG_RX)
priv->hw->hw_vlan_en = true;
@@ -7863,7 +7869,7 @@ static int __stmmac_dvr_probe(struct device *device,
ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
if (priv->plat->core_type == DWMAC_CORE_GMAC4)
ndev->hw_features |= NETIF_F_GSO_UDP_L4;
- priv->tso = true;
+ stmmac_set_gso_types(priv, true);
dev_info(priv->device, "TSO feature enabled\n");
}
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 07/10] net: stmmac: split out gso features setup
From: Russell King (Oracle) @ 2026-03-28 21:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
Move the GSO features setup into a separate function, co-loated with
other GSO/TSO support.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 21 ++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8991da2f96a9..4442358e8280 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4381,6 +4381,19 @@ static void stmmac_set_gso_types(struct stmmac_priv *priv, bool tso)
}
}
+static void stmmac_set_gso_features(struct net_device *ndev)
+{
+ struct stmmac_priv *priv = netdev_priv(ndev);
+
+ if ((priv->plat->flags & STMMAC_FLAG_TSO_EN) && (priv->dma_cap.tsoen)) {
+ ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
+ if (priv->plat->core_type == DWMAC_CORE_GMAC4)
+ ndev->hw_features |= NETIF_F_GSO_UDP_L4;
+ stmmac_set_gso_types(priv, true);
+ dev_info(priv->device, "TSO feature enabled\n");
+ }
+}
+
/**
* stmmac_tso_xmit - Tx entry point of the driver for oversized frames (TSO)
* @skb : the socket buffer
@@ -7865,13 +7878,7 @@ static int __stmmac_dvr_probe(struct device *device,
ndev->hw_features |= NETIF_F_HW_TC;
}
- if ((priv->plat->flags & STMMAC_FLAG_TSO_EN) && (priv->dma_cap.tsoen)) {
- ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
- if (priv->plat->core_type == DWMAC_CORE_GMAC4)
- ndev->hw_features |= NETIF_F_GSO_UDP_L4;
- stmmac_set_gso_types(priv, true);
- dev_info(priv->device, "TSO feature enabled\n");
- }
+ stmmac_set_gso_features(ndev);
if (priv->dma_cap.sphen &&
!(priv->plat->flags & STMMAC_FLAG_SPH_DISABLE)) {
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 05/10] net: stmmac: fix .ndo_fix_features()
From: Russell King (Oracle) @ 2026-03-28 21:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
netdev features documentation requires that .ndo_fix_features() is
stateless: it shouldn't modify driver state. Yet, stmmac_fix_features()
does exactly that, changing whether GSO frames are processed by the
driver.
Move this code to stmmac_set_features() instead, which is the correct
place for it. We don't need to check whether TSO is supported; this
is already handled via the setup of netdev->hw_features, and we are
guaranteed that if netdev->hw_features indicates that a feature is
not supported, .ndo_set_features() won't be called with it set.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f500fcc17ce5..9730535d2dd8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6102,14 +6102,6 @@ static netdev_features_t stmmac_fix_features(struct net_device *dev,
if (priv->plat->bugged_jumbo && (dev->mtu > ETH_DATA_LEN))
features &= ~NETIF_F_CSUM_MASK;
- /* Disable tso if asked by ethtool */
- if ((priv->plat->flags & STMMAC_FLAG_TSO_EN) && (priv->dma_cap.tsoen)) {
- if (features & NETIF_F_TSO)
- priv->tso = true;
- else
- priv->tso = false;
- }
-
return features;
}
@@ -6136,6 +6128,8 @@ static int stmmac_set_features(struct net_device *netdev,
stmmac_enable_sph(priv, priv->ioaddr, sph_en, chan);
}
+ priv->tso = !!(features & NETIF_F_TSO);
+
if (features & NETIF_F_HW_VLAN_CTAG_RX)
priv->hw->hw_vlan_en = true;
else
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 03/10] net: stmmac: move TSO VLAN tag insertion to core code
From: Russell King (Oracle) @ 2026-03-28 21:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
stmmac_tso_xmit() checks whether the skbuff is trying to offload
vlan tag insertion to hardware, which from the comment in the code
appears to be buggy when the TSO feature is used.
Rather than stmmac_tso_xmit() inserting the VLAN tag, handle this
in stmmac_features_check() which will then use core net code to
handle this. See net/core/dev.c::validate_xmit_skb()
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 21 +++++++------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e21ca1c70c6d..ed3e9515cf25 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4419,19 +4419,6 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
u8 proto_hdr_len, hdr;
dma_addr_t des;
- /* Always insert VLAN tag to SKB payload for TSO frames.
- *
- * Never insert VLAN tag by HW, since segments split by
- * TSO engine will be un-tagged by mistake.
- */
- if (skb_vlan_tag_present(skb)) {
- skb = __vlan_hwaccel_push_inside(skb);
- if (unlikely(!skb)) {
- priv->xstats.tx_dropped++;
- return NETDEV_TX_OK;
- }
- }
-
nfrags = skb_shinfo(skb)->nr_frags;
queue = skb_get_queue_mapping(skb);
@@ -4932,6 +4919,14 @@ static netdev_features_t stmmac_features_check(struct sk_buff *skb,
features = vlan_features_check(skb, features);
if (skb_is_gso(skb)) {
+ /* Always insert VLAN tag to SKB payload for TSO frames.
+ *
+ * Never insert VLAN tag by HW, since segments split by
+ * TSO engine will be un-tagged by mistake.
+ */
+ features &= ~(NETIF_F_HW_VLAN_STAG_TX |
+ NETIF_F_HW_VLAN_CTAG_TX);
+
/* STM32MP25xx (dwmac v5.3) states "Do not enable time-based
* scheduling for channels on which the TSO feature is
* enabled." If we have a skb for a channel which has TBS
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 04/10] net: stmmac: always enable channel TSO when supported
From: Russell King (Oracle) @ 2026-03-28 21:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
Rather than configuring the channels depending on whether GSO/TSO is
currently enabled by the user, always enable if the hardware has
TSO support and the platform wants TSO to be enabled.
This avoids TSO being disabled on a channel over a suspend/resume
when the user has disabled TSO features, and then the hardware
misbehaves when TSO is re-enabled.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ed3e9515cf25..f500fcc17ce5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3712,7 +3712,7 @@ static int stmmac_hw_setup(struct net_device *dev)
stmmac_set_rings_length(priv);
/* Enable TSO */
- if (priv->tso) {
+ if (priv->dma_cap.tsoen && priv->plat->flags & STMMAC_FLAG_TSO_EN) {
for (chan = 0; chan < tx_cnt; chan++) {
if (!stmmac_channel_tso_permitted(priv, chan))
continue;
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 02/10] net: stmmac: add TSO check for header length
From: Russell King (Oracle) @ 2026-03-28 21:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
According to the STM32MP151 documentation which covers dwmac v4.2, the
hardware TSO feature can handle header lengths up to a maximum of 1023
bytes.
Add a .ndo_features_check() method implementation to check the header
length meets these requirements, otherwise fall back to software GSO.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2957ee4a43db..e21ca1c70c6d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4940,6 +4940,14 @@ static netdev_features_t stmmac_features_check(struct sk_buff *skb,
queue = skb_get_queue_mapping(skb);
if (!stmmac_channel_tso_permitted(netdev_priv(dev), queue))
features &= ~NETIF_F_GSO_MASK;
+
+ /* STM32MP151 (dwmac v4.2) and STM32MP25xx (dwmac v5.3) states
+ * for TDES2 normal (read format) descriptor that the maximum
+ * header length supported for the TSO feature is 1023 bytes.
+ * Fall back to software GSO for these skbs.
+ */
+ if (skb_headlen(skb) > 1023)
+ features &= ~NETIF_F_GSO_MASK;
}
return features;
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox