* Re: [PATCH net-next v11 00/14] netkit: Support for io_uring zero-copy and AF_XDP
From: Daniel Borkmann @ 2026-04-07 9:50 UTC (permalink / raw)
To: netdev
Cc: bpf, kuba, davem, razor, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260402231031.447597-1-daniel@iogearbox.net>
Hi Jakub,
On 4/3/26 1:10 AM, Daniel Borkmann wrote:
> Containers use virtual netdevs to route traffic from a physical netdev
> in the host namespace. They do not have access to the physical netdev
> in the host and thus can't use memory providers or AF_XDP that require
> reconfiguring/restarting queues in the physical netdev.
>
> This patchset adds the concept of queue leasing to virtual netdevs that
> allow containers to use memory providers and AF_XDP at native speed.
> Leased queues are bound to a real queue in a physical netdev and act
> as a proxy.
>
> Memory providers and AF_XDP operations take an ifindex and queue id,
> so containers would pass in an ifindex for a virtual netdev and a queue
> id of a leased queue, which then gets proxied to the underlying real
> queue.
>
> We have implemented support for this concept in netkit and tested the
> latter against Nvidia ConnectX-6 (mlx5) as well as Broadcom BCM957504
> (bnxt_en) 100G NICs. For more details see the individual patches.
>
> v10->v11:
> - Fix missing mp_ops->uninstall upon unlease path (Gemini)
> - Fix dma device retrieval on tx queue when rx queue is leased (Gemini)
> - Rework ethtool channel checks to check rx/tx individually (Gemini)
> - The remainder of the Gemini findings were non-issues
> - Add more extensive net selftests around queue leasing corner cases
> - Rebase and retested everything with mlx5 + bnxt_en
I've look into the latest v11 findings from Gemini in the meantime, and
thought I'd share an update/comments related to them:
https://sashiko.dev/#/patchset/20260402231031.447597-1-daniel%40iogearbox.net
From all the claims related to the series, the one in the netkit device dump
looks reasonable to improve, iow, to not dump IFLA_NETKIT_SCRUB if in single
mode since we also reject the presence of the attribute during device creation,
change would look like:
- if (nla_put_u32(skb, IFLA_NETKIT_SCRUB, nk->scrub))
- return -EMSGSIZE;
+ if (nk->pair != NETKIT_DEVICE_SINGLE &&
+ nla_put_u32(skb, IFLA_NETKIT_SCRUB, nk->scrub))
+ return -EMSGSIZE;
Anyway, wrt the individual patch comments from Gemini:
Patch 2:
- The capable(CAP_NET_ADMIN) is intentional
Patch 6:
- Solved in your patch which is a good thing to do
https://patchwork.kernel.org/project/netdevbpf/patch/20260404001938.2425670-1-kuba@kernel.org/
-> Iiuc, its unreachable today due to other guards, but an explicit check
would definitely cement that
- The second double free or use-after-free on unregistered devices claim is
not true, there is an inconsistency in the io_uring vs devmem wrt clearing
mp_ops to NULL but the code handles both cases correctly
Patch 7:
- Independent of the series; oob queue index in io_uring/zcrx claims that
there is no bounds-check against real_num_rx_queues before being passed
to netdev_queue_get_dma_dev and from there into ndo_queue_get_dma_dev
callback
-> mlx5e_queue_get_dma_dev as the only implementation does bounds check
internally, it might make sense to have a guard in the core code if
more drivers implement the ndo_queue_get_dma_dev
- Order-dependent DMA dev validation in netdev_nl_get_dma_dev claim cannot
override memory provider state, mixed cases get rejected
Patch 9:
- Intentional, netkit proxies all xsk operations to the phys device
Patch 10:
- Above diff to not dump IFLA_NETKIT_SCRUB makes sense to me
- The changelink operations claim further below is intentional and for now
rejected with -EOPNOTSUPP given nothing new can be configured here
Patch 11:
- netkit notifier takes care of this and is part of this series
Some cases in patch 6 and 7 that don't require a specific driver are worth additional
tracking in the netkit leasing selftests to asset behavior though. Happy to fold that
+ the IFLA_NETKIT_SCRUB diff above into a v12 or as a follow-up, let me know.
Thanks a lot,
Daniel
^ permalink raw reply
* Re: [PATCH v10 net-next 3/6] devlink: Implement devlink param multi attribute nested data values
From: Paolo Abeni @ 2026-04-07 9:58 UTC (permalink / raw)
To: Ratheesh Kannoth, netdev, linux-kernel, linux-rdma
Cc: sgoutham, andrew+netdev, davem, edumazet, kuba, donald.hunter,
horms, jiri, chuck.lever, matttbe, cjubran, saeedm, leon, tariqt,
mbloch, dtatulea
In-Reply-To: <20260403025533.6250-4-rkannoth@marvell.com>
On 4/3/26 4:55 AM, Ratheesh Kannoth wrote:
> From: Saeed Mahameed <saeedm@nvidia.com>
>
> Devlink param value attribute is not defined since devlink is handling
> the value validating and parsing internally, this allows us to implement
> multi attribute values without breaking any policies.
>
> Devlink param multi-attribute values are considered to be dynamically
> sized arrays of u64 values, by introducing a new devlink param type
> DEVLINK_PARAM_TYPE_U64_ARRAY, driver and user space can set a variable
> count of u32 values into the DEVLINK_ATTR_PARAM_VALUE_DATA attribute.
>
> Implement get/set parsing and add to the internal value structure passed
> to drivers.
>
> This is useful for devices that need to configure a list of values for
> a specific configuration.
>
> example:
> $ devlink dev param show pci/... name multi-value-param
> name multi-value-param type driver-specific
> values:
> cmode permanent value: 0,1,2,3,4,5,6,7
>
> $ devlink dev param set pci/... name multi-value-param \
> value 4,5,6,7,0,1,2,3 cmode permanent
>
> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
> ---
> Documentation/netlink/specs/devlink.yaml | 4 ++
> include/net/devlink.h | 8 +++
> include/uapi/linux/devlink.h | 1 +
> net/devlink/netlink_gen.c | 2 +
> net/devlink/param.c | 91 +++++++++++++++++++-----
> 5 files changed, 89 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml
> index b495d56b9137..b619de4fe08a 100644
> --- a/Documentation/netlink/specs/devlink.yaml
> +++ b/Documentation/netlink/specs/devlink.yaml
> @@ -226,6 +226,10 @@ definitions:
> value: 10
> -
> name: binary
> + -
> + name: u64-array
> + value: 129
> +
> -
> name: rate-tc-index-max
> type: const
> diff --git a/include/net/devlink.h b/include/net/devlink.h
> index 3038af6ec017..3a355fea8189 100644
> --- a/include/net/devlink.h
> +++ b/include/net/devlink.h
> @@ -432,6 +432,13 @@ enum devlink_param_type {
> DEVLINK_PARAM_TYPE_U64 = DEVLINK_VAR_ATTR_TYPE_U64,
> DEVLINK_PARAM_TYPE_STRING = DEVLINK_VAR_ATTR_TYPE_STRING,
> DEVLINK_PARAM_TYPE_BOOL = DEVLINK_VAR_ATTR_TYPE_FLAG,
> + DEVLINK_PARAM_TYPE_U64_ARRAY = DEVLINK_VAR_ATTR_TYPE_U64_ARRAY,
> +};
> +
> +#define __DEVLINK_PARAM_MAX_ARRAY_SIZE 32
> +struct devlink_param_u64_array {
> + u64 size;
> + u64 val[__DEVLINK_PARAM_MAX_ARRAY_SIZE];
> };
>
> union devlink_param_value {
> @@ -441,6 +448,7 @@ union devlink_param_value {
> u64 vu64;
> char vstr[__DEVLINK_PARAM_MAX_STRING_VALUE];
> bool vbool;
> + struct devlink_param_u64_array u64arr;
Sashiko as a couple of relevant remarks here, specifically:
---
Does this increase the size of union devlink_param_value from 32 bytes
to over 264 bytes?
Looking at existing functions like devlink_nl_param_value_fill_one() and
devlink_nl_param_value_put(), they take multiple copies of this union by
value. Passing two of these unions by value consumes over 528 bytes of
stack space, and combined in a call chain this pushes nearly 800 bytes
of arguments onto the stack.
Could this create a risk of hitting CONFIG_FRAME_WARN limits deep in
driver notification contexts? Should the signatures of the internal
functions and exported APIs be updated to pass the unions by pointer
instead?
---
> };
>
> struct devlink_param_gset_ctx {
> diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
> index 7de2d8cc862f..5332223dd6d0 100644
> --- a/include/uapi/linux/devlink.h
> +++ b/include/uapi/linux/devlink.h
> @@ -406,6 +406,7 @@ enum devlink_var_attr_type {
> DEVLINK_VAR_ATTR_TYPE_BINARY,
> __DEVLINK_VAR_ATTR_TYPE_CUSTOM_BASE = 0x80,
> /* Any possible custom types, unrelated to NLA_* values go below */
> + DEVLINK_VAR_ATTR_TYPE_U64_ARRAY,
> };
>
> enum devlink_attr {
> diff --git a/net/devlink/netlink_gen.c b/net/devlink/netlink_gen.c
> index eb35e80e01d1..7aaf462f27ee 100644
> --- a/net/devlink/netlink_gen.c
> +++ b/net/devlink/netlink_gen.c
> @@ -37,6 +37,8 @@ devlink_attr_param_type_validate(const struct nlattr *attr,
> case DEVLINK_VAR_ATTR_TYPE_NUL_STRING:
> fallthrough;
> case DEVLINK_VAR_ATTR_TYPE_BINARY:
> + fallthrough;
> + case DEVLINK_VAR_ATTR_TYPE_U64_ARRAY:
> return 0;
> }
> NL_SET_ERR_MSG_ATTR(extack, attr, "invalid enum value");
> diff --git a/net/devlink/param.c b/net/devlink/param.c
> index cf95268da5b0..2ec85dffd8ac 100644
> --- a/net/devlink/param.c
> +++ b/net/devlink/param.c
> @@ -252,6 +252,14 @@ devlink_nl_param_value_put(struct sk_buff *msg, enum devlink_param_type type,
> return -EMSGSIZE;
> }
> break;
> + case DEVLINK_PARAM_TYPE_U64_ARRAY:
> + if (val.u64arr.size > __DEVLINK_PARAM_MAX_ARRAY_SIZE)
> + return -EMSGSIZE;
> +
> + for (int i = 0; i < val.u64arr.size; i++)
> + if (nla_put_uint(msg, nla_type, val.u64arr.val[i]))
> + return -EMSGSIZE;
> + break;
> }
> return 0;
> }
> @@ -304,56 +312,78 @@ static int devlink_nl_param_fill(struct sk_buff *msg, struct devlink *devlink,
> u32 portid, u32 seq, int flags,
> struct netlink_ext_ack *extack)
> {
> - union devlink_param_value default_value[DEVLINK_PARAM_CMODE_MAX + 1];
> - union devlink_param_value param_value[DEVLINK_PARAM_CMODE_MAX + 1];
> bool default_value_set[DEVLINK_PARAM_CMODE_MAX + 1] = {};
> bool param_value_set[DEVLINK_PARAM_CMODE_MAX + 1] = {};
> const struct devlink_param *param = param_item->param;
> - struct devlink_param_gset_ctx ctx;
> + union devlink_param_value *default_value;
> + union devlink_param_value *param_value;
> + struct devlink_param_gset_ctx *ctx;
> struct nlattr *param_values_list;
> struct nlattr *param_attr;
> void *hdr;
> int err;
> int i;
>
> + default_value = kcalloc(DEVLINK_PARAM_CMODE_MAX + 1,
> + sizeof(*default_value), GFP_KERNEL);
> + if (!default_value)
> + return -ENOMEM;
> +
> + param_value = kcalloc(DEVLINK_PARAM_CMODE_MAX + 1,
> + sizeof(*param_value), GFP_KERNEL);
> + if (!param_value) {
> + kfree(default_value);
> + return -ENOMEM;
> + }
> +
> + ctx = kmalloc_obj(*ctx);
> + if (!ctx) {
> + kfree(param_value);
> + kfree(default_value);
> + return -ENOMEM;
> + }
> +
> /* Get value from driver part to driverinit configuration mode */
> for (i = 0; i <= DEVLINK_PARAM_CMODE_MAX; i++) {
> if (!devlink_param_cmode_is_supported(param, i))
> continue;
> if (i == DEVLINK_PARAM_CMODE_DRIVERINIT) {
> - if (param_item->driverinit_value_new_valid)
> + if (param_item->driverinit_value_new_valid) {
> param_value[i] = param_item->driverinit_value_new;
> - else if (param_item->driverinit_value_valid)
> + } else if (param_item->driverinit_value_valid) {
> param_value[i] = param_item->driverinit_value;
> - else
> - return -EOPNOTSUPP;
> + } else {
> + err = -EOPNOTSUPP;
> + goto get_put_fail;
> + }
>
> if (param_item->driverinit_value_valid) {
> default_value[i] = param_item->driverinit_default;
> default_value_set[i] = true;
> }
> } else {
> - ctx.cmode = i;
> - err = devlink_param_get(devlink, param, &ctx, extack);
> + ctx->cmode = i;
> + err = devlink_param_get(devlink, param, ctx, extack);
> if (err)
> - return err;
> - param_value[i] = ctx.val;
> + goto get_put_fail;
> + param_value[i] = ctx->val;
>
> - err = devlink_param_get_default(devlink, param, &ctx,
> + err = devlink_param_get_default(devlink, param, ctx,
> extack);
> if (!err) {
> - default_value[i] = ctx.val;
> + default_value[i] = ctx->val;
> default_value_set[i] = true;
> } else if (err != -EOPNOTSUPP) {
> - return err;
> + goto get_put_fail;
> }
> }
> param_value_set[i] = true;
> }
>
> + err = -EMSGSIZE;
> hdr = genlmsg_put(msg, portid, seq, &devlink_nl_family, flags, cmd);
> if (!hdr)
> - return -EMSGSIZE;
> + goto get_put_fail;
>
> if (devlink_nl_put_handle(msg, devlink))
> goto genlmsg_cancel;
> @@ -393,6 +423,9 @@ static int devlink_nl_param_fill(struct sk_buff *msg, struct devlink *devlink,
> nla_nest_end(msg, param_values_list);
> nla_nest_end(msg, param_attr);
> genlmsg_end(msg, hdr);
> + kfree(default_value);
> + kfree(param_value);
> + kfree(ctx);
> return 0;
>
> values_list_nest_cancel:
> @@ -401,7 +434,11 @@ static int devlink_nl_param_fill(struct sk_buff *msg, struct devlink *devlink,
> nla_nest_cancel(msg, param_attr);
> genlmsg_cancel:
> genlmsg_cancel(msg, hdr);
> - return -EMSGSIZE;
> +get_put_fail:
> + kfree(default_value);
> + kfree(param_value);
> + kfree(ctx);
> + return err;
> }
>
> static void devlink_param_notify(struct devlink *devlink,
> @@ -507,7 +544,7 @@ devlink_param_value_get_from_info(const struct devlink_param *param,
> union devlink_param_value *value)
> {
> struct nlattr *param_data;
> - int len;
> + int len, cnt, rem;
>
> param_data = info->attrs[DEVLINK_ATTR_PARAM_VALUE_DATA];
>
> @@ -547,6 +584,26 @@ devlink_param_value_get_from_info(const struct devlink_param *param,
> return -EINVAL;
> value->vbool = nla_get_flag(param_data);
> break;
> +
> + case DEVLINK_PARAM_TYPE_U64_ARRAY:
> + cnt = 0;
> + nla_for_each_attr_type(param_data,
> + DEVLINK_ATTR_PARAM_VALUE_DATA,
> + genlmsg_data(info->genlhdr),
> + genlmsg_len(info->genlhdr), rem) {
> + if (cnt >= __DEVLINK_PARAM_MAX_ARRAY_SIZE)
> + return -EMSGSIZE;
> +
> + if ((nla_len(param_data) != sizeof(u64)) &&
> + (nla_len(param_data) != sizeof(u32)))
> + return -EINVAL;
> +
> + value->u64arr.val[cnt] = (u64)nla_get_uint(param_data);
> + cnt++;
> + }
> +
> + value->u64arr.size = cnt;
> + break;
Sashiko says:
---
Does this make it impossible to set an empty array to clear a
multi-value parameter?
If userspace provides 0 elements, param_data will be NULL. Earlier in
devlink_param_value_get_from_info(), there is a check:
param_data = info->attrs[DEVLINK_ATTR_PARAM_VALUE_DATA];
if (param->type != DEVLINK_PARAM_TYPE_BOOL && !param_data)
return -EINVAL;
If the parameter is a U64_ARRAY and no data is provided, this check will
immediately return -EINVAL.
The kernel can successfully emit an empty array on a GET request if the
size is 0. Should the SET path similarly support receiving 0 elements to
allow userspace to clear a multi-value parameter?
---
There are several others NIC-specific remarks, which IMHO are mostly
pre-existing issues, but please have a look:
https://sashiko.dev/#/patchset/20260403025533.6250-1-rkannoth%40marvell.com
/P
^ permalink raw reply
* Re: [PATCH net-next v8] selftests: net: add tests for PPP
From: Paolo Abeni @ 2026-04-07 10:08 UTC (permalink / raw)
To: Qingfang Deng, linux-ppp, Shuah Khan, David S. Miller,
Eric Dumazet, Jakub Kicinski, Simon Horman,
Sebastian Andrzej Siewior, Felix Maurer, Petr Machata,
linux-kernel, linux-kselftest, netdev
Cc: Paul Mackerras, Dianne Skoll, Jaco Kroon, James Carlson,
Andrew Lunn
In-Reply-To: <20260403034908.30017-1-qingfang.deng@linux.dev>
On 4/3/26 5:48 AM, Qingfang Deng wrote:
> diff --git a/tools/testing/selftests/net/ppp/pppoe.sh b/tools/testing/selftests/net/ppp/pppoe.sh
> new file mode 100755
> index 000000000000..f67b51df7490
> --- /dev/null
> +++ b/tools/testing/selftests/net/ppp/pppoe.sh
> @@ -0,0 +1,65 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +
> +source ppp_common.sh
> +
> +VETH_SERVER="veth-server"
> +VETH_CLIENT="veth-client"
> +PPPOE_LOG=$(mktemp /tmp/pppoe.XXXXXX)
> +
> +# shellcheck disable=SC2329
> +cleanup() {
> + cleanup_all_ns
> + [ -n "$SOCAT_PID" ] && kill_process "$SOCAT_PID"
> + rm -f "$PPPOE_LOG"
> +}
> +
> +trap cleanup EXIT
> +
> +require_command pppoe-server
> +ppp_common_init
> +modprobe -q pppoe
> +
> +# Try to locate pppoe.so plugin
> +PPPOE_PLUGIN=$(find /usr/{lib,lib64,lib32}/pppd/ -name pppoe.so -type f -print -quit)
Minor nit: here stderr could be redirected to /dev/null, since the
command will likely emit at least an error message on most systems.
Could be a follow-up or added if/when you will expand the self-tests.
/P
^ permalink raw reply
* Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG
From: Eric Dumazet @ 2026-04-07 10:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, Paolo Abeni, Simon Horman, Kuniyuki Iwashima,
Andrew Lunn, netdev, eric.dumazet
In-Reply-To: <20260406180254.5221a267@kernel.org>
On Mon, Apr 6, 2026 at 6:02 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 3 Apr 2026 02:24:43 +0000 Eric Dumazet wrote:
> > ipvlan and macvlan use queues to process broadcast or multicast packets
> > from a work queue.
> >
> > Under attack these queues can drop packets.
> >
> > Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
> >
> > Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.
>
> What distinction are you trying to communicate by using BROADCAST
> vs MULTICAST? Funny naming of the functions aside I believe that
> in both cases we're basically dealing with multicast traffic.
> Reading the code it seems like macvlan has some optimization where
> it delivers the frame inline if the multicast group is not very
> popular. And if it is popular it schedules a work (and calls that
> broadcast). ipvlan doesn't have the inline filter and calls the
> deliver via work multicast.
>
> tl;dr I think the drivers do the same thing just call their functions
> broadcast vs multicast. Having two drop reasons here is actively
> misleading?
My intent was to differentiate ipvlan and macvlan reasons, some
deployments use both.
I can rename the reasons if you think this is better.
IPVLAN_MULTICAST_BACKLOG
MACVLAN_BROADCAST_BACKLOG
^ permalink raw reply
* Re: [PATCH net-next v8] selftests: net: add tests for PPP
From: patchwork-bot+netdevbpf @ 2026-04-07 10:20 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, shuah, davem, edumazet, kuba, pabeni, horms, bigeasy,
fmaurer, petrm, linux-kernel, linux-kselftest, netdev, paulus,
dianne, jaco, carlsonj, andrew
In-Reply-To: <20260403034908.30017-1-qingfang.deng@linux.dev>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 3 Apr 2026 11:48:47 +0800 you wrote:
> Add ping and iperf3 tests for ppp_async.c and pppoe.c.
>
> Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
> ---
> v8:
> - locate pppoe.so and pass it to pppoe-server
> - start socat as a syslog listener and dump the log messages if the test fails
> https://lore.kernel.org/netdev/20260330035604.133073-1-dqfext@gmail.com/
>
> [...]
Here is the summary with links:
- [net-next,v8] selftests: net: add tests for PPP
https://git.kernel.org/netdev/net-next/c/dfecb0c5af3b
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-next v2] selftests: forwarding: lib: rewrite processing of command line arguments
From: Ioana Ciornei @ 2026-04-07 10:20 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-kernel, petrm, willemb,
linux-kselftest, Shuah Khan, Hangbin Liu
The piece of code which processes the command line arguments and
populates NETIFS based on them is really unobvious. Rewrite it so that
the intention is clear and the code is easy to follow.
Suggested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v2:
- added back 'count=0'
tools/testing/selftests/net/forwarding/lib.sh | 21 ++++++++++---------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index d8cc4c64148d..d2bdbff68075 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -467,17 +467,18 @@ if [ "${DRIVER_TEST_CONFORMANT}" = "yes" ]; then
TARGETS[$remote_netif]="$REMOTE_TYPE:$REMOTE_ARGS"
else
count=0
+ # Prime NETIFS from the command line, but retain if none given.
+ if [[ $# -gt 0 ]]; then
+ unset NETIFS
+ declare -A NETIFS
- while [[ $# -gt 0 ]]; do
- if [[ "$count" -eq "0" ]]; then
- unset NETIFS
- declare -A NETIFS
- fi
- count=$((count + 1))
- NETIFS[p$count]="$1"
- TARGETS[$1]="local:"
- shift
- done
+ while [[ $# -gt 0 ]]; do
+ count=$((count + 1))
+ NETIFS[p$count]="$1"
+ TARGETS[$1]="local:"
+ shift
+ done
+ fi
fi
##############################################################################
--
2.25.1
^ permalink raw reply related
* [PATCH net] net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo
From: Kai Zen @ 2026-04-07 10:21 UTC (permalink / raw)
To: netdev
Cc: edwin.peer, Eric Dumazet, davem, kuba, pabeni, horms, stable,
security
rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack
without initialisation:
struct ifla_vf_broadcast vf_broadcast;
The struct contains a single fixed 32-byte field:
/* include/uapi/linux/if_link.h */
struct ifla_vf_broadcast {
__u8 broadcast[32];
};
The function then copies dev->broadcast into it using dev->addr_len
as the length:
memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
On Ethernet devices (the overwhelming majority of SR-IOV NICs)
dev->addr_len is 6, so only the first 6 bytes of broadcast[] are
written. The remaining 26 bytes retain whatever was previously on
the kernel stack. The full struct is then handed to userspace via:
nla_put(skb, IFLA_VF_BROADCAST,
sizeof(vf_broadcast), &vf_broadcast)
leaking up to 26 bytes of uninitialised kernel stack per VF per
RTM_GETLINK request, repeatable.
The other vf_* structs in the same function are explicitly zeroed
for exactly this reason - see the memset() calls for ivi,
vf_vlan_info, node_guid and port_guid a few lines above.
vf_broadcast was simply missed when it was added.
The pattern used elsewhere in this file for the regular IFLA_BROADCAST
attribute also avoids the issue by sending only dev->addr_len bytes
rather than a fixed-size struct, but for IFLA_VF_BROADCAST the wire
format is the fixed 32-byte struct, so the right fix is to zero the
struct before the partial memcpy.
Reachability and impact
-----------------------
The leak is reachable by any unprivileged local process. AF_NETLINK
with NETLINK_ROUTE requires no capabilities. The only environmental
requirement is that the host has at least one SR-IOV-capable
interface present (a parent device with VFs), which is the common
case for cloud, datacenter and HPC hosts.
Trigger: send RTM_GETLINK with an IFLA_EXT_MASK attribute whose
value has the RTEXT_FILTER_VF bit set. The kernel will then walk
each VF and emit IFLA_VFINFO_LIST, including IFLA_VF_BROADCAST,
which carries the 26 bytes of uninitialised stack per VF.
Stack residue at this call site can include return addresses
(useful as a KASLR / function-pointer disclosure primitive) and
transient sensitive data left over by whatever ran on the same
kernel stack just prior. KASAN with stack instrumentation, or
KMSAN, will flag the nla_put() when reproduced.
Reproducer (unprivileged):
import socket, struct
IFLA_EXT_MASK = 29
RTEXT_FILTER_VF = 1
s = socket.socket(socket.AF_NETLINK, socket.SOCK_RAW,
socket.NETLINK_ROUTE)
s.bind((0, 0))
hdr = struct.pack('=IHHII', 0, 18, 0x301, 0, 0)
ifi = struct.pack('=BxHiII', 0, 0, 0, 0, 0)
attr = (struct.pack('=HH', 8, IFLA_EXT_MASK) +
struct.pack('=I', RTEXT_FILTER_VF))
msg = hdr + ifi + attr
msg = struct.pack('=I', len(msg)) + msg[4:]
s.send(msg)
data = s.recv(65536)
# Parse IFLA_VF_BROADCAST from the response. Bytes 7..32 of the
# broadcast[] field are uninitialised kernel stack on Ethernet.
Fix
---
Zero the on-stack struct before the partial memcpy, matching the
existing pattern used for the other vf_* structs in the same
function.
Reported-by: Kai Aizen <kai.aizen.dev@gmail.com>
Signed-off-by: Kai Aizen <kai.aizen.dev@gmail.com>
---
Note for reviewers: this is v1. I have not yet identified the
exact introducing commit for the Fixes: tag and would appreciate
a pointer, or I will resend as v2 once I have run git blame on a
local checkout. The bug is present at least as far back as the
introduction of struct ifla_vf_broadcast in net-next.
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1572,6 +1572,7 @@ static noinline_for_stack int
rtnl_fill_vfinfo(struct sk_buff *skb,
port_guid.vf = ivi.vf;
memcpy(vf_mac.mac, ivi.mac, sizeof(ivi.mac));
+ memset(&vf_broadcast, 0, sizeof(vf_broadcast));
memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
vf_vlan.vlan = ivi.vlan;
vf_vlan.qos = ivi.qos;
--
2.43.0
^ permalink raw reply
* Re: [PATCH net] net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo
From: Eric Dumazet @ 2026-04-07 10:26 UTC (permalink / raw)
To: Kai Zen; +Cc: netdev, edwin.peer, davem, kuba, pabeni, horms, stable, security
In-Reply-To: <CALynFi7k1Z7Vgr4p2=KH2-uWVntBRE5R+8uP=cds9_ihGqzOdQ@mail.gmail.com>
On Tue, Apr 7, 2026 at 3:22 AM Kai Zen <kai.aizen.dev@gmail.com> wrote:
>
> rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack
> without initialisation:
>
> struct ifla_vf_broadcast vf_broadcast;
>
> The struct contains a single fixed 32-byte field:
>
> /* include/uapi/linux/if_link.h */
> struct ifla_vf_broadcast {
> __u8 broadcast[32];
> };
>
> The function then copies dev->broadcast into it using dev->addr_len
> as the length:
>
> memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
>
> On Ethernet devices (the overwhelming majority of SR-IOV NICs)
> dev->addr_len is 6, so only the first 6 bytes of broadcast[] are
> written. The remaining 26 bytes retain whatever was previously on
> the kernel stack. The full struct is then handed to userspace via:
>
> nla_put(skb, IFLA_VF_BROADCAST,
> sizeof(vf_broadcast), &vf_broadcast)
>
> leaking up to 26 bytes of uninitialised kernel stack per VF per
> RTM_GETLINK request, repeatable.
>
> The other vf_* structs in the same function are explicitly zeroed
> for exactly this reason - see the memset() calls for ivi,
> vf_vlan_info, node_guid and port_guid a few lines above.
> vf_broadcast was simply missed when it was added.
>
> The pattern used elsewhere in this file for the regular IFLA_BROADCAST
> attribute also avoids the issue by sending only dev->addr_len bytes
> rather than a fixed-size struct, but for IFLA_VF_BROADCAST the wire
> format is the fixed 32-byte struct, so the right fix is to zero the
> struct before the partial memcpy.
>
> Reachability and impact
> -----------------------
>
> The leak is reachable by any unprivileged local process. AF_NETLINK
> with NETLINK_ROUTE requires no capabilities. The only environmental
> requirement is that the host has at least one SR-IOV-capable
> interface present (a parent device with VFs), which is the common
> case for cloud, datacenter and HPC hosts.
>
> Trigger: send RTM_GETLINK with an IFLA_EXT_MASK attribute whose
> value has the RTEXT_FILTER_VF bit set. The kernel will then walk
> each VF and emit IFLA_VFINFO_LIST, including IFLA_VF_BROADCAST,
> which carries the 26 bytes of uninitialised stack per VF.
>
> Stack residue at this call site can include return addresses
> (useful as a KASLR / function-pointer disclosure primitive) and
> transient sensitive data left over by whatever ran on the same
> kernel stack just prior. KASAN with stack instrumentation, or
> KMSAN, will flag the nla_put() when reproduced.
>
> Reproducer (unprivileged):
>
> import socket, struct
> IFLA_EXT_MASK = 29
> RTEXT_FILTER_VF = 1
> s = socket.socket(socket.AF_NETLINK, socket.SOCK_RAW,
> socket.NETLINK_ROUTE)
> s.bind((0, 0))
> hdr = struct.pack('=IHHII', 0, 18, 0x301, 0, 0)
> ifi = struct.pack('=BxHiII', 0, 0, 0, 0, 0)
> attr = (struct.pack('=HH', 8, IFLA_EXT_MASK) +
> struct.pack('=I', RTEXT_FILTER_VF))
> msg = hdr + ifi + attr
> msg = struct.pack('=I', len(msg)) + msg[4:]
> s.send(msg)
> data = s.recv(65536)
> # Parse IFLA_VF_BROADCAST from the response. Bytes 7..32 of the
> # broadcast[] field are uninitialised kernel stack on Ethernet.
>
> Fix
> ---
>
> Zero the on-stack struct before the partial memcpy, matching the
> existing pattern used for the other vf_* structs in the same
> function.
>
> Reported-by: Kai Aizen <kai.aizen.dev@gmail.com>
> Signed-off-by: Kai Aizen <kai.aizen.dev@gmail.com>
> ---
>
> Note for reviewers: this is v1. I have not yet identified the
> exact introducing commit for the Fixes: tag and would appreciate
> a pointer, or I will resend as v2 once I have run git blame on a
> local checkout. The bug is present at least as far back as the
> introduction of struct ifla_vf_broadcast in net-next.
Fixes: 75345f888f70 ("ipoib: show VF broadcast address")
>
> net/core/rtnetlink.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1572,6 +1572,7 @@ static noinline_for_stack int
> rtnl_fill_vfinfo(struct sk_buff *skb,
> port_guid.vf = ivi.vf;
>
> memcpy(vf_mac.mac, ivi.mac, sizeof(ivi.mac));
> + memset(&vf_broadcast, 0, sizeof(vf_broadcast));
> memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
> vf_vlan.vlan = ivi.vlan;
> vf_vlan.qos = ivi.qos;
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH net] ipv6: add READ_ONCE() annotations to fib6_metrics reader paths
From: Paolo Abeni @ 2026-04-07 10:27 UTC (permalink / raw)
To: Hangbin Liu, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Simon Horman
Cc: David Ahern, netdev, linux-kernel, Jiayuan Chen
In-Reply-To: <20260403-fib6_metric_read_once-v1-1-45de44912b24@gmail.com>
On 4/3/26 6:16 AM, Hangbin Liu wrote:
> diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
> index 9f8b6814a96a..2dfb04fab5da 100644
> --- a/include/net/ip6_fib.h
> +++ b/include/net/ip6_fib.h
> @@ -594,7 +594,9 @@ void fib6_update_sernum_stub(struct net *net, struct fib6_info *f6i);
> void fib6_metric_set(struct fib6_info *f6i, int metric, u32 val);
> static inline bool fib6_metric_locked(struct fib6_info *f6i, int metric)
> {
> - return !!(f6i->fib6_metrics->metrics[RTAX_LOCK - 1] & (1 << metric));
> + struct dst_metrics *m = READ_ONCE(f6i->fib6_metrics);
> +
> + return !!(m->metrics[RTAX_LOCK - 1] & (1 << metric));
Sashiko notes that here you may want to add an additional READ_ONCE() on
m->metrics[RTAX_LOCK - 1], which in turn looks like more a
follow-up/separate change than a change specific to this patch
> }
> void fib6_info_hw_flags_set(struct net *net, struct fib6_info *f6i,
> bool offload, bool trap, bool offload_failed);
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index dd26657b6a4a..3c96580c2a03 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -1144,9 +1144,11 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt,
> iter->fib6_flags &= ~RTF_PREFIX_RT;
> }
>
> - if (rt->fib6_pmtu)
> + u32 pmtu = READ_ONCE(rt->fib6_pmtu);
Here the READ_ONCE() on rt->metrics is still missing.
> @@ -1635,11 +1635,12 @@ __rt6_find_exception_rcu(struct rt6_exception_bucket **bucket,
> static unsigned int fib6_mtu(const struct fib6_result *res)
> {
> const struct fib6_nh *nh = res->nh;
> + struct dst_metrics *m;
> unsigned int mtu;
>
> - if (res->f6i->fib6_pmtu) {
> - mtu = res->f6i->fib6_pmtu;
> - } else {
> + m = READ_ONCE(res->f6i->fib6_metrics);
> + mtu = READ_ONCE(m->metrics[RTAX_MTU - 1]);
After this patch there will be a single usage of the `fib6_pmtu` macro.
I think it would be better to entirely drop it and replace with an helper:
static inline unsigned int fib6_mtu(const struct fib6_info *f6i)
{
const struct dst_metrics *m = READ_ONCE(f6i->fib6_metrics);
return READ_ONCE(m->metrics[RTAX_MTU - 1]);
}
/P
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: milos: Add IPA node
From: Konrad Dybcio @ 2026-04-07 10:30 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-5-01e9e4e03d3e@fairphone.com>
On 4/3/26 6:43 PM, Luca Weiss wrote:
> Add the description of the IPA block in the Milos SoC.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
> + iommus = <&apps_smmu 0x4a0 0x0>,
> + <&apps_smmu 0x4a2 0x0>;
P.S.
I don't know what's the scope of upstream IPA today, but it seems like
there's two additional SIDs: 0x4a1 attached to an "ipa_smmu_wlan"
subnode and another one (0x4a4) called ipa_smmu_11ad, perhaps for
some tighter integration with ath1xk_ahb?
But again, I don't know much.
Konrad
^ permalink raw reply
* Re: [PATCH net v2] ipvs: fix MTU check for GSO packets in tunnel mode
From: kernel test robot @ 2026-04-07 10:38 UTC (permalink / raw)
To: Yingnan Zhang, horms, ja
Cc: llvm, oe-kbuild-all, pablo, fw, phil, davem, edumazet, kuba,
pabeni, netdev, lvs-devel, netfilter-devel, coreteam,
linux-kernel, Yingnan Zhang
In-Reply-To: <tencent_CA2C1C219C99D315086BE55E8654AF7E6009@qq.com>
Hi Yingnan,
kernel test robot noticed the following build errors:
[auto build test ERROR on net/main]
url: https://github.com/intel-lab-lkp/linux/commits/Yingnan-Zhang/ipvs-fix-MTU-check-for-GSO-packets-in-tunnel-mode/20260407-141549
base: net/main
patch link: https://lore.kernel.org/r/tencent_CA2C1C219C99D315086BE55E8654AF7E6009%40qq.com
patch subject: [PATCH net v2] ipvs: fix MTU check for GSO packets in tunnel mode
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260407/202604071825.Sh4Y1fMi-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260407/202604071825.Sh4Y1fMi-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604071825.Sh4Y1fMi-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
>> net/netfilter/ipvs/ip_vs_xmit.c:115:2: warning: non-void function does not return a value in all control paths [-Wreturn-type]
115 | } else if (skb->len > mtu &&
| ^
>> net/netfilter/ipvs/ip_vs_xmit.c:115:4: error: expected identifier or '('
115 | } else if (skb->len > mtu &&
| ^
net/netfilter/ipvs/ip_vs_xmit.c:119:2: error: expected identifier or '('
119 | return false;
| ^
>> net/netfilter/ipvs/ip_vs_xmit.c:120:1: error: extraneous closing brace ('}')
120 | }
| ^
1 warning and 3 errors generated.
vim +115 net/netfilter/ipvs/ip_vs_xmit.c
104
105 static inline bool
106 __mtu_check_toobig_v6(const struct sk_buff *skb, u32 mtu)
107 {
108 if (IP6CB(skb)->frag_max_size) {
109 /* frag_max_size tell us that, this packet have been
110 * defragmented by netfilter IPv6 conntrack module.
111 */
112 if (IP6CB(skb)->frag_max_size > mtu)
113 return true; /* largest fragment violate MTU */
114 }
> 115 } else if (skb->len > mtu &&
116 !(skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu))) {
117 return true; /* Packet size violate MTU size */
118 }
119 return false;
> 120 }
121
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net] net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo
From: Greg KH @ 2026-04-07 10:42 UTC (permalink / raw)
To: Kai Zen
Cc: netdev, edwin.peer, Eric Dumazet, davem, kuba, pabeni, horms,
stable, security
In-Reply-To: <CALynFi7k1Z7Vgr4p2=KH2-uWVntBRE5R+8uP=cds9_ihGqzOdQ@mail.gmail.com>
On Tue, Apr 07, 2026 at 01:21:57PM +0300, Kai Zen wrote:
> rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack
> without initialisation:
>
> struct ifla_vf_broadcast vf_broadcast;
>
> The struct contains a single fixed 32-byte field:
>
> /* include/uapi/linux/if_link.h */
> struct ifla_vf_broadcast {
> __u8 broadcast[32];
> };
>
> The function then copies dev->broadcast into it using dev->addr_len
> as the length:
>
> memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
>
> On Ethernet devices (the overwhelming majority of SR-IOV NICs)
> dev->addr_len is 6, so only the first 6 bytes of broadcast[] are
> written. The remaining 26 bytes retain whatever was previously on
> the kernel stack. The full struct is then handed to userspace via:
>
> nla_put(skb, IFLA_VF_BROADCAST,
> sizeof(vf_broadcast), &vf_broadcast)
>
> leaking up to 26 bytes of uninitialised kernel stack per VF per
> RTM_GETLINK request, repeatable.
>
> The other vf_* structs in the same function are explicitly zeroed
> for exactly this reason - see the memset() calls for ivi,
> vf_vlan_info, node_guid and port_guid a few lines above.
> vf_broadcast was simply missed when it was added.
>
> The pattern used elsewhere in this file for the regular IFLA_BROADCAST
> attribute also avoids the issue by sending only dev->addr_len bytes
> rather than a fixed-size struct, but for IFLA_VF_BROADCAST the wire
> format is the fixed 32-byte struct, so the right fix is to zero the
> struct before the partial memcpy.
>
> Reachability and impact
> -----------------------
>
> The leak is reachable by any unprivileged local process. AF_NETLINK
> with NETLINK_ROUTE requires no capabilities. The only environmental
> requirement is that the host has at least one SR-IOV-capable
> interface present (a parent device with VFs), which is the common
> case for cloud, datacenter and HPC hosts.
>
> Trigger: send RTM_GETLINK with an IFLA_EXT_MASK attribute whose
> value has the RTEXT_FILTER_VF bit set. The kernel will then walk
> each VF and emit IFLA_VFINFO_LIST, including IFLA_VF_BROADCAST,
> which carries the 26 bytes of uninitialised stack per VF.
>
> Stack residue at this call site can include return addresses
> (useful as a KASLR / function-pointer disclosure primitive) and
> transient sensitive data left over by whatever ran on the same
> kernel stack just prior. KASAN with stack instrumentation, or
> KMSAN, will flag the nla_put() when reproduced.
>
> Reproducer (unprivileged):
>
> import socket, struct
> IFLA_EXT_MASK = 29
> RTEXT_FILTER_VF = 1
> s = socket.socket(socket.AF_NETLINK, socket.SOCK_RAW,
> socket.NETLINK_ROUTE)
> s.bind((0, 0))
> hdr = struct.pack('=IHHII', 0, 18, 0x301, 0, 0)
> ifi = struct.pack('=BxHiII', 0, 0, 0, 0, 0)
> attr = (struct.pack('=HH', 8, IFLA_EXT_MASK) +
> struct.pack('=I', RTEXT_FILTER_VF))
> msg = hdr + ifi + attr
> msg = struct.pack('=I', len(msg)) + msg[4:]
> s.send(msg)
> data = s.recv(65536)
> # Parse IFLA_VF_BROADCAST from the response. Bytes 7..32 of the
> # broadcast[] field are uninitialised kernel stack on Ethernet.
>
> Fix
> ---
>
> Zero the on-stack struct before the partial memcpy, matching the
> existing pattern used for the other vf_* structs in the same
> function.
>
> Reported-by: Kai Aizen <kai.aizen.dev@gmail.com>
> Signed-off-by: Kai Aizen <kai.aizen.dev@gmail.com>
> ---
>
> Note for reviewers: this is v1. I have not yet identified the
> exact introducing commit for the Fixes: tag and would appreciate
> a pointer, or I will resend as v2 once I have run git blame on a
> local checkout. The bug is present at least as far back as the
> introduction of struct ifla_vf_broadcast in net-next.
>
> net/core/rtnetlink.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1572,6 +1572,7 @@ static noinline_for_stack int
> rtnl_fill_vfinfo(struct sk_buff *skb,
> port_guid.vf = ivi.vf;
>
> memcpy(vf_mac.mac, ivi.mac, sizeof(ivi.mac));
> + memset(&vf_broadcast, 0, sizeof(vf_broadcast));
> memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
> vf_vlan.vlan = ivi.vlan;
> vf_vlan.qos = ivi.qos;
Nice catch, but your patch is corrupted and can't be applied as the tabs
were converted to spaces and the commit is line-wrapped :(
With that fixed, feel free to resubmit and add:
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net v2] net: txgbe: fix RTNL assertion warning when remove module
From: Russell King (Oracle) @ 2026-04-07 10:44 UTC (permalink / raw)
To: Jiawen Wu
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Mengyuan Lou, stable
In-Reply-To: <8B47A5872884147D+20260407094041.4646-1-jiawenwu@trustnetic.com>
On Tue, Apr 07, 2026 at 05:40:41PM +0800, Jiawen Wu wrote:
> For the copper NIC with external PHY, the driver called
> phylink_connect_phy() during probe and phylink_disconnect_phy() during
> remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> upon module remove.
>
> To fix this, add rtnl_lock() and rtnl_unlock() around the
> phylink_disconnect_phy() in remove function.
>
> ------------[ cut here ]------------
> RTNL: assertion failed at drivers/net/phy/phylink.c (2351)
> WARNING: drivers/net/phy/phylink.c:2351 at
> phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464
> Modules linked in: ...
> CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+
> Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING
> PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024
> RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink]
> Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7
> 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a
> e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90
> RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000
> RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020
> RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000
> R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348
> FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0
> PKRU: 55555554
> Call Trace:
> <TASK>
> txgbe_remove_phy+0xbb/0xd0 [txgbe]
> txgbe_remove+0x4c/0xb0 [txgbe]
> pci_device_remove+0x41/0xb0
> device_remove+0x43/0x80
> device_release_driver_internal+0x206/0x270
> driver_detach+0x4a/0xa0
> bus_remove_driver+0x83/0x120
> driver_unregister+0x2f/0x60
> pci_unregister_driver+0x40/0x90
> txgbe_driver_exit+0x10/0x850 [txgbe]
> __do_sys_delete_module.isra.0+0x1c3/0x2f0
> __x64_sys_delete_module+0x12/0x20
> x64_sys_call+0x20c3/0x2390
> do_syscall_64+0x11c/0x1500
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_syscall_64+0x15a/0x1500
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_fault+0x312/0x580
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __handle_mm_fault+0x9d5/0x1040
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? count_memcg_events+0x101/0x1d0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? handle_mm_fault+0x1e8/0x2f0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_user_addr_fault+0x2f8/0x820
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? irqentry_exit+0xb2/0x600
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? exc_page_fault+0x92/0x1c0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Fixes: 02b2a6f91b90 ("net: txgbe: support copper NIC with external PHY")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Krzysztof Kozlowski @ 2026-04-07 10:46 UTC (permalink / raw)
To: Thomas Richard
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <c2026868-35ff-4b5e-a0e2-bf6b3f6b75ce@bootlin.com>
On 07/04/2026 10:34, Thomas Richard wrote:
>>
>>> + - enum:
>>> + - usb424,7500
>>> + - usb424,7505
>>
>> But you should notice that this is exactly the same as 95xx, so why it
>> cannot go there? Because of the wildcard 95xx naming? That's not a
>> reason.
>
> Yes I noticed. I did not put them in 95xx because it is not the same
> driver. Isn't that a valid reason?
Not really a valid reason. If you split driver into two, do you split
bindings? Or merge drivers? Bindings here describe the hardware, not the
driver layout.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 0/2] ptp: split non-NIC PHC drivers into the clock/timekeeping maintenance domain
From: Wen Gu @ 2026-04-07 10:48 UTC (permalink / raw)
To: tglx, richardcochran, andrew+netdev, davem, edumazet, kuba,
pabeni, linux-kernel, netdev, jstultz, anna-maria, frederic,
daniel.lezcano, sboyd, dwmw2
Cc: vladimir.oltean, wei.fang, xiaoning.wang, jonathan.lemon,
vadim.fedorenko, yangbo.lu, svens, nick.shi, ajay.kaher,
alexey.makhalov, bcm-kernel-feedback-list, linux-fpga, imx,
linux-s390, dust.li, xuanzhuo, mani, imran.shaik, taniya.das
Hi all,
This series follows the discussion in RFC [1-2] and v1 [3].
# Background
The PTP Hardware Clock (PHC) interface (/dev/ptpX and the standard PTP_*
ioctls) was originally introduced for IEEE 1588 / network oriented clock
drivers. Over time, it has also become a userspace API for many non-NIC
high-precision clock implementations (virtualization/platform/architecture
provided clocks) [4-8], and more are expected to appear [9-10].
During the review of these incoming non IEEE 1588 based PHC drivers, concerns
were raised that such "non-NIC" clocks may not be a good fit for the netdev
maintainership model [11], where PTP/PHC drivers are currently maintained.
This leaves an unclear upstream home and maintainership model for this class
of drivers.
# Proposal
This series proposes moving PHC drivers that expose a high-precision clock to
userspace via the existing PTP interface but are not tied to the traditional
NIC/IEEE 1588 packet timestamping pipeline, out of the netdev maintenance
domain and into the clock/timekeeping maintenance domain.
As discussed in [3], this series makes the separation explicit by reorganizing
the drivers/ptp/ layout into the following groups. This provides clearer
ownership and long-term maintenance boundaries:
- drivers/ptp/ : PTP core infrastructure and
network / IEEE 1588 oriented PTP drivers.
- drivers/ptp/emulated/ : emulated/virtual PTP drivers. They are typically
platform/architecture/virtualization/special
hardware provided high-precision time sources.
Patch 1 performs the refactor: move drivers and split Kconfig/Makefiles
accordingly, without intended functional changes.
Patch 2 updates MAINTAINERS to match the new layout and adds a dedicated entry
for drivers/ptp/emulated/, moving review and ownership routing for this class
of drivers away from the netdev maintainership.
No userspace ABI changes are intended; this is a refactor and maintenance
metadata update only.
# Changes since Patch v1:
- List David Woodhouse as the maintainer of emulated PTP drivers.
- Adjust the directory layout: instead of creating both ieee1588/ and
emulated/ subdirectories, keep the network-oriented drivers in the
main drivers/ptp/ directory and only split out the emulated drivers.
# Changes since RFC v2:
- Keep ptp_ocp under the IEEE1588/network-oriented PTP drivers as suggested
by Jakub.
- Following the model used by NTP related code, this series lists tip.git
(timers/core) as the integration tree for emulated PTP clocks in the
MAINTAINERS entry. Guidance from clock/timekeeping maintainers
(Thomas Gleixner, John Stultz, Anna-Maria Behnsen, Frederic Weisbecker,
Daniel Lezcano, Stephen Boyd) on whether this is the appropriate workflow
for this class of drivers would be appreciated.
- Continue listing ourselves as maintainers for now as a fallback contact
point. In the long term it would be preferable for this area to be
maintained by clock/timekeeping experts, and suggestions are welcome.
Thanks for any input.
Regards.
[1] https://lore.kernel.org/all/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
[2] https://lore.kernel.org/all/20260227081934.96865-1-guwen@linux.alibaba.com/
[3] https://lore.kernel.org/all/20260318073330.115808-1-guwen@linux.alibaba.com/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0e136d436ded817c0aade72efdefa56a00b4e5e
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d10001e20e46ad6ad95622164686bc2cbfc9802
[6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d7de7a3010d713fb89b7ba99e6fdc14475ad106
[7] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3716a49a81ba19dda7202633a68b28564ba95eb5
[8] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a17125a18f9ae1e1233a8e2d919059445b9d6fd
[9] https://lore.kernel.org/netdev/20251030121314.56729-1-guwen@linux.alibaba.com/
[10] https://lore.kernel.org/mhi/20250818-tsc_time_sync-v1-0-2747710693ba@oss.qualcomm.com/
[11] https://lore.kernel.org/netdev/20251127083610.6b66a728@kernel.org/
Wen Gu (2):
ptp: move emulated/virtual clock drivers into a dedicated subdirectory
MAINTAINERS: update PTP maintainer entries after directory split
MAINTAINERS | 21 +++++--
drivers/ptp/Kconfig | 68 ++++-----------------
drivers/ptp/Makefile | 11 ++--
drivers/ptp/emulated/Kconfig | 61 ++++++++++++++++++
drivers/ptp/emulated/Makefile | 11 ++++
drivers/ptp/{ => emulated}/ptp_kvm_arm.c | 0
drivers/ptp/{ => emulated}/ptp_kvm_common.c | 0
drivers/ptp/{ => emulated}/ptp_kvm_x86.c | 0
drivers/ptp/{ => emulated}/ptp_s390.c | 0
drivers/ptp/{ => emulated}/ptp_vmclock.c | 0
drivers/ptp/{ => emulated}/ptp_vmw.c | 0
11 files changed, 103 insertions(+), 69 deletions(-)
create mode 100644 drivers/ptp/emulated/Kconfig
create mode 100644 drivers/ptp/emulated/Makefile
rename drivers/ptp/{ => emulated}/ptp_kvm_arm.c (100%)
rename drivers/ptp/{ => emulated}/ptp_kvm_common.c (100%)
rename drivers/ptp/{ => emulated}/ptp_kvm_x86.c (100%)
rename drivers/ptp/{ => emulated}/ptp_s390.c (100%)
rename drivers/ptp/{ => emulated}/ptp_vmclock.c (100%)
rename drivers/ptp/{ => emulated}/ptp_vmw.c (100%)
--
2.43.5
^ permalink raw reply
* [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split
From: Wen Gu @ 2026-04-07 10:48 UTC (permalink / raw)
To: tglx, richardcochran, andrew+netdev, davem, edumazet, kuba,
pabeni, linux-kernel, netdev, jstultz, anna-maria, frederic,
daniel.lezcano, sboyd, dwmw2
Cc: vladimir.oltean, wei.fang, xiaoning.wang, jonathan.lemon,
vadim.fedorenko, yangbo.lu, svens, nick.shi, ajay.kaher,
alexey.makhalov, bcm-kernel-feedback-list, linux-fpga, imx,
linux-s390, dust.li, xuanzhuo, mani, imran.shaik, taniya.das
In-Reply-To: <20260407104802.34429-1-guwen@linux.alibaba.com>
Update MAINTAINERS to match the new drivers/ptp/ directory layout after
moving emulated/virtual PTP clock drivers into a new subdirectory.
Adjust file patterns and per-driver entries to point to their new
locations, and add a dedicated MAINTAINERS entry for the emulated PTP
clock drivers.
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
---
MAINTAINERS | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cb48c9ad9ddc..2b5464e38238 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18335,6 +18335,7 @@ X: Documentation/devicetree/bindings/net/can/
X: Documentation/devicetree/bindings/net/wireless/
X: drivers/net/can/
X: drivers/net/wireless/
+X: drivers/ptp/emulated/
NETWORKING DRIVERS (WIRELESS)
M: Johannes Berg <johannes@sipsolutions.net>
@@ -21243,8 +21244,18 @@ F: Documentation/driver-api/ptp.rst
F: drivers/net/phy/dp83640*
F: drivers/ptp/*
F: include/linux/ptp_cl*
+X: drivers/ptp/emulated/
K: (?:\b|_)ptp(?:\b|_)
+PTP EMULATED CLOCK SUPPORT
+M: David Woodhouse <dwmw2@infradead.org>
+M: Wen Gu <guwen@linux.alibaba.com>
+M: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
+F: drivers/ptp/emulated/
+
PTP MOCKUP CLOCK SUPPORT
M: Vladimir Oltean <vladimir.oltean@nxp.com>
L: netdev@vger.kernel.org
@@ -21261,10 +21272,10 @@ F: net/ethtool/phc_vclocks.c
PTP VMCLOCK SUPPORT
M: David Woodhouse <dwmw2@infradead.org>
-L: netdev@vger.kernel.org
+L: linux-kernel@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/ptp/amazon,vmclock.yaml
-F: drivers/ptp/ptp_vmclock.c
+F: drivers/ptp/emulated/ptp_vmclock.c
F: include/uapi/linux/vmclock-abi.h
PTRACE SUPPORT
@@ -23323,7 +23334,7 @@ S390 PTP DRIVER
M: Sven Schnelle <svens@linux.ibm.com>
L: linux-s390@vger.kernel.org
S: Supported
-F: drivers/ptp/ptp_s390.c
+F: drivers/ptp/emulated/ptp_s390.c
S390 SCM DRIVER
M: Vineeth Vijayan <vneethv@linux.ibm.com>
@@ -28219,9 +28230,9 @@ M: Nick Shi <nick.shi@broadcom.com>
R: Ajay Kaher <ajay.kaher@broadcom.com>
R: Alexey Makhalov <alexey.makhalov@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
-L: netdev@vger.kernel.org
+L: linux-kernel@vger.kernel.org
S: Supported
-F: drivers/ptp/ptp_vmw.c
+F: drivers/ptp/emulated/ptp_vmw.c
VMWARE VMCI DRIVER
M: Bryan Tan <bryan-bt.tan@broadcom.com>
--
2.43.5
^ permalink raw reply related
* [PATCH v2 1/2] ptp: move emulated/virtual clock drivers into a dedicated subdirectory
From: Wen Gu @ 2026-04-07 10:48 UTC (permalink / raw)
To: tglx, richardcochran, andrew+netdev, davem, edumazet, kuba,
pabeni, linux-kernel, netdev, jstultz, anna-maria, frederic,
daniel.lezcano, sboyd, dwmw2
Cc: vladimir.oltean, wei.fang, xiaoning.wang, jonathan.lemon,
vadim.fedorenko, yangbo.lu, svens, nick.shi, ajay.kaher,
alexey.makhalov, bcm-kernel-feedback-list, linux-fpga, imx,
linux-s390, dust.li, xuanzhuo, mani, imran.shaik, taniya.das
In-Reply-To: <20260407104802.34429-1-guwen@linux.alibaba.com>
The PTP subsystem has grown beyond the original IEEE 1588/NIC use case
and today contains both network-oriented PHC drivers and various
emulated/virtual clock implementations.
Prepare for clearer ownership and future maintenance by moving the
emulated/virtual/non-NIC PTP clock drivers into a dedicated subdirectory,
with its own Kconfig and Makefile.
The network/IEEE 1588 oriented drivers remain in drivers/ptp/ alongside
the PTP core infrastructure:
- drivers/ptp/ : PTP core infrastructure and IEEE 1588 /
network-oriented clock drivers.
- drivers/ptp/emulated/ : emulated/virtual/non-NIC implementations
that expose high-precision time sources via
the PTP interface but are not tied to the
NIC/packet-timestamping pipeline.
No functional changes are intended; this is a refactor only.
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
---
drivers/ptp/Kconfig | 68 ++++-----------------
drivers/ptp/Makefile | 11 ++--
drivers/ptp/emulated/Kconfig | 61 ++++++++++++++++++
drivers/ptp/emulated/Makefile | 11 ++++
drivers/ptp/{ => emulated}/ptp_kvm_arm.c | 0
drivers/ptp/{ => emulated}/ptp_kvm_common.c | 0
drivers/ptp/{ => emulated}/ptp_kvm_x86.c | 0
drivers/ptp/{ => emulated}/ptp_s390.c | 0
drivers/ptp/{ => emulated}/ptp_vmclock.c | 0
drivers/ptp/{ => emulated}/ptp_vmw.c | 0
10 files changed, 87 insertions(+), 64 deletions(-)
create mode 100644 drivers/ptp/emulated/Kconfig
create mode 100644 drivers/ptp/emulated/Makefile
rename drivers/ptp/{ => emulated}/ptp_kvm_arm.c (100%)
rename drivers/ptp/{ => emulated}/ptp_kvm_common.c (100%)
rename drivers/ptp/{ => emulated}/ptp_kvm_x86.c (100%)
rename drivers/ptp/{ => emulated}/ptp_s390.c (100%)
rename drivers/ptp/{ => emulated}/ptp_vmclock.c (100%)
rename drivers/ptp/{ => emulated}/ptp_vmw.c (100%)
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index b93640ca08b7..4cb199332546 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -20,11 +20,16 @@ config PTP_1588_CLOCK
time stamping units, it can be possible to achieve
synchronization to within a few hundred nanoseconds.
- This driver adds support for PTP clocks as character
- devices. If you want to use a PTP clock, then you should
- also enable at least one clock driver as well.
+ This infrastructure adds support for PTP clocks as character
+ devices. It has since evolved into a general-purpose PTP
+ clock framework also used by high-precision clocks exposed
+ by platforms, hypervisors or special hardware, beyond the
+ traditional NIC/IEEE 1588 use case.
- To compile this driver as a module, choose M here: the module
+ If you want to use any PTP clock device, enable this option
+ and at least one clock driver.
+
+ To compile the core as a module, choose M here: the module
will be called ptp.
config PTP_1588_CLOCK_OPTIONAL
@@ -119,35 +124,6 @@ config PTP_1588_CLOCK_PCH
To compile this driver as a module, choose M here: the module
will be called ptp_pch.
-config PTP_1588_CLOCK_KVM
- tristate "KVM virtual PTP clock"
- depends on PTP_1588_CLOCK
- depends on (KVM_GUEST && X86) || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER)
- default y
- help
- This driver adds support for using kvm infrastructure as a PTP
- clock. This clock is only useful if you are using KVM guests.
-
- To compile this driver as a module, choose M here: the module
- will be called ptp_kvm.
-
-config PTP_1588_CLOCK_VMCLOCK
- tristate "Virtual machine PTP clock"
- depends on X86_TSC || ARM_ARCH_TIMER
- depends on PTP_1588_CLOCK && ARCH_SUPPORTS_INT128
- default PTP_1588_CLOCK_KVM
- help
- This driver adds support for using a virtual precision clock
- advertised by the hypervisor. This clock is only useful in virtual
- machines where such a device is present.
-
- Unlike the KVM virtual PTP clock, the VMCLOCK device offers support
- for reliable timekeeping even across live migration. So this driver
- is enabled by default whenever the KVM PTP clock is.
-
- To compile this driver as a module, choose M here: the module
- will be called ptp_vmclock.
-
config PTP_1588_CLOCK_IDT82P33
tristate "IDT 82P33xxx PTP clock"
depends on PTP_1588_CLOCK && I2C
@@ -195,18 +171,6 @@ config PTP_1588_CLOCK_MOCK
To compile this driver as a module, choose M here: the module
will be called ptp_mock.
-config PTP_1588_CLOCK_VMW
- tristate "VMware virtual PTP clock"
- depends on ACPI && HYPERVISOR_GUEST && X86
- depends on PTP_1588_CLOCK
- help
- This driver adds support for using VMware virtual precision
- clock device as a PTP clock. This is only useful in virtual
- machines running on VMware virtual infrastructure.
-
- To compile this driver as a module, choose M here: the module
- will be called ptp_vmw.
-
config PTP_1588_CLOCK_OCP
tristate "OpenCompute TimeCard as PTP clock"
depends on PTP_1588_CLOCK
@@ -241,18 +205,6 @@ config PTP_DFL_TOD
To compile this driver as a module, choose M here: the module
will be called ptp_dfl_tod.
-config PTP_S390
- tristate "S390 PTP driver"
- depends on PTP_1588_CLOCK
- depends on S390
- help
- This driver adds support for S390 time steering via the PtP
- interface. This works by adding a in-kernel clock delta value,
- which is always added to time values used in the kernel. The PtP
- driver provides the raw clock value without the delta to
- userspace. That way userspace programs like chrony could steer
- the kernel clock.
-
config PTP_NETC_V4_TIMER
tristate "NXP NETC V4 Timer PTP Driver"
depends on PTP_1588_CLOCK
@@ -263,4 +215,6 @@ config PTP_NETC_V4_TIMER
synchronization. It also supports periodic output signal (e.g. PPS)
and external trigger timestamping.
+source "drivers/ptp/emulated/Kconfig"
+
endmenu
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index bdc47e284f14..bcea2d3d4efd 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -1,24 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
#
-# Makefile for PTP 1588 clock support.
+# Makefile for PTP clock support.
#
+subdir-ccflags-y += -I$(srctree)/drivers/ptp
+
ptp-y := ptp_clock.o ptp_chardev.o ptp_sysfs.o ptp_vclock.o
-ptp_kvm-$(CONFIG_X86) := ptp_kvm_x86.o ptp_kvm_common.o
-ptp_kvm-$(CONFIG_HAVE_ARM_SMCCC) := ptp_kvm_arm.o ptp_kvm_common.o
obj-$(CONFIG_PTP_1588_CLOCK) += ptp.o
obj-$(CONFIG_PTP_1588_CLOCK_DTE) += ptp_dte.o
obj-$(CONFIG_PTP_1588_CLOCK_INES) += ptp_ines.o
obj-$(CONFIG_PTP_1588_CLOCK_PCH) += ptp_pch.o
-obj-$(CONFIG_PTP_1588_CLOCK_KVM) += ptp_kvm.o
-obj-$(CONFIG_PTP_1588_CLOCK_VMCLOCK) += ptp_vmclock.o
obj-$(CONFIG_PTP_1588_CLOCK_QORIQ) += ptp_qoriq.o
obj-$(CONFIG_PTP_1588_CLOCK_IDTCM) += ptp_clockmatrix.o
obj-$(CONFIG_PTP_1588_CLOCK_FC3W) += ptp_fc3.o
obj-$(CONFIG_PTP_1588_CLOCK_IDT82P33) += ptp_idt82p33.o
obj-$(CONFIG_PTP_1588_CLOCK_MOCK) += ptp_mock.o
-obj-$(CONFIG_PTP_1588_CLOCK_VMW) += ptp_vmw.o
obj-$(CONFIG_PTP_1588_CLOCK_OCP) += ptp_ocp.o
obj-$(CONFIG_PTP_DFL_TOD) += ptp_dfl_tod.o
-obj-$(CONFIG_PTP_S390) += ptp_s390.o
obj-$(CONFIG_PTP_NETC_V4_TIMER) += ptp_netc.o
+obj-$(CONFIG_PTP_1588_CLOCK) += emulated/
diff --git a/drivers/ptp/emulated/Kconfig b/drivers/ptp/emulated/Kconfig
new file mode 100644
index 000000000000..3e11f78dfbd8
--- /dev/null
+++ b/drivers/ptp/emulated/Kconfig
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Emulated PTP clock drivers configuration
+#
+
+menu "Emulated PTP clock drivers"
+
+config PTP_1588_CLOCK_KVM
+ tristate "KVM virtual PTP clock"
+ depends on PTP_1588_CLOCK
+ depends on (KVM_GUEST && X86) || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER)
+ default y
+ help
+ This driver adds support for using kvm infrastructure as a PTP
+ clock. This clock is only useful if you are using KVM guests.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ptp_kvm.
+
+config PTP_1588_CLOCK_VMCLOCK
+ tristate "Virtual machine PTP clock"
+ depends on X86_TSC || ARM_ARCH_TIMER
+ depends on PTP_1588_CLOCK && ARCH_SUPPORTS_INT128
+ default PTP_1588_CLOCK_KVM
+ help
+ This driver adds support for using a virtual precision clock
+ advertised by the hypervisor. This clock is only useful in virtual
+ machines where such a device is present.
+
+ Unlike the KVM virtual PTP clock, the VMCLOCK device offers support
+ for reliable timekeeping even across live migration. So this driver
+ is enabled by default whenever the KVM PTP clock is.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ptp_vmclock.
+
+config PTP_1588_CLOCK_VMW
+ tristate "VMware virtual PTP clock"
+ depends on ACPI && HYPERVISOR_GUEST && X86
+ depends on PTP_1588_CLOCK
+ help
+ This driver adds support for using VMware virtual precision
+ clock device as a PTP clock. This is only useful in virtual
+ machines running on VMware virtual infrastructure.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ptp_vmw.
+
+config PTP_S390
+ tristate "S390 PTP driver"
+ depends on PTP_1588_CLOCK
+ depends on S390
+ help
+ This driver adds support for S390 time steering via the PtP
+ interface. This works by adding a in-kernel clock delta value,
+ which is always added to time values used in the kernel. The PtP
+ driver provides the raw clock value without the delta to
+ userspace. That way userspace programs like chrony could steer
+ the kernel clock.
+
+endmenu
diff --git a/drivers/ptp/emulated/Makefile b/drivers/ptp/emulated/Makefile
new file mode 100644
index 000000000000..577917df3dc9
--- /dev/null
+++ b/drivers/ptp/emulated/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for emulated PTP clocks.
+#
+
+ptp_kvm-$(CONFIG_X86) := ptp_kvm_x86.o ptp_kvm_common.o
+ptp_kvm-$(CONFIG_HAVE_ARM_SMCCC) := ptp_kvm_arm.o ptp_kvm_common.o
+obj-$(CONFIG_PTP_1588_CLOCK_KVM) += ptp_kvm.o
+obj-$(CONFIG_PTP_1588_CLOCK_VMCLOCK) += ptp_vmclock.o
+obj-$(CONFIG_PTP_1588_CLOCK_VMW) += ptp_vmw.o
+obj-$(CONFIG_PTP_S390) += ptp_s390.o
diff --git a/drivers/ptp/ptp_kvm_arm.c b/drivers/ptp/emulated/ptp_kvm_arm.c
similarity index 100%
rename from drivers/ptp/ptp_kvm_arm.c
rename to drivers/ptp/emulated/ptp_kvm_arm.c
diff --git a/drivers/ptp/ptp_kvm_common.c b/drivers/ptp/emulated/ptp_kvm_common.c
similarity index 100%
rename from drivers/ptp/ptp_kvm_common.c
rename to drivers/ptp/emulated/ptp_kvm_common.c
diff --git a/drivers/ptp/ptp_kvm_x86.c b/drivers/ptp/emulated/ptp_kvm_x86.c
similarity index 100%
rename from drivers/ptp/ptp_kvm_x86.c
rename to drivers/ptp/emulated/ptp_kvm_x86.c
diff --git a/drivers/ptp/ptp_s390.c b/drivers/ptp/emulated/ptp_s390.c
similarity index 100%
rename from drivers/ptp/ptp_s390.c
rename to drivers/ptp/emulated/ptp_s390.c
diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/emulated/ptp_vmclock.c
similarity index 100%
rename from drivers/ptp/ptp_vmclock.c
rename to drivers/ptp/emulated/ptp_vmclock.c
diff --git a/drivers/ptp/ptp_vmw.c b/drivers/ptp/emulated/ptp_vmw.c
similarity index 100%
rename from drivers/ptp/ptp_vmw.c
rename to drivers/ptp/emulated/ptp_vmw.c
--
2.43.5
^ permalink raw reply related
* Re: [PATCH v3 net] amd-xgbe: synchronize KR training with device operations
From: Paolo Abeni @ 2026-04-07 10:48 UTC (permalink / raw)
To: Raju Rangoju, netdev
Cc: linux-kernel, kuba, edumazet, davem, andrew+netdev,
Thomas.Lendacky, maxime.chevallier
In-Reply-To: <20260403072157.1042806-1-Raju.Rangoju@amd.com>
On 4/3/26 9:21 AM, Raju Rangoju wrote:
> +static bool xgbe_kr_training_in_progress(struct xgbe_prv_data *pdata)
> +{
> + struct xgbe_phy_data *phy_data = pdata->phy_data;
> + unsigned long kr_start, kr_end;
> +
> + /* Only wait for KR training in specific conditions:
> + * - Inphi re-driver is present, OR
> + * - Currently in KR mode with autoneg enabled
> + */
> + if (!xgbe_phy_port_is_inphi(pdata) &&
> + !(phy_data->cur_mode == XGBE_MODE_KR &&
> + pdata->phy.autoneg == AUTONEG_ENABLE))
> + return false;
> +
> + /* If training hasn't completed, ensure it actually started */
> + kr_start = READ_ONCE(pdata->kr_start_time);
> + if (!kr_start)
> + return false;
AFAICS kr_start_time is set to the current jiffies value at
initialization time and 0 is a valid - even if unlikely - jiffies value.
The above test is false-positive prone.
> +
> + /* Training is complete - no need to wait */
> + if (READ_ONCE(pdata->an_result) == XGBE_AN_COMPLETE)
> + return false;
> +
> + kr_end = kr_start +
> + msecs_to_jiffies(XGBE_AN_MS_TIMEOUT + XGBE_KRTR_TIME);
> +
> + /* If we're already past the training window, it's not "in progress" */
> + if (time_after(jiffies, kr_end))
> + return false;
Sashiko notes wrap-around (32 bits systems) will lead to wrong return value.
> +
> + return true;
> +}
> +
> +static void xgbe_wait_for_kr_training_inprogress(struct xgbe_prv_data *pdata)
> +{
> + unsigned long kr_end;
> +
> + if (!xgbe_kr_training_in_progress(pdata))
> + return;
> +
> + /* Don't block the auto-negotiation state machine work item */
> + if (current_work() == &pdata->an_work)
> + return;
> +
> + kr_end = READ_ONCE(pdata->kr_start_time) +
> + msecs_to_jiffies(XGBE_AN_MS_TIMEOUT + XGBE_KRTR_TIME);
> +
> + /* Poll until training completes or the training window expires */
> + while (time_before(jiffies, kr_end)) {
> + if (READ_ONCE(pdata->an_result) == XGBE_AN_COMPLETE)
> + break;
> +
> + usleep_range(10000, 11000);
> + }
> +}
> +
> static void xgbe_phy_perform_ratechange(struct xgbe_prv_data *pdata,
> - enum xgbe_mb_cmd cmd, enum xgbe_mb_subcmd sub_cmd)
> + enum xgbe_mb_cmd cmd,
> + enum xgbe_mb_subcmd sub_cmd)
> {
> unsigned int s0 = 0;
> unsigned int wait;
> @@ -2104,6 +2171,13 @@ static void xgbe_phy_perform_ratechange(struct xgbe_prv_data *pdata,
> /* Disable PLL re-initialization during FW command processing */
> xgbe_phy_pll_ctrl(pdata, false);
>
> + /* Serialize firmware mailbox access.
> + * Protects entire command sequence including busy check, PLL control,
> + * and command execution. Uses explicit lock/unlock for compatibility
> + * with goto-based cleanup (per cleanup.h guidelines).
> + */
> + mutex_lock(&pdata->mailbox_lock);
The comment is confusing, due the the `xgbe_phy_pll_ctrl()` invocation
just before acquiring the lock.
> +
> /* Log if a previous command did not complete */
> if (XP_IOREAD_BITS(pdata, XP_DRIVER_INT_RO, STATUS)) {
> netif_dbg(pdata, link, pdata->netdev,
> @@ -2115,7 +2189,7 @@ static void xgbe_phy_perform_ratechange(struct xgbe_prv_data *pdata,
> XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, COMMAND, cmd);
> XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, sub_cmd);
>
> - /* Issue the command */
> + /* Issue the firmware command */
> XP_IOWRITE(pdata, XP_DRIVER_SCRATCH_0, s0);
> XP_IOWRITE(pdata, XP_DRIVER_SCRATCH_1, 0);
> XP_IOWRITE_BITS(pdata, XP_DRIVER_INT_REQ, REQUEST, 1);
> @@ -2123,11 +2197,13 @@ static void xgbe_phy_perform_ratechange(struct xgbe_prv_data *pdata,
> /* Wait for command to complete */
> wait = XGBE_RATECHANGE_COUNT;
> while (wait--) {
> - if (!XP_IOREAD_BITS(pdata, XP_DRIVER_INT_RO, STATUS))
> + if (!XP_IOREAD_BITS(pdata, XP_DRIVER_INT_RO, STATUS)) {
> + mutex_unlock(&pdata->mailbox_lock);
> goto do_rx_adaptation;
> -
> + }
> usleep_range(1000, 2000);
> }
> + mutex_unlock(&pdata->mailbox_lock);
>
> netif_dbg(pdata, link, pdata->netdev,
> "firmware mailbox command did not complete\n");
A `xgbe_phy_rx_reset()` invocation will happen here, outside the lock.
Can that race? will that corrupt the nic status?
/P
^ permalink raw reply
* [PATCH bpf-next v3 4/6] bpf: allow new DECAP flags and add guard rails
From: Nick Hudson @ 2026-04-07 10:50 UTC (permalink / raw)
To: bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260407105005.1639815-1-nhudson@akamai.com>
Add checks to require shrink-only decap, reject conflicting decap flag
combinations, and verify removed length is sufficient for claimed header
decapsulation.
Co-developed-by: Max Tottenham <mtottenh@akamai.com>
Signed-off-by: Max Tottenham <mtottenh@akamai.com>
Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Nick Hudson <nhudson@akamai.com>
---
net/core/filter.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 4e860da4381d..7f8d43420afb 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -56,6 +56,7 @@
#include <net/sock_reuseport.h>
#include <net/busy_poll.h>
#include <net/tcp.h>
+#include <net/gre.h>
#include <net/xfrm.h>
#include <net/udp.h>
#include <linux/bpf_trace.h>
@@ -3490,6 +3491,12 @@ static u32 bpf_skb_net_base_len(const struct sk_buff *skb)
#define BPF_F_ADJ_ROOM_DECAP_L3_MASK (BPF_F_ADJ_ROOM_DECAP_L3_IPV4 | \
BPF_F_ADJ_ROOM_DECAP_L3_IPV6)
+#define BPF_F_ADJ_ROOM_DECAP_L4_MASK (BPF_F_ADJ_ROOM_DECAP_L4_UDP | \
+ BPF_F_ADJ_ROOM_DECAP_L4_GRE)
+
+#define BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK (BPF_F_ADJ_ROOM_DECAP_IPXIP4 | \
+ BPF_F_ADJ_ROOM_DECAP_IPXIP6)
+
#define BPF_F_ADJ_ROOM_ENCAP_MASK (BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
BPF_F_ADJ_ROOM_ENCAP_L4_GRE | \
BPF_F_ADJ_ROOM_ENCAP_L4_UDP | \
@@ -3497,7 +3504,9 @@ static u32 bpf_skb_net_base_len(const struct sk_buff *skb)
BPF_F_ADJ_ROOM_ENCAP_L2( \
BPF_ADJ_ROOM_ENCAP_L2_MASK))
-#define BPF_F_ADJ_ROOM_DECAP_MASK (BPF_F_ADJ_ROOM_DECAP_L3_MASK)
+#define BPF_F_ADJ_ROOM_DECAP_MASK (BPF_F_ADJ_ROOM_DECAP_L3_MASK | \
+ BPF_F_ADJ_ROOM_DECAP_L4_MASK | \
+ BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)
#define BPF_F_ADJ_ROOM_MASK (BPF_F_ADJ_ROOM_FIXED_GSO | \
BPF_F_ADJ_ROOM_ENCAP_MASK | \
@@ -3740,6 +3749,8 @@ BPF_CALL_4(bpf_skb_adjust_room, struct sk_buff *, skb, s32, len_diff,
}
if (flags & BPF_F_ADJ_ROOM_DECAP_MASK) {
+ u32 len_decap_min = 0;
+
if (!shrink)
return -EINVAL;
@@ -3748,6 +3759,37 @@ BPF_CALL_4(bpf_skb_adjust_room, struct sk_buff *, skb, s32, len_diff,
BPF_F_ADJ_ROOM_DECAP_L3_MASK)
return -EINVAL;
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_MASK) ==
+ BPF_F_ADJ_ROOM_DECAP_L4_MASK)
+ return -EINVAL;
+
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK) ==
+ BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)
+ return -EINVAL;
+
+ /* Reject mutually exclusive decap tunnel type flags. */
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_MASK) &&
+ (flags & BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK))
+ return -EINVAL;
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_L4_MASK)
+ len_decap_min += bpf_skb_net_base_len(skb);
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP)
+ len_decap_min += sizeof(struct udphdr);
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_L4_GRE)
+ len_decap_min += sizeof(struct gre_base_hdr);
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_IPXIP4)
+ len_decap_min += sizeof(struct iphdr);
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_IPXIP6)
+ len_decap_min += sizeof(struct ipv6hdr);
+
+ if (len_diff_abs < len_decap_min)
+ return -EINVAL;
+
if (flags & BPF_F_ADJ_ROOM_DECAP_L3_IPV4)
len_min = sizeof(struct iphdr);
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v3 3/6] bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation
From: Nick Hudson @ 2026-04-07 10:50 UTC (permalink / raw)
To: bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, linux-kernel
In-Reply-To: <20260407105005.1639815-1-nhudson@akamai.com>
Add new bpf_skb_adjust_room() decapsulation flags:
- BPF_F_ADJ_ROOM_DECAP_L4_GRE
- BPF_F_ADJ_ROOM_DECAP_L4_UDP
- BPF_F_ADJ_ROOM_DECAP_IPXIP4
- BPF_F_ADJ_ROOM_DECAP_IPXIP6
These flags let BPF programs describe which tunnel layer is being
removed, so later changes can update tunnel-related GSO state
accordingly during decapsulation.
This patch only introduces the UAPI flag definitions and helper
documentation.
Co-developed-by: Max Tottenham <mtottenh@akamai.com>
Signed-off-by: Max Tottenham <mtottenh@akamai.com>
Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Nick Hudson <nhudson@akamai.com>
---
include/uapi/linux/bpf.h | 34 ++++++++++++++++++++++++++++++++--
tools/include/uapi/linux/bpf.h | 34 ++++++++++++++++++++++++++++++++--
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index c021ed8d7b44..4a53e731c554 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -3010,8 +3010,34 @@ union bpf_attr {
*
* * **BPF_F_ADJ_ROOM_DECAP_L3_IPV4**,
* **BPF_F_ADJ_ROOM_DECAP_L3_IPV6**:
- * Indicate the new IP header version after decapsulating the outer
- * IP header. Used when the inner and outer IP versions are different.
+ * Indicate the new IP header version after decapsulating the
+ * outer IP header. Used when the inner and outer IP versions
+ * are different. These flags only trigger a protocol change
+ * without clearing any tunnel-specific GSO flags.
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_L4_GRE**:
+ * Clear GRE tunnel GSO flags (SKB_GSO_GRE and SKB_GSO_GRE_CSUM)
+ * when decapsulating a GRE tunnel.
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_L4_UDP**:
+ * Clear UDP tunnel GSO flags (SKB_GSO_UDP_TUNNEL and
+ * SKB_GSO_UDP_TUNNEL_CSUM) when decapsulating a UDP tunnel.
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_IPXIP4**:
+ * Clear IPIP/SIT tunnel GSO flag (SKB_GSO_IPXIP4) when decapsulating
+ * a tunnel with an outer IPv4 header (IPv4-in-IPv4 or IPv6-in-IPv4).
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_IPXIP6**:
+ * Clear IPv6 encapsulation tunnel GSO flag (SKB_GSO_IPXIP6) when
+ * decapsulating a tunnel with an outer IPv6 header (IPv6-in-IPv6
+ * or IPv4-in-IPv6).
+ *
+ * When using the decapsulation flags above, the skb->encapsulation
+ * flag is automatically cleared if all tunnel-specific GSO flags
+ * (SKB_GSO_UDP_TUNNEL, SKB_GSO_UDP_TUNNEL_CSUM, SKB_GSO_GRE,
+ * SKB_GSO_GRE_CSUM, SKB_GSO_IPXIP4, SKB_GSO_IPXIP6) have been
+ * removed from the packet. This handles cases where all tunnel
+ * layers have been decapsulated.
*
* A call to this helper is susceptible to change the underlying
* packet buffer. Therefore, at load time, all checks on pointers
@@ -6221,6 +6247,10 @@ enum bpf_adj_room_flags {
BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
BPF_F_ADJ_ROOM_DECAP_L3_IPV4 = (1ULL << 7),
BPF_F_ADJ_ROOM_DECAP_L3_IPV6 = (1ULL << 8),
+ BPF_F_ADJ_ROOM_DECAP_L4_GRE = (1ULL << 9),
+ BPF_F_ADJ_ROOM_DECAP_L4_UDP = (1ULL << 10),
+ BPF_F_ADJ_ROOM_DECAP_IPXIP4 = (1ULL << 11),
+ BPF_F_ADJ_ROOM_DECAP_IPXIP6 = (1ULL << 12),
};
enum {
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index ca35ed622ed5..f4c2fbd8fe68 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -3010,8 +3010,34 @@ union bpf_attr {
*
* * **BPF_F_ADJ_ROOM_DECAP_L3_IPV4**,
* **BPF_F_ADJ_ROOM_DECAP_L3_IPV6**:
- * Indicate the new IP header version after decapsulating the outer
- * IP header. Used when the inner and outer IP versions are different.
+ * Indicate the new IP header version after decapsulating the
+ * outer IP header. Used when the inner and outer IP versions
+ * are different. These flags only trigger a protocol change
+ * without clearing any tunnel-specific GSO flags.
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_L4_GRE**:
+ * Clear GRE tunnel GSO flags (SKB_GSO_GRE and SKB_GSO_GRE_CSUM)
+ * when decapsulating a GRE tunnel.
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_L4_UDP**:
+ * Clear UDP tunnel GSO flags (SKB_GSO_UDP_TUNNEL and
+ * SKB_GSO_UDP_TUNNEL_CSUM) when decapsulating a UDP tunnel.
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_IPXIP4**:
+ * Clear IPIP/SIT tunnel GSO flag (SKB_GSO_IPXIP4) when decapsulating
+ * a tunnel with an outer IPv4 header (IPv4-in-IPv4 or IPv6-in-IPv4).
+ *
+ * * **BPF_F_ADJ_ROOM_DECAP_IPXIP6**:
+ * Clear IPv6 encapsulation tunnel GSO flag (SKB_GSO_IPXIP6) when
+ * decapsulating a tunnel with an outer IPv6 header (IPv6-in-IPv6
+ * or IPv4-in-IPv6).
+ *
+ * When using the decapsulation flags above, the skb->encapsulation
+ * flag is automatically cleared if all tunnel-specific GSO flags
+ * (SKB_GSO_UDP_TUNNEL, SKB_GSO_UDP_TUNNEL_CSUM, SKB_GSO_GRE,
+ * SKB_GSO_GRE_CSUM, SKB_GSO_IPXIP4, SKB_GSO_IPXIP6) have been
+ * removed from the packet. This handles cases where all tunnel
+ * layers have been decapsulated.
*
* A call to this helper is susceptible to change the underlying
* packet buffer. Therefore, at load time, all checks on pointers
@@ -6221,6 +6247,10 @@ enum bpf_adj_room_flags {
BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
BPF_F_ADJ_ROOM_DECAP_L3_IPV4 = (1ULL << 7),
BPF_F_ADJ_ROOM_DECAP_L3_IPV6 = (1ULL << 8),
+ BPF_F_ADJ_ROOM_DECAP_L4_GRE = (1ULL << 9),
+ BPF_F_ADJ_ROOM_DECAP_L4_UDP = (1ULL << 10),
+ BPF_F_ADJ_ROOM_DECAP_IPXIP4 = (1ULL << 11),
+ BPF_F_ADJ_ROOM_DECAP_IPXIP6 = (1ULL << 12),
};
enum {
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v3 5/6] bpf: clear decap tunnel GSO state in skb_adjust_room
From: Nick Hudson @ 2026-04-07 10:50 UTC (permalink / raw)
To: bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260407105005.1639815-1-nhudson@akamai.com>
On shrink in bpf_skb_adjust_room(), clear tunnel-specific GSO flags
according to the decapsulation flags:
- BPF_F_ADJ_ROOM_DECAP_L4_UDP clears SKB_GSO_UDP_TUNNEL{,_CSUM}, and
SKB_GSO_TUNNEL_REMCSUM
- BPF_F_ADJ_ROOM_DECAP_L4_GRE clears SKB_GSO_GRE{,_CSUM}
- BPF_F_ADJ_ROOM_DECAP_IPXIP4 clears SKB_GSO_IPXIP4
- BPF_F_ADJ_ROOM_DECAP_IPXIP6 clears SKB_GSO_IPXIP6
When all tunnel-related GSO bits are cleared, also clear
skb->encapsulation.
Handle the ESP inside a UDP tunnel case where encapsulation should remain
set.
If UDP decap is performed and GSO state removed then reset encap_hdr_csum, and
remcsum_offload.
Co-developed-by: Max Tottenham <mtottenh@akamai.com>
Signed-off-by: Max Tottenham <mtottenh@akamai.com>
Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Nick Hudson <nhudson@akamai.com>
---
net/core/filter.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 7f8d43420afb..04059d07d368 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3667,6 +3667,46 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 off, u32 len_diff,
if (!(flags & BPF_F_ADJ_ROOM_FIXED_GSO))
skb_increase_gso_size(shinfo, len_diff);
+ /* Selective GSO flag clearing based on decap type.
+ * Only clear the flags for the tunnel layer being removed.
+ */
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) &&
+ (shinfo->gso_type & (SKB_GSO_UDP_TUNNEL |
+ SKB_GSO_UDP_TUNNEL_CSUM |
+ SKB_GSO_TUNNEL_REMCSUM)))
+ shinfo->gso_type &= ~(SKB_GSO_UDP_TUNNEL |
+ SKB_GSO_UDP_TUNNEL_CSUM |
+ SKB_GSO_TUNNEL_REMCSUM);
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_GRE) &&
+ (shinfo->gso_type & (SKB_GSO_GRE | SKB_GSO_GRE_CSUM)))
+ shinfo->gso_type &= ~(SKB_GSO_GRE |
+ SKB_GSO_GRE_CSUM);
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP4) &&
+ (shinfo->gso_type & SKB_GSO_IPXIP4))
+ shinfo->gso_type &= ~SKB_GSO_IPXIP4;
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP6) &&
+ (shinfo->gso_type & SKB_GSO_IPXIP6))
+ shinfo->gso_type &= ~SKB_GSO_IPXIP6;
+
+ /* Clear encapsulation flag only when no tunnel GSO flags remain */
+ if (flags & (BPF_F_ADJ_ROOM_DECAP_L4_MASK |
+ BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)) {
+ if (!(shinfo->gso_type & (SKB_GSO_UDP_TUNNEL |
+ SKB_GSO_UDP_TUNNEL_CSUM |
+ SKB_GSO_GRE |
+ SKB_GSO_GRE_CSUM |
+ SKB_GSO_IPXIP4 |
+ SKB_GSO_IPXIP6 |
+ SKB_GSO_ESP)))
+ if (skb->encapsulation)
+ skb->encapsulation = 0;
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) {
+ skb->encap_hdr_csum = !!(shinfo->gso_type & SKB_GSO_UDP_TUNNEL_CSUM);
+ skb->remcsum_offload = !!(shinfo->gso_type & SKB_GSO_TUNNEL_REMCSUM);
+ }
+ }
+
/* Header must be checked, and gso_segs recomputed. */
shinfo->gso_type |= SKB_GSO_DODGY;
shinfo->gso_segs = 0;
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v3 2/6] bpf: refactor masks for ADJ_ROOM flags and encap validation
From: Nick Hudson @ 2026-04-07 10:50 UTC (permalink / raw)
To: bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260407105005.1639815-1-nhudson@akamai.com>
Refactor the helper masks for bpf_skb_adjust_room() flags to simplify
validation logic and introduce:
- BPF_F_ADJ_ROOM_ENCAP_MASK
- BPF_F_ADJ_ROOM_DECAP_MASK
Refactor existing validation checks in bpf_skb_net_shrink()
and bpf_skb_adjust_room() to use the new masks (no behavior change).
This is in preparation for supporting the new decap flags.
Co-developed-by: Max Tottenham <mtottenh@akamai.com>
Signed-off-by: Max Tottenham <mtottenh@akamai.com>
Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Nick Hudson <nhudson@akamai.com>
---
---
net/core/filter.c | 38 +++++++++++++++++++++-----------------
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 78b548158fb0..4e860da4381d 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3490,14 +3490,19 @@ static u32 bpf_skb_net_base_len(const struct sk_buff *skb)
#define BPF_F_ADJ_ROOM_DECAP_L3_MASK (BPF_F_ADJ_ROOM_DECAP_L3_IPV4 | \
BPF_F_ADJ_ROOM_DECAP_L3_IPV6)
-#define BPF_F_ADJ_ROOM_MASK (BPF_F_ADJ_ROOM_FIXED_GSO | \
- BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
+#define BPF_F_ADJ_ROOM_ENCAP_MASK (BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
BPF_F_ADJ_ROOM_ENCAP_L4_GRE | \
BPF_F_ADJ_ROOM_ENCAP_L4_UDP | \
BPF_F_ADJ_ROOM_ENCAP_L2_ETH | \
BPF_F_ADJ_ROOM_ENCAP_L2( \
- BPF_ADJ_ROOM_ENCAP_L2_MASK) | \
- BPF_F_ADJ_ROOM_DECAP_L3_MASK)
+ BPF_ADJ_ROOM_ENCAP_L2_MASK))
+
+#define BPF_F_ADJ_ROOM_DECAP_MASK (BPF_F_ADJ_ROOM_DECAP_L3_MASK)
+
+#define BPF_F_ADJ_ROOM_MASK (BPF_F_ADJ_ROOM_FIXED_GSO | \
+ BPF_F_ADJ_ROOM_ENCAP_MASK | \
+ BPF_F_ADJ_ROOM_DECAP_MASK | \
+ BPF_F_ADJ_ROOM_NO_CSUM_RESET)
static int bpf_skb_net_grow(struct sk_buff *skb, u32 off, u32 len_diff,
u64 flags)
@@ -3618,8 +3623,8 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 off, u32 len_diff,
{
int ret;
- if (unlikely(flags & ~(BPF_F_ADJ_ROOM_FIXED_GSO |
- BPF_F_ADJ_ROOM_DECAP_L3_MASK |
+ if (unlikely(flags & ~(BPF_F_ADJ_ROOM_DECAP_MASK |
+ BPF_F_ADJ_ROOM_FIXED_GSO |
BPF_F_ADJ_ROOM_NO_CSUM_RESET)))
return -EINVAL;
@@ -3715,8 +3720,7 @@ BPF_CALL_4(bpf_skb_adjust_room, struct sk_buff *, skb, s32, len_diff,
u32 off;
int ret;
- if (unlikely(flags & ~(BPF_F_ADJ_ROOM_MASK |
- BPF_F_ADJ_ROOM_NO_CSUM_RESET)))
+ if (unlikely(flags & ~BPF_F_ADJ_ROOM_MASK))
return -EINVAL;
if (unlikely(len_diff_abs > 0xfffU))
return -EFAULT;
@@ -3735,20 +3739,20 @@ BPF_CALL_4(bpf_skb_adjust_room, struct sk_buff *, skb, s32, len_diff,
return -ENOTSUPP;
}
- if (flags & BPF_F_ADJ_ROOM_DECAP_L3_MASK) {
+ if (flags & BPF_F_ADJ_ROOM_DECAP_MASK) {
if (!shrink)
return -EINVAL;
- switch (flags & BPF_F_ADJ_ROOM_DECAP_L3_MASK) {
- case BPF_F_ADJ_ROOM_DECAP_L3_IPV4:
+ /* Reject mutually exclusive decap flag pairs. */
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_L3_MASK) ==
+ BPF_F_ADJ_ROOM_DECAP_L3_MASK)
+ return -EINVAL;
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_L3_IPV4)
len_min = sizeof(struct iphdr);
- break;
- case BPF_F_ADJ_ROOM_DECAP_L3_IPV6:
+
+ if (flags & BPF_F_ADJ_ROOM_DECAP_L3_IPV6)
len_min = sizeof(struct ipv6hdr);
- break;
- default:
- return -EINVAL;
- }
}
len_cur = skb->len - skb_network_offset(skb);
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v3 6/6] selftests/bpf: tc_tunnel validate decap GSO state
From: Nick Hudson @ 2026-04-07 10:50 UTC (permalink / raw)
To: bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Shuah Khan,
linux-kselftest, linux-kernel
In-Reply-To: <20260407105005.1639815-1-nhudson@akamai.com>
Require BPF_F_ADJ_ROOM_DECAP_L4_UDP and BPF_F_ADJ_ROOM_DECAP_L4_GRE enum
values at runtime using CO-RE enum existence checks so missing kernel
support fails fast instead of silently proceeding.
After bpf_skb_adjust_room() decapsulation, inspect skb_shared_info and
sk_buff state for GSO packets and assert that the expected tunnel GSO
bits are cleared and encapsulation matches the remaining tunnel state.
Signed-off-by: Nick Hudson <nhudson@akamai.com>
---
.../selftests/bpf/progs/test_tc_tunnel.c | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
index 7376df405a6b..74dfb694a210 100644
--- a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
+++ b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
@@ -6,6 +6,7 @@
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>
+#include <bpf/bpf_core_read.h>
#include "bpf_tracing_net.h"
#include "bpf_compiler.h"
@@ -37,6 +38,23 @@ struct vxlanhdr___local {
#define EXTPROTO_VXLAN 0x1
+#define SKB_GSO_UDP_TUNNEL_MASK (SKB_GSO_UDP_TUNNEL | \
+ SKB_GSO_UDP_TUNNEL_CSUM | \
+ SKB_GSO_TUNNEL_REMCSUM)
+
+#define SKB_GSO_TUNNEL_MASK (SKB_GSO_UDP_TUNNEL_MASK | \
+ SKB_GSO_GRE | \
+ SKB_GSO_GRE_CSUM | \
+ SKB_GSO_IPXIP4 | \
+ SKB_GSO_IPXIP6 | \
+ SKB_GSO_ESP)
+
+#define BPF_F_ADJ_ROOM_DECAP_L4_MASK (BPF_F_ADJ_ROOM_DECAP_L4_UDP | \
+ BPF_F_ADJ_ROOM_DECAP_L4_GRE)
+
+#define BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK (BPF_F_ADJ_ROOM_DECAP_IPXIP4 | \
+ BPF_F_ADJ_ROOM_DECAP_IPXIP6)
+
#define VXLAN_FLAGS bpf_htonl(1<<27)
#define VNI_ID 1
#define VXLAN_VNI bpf_htonl(VNI_ID << 8)
@@ -592,6 +610,8 @@ int __encap_ip6vxlan_eth(struct __sk_buff *skb)
static int decap_internal(struct __sk_buff *skb, int off, int len, char proto)
{
__u64 flags = BPF_F_ADJ_ROOM_FIXED_GSO;
+ struct sk_buff *kskb;
+ struct skb_shared_info *shinfo;
struct ipv6_opt_hdr ip6_opt_hdr;
struct gre_hdr greh;
struct udphdr udph;
@@ -621,6 +641,11 @@ static int decap_internal(struct __sk_buff *skb, int off, int len, char proto)
break;
case IPPROTO_GRE:
olen += sizeof(struct gre_hdr);
+ if (!bpf_core_enum_value_exists(enum bpf_adj_room_flags,
+ BPF_F_ADJ_ROOM_DECAP_L4_GRE))
+ return TC_ACT_SHOT;
+ flags |= BPF_F_ADJ_ROOM_DECAP_L4_GRE;
+
if (bpf_skb_load_bytes(skb, off + len, &greh, sizeof(greh)) < 0)
return TC_ACT_OK;
switch (bpf_ntohs(greh.protocol)) {
@@ -634,6 +659,10 @@ static int decap_internal(struct __sk_buff *skb, int off, int len, char proto)
break;
case IPPROTO_UDP:
olen += sizeof(struct udphdr);
+ if (!bpf_core_enum_value_exists(enum bpf_adj_room_flags,
+ BPF_F_ADJ_ROOM_DECAP_L4_UDP))
+ return TC_ACT_SHOT;
+ flags |= BPF_F_ADJ_ROOM_DECAP_L4_UDP;
if (bpf_skb_load_bytes(skb, off + len, &udph, sizeof(udph)) < 0)
return TC_ACT_OK;
switch (bpf_ntohs(udph.dest)) {
@@ -655,6 +684,35 @@ static int decap_internal(struct __sk_buff *skb, int off, int len, char proto)
if (bpf_skb_adjust_room(skb, -olen, BPF_ADJ_ROOM_MAC, flags))
return TC_ACT_SHOT;
+ kskb = bpf_cast_to_kern_ctx(skb);
+ shinfo = bpf_core_cast(kskb->head + kskb->end, struct skb_shared_info);
+ if (!shinfo->gso_size)
+ return TC_ACT_OK;
+
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) &&
+ (shinfo->gso_type & SKB_GSO_UDP_TUNNEL_MASK))
+ return TC_ACT_SHOT;
+
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_GRE) &&
+ (shinfo->gso_type & (SKB_GSO_GRE | SKB_GSO_GRE_CSUM)))
+ return TC_ACT_SHOT;
+
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP4) &&
+ (shinfo->gso_type & SKB_GSO_IPXIP4))
+ return TC_ACT_SHOT;
+
+ if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP6) &&
+ (shinfo->gso_type & SKB_GSO_IPXIP6))
+ return TC_ACT_SHOT;
+
+ if (flags & (BPF_F_ADJ_ROOM_DECAP_L4_MASK |
+ BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)) {
+ if ((shinfo->gso_type & SKB_GSO_TUNNEL_MASK) && !kskb->encapsulation)
+ return TC_ACT_SHOT;
+ if (!(shinfo->gso_type & SKB_GSO_TUNNEL_MASK) && kskb->encapsulation)
+ return TC_ACT_SHOT;
+ }
+
return TC_ACT_OK;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next] pppoe: drop PFC frames
From: Paolo Abeni @ 2026-04-07 11:05 UTC (permalink / raw)
To: qingfang.deng, Simon Horman
Cc: linux-ppp, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, netdev, linux-kernel, Paul Mackerras, Jaco Kroon,
James Carlson, Wojciech Drewek, Guillaume Nault
In-Reply-To: <e3ada3f0bb0c389d592657b37c462944e633a0d6@linux.dev>
On 4/7/26 5:19 AM, qingfang.deng@linux.dev wrote:
> April 6, 2026 at 10:48 PM, Simon Horman wrote:
>> I think it would be best to add/use a #define rather than
>> open coding the magic value 0x01. And perhaps expanding
>> the comment to note that skb->data[0] is the first byte
>> of the PPP protocol would be nice too.
>
> The field does not have a canonical name. As per RFC1661, the LSB of the
> first octet is used to test if the protocol field is compressed, and the
> same code snippet is used in ppp_generic.c.
>
> I could instead add a helper function:
>
> static inline bool ppp_skb_is_compressed_proto(const struct sk_buff *skb)
> {
> return skb->data[0] & 0x01;
> }
>
> What do you think?
The helper LGTM, and could be re-used in ppp_generic.c, too.
/P
^ permalink raw reply
* [PATCH net-next v4 2/2] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 10:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <191e9f7e3a6c14eabe891a98c5fb646766479c0a.1775558273.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: drop AM64_CPSW_QUIRK_CUT_THRU flag, which is a downstream ti-linux feature
v3: resubmission for net-next, no changes
v4: no changes
SGMII operation also requires changes to the phy-j721e-wiz and gmii-sel drivers:
https://lore.kernel.org/lkml/cover.1775045279.git.nora.schiffer@ew.tq-group.com/
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d9400599e80a4..7ac75fc8cdcf4 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -3468,6 +3468,13 @@ static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
.fdqring_mode = K3_RINGACC_RING_MODE_RING,
};
+static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
+ .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ,
+ .ale_dev_id = "am64-cpswxg",
+ .fdqring_mode = K3_RINGACC_RING_MODE_RING,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const struct am65_cpsw_pdata j7200_cpswxg_pdata = {
.quirks = 0,
.ale_dev_id = "am64-cpswxg",
@@ -3495,6 +3502,7 @@ static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
{ .compatible = "ti,am654-cpsw-nuss", .data = &am65x_sr1_0},
{ .compatible = "ti,j721e-cpsw-nuss", .data = &j721e_pdata},
{ .compatible = "ti,am642-cpsw-nuss", .data = &am64x_cpswxg_pdata},
+ { .compatible = "ti,j722s-cpsw-nuss", .data = &j722s_cpswxg_pdata},
{ .compatible = "ti,j7200-cpswxg-nuss", .data = &j7200_cpswxg_pdata},
{ .compatible = "ti,j721e-cpswxg-nuss", .data = &j721e_cpswxg_pdata},
{ .compatible = "ti,j784s4-cpswxg-nuss", .data = &j784s4_cpswxg_pdata},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ 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