* Re: [PATCH net v2 2/2] 8021q: delete cleared egress QoS mappings
From: Paolo Abeni @ 2026-04-23 10:13 UTC (permalink / raw)
To: Simon Horman, Ren Wei
Cc: netdev, edumazet, andrew+netdev, davem, kuba, kees, yuantan098,
ylong030, yifanwucs, tomapufckgml, bird
In-Reply-To: <20260422162041.GO651125@horms.kernel.org>
On 4/22/26 6:20 PM, Simon Horman wrote:
> On Mon, Apr 20, 2026 at 11:18:46AM +0800, Ren Wei wrote:
>> From: Longxuan Yu <ylong030@ucr.edu>
>>
>> vlan_dev_set_egress_priority() currently keeps cleared egress
>> priority mappings in the hash as tombstones. Repeated set/clear cycles
>> with distinct skb priorities therefore accumulate mapping nodes until
>> device teardown and leak memory.
>>
>> Delete mappings when vlan_prio is cleared instead of keeping tombstones.
>> Now that the egress mapping lists are RCU protected, the node can be
>> unlinked safely and freed after a grace period.
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Cc: stable@kernel.org
>> Reported-by: Yifan Wu <yifanwucs@gmail.com>
>> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
>> Reported-by: Xin Liu <bird@lzu.edu.cn>
>> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
>> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
>> Signed-off-by: Longxuan Yu <ylong030@ucr.edu>
>> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
>> ---
>> net/8021q/vlan_dev.c | 20 ++++++++++++++------
>> net/8021q/vlan_netlink.c | 4 ----
>> 2 files changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
>> index a5340932b657..7aa3af8b10ea 100644
>> --- a/net/8021q/vlan_dev.c
>> +++ b/net/8021q/vlan_dev.c
>> @@ -172,26 +172,34 @@ int vlan_dev_set_egress_priority(const struct net_device *dev,
>> u32 skb_prio, u16 vlan_prio)
>> {
>> struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
>> + struct vlan_priority_tci_mapping __rcu **mpp;
>> struct vlan_priority_tci_mapping *mp;
>> struct vlan_priority_tci_mapping *np;
>> u32 bucket = skb_prio & 0xF;
>> u32 vlan_qos = (vlan_prio << VLAN_PRIO_SHIFT) & VLAN_PRIO_MASK;
>>
>> /* See if a priority mapping exists.. */
>> - mp = rtnl_dereference(vlan->egress_priority_map[bucket]);
>> + mpp = &vlan->egress_priority_map[bucket];
>> + mp = rtnl_dereference(*mpp);
>> while (mp) {
>> if (mp->priority == skb_prio) {
>> - if (mp->vlan_qos && !vlan_qos)
>> + if (!vlan_qos) {
>> + rcu_assign_pointer(*mpp, rtnl_dereference(mp->next));
>> vlan->nr_egress_mappings--;
>> - else if (!mp->vlan_qos && vlan_qos)
>> - vlan->nr_egress_mappings++;
>> - WRITE_ONCE(mp->vlan_qos, vlan_qos);
>> + kfree_rcu(mp, rcu);
>> + } else {
>> + WRITE_ONCE(mp->vlan_qos, vlan_qos);
>> + }
>> return 0;
>> }
>> - mp = rtnl_dereference(mp->next);
>> + mpp = &mp->next;
>> + mp = rtnl_dereference(*mpp);
>> }
>
> Hi Ren,
>
> Thanks for splitting up the patchset, it is very helpful to me.
>
> It seems to me that the mpp/mp construct used is a bit complex and
> stems from the use of a hand-rolled list centred the next field of
> struct vlan_priority_tci_mapping.
>
> I wonder if things can be simplified by moving to use a standardised
> list construct, such as an hlist. And the helpers available for using it.
I agree hlist_rcu usage would simplify the code above, but I fear it
will make this already relatively big change even bigger, as several
list traversing places will need to be updated accordingly.
I think conversion to hlist_rcu could/should be a net-next follow-up.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net] ipv6: validate extension header length before copying to cmsg
From: Qi Tang @ 2026-04-23 9:57 UTC (permalink / raw)
To: Paolo Abeni
Cc: David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Simon Horman, netdev, linux-kernel
In-Reply-To: <01e90b44-88c8-4e29-86db-b9258d8271b2@redhat.com>
On Thu, Apr 23, 2026, Paolo Abeni <pabeni@redhat.com> wrote:
> The patch looks functionally correct to me, but the above 3 statements
> are repeated multiple times. You can put them in a local helper and
> avoud a lot of duplicate code.
I actually considered that first, but went with per-site
replication in v1 to keep the diff minimal for backporting.
A local helper is definitely the better approach though.
Will do that for v2.
> The packet is corrupted, allowing processing of later rxopt requires the
> IMHO not nice empty label. I think it would be better just returning
> from this function.
Makes sense. Will return directly in v2.
Thanks for the review.
Qi
^ permalink raw reply
* Re: [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe
From: Corey Leavitt @ 2026-04-23 9:48 UTC (permalink / raw)
To: Kory Maincent, Carlo Szelinsky
Cc: Oleksij Rempel, Andrew Lunn, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Heiner Kallweit,
Russell King, netdev, linux-kernel
In-Reply-To: <20260423110544.052f631e@kmaincent-XPS-13-7390>
Hi Kory,
Thanks for the pointer -- I had not seen Carlo's thread; I should have
searched lore before sending and will do so before v2. Adding Carlo on
cc.
Having read it end-to-end, my read of the state as of 2026-04-13 was
that the conversation had narrowed to two open directions: propagate
EPROBE_DEFER further up into phylink/MAC probe (Andrew/Russell), or
resolve psec at PSE controller register time (your msg on 9 Apr,
"save the phandle ... then at PSE register time look for each PHY and
try to resolve every unresolved phandle"). Nothing concrete had been
posted for either.
This RFC implements the second direction. pse_core publishes a
BLOCKING_NOTIFIER chain with REGISTERED / UNREGISTERED events,
phy_device subscribes, and psec ownership moves from fwnode_mdio probe
into the notifier handler. Concretely with respect to points raised in
the earlier thread:
- fwnode_mdio loses PSE awareness entirely, so the MDIO bus scan no
longer sees -EPROBE_DEFER from PSE lookup. Consistent with
Andrew's point that bus and device lifecycles are separate.
- psec is acquired at PSE register time, before
regulator_late_cleanup (30s) can run. Carlo's admin_state_synced
guard (his patch 1) therefore isn't needed in this model. psec
resolution happens eagerly on the REGISTERED event rather than
lazily on first ethtool access, so his patch 2 is also not needed.
And because fwnode_mdio no longer looks up PSE at all, the
non-fatal EPROBE_DEFER handling there (patch 3) drops out. This
series is a different architectural shape, not an increment on
his v2.
- Oleksij's concern about lazy resolution dropping UAPI
notifications is addressed: the notifier fires at register time,
so boot-time observer semantics are preserved.
- One caveat I already owe a fix for in v2: the attach helper in
phy_device currently treats every error from of_pse_control_get()
as retry-on-notifier, including non-transient ones. Carlo's v2
patch 3 was careful to differentiate -EPROBE_DEFER from bad-DT
errors at the fwnode_mdio lookup site (which matches his msg 1
concern about catching broken bindings at boot rather than
silently later). I need to preserve that discrimination at the
notifier-handler site -- phydev_warn() on anything other than
-EPROBE_DEFER. Trivial, but worth flagging.
- The DSA genphy force-bind sequence Carlo hit
(phy_attach_direct -> device_bind_driver -> deferred retry
skipped) does not apply, because psec attachment is not tied to
phy_probe.
- Patch 1 of this series scopes the regulator handle held by
pse_control to its own kref lifetime, fixing a latent
dangling-handle sequence that the notifier unregister path makes
reachable. This is a separate regulator-lifetime bug from the one
Carlo's patch 1 addresses.
Validated end-to-end on a Cudy C200P (MT7621 DSA + i2c IP804AR as
module), with lockdep active, across the i2c driver unbind/rebind
cycle that triggers UNREGISTERED -> REGISTERED on the live system.
The cover letter has the full evidence.
I would welcome your view on whether this is the shape you had in
mind on 9 Apr, or whether the MDI-based binding you raised with
Maxime is the better endpoint and we should be reshaping around that.
Happy to keep this RFC as the scaffolding either way.
Carlo -- your debugging work on the DSA phy_attach_direct interaction
is what made it clear this kind of approach was needed; thanks for
laying that groundwork. Would value your thoughts on the tradeoffs.
Best regards,
Corey
^ permalink raw reply
* Re: [PATCH v2 net 0/11] octeontx2-af: npc: cn20k: MCAM fixes
From: Paolo Abeni @ 2026-04-23 9:44 UTC (permalink / raw)
To: Ratheesh Kannoth, netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, andrew+netdev, dan.carpenter
In-Reply-To: <20260420023442.3295891-1-rkannoth@marvell.com>
On 4/20/26 4:34 AM, Ratheesh Kannoth wrote:
> This series tightens Marvell OcteonTX2 AF NPC support for CN20K
> silicon around MCAM key typing, optional debugfs setup, defrag
> allocation rollback, x2 versus x4 KEX profiles and default-rule
> allocation, logical MCAM clear and configuration, default-rule index
> bookkeeping and explicit teardown, and NIXLF reserved-slot lookup when
> default rules are missing.
>
> Patches 1 through 3 focus on AF error handling: propagate
> npc_mcam_idx_2_key_type() failures through cn20k MCAM enable, config,
> copy, and read paths; treat cn20k NPC debugfs files as optional so
> probe does not fail when debugfs is unavailable; and fix defrag MCAM
> allocation rollback so allocation errno is not overwritten by subbank
> index resolution.
>
> Patches 4 and 5 align default-rule and flow-install behaviour with the
> loaded mkex profile: prefer x4 default entries when the profile is x4,
> and reject x4 flow keys when the profile is strictly x2.
>
> Patches 6 through 8 refine cn20k MCAM programming: clear entries by
> logical index and resolved key width, fix bank and CFG sequencing in
> npc_cn20k_config_mcam_entry(), and read action metadata from the
> correct bank in npc_cn20k_read_mcam_entry().
>
> Patches 9 through 11 complete default-rule lifecycle handling:
> initialize all default-rule index outputs up front, tear down default
> MCAM rules explicitly (coordinated with npc_mcam_free_all_entries()),
> and reject USHRT_MAX sentinel indices in npc_get_nixlf_mcam_index()
> for cn20k.
>
> Ratheesh Kannoth (11):
> octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k
> octeontx2-af: npc: cn20k: Drop debugfs_create_file() error checks in
> init
> octeontx2-af: npc: cn20k: Propagate errors in defrag MCAM alloc
> rollback
> octeontx2-af: npc: cn20k: Make default entries as x4.
> octeontx2-af: npc: cn20k: Reject request for x4 entries in x2
> profile.
> octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width
> octeontx2-af: npc: cn20k: Fix bank value.
> octeontx2-af: npc: cn20k: Fix MCAM actions read
> octeontx2-af: npc: cn20k: Initialize default-rule index outputs up
> front
> octeontx2-af: npc: cn20k: Tear down default MCAM rules explicitly on
> free
> octeontx2-af: npc: cn20k: Reject missing default-rule MCAM indices
>
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
>
> --
> v1 -> v2: Addressed simon comments. Added more patch fixes to this series.
> https://lore.kernel.org/netdev/20260418162013.GG280379@horms.kernel.org/
I strongly suggest avoid extending a series to address issues found by
the AI review, unless such issues are actual regressions/problems
introduced by the new code. Sashiko tends to find a lot of collateral
problem and the series could easily expand beyond any hope of merging.
Instead you should reply on the ML, commenting on sashiko's review,
explain why or why not the outlined problems are valid and/or should be
handled separately.
Thanks,
Paolo
^ permalink raw reply
* [PATCH net 3/3] netconsole: propagate device name truncation in dev_name_store()
From: Breno Leitao @ 2026-04-23 9:41 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Keiichi Kii, Satyam Sharma, Andrew Morton,
Matthew Wood, asantostc, gustavold
Cc: netdev, linux-kernel, Breno Leitao, kernel-team
In-Reply-To: <20260423-netconsole_ai_fixes-v1-0-92b8b7de9a2c@debian.org>
dev_name_store() calls strscpy(nt->np.dev_name, buf, IFNAMSIZ) without
checking the return value. If userspace writes an interface name longer
than IFNAMSIZ - 1, strscpy() silently truncates and returns -E2BIG, but
the function ignores it and reports a fully successful write back to
userspace.
If a real interface happens to match the truncated name, netconsole will
bind to the wrong device on the next enable, sending kernel logs and
panic output to an unintended network segment with no indication to
userspace that anything was rewritten.
Reject writes whose length cannot fit in nt->np.dev_name up front:
if (count >= IFNAMSIZ)
return -ENAMETOOLONG;
This is not a big deal of a problem, but, it is still the correct
approach.
Fixes: 0bcc1816188e57 ("[NET] netconsole: Support dynamic reconfiguration using configfs")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/netconsole.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 4bef003d9df64..3914fb90f9afd 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -816,6 +816,9 @@ static ssize_t dev_name_store(struct config_item *item, const char *buf,
{
struct netconsole_target *nt = to_target(item);
+ if (count >= IFNAMSIZ)
+ return -ENAMETOOLONG;
+
dynamic_netconsole_mutex_lock();
if (nt->state == STATE_ENABLED) {
pr_err("target (%s) is enabled, disable to update parameters\n",
--
2.52.0
^ permalink raw reply related
* [PATCH net 2/3] netconsole: avoid clobbering userdatum value on truncated write
From: Breno Leitao @ 2026-04-23 9:41 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Keiichi Kii, Satyam Sharma, Andrew Morton,
Matthew Wood, asantostc, gustavold
Cc: netdev, linux-kernel, Breno Leitao, kernel-team
In-Reply-To: <20260423-netconsole_ai_fixes-v1-0-92b8b7de9a2c@debian.org>
userdatum_value_store() bounds count by MAX_EXTRADATA_VALUE_LEN (200)
and then copies straight into udm->value, which is itself 200 bytes:
if (count > MAX_EXTRADATA_VALUE_LEN)
return -EMSGSIZE;
...
ret = strscpy(udm->value, buf, sizeof(udm->value));
if (ret < 0)
goto out_unlock;
If userspace writes exactly MAX_EXTRADATA_VALUE_LEN bytes with no NUL
within them, strscpy() copies 199 bytes plus a NUL into udm->value and
returns -E2BIG. The function jumps to out_unlock and reports the error
to userspace, but udm->value has already been overwritten with the
truncated string and update_userdata() is skipped, so the corruption
is not yet visible on the wire.
The next successful write to any userdatum entry under the same target
calls update_userdata(), which packs udm->value into the active
netconsole payload. From that point on, every netconsole message
carries the silently truncated value, and userspace has no indication
that a previous, error-returning write left state behind.
Tighten the entry check from "count > MAX_EXTRADATA_VALUE_LEN" to
"count >= MAX_EXTRADATA_VALUE_LEN". With count strictly less than
sizeof(udm->value), strscpy() can no longer return -E2BIG here, so
the corrupting truncation path is removed entirely.
Fixes: 8a6d5fec6c7f ("net: netconsole: add a userdata config_group member to netconsole_target")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/netconsole.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 5713cb3783ef2..4bef003d9df64 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -1074,7 +1074,7 @@ static ssize_t userdatum_value_store(struct config_item *item, const char *buf,
struct userdata *ud;
ssize_t ret;
- if (count > MAX_EXTRADATA_VALUE_LEN)
+ if (count >= MAX_EXTRADATA_VALUE_LEN)
return -EMSGSIZE;
mutex_lock(&netconsole_subsys.su_mutex);
--
2.52.0
^ permalink raw reply related
* [PATCH net 1/3] netconsole: return count instead of strnlen(buf, count) from store callbacks
From: Breno Leitao @ 2026-04-23 9:41 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Keiichi Kii, Satyam Sharma, Andrew Morton,
Matthew Wood, asantostc, gustavold
Cc: netdev, linux-kernel, Breno Leitao, kernel-team
In-Reply-To: <20260423-netconsole_ai_fixes-v1-0-92b8b7de9a2c@debian.org>
Several configfs store callbacks in netconsole end with:
ret = strnlen(buf, count);
This under-reports the number of bytes consumed when the input
contains an embedded NUL within count, telling the VFS that fewer
bytes were written than userspace actually handed in. A conformant
partial-write loop would then retry the trailing bytes against a
callback that has already accepted them.
Every other configfs driver in the tree returns count directly from
its store callbacks once parsing has succeeded, including
drivers/nvme/target/configfs.c, drivers/gpio/gpio-sim.c,
drivers/most/configfs.c, drivers/block/null_blk/main.c,
drivers/pci/endpoint/pci-ep-cfs.c, and the rest of the configfs
users. netconsole was the outlier (along with
drivers/infiniband/core/cma_configfs.c, which has the same latent
issue).
Align netconsole with the rest of the configfs ecosystem: return
count once the parser/validator has accepted the input. The numeric
and boolean parsers (kstrtobool, kstrtou16, mac_pton,
netpoll_parse_ip_addr) have already validated the meaningful prefix;
any trailing bytes are padding and should simply be reported as
consumed.
Fixes: 0bcc1816188e ("[NET] netconsole: Support dynamic reconfiguration using configfs")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/netconsole.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 3c9acd6e49e86..5713cb3783ef2 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -750,7 +750,7 @@ static ssize_t enabled_store(struct config_item *item,
unregister_netcons_consoles();
}
- ret = strnlen(buf, count);
+ ret = count;
/* Deferred cleanup */
netconsole_process_cleanups();
out_unlock:
@@ -779,7 +779,7 @@ static ssize_t release_store(struct config_item *item, const char *buf,
nt->release = release;
- ret = strnlen(buf, count);
+ ret = count;
out_unlock:
dynamic_netconsole_mutex_unlock();
return ret;
@@ -805,7 +805,7 @@ static ssize_t extended_store(struct config_item *item, const char *buf,
goto out_unlock;
nt->extended = extended;
- ret = strnlen(buf, count);
+ ret = count;
out_unlock:
dynamic_netconsole_mutex_unlock();
return ret;
@@ -828,7 +828,7 @@ static ssize_t dev_name_store(struct config_item *item, const char *buf,
trim_newline(nt->np.dev_name, IFNAMSIZ);
dynamic_netconsole_mutex_unlock();
- return strnlen(buf, count);
+ return count;
}
static ssize_t local_port_store(struct config_item *item, const char *buf,
@@ -847,7 +847,7 @@ static ssize_t local_port_store(struct config_item *item, const char *buf,
ret = kstrtou16(buf, 10, &nt->np.local_port);
if (ret < 0)
goto out_unlock;
- ret = strnlen(buf, count);
+ ret = count;
out_unlock:
dynamic_netconsole_mutex_unlock();
return ret;
@@ -869,7 +869,7 @@ static ssize_t remote_port_store(struct config_item *item,
ret = kstrtou16(buf, 10, &nt->np.remote_port);
if (ret < 0)
goto out_unlock;
- ret = strnlen(buf, count);
+ ret = count;
out_unlock:
dynamic_netconsole_mutex_unlock();
return ret;
@@ -894,7 +894,7 @@ static ssize_t local_ip_store(struct config_item *item, const char *buf,
goto out_unlock;
nt->np.ipv6 = !!ipv6;
- ret = strnlen(buf, count);
+ ret = count;
out_unlock:
dynamic_netconsole_mutex_unlock();
return ret;
@@ -919,7 +919,7 @@ static ssize_t remote_ip_store(struct config_item *item, const char *buf,
goto out_unlock;
nt->np.ipv6 = !!ipv6;
- ret = strnlen(buf, count);
+ ret = count;
out_unlock:
dynamic_netconsole_mutex_unlock();
return ret;
@@ -955,7 +955,7 @@ static ssize_t remote_mac_store(struct config_item *item, const char *buf,
goto out_unlock;
memcpy(nt->np.remote_mac, remote_mac, ETH_ALEN);
- ret = strnlen(buf, count);
+ ret = count;
out_unlock:
dynamic_netconsole_mutex_unlock();
return ret;
@@ -1131,7 +1131,7 @@ static ssize_t sysdata_msgid_enabled_store(struct config_item *item,
disable_sysdata_feature(nt, SYSDATA_MSGID);
unlock_ok:
- ret = strnlen(buf, count);
+ ret = count;
dynamic_netconsole_mutex_unlock();
mutex_unlock(&netconsole_subsys.su_mutex);
return ret;
@@ -1160,7 +1160,7 @@ static ssize_t sysdata_release_enabled_store(struct config_item *item,
disable_sysdata_feature(nt, SYSDATA_RELEASE);
unlock_ok:
- ret = strnlen(buf, count);
+ ret = count;
dynamic_netconsole_mutex_unlock();
mutex_unlock(&netconsole_subsys.su_mutex);
return ret;
@@ -1189,7 +1189,7 @@ static ssize_t sysdata_taskname_enabled_store(struct config_item *item,
disable_sysdata_feature(nt, SYSDATA_TASKNAME);
unlock_ok:
- ret = strnlen(buf, count);
+ ret = count;
dynamic_netconsole_mutex_unlock();
mutex_unlock(&netconsole_subsys.su_mutex);
return ret;
@@ -1223,7 +1223,7 @@ static ssize_t sysdata_cpu_nr_enabled_store(struct config_item *item,
disable_sysdata_feature(nt, SYSDATA_CPU_NR);
unlock_ok:
- ret = strnlen(buf, count);
+ ret = count;
dynamic_netconsole_mutex_unlock();
mutex_unlock(&netconsole_subsys.su_mutex);
return ret;
--
2.52.0
^ permalink raw reply related
* [PATCH net 0/3] netconsole: configfs store callback fixes
From: Breno Leitao @ 2026-04-23 9:41 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Keiichi Kii, Satyam Sharma, Andrew Morton,
Matthew Wood, asantostc, gustavold
Cc: netdev, linux-kernel, Breno Leitao, kernel-team
This series fixes a small cluster of related issues in netconsole's
configfs store callbacks.
They showed up in sashiko and brought to my attention by Simon:
https://lore.kernel.org/all/20260421162219.GF651125@horms.kernel.org/
None are crashes or security problems, but each is a real correctness
bug that surfaces at boundary conditions and was easy to clean up while
the code was already under the microscope.
All three changes narrow the accepted write size by exactly one byte
at the boundary that was previously buggy, so no well-behaved
userspace should notice the tightening.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (3):
netconsole: return count instead of strnlen(buf, count) from store callbacks
netconsole: avoid clobbering userdatum value on truncated write
netconsole: propagate device name truncation in dev_name_store()
drivers/net/netconsole.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
---
base-commit: 70c8a7ec6715b5fb14e501731b5b9210a16684f7
change-id: 20260422-netconsole_ai_fixes-24599337a79d
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [v2,net,06/11] octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width
From: Paolo Abeni @ 2026-04-23 9:39 UTC (permalink / raw)
To: rkannoth
Cc: davem, sgoutham, pabeni, sumang, dan.carpenter, error27,
andrew+netdev, kuba, horms, linux-kernel, edumazet, netdev
In-Reply-To: <20260420023442.3295891-7-rkannoth@marvell.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width
Replace the old four-argument CN20K MCAM clear with a per-bank static
helper and npc_cn20k_clear_mcam_entry() that takes a logical MCAM index,
resolves the key width via npc_mcam_idx_2_key_type(), and clears either
one bank (X2) or every bank (X4). Call it from npc_clear_mcam_entry() on
cn20k and log when key-type lookup fails. Use the per-bank helper from
npc_cn20k_config_mcam_entry() for pre-program clears. For loopback VFs,
use the promisc MCAM index as ucast_idx when copying RSS action for
promisc, matching cn20k default-rule layout.
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> index 705fe7a877e6..7bfd39fe0f5e 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
[ ... ]
> @@ -877,6 +877,32 @@ npc_cn20k_clear_mcam_entry(struct rvu *rvu, int blkaddr, int bank, int index)
> NPC_AF_CN20K_MCAMEX_BANKX_STAT_EXT(index, bank), 0);
> }
>
> +int
> +npc_cn20k_clear_mcam_entry(struct rvu *rvu, int blkaddr, int mcam_idx)
> +{
> + struct npc_mcam *mcam = &rvu->hw->mcam;
> + int bank = npc_get_bank(mcam, mcam_idx);
> + u8 kw_type, index;
> +
> + if (npc_mcam_idx_2_key_type(rvu, mcam_idx, &kw_type))
> + return -EINVAL;
> +
> + index = mcam_idx & (mcam->banksize - 1);
Can the index calculation overflow a u8 when banksize exceeds 256?
The mcam->banksize field is u16 and can be up to 65535, with typical
values like 512 or 1024 for NPC MCAM hardware. When computing 'mcam_idx &
(mcam->banksize - 1)', the result will be truncated to 8 bits if it
exceeds 255, causing the wrong MCAM entry to be cleared.
Other code in this driver uses u16 or int for the same calculation:
drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c:npc_cn20k_copy_mcam_entry()
u16 src, dest;
...
src = src_idx & (mcam->banksize - 1);
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:npc_clear_mcam_entry()
index &= (mcam->banksize - 1);
where index is int.
> +
> + if (kw_type == NPC_MCAM_KEY_X2) {
> + npc_clear_x2_entry(rvu, blkaddr, bank, index);
> + return 0;
> + }
> +
> + /* For NPC_MCAM_KEY_X4 keys, both the banks
> + * need to be programmed with the same value.
> + */
> + for (bank = 0; bank < mcam->banks_per_entry; bank++)
> + npc_clear_x2_entry(rvu, blkaddr, bank, index);
> +
> + return 0;
> +}
[ ... ]
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
> index 762fafd4ccb7..0a2191fda614 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
> @@ -259,6 +259,13 @@ static void npc_clear_mcam_entry(struct rvu *rvu, struct npc_mcam *mcam,
> int bank = npc_get_bank(mcam, index);
> int actbank = bank;
>
> + if (is_cn20k(rvu->pdev)) {
> + if (npc_cn20k_clear_mcam_entry(rvu, blkaddr, index))
> + dev_err(rvu->dev, "%s Failed to enable mcam %u\n",
> + __func__, index);
This isn't a bug, but the error message says "Failed to enable mcam"
when the operation is clearing the entry. Should this be "Failed to clear
mcam"?
> + return;
> + }
> +
> index &= (mcam->banksize - 1);
> for (; bank < (actbank + mcam->banks_per_entry); bank++) {
> rvu_write64(rvu, blkaddr,
[ ... ]
^ permalink raw reply
* Re: [v2,net,01/11] octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k
From: Paolo Abeni @ 2026-04-23 9:38 UTC (permalink / raw)
To: rkannoth
Cc: davem, sgoutham, pabeni, sumang, dan.carpenter, error27,
andrew+netdev, kuba, horms, linux-kernel, edumazet, netdev
In-Reply-To: <20260420023442.3295891-2-rkannoth@marvell.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k
This patch converts several cn20k NPC functions from void to int return
types to propagate MCAM key-type lookup errors. It adds error checking
for npc_mcam_idx_2_key_type() and threads these errors through the
cn20k MCAM handlers.
Link: https://lore.kernel.org/netdev/adiQJvuKlEhq2ILx@stanley.mountain/
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> index 7291fdb89b03..18d70f4527d1 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
[ ... ]
> @@ -1415,9 +1435,9 @@ int rvu_mbox_handler_npc_cn20k_mcam_alloc_and_write_entry(struct rvu *rvu,
> else
> nix_intf = pfvf->nix_rx_intf;
>
> - npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf,
> - &req->entry_data, req->enable_entry,
> - req->hw_prio, req->req_kw_type);
> + rc = npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf,
> + &req->entry_data, req->enable_entry,
> + req->hw_prio, req->req_kw_type);
>
> mutex_unlock(&mcam->lock);
>
> rsp->entry = entry_rsp.entry;
> return 0;
Does this function need to return rc instead of 0? If
npc_cn20k_config_mcam_entry() fails (for example, due to an invalid key
type), the function still returns success to the caller. The mailbox
response indicates the entry was successfully allocated and configured,
but the hardware entry may be in an undefined state.
[ ... ]
^ permalink raw reply
* Re: [PATCH net 1/8] netfilter: nft_osf: restrict it to ipv4
From: patchwork-bot+netdevbpf @ 2026-04-23 9:30 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260420220215.111510-2-pablo@netfilter.org>
Hello:
This series was applied to netdev/net.git (main)
by Pablo Neira Ayuso <pablo@netfilter.org>:
On Tue, 21 Apr 2026 00:02:08 +0200 you wrote:
> This expression only supports for ipv4, restrict it.
>
> Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf")
> Acked-by: Florian Westphal <fw@strlen.de>
> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> [...]
Here is the summary with links:
- [net,1/8] netfilter: nft_osf: restrict it to ipv4
https://git.kernel.org/netdev/net/c/b336fdbb7103
- [net,2/8] netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO
https://git.kernel.org/netdev/net/c/2195574dc6d9
- [net,3/8] netfilter: conntrack: remove sprintf usage
https://git.kernel.org/netdev/net/c/6e7066bdb481
- [net,4/8] netfilter: xtables: restrict several matches to inet family
https://git.kernel.org/netdev/net/c/b6fe26f86a16
- [net,5/8] netfilter: nat: use kfree_rcu to release ops
https://git.kernel.org/netdev/net/c/6eda0d771f94
- [net,6/8] ipvs: fix MTU check for GSO packets in tunnel mode
https://git.kernel.org/netdev/net/c/67bf42cae41d
- [net,7/8] netfilter: nfnetlink_osf: fix out-of-bounds read on option matching
https://git.kernel.org/netdev/net/c/f5ca450087c3
- [net,8/8] netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check
https://git.kernel.org/netdev/net/c/711987ba281f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2 10/15] drivers: net: cirrus: mac89x0: Remove this driver
From: John Paul Adrian Glaubitz @ 2026-04-23 9:28 UTC (permalink / raw)
To: Daniel Palmer
Cc: Geert Uytterhoeven, Andrew Lunn, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Jonathan Corbet, Shuah Khan, Michael Fritscher, Byron Stanoszek,
linux-kernel, netdev, linux-doc, linux-m68k
In-Reply-To: <CAFr9PXnECog56b+Jq9TBohhQ4oBB3hGV1pHj6OstOSLqkOpcTQ@mail.gmail.com>
Hi Daniel,
On Thu, 2026-04-23 at 17:52 +0900, Daniel Palmer wrote:
> Hi Adrian,
>
> On Thu, 23 Apr 2026 at 16:10, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > > Macs do run modern kernels.
> >
> > Retrocomputing still is not well regarded by some maintainers, it seems :-(.
>
> I've found bugs in drivers by plugging those things into exotic
> hardware like my Amiga 4000 and Ultra5 [0].
> So, it's not totally pointless. And having a shader capable Amiga[1]
> is pretty cool.
Not only that. Those exotic architectures also help iron out generic kernel
bugs and give new maintainers an possibility to get their feet wet.
> Sad to see fun stuff getting pushed out by basically spam bots. :(
It's not so much pushed out by spam bots but by the commercialization of the
Linux kernel. Many developers think that the sole purpose of the Linux kernel
is to run on modern commodity hardware.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v2] net: dsa: realtek: rtl8365mb: fix mode mask calculation
From: patchwork-bot+netdevbpf @ 2026-04-23 9:20 UTC (permalink / raw)
To: Mieczyslaw Nalewaj; +Cc: netdev
In-Reply-To: <400a6387-a444-4576-af6d-26be5410bce3@yahoo.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 19 Apr 2026 21:37:07 +0200 you wrote:
> The RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK macro was shifting
> the 4-bit mask (0xF) by only (_extint % 2) bits instead of
> (_extint % 2) * 4. This caused the mask to overlap with the adjacent
> nibble when configuring odd-numbered external interfaces, selecting
> the wrong bits entirely.
>
> Align the shift calculation with the existing ...MODE_OFFSET macro.
>
> [...]
Here is the summary with links:
- [v2] net: dsa: realtek: rtl8365mb: fix mode mask calculation
https://git.kernel.org/netdev/net/c/0c078021d386
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC PATCH bpf-next v6 11/12] selftests/bpf: Add test for memcg_bpf_ops hierarchies
From: XIAO WU @ 2026-04-23 9:15 UTC (permalink / raw)
To: bot+bpf-ci
Cc: a.s.protopopov, akpm, ameryhung, andrii, ast, bpf, brauner,
brgerst, cgroups, chenridong, clm, daniel, davem, eddyz87,
geliang, hannes, haoluo, hawk, hui.zhu, ihor.solodrai,
inwardvessel, jeffxu, jiayuan.chen, john.fastabend, jolsa, kees,
kernel, kerneljasonxing, kpsingh, kuba, lance.yang, linux-kernel,
linux-kselftest, linux-mm, martin.lau, martin.lau, masahiroy,
mhocko, mkoutny, muchun.song, nathan, netdev, ojeda,
paul.chaignon, peterz, rdunlap, roman.gushchin, sdf, shakeel.butt,
shuah, song, tj, willemb, yonghong.song, zhuhui
In-Reply-To: <958ccd923342ddd02e9122381d51319cb125ec51d601bb6fcad57531a2f5ef57@mail.kernel.org>
Hi,
> +cleanup:
> + bpf_link__destroy(link1);
> + bpf_link__destroy(link2);
> + bpf_link__destroy(link3);
> + memcg_ops__detach(skel);
> + memcg_ops__destroy(skel);
>
> Can this crash if skel is NULL?
Yes, this is a valid bug in the selftest cleanup path.
If execution jumps to cleanup before memcg_ops__open_and_load()
succeeds, skel remains NULL. In that case, memcg_ops__detach(skel)
dereferences NULL through obj->skeleton in the generated detach helper,
as you pointed out.
This is also inconsistent with nearby tests in the same file that
already do if (skel) {
memcg_ops__detach(skel);
memcg_ops__destroy(skel);
}
The C repro, modeling the same control flow:
--8<--
// SPDX-License-Identifier: GPL-2.0
// PoC for cleanup-path NULL dereference in
test_memcg_ops_hierarchies().
#include <stdio.h>
struct bpf_object_skeleton {
int dummy;
};
struct memcg_ops {
struct bpf_object_skeleton *skeleton;
};
__attribute__((noinline))
static void bpf_object__detach_skeleton(struct bpf_object_skeleton *s)
{
(void)s;
}
/* Matches generated skeleton helper shape from review mail. */
static inline void memcg_ops__detach(struct memcg_ops *obj)
{
bpf_object__detach_skeleton(obj->skeleton);
}
static int setup_cgroup_environment_fail(void)
{
return -1;
}
int main(void)
{
int ret;
struct memcg_ops *skel = NULL;
fprintf(stderr, "[*] trigger cleanup with skel == NULL\n");
/* Simulate early failure before open_and_load() assigns skel. */
ret = setup_cgroup_environment_fail();
if (ret)
goto cleanup;
cleanup:
/* Same problematic call pattern as in the test cleanup block. */
memcg_ops__detach(skel);
return 0;
}
--8<--
Signed-off-by: XIAO WU <shawdoxwu@gmail.com>
Thanks,
xiao
^ permalink raw reply
* Re: [PATCH net v2 13/15] drivers: net: 8390: pcnet: Remove this driver
From: Bjørn Mork @ 2026-04-23 9:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Geert Uytterhoeven, Michael Fritscher, Byron Stanoszek,
Daniel Palmer, linux-kernel, netdev, linux-doc
In-Reply-To: <20260422-v7-0-0-net-next-driver-removal-v1-v2-13-08a5b59784d5@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> The pcnet was written by David A. Hindsh
Hinds again
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Jakub Raczynski @ 2026-04-23 9:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <52b06f0a-8283-4903-9d8a-2bbdf637dd5d@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]
On Wed, Apr 22, 2026 at 06:15:20PM +0200, Andrew Lunn wrote:
> On Wed, Apr 22, 2026 at 04:15:37PM +0200, Jakub Raczynski wrote:
> > On Wed, Apr 22, 2026 at 02:47:38PM +0200, Andrew Lunn wrote:
> > > > I don't see anything wrong with it?
> > > > - naming is correct, same as stmmac_extra_stats from common.h, as it
> > > > wouldn't compile otherwise
> > > > - string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
> > > > not close
> > > > - ethtool just polls data from driver and in my tests it is ok
> > > > - all instances of 'undeflow' are changed
> > > > - 'underflow' semantic is ok, 'undeflow' is just not correct
> > > >
> > > > Please correct me if I am wrong, but imo no issues with this patch.
> > >
> > > ABI
> > >
> > > This name is published as part of the kAPI. You are changing its
> > > name. User space could be looking for this name, even thought it has a
> > > typo in it.
> > >
> > > Andrew
> > >
> > I don't think it is? This part of extra stats (struct stmmac_extra_stats) and
> > is not part of standard ABI from
> > Documentation/ABI/testing/sysfs-class-net-statistics
> > nor is mentioned in
> > Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
> >
> > These extra stats are specific to stmmac driver and most of these are more
> > than standard
> > https://www.kernel.org/doc/html/v7.0/networking/statistics.html#c.rtnl_link_stats64
> > This name does not exist outside stmmac driver, so while some application may
> > expect this (stmmac specific app), question is should this typo stick?
>
> 47dd7a540b8a0 drivers/net/stmmac/stmmac_ethtool.c (Giuseppe Cavallaro 2009-10-14 15:13:45 -0700 81) STMMAC_STAT(tx_undeflow_irq),
>
> It has been exposed to user space for 17 years. In that time, there
> could well be stmmac specific apps using it.
>
> Just because it is not documented as ABI does not make it not ABI.
>
> Andrew
>
Sure, up to you whether NAK or ACK this change.
IMO this name is specific to stmmac and should not be part of any app,
as monitoring tools should be more universal. When monitoring interface this
field will show some other way, via dropped packets and then you would use
driver specific fields for debugging.
Problem is, quick search on github shows this change propagated through
hundreds of Linux forks or different RTOS. But no public app using this found,
at least C app (but well, I didn't browse everything for obvious reasons).
Funny how typo will live everywhere and not be fixed.
So this change would make it differ from all the forks/RTOS'es that will
probably never fix this. So thats the downside.
Question is whether this should then remain that way forever?
And was it really part of some ABI if no one noticed?
Regards
Jakub Raczynski
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH net v2 12/15] drivers: net: 8390: AX88190: Remove this driver
From: Bjørn Mork @ 2026-04-23 9:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Geert Uytterhoeven, Michael Fritscher, Byron Stanoszek,
Daniel Palmer, linux-kernel, netdev, linux-doc
In-Reply-To: <20260422-v7-0-0-net-next-driver-removal-v1-v2-12-08a5b59784d5@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> The ax88190 was written by David A. Hindsh
Hinds
^ permalink raw reply
* Re: [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe
From: Kory Maincent @ 2026-04-23 9:05 UTC (permalink / raw)
To: Corey Leavitt via B4 Relay
Cc: corey, Oleksij Rempel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Heiner Kallweit, Russell King,
Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260423-pse-notifier-decouple-v1-0-86ed750a9d62@leavitt.info>
Hello Corey,
On Thu, 23 Apr 2026 01:42:13 -0600
Corey Leavitt via B4 Relay <devnull+corey.leavitt.info@kernel.org> wrote:
> On systems where a PSE controller driver loads as a module and a
> device-tree PHY node carries a `pses = <&pse_pi>` reference,
> fwnode_mdiobus_register_phy() tries to resolve the PSE handle before
> the controller driver has probed. of_pse_control_get() returns
> -EPROBE_DEFER, the enclosing MDIO/DSA probe fails, and driver-core
> re-queues the work. The retry loop spins until the PSE driver module
> loads and its controller registers.
I will take a look at your series but FYI there was already a RFC series
tackling this issue:
https://lore.kernel.org/lkml/20260330132952.2950531-4-github@szelinsky.de/
It rose a debate and there was currently no final solution.
> Commit fa2f0454174c ("net: pse-pd: Introduce attached_phydev to pse
> control") made each retry expensive. It reordered
> fwnode_mdiobus_register_phy() so the PHY is registered before the
> PSE lookup. Every deferral now performs a full
> phy_device_register() / phy_device_remove() cycle. On a board with a
> sufficiently tight watchdog the retry loop can starve the watchdog
> kthread. On the reporting hardware (MT7621 + gpio-wdt, 1-second
> margin) the retry loop converts a slow probe phase into a reset
> before userspace loads.
>
> The affected population today looks small. OpenWrt, where PSE
> actually ships, is still on 6.12 (pre-regression), and most
> environments with CONFIG_PSE_*=m do not have boards whose DT
> references a PSE controller from a PHY. Still, the mechanism is
> general. Any modular PSE driver combined with the documented
> `pses = <&...>` binding reproduces the retry loop. Whether it
> reaches brick-grade or merely slow/flaky boot depends on local
> watchdog timing. More exposure is expected as distribution and
> embedded kernels move to 6.13 and later.
>
> The narrow fix would be to partially revert the ordering in
> fa2f0454174c so each defer is cheap again. That keeps the same
> architecture (fwnode_mdio holding PSE knowledge, -EPROBE_DEFER
> flowing across the subsystem boundary), and any future reorder
> reintroduces the same class of bug. This series takes the larger
> fix: decouple PSE controller lookup from MDIO registration entirely.
> pse_core now publishes a BLOCKING_NOTIFIER chain with REGISTERED
> and UNREGISTERED events. phy_device subscribes, owns phydev->psec
> lifetime, and attaches PSE handles in response to controller
> lifecycle rather than during probe. fwnode_mdio loses its PSE
> awareness, and -EPROBE_DEFER no longer flows out of fwnode_mdio.
>
> Patch breakdown:
>
> 1. Scope the pse_control regulator handle to kref lifetime
> (Fixes: d83e13761d5b). A latent bug that patch 4 makes
> reachable.
> 2. Add the notifier chain (enum, head, register/unregister
> helpers). Pure infrastructure. No subscribers yet, no
> observable change.
> 3. Fire REGISTERED and UNREGISTERED events from the controller
> register/unregister paths. Still no subscribers, still no
> observable change.
> 4. Subscribe from the PHY layer, take ownership of phydev->psec
> via the notifier, and remove fwnode_find_pse_control() from
> fwnode_mdio.
>
> Patch 1 is bundled here per stable-kernel-rules section 4
> reachability guidance. On mainline today, with no notifier
> subscriber, no caller drives the dangling regulator-handle sequence.
> Patches 2 and 3 are deliberately split to separate "add
> infrastructure" from "wire it up". Happy to fold them if maintainers
> prefer the combined form.
>
> Validated on a Cudy C200P (MT7621 + IP804AR) running an OpenWrt
> build of 6.18.21 with the series applied. A lockdep build
> (CONFIG_PROVE_LOCKING + CONFIG_DEBUG_ATOMIC_SLEEP) shows no splats
> from the series' code paths during boot, PHY attach, PHY detach, or
> a full controller unbind/rebind cycle. ethtool --set-pse drives all
> four PoE-capable LAN ports, and a Ruckus H510 class-4 PD plugged
> into lan3 negotiates and receives 48 V.
>
> The C200P has no SFP cage, so the SFP path change in sfp.c
> (phy_device_register -> phy_device_register_locked) isn't exercised
> on the bench. Verified by call-graph audit: every path reaching
> sfp_sm_probe_phy() holds rtnl at entry, via sfp_timeout,
> sfp_check_state, sfp_probe, sfp_remove, or
> sfp_bus_{add,del}_upstream.
>
> Not addressed by this series: ethtool --show-pse returns "No data
> available" on DSA netdevs in 6.18, because dev->phydev is NULL for
> DSA-frontend netdevs and ethnl_req_get_phydev() therefore returns
> NULL. That's a DSA / ethtool integration quirk that predates this
> work.
>
> Sending as RFC because this is my first net-next series. I'd
> appreciate maintainer guidance on whether patch 1 should go to net
> rather than net-next, and whether the patch 2/3 split is preferred
> to the combined form.
>
> Signed-off-by: Corey Leavitt <corey@leavitt.info>
> ---
> Corey Leavitt (4):
> net: pse-pd: scope pse_control regulator handle to kref lifetime
> net: pse-pd: add notifier chain for controller lifecycle events
> net: pse-pd: fire lifecycle events on controller register/unregister
> net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio hook
>
> drivers/net/mdio/fwnode_mdio.c | 34 ----------
> drivers/net/phy/phy_device.c | 144
> ++++++++++++++++++++++++++++++++++++++--- drivers/net/phy/sfp.c |
> 2 +- drivers/net/pse-pd/pse_core.c | 60 ++++++++++++++++-
> include/linux/phy.h | 2 +
> include/linux/pse-pd/pse.h | 41 ++++++++++++
> 6 files changed, 236 insertions(+), 47 deletions(-)
> ---
> base-commit: 1f5ffc672165ff851063a5fd044b727ab2517ae3
> change-id: 20260422-pse-notifier-decouple-efa80d77f4be
>
> Best regards,
> --
> Corey Leavitt <corey@leavitt.info>
>
>
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next v6 3/3] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: lizhi2 @ 2026-04-23 8:56 UTC (permalink / raw)
To: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier
Cc: ningyu, linmin, pinkesh.vaghela, pritesh.patel, weishangjuan,
horms, Zhi Li
In-Reply-To: <20260423085501.760-1-lizhi2@eswincomputing.com>
From: Zhi Li <lizhi2@eswincomputing.com>
Enable the on-board Gigabit Ethernet controller on the
HiFive Premier P550 development board.
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
---
.../devicetree/bindings/mfd/syscon.yaml | 2 +
.../dts/eswin/eic7700-hifive-premier-p550.dts | 232 ++++++++++++++++++
arch/riscv/boot/dts/eswin/eic7700.dtsi | 103 ++++++++
3 files changed, 337 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index e57add2bacd3..89e90b3f12a9 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -61,6 +61,7 @@ select:
- cirrus,ep7209-syscon2
- cirrus,ep7209-syscon3
- cnxt,cx92755-uc
+ - eswin,eic7700-syscfg
- freecom,fsg-cs2-system-controller
- fsl,imx93-aonmix-ns-syscfg
- fsl,imx93-wakeupmix-syscfg
@@ -173,6 +174,7 @@ properties:
- cirrus,ep7209-syscon2
- cirrus,ep7209-syscon3
- cnxt,cx92755-uc
+ - eswin,eic7700-syscfg
- freecom,fsg-cs2-system-controller
- fsl,imx93-aonmix-ns-syscfg
- fsl,imx93-wakeupmix-syscfg
diff --git a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
index 131ed1fc6b2e..12e032dbe88d 100644
--- a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
+++ b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
@@ -13,11 +13,243 @@ / {
aliases {
serial0 = &uart0;
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
};
chosen {
stdout-path = "serial0:115200n8";
};
+
+ vcc_1v8: vcc1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&xtal24m {
+ clock-frequency = <24000000>;
+ clock-output-names = "xtal24m";
+};
+
+&pinctrl {
+ status = "okay";
+ vrgmii-supply = <&vcc_1v8>;
+
+ pinctrl_gpio0: gpio0-grp {
+ gpio0-pins {
+ pins = "gpio0";
+ function = "gpio";
+ input-enable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio5: gpio5-grp {
+ gpio5-pins {
+ pins = "gpio5";
+ function = "gpio";
+ input-enable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio11: gpio11-grp {
+ gpio11-pins {
+ pins = "gpio11";
+ function = "gpio";
+ input-enable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio14: gpio14-grp {
+ gpio14-pins {
+ pins = "mode_set1";
+ function = "gpio";
+ input-disable;
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_gpio15: gpio15-grp {
+ gpio15-pins {
+ pins = "mode_set2";
+ function = "gpio";
+ input-enable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio28: gpio28-grp {
+ gpio28-pins {
+ pins = "gpio28";
+ function = "gpio";
+ input-enable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio43: gpio43-grp {
+ gpio43-pins {
+ pins = "usb1_pwren";
+ function = "gpio";
+ input-disable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio71: gpio71-grp {
+ gpio71-pins {
+ pins = "mipi_csi0_xhs";
+ function = "gpio";
+ input-disable;
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_gpio74: gpio74-grp {
+ gpio74-pins {
+ pins = "mipi_csi1_xhs";
+ function = "gpio";
+ input-disable;
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_gpio76: gpio76-grp {
+ gpio76-pins {
+ pins = "mipi_csi2_xvs";
+ function = "gpio";
+ input-disable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio77: gpio77-grp {
+ gpio77-pins {
+ pins = "mipi_csi2_xhs";
+ function = "gpio";
+ input-disable;
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_gpio79: gpio79-grp {
+ gpio79-pins {
+ pins = "mipi_csi3_xvs";
+ function = "gpio";
+ input-disable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio80: gpio80-grp {
+ gpio80-pins {
+ pins = "mipi_csi3_xhs";
+ function = "gpio";
+ input-disable;
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_gpio82: gpio82-grp {
+ gpio82-pins {
+ pins = "mipi_csi4_xvs";
+ function = "gpio";
+ input-disable;
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_gpio84: gpio84-grp {
+ gpio84-pins {
+ pins = "mipi_csi4_mclk";
+ function = "gpio";
+ input-disable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio85: gpio85-grp {
+ gpio85-pins {
+ pins = "mipi_csi5_xvs";
+ function = "gpio";
+ input-disable;
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_gpio94: gpio94-grp {
+ gpio94-pins {
+ pins = "s_mode";
+ function = "gpio";
+ input-disable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio106: gpio106-grp {
+ gpio106-pins {
+ pins = "gpio106";
+ function = "gpio";
+ input-disable;
+ bias-disable;
+ };
+ };
+
+ pinctrl_gpio111: gpio111-grp {
+ gpio111-pins {
+ pins = "gpio111";
+ function = "gpio";
+ input-disable;
+ bias-disable;
+ };
+ };
+};
+
+&gmac0 {
+ phy-handle = <&gmac0_phy0>;
+ phy-mode = "rgmii-id";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio106>;
+ rx-internal-delay-ps = <20>;
+ tx-internal-delay-ps = <100>;
+ status = "okay";
+};
+
+&gmac0_mdio {
+ gmac0_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id001c.c916";
+ reg = <0>;
+ reset-gpios = <&gpioD 10 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ };
+};
+
+&gmac1 {
+ phy-handle = <&gmac1_phy0>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio111>;
+ rx-internal-delay-ps = <200>;
+ tx-internal-delay-ps = <200>;
+ status = "okay";
+};
+
+&gmac1_mdio {
+ gmac1_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id001c.c916";
+ reg = <0>;
+ reset-gpios = <&gpioD 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ };
};
&uart0 {
diff --git a/arch/riscv/boot/dts/eswin/eic7700.dtsi b/arch/riscv/boot/dts/eswin/eic7700.dtsi
index c3ed93008bca..5690d4c6981b 100644
--- a/arch/riscv/boot/dts/eswin/eic7700.dtsi
+++ b/arch/riscv/boot/dts/eswin/eic7700.dtsi
@@ -5,6 +5,9 @@
/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/reset/eswin,eic7700-reset.h>
+
/ {
#address-cells = <2>;
#size-cells = <2>;
@@ -202,6 +205,11 @@ pmu {
<0x00000000 0x0000000f 0xfffffffc 0x000000ff 0x00000078>;
};
+ xtal24m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ };
+
soc {
compatible = "simple-bus";
ranges;
@@ -245,6 +253,83 @@ plic: interrupt-controller@c000000 {
#interrupt-cells = <1>;
};
+ hsp_power_domain: bus@50400000 {
+ compatible = "simple-pm-bus";
+ ranges;
+ clocks = <&clk 171>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ hsp_sp_csr: hsp-sp-top-csr@50440000 {
+ compatible = "eswin,eic7700-syscfg", "syscon";
+ reg = <0x0 0x50440000 0x0 0x2000>;
+ };
+
+ gmac0: ethernet@50400000 {
+ compatible = "eswin,eic7700-qos-eth", "snps,dwmac-5.20";
+ reg = <0x0 0x50400000 0x0 0x10000>;
+ interrupts = <61>;
+ interrupt-names = "macirq";
+ clocks = <&clk 186>,
+ <&clk 171>,
+ <&clk 40>,
+ <&clk 193>;
+ clock-names = "axi", "cfg", "stmmaceth", "tx";
+ resets = <&reset EIC7700_RESET_HSP_ETH0_ARST>;
+ reset-names = "stmmaceth";
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118 0x114 0x11c>;
+ snps,aal;
+ snps,fixed-burst;
+ snps,tso;
+ snps,axi-config = <&stmmac_axi_setup_gmac0>;
+ status = "disabled";
+
+ gmac0_mdio: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ stmmac_axi_setup_gmac0: stmmac-axi-config {
+ snps,blen = <0 0 0 0 16 8 4>;
+ snps,rd_osr_lmt = <2>;
+ snps,wr_osr_lmt = <2>;
+ };
+ };
+
+ gmac1: ethernet@50410000 {
+ compatible = "eswin,eic7700-qos-eth-clk-inversion", "snps,dwmac-5.20";
+ reg = <0x0 0x50410000 0x0 0x10000>;
+ interrupts = <70>;
+ interrupt-names = "macirq";
+ clocks = <&clk 186>,
+ <&clk 171>,
+ <&clk 40>,
+ <&clk 194>;
+ clock-names = "axi", "cfg", "stmmaceth", "tx";
+ resets = <&reset EIC7700_RESET_HSP_ETH1_ARST>;
+ reset-names = "stmmaceth";
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x200 0x208 0x218 0x214 0x21c>;
+ snps,aal;
+ snps,fixed-burst;
+ snps,tso;
+ snps,axi-config = <&stmmac_axi_setup_gmac1>;
+ status = "disabled";
+
+ gmac1_mdio: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ stmmac_axi_setup_gmac1: stmmac-axi-config {
+ snps,blen = <0 0 0 0 16 8 4>;
+ snps,rd_osr_lmt = <2>;
+ snps,wr_osr_lmt = <2>;
+ };
+ };
+ };
+
uart0: serial@50900000 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x50900000 0x0 0x10000>;
@@ -341,5 +426,23 @@ gpioD: gpio-port@3 {
#gpio-cells = <2>;
};
};
+
+ pinctrl: pinctrl@51600080 {
+ compatible = "eswin,eic7700-pinctrl";
+ reg = <0x0 0x51600080 0x0 0x1fff80>;
+ };
+
+ clk: clock-controller@51828000 {
+ compatible = "eswin,eic7700-clock";
+ reg = <0x0 0x51828000 0x0 0x300>;
+ clocks = <&xtal24m>;
+ #clock-cells = <1>;
+ };
+
+ reset: reset-controller@51828300 {
+ compatible = "eswin,eic7700-reset";
+ reg = <0x0 0x51828300 0x0 0x200>;
+ #reset-cells = <1>;
+ };
};
};
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 2/3] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
From: lizhi2 @ 2026-04-23 8:56 UTC (permalink / raw)
To: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier
Cc: ningyu, linmin, pinkesh.vaghela, pritesh.patel, weishangjuan,
horms, Zhi Li
In-Reply-To: <20260423085501.760-1-lizhi2@eswincomputing.com>
From: Zhi Li <lizhi2@eswincomputing.com>
The second Ethernet controller (eth1) on the Eswin EIC7700 SoC may fail
to sample RX data correctly at Gigabit speed due to EIC7700-specific
receive clock to data skew at the MAC input in the silicon.
The existing internal delay configuration does not provide sufficient
adjustment range to compensate for this condition at 1000Mbps.
Update the EIC7700 DWMAC glue driver to apply EIC7700-specific clock
sampling inversion only during Gigabit operation on MAC instances
that require it.
TXD and RXD delay registers are explicitly cleared during initialization
to override any residual configuration left by the bootloader. All HSP
CSR register accesses are performed only after the required clocks are
enabled.
Fixes: ea77dbbdbc4e ("net: stmmac: add Eswin EIC7700 glue driver")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
---
.../ethernet/stmicro/stmmac/dwmac-eic7700.c | 183 ++++++++++++++----
1 file changed, 140 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
index bcb8e000e720..33144611da8d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
@@ -28,20 +28,40 @@
/*
* TX/RX Clock Delay Bit Masks:
- * - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.1ns per bit)
- * - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.1ns per bit)
+ * - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.02ns per bit)
+ * - TX Invert : bit [15]
+ * - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.02ns per bit)
+ * - RX Invert : bit [31]
*/
#define EIC7700_ETH_TX_ADJ_DELAY GENMASK(14, 8)
#define EIC7700_ETH_RX_ADJ_DELAY GENMASK(30, 24)
+#define EIC7700_ETH_TX_INV_DELAY BIT(15)
+#define EIC7700_ETH_RX_INV_DELAY BIT(31)
-#define EIC7700_MAX_DELAY_UNIT 0x7F
+#define EIC7700_MAX_DELAY_STEPS 0x7F
+#define EIC7700_DELAY_STEP_PS 20
+#define EIC7700_MAX_DELAY_PS \
+ (EIC7700_MAX_DELAY_STEPS * EIC7700_DELAY_STEP_PS)
static const char * const eic7700_clk_names[] = {
"tx", "axi", "cfg",
};
+struct eic7700_dwmac_data {
+ bool rgmii_rx_clk_invert;
+};
+
struct eic7700_qos_priv {
+ struct device *dev;
struct plat_stmmacenet_data *plat_dat;
+ struct regmap *eic7700_hsp_regmap;
+ u32 eth_axi_lp_ctrl_offset;
+ u32 eth_phy_ctrl_offset;
+ u32 eth_txd_offset;
+ u32 eth_clk_offset;
+ u32 eth_rxd_offset;
+ u32 eth_clk_dly_param;
+ bool eth_rx_clk_inv;
};
static int eic7700_clks_config(void *priv, bool enabled)
@@ -61,8 +81,28 @@ static int eic7700_clks_config(void *priv, bool enabled)
static int eic7700_dwmac_init(struct device *dev, void *priv)
{
struct eic7700_qos_priv *dwc = priv;
+ int ret;
+
+ ret = eic7700_clks_config(dwc, true);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(dwc->eic7700_hsp_regmap,
+ dwc->eth_phy_ctrl_offset,
+ EIC7700_ETH_TX_CLK_SEL |
+ EIC7700_ETH_PHY_INTF_SELI);
+ if (ret) {
+ eic7700_clks_config(dwc, false);
+ return ret;
+ }
+
+ regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_axi_lp_ctrl_offset,
+ EIC7700_ETH_CSYSREQ_VAL);
+
+ regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_txd_offset, 0);
+ regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_rxd_offset, 0);
- return eic7700_clks_config(dwc, true);
+ return 0;
}
static void eic7700_dwmac_exit(struct device *dev, void *priv)
@@ -88,18 +128,35 @@ static int eic7700_dwmac_resume(struct device *dev, void *priv)
return ret;
}
+static void eic7700_dwmac_fix_speed(void *priv, phy_interface_t interface,
+ int speed, unsigned int mode)
+{
+ struct eic7700_qos_priv *dwc = (struct eic7700_qos_priv *)priv;
+ u32 dly_param = dwc->eth_clk_dly_param;
+
+ switch (speed) {
+ case SPEED_1000:
+ if (dwc->eth_rx_clk_inv)
+ dly_param |= EIC7700_ETH_RX_INV_DELAY;
+ break;
+ case SPEED_100:
+ case SPEED_10:
+ break;
+ default:
+ dev_err(dwc->dev, "invalid speed %u\n", speed);
+ break;
+ }
+
+ regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_clk_offset, dly_param);
+}
+
static int eic7700_dwmac_probe(struct platform_device *pdev)
{
+ const struct eic7700_dwmac_data *data;
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
struct eic7700_qos_priv *dwc_priv;
- struct regmap *eic7700_hsp_regmap;
- u32 eth_axi_lp_ctrl_offset;
- u32 eth_phy_ctrl_offset;
- u32 eth_phy_ctrl_regset;
- u32 eth_rxd_dly_offset;
- u32 eth_dly_param = 0;
- u32 delay_ps;
+ u32 delay_ps, val;
int i, ret;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
@@ -116,70 +173,95 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
if (!dwc_priv)
return -ENOMEM;
+ dwc_priv->dev = &pdev->dev;
+
+ data = device_get_match_data(&pdev->dev);
+ if (!data)
+ return dev_err_probe(&pdev->dev,
+ -EINVAL, "no match data found\n");
+
+ dwc_priv->eth_rx_clk_inv = data->rgmii_rx_clk_invert;
+
/* Read rx-internal-delay-ps and update rx_clk delay */
if (!of_property_read_u32(pdev->dev.of_node,
"rx-internal-delay-ps", &delay_ps)) {
- u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT);
+ if (delay_ps % EIC7700_DELAY_STEP_PS)
+ return dev_err_probe(&pdev->dev, -EINVAL,
+ "rx delay must be multiple of %dps\n",
+ EIC7700_DELAY_STEP_PS);
+
+ if (delay_ps > EIC7700_MAX_DELAY_PS)
+ return dev_err_probe(&pdev->dev, -EINVAL,
+ "rx delay out of range\n");
- eth_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
- eth_dly_param |= FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
- } else {
- return dev_err_probe(&pdev->dev, -EINVAL,
- "missing required property rx-internal-delay-ps\n");
+ val = delay_ps / EIC7700_DELAY_STEP_PS;
+
+ dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
+ dwc_priv->eth_clk_dly_param |=
+ FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
}
/* Read tx-internal-delay-ps and update tx_clk delay */
if (!of_property_read_u32(pdev->dev.of_node,
"tx-internal-delay-ps", &delay_ps)) {
- u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT);
+ if (delay_ps % EIC7700_DELAY_STEP_PS)
+ return dev_err_probe(&pdev->dev, -EINVAL,
+ "tx delay must be multiple of %dps\n",
+ EIC7700_DELAY_STEP_PS);
+
+ if (delay_ps > EIC7700_MAX_DELAY_PS)
+ return dev_err_probe(&pdev->dev, -EINVAL,
+ "tx delay out of range\n");
+
+ val = delay_ps / EIC7700_DELAY_STEP_PS;
- eth_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
- eth_dly_param |= FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
- } else {
- return dev_err_probe(&pdev->dev, -EINVAL,
- "missing required property tx-internal-delay-ps\n");
+ dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
+ dwc_priv->eth_clk_dly_param |=
+ FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
}
- eic7700_hsp_regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
- "eswin,hsp-sp-csr");
- if (IS_ERR(eic7700_hsp_regmap))
+ dwc_priv->eic7700_hsp_regmap =
+ syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "eswin,hsp-sp-csr");
+ if (IS_ERR(dwc_priv->eic7700_hsp_regmap))
return dev_err_probe(&pdev->dev,
- PTR_ERR(eic7700_hsp_regmap),
+ PTR_ERR(dwc_priv->eic7700_hsp_regmap),
"Failed to get hsp-sp-csr regmap\n");
ret = of_property_read_u32_index(pdev->dev.of_node,
"eswin,hsp-sp-csr",
- 1, ð_phy_ctrl_offset);
+ 1, &dwc_priv->eth_phy_ctrl_offset);
if (ret)
return dev_err_probe(&pdev->dev, ret,
"can't get eth_phy_ctrl_offset\n");
- regmap_read(eic7700_hsp_regmap, eth_phy_ctrl_offset,
- ð_phy_ctrl_regset);
- eth_phy_ctrl_regset |=
- (EIC7700_ETH_TX_CLK_SEL | EIC7700_ETH_PHY_INTF_SELI);
- regmap_write(eic7700_hsp_regmap, eth_phy_ctrl_offset,
- eth_phy_ctrl_regset);
-
ret = of_property_read_u32_index(pdev->dev.of_node,
"eswin,hsp-sp-csr",
- 2, ð_axi_lp_ctrl_offset);
+ 2, &dwc_priv->eth_axi_lp_ctrl_offset);
if (ret)
return dev_err_probe(&pdev->dev, ret,
"can't get eth_axi_lp_ctrl_offset\n");
- regmap_write(eic7700_hsp_regmap, eth_axi_lp_ctrl_offset,
- EIC7700_ETH_CSYSREQ_VAL);
+ ret = of_property_read_u32_index(pdev->dev.of_node,
+ "eswin,hsp-sp-csr",
+ 3, &dwc_priv->eth_clk_offset);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "can't get eth_clk_offset\n");
ret = of_property_read_u32_index(pdev->dev.of_node,
"eswin,hsp-sp-csr",
- 3, ð_rxd_dly_offset);
+ 4, &dwc_priv->eth_txd_offset);
if (ret)
return dev_err_probe(&pdev->dev, ret,
- "can't get eth_rxd_dly_offset\n");
+ "can't get eth_txd_offset\n");
- regmap_write(eic7700_hsp_regmap, eth_rxd_dly_offset,
- eth_dly_param);
+ ret = of_property_read_u32_index(pdev->dev.of_node,
+ "eswin,hsp-sp-csr",
+ 5, &dwc_priv->eth_rxd_offset);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "can't get eth_rxd_offset\n");
plat_dat->num_clks = ARRAY_SIZE(eic7700_clk_names);
plat_dat->clks = devm_kcalloc(&pdev->dev,
@@ -208,12 +290,27 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
plat_dat->exit = eic7700_dwmac_exit;
plat_dat->suspend = eic7700_dwmac_suspend;
plat_dat->resume = eic7700_dwmac_resume;
+ plat_dat->fix_mac_speed = eic7700_dwmac_fix_speed;
return devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
}
+static const struct eic7700_dwmac_data eic7700_dwmac_data = {
+ .rgmii_rx_clk_invert = false,
+};
+
+static const struct eic7700_dwmac_data eic7700_dwmac_data_clk_inversion = {
+ .rgmii_rx_clk_invert = true,
+};
+
static const struct of_device_id eic7700_dwmac_match[] = {
- { .compatible = "eswin,eic7700-qos-eth" },
+ { .compatible = "eswin,eic7700-qos-eth",
+ .data = &eic7700_dwmac_data,
+ },
+ {
+ .compatible = "eswin,eic7700-qos-eth-clk-inversion",
+ .data = &eic7700_dwmac_data_clk_inversion,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, eic7700_dwmac_match);
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 1/3] dt-bindings: ethernet: eswin: add clock sampling control
From: lizhi2 @ 2026-04-23 8:56 UTC (permalink / raw)
To: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier
Cc: ningyu, linmin, pinkesh.vaghela, pritesh.patel, weishangjuan,
horms, Zhi Li, Conor Dooley
In-Reply-To: <20260423085501.760-1-lizhi2@eswincomputing.com>
From: Zhi Li <lizhi2@eswincomputing.com>
Due to chip backend reasons, there is already an approximately 4-5 ns
skew between the RX clock and data of the eth1 MAC controller inside
the silicon.
For 1000M, the RX clock must be inverted since it is not possible to
meet the RGMII timing requirements using only rx-internal-delay-ps on
the MAC together with the standard 2 ns delay on the PHY. Therefore,
even on a properly designed board, eth1 still requires RX clock
inversion.
This behaviour effectively breaks the RGMII timing assumptions at the
SoC level.
For the TX path of eth1, there is also a skew between the TX clock
and data on the MAC controller inside the silicon. This skew happens
to be approximately 2 ns. Therefore, it can be considered that the
2 ns delay of TX is provided by the MAC, so the TX is compliant with
the RGMII standard.
For 10/100 operation, the approximately 4-5 ns skew in the chip does
not break the standard. The RGMII timing table (Section 3.3) specifies
that for 10/100 operation the maximum value is unspecified:
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/20655/1/RGMIIv2_0_final_hp.pdf
Due to the eth1 silicon behavior described above, a new compatible
string "eswin,eic7700-qos-eth-clk-inversion" is added to the device
tree. This allows the driver to handle the differences between eth1
and eth0 through dedicated logic.
The rx-internal-delay-ps and tx-internal-delay-ps properties now use
minimum and maximum constraints to reflect the actual hardware delay
range (0-2540 ps) applied in 20 ps steps. This relaxes the binding
validation compared to the previous enum-based definition and avoids
regressions for existing DTBs while keeping the same hardware limits.
Treat the RX/TX internal delay properties as optional, board-specific
tuning knobs and remove them from the example to avoid encouraging
their use.
In addition, the binding now includes additional background information
about the HSP CSR registers accessed by the MAC. The TXD and RXD delay
control registers are included so the driver can explicitly clear any
residual configuration left by the bootloader.
Background reference for the High-Speed Subsystem and HSP CSR block is
available in Chapter 10 ("High-Speed Interface") of the EIC7700X SoC
Technical Reference Manual, Part 4
(EIC7700X_SoC_Technical_Reference_Manual_Part4.pdf):
https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
There are currently no in-tree users of the EIC7700 Ethernet driver, so
these changes are safe.
Fixes: 888bd0eca93c ("dt-bindings: ethernet: eswin: Document for EIC7700 SoC")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/net/eswin,eic7700-eth.yaml | 69 +++++++++++++++----
1 file changed, 55 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
index 91e8cd1db67b..0b27719feb7d 100644
--- a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
+++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
@@ -20,6 +20,7 @@ select:
contains:
enum:
- eswin,eic7700-qos-eth
+ - eswin,eic7700-qos-eth-clk-inversion
required:
- compatible
@@ -29,7 +30,9 @@ allOf:
properties:
compatible:
items:
- - const: eswin,eic7700-qos-eth
+ - enum:
+ - eswin,eic7700-qos-eth
+ - eswin,eic7700-qos-eth-clk-inversion
- const: snps,dwmac-5.20
reg:
@@ -63,16 +66,29 @@ properties:
- const: stmmaceth
rx-internal-delay-ps:
- enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+ minimum: 0
+ maximum: 2540
+ multipleOf: 20
tx-internal-delay-ps:
- enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+ minimum: 0
+ maximum: 2540
+ multipleOf: 20
eswin,hsp-sp-csr:
description:
HSP CSR is to control and get status of different high-speed peripherals
(such as Ethernet, USB, SATA, etc.) via register, which can tune
board-level's parameters of PHY, etc.
+
+ Additional background information about the High-Speed Subsystem
+ and the HSP CSR block is available in Chapter 10 ("High-Speed Interface")
+ of the EIC7700X SoC Technical Reference Manual, Part 4
+ (EIC7700X_SoC_Technical_Reference_Manual_Part4.pdf). The manual is
+ publicly available at
+ https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
+
+ This reference is provided for background information only.
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
@@ -82,6 +98,8 @@ properties:
- description: Offset of AXI clock controller Low-Power request
register
- description: Offset of register controlling TX/RX clock delay
+ - description: Offset of register controlling TXD delay
+ - description: Offset of register controlling RXD delay
required:
- compatible
@@ -93,8 +111,6 @@ required:
- phy-mode
- resets
- reset-names
- - rx-internal-delay-ps
- - tx-internal-delay-ps
- eswin,hsp-sp-csr
unevaluatedProperties: false
@@ -104,24 +120,49 @@ examples:
ethernet@50400000 {
compatible = "eswin,eic7700-qos-eth", "snps,dwmac-5.20";
reg = <0x50400000 0x10000>;
+ interrupt-parent = <&plic>;
+ interrupts = <61>;
+ interrupt-names = "macirq";
clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
<&d0_clock 193>;
clock-names = "axi", "cfg", "stmmaceth", "tx";
+ resets = <&reset 95>;
+ reset-names = "stmmaceth";
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118 0x114 0x11c>;
+ phy-handle = <&gmac0_phy0>;
+ phy-mode = "rgmii-id";
+ snps,aal;
+ snps,fixed-burst;
+ snps,tso;
+ snps,axi-config = <&stmmac_axi_setup_gmac0>;
+
+ stmmac_axi_setup_gmac0: stmmac-axi-config {
+ snps,blen = <0 0 0 0 16 8 4>;
+ snps,rd_osr_lmt = <2>;
+ snps,wr_osr_lmt = <2>;
+ };
+ };
+
+ ethernet@50410000 {
+ compatible = "eswin,eic7700-qos-eth-clk-inversion", "snps,dwmac-5.20";
+ reg = <0x50410000 0x10000>;
interrupt-parent = <&plic>;
- interrupts = <61>;
+ interrupts = <70>;
interrupt-names = "macirq";
- phy-mode = "rgmii-id";
- phy-handle = <&phy0>;
- resets = <&reset 95>;
+ clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
+ <&d0_clock 194>;
+ clock-names = "axi", "cfg", "stmmaceth", "tx";
+ resets = <&reset 94>;
reset-names = "stmmaceth";
- rx-internal-delay-ps = <200>;
- tx-internal-delay-ps = <200>;
- eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118>;
- snps,axi-config = <&stmmac_axi_setup>;
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x200 0x208 0x218 0x214 0x21c>;
+ phy-handle = <&gmac1_phy0>;
+ phy-mode = "rgmii-id";
snps,aal;
snps,fixed-burst;
snps,tso;
- stmmac_axi_setup: stmmac-axi-config {
+ snps,axi-config = <&stmmac_axi_setup_gmac1>;
+
+ stmmac_axi_setup_gmac1: stmmac-axi-config {
snps,blen = <0 0 0 0 16 8 4>;
snps,rd_osr_lmt = <2>;
snps,wr_osr_lmt = <2>;
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 0/3] net: stmmac: eic7700: fix EIC7700 eth1 RX sampling timing
From: lizhi2 @ 2026-04-23 8:55 UTC (permalink / raw)
To: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier
Cc: ningyu, linmin, pinkesh.vaghela, pritesh.patel, weishangjuan,
horms, Zhi Li
From: Zhi Li <lizhi2@eswincomputing.com>
v5 -> v6:
- Update DTS/DTSI descriptions to fix invalid phandle references reported by DTC:
- Add missing GMAC provider nodes required for proper hardware description:
- HSP power domain: GMAC nodes moved under this domain to reflect
hardware power hierarchy.
- Clock nodes: added to provide clk phandles referenced by GMAC.
- Reset nodes: added to provide reset phandles referenced by GMAC.
- Pinctrl nodes: defines pinctrl settings for GMAC signals
(pinctrl_gpio106, pinctrl_gpio111).
- Move GMAC nodes under the correct HSP power domain.
- Ensure DTS builds without dtc errors and all phandle references
(clk/reset/pinctrl/power-domain) are valid.
- This update does not change runtime behavior; it only improves DTS
consistency and resolves issues reported by dtc.
- Note:
- The patch 3/3 for DTS changes in this series provide an overview of the GMAC
integration and its dependencies, as discussed previously:
https://lore.kernel.org/lkml/64bf6b40-b947-4ffa-8d48-4d6341931327@lunn.ch/
- It is **not intended for upstream inclusion** in its current form,
and is provided solely for architecture overview and integration
context.
- A fully cleaned and upstream-ready DTS series will be submitted
separately once all related components (pinctrl, clock, power-domain,
etc.) are finalized.
- dtbs_check has been run on top of net-next for reference purposes.
Remaining warnings are expected due to missing EIC7700 clock binding[1]
in net-next and do not reflect issues in the DTS design itself.
- One remaining warning:
- eswin,eic7700-clock
- The clock binding has already been applied to upstream and is present
in mainline, but not yet available in net-next.
- The syscon binding is extended in this series to include the
eswin,eic7700-syscfg compatible.
- Any further refinement of the syscfg binding will be handled in
separate patches if needed.
- Dependencies:
- [1]EIC7700 clock binding:
https://lore.kernel.org/lkml/20260303080637.2100-1-dongxuyang@eswincomputing.com/
(already applied to upstream)
- Link to v5:
https://lore.kernel.org/lkml/20260324073017.376-1-lizhi2@eswincomputing.com/
v4 -> v5:
- eswin,eic7700-eth.yaml:
- Add Acked-by from Conor Dooley
- No functional changes
- Update dwmac-eic7700.c:
- Disable clocks on the error path to fix a clock leak in
eic7700_dwmac_init() when regmap_set_bits() fails
(reported by Simon Horman <horms@kernel.org>)
- Link to v4:
https://lore.kernel.org/lkml/20260313075234.1567-1-lizhi2@eswincomputing.com/
v3 -> v4:
- Update eswin,eic7700-eth.yaml:
- Improve commit message in dt-bindings patch to clarify the
hardware difference of the eth1 MAC and why a new compatible
string is required.
- Move the newly added eswin,hsp-sp-csr item to the end of the list
to avoid inserting entries in the middle of the binding schema.
- Simplify the compatible schema by replacing the previous oneOf
construct with an enum.
- Update dwmac-eic7700.c:
- Fix build issues.
- Adjust code to match the updated binding definition.
- Update DTS/DTSI descriptions:
- Move SoC-level descriptions to the .dtsi file.
- Keep board-specific configuration in the .dts file.
- Link to v3:
https://lore.kernel.org/lkml/20260303061525.846-1-lizhi2@eswincomputing.com/
v2 -> v3:
- Update eswin,eic7700-eth.yaml:
- Extend rx-internal-delay-ps and tx-internal-delay-ps range
from 0-2400 to 0-2540 to match the full 7-bit hardware delay
field (127 * 20 ps).
- Add "multipleOf: 20" constraint to reflect the 20 ps hardware
step size.
- Make rx-internal-delay-ps and tx-internal-delay-ps optional.
A well-designed board should not require internal delay tuning.
- Remove rx-internal-delay-ps and tx-internal-delay-ps from the
example to avoid encouraging blind copy into board DTs.
- Update dwmac-eic7700.c:
- Treat rx-internal-delay-ps and tx-internal-delay-ps as optional
DT properties.
- Apply delay configuration only when properties are present.
- Keep TX/RX delay registers cleared by default to ensure a
deterministic state when no delay is specified.
- Describe Ethernet configuration for the HiFive Premier P550 board:
- Add GMAC controller nodes for the HiFive Premier P550 board
to describe the on-board Ethernet configuration.
The Ethernet controller depends on clock, reset, pinctrl
and HSP subsystem providers which are currently under
upstream review. These dependent nodes will be submitted
separately once the corresponding drivers are merged.
Due to these missing dependencies, dt-binding-check may
report warnings or failures for this series.
- No functional changes to RX clock inversion logic.
- Link to v2:
https://lore.kernel.org/lkml/20260209094628.886-1-lizhi2@eswincomputing.com/
- This series is based on the EIC7700 clock support series:
https://lore.kernel.org/all/20260210095008.726-1-dongxuyang@eswincomputing.com/
The clock series is currently under review.
v1 -> v2:
- Update eswin,eic7700-eth.yaml:
- Drop the vendor-specific properties eswin,rx-clk-invert and
eswin,tx-clk-invert.
- Introduce a distinct compatible string
"eswin,eic7700-qos-eth-clk-inversion" to describe MAC instances that
require internal RGMII clock inversion.
This models the SoC-specific hardware difference directly via the
compatible string and avoids per-board configuration properties.
- Change rx-internal-delay-ps and tx-internal-delay-ps from enum to
minimum/maximum to reflect the actual delay range (0-2400 ps)
- Add reference to High-Speed Subsystem documentation in eswin,hsp-sp-csr
description. The HSP CSR block is described in Chapter 10
("High-Speed Interface") of the EIC7700X SoC Technical Reference Manual,
Part 4 (EIC7700X_SoC_Technical_Reference_Manual_Part4.pdf):
https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
- Update dwmac-eic7700.c:
- Remove handling of eswin,rx-clk-invert and eswin,tx-clk-invert
properties.
- Select RX clock inversion based on the new
"eswin,eic7700-qos-eth-clk-inversion" compatible string, using
match data to apply the required configuration for affected MAC
instances (eth1).
- Link to v1:
https://lore.kernel.org/lkml/20260109080601.1262-1-lizhi2@eswincomputing.com/
Zhi Li (3):
dt-bindings: ethernet: eswin: add clock sampling control
net: stmmac: eic7700: enable clocks before syscon access and correct
RX sampling timing
riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet
controller
.../devicetree/bindings/mfd/syscon.yaml | 2 +
.../bindings/net/eswin,eic7700-eth.yaml | 69 ++++--
.../dts/eswin/eic7700-hifive-premier-p550.dts | 232 ++++++++++++++++++
arch/riscv/boot/dts/eswin/eic7700.dtsi | 103 ++++++++
.../ethernet/stmicro/stmmac/dwmac-eic7700.c | 183 ++++++++++----
5 files changed, 532 insertions(+), 57 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH net v2 10/15] drivers: net: cirrus: mac89x0: Remove this driver
From: Daniel Palmer @ 2026-04-23 8:52 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Geert Uytterhoeven, Andrew Lunn, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Jonathan Corbet, Shuah Khan, Michael Fritscher, Byron Stanoszek,
linux-kernel, netdev, linux-doc, linux-m68k
In-Reply-To: <c0c80113af470b265650405fa24deefe2d82ea24.camel@physik.fu-berlin.de>
Hi Adrian,
On Thu, 23 Apr 2026 at 16:10, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> > Macs do run modern kernels.
>
> Retrocomputing still is not well regarded by some maintainers, it seems :-(.
I've found bugs in drivers by plugging those things into exotic
hardware like my Amiga 4000 and Ultra5 [0].
So, it's not totally pointless. And having a shader capable Amiga[1]
is pretty cool.
Sad to see fun stuff getting pushed out by basically spam bots. :(
0 - https://lists.freedesktop.org/archives/amd-gfx/2025-October/132283.html
1 - https://gist.github.com/fifteenhex/0e5ce8c1614bcec20ed242045c11d1d9
^ permalink raw reply
* Re: [PATCH iproute2] ss: fix vsock port filter
From: Luigi Leonardi @ 2026-04-23 8:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Stefano Garzarella, stefanha, netdev, Mathieu Schroeter,
David Ahern
In-Reply-To: <20260422092100.46744a32@phoenix.local>
On Wed, Apr 22, 2026 at 09:21:00AM -0700, Stephen Hemminger wrote:
>On Wed, 22 Apr 2026 10:03:49 +0200
>Stefano Garzarella <sgarzare@redhat.com> wrote:
>
>> On Wed, 22 Apr 2026 at 01:38, Stephen Hemminger <stephen@networkplumber.org> wrote:
>> >
>> > On Tue, 21 Apr 2026 14:35:12 +0200
>> > Luigi Leonardi <leonardi@redhat.com> wrote:
>> >
>> > > parse_hostcond() uses get_u32() to parse the vsock port into the
>> > > aafilter.port field, which is a long. On 64-bit systems, get_u32()
>> > > only writes the lower 32 bits, leaving the upper 32 bits set from
>> > > the -1 initialization. This causes the port comparison
>> > > "a->port != s->rport" in run_ssfilter() to always fail, since the
>> > > corrupted long value never matches the int rport.
>> > >
>> > > Fix by using get_long() instead, consistent with how AF_PACKET and
>> > > AF_NETLINK handle the same field.
>> > >
>> > > Fixes: c759116a0b2b ("ss: add AF_VSOCK support")
>> > > Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>> > > ---
>> > > misc/ss.c | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/misc/ss.c b/misc/ss.c
>> > > index 14e9f27a..6e3321ac 100644
>> > > --- a/misc/ss.c
>> > > +++ b/misc/ss.c
>> > > @@ -2323,7 +2323,7 @@ void *parse_hostcond(char *addr, bool is_port)
>> > > port = find_port(addr, is_port);
>> > >
>> > > if (port && strcmp(port, "*") &&
>> > > - get_u32((__u32 *)&a.port, port, 0))
>> > > + get_long(&a.port, port, 0))
>> > > return NULL;
>> >
>> > If you use get_long() then the code could get negative values.
>> > Actually have port in ss as signed value seems like a mistake in original design.
>> >
>> > The port in unix domain socket is inode number.
>> > Originally it was int, but got changed to long back in 6.6
>> >
>> > The port in ss cache is int.
>>
>> Yeah, as I mentioned I think the issue was introduced by commit
>> 012cb515 ("ss: change aafilter port from int to long (inode support)").
>
>What about this which avoids the cast but keeps the same semantics.
>
>diff --git a/misc/ss.c b/misc/ss.c
>index 14e9f27a..e830e146 100644
>--- a/misc/ss.c
>+++ b/misc/ss.c
>@@ -2317,14 +2317,16 @@ void *parse_hostcond(char *addr, bool is_port)
>
> if (fam == AF_VSOCK) {
> __u32 cid = ~(__u32)0;
>+ __u32 vport = 0;
>
> a.addr.family = AF_VSOCK;
>
> port = find_port(addr, is_port);
>-
>- if (port && strcmp(port, "*") &&
>- get_u32((__u32 *)&a.port, port, 0))
>- return NULL;
>+ if (port && strcmp(port, "*")) {
>+ if (get_u32(&vport, port, 0))
>+ return NULL;
>+ }
>+ a.port = vport;
>
> if (!is_port && addr[0] && strcmp(addr, "*")) {
> a.addr.bitlen = 32;
>
>
With high enough ports it's not working, I expect to be a problem with
the sign. I'll try updating `struct sockstat` as Stefano suggested.
Luigi
^ permalink raw reply
* Re: [PATCH net] ipv6: validate extension header length before copying to cmsg
From: Paolo Abeni @ 2026-04-23 8:45 UTC (permalink / raw)
To: Qi Tang, davem, dsahern, edumazet, kuba, horms; +Cc: netdev, linux-kernel
In-Reply-To: <20260419150344.624673-1-tpluszz77@gmail.com>
On 4/19/26 5:03 PM, Qi Tang wrote:
> ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}
> cmsgs (and their IPV6_2292* legacy counterparts) by trusting the
> on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.
> The length was validated only at parse time (ipv6_parse_hopopts(),
> etc.). An nftables payload-write expression can rewrite hdrlen after
> parsing and before the skb reaches recvmsg; the write itself is
> in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040
> bytes from an 8-byte header. nftables is reachable from an unprivi-
> leged user namespace, so this is an unprivileged slab-out-of-bounds
> read:
>
> BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540
> put_cmsg+0x3ac/0x540
> udpv6_recvmsg+0xca0/0x1250
> sock_recvmsg+0xdf/0x190
> ____sys_recvmsg+0x1b1/0x620
>
> Clamp each cmsg length against skb_tail_pointer(skb) before calling
> put_cmsg(). Extension headers are kept in the linear skb area by
> pskb_may_pull() during input, so skb_tail_pointer() is the correct
> bound. The check is replicated at each call site (one HbH, four
> RFC2292 sites, and four switch cases in the DSTOPTS/RTHDR/AH walk)
> rather than hoisted out of the switch, to keep the fix minimal and
> backportable; a follow-up cleanup can factor it out. In the walk
> loop a failed check also aborts the walk, since subsequent offsets
> depend on the tampered length.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Qi Tang <tpluszz77@gmail.com>
> ---
> net/ipv6/datagram.c | 35 ++++++++++++++++++++++++++++++-----
> 1 file changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
> index ca3605acb..a7b9f5a24 100644
> --- a/net/ipv6/datagram.c
> +++ b/net/ipv6/datagram.c
> @@ -643,7 +643,10 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
> /* HbH is allowed only once */
> if (np->rxopt.bits.hopopts && (opt->flags & IP6SKB_HOPBYHOP)) {
> u8 *ptr = nh + sizeof(struct ipv6hdr);
> - put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, (ptr[1]+1)<<3, ptr);
> + u16 hbhlen = (ptr[1] + 1) << 3;
> +
> + if (ptr + hbhlen <= skb_tail_pointer(skb))
> + put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, hbhlen, ptr);
The patch looks functionally correct to me, but the above 3 statements
are repeated multiple times. You can put them in a local helper and
avoud a lot of duplicate code.
> }
>
> if (opt->lastopt &&
> @@ -668,27 +671,37 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
> case IPPROTO_DSTOPTS:
> nexthdr = ptr[0];
> len = (ptr[1] + 1) << 3;
> + if (ptr + len > skb_tail_pointer(skb))
> + goto ext_hdr_done;
The packet is corrupted, allowing processing of later rxopt requires the
IMHO not nice empty label. I think it would be better just returning
from this function.
/P
^ 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