* [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
* [PATCH net-next 01/10] net: stmmac: fix TSO support when some channels have TBS available
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 STM32MP25xx manual, which is dwmac v5.3, TBS (time
based scheduling) is not permitted for channels which have hardware
TSO enabled. Intel's commit 5e6038b88a57 ("net: stmmac: fix TSO and
TBS feature enabling during driver open") concurs with this, but it
is incomplete.
This commit avoids enabling TSO support on the channels which have
TBS available, which, as far as the hardware is concerned, means we
do not set the TSE bit in the DMA channel's transmit control register.
However, the net device's features apply to all queues(channels), which
means these channels may still be handed TSO skbs to transmit, and the
driver will pass them to stmmac_tso_xmit(). This will generate the
descriptors for TSO, even though the channel has the TSE bit clear.
Fix this by checking whether the queue(channel) has TBS available,
and if it does, fall back to software GSO support.
Fixes: 5e6038b88a57 ("net: stmmac: fix TSO and TBS feature enabling during driver open")
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++++++---
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ce51b9c22129..2957ee4a43db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3619,6 +3619,13 @@ static void stmmac_safety_feat_configuration(struct stmmac_priv *priv)
}
}
+static bool stmmac_channel_tso_permitted(struct stmmac_priv *priv,
+ unsigned int chan)
+{
+ /* TSO and TBS cannot co-exist */
+ return !(priv->dma_conf.tx_queue[chan].tbs & STMMAC_TBS_AVAIL);
+}
+
/**
* stmmac_hw_setup - setup mac in a usable state.
* @dev : pointer to the device structure.
@@ -3707,10 +3714,7 @@ static int stmmac_hw_setup(struct net_device *dev)
/* Enable TSO */
if (priv->tso) {
for (chan = 0; chan < tx_cnt; chan++) {
- struct stmmac_tx_queue *tx_q = &priv->dma_conf.tx_queue[chan];
-
- /* TSO and TBS cannot co-exist */
- if (tx_q->tbs & STMMAC_TBS_AVAIL)
+ if (!stmmac_channel_tso_permitted(priv, chan))
continue;
stmmac_enable_tso(priv, priv->ioaddr, 1, chan);
@@ -4919,6 +4923,28 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
+static netdev_features_t stmmac_features_check(struct sk_buff *skb,
+ struct net_device *dev,
+ netdev_features_t features)
+{
+ u16 queue;
+
+ features = vlan_features_check(skb, features);
+
+ if (skb_is_gso(skb)) {
+ /* 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
+ * enabled, fall back to software GSO.
+ */
+ queue = skb_get_queue_mapping(skb);
+ if (!stmmac_channel_tso_permitted(netdev_priv(dev), queue))
+ features &= ~NETIF_F_GSO_MASK;
+ }
+
+ return features;
+}
+
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
struct vlan_ethhdr *veth = skb_vlan_eth_hdr(skb);
@@ -7220,6 +7246,7 @@ static void stmmac_get_stats64(struct net_device *dev, struct rtnl_link_stats64
static const struct net_device_ops stmmac_netdev_ops = {
.ndo_open = stmmac_open,
.ndo_start_xmit = stmmac_xmit,
+ .ndo_features_check = stmmac_features_check,
.ndo_stop = stmmac_release,
.ndo_change_mtu = stmmac_change_mtu,
.ndo_fix_features = stmmac_fix_features,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 00/10] net: stmmac: TSO fixes/cleanups
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
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.
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 135 ++++++++++++++--------
2 files changed, 92 insertions(+), 46 deletions(-)
--
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 6/6] drm/mediatek: Add TDSHP component support for MT8196
From: kernel test robot @ 2026-03-28 20:08 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: oe-kbuild-all, dri-devel, linux-mediatek, devicetree,
linux-kernel, linux-arm-kernel, Jay Liu, CK Hu
In-Reply-To: <20260324125315.4715-7-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-7-jay.liu%40mediatek.com
patch subject: [PATCH v4 6/6] drm/mediatek: Add TDSHP component support for MT8196
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20260329/202603290406.4CTuDfmw-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260329/202603290406.4CTuDfmw-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/202603290406.4CTuDfmw-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:509:10: error: 'DDP_COMPONENT_CCORR0' undeclared here (not in a function); did you mean 'DDP_COMPONENT_CCORR'?
509 | [DDP_COMPONENT_CCORR0] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
| ^~~~~~~~~~~~~~~~~~~~
| DDP_COMPONENT_CCORR
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:509:10: error: array index in initializer not of integer type
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:509:10: note: (near initialization for 'mtk_ddp_matches')
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:510:10: error: 'DDP_COMPONENT_CCORR1' undeclared here (not in a function); did you mean 'DDP_COMPONENT_CCORR'?
510 | [DDP_COMPONENT_CCORR1] = { MTK_DISP_CCORR, 1, &ddp_ccorr },
| ^~~~~~~~~~~~~~~~~~~~
| DDP_COMPONENT_CCORR
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:510:10: error: array index in initializer not of integer type
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:510:10: note: (near initialization for 'mtk_ddp_matches')
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:511:43: warning: initialized field overwritten [-Woverride-init]
511 | [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
| ^
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:511:43: note: (near initialization for 'mtk_ddp_matches[4]')
>> drivers/gpu/drm/mediatek/mtk_ddp_comp.c:547:10: error: 'DDP_COMPONENT_TDSHP0' undeclared here (not in a function); did you mean 'DDP_COMPONENT_DSI0'?
547 | [DDP_COMPONENT_TDSHP0] = { MTK_DISP_TDSHP, 0, &ddp_tdshp },
| ^~~~~~~~~~~~~~~~~~~~
| DDP_COMPONENT_DSI0
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:547:10: error: array index in initializer not of integer type
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:547:10: note: (near initialization for 'mtk_ddp_matches')
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:548:43: warning: initialized field overwritten [-Woverride-init]
548 | [DDP_COMPONENT_UFOE] = { MTK_DISP_UFOE, 0, &ddp_ufoe },
| ^
drivers/gpu/drm/mediatek/mtk_ddp_comp.c:548:43: note: (near initialization for 'mtk_ddp_matches[57]')
vim +547 drivers/gpu/drm/mediatek/mtk_ddp_comp.c
504
505 static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_DRM_ID_MAX] = {
506 [DDP_COMPONENT_AAL0] = { MTK_DISP_AAL, 0, &ddp_aal },
507 [DDP_COMPONENT_AAL1] = { MTK_DISP_AAL, 1, &ddp_aal },
508 [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
509 [DDP_COMPONENT_CCORR0] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
> 510 [DDP_COMPONENT_CCORR1] = { MTK_DISP_CCORR, 1, &ddp_ccorr },
511 [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
512 [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
513 [DDP_COMPONENT_DITHER0] = { MTK_DISP_DITHER, 0, &ddp_dither },
514 [DDP_COMPONENT_DP_INTF0] = { MTK_DP_INTF, 0, &ddp_dpi },
515 [DDP_COMPONENT_DP_INTF1] = { MTK_DP_INTF, 1, &ddp_dpi },
516 [DDP_COMPONENT_DPI0] = { MTK_DPI, 0, &ddp_dpi },
517 [DDP_COMPONENT_DPI1] = { MTK_DPI, 1, &ddp_dpi },
518 [DDP_COMPONENT_DRM_OVL_ADAPTOR] = { MTK_DISP_OVL_ADAPTOR, 0, &ddp_ovl_adaptor },
519 [DDP_COMPONENT_DSC0] = { MTK_DISP_DSC, 0, &ddp_dsc },
520 [DDP_COMPONENT_DSC1] = { MTK_DISP_DSC, 1, &ddp_dsc },
521 [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, &ddp_dsi },
522 [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, &ddp_dsi },
523 [DDP_COMPONENT_DSI2] = { MTK_DSI, 2, &ddp_dsi },
524 [DDP_COMPONENT_DSI3] = { MTK_DSI, 3, &ddp_dsi },
525 [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
526 [DDP_COMPONENT_MERGE0] = { MTK_DISP_MERGE, 0, &ddp_merge },
527 [DDP_COMPONENT_MERGE1] = { MTK_DISP_MERGE, 1, &ddp_merge },
528 [DDP_COMPONENT_MERGE2] = { MTK_DISP_MERGE, 2, &ddp_merge },
529 [DDP_COMPONENT_MERGE3] = { MTK_DISP_MERGE, 3, &ddp_merge },
530 [DDP_COMPONENT_MERGE4] = { MTK_DISP_MERGE, 4, &ddp_merge },
531 [DDP_COMPONENT_MERGE5] = { MTK_DISP_MERGE, 5, &ddp_merge },
532 [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
533 [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
534 [DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, &ddp_ovl },
535 [DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, &ddp_ovl },
536 [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L, 0, &ddp_ovl },
537 [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L, 1, &ddp_ovl },
538 [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L, 2, &ddp_ovl },
539 [DDP_COMPONENT_POSTMASK0] = { MTK_DISP_POSTMASK, 0, &ddp_postmask },
540 [DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
541 [DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
542 [DDP_COMPONENT_PWM2] = { MTK_DISP_PWM, 2, NULL },
543 [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, &ddp_rdma },
544 [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, &ddp_rdma },
545 [DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, &ddp_rdma },
546 [DDP_COMPONENT_RDMA4] = { MTK_DISP_RDMA, 4, &ddp_rdma },
> 547 [DDP_COMPONENT_TDSHP0] = { MTK_DISP_TDSHP, 0, &ddp_tdshp },
548 [DDP_COMPONENT_UFOE] = { MTK_DISP_UFOE, 0, &ddp_ufoe },
549 [DDP_COMPONENT_WDMA0] = { MTK_DISP_WDMA, 0, NULL },
550 [DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
551 };
552
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-28 19:39 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maxime Ripard, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acclgID7lSVNten2@intel.com>
On Saturday, 28 March 2026 01:49:04 Central European Standard Time Ville Syrjälä wrote:
> On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > > > + * semantics.
> > > > > > > > > > > > + *
> > > > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > > > + *
> > > > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > >
> > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > should be for each format.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > by other properties.
> > > > > > > > > >
> > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > >
> > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > >
> > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > >
> > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > field of its own?
> > > > > > >
> > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > I think the assumption is limited range everywhere.
> > > > > > >
> > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > will want to know what the new property actually does so the
> > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > is no clear specification.
> > > > > >
> > > > > > Ack
> > > > > >
> > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > - YCbCr limited range
> > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > >
> > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > anything else full range?
> > > > >
> > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > those would always go hand in hand now.
> > > >
> > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > and uses the HDMI state helpers.
> > > >
> > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > drm_default_rgb_quant_range() which seems suspicious?
> > >
> > > If they want just manual full vs. limited then they should
> > > limit the property to not expose the "auto" option at all.
> > >
> > > amdgpu also ties this in with the "colorspace" property, which
> > > originally in i915 only controlled the infoframes/etc. But on
> > > amdgpu it now controls various aspects of output color
> > > transformation. The end result is that the property is a complete
> > > mess with most of the values making no sense. And for whatever
> > > reason everyone involved refused to remove/deprecate the
> > > nonsensical values :/
> > >
> > > Looks like this series should make sure the documentation for
> > > the "colorspace" property is in sync with the new property
> > > as well. Currently now it's giving conflicting information.
> > >
> >
> > I take it the problematic information is in
> >
> > * DOC: standard connector properties
> > *
> > * Colorspace:
> >
> > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > that they "produce RGB content".
> >
> > I think we probably just have to change the statement "The variants
> > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > RGB and YCbCr on its own."
> >
> > The "on its own" here would get turned into "based on the color format
> > property".
> >
> > Speaking of i915, that patch is one of the very few (5) patches in
> > this series still lacking a review (hint hint nudge nudge). I'd like
> > to get some more feedback on the remaining patches before I send out
> > another revision, so that it's hopefully not just docs changes (I
> > know better than to think those patches must be perfect and won't
> > need revision.)
>
> The i915 code around this is already a big mess, and I don't really
> adding to that mess. So I think we'll need to do some refactoring before
> we add anything there. I already started typing something and so far
> it looks fairly straightforward, so I should have something soon.
>
> While doing that several questions came to my mind though:
>
> * More interactions with the colorspace property, but I sent
> a separate mail already about that
>
> * Which conversion matrix to use, and the answer I suspect
> should be "ask the colorspace property", as mentioned in the
> other mail
>
> * Should we flat out reject color formats (and I suppose also
> colorspace prop values) the sink doesn't claim to support?
That is currently the intention, yes. In the common HDMI state
helper, hdmi_try_format_bpc will return false if a format isn't
supported by the sink at a certain bpc, and ultimately, make its
caller return -EINVAL if it's not supported at any bpc.
Userspace asking for something impossible will result in userspace
being told so during atomic check, or at least that's the intention.
> If yes, then I think we'll have to forget about adding anything
> to i915 MST code. The way the MST stuff works is that if one
> stream needs a modeset then all the related streams get modeset
> as well. Thus if the user replaces a monitor getting fed with a
> YCbCr stream just as another stream is being modeset, then the
> entire atomic commit could fail due to the YCbCr stream getting
> rejected.
Yeah, my patch has an MST implementation for i915 and it does "work"
for the simple case where monitors don't have different sets of
supported formats, but I think it's better we make MST just not
have the property. May also drop it from amdgpu as a consequence.
> I think eventually we might have to invent some mechanism where
> all the input into the modeset computation is cached somehow,
> and said cache updated only on explicit userspace modesets.
> Either that or we have to come up with a way to skip some of
> the calculations that depend on external factors. Either way
> it's going to be a pain.
>
> OTOH if we don't mind feeding the sink with stuff it can't
> understand, then I suppose we might add YCbCr 4:4:4 support
> for MST. It shouldn't be any different from RGB apart from
> the RGB->YCbCr conversion, which is handled elsewhere. But
> YCbCr 4:2:0 is definitely out either way, the MST code has
> no support for that currently.
My general approach so far has been that we should never feed
the sink anything it can't handle. This results in some fun edge
cases, e.g. my primary monitor (ASUS XG27AQDMG) does support
YCbCr 4:2:0 on all modes, but since I'm talking to it from an
HDMI 1.4b device, it only exposes the two modes in the EDID it
sends the device as YCbCr 4:2:0 that need it. In that case, the
kernel is stricter than the sink because it takes it by its word.
I think forcing userspace to make safer choices is preferable over
having the monitor lose its picture. If people want to be
adventurous, they can always override the EDID, and thus get away
with such things.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* [RESEND PATCH net v3 2/2] net: stmmac: Prevent indefinite RX stall on buffer exhaustion
From: Sam Edwards @ 2026-03-28 19:25 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Maxime Chevallier, Ovidiu Panait, Vladimir Oltean, Baruch Siach,
Serge Semin, Giuseppe Cavallaro, netdev, linux-stm32,
linux-arm-kernel, linux-kernel, Sam Edwards, stable
In-Reply-To: <20260328192503.520689-1-CFSworks@gmail.com>
The stmmac driver handles interrupts in the usual NAPI way: an interrupt
arrives, the NAPI instance is scheduled and interrupts are masked, and
the actual work occurs in the NAPI polling function. Once no further
work remains, interrupts are unmasked and the NAPI instance is put to
sleep to await a future interrupt. In the receive case, the MAC only
sends the interrupt when a DMA operation completes; thus the driver must
make sure a usable RX DMA descriptor exists before expecting a future
interrupt.
The main receive loop in stmmac_rx() exits under one of 3 conditions:
1) It encounters a DMA descriptor with OWN=1, indicating that no further
pending data exists. The MAC will use this descriptor for the next
RX DMA operation, so the driver can expect a future interrupt.
2) It exhausts the NAPI budget. In this case, the driver doesn't know
whether the MAC has any usable DMA descriptors. But when the driver
consumes its full budget, that signals NAPI to keep polling, so the
question is moot.
3) It runs out of (non-dirty) descriptors in the RX ring. In this case,
the MAC will only have a usable descriptor if stmmac_rx_refill()
succeeds (at least partially).
Currently, stmmac_rx() lacks any check against scenario #3 and
stmmac_rx_refill() failing: it will stop NAPI polling and unmask
interrupts to await an interrupt that will never arrive, stalling the
receive pipeline indefinitely.
Fix this by checking stmmac_rx_dirty(): it will return 0 if
stmmac_rx_refill() fully succeeded and we can safely await an interrupt.
Any nonzero value means some allocations failed, in which case we risk
dropping frames if a large traffic burst exhausts the surviving
non-dirties. Therefore, simply return the full budget (to keep polling)
until all allocations succeed.
Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
Cc: stable@vger.kernel.org
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f98b070073c0..81f764352f3d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5604,6 +5604,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
unsigned int desc_size;
struct sk_buff *skb = NULL;
struct stmmac_xdp_buff ctx;
+ int budget = limit;
int xdp_status = 0;
int bufsz;
@@ -5870,6 +5871,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
priv->xstats.rx_dropped += rx_dropped;
priv->xstats.rx_errors += rx_errors;
+ /* If stmmac_rx_refill() failed, keep trying until it doesn't. */
+ if (unlikely(stmmac_rx_dirty(priv, queue) > 0))
+ return budget;
+
return count;
}
--
2.52.0
^ permalink raw reply related
* [RESEND PATCH net v3 1/2] net: stmmac: Prevent NULL deref when RX memory exhausted
From: Sam Edwards @ 2026-03-28 19:25 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Maxime Chevallier, Ovidiu Panait, Vladimir Oltean, Baruch Siach,
Serge Semin, Giuseppe Cavallaro, netdev, linux-stm32,
linux-arm-kernel, linux-kernel, Sam Edwards, stable
In-Reply-To: <20260328192503.520689-1-CFSworks@gmail.com>
The CPU receives frames from the MAC through conventional DMA: the CPU
allocates buffers for the MAC, then the MAC fills them and returns
ownership to the CPU. For each hardware RX queue, the CPU and MAC
coordinate through a shared ring array of DMA descriptors: one
descriptor per DMA buffer. Each descriptor includes the buffer's
physical address and a status flag ("OWN") indicating which side owns
the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set
the flag and the MAC is only allowed to clear it, and both must move
through the ring in sequence: thus the ring is used for both
"submissions" and "completions."
In the stmmac driver, stmmac_rx() bookmarks its position in the ring
with the `cur_rx` index. The main receive loop in that function checks
for rx_descs[cur_rx].own=0, gives the corresponding buffer to the
network stack (NULLing the pointer), and increments `cur_rx` modulo the
ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
position with `dirty_rx`, allocates fresh buffers and rearms the
descriptors (setting OWN=1). If it fails any allocation, it simply stops
early (leaving OWN=0) and will retry where it left off when next called.
This means descriptors have a three-stage lifecycle (terms my own):
- `empty` (OWN=1, buffer valid)
- `full` (OWN=0, buffer valid and populated)
- `dirty` (OWN=0, buffer NULL)
But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In
the past (see 'Fixes:'), there was a bug where the loop could cycle
`cur_rx` all the way back to the first descriptor it dirtied, resulting
in a NULL dereference when mistaken for `full`. The aforementioned
commit resolved that *specific* failure by capping the loop's iteration
limit at `dma_rx_size - 1`, but this is only a partial fix: if the
previous stmmac_rx_refill() didn't complete, then there are leftover
`dirty` descriptors that the loop might encounter without needing to
cycle fully around. The current code therefore panics (see 'Closes:')
when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to
catch up to `dirty_rx`.
Fix this by further tightening the clamp from `dma_rx_size - 1` to
`dma_rx_size - stmmac_rx_dirty() - 1`, subtracting any remnant dirty
entries and limiting the loop so that `cur_rx` cannot catch back up to
`dirty_rx`. This carries no risk of arithmetic underflow: since the
maximum possible return value of stmmac_rx_dirty() is `dma_rx_size - 1`,
the worst the clamp can do is prevent the loop from running at all.
Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221010
Cc: stable@vger.kernel.org
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 6827c99bde8c..f98b070073c0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5609,7 +5609,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
dma_dir = page_pool_get_dma_dir(rx_q->page_pool);
bufsz = DIV_ROUND_UP(priv->dma_conf.dma_buf_sz, PAGE_SIZE) * PAGE_SIZE;
- limit = min(priv->dma_conf.dma_rx_size - 1, (unsigned int)limit);
+ limit = min(priv->dma_conf.dma_rx_size - stmmac_rx_dirty(priv, queue) - 1,
+ (unsigned int)limit);
if (netif_msg_rx_status(priv)) {
void *rx_head;
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox