* Re: [PATCH 1/2] net: qrtr: ns: Limit the maximum server registration per node
From: Simon Horman @ 2026-03-27 9:58 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: davem, edumazet, kuba, pabeni, linux-arm-msm, netdev,
linux-kernel, andersson, yimingqian591, chris.lew, mani, stable
In-Reply-To: <20260325104415.104972-2-manivannan.sadhasivam@oss.qualcomm.com>
On Wed, Mar 25, 2026 at 04:14:14PM +0530, Manivannan Sadhasivam wrote:
> Current code does no bound checking on the number of servers added per
> node. A malicious client can flood NEW_SERVER messages and exhaust memory.
>
> Fix this issue by limiting the maximum number of server registrations to
> 256 per node. If the NEW_SERVER message is received for an old port, then
> don't restrict it as it will get replaced.
>
> Note that the limit of 256 is chosen based on the current platform
> requirements. If requirement changes in the future, this limit can be
> increased.
>
> Cc: stable@vger.kernel.org
> Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> net/qrtr/ns.c | 24 ++++++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
> index 3203b2220860..fb4e8a2d370d 100644
> --- a/net/qrtr/ns.c
> +++ b/net/qrtr/ns.c
> @@ -67,8 +67,14 @@ struct qrtr_server {
> struct qrtr_node {
> unsigned int id;
> struct xarray servers;
> + u32 server_count;
> };
>
> +/* Max server limit is chosen based on the current platform requirements. If the
> + * requirement changes in the future, this value can be increased.
> + */
> +#define QRTR_NS_MAX_SERVERS 256
> +
> static struct qrtr_node *node_get(unsigned int node_id)
> {
> struct qrtr_node *node;
> @@ -229,6 +235,17 @@ static struct qrtr_server *server_add(unsigned int service,
> if (!service || !port)
> return NULL;
>
> + node = node_get(node_id);
> + if (!node)
> + return NULL;
This is not new behaviour added by patch, but If I understand things
correctly, node_get will allocate a new node if one doesn't already exist
for the node_id.
I am wondering if any bounds are placed on the number of nodes that can be
created. And, if not, is this a point of concern from a memory exhaustion
perspective?
...
^ permalink raw reply
* [PATCH net] ipv6: prevent possible UaF in addrconf_permanent_addr()
From: Paolo Abeni @ 2026-03-27 9:52 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Simon Horman
The mentioned helper try to warn the user about an exceptional
condition, but the message is delivered too late, accessing the ipv6
after its possible deletion.
Reorder the statement to avoid the possible UaF; while at it, place the
warning outside the idev->lock as it needs no protection.
Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://sashiko.dev/#/patchset/8c8bfe2e1a324e501f0e15fef404a77443fd8caf.1774365668.git.pabeni%40redhat.com
Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv6/addrconf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f4e23b543585..dd0b4d80e0f8 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3625,12 +3625,12 @@ static void addrconf_permanent_addr(struct net *net, struct net_device *dev)
if ((ifp->flags & IFA_F_PERMANENT) &&
fixup_permanent_addr(net, idev, ifp) < 0) {
write_unlock_bh(&idev->lock);
- in6_ifa_hold(ifp);
- ipv6_del_addr(ifp);
- write_lock_bh(&idev->lock);
net_info_ratelimited("%s: Failed to add prefix route for address %pI6c; dropping\n",
idev->dev->name, &ifp->addr);
+ in6_ifa_hold(ifp);
+ ipv6_del_addr(ifp);
+ write_lock_bh(&idev->lock);
}
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH next] netfilter: nf_conntrack_h323: Correct indentation when H323_TRACE defined
From: David Laight @ 2026-03-27 9:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
netfilter-devel, coreteam, netdev, linux-kernel, Masami Hiramatsu,
Petr Mladek, Rasmus Villemoes, Steven Rostedt, Sergey Senozhatsky,
Andrew Morton
In-Reply-To: <acZM4qwEtWqANece@ashevche-desk.local>
On Fri, 27 Mar 2026 11:24:50 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Thu, Mar 26, 2026 at 10:18:09PM +0000, David Laight wrote:
> > On Thu, 26 Mar 2026 21:24:39 +0100
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > On Thu, Mar 26, 2026 at 08:18:19PM +0000, david.laight.linux@gmail.com wrote:
> > > >
> > > > The trace lines are indented using PRINT("%*.s", xx, " ").
> > > > Userspace will treat this as "%*.0s" and will output no characters
> > > > when 'xx' is zero, the kernel treats it as "%*s" and will output
> > > > a single ' ' - which is probably what is intended.
> > > >
> > > > Change all the formats to "%*s" removing the default precision.
> > > > This gives a single space indent when level is zero.
> > >
> > > Do you have a setup using this helper? Or you just found this via
> > > visual inspection?
> >
> > Found with grep looking for places which might be affected by 'fixing'
> > the kernel printf code to be POSIX compliant.
>
> Do we have the respective test case in printf_kunit?
>
There are definitely related ones and this comment:
static void
test_string(struct kunit *kunittest)
{
[...]
/*
* POSIX and C99 say that a negative precision (which is only
* possible to pass via a * argument) should be treated as if
* the precision wasn't present, and that if the precision is
* omitted (as in %.s), the precision should be taken to be
* 0. However, the kernel's printf behave exactly opposite,
* treating a negative precision as 0 and treating an omitted
* precision specifier as if no precision was given.
*
* These test cases document the current behaviour; should
* anyone ever feel the need to follow the standards more
* closely, this can be revisited.
*/
test(" ", "%4.*s", -5, "123456");
[...]
}
I suspect whoever wrote the tests found the code was non-conformant.
But there isn't a comment in the snprintf() code itself.
I've not checked what the kernel code does (I've just written/fixed all
this for nolibc - the kernel will fail the nolibc tests).
David
^ permalink raw reply
* Re: [PATCH net-next 0/5] veth: add Byte Queue Limits (BQL) support
From: Toke Høiland-Jørgensen @ 2026-03-27 9:50 UTC (permalink / raw)
To: hawk, netdev
Cc: hawk, andrew+netdev, davem, edumazet, kuba, pabeni, horms, jhs,
jiri, j.koeppeler, kernel-team, Chris Arges, Mike Freemon
In-Reply-To: <20260324174719.1224337-1-hawk@kernel.org>
hawk@kernel.org writes:
> From: Jesper Dangaard Brouer <hawk@kernel.org>
>
> This series adds BQL (Byte Queue Limits) to the veth driver, reducing
> latency by dynamically limiting in-flight bytes in the ptr_ring and
> moving buffering into the qdisc where AQM algorithms can act on it.
>
> Problem:
> veth's 256-entry ptr_ring acts as a "dark buffer" -- packets queued
> there are invisible to the qdisc's AQM. Under load, the ring fills
> completely (DRV_XOFF backpressure), adding up to 256 packets of
> unmanaged latency before the qdisc even sees congestion.
>
> Solution:
> BQL (STACK_XOFF) dynamically limits in-flight bytes, stopping the
> queue before the ring fills. This keeps the ring shallow and pushes
> excess packets into the qdisc, where sojourn-based AQM can measure
> and drop them.
So one question here: Is *Byte* queue limits really the right thing for
veth? As you mention above, the ptr_ring is sized in a number of
packets. On a physical NIC, accounting bytes makes sense because there's
a fixed line rate, so bytes turn directly into latency.
But on a veth device, the stack processing is per packet, and most
processing takes the same amount of time regardless of the size of the
packet (e.g., netfilter rules that operate on the skb only).
So my worry would be that when you're accounting in bytes, if there's a
mix of big and small packets, you'd end up with the BQL algorithm
scaling to a "too large" value, which would allow a lot of small packets
to be queued up, adding extra latency (or even overflowing the ring
buffer if the ratio is large enough).
Have you run any such experiments? And have you tried just accounting
the queue in packets, so instead of:
+ netdev_tx_sent_queue(txq, skb->len);
you'd just do:
+ netdev_tx_sent_queue(txq, 1);
?
-Toke
^ permalink raw reply
* [PATCH net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
From: Lorenzo Bianconi @ 2026-03-27 9:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In order to properly cleanup hw rx QDMA queues and bring the device to
the initial state, reset rx DMA queue head/tail index. Moreover, reset
queued DMA descriptor fields.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Tested-by: Madhur Agrawal <Madhur.Agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 56cf9a926a83da38bb03373ced9728f1fecdbce7..c2a54dbcbb0d576da298f2a36a354afaef89b240 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -794,18 +794,34 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
static void airoha_qdma_cleanup_rx_queue(struct airoha_queue *q)
{
- struct airoha_eth *eth = q->qdma->eth;
+ struct airoha_qdma *qdma = q->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int qid = q - &qdma->q_rx[0];
while (q->queued) {
struct airoha_queue_entry *e = &q->entry[q->tail];
+ struct airoha_qdma_desc *desc = &q->desc[q->tail];
struct page *page = virt_to_head_page(e->buf);
dma_sync_single_for_cpu(eth->dev, e->dma_addr, e->dma_len,
page_pool_get_dma_dir(q->page_pool));
page_pool_put_full_page(q->page_pool, page, false);
+ /* Reset DMA descriptor */
+ WRITE_ONCE(desc->ctrl, 0);
+ WRITE_ONCE(desc->addr, 0);
+ WRITE_ONCE(desc->data, 0);
+ WRITE_ONCE(desc->msg0, 0);
+ WRITE_ONCE(desc->msg1, 0);
+ WRITE_ONCE(desc->msg2, 0);
+ WRITE_ONCE(desc->msg3, 0);
+
q->tail = (q->tail + 1) % q->ndesc;
q->queued--;
}
+
+ q->head = q->tail;
+ airoha_qdma_rmw(qdma, REG_RX_DMA_IDX(qid), RX_RING_DMA_IDX_MASK,
+ FIELD_PREP(RX_RING_DMA_IDX_MASK, q->tail));
}
static int airoha_qdma_init_rx(struct airoha_qdma *qdma)
---
base-commit: ae05340ccaa9d347fe85415609e075545bec589f
change-id: 20260326-airoha_qdma_cleanup_rx_queue-fix-5efd8e392bd0
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH next] netfilter: nf_conntrack_h323: Correct indentation when H323_TRACE defined
From: Petr Mladek @ 2026-03-27 9:47 UTC (permalink / raw)
To: david.laight.linux
Cc: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
netfilter-devel, coreteam, netdev, linux-kernel, Masami Hiramatsu,
Rasmus Villemoes, Andy Shevchenko, Steven Rostedt,
Sergey Senozhatsky, Andrew Morton
In-Reply-To: <20260326201819.3900-1-david.laight.linux@gmail.com>
On Thu 2026-03-26 20:18:19, david.laight.linux@gmail.com wrote:
> From: David Laight <david.laight.linux@gmail.com>
>
> The trace lines are indented using PRINT("%*.s", xx, " ").
> Userspace will treat this as "%*.0s" and will output no characters
> when 'xx' is zero, the kernel treats it as "%*s" and will output
> a single ' ' - which is probably what is intended.
>
> Change all the formats to "%*s" removing the default precision.
> This gives a single space indent when level is zero.
>
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
> ---
> net/netfilter/nf_conntrack_h323_asn1.c | 38 +++++++++++++-------------
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_h323_asn1.c b/net/netfilter/nf_conntrack_h323_asn1.c
> index 7b1497ed97d2..287402428975 100644
> --- a/net/netfilter/nf_conntrack_h323_asn1.c
> +++ b/net/netfilter/nf_conntrack_h323_asn1.c
> @@ -276,7 +276,7 @@ static unsigned int get_uint(struct bitstr *bs, int b)
> static int decode_nul(struct bitstr *bs, const struct field_t *f,
> char *base, int level)
> {
> - PRINT("%*.s%s\n", level * TAB_SIZE, " ", f->name);
> + PRINT("%*s%s\n", level * TAB_SIZE, " ", f->name);
>
> return H323_ERROR_NONE;
> }
The change is important for making the kernel %*.s handling POSIX
compliant. The dot '.' without any following number is handled
a zero precision by POSIX. It would print no space "" when
also the field width was zero, aka when level == 0.
It has no efect if the field width (@level) is always > 0 because
vsprintf() would add the required emptry spaces ' ' anyway.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH net-next v3] net: qrtr: fix endian handling of confirm_rx field
From: Simon Horman @ 2026-03-27 9:46 UTC (permalink / raw)
To: Alexander Wilhelm
Cc: Manivannan Sadhasivam, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Bjorn Andersson, linux-arm-msm,
netdev, linux-kernel
In-Reply-To: <20260326-b4-qrtr-fix-confirm_rx-on-big-endian-v3-1-9ea3c855ce39@westermo.com>
On Thu, Mar 26, 2026 at 08:17:52AM +0100, Alexander Wilhelm wrote:
> Convert confirm_rx to little endian when enqueueing and convert it back on
> receive. This fixes control flow on big endian hosts, little endian is
> unaffected.
>
> On transmit, store confirm_rx as __le32 using cpu_to_le32(). On receive,
> apply le32_to_cpu() before using the value. !! ensures the value is 0 or 1
> in native endianness, so the conversion isn’t strictly required here, but
> it is kept for consistency and clarity.
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
> ---
> Changes in v3:
> - Rebase on latest net-next tree
> - Remove "Fixes" tag
> - Link to v2: https://lore.kernel.org/r/20260324-b4-qrtr-fix-confirm_rx-on-big-endian-v2-1-674fb3f4865b@westermo.com
>
> Changes in v2:
> - Rebase on latest net tree
> - Improve commit message
> - Link to v1: https://lore.kernel.org/r/20260320-qrtr-fix-confirm_rx-on-big-endian-v1-1-e1a337dc1a38@westermo.com
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [PATCH net-next 2/2] net: stmmac: simplify GSO/TSO test in stmmac_xmit()
From: Russell King (Oracle) @ 2026-03-27 9:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Paolo Abeni
In-Reply-To: <acZQaDeCoib5S5UA@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 | 30 +++++++++++--------
2 files changed, 20 insertions(+), 13 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 8203d6845b00..d3e8d793af52 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3700,7 +3700,7 @@ static int stmmac_hw_setup(struct net_device *dev)
stmmac_set_rings_length(priv);
/* Enable TSO */
- if (priv->tso) {
+ if (priv->gso_enabled_types) {
for (chan = 0; chan < tx_cnt; chan++) {
struct stmmac_tx_queue *tx_q = &priv->dma_conf.tx_queue[chan];
@@ -4675,7 +4675,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;
@@ -4687,14 +4686,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]) {
@@ -6049,6 +6043,18 @@ static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
+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 netdev_features_t stmmac_fix_features(struct net_device *dev,
netdev_features_t features)
{
@@ -6094,7 +6100,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;
@@ -7828,7 +7834,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 1/2] net: stmmac: fix .ndo_fix_features()
From: Russell King (Oracle) @ 2026-03-27 9:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Paolo Abeni
In-Reply-To: <acZQaDeCoib5S5UA@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 9b6b49331639..8203d6845b00 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6068,14 +6068,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;
}
@@ -6102,6 +6094,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 0/2] net: stmmac: fix and clean up TSO/GSO support
From: Russell King (Oracle) @ 2026-03-27 9:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Paolo Abeni
This series:
1. moves setting priv->tso from stmmac_fix_features() to
stmmac_set_features() as fix_features is not supposed to change
driver state.
2. simplifies the TSO/GSP test in stmmac_xmit() to simply check if the
skbuff is a GSO buffer, and whether the gso_type is one that we
should handle.
A previous version of patch 1 was posted in February:
https://lore.kernel.org/r/E1vuU3X-0000000Ae9G-1Er8@rmk-PC.armlinux.org.uk/
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 38 +++++++++++------------
2 files changed, 21 insertions(+), 20 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] net: airoha: Grab flow_offload_mutex running airoha_register_gdm_devices()
From: Lorenzo Bianconi @ 2026-03-27 8:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260326200605.39222917@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Mar 26, Jakub Kicinski wrote:
> On Tue, 24 Mar 2026 17:54:45 +0100 Lorenzo Bianconi wrote:
> > Netfilter flowtable can theoretically try offload flower rules as soon
> > as a net-device is registered while not all the other ones are
> > registered/initialized, triggering a possible NULL pointer dereferencing
> > of qdma pointer in airoha_ppe_set_cpu_port routine. In order to avoid any
> > possible race, grab the flow_offload_mutex running
> > airoha_register_gdm_devices().
>
> Sashiko says this causes a lock ordering issue:
> https://sashiko.dev/#/patchset/20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org
Ack, right. Thx for pointing this issue out. I will work on a different
solution.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next v2] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Ronald Claveau @ 2026-03-27 9:36 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
van Spriel
Cc: linux-wireless, devicetree, linux-kernel, netdev, Conor Dooley,
Ronald Claveau
Add bcm43752 compatible with its bcm4329 compatible fallback.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
The Khadas VIM4 board based on Amlogic A311D2 aka T7 features an AP6275s Wi-Fi/Bluetooth module with a BCM43752 chipset.
This patch aims to add this chipset with its fallback to bcm4329 compatible.
The original patch series is here:
https://lore.kernel.org/r/20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr
---
Changes in v2:
- Add netdev in CC.
- Link to v1: https://lore.kernel.org/r/20260326-add-bcm43752-compatible-v1-1-b3b9a58ab38b@aliel.fr
---
Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index 3be7576787644..81fd3e37452a6 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
@@ -42,6 +42,7 @@ properties:
- brcm,bcm4356-fmac
- brcm,bcm4359-fmac
- brcm,bcm4366-fmac
+ - brcm,bcm43752-fmac
- cypress,cyw4373-fmac
- cypress,cyw43012-fmac
- infineon,cyw43439-fmac
---
base-commit: 45b2b84ac6fde39c427018d6cdf7d44258938faa
change-id: 20260326-add-bcm43752-compatible-e264a4f7973a
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply related
* Re: [PATCH next] netfilter: nf_conntrack_h323: Correct indentation when H323_TRACE defined
From: Andy Shevchenko @ 2026-03-27 9:24 UTC (permalink / raw)
To: David Laight
Cc: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
netfilter-devel, coreteam, netdev, linux-kernel, Masami Hiramatsu,
Petr Mladek, Rasmus Villemoes, Steven Rostedt, Sergey Senozhatsky,
Andrew Morton
In-Reply-To: <20260326221809.0b99df3f@pumpkin>
On Thu, Mar 26, 2026 at 10:18:09PM +0000, David Laight wrote:
> On Thu, 26 Mar 2026 21:24:39 +0100
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Thu, Mar 26, 2026 at 08:18:19PM +0000, david.laight.linux@gmail.com wrote:
> > >
> > > The trace lines are indented using PRINT("%*.s", xx, " ").
> > > Userspace will treat this as "%*.0s" and will output no characters
> > > when 'xx' is zero, the kernel treats it as "%*s" and will output
> > > a single ' ' - which is probably what is intended.
> > >
> > > Change all the formats to "%*s" removing the default precision.
> > > This gives a single space indent when level is zero.
> >
> > Do you have a setup using this helper? Or you just found this via
> > visual inspection?
>
> Found with grep looking for places which might be affected by 'fixing'
> the kernel printf code to be POSIX compliant.
Do we have the respective test case in printf_kunit?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next 03/15] net: stmmac: qcom-ethqos: eliminate configure_func
From: Simon Horman @ 2026-03-27 9:23 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-stm32, Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <acV29ruRVy_fcwDq@shell.armlinux.org.uk>
On Thu, Mar 26, 2026 at 06:12:06PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 26, 2026 at 06:04:53PM +0000, Simon Horman wrote:
> > On Tue, Mar 24, 2026 at 01:11:44PM +0000, Russell King (Oracle) wrote:
> > > Since ethqos_fix_mac_speed() is called via a function pointer, and only
> > > indirects via the configure_func function pointer, eliminate this
> > > unnecessary indirection.
> > >
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> >
> > ...
> >
> > > @@ -623,14 +627,6 @@ static void ethqos_configure_sgmii(struct qcom_ethqos *ethqos,
> > > ethqos_pcs_set_inband(ethqos, interface == PHY_INTERFACE_MODE_SGMII);
> > > }
> > >
> > > -static void ethqos_fix_mac_speed(void *priv, phy_interface_t interface,
> > > - int speed, unsigned int mode)
> > > -{
> > > - struct qcom_ethqos *ethqos = priv;
> > > -
> > > - ethqos->configure_func(ethqos, interface, speed);
> > > -}
> > > -
> > > static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
> > > {
> > > struct qcom_ethqos *ethqos = priv;
> >
> > Hi Russell,
> >
> > FYI, AI generated review reports that the comment in ethqos_clks_config()
> > that references ethqos_fix_mac_speed() should also be updated.
>
> Also already noted (yesterday).
>
> I do keep an eye on patchwork for my own patches - I have a firefox tab
> permanently open for my patches in patchwork:
>
> https://patchwork.kernel.org/project/netdevbpf/list/?submitter=165511
>
> Thanks anyway.
Thanks, and sorry if you told me this before.
I'll try to remember and not spam you with these things going forward.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: lan743x: add support for RMII interface
From: Maxime Chevallier @ 2026-03-27 9:18 UTC (permalink / raw)
To: Thangaraj Samynathan, bryan.whitehead, UNGLinuxDriver,
andrew+netdev, davem, edumazet, kuba, pabeni, linux,
Raju.Lakkaraju
Cc: netdev, linux-kernel
In-Reply-To: <72b79059-25e1-4209-a0dc-30dc0c310aff@bootlin.com>
On 27/03/2026 09:47, Maxime Chevallier wrote:
> Hi,
>
> On 27/03/2026 06:40, Thangaraj Samynathan wrote:
>> Enable RMII interface in the lan743x driver for PHY and MAC
>> configuration.
>>
>> - Select RMII interface in lan743x_phy_interface_select().
>> - Update phylink supported_interfaces and MAC capabilities.
>> - Enable RMII via RMII_CTL in lan743x_hardware_init().
>> - Define RMII_CTL register and enable bit in lan743x_main.h.
>>
>> Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
>> ---
>> drivers/net/ethernet/microchip/lan743x_main.c | 18 ++++++++++++++++++
>> drivers/net/ethernet/microchip/lan743x_main.h | 3 +++
>> 2 files changed, 21 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
>> index b7b1584d867d..86d35810460f 100644
>> --- a/drivers/net/ethernet/microchip/lan743x_main.c
>> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
>> @@ -1370,6 +1370,8 @@ static void lan743x_phy_interface_select(struct lan743x_adapter *adapter)
>>
>> if (adapter->is_pci11x1x && adapter->is_sgmii_en)
>> adapter->phy_interface = PHY_INTERFACE_MODE_SGMII;
>> + else if (adapter->is_pci11x1x && adapter->is_rmii_en)
>> + adapter->phy_interface = PHY_INTERFACE_MODE_RMII;
>> else if (id_rev == ID_REV_ID_LAN7430_)
>> adapter->phy_interface = PHY_INTERFACE_MODE_GMII;
>> else if ((id_rev == ID_REV_ID_LAN7431_) && (data & MAC_CR_MII_EN_))
>> @@ -3158,6 +3160,13 @@ static int lan743x_phylink_create(struct lan743x_adapter *adapter)
>> __set_bit(PHY_INTERFACE_MODE_MII,
>> adapter->phylink_config.supported_interfaces);
>> break;
>> + case PHY_INTERFACE_MODE_RMII:
>> + __set_bit(PHY_INTERFACE_MODE_RMII,
>> + adapter->phylink_config.supported_interfaces);
>> + adapter->phylink_config.mac_capabilities &= ~MAC_1000FD;
>
> Some followup should take care of removing the 1000FD cap for MII as
> well.
Well as Russell says, no need for that :)
Maxime
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: lan743x: add support for RMII interface
From: Russell King (Oracle) @ 2026-03-27 8:57 UTC (permalink / raw)
To: Thangaraj Samynathan
Cc: bryan.whitehead, UNGLinuxDriver, andrew+netdev, davem, edumazet,
kuba, pabeni, Raju.Lakkaraju, maxime.chevallier, netdev,
linux-kernel
In-Reply-To: <20260327054008.79294-3-thangaraj.s@microchip.com>
On Fri, Mar 27, 2026 at 11:10:08AM +0530, Thangaraj Samynathan wrote:
> Enable RMII interface in the lan743x driver for PHY and MAC
> configuration.
>
> - Select RMII interface in lan743x_phy_interface_select().
> - Update phylink supported_interfaces and MAC capabilities.
> - Enable RMII via RMII_CTL in lan743x_hardware_init().
> - Define RMII_CTL register and enable bit in lan743x_main.h.
>
> Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
> ---
> drivers/net/ethernet/microchip/lan743x_main.c | 18 ++++++++++++++++++
> drivers/net/ethernet/microchip/lan743x_main.h | 3 +++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
> index b7b1584d867d..86d35810460f 100644
> --- a/drivers/net/ethernet/microchip/lan743x_main.c
> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
> @@ -1370,6 +1370,8 @@ static void lan743x_phy_interface_select(struct lan743x_adapter *adapter)
>
> if (adapter->is_pci11x1x && adapter->is_sgmii_en)
> adapter->phy_interface = PHY_INTERFACE_MODE_SGMII;
> + else if (adapter->is_pci11x1x && adapter->is_rmii_en)
> + adapter->phy_interface = PHY_INTERFACE_MODE_RMII;
> else if (id_rev == ID_REV_ID_LAN7430_)
> adapter->phy_interface = PHY_INTERFACE_MODE_GMII;
> else if ((id_rev == ID_REV_ID_LAN7431_) && (data & MAC_CR_MII_EN_))
> @@ -3158,6 +3160,13 @@ static int lan743x_phylink_create(struct lan743x_adapter *adapter)
> __set_bit(PHY_INTERFACE_MODE_MII,
> adapter->phylink_config.supported_interfaces);
> break;
> + case PHY_INTERFACE_MODE_RMII:
> + __set_bit(PHY_INTERFACE_MODE_RMII,
> + adapter->phylink_config.supported_interfaces);
> + adapter->phylink_config.mac_capabilities &= ~MAC_1000FD;
Phylink already knows that gigabit isn't supported with RMII. See
phy_caps_from_interface():
case PHY_INTERFACE_MODE_REVRMII:
case PHY_INTERFACE_MODE_RMII:
case PHY_INTERFACE_MODE_SMII:
case PHY_INTERFACE_MODE_REVMII:
case PHY_INTERFACE_MODE_MII:
link_caps |= BIT(LINK_CAPA_10HD) | BIT(LINK_CAPA_10FD);
fallthrough;
case PHY_INTERFACE_MODE_100BASEX:
link_caps |= BIT(LINK_CAPA_100HD) | BIT(LINK_CAPA_100FD);
break;
which is used by phylink_get_capabilities() to reduce the MAC
capabilities depending on the interface and rate matching.
The only case to do this is where the MAC really has no 1G support.
--
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 v2 03/12] ethtool: Add loopback netlink UAPI definitions
From: Maxime Chevallier @ 2026-03-27 8:57 UTC (permalink / raw)
To: Jakub Kicinski, Björn Töpel
Cc: netdev, David S. Miller, Andrew Lunn, Donald Hunter, Eric Dumazet,
Naveen Mamindlapalli, Paolo Abeni, Simon Horman, Danielle Ratson,
Hariprasad Kelam, Ido Schimmel, Kory Maincent, Leon Romanovsky,
Michael Chan, Oleksij Rempel, Pavan Chebbi, Piergiorgio Beruto,
Russell King, Saeed Mahameed, Shuah Khan, Tariq Toukan,
Willem de Bruijn, Kees Cook, linux-kernel, linux-kselftest,
linux-rdma
In-Reply-To: <20260326152337.2cff3c24@kernel.org>
On 26/03/2026 23:23, Jakub Kicinski wrote:
> On Wed, 25 Mar 2026 15:50:10 +0100 Björn Töpel wrote:
>> + -
>> + name: depth
>> + type: u8
>> + doc: |
>> + Ordering index within a component instance. When a component
>> + has multiple loopback points of the same type (e.g. two PCS
>> + blocks inside a rate-adaptation PHY), depth distinguishes
>> + them. Lower depth values are closer to the host side, higher
>> + values are closer to the line/media side. Defaults to 0 when
>> + there is only one loopback point per (component, name) tuple.
>> + -
>> + name: supported
>> + type: u8
>> + enum: loopback-direction
>> + enum-as-flags: true
>> + doc: Bitmask of supported loopback directions
>> + -
>> + name: direction
>> + type: u8
>> + enum: loopback-direction
>> + doc: Current loopback direction, 0 means disabled
>
> u32, Netlink attrs are padded to 4B anyway
That's my bad, I was the one suggesting u8 :( I didn't have the padding
thing in mind at that time :/
Maxime
^ permalink raw reply
* Re: [PATCH net-next] mlx5: shd: Gracefully avoid shared devlink creation when no usable SN is found
From: Ben Copeland @ 2026-03-27 8:56 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, kuba, pabeni, andrew+netdev, saeedm,
leon, tariqt, mbloch, admiyo
In-Reply-To: <20260325152801.236343-1-jiri@resnulli.us>
On Wed, 25 Mar 2026 at 15:28, Jiri Pirko <jiri@resnulli.us> wrote:
>
> From: Jiri Pirko <jiri@nvidia.com>
>
> On some HW, not even fall-back "SERIALNO" is found in VPD data. Unify
> the behavior with the case there are no VPD data at all and avoid
> creation of shared devlink instance.
>
> Fixes: 2a8c8a03f306 ("net/mlx5: Add a shared devlink instance for PFs on same chip")
> Reported-by: Adam Young <admiyo@amperemail.onmicrosoft.com>
> Closes: https://lore.kernel.org/all/bab5b6bc-aa42-4af1-80d1-e56bcef06bc2@amperemail.onmicrosoft.com/
> Reported-by: Ben Copeland <ben.copeland@linaro.org>
> Closes: https://lore.kernel.org/all/20260324151014.860376-1-ben.copeland@linaro.org/
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/sh_devlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sh_devlink.c b/drivers/net/ethernet/mellanox/mlx5/core/sh_devlink.c
> index bc33f95302df..b925364765ac 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/sh_devlink.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/sh_devlink.c
> @@ -33,7 +33,7 @@ int mlx5_shd_init(struct mlx5_core_dev *dev)
> start = pci_vpd_find_ro_info_keyword(vpd_data, vpd_size,
> PCI_VPD_RO_KEYWORD_SERIALNO, &kw_len);
> if (start < 0)
> - return -ENOENT;
> + return 0; /* No usable serial number found, ignore. */
> }
> sn = kstrndup(vpd_data + start, kw_len, GFP_KERNEL);
> if (!sn)
> --
> 2.51.1
>
Tested-by: Ben Copeland <ben.copeland@linaro.org>
Tested before and after on the Ampere Server, and the applied fix worked.
Thanks!
Ben
^ permalink raw reply
* Re: [PATCH] rtnetlink: add missing netlink_ns_capable() check for peer netns
From: Nikolaos Gkarlis @ 2026-03-27 8:55 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20260326203646.2da52419@kernel.org>
Hi Jakub,
I've created a crude reproduction script using some AI. If that helps,
you can find it here:
https://gist.githubusercontent.com/nickgarlis/5a5815d438aa19b409806712f35f2cb1/raw/c7e2dd0902f1f53f5750f7bbd3ba39ff0b21e43e/inject_iface.c
> AI assistant here suggests this is not the valid Fixes tag,
> which seems true on the surface. This commit was fixing
> cleanup, IDK how it could break input validation?
I went back to check and ran the test against 7a0ea70da56e (the commit
prior) and it does seem like it was broken then too. I think I must have
messed up my testing process when I initially submitted the patch.
It also seems like the bug was always there or at least - almost always
- since Iassume it wasn't a problem before unprivileged namespaces
were introduced ?
In that case, should the tags point to the introduction of the
attributes (like shown below) or point to the introduction of
the namespaces ?
Fixes: 0eb87b02a705 ("veth: Set VETH_INFO_PEER to veth_link_ops.peer_type.")
Fixes: 6b84e558e95d ("vxcan: Set VXCAN_INFO_PEER to vxcan_link_ops.peer_type.")
Fixes: fefd5d082172 ("netkit: Set IFLA_NETKIT_PEER_INFO to
netkit_link_ops.peer_type.")
> Reported-by tags are only when the reporter is different than author
> the Google's bounty program rules have been amended to make this
> explicit, please let us know if other programs still mislead people
That was a mistake on my part, not going through the docs properly.
I'll fix all of the tags in a V2 if you want to accept the patch.
^ permalink raw reply
* [PATCH net] net/x25: Fix overflow when accumulating packets
From: Martin Schiller @ 2026-03-27 8:30 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Yiming Qian, linux-x25, netdev, linux-kernel, security,
Martin Schiller
Add a check to ensure that `x25_sock.fraglen` does not overflow.
The `fraglen` also needs to be resetted when purging `fragment_queue` in
`x25_clear_queues()`.
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
---
net/x25/x25_in.c | 6 ++++++
net/x25/x25_subr.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/net/x25/x25_in.c b/net/x25/x25_in.c
index b981a4828d08c2e6676749a06035910eab01e6cd..1603238d6fff73090ef10b5fd11387b3e7f017a2 100644
--- a/net/x25/x25_in.c
+++ b/net/x25/x25_in.c
@@ -34,6 +34,12 @@ static int x25_queue_rx_frame(struct sock *sk, struct sk_buff *skb, int more)
struct sk_buff *skbo, *skbn = skb;
struct x25_sock *x25 = x25_sk(sk);
+ /* make sure we don't overflow */
+ if (x25->fraglen + skb->len > sizeof(x25->fraglen)) {
+ kfree_skb(skb);
+ return 1;
+ }
+
if (more) {
x25->fraglen += skb->len;
skb_queue_tail(&x25->fragment_queue, skb);
diff --git a/net/x25/x25_subr.c b/net/x25/x25_subr.c
index 0285aaa1e93c17233748d38eef6d8b5c6059b67a..159708d9ad20cb2e6db24ead67daf1e9d6258f64 100644
--- a/net/x25/x25_subr.c
+++ b/net/x25/x25_subr.c
@@ -40,6 +40,7 @@ void x25_clear_queues(struct sock *sk)
skb_queue_purge(&x25->interrupt_in_queue);
skb_queue_purge(&x25->interrupt_out_queue);
skb_queue_purge(&x25->fragment_queue);
+ x25->fraglen = 0;
}
---
base-commit: 4ae97cae07e15d41e5c0ebabba64c6eefdeb0bbe
change-id: 20260325-x25_fraglen-8fc240d1edd3
Best regards,
--
Martin Schiller <ms@dev.tdt.de>
^ permalink raw reply related
* [PATCH net v2] net/x25: Fix overflow when accumulating packets
From: Martin Schiller @ 2026-03-27 8:49 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Yiming Qian, linux-x25, netdev, linux-kernel, security,
Martin Schiller
Add a check to ensure that `x25_sock.fraglen` does not overflow.
The `fraglen` also needs to be resetted when purging `fragment_queue` in
`x25_clear_queues()`.
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
---
Changes in v2:
- Use USHRT_MAX instead of sizeof(fraglen) nonsense
- Link to v1: https://lore.kernel.org/r/20260327-x25_fraglen-v1-1-9fc751d4f754@dev.tdt.de
---
net/x25/x25_in.c | 6 ++++++
net/x25/x25_subr.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/net/x25/x25_in.c b/net/x25/x25_in.c
index b981a4828d08c2e6676749a06035910eab01e6cd..cb84c683d249d6078f3673835bb2f80eb487f253 100644
--- a/net/x25/x25_in.c
+++ b/net/x25/x25_in.c
@@ -34,6 +34,12 @@ static int x25_queue_rx_frame(struct sock *sk, struct sk_buff *skb, int more)
struct sk_buff *skbo, *skbn = skb;
struct x25_sock *x25 = x25_sk(sk);
+ /* make sure we don't overflow */
+ if (x25->fraglen + skb->len > USHRT_MAX) {
+ kfree_skb(skb);
+ return 1;
+ }
+
if (more) {
x25->fraglen += skb->len;
skb_queue_tail(&x25->fragment_queue, skb);
diff --git a/net/x25/x25_subr.c b/net/x25/x25_subr.c
index 0285aaa1e93c17233748d38eef6d8b5c6059b67a..159708d9ad20cb2e6db24ead67daf1e9d6258f64 100644
--- a/net/x25/x25_subr.c
+++ b/net/x25/x25_subr.c
@@ -40,6 +40,7 @@ void x25_clear_queues(struct sock *sk)
skb_queue_purge(&x25->interrupt_in_queue);
skb_queue_purge(&x25->interrupt_out_queue);
skb_queue_purge(&x25->fragment_queue);
+ x25->fraglen = 0;
}
---
base-commit: 4ae97cae07e15d41e5c0ebabba64c6eefdeb0bbe
change-id: 20260325-x25_fraglen-8fc240d1edd3
Best regards,
--
Martin Schiller <ms@dev.tdt.de>
^ permalink raw reply related
* Re: [PATCH net-next v8 4/4] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
From: Michael S. Tsirkin @ 2026-03-27 8:47 UTC (permalink / raw)
To: Jason Wang
Cc: Simon Schippers, willemdebruijn.kernel, andrew+netdev, davem,
edumazet, kuba, pabeni, eperezma, leiyang, stephen, jon,
tim.gebauer, netdev, linux-kernel, kvm, virtualization
In-Reply-To: <CACGkMEsUag4zNZG+aYipHv_PirbKb_rs7DzSOr-NF8ckhUaJOQ@mail.gmail.com>
On Fri, Mar 27, 2026 at 09:13:44AM +0800, Jason Wang wrote:
> On Thu, Mar 26, 2026 at 11:31 PM Simon Schippers
> <simon.schippers@tu-dortmund.de> wrote:
> >
> > On 3/26/26 03:41, Jason Wang wrote:
> > > On Wed, Mar 25, 2026 at 10:48 PM Simon Schippers
> > > <simon.schippers@tu-dortmund.de> wrote:
> > >>
> > >> On 3/24/26 11:14, Simon Schippers wrote:
> > >>> On 3/24/26 02:47, Jason Wang wrote:
> > >>>> On Thu, Mar 12, 2026 at 9:07 PM Simon Schippers
> > >>>> <simon.schippers@tu-dortmund.de> wrote:
> > >>>>>
> > >>>>> This commit prevents tail-drop when a qdisc is present and the ptr_ring
> > >>>>> becomes full. Once an entry is successfully produced and the ptr_ring
> > >>>>> reaches capacity, the netdev queue is stopped instead of dropping
> > >>>>> subsequent packets.
> > >>>>>
> > >>>>> If producing an entry fails anyways due to a race, tun_net_xmit returns
> > >>>>> NETDEV_TX_BUSY, again avoiding a drop. Such races are expected because
> > >>>>> LLTX is enabled and the transmit path operates without the usual locking.
> > >>>>>
> > >>>>> The existing __tun_wake_queue() function wakes the netdev queue. Races
> > >>>>> between this wakeup and the queue-stop logic could leave the queue
> > >>>>> stopped indefinitely. To prevent this, a memory barrier is enforced
> > >>>>> (as discussed in a similar implementation in [1]), followed by a recheck
> > >>>>> that wakes the queue if space is already available.
> > >>>>>
> > >>>>> If no qdisc is present, the previous tail-drop behavior is preserved.
> > >>>>
> > >>>> I wonder if we need a dedicated TUN flag to enable this. With this new
> > >>>> flag, we can even prevent TUN from using noqueue (not sure if it's
> > >>>> possible or not).
> > >>>>
> > >>>
> > >>> Except of the slight regressions because of this patchset I do not see
> > >>> a reason for such a flag.
> > >>>
> > >>> I have never seen that the driver prevents noqueue. For example you can
> > >>> set noqueue to your ethernet interface and under load you soon get
> > >>>
> > >>> net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
> > >>> dev->name);
> > >>>
> > >>> followed by a -ENETDOWN. And this is not prevented even though it is
> > >>> clearly not something a user wants.
> > >>>
> > >>>>>
> > >>>>> Benchmarks:
> > >>>>> The benchmarks show a slight regression in raw transmission performance,
> > >>>>> though no packets are lost anymore.
> > >>>>>
> > >>>>> The previously introduced threshold to only wake after the queue stopped
> > >>>>> and half of the ring was consumed showed to be a descent choice:
> > >>>>> Waking the queue whenever a consume made space in the ring strongly
> > >>>>> degrades performance for tap, while waking only when the ring is empty
> > >>>>> is too late and also hurts throughput for tap & tap+vhost-net.
> > >>>>> Other ratios (3/4, 7/8) showed similar results (not shown here), so
> > >>>>> 1/2 was chosen for the sake of simplicity for both tun/tap and
> > >>>>> tun/tap+vhost-net.
> > >>>>>
> > >>>>> Test setup:
> > >>>>> AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads;
> > >>>>> Average over 20 runs @ 100,000,000 packets. SRSO and spectre v2
> > >>>>> mitigations disabled.
> > >>>>>
> > >>>>> Note for tap+vhost-net:
> > >>>>> XDP drop program active in VM -> ~2.5x faster, slower for tap due to
> > >>>>> more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf)
> > >>>>>
> > >>>>> +--------------------------+--------------+----------------+----------+
> > >>>>> | 1 thread | Stock | Patched with | diff |
> > >>>>> | sending | | fq_codel qdisc | |
> > >>>>> +------------+-------------+--------------+----------------+----------+
> > >>>>> | TAP | Transmitted | 1.151 Mpps | 1.139 Mpps | -1.1% |
> > >>>>> | +-------------+--------------+----------------+----------+
> > >>>>> | | Lost/s | 3.606 Mpps | 0 pps | |
> > >>>>> +------------+-------------+--------------+----------------+----------+
> > >>>>> | TAP | Transmitted | 3.948 Mpps | 3.738 Mpps | -5.3% |
> > >>>>> | +-------------+--------------+----------------+----------+
> > >>>>> | +vhost-net | Lost/s | 496.5 Kpps | 0 pps | |
> > >>>>> +------------+-------------+--------------+----------------+----------+
> > >>>>>
> > >>>>> +--------------------------+--------------+----------------+----------+
> > >>>>> | 2 threads | Stock | Patched with | diff |
> > >>>>> | sending | | fq_codel qdisc | |
> > >>>>> +------------+-------------+--------------+----------------+----------+
> > >>>>> | TAP | Transmitted | 1.133 Mpps | 1.109 Mpps | -2.1% |
> > >>>>> | +-------------+--------------+----------------+----------+
> > >>>>> | | Lost/s | 8.269 Mpps | 0 pps | |
> > >>>>> +------------+-------------+--------------+----------------+----------+
> > >>>>> | TAP | Transmitted | 3.820 Mpps | 3.513 Mpps | -8.0% |
> > >>>>> | +-------------+--------------+----------------+----------+
> > >>>>> | +vhost-net | Lost/s | 4.961 Mpps | 0 pps | |
> > >>>>> +------------+-------------+--------------+----------------+----------+
> > >>>>>
> > >>>>> [1] Link: https://lore.kernel.org/all/20250424085358.75d817ae@kernel.org/
> > >>>>>
> > >>>>> Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> > >>>>> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> > >>>>> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
> > >>>>> ---
> > >>>>> drivers/net/tun.c | 30 ++++++++++++++++++++++++++++--
> > >>>>> 1 file changed, 28 insertions(+), 2 deletions(-)
> > >>>>>
> > >>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > >>>>> index b86582cc6cb6..9b7daec69acd 100644
> > >>>>> --- a/drivers/net/tun.c
> > >>>>> +++ b/drivers/net/tun.c
> > >>>>> @@ -1011,6 +1011,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> > >>>>> struct netdev_queue *queue;
> > >>>>> struct tun_file *tfile;
> > >>>>> int len = skb->len;
> > >>>>> + bool qdisc_present;
> > >>>>> + int ret;
> > >>>>>
> > >>>>> rcu_read_lock();
> > >>>>> tfile = rcu_dereference(tun->tfiles[txq]);
> > >>>>> @@ -1063,13 +1065,37 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> > >>>>>
> > >>>>> nf_reset_ct(skb);
> > >>>>>
> > >>>>> - if (ptr_ring_produce(&tfile->tx_ring, skb)) {
> > >>>>> + queue = netdev_get_tx_queue(dev, txq);
> > >>>>> + qdisc_present = !qdisc_txq_has_no_queue(queue);
> > >>>>> +
> > >>>>> + spin_lock(&tfile->tx_ring.producer_lock);
> > >>>>> + ret = __ptr_ring_produce(&tfile->tx_ring, skb);
> > >>>>> + if (__ptr_ring_produce_peek(&tfile->tx_ring) && qdisc_present) {
> > >>>>
> > >>>> So, it's possible that the administrator is switching between noqueue
> > >>>> and another qdisc. So ptr_ring_produce() can fail here, do we need to
> > >>>> check that or not?
> > >>>>
> > >>>
> > >>> Do you mean that? My thoughts:
> > >>>
> > >>> Switching from noqueue to some qdisc can cause a
> > >>>
> > >>> net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
> > >>> dev->name);
> > >>>
> > >>> followed by a return of -ENETDOWN in __dev_queue_xmit().
> > >>> This is because tun_net_xmit detects some qdisc with
> > >>>
> > >>> qdisc_present = !qdisc_txq_has_no_queue(queue);
> > >>>
> > >>> and returns NETDEV_TX_BUSY even though __dev_queue_xmit() did still
> > >>> detect noqueue.
> > >>>
> > >>> I am not sure how to solve this/if this has to be solved.
> > >>> I do not see a proper way to avoid parallel execution of ndo_start_xmit
> > >>> and a qdisc change (dev_graft_qdisc only takes qdisc_skb_head lock).
> > >>>
> > >>> And from my understanding the veth implementation faces the same issue.
> > >>
> > >> How about rechecking if a qdisc is connected?
> > >> This would avoid -ENETDOWN.
> > >>
> > >> diff --git a/net/core/dev.c b/net/core/dev.c
> > >> index f48dc299e4b2..2731a1a70732 100644
> > >> --- a/net/core/dev.c
> > >> +++ b/net/core/dev.c
> > >> @@ -4845,10 +4845,17 @@ int __dev_queue_xmit(struct sk_buff *skb, struct net_device *sb_dev)
> > >> if (is_list)
> > >> rc = NETDEV_TX_OK;
> > >> }
> > >> + bool qdisc_present = !qdisc_txq_has_no_queue(txq);
> > >> HARD_TX_UNLOCK(dev, txq);
> > >> if (!skb) /* xmit completed */
> > >> goto out;
> > >>
> > >> + /* Maybe a qdisc was connected in the meantime */
> > >> + if (qdisc_present) {
> > >> + kfree_skb(skb);
> > >> + goto out;
> > >> + }
> > >> +
> > >> net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
> > >> dev->name);
> > >> /* NETDEV_TX_BUSY or queue was stopped */
> > >>
> > >
> > > Probably not, and we likely won't hit this warning because qdisc could
> > > not be changed during ndo_start_xmit().
> >
> > Okay.
> >
> > >
> > > I meant something like this:
> > >
> > > 1) set noqueue to tuntap
> > > 2) produce packets so tuntap is full
> > > 3) set e.g fq_codel to tuntap
> > > 4) then we can hit the failure of __ptr_ring_produce()
> > >
> > > Rethink of the code, it looks just fine.
> >
> > Yes, in this case it just returns NETDEV_TX_BUSY which is fine with a
> > qdisc attached.
> >
> > >
> > >>
> > >>>
> > >>>
> > >>> Switching from some qdisc to noqueue is no problem I think.
> > >>>
> > >>>>> + netif_tx_stop_queue(queue);
> > >>>>> + /* Avoid races with queue wake-ups in __tun_wake_queue by
> > >>>>> + * waking if space is available in a re-check.
> > >>>>> + * The barrier makes sure that the stop is visible before
> > >>>>> + * we re-check.
> > >>>>> + */
> > >>>>> + smp_mb__after_atomic();
> > >>>>
> > >>>> Let's document which barrier is paired with this.
> > >>>>
> > >>>
> > >>> I am basically copying the (old) logic of veth [1] proposed by
> > >>> Jakub Kicinski. I must admit I am not 100% sure what it pairs with.
> > >>>
> > >>> [1] Link: https://lore.kernel.org/all/20250424085358.75d817ae@kernel.org/
> > >
> > > So it looks like it implicitly tries to pair with tun_ring_consume():
> > >
> > > 1) spinlock(consumer_lock)
> > > 2) store NULL to ptr_ring // STORE
> > > 3) spinunlock(consumer_lock) // RELEASE
> > > 4) spinlock(consumer_lock) // ACQURE
> > > 5) check empty
> > > 6) spinunlock(consumer_lock)
> > > 7) netif_wakeup_queue() // test_and_set() which is an RMW
> > >
> > > RELEASE + ACQUIRE implies a full barrier
> >
> > Thanks.
> >
> > >
> > > I see several problems
> > >
> > > 1) Due to batch consumption, we may get spurious wakeups under heavy
> > > load (we can try disabling batch consuming to see if it helps).
> >
> > I assume that you mean the waking in the recheck of the producer happens
> > too often and then wakes too often. But this would just take slightly
> > more producer cpu as the SOFTIRQ runs on the producer cpu and not slow
> > down the consumer?
> >
> > Why would disabling batch consume help here?
>
> We could end up with.
>
> 1) consumer wakes up the producer but the slot is not cleaned
> 2) producer is woken up but see the ring is full, so it need to drop the packet
>
> This probably defeat the goal of zero packet loss.
if this is rare enough, it might not matter.
> > Wouldn't it just decrease the consumer speed?
>
> Not sure, we probably need a benchmark.
>
> >
> > Apart from that I do not see a different method to do this recheck.
> > The ring producer is only safely able to do a !produce_peek (so a check
> > for !full).
> >
> > The normal waking (after consuming half of the ring) should be fine IMO.
> >
> > > 2) So the barriers don't help but would slow down the consuming
> > > 3) Two spinlocks were used instead of one, this is another reason we
> > > will see a performance regression
> >
> > You are right, I can change it to a single spin_lock. Apart from that
> > I do not see how the barriers/locking could be reduced further.
> >
> > > 4) Tricky code that needs to be understood or at least requires a comment tweak.
> > >
> > > Note that due to ~IFF_TX_SKB_SHARING, pktgen can't clone skbs, so we
> > > may not notice the real degradation.
> >
> > So run pktgen with pg_set SHARED?
>
> Probably (as a workaround).
>
> > I am pretty sure that the vhost
> > thread was always at 100% CPU so pktgen was not the bottleneck. And when
> > I had perf enabled I always saw that in my patched version not the
> > creation of SKB's took most CPU in pktgen but a different unnamed
> > function (I assume this is a waiting function).
>
> Let's try and see.
>
> Thanks
>
> >
> >
> > Thank you!
> >
> > >
> > >>>
> > >>>>> + if (!__ptr_ring_produce_peek(&tfile->tx_ring))
> > >>>>> + netif_tx_wake_queue(queue);
> > >>>>> + }
> > >>>>> + spin_unlock(&tfile->tx_ring.producer_lock);
> > >>>>> +
> > >>>>> + if (ret) {
> > >>>>> + /* If a qdisc is attached to our virtual device,
> > >>>>> + * returning NETDEV_TX_BUSY is allowed.
> > >>>>> + */
> > >>>>> + if (qdisc_present) {
> > >>>>> + rcu_read_unlock();
> > >>>>> + return NETDEV_TX_BUSY;
> > >>>>> + }
> > >>>>> drop_reason = SKB_DROP_REASON_FULL_RING;
> > >>>>> goto drop;
> > >>>>> }
> > >>>>>
> > >>>>> /* dev->lltx requires to do our own update of trans_start */
> > >>>>> - queue = netdev_get_tx_queue(dev, txq);
> > >>>>> txq_trans_cond_update(queue);
> > >>>>>
> > >>>>> /* Notify and wake up reader process */
> > >>>>> --
> > >>>>> 2.43.0
> > >>>>>
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>
> > >
> > > Thanks
> > >
> >
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: lan743x: add support for RMII interface
From: Maxime Chevallier @ 2026-03-27 8:47 UTC (permalink / raw)
To: Thangaraj Samynathan, bryan.whitehead, UNGLinuxDriver,
andrew+netdev, davem, edumazet, kuba, pabeni, linux,
Raju.Lakkaraju
Cc: netdev, linux-kernel
In-Reply-To: <20260327054008.79294-3-thangaraj.s@microchip.com>
Hi,
On 27/03/2026 06:40, Thangaraj Samynathan wrote:
> Enable RMII interface in the lan743x driver for PHY and MAC
> configuration.
>
> - Select RMII interface in lan743x_phy_interface_select().
> - Update phylink supported_interfaces and MAC capabilities.
> - Enable RMII via RMII_CTL in lan743x_hardware_init().
> - Define RMII_CTL register and enable bit in lan743x_main.h.
>
> Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
> ---
> drivers/net/ethernet/microchip/lan743x_main.c | 18 ++++++++++++++++++
> drivers/net/ethernet/microchip/lan743x_main.h | 3 +++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
> index b7b1584d867d..86d35810460f 100644
> --- a/drivers/net/ethernet/microchip/lan743x_main.c
> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
> @@ -1370,6 +1370,8 @@ static void lan743x_phy_interface_select(struct lan743x_adapter *adapter)
>
> if (adapter->is_pci11x1x && adapter->is_sgmii_en)
> adapter->phy_interface = PHY_INTERFACE_MODE_SGMII;
> + else if (adapter->is_pci11x1x && adapter->is_rmii_en)
> + adapter->phy_interface = PHY_INTERFACE_MODE_RMII;
> else if (id_rev == ID_REV_ID_LAN7430_)
> adapter->phy_interface = PHY_INTERFACE_MODE_GMII;
> else if ((id_rev == ID_REV_ID_LAN7431_) && (data & MAC_CR_MII_EN_))
> @@ -3158,6 +3160,13 @@ static int lan743x_phylink_create(struct lan743x_adapter *adapter)
> __set_bit(PHY_INTERFACE_MODE_MII,
> adapter->phylink_config.supported_interfaces);
> break;
> + case PHY_INTERFACE_MODE_RMII:
> + __set_bit(PHY_INTERFACE_MODE_RMII,
> + adapter->phylink_config.supported_interfaces);
> + adapter->phylink_config.mac_capabilities &= ~MAC_1000FD;
Some followup should take care of removing the 1000FD cap for MII as
well. Same for the LPI caps, is there a similiar limitation for MII ?
Otherwise, this patch looks good to me so,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* [PATCH net-next v2 14/15] net: stmmac: qcom-ethqos: correct prg_rclk_dly comment
From: Russell King (Oracle) @ 2026-03-27 8:44 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-stm32,
Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <acZDEg9wdjhBTHlL@shell.armlinux.org.uk>
The comment for calculating the prg_rclk_dly value is incorrect as it
omits the brackets around the divisor. Add the brackets to allow the
reader to correctly evaluate the value. Validated with the values given
in the driver.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 9dae40c27903..667676c29a95 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -450,8 +450,10 @@ static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
rgmii_setmask(ethqos, SDCC_DDR_CONFIG_EXT_PRG_RCLK_DLY_EN,
SDCC_HC_REG_DDR_CONFIG);
} else {
- /* PRG_RCLK_DLY = TCXO period * TCXO_CYCLES_CNT / 2 * RX delay ns,
- * in practice this becomes PRG_RCLK_DLY = 52 * 4 / 2 * RX delay ns
+ /* PRG_RCLK_DLY = TCXO period * TCXO_CYCLES_CNT /
+ * (2 * RX delay ns),
+ * in practice this becomes PRG_RCLK_DLY = 52 * 4 /
+ * (2 * RX delay ns)
*/
if (ethqos->has_emac_ge_3) {
/* 0.9 ns */
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 15/15] net: stmmac: qcom-ethqos: move phase_shift to register update site
From: Russell King (Oracle) @ 2026-03-27 8:44 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-stm32,
Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <acZDEg9wdjhBTHlL@shell.armlinux.org.uk>
Move the determination of the phase shift enable alongside the register
update, and make "phase_shift" unsigned.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 667676c29a95..ad3a983d2a08 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -375,14 +375,7 @@ static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
{
struct device *dev = ðqos->pdev->dev;
unsigned int prg_rclk_dly, loopback;
- int phase_shift;
-
- /* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
- if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
- ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
- phase_shift = 0;
- else
- phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
+ unsigned int phase_shift;
/* Disable loopback mode */
rgmii_clrmask(ethqos, RGMII_CONFIG2_TX_TO_RX_LOOPBACK_EN,
@@ -416,6 +409,14 @@ static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
rgmii_clrmask(ethqos, RGMII_CONFIG2_DATA_DIVIDE_CLK_SEL,
RGMII_IO_MACRO_CONFIG2);
+
+ /* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
+ if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
+ ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
+ phase_shift = 0;
+ else
+ phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
+
rgmii_updatel(ethqos, RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN, phase_shift,
RGMII_IO_MACRO_CONFIG2);
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox