* Re: [PATCH net-next 3/4] ethtool: strset: check nla_len overflow before nla_nest_end
From: Hangbin Liu @ 2026-04-01 7:27 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260331184637.58b968ef@kernel.org>
On Tue, Mar 31, 2026 at 06:46:37PM -0700, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 11:56:13 +0800 Hangbin Liu wrote:
> > + if (skb_tail_pointer(skb) - (unsigned char *)strings_attr > U16_MAX)
> > + goto nla_put_failure;
>
> bit ugly, let's add a variant of nla_nest_end() which can return
> an error on overflow (without the warning from patch 4) ?
I was tried to not touch nla_nest_end() as it is used everywhere. But it makes
sense to me to add a new function to check this. I'm not very good at naming,
maybe `nla_nest_end_validate()` ? Or any other name if you have?
Thanks
Hangbin
>
> > +
> > nla_nest_end(skb, strings_attr);
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] ipv4: igmp: encode multicast exponential fields
From: Ido Schimmel @ 2026-04-01 7:27 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260330191611.16929-4-royujjal@gmail.com>
On Mon, Mar 30, 2026 at 07:16:09PM +0000, Ujjal Roy wrote:
> In IGMP, QQIC and MRC fields are not currently encoded
s/currently/correctly/ ?
> when generating query packets. Since the receiver of the
> query interprets these fields using the IGMPv3 floating-
> point decoding logic, any raw interval value that exceeds
> the linear threshold is currently parsed incorrectly as
> an exponential value, leading to an incorrect interval
> calculation.
>
> Encode and assign the corresponding protocol fields during
> query generation. Introduce the logic to dynamically
> calculate the exponent and mantissa using bit-scan (fls).
> This ensures QQIC and MRC fields (8-bit) are properly
> encoded when transmitting query packets with intervals
> that exceed their respective linear threshold value of
> 128 (for QQI/MRT).
>
> RFC 3376: if QQIC/MRC >= 128, the QQIC/MRC field represents
> a floating-point value as follows:
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |1| exp | mant |
> +-+-+-+-+-+-+-+-+
>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
[...]
> +static inline u8 igmpv3_exp_field_encode(unsigned long value)
> +{
> + u8 mc_exp, mc_man;
> +
> + /* RFC3376: QQIC/MRC < 128 is literal */
> + if (value < IGMPV3_EXP_MIN_THRESHOLD)
> + return (u8)value;
return value;
> +
> + /* Saturate at max representable (mant = 0xF, exp = 7) -> 31744 */
> + if (value >= IGMPV3_EXP_MAX_THRESHOLD)
> + return 0xFF;
> +
> + mc_exp = (u8)(fls(value) - 8);
> + mc_man = (u8)((value >> (mc_exp + 3)) & 0x0F);
Drop the casts?
Same in other places throughout the patchset.
> +
> + return 0x80 | (mc_exp << 4) | mc_man;
> +}
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()
From: Ido Schimmel @ 2026-04-01 7:26 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260330191611.16929-3-royujjal@gmail.com>
On Mon, Mar 30, 2026 at 07:16:08PM +0000, Ujjal Roy wrote:
> Rename mldv2_mrc() to mldv2_mrd() as it used to calculate
s/as it used/as it is used/
> the Maximum Response Delay from the Maximum Response Code.
>
> Introduce a new API mldv2_qqi() to define the existing
> calculation logic of QQI from QQIC. This also organizes
> the existing mld_update_qi() API.
>
> Added by e3f5b1704 ("net: ipv6: mld: get rid of MLDV2_MRC and simplify calculation").
I don't see a point in mentioning this.
>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
> ---
> include/net/mld.h | 64 +++++++++++++++++++++++++++++++++------
> net/bridge/br_multicast.c | 2 +-
> net/ipv6/mcast.c | 19 ++----------
> 3 files changed, 58 insertions(+), 27 deletions(-)
This is mostly similar to the previous patch, so the same comments apply
here.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac support
From: Krzysztof Kozlowski @ 2026-04-01 7:25 UTC (permalink / raw)
To: Umang Chheda
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel, netdev
In-Reply-To: <20260401-monaco-evk-ac-sku-v2-1-27b5f702cfba@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 12:14:42AM +0530, Umang Chheda wrote:
> Introduce bindings for the monaco-evk-ac IoT board, which is
> based on the monaco-ac (QCS8300-AC) SoC variant.
>
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v2 1/5] ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation
From: Ido Schimmel @ 2026-04-01 7:25 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260330191611.16929-2-royujjal@gmail.com>
On Mon, Mar 30, 2026 at 07:16:07PM +0000, Ujjal Roy wrote:
> Get rid of the IGMPV3_MRC macro and use the igmpv3_mrt() API to
> calculate the Max Resp Time from the Maximum Response Code.
>
> Similarly, for IGMPV3_QQIC, use the igmpv3_qqi() API to calculate
> the Querier's Query Interval from the QQIC field.
>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
> ---
> include/linux/igmp.h | 78 +++++++++++++++++++++++++++++++++++----
> net/bridge/br_multicast.c | 2 +-
> net/ipv4/igmp.c | 6 +--
> 3 files changed, 74 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/igmp.h b/include/linux/igmp.h
> index 073b30a9b850..3c12c0a63492 100644
> --- a/include/linux/igmp.h
> +++ b/include/linux/igmp.h
> @@ -92,15 +92,77 @@ struct ip_mc_list {
> struct rcu_head rcu;
> };
>
> +/* RFC3376, relevant sections:
> + * - 4.1.1. Maximum Response Code
> + * - 4.1.7. QQIC (Querier's Query Interval Code)
> + *
> + * If Max Resp Code >= 128, Max Resp Code represents a floating-point
> + * value as follows:
> + * If QQIC >= 128, QQIC represents a floating-point value as follows:
You have "as follows:" twice. Reword it to make it clear that both
fields are encoded the same.
Please also mention that MRT is in units of 100ms (0.1 seconds) and that
QQIC is in units of seconds.
> + *
> + * 0 1 2 3 4 5 6 7
> + * +-+-+-+-+-+-+-+-+
> + * |1| exp | mant |
> + * +-+-+-+-+-+-+-+-+
> + */
> +#define IGMPV3_FP_EXP(value) (((value) >> 4) & 0x07)
> +#define IGMPV3_FP_MAN(value) ((value) & 0x0f)
> +
> +/* IGMPV3 floating-point exponential field threshold */
> +#define IGMPV3_EXP_MIN_THRESHOLD 128
> +
> /* V3 exponential field decoding */
> -#define IGMPV3_MASK(value, nb) ((nb)>=32 ? (value) : ((1<<(nb))-1) & (value))
> -#define IGMPV3_EXP(thresh, nbmant, nbexp, value) \
> - ((value) < (thresh) ? (value) : \
> - ((IGMPV3_MASK(value, nbmant) | (1<<(nbmant))) << \
> - (IGMPV3_MASK((value) >> (nbmant), nbexp) + (nbexp))))
> -
> -#define IGMPV3_QQIC(value) IGMPV3_EXP(0x80, 4, 3, value)
> -#define IGMPV3_MRC(value) IGMPV3_EXP(0x80, 4, 3, value)
> +
> +/*
> + * IGMPv3 QQI/MRT 8-bit exponential field decode.
> + *
> + * RFC3376, 4.1.1 & 4.1.7. defines the decoding formula:
> + * 0 1 2 3 4 5 6 7
> + * +-+-+-+-+-+-+-+-+
> + * |1| exp | mant |
> + * +-+-+-+-+-+-+-+-+
> + * Max Resp Time = (mant | 0x10) << (exp + 3)
> + * QQI = (mant | 0x10) << (exp + 3)
> + */
You are mixing two different styles of comments. Please use netdev style
comments like you have above:
/* IGMPv3 QQI/MRT 8-bit exponential field decode.
* [...]
*/
Same in other places throughout the patchset.
> +static inline unsigned long igmpv3_exp_field_decode(const u8 code)
> +{
> + /* RFC3376, relevant sections:
> + * - 4.1.1. Maximum Response Code
> + * - 4.1.7. QQIC (Querier's Query Interval Code)
> + */
> + if (code < IGMPV3_EXP_MIN_THRESHOLD) {
> + return (unsigned long)code;
return code;
> + } else {
> + unsigned long mc_man, mc_exp;
> +
> + mc_exp = IGMPV3_FP_EXP(code);
> + mc_man = IGMPV3_FP_MAN(code);
> +
> + return ((mc_man | 0x10) << (mc_exp + 3));
return (mc_man | 0x10) << (mc_exp + 3);
> + }
> +}
> +
> +/* Calculate Max Resp Time from Maximum Response Code */
> +static inline unsigned long igmpv3_mrt(const struct igmpv3_query *ih3)
> +{
> + /* RFC3376, relevant sections:
> + * - 4.1.1. Maximum Response Code
> + * - 8.3. Query Response Interval
> + */
> + return igmpv3_exp_field_decode(ih3->code);
> +}
> +
> +/* Calculate Querier's Query Interval from Querier's Query Interval Code */
> +static inline unsigned long igmpv3_qqi(const struct igmpv3_query *ih3)
> +{
> + /* RFC3376, relevant sections:
> + * - 4.1.7. QQIC (Querier's Query Interval Code)
> + * - 8.2. Query Interval
> + * - 8.12. Older Version Querier Present Timeout
> + * (the [Query Interval] in the last Query received)
> + */
> + return igmpv3_exp_field_decode(ih3->qqic);
> +}
>
> static inline int ip_mc_may_pull(struct sk_buff *skb, unsigned int len)
> {
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 881d866d687a..9fec76e887bc 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -3518,7 +3518,7 @@ static void br_ip4_multicast_query(struct net_bridge_mcast *brmctx,
> goto out;
>
> max_delay = ih3->code ?
> - IGMPV3_MRC(ih3->code) * (HZ / IGMP_TIMER_SCALE) : 1;
> + igmpv3_mrt(ih3) * (HZ / IGMP_TIMER_SCALE) : 1;
> } else {
> goto out;
> }
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index a674fb44ec25..8c6102737096 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -991,7 +991,7 @@ static bool igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
> * different encoding. We use the v3 encoding as more likely
> * to be intended in a v3 query.
> */
> - max_delay = IGMPV3_MRC(ih3->code)*(HZ/IGMP_TIMER_SCALE);
> + max_delay = igmpv3_mrt(ih3)*(HZ/IGMP_TIMER_SCALE);
Given you are modifying the line, adjust it to:
max_delay = igmpv3_mrt(ih3) * (HZ / IGMP_TIMER_SCALE);
Same in other places where you are already modifying a line.
> if (!max_delay)
> max_delay = 1; /* can't mod w/ 0 */
> } else { /* v3 */
> @@ -1006,7 +1006,7 @@ static bool igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
> ih3 = igmpv3_query_hdr(skb);
> }
>
> - max_delay = IGMPV3_MRC(ih3->code)*(HZ/IGMP_TIMER_SCALE);
> + max_delay = igmpv3_mrt(ih3)*(HZ/IGMP_TIMER_SCALE);
> if (!max_delay)
> max_delay = 1; /* can't mod w/ 0 */
> WRITE_ONCE(in_dev->mr_maxdelay, max_delay);
> @@ -1016,7 +1016,7 @@ static bool igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
> * configured value.
> */
> in_dev->mr_qrv = ih3->qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
> - in_dev->mr_qi = IGMPV3_QQIC(ih3->qqic)*HZ ?: IGMP_QUERY_INTERVAL;
> + in_dev->mr_qi = igmpv3_qqi(ih3)*HZ ?: IGMP_QUERY_INTERVAL;
>
> /* RFC3376, 8.3. Query Response Interval:
> * The number of seconds represented by the [Query Response
> --
> 2.43.0
>
^ permalink raw reply
* Re: [RESEND PATCH] ice: access @pp through netmem_desc instead of page
From: David Hildenbrand (Arm) @ 2026-04-01 7:24 UTC (permalink / raw)
To: Byungchul Park, netdev, kuba
Cc: linux-kernel, kernel_team, harry.yoo, willy, toke, asml.silence,
almasrymina, anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev,
davem, edumazet, pabeni, intel-wired-lan
In-Reply-To: <20260224053546.62757-1-byungchul@sk.com>
On 2/24/26 06:35, Byungchul Park wrote:
> To eliminate the use of struct page in page pool, the page pool users
> should use netmem descriptor and APIs instead.
>
> Make ice driver access @pp through netmem_desc instead of page.
>
> Signed-off-by: Byungchul Park <byungchul@sk.com>
> ---
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH net] ipvs: fix NULL deref in ip_vs_add_service error path
From: Weiming Shi @ 2026-04-01 7:23 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman, Pablo Neira Ayuso, Florian Westphal,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Phil Sutter, netdev, lvs-devel, netfilter-devel, coreteam,
Xiang Mei
In-Reply-To: <55c32c6e-8126-8a85-9ddb-1ecebedf2b67@ssi.bg>
On 26-04-01 09:38, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 1 Apr 2026, Weiming Shi wrote:
>
> > When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local
> > variable sched is set to NULL. If ip_vs_start_estimator() subsequently
> > fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)
> > with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL
> > check (because svc->scheduler was set by the successful bind) but then
> > dereferences the NULL sched parameter at sched->done_service, causing a
> > kernel panic at offset 0x30 from NULL.
> >
> > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
> > RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69)
> > Call Trace:
> > <TASK>
> > ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500)
> > do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809)
> > nf_setsockopt (net/netfilter/nf_sockopt.c:102)
> > ip_setsockopt (net/ipv4/ip_sockglue.c:1427)
> > raw_setsockopt (net/ipv4/raw.c:850)
> > do_sock_setsockopt (net/socket.c:2322)
> > __sys_setsockopt (net/socket.c:2339)
> > __x64_sys_setsockopt (net/socket.c:2350)
> > do_syscall_64 (arch/x86/entry/syscall_64.c:94)
> > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> > </TASK>
> >
> > Fix by recovering the scheduler pointer from svc->scheduler before
> > cleanup when the local sched variable has been cleared. This also
> > prevents a latent module refcount leak: without the recovery,
> > ip_vs_scheduler_put(sched) receives NULL and skips the module_put(),
> > so the scheduler module could never be unloaded if the kernel survived
> > past the dereference.
> >
> > Fixes: 05f00505a89a ("ipvs: fix crash if scheduler is changed")
> > Reported-by: Xiang Mei <xmei5@asu.edu>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> > ---
> > net/netfilter/ipvs/ip_vs_ctl.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> > index 35642de2a0fee..e0c978def9749 100644
> > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > @@ -1497,6 +1497,8 @@ ip_vs_add_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *u,
> > if (ret_hooks >= 0)
> > ip_vs_unregister_hooks(ipvs, u->af);
> > if (svc != NULL) {
> > + if (!sched)
> > + sched = rcu_dereference_protected(svc->scheduler, 1);
>
> Good catch. But may be it should be enough if
> we just remove the sched = NULL after successful
> ip_vs_bind_scheduler(), what do you think? ip_vs_unbind_scheduler()
> already detects if the scheduler is installed.
>
> > ip_vs_unbind_scheduler(svc, sched);
> > ip_vs_service_free(svc);
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
Hi Julian,
Thanks for the review. You're right, removing the sched = NULL is
simpler and sufficient
I'll send a v2 patch.
Best,
Weiming Shi
^ permalink raw reply
* [PATCH net-next v2 14/14] net: stmmac: move "TSO supported" message to stmmac_set_gso_features()
From: Russell King (Oracle) @ 2026-04-01 7:22 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: <aczHVF04LIGq_lYO@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 406c32142d90..3e01f968115d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4391,6 +4391,9 @@ static void stmmac_set_gso_features(struct net_device *ndev)
const struct stmmac_dma_cfg *dma_cfg;
int txpbl;
+ if (priv->dma_cap.tsoen)
+ dev_info(priv->device, "TSO supported\n");
+
if (!(priv->plat->flags & STMMAC_FLAG_TSO_EN))
return;
@@ -7469,9 +7472,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 v2 13/14] net: stmmac: check txpbl for TSO
From: Russell King (Oracle) @ 2026-04-01 7:22 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: <aczHVF04LIGq_lYO@shell.armlinux.org.uk>
Documentation states that TxPBL must be >= 4 to allow TSO support, but
the driver doesn't check this. TxPBL comes from the platform glue code
or DT. Add a check with a warning if platform glue code attempts to
enable TSO support with TxPBL too low.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5286ad6412a3..406c32142d90 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4388,6 +4388,8 @@ 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);
+ const struct stmmac_dma_cfg *dma_cfg;
+ int txpbl;
if (!(priv->plat->flags & STMMAC_FLAG_TSO_EN))
return;
@@ -4397,6 +4399,18 @@ static void stmmac_set_gso_features(struct net_device *ndev)
return;
}
+ /* FIXME:
+ * STM32MP151 (v4.2 userver v4.0) states that TxPBL must be >= 4. It
+ * is not clear whether PBLx8 (which multiplies the PBL value by 8)
+ * influences this.
+ */
+ dma_cfg = priv->plat->dma_cfg;
+ txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
+ if (txpbl < 4) {
+ dev_warn(priv->device, "txpbl(%d) is too low for TSO\n", txpbl);
+ 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;
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 12/14] net: stmmac: add warning when TSO is requested but unsupported
From: Russell King (Oracle) @ 2026-04-01 7:22 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: <aczHVF04LIGq_lYO@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 7134f6c6075b..5286ad6412a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4392,8 +4392,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 v2 11/14] net: stmmac: make stmmac_set_gso_features() more readable
From: Russell King (Oracle) @ 2026-04-01 7:22 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: <aczHVF04LIGq_lYO@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 e868fb0c9894..7134f6c6075b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4389,13 +4389,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");
}
static size_t stmmac_tso_header_size(struct sk_buff *skb)
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 10/14] net: stmmac: split out gso features setup
From: Russell King (Oracle) @ 2026-04-01 7:22 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: <aczHVF04LIGq_lYO@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 42e2196e82a4..e868fb0c9894 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4385,6 +4385,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");
+ }
+}
+
static size_t stmmac_tso_header_size(struct sk_buff *skb)
{
size_t size;
@@ -7888,13 +7901,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 v2 09/14] net: stmmac: simplify GSO/TSO test in stmmac_xmit()
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@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 d3cbe71b9af1..42e2196e82a4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4373,6 +4373,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;
+ }
+}
+
static size_t stmmac_tso_header_size(struct sk_buff *skb)
{
size_t size;
@@ -4706,7 +4718,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;
@@ -4718,14 +4729,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]) {
@@ -6151,7 +6157,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;
@@ -7886,7 +7892,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
* Re: [PATCH net-next 1/4] tools: ynl: ethtool: use doit instead of dumpit for per-device GET
From: Hangbin Liu @ 2026-04-01 7:21 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260331185028.45dffe3a@kernel.org>
On Tue, Mar 31, 2026 at 06:50:28PM -0700, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 11:56:11 +0800 Hangbin Liu wrote:
> > +++ b/tools/net/ynl/pyynl/ethtool.py
>
> We have converted all the samples to selftests so this script is
> the last piece of random "PoC" code we still have laying around.
> Should we also move it to tests/ ?
>
> If there's a reason to keep it as is -- could you please add that reason
> at the top of the file for my future self? I'm pretty sure I already
> questioned this script in the past ;)
I have no objection to this. Will you keep it as it is when moving it to
tests/ ? Should I wait for your moving first?
Hangbin
^ permalink raw reply
* [PATCH net-next v2 08/14] net: stmmac: move check for hardware checksum supported
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@shell.armlinux.org.uk>
Add a check in .ndo_features_check() to indicate whether hardware
checksum can be performed on the skbuff. Where hardware checksum is
not supported - either because the channel does not support Tx COE
or the skb isn't suitable (stmmac uses a tighter test than
can_checksum_protocol()) we also need to disable TSO, which will be
done by harmonize_features() in net/core/dev.c
This fixes a bug where a channel which has COE disabled may still
receive TSO skbuffs.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 38 +++++++++----------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c67f042a90af..d3cbe71b9af1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4757,22 +4757,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
/* Check if VLAN can be inserted by HW */
has_vlan = stmmac_vlan_insert(priv, skb, tx_q);
- csum_insertion = (skb->ip_summed == CHECKSUM_PARTIAL);
- /* DWMAC IPs can be synthesized to support tx coe only for a few tx
- * queues. In that case, checksum offloading for those queues that don't
- * support tx coe needs to fallback to software checksum calculation.
- *
- * Packets that won't trigger the COE e.g. most DSA-tagged packets will
- * also have to be checksummed in software.
- */
- if (csum_insertion &&
- (priv->plat->tx_queues_cfg[queue].coe_unsupported ||
- !stmmac_has_ip_ethertype(skb))) {
- if (unlikely(skb_checksum_help(skb)))
- goto dma_map_err;
- csum_insertion = !csum_insertion;
- }
-
entry = tx_q->cur_tx;
first_entry = entry;
WARN_ON(tx_q->tx_skbuff[first_entry]);
@@ -4788,6 +4772,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
if (enh_desc)
is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc);
+ csum_insertion = skb->ip_summed == CHECKSUM_PARTIAL;
+
if (unlikely(is_jumbo)) {
entry = stmmac_jumbo_frm(priv, tx_q, skb, csum_insertion);
if (unlikely(entry < 0) && (entry != -EINVAL))
@@ -4949,11 +4935,25 @@ static netdev_features_t stmmac_features_check(struct sk_buff *skb,
struct net_device *dev,
netdev_features_t features)
{
- u16 queue;
+ struct stmmac_priv *priv = netdev_priv(dev);
+ u16 queue = skb_get_queue_mapping(skb);
+
+ /* DWMAC IPs can be synthesized to support tx coe only for a few tx
+ * queues. In that case, checksum offloading for those queues that don't
+ * support tx coe needs to fallback to software checksum calculation.
+ *
+ * Packets that won't trigger the COE e.g. most DSA-tagged packets will
+ * also have to be checksummed in software.
+ *
+ * Note that disabling hardware checksumming also disables TSO. See
+ * harmonize_features() in net/core/dev.c
+ */
+ if (priv->plat->tx_queues_cfg[queue].coe_unsupported ||
+ !stmmac_has_ip_ethertype(skb))
+ features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
if (skb_is_gso(skb)) {
- queue = skb_get_queue_mapping(skb);
- if (!stmmac_tso_channel_permitted(netdev_priv(dev), queue) ||
+ if (!stmmac_tso_channel_permitted(priv, queue) ||
!stmmac_tso_valid_packet(skb))
features &= ~NETIF_F_GSO_MASK;
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 07/14] net: stmmac: move TSO VLAN tag insertion to core code
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@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 | 23 ++++++++-----------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b4cc34dd0d76..c67f042a90af 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4456,19 +4456,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);
@@ -4969,6 +4956,16 @@ static netdev_features_t stmmac_features_check(struct sk_buff *skb,
if (!stmmac_tso_channel_permitted(netdev_priv(dev), queue) ||
!stmmac_tso_valid_packet(skb))
features &= ~NETIF_F_GSO_MASK;
+
+ /* If we are going to be using hardware TSO, 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 (features & NETIF_F_GSO_MASK)
+ features &= ~(NETIF_F_HW_VLAN_STAG_TX |
+ NETIF_F_HW_VLAN_CTAG_TX);
}
return vlan_features_check(skb, features);
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 06/14] net: stmmac: add GSO MSS checks
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@shell.armlinux.org.uk>
Add GSO MSS checks to stmmac_features_check().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 031ffb78f40d..b4cc34dd0d76 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4391,12 +4391,19 @@ static size_t stmmac_tso_header_size(struct sk_buff *skb)
*
* While IPv4 is limited to MAC+VLAN+IPv4+ext+TCP+ext = 138 bytes, the IPv6
* extension headers aren't similarly limited.
+ *
+ * Fall back to software GSO for these skbs. Also check that the MSS is >=
+ * the recommended 64 bytes (documented in ETH_DMACxCR register description),
+ * and that a the header plus MSS is not larger than 16383 (documented in
+ * "Building the Descriptor and the packet for the TSO feature").
*/
static bool stmmac_tso_valid_packet(struct sk_buff *skb)
{
size_t header_len = stmmac_tso_header_size(skb);
+ unsigned int gso_size = skb_shinfo(skb)->gso_size;
- return header_len <= 1023;
+ return header_len <= 1023 && gso_size >= 64 &&
+ header_len + gso_size < 16383;
}
/**
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 05/14] net: stmmac: add TSO check for header length
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@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>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2b5bccc727a5..031ffb78f40d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4385,6 +4385,20 @@ static size_t stmmac_tso_header_size(struct sk_buff *skb)
return size;
}
+/* 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.
+ *
+ * While IPv4 is limited to MAC+VLAN+IPv4+ext+TCP+ext = 138 bytes, the IPv6
+ * extension headers aren't similarly limited.
+ */
+static bool stmmac_tso_valid_packet(struct sk_buff *skb)
+{
+ size_t header_len = stmmac_tso_header_size(skb);
+
+ return header_len <= 1023;
+}
+
/**
* stmmac_tso_xmit - Tx entry point of the driver for oversized frames (TSO)
* @skb : the socket buffer
@@ -4945,7 +4959,8 @@ static netdev_features_t stmmac_features_check(struct sk_buff *skb,
if (skb_is_gso(skb)) {
queue = skb_get_queue_mapping(skb);
- if (!stmmac_tso_channel_permitted(netdev_priv(dev), queue))
+ if (!stmmac_tso_channel_permitted(netdev_priv(dev), queue) ||
+ !stmmac_tso_valid_packet(skb))
features &= ~NETIF_F_GSO_MASK;
}
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 04/14] net: stmmac: add stmmac_tso_header_size()
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@shell.armlinux.org.uk>
We will need to compute the size of the protocol headers in two places,
so move this into a separate function.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 890a1efb8733..2b5bccc727a5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4373,6 +4373,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 size_t stmmac_tso_header_size(struct sk_buff *skb)
+{
+ size_t size;
+
+ if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
+ size = skb_transport_offset(skb) + sizeof(struct udphdr);
+ else
+ size = skb_tcp_all_headers(skb);
+
+ return size;
+}
+
/**
* stmmac_tso_xmit - Tx entry point of the driver for oversized frames (TSO)
* @skb : the socket buffer
@@ -4444,13 +4456,11 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
first_tx = tx_q->cur_tx;
/* Compute header lengths */
- if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4) {
- proto_hdr_len = skb_transport_offset(skb) + sizeof(struct udphdr);
+ proto_hdr_len = stmmac_tso_header_size(skb);
+ if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
hdr = sizeof(struct udphdr);
- } else {
- proto_hdr_len = skb_tcp_all_headers(skb);
+ else
hdr = tcp_hdrlen(skb);
- }
/* Desc availability based on threshold should be enough safe */
if (unlikely(stmmac_tx_avail(priv, queue) <
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 03/14] net: stmmac: fix TSO support when some channels have TBS available
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@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 | 32 ++++++++++++++++---
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c80b4a375ddb..890a1efb8733 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3619,6 +3619,17 @@ static void stmmac_safety_feat_configuration(struct stmmac_priv *priv)
}
}
+/* 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.
+ */
+static bool stmmac_tso_channel_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 +3718,7 @@ static int stmmac_hw_setup(struct net_device *dev)
/* Enable TSO */
if (priv->dma_cap.tsoen && priv->plat->flags & STMMAC_FLAG_TSO_EN) {
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_tso_channel_permitted(priv, chan))
continue;
stmmac_enable_tso(priv, priv->ioaddr, 1, chan);
@@ -4919,6 +4927,21 @@ 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;
+
+ if (skb_is_gso(skb)) {
+ queue = skb_get_queue_mapping(skb);
+ if (!stmmac_tso_channel_permitted(netdev_priv(dev), queue))
+ features &= ~NETIF_F_GSO_MASK;
+ }
+
+ return vlan_features_check(skb, features);
+}
+
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
struct vlan_ethhdr *veth = skb_vlan_eth_hdr(skb);
@@ -7214,6 +7237,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 v2 02/14] net: stmmac: fix .ndo_fix_features()
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@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 cd76f62e1b6e..c80b4a375ddb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6073,14 +6073,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;
}
@@ -6107,6 +6099,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 v2 01/14] net: stmmac: fix channel TSO enable on resume
From: Russell King (Oracle) @ 2026-04-01 7:21 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: <aczHVF04LIGq_lYO@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 the channel TSO enable bit being disabled after a resume
when the user has disabled TSO features. This will cause problems when
the user re-enables TSO.
This bug goes back to commit f748be531d70 ("stmmac: support new GMAC4")
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 ce51b9c22129..cd76f62e1b6e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3705,7 +3705,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++) {
struct stmmac_tx_queue *tx_q = &priv->dma_conf.tx_queue[chan];
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups
From: Russell King (Oracle) @ 2026-04-01 7:20 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
This is a more refined version of the previous patch series fixing
and cleaning up the TSO code.
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.
While IPv4 headers are unlikely to be anywhere near this, there is
nothing in the protocol which prevents IPv6 headers up to 64KiB.
As we now have a .ndo_features_check() method, I'm moving the VLAN
insertion for TSO packets into core code by unpublishing the VLAN
insertion features when we use TSO. Another move is for checksumming,
which is required for TSO, but stmmac's requirements for offloading
checksums are more strict - and this seems to be a bug in the TSO
path.
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.
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 adding a check for TxPBL
value.
Finally, moving 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 | 214 +++++++++++++++-------
2 files changed, 150 insertions(+), 67 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 net-next v1 2/4] r8169: add sfp mode for RTL8116af
From: Heiner Kallweit @ 2026-04-01 7:20 UTC (permalink / raw)
To: Javen, nic_swsd@realtek.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <d4357d7d824f4558842fb1997dff7867@realsil.com.cn>
On 01.04.2026 03:43, Javen wrote:
>> On 17.03.2026 04:14, Javen wrote:
>>>> On 13.03.2026 08:25, Javen wrote:
>>>>>> On 02.03.2026 07:32, javen wrote:
>>>>>>> From: Javen Xu <javen_xu@realsil.com.cn>
>>>>>>>
>>>>>>> RTL8116af is a variation of RTL8168fp. It uses SerDes instead of PHY.
>>>>>>> But SerDes status will not relect to PHY. So it needs to add sfp
>>>>>>> mode for quirk to help reflect SerDes status during PHY read.
>>>>>>>
>>>>>>
>>>>>> Is there any mass market device using this chip version? As far as
>>>>>> possible I'd like to avoid adding support for chip versions that
>>>>>> never make it to the mass market. This just makes driver
>>>>>> maintenance
>>>> harder.
>>>>>>
>>>>>> The patch includes support for 100Mbps fiber mode. Is there any use
>>>>>> case for such legacy modes?
>>>>>>
>>>>>>
>>>>>>> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
>>>>>>> ---
>>>>>>> drivers/net/ethernet/realtek/r8169_main.c | 71
>>>>>>> ++++++++++++++++++++---
>>>>>>> 1 file changed, 62 insertions(+), 9 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> index fb2247a20c36..a5c0d3995328 100644
>>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>>>>> @@ -726,6 +726,12 @@ enum rtl_dash_type {
>>>>>>> RTL_DASH_25_BP,
>>>>>>> };
>>>>>>>
>>>>>>> +enum rtl_sfp_mode {
>>>>>>> + RTL_SFP_NONE,
>>>>>>> + RTL_SFP_8168_AF,
>>>>>>> + RTL_SFP_8127_ATF,
>>>>>>> +};
>>>>>>> +
>>>>>>> struct rtl8169_private {
>>>>>>> void __iomem *mmio_addr; /* memory map physical address
>> */
>>>>>>> struct pci_dev *pci_dev;
>>>>>>> @@ -734,6 +740,7 @@ struct rtl8169_private {
>>>>>>> struct napi_struct napi;
>>>>>>> enum mac_version mac_version;
>>>>>>> enum rtl_dash_type dash_type;
>>>>>>> + enum rtl_sfp_mode sfp_mode;
>>>>>>> u32 cur_rx; /* Index into the Rx descriptor buffer of next Rx pkt. */
>>>>>>> u32 cur_tx; /* Index into the Tx descriptor buffer of next Rx pkt. */
>>>>>>> u32 dirty_tx;
>>>>>>> @@ -760,7 +767,6 @@ struct rtl8169_private {
>>>>>>> unsigned supports_gmii:1;
>>>>>>> unsigned aspm_manageable:1;
>>>>>>> unsigned dash_enabled:1;
>>>>>>> - bool sfp_mode:1;
>>>>>>> dma_addr_t counters_phys_addr;
>>>>>>> struct rtl8169_counters *counters;
>>>>>>> struct rtl8169_tc_offsets tc_offset; @@ -1126,7 +1132,7 @@
>>>>>>> static int r8168_phy_ocp_read(struct rtl8169_private *tp, u32 reg)
>>>>>>> return 0;
>>>>>>>
>>>>>>> /* Return dummy MII_PHYSID2 in SFP mode to match SFP PHY
>>>>>>> driver
>>>> */
>>>>>>> - if (tp->sfp_mode && reg == (OCP_STD_PHY_BASE + 2 *
>> MII_PHYSID2))
>>>>>>> + if (tp->sfp_mode == RTL_SFP_8127_ATF && reg ==
>>>>>> (OCP_STD_PHY_BASE
>>>>>>> + + 2 * MII_PHYSID2))
>>>>>>> return PHY_ID_RTL_DUMMY_SFP & 0xffff;
>>>>>>>
>>>>>>> RTL_W32(tp, GPHY_OCP, reg << 15); @@ -1270,6 +1276,34 @@
>>>>>>> static int r8168g_mdio_read(struct rtl8169_private *tp, int reg)
>>>>>>> return r8168_phy_ocp_read(tp, tp->ocp_base + reg * 2); }
>>>>>>>
>>>>>>> +/* The quirk reflects RTL8116af SerDes status. */ static int
>>>>>>> +r8116af_mdio_read_quirk(struct rtl8169_private *tp, int reg) {
>>>>>>> + u8 phyStatus = RTL_R8(tp, PHYstatus);
>>>>>>> +
>>>>>>> + if (!(phyStatus & LinkStatus))
>>>>>>> + return 0;
>>>>>>> +
>>>>>>> + /* BMSR */
>>>>>>> + if (tp->ocp_base == OCP_STD_PHY_BASE && reg == MII_BMSR)
>>>>>>> + return BMSR_ANEGCOMPLETE | BMSR_LSTATUS;
>>>>>>> +
>>>>>>> + /* PHYSR */
>>>>>>> + if (tp->ocp_base == 0xa430 && reg == 0x12) {
>>>>>>> + if (phyStatus & _1000bpsF)
>>>>>>> + return 0x0028;
>>>>>>> + else if (phyStatus & _100bps)
>>>>>>> + return 0x0018;
>>>>>>
>>>>>> This is a complete hack. Any means to access the SerDes directly?
>>>>>
>>>>> Hi, Heiner
>>>>> Now we find a indirect access to serdes reg. The serdes reg is
>>>>> designed
>>>> according to IEEE 802.3.
>>>>> BIT 2 means Link Status and BIT 5 means ANEGCOMPLETE. We can access
>>>>> it through read mac ocp 0xeb14, I wonder whether this indirect
>>>>> access can be
>>>> accepted?
>>>>>
>>>> Based on the bit numbers this seems to be the BMSR register. Can all
>>>> clause
>>>> 22 registers be accessed in a similar way so that a MII bus can be
>>>> implemented for accessing the SerDes?
>>>
>>> We checked our chip documentation and confirmed that the SerDes
>>> register file maps all clause 22 registers(e.g. WR 0xeb10<reg_addr>,
>>> RD 0xeb14. reg_addr 0x40 is for BMCR,
>>> 0x41 for BMSR, 0x42 for PHYSID1, 0x43 for PHYSID2, etc.) As you
>>> suggested, I wonder whether the proper approach is to implement a
>>> virtual mii_bus and map the standard serdes reg in the new map.
>>>
>> We'd need to know how the internal PHY and the SerDes play together.
>> Whether the usual internal PHY plays any role in communication between
>> MAC and SerDes.
>> How interface modes are controlled on MAC and SerDes side, etc.
>> If Realtek doesn't implement proper layering in hw, and doesn't have enough
>> knowledge about mainline network driver structures, and on the other hand
>> doesn't want to provide chip documentation, then the situation somewhat
>> deadlocks.
>>
>
> Hi, Heiner
> For RTL8116af, the datapath is structured as MAC->PCS->SerDes.
> However, PCS block does not have a standard MDIO interface. Instead, we have to
> access the standard reg via MAC OCP.These standard registers are exactly the standard
> IEEE 802.3 Clause 22 PHY registers.
> Given hardware information above, I would like to ask for your advice on the recommended
> approach to support RTL8116af. Or any other information do I need to provide?
>
The described scenario MAC->PCS->SerDes is a standard scenario supported
by phylink, see e.g. phylink_pcs_ops and the drivers under drivers/net/pcs.
So you best get familiar with phylink, and start thinking about what it
would take to drive your IP blocks using phylink.
And still: Proper advice needs documentation as input. So if Realtek asks
for advice, they should also be willing to share datasheets etc.
> Thanks,
> Javen Xu
>
>>>> In general it's hard to provide a statement w/o knowing the internal
>>>> layout of the IP blocks.
>>>> Can you provide any chip documentation / datasheet?
>>>> For proper support of such a component chain between MAC and SFP port
>>>> the driver would have to be converted to use phylink, what requires
>>>> access to the involved components, incl. the SFP I2C bus.
>>>>
>>>>
>>>>> Thanks,
>>>>> Javen Xu
>>>>>
>>>>>>
>>>>>>> + }
>>>>>>> +
>>>>>>> + return 0;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static int r8116af_mdio_read(struct rtl8169_private *tp, int reg) {
>>>>>>> + return r8168g_mdio_read(tp, reg) |
>>>>>>> +r8116af_mdio_read_quirk(tp, reg); }
>>>>>>> +
>>>>>>> static void mac_mcu_write(struct rtl8169_private *tp, int reg,
>>>>>>> int
>>>>>>> value) {
>>>>>>> if (reg == 0x1f) {
>>>>>>> @@ -1280,6 +1314,13 @@ static void mac_mcu_write(struct
>>>>>>> rtl8169_private
>>>>>> *tp, int reg, int value)
>>>>>>> r8168_mac_ocp_write(tp, tp->ocp_base + reg, value); }
>>>>>>>
>>>>>>> +static bool rtl_is_8116af(struct rtl8169_private *tp) {
>>>>>>> + return tp->mac_version == RTL_GIGA_MAC_VER_52 &&
>>>>>>> + (r8168_mac_ocp_read(tp, 0xdc00) & 0x0078) == 0x0030 &&
>>>>>>> + (r8168_mac_ocp_read(tp, 0xd006) & 0x00ff) == 0x0000;
>>>>>>> +}
>>>>>>> +
>>>>>>> static int mac_mcu_read(struct rtl8169_private *tp, int reg) {
>>>>>>> return r8168_mac_ocp_read(tp, tp->ocp_base + reg); @@
>>>>>>> -1386,7
>>>>>>> +1427,10 @@ static int rtl_readphy(struct rtl8169_private *tp, int
>>>>>>> +location)
>>>>>>> case RTL_GIGA_MAC_VER_31:
>>>>>>> return r8168dp_2_mdio_read(tp, location);
>>>>>>> case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_LAST:
>>>>>>> - return r8168g_mdio_read(tp, location);
>>>>>>> + if (tp->sfp_mode == RTL_SFP_8168_AF)
>>>>>>> + return r8116af_mdio_read(tp, location);
>>>>>>> + else
>>>>>>> + return r8168g_mdio_read(tp, location);
>>>>>>> default:
>>>>>>> return r8169_mdio_read(tp, location);
>>>>>>> }
>>>>>>> @@ -1575,6 +1619,20 @@ static bool rtl_dash_is_enabled(struct
>>>>>> rtl8169_private *tp)
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> +static enum rtl_sfp_mode rtl_get_sfp_mode(struct rtl8169_private
>>>>>>> +*tp) {
>>>>>>> + if (rtl_is_8125(tp)) {
>>>>>>> + u16 data = r8168_mac_ocp_read(tp, 0xd006);
>>>>>>> +
>>>>>>> + if ((data & 0xff) == 0x07)
>>>>>>> + return RTL_SFP_8127_ATF;
>>>>>>> + } else if (rtl_is_8116af(tp)) {
>>>>>>> + return RTL_SFP_8168_AF;
>>>>>>> + }
>>>>>>> +
>>>>>>> + return RTL_SFP_NONE;
>>>>>>> +}
>>>>>>> +
>>>>>>> static enum rtl_dash_type rtl_get_dash_type(struct
>>>>>>> rtl8169_private
>>>>>>> *tp) {
>>>>>>> switch (tp->mac_version) {
>>>>>>> @@ -5693,12 +5751,7 @@ static int rtl_init_one(struct pci_dev
>>>>>>> *pdev, const
>>>>>> struct pci_device_id *ent)
>>>>>>> }
>>>>>>> tp->aspm_manageable = !rc;
>>>>>>>
>>>>>>> - if (rtl_is_8125(tp)) {
>>>>>>> - u16 data = r8168_mac_ocp_read(tp, 0xd006);
>>>>>>> -
>>>>>>> - if ((data & 0xff) == 0x07)
>>>>>>> - tp->sfp_mode = true;
>>>>>>> - }
>>>>>>> + tp->sfp_mode = rtl_get_sfp_mode(tp);
>>>>>>>
>>>>>>> tp->dash_type = rtl_get_dash_type(tp);
>>>>>>> tp->dash_enabled = rtl_dash_is_enabled(tp);
>>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Fernando Fernandez Mancera @ 2026-04-01 7:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, horms, pabeni, edumazet, davem, dsahern, Yiming Qian
In-Reply-To: <20260331154154.317437c4@kernel.org>
On 4/1/26 12:41 AM, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 19:40:38 +0200 Fernando Fernandez Mancera wrote:
>> thanks for sharing. As I replied to Eric this is the main reason why a
>> V2 is needed. There is also another bug I discovered while fixing this.
>> When dumping the stats NHA_HW_STATS_ENABLE is being included twice per
>> group. I am fixing that in another patch that will be included on the V2
>> series.
>
> If you remember -- please try to slap a pw-bot: cr on your own reply
> when you notice that a follow up is needed, especially if the patch
> is breaking selftests. We still lack automation to attribute failures
> and bad changes get stuck in the testing branch :(
Oh sure. Will do next time. Thanks Jakub!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox