* Re: [PATCH 1/2] net/socket: Record preference for synchronous wakeups
From: Shrikanth Hegde @ 2026-07-21 5:00 UTC (permalink / raw)
To: Srikar Dronamraju, LKML, netdev, David S Miller
Cc: Ingo Molnar, Peter Zijlstra, Dietmar Eggemann, Dust Li, D Wythe,
Eric Dumazet, Jakub Kicinski, Jon Maloy, Kuniyuki Iwashima,
linux-sctp, Mahanta Jambigi, Marcelo Ricardo Leitner, Paolo Abeni,
Sidraya Jayagond, Simon Horman, Tony Lu, Wen Gu, Wenjia Zhang,
Willem de Bruijn, Xin Long, Vincent Guittot, Steven Rostedt,
Ben Segall, Mel Gorman, Valentin Schneider, K Prateek Nayak
In-Reply-To: <20260714013940.4068189-5-srikar@linux.ibm.com>
Hi Srikar.
On 7/14/26 7:09 AM, Srikar Dronamraju wrote:
> Scheduler differentiates between affine and non-affine wakeups by the
> way of sync flags. Scheduler prefers to pull the tasks towards the waker
> if the sync flag is set.
>
> In some cases, socket APIs are blindly requesting sync wakeups. This may
> cause load-balance issues and non-optimal performance.
>
> Record whether the most recent blocking socket operation could benefit
> from synchronous wakeups. Subsequent readiness notifications use this
> hint to determine whether WF_SYNC should be propagated.
>
What you mean by recent? Was it info on past set of packets?
Could you please explain the flow a bit?
Shouldn't it be
- if this socket has been defined as nonblock it shouldn't use sync
always?
> The flag is advisory and affects only wakeup placement decisions.
>
> Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
> ---
> include/net/sock.h | 1 +
> net/socket.c | 56 +++++++++++++++++++++++++++++++++++++++-------
> 2 files changed, 49 insertions(+), 8 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 51185222aac2..acc6b1976dc4 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1022,6 +1022,7 @@ enum sock_flags {
> SOCK_RCVMARK, /* Receive SO_MARK ancillary data with packet */
> SOCK_RCVPRIORITY, /* Receive SO_PRIORITY ancillary data with packet */
> SOCK_TIMESTAMPING_ANY, /* Copy of sk_tsflags & TSFLAGS_ANY */
> + SOCK_SYNC_WAKEUP, /* Prefer synchronous socket wakeups */
> };
>
> #define SK_FLAGS_TIMESTAMP ((1UL << SOCK_TIMESTAMP) | (1UL << SOCK_TIMESTAMPING_RX_SOFTWARE))
> diff --git a/net/socket.c b/net/socket.c
> index 63c69a0fa74e..0bcb57ae490e 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1198,15 +1198,27 @@ static void sock_splice_eof(struct file *file)
> ops->splice_eof(sock);
> }
>
> +static inline void sock_update_sync_wakeup(struct sock *sk, bool nonblock)
> +{
> + if (unlikely(!sk))
> + return;
> +
> + if (nonblock) {
> + if (sock_flag(sk, SOCK_SYNC_WAKEUP))
> + sock_reset_flag(sk, SOCK_SYNC_WAKEUP);
> + } else {
> + if (!sock_flag(sk, SOCK_SYNC_WAKEUP))
> + sock_set_flag(sk, SOCK_SYNC_WAKEUP);
> + }
> +}
nit: You can combine two if statements. A bit easier to read.
static inline void sock_update_sync_wakeup(struct sock *sk, bool nonblock)
{
if (unlikely(!sk))
return;
if (nonblock && sock_flag(sk, SOCK_SYNC_WAKEUP))
sock_reset_flag(sk, SOCK_SYNC_WAKEUP);
else if (!nonblock && !sock_flag(sk, SOCK_SYNC_WAKEUP))
sock_set_flag(sk, SOCK_SYNC_WAKEUP);
}
> +
> static ssize_t sock_read_iter(struct kiocb *iocb, struct iov_iter *to)
> {
> struct file *file = iocb->ki_filp;
> struct socket *sock = file->private_data;
> struct msghdr msg = {.msg_iter = *to};
> ssize_t res;
> -
> - if (file->f_flags & O_NONBLOCK || (iocb->ki_flags & IOCB_NOWAIT))
> - msg.msg_flags = MSG_DONTWAIT;
> + bool nonblock;
>
> if (iocb->ki_pos != 0)
> return -ESPIPE;
> @@ -1214,6 +1226,11 @@ static ssize_t sock_read_iter(struct kiocb *iocb, struct iov_iter *to)
> if (!iov_iter_count(to)) /* Match SYS5 behaviour */
> return 0;
>
> + nonblock = (file->f_flags & O_NONBLOCK) || (iocb->ki_flags & IOCB_NOWAIT);
> + if (nonblock)
> + msg.msg_flags = MSG_DONTWAIT;
> +
> + sock_update_sync_wakeup(sock->sk, nonblock);
> res = sock_recvmsg(sock, &msg, msg.msg_flags);
> *to = msg.msg_iter;
> return res;
> @@ -1225,13 +1242,17 @@ static ssize_t sock_write_iter(struct kiocb *iocb, struct iov_iter *from)
> struct socket *sock = file->private_data;
> struct msghdr msg = {.msg_iter = *from};
> ssize_t res;
> + bool nonblock;
>
> if (iocb->ki_pos != 0)
> return -ESPIPE;
>
> - if (file->f_flags & O_NONBLOCK || (iocb->ki_flags & IOCB_NOWAIT))
> + nonblock = (file->f_flags & O_NONBLOCK) || (iocb->ki_flags & IOCB_NOWAIT);
> + if (nonblock)
> msg.msg_flags = MSG_DONTWAIT;
>
> + sock_update_sync_wakeup(sock->sk, nonblock);
> +
> if (sock->type == SOCK_SEQPACKET)
> msg.msg_flags |= MSG_EOR;
>
> @@ -2221,6 +2242,7 @@ int __sys_sendto(int fd, void __user *buff, size_t len, unsigned int flags,
> struct sockaddr_storage address;
> int err;
> struct msghdr msg;
> + bool nonblock;
>
> err = import_ubuf(ITER_SOURCE, buff, len, &msg.msg_iter);
> if (unlikely(err))
> @@ -2246,8 +2268,11 @@ int __sys_sendto(int fd, void __user *buff, size_t len, unsigned int flags,
> msg.msg_namelen = addr_len;
> }
> flags &= ~MSG_INTERNAL_SENDMSG_FLAGS;
> - if (sock->file->f_flags & O_NONBLOCK)
> + nonblock = (sock->file->f_flags & O_NONBLOCK);
> + if (nonblock)
> flags |= MSG_DONTWAIT;
> +
> + sock_update_sync_wakeup(sock->sk, nonblock);
> msg.msg_flags = flags;
> return __sock_sendmsg(sock, &msg);
> }
> @@ -2284,6 +2309,7 @@ int __sys_recvfrom(int fd, void __user *ubuf, size_t size, unsigned int flags,
> };
> struct socket *sock;
> int err, err2;
> + bool nonblock;
>
> err = import_ubuf(ITER_DEST, ubuf, size, &msg.msg_iter);
> if (unlikely(err))
> @@ -2297,8 +2323,11 @@ int __sys_recvfrom(int fd, void __user *ubuf, size_t size, unsigned int flags,
> if (unlikely(!sock))
> return -ENOTSOCK;
>
> - if (sock->file->f_flags & O_NONBLOCK)
> + nonblock = (sock->file->f_flags & O_NONBLOCK);
> + if (nonblock)
> flags |= MSG_DONTWAIT;
> +
> + sock_update_sync_wakeup(sock->sk, nonblock);
> err = sock_recvmsg(sock, &msg, flags);
>
> if (err >= 0 && addr != NULL) {
> @@ -2634,6 +2663,7 @@ static int ____sys_sendmsg(struct socket *sock, struct msghdr *msg_sys,
> unsigned char *ctl_buf = ctl;
> int ctl_len;
> ssize_t err;
> + bool nonblock;
>
> err = -ENOBUFS;
>
> @@ -2666,8 +2696,12 @@ static int ____sys_sendmsg(struct socket *sock, struct msghdr *msg_sys,
> flags &= ~MSG_INTERNAL_SENDMSG_FLAGS;
> msg_sys->msg_flags = flags;
>
> - if (sock->file->f_flags & O_NONBLOCK)
> + nonblock = (sock->file->f_flags & O_NONBLOCK);
> + if (nonblock)
> msg_sys->msg_flags |= MSG_DONTWAIT;
> +
> + sock_update_sync_wakeup(sock->sk, nonblock);
> +
> /*
> * If this is sendmmsg() and current destination address is same as
> * previously succeeded address, omit asking LSM's decision.
> @@ -2887,6 +2921,7 @@ static int ____sys_recvmsg(struct socket *sock, struct msghdr *msg_sys,
> unsigned long cmsg_ptr;
> int len;
> ssize_t err;
> + bool nonblock;
>
> msg_sys->msg_name = &addr;
> cmsg_ptr = (unsigned long)msg_sys->msg_control;
> @@ -2895,9 +2930,12 @@ static int ____sys_recvmsg(struct socket *sock, struct msghdr *msg_sys,
> /* We assume all kernel code knows the size of sockaddr_storage */
> msg_sys->msg_namelen = 0;
>
> - if (sock->file->f_flags & O_NONBLOCK)
> + nonblock = (sock->file->f_flags & O_NONBLOCK);
> + if (nonblock)
> flags |= MSG_DONTWAIT;
>
> + sock_update_sync_wakeup(sock->sk, nonblock);
> +
> if (unlikely(nosec))
> err = sock_recvmsg_nosec(sock, msg_sys, flags);
> else
> @@ -3056,6 +3094,8 @@ static int do_recvmmsg(int fd, struct mmsghdr __user *mmsg,
> if (flags & MSG_WAITFORONE)
> flags |= MSG_DONTWAIT;
>
> + sock_update_sync_wakeup(sock->sk, flags & MSG_WAITFORONE);
> +
> if (timeout) {
> ktime_get_ts64(&timeout64);
> *timeout = timespec64_sub(end_time, timeout64);
^ permalink raw reply
* [PATCH v5 0/7] Read MAC address from SST vendor specific SFDP region
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
Some Microchip/SST QSPI flashes (e.g. the SST26VF064BEUI) are factory
programmed with globally unique, write-protected EUI-48 and EUI-64
identifiers stored in a vendor-specific SFDP parameter table. On boards
that have no on-board EEPROM (sama5d27_wlsom1, sama5d29 curiosity,
sam9x75 curiosity) this is a reliable source for an Ethernet MAC address,
instead of relying on a U-Boot-provided or random address.
This v5 reworks the approach into a generic NVMEM framework with no vendor
code in the SPI NOR core:
- The SPI NOR core now exposes the entire SFDP as a generic read-only
NVMEM device, rooted at a new "sfdp" child node of the flash.
- A new NVMEM layout driver (drivers/nvmem/layouts/) locates the
Microchip vendor parameter table at runtime and presents the EUI-48 as
a "mac-address" cell.
- Arbitrary parameters can be read with a standard fixed-layout
(known offset) or with an nvmem-layout parser (location discovered at runtime).
Changes in v5:
- 1/7 and 5/7 - Add R-b tags
- 3/7- Rework the comments, function name and commit message.Check all the nodes
(for_each_available_child) for the right compatible "jedec,sfdp" instead
of node name.
Changes in v4:
- Rework per v3 review: remove the vendor-specific SFDP handling from the
SPI NOR core; expose the whole SFDP as a generic read-only NVMEM device
and move the EUI extraction into an nvmem-layout driver.
- Introduce a new nvmem-layout driver to discover the vendor-table location
at runtime; no offset hardcoded in the device tree.
- Describe the SFDP via a dedicated "sfdp" subnode (compatible
"jedec,sfdp"), which also resolves the v3 dtbs_check "Unevaluated
properties ('nvmem-layout')" warning.
- Reverse the stored EUI bytes into canonical MAC order.
- Enable the layout in sama5_defconfig.
Changes in v3:
- 2/3 - add support to update the QSPI partition into 'fixed-partition'
binding in sama5d27_wlsom1
- 3/3 - add nvmem-layout in qspi node for EUI48 MAC Address and nvmem cell
properties for macb node in sama5d27_wlsom1
Changes in v2:
- 1/3 - parse the SST vendor table, read and store the addresses
into a resource - managed space. Register the addresses
into NVMEM framework
- 2/3 - add support to update the QSPI partition into 'fixed-partition'
binding
v4: https://lore.kernel.org/linux-devicetree/20260630092406.150587-1-manikandan.m@microchip.com/
Manikandan Muralidharan (7):
dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via
NVMEM
dt-bindings: nvmem: layouts: add Microchip/SST SFDP EUI layout
mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
nvmem: layouts: add Microchip/SST SFDP EUI layout driver
ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI
flash
ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP
ARM: configs: sama5: enable Microchip/SST SFDP EUI NVMEM layout
.../bindings/mtd/jedec,spi-nor.yaml | 18 ++
.../layouts/microchip,sst26vf-sfdp-eui.yaml | 60 ++++++
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
MAINTAINERS | 6 +
.../dts/microchip/at91-sama5d27_wlsom1.dtsi | 61 +++---
.../dts/microchip/at91-sama5d27_wlsom1_ek.dts | 2 +
arch/arm/configs/sama5_defconfig | 1 +
drivers/mtd/spi-nor/core.c | 8 +
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 86 +++++++++
drivers/nvmem/layouts/Kconfig | 10 +
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/sst26vf-sfdp-eui.c | 182 ++++++++++++++++++
13 files changed, 415 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
create mode 100644 drivers/nvmem/layouts/sst26vf-sfdp-eui.c
base-commit: b95f03f04d475aa6719d15a636ddf32222d55657
--
2.43.0
^ permalink raw reply
* [PATCH v5 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Add an optional "sfdp" child node (compatible "jedec,sfdp") that
describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
.../devicetree/bindings/mtd/jedec,spi-nor.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 587af4968255..98fd954598ab 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -103,6 +103,20 @@ properties:
spi-cpol: true
spi-cpha: true
+ sfdp:
+ $ref: /schemas/nvmem/nvmem.yaml#
+ unevaluatedProperties: false
+ description:
+ The Serial Flash Discoverable Parameters (SFDP) tables exposed as a
+ read-only NVMEM device. This allows standard or vendor-specific SFDP
+ data (for example a factory-programmed EUI-48/EUI-64 identifier) to be
+ consumed through NVMEM cells.
+ properties:
+ compatible:
+ const: jedec,sfdp
+ required:
+ - compatible
+
dependencies:
spi-cpol: [ spi-cpha ]
spi-cpha: [ spi-cpol ]
@@ -122,6 +136,10 @@ examples:
spi-max-frequency = <40000000>;
m25p,fast-read;
reset-gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+
+ sfdp {
+ compatible = "jedec,sfdp";
+ };
};
};
...
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/7] dt-bindings: nvmem: layouts: add Microchip/SST SFDP EUI layout
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Add a binding for the NVMEM layout that exposes the factory-programmed
EUI-48 identifier from the Microchip/SST vendor-specific SFDP parameter
table (e.g. SST26VF064BEUI) as a "mac-address" NVMEM cell, and reference
it from nvmem-layout.yaml.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
.../layouts/microchip,sst26vf-sfdp-eui.yaml | 60 +++++++++++++++++++
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
2 files changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml b/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
new file mode 100644
index 000000000000..37357efb7840
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the Microchip/SST SFDP EUI-48 identifier
+
+maintainers:
+ - Manikandan Muralidharan <manikandan.m@microchip.com>
+
+description:
+ Some Microchip/SST serial flashes (for example the SST26VF064BEUI) are
+ factory programmed with a globally unique EUI-48 identifier stored in a
+ vendor-specific SFDP parameter table and permanently write-protected. This
+ layout locates that table and exposes the EUI-48 as an NVMEM cell so that,
+ for example, a network driver can use it as a MAC address. The location of
+ the data is discovered at runtime from the SFDP; no offset is encoded in the
+ device tree.
+
+select: false
+
+properties:
+ compatible:
+ const: microchip,sst26vf-sfdp-eui
+
+ mac-address:
+ type: object
+ description:
+ The factory-programmed EUI-48 identifier, usable as a MAC address.
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+
+ sfdp {
+ compatible = "jedec,sfdp";
+
+ nvmem-layout {
+ compatible = "microchip,sst26vf-sfdp-eui";
+
+ mac-address {
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
index 382507060651..e63b93083821 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -20,6 +20,7 @@ description: |
oneOf:
- $ref: fixed-layout.yaml
- $ref: kontron,sl28-vpd.yaml
+ - $ref: microchip,sst26vf-sfdp-eui.yaml
- $ref: onie,tlv-layout.yaml
- $ref: u-boot,env.yaml
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
The SPI NOR core already reads the SFDP tables during enumeration and
caches them in nor->sfdp->dwords (see spi_nor_parse_sfdp()). Re-expose
that cached data as a read-only NVMEM device, in on-flash byte order,
rooted at the flash's SFDP child node (compatible "jedec,sfdp").
This lets NVMEM cells reference any SFDP data: a fixed-layout for
parameters at a known offset, or an nvmem-layout parser for vendor data
whose location must be discovered at runtime.The device is only registered
when an "sfdp" node is present in the device tree.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
drivers/mtd/spi-nor/core.c | 8 ++++
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 86 ++++++++++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ccf4396cdcd0..b833d8ec2d65 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3204,6 +3204,14 @@ static int spi_nor_init_params(struct spi_nor *nor)
spi_nor_init_params_deprecated(nor);
}
+ /*
+ * Expose the SFDP table as an NVMEM device only when
+ * the flash actually provides one
+ */
+ ret = spi_nor_register_sfdp_nvmem(nor);
+ if (ret)
+ return ret;
+
ret = spi_nor_late_init_params(nor);
if (ret)
return ret;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index ba2d1a862c9d..0a6484298c5c 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -698,6 +698,7 @@ int spi_nor_controller_ops_write_reg(struct spi_nor *nor, u8 opcode,
int spi_nor_check_sfdp_signature(struct spi_nor *nor);
int spi_nor_parse_sfdp(struct spi_nor *nor);
+int spi_nor_register_sfdp_nvmem(struct spi_nor *nor);
static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
{
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 4600983cb579..704799fe92ae 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -6,6 +6,8 @@
#include <linux/bitfield.h>
#include <linux/mtd/spi-nor.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
#include <linux/slab.h>
#include <linux/sort.h>
@@ -1612,3 +1614,87 @@ int spi_nor_parse_sfdp(struct spi_nor *nor)
kfree(param_headers);
return err;
}
+
+static int spi_nor_sfdp_reg_read(void *priv, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct spi_nor *nor = priv;
+ struct sfdp *sfdp = nor->sfdp;
+ size_t sfdp_size = sfdp->num_dwords * sizeof(*sfdp->dwords);
+
+ if (offset >= sfdp_size || bytes > sfdp_size - offset)
+ return -EINVAL;
+
+ /* The cached SFDP is kept in on-flash (little-endian) byte order. */
+ memcpy(val, (u8 *)sfdp->dwords + offset, bytes);
+
+ return 0;
+}
+
+static void spi_nor_sfdp_nvmem_put_np(void *data)
+{
+ of_node_put(data);
+}
+
+/**
+ * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
+ * rooted at the flash's SFDP child node (compatible "jedec,sfdp"). This lets
+ * generic (fixed-layout) or vendor (nvmem-layout) cells reference any SFDP
+ * data. The device is only registered when a child node with the "jedec,sfdp"
+ * compatible is described in the device tree.
+ *
+ * Return: 0 on success or if there is nothing to do, -errno otherwise.
+ */
+int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
+{
+ struct device *dev = nor->dev;
+ struct nvmem_config config = { };
+ struct nvmem_device *nvmem;
+ struct device_node *np;
+ int ret;
+
+ if (!nor->sfdp)
+ return 0;
+
+ for_each_available_child_of_node(dev_of_node(dev), np)
+ if (of_device_is_compatible(np, "jedec,sfdp"))
+ break;
+ if (!np)
+ return 0;
+
+ /*
+ * Register the put before devm_nvmem_register() so it runs last on
+ * detach, after the NVMEM device that uses the node is gone.
+ */
+ ret = devm_add_action_or_reset(dev, spi_nor_sfdp_nvmem_put_np, np);
+ if (ret)
+ return ret;
+
+ config.dev = dev;
+ config.of_node = np;
+ config.name = "sfdp";
+ config.id = NVMEM_DEVID_AUTO;
+ config.owner = THIS_MODULE;
+ config.read_only = true;
+ config.word_size = 1;
+ config.stride = 1;
+ config.size = (int)(nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords));
+ config.reg_read = spi_nor_sfdp_reg_read;
+ config.priv = nor;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem)) {
+ /* NVMEM support is optional. */
+ if (PTR_ERR(nvmem) == -EOPNOTSUPP)
+ return 0;
+ return dev_err_probe(dev, PTR_ERR(nvmem),
+ "failed to register SFDP NVMEM device\n");
+ }
+
+ dev_dbg(dev, "exposed %d-byte SFDP as an NVMEM device\n", config.size);
+
+ return 0;
+}
--
2.43.0
^ permalink raw reply related
* [PATCH v5 4/7] nvmem: layouts: add Microchip/SST SFDP EUI layout driver
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Add an NVMEM layout that exposes the factory-programmed EUI-48 identifier
from the Microchip/SST vendor SFDP parameter table (e.g. SST26VF064BEUI)
as a "mac-address" cell, for use as a network MAC address. The vendor
table is located at runtime via the SFDP NVMEM device (no offset in DT),
and a read_post_process callback reverses the LSB-first bytes into
canonical MAC order. Binds to an "nvmem-layout" node with compatible
"microchip,sst26vf-sfdp-eui".
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
MAINTAINERS | 6 +
drivers/nvmem/layouts/Kconfig | 10 ++
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/sst26vf-sfdp-eui.c | 182 +++++++++++++++++++++++
4 files changed, 199 insertions(+)
create mode 100644 drivers/nvmem/layouts/sst26vf-sfdp-eui.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1ab8736850ea..9fac8c5203a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17815,6 +17815,12 @@ F: Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml
F: drivers/misc/atmel-ssc.c
F: include/linux/atmel-ssc.h
+MICROCHIP SST SFDP EUI NVMEM LAYOUT DRIVER
+M: Manikandan Muralidharan <manikandan.m@microchip.com>
+S: Maintained
+F: Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
+F: drivers/nvmem/layouts/sst26vf-sfdp-eui.c
+
Microchip Timer Counter Block (TCB) Capture Driver
M: Kamel Bouhara <kamel.bouhara@bootlin.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 5e586dfebe47..855c7db530da 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -26,6 +26,16 @@ config NVMEM_LAYOUT_ONIE_TLV
If unsure, say N.
+config NVMEM_LAYOUT_SST26VF_SFDP_EUI
+ tristate "Microchip/SST SFDP EUI-48 layout support"
+ help
+ Say Y here if you want to expose the factory-programmed EUI-48
+ identifier stored in the Microchip/SST vendor-specific SFDP parameter
+ table (e.g. SST26VF064BEUI) as NVMEM cells, so that network drivers
+ can use them as a MAC address.
+
+ If unsure, say N.
+
config NVMEM_LAYOUT_U_BOOT_ENV
tristate "U-Boot environment variables layout"
select CRC32
diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile
index 4940c9db0665..b99eac1f63f2 100644
--- a/drivers/nvmem/layouts/Makefile
+++ b/drivers/nvmem/layouts/Makefile
@@ -5,4 +5,5 @@
obj-$(CONFIG_NVMEM_LAYOUT_SL28_VPD) += sl28vpd.o
obj-$(CONFIG_NVMEM_LAYOUT_ONIE_TLV) += onie-tlv.o
+obj-$(CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI) += sst26vf-sfdp-eui.o
obj-$(CONFIG_NVMEM_LAYOUT_U_BOOT_ENV) += u-boot-env.o
diff --git a/drivers/nvmem/layouts/sst26vf-sfdp-eui.c b/drivers/nvmem/layouts/sst26vf-sfdp-eui.c
new file mode 100644
index 000000000000..641318d6f0af
--- /dev/null
+++ b/drivers/nvmem/layouts/sst26vf-sfdp-eui.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NVMEM layout for the factory-programmed EUI-48 identifier stored in the
+ * Microchip/SST vendor-specific SFDP parameter table (e.g. SST26VF064BEUI).
+ *
+ * The whole SFDP is exposed as a read-only NVMEM device by the SPI NOR core.
+ * This layout locates the Microchip vendor parameter table at runtime and
+ * registers the EUI-48 address as an NVMEM cell, so that a network driver can
+ * consume it as a MAC address. No offset is hardcoded in the device tree.
+ *
+ * Copyright (C) 2026 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan <manikandan.m@microchip.com>
+ */
+
+#include <linux/etherdevice.h>
+#include <linux/minmax.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/unaligned.h>
+#include <uapi/linux/if_ether.h>
+
+/* SFDP header and parameter header, as laid out on the flash. */
+struct sfdp_header {
+ u8 signature[4];
+ u8 minor;
+ u8 major;
+ u8 nph;
+ u8 unused;
+};
+
+struct sfdp_parameter_header {
+ u8 id_lsb;
+ u8 minor;
+ u8 major;
+ u8 length;
+ u8 parameter_table_pointer[3];
+ u8 id_msb;
+};
+
+#define SFDP_SIGNATURE 0x50444653U
+
+#define SFDP_PARAM_HEADER_ID(h) (((h)->id_msb << 8) | (h)->id_lsb)
+#define SFDP_PARAM_HEADER_PTP(h) get_unaligned_le24((h)->parameter_table_pointer)
+
+/* Microchip (vendor) parameter table identifier: id_msb << 8 | id_lsb. */
+#define SFDP_MCHP_VENDOR_ID 0x01bf
+
+#define SFDP_MCHP_EUI48_MARKER_OFFSET 0x60
+#define SFDP_MCHP_EUI48_MARKER 0x30
+#define SFDP_MCHP_EUI48_OFFSET 0x61
+
+static int sfdp_eui_read_post_process(void *priv, const char *id, int index,
+ unsigned int offset, void *buf,
+ size_t bytes)
+{
+ u8 *data = buf;
+ int i;
+
+ /* SFDP stores the address least-significant octet first; reverse it. */
+ for (i = 0; i < bytes / 2; i++)
+ swap(data[i], data[bytes - 1 - i]);
+
+ if (bytes == ETH_ALEN && !is_valid_ether_addr(buf))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int sfdp_eui_find_vendor_table(struct nvmem_device *nvmem, u32 *ptp)
+{
+ struct sfdp_parameter_header ph;
+ struct sfdp_header hdr;
+ int nph, i, ret;
+
+ ret = nvmem_device_read(nvmem, 0, sizeof(hdr), &hdr);
+ if (ret < 0)
+ return ret;
+
+ if (get_unaligned_le32(hdr.signature) != SFDP_SIGNATURE)
+ return -EINVAL;
+
+ /* The number of parameter headers (NPH) field is zero-based. */
+ nph = hdr.nph;
+
+ for (i = 0; i <= nph; i++) {
+ ret = nvmem_device_read(nvmem, sizeof(hdr) + i * sizeof(ph),
+ sizeof(ph), &ph);
+ if (ret < 0)
+ return ret;
+
+ if (SFDP_PARAM_HEADER_ID(&ph) != SFDP_MCHP_VENDOR_ID)
+ continue;
+
+ *ptp = SFDP_PARAM_HEADER_PTP(&ph);
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
+static int sfdp_eui_add_cells(struct nvmem_layout *layout)
+{
+ struct nvmem_device *nvmem = layout->nvmem;
+ struct device *dev = &layout->dev;
+ struct nvmem_cell_info info = { };
+ struct device_node *layout_np;
+ u32 base = 0;
+ u8 marker;
+ int ret;
+
+ ret = sfdp_eui_find_vendor_table(nvmem, &base);
+ if (ret == -ENOENT) {
+ dev_dbg(dev, "no Microchip SFDP vendor table found\n");
+ return 0;
+ }
+ if (ret)
+ return ret;
+
+ /* The EUI-48 is present only if its marker byte is programmed. */
+ ret = nvmem_device_read(nvmem, base + SFDP_MCHP_EUI48_MARKER_OFFSET,
+ 1, &marker);
+ if (ret < 0)
+ return ret;
+ if (marker != SFDP_MCHP_EUI48_MARKER) {
+ dev_dbg(dev, "EUI-48 not programmed (marker 0x%02x)\n", marker);
+ return 0;
+ }
+
+ layout_np = of_nvmem_layout_get_container(nvmem);
+ if (!layout_np)
+ return -ENOENT;
+
+ info.name = "mac-address";
+ info.offset = base + SFDP_MCHP_EUI48_OFFSET;
+ info.bytes = ETH_ALEN;
+ info.np = of_get_child_by_name(layout_np, "mac-address");
+ info.read_post_process = sfdp_eui_read_post_process;
+
+ ret = nvmem_add_one_cell(nvmem, &info);
+ if (ret)
+ of_node_put(info.np);
+ else
+ dev_dbg(dev, "exposed EUI-48 at SFDP offset 0x%x\n", info.offset);
+
+ of_node_put(layout_np);
+
+ return ret;
+}
+
+static int sfdp_eui_probe(struct nvmem_layout *layout)
+{
+ layout->add_cells = sfdp_eui_add_cells;
+
+ return nvmem_layout_register(layout);
+}
+
+static void sfdp_eui_remove(struct nvmem_layout *layout)
+{
+ nvmem_layout_unregister(layout);
+}
+
+static const struct of_device_id sfdp_eui_of_match_table[] = {
+ { .compatible = "microchip,sst26vf-sfdp-eui" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sfdp_eui_of_match_table);
+
+static struct nvmem_layout_driver sfdp_eui_layout = {
+ .driver = {
+ .name = "microchip-sst26vf-sfdp-eui-layout",
+ .of_match_table = sfdp_eui_of_match_table,
+ },
+ .probe = sfdp_eui_probe,
+ .remove = sfdp_eui_remove,
+};
+module_nvmem_layout_driver(sfdp_eui_layout);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Manikandan Muralidharan <manikandan.m@microchip.com>");
+MODULE_DESCRIPTION("NVMEM layout for the EUI-48 in the Microchip/SST SFDP vendor table");
--
2.43.0
^ permalink raw reply related
* [PATCH v5 5/7] ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI flash
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Move the QSPI flash partitions under a "partitions" node with the
"fixed-partitions" compatible, as required by the current MTD partition
binding, instead of declaring them as direct children of the flash node.
No functional change.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
.../dts/microchip/at91-sama5d27_wlsom1.dtsi | 52 +++++++++++--------
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 0417f53b3e96..062aa02a98ed 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -240,34 +240,40 @@ qspi1_flash: flash@0 {
m25p,fast-read;
status = "disabled";
- at91bootstrap@0 {
- label = "at91bootstrap";
- reg = <0x0 0x40000>;
- };
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
- bootloader@40000 {
- label = "bootloader";
- reg = <0x40000 0xc0000>;
- };
+ bootloader@40000 {
+ label = "bootloader";
+ reg = <0x40000 0xc0000>;
+ };
- bootloaderenvred@100000 {
- label = "bootloader env redundant";
- reg = <0x100000 0x40000>;
- };
+ bootloaderenvred@100000 {
+ label = "bootloader env redundant";
+ reg = <0x100000 0x40000>;
+ };
- bootloaderenv@140000 {
- label = "bootloader env";
- reg = <0x140000 0x40000>;
- };
+ bootloaderenv@140000 {
+ label = "bootloader env";
+ reg = <0x140000 0x40000>;
+ };
- dtb@180000 {
- label = "device tree";
- reg = <0x180000 0x80000>;
- };
+ dtb@180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
- kernel@200000 {
- label = "kernel";
- reg = <0x200000 0x600000>;
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
};
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 6/7] ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Describe the QSPI flash SFDP as an NVMEM provider with the
microchip,sst26vf-sfdp-eui layout, which exposes the factory-programmed
EUI-48 as a "mac-address" cell, and point macb0 at it through
nvmem-cells. This yields a stable MAC address on boards where U-Boot does
not program one, instead of falling back to a random address.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi | 11 +++++++++++
.../boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts | 2 ++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 062aa02a98ed..6016d7f2a39c 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -240,6 +240,17 @@ qspi1_flash: flash@0 {
m25p,fast-read;
status = "disabled";
+ sfdp {
+ compatible = "jedec,sfdp";
+
+ nvmem-layout {
+ compatible = "microchip,sst26vf-sfdp-eui";
+
+ mac_address_eui48: mac-address {
+ };
+ };
+ };
+
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
index 35a933eec573..5e87bf04bc47 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
@@ -97,6 +97,8 @@ uart6: serial@200 {
&macb0 {
status = "okay";
+ nvmem-cells = <&mac_address_eui48>;
+ nvmem-cell-names = "mac-address";
};
&pioA {
--
2.43.0
^ permalink raw reply related
* [PATCH v5 7/7] ARM: configs: sama5: enable Microchip/SST SFDP EUI NVMEM layout
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Enable CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI so the factory EUI-48 stored
in the SST26VF QSPI flash SFDP can be used as a MAC address on boards
such as the sama5d27_wlsom1.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/configs/sama5_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index bd7f0b5f7d66..14dda4b0cfd0 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -220,6 +220,7 @@ CONFIG_PWM=y
CONFIG_PWM_ATMEL=y
CONFIG_PWM_ATMEL_HLCDC_PWM=y
CONFIG_PWM_ATMEL_TCB=y
+CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI=y
CONFIG_EXT4_FS=y
CONFIG_FANOTIFY=y
CONFIG_AUTOFS_FS=m
--
2.43.0
^ permalink raw reply related
* RE: [PATCH RESEND v4 net-next 07/14] net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC
From: Wei Fang (OSS) @ 2026-07-21 5:46 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: imx@lists.linux.dev, Frank.Li@kernel.org, network dev
In-Reply-To: <20260721021331.6E5DD1F00A3A@smtp.kernel.org>
> [ ... ]
> > @@ -400,25 +401,42 @@ int enetc_phylink_create(struct enetc_ndev_priv
> *priv, struct device_node *node,
> > {
> [ ... ]
> > + if (!is_enetc_rev1(priv->si)) {
> > + mac_caps |= MAC_5000FD | MAC_10000FD;
> > + __set_bit(PHY_INTERFACE_MODE_10GBASER,
> > + pf->phylink_config.supported_interfaces);
> > + }
>
> [Severity: High]
> The commit message explicitly states that 10GBASE-R mode is not supported yet
> and is added simply as preparation.
>
> Will advertising an unsupported interface mode to phylink in
> enetc_phylink_create() cause it to accept configurations for it, leading to a
> broken configuration state or a hard probe failure when it attempts to
> configure the MAC and PCS?
>
As the commit message stated, this is simply preparation for 10GBASER mode.
The probe should fail if the phy-mode is set to "10gbase-r", which is a normal
behavior. No fixed are needed to be fixed for this.
^ permalink raw reply
* RE: [PATCH RESEND v4 net-next 13/14] net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver
From: Wei Fang (OSS) @ 2026-07-21 5:54 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: Frank.Li@kernel.org, imx@lists.linux.dev, network dev
In-Reply-To: <20260721021332.C1B431F000E9@smtp.kernel.org>
> > - ndev = alloc_etherdev_mq(sizeof(*priv), ENETC_MAX_NUM_TXQS);
> > + /* Currently, the supported SoCs have a max of 6 CPUs and the VFs
> > + * have less than 6 RX/TX rings. So no issues for these supported
> > + * SoCs, but for future SoCs which have more CPUs or more TX/RX
> > + * rings, all the related logic needs to be improved.
> > + */
> > + ndev = alloc_etherdev_mqs(sizeof(*priv),
> > + min(si->num_tx_rings, ENETC_MAX_NUM_TXQS),
> > + min(si->num_rx_rings, ENETC_MAX_NUM_TXQS));
>
> [Severity: Low]
> Does this code handle the case where the hardware reports 0 rings?
>
The number of rings cannot be zero; if it is, then it's a severe bug.
> If si->num_tx_rings or si->num_rx_rings is 0, this passes 0 to
> alloc_etherdev_mqs(), which triggers a "Unable to allocate device with zero
> queues" pr_err() in the network core and returns NULL. The previous hardcoded
> ENETC_MAX_NUM_TXQS guaranteed a valid count.
>
> Should there be a check to ensure the ring counts are at least 1?
^ permalink raw reply
* Re: [PATCH v5 1/3] drm/drm_ras: Add drm_ras netlink error event
From: Raag Jadav @ 2026-07-21 6:02 UTC (permalink / raw)
To: Riana Tauro
Cc: intel-xe, dri-devel, netdev, aravind.iddamsetty, anshuman.gupta,
rodrigo.vivi, joonas.lahtinen, kuba, simona.vetter, airlied,
pratik.bari, joshua.santosh.ranjan, ashwin.kumar.kulkarni,
shubham.kumar, ravi.kishore.koppuravuri, maarten.lankhorst,
mallesh.koujalagi, soham.purkait, Zack McKevitt, Lijo Lazar,
Hawking Zhang, David S. Miller, Paolo Abeni, Eric Dumazet
In-Reply-To: <20260720082208.2648279-6-riana.tauro@intel.com>
On Mon, Jul 20, 2026 at 01:52:10PM +0530, Riana Tauro wrote:
> Define a new netlink event 'error-event' and a new multicast group
> 'error-report' in drm_ras. Each event contains device name, node and
> error information to identify the error triggering the event.
>
> Add drm_ras_nl_error_event() to trigger an event from the driver.
> Userspace must subscribe to 'error-report' to receive 'error-event'
> notifications.
...
> v4: send event to all network namespaces (Sashiko)
> remove has_listeners check
Curious, is it possible to have a has_listeners() that covers all
namespaces?
Raag
^ permalink raw reply
* Re: [PATCH v5 1/3] drm/drm_ras: Add drm_ras netlink error event
From: Tauro, Riana @ 2026-07-21 6:19 UTC (permalink / raw)
To: Raag Jadav
Cc: intel-xe, dri-devel, netdev, aravind.iddamsetty, anshuman.gupta,
rodrigo.vivi, joonas.lahtinen, kuba, simona.vetter, airlied,
pratik.bari, joshua.santosh.ranjan, ashwin.kumar.kulkarni,
shubham.kumar, ravi.kishore.koppuravuri, maarten.lankhorst,
mallesh.koujalagi, soham.purkait, Zack McKevitt, Lijo Lazar,
Hawking Zhang, David S. Miller, Paolo Abeni, Eric Dumazet
In-Reply-To: <al8LkE_elgQCxcXk@black.igk.intel.com>
On 21-07-2026 11:32, Raag Jadav wrote:
> On Mon, Jul 20, 2026 at 01:52:10PM +0530, Riana Tauro wrote:
>> Define a new netlink event 'error-event' and a new multicast group
>> 'error-report' in drm_ras. Each event contains device name, node and
>> error information to identify the error triggering the event.
>>
>> Add drm_ras_nl_error_event() to trigger an event from the driver.
>> Userspace must subscribe to 'error-report' to receive 'error-event'
>> notifications.
> ...
>
>> v4: send event to all network namespaces (Sashiko)
>> remove has_listeners check
> Curious, is it possible to have a has_listeners() that covers all
> namespaces?
We can do this. But this is already done in multicast function. This
will be a bigger overhead
just to avoid overhead of creating a new message in error path
Thanks
Riana
>
> Raag
^ permalink raw reply
* Re: [PATCH net-next] net: Convert %pK back to %p
From: Sebastian Andrzej Siewior @ 2026-07-21 6:20 UTC (permalink / raw)
To: Jakub Kicinski
Cc: linux-atm-general, linux-can, linux-sctp, netdev, David S. Miller,
Eric Dumazet, Herbert Xu, Kuniyuki Iwashima, Marc Kleine-Budde,
Marcelo Ricardo Leitner, Neal Cardwell, Oliver Hartkopp,
Paolo Abeni, Remi Denis-Courmont, Simon Horman, Steffen Klassert,
Willem de Bruijn, Xin Long, Petr Mladek, Thomas Weißschuh,
Kees Cook
In-Reply-To: <20260720173926.766b2ddd@kernel.org>
On 2026-07-20 17:39:26 [-0700], Jakub Kicinski wrote:
> The netdev patch queue has overflown.
> If these patches are still relevant you'll have to repost them.
There was no other feedback and I posted an updated version based on
Kees' suggestion (yesterday).
https://lore.kernel.org/all/20260720144031.oU6azheV@linutronix.de/
Sebastian
^ permalink raw reply
* [PATCH net] mlxsw: pci: Quiesce EQ tasklet and CQ NAPI before teardown
From: Myeonghun Pak @ 2026-07-21 6:21 UTC (permalink / raw)
To: Ido Schimmel, Petr Machata
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev, linux-kernel, Myeonghun Pak, Ijae Kim
mlxsw_pci_eq_irq_handler() schedules the EQ tasklet. The tasklet reads
the EQ ring and schedules CQ NAPI instances. The CQ poll callbacks, in
turn, dereference the RDQ or SDQ associated with the CQ.
mlxsw_pci_fini() unregisters the IRQ and immediately tears down the
asynchronous queues in RDQ, SDQ, CQ, EQ order. free_irq() waits for IRQ
handlers, but not for a tasklet already scheduled by one. In addition,
mlxsw_pci_cq_fini() disables each CQ NAPI only after all RDQs and SDQs
have been freed. A pending tasklet or NAPI poll can therefore access
freed queue storage.
Kill the EQ tasklet after free_irq() so it cannot schedule any more CQ
NAPI instances. Disable all CQ NAPI instances before freeing the first
descriptor queue, ensuring their poll callbacks have completed. Track
the enabled state per CQ to avoid disabling a NAPI instance twice when
the CQ is later destroyed, while preserving the partial initialization
unwind.
Fixes: eda6500a987a ("mlxsw: Add PCI bus implementation")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
Found by static analysis on v7.2-rc2; not tested on hardware.
drivers/net/ethernet/mellanox/mlxsw/pci.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index 0da85d36647d..feeb32134d2a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -86,6 +86,7 @@ struct mlxsw_pci_queue {
enum mlxsw_pci_cqe_v v;
struct mlxsw_pci_queue *dq;
struct napi_struct napi;
+ bool napi_enabled;
struct page_pool *page_pool;
} cq;
struct {
@@ -989,6 +990,15 @@ static void mlxsw_pci_cq_napi_teardown(struct mlxsw_pci_queue *q)
netif_napi_del(&q->u.cq.napi);
}
+static void mlxsw_pci_cq_napi_disable(struct mlxsw_pci_queue *q)
+{
+ if (!q->u.cq.napi_enabled)
+ return;
+
+ napi_disable(&q->u.cq.napi);
+ q->u.cq.napi_enabled = false;
+}
+
static int mlxsw_pci_cq_page_pool_init(struct mlxsw_pci_queue *q,
enum mlxsw_pci_cq_type cq_type)
{
@@ -1064,6 +1074,7 @@ static int mlxsw_pci_cq_init(struct mlxsw_pci *mlxsw_pci, char *mbox,
goto err_page_pool_init;
napi_enable(&q->u.cq.napi);
+ q->u.cq.napi_enabled = truea
mlxsw_pci_queue_doorbell_consumer_ring(mlxsw_pci, q);
mlxsw_pci_queue_doorbell_arm_consumer_ring(mlxsw_pci, q);
return 0;
@@ -1078,7 +1089,7 @@ static void mlxsw_pci_cq_fini(struct mlxsw_pci *mlxsw_pci,
{
enum mlxsw_pci_cq_type cq_type = mlxsw_pci_cq_type(mlxsw_pci, q);
- napi_disable(&q->u.cq.napi);
+ mlxsw_pci_cq_napi_disable(q);
mlxsw_pci_cq_page_pool_fini(q, cq_type);
mlxsw_pci_cq_napi_teardown(q);
mlxsw_cmd_hw2sw_cq(mlxsw_pci->core, q->num);
@@ -1439,6 +1450,14 @@ err_cqs_init:
static void mlxsw_pci_aqs_fini(struct mlxsw_pci *mlxsw_pci)
{
+ struct mlxsw_pci_queue_type_group *queue_group;
+ int i;
+
+ queue_group = mlxsw_pci_queue_type_group_get(mlxsw_pci,
+ MLXSW_PCI_QUEUE_TYPE_CQ);
+ for (i = 0; i < queue_group->count; i++)
+ mlxsw_pci_cq_napi_disable(&queue_group->q[i]);
+
mlxsw_pci_queue_group_fini(mlxsw_pci, &mlxsw_pci_rdq_ops);
mlxsw_pci_queue_group_fini(mlxsw_pci, &mlxsw_pci_sdq_ops);
mlxsw_pci_queue_group_fini(mlxsw_pci, &mlxsw_pci_cq_ops);
@@ -2089,6 +2108,7 @@ static void mlxsw_pci_fini(void *bus_priv)
struct mlxsw_pci *mlxsw_pci = bus_priv;
free_irq(pci_irq_vector(mlxsw_pci->pdev, 0), mlxsw_pci);
+ tasklet_kill(&mlxsw_pci_eq_get(mlxsw_pci)->u.eq.tasklet);
mlxsw_pci_aqs_fini(mlxsw_pci);
mlxsw_pci_napi_devs_fini(mlxsw_pci);
mlxsw_pci_fw_area_fini(mlxsw_pci);
--
2.47.1
^ permalink raw reply related
* [PATCH v4 net] octeontx2-af: Block VFs from clobbering special CGX PKIND state
From: Ratheesh Kannoth @ 2026-07-21 6:29 UTC (permalink / raw)
To: davem, gakula, linux-kernel, netdev, sgoutham
Cc: andrew+netdev, edumazet, kuba, pabeni, Hariprasad Kelam,
Ratheesh Kannoth
From: Hariprasad Kelam <hkelam@marvell.com>
PF and VF NIX LFs that share a CGX LMAC reuse the same hardware PKIND
programming. When HiGig2 or EDSA parsing is enabled, a VF NIX LF alloc must
not reset the LMAC RX PKIND or default TX parse config over the PF setup.
Add cgx_get_pkind() and rvu_cgx_is_pkind_config_permitted() so VFs skip
cgx_set_pkind(), rvu_npc_set_pkind(), and NIX_AF_LFX_TX_PARSE_CFG updates
when the LMAC is using NPC_RX_HIGIG_PKIND or NPC_RX_EDSA_PKIND.
Fixes: 94d942c5fb97 ("octeontx2-af: Config pkind for CGX mapped PFs")
Cc: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
---
v2 -> v3: Addressed simon comments
https://lore.kernel.org/netdev/20260713121902.3938875-1-rkannoth@marvell.com/
v2 -> v3: Addressed simon comments
https://lore.kernel.org/netdev/20260709122648.1552103-2-horms@kernel.org/
v1 -> v2: Addressed simon comments
https://lore.kernel.org/netdev/20260619041002.1773822-1-rkannoth@marvell.com/
---
.../net/ethernet/marvell/octeontx2/af/cgx.c | 12 +++
.../net/ethernet/marvell/octeontx2/af/cgx.h | 1 +
.../net/ethernet/marvell/octeontx2/af/rvu.h | 2 +
.../ethernet/marvell/octeontx2/af/rvu_cgx.c | 79 +++++++++++++++++++
.../ethernet/marvell/octeontx2/af/rvu_nix.c | 23 ++++--
.../ethernet/marvell/octeontx2/af/rvu_npc.c | 29 ++++---
6 files changed, 131 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index 2e94d5105016..f5fd6138c352 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -518,6 +518,18 @@ int cgx_set_pkind(void *cgxd, u8 lmac_id, int pkind)
return 0;
}
+int cgx_get_pkind(void *cgxd, u8 lmac_id, int *pkind)
+{
+ struct cgx *cgx = cgxd;
+
+ if (!is_lmac_valid(cgx, lmac_id))
+ return -ENODEV;
+
+ *pkind = cgx_read(cgx, lmac_id, cgx->mac_ops->rxid_map_offset);
+ *pkind = *pkind & 0x3F;
+ return 0;
+}
+
static u8 cgx_get_lmac_type(void *cgxd, int lmac_id)
{
struct cgx *cgx = cgxd;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index 92ccf343dfe0..8411a75dd723 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -141,6 +141,7 @@ int cgx_get_cgxid(void *cgxd);
int cgx_get_lmac_cnt(void *cgxd);
void *cgx_get_pdata(int cgx_id);
int cgx_set_pkind(void *cgxd, u8 lmac_id, int pkind);
+int cgx_get_pkind(void *cgxd, u8 lmac_id, int *pkind);
int cgx_lmac_evh_register(struct cgx_event_cb *cb, void *cgxd, int lmac_id);
int cgx_lmac_evh_unregister(void *cgxd, int lmac_id);
int cgx_get_tx_stats(void *cgxd, int lmac_id, int idx, u64 *tx_stat);
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.h b/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
index 7f3505ae6860..9d5b7b51bdfa 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
@@ -1115,6 +1115,8 @@ void npc_read_mcam_entry(struct rvu *rvu, struct npc_mcam *mcam,
u8 *intf, u8 *ena);
int npc_config_cntr_default_entries(struct rvu *rvu, bool enable);
bool is_cgx_config_permitted(struct rvu *rvu, u16 pcifunc);
+bool rvu_cgx_check_permission_and_set_pkind(struct rvu *rvu, u16 pcifunc, int pkind);
+bool rvu_cgx_is_pkind_config_permitted(struct rvu *rvu, u16 pcifunc);
bool is_mac_feature_supported(struct rvu *rvu, int pf, int feature);
u32 rvu_cgx_get_fifolen(struct rvu *rvu);
void *rvu_first_cgx_pdata(struct rvu *rvu);
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
index 4ff3935ed3fe..87d21889dc49 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
@@ -1355,3 +1355,82 @@ void rvu_mac_reset(struct rvu *rvu, u16 pcifunc)
if (mac_ops->mac_reset(cgxd, lmac, !is_vf(pcifunc)))
dev_err(rvu->dev, "Failed to reset MAC\n");
}
+
+/* Do not allow CGX-mapped VFs to overwrite PKIND when special parse kinds
+ * (HiGig, EDSA, etc.) are in use on the shared LMAC. VFs must not program
+ * NPC_TX_DEF_PKIND on NIX_AF_LFX_TX_PARSE_CFG in that case: the PF owns
+ * parse mode and no separate NPC_TX_HIGIG_PKIND is installed on the VF LF.
+ * TX-parse callers skip the write when denied; rvu_lf_reset() clears each LF
+ * before alloc so the next permitted owner programs NPC_TX_DEF_PKIND.
+ */
+bool rvu_cgx_is_pkind_config_permitted(struct rvu *rvu, u16 pcifunc)
+{
+ int pf, err, rxpkind;
+ u8 cgx_id, lmac_id;
+ void *cgxd;
+
+ pf = rvu_get_pf(rvu->pdev, pcifunc);
+
+ if (!(pcifunc & RVU_PFVF_FUNC_MASK))
+ return true;
+
+ if (!is_pf_cgxmapped(rvu, pf))
+ return true;
+
+ rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
+ cgxd = rvu_cgx_pdata(cgx_id, rvu);
+ err = cgx_get_pkind(cgxd, lmac_id, &rxpkind);
+ if (err)
+ return false;
+
+ switch (rxpkind) {
+ case NPC_RX_HIGIG_PKIND:
+ case NPC_RX_EDSA_PKIND:
+ return false;
+ default:
+ return true;
+ }
+}
+
+/* Do not allow CGX-mapped VFs to overwrite PKIND when special parse kinds
+ * (HiGig, EDSA, etc.) are in use on the shared LMAC.
+ */
+bool rvu_cgx_check_permission_and_set_pkind(struct rvu *rvu, u16 pcifunc, int pkind)
+{
+ int pf, err, rxpkind;
+ u8 cgx_id, lmac_id;
+ struct cgx *cgxd;
+
+ pf = rvu_get_pf(rvu->pdev, pcifunc);
+
+ if (!is_pf_cgxmapped(rvu, pf))
+ return false;
+
+ rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
+ cgxd = rvu_cgx_pdata(cgx_id, rvu);
+
+ mutex_lock(&cgxd->lock);
+ if (!is_vf(pcifunc))
+ goto set;
+
+ err = cgx_get_pkind(cgxd, lmac_id, &rxpkind);
+ if (err)
+ goto err;
+
+ switch (rxpkind) {
+ case NPC_RX_HIGIG_PKIND:
+ case NPC_RX_EDSA_PKIND:
+ goto err;
+ default:
+ break;
+ }
+
+set:
+ cgx_set_pkind(rvu_cgx_pdata(cgx_id, rvu), lmac_id, pkind);
+ mutex_unlock(&cgxd->lock);
+ return true;
+
+err:
+ mutex_unlock(&cgxd->lock);
+ return false;
+}
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
index 6a0ce2665031..d1de9c9894bd 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
@@ -363,8 +363,8 @@ static int nix_interface_init(struct rvu *rvu, u16 pcifunc, int type, int nixlf,
pfvf->tx_chan_cnt = 1;
rsp->tx_link = cgx_id * hw->lmac_per_cgx + lmac_id;
- cgx_set_pkind(rvu_cgx_pdata(cgx_id, rvu), lmac_id, pkind);
- rvu_npc_set_pkind(rvu, pkind, pfvf);
+ if (rvu_cgx_check_permission_and_set_pkind(rvu, pcifunc, pkind))
+ rvu_npc_set_pkind(rvu, pkind, pfvf);
break;
case NIX_INTF_TYPE_LBK:
vf = (pcifunc & RVU_PFVF_FUNC_MASK) - 1;
@@ -1505,13 +1505,15 @@ int rvu_mbox_handler_nix_lf_alloc(struct rvu *rvu,
struct nix_lf_alloc_req *req,
struct nix_lf_alloc_rsp *rsp)
{
- int nixlf, qints, hwctx_size, intf, rc = 0;
+ int nixlf, qints, hwctx_size, intf, rc = 0, pf;
u16 bcast, mcast, promisc, ucast;
struct rvu_hwinfo *hw = rvu->hw;
u16 pcifunc = req->hdr.pcifunc;
+ u8 cgx_id = 0, lmac_id = 0;
bool rules_created = false;
struct rvu_block *block;
struct rvu_pfvf *pfvf;
+ struct cgx *cgxd;
u64 cfg, ctx_cfg;
int blkaddr;
@@ -1685,8 +1687,19 @@ int rvu_mbox_handler_nix_lf_alloc(struct rvu *rvu,
rvu_write64(rvu, blkaddr, NIX_AF_LFX_RX_CFG(nixlf), req->rx_cfg);
/* Configure pkind for TX parse config */
- cfg = NPC_TX_DEF_PKIND;
- rvu_write64(rvu, blkaddr, NIX_AF_LFX_TX_PARSE_CFG(nixlf), cfg);
+
+ pf = rvu_get_pf(rvu->pdev, pcifunc);
+
+ if (is_pf_cgxmapped(rvu, pf)) {
+ rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
+ cgxd = rvu_cgx_pdata(cgx_id, rvu);
+ mutex_lock(&cgxd->lock);
+ if (rvu_cgx_is_pkind_config_permitted(rvu, pcifunc)) {
+ cfg = NPC_TX_DEF_PKIND;
+ rvu_write64(rvu, blkaddr, NIX_AF_LFX_TX_PARSE_CFG(nixlf), cfg);
+ }
+ mutex_unlock(&cgxd->lock);
+ }
if (is_rep_dev(rvu, pcifunc)) {
pfvf->tx_chan_base = RVU_SWITCH_LBK_CHAN;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
index c7bc0b3a29b9..38554d51164e 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
@@ -19,6 +19,7 @@
#include "cn20k/npc.h"
#include "rvu_npc.h"
#include "cn20k/reg.h"
+#include "lmac_common.h"
#define RSVD_MCAM_ENTRIES_PER_PF 3 /* Broadcast, Promisc and AllMulticast */
#define RSVD_MCAM_ENTRIES_PER_NIXLF 1 /* Ucast for LFs */
@@ -4200,10 +4201,11 @@ int rvu_npc_set_parse_mode(struct rvu *rvu, u16 pcifunc, u64 mode, u8 dir,
{
struct rvu_pfvf *pfvf = rvu_get_pfvf(rvu, pcifunc);
- int blkaddr, nixlf, rc, intf_mode;
int pf = rvu_get_pf(rvu->pdev, pcifunc);
+ int blkaddr, nixlf, rc, intf_mode;
+ u8 cgx_id = 0, lmac_id = 0;
u64 rxpkind, txpkind;
- u8 cgx_id, lmac_id;
+ struct cgx *cgxd;
/* use default pkind to disable edsa/higig */
rxpkind = rvu_npc_get_pkind(rvu, pf);
@@ -4227,12 +4229,8 @@ int rvu_npc_set_parse_mode(struct rvu *rvu, u16 pcifunc, u64 mode, u8 dir,
/* rx pkind set req valid only for cgx mapped PFs */
if (!is_cgx_config_permitted(rvu, pcifunc))
return 0;
- rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
-
- rc = cgx_set_pkind(rvu_cgx_pdata(cgx_id, rvu), lmac_id,
- rxpkind);
- if (rc)
- return rc;
+ if (!rvu_cgx_check_permission_and_set_pkind(rvu, pcifunc, rxpkind))
+ return -EINVAL;
}
if (dir & PKIND_TX) {
@@ -4241,8 +4239,19 @@ int rvu_npc_set_parse_mode(struct rvu *rvu, u16 pcifunc, u64 mode, u8 dir,
if (rc)
return rc;
- rvu_write64(rvu, blkaddr, NIX_AF_LFX_TX_PARSE_CFG(nixlf),
- txpkind);
+ if (is_pf_cgxmapped(rvu, pf) && is_vf(pcifunc)) {
+ rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id,
+ &lmac_id);
+ cgxd = rvu_cgx_pdata(cgx_id, rvu);
+ mutex_lock(&cgxd->lock);
+ if (rvu_cgx_is_pkind_config_permitted(rvu, pcifunc))
+ rvu_write64(rvu, blkaddr, NIX_AF_LFX_TX_PARSE_CFG(nixlf),
+ txpkind);
+ mutex_unlock(&cgxd->lock);
+ } else {
+ rvu_write64(rvu, blkaddr, NIX_AF_LFX_TX_PARSE_CFG(nixlf),
+ txpkind);
+ }
}
pfvf->intf_mode = intf_mode;
--
2.43.0
^ permalink raw reply related
* [PATCH net v3] bnge/bng_re: fix ring ID widths
From: Vikas Gupta @ 2026-07-21 6:37 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, andrew+netdev, horms
Cc: netdev, linux-kernel, linux-rdma, leonro, jgg, bhargava.marreddy,
rahul-rg.gupta, vsrama-krishna.nemani, rajashekar.hudumula,
ajit.khaparde, Vikas Gupta, Siva Reddy Kallam, Dharmender Garg,
Yendapally Reddy Dhananjaya Reddy
Firmware requires more than 16 bits to address TX ring IDs for its
internal QP management. Widen the associated HSI ring ID fields to
32 bits. The values firmware assigns remain within 24 bits, bounded
by the hardware doorbell XID field.
The fw_ring_id field belongs to bnge_ring_struct, a common struct
shared by all ring types, so widening it to u32 applies uniformly
across TX, RX, CP, and NQ rings but firmware assigns values within
16-bit range for all ring types except TX, which requires the wider
field.
Note that, Thor Ultra hardware has not yet been deployed and no
firmware has been released to field, so backward compatibility
is not a concern.
Fixes: 42d1c54d6248 ("bnge/bng_re: Add a new HSI")
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Reviewed-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
v3:
- Updated commit message as suggested by Przemek Kitszel.
https://lore.kernel.org/netdev/73e4895c-4d07-4841-92eb-2bcb61ca4d38@intel.com/
No code change in this version.
v2:
Sashiko review:
- Updated commit message only, no code change.
- Sashiko's concern about XID overflow is valid in theory but is
handled by firmware, which guarantees TX ring IDs stay within the
24-bit hardware doorbell XID field.
- Backward compatibility with older firmware is not a concern.
drivers/infiniband/hw/bng_re/bng_dev.c | 6 +--
drivers/net/ethernet/broadcom/bnge/bnge.h | 1 +
.../ethernet/broadcom/bnge/bnge_hwrm_lib.c | 8 +--
.../ethernet/broadcom/bnge/bnge_hwrm_lib.h | 2 +-
.../net/ethernet/broadcom/bnge/bnge_netdev.c | 50 +++++++++----------
.../net/ethernet/broadcom/bnge/bnge_netdev.h | 4 +-
.../net/ethernet/broadcom/bnge/bnge_rmem.h | 2 +-
include/linux/bnge/hsi.h | 7 ++-
8 files changed, 39 insertions(+), 41 deletions(-)
diff --git a/drivers/infiniband/hw/bng_re/bng_dev.c b/drivers/infiniband/hw/bng_re/bng_dev.c
index 71a7ca2196ad..311c8bc93160 100644
--- a/drivers/infiniband/hw/bng_re/bng_dev.c
+++ b/drivers/infiniband/hw/bng_re/bng_dev.c
@@ -113,7 +113,7 @@ static void bng_re_fill_fw_msg(struct bnge_fw_msg *fw_msg, void *msg,
}
static int bng_re_net_ring_free(struct bng_re_dev *rdev,
- u16 fw_ring_id, int type)
+ u32 fw_ring_id, int type)
{
struct bnge_auxr_dev *aux_dev = rdev->aux_dev;
struct hwrm_ring_free_input req = {};
@@ -123,7 +123,7 @@ static int bng_re_net_ring_free(struct bng_re_dev *rdev,
bng_re_init_hwrm_hdr((void *)&req, HWRM_RING_FREE);
req.ring_type = type;
- req.ring_id = cpu_to_le16(fw_ring_id);
+ req.ring_id = cpu_to_le32(fw_ring_id);
bng_re_fill_fw_msg(&fw_msg, (void *)&req, sizeof(req), (void *)&resp,
sizeof(resp), BNGE_DFLT_HWRM_CMD_TIMEOUT);
rc = bnge_send_msg(aux_dev, &fw_msg);
@@ -161,7 +161,7 @@ static int bng_re_net_ring_alloc(struct bng_re_dev *rdev,
sizeof(resp), BNGE_DFLT_HWRM_CMD_TIMEOUT);
rc = bnge_send_msg(aux_dev, &fw_msg);
if (!rc)
- *fw_ring_id = le16_to_cpu(resp.ring_id);
+ *fw_ring_id = (u16)le32_to_cpu(resp.ring_id);
return rc;
}
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge.h b/drivers/net/ethernet/broadcom/bnge/bnge.h
index f21cff651fd4..4479ccd071f5 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge.h
+++ b/drivers/net/ethernet/broadcom/bnge/bnge.h
@@ -36,6 +36,7 @@ struct bnge_pf_info {
};
#define INVALID_HW_RING_ID ((u16)-1)
+#define INVALID_HW_RING_ID_32BIT (U32_MAX)
enum {
BNGE_FW_CAP_SHORT_CMD = BIT_ULL(0),
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c
index 1c9cfec1b633..651c5e783516 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c
@@ -1283,7 +1283,7 @@ int bnge_hwrm_stat_ctx_alloc(struct bnge_net *bn)
int hwrm_ring_free_send_msg(struct bnge_net *bn,
struct bnge_ring_struct *ring,
- u32 ring_type, int cmpl_ring_id)
+ u32 ring_type, u32 cmpl_ring_id)
{
struct hwrm_ring_free_input *req;
struct bnge_dev *bd = bn->bd;
@@ -1295,7 +1295,7 @@ int hwrm_ring_free_send_msg(struct bnge_net *bn,
req->cmpl_ring = cpu_to_le16(cmpl_ring_id);
req->ring_type = ring_type;
- req->ring_id = cpu_to_le16(ring->fw_ring_id);
+ req->ring_id = cpu_to_le32(ring->fw_ring_id);
bnge_hwrm_req_hold(bd, req);
rc = bnge_hwrm_req_send(bd, req);
@@ -1317,7 +1317,7 @@ int hwrm_ring_alloc_send_msg(struct bnge_net *bn,
struct hwrm_ring_alloc_output *resp;
struct hwrm_ring_alloc_input *req;
struct bnge_dev *bd = bn->bd;
- u16 ring_id, flags = 0;
+ u32 ring_id, flags = 0;
int rc;
rc = bnge_hwrm_req_init(bd, req, HWRM_RING_ALLOC);
@@ -1401,7 +1401,7 @@ int hwrm_ring_alloc_send_msg(struct bnge_net *bn,
resp = bnge_hwrm_req_hold(bd, req);
rc = bnge_hwrm_req_send(bd, req);
- ring_id = le16_to_cpu(resp->ring_id);
+ ring_id = le32_to_cpu(resp->ring_id);
bnge_hwrm_req_drop(bd, req);
exit:
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.h b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.h
index 3501de7a89b9..bf452e390d5b 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.h
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.h
@@ -50,7 +50,7 @@ int bnge_hwrm_cfa_l2_set_rx_mask(struct bnge_dev *bd,
void bnge_hwrm_stat_ctx_free(struct bnge_net *bn);
int bnge_hwrm_stat_ctx_alloc(struct bnge_net *bn);
int hwrm_ring_free_send_msg(struct bnge_net *bn, struct bnge_ring_struct *ring,
- u32 ring_type, int cmpl_ring_id);
+ u32 ring_type, u32 cmpl_ring_id);
int hwrm_ring_alloc_send_msg(struct bnge_net *bn,
struct bnge_ring_struct *ring,
u32 ring_type, u32 map_index);
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
index 70768193004c..6f7ef506d4e1 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
@@ -1327,12 +1327,12 @@ static int bnge_alloc_core(struct bnge_net *bn)
return rc;
}
-u16 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr)
+u32 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr)
{
return rxr->rx_cpr->ring_struct.fw_ring_id;
}
-u16 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr)
+u32 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr)
{
return txr->tx_cpr->ring_struct.fw_ring_id;
}
@@ -1375,12 +1375,12 @@ static void bnge_init_nq_tree(struct bnge_net *bn)
struct bnge_nq_ring_info *nqr = &bn->bnapi[i]->nq_ring;
struct bnge_ring_struct *ring = &nqr->ring_struct;
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
for (j = 0; j < nqr->cp_ring_count; j++) {
struct bnge_cp_ring_info *cpr = &nqr->cp_ring_arr[j];
ring = &cpr->ring_struct;
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
}
}
}
@@ -1637,7 +1637,7 @@ static void bnge_init_one_rx_ring_rxbd(struct bnge_net *bn,
ring = &rxr->rx_ring_struct;
bnge_init_rxbd_pages(ring, type);
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
}
static void bnge_init_one_agg_ring_rxbd(struct bnge_net *bn,
@@ -1647,7 +1647,7 @@ static void bnge_init_one_agg_ring_rxbd(struct bnge_net *bn,
u32 type;
ring = &rxr->rx_agg_ring_struct;
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
if (bnge_is_agg_reqd(bn->bd)) {
type = ((u32)BNGE_RX_PAGE_SIZE << RX_BD_LEN_SHIFT) |
RX_BD_TYPE_RX_AGG_BD | RX_BD_FLAGS_SOP;
@@ -1708,7 +1708,7 @@ static void bnge_init_tx_rings(struct bnge_net *bn)
struct bnge_tx_ring_info *txr = &bn->tx_ring[i];
struct bnge_ring_struct *ring = &txr->tx_ring_struct;
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
netif_queue_set_napi(bn->netdev, i, NETDEV_QUEUE_TYPE_TX,
&txr->bnapi->napi);
@@ -1867,7 +1867,7 @@ static int bnge_hwrm_rx_agg_ring_alloc(struct bnge_net *bn,
ring->fw_ring_id);
bnge_db_write(bn->bd, &rxr->rx_agg_db, rxr->rx_agg_prod);
bnge_db_write(bn->bd, &rxr->rx_db, rxr->rx_prod);
- bn->grp_info[grp_idx].agg_fw_ring_id = ring->fw_ring_id;
+ bn->grp_info[grp_idx].agg_fw_ring_id = (u16)ring->fw_ring_id;
return 0;
}
@@ -1886,7 +1886,7 @@ static int bnge_hwrm_rx_ring_alloc(struct bnge_net *bn,
return rc;
bnge_set_db(bn, &rxr->rx_db, type, map_idx, ring->fw_ring_id);
- bn->grp_info[map_idx].rx_fw_ring_id = ring->fw_ring_id;
+ bn->grp_info[map_idx].rx_fw_ring_id = (u16)ring->fw_ring_id;
return 0;
}
@@ -1916,7 +1916,7 @@ static int bnge_hwrm_ring_alloc(struct bnge_net *bn)
bnge_set_db(bn, &nqr->nq_db, type, map_idx, ring->fw_ring_id);
bnge_db_nq(bn, &nqr->nq_db, nqr->nq_raw_cons);
enable_irq(vector);
- bn->grp_info[i].nq_fw_ring_id = ring->fw_ring_id;
+ bn->grp_info[i].nq_fw_ring_id = (u16)ring->fw_ring_id;
if (!i) {
rc = bnge_hwrm_set_async_event_cr(bd, ring->fw_ring_id);
@@ -1986,15 +1986,13 @@ void bnge_fill_hw_rss_tbl(struct bnge_net *bn, struct bnge_vnic_info *vnic)
tbl_size = bnge_get_rxfh_indir_size(bd);
for (i = 0; i < tbl_size; i++) {
- u16 ring_id, j;
+ u32 j;
j = bd->rss_indir_tbl[i];
rxr = &bn->rx_ring[j];
- ring_id = rxr->rx_ring_struct.fw_ring_id;
- *ring_tbl++ = cpu_to_le16(ring_id);
- ring_id = bnge_cp_ring_for_rx(rxr);
- *ring_tbl++ = cpu_to_le16(ring_id);
+ *ring_tbl++ = cpu_to_le16(rxr->rx_ring_struct.fw_ring_id);
+ *ring_tbl++ = cpu_to_le16(bnge_cp_ring_for_rx(rxr));
}
}
@@ -2285,7 +2283,7 @@ static void bnge_disable_int(struct bnge_net *bn)
nqr = &bnapi->nq_ring;
ring = &nqr->ring_struct;
- if (ring->fw_ring_id != INVALID_HW_RING_ID)
+ if (ring->fw_ring_id != INVALID_HW_RING_ID_32BIT)
bnge_db_nq(bn, &nqr->nq_db, nqr->nq_raw_cons);
}
}
@@ -2401,7 +2399,7 @@ static void bnge_hwrm_rx_ring_free(struct bnge_net *bn,
u32 grp_idx = rxr->bnapi->index;
u32 cmpl_ring_id;
- if (ring->fw_ring_id == INVALID_HW_RING_ID)
+ if (ring->fw_ring_id == INVALID_HW_RING_ID_32BIT)
return;
cmpl_ring_id = bnge_cp_ring_for_rx(rxr);
@@ -2409,7 +2407,7 @@ static void bnge_hwrm_rx_ring_free(struct bnge_net *bn,
RING_FREE_REQ_RING_TYPE_RX,
close_path ? cmpl_ring_id :
INVALID_HW_RING_ID);
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
bn->grp_info[grp_idx].rx_fw_ring_id = INVALID_HW_RING_ID;
}
@@ -2421,14 +2419,14 @@ static void bnge_hwrm_rx_agg_ring_free(struct bnge_net *bn,
u32 grp_idx = rxr->bnapi->index;
u32 cmpl_ring_id;
- if (ring->fw_ring_id == INVALID_HW_RING_ID)
+ if (ring->fw_ring_id == INVALID_HW_RING_ID_32BIT)
return;
cmpl_ring_id = bnge_cp_ring_for_rx(rxr);
hwrm_ring_free_send_msg(bn, ring, RING_FREE_REQ_RING_TYPE_RX_AGG,
close_path ? cmpl_ring_id :
INVALID_HW_RING_ID);
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
bn->grp_info[grp_idx].agg_fw_ring_id = INVALID_HW_RING_ID;
}
@@ -2439,14 +2437,14 @@ static void bnge_hwrm_tx_ring_free(struct bnge_net *bn,
struct bnge_ring_struct *ring = &txr->tx_ring_struct;
u32 cmpl_ring_id;
- if (ring->fw_ring_id == INVALID_HW_RING_ID)
+ if (ring->fw_ring_id == INVALID_HW_RING_ID_32BIT)
return;
cmpl_ring_id = close_path ? bnge_cp_ring_for_tx(txr) :
INVALID_HW_RING_ID;
hwrm_ring_free_send_msg(bn, ring, RING_FREE_REQ_RING_TYPE_TX,
cmpl_ring_id);
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
}
static void bnge_hwrm_cp_ring_free(struct bnge_net *bn,
@@ -2455,12 +2453,12 @@ static void bnge_hwrm_cp_ring_free(struct bnge_net *bn,
struct bnge_ring_struct *ring;
ring = &cpr->ring_struct;
- if (ring->fw_ring_id == INVALID_HW_RING_ID)
+ if (ring->fw_ring_id == INVALID_HW_RING_ID_32BIT)
return;
hwrm_ring_free_send_msg(bn, ring, RING_FREE_REQ_RING_TYPE_L2_CMPL,
INVALID_HW_RING_ID);
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
}
static void bnge_hwrm_ring_free(struct bnge_net *bn, bool close_path)
@@ -2496,11 +2494,11 @@ static void bnge_hwrm_ring_free(struct bnge_net *bn, bool close_path)
bnge_hwrm_cp_ring_free(bn, &nqr->cp_ring_arr[j]);
ring = &nqr->ring_struct;
- if (ring->fw_ring_id != INVALID_HW_RING_ID) {
+ if (ring->fw_ring_id != INVALID_HW_RING_ID_32BIT) {
hwrm_ring_free_send_msg(bn, ring,
RING_FREE_REQ_RING_TYPE_NQ,
INVALID_HW_RING_ID);
- ring->fw_ring_id = INVALID_HW_RING_ID;
+ ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
bn->grp_info[i].nq_fw_ring_id = INVALID_HW_RING_ID;
}
}
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_netdev.h b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.h
index f4636b5b0cf3..d177919c2e11 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_netdev.h
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.h
@@ -630,8 +630,8 @@ struct bnge_l2_filter {
refcount_t refcnt;
};
-u16 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr);
-u16 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr);
+u32 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr);
+u32 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr);
void bnge_fill_hw_rss_tbl(struct bnge_net *bn, struct bnge_vnic_info *vnic);
int bnge_alloc_rx_data(struct bnge_net *bn, struct bnge_rx_ring_info *rxr,
u16 prod, gfp_t gfp);
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_rmem.h b/drivers/net/ethernet/broadcom/bnge/bnge_rmem.h
index 341c7f81ed09..bb0c79a1ee60 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_rmem.h
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_rmem.h
@@ -184,7 +184,7 @@ struct bnge_ctx_mem_info {
struct bnge_ring_struct {
struct bnge_ring_mem_info ring_mem;
- u16 fw_ring_id;
+ u32 fw_ring_id;
union {
u16 grp_idx;
u16 map_idx; /* Used by NQs */
diff --git a/include/linux/bnge/hsi.h b/include/linux/bnge/hsi.h
index 8ea13d5407ee..1f7bd96415a5 100644
--- a/include/linux/bnge/hsi.h
+++ b/include/linux/bnge/hsi.h
@@ -8317,8 +8317,7 @@ struct hwrm_ring_alloc_output {
__le16 req_type;
__le16 seq_id;
__le16 resp_len;
- __le16 ring_id;
- __le16 logical_ring_id;
+ __le32 ring_id;
u8 push_buffer_index;
#define RING_ALLOC_RESP_PUSH_BUFFER_INDEX_PING_BUFFER 0x0UL
#define RING_ALLOC_RESP_PUSH_BUFFER_INDEX_PONG_BUFFER 0x1UL
@@ -8345,10 +8344,10 @@ struct hwrm_ring_free_input {
u8 flags;
#define RING_FREE_REQ_FLAGS_VIRTIO_RING_VALID 0x1UL
#define RING_FREE_REQ_FLAGS_LAST RING_FREE_REQ_FLAGS_VIRTIO_RING_VALID
- __le16 ring_id;
+ __le16 unused_1;
__le32 prod_idx;
__le32 opaque;
- __le32 unused_1;
+ __le32 ring_id;
};
/* hwrm_ring_free_output (size:128b/16B) */
--
2.47.1
^ permalink raw reply related
* Re: [PATCH net-next v10 1/5] net: phy: c45: add genphy_c45_pma_soft_reset()
From: Maxime Chevallier @ 2026-07-21 6:52 UTC (permalink / raw)
To: javen, andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni,
freddy_gu, nb
Cc: netdev, linux-kernel, daniel, vladimir.oltean
In-Reply-To: <20260721022410.1391-2-javen_xu@realsil.com.cn>
Hi,
On 7/21/26 04:24, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> Add a generic Clause 45 software reset helper. The helper sets the reset
> bit in the PMA/PMD control register and waits until the bit is cleared by
> hardware.
>
> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH v2] virtio_net: fix infinite loop in virtnet_poll_cleantx when device is broken
From: Xuan Zhuo @ 2026-07-21 6:52 UTC (permalink / raw)
To: Jinqian Yang
Cc: netdev, virtualization, linux-kernel, liuyonglong, wangzhou1,
linuxarm, Jinqian Yang, mst, jasowang, xuanzhuo, eperezma,
andrew+netdev, davem, edumazet, kuba, pabeni
In-Reply-To: <20260716035201.3736582-1-yangjinqian1@huawei.com>
On Thu, 16 Jul 2026 11:52:01 +0800, Jinqian Yang <yangjinqian1@huawei.com> wrote:
> virtnet_poll_cleantx() contains a do-while loop that cleans up
> transmitted TX buffers and calls virtqueue_enable_cb_delayed() to check
> whether more buffers need processing. When the virtio backend stops
> responding during guest reboot, used->idx is never updated, so
> virtqueue_enable_cb_delayed() always returns false and the loop never
> terminates. Then it will block reboot process, and the guest will hang.
>
> The problem occurs during guest reboot under network traffic:
>
> 1. kernel_restart() -> device_shutdown() traverses the device list
> 2. virtio_dev_shutdown() calls virtio_break_device() which sets
> vq->broken = true
> 3. virtio_dev_shutdown() then calls virtio_synchronize_cbs() to wait
> for in-flight callbacks to complete
> 4. A virtio interrupt fires, softirq is deferred to ksoftirqd which
> calls net_rx_action() -> virtnet_poll() -> virtnet_poll_cleantx()
> 5. virtnet_poll_cleantx() enters the do-while loop and never exits
> because the QEMU backend has stopped updating used->idx, despite
> vq->broken having been set to true in step 2.
>
> Since the loop runs inside ksoftirqd (a SCHED_OTHER kthread), it is
> visible to the scheduler and does not trigger a hard lockup. However,
> the kthread never leaves the loop, so RCU detects it as a CPU stall
> and reports it periodically. Meanwhile, the reboot process remains
> blocked in device_shutdown() because virtio_dev_shutdown() cannot
> complete its synchronization step, and the guest hangs permanently.
>
> This can be reproduced on a guest with a virtio-net device: run iperf3
> traffic in the guest, then trigger reboot. The reboot occasionally hangs
> permanently with RCU stall on ksoftirqd.
>
> Observed on ARM64 KVM guest:
>
> CPU#1 RCU stall (ksoftirqd/1), repeated periodically:
> virtqueue_enable_cb_delayed_split <- virtnet_poll <- __napi_poll <-
> net_rx_action <- handle_softirqs <- run_ksoftirqd <-
> smpboot_thread_fn <- kthread
>
> Fix by adding a virtqueue_is_broken() check to the loop condition, so
> that the loop exits immediately when the device is broken, allowing
> the device shutdown to proceed.
>
> Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com>
Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> ---
> Changes in v2:
> - Moved vq->broken check to virtqueue_enable_cb_delayed().
>
> v1: https://lore.kernel.org/lkml/20260713132025.703147-1-yangjinqian1@huawei.com/
> ---
> drivers/virtio/virtio_ring.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index b438dc2ce1b8..5c169fbb418a 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -3233,6 +3233,14 @@ bool virtqueue_enable_cb_delayed(struct virtqueue *_vq)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
>
> + /*
> + * When the device is broken there is no point in polling used->idx,
> + * the backend will never update it. Return true to let callers
> + * exit their cleanup loops instead of spinning forever.
> + */
> + if (unlikely(vq->broken))
> + return true;
> +
> if (vq->event_triggered)
> data_race(vq->event_triggered = false);
>
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH v3] virtio_ring: fix infinite loop in virtnet_poll_cleantx when device is broken
From: Xuan Zhuo @ 2026-07-21 6:53 UTC (permalink / raw)
To: Jinqian Yang
Cc: netdev, virtualization, linux-kernel, liuyonglong, wangzhou1,
linuxarm, Jinqian Yang, mst, jasowang, xuanzhuo, eperezma,
andrew+netdev, davem, edumazet, kuba, pabeni
In-Reply-To: <20260716115940.394832-1-yangjinqian1@huawei.com>
On Thu, 16 Jul 2026 19:59:40 +0800, Jinqian Yang <yangjinqian1@huawei.com> wrote:
> virtnet_poll_cleantx() contains a do-while loop that cleans up
> transmitted TX buffers and calls virtqueue_enable_cb_delayed() to check
> whether more buffers need processing. When the virtio backend stops
> responding during guest reboot, used->idx is never updated, so
> virtqueue_enable_cb_delayed() always returns false and the loop never
> terminates. Then it will block reboot process, and the guest will hang.
>
> The problem occurs during guest reboot under network traffic:
>
> 1. kernel_restart() -> device_shutdown() traverses the device list
> 2. virtio_dev_shutdown() calls virtio_break_device() which sets
> vq->broken = true
> 3. virtio_dev_shutdown() then calls virtio_synchronize_cbs() to wait
> for in-flight callbacks to complete
> 4. A virtio interrupt fires, softirq is deferred to ksoftirqd which
> calls net_rx_action() -> virtnet_poll() -> virtnet_poll_cleantx()
> 5. virtnet_poll_cleantx() enters the do-while loop and never exits
> because the QEMU backend has stopped updating used->idx, despite
> vq->broken having been set to true in step 2.
>
> Since the loop runs inside ksoftirqd (a SCHED_OTHER kthread), it is
> visible to the scheduler and does not trigger a hard lockup. However,
> the kthread never leaves the loop, so RCU detects it as a CPU stall
> and reports it periodically. Meanwhile, the reboot process remains
> blocked in device_shutdown() because virtio_dev_shutdown() cannot
> complete its synchronization step, and the guest hangs permanently.
>
> This can be reproduced on a guest with a virtio-net device: run iperf3
> traffic in the guest, then trigger reboot. The reboot occasionally hangs
> permanently with RCU stall on ksoftirqd.
>
> Observed on ARM64 KVM guest:
>
> CPU#1 RCU stall (ksoftirqd/1), repeated periodically:
> virtqueue_enable_cb_delayed_split <- virtnet_poll <- __napi_poll <-
> net_rx_action <- handle_softirqs <- run_ksoftirqd <-
> smpboot_thread_fn <- kthread
>
> Fix by adding a vq->broken check in virtqueue_enable_cb_delayed(), so
> that the loop exits immediately when the device is broken, allowing
> the device shutdown to proceed.
>
> Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com>
Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> ---
> Changes in v2:
> - Moved vq->broken check to virtqueue_enable_cb_delayed().
> Changes in v3:
> - Updated the patch subject prefix.
>
> v1: https://lore.kernel.org/lkml/20260713132025.703147-1-yangjinqian1@huawei.com/
> v2: https://lore.kernel.org/lkml/20260716035201.3736582-1-yangjinqian1@huawei.com/
> ---
> drivers/virtio/virtio_ring.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index b438dc2ce1b8..5c169fbb418a 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -3233,6 +3233,14 @@ bool virtqueue_enable_cb_delayed(struct virtqueue *_vq)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
>
> + /*
> + * When the device is broken there is no point in polling used->idx,
> + * the backend will never update it. Return true to let callers
> + * exit their cleanup loops instead of spinning forever.
> + */
> + if (unlikely(vq->broken))
> + return true;
> +
> if (vq->event_triggered)
> data_race(vq->event_triggered = false);
>
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH net-next v2] net/sched: sch_cake: skip clearing unused tins during rate adjustment
From: Toke Høiland-Jørgensen @ 2026-07-21 6:55 UTC (permalink / raw)
To: Jonas Köppeler, Jamal Hadi Salim, Jiri Pirko,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: cake, netdev, linux-kernel, Mike Pham
In-Reply-To: <20260720-sch_cake-skip-clearing-tins-v2-1-e6a8b0275c73@tu-berlin.de>
On 20 July 2026 23.14.52 CEST, "Jonas Köppeler" <j.koeppeler@tu-berlin.de> wrote:
>When cake_configure_rates() is called from the dequeue path with
>rate_adjust=true, it only needs to update the rate parameters. The
>loop that clears the unused tins is both unnecessary and harmful in
>this path:
>
> - cake_clear_tin() overwrites q->cur_tin and q->cur_flow, which are
> actively used by cake_dequeue(), corrupting the dequeue state.
> - iterating over the unused tins and their internal queues to purge
> packets adds needless overhead to the hot path.
>
>Skip the entire loop when rate_adjust is set, as neither
>cake_clear_tin() nor the mtu_time update are needed when only the
>rate changes.
>
>The clearing loop runs on every rate adjustment from the dequeue path,
>clearing (max_tins - cur_tins) tins each time, so the cost grows the
>fewer tins the configured mode actually uses. Testing cake_mq over veth
>(8 rx/tx queues, 2 Gbit limit) with flent's [1] rrul and tcp_nup tests and
>32 TCP upstreams shows a large drop in loaded latency and a throughput
>gain, restoring behaviour to pre-15c2715a5264 levels:
>
> +------------+------+------+-------+-------+---------+
> | kernel | mode | test | base | load | tput |
> | | | | (ms) | (ms) | (Mbit) |
> +------------+------+------+-------+-------+---------+
> | net-next | be | rrul | 0.810 | 11.78 | 1469.67 |
> | net-next | be | nup | 0.637 | 85.71 | 1243.15 |
> | net-next | ds3 | rrul | 0.397 | 15.28 | 1770.06 |
> | net-next | ds3 | nup | 0.351 | 15.98 | 1799.39 |
> +------------+------+------+-------+-------+---------+
> | patched | be | rrul | 0.092 | 0.56 | 1873.40 |
> | patched | be | nup | 0.109 | 1.82 | 1869.12 |
> | patched | ds3 | rrul | 0.097 | 0.98 | 1866.10 |
> | patched | ds3 | nup | 0.101 | 0.51 | 1861.79 |
> +------------+------+------+-------+-------+---------+
>
>The same trend holds on real hardware (IPQ8074A, 4 rx/tx queues,
>OpenWrt): in besteffort mode the tcp_nup loaded latency drops from
>~470 ms to ~4 ms.
>
>[1] https://flent.org
>
>Fixes: 15c2715a5264 ("net/sched: sch_cake: fixup cake_mq rate adjustment for diffserv config")
>Signed-off-by: Jonas Köppeler <j.koeppeler@tu-berlin.de>
>Tested-by: Mike Pham <mikepham4321@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH net-next v10 5/5] net: phy: realtek: add support for RTL8261D
From: Maxime Chevallier @ 2026-07-21 6:57 UTC (permalink / raw)
To: javen, andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni,
freddy_gu, nb
Cc: netdev, linux-kernel, daniel, vladimir.oltean
In-Reply-To: <20260721022410.1391-6-javen_xu@realsil.com.cn>
Hi,
On 7/21/26 04:24, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> RTL8261D is also 10g phy. It's sub_phy_id is 0x81. And it does not need
> any firmware.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH v5 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
From: Michael Walle @ 2026-07-21 7:02 UTC (permalink / raw)
To: Manikandan Muralidharan, pratyush, mwalle, takahiro.kuwano,
miquel.raynal, richard, vigneshr, robh, krzk+dt, conor+dt, srini,
nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
richardcochran, linusw, arnd, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20260721052859.171341-4-manikandan.m@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 5545 bytes --]
On Tue Jul 21, 2026 at 7:28 AM CEST, Manikandan Muralidharan wrote:
> The SPI NOR core already reads the SFDP tables during enumeration and
> caches them in nor->sfdp->dwords (see spi_nor_parse_sfdp()). Re-expose
> that cached data as a read-only NVMEM device, in on-flash byte order,
> rooted at the flash's SFDP child node (compatible "jedec,sfdp").
>
> This lets NVMEM cells reference any SFDP data: a fixed-layout for
> parameters at a known offset, or an nvmem-layout parser for vendor data
> whose location must be discovered at runtime.The device is only registered
> when an "sfdp" node is present in the device tree.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
> ---
> drivers/mtd/spi-nor/core.c | 8 ++++
> drivers/mtd/spi-nor/core.h | 1 +
> drivers/mtd/spi-nor/sfdp.c | 86 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 95 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index ccf4396cdcd0..b833d8ec2d65 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3204,6 +3204,14 @@ static int spi_nor_init_params(struct spi_nor *nor)
> spi_nor_init_params_deprecated(nor);
> }
>
> + /*
> + * Expose the SFDP table as an NVMEM device only when
> + * the flash actually provides one
> + */
> + ret = spi_nor_register_sfdp_nvmem(nor);
> + if (ret)
> + return ret;
> +
> ret = spi_nor_late_init_params(nor);
> if (ret)
> return ret;
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index ba2d1a862c9d..0a6484298c5c 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -698,6 +698,7 @@ int spi_nor_controller_ops_write_reg(struct spi_nor *nor, u8 opcode,
>
> int spi_nor_check_sfdp_signature(struct spi_nor *nor);
> int spi_nor_parse_sfdp(struct spi_nor *nor);
> +int spi_nor_register_sfdp_nvmem(struct spi_nor *nor);
That's probably not needed if..
> static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
> {
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 4600983cb579..704799fe92ae 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -6,6 +6,8 @@
>
> #include <linux/bitfield.h>
> #include <linux/mtd/spi-nor.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/of.h>
> #include <linux/slab.h>
> #include <linux/sort.h>
>
> @@ -1612,3 +1614,87 @@ int spi_nor_parse_sfdp(struct spi_nor *nor)
> kfree(param_headers);
> return err;
> }
> +
> +static int spi_nor_sfdp_reg_read(void *priv, unsigned int offset,
> + void *val, size_t bytes)
> +{
> + struct spi_nor *nor = priv;
> + struct sfdp *sfdp = nor->sfdp;
> + size_t sfdp_size = sfdp->num_dwords * sizeof(*sfdp->dwords);
> +
> + if (offset >= sfdp_size || bytes > sfdp_size - offset)
> + return -EINVAL;
> +
> + /* The cached SFDP is kept in on-flash (little-endian) byte order. */
> + memcpy(val, (u8 *)sfdp->dwords + offset, bytes);
> +
> + return 0;
> +}
> +
> +static void spi_nor_sfdp_nvmem_put_np(void *data)
> +{
> + of_node_put(data);
> +}
> +
> +/**
> + * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
> + * @nor: pointer to a 'struct spi_nor'
> + *
> + * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
> + * rooted at the flash's SFDP child node (compatible "jedec,sfdp"). This lets
> + * generic (fixed-layout) or vendor (nvmem-layout) cells reference any SFDP
> + * data. The device is only registered when a child node with the "jedec,sfdp"
> + * compatible is described in the device tree.
> + *
> + * Return: 0 on success or if there is nothing to do, -errno otherwise.
> + */
> +int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
.. you move all this into the core, as the sfdp.c is just for
parsing the tables.
> +{
> + struct device *dev = nor->dev;
> + struct nvmem_config config = { };
> + struct nvmem_device *nvmem;
> + struct device_node *np;
> + int ret;
> +
> + if (!nor->sfdp)
> + return 0;
> +
> + for_each_available_child_of_node(dev_of_node(dev), np)
> + if (of_device_is_compatible(np, "jedec,sfdp"))
> + break;
There is already of_get_compatible_child() doing exactly this.
> + if (!np)
> + return 0;
> +
> + /*
> + * Register the put before devm_nvmem_register() so it runs last on
> + * detach, after the NVMEM device that uses the node is gone.
> + */
> + ret = devm_add_action_or_reset(dev, spi_nor_sfdp_nvmem_put_np, np);
> + if (ret)
> + return ret;
> +
> + config.dev = dev;
> + config.of_node = np;
> + config.name = "sfdp";
> + config.id = NVMEM_DEVID_AUTO;
Or rather NVEMEM_DEVID_NONE? There will ever be just one SFDP nvmem
device.
How does the sysfs path looks like?
-michael
> + config.owner = THIS_MODULE;
> + config.read_only = true;
> + config.word_size = 1;
> + config.stride = 1;
> + config.size = (int)(nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords));
> + config.reg_read = spi_nor_sfdp_reg_read;
> + config.priv = nor;
> +
> + nvmem = devm_nvmem_register(dev, &config);
> + if (IS_ERR(nvmem)) {
> + /* NVMEM support is optional. */
> + if (PTR_ERR(nvmem) == -EOPNOTSUPP)
> + return 0;
> + return dev_err_probe(dev, PTR_ERR(nvmem),
> + "failed to register SFDP NVMEM device\n");
> + }
> +
> + dev_dbg(dev, "exposed %d-byte SFDP as an NVMEM device\n", config.size);
> +
> + return 0;
> +}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* [PATCH v2 net-next] octeontx2-af: npc: Warn on NPC_IPSEC_SPI key overlap
From: Ratheesh Kannoth @ 2026-07-21 7:03 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, sgoutham,
Hariprasad Kelam, Ratheesh Kannoth
From: Hariprasad Kelam <hkelam@marvell.com>
When scanning the MKEX profile to determine supported NPC features, warn
if the SPI extraction field overlaps with other key fields. AH and ESP
may legitimately use the same key offset for SPI, so continue to
advertise NPC_IPSEC_SPI via npc_is_field_present() instead of treating
the overlap as a hard failure.
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
---
v1 -> v2: Addressed Simon comments
https://lore.kernel.org/netdev/20260720171857.278396-2-horms@kernel.org/
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
index 91b5947dae06..d422bdd5e8f8 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
@@ -729,7 +729,12 @@ static void npc_set_features(struct rvu *rvu, int blkaddr, u8 intf)
if (!npc_check_field(rvu, blkaddr, NPC_LB, intf))
*features &= ~BIT_ULL(NPC_OUTER_VID);
- /* Allow extracting SPI field from AH and ESP headers at same offset */
+ /* Warn on unrelated MKEX fields colliding with SPI key bits. AH/ESP
+ * sharing the same SPI key offset is valid; use npc_is_field_present(),
+ * not npc_check_field(), to advertise the feature.
+ */
+ if (npc_check_overlap(rvu, blkaddr, NPC_IPSEC_SPI, 0, intf))
+ dev_warn(rvu->dev, "Overlap detected the field NPC_IPSEC_SPI\n");
if (npc_is_field_present(rvu, NPC_IPSEC_SPI, intf) &&
(*features & (BIT_ULL(NPC_IPPROTO_ESP) | BIT_ULL(NPC_IPPROTO_AH))))
*features |= BIT_ULL(NPC_IPSEC_SPI);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] octeontx2-af: npc: Warn on NPC_IPSEC_SPI key overlap
From: Ratheesh Kannoth @ 2026-07-21 7:13 UTC (permalink / raw)
To: Simon Horman
Cc: linux-kernel, netdev, andrew+netdev, davem, edumazet, kuba,
pabeni, sgoutham, hkelam
In-Reply-To: <20260720171857.278396-2-horms@kernel.org>
On 2026-07-20 at 22:48:58, Simon Horman (horms@kernel.org) wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> https://sashiko.dev/#/patchset/20260713144247.545592-1-rkannoth@marvell.com?part=1
> ---
> --- Patch [1]: [PATCH net-next] octeontx2-af: npc: Warn on NPC_IPSEC_SPI key overlap ---
> commit f018da26dc974202fbe56b064f0bc0375c74613a
> Author: Hariprasad Kelam <hkelam@marvell.com>
>
> octeontx2-af: npc: Warn on NPC_IPSEC_SPI key overlap
>
> When scanning the MKEX profile to determine supported NPC features, warn
> if the SPI extraction field overlaps with other key fields. AH and ESP
> may legitimately use the same key offset for SPI, so continue to
> advertise NPC_IPSEC_SPI via npc_is_field_present() instead of treating
> the overlap as a hard failure.
>
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> > index 91b5947dae060..b217c1c19810a 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
> > @@ -730,6 +730,9 @@ static void npc_set_features(struct rvu *rvu, int blkaddr, u8 intf)
> > *features &= ~BIT_ULL(NPC_OUTER_VID);
> >
> > /* Allow extracting SPI field from AH and ESP headers at same offset */
> > + if (npc_check_overlap(rvu, blkaddr, NPC_IPSEC_SPI, 0, intf))
> > + dev_warn(rvu->dev, "Overlap detected the field NPC_IPSEC_SPI\n");
>
> [Severity: Medium]
> The commit message notes that AH and ESP may legitimately use the same key
> offset for SPI. However, will this new dev_warn() trigger anyway for those
> valid configurations?
>
> If an MKEX profile configures AH and ESP SPI extraction at the same
> offset, npc_check_overlap() will still see them as mutually exclusive fields
> with different lids (LID_LD and LID_LE). Does this result in spurious
> warnings polluting the kernel log on valid hardware configurations?
>
> [Severity: High]
> This is a pre-existing issue, but does npc_check_overlap() have a data
> race when called concurrently?
>
> Looking at npc_check_overlap(), it assigns a local pointer to the shared
> scratchpad array and then mutates it:
>
> rvu_npc_fs.c:npc_check_overlap() {
> ...
> dummy = &mcam->rx_key_fields[NPC_UNKNOWN];
> ...
> memset(dummy, 0, sizeof(struct npc_key_field));
> npc_set_layer_mdata(rvu, mcam, NPC_UNKNOWN, cfg, lid, lt, intf);
> ...
> }
>
> If multiple VFs simultaneously send mailbox commands that trigger overlap
> checks across different CPUs, won't they overwrite this global dummy struct
> and corrupt each other's flow validation?
>
> > + /* Set SPI flag only if AH/ESP and IPSEC_SPI are in the key */
> > if (npc_is_field_present(rvu, NPC_IPSEC_SPI, intf) &&
> > (*features & (BIT_ULL(NPC_IPPROTO_ESP) | BIT_ULL(NPC_IPPROTO_AH))))
> > *features |= BIT_ULL(NPC_IPSEC_SPI);
These comments are not valid. Let me modify the code omment so that AI reviewer
wont raise this again.
pw-bot: changes-requested
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox