* Re: [PATCH bpf-next 3/6] selftests/bpf: Add ksock kfunc test
From: bot+bpf-ci @ 2026-07-06 10:16 UTC (permalink / raw)
To: mahe.tardy, bpf
Cc: andrew+netdev, andrii, ast, daniel, davem, eddyz87, edumazet,
john.fastabend, kuba, liamwisehart, martin.lau, pabeni, song,
netdev, mahe.tardy, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260706093525.13030-4-mahe.tardy@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
> Add a selftest that exercises the ksock kfuncs end-to-end. One sycall
> bpf setup program creates a ksock context and connect the socket.
> Another syscall bpf program lookup the context and send test data.
> The userspace harness create a network namespace and a new socket on
> loopback, run the setup and send syscall bpf progs then check that the
> userspace socket received the data from bpf.
This isn't a bug, but would a quick pass over the changelog wording help
here? A few spots read a little off:
"One sycall" -> "One syscall"
"creates a ksock context and connect the socket" -> connects
"Another syscall bpf program lookup the context" -> looks up
"The userspace harness create a network namespace" -> creates
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28783010022
^ permalink raw reply
* [PATCH nf v2 2/3] ipvs: use parsed transport offset in TCP state lookup
From: Yizhou Zhao @ 2026-07-06 10:16 UTC (permalink / raw)
To: netdev
Cc: coreteam, davem, edumazet, fengxw06, fw, horms, ja, kuba,
linux-kernel, lvs-devel, netfilter-devel, pabeni, pablo, phil,
qli01, stable, wangao, xuke, yangyx22, Yizhou Zhao
In-Reply-To: <20260706101624.69471-1-zhaoyz24@mails.tsinghua.edu.cn>
TCP state handling reparses the skb to find the TCP header. For IPv6 it
uses sizeof(struct ipv6hdr), while the surrounding IPVS code already
parsed the packet with ip_vs_fill_iph_skb() and has the real
transport-header offset in iph.len.
This makes TCP state handling look at the wrong bytes when an IPv6
packet carries extension headers. Use the parsed transport offset passed
down from ip_vs_set_state() when reading the TCP header.
For IPv4 and for IPv6 packets without extension headers, the passed
offset matches the previous value.
Fixes: 0bbdd42b7efa6 ("IPVS: Extend protocol DNAT/SNAT and state handlers")
Link: https://lore.kernel.org/netdev/20260705125659.37744-1-zhaoyz24@mails.tsinghua.edu.cn/
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
net/netfilter/ipvs/ip_vs_proto_tcp.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index 2d3f6aeafe52..f86b763efcc4 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -584,13 +584,7 @@ tcp_state_transition(struct ip_vs_conn *cp, int direction,
{
struct tcphdr _tcph, *th;
-#ifdef CONFIG_IP_VS_IPV6
- int ihl = cp->af == AF_INET ? ip_hdrlen(skb) : sizeof(struct ipv6hdr);
-#else
- int ihl = ip_hdrlen(skb);
-#endif
-
- th = skb_header_pointer(skb, ihl, sizeof(_tcph), &_tcph);
+ th = skb_header_pointer(skb, iph_len, sizeof(_tcph), &_tcph);
if (th == NULL)
return;
--
2.34.1
^ permalink raw reply related
* [PATCH nf v2 0/3] ipvs: use parsed transport offsets in state handlers
From: Yizhou Zhao @ 2026-07-06 10:16 UTC (permalink / raw)
To: netdev
Cc: coreteam, davem, edumazet, fengxw06, fw, horms, ja, kuba,
linux-kernel, lvs-devel, netfilter-devel, pabeni, pablo, phil,
qli01, stable, wangao, xuke, yangyx22, Yizhou Zhao
IPVS parses packets into struct ip_vs_iphdr before scheduling and state
handling. For IPv6, iph.len contains the real transport-header offset
after ipv6_find_hdr() has skipped any extension headers.
TCP and SCTP state handlers still recompute their own transport offsets.
They use sizeof(struct ipv6hdr) for IPv6, so packets with extension
headers make the state machines read the wrong bytes.
Pass the parsed transport offset through the common IPVS state handling
callback, then use it in the TCP and SCTP state lookups.
Changes in v2:
- Pass the parsed transport offset through ip_vs_set_state() and the
protocol callbacks.
- Fix TCP state handling as well as SCTP.
- Avoid reparsing the skb in SCTP state handling.
- Split the common plumbing, TCP fix and SCTP fix into a 3-patch series.
Yizhou Zhao (3):
ipvs: pass parsed transport offset to state handlers
ipvs: use parsed transport offset in TCP state lookup
ipvs: use parsed transport offset in SCTP state lookup
include/net/ip_vs.h | 3 ++-
net/netfilter/ipvs/ip_vs_core.c | 10 +++++-----
net/netfilter/ipvs/ip_vs_proto_sctp.c | 18 +++++++-----------
net/netfilter/ipvs/ip_vs_proto_tcp.c | 11 +++--------
net/netfilter/ipvs/ip_vs_proto_udp.c | 3 ++-
5 files changed, 19 insertions(+), 26 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH nf v2 1/3] ipvs: pass parsed transport offset to state handlers
From: Yizhou Zhao @ 2026-07-06 10:16 UTC (permalink / raw)
To: netdev
Cc: coreteam, davem, edumazet, fengxw06, fw, horms, ja, kuba,
linux-kernel, lvs-devel, netfilter-devel, pabeni, pablo, phil,
qli01, stable, wangao, xuke, yangyx22, Yizhou Zhao
In-Reply-To: <20260706101624.69471-1-zhaoyz24@mails.tsinghua.edu.cn>
IPVS callers already parse the packet into struct ip_vs_iphdr before
updating connection state. For IPv6 this records the real
transport-header offset after extension headers in iph.len.
Pass this parsed transport offset through ip_vs_set_state() and the
protocol state_transition() callback so protocol handlers can use the
same packet context as scheduling and NAT handling. This patch only
changes the common callback plumbing and adapts the protocol callback
signatures; TCP and SCTP start using the value in follow-up patches.
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
include/net/ip_vs.h | 3 ++-
net/netfilter/ipvs/ip_vs_core.c | 10 +++++-----
net/netfilter/ipvs/ip_vs_proto_sctp.c | 3 ++-
net/netfilter/ipvs/ip_vs_proto_tcp.c | 3 ++-
net/netfilter/ipvs/ip_vs_proto_udp.c | 3 ++-
5 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 49297fec448a..417ff51f62fc 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -752,7 +752,8 @@ struct ip_vs_protocol {
void (*state_transition)(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb,
- struct ip_vs_proto_data *pd);
+ struct ip_vs_proto_data *pd,
+ unsigned int iph_len);
int (*register_app)(struct netns_ipvs *ipvs, struct ip_vs_app *inc);
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index d40b404c1bf6..bd90f03fe3a4 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -398,10 +398,10 @@ ip_vs_conn_stats(struct ip_vs_conn *cp, struct ip_vs_service *svc)
static inline void
ip_vs_set_state(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb,
- struct ip_vs_proto_data *pd)
+ struct ip_vs_proto_data *pd, unsigned int iph_len)
{
if (likely(pd->pp->state_transition))
- pd->pp->state_transition(cp, direction, skb, pd);
+ pd->pp->state_transition(cp, direction, skb, pd, iph_len);
}
static inline int
@@ -803,7 +803,7 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
ip_vs_in_stats(cp, skb);
/* set state */
- ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
+ ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd, iph->len);
/* transmit the first SYN packet */
ret = cp->packet_xmit(skb, cp, pd->pp, iph);
@@ -1484,7 +1484,7 @@ handle_response(int af, struct sk_buff *skb, struct ip_vs_proto_data *pd,
after_nat:
ip_vs_out_stats(cp, skb);
- ip_vs_set_state(cp, IP_VS_DIR_OUTPUT, skb, pd);
+ ip_vs_set_state(cp, IP_VS_DIR_OUTPUT, skb, pd, iph->len);
skb->ipvs_property = 1;
if (!(cp->flags & IP_VS_CONN_F_NFCT))
ip_vs_notrack(skb);
@@ -2233,7 +2233,7 @@ ip_vs_in_hook(void *priv, struct sk_buff *skb, const struct nf_hook_state *state
IP_VS_DBG_PKT(11, af, pp, skb, iph.off, "Incoming packet");
ip_vs_in_stats(cp, skb);
- ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
+ ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd, iph.len);
if (cp->packet_xmit)
ret = cp->packet_xmit(skb, cp, pp, &iph);
/* do not touch skb anymore */
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index 63c78a1f3918..394367b7b388 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -468,7 +468,8 @@ set_sctp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
static void
sctp_state_transition(struct ip_vs_conn *cp, int direction,
- const struct sk_buff *skb, struct ip_vs_proto_data *pd)
+ const struct sk_buff *skb, struct ip_vs_proto_data *pd,
+ unsigned int iph_len)
{
spin_lock_bh(&cp->lock);
set_sctp_state(pd, cp, direction, skb);
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index 8cc0a8ce6241..2d3f6aeafe52 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -579,7 +579,8 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
static void
tcp_state_transition(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb,
- struct ip_vs_proto_data *pd)
+ struct ip_vs_proto_data *pd,
+ unsigned int iph_len)
{
struct tcphdr _tcph, *th;
diff --git a/net/netfilter/ipvs/ip_vs_proto_udp.c b/net/netfilter/ipvs/ip_vs_proto_udp.c
index f9de632e38cd..58f9e255927e 100644
--- a/net/netfilter/ipvs/ip_vs_proto_udp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_udp.c
@@ -444,7 +444,8 @@ static const char * udp_state_name(int state)
static void
udp_state_transition(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb,
- struct ip_vs_proto_data *pd)
+ struct ip_vs_proto_data *pd,
+ unsigned int iph_len)
{
if (unlikely(!pd)) {
pr_err("UDP no ns data\n");
--
2.34.1
^ permalink raw reply related
* [PATCH nf v2 3/3] ipvs: use parsed transport offset in SCTP state lookup
From: Yizhou Zhao @ 2026-07-06 10:16 UTC (permalink / raw)
To: netdev
Cc: coreteam, davem, edumazet, fengxw06, fw, horms, ja, kuba,
linux-kernel, lvs-devel, netfilter-devel, pabeni, pablo, phil,
qli01, stable, wangao, xuke, yangyx22, Yizhou Zhao
In-Reply-To: <20260706101624.69471-1-zhaoyz24@mails.tsinghua.edu.cn>
set_sctp_state() reads the SCTP chunk header again in order to drive the
IPVS SCTP state table. For IPv6 it computes the offset with
sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from
ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped
extension headers and found the real transport header.
This makes the state machine read from the wrong offset for IPv6 SCTP
packets that carry extension headers. For example, an INIT packet with an
8-byte destination options header can be scheduled correctly by
sctp_conn_schedule(), but set_sctp_state() reads the first byte of the
SCTP verification tag as a DATA chunk type. The connection then moves
from NONE to ESTABLISHED instead of INIT1, gets the longer established
timeout, and updates the active/inactive destination counters
incorrectly. This happens even though the SCTP handshake has not
completed.
Use the parsed transport offset passed down from ip_vs_set_state() for
the SCTP chunk-header lookup. For IPv4 and IPv6 packets without
extension headers this preserves the existing offset.
Fixes: 2906f66a5682 ("ipvs: SCTP Trasport Loadbalancing Support")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/netdev/20260705123040.35755-1-zhaoyz24@mails.tsinghua.edu.cn/
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
net/netfilter/ipvs/ip_vs_proto_sctp.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index 394367b7b388..c67317be17df 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -372,20 +372,15 @@ static const char *sctp_state_name(int state)
static inline void
set_sctp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
- int direction, const struct sk_buff *skb)
+ int direction, const struct sk_buff *skb,
+ unsigned int iph_len)
{
struct sctp_chunkhdr _sctpch, *sch;
unsigned char chunk_type;
int event, next_state;
- int ihl, cofs;
-
-#ifdef CONFIG_IP_VS_IPV6
- ihl = cp->af == AF_INET ? ip_hdrlen(skb) : sizeof(struct ipv6hdr);
-#else
- ihl = ip_hdrlen(skb);
-#endif
+ int cofs;
- cofs = ihl + sizeof(struct sctphdr);
+ cofs = iph_len + sizeof(struct sctphdr);
sch = skb_header_pointer(skb, cofs, sizeof(_sctpch), &_sctpch);
if (sch == NULL)
return;
@@ -472,7 +467,7 @@ sctp_state_transition(struct ip_vs_conn *cp, int direction,
unsigned int iph_len)
{
spin_lock_bh(&cp->lock);
- set_sctp_state(pd, cp, direction, skb);
+ set_sctp_state(pd, cp, direction, skb, iph_len);
spin_unlock_bh(&cp->lock);
}
--
2.34.1
^ permalink raw reply related
* [PATCH] ARM: dts: ti: omap: Correct indentation
From: Krzysztof Kozlowski @ 2026-07-06 10:18 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, linux-omap, devicetree, linux-kernel, netdev
Cc: Krzysztof Kozlowski
Correct spaces or mix of tabs+spaces into proper tab-indented lines.
No functional impact (same DTB).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Ongoing bigger work for all bindings and DTS with built-in checker (dt-check-style).
---
.../ti/omap/am335x-icev2-prueth-overlay.dtso | 126 +++++++++---------
arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm8148-evm.dts | 4 +-
arch/arm/boot/dts/ti/omap/dm816x-clocks.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 +-
.../dts/ti/omap/motorola-mapphone-common.dtsi | 10 +-
arch/arm/boot/dts/ti/omap/omap3-cm-t3x30.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi | 2 +-
.../dts/ti/omap/omap3-overo-common-lcd35.dtsi | 2 +-
.../dts/ti/omap/omap3-overo-common-lcd43.dtsi | 2 +-
10 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso b/arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso
index ffed1f3d046a..c0f32c889f69 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso
+++ b/arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso
@@ -19,61 +19,61 @@
#include <dt-bindings/clock/am3.h>
&{/} {
- /* Dual-MAC Ethernet application node on PRU-ICSS */
- pruss_eth: pruss-eth {
- compatible = "ti,am3359-prueth";
- ti,prus = <&pru0>, <&pru1>;
- sram = <&ocmcram>;
- ti,mii-rt = <&pruss_mii_rt>;
- ti,iep = <&pruss_iep>;
- ti,ecap = <&pruss_ecap>;
- interrupts = <20 2 2>, <21 3 3>;
- interrupt-names = "rx_hp", "rx_lp";
- interrupt-parent = <&pruss_intc>;
+ /* Dual-MAC Ethernet application node on PRU-ICSS */
+ pruss_eth: pruss-eth {
+ compatible = "ti,am3359-prueth";
+ ti,prus = <&pru0>, <&pru1>;
+ sram = <&ocmcram>;
+ ti,mii-rt = <&pruss_mii_rt>;
+ ti,iep = <&pruss_iep>;
+ ti,ecap = <&pruss_ecap>;
+ interrupts = <20 2 2>, <21 3 3>;
+ interrupt-names = "rx_hp", "rx_lp";
+ interrupt-parent = <&pruss_intc>;
- pinctrl-0 = <&pruss_eth_default>;
- pinctrl-names = "default";
+ pinctrl-0 = <&pruss_eth_default>;
+ pinctrl-names = "default";
- ethernet-ports {
- #address-cells = <1>;
- #size-cells = <0>;
- pruss_emac0: ethernet-port@0 {
- reg = <0>;
- phy-handle = <&pruss_eth0_phy>;
- phy-mode = "mii";
- interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
- interrupt-names = "rx", "emac_ptp_tx",
- "hsr_ptp_tx";
- /* Filled in by bootloader */
- local-mac-address = [00 00 00 00 00 00];
- };
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss_emac0: ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <&pruss_eth0_phy>;
+ phy-mode = "mii";
+ interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
- pruss_emac1: ethernet-port@1 {
- reg = <1>;
- phy-handle = <&pruss_eth1_phy>;
- phy-mode = "mii";
- interrupts = <21 3 3>, <27 9 7>, <24 9 7>;
- interrupt-names = "rx", "emac_ptp_tx",
- "hsr_ptp_tx";
- /* Filled in by bootloader */
- local-mac-address = [00 00 00 00 00 00];
- };
- };
- };
+ pruss_emac1: ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <&pruss_eth1_phy>;
+ phy-mode = "mii";
+ interrupts = <21 3 3>, <27 9 7>, <24 9 7>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
};
&am33xx_pinmux {
/* MDIO node for PRU-ICSS */
- pruss_mdio_default: pruss-mdio-default-pins {
- pinctrl-single,pins = <
+ pruss_mdio_default: pruss-mdio-default-pins {
+ pinctrl-single,pins = <
AM33XX_IOPAD(0x88c, PIN_OUTPUT | MUX_MODE5) /* (V12) gpmc_clk.pr1_mdio_mdclk */
AM33XX_IOPAD(0x888, PIN_INPUT | MUX_MODE5) /* (T13) gpmc_csn3.pr1_mdio_data */
- >;
- };
+ >;
+ };
/* Pinmux configuration for PRU-ICSS */
- pruss_eth_default: pruss-eth-default-pins {
- pinctrl-single,pins = <
+ pruss_eth_default: pruss-eth-default-pins {
+ pinctrl-single,pins = <
AM33XX_IOPAD(0x8a0, PIN_INPUT | MUX_MODE2) /* (R1) lcd_data0.pr1_mii_mt0_clk */
AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE2) /* (T2) lcd_data5.pr1_mii0_txd0 */
AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE2) /* (T1) lcd_data4.pr1_mii0_txd1 */
@@ -105,14 +105,14 @@ AM33XX_IOPAD(0x868, PIN_INPUT | MUX_MODE5) /* (T16) gpmc_a10.pr1_mii1_rxdv */
AM33XX_IOPAD(0x86c, PIN_INPUT | MUX_MODE5) /* (V17) gpmc_a11.pr1_mii1_rxer */
AM33XX_IOPAD(0x878, PIN_INPUT | MUX_MODE5) /* (U18) gpmc_be1n.pr1_mii1_rxlink */
AM33XX_IOPAD(0x8ec, PIN_INPUT | MUX_MODE2) /* (R6) lcd_ac_bias_en.pr1_mii1_crs */
- >;
- };
+ >;
+ };
};
&gpio3 {
- mux-mii-hog {
+ mux-mii-hog {
status = "disabled";
- };
+ };
mux-mii-hog-0 {
gpio-hog;
@@ -129,28 +129,28 @@ mux-mii-hog-0 {
* conflict with PRU-ICSS
*/
&mac_sw {
- status = "disabled";
+ status = "disabled";
};
&davinci_mdio_sw {
- status = "disabled";
+ status = "disabled";
};
/* PRU-ICSS MDIO configuration */
&pruss_mdio {
- pinctrl-0 = <&pruss_mdio_default>;
- pinctrl-names = "default";
- reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
- reset-delay-us = <2>; /* PHY datasheet states 1uS min */
- status = "okay";
- #address-cells = <1>;
- #size-cells = <0>;
+ pinctrl-0 = <&pruss_mdio_default>;
+ pinctrl-names = "default";
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <2>; /* PHY datasheet states 1uS min */
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
- pruss_eth0_phy: ethernet-phy@1 {
- reg = <1>;
- };
+ pruss_eth0_phy: ethernet-phy@1 {
+ reg = <1>;
+ };
- pruss_eth1_phy: ethernet-phy@3 {
- reg = <3>;
- };
+ pruss_eth1_phy: ethernet-phy@3 {
+ reg = <3>;
+ };
};
diff --git a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
index 8a693c478bea..57a45609f9f5 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
@@ -1870,7 +1870,7 @@ SYSC_OMAP2_SOFTRESET |
gpio2: gpio@0 {
compatible = "ti,omap4-gpio";
- gpio-ranges = <&am33xx_pinmux 0 34 18>,
+ gpio-ranges = <&am33xx_pinmux 0 34 18>,
<&am33xx_pinmux 18 77 4>,
<&am33xx_pinmux 22 56 10>;
gpio-controller;
diff --git a/arch/arm/boot/dts/ti/omap/dm8148-evm.dts b/arch/arm/boot/dts/ti/omap/dm8148-evm.dts
index 57a9eef09f6f..8236d9eb438a 100644
--- a/arch/arm/boot/dts/ti/omap/dm8148-evm.dts
+++ b/arch/arm/boot/dts/ti/omap/dm8148-evm.dts
@@ -99,7 +99,7 @@ partition@780000 {
};
&mmc1 {
- status = "disabled";
+ status = "disabled";
};
&mmc2 {
@@ -111,7 +111,7 @@ &mmc2 {
};
&mmc3 {
- status = "disabled";
+ status = "disabled";
};
&pincntl {
diff --git a/arch/arm/boot/dts/ti/omap/dm816x-clocks.dtsi b/arch/arm/boot/dts/ti/omap/dm816x-clocks.dtsi
index 338449b32a18..76ebc6c3c3e5 100644
--- a/arch/arm/boot/dts/ti/omap/dm816x-clocks.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dm816x-clocks.dtsi
@@ -177,7 +177,7 @@ mpu_ck: mpu_ck@15dc {
compatible = "ti,gate-clock";
clocks = <&sysclk2_ck>;
ti,bit-shift = <1>;
- reg = <0x15dc>;
+ reg = <0x15dc>;
};
audio_pll_a_ck: audio_pll_a_ck@35c {
diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
index 9df7648c4b79..a595745afe59 100644
--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
@@ -1695,9 +1695,9 @@ uart4: serial@0 {
reg = <0x0 0x100>;
interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <48000000>;
- status = "disabled";
dmas = <&sdma_xbar 55>, <&sdma_xbar 56>;
dma-names = "tx", "rx";
+ status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi b/arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi
index a0c53d9c2625..28b4f12b82a7 100644
--- a/arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi
+++ b/arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi
@@ -91,22 +91,22 @@ &cpu_thermal {
};
&cpu_alert0 {
- temperature = <80000>; /* millicelsius */
+ temperature = <80000>; /* millicelsius */
};
&cpu0 {
- /*
+ /*
* Note that the 1.2GiHz mode is enabled for all SoC variants for
* the Motorola Android Linux v3.0.8 based kernel.
*/
- operating-points = <
- /* kHz uV */
+ operating-points = <
+ /* kHz uV */
300000 1025000
600000 1200000
800000 1313000
1008000 1375000
1200000 1375000
- >;
+ >;
};
&dss {
diff --git a/arch/arm/boot/dts/ti/omap/omap3-cm-t3x30.dtsi b/arch/arm/boot/dts/ti/omap/omap3-cm-t3x30.dtsi
index 0e942513560d..6c4916ec41b4 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3-cm-t3x30.dtsi
@@ -29,7 +29,7 @@ OMAP3_CORE1_IOPAD(0x219a, PIN_INPUT_PULLUP | MUX_MODE4) /* uart3_cts_rctx.gpio_1
>;
};
- hsusb0_pins: hsusb0-pins {
+ hsusb0_pins: hsusb0-pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x21a2, PIN_OUTPUT | MUX_MODE0) /* hsusb0_clk.hsusb0_clk */
OMAP3_CORE1_IOPAD(0x21a4, PIN_OUTPUT | MUX_MODE0) /* hsusb0_stp.hsusb0_stp */
diff --git a/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi b/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
index aa4fcdbedd8f..519f7b42a59a 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
@@ -287,7 +287,7 @@ lis302: lis302@1d {
pinctrl-names = "default";
pinctrl-0 = <&accelerator_pins>;
- interrupts-extended = <&gpio6 20 IRQ_TYPE_EDGE_FALLING>, <&gpio6 21 IRQ_TYPE_EDGE_FALLING>; /* 180, 181 */
+ interrupts-extended = <&gpio6 20 IRQ_TYPE_EDGE_FALLING>, <&gpio6 21 IRQ_TYPE_EDGE_FALLING>; /* 180, 181 */
/* click flags */
st,click-single-x;
diff --git a/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd35.dtsi b/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd35.dtsi
index 0da561a23f36..2f7a4a717359 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd35.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd35.dtsi
@@ -103,7 +103,7 @@ ads7846reg: ads7846-reg {
backlight {
compatible = "gpio-backlight";
-
+
pinctrl-names = "default";
pinctrl-0 = <&backlight_pins>;
gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>; /* gpio_145 */
diff --git a/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd43.dtsi b/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd43.dtsi
index 981f02f088f8..35701f596972 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd43.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3-overo-common-lcd43.dtsi
@@ -134,7 +134,7 @@ ads7846reg: ads7846-reg {
backlight {
compatible = "gpio-backlight";
-
+
pinctrl-names = "default";
pinctrl-0 = <&backlight_pins>;
gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>; /* gpio_145 */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net v2] selftests: net: make busywait timeout clock portable
From: patchwork-bot+netdevbpf @ 2026-07-06 10:20 UTC (permalink / raw)
To: Nirmoy Das
Cc: davem, edumazet, kuba, pabeni, shuah, netdev, linux-kselftest,
stable
In-Reply-To: <20260630165157.3814871-1-nirmoyd@nvidia.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 30 Jun 2026 09:51:57 -0700 you wrote:
> loopy_wait() expects millisecond timestamps. However, Ubuntu Resolute
> can use uutils date, where `date -u +%s%3N` returns seconds plus full
> nanoseconds instead of a 3-digit millisecond field. This makes
> busywait expire too early and can make vlan_bridge_binding.sh read a
> stale operstate.
>
> Fixes: 25ae948b4478 ("selftests/net: add lib.sh")
> Cc: stable@vger.kernel.org # 6.8+
> Link: https://github.com/uutils/coreutils/issues/11658
> Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
>
> [...]
Here is the summary with links:
- [net,v2] selftests: net: make busywait timeout clock portable
https://git.kernel.org/netdev/net/c/dd6a23bac306
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] selftests/tc-testing: Add tests that force multiq and taprio to enqueue to child's gso_skb
From: patchwork-bot+netdevbpf @ 2026-07-06 10:20 UTC (permalink / raw)
To: Victor Nogueira
Cc: davem, edumazet, kuba, pabeni, jhs, jiri, netdev, hexlabsecurity,
pctammela
In-Reply-To: <20260630153651.249752-1-victor@mojatatu.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 30 Jun 2026 12:36:51 -0300 you wrote:
> Add test cases to reproduce scenarios fixed recently [1] where
> multiqueue and taprio forced their children into enqueueing an skb to
> gso_skb (during peek), but failed to dequeue from gso_skb because they
> called the child's dequeue callback directly. This causes a desync in the
> child's qlen/backlog and results in an eventual null-ptr-deref (with a
> qfq or dualpi2 child).
>
> [...]
Here is the summary with links:
- [net] selftests/tc-testing: Add tests that force multiq and taprio to enqueue to child's gso_skb
https://git.kernel.org/netdev/net-next/c/1704cc864070
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 bpf-next 2/6] bpf: Add ksock kfuncs
From: bot+bpf-ci @ 2026-07-06 10:30 UTC (permalink / raw)
To: mahe.tardy, bpf
Cc: andrew+netdev, andrii, ast, daniel, davem, eddyz87, edumazet,
john.fastabend, kuba, liamwisehart, martin.lau, pabeni, song,
netdev, mahe.tardy, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260706093525.13030-3-mahe.tardy@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
> diff --git a/net/core/bpf_ksock.c b/net/core/bpf_ksock.c
> new file mode 100644
> index 000000000000..8bde734bc917
> --- /dev/null
> +++ b/net/core/bpf_ksock.c
[ ... ]
> @@ -0,0 +1,516 @@
[ ... ]
> +static int __init bpf_ksock_kfunc_init(void)
> +{
> + int ret;
> + const struct btf_id_dtor_kfunc bpf_ksock_dtors[] = {
> + {
> + .btf_id = bpf_ksock_dtor_ids[0],
> + .kfunc_btf_id = bpf_ksock_dtor_ids[1],
> + },
> + };
> +
> + ret = register_pernet_subsys(&bpf_ksock_net_ops);
> + if (ret)
> + return ret;
> +
> + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL,
> + &ksock_init_kfunc_set);
> + if (ret) {
> + unregister_pernet_subsys(&bpf_ksock_net_ops);
> + return ret;
> + }
> +
> + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL,
> + &ksock_kfunc_set);
> + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_LSM,
> + &ksock_kfunc_set);
> + return ret = ret ?: register_btf_id_dtor_kfuncs(bpf_ksock_dtors,
> + ARRAY_SIZE(bpf_ksock_dtors),
> + THIS_MODULE);
^^^^
This isn't a bug, but in the final return statement the assignment
to ret looks like a dead store since the value is returned right
away. Could this just be:
return ret ?: register_btf_id_dtor_kfuncs(bpf_ksock_dtors,
ARRAY_SIZE(bpf_ksock_dtors),
THIS_MODULE);
> +}
> +
> +late_initcall(bpf_ksock_kfunc_init);
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28783010022
^ permalink raw reply
* Re: [PATCH net-next v11 02/12] enic: verify firmware supports V2 SR-IOV at probe time
From: Breno Leitao @ 2026-07-06 10:43 UTC (permalink / raw)
To: Satish Kharat
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev, linux-kernel, Sesidhar Baddela
In-Reply-To: <20260703-enic-sriov-v2-admin-channel-v2-v11-2-5b739f1fe9e5@cisco.com>
On Fri, Jul 03, 2026 at 11:08:51AM -0700, Satish Kharat wrote:
> During PF probe, query the firmware get-supported-feature interface
> to verify that the running firmware supports V2 SR-IOV. Firmware
> version 5.3(4.72) and later report VIC_FEATURE_SRIOV via
> CMD_GET_SUPP_FEATURE_VER. If the firmware does not support the
> feature, set vf_type to ENIC_VF_TYPE_NONE and log a warning so the
> admin knows a firmware upgrade is needed.
>
> V2 VFs are only ever enabled later through the sysfs .sriov_configure
> path (enic_sriov_configure()), which rejects ENIC_VF_TYPE_NONE before
> calling pci_enable_sriov(); there is no probe-time auto-enable, so
> firmware that lacks V2 support never exposes VFs.
>
> VIC_FEATURE_SRIOV is assigned the explicit value 4 to match the
> firmware ABI. Slot 3 (firmware's VIC_FEATURE_PTP) is reserved with
> a comment rather than a placeholder enum entry, since PTP is not
> used by the upstream driver.
>
> Suggested-by: Breno Leitao <leitao@debian.org>
> Signed-off-by: Satish Kharat <satishkh@cisco.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: CL37 autonegotiation not working on amd-xgbe
From: Thorsten Leemhuis @ 2026-07-06 10:44 UTC (permalink / raw)
To: K.R, Prashanth Kumar, S-k, Shyam-sundar, Jakub Kicinski,
Banavara, Madhu
Cc: Patrick Oppenlander, netdev@vger.kernel.org,
Linux kernel regressions list
In-Reply-To: <MN6PR12MB8513D5386E2A586BE4FC68D7CF102@MN6PR12MB8513.namprd12.prod.outlook.com>
On 6/4/26 08:51, K.R, Prashanth Kumar wrote:
> On 5/6/26 05:55, Shyam Sundar S K wrote:
>> On 4/28/2026 04:58, Jakub Kicinski wrote:
>>> On Thu, 23 Apr 2026 10:18:49 +1000 Patrick Oppenlander wrote:
>>>> A recent change [1]
> FWIW, that was 42fd432fe6d320 ("amd-xgbe: align CL37 AN sequence as per
> databook") [v6.16-rc5]
>
>>>> stopped CL37 autonegotiation from working on amd-xgbe hardware.
>> Thanks for the bug report. Prashanth will maintain this driver going
>> forward.
>>
>> Prashanth, can you address this bug? Also, please update the
>> MAINTAINERS list by dropping Raju's name.
> Any progress? It looks like nothing happened to fix this regression since above mail, but I'm looking at things from the outside and there it's easy to miss something, so please tell me if that's the case.
>
> Thanks for the follow-up.
Side note: please fix your quoting, it leads to confusion.
> A fix has been identified and a patch is prepared. We are currently running regression testing to ensure the fix does not introduce any unintended issues. We will share the patch on the mailing list once regression validation is complete.
That was a months ago. Any progress? Didn't spot anything on the lists,
but it's easy to miss something.
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH net] ipvs: reset full ip_vs_seq structs in ip_vs_conn_new
From: patchwork-bot+netdevbpf @ 2026-07-06 10:50 UTC (permalink / raw)
To: Yizhou Zhao
Cc: netdev, horms, ja, pablo, fw, phil, davem, edumazet, kuba, pabeni,
lvs-devel, netfilter-devel, coreteam, linux-kernel, stable,
yangyx22, wangao, fengxw06, qli01, xuke
In-Reply-To: <20260702112837.81121-1-zhaoyz24@mails.tsinghua.edu.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Florian Westphal <fw@strlen.de>:
On Thu, 2 Jul 2026 19:28:36 +0800 you wrote:
> Commit 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in
> ip_vs_conn_new") changed ip_vs_conn_new() to allocate an ip_vs_conn
> object with kmem_cache_alloc(). The function then initializes many
> fields explicitly, but only resets in_seq.delta and out_seq.delta in the
> two struct ip_vs_seq members.
>
> That leaves init_seq and previous_delta uninitialized. This is normally
> harmless while the corresponding IP_VS_CONN_F_IN_SEQ or
> IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync
> message, however, ip_vs_proc_conn() preserves those flags from
> IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits
> IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with
> SEQ flags set but with the rest of in_seq/out_seq still containing stale
> slab data.
>
> [...]
Here is the summary with links:
- [net] ipvs: reset full ip_vs_seq structs in ip_vs_conn_new
https://git.kernel.org/netdev/net/c/2975324d164c
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 1/9] netfilter: nf_nat_sip: reload possible stale data pointer
From: patchwork-bot+netdevbpf @ 2026-07-06 10:50 UTC (permalink / raw)
To: Florian Westphal
Cc: netdev, pabeni, davem, edumazet, kuba, netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-2-fw@strlen.de>
Hello:
This series was applied to netdev/net.git (main)
by Florian Westphal <fw@strlen.de>:
On Fri, 3 Jul 2026 14:57:01 +0200 you wrote:
> quoting sashiko:
> ------------------------------------------------------------------------
> [..] noticed a potential memory bug and header corruption involving the
> SIP NAT helper.
>
> In net/netfilter/nf_nat_sip.c:nf_nat_sip():
> if (skb_ensure_writable(skb, skb->len)) {
> nf_ct_helper_log(skb, ct, "cannot mangle packet");
> return NF_DROP;
> }
> uh = (void *)skb->data + protoff;
> uh->dest = ct_sip_info->forced_dport;
> if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff,
> 0, 0, NULL, 0)) {
>
> [...]
Here is the summary with links:
- [net,1/9] netfilter: nf_nat_sip: reload possible stale data pointer
https://git.kernel.org/netdev/net/c/77e43bcb7ec1
- [net,2/9] netfilter: xt_u32: reject invalid shift counts
https://git.kernel.org/netdev/net/c/64cdf7d30ac1
- [net,3/9] netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()
https://git.kernel.org/netdev/net/c/444853cd4382
- [net,4/9] netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master on updates
https://git.kernel.org/netdev/net/c/278296b69fae
- [net,5/9] netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop
https://git.kernel.org/netdev/net/c/43ccc20b5a73
- [net,6/9] netfilter: nft_set_rbtree: get command skips end element with open interval
https://git.kernel.org/netdev/net/c/d63611cbe8af
- [net,7/9] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
https://git.kernel.org/netdev/net/c/6b335af0d0d1
- [net,8/9] ipvs: reset full ip_vs_seq structs in ip_vs_conn_new
https://git.kernel.org/netdev/net/c/2975324d164c
- [net,9/9] netfilter: xt_connmark: reject invalid shift parameters
https://git.kernel.org/netdev/net/c/1b47026fb4b3
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] net: qualcomm: rmnet: validate MAP frame length before ingress parsing
From: patchwork-bot+netdevbpf @ 2026-07-06 10:50 UTC (permalink / raw)
To: Xiang Mei
Cc: subash.a.kasiviswanathan, sean.tranchetti, netdev, andrew+netdev,
davem, edumazet, kuba, pabeni, linux-kernel, bestswngs
In-Reply-To: <20260630174110.2003121-1-xmei5@asu.edu>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 30 Jun 2026 10:41:09 -0700 you wrote:
> When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes
> the skb straight to __rmnet_map_ingress_handler(), skipping the length
> validation that rmnet_map_deaggregate() performs on the aggregated path.
> The parser then dereferences the MAP header and csum header/trailer based on
> the on-wire pkt_len without checking skb->len, so a short frame is read out
> of bounds:
>
> [...]
Here is the summary with links:
- [net,v2] net: qualcomm: rmnet: validate MAP frame length before ingress parsing
https://git.kernel.org/netdev/net/c/f0f1887a9e30
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] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
From: patchwork-bot+netdevbpf @ 2026-07-06 10:50 UTC (permalink / raw)
To: Yizhou Zhao
Cc: netdev, horms, ja, pablo, fw, phil, davem, edumazet, kuba, pabeni,
lvs-devel, netfilter-devel, coreteam, linux-kernel, stable,
yangyx22, wangao, fengxw06, qli01, xuke
In-Reply-To: <20260702073430.67680-1-zhaoyz24@mails.tsinghua.edu.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Florian Westphal <fw@strlen.de>:
On Thu, 2 Jul 2026 15:34:28 +0800 you wrote:
> When an ICMP Fragmentation Needed error is received for a tunneled IPVS
> connection, ip_vs_in_icmp() recomputes the MTU that the original packet
> can use by subtracting the tunnel overhead from the reported next-hop
> MTU.
>
> The current code always subtracts sizeof(struct iphdr), which is only
> the IPIP overhead. For GUE and GRE tunnels, ipvs_udp_decap() and
> ipvs_gre_decap() already compute the additional tunnel header length,
> but that value is scoped to the decapsulation block and is lost before
> the ICMP_FRAG_NEEDED handling. As a result, the ICMP error sent back to
> the client advertises an MTU that is too large, so PMTUD can fail to
> converge for GUE/GRE-tunneled real servers.
>
> [...]
Here is the summary with links:
- [net,v2] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
https://git.kernel.org/netdev/net/c/6b335af0d0d1
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] net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket
From: patchwork-bot+netdevbpf @ 2026-07-06 11:00 UTC (permalink / raw)
To: Xiang Mei
Cc: sidraya, alibuda, dust.li, wenjia, mjambigi, tonylu, guwen,
netdev, davem, edumazet, kuba, pabeni, horms, hwippel, linux-rdma,
linux-s390, bestswngs
In-Reply-To: <20260630183227.2044998-1-xmei5@asu.edu>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 30 Jun 2026 11:32:27 -0700 you wrote:
> smc_cdc_rx_handler() looks up the connection by token under the link
> group's conns_lock, drops the lock, and then dereferences conn and the
> smc_sock derived from it, ending in sock_hold(&smc->sk) inside
> smc_cdc_msg_recv(). No reference is held across the lock release.
>
> The only reference pinning the socket while the connection is
> discoverable in the link group is taken in smc_lgr_register_conn()
> (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both
> under conns_lock. Once the handler drops conns_lock, a concurrent
> close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn()
> can drop that reference and free the smc_sock, so the handler's later
> sock_hold() runs on freed memory:
>
> [...]
Here is the summary with links:
- [net,v2] net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket
https://git.kernel.org/netdev/net/c/9d160b35cc34
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 1/1] net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload
From: patchwork-bot+netdevbpf @ 2026-07-06 11:00 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, edumazet, kuba, pabeni, horms, jiri, victor,
security, zdi-disclosures, stable
In-Reply-To: <20260701161912.125355-1-jhs@mojatatu.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 1 Jul 2026 12:19:12 -0400 you wrote:
> There is a TOCTOU race condition in flower lockless approach between sizing
> a flow_rule buffer and filling it.
> zdi-disclosures@trendmicro.com reports:
> The cls_flower classifier operates with TCF_PROTO_OPS_DOIT_UNLOCKED
> (fl_change runs without RTNL), while RTM_NEWACTION holds RTNL, so the
> independent locking domains make the race reachable in practice. KASAN
> confirms:
> BUG: KASAN: slab-out-of-bounds in tcf_pedit_offload_act_setup+0x81b/0x930
> Write of size 4 at addr ffff888001f27520 by task poc-toctou/312
> The buggy address is located 0 bytes to the right of
> allocated 288-byte region [ffff888001f27400, ffff888001f27520)
> (cache kmalloc-512)
>
> [...]
Here is the summary with links:
- [net,1/1] net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload
https://git.kernel.org/netdev/net/c/8b519cbcabe8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Bug 221606] r8169: PCIe AER errors and recovery failure after recent driver changes
From: Thorsten Leemhuis @ 2026-07-06 11:03 UTC (permalink / raw)
To: Lasse Bjerre, Javen
Cc: netdev@vger.kernel.org, Heiner Kallweit,
Linux kernel regressions list
In-Reply-To: <PA4PR02MB6991F71D748EE9A99191EEACDA1E2@PA4PR02MB6991.eurprd02.prod.outlook.com>
On 6/10/26 19:58, Lasse Bjerre wrote:
>
> Absolutely, I have attached a full dmesg from a fresh boot as well as
> the output of lspci.
> Important to note (should have done so earlier) that I have manually
> turned on l1_1_aspm using a udev rule. It is not on by default, but has
> worked flawlessly until the issue in question.
Hmm, seems nothing happened since then -- or was there progress and I
just missed it? If not: is this intentional (due to manually enabling
l1_1_aspm maybe?), or did this regression fall through the cracks?
Ciao, Thorsten
> ------------------------------------------------------------------------
> *From:* Javen <javen_xu@realsil.com.cn>
> *Sent:* 04 June 2026 11:01
> *To:* Heiner Kallweit <hkallweit1@gmail.com>
> *Cc:* netdev@vger.kernel.org <netdev@vger.kernel.org>; Lasse Bjerre
> <lasse@lgb.dk>
> *Subject:* RE: [Bug 221606] r8169: PCIe AER errors and recovery failure
> after recent driver changes
>
>>On 03.06.2026 09:44, bugzilla-daemon@kernel.org wrote:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=221606 <https://
> bugzilla.kernel.org/show_bug.cgi?id=221606>
>>>
>>> --- Comment #2 from lasse@lgb.dk ---
>>> Commit 9ab94a32af704fa9c873094283ae8744a07baf25 (r8169: enable LTR
>>> support) seems to be the issue. Running the commit before this doesn't
>>> give me any AER errors and everything seems to behave normally.
>>>
>>Bisecting the reported issue points to one of your commits.
>>Could you please check with the user?
>
> Hi, Heiner, Lasse
>
> Thanks for reporting this issue.
>
> Currently, we haven't received any similar reports from our customers,
> and I am unable to reproduce this AER error on my local test platforms.
>
> Could you please provide some more detailed information? The full dmesg
> log will help me check the exact AER error messages and the boot
> context. Also the output of sudo lspci -vvv. I need this to check the
> exact platform information, PCIe topology, and the LTR/ASPM capabilities
> of both your Root Port and the Realtek NIC.
>
> While reviewing the initialization flow, I noticed a potential logic
> contradiction. If rtl_aspm_is_safe(tp) returns false, the driver
> disables L1 at the PCIe core level, but tp->aspm_manageable might still
> be set to true. This could cause the driver to incorrectly enable ASPM/
> LTR in the MAC registers later, creating a hardware state mismatch (PCIe
> L1 disabled, but MAC LTR enabled) which usually leads to AER.
>
> Could you please test if the following patch fixes the AER error on your
> side?
>
> - if (enable && tp->aspm_manageable) {
> + if (enable && tp->aspm_manageable && rtl_aspm_is_safe(tp)) {
>
> Thanks,
> BRs,
> Javen
^ permalink raw reply
* Re: [PATCH net] net: stmmac: raise TX completion interrupt at the end of an xmit burst
From: Maciej Fijalkowski @ 2026-07-06 11:04 UTC (permalink / raw)
To: Johan Alvarado
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, Jose.Abreu, pavel, netdev, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <0100019f35ea26e0-42ad009c-01ab-4a8f-b126-fa65fbacae5c-000000@email.amazonses.com>
On Mon, Jul 06, 2026 at 05:32:45AM +0000, Johan Alvarado wrote:
> The TX mitigation logic only sets the Interrupt on Completion bit once
> every tx_coal_frames descriptors (STMMAC_TX_FRAMES = 25), with the
> tx_coal_timer hrtimer (STMMAC_COAL_TX_TIMER = 5000 us) as the only
> fallback. TX skbs are freed exclusively from the TX completion path,
> so any flow that keeps fewer than 25 frames in flight has all of its
> skbs held for up to 5 ms after transmission.
>
> Paced flows never queue enough frames to reach the frame threshold:
> TCP Small Queues caps the amount of unfreed data at roughly two pacing
> intervals worth, which at moderate pacing rates is only a couple of
> packets. Every small burst then stalls until the coalesce timer fires,
> and throughput collapses to approximately tsq_limit / tx_coal_timer
> regardless of link capacity.
>
> This is easily reproducible with BBR, which paces its output and thus
> keeps only a few frames in flight at a time. On a YT6801
> (dwmac-motorcomm) equipped Orange Pi 5 Pro, a BBR upload over a ~23 ms
> RTT path is capped at 5.24 Mbit/s, while CUBIC reaches 207 Mbit/s on
> the same path. BBR measures the stalled send rate as the path
> bandwidth and locks its estimate near the floor, so the connection
> never recovers. Lowering the coalesce settings with ethtool -C
> (tx-usecs 100 tx-frames 1) lifts the same transfer to 447 Mbit/s,
> confirming the mechanism.
>
> Fix this by setting the IC bit on the last descriptor of every xmit
> burst, i.e. whenever netdev_xmit_more() reports that no further frames
> are pending in the current dequeue batch. Frame-based coalescing still
> applies within a burst, bulk traffic keeps batching through qdisc bulk
> dequeue and NAPI polling, and the coalesce timer becomes a pure
> fallback instead of the primary completion mechanism for lightly
> queued flows.
>
> tx-frames 0 keeps its meaning of timer-based mitigation only.
>
> Fixes: da2024510031 ("net: stmmac: Tune-up default coalesce settings")
> Signed-off-by: Johan Alvarado <contact@c127.dev>
> ---
> Notes for reviewers (not for the changelog):
>
> Tested on an Orange Pi 5 Pro (RK3588, Motorcomm YT6801 PCIe GbE via
> dwmac-motorcomm), iperf3 upload to a public server over a ~23 ms RTT
> path, coalesce settings left at their shipped values (tx-usecs 5000,
> tx-frames 25):
>
> before, BBR: 5.24 Mbit/s (cwnd pinned, bw estimate ~6 Mbit/s)
> before, CUBIC: 207 Mbit/s
> after, BBR: 447 Mbit/s
>
> Interrupt overhead stays sane: ~3.3k NIC IRQs/s total at 447 Mbit/s
> (~38 kpps), i.e. roughly 12 packets per interrupt, since qdisc bulk
> dequeue plus NAPI polling still coalesce within bursts.
>
> The 5000 us STMMAC_COAL_TX_TIMER value postdates the tagged commit
> (it was 1000 us back then); the stall mechanism is the same, only the
> throughput ceiling differs, hence the Fixes tag on the frame-count
> change.
>
> The XSK/XDP TX paths keep their frame-count-only IC logic: there is
> no skb/TSQ backpressure on those paths, and netdev_xmit_more() is not
> meaningful outside ndo_start_xmit.
>
> The same completion starvation was reported by Pavel Machek in 2016
> (UDP burst pauses, back then a 40 ms low-res timer):
> https://lore.kernel.org/netdev/20161123105125.GA26394@amd/
> His patch disabling TX coalescing entirely was rejected in favour of
> "a real solution":
> https://lore.kernel.org/netdev/20161205122711.GA30774@amd/
Very messy thread. To reiterate - does tx coalescing do any good in this
driver?
I did some digging and seems there was a rework of coalescing in 2018 and
then some more polishing happened in 2023 (net: stmmac: improve TX timer
arm logic).
> The subsequent hrtimer conversion fixed the timer resolution but kept
> the timer as the only completion mechanism for lightly queued flows;
Wouldn't your change imply that tx coalescing could be dropped altogether?
I do agree that each single batch of tx descs should be signalled with ic
bit at the end.
> this patch adds the missing burst-end interrupt.
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 2a0d7eff88d3..ddf4ac03538d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -4626,6 +4626,8 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> set_ic = true;
> else if (!priv->tx_coal_frames[queue])
> set_ic = false;
> + else if (!netdev_xmit_more())
> + set_ic = true;
> else if (tx_packets > priv->tx_coal_frames[queue])
> set_ic = true;
> else if ((tx_q->tx_count_frames %
> @@ -4910,6 +4912,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> set_ic = true;
> else if (!priv->tx_coal_frames[queue])
> set_ic = false;
> + else if (!netdev_xmit_more())
> + set_ic = true;
> else if (tx_packets > priv->tx_coal_frames[queue])
> set_ic = true;
> else if ((tx_q->tx_count_frames %
> --
> 2.55.0
>
>
^ permalink raw reply
* Re: [PATCH net] amt: fix size calculation in amt_get_size()
From: patchwork-bot+netdevbpf @ 2026-07-06 11:10 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, kuniyu, andrew+netdev, netdev,
eric.dumazet
In-Reply-To: <20260701122329.3562825-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 1 Jul 2026 12:23:29 +0000 you wrote:
> amt_get_size() incorrectly used sizeof(struct iphdr) for the sizes of
> IFLA_AMT_DISCOVERY_IP, IFLA_AMT_REMOTE_IP, and IFLA_AMT_LOCAL_IP.
> These attributes contain IPv4 addresses (__be32), not full IP headers.
>
> Replace sizeof(struct iphdr) with sizeof(__be32) to avoid over-allocating
> netlink message space.
>
> [...]
Here is the summary with links:
- [net] amt: fix size calculation in amt_get_size()
https://git.kernel.org/netdev/net/c/9e05e91a9a84
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net v2] packet: avoid re-registering fanout hook after device unregister
From: David Lee @ 2026-07-06 11:12 UTC (permalink / raw)
To: Willem de Bruijn
Cc: David Lee, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman,
Dominik 'Disconnect3d' Czarnota, netdev, linux-kernel
packet_set_ring() temporarily detaches a socket from packet delivery while
reconfiguring its ring. It records the previous running state, clears
po->num, unregisters the protocol hook when needed, drops po->bind_lock,
and later restores po->num and re-registers the hook from the saved
was_running value.
That unlocked window can race with NETDEV_UNREGISTER. The notifier can
observe the socket as not running, skip __unregister_prot_hook(), and
invalidate the per-socket binding by setting po->ifindex to -1 and clearing
po->prot_hook.dev. A one-member fanout group can still retain its shared
fanout hook device pointer. When packet_set_ring() resumes, re-registering
solely from the stale was_running state can re-add the fanout hook after
the device has been unregistered.
Treat po->ifindex == -1 as an invalidated binding after reacquiring
po->bind_lock. Restore po->num as before, but do not re-register the hook
if device unregister already detached the socket.
Fixes: dc99f600698d ("packet: Add fanout support.")
Reported-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: David Lee <david.lee@trailofbits.com>
Assisted-by: Codex:gpt-5
---
Changes in v2:
- Add Fixes and Reported-by tags.
- Fix the incorrect Signed-off-by tag from v1.
Trail of Bits has a PoC that achieves local privilege escalation using this
bug on a custom kernel config with CONFIG_LIST_HARDENED disabled, which can
be shared further if needed.
net/packet/af_packet.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -4561,7 +4561,11 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
spin_lock(&po->bind_lock);
WRITE_ONCE(po->num, num);
- if (was_running)
+ /*
+ * NETDEV_UNREGISTER may have invalidated the binding while bind_lock
+ * was dropped above. Do not re-add a fanout hook to a dead device.
+ */
+ if (was_running && READ_ONCE(po->ifindex) != -1)
register_prot_hook(sk);
spin_unlock(&po->bind_lock);
--
2.43.0
^ permalink raw reply
* Re: [PATCH 02/13] m68k/coldfire: replace linux/gpio.h inclusions
From: Greg Ungerer @ 2026-07-06 11:22 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Thomas Bogendoerfer, Hauke Mehrtens,
Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-3-arnd@kernel.org>
Hi Arnd,
On 29/6/26 23:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for coldfire.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For the ColdFire changes, LGTM:
Reviewed-by: Greg Ungerer <gerg@linux-m68k.com>
Regards
Greg
> ---
> arch/m68k/coldfire/device.c | 2 +-
> arch/m68k/include/asm/mcfgpio.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
> index 1420bae0964f..9a0258acd998 100644
> --- a/arch/m68k/coldfire/device.c
> +++ b/arch/m68k/coldfire/device.c
> @@ -12,7 +12,7 @@
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/spi/spi.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
> #include <linux/fec.h>
> #include <linux/dmaengine.h>
> #include <asm/traps.h>
> diff --git a/arch/m68k/include/asm/mcfgpio.h b/arch/m68k/include/asm/mcfgpio.h
> index 7103cfa4edb6..29726aa40eb6 100644
> --- a/arch/m68k/include/asm/mcfgpio.h
> +++ b/arch/m68k/include/asm/mcfgpio.h
> @@ -16,7 +16,7 @@ int __mcfgpio_request(unsigned gpio);
> void __mcfgpio_free(unsigned gpio);
>
> #ifdef CONFIG_GPIOLIB
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
> #else
>
> /* our alternate 'gpiolib' functions */
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net: pse-pd: add Realtek/Broadcom PSE MCU driver
From: Jonas Jelonek @ 2026-07-06 11:22 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, devicetree, linux-kernel, Daniel Golle, Bjørn Mork,
Conor Dooley, Krzysztof Kozlowski, David S . Miller, Andrew Lunn,
Eric Dumazet, Jakub Kicinski, Rob Herring, Kory Maincent,
Oleksij Rempel
In-Reply-To: <2ee45ab5-a329-4891-8326-ac8f14b6374a@redhat.com>
Hi Paolo,
On 03.07.26 09:55, Paolo Abeni wrote:
> On 6/30/26 12:56 PM, Jonas Jelonek wrote:
>> A range of PoE switches use a small microcontroller on the PCB to front
>> the actual PSE silicon. The host CPU talks to that MCU over I2C/SMBus or
>> UART using a fixed 12-byte request/response protocol with a trailing
>> checksum; the PSE chips are managed by the MCU and are not accessed
>> directly. The same protocol family is spoken by Realtek and Broadcom PSE
>> MCUs, diverging in opcode numbering and a few response layouts, which the
>> driver abstracts behind a per-dialect opcode table and parser hooks
>> selected by the compatible. The specific PSE chip behind the MCU is
>> detected at runtime and only influences per-chip constants (power scaling
>> and the per-port cap).
>>
>> The driver is split into a shared core and two transport modules:
>>
>> - PSE_REALTEK_MCU: protocol, message framing, dialect machinery, and the
>> pse_controller_ops glue.
>> - PSE_REALTEK_MCU_I2C / PSE_REALTEK_MCU_UART: transport modules
>> registering the MCU on an I2C bus or a serdev port respectively.
>>
>> The realtek-pse-mcu-* files and PSE_REALTEK_MCU* symbols match the
>> realtek,pse-mcu-rtk / realtek,pse-mcu-brcm compatibles: all name the
>> Realtek PSE-MCU front-end, not the MCU silicon or the PSE chip behind
>> it (see the binding for the prefix rationale). Broadcom PSE MCUs speak
>> the same protocol family and are handled by the same shared core
>> through the dialect abstraction selected by the '-brcm' compatible.
>>
>> Power budgeting is left to the MCU firmware; the driver advertises
>> PSE_BUDGET_EVAL_STRAT_DYNAMIC (controller-managed budget) accordingly.
>>
>> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
>> ---
>> MAINTAINERS | 7 +
>> drivers/net/pse-pd/Kconfig | 28 +
>> drivers/net/pse-pd/Makefile | 3 +
>> drivers/net/pse-pd/realtek-pse-mcu-core.c | 1019 +++++++++++++++++++++
>> drivers/net/pse-pd/realtek-pse-mcu-i2c.c | 163 ++++
>> drivers/net/pse-pd/realtek-pse-mcu-uart.c | 156 ++++
>> drivers/net/pse-pd/realtek-pse-mcu.h | 87 ++
>> 7 files changed, 1463 insertions(+)
>> create mode 100644 drivers/net/pse-pd/realtek-pse-mcu-core.c
>> create mode 100644 drivers/net/pse-pd/realtek-pse-mcu-i2c.c
>> create mode 100644 drivers/net/pse-pd/realtek-pse-mcu-uart.c
>> create mode 100644 drivers/net/pse-pd/realtek-pse-mcu.h
> This is quite large, and shouls be split in smaller patches to help
> reviewers.
>
> [...]
>> +struct rtpse_mcu_dialect {
>> + struct rtpse_mcu_opcode opcode[RTPSE_MCU_NUM_CMDS];
>> +
>> + /*
>> + * Response parsers. Each dialect must supply its own; the core calls
>> + * these unconditionally rather than carrying a default that would
>> + * silently mis-decode bytes from a dialect that forgot to set them.
>> + */
>> + int (*parse_system_info)(const u8 *payload, struct rtpse_mcu_info *info);
> The 2 existing implementation always return 0; you may consider change
> it to a void function.
>
>> +static int rtpse_mcu_port_get_voltage(struct pse_controller_dev *pcdev, int id)
>> +{
>> + struct rtpse_mcu_ctrl *pse = to_rtpse_mcu_ctrl(pcdev);
>> + struct rtpse_mcu_port_measurement measurement;
>> + int ret;
>> + u32 uV;
>> +
>> + ret = rtpse_mcu_port_get_measurement(pse, id, &measurement);
>> + if (ret)
>> + return ret;
>> +
>> + /* 64.45mV per LSB */
>> + uV = (u32)measurement.voltage_raw * 64450U;
> This cast ^^^^^ should be unneeded.
>
>> + return min_t(u32, uV, INT_MAX);
>> +}
>> +
>> +static int rtpse_mcu_port_enable(struct pse_controller_dev *pcdev, int id)
>> +{
>> + return rtpse_mcu_port_set_state(to_rtpse_mcu_ctrl(pcdev), id, true);
>> +}
>> +
>> +static int rtpse_mcu_port_disable(struct pse_controller_dev *pcdev, int id)
>> +{
>> + return rtpse_mcu_port_set_state(to_rtpse_mcu_ctrl(pcdev), id, false);
>> +}
>> +
>> +static int rtpse_mcu_port_get_pw_limit(struct pse_controller_dev *pcdev, int id)
>> +{
>> + struct rtpse_mcu_ctrl *pse = to_rtpse_mcu_ctrl(pcdev);
>> + struct rtpse_mcu_port_ext_config config;
>> + int ret;
>> +
>> + ret = rtpse_mcu_port_get_ext_config(pse, id, &config);
>> + if (ret)
>> + return ret;
>> +
>> + return config.max_power * pse->chip->pw_read_lsb_mW;
>> +}
>> +
>> +static int rtpse_mcu_port_set_pw_limit(struct pse_controller_dev *pcdev, int id, int max_mW)
>> +{
>> + const struct rtpse_mcu_opcode *type_opc, *val_opc;
>> + struct rtpse_mcu_ctrl *pse = to_rtpse_mcu_ctrl(pcdev);
>> + const struct rtpse_mcu_chip_info *chip = pse->chip;
>> + unsigned int prg_val;
>> + int ret;
>> +
>> + if (max_mW < 0 || max_mW > chip->max_mW_per_port)
>> + return -ERANGE;
>> +
>> + type_opc = &pse->dialect->opcode[RTPSE_MCU_CMD_PORT_SET_POWER_LIMIT_TYPE];
>> + val_opc = &pse->dialect->opcode[chip->pw_set_cmd];
>> + if (!type_opc->valid || !val_opc->valid)
>> + return -EOPNOTSUPP;
>> +
>> + /*
>> + * Switch the port to user-defined limit mode first, then program the
>> + * limit value. If the second cmd fails, the port is left in
>> + * user-defined mode but with the previous limit value; the next
>> + * successful set_pw_limit call recovers it.
>> + */
>> + ret = rtpse_mcu_port_cmd(pse, id, type_opc->op, RTPSE_MCU_PORT_PW_LIMIT_TYPE_USER);
>> + if (ret)
>> + return ret;
>> +
>> + prg_val = min_t(unsigned int, max_mW / chip->pw_set_lsb_mW, 0xff);
>> +
>> + return rtpse_mcu_port_cmd(pse, id, val_opc->op, prg_val);
>> +}
>> +
>> +static int rtpse_mcu_port_get_pw_limit_ranges(struct pse_controller_dev *pcdev, int id,
>> + struct pse_pw_limit_ranges *out)
>> +{
>> + struct ethtool_c33_pse_pw_limit_range *range;
>> + struct rtpse_mcu_ctrl *pse = to_rtpse_mcu_ctrl(pcdev);
>> +
>> + range = kzalloc_obj(*range, GFP_KERNEL);
> or just:
>
> range = kzalloc_obj(*range);
>
>
>> +static int rtpse_mcu_discover(struct rtpse_mcu_ctrl *pse, struct rtpse_mcu_info *info)
>> +{
>> + struct rtpse_mcu_ext_config ext_config;
>> + unsigned long deadline;
>> + int ret;
>> +
>> + /*
>> + * The MCU may not answer on the bus yet right after power-up or
>> + * enable-gpios assertion: depending on the transport it either stays
>> + * silent (-ETIMEDOUT) or does not ACK its address at all (-ENXIO /
>> + * -EREMOTEIO). Retry within a bounded wall-time window so a slow boot
>> + * still probes, while a genuinely unresponsive MCU fails with its real
>> + * error instead of deferring forever and masking it.
>> + */
>> + deadline = jiffies + msecs_to_jiffies(RTPSE_MCU_BOOT_TIMEOUT_MS);
>> + do {
>> + ret = rtpse_mcu_get_info(pse, info);
>> + if (ret != -ETIMEDOUT && ret != -ENXIO && ret != -EREMOTEIO &&
>> + ret != -EAGAIN)
>> + break;
>> + msleep(RTPSE_MCU_BOOT_RETRY_MS);
>> + } while (time_before(jiffies, deadline));
>> + if (ret)
>> + return dev_err_probe(pse->dev, ret, "failed to read MCU info\n");
>> +
>> + switch (info->device_id) {
>> + case RTPSE_MCU_DEVICE_ID_RTL8238B:
>> + pse->chip = &rtl8238b_info;
>> + break;
>> + case RTPSE_MCU_DEVICE_ID_RTL8239:
>> + pse->chip = &rtl8239_info;
>> + break;
>> + case RTPSE_MCU_DEVICE_ID_RTL8239C:
>> + pse->chip = &rtl8239c_info;
>> + break;
>> + case RTPSE_MCU_DEVICE_ID_BCM59111:
>> + pse->chip = &bcm59111_info;
>> + break;
>> + case RTPSE_MCU_DEVICE_ID_BCM59121:
>> + pse->chip = &bcm59121_info;
>> + break;
>> + default:
>> + return dev_err_probe(pse->dev, -EINVAL, "unknown PSE id 0x%x\n",
>> + info->device_id);
>> + }
>> +
>> + if (!info->max_ports || info->max_ports > RTPSE_MCU_MAX_PORTS)
>> + return dev_err_probe(pse->dev, -EINVAL,
>> + "MCU reports invalid port count %u\n", info->max_ports);
>> +
>> + ret = rtpse_mcu_get_ext_config(pse, &ext_config);
>> + if (ret)
>> + return dev_err_probe(pse->dev, ret, "failed to read MCU ext config\n");
>> +
>> + dev_info(pse->dev, "%s MCU, %s (id 0x%04x), %u ports across %u PSE chip(s)\n",
>> + pse->dialect->mcu_type_str(info->mcu_type), pse->chip->name,
>> + info->device_id, info->max_ports, ext_config.num_of_pses);
> The general guidance is to try to avoid unneeded print on dmsg, as they
> tend to scary admins, but I personally agree on message on modprobe.
>
> No strong opionion either ways.
>
> /P
>
Thanks for your remarks, I'll address them in v5.
Best regards,
Jonas
^ permalink raw reply
* [PATCH net-next v5 0/4] net: pse-pd: add Realtek/Broadcom PSE MCU support
From: Jonas Jelonek @ 2026-07-06 11:24 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: netdev, devicetree, linux-kernel, Daniel Golle, Bjørn Mork,
Jonas Jelonek
This series adds a PSE-PD driver for the microcontroller (MCU) that
fronts the PSE silicon on a range of managed switches, together with its
DT binding.
Hardware model
==============
These boards do not expose the PSE chips to the host directly. A small
microcontroller sits on an I2C/SMBus or UART bus and manages one or more
PSE chips behind it; the host CPU only ever talks to that MCU, using a
fixed 12-byte request/response protocol with a trailing checksum. The
PSE silicon never appears on the bus.
The same protocol family is used by MCUs fronting Realtek PSE chips
(RTL8238B, RTL8239, RTL8239C) and Broadcom PSE chips (BCM59111,
BCM59121), diverging in opcode numbering and a few response layouts. The
driver abstracts that behind a per-dialect opcode table and parser hooks,
selected by the compatible. The specific PSE chip behind the MCU is
detected at runtime and only influences per-chip constants (power scaling
and the per-port cap).
Why the compatible names the protocol, not the chip
===================================================
The compatibles are "realtek,pse-mcu-rtk" and "realtek,pse-mcu-brcm".
This is a deliberate choice and the part most likely to raise questions,
so the reasoning up front.
The node names the protocol dialect, not a part:
- The DT node describes the MCU, not a PSE chip: the PSE chips are
behind the MCU and never appear on the bus, so naming the node after
one (e.g. "realtek,rtl8239") would describe hardware that isn't at
that address.
- The PSE chips are, in principle, usable without this MCU (host-driven
directly) - different hardware with a different programming model
that would warrant its own binding. Claiming the PSE-chip compatibles
here would collide with that.
- Naming the MCU silicon is equally wrong: these are ordinary
general-purpose microcontrollers (GigaDevice, Nuvoton, ...) that vary
across boards and are not dedicated to this application.
- What is fixed, and all the driver needs at DT-parse time, is the
protocol dialect, so the compatible encodes exactly that. The
"realtek" prefix names the owner of the protocol the MCU runs -
Realtek documents it and supplies the firmware - following the
"google,cros-ec-*" pattern (the prefix is the protocol/firmware owner,
not the varying controller silicon). The "-rtk"/"-brcm" suffix selects
the Realtek or Broadcom dialect; the specific PSE chip behind the MCU
is detected at runtime.
One compatible per dialect spans both transports:
- The 12-byte wire protocol is identical over I2C/SMBus and UART; only
the plumbing differs (SMBus vs native framing on I2C, baud rate on
UART), and the transport is already expressed structurally by the
node's parent bus (i2c@... vs serial@...). A "-i2c"/"-uart" suffix
would only duplicate that, for a protocol that does not change across
transports.
- This is the multi-transport model used by e.g. "bosch,bmi160" (one
compatible, separate i2c and spi drivers binding it), rather than the
cros-ec model of per-transport compatibles - cros-ec splits because
its on-wire framing genuinely differs per bus, which is not the case
here.
The binding documents both points as well.
Testing
=======
- Linksys LGS328MPCv2 (RTL8238B, I2C)
- Unifi USW Pro XG 8 PoE (RTL8239, SMBus)
- Zyxel GS1900-10HP A1 (BCM59121, UART)
- Zyxel GS1900-10HP B1 (RTL8238B, UART)
- Zyxel GS1920-24HPv2 (BCM59121, SMBus)
- Zyxel XMG1915-10EP (RTL8239C, UART)
- Zyxel XS1930-12HP (RTL8239, SMBus)
---
v4 -> v5:
- split the single driver patch into three — core / I2C transport / UART
transport. Binding stays patch 1, unchanged in shape. (Paolo)
Please give guidance on how to if I should split more.
- core: set_pw_limit: guard divide-by-zero on pw_set_lsb_mW; cap the
programmed value with U8_MAX instead of a bare 0xff; prg_val is now u8.
(Oleksij, Sashiko)
- core: discover: also retry transient boot-time frames (-EBADMSG / -EBADE)
within the bounded window, not just silence/NAK/not-ready (Sashiko).
- core: pw_status: report Broadcom 0x3 → TEST and 0x5 → OTHERFAULT
(new STS_TEST/STS_OTHER_FAULT); pw_class comment corrected (0x3/0x5
aren't "other fault" on RTL; class-0-vs-fault note). (Sashiko)
- core: dropped unused decoded fields — function_mode, cls_type,
disconnect_type, pair_type, inrush_mode, limit_type, chip_addr,
channel. (Oleksij)
- core: removed forward declarations by moving the response structs above
the dialect struct. (Oleksij)
- core: get_pw_limit_ranges: reverse-Christmas-tree local ordering.
(Oleksij)
- core: dialect comment clarified (only divergent responses are hooked);
commit message "parser hooks" tightened to "…for the responses that
differ." (Sashiko)
- core: made parse_system_info hook void, both implementations return
hardcoded 0. (Paolo)
- core: dropped GFP_KERNEL from kzalloc_obj. (Paolo)
- core: dropped unneeded u32 cast
- kept probe dev_info() for now deliberately, due to different opinions
on whether a probe might print or not
- NOT included Acked-by from Oleksij, due to several changes
v4: https://lore.kernel.org/netdev/20260630105651.756058-1-jelonek.jonas@gmail.com/
v3 -> v4:
- move owner setting from core to transport, mitigating possible
use-after-free (Sashiko)
- resend because net-next was still closed
v3: https://lore.kernel.org/netdev/20260628222705.4052815-1-jelonek.jonas@gmail.com/
v2 -> v3:
- dt-bindings: using brcm instead of bcm for Broadcom
- rename the driver files and Kconfig symbols to realtek-pse-mcu-* /
PSE_REALTEK_MCU* for consistency with the realtek,pse-mcu-* compatibles
- rename driver-internal prefix from 'rtpse_' to 'rtpse_mcu' to
emphasize this targets the MCU-centric setup (and leaves room open
for eventual directly addressable PSE chips)
- rework the vendor-prefix rationale (binding + commit message): the
prefix names the protocol/firmware owner (Realtek documents the protocol
and supplies the firmware), and -rtk/-brcm select the Realtek or Broadcom
protocol dialect
- core: reject zeroed/echo-mismatched responses via the echoed seq_num
(a BCM PORT_ENABLE on port 0 was otherwise accepted from an all-zero
frame)
- core: enable the PoE supply before global-enabling the MCU, and roll
back the global enable on probe failure or driver removal
- core: drop inline from helpers (flagged by automated check)
- uart: update the completion under rx_lock too, so a late frame can no
longer make the next transaction fail spuriously with -EIO
v2: https://lore.kernel.org/netdev/20260612132944.460646-1-jelonek.jonas@gmail.com/
v1 -> v2:
- all points flagged by Sashiko addressed:
- uart: drop frame overflow (return count, not the stored length) so
serdev retains no leftover bytes that would misalign the next response
- uart: guard rx_buf/rx_len with a spinlock to close a data race between
the async receive_buf callback and send/recv
- i2c: return terminal MCU error opcodes (0xfd/0xfe) to the core
immediately instead of polling to the 1 s timeout
- core: cap BCM59121 at 30 W (802.3at) — the basic 8-bit set command
can't program the advertised 60 W (it silently clamped to 51 W)
v1: https://lore.kernel.org/netdev/20260608205758.1830521-1-jelonek.jonas@gmail.com/
---
Jonas Jelonek (4):
dt-bindings: net: pse-pd: add bindings for Realtek/Broadcom PSE MCU
net: pse-pd: add Realtek/Broadcom PSE MCU core
net: pse-pd: realtek-pse-mcu: add I2C transport
net: pse-pd: realtek-pse-mcu: add UART transport
.../bindings/net/pse-pd/realtek,pse-mcu.yaml | 154 +++
MAINTAINERS | 7 +
drivers/net/pse-pd/Kconfig | 28 +
drivers/net/pse-pd/Makefile | 3 +
drivers/net/pse-pd/realtek-pse-mcu-core.c | 1006 +++++++++++++++++
drivers/net/pse-pd/realtek-pse-mcu-i2c.c | 163 +++
drivers/net/pse-pd/realtek-pse-mcu-uart.c | 156 +++
drivers/net/pse-pd/realtek-pse-mcu.h | 87 ++
8 files changed, 1604 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
create mode 100644 drivers/net/pse-pd/realtek-pse-mcu-core.c
create mode 100644 drivers/net/pse-pd/realtek-pse-mcu-i2c.c
create mode 100644 drivers/net/pse-pd/realtek-pse-mcu-uart.c
create mode 100644 drivers/net/pse-pd/realtek-pse-mcu.h
base-commit: b73bc9ca3686b78b642fb35dcc1fdf874ecb74a1
--
2.51.0
^ permalink raw reply
* [PATCH net-next v5 1/4] dt-bindings: net: pse-pd: add bindings for Realtek/Broadcom PSE MCU
From: Jonas Jelonek @ 2026-07-06 11:24 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: netdev, devicetree, linux-kernel, Daniel Golle, Bjørn Mork,
Jonas Jelonek
In-Reply-To: <20260706112425.3149226-1-jelonek.jonas@gmail.com>
Add a binding for the microcontroller (MCU) that fronts the PSE silicon
on a range of managed switches. The host talks only to the MCU, over
I2C/SMBus or UART, using a fixed message-based protocol; the PSE chips
behind it never appear on the bus.
The compatible names the MCU front-end, not a specific part. These
boards front the PSE silicon with an MCU that presents a stable
message protocol Realtek documents. The PSE chip behind it varies
- Broadcom on older boards, Realtek on newer - and is detected at
runtime; the arrangement appears to be a Realtek MCU-based PoE design
carried across those PSE-chip generations. So the 'realtek' prefix
names that front-end (Realtek's protocol and firmware), not the
general-purpose MCU silicon or the PSE chip - the google,cros-ec-*
model. The '-rtk'/'-brcm' suffix selects the Realtek or Broadcom dialect.
A single compatible per dialect covers both the I2C/SMBus and UART
attachments: the wire protocol is identical across them and the transport
is expressed by the node's parent bus, so it is not encoded in the
compatible.
Both dialects share one protocol family and one device tree contract, so
they are documented in a single binding under the one 'realtek' prefix,
with the '-rtk'/'-brcm' suffix distinguishing the dialect.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
.../bindings/net/pse-pd/realtek,pse-mcu.yaml | 154 ++++++++++++++++++
1 file changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
diff --git a/Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml b/Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
new file mode 100644
index 000000000000..d0dfae220dc1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pse-pd/realtek,pse-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek/Broadcom PSE MCU
+
+maintainers:
+ - Jonas Jelonek <jelonek.jonas@gmail.com>
+
+description: |
+ Microcontroller (MCU) that fronts the PSE hardware on switches using
+ Realtek (RTL8238B, RTL8239, RTL8239C) or Broadcom (BCM59111, BCM59121)
+ PSE chips. The MCU exposes a small message-based protocol over either
+ I2C/SMBus or UART; the actual PSE silicon is not accessed directly. The
+ Realtek and Broadcom variants share this device tree contract but use
+ different protocol opcodes, selected by the compatible.
+
+ The compatible identifies the PSE-MCU protocol dialect, not a specific
+ part. The device here is the MCU: it presents a stable message protocol
+ documented by Realtek, with the PSE silicon behind it - Broadcom on
+ older boards, Realtek on newer - detected at runtime and not described
+ here. The MCU's own silicon is general-purpose and varies across
+ boards, so the 'realtek' vendor prefix names the protocol front-end
+ (following the google,cros-ec pattern); the '-rtk'/'-brcm' suffix
+ selects the Realtek or Broadcom dialect.
+
+ A single compatible per dialect covers both the I2C/SMBus and UART
+ attachments: the wire protocol is identical across them and the
+ transport is already expressed by the node's parent bus, so it is not
+ encoded in the compatible. Transport-specific properties differ
+ accordingly - the I2C attachment carries 'reg' (and, for Realtek,
+ 'realtek,i2c-protocol'), while the UART attachment carries the serial
+ peripheral properties such as 'current-speed'.
+
+properties:
+ compatible:
+ enum:
+ - realtek,pse-mcu-rtk
+ - realtek,pse-mcu-brcm
+
+ reg:
+ maxItems: 1
+
+ power-supply:
+ description: Regulator supplying the PoE power rail.
+
+ enable-gpios:
+ maxItems: 1
+
+ realtek,i2c-protocol:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ i2c, smbus ]
+ description: |
+ Wire framing the MCU firmware expects on the I2C bus. "smbus" means
+ reads carry a leading command byte (0x00) and a repeated start; "i2c"
+ means bare 12-byte writes and reads with no command prefix. Only
+ applies to the Realtek I2C attachment.
+
+required:
+ - compatible
+
+allOf:
+ - $ref: pse-controller.yaml#
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+ # The I2C attachment (identified by 'reg') cannot carry serial bus props.
+ - if:
+ required: [reg]
+ then:
+ properties:
+ current-speed: false
+ max-speed: false
+ # 'realtek,i2c-protocol' is meaningful only for the Realtek I2C attachment;
+ # the Broadcom variant and any UART attachment must not carry it.
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: realtek,pse-mcu-rtk
+ required: [reg]
+ then:
+ required:
+ - realtek,i2c-protocol
+ else:
+ properties:
+ "realtek,i2c-protocol": false
+
+unevaluatedProperties: false
+
+examples:
+ # Realtek PSE chip, I2C attachment (SMBus framing).
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-pse@20 {
+ compatible = "realtek,pse-mcu-rtk";
+ reg = <0x20>;
+ realtek,i2c-protocol = "smbus";
+
+ pse-pis {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pse-pi@0 {
+ reg = <0>;
+ #pse-cells = <0>;
+ };
+ };
+ };
+ };
+
+ # Broadcom PSE chip, I2C attachment.
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-pse@20 {
+ compatible = "realtek,pse-mcu-brcm";
+ reg = <0x20>;
+
+ pse-pis {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pse-pi@0 {
+ reg = <0>;
+ #pse-cells = <0>;
+ };
+ };
+ };
+ };
+
+ # Realtek PSE chip, UART attachment.
+ - |
+ serial {
+ ethernet-pse {
+ compatible = "realtek,pse-mcu-rtk";
+ current-speed = <115200>;
+
+ pse-pis {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pse-pi@0 {
+ reg = <0>;
+ #pse-cells = <0>;
+ };
+ };
+ };
+ };
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox