* [ANN] Summer vacations and "Won't Fix" bugs
From: Alexei Starovoitov @ 2026-07-02 16:39 UTC (permalink / raw)
To: bpf, Network Development, LKML
Hi Everyone,
The summer is upon us and many BPF maintainers are going to take very
long vacations "surprisingly" at the same time during July and August.
As signs on freeways say: "Expect delays" in patch processing and
please don't spam few overloaded maintainers and reviewers.
We see a lot of AI generated patches where human took AI generated bug
finding, AI produced a patch and human sent it to the list without
much thinking since AI "bug" sounded real and AI "patch" looked legit.
This is not cool. It doesn't move the BPF project forward. It's a
wheel spin and a noise in the long run. 3 out of 4 such patches are
wrong. They consume maintainer's time and distract from real bugs and
features. Don't be the one who spreads AI slop. Submitters must
review such patches first. Use another LLM to review it and ask "Does
this need to be fixed?" If it's a race condition and the reproducer
requires adding mdelay() to the kernel the chances of hitting such a
bug are the same as HW crashing due to cosmic rays. Typical solar
flares cause more kernel crashes in the datacenter than these bugs.
These are "Won't Fix" bugs.
Similarly a patch to fix a "bug" without a reproducer is going to be
ignored, because it's a sign that AI couldn't craft a reproducer and
description of the "bug" is a hallucination. No matter how plausible
it sounds.
We see newcomers sending such AI slop to multiple subsystems at the
same time (netdev, bpf, etc). It's a red flag and a sign that the
submitter has no depth in either area. They are merely forwarding AI
to the list. Such patches are the lowest priority and might be
ignored.
Landing 100 patches to fix 100 never-in-real-life bugs is not a
success story. Lines-of-code and number-of-patches-landed is not a
metric that businesses evaluate employees over. Expect more "Won't Fix".
Maintainers are not going to help you increase these pointless metrics.
Also developers who sent 10+ patches are no longer occasional
contributors they _must_ review other patches. See
https://lore.kernel.org/bpf/CAADnVQ+TKKptnNB25V3=bcdybh5G6c2DyW2sYtXvyRaVnPN8MA@mail.gmail.com/
"As a prerequisite for merging a patch, the submitting developer is
expected to complete a comprehensive review of another developer's
patch of comparable scope and complexity."
If you don't review other patches and merely forward AI to the list
expect that your patches will be ignored.
Have a great summer.
^ permalink raw reply
* [PATCH 6.6 040/175] rxrpc: Fix the ACK parser to extract the SACK table for parsing
From: Greg Kroah-Hartman @ 2026-07-02 16:19 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Michael Bommarito, David Howells,
Marc Dionne, Jeffrey Altman, Eric Dumazet, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-afs, netdev,
stable, Sasha Levin
In-Reply-To: <20260702155115.766838875@linuxfoundation.org>
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <dhowells@redhat.com>
[ Upstream commit 333b6d5bb9f87827ac2639c737bf9613dbae7253 ]
Fix modification of the received skbuff in rxrpc_input_soft_acks() and a
potential incorrect access of the buffer in a fragmented UDP packet (the
packet would probably have to be deliberately pre-generated as fragmented)
when AF_RXRPC tries to extract the contents of the SACK table by copying
out the contents of the SACK table into a buffer before attempting to parse
AF_RXRPC assumes that it can just call skb_condense() and then validly
access the SACK table from skb->data and that it will be a flat buffer -
but skb_condense() can silently fail to do anything under some
circumstances.
Note that whilst rxrpc_input_soft_acks() should be able to parse extended
ACKs, the rest of AF_RXRPC doesn't currently support that.
Further, there's then no need to call skb_condense() in rxrpc_input_ack(),
so don't.
Fixes: d57a3a151660 ("rxrpc: Save last ACK's SACK table rather than marking txbufs")
Reported-by: Michael Bommarito <michael.bommarito@gmail.com>
Link: https://lore.kernel.org/r/20260513180907.2061972-1-michael.bommarito@gmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org
Link: https://patch.msgid.link/105362.1780573560@warthog.procyon.org.uk
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rxrpc/input.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -781,7 +781,18 @@ static void rxrpc_input_soft_acks(struct
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
unsigned int i, old_nacks = 0;
rxrpc_seq_t lowest_nak = seq + sp->nr_acks;
- u8 *acks = skb->data + sizeof(struct rxrpc_wire_header) + sizeof(struct rxrpc_ackpacket);
+ u8 sack[256] __aligned(sizeof(unsigned long));
+ u8 *acks = sack;
+
+ /* Extract the SACK table into a flat buffer rather than accessing it
+ * directly through skb->data, which is not guaranteed to be linear for
+ * a fragmented packet (skb_condense() can silently fail to linearise
+ * it).
+ */
+ if (skb_copy_bits(skb,
+ sizeof(struct rxrpc_wire_header) + sizeof(struct rxrpc_ackpacket),
+ sack, umin(sp->nr_acks, sizeof(sack))) < 0)
+ return;
for (i = 0; i < sp->nr_acks; i++) {
if (acks[i] == RXRPC_ACK_TYPE_ACK) {
^ permalink raw reply
* [PATCH net-next] selftests: drv-net: rss_ctx: Add retries to test_rss_context_overlap to reduce flakes
From: Zinc Lim @ 2026-07-02 16:49 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan
Cc: zinclim, Zinc Lim, netdev, linux-kselftest, linux-kernel
Similar to commit 690043b95c18 ("selftests: drv-net: rss: Add
retries to test_rss_key_indir to reduce flakes"), implement the
retry mechanism for test_rss_context_overlap. This gives the test
more attempts to distribute the flow evenly, as the chance of
flow skewing to one queue is high.
Example failures:
# Check failed 5288 < 7000 traffic on main context (1/2): [2727, 2561, 8961, 6648]
not ok 1 rss_ctx.test_rss_context_overlap
# Check failed 6710 < 7000 traffic on main context (2/2): [9280, 5217, 5358, 1352]
not ok 1 rss_ctx.test_rss_context_overlap
Ran test_rss_context_overlap and test_rss_context_overlap2
over 1,000 consecutive runs with no failures.
Signed-off-by: Zinc Lim <limzhineng2@gmail.com>
---
| 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--git a/tools/testing/selftests/drivers/net/hw/rss_ctx.py b/tools/testing/selftests/drivers/net/hw/rss_ctx.py
index f36f76d6ca59..5b25fa89c629 100755
--- a/tools/testing/selftests/drivers/net/hw/rss_ctx.py
+++ b/tools/testing/selftests/drivers/net/hw/rss_ctx.py
@@ -651,9 +651,14 @@ def test_rss_context_overlap(cfg, other_ctx=0):
ntuple = defer(ethtool, f"-N {cfg.ifname} delete {ntuple_id}")
# Test the main context
- cnts = _get_rx_cnts(cfg)
- GenerateTraffic(cfg, port=port).wait_pkts_and_stop(20000)
- cnts = _get_rx_cnts(cfg, prev=cnts)
+ attempts = 3
+ for attempt in range(attempts):
+ cnts = _get_rx_cnts(cfg)
+ GenerateTraffic(cfg, port=port).wait_pkts_and_stop(20000)
+ cnts = _get_rx_cnts(cfg, prev=cnts)
+ if sum(cnts[:2]) >= 7000 and sum(cnts[2:4]) >= 7000:
+ break
+ ksft_pr(f"Skewed queue distribution, attempt {attempt + 1}/{attempts}: " + str(cnts))
ksft_ge(sum(cnts[ :4]), 20000, "traffic on main context: " + str(cnts))
ksft_ge(sum(cnts[ :2]), 7000, "traffic on main context (1/2): " + str(cnts))
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH RFC 3/8] clk: sunxi-ng: a733: Add PRCM CCU
From: Enzo Adriano @ 2026-07-02 16:59 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-3-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Register check for the PRCM driver against the public A733 User Manual
V0.92, chapter 4.2.5: all 41 entries I could extract (13 reset-map
entries, 18 bus gates, 10 mod/mux clocks) match the manual's register
offsets and bit positions. No discrepancies found in this patch.
For what it's worth, we have also exercised the R-domain at runtime on a
Radxa Cubie A7S (r-ahb/r-apb0 rates with live consumers on r-pinctrl,
r-rtc and the PPU, bus-r-cpucfg via its critical flag), with no
misbehavior attributable to the PRCM model.
Thanks,
Enzo
^ permalink raw reply
* [PATCH net-next v3] net: skb: isolate skb data area allocations into a separate bucket
From: Pedro Falcato @ 2026-07-02 17:07 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Jason Xing, Kuniyuki Iwashima, netdev, linux-kernel,
linux-hardening, Pedro Falcato, Kees Cook
SKB data area allocations (as done from alloc_skb()) use kmalloc().
These allocations can be variably sized and their contents can be more
or less controlled from userspace, which makes them useful for attackers
that want to overwrite a use-after-free'd object from the same kmalloc slab
(which often just requires the sizes to roughly match into the same kmalloc
bucket). [0] is an easy example of an exploit that uses netlink skb
allocation to target another similarly-sized accidentally freed object.
While other mitigations like CONFIG_RANDOM_KMALLOC_CACHES exist, these are
probabilistic. Use the existing kmem buckets API to further isolate these
allocations in a guaranteed fashion, when CONFIG_SLAB_BUCKETS=y.
Link: https://github.com/google/security-research/blob/master/pocs/linux/kernelctf/CVE-2023-4207_lts_cos_mitigation_2/docs/exploit.md [0]
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Pedro Falcato <pfalcato@suse.de>
---
v3:
- rebase on net-next and resend
net/core/skbuff.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 18dabb4e9cfa..9dc5a8548681 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -586,6 +586,8 @@ struct sk_buff *napi_build_skb(void *data, unsigned int frag_size)
}
EXPORT_SYMBOL(napi_build_skb);
+static kmem_buckets *skb_data_buckets __ro_after_init;
+
static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
{
if (!gfp_pfmemalloc_allowed(flags))
@@ -593,7 +595,8 @@ static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
if (!obj_size)
return kmem_cache_alloc_node(net_hotdata.skb_small_head_cache,
flags, node);
- return kmalloc_node_track_caller(obj_size, flags, node);
+ return kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
+ flags, node);
}
/*
@@ -634,7 +637,7 @@ static void *kmalloc_reserve(unsigned int *size, gfp_t flags, int node,
* Try a regular allocation, when that fails and we're not entitled
* to the reserves, fail.
*/
- obj = kmalloc_node_track_caller(obj_size,
+ obj = kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
flags | __GFP_NOMEMALLOC | __GFP_NOWARN,
node);
if (likely(obj))
@@ -5215,6 +5218,7 @@ void __init skb_init(void)
0,
SKB_SMALL_HEAD_HEADROOM,
NULL);
+ skb_data_buckets = kmem_buckets_create("skb_data", SLAB_PANIC, 0, INT_MAX, NULL);
skb_extensions_init();
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC 4/8] clk: sunxi-ng: a733: Add PLL clocks support
From: Enzo Adriano @ 2026-07-02 17:10 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-4-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Register check for the PLLs against the public A733 User Manual V0.92:
13 of the 14 PLL control registers match the manual's offsets
(PLL_DDR 0x0020 through PLL_DE 0x02E0, section 4.1.6.1 onwards).
The one exception is pll-ref at 0x0000: the manual's CCU register list
starts at 0x0020 (PLL_DDR), so the PLL_REF control register is not in
the public V0.92 document. It does match the vendor kernel's CCU
(SUN60IW2_PLL_REF_CTRL_REG 0x0000), so a short provenance note near the
definition might help future readers, same as for the other
vendor-sourced entries discussed in this thread. For what it's worth,
on a Radxa Cubie A7S (26 MHz DCXO) we can confirm at runtime that
pll-ref produces the normalized 24 MHz reference with the hosc-side
clocks reading 26 MHz, so the modeling demonstrably works on hardware.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH net-next] ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DA
From: Andrew Lunn @ 2026-07-02 17:11 UTC (permalink / raw)
To: Siddaraju DH
Cc: Michal Kubecek, Maxime Chevallier, kuba, netdev, Shubham Das,
Balaji Chintalapalle, Vijay Srinivasan, Magnus Lindberg,
Niklas Damberg, Jonas Wirandi, Siddaraju DH
In-Reply-To: <20260702145326.1024800-1-siddaraju.dh@intel.com>
On Thu, Jul 02, 2026 at 08:23:26PM +0530, Siddaraju DH wrote:
> Add comment to clarify the physical media 10000baseCR follows.
>
> 10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD.
> It has no autonegotiation, no link training, and no mandatory FEC.
> The industry standard for this media type is SFF-8431 Appendix-E
> Direct Attach cable, also known as 10G_SFI_DA.
>
> This change follows the conversation from netdev mail thread with
> subject: "the confusing 10000base_CR. Shouldn't it be 10000_SFI_DA?"
Please add a link to lore, it makes it a lot easier to get to the
discussion.
Link: https://lore.kernel.org/r/[Message-ID]
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH ethtool] man: ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DA
From: Andrew Lunn @ 2026-07-02 17:12 UTC (permalink / raw)
To: D H, Siddaraju
Cc: Michal Kubecek, Maxime Chevallier, netdev, Shubham Das,
Balaji Chintalapalle, Vijay Srinivasan, Magnus Lindberg,
Niklas Damberg, Jonas Wirandi, Siddaraju DH
In-Reply-To: <20260702145002.1024439-1-siddaraju.dh@intel.com>
On Thu, Jul 02, 2026 at 08:20:02PM +0530, D H, Siddaraju wrote:
> From: Siddaraju DH <siddaraju.dh@intel.com>
>
> Annotate the 10000baseCR entry in the advertise mask table so users
> understand what physical media this mode it actually represents.
>
> 10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD.
> It has no autonegotiation, no link training, and no mandatory FEC.
> The industry standard for this media type is SFF-8431 Appendix-E
> Direct Attach cable, also known as 10G_SFI_DA.
>
> This change follows the conversation from netdev mail thread with
> subject: "the confusing 10000base_CR. Shouldn't it be 10000_SFI_DA?"
>
> Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net] net/smc: ignore peer-supplied rmbe_idx and dmbe_idx
From: Dust Li @ 2026-07-02 17:11 UTC (permalink / raw)
To: D. Wythe, Dust Li, Sidraya Jayagond, Wenjia Zhang,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Mahanta Jambigi, Tony Lu, Wen Gu, Simon Horman, Ursula Braun,
Hans Wippel, linux-rdma, linux-s390, netdev, linux-kernel, stable
Linux always uses exactly one RMBE per RMB (index 1 for SMC-R) and
one DMBE per DMB (index 0 for SMC-D), so conn->tx_off is always zero.
Hardcode these fixed values instead of deriving tx_off from the
peer-supplied rmbe_idx / dmbe_idx in the CLC Accept/Confirm message.
Fixes: e6727f39004b ("smc: send data (through RDMA)")
Fixes: 413498440e30 ("net/smc: add SMC-D support in af_smc")
Cc: stable@vger.kernel.org
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Signed-off-by: Dust Li <dust.li@linux.alibaba.com>
---
net/smc/af_smc.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index b5db69073e20..3706e8ac49e0 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -729,11 +729,15 @@ static void smcr_conn_save_peer_info(struct smc_sock *smc,
{
int bufsize = smc_uncompress_bufsize(clc->r0.rmbe_size);
- smc->conn.peer_rmbe_idx = clc->r0.rmbe_idx;
+ /* Linux uses exactly one RMBE per RMB (always index 1); ignore the
+ * peer-supplied rmbe_idx to prevent a malicious peer from setting an
+ * out-of-bounds tx_off.
+ */
+ smc->conn.peer_rmbe_idx = 1;
smc->conn.local_tx_ctrl.token = ntohl(clc->r0.rmbe_alert_token);
smc->conn.peer_rmbe_size = bufsize;
atomic_set(&smc->conn.peer_rmbe_space, smc->conn.peer_rmbe_size);
- smc->conn.tx_off = bufsize * (smc->conn.peer_rmbe_idx - 1);
+ smc->conn.tx_off = 0;
}
static void smcd_conn_save_peer_info(struct smc_sock *smc,
@@ -741,12 +745,16 @@ static void smcd_conn_save_peer_info(struct smc_sock *smc,
{
int bufsize = smc_uncompress_bufsize(clc->d0.dmbe_size);
- smc->conn.peer_rmbe_idx = clc->d0.dmbe_idx;
+ /* Linux uses exactly one DMBE per DMB (always index 0); ignore the
+ * peer-supplied dmbe_idx to prevent a malicious peer from deriving an
+ * out-of-bounds tx_off that causes an OOB write.
+ */
+ smc->conn.peer_rmbe_idx = 0;
smc->conn.peer_token = ntohll(clc->d0.token);
/* msg header takes up space in the buffer */
smc->conn.peer_rmbe_size = bufsize - sizeof(struct smcd_cdc_msg);
atomic_set(&smc->conn.peer_rmbe_space, smc->conn.peer_rmbe_size);
- smc->conn.tx_off = bufsize * smc->conn.peer_rmbe_idx;
+ smc->conn.tx_off = 0;
}
static void smc_conn_save_peer_info(struct smc_sock *smc,
--
2.43.7
^ permalink raw reply related
* [PATCH net v3] net: airoha: fix MIB stats collection to be lossless
From: Aniket Negi @ 2026-07-02 17:18 UTC (permalink / raw)
To: lorenzo, netdev
Cc: Aniket Negi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-arm-kernel, linux-mediatek,
linux-kernel
The current driver resets hardware MIB counters after every read via
REG_FE_GDM_MIB_CLEAR. This creates a race window: packets arriving
between the read and the clear are silently lost from statistics.
Fix this by removing the MIB clear and switching to a delta-based
software tracking approach:
- 64-bit H+L registers (tx/rx ok pkts, ok bytes, E64..L1023):
read the absolute hardware total directly each poll.
- 32-bit registers (drops, bc, mc, errors, runt, long, ...):
store the previous raw register value in mib_prev and accumulate
(u32)(curr - prev) into a 64-bit software counter. Unsigned
subtraction handles wrap-around transparently.
- tx_len[0]/rx_len[0] ({0,64} RMON bucket) combines RUNT_CNT
(32-bit, delta-tracked via mib_prev.tx_runt) and E64_CNT
(64-bit, absolute). A u64 accumulator tx_runt64 holds the
running RUNT delta sum so that each poll sets:
tx_len[0] = tx_runt64 + E64_abs
without double-counting the E64 value.
Merge airoha_dev_get_hw_stats() into airoha_update_hw_stats(),
moving the port spin_lock inside so callers do not need a separate
wrapper.
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Aniket Negi <aniket.negi03@gmail.com>
---
Changes in v3:
- Link to V2: https://lore.kernel.org/20260701173941.314795-1-aniket.negi03@gmail.com/
- Add Acked-by tag from Lorenzo
- Rename from tx_runt_cnt to tx_runt, tx_long_cnt to tx_long,
tx_runt_accum64 to tx_runt64
- Rename from rx_runt_cnt to rx_runt, rx_long_cnt to rx_long,
rx_runt_accum64 to rx_runt64
- Condense the marked comments in V2, remove new line after comment
Changes in v2:
- Store _CNT_L register reads in val before adding to stats, improving
readability (suggested by Lorenzo Bianconi)
- Fix double-counting bug in the RUNT+E64 combined bucket: previously
"+=" for E64 re-added the full absolute counter each poll; now a
dedicated tx_runt_accum64/rx_runt_accum64 accumulator holds the
running RUNT delta, and tx_len[0] is assigned (not accumulated) each
poll as runt_accum64 + E64_abs
- Replace 7-element tx_len[]/rx_len[] shadow arrays in mib_prev with
focused tx_runt_cnt/tx_long_cnt and rx_runt_cnt/rx_long_cnt fields;
only RUNT and LONG are 32-bit and need wrap-around tracking
- Rename inner struct hw_prev_stats to mib_prev; rename accumulator
fields to tx_runt_accum64/rx_runt_accum64 for clarity
- Fix comment alignment in mib_prev struct block
- Rename airoha_dev_get_hw_stats() to airoha_update_hw_stats() and
move the port spin_lock inside, removing the separate wrapper
drivers/net/ethernet/airoha/airoha_eth.c | 107 ++++++++++++-----------
drivers/net/ethernet/airoha/airoha_eth.h | 27 ++++++
2 files changed, 84 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 59001fd4b6f7..e009266fd268 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1686,12 +1686,14 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
}
}
-static void airoha_dev_get_hw_stats(struct airoha_gdm_dev *dev)
+static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
{
struct airoha_gdm_port *port = dev->port;
struct airoha_eth *eth = dev->eth;
u32 val, i = 0;
+ spin_lock(&port->stats_lock);
+
/* Read relevant MIB for GDM with multiple port attached */
if (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)
airoha_fe_rmw(eth, REG_FE_GDM_MIB_CFG(port->id),
@@ -1701,152 +1703,157 @@ static void airoha_dev_get_hw_stats(struct airoha_gdm_dev *dev)
u64_stats_update_begin(&dev->stats.syncp);
- /* TX */
+ /* TX - 64-bit H+L registers: hw accumulates the total, read directly. */
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id));
- dev->stats.tx_ok_pkts += ((u64)val << 32);
+ dev->stats.tx_ok_pkts = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
dev->stats.tx_ok_pkts += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_H(port->id));
- dev->stats.tx_ok_bytes += ((u64)val << 32);
+ dev->stats.tx_ok_bytes = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
dev->stats.tx_ok_bytes += val;
+ /* TX - 32-bit registers: accumulate delta to handle wrap-around. */
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_DROP_CNT(port->id));
- dev->stats.tx_drops += val;
+ dev->stats.tx_drops += (u32)(val - dev->stats.mib_prev.tx_drops);
+ dev->stats.mib_prev.tx_drops = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_BC_CNT(port->id));
- dev->stats.tx_broadcast += val;
+ dev->stats.tx_broadcast += (u32)(val - dev->stats.mib_prev.tx_broadcast);
+ dev->stats.mib_prev.tx_broadcast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_MC_CNT(port->id));
- dev->stats.tx_multicast += val;
+ dev->stats.tx_multicast += (u32)(val - dev->stats.mib_prev.tx_multicast);
+ dev->stats.mib_prev.tx_multicast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_RUNT_CNT(port->id));
- dev->stats.tx_len[i] += val;
+ dev->stats.mib_prev.tx_runt64 +=
+ (u32)(val - dev->stats.mib_prev.tx_runt);
+ dev->stats.mib_prev.tx_runt = val;
+ /* tx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute). */
+ dev->stats.tx_len[i] = dev->stats.mib_prev.tx_runt64;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] += (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_L(port->id));
dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_L(port->id));
dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_L(port->id));
dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_L(port->id));
dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_H(port->id));
- dev->stats.tx_len[i] += ((u64)val << 32);
+ dev->stats.tx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_L(port->id));
dev->stats.tx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_LONG_CNT(port->id));
- dev->stats.tx_len[i++] += val;
+ dev->stats.tx_len[i++] += (u32)(val - dev->stats.mib_prev.tx_long);
+ dev->stats.mib_prev.tx_long = val;
/* RX */
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_H(port->id));
- dev->stats.rx_ok_pkts += ((u64)val << 32);
+ dev->stats.rx_ok_pkts = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_L(port->id));
dev->stats.rx_ok_pkts += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_H(port->id));
- dev->stats.rx_ok_bytes += ((u64)val << 32);
+ dev->stats.rx_ok_bytes = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_L(port->id));
dev->stats.rx_ok_bytes += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_DROP_CNT(port->id));
- dev->stats.rx_drops += val;
+ dev->stats.rx_drops += (u32)(val - dev->stats.mib_prev.rx_drops);
+ dev->stats.mib_prev.rx_drops = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_BC_CNT(port->id));
- dev->stats.rx_broadcast += val;
+ dev->stats.rx_broadcast += (u32)(val - dev->stats.mib_prev.rx_broadcast);
+ dev->stats.mib_prev.rx_broadcast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_MC_CNT(port->id));
- dev->stats.rx_multicast += val;
+ dev->stats.rx_multicast += (u32)(val - dev->stats.mib_prev.rx_multicast);
+ dev->stats.mib_prev.rx_multicast = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ERROR_DROP_CNT(port->id));
- dev->stats.rx_errors += val;
+ dev->stats.rx_errors += (u32)(val - dev->stats.mib_prev.rx_errors);
+ dev->stats.mib_prev.rx_errors = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_CRC_ERR_CNT(port->id));
- dev->stats.rx_crc_error += val;
+ dev->stats.rx_crc_error += (u32)(val - dev->stats.mib_prev.rx_crc_error);
+ dev->stats.mib_prev.rx_crc_error = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_OVERFLOW_DROP_CNT(port->id));
- dev->stats.rx_over_errors += val;
+ dev->stats.rx_over_errors += (u32)(val - dev->stats.mib_prev.rx_over_errors);
+ dev->stats.mib_prev.rx_over_errors = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_FRAG_CNT(port->id));
- dev->stats.rx_fragment += val;
+ dev->stats.rx_fragment += (u32)(val - dev->stats.mib_prev.rx_fragment);
+ dev->stats.mib_prev.rx_fragment = val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_JABBER_CNT(port->id));
- dev->stats.rx_jabber += val;
+ dev->stats.rx_jabber += (u32)(val - dev->stats.mib_prev.rx_jabber);
+ dev->stats.mib_prev.rx_jabber = val;
i = 0;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_RUNT_CNT(port->id));
- dev->stats.rx_len[i] += val;
+ dev->stats.mib_prev.rx_runt64 +=
+ (u32)(val - dev->stats.mib_prev.rx_runt);
+ dev->stats.mib_prev.rx_runt = val;
+ /* rx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute). */
+ dev->stats.rx_len[i] = dev->stats.mib_prev.rx_runt64;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] += (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_L(port->id));
dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_L(port->id));
dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_L(port->id));
dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_L(port->id));
dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_H(port->id));
- dev->stats.rx_len[i] += ((u64)val << 32);
+ dev->stats.rx_len[i] = (u64)val << 32;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_L(port->id));
dev->stats.rx_len[i++] += val;
val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_LONG_CNT(port->id));
- dev->stats.rx_len[i++] += val;
+ dev->stats.rx_len[i] += (u32)(val - dev->stats.mib_prev.rx_long);
+ dev->stats.mib_prev.rx_long = val;
u64_stats_update_end(&dev->stats.syncp);
-}
-
-static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
-{
- struct airoha_gdm_port *port = dev->port;
- int i;
-
- spin_lock(&port->stats_lock);
-
- for (i = 0; i < ARRAY_SIZE(port->devs); i++) {
- if (port->devs[i])
- airoha_dev_get_hw_stats(port->devs[i]);
- }
-
- /* Reset MIB counters */
- airoha_fe_set(dev->eth, REG_FE_GDM_MIB_CLEAR(port->id),
- FE_GDM_MIB_RX_CLEAR_MASK | FE_GDM_MIB_TX_CLEAR_MASK);
spin_unlock(&port->stats_lock);
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index f6d01a8e8da1..dae9cfa6cc06 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -245,6 +245,33 @@ struct airoha_hw_stats {
u64 rx_fragment;
u64 rx_jabber;
u64 rx_len[7];
+
+ struct {
+ /* Previous HW register values for 32-bit counter delta
+ * tracking. Storing the last seen value and accumulating
+ * (u32)(curr - prev) into the 64-bit software counter
+ * handles wrap-around transparently via unsigned arithmetic.
+ * tx_runt64/rx_runt64 hold the running sum of runt deltas.
+ * These fields are never reported to userspace.
+ */
+ u32 tx_drops;
+ u32 tx_broadcast;
+ u32 tx_multicast;
+ u32 tx_runt;
+ u32 tx_long;
+ u64 tx_runt64;
+ u32 rx_drops;
+ u32 rx_broadcast;
+ u32 rx_multicast;
+ u32 rx_errors;
+ u32 rx_crc_error;
+ u32 rx_over_errors;
+ u32 rx_fragment;
+ u32 rx_jabber;
+ u32 rx_runt;
+ u32 rx_long;
+ u64 rx_runt64;
+ } mib_prev;
};
enum {
base-commit: a225f8c20712713406ae47024b8df42deacddd4a
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RFC 6/8] clk: sunxi-ng: a733: Add mod clocks support
From: Enzo Adriano @ 2026-07-02 17:24 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-6-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Register check for the mod clocks in this patch against the public A733
User Manual V0.92: 88 of the 94 mod/mux clock entries match the manual's
register offsets, with the documented gating/mux/divider layout at each
offset. The six that have no register in the public manual are the set
already discussed in this thread for provenance notes - avs (0x0880),
spi4 (0x0F28), sgpio (0x1060), lpc (0x1080), gmac1-phy (0x1420) - plus
one more: tcon-lcd2 (0x1510); the manual only documents VO0_TCONLCD0
(0x1500) and VO0_TCONLCD1 (0x1508).
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH v2 net-next 07/14] net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC
From: Maxime Chevallier @ 2026-07-02 17:30 UTC (permalink / raw)
To: wei.fang, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, kuba, pabeni, linux, wei.fang,
chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-8-wei.fang@oss.nxp.com>
Hi,
On 7/2/26 04:57, wei.fang@oss.nxp.com wrote:
> From: Claudiu Manoil <claudiu.manoil@nxp.com>
>
> The ENETC pseudo-MACs are proprietary internal links that do not
> implement any standard MII interface, so restrict their supported PHY
> interface modes to PHY_INTERFACE_MODE_INTERNAL only.
>
> Since pseudo-MACs can operate at any speed between 10Mbps and 25Gbps
> in multiples of 10Mbps, set their MAC capabilities to cover the full
> range of standard full-duplex speeds: 10/100/1000/2500/5000/10000/
> 20000/25000 Mbps.
>
> For standalone ENETC, expand the supported interface modes to include
> 10GBASER and XGMII in addition to the existing RGMII, SGMII, 1000BASEX,
> 2500BASEX and USXGMII modes, with MAC capabilities up to 10G. MAC_1000
> is replaced with MAC_1000FD to explicitly exclude 1000M half-duplex,
> which is not supported.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH v2 net-next 06/14] net: enetc: simplify enetc4_set_port_speed()
From: Maxime Chevallier @ 2026-07-02 17:32 UTC (permalink / raw)
To: wei.fang, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, kuba, pabeni, linux, wei.fang,
chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-7-wei.fang@oss.nxp.com>
On 7/2/26 04:57, wei.fang@oss.nxp.com wrote:
> From: Wei Fang <wei.fang@nxp.com>
>
> Since phylink only passes valid speed values to mac_link_up, the switch
> statement with its default fallback to SPEED_10 is unnecessary. Replace
> it with a direct call to PCR_PSPEED_VAL(). Also update PCR_PSPEED_VAL()
> to use FIELD_PREP() for proper field masking instead of an open-coded
> shift.
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH RFC 7/8] clk: sunxi-ng: a733: Add bus clock gates
From: Enzo Adriano @ 2026-07-02 17:34 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-7-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Following Andre's suggestion I went through the bus gates in this patch
and compared every register offset and bit position against the public
A733 User Manual V0.92. Findings below; everything not listed matched
the manual (122 of the 135 gate entries verified clean).
1) UART1-UART6 gate bits look wrong:
> +static SUNXI_CCU_GATE_HWS(bus_uart1_clk, "bus-uart1", apb_uart_hws, 0xe04, BIT(1), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart2_clk, "bus-uart2", apb_uart_hws, 0xe08, BIT(2), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart3_clk, "bus-uart3", apb_uart_hws, 0xe0c, BIT(3), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart4_clk, "bus-uart4", apb_uart_hws, 0xe10, BIT(4), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart5_clk, "bus-uart5", apb_uart_hws, 0xe14, BIT(5), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart6_clk, "bus-uart6", apb_uart_hws, 0xe18, BIT(6), 0);
Each UART has its own BGR register, and in every one of them the
gating bit is bit 0. Manual section 4.1.6.141 (0x0E04 UART1 Bus Gating
Reset Register): bit 16 "UART1_RST", bits 15:1 reserved ("/"), bit 0
"UART1_GATING - Gating Clock for UART1, 0: Mask, 1: Pass". Sections
4.1.6.142-4.1.6.146 have the same layout for UART2-UART6. So these six
entries should all use BIT(0); as written, enabling any of bus-uart1..6
sets a reserved bit and the UART clock stays gated. (bus-uart0 at 0xe00
BIT(0) and the uartN resets at bit 16 all match the manual.)
2) SYSDAP gate offset looks wrong:
> +static SUNXI_CCU_GATE_HWS(bus_sysdap_clk, "bus-sysdap", apb1_hws,
> + 0x88c, BIT(0), 0);
Manual section 4.1.6.92 puts SYSDAP_BGR_REG at 0x07AC (bit 16
"SYSDAP_RST", bit 0 "SYSDAP_GATING"), and patch 8/8's reset map already
uses { 0x7ac, BIT(16) } for RST_BUS_SYSDAP, so the gate here presumably
wants 0x7ac as well. There is no CCU register at 0x88C in the manual.
3) Gates without a register in the public manual (V0.92) - these could
use a short provenance note near the entry, as discussed for other IDs:
- bus-spi4 (0x0F2C)
- bus-sgpio (0x1064)
- bus-lpc (0x1084)
- bus-gmac1 (0x142C) [same question as the GMAC1 clock IDs]
- bus-tcon-lcd2 (0x1514, and the tcon-lcd2 mod clock at 0x1510) - the
manual documents only VO0_TCONLCD0 (0x1500/0x1504) and VO0_TCONLCD1
(0x1508/0x150C)
- mbus-gmac1 (0x05E4 bit 12) - bit 12 is not described in the MBUS
Gate Enable Register section
The remaining bus/mbus gate entries in this patch all match the manual's
offsets and bit positions.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH v2 net-next 08/14] net: enetc: remove invalid code from enetc4_pl_mac_link_up()
From: Maxime Chevallier @ 2026-07-02 17:35 UTC (permalink / raw)
To: wei.fang, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, kuba, pabeni, linux, wei.fang,
chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-9-wei.fang@oss.nxp.com>
On 7/2/26 04:57, wei.fang@oss.nxp.com wrote:
> From: Wei Fang <wei.fang@nxp.com>
>
> When adding phylink MAC operations support to the NETC switch driver,
> Russell King pointed out several pieces of invalid logic in the
> .mac_link_up() implementation (see [1] and [2]):
>
> 1) Half-duplex backpressure is not supported by the kernel, Ethernet
> relies on packet dropping for congestion management.
>
> 2) phylink_autoneg_inband() is unnecessary, as RGMII in-band status is
> not supported.
>
> 3) TX and RX pause are disabled in half-duplex mode, so there is no
> need to override them in .mac_link_up().
>
> The same invalid logic is also present in enetc4_pl_mac_link_up(), so
> remove the invalid code from it.
>
> Link: https://lore.kernel.org/imx/acEIQqI-_oyCym8O@shell.armlinux.org.uk/ # 1
> Link: https://lore.kernel.org/imx/acEFwqmAvWls_9Ef@shell.armlinux.org.uk/ # 2
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH net 1/4] afs: Fix NULL deref in afs_deliver_cb_init_call_back_state3()
From: Jeffrey E Altman @ 2026-07-02 17:31 UTC (permalink / raw)
To: David Howells, netdev
Cc: Marc Dionne, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, linux-afs, linux-kernel, stable
In-Reply-To: <20260702144919.172295-2-dhowells@redhat.com>
On 7/2/2026 10:49 AM, David Howells wrote:
> Fix afs_deliver_cb_init_call_back_state3() to avoid a potential NULL deref
> should call->server be NULL (ie. afs_rx_new_call() failed to find a
> matching server record) when it checks the server's UUID.
>
> Fixes: 40e8b52fe8c8 ("afs: Use the per-peer app data provided by rxrpc")
> Link: https://sashiko.dev/#/patchset/20260624163819.3017002-1-dhowells%40redhat.com
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marc Dionne <marc.dionne@auristor.com>
> cc: Jeffrey Altman <jaltman@auristor.com>
> cc: Eric Dumazet <edumazet@google.com>
> cc: "David S. Miller" <davem@davemloft.net>
> cc: Jakub Kicinski <kuba@kernel.org>
> cc: Paolo Abeni <pabeni@redhat.com>
> cc: Simon Horman <horms@kernel.org>
> cc: linux-afs@lists.infradead.org
> cc: stable@kernel.org
> ---
> fs/afs/cmservice.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/afs/cmservice.c b/fs/afs/cmservice.c
> index 5540ae1cad59..d579a665e3da 100644
> --- a/fs/afs/cmservice.c
> +++ b/fs/afs/cmservice.c
> @@ -364,7 +364,8 @@ static int afs_deliver_cb_init_call_back_state3(struct afs_call *call)
> if (!afs_check_call_state(call, AFS_CALL_SV_REPLYING))
> return afs_io_error(call, afs_io_error_cm_reply);
>
> - if (memcmp(call->request, &call->server->_uuid, sizeof(call->server->_uuid)) != 0) {
> + if (call->server &&
> + memcmp(call->request, &call->server->_uuid, sizeof(call->server->_uuid)) != 0) {
> pr_notice("Callback UUID does not match fileserver UUID\n");
> trace_afs_cm_no_server_u(call, call->request);
> return 0;
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: usb: move updating filter and status from cdc to usbnet
From: Manuel Ebner @ 2026-07-02 17:59 UTC (permalink / raw)
To: Oliver Neukum, andrew+netdev, davem, edumazet, kuba, pabeni,
shaoxul, netdev, linux-usb, linux-kernel
In-Reply-To: <20260702143142.890654-2-oneukum@suse.com>
Hi,
I have a couple suggestions for you patch. Some parts are
weird to read - it could also be that my perception today is off.
On Thu, 2026-07-02 at 16:25 +0200, Oliver Neukum wrote:
> These helpers are used by multiple drivers and do not depend
"and do not only depend on cdc core. They also depend on
other cdc drivers."
is this better?
> on the rest of cdc. Leavin them in a cdc driver means that
/Leavin/Leaving/
> more drivers are loaded just for infrastructure, not hardware
just for the support of other drivers, not their hardware.
> support.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
> drivers/net/usb/cdc_ether.c | 75 ------------------------------------
> drivers/net/usb/usbnet.c | 76 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 76 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
> index a0a5740590b9..b4df32e18461 100644
> --- a/drivers/net/usb/cdc_ether.c
> +++ b/drivers/net/usb/cdc_ether.c
> @@ -63,35 +63,6 @@ static const u8 mbm_guid[16] = {
> 0xa6, 0x07, 0xc0, 0xff, 0xcb, 0x7e, 0x39, 0x2a,
> };
>
> -void usbnet_cdc_update_filter(struct usbnet *dev)
> -{
> - struct net_device *net = dev->net;
> -
> - u16 cdc_filter = USB_CDC_PACKET_TYPE_DIRECTED
> - | USB_CDC_PACKET_TYPE_BROADCAST;
> -
> - /* filtering on the device is an optional feature and not worth
> - * the hassle so we just roughly care about snooping and if any
> - * multicast is requested, we take every multicast
> - */
> - if (net->flags & IFF_PROMISC)
> - cdc_filter |= USB_CDC_PACKET_TYPE_PROMISCUOUS;
> - if (!netdev_mc_empty(net) || (net->flags & IFF_ALLMULTI))
> - cdc_filter |= USB_CDC_PACKET_TYPE_ALL_MULTICAST;
> -
> - usb_control_msg(dev->udev,
> - usb_sndctrlpipe(dev->udev, 0),
> - USB_CDC_SET_ETHERNET_PACKET_FILTER,
> - USB_TYPE_CLASS | USB_RECIP_INTERFACE,
> - cdc_filter,
> - dev->intf->cur_altsetting->desc.bInterfaceNumber,
> - NULL,
> - 0,
> - USB_CTRL_SET_TIMEOUT
> - );
> -}
> -EXPORT_SYMBOL_GPL(usbnet_cdc_update_filter);
> -
> /* We need to override usbnet_*_link_ksettings in bind() */
> static const struct ethtool_ops cdc_ether_ethtool_ops = {
> .get_link = usbnet_get_link,
> @@ -400,52 +371,6 @@ EXPORT_SYMBOL_GPL(usbnet_cdc_unbind);
> * (by Brad Hards) talked with, with more functionality.
> */
>
> -static void speed_change(struct usbnet *dev, __le32 *speeds)
> -{
> - dev->tx_speed = __le32_to_cpu(speeds[0]);
> - dev->rx_speed = __le32_to_cpu(speeds[1]);
> -}
> -
> -void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
> -{
> - struct usb_cdc_notification *event;
> -
> - if (urb->actual_length < sizeof(*event))
> - return;
> -
> - /* SPEED_CHANGE can get split into two 8-byte packets */
> - if (test_and_clear_bit(EVENT_STS_SPLIT, &dev->flags)) {
> - speed_change(dev, (__le32 *) urb->transfer_buffer);
> - return;
> - }
> -
> - event = urb->transfer_buffer;
> - switch (event->bNotificationType) {
> - case USB_CDC_NOTIFY_NETWORK_CONNECTION:
> - netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
> - event->wValue ? "on" : "off");
> - if (netif_carrier_ok(dev->net) != !!event->wValue)
> - usbnet_link_change(dev, !!event->wValue, 0);
> - break;
> - case USB_CDC_NOTIFY_SPEED_CHANGE: /* tx/rx rates */
> - netif_dbg(dev, timer, dev->net, "CDC: speed change (len %d)\n",
> - urb->actual_length);
> - if (urb->actual_length != (sizeof(*event) + 8))
> - set_bit(EVENT_STS_SPLIT, &dev->flags);
> - else
> - speed_change(dev, (__le32 *) &event[1]);
> - break;
> - /* USB_CDC_NOTIFY_RESPONSE_AVAILABLE can happen too (e.g. RNDIS),
> - * but there are no standard formats for the response data.
> - */
> - default:
> - netdev_err(dev->net, "CDC: unexpected notification %02x!\n",
> - event->bNotificationType);
> - break;
> - }
> -}
> -EXPORT_SYMBOL_GPL(usbnet_cdc_status);
> -
> int usbnet_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
> {
> int status;
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 25518635b7b7..5544af1f4aa5 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -22,6 +22,7 @@
> #include <linux/init.h>
> #include <linux/netdevice.h>
> #include <linux/etherdevice.h>
> +#include <linux/usb/cdc.h>
why do you put it there?
it could be alphabetical instead.
> #include <linux/ctype.h>
> #include <linux/ethtool.h>
> #include <linux/workqueue.h>
> @@ -2271,6 +2272,81 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8
> reqtype,
>
> }
> EXPORT_SYMBOL_GPL(usbnet_write_cmd_async);
> +
> +void usbnet_cdc_update_filter(struct usbnet *dev)
> +{
> + struct net_device *net = dev->net;
> +
> + u16 cdc_filter = USB_CDC_PACKET_TYPE_DIRECTED
> + | USB_CDC_PACKET_TYPE_BROADCAST;
> +
Multi-line-comments in coding-style:
/*
* filtering on ..
> + /* filtering on the device is an optional feature and not worth
> + * the hassle so we just roughly care about snooping and if any
> + * multicast is requested, we take every multicast
, we take that multicast.
also that's a pretty long sentence.
> + */
> + if (net->flags & IFF_PROMISC)
> + cdc_filter |= USB_CDC_PACKET_TYPE_PROMISCUOUS;
> + if (!netdev_mc_empty(net) || (net->flags & IFF_ALLMULTI))
> + cdc_filter |= USB_CDC_PACKET_TYPE_ALL_MULTICAST;
> +
> + usb_control_msg(dev->udev,
> + usb_sndctrlpipe(dev->udev, 0),
> + USB_CDC_SET_ETHERNET_PACKET_FILTER,
> + USB_TYPE_CLASS | USB_RECIP_INTERFACE,
> + cdc_filter,
> + dev->intf->cur_altsetting->desc.bInterfaceNumber,
> + NULL,
> + 0,
> + USB_CTRL_SET_TIMEOUT
> + );
> +}
> +EXPORT_SYMBOL_GPL(usbnet_cdc_update_filter);
> +
> +static void speed_change(struct usbnet *dev, __le32 *speeds)
> +{
> + dev->tx_speed = __le32_to_cpu(speeds[0]);
> + dev->rx_speed = __le32_to_cpu(speeds[1]);
> +}
> +
> +void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
> +{
> + struct usb_cdc_notification *event;
> +
> + if (urb->actual_length < sizeof(*event))
> + return;
> +
> + /* SPEED_CHANGE can get split into two 8-byte packets */
> + if (test_and_clear_bit(EVENT_STS_SPLIT, &dev->flags)) {
> + speed_change(dev, (__le32 *)urb->transfer_buffer);
> + return;
> + }
> +
> + event = urb->transfer_buffer;
> + switch (event->bNotificationType) {
> + case USB_CDC_NOTIFY_NETWORK_CONNECTION:
> + netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
> + event->wValue ? "on" : "off");
> + if (netif_carrier_ok(dev->net) != !!event->wValue)
> + usbnet_link_change(dev, !!event->wValue, 0);
> + break;
> + case USB_CDC_NOTIFY_SPEED_CHANGE: /* tx/rx rates */
> + netif_dbg(dev, timer, dev->net, "CDC: speed change (len %d)\n",
> + urb->actual_length);
> + if (urb->actual_length != (sizeof(*event) + 8))
> + set_bit(EVENT_STS_SPLIT, &dev->flags);
> + else
> + speed_change(dev, (__le32 *)&event[1]);
> + break;
/*
* USB ..
> + /* USB_CDC_NOTIFY_RESPONSE_AVAILABLE can happen too (e.g. RNDIS),
> + * but there are no standard formats for the response data.
> + */
> + default:
> + netdev_err(dev->net, "CDC: unexpected notification %02x!\n",
> + event->bNotificationType);
> + break;
> + }
> +}
> +EXPORT_SYMBOL_GPL(usbnet_cdc_status);
> /*-------------------------------------------------------------------------*/
>
> static int __init usbnet_init(void)
You can add my
Reviewed-by: Manuel Ebner <manuelebner@mailbox.org>
Thanks
Manuel
^ permalink raw reply
* Re: [PATCH net 1/2] octeon_ep: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:03 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: Veerasenareddy Burru, Sathesh Edara, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <akUWzu9VjN5WEoJH@boxer>
Thanks Maciej. v2 addresses your comments. The check now runs before the
skb is built in both drivers. I kept octep_oq_drop_rx() as is, since it
derives data_len itself. The octeon_ep_vf dedup is left for net-next.
One more thing. The drop path does not free the dropped packet's pages. It
unmaps them but never calls put_page(). This is not new. The build_skb
failure path leaks the same way. But v2 makes the leak reachable from an
oversized packet. I will send a separate patch for it.
Thanks,
Maoyi
^ permalink raw reply
* Re: [PATCH net] net/tls: Consume empty data records in tls_sw_read_sock()
From: Sabrina Dubroca @ 2026-07-02 18:05 UTC (permalink / raw)
To: Chuck Lever; +Cc: john.fastabend, kuba, davem, edumazet, pabeni, horms, netdev
In-Reply-To: <20260630191551.875664-1-cel@kernel.org>
2026-06-30, 15:15:51 -0400, Chuck Lever wrote:
> A peer may send a zero-length TLS application_data record; TLS 1.3
> explicitly permits these as a traffic-analysis countermeasure (RFC
> 8446, Section 5.1). After decryption such a record has full_len ==
> 0. tls_sw_read_sock() hands it to the read_actor, which has no
> payload to consume and returns zero. The loop treats a zero return
> as backpressure (used <= 0), requeues the skb at the head of
> rx_list, and stops. rx_list is serviced head-first on the next
> call, so the empty record is dequeued, fails the same way, and is
> requeued again; every later record on the connection is blocked
> behind it.
>
> tls_sw_recvmsg() does not stall on this: a zero-length data record
> copies nothing and falls through to consume_skb(). Mirror that in
> the read_sock() path by recognizing an empty data record before
> the actor runs, consuming it, and continuing.
>
> Fixes: 662fbcec32f4 ("net/tls: implement ->read_sock()")
> Signed-off-by: Chuck Lever <cel@kernel.org>
> ---
> net/tls/tls_sw.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
I think tls_sw_splice_read() suffers from a similar issue (returning 0
even though more data may be available). Sashiko agrees, and also
found a few more pre-existing issues.
--
Sabrina
^ permalink raw reply
* [PATCH net v2 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:05 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel
Both octeon_ep and octeon_ep_vf build an skb for a multi-buffer RX packet
by adding one fragment per buffer_size chunk of a device-reported length.
Neither bounds the count against MAX_SKB_FRAGS. A long packet yields about
18 fragments, one past the default MAX_SKB_FRAGS of 17, so
skb_add_rx_frag() writes past shinfo->frags[].
Each driver now checks the fragment count before it builds the skb and
drops a packet that would not fit.
v2:
- move the check before (napi_)build_skb() so the driver does not build an
skb only to free it, per Maciej Fijalkowski.
- the frag count check uses the same u16 length the fragment loop uses.
The repeated linear/non-linear code in octeon_ep_vf that Maciej noted is a
separate cleanup, left for net-next to keep this fix minimal.
v1: https://lore.kernel.org/r/20260701112825.1653044-1-maoyixie.tju@gmail.com
Maoyi Xie (2):
octeon_ep: fix skb frags overflow in the RX path
octeon_ep_vf: fix skb frags overflow in the RX path
.../net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++
.../marvell/octeon_ep_vf/octep_vf_rx.c | 20 +++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH net v2 1/2] octeon_ep: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:05 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-1-maoyixie.tju@gmail.com>
__octep_oq_process_rx() builds an skb for a multi-buffer packet by adding
one fragment per buffer_size chunk:
data_len = buff_info->len - oq->max_single_buffer_size;
while (data_len) {
...
skb_add_rx_frag(skb, shinfo->nr_frags, buff_info->page, 0,
buff_info->len, buff_info->len);
...
}
buff_info->len comes from the device response header
(be64_to_cpu(resp_hw->length)). Nothing bounds the fragment count against
MAX_SKB_FRAGS. data_len can be close to 65535. buffer_size defaults to
about 3776 on 4K pages, so a full packet yields about 18 fragments. That
is one more than the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag()
writes past shinfo->frags[].
The fragment count is now checked before build_skb(). A packet that needs
more fragments than the skb can hold is dropped. octep_oq_drop_rx()
consumes its descriptors like the build_skb failure path. The same class
was fixed in other RX paths, including commit 5ffcb7b890f6 ("net: atlantic:
fix fragment overflow handling in RX path") and commit f0813bcd2d9d ("net:
wwan: t7xx: fix potential skb->frags overflow in RX path").
Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
index e6ebc7e44a..bdbed58c7b 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
@@ -453,6 +453,15 @@ static int __octep_oq_process_rx(struct octep_device *oct,
octep_oq_next_pkt(oq, buff_info, &read_idx, &desc_used);
+ if (buff_info->len > oq->max_single_buffer_size) {
+ u16 data_len = buff_info->len - oq->max_single_buffer_size;
+
+ if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
+ octep_oq_drop_rx(oq, buff_info, &read_idx, &desc_used);
+ continue;
+ }
+ }
+
skb = build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
octep_oq_drop_rx(oq, buff_info,
--
2.34.1
^ permalink raw reply related
* [PATCH net v2 2/2] octeon_ep_vf: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:05 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-1-maoyixie.tju@gmail.com>
__octep_vf_oq_process_rx() has the same unbounded fragment loop as the PF
driver. buff_info->len comes from the device response header, and one
fragment is added per buffer_size chunk with no check against
MAX_SKB_FRAGS. A long packet yields about 18 fragments, one past the
default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past
shinfo->frags[].
The fragment count is now checked before napi_build_skb(). A packet that
needs more fragments than the skb can hold is dropped. Its descriptors are
drained the same way the build_skb failure path does.
Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
.../marvell/octeon_ep_vf/octep_vf_rx.c | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
index d982474082..7af6a80671 100644
--- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
@@ -431,6 +431,26 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
struct skb_shared_info *shinfo;
u16 data_len;
+ data_len = buff_info->len - oq->max_single_buffer_size;
+ if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
+ desc_used++;
+ read_idx = octep_vf_oq_next_idx(oq, read_idx);
+ while (data_len) {
+ dma_unmap_page(oq->dev, oq->desc_ring[read_idx].buffer_ptr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
+ buff_info = (struct octep_vf_rx_buffer *)
+ &oq->buff_info[read_idx];
+ buff_info->page = NULL;
+ if (data_len < oq->buffer_size)
+ data_len = 0;
+ else
+ data_len -= oq->buffer_size;
+ desc_used++;
+ read_idx = octep_vf_oq_next_idx(oq, read_idx);
+ }
+ continue;
+ }
+
skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
oq->stats->alloc_failures++;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC 8/8] clk: sunxi-ng: a733: Add reset lines
From: Enzo Adriano @ 2026-07-02 18:11 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-8-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Same exercise for the reset map: I compared all 121 entries' offsets
and bit positions against the public A733 User Manual V0.92. 115 match
the manual exactly (including the multi-bit GMAC0 entry - 0x141C bits
16/17 per section 4.1.6.212 - and RST_BUS_SYSDAP at 0x7ac, which is
what makes the gate offset in patch 7/8 stand out).
The six that have no register in the public manual, in case you want
to add provenance notes near them (as already discussed for other
undocumented IDs in this series):
- RST_BUS_SPI4 { 0x0F2C, BIT(16) }
- RST_BUS_SGPIO { 0x1064, BIT(16) }
- RST_BUS_LPC { 0x1084, BIT(16) }
- RST_BUS_GMAC1 { 0x142C, BIT(16) } [GMAC1 question]
- RST_BUS_GMAC1_AXI { 0x142C, BIT(17) } [GMAC1 question]
- RST_BUS_TCON_LCD2 { 0x1514, BIT(16) } - the manual documents only
VO0_TCONLCD0_BGR (0x1504) and VO0_TCONLCD1_BGR (0x150C); there is
no TCONLCD2 register set in V0.92
Everything else in the reset map checks out against the manual.
This analysis was done with AI assistance (Claude Code, claude-fable-5)
and each finding was checked against the cited sources.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: usb: move exported code to usbnet
From: Andrew Lunn @ 2026-07-02 18:15 UTC (permalink / raw)
To: Oliver Neukum
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, shaoxul, netdev,
linux-usb, linux-kernel
In-Reply-To: <20260702143142.890654-1-oneukum@suse.com>
On Thu, Jul 02, 2026 at 04:25:29PM +0200, Oliver Neukum wrote:
> Some drivers are reusing common code originating in other drivers.
> This means that two drivers need to be loaded for one device.
Maybe consider using 'framework' or 'library', rather than driver,
when referring to the shared code?
I tend to think of a driver as the leaf node which probes based on
enumeration of a bus. But usbnet.c itself is never probed.
Andrew
^ permalink raw reply
* Re: [RFC net-next] bonding: Retry updating slave MAC after a failure
From: Jay Vosburgh @ 2026-07-02 18:17 UTC (permalink / raw)
To: Paritosh Potukuchi; +Cc: netdev, linux-kernel, paritosh.potukuchi
In-Reply-To: <CAMfiSebUf6rbHu4bVL-5vCFRs5cafiEeiNDpX3eQRdxKuRgGeQ@mail.gmail.com>
Paritosh Potukuchi <paritoshpotukuchi@gmail.com> wrote:
>> I think the proper thing to do is remove this comment block and
>make no other changes.
>
> > This comment dates to sometime before git, when it was common
>for network device drivers to lack the ability to change the MAC while
>the interface is up. To the best of my knowledge, that isn't a issue
>today.
>
>Sure Jay. That makes sense. Should I go ahead and post a patch
>removing this comment?
Yes, please do so.
-J
> -Paritosh
>
>On Wed, 1 Jul 2026 at 04:29, Jay Vosburgh <jv@jvosburgh.net> wrote:
>
> Paritosh Potukuchi <paritoshpotukuchi@gmail.com> wrote:
>
> >I came across this TODO in bond_set_mac_address() :
> >
> > /* TODO: consider downing the slave
> > * and retry ?
> > * User should expect communications
> > * breakage anyway until ARP finish
> > * updating, so...
> > */
> >
> >Currently, if the dev_set_mac_address() fails on a slave, we go
> >ahead and unwind the bond and its slaves.
> >
> >As the TODO suggests, one possible solution is to try setting
> >the MAC again, after putting down the interface. This is because some
> >drivers may reject changing the MAC when the device is UP.
> >
> >The solution I am proposing is as follows:
> >
> >dev_set_mac_address on the slave
> > - If this fails, temporarily stop the slave - ndo_stop
> > - If stop fails, unwind
> > - call dev_set_mac_address() on the slave
> > - If this fails, unwind
> > - Bring up the slave by calling ndo_open
> > - If this fails, unwind
> >If dev_set_mac_address on slave passes, we go to the next slave
> >
> >
> >Before working on a patch, I wanted to get feedback on whether
> >this interpretation of the TODO makes sense and whether there
> >are concerns with temporarily stopping and restarting a slave
> >during bond_set_mac_address().
>
> I think the proper thing to do is remove this comment block
> and
> make no other changes.
>
> This comment dates to sometime before git, when it was common
> for network device drivers to lack the ability to change the MAC while
> the interface is up. To the best of my knowledge, that isn't a issue
> today.
>
> -J
>
---
-Jay Vosburgh, jv@jvosburgh.net
^ 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