* Re: [PATCH net-next v5 2/4] net: phy: c45: add genphy_c45_config_master_slave()
From: Jakub Kicinski @ 2026-06-13 23:59 UTC (permalink / raw)
To: javen
Cc: andrew, hkallweit1, linux, davem, edumazet, pabeni, freddy_gu, nb,
netdev, linux-kernel, daniel, vladimir.oltean
In-Reply-To: <20260611031839.568-3-javen_xu@realsil.com.cn>
On Thu, 11 Jun 2026 11:18:37 +0800 javen wrote:
> + * Returns negative errno code on failure, 0 if Master/Slave didn't change,
> + * or 1 if Master/Slave modes changed.
Returns:
the colon is needed otherwise:
Warning: drivers/net/phy/phy-c45.c:420 No description found for return value of 'genphy_c45_an_setup_master_slave'
There's also an AI review at
https://sashiko.dev/#/patchset/20260611031839.568-3-javen_xu@realsil.com.cn
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net v2] net: skmsg: preserve sg.copy across SG transforms
From: Jakub Kicinski @ 2026-06-13 23:57 UTC (permalink / raw)
To: Yiming Qian
Cc: security, John Fastabend, Jakub Sitnicki, Sabrina Dubroca,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
keenanat2000, netdev, bpf, linux-kernel, stable
In-Reply-To: <20260610062137.49075-1-yimingqian591@gmail.com>
On Wed, 10 Jun 2026 06:21:36 +0000 Yiming Qian wrote:
> The sk_msg sg.copy bitmap is part of the scatterlist entry ownership
> state. A set bit tells sk_msg_compute_data_pointers() not to expose the
> entry through writable BPF ctx->data. This protects entries backed by
> pages that are not private to the sk_msg, such as splice-backed file
> page-cache pages.
Note to other maintainers: please don't commit this yet.
I will send a de-feature for TLS+sockmap to net-next,
if this is in the tree the CI won't ingest it (once CI
goes thru we can merge and fix the conflict).
^ permalink raw reply
* Re: [PATCH net-next v4 0/5] ionic: Expose more port stats to ethtool
From: Jakub Kicinski @ 2026-06-13 23:53 UTC (permalink / raw)
To: Eric Joyner
Cc: netdev, Brett Creeley, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Jacob Keller
In-Reply-To: <20260610061830.51037-1-eric.joyner@amd.com>
On Tue, 9 Jun 2026 23:18:25 -0700 Eric Joyner wrote:
> - The link_down_count from firmware mentioned in v2 was moved back to an
> entry in the general ethtool statistics; the existing driver-calculated
> value for the ethtool ext link is more appropriate due to the firmware
> value being a small size and not resetting between driver loads.
There's a uAPI stat defined for something but you don't use it because
you can't be bothered to handle overflow and reset? What am I missing :/
^ permalink raw reply
* [PATCH] net: airoha: Fix MODULE_LICENSE to match SPDX GPL-2.0-only identifier
From: Wayen.Yan @ 2026-06-13 23:52 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
Both airoha_eth.c and airoha_npu.c declare SPDX-License-Identifier:
GPL-2.0-only but use MODULE_LICENSE("GPL"), which the kernel module
loader interprets as GPL-2.0+ (any GPL version). This mismatch causes
license compliance tools (FOSSology, ScanCode, etc.) to misidentify
the effective license as more permissive than intended.
Replace MODULE_LICENSE("GPL") with MODULE_LICENSE("GPL v2") to
align with the GPL-2.0-only SPDX identifier. Per include/linux/module.h,
"GPL v2" maps to GPL-2.0-only, matching the source files' declared
license.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Wayen <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
drivers/net/ethernet/airoha/airoha_npu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..960727957e 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -3333,6 +3333,6 @@ static struct platform_driver airoha_driver = {
};
module_platform_driver(airoha_driver);
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Lorenzo Bianconi <lorenzo@kernel.org>");
MODULE_DESCRIPTION("Ethernet driver for Airoha SoC");
diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
index 17dbdc8325..870d61fdd9 100644
--- a/drivers/net/ethernet/airoha/airoha_npu.c
+++ b/drivers/net/ethernet/airoha/airoha_npu.c
@@ -826,6 +826,6 @@ MODULE_FIRMWARE(NPU_EN7581_7996_FIRMWARE_DATA);
MODULE_FIRMWARE(NPU_EN7581_7996_FIRMWARE_RV32);
MODULE_FIRMWARE(NPU_AN7583_FIRMWARE_DATA);
MODULE_FIRMWARE(NPU_AN7583_FIRMWARE_RV32);
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Lorenzo Bianconi <lorenzo@kernel.org>");
MODULE_DESCRIPTION("Airoha Network Processor Unit driver");
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next 00/15][pull request] Intel Wired LAN Driver Updates 2026-06-09 (idpf, ice, i40e, iavf, ixgbe, igc, igb, e1000e, e1000)
From: patchwork-bot+netdevbpf @ 2026-06-13 23:50 UTC (permalink / raw)
To: Tony Nguyen; +Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
In-Reply-To: <20260609213559.178657-1-anthony.l.nguyen@intel.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 9 Jun 2026 14:35:41 -0700 you wrote:
> Marco Crivellari replaces obsolete use of system_unbound_wq to
> system_dfl_wq for idpf.
>
> Natalia removes redundant PTP checks on ice.
>
> Corinna Vinschen removes redundant MAC address check on iavf.
>
> [...]
Here is the summary with links:
- [net-next,01/15] idpf: Replace use of system_unbound_wq with system_dfl_wq
https://git.kernel.org/netdev/net-next/c/711bdf0b7879
- [net-next,02/15] ice: remove redundant checks from PTP init
https://git.kernel.org/netdev/net-next/c/e5652e6d37fe
- [net-next,03/15] iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test
https://git.kernel.org/netdev/net-next/c/8538aaea10e1
- [net-next,04/15] net/intel: Replace manual array size calculation with ARRAY_SIZE
https://git.kernel.org/netdev/net-next/c/48d588dc9f26
- [net-next,05/15] ixgbe: e610: remove redundant assignment
https://git.kernel.org/netdev/net-next/c/06be82a0d9d7
- [net-next,06/15] igb: Retrieve Tx timestamp from BH workqueue
(no matching commit)
- [net-next,07/15] igb: use ktime_get_real helpers in igb_ptp_reset()
https://git.kernel.org/netdev/net-next/c/2040b8ba371b
- [net-next,08/15] e1000e: use ktime_get_real_ns() in e1000e_systim_reset()
https://git.kernel.org/netdev/net-next/c/1b4558e0b4e8
- [net-next,09/15] igb: use napi_schedule_irqoff() instead of napi_schedule()
https://git.kernel.org/netdev/net-next/c/ef298ba0f9ed
- [net-next,10/15] igc: use napi_schedule_irqoff() instead of napi_schedule()
https://git.kernel.org/netdev/net-next/c/046100cdeb98
- [net-next,11/15] e1000e: Use __napi_schedule_irqoff()
https://git.kernel.org/netdev/net-next/c/4d9508d97b7b
- [net-next,12/15] e1000: limit endianness conversion to boundary words
https://git.kernel.org/netdev/net-next/c/4cc8566ae0d1
- [net-next,13/15] e1000e: limit endianness conversion to boundary words
https://git.kernel.org/netdev/net-next/c/a5ecafcfb27b
- [net-next,14/15] igb: fix typos in comments
https://git.kernel.org/netdev/net-next/c/2904b67ba2f1
- [net-next,15/15] igc: fix typos in comments
https://git.kernel.org/netdev/net-next/c/d4e035b3a517
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] psample: zero the netlink attribute padding in PSAMPLE_ATTR_DATA
From: Jakub Kicinski @ 2026-06-13 23:48 UTC (permalink / raw)
To: Xiang Mei; +Cc: netdev, davem, yotam.gi, edumazet, pabeni, horms, bestswngs
In-Reply-To: <ohbtwmotp5mvghzjkwpjecz4rglal3ayh5bylw72qkv6fjscii@3ks3kavmycel>
On Sat, 13 Jun 2026 16:33:44 -0700 Xiang Mei wrote:
> That looks better. I just found that nla_reserve can memset for us:
>
> diff --git a/net/psample/psample.c b/net/psample/psample.c
> index 7763662036fb..c112e1f0ccac 100644
> --- a/net/psample/psample.c
> +++ b/net/psample/psample.c
> @@ -476,12 +476,11 @@ void psample_sample_packet(struct psample_group *group,
> goto error;
>
> if (data_len) {
> - int nla_len = nla_total_size(data_len);
> struct nlattr *nla;
>
> - nla = skb_put(nl_skb, nla_len);
> - nla->nla_type = PSAMPLE_ATTR_DATA;
> - nla->nla_len = nla_attr_size(data_len);
> + nla = nla_reserve(nl_skb, PSAMPLE_ATTR_DATA, data_len);
> + if (!nla)
> + goto error;
>
> if (skb_copy_bits(skb, 0, nla_data(nla), data_len))
> goto error;
>
> Let me know if the new patch makes sense.
I assumed the author intentionally was avoiding the memset for
the memory we will override with data. Otherwise the whole dance
could be avoided and nla_put() would have been the answer.
^ permalink raw reply
* Re: [PATCH net-next 06/15] igb: Retrieve Tx timestamp from BH workqueue
From: Jakub Kicinski @ 2026-06-13 23:43 UTC (permalink / raw)
To: anthony.l.nguyen
Cc: Simon Horman, davem, pabeni, edumazet, andrew+netdev, netdev, ade,
dima.ruinskiy, jacob.e.keller, dish, avigailx.dahan,
Kurt Kanzenbach
In-Reply-To: <20260612095742.662653-3-horms@kernel.org>
On Fri, 12 Jun 2026 10:57:44 +0100 Simon Horman wrote:
> > /* reschedule to check later */
> > - schedule_work(&adapter->ptp_tx_work);
> > + queue_work(system_bh_wq, &adapter->ptp_tx_work);
>
> [Severity: High]
> If the hardware timestamp is not yet valid, won't this work item
> unconditionally reschedule itself to system_bh_wq without delay?
This sounds correct, the patch is basically busy polling from a tasklet.
BH workqueue is not just another work queue.
^ permalink raw reply
* [PATCH] net: airoha: Remove dead MT7996 NPU firmware declarations
From: Wayen.Yan @ 2026-06-13 23:40 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
Remove the NPU_EN7581_7996_FIRMWARE_DATA/RV32 #define macros and
their corresponding MODULE_FIRMWARE() declarations. Neither the
en7581_npu_soc_data nor the an7583_npu_soc_data references these
firmware names, and no firmware loading path in the driver ever
requests them. The only references are the #define lines themselves
and the MODULE_FIRMWARE() declarations below.
Keeping dead MODULE_FIRMWARE entries causes modprobe/udev to attempt
pre-loading non-existent firmware files, generating kernel log noise
and misleading distributors about which firmware files to package.
Fixes: 23290c7bc190 ("net: airoha: Introduce Airoha NPU support")
Signed-off-by: Wayen <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_npu.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
index 17dbdc8325..93095f3894 100644
--- a/drivers/net/ethernet/airoha/airoha_npu.c
+++ b/drivers/net/ethernet/airoha/airoha_npu.c
@@ -16,8 +16,6 @@
#define NPU_EN7581_FIRMWARE_DATA "airoha/en7581_npu_data.bin"
#define NPU_EN7581_FIRMWARE_RV32 "airoha/en7581_npu_rv32.bin"
-#define NPU_EN7581_7996_FIRMWARE_DATA "airoha/en7581_MT7996_npu_data.bin"
-#define NPU_EN7581_7996_FIRMWARE_RV32 "airoha/en7581_MT7996_npu_rv32.bin"
#define NPU_AN7583_FIRMWARE_DATA "airoha/an7583_npu_data.bin"
#define NPU_AN7583_FIRMWARE_RV32 "airoha/an7583_npu_rv32.bin"
#define NPU_EN7581_FIRMWARE_RV32_MAX_SIZE 0x200000
@@ -822,8 +820,6 @@ module_platform_driver(airoha_npu_driver);
MODULE_FIRMWARE(NPU_EN7581_FIRMWARE_DATA);
MODULE_FIRMWARE(NPU_EN7581_FIRMWARE_RV32);
-MODULE_FIRMWARE(NPU_EN7581_7996_FIRMWARE_DATA);
-MODULE_FIRMWARE(NPU_EN7581_7996_FIRMWARE_RV32);
MODULE_FIRMWARE(NPU_AN7583_FIRMWARE_DATA);
MODULE_FIRMWARE(NPU_AN7583_FIRMWARE_RV32);
MODULE_LICENSE("GPL");
--
2.51.0
^ permalink raw reply related
* [PATCH] sctp: correct CONFIG_SCTP_DBG_OBJCNT macro name in comment
From: Ethan Nelson-Moore @ 2026-06-13 23:37 UTC (permalink / raw)
To: Simon Horman, linux-sctp, netdev
Cc: Ethan Nelson-Moore, Marcelo Ricardo Leitner, Xin Long,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
A comment in <net/sctp/sctp.h> incorrectly refers to
CONFIG_SCTP_DBG_OBJCOUNT instead of CONFIG_SCTP_DBG_OBJCNT. Correct it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
include/net/sctp/sctp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 58242b37b47a..60b073fd3ed8 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -303,7 +303,7 @@ void sctp_dbg_objcnt_init(struct net *);
static inline void sctp_dbg_objcnt_init(struct net *net) { return; }
-#endif /* CONFIG_SCTP_DBG_OBJCOUNT */
+#endif /* CONFIG_SCTP_DBG_OBJCNT */
#if defined CONFIG_SYSCTL
void sctp_sysctl_register(void);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] psample: zero the netlink attribute padding in PSAMPLE_ATTR_DATA
From: Xiang Mei @ 2026-06-13 23:33 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, yotam.gi, edumazet, pabeni, horms, bestswngs
In-Reply-To: <20260609183018.1764046d@kernel.org>
On Tue, Jun 09, 2026 at 06:30:18PM -0700, Jakub Kicinski wrote:
> On Sat, 6 Jun 2026 20:16:40 -0700 Xiang Mei wrote:
> > psample_sample_packet() open-codes the PSAMPLE_ATTR_DATA attribute.
> > It reserves nla_total_size(data_len) bytes via skb_put() but only writes
> > NLA_HDRLEN + data_len of them, so when data_len is not a multiple of 4 the
> > up to 3 trailing alignment-padding bytes are left uninitialised. The skb
> > head comes from kmalloc_reserve(), which does not zero memory, so those
> > bytes hold stale slab contents that are then broadcast to all listeners on
> > the PSAMPLE_NL_MCGRP_SAMPLE multicast group, leaking kernel heap memory to
> > userspace.
> >
> > Zero the trailing padding after the payload copy.
> >
> > Fixes: 6ae0a6286171 ("net: Introduce psample, a new genetlink channel for packet sampling")
> > Reported-by: Weiming Shi <bestswngs@gmail.com>
> > Assisted-by: Claude:claude-opus-4-8
> > Signed-off-by: Xiang Mei <xmei5@asu.edu>
> > ---
> > net/psample/psample.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/psample/psample.c b/net/psample/psample.c
> > index 7763662036fb..26220dca0f12 100644
> > --- a/net/psample/psample.c
> > +++ b/net/psample/psample.c
> > @@ -485,6 +485,9 @@ void psample_sample_packet(struct psample_group *group,
> >
> > if (skb_copy_bits(skb, 0, nla_data(nla), data_len))
> > goto error;
> > +
> > + memset((unsigned char *)nla + nla->nla_len, 0,
> > + nla_padlen(data_len));
> > }
> >
> > #ifdef CONFIG_INET
>
> Could you see if this diff works? I think it's slightly cleaner:
>
>
> diff --git a/net/psample/psample.c b/net/psample/psample.c
> index 7763662036fb..c112e1f0ccac 100644
> --- a/net/psample/psample.c
> +++ b/net/psample/psample.c
> @@ -476,15 +476,17 @@ void psample_sample_packet(struct psample_group *group,
> goto error;
>
> if (data_len) {
> - int nla_len = nla_total_size(data_len);
> + int nla_len = nla_attr_size(data_len);
> struct nlattr *nla;
>
> nla = skb_put(nl_skb, nla_len);
> nla->nla_type = PSAMPLE_ATTR_DATA;
> - nla->nla_len = nla_attr_size(data_len);
> + nla->nla_len = nla_len;
>
> if (skb_copy_bits(skb, 0, nla_data(nla), data_len))
> goto error;
> +
> + skb_put_zero(nl_skb, nla_padlen(data_len));
That looks better. I just found that nla_reserve can memset for us:
diff --git a/net/psample/psample.c b/net/psample/psample.c
index 7763662036fb..c112e1f0ccac 100644
--- a/net/psample/psample.c
+++ b/net/psample/psample.c
@@ -476,12 +476,11 @@ void psample_sample_packet(struct psample_group *group,
goto error;
if (data_len) {
- int nla_len = nla_total_size(data_len);
struct nlattr *nla;
- nla = skb_put(nl_skb, nla_len);
- nla->nla_type = PSAMPLE_ATTR_DATA;
- nla->nla_len = nla_attr_size(data_len);
+ nla = nla_reserve(nl_skb, PSAMPLE_ATTR_DATA, data_len);
+ if (!nla)
+ goto error;
if (skb_copy_bits(skb, 0, nla_data(nla), data_len))
goto error;
Let me know if the new patch makes sense.
Xiang
> }
>
> #ifdef CONFIG_INET
^ permalink raw reply related
* [PATCH] net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()
From: Wayen.Yan @ 2026-06-13 23:30 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_dev_select_queue(), the expression:
queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES;
implicitly converts to unsigned arithmetic: when skb->priority is 0
(the default for unclassified traffic), (0u - 1u) wraps to UINT_MAX,
and UINT_MAX % 8 = 7, routing default best-effort packets to the
highest-priority QoS queue. This causes QoS inversion where the
majority of traffic on a PON gateway starves actual high-priority
flows (VoIP, gaming, etc.).
Fix by guarding the subtraction: when priority is 0, map to queue 0
(lowest priority), otherwise apply the original (priority - 1) % 8
mapping.
Fixes: 2b288b81560b ("net: airoha: Introduce ndo_select_queue callback")
Signed-off-by: Wayen <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..d476ef83c3 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1933,7 +1933,7 @@ static u16 airoha_dev_select_queue(struct net_device *dev, struct sk_buff *skb,
*/
channel = netdev_uses_dsa(dev) ? skb_get_queue_mapping(skb) : port->id;
channel = channel % AIROHA_NUM_QOS_CHANNELS;
- queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES; /* QoS queue */
+ queue = skb->priority ? (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES : 0;
queue = channel * AIROHA_NUM_QOS_QUEUES + queue;
return queue < dev->num_tx_queues ? queue : 0;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v20 net-next 0/9] octeontx2-af: npc: Enhancements.
From: patchwork-bot+netdevbpf @ 2026-06-13 23:30 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: linux-kernel, netdev, andrew+netdev, davem, donald.hunter,
edumazet, horms, jiri, kuba, pabeni, sgoutham
In-Reply-To: <20260609040453.711932-1-rkannoth@marvell.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 9 Jun 2026 09:34:44 +0530 you wrote:
> This series extends Marvell octeontx2-af support for CN20K NPC (MCAM
> debuggability, allocation policy, default-rule lifetime, optional KPU
> profiles from firmware files, X2/X4 MCAM keyword handling in flows and
> defaults, and dynamic CN20K NPC private state), adds a devlink mechanism
> for multi-value parameters, and moves devlink_nl_param_fill() temporaries
> to the heap so stack usage stays reasonable once union devlink_param_value
> grows (patch 3).
>
> [...]
Here is the summary with links:
- [v20,net-next,1/9] octeontx2-af: enforce single RVU AF probe
https://git.kernel.org/netdev/net-next/c/6056a11b8dc4
- [v20,net-next,2/9] octeontx2-af: npc: cn20k: debugfs enhancements
https://git.kernel.org/netdev/net-next/c/4655902deedf
- [v20,net-next,3/9] devlink: heap-allocate param fill buffers in devlink_nl_param_fill
https://git.kernel.org/netdev/net-next/c/c0e67fd12313
- [v20,net-next,4/9] devlink: Implement devlink param multi attribute nested data values
https://git.kernel.org/netdev/net-next/c/eb7b4d458e0d
- [v20,net-next,5/9] octeontx2-af: npc: cn20k: add subbank search order control
https://git.kernel.org/netdev/net-next/c/7ac9d4c4075c
- [v20,net-next,6/9] octeontx2: cn20k: Coordinate default rules with NIX LF lifecycle
https://git.kernel.org/netdev/net-next/c/aac055dbc0fa
- [v20,net-next,7/9] octeontx2-af: npc: Support for custom KPU profile from filesystem
https://git.kernel.org/netdev/net-next/c/c0c9ac88156a
- [v20,net-next,8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc
https://git.kernel.org/netdev/net-next/c/ad804b325075
- [v20,net-next,9/9] octeontx2-af: npc: cn20k: Allocate npc_priv and dstats dynamically.
https://git.kernel.org/netdev/net-next/c/e1938b10fa26
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 v3 5/6] pds_core: add host backed memory support for firmware
From: Rao, Nikhil @ 2026-06-13 23:26 UTC (permalink / raw)
To: Paolo Abeni, netdev
Cc: Brett Creeley, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, linux-kernel, Eric Joyner, Vamsi Atluri
In-Reply-To: <9166857f-880d-4324-9300-9cb1da600aed@redhat.com>
>> +void pdsc_host_mem_add(struct pdsc *pdsc)
>> +{
[..]
>> +
>> + for (i = 0; i < count; i++) {
>> + err = pdsc_host_mem_add_one(pdsc, i);
>> + if (err)
>> + break;
>
> When pdsc_host_mem_add_one() returns an error, pdsc->host_mem_reqs[i].pg
> will be zero.
In pdsc_host_mem_add_one(), If the MEM_ADD devcmd fails, pg is still
valid (allocated and DMA-mapped). The counter (pdsc->num_host_mem_reqs)
is incremented after both alloc_pages() and dma_map_page() succeed, with
a comment explaining why:
/* Track this allocation so pdsc_host_mem_free() can clean it up */
pdsc->num_host_mem_reqs++;
> Errors are not propagate to the caller...
Partial allocation is acceptable; firmware works with whatever memory it
gets. The initialized entries are tracked by num_host_mem_reqs and
cleaned up correctly on shutdown.
Will address - remove redundant memset, change to dev_warn.
Thanks for the review,
Nikhil
^ permalink raw reply
* [PATCH net-next v3 2/2] net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
From: Johan Alvarado @ 2026-06-13 23:22 UTC (permalink / raw)
To: linusw, alsi, andrew, olteanv, davem, edumazet, kuba, pabeni,
netdev
Cc: linux, namiltd, luizluca, linux-kernel, contact
In-Reply-To: <20260613232136.24246-1-contact@c127.dev>
In addition to SGMII, the RTL8367S SerDes also supports HSGMII, which
carries 2.5 Gbps with the same signaling as SGMII at 2.5x clock rate.
The chip info table already declares HSGMII as a supported interface
mode for external interface 1.
Extend the SGMII configuration path to handle HSGMII, which phylink
represents as 2500base-x:
- Use the HSGMII SerDes tuning parameters and external interface mode,
and mux the SerDes to MAC8 in HSGMII mode. The parameters are again
lifted from the GPL-licensed Realtek rtl8367c vendor driver.
- Advertise 2500base-x and MAC_2500FD on ports whose external
interface supports HSGMII.
- Accept SPEED_2500 in the force mode configuration. The MAC speed
field has no 2.5 Gbps value: the rate is determined by the HSGMII
SerDes configuration, and the vendor driver programs the 1 Gbps
value here, so do the same.
Tested on a Mercusys MR80X v2.20, where the RTL8367S is connected to
the SoC over HSGMII.
Signed-off-by: Johan Alvarado <contact@c127.dev>
---
drivers/net/dsa/realtek/rtl8365mb_main.c | 66 ++++++++++++++++++------
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c
index 89b7608aaa3a..ac5348f505b9 100644
--- a/drivers/net/dsa/realtek/rtl8365mb_main.c
+++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
@@ -41,7 +41,7 @@
* matter.
*
* NOTE: Currently, only the RGMII interface is implemented in this driver. On
- * the RTL8367S, the SGMII interface is also supported.
+ * the RTL8367S, the SGMII and HSGMII interfaces are also supported.
*
* The interrupt line is asserted on link UP/DOWN events. The driver creates a
* custom irqchip to handle this interrupt and demultiplex the events by reading
@@ -603,6 +603,13 @@ static const struct rtl8365mb_jam_tbl_entry rtl8365mb_sds_jam_sgmii[] = {
{ 0x0424, 0xD810 }, { 0x002E, 0x83F2 },
};
+/* HSGMII SerDes tuning parameters, lifted from the vendor driver sources */
+static const struct rtl8365mb_jam_tbl_entry rtl8365mb_sds_jam_hsgmii[] = {
+ { 0x0500, 0x82F0 }, { 0x0501, 0xF195 }, { 0x0502, 0x31A2 },
+ { 0x0503, 0x7960 }, { 0x0504, 0x9728 }, { 0x0423, 0x9D85 },
+ { 0x0424, 0xD810 }, { 0x0001, 0x0F80 }, { 0x002E, 0x83F2 },
+};
+
enum rtl8365mb_phy_interface_mode {
RTL8365MB_PHY_INTERFACE_MODE_INVAL = 0,
RTL8365MB_PHY_INTERFACE_MODE_INTERNAL = BIT(0),
@@ -1150,10 +1157,14 @@ static int rtl8365mb_sds_read(struct realtek_priv *priv, int sds, u16 addr,
return 0;
}
-static int rtl8365mb_ext_config_sgmii(struct realtek_priv *priv, int port)
+static int rtl8365mb_ext_config_sgmii(struct realtek_priv *priv, int port,
+ phy_interface_t interface)
{
const struct rtl8365mb_extint *extint =
rtl8365mb_get_port_extint(priv, port);
+ const struct rtl8365mb_jam_tbl_entry *sds_jam;
+ size_t sds_jam_size;
+ u32 mode;
u16 val;
int ret;
int i;
@@ -1165,6 +1176,16 @@ static int rtl8365mb_ext_config_sgmii(struct realtek_priv *priv, int port)
if (extint->id != 1)
return -EOPNOTSUPP;
+ if (interface == PHY_INTERFACE_MODE_2500BASEX) {
+ sds_jam = rtl8365mb_sds_jam_hsgmii;
+ sds_jam_size = ARRAY_SIZE(rtl8365mb_sds_jam_hsgmii);
+ mode = RTL8365MB_EXT_PORT_MODE_HSGMII;
+ } else {
+ sds_jam = rtl8365mb_sds_jam_sgmii;
+ sds_jam_size = ARRAY_SIZE(rtl8365mb_sds_jam_sgmii);
+ mode = RTL8365MB_EXT_PORT_MODE_SGMII;
+ }
+
/* Hold the embedded DW8051 microcontroller in reset and keep it
* disabled. The vendor driver loads firmware into it to manage the
* SerDes link, but the firmware only duplicates work that phylink
@@ -1192,28 +1213,28 @@ static int rtl8365mb_ext_config_sgmii(struct realtek_priv *priv, int port)
return ret;
/* Tune the SerDes with vendor-prescribed parameters */
- for (i = 0; i < ARRAY_SIZE(rtl8365mb_sds_jam_sgmii); i++) {
- ret = rtl8365mb_sds_write(priv, 0,
- rtl8365mb_sds_jam_sgmii[i].reg,
- rtl8365mb_sds_jam_sgmii[i].val);
+ for (i = 0; i < sds_jam_size; i++) {
+ ret = rtl8365mb_sds_write(priv, 0, sds_jam[i].reg,
+ sds_jam[i].val);
if (ret)
return ret;
}
- /* Mux the SerDes to MAC8 in SGMII mode */
+ /* Mux the SerDes to MAC8 in the requested mode */
ret = regmap_update_bits(priv->map, RTL8365MB_SDS_MISC_REG,
RTL8365MB_SDS_MISC_MAC8_SEL_SGMII_MASK |
RTL8365MB_SDS_MISC_MAC8_SEL_HSGMII_MASK,
- RTL8365MB_SDS_MISC_MAC8_SEL_SGMII_MASK);
+ mode == RTL8365MB_EXT_PORT_MODE_SGMII ?
+ RTL8365MB_SDS_MISC_MAC8_SEL_SGMII_MASK :
+ RTL8365MB_SDS_MISC_MAC8_SEL_HSGMII_MASK);
if (ret)
return ret;
ret = regmap_update_bits(
priv->map, RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(extint->id),
RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(extint->id),
- RTL8365MB_EXT_PORT_MODE_SGMII
- << RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_OFFSET(
- extint->id));
+ mode << RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_OFFSET(
+ extint->id));
if (ret)
return ret;
@@ -1255,7 +1276,8 @@ static int rtl8365mb_ext_config_sgmii(struct realtek_priv *priv, int port)
static bool rtl8365mb_interface_is_serdes(phy_interface_t interface)
{
- return interface == PHY_INTERFACE_MODE_SGMII;
+ return interface == PHY_INTERFACE_MODE_SGMII ||
+ interface == PHY_INTERFACE_MODE_2500BASEX;
}
static int rtl8365mb_sds_config_forcemode(struct realtek_priv *priv, bool link,
@@ -1271,7 +1293,11 @@ static int rtl8365mb_sds_config_forcemode(struct realtek_priv *priv, bool link,
u32 r_speed;
if (link) {
- if (speed == SPEED_1000) {
+ /* The speed field has no value for 2.5 Gbps: the rate is
+ * determined by the HSGMII SerDes configuration, and the
+ * vendor driver programs the 1 Gbps value here.
+ */
+ if (speed == SPEED_2500 || speed == SPEED_1000) {
r_speed = RTL8365MB_PORT_SPEED_1000M;
} else if (speed == SPEED_100) {
r_speed = RTL8365MB_PORT_SPEED_100M;
@@ -1323,7 +1349,11 @@ static int rtl8365mb_ext_config_forcemode(struct realtek_priv *priv, int port,
r_rx_pause = rx_pause ? 1 : 0;
r_tx_pause = tx_pause ? 1 : 0;
- if (speed == SPEED_1000) {
+ /* The speed field has no value for 2.5 Gbps: the rate is
+ * determined by the HSGMII SerDes configuration, and the
+ * vendor driver programs the 1 Gbps value here.
+ */
+ if (speed == SPEED_2500 || speed == SPEED_1000) {
r_speed = RTL8365MB_PORT_SPEED_1000M;
} else if (speed == SPEED_100) {
r_speed = RTL8365MB_PORT_SPEED_100M;
@@ -1403,6 +1433,12 @@ static void rtl8365mb_phylink_get_caps(struct dsa_switch *ds, int port,
if (extint->supported_interfaces & RTL8365MB_PHY_INTERFACE_MODE_SGMII)
__set_bit(PHY_INTERFACE_MODE_SGMII,
config->supported_interfaces);
+
+ if (extint->supported_interfaces & RTL8365MB_PHY_INTERFACE_MODE_HSGMII) {
+ __set_bit(PHY_INTERFACE_MODE_2500BASEX,
+ config->supported_interfaces);
+ config->mac_capabilities |= MAC_2500FD;
+ }
}
static void rtl8365mb_phylink_mac_config(struct phylink_config *config,
@@ -1431,7 +1467,7 @@ static void rtl8365mb_phylink_mac_config(struct phylink_config *config,
}
if (rtl8365mb_interface_is_serdes(state->interface)) {
- ret = rtl8365mb_ext_config_sgmii(priv, port);
+ ret = rtl8365mb_ext_config_sgmii(priv, port, state->interface);
if (ret)
dev_err(priv->dev,
"failed to configure SGMII mode on port %d: %d\n",
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v3 1/2] net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
From: Johan Alvarado @ 2026-06-13 23:22 UTC (permalink / raw)
To: linusw, alsi, andrew, olteanv, davem, edumazet, kuba, pabeni,
netdev
Cc: linux, namiltd, luizluca, linux-kernel, contact
In-Reply-To: <20260613232136.24246-1-contact@c127.dev>
The RTL8367S can mux its embedded SerDes to external interface 1,
which is typically used to connect the switch to a CPU port. The chip
info table already declares SGMII as a supported interface mode for
this chip, but the driver only implements RGMII so far.
Implement SGMII support, with the configuration sequence derived from
the GPL-licensed Realtek rtl8367c vendor driver as distributed in the
Mercusys MR80X GPL code drop:
- Add accessors for the SerDes indirect access registers (SDS_INDACS),
through which the SerDes internal registers are reached.
- Keep the embedded DW8051 microcontroller in reset and disabled. The
vendor driver loads firmware into it to manage the SerDes link, but
analysis of that firmware shows it only duplicates the link
management phylink already performs: it polls the port status and
writes the external interface force registers behind the driver's
back.
- Clear the line rate bypass bit for the external interface, tune the
SerDes with the vendor-prescribed parameters, mux the SerDes to MAC8
in SGMII mode and only then take the SerDes out of reset, as the
vendor driver does.
- After deasserting the SerDes reset, reset the SerDes data path via
the SerDes BMCR register to flush the FIFOs and resync the PLL.
This mirrors what the vendor firmware does right after deasserting
the SerDes reset, and ensures a clean link state from cold boot.
- Force the SGMII link parameters (link, speed, duplex, flow control)
in the SDS_MISC register from the phylink mac_link_up/down
operations, in addition to the usual external interface force
configuration. SGMII in-band autonegotiation is disabled, so only
fixed-link and conventional PHY setups are supported, just like
RGMII.
Tested on a Mercusys MR80X v2.20, where the RTL8367S is connected to
the SoC over SGMII.
Suggested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Johan Alvarado <contact@c127.dev>
---
drivers/net/dsa/realtek/rtl8365mb_main.c | 298 ++++++++++++++++++++++-
1 file changed, 295 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c
index 5ac091bf93c9..89b7608aaa3a 100644
--- a/drivers/net/dsa/realtek/rtl8365mb_main.c
+++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
@@ -40,7 +40,8 @@
* driver has only been tested with a fixed-link, but in principle it should not
* matter.
*
- * NOTE: Currently, only the RGMII interface is implemented in this driver.
+ * NOTE: Currently, only the RGMII interface is implemented in this driver. On
+ * the RTL8367S, the SGMII interface is also supported.
*
* The interrupt line is asserted on link UP/DOWN events. The driver creates a
* custom irqchip to handle this interrupt and demultiplex the events by reading
@@ -129,6 +130,7 @@
/* Chip reset register */
#define RTL8365MB_CHIP_RESET_REG 0x1322
+#define RTL8365MB_CHIP_RESET_DW8051_MASK 0x0010
#define RTL8365MB_CHIP_RESET_SW_MASK 0x0002
#define RTL8365MB_CHIP_RESET_HW_MASK 0x0001
@@ -238,6 +240,49 @@
#define RTL8365MB_EXT_RGMXF_RXDELAY_MASK 0x0007
#define RTL8365MB_EXT_RGMXF_TXDELAY_MASK 0x0008
+/* External interface line rate bypass register - one bit per interface */
+#define RTL8365MB_BYPASS_LINE_RATE_REG 0x03F7
+
+/* SerDes indirect access registers */
+#define RTL8365MB_SDS_INDACS_CMD_REG 0x6600
+#define RTL8365MB_SDS_INDACS_CMD_RUN_MASK 0x0080
+#define RTL8365MB_SDS_INDACS_CMD_WR_MASK 0x0040
+#define RTL8365MB_SDS_INDACS_CMD_INDEX_MASK 0x0007
+#define RTL8365MB_SDS_INDACS_ADR_REG 0x6601
+#define RTL8365MB_SDS_INDACS_DATA_REG 0x6602
+
+/* SerDes miscellaneous configuration register */
+#define RTL8365MB_SDS_MISC_REG 0x1D11
+#define RTL8365MB_SDS_MISC_SGMII_RXFC_MASK 0x4000
+#define RTL8365MB_SDS_MISC_SGMII_TXFC_MASK 0x2000
+#define RTL8365MB_SDS_MISC_MAC8_SEL_HSGMII_MASK 0x0800
+#define RTL8365MB_SDS_MISC_SGMII_FDUP_MASK 0x0400
+#define RTL8365MB_SDS_MISC_SGMII_LINK_MASK 0x0200
+#define RTL8365MB_SDS_MISC_SGMII_SPD_MASK 0x0180
+#define RTL8365MB_SDS_MISC_MAC8_SEL_SGMII_MASK 0x0040
+
+/* SerDes internal registers, accessed via the SDS_INDACS registers. The
+ * BMCR data path reset values set BMCR_ANENABLE | BMCR_ISOLATE (0x1400),
+ * and toggling the vendor-specific low bits from 0x1 to 0x3 triggers a
+ * data path reset and PLL resync.
+ */
+#define RTL8365MB_SDS_REG_BMCR 0x0000
+#define RTL8365MB_SDS_BMCR_DPRST_PHASE1 0x1401
+#define RTL8365MB_SDS_BMCR_DPRST_PHASE2 0x1403
+#define RTL8365MB_SDS_REG_NWAY 0x0002
+#define RTL8365MB_SDS_NWAY_EN_MASK 0x0200
+#define RTL8365MB_SDS_NWAY_RESTART_MASK 0x0100
+#define RTL8365MB_SDS_REG_RESET 0x0003
+#define RTL8365MB_SDS_RESET_DEASSERT 0x7106
+
+/* Embedded DW8051 microcontroller control registers. The microcontroller
+ * can run firmware to manage the SerDes link, but this driver keeps it in
+ * reset and disabled: phylink already performs the link management that
+ * the firmware would otherwise do.
+ */
+#define RTL8365MB_MISC_CFG0_REG 0x130C
+#define RTL8365MB_MISC_CFG0_DW8051_EN_MASK 0x0020
+
/* External interface port speed values - used in DIGITAL_INTERFACE_FORCE */
#define RTL8365MB_PORT_SPEED_10M 0
#define RTL8365MB_PORT_SPEED_100M 1
@@ -551,6 +596,13 @@ static const struct rtl8365mb_jam_tbl_entry rtl8365mb_init_jam_common[] = {
{ 0x1D32, 0x0002 },
};
+/* SGMII SerDes tuning parameters, lifted from the vendor driver sources */
+static const struct rtl8365mb_jam_tbl_entry rtl8365mb_sds_jam_sgmii[] = {
+ { 0x0480, 0x04D7 }, { 0x0481, 0xF994 }, { 0x0482, 0x2420 },
+ { 0x0483, 0x6960 }, { 0x0484, 0x9728 }, { 0x0423, 0x9D85 },
+ { 0x0424, 0xD810 }, { 0x002E, 0x83F2 },
+};
+
enum rtl8365mb_phy_interface_mode {
RTL8365MB_PHY_INTERFACE_MODE_INVAL = 0,
RTL8365MB_PHY_INTERFACE_MODE_INTERNAL = BIT(0),
@@ -1042,6 +1094,212 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_priv *priv, int port,
return 0;
}
+static int rtl8365mb_sds_write(struct realtek_priv *priv, int sds, u16 addr,
+ u16 data)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_write(priv->map, RTL8365MB_SDS_INDACS_DATA_REG, data);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(priv->map, RTL8365MB_SDS_INDACS_ADR_REG, addr);
+ if (ret)
+ return ret;
+
+ val = RTL8365MB_SDS_INDACS_CMD_RUN_MASK |
+ RTL8365MB_SDS_INDACS_CMD_WR_MASK |
+ FIELD_PREP(RTL8365MB_SDS_INDACS_CMD_INDEX_MASK, sds);
+ ret = regmap_write(priv->map, RTL8365MB_SDS_INDACS_CMD_REG, val);
+ if (ret)
+ return ret;
+
+ /* The vendor driver does not poll for completion, but a short delay
+ * is needed before issuing the next command.
+ */
+ usleep_range(10, 50);
+
+ return 0;
+}
+
+static int rtl8365mb_sds_read(struct realtek_priv *priv, int sds, u16 addr,
+ u16 *data)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_write(priv->map, RTL8365MB_SDS_INDACS_ADR_REG, addr);
+ if (ret)
+ return ret;
+
+ val = RTL8365MB_SDS_INDACS_CMD_RUN_MASK |
+ FIELD_PREP(RTL8365MB_SDS_INDACS_CMD_INDEX_MASK, sds);
+ ret = regmap_write(priv->map, RTL8365MB_SDS_INDACS_CMD_REG, val);
+ if (ret)
+ return ret;
+
+ usleep_range(10, 50);
+
+ ret = regmap_read(priv->map, RTL8365MB_SDS_INDACS_DATA_REG, &val);
+ if (ret)
+ return ret;
+
+ *data = val;
+
+ return 0;
+}
+
+static int rtl8365mb_ext_config_sgmii(struct realtek_priv *priv, int port)
+{
+ const struct rtl8365mb_extint *extint =
+ rtl8365mb_get_port_extint(priv, port);
+ u16 val;
+ int ret;
+ int i;
+
+ if (!extint)
+ return -ENODEV;
+
+ /* The SerDes can only be muxed to external interface 1 */
+ if (extint->id != 1)
+ return -EOPNOTSUPP;
+
+ /* Hold the embedded DW8051 microcontroller in reset and keep it
+ * disabled. The vendor driver loads firmware into it to manage the
+ * SerDes link, but the firmware only duplicates work that phylink
+ * already does: it polls the port status and forces the external
+ * interface configuration in the very registers this driver manages.
+ * Letting it run would race with phylink.
+ */
+ ret = regmap_update_bits(priv->map, RTL8365MB_CHIP_RESET_REG,
+ RTL8365MB_CHIP_RESET_DW8051_MASK,
+ RTL8365MB_CHIP_RESET_DW8051_MASK);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(priv->map, RTL8365MB_MISC_CFG0_REG,
+ RTL8365MB_MISC_CFG0_DW8051_EN_MASK, 0);
+ if (ret)
+ return ret;
+
+ /* The vendor driver clears the line rate bypass for all interface
+ * modes except TMII.
+ */
+ ret = regmap_update_bits(priv->map, RTL8365MB_BYPASS_LINE_RATE_REG,
+ BIT(extint->id), 0);
+ if (ret)
+ return ret;
+
+ /* Tune the SerDes with vendor-prescribed parameters */
+ for (i = 0; i < ARRAY_SIZE(rtl8365mb_sds_jam_sgmii); i++) {
+ ret = rtl8365mb_sds_write(priv, 0,
+ rtl8365mb_sds_jam_sgmii[i].reg,
+ rtl8365mb_sds_jam_sgmii[i].val);
+ if (ret)
+ return ret;
+ }
+
+ /* Mux the SerDes to MAC8 in SGMII mode */
+ ret = regmap_update_bits(priv->map, RTL8365MB_SDS_MISC_REG,
+ RTL8365MB_SDS_MISC_MAC8_SEL_SGMII_MASK |
+ RTL8365MB_SDS_MISC_MAC8_SEL_HSGMII_MASK,
+ RTL8365MB_SDS_MISC_MAC8_SEL_SGMII_MASK);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(
+ priv->map, RTL8365MB_DIGITAL_INTERFACE_SELECT_REG(extint->id),
+ RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(extint->id),
+ RTL8365MB_EXT_PORT_MODE_SGMII
+ << RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_OFFSET(
+ extint->id));
+ if (ret)
+ return ret;
+
+ /* Take the SerDes out of reset. The vendor driver does this only
+ * after the SerDes mux and the interface mode are configured.
+ */
+ ret = rtl8365mb_sds_write(priv, 0, RTL8365MB_SDS_REG_RESET,
+ RTL8365MB_SDS_RESET_DEASSERT);
+ if (ret)
+ return ret;
+
+ /* Reset the SerDes data path and resync its PLL, mirroring what the
+ * vendor firmware does right after deasserting the SerDes reset.
+ * This flushes the FIFOs and ensures a clean state for the link,
+ * preventing silent drops and CRC errors.
+ */
+ ret = rtl8365mb_sds_write(priv, 0, RTL8365MB_SDS_REG_BMCR,
+ RTL8365MB_SDS_BMCR_DPRST_PHASE1);
+ if (ret)
+ return ret;
+
+ ret = rtl8365mb_sds_write(priv, 0, RTL8365MB_SDS_REG_BMCR,
+ RTL8365MB_SDS_BMCR_DPRST_PHASE2);
+ if (ret)
+ return ret;
+
+ /* Disable SGMII in-band autonegotiation: the link parameters are
+ * forced in rtl8365mb_phylink_mac_link_up.
+ */
+ ret = rtl8365mb_sds_read(priv, 0, RTL8365MB_SDS_REG_NWAY, &val);
+ if (ret)
+ return ret;
+
+ val &= ~RTL8365MB_SDS_NWAY_EN_MASK;
+ val |= RTL8365MB_SDS_NWAY_RESTART_MASK;
+
+ return rtl8365mb_sds_write(priv, 0, RTL8365MB_SDS_REG_NWAY, val);
+}
+
+static bool rtl8365mb_interface_is_serdes(phy_interface_t interface)
+{
+ return interface == PHY_INTERFACE_MODE_SGMII;
+}
+
+static int rtl8365mb_sds_config_forcemode(struct realtek_priv *priv, bool link,
+ int speed, int duplex, bool tx_pause,
+ bool rx_pause)
+{
+ u32 mask = RTL8365MB_SDS_MISC_SGMII_RXFC_MASK |
+ RTL8365MB_SDS_MISC_SGMII_TXFC_MASK |
+ RTL8365MB_SDS_MISC_SGMII_FDUP_MASK |
+ RTL8365MB_SDS_MISC_SGMII_LINK_MASK |
+ RTL8365MB_SDS_MISC_SGMII_SPD_MASK;
+ u32 val = 0;
+ u32 r_speed;
+
+ if (link) {
+ if (speed == SPEED_1000) {
+ r_speed = RTL8365MB_PORT_SPEED_1000M;
+ } else if (speed == SPEED_100) {
+ r_speed = RTL8365MB_PORT_SPEED_100M;
+ } else if (speed == SPEED_10) {
+ r_speed = RTL8365MB_PORT_SPEED_10M;
+ } else {
+ dev_err(priv->dev, "unsupported port speed %s\n",
+ phy_speed_to_str(speed));
+ return -EINVAL;
+ }
+
+ val |= RTL8365MB_SDS_MISC_SGMII_LINK_MASK;
+ val |= FIELD_PREP(RTL8365MB_SDS_MISC_SGMII_SPD_MASK, r_speed);
+
+ if (duplex == DUPLEX_FULL)
+ val |= RTL8365MB_SDS_MISC_SGMII_FDUP_MASK;
+
+ if (tx_pause)
+ val |= RTL8365MB_SDS_MISC_SGMII_TXFC_MASK;
+
+ if (rx_pause)
+ val |= RTL8365MB_SDS_MISC_SGMII_RXFC_MASK;
+ }
+
+ return regmap_update_bits(priv->map, RTL8365MB_SDS_MISC_REG, mask,
+ val);
+}
+
static int rtl8365mb_ext_config_forcemode(struct realtek_priv *priv, int port,
bool link, int speed, int duplex,
bool tx_pause, bool rx_pause)
@@ -1141,6 +1399,10 @@ static void rtl8365mb_phylink_get_caps(struct dsa_switch *ds, int port,
if (extint->supported_interfaces & RTL8365MB_PHY_INTERFACE_MODE_RGMII)
phy_interface_set_rgmii(config->supported_interfaces);
+
+ if (extint->supported_interfaces & RTL8365MB_PHY_INTERFACE_MODE_SGMII)
+ __set_bit(PHY_INTERFACE_MODE_SGMII,
+ config->supported_interfaces);
}
static void rtl8365mb_phylink_mac_config(struct phylink_config *config,
@@ -1168,6 +1430,15 @@ static void rtl8365mb_phylink_mac_config(struct phylink_config *config,
return;
}
+ if (rtl8365mb_interface_is_serdes(state->interface)) {
+ ret = rtl8365mb_ext_config_sgmii(priv, port);
+ if (ret)
+ dev_err(priv->dev,
+ "failed to configure SGMII mode on port %d: %d\n",
+ port, ret);
+ return;
+ }
+
/* TODO: Implement MII and RMII modes, which the RTL8365MB-VC also
* supports
*/
@@ -1188,7 +1459,8 @@ static void rtl8365mb_phylink_mac_link_down(struct phylink_config *config,
p = &mb->ports[port];
cancel_delayed_work_sync(&p->mib_work);
- if (phy_interface_mode_is_rgmii(interface)) {
+ if (phy_interface_mode_is_rgmii(interface) ||
+ rtl8365mb_interface_is_serdes(interface)) {
ret = rtl8365mb_ext_config_forcemode(priv, port, false, 0, 0,
false, false);
if (ret)
@@ -1196,6 +1468,15 @@ static void rtl8365mb_phylink_mac_link_down(struct phylink_config *config,
"failed to reset forced mode on port %d: %pe\n",
port, ERR_PTR(ret));
+ if (rtl8365mb_interface_is_serdes(interface)) {
+ ret = rtl8365mb_sds_config_forcemode(priv, false, 0, 0,
+ false, false);
+ if (ret)
+ dev_err(priv->dev,
+ "failed to reset forced SGMII link on port %d: %d\n",
+ port, ret);
+ }
+
return;
}
}
@@ -1218,7 +1499,8 @@ static void rtl8365mb_phylink_mac_link_up(struct phylink_config *config,
p = &mb->ports[port];
schedule_delayed_work(&p->mib_work, 0);
- if (phy_interface_mode_is_rgmii(interface)) {
+ if (phy_interface_mode_is_rgmii(interface) ||
+ rtl8365mb_interface_is_serdes(interface)) {
ret = rtl8365mb_ext_config_forcemode(priv, port, true, speed,
duplex, tx_pause,
rx_pause);
@@ -1227,6 +1509,16 @@ static void rtl8365mb_phylink_mac_link_up(struct phylink_config *config,
"failed to force mode on port %d: %pe\n", port,
ERR_PTR(ret));
+ if (rtl8365mb_interface_is_serdes(interface)) {
+ ret = rtl8365mb_sds_config_forcemode(priv, true, speed,
+ duplex, tx_pause,
+ rx_pause);
+ if (ret)
+ dev_err(priv->dev,
+ "failed to force SGMII link on port %d: %d\n",
+ port, ret);
+ }
+
return;
}
}
base-commit: 8f4695fb67b259b2cae0be1eef55859bfc559058
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v3 0/2] net: dsa: realtek: rtl8365mb: add SGMII/HSGMII support for RTL8367S
From: Johan Alvarado @ 2026-06-13 23:21 UTC (permalink / raw)
To: linusw, alsi, andrew, olteanv, davem, edumazet, kuba, pabeni,
netdev
Cc: linux, namiltd, luizluca, linux-kernel, contact
The RTL8367S is a 5+2 port switch from the same family as the
RTL8365MB-VC already supported by this driver. Its chip info table
entry declares SGMII and HSGMII on external interface 1, but the
driver so far only implements RGMII, leaving boards that wire the
switch to the CPU over the SerDes without a working CPU port.
This series implements both modes. The configuration sequence and the
SerDes tuning parameters are derived from the GPL-licensed Realtek
rtl8367c vendor driver, as distributed in the Mercusys MR80X GPL code
drop, and cross-checked against the real register sequence captured at
runtime by chainloading a custom U-Boot ahead of the stock firmware
and logging the live SerDes accesses on hardware.
The vendor driver brings up the SerDes by loading firmware into the
switch's embedded DW8051 microcontroller. Analysis of that firmware
(by Luiz Angelo Daros de Luca) showed it only performs a SerDes
data-path reset right after the SerDes reset is deasserted, and then
runs a link-polling loop that writes the external interface force
registers -- duplicating, and racing with, the link management phylink
already performs. This series therefore keeps the DW8051 disabled and
performs the one necessary action (the data-path reset via the SerDes
BMCR register) directly in the driver, avoiding both the race and a
dependency on a redistributable firmware blob.
Patch 1 adds the SerDes indirect access helpers and SGMII (1 Gbps)
support. Patch 2 extends this to HSGMII (2.5 Gbps), which phylink
represents as 2500base-x.
Tested on a Mercusys MR80X v2.20 (RTL8367S wired to the SoC over the
SerDes), in both SGMII and HSGMII modes with a fixed-link device tree
description: link bring-up verified across cold boots, warm reboots,
module reloads and link down/up cycles, with sustained traffic and no
CRC/symbol errors. The HSGMII link is confirmed running at 2.5G at the
register level (SoC uniphy mode and gmac clocks); per-direction
throughput could not be pushed past ~1 Gbps on this board because the
SoC side is driven by the IPQ5018 SSDK and the user-facing PHY is 1G,
so full 2.5G line-rate throughput remains unverified on my hardware.
Signed-off-by: Johan Alvarado <contact@c127.dev>
---
v3:
- Drop the DW8051 firmware loading entirely. Analysis of the vendor
firmware showed it only duplicates the link management phylink
already does; the one needed action (SerDes data-path reset via
the BMCR register) is now performed directly in the driver, with
the DW8051 kept disabled. This removes the dependency on the
rtl8367s-sgmii.bin firmware blob, which could not be redistributed
via linux-firmware (the GPL vendor source ships it as a byte array
without the corresponding microcode source). Thanks to Luiz Angelo
Daros de Luca for the firmware analysis.
v2: https://lore.kernel.org/netdev/0100019eb0b1822e-ffc5626c-1b9f-4c8a-8a1a-759a9e665f4f-000000@email.amazonses.com/
- No code changes; resend because the SMTP provider used for v1
corrupted the mails and patch 1/2 never reached the list.
v1: https://lore.kernel.org/netdev/aebccaad-eca3-4ea4-99dd-ae7edbc8981b@smtp-relay.sendinblue.com/
Johan Alvarado (2):
net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
drivers/net/dsa/realtek/rtl8365mb.c | 336 +++++++++++++++++++++++++++-
1 file changed, 332 insertions(+), 4 deletions(-)
base-commit: 8f4695fb67b259b2cae0be1eef55859bfc559058
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 bpf-next/net 0/5] bpf: Support RX/TX HW timestamp proxy.
From: Kuniyuki Iwashima @ 2026-06-13 23:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau,
Stanislav Fomichev, Andrii Nakryiko, John Fastabend,
Kumar Kartikeya Dwivedi, Eduard Zingerman, Song Liu,
Yonghong Song, Jiri Olsa, Andrew Lunn, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Willem de Bruijn,
Kuniyuki Iwashima, bpf, netdev
In-Reply-To: <20260613154750.0a2355a4@kernel.org>
On Sat, Jun 13, 2026 at 3:47 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sat, 13 Jun 2026 14:43:46 -0700 Kuniyuki Iwashima wrote:
> > On Sat, Jun 13, 2026 at 10:20 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > > On Sat, 13 Jun 2026 00:59:57 +0000 Kuniyuki Iwashima wrote:
> > > > When standard socket applications are run on these hosts,
> > > > a userspace proxy is required to mediate traffic between the
> > > > hardware and the applications.
> > > >
> > > > +---------+ +----------------------+
> > > > | proxy | | socket application |
> > > > +---------+ +----------------------+
> > > > ^ ^ ^
> > > > userspace | | |
> > > > -----------| |-----------------------------------------------
> > > > | | | +---------------------+ | skb
> > > > | | `--->| virtual interface |<---'
> > > > kernel | | skb +---------------------+
> > > > -----------| |-----------------------------------------------
> > > > |
> > > > v
> > > > +------------+
> > > > | hardware |
> > > > +------------+
> > >
> > > The first patch looks kinda nonsensical but then I saw this diagram.
> > > Looks like you're vibe coding an integration that makes it easier to
> > > treat netdev as a slow path for a user networking stack.
> > > Please tell me if I'm missing anything otherwise add my nack if you
> > > repost.
> >
> > Hmm, what would be a better way to tell users that HW TS is
> > available on tunnel devices ?
> >
> > Other options were 1) add attribute to tie the tunnel to a physical
> > device and use its ndo_hwtstamp_set/get, or 2) add bpf retval
> > hook in the path like update_socket_protocol().
>
> Can you explain the use case for HW timestamps on tunnels?
> I see you have some diagrams in patches 3 and 4 but the motivation
> isn't really explained, and we have 250 patches in the queue still.
> Not much time to play detective right now :/
To be clear, this series is not related to Swift.
Our RPC library capture timestamps as many places as possible
so that we can visualise the RPC calls and know/debug where the
latency comes from: application, library, kernel, network.
This is not specific to tunnels and applied to all workloads running
on container w/ virtual devices and init_net w/ physical devices.
>
> > Or do you think applications should handle ENOTSUP by ioctl
> > as soft error and always set SOF_TIMESTAMPING_XXX_HARDWARE
> > since the underlying physical device may support it ?
>
> And explain the deployment model and API semantics you have in mind.
The application first calls ioctl(SIOCSHWTSTAMP) and only when
hwtstamp is supported, it uses SOF_TIMESTAMPING_XXX_HARDARE.
The doc mentions ioctl(SIOCSHWTSTAMP) may overwrite the
configuration and ioctl(SIOCGHWTSTAMP) is not always implemented.
https://docs.kernel.org/networking/timestamping.html
But it does not say ioctl(SIOCSHWTSTAMP) may fail although
SOF_TIMESTAMPING_XXX_HARDARE could be supported.
>
> > Anyway, I'm happy to drop patch 1 for now and explore options.
>
> Not patch 1, all of it. I get the feeling y'all are sitting on a pile
> of Swift related code that needs to be made upstreamable. Odd series
> like this make me think it's never going to happen.
>
> > (Believe it or not, I haven't let AI write code because I don't
> > want AI to take over the most fun part.)
^ permalink raw reply
* [PATCH net v3] ip_tunnel: drop stale dst from generated PMTU ICMP replies
From: Laika Price via B4 Relay @ 2026-06-13 23:13 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan
Cc: netdev, linux-kernel, linux-kselftest, Laika Price
From: Laika Price <laikabcprice@gmail.com>
iptunnel_pmtud_build_icmp(...) and iptunnel_pmtud_build_icmpv6(...) take
in an sk_buff, modify it to create a PMTU ICMP error reply, and return it.
As part of these modifications, the source/destination ethernet and IP
addresses are swapped around which makes the sk_buff's current dst invalid.
If the stale dst is left, the packet can skip input routing and be
forwarded using the original output device. This was observed when sending
packets to a VXLAN over a WireGuard tunnel - the ICMP reply was generated
but it was sent over the VXLAN instead of to the WireGuard tunnel.
This patch drops the stale dst after building the PMTU reply so that the
packet is routed using its new headers when it is reinjected.
The pmtu_ipv4_br_vxlan4_exception test generates PMTU exceptions by
pinging an IP on the other side of a tunnel. This was incorrect as it
would return upon the first ICMP Fragmentation Needed due to the -w flag
being used in conjunction with || return 1.
This patch updates pmtu_ipv4_br_vxlan4_exception to be in line with how
PMTU exceptions are generated in other tests such as in test_pmtu_ipvX
run_cmd ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1800 ${dst1}
run_cmd ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1800 ${dst2}
Signed-off-by: Laika Price <laikabcprice@gmail.com>
---
Changes in v3:
- Squashed the selftest update into the ip_tunnel fix so the patch remains
bisectable.
- Link to v2: https://patch.msgid.link/20260613-master-v2-0-061b70fd45dd@gmail.com
Changes in v2:
- Fixed incorrect PMTU exception generation in the selftest.
- Link to v1: https://patch.msgid.link/20260613-master-v1-1-df796e8e2d74@gmail.com
---
net/ipv4/ip_tunnel_core.c | 2 ++
tools/testing/selftests/net/pmtu.sh | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index d3c677e9b..949150e43 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -267,6 +267,7 @@ static int iptunnel_pmtud_build_icmp(struct sk_buff *skb, int mtu)
eth_header(skb, skb->dev, ntohs(eh.h_proto), eh.h_source, eh.h_dest, 0);
skb_reset_mac_header(skb);
+ skb_dst_drop(skb);
return skb->len;
}
@@ -370,6 +371,7 @@ static int iptunnel_pmtud_build_icmpv6(struct sk_buff *skb, int mtu)
eth_header(skb, skb->dev, ntohs(eh.h_proto), eh.h_source, eh.h_dest, 0);
skb_reset_mac_header(skb);
+ skb_dst_drop(skb);
return skb->len;
}
diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh
index a3323c21f..9498d9f53 100755
--- a/tools/testing/selftests/net/pmtu.sh
+++ b/tools/testing/selftests/net/pmtu.sh
@@ -1456,8 +1456,8 @@ test_pmtu_ipvX_over_bridged_vxlanY_or_geneveY_exception() {
mtu "${ns_a}" ${type}_a $((${ll_mtu} + 1000))
mtu "${ns_b}" ${type}_b $((${ll_mtu} + 1000))
- run_cmd ${ns_c} ${ping} -q -M want -i 0.1 -c 10 -s $((${ll_mtu} + 500)) ${dst} || return 1
- run_cmd ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${dst} || return 1
+ run_cmd ${ns_c} ${ping} -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${dst}
+ run_cmd ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${dst}
# Check that exceptions were created
pmtu="$(route_get_dst_pmtu_from_exception "${ns_c}" ${dst})"
---
base-commit: 2a2974b5145cdf2f4db134be1a2157e9ca4a1cf0
change-id: 20260613-master-b749dfae5ecc
Best regards,
--
Laika Price <laikabcprice@gmail.com>
^ permalink raw reply related
* Re: [PATCH net 0/2] net/stmmac: Fixes for maximum TX/RX queues to use by driver
From: patchwork-bot+netdevbpf @ 2026-06-13 23:10 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, alexandre.torgue, linux-kernel, linux-arm-kernel,
k.domagalski, k.tegowski
In-Reply-To: <20260611113358.3379518-1-j.raczynski@samsung.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 11 Jun 2026 13:33:56 +0200 you wrote:
> When contributing other changes preparing functions for new XGMAC hardware
> https://lore.kernel.org/netdev/20260601162537.553512-1-j.raczynski@samsung.com/
> there have been reports by Sashiko AI review about pre-existing issues
> in the code. These problems are non-insignificant and are 'net' material fixes,
> rather than net-next features.
> One issue in this patchset was reported by Sashiko AI, while other
> technically part of new patchset, but is reasonable related fix.
> All of issues are wrong DTS configuration, but kernel needs to handle it.
>
> [...]
Here is the summary with links:
- [net,1/2] net/stmmac: Apply TBS config only to used queues
https://git.kernel.org/netdev/net-next/c/8b10877d9d6c
- [net,2/2] net/stmmac: Apply MTL_MAX queue limit if config missing
https://git.kernel.org/netdev/net-next/c/8a7bca6de6de
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 v2] net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries
From: patchwork-bot+netdevbpf @ 2026-06-13 23:00 UTC (permalink / raw)
To: Wayen.Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2be54b.ef98c1b2.3c3224.2ed8@mx.google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 12 Jun 2026 07:09:56 +0800 you wrote:
> In airoha_ppe_debugfs_foe_show(), the second switch statement falls
> through from PPE_PKT_TYPE_IPV4_HNAPT/DSLITE to PPE_PKT_TYPE_IPV4_ROUTE,
> accessing hwe->ipv4.new_tuple for all three types. However, IPv4 ROUTE
> (3-tuple) entries do not contain a valid new_tuple — this field is only
> meaningful for NATted flows (HNAPT/DSLITE). For ROUTE entries, the
> memory at the new_tuple offset holds routing information, not NAT data,
> so displaying "new=" produces garbage output.
>
> [...]
Here is the summary with links:
- [v2] net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries
https://git.kernel.org/netdev/net/c/1c3a77471afb
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: airoha: Fix register index for Tx-fwd counter configuration
From: patchwork-bot+netdevbpf @ 2026-06-13 23:00 UTC (permalink / raw)
To: Wayen.Yan; +Cc: netdev, lorenzo, linux-arm-kernel, linux-mediatek
In-Reply-To: <6a2b40e7.4dd82583.3a5c46.e566@mx.google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 12 Jun 2026 07:09:13 +0800 you wrote:
> In airoha_qdma_init_qos_stats(), the Tx-fwd counter configuration
> register uses the same index (i << 1) as the Tx-cpu counter, which
> overwrites the Tx-cpu configuration. The Tx-fwd counter value register
> correctly uses (i << 1) + 1, so the configuration register should use
> the same index.
>
> Fix the REG_CNTR_CFG index from (i << 1) to ((i << 1) + 1) so that
> the Tx-fwd counter is properly configured instead of clobbering the
> Tx-cpu counter config.
>
> [...]
Here is the summary with links:
- net: airoha: Fix register index for Tx-fwd counter configuration
https://git.kernel.org/netdev/net/c/1402ecccf563
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-next] net: pse-pd: set user byte command SUB2 field
From: Jakub Kicinski @ 2026-06-13 22:59 UTC (permalink / raw)
To: Robert Marko
Cc: o.rempel, kory.maincent, andrew+netdev, davem, edumazet, pabeni,
netdev, linux-kernel, luka.perkov
In-Reply-To: <20260611102517.445549-1-robert.marko@sartura.hr>
On Thu, 11 Jun 2026 12:24:49 +0200 Robert Marko wrote:
> The Set User Byte to Save command has three subject bytes.
> The PD692x0 protocol guides defines SUB2 with value 0x4e, while SUB1
> carries the NVM user byte.
>
> Template only initialized SUB and SUB1.
> Fill SUB2 explicitly so the command matches the documented layout.
Could you mention if you observed any misbehavior in practice?
If you can see any effect of this patch it needs to include a Fixes tag
so that it can be backported.
^ permalink raw reply
* [PATCH] net/mlx5: HWS: correct CONFIG_MLX5_HW_STEERING macro name in comment
From: Ethan Nelson-Moore @ 2026-06-13 22:59 UTC (permalink / raw)
To: GitAuthor: Ethan Nelson-Moore, netdev, linux-rdma
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
A comment in
drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.h
incorrectly refers to CONFIG_MLX5_HWS_STEERING instead of
CONFIG_MLX5_HW_STEERING. Correct it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.h b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.h
index b92d55b2d147..20cdacd8f12e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.h
@@ -116,5 +116,5 @@ static inline const struct mlx5_flow_cmds *mlx5_fs_cmd_get_hws_cmds(void)
return NULL;
}
-#endif /* CONFIG_MLX5_HWS_STEERING */
+#endif /* CONFIG_MLX5_HW_STEERING */
#endif
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v2 0/4] Extend netkit io_uring ZC selftests
From: Jakub Kicinski @ 2026-06-13 22:57 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: razor, bobbyeshleman, dw, netdev
In-Reply-To: <20260611082527.741674-1-daniel@iogearbox.net>
On Thu, 11 Jun 2026 10:25:23 +0200 Daniel Borkmann wrote:
> Small follow-up to the HW net selftests, in particular to add a
> selftest showing that also large rx_buf_len for io_uring ZC is
> supported with netkit queue leasing.
needs a rebase vs the PSP series that landed yesterday
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v2 bpf-next/net 0/5] bpf: Support RX/TX HW timestamp proxy.
From: Jakub Kicinski @ 2026-06-13 22:47 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau,
Stanislav Fomichev, Andrii Nakryiko, John Fastabend,
Kumar Kartikeya Dwivedi, Eduard Zingerman, Song Liu,
Yonghong Song, Jiri Olsa, Andrew Lunn, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Willem de Bruijn,
Kuniyuki Iwashima, bpf, netdev
In-Reply-To: <CAAVpQUBP_21b5MB8MS-wFwg9BUdcgMoNxi8s479YQHH9g5ahCw@mail.gmail.com>
On Sat, 13 Jun 2026 14:43:46 -0700 Kuniyuki Iwashima wrote:
> On Sat, Jun 13, 2026 at 10:20 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > On Sat, 13 Jun 2026 00:59:57 +0000 Kuniyuki Iwashima wrote:
> > > When standard socket applications are run on these hosts,
> > > a userspace proxy is required to mediate traffic between the
> > > hardware and the applications.
> > >
> > > +---------+ +----------------------+
> > > | proxy | | socket application |
> > > +---------+ +----------------------+
> > > ^ ^ ^
> > > userspace | | |
> > > -----------| |-----------------------------------------------
> > > | | | +---------------------+ | skb
> > > | | `--->| virtual interface |<---'
> > > kernel | | skb +---------------------+
> > > -----------| |-----------------------------------------------
> > > |
> > > v
> > > +------------+
> > > | hardware |
> > > +------------+
> >
> > The first patch looks kinda nonsensical but then I saw this diagram.
> > Looks like you're vibe coding an integration that makes it easier to
> > treat netdev as a slow path for a user networking stack.
> > Please tell me if I'm missing anything otherwise add my nack if you
> > repost.
>
> Hmm, what would be a better way to tell users that HW TS is
> available on tunnel devices ?
>
> Other options were 1) add attribute to tie the tunnel to a physical
> device and use its ndo_hwtstamp_set/get, or 2) add bpf retval
> hook in the path like update_socket_protocol().
Can you explain the use case for HW timestamps on tunnels?
I see you have some diagrams in patches 3 and 4 but the motivation
isn't really explained, and we have 250 patches in the queue still.
Not much time to play detective right now :/
> Or do you think applications should handle ENOTSUP by ioctl
> as soft error and always set SOF_TIMESTAMPING_XXX_HARDWARE
> since the underlying physical device may support it ?
And explain the deployment model and API semantics you have in mind.
> Anyway, I'm happy to drop patch 1 for now and explore options.
Not patch 1, all of it. I get the feeling y'all are sitting on a pile
of Swift related code that needs to be made upstreamable. Odd series
like this make me think it's never going to happen.
> (Believe it or not, I haven't let AI write code because I don't
> want AI to take over the most fun part.)
^ 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