* [PATCH v4 0/7] Read MAC address from SST vendor specific SFDP region
From: Manikandan Muralidharan @ 2026-06-30 9:23 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 v4 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 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
v3: https://lore.kernel.org/linux-arm-kernel/20250521070336.402202-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 | 5 +
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 83 ++++++++
drivers/nvmem/layouts/Kconfig | 10 +
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/sst26vf-sfdp-eui.c | 182 ++++++++++++++++++
13 files changed, 409 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: dc59e4fea9d83f03bad6bddf3fa2e52491777482
--
2.43.0
^ permalink raw reply
* Re: [PATCH 1/2] bug: Provide WARN_ON.*DEFERRED() macros for console deferred output
From: Petr Mladek @ 2026-06-30 9:21 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: K Prateek Nayak, linux-arch, linux-kernel, sched-ext, netdev,
David S . Miller, Andrea Righi, Andrew Morton, Arnd Bergmann,
Ben Segall, Breno Leitao, Changwoo Min, David Vernet,
Dietmar Eggemann, Eric Dumazet, Ingo Molnar, Jakub Kicinski,
John Ogness, Juri Lelli, Paolo Abeni, Peter Zijlstra,
Sergey Senozhatsky, Simon Horman, Steven Rostedt, Tejun Heo,
Vincent Guittot, Vlad Poenaru
In-Reply-To: <20260624152431.Ufq0jT8r@linutronix.de>
On Wed 2026-06-24 17:24:31, Sebastian Andrzej Siewior wrote:
> On 2026-06-24 11:17:31 [+0200], Petr Mladek wrote:
> > For Linus, it was a no-go, definitely.
> …
> > I would vote for adding the WARN_*DEFERRED() into the scheduler code
> > at least until majority of console drivers are converted to nbcon API.
>
> I see four nbcon serial console drivers (+netconsole, + drm_log). We
> have at least four times that many console drivers. What is the
> majority from your point of view? The 8250 should cover all of x86.
Good question. IMHO, there are about 100 console drivers:
$> git grep "struct console.*= {" | wc -l
107
But I guess that many of them are some old rarely used ones.
I tried to google amount of market share from various architectures
and it seems that most spread are: arm, x86_64, and risc-v.
Arm might already be mostly covered by pl011.
x86_64 will be covered by 8250.
I am not sure about risc-v. It seems that it might use 8250 as well
at least in virtual machines. Also there is drivers/tty/hvc/hvc_riscv_sbi.c.
Hmm, 8250 might the breakpoint. Maybe, we could leave the rest as a
motivation to convert the console driver instead of adding workarounds
using the printk_deferred() mechanism.
That said, AFAIK, the netconsole is often used when the device does
not have a serial console. And it is pity that it does not have
the .write_atomic callbacks implemented.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH net v3 1/2] net: macb: give reasons for Tx SKB kfree
From: Théo Lebrun @ 2026-06-30 9:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Haavard Skinnemoen, Jeff Garzik,
Conor Dooley, Paolo Valerio, Nicolai Buchwitz, netdev,
linux-kernel, Vladimir Kondratiev, Gregory CLEMENT,
Benoît Monin, Tawfik Bayouk, Thomas Petazzoni,
Maxime Chevallier, stable
In-Reply-To: <20260621144047.3db74e2b@kernel.org>
Hello Jakub,
On Sun Jun 21, 2026 at 11:40 PM CEST, Jakub Kicinski wrote:
> On Wed, 17 Jun 2026 11:17:29 +0200 Théo Lebrun wrote:
>> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
>> Cc: stable@vger.kernel.org
>
> Interesting, did AI suggest this? It's fairly uncommon for drivers
> to care about drop reasons, packet loss on egress ports is pretty
> clearly attributed by tx_drops.
>
> I don't think this belongs in net, net-next would be fine, if you think
> it's necessary. Sashiko seems to point out a few more clear cut bugs.
I don't use AI for kernel code generation, only code exploration and
reviews.
In MACB we know our stats are pretty broken (including tx_drops) but
fixing stats is a full refactor that will come later and is too large
for this bugfix. So I used the drop reason mechanism to have a way to
notice dropped packets, otherwise we have nothing.
My commit message should have covered this in more details!
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] bpf: Fix smp_processor_id() call trace for preemptible kernels
From: Edward Adam Davis @ 2026-06-30 9:11 UTC (permalink / raw)
To: sashiko-bot
Cc: andrii, ast, bpf, daniel, eddyz87, emil, jolsa, linux-kernel,
martin.lau, memxor, netdev, song, syzkaller-bugs, yonghong.song
In-Reply-To: <20260630084910.D5C3A1F000E9@smtp.kernel.org>
bpf_mem_cache_free_rcu() maybe called in preemptible context, this
will trigger the below warning message:
BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
Call Trace:
check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
__rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
__sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1
this_cpu_ptr() access needs to be guarded against preemption.
Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: using guard against preemption
kernel/bpf/memalloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/memalloc.c b/kernel/bpf/memalloc.c
index bd45dda9dc35..1d7ddfc1c9d1 100644
--- a/kernel/bpf/memalloc.c
+++ b/kernel/bpf/memalloc.c
@@ -957,7 +957,9 @@ void notrace bpf_mem_cache_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
if (!ptr)
return;
+ get_cpu();
unit_free_rcu(this_cpu_ptr(ma->cache), ptr);
+ put_cpu();
}
/* Directly does a kfree() without putting 'ptr' back to the free_llist
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v4 2/3] net: pse-pd: fire lifecycle events on controller register/unregister
From: Carlo Szelinsky @ 2026-06-30 9:11 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Corey Leavitt, Jonas Jelonek, Simon Horman, netdev, linux-kernel,
Carlo Szelinsky
In-Reply-To: <20260630091125.3162481-1-github@szelinsky.de>
From: Corey Leavitt <corey@leavitt.info>
Hook the newly-introduced pse_controller_notifier chain so that
pse_controller_register() fires PSE_REGISTERED after the controller
has been added to pse_controller_list (i.e. is now resolvable by
of_pse_control_get()), and pse_controller_unregister() fires
PSE_UNREGISTERED before the controller is removed from the list
(while it is still valid to dereference from a subscriber's
pse_control pointer targeting it).
With no subscribers yet, this is observably a no-op. A later change
wires the phy subsystem in as the first subscriber.
Signed-off-by: Corey Leavitt <corey@leavitt.info>
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Tested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
drivers/net/pse-pd/pse_core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 3c4d09f1d6e4..0190fac33c78 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -1138,6 +1138,9 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
list_add(&pcdev->list, &pse_controller_list);
mutex_unlock(&pse_list_mutex);
+ blocking_notifier_call_chain(&pse_controller_notifier,
+ PSE_REGISTERED, pcdev);
+
return 0;
}
EXPORT_SYMBOL_GPL(pse_controller_register);
@@ -1148,6 +1151,9 @@ EXPORT_SYMBOL_GPL(pse_controller_register);
*/
void pse_controller_unregister(struct pse_controller_dev *pcdev)
{
+ blocking_notifier_call_chain(&pse_controller_notifier,
+ PSE_UNREGISTERED, pcdev);
+
pse_flush_pw_ds(pcdev);
pse_release_pis(pcdev);
if (pcdev->irq)
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v4 1/3] net: pse-pd: add notifier chain for controller lifecycle events
From: Carlo Szelinsky @ 2026-06-30 9:11 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Corey Leavitt, Jonas Jelonek, Simon Horman, netdev, linux-kernel,
Carlo Szelinsky
In-Reply-To: <20260630091125.3162481-1-github@szelinsky.de>
From: Corey Leavitt <corey@leavitt.info>
Introduce a blocking notifier chain that allows other subsystems to be
informed when a PSE controller is registered or unregistered, and
provide pse_register_notifier() / pse_unregister_notifier() as the
subscriber interface.
Subsequent patches will use this to let the phy subsystem own the
phydev->psec lifecycle directly, decoupling PSE lookup from
fwnode_mdiobus_register_phy() and removing the probe-time
-EPROBE_DEFER coupling that currently exists between mdio, phy and
pse-pd when the PSE controller driver is modular.
A blocking chain (rather than atomic) is used because callbacks will
take rtnl_lock and call back into pse_core via of_pse_control_get().
The enum pse_controller_event is placed outside the
IS_ENABLED(CONFIG_PSE_CONTROLLER) guard so that subscribers compiled
into a kernel without PSE support can still reference the event
values in dead-code paths without breaking the build.
This patch is pure infrastructure: nothing fires events yet, and
nothing subscribes. No observable behavior change.
Signed-off-by: Corey Leavitt <corey@leavitt.info>
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Tested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
drivers/net/pse-pd/pse_core.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/pse-pd/pse.h | 32 ++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 69dbdbde9d71..3c4d09f1d6e4 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -8,6 +8,7 @@
#include <linux/device.h>
#include <linux/ethtool.h>
#include <linux/ethtool_netlink.h>
+#include <linux/notifier.h>
#include <linux/of.h>
#include <linux/phy.h>
#include <linux/pse-pd/pse.h>
@@ -23,6 +24,39 @@ static LIST_HEAD(pse_controller_list);
static DEFINE_XARRAY_ALLOC(pse_pw_d_map);
static DEFINE_MUTEX(pse_pw_d_mutex);
+static BLOCKING_NOTIFIER_HEAD(pse_controller_notifier);
+
+/**
+ * pse_register_notifier - register a callback for PSE controller events
+ * @nb: notifier block to register
+ *
+ * See enum pse_controller_event for events fired and their subscriber
+ * contract. Callbacks run in process context; they may sleep, take
+ * rtnl, and call of_pse_control_get(). The chain fires synchronously,
+ * so a PSE controller driver's probe/unbind path must not hold any
+ * such lock when calling pse_controller_register() or
+ * pse_controller_unregister().
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_register_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_register_notifier);
+
+/**
+ * pse_unregister_notifier - unregister a previously registered callback
+ * @nb: notifier block previously passed to pse_register_notifier()
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_unregister_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_unregister_notifier);
+
/**
* struct pse_control - a PSE control
* @pcdev: a pointer to the PSE controller device
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7..78fe3a2b1ea8 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -21,6 +21,7 @@ struct net_device;
struct phy_device;
struct pse_controller_dev;
struct netlink_ext_ack;
+struct notifier_block;
/* C33 PSE extended state and substate. */
struct ethtool_c33_pse_ext_state_info {
@@ -337,6 +338,24 @@ enum pse_budget_eval_strategies {
PSE_BUDGET_EVAL_STRAT_DYNAMIC = 1 << 2,
};
+/**
+ * enum pse_controller_event - PSE controller lifecycle events
+ *
+ * Event data in callbacks is always a pointer to the struct
+ * pse_controller_dev firing the event.
+ *
+ * @PSE_REGISTERED: controller added to pse_controller_list and
+ * resolvable by of_pse_control_get().
+ * @PSE_UNREGISTERED: controller about to be removed from
+ * pse_controller_list. Subscribers holding pse_control references
+ * targeting it must drop them before returning and must not
+ * acquire new references for it.
+ */
+enum pse_controller_event {
+ PSE_REGISTERED,
+ PSE_UNREGISTERED,
+};
+
#if IS_ENABLED(CONFIG_PSE_CONTROLLER)
int pse_controller_register(struct pse_controller_dev *pcdev);
void pse_controller_unregister(struct pse_controller_dev *pcdev);
@@ -366,6 +385,9 @@ int pse_ethtool_set_prio(struct pse_control *psec,
bool pse_has_podl(struct pse_control *psec);
bool pse_has_c33(struct pse_control *psec);
+int pse_register_notifier(struct notifier_block *nb);
+int pse_unregister_notifier(struct notifier_block *nb);
+
#else
static inline struct pse_control *of_pse_control_get(struct device_node *node,
@@ -416,6 +438,16 @@ static inline bool pse_has_c33(struct pse_control *psec)
return false;
}
+static inline int pse_register_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int pse_unregister_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
#endif
#endif
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v4 3/3] net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio hook
From: Carlo Szelinsky @ 2026-06-30 9:11 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Corey Leavitt, Jonas Jelonek, Simon Horman, netdev, linux-kernel,
Carlo Szelinsky
In-Reply-To: <20260630091125.3162481-1-github@szelinsky.de>
From: Corey Leavitt <corey@leavitt.info>
Transfer ownership of phydev->psec from fwnode_mdio to the phy
subsystem itself. The phy subsystem now subscribes to the pse-pd
notifier chain and manages psec attach/detach in response to PSE
controller lifecycle events, while fwnode_mdio loses its PSE awareness
entirely.
phydev->psec is attached after device_add() has made the phy visible
on mdio_bus_type, under a narrow rtnl_lock() that covers only
phy_try_attach_pse(). Ordering the attach after registration closes
the race that would otherwise leave a phy unattached: a PSE_REGISTERED
event firing during registration walks mdio_bus_type and either finds
the phy already added (and attaches it) or runs before device_add(),
in which case the post-add attach resolves it. The phydev->psec check
in phy_try_attach_pse() makes the two paths idempotent. Holding rtnl
across of_pse_control_get() is safe because pse_list_mutex is never
taken in the opposite order.
device_add() is deliberately left outside rtnl. Binding a phy that
itself provides an SFP cage reaches sfp_bus_add_upstream() through
phy_probe() -> phy_setup_ports() -> phy_sfp_probe(), and
sfp_bus_add_upstream() takes rtnl_lock(); holding rtnl across
device_add() would deadlock such phys (reported on RTL8214FC).
phy_device_register() is split into the public form, which takes the
narrow rtnl_lock() around the attach, and a phy_device_register_locked()
form for callers that already hold rtnl (the SFP module state machine
via __sfp_sm_event). This pair mirrors the register_netdevice() /
register_netdev() split convention already established in the core
networking stack. The _locked form runs device_add() under the
caller's rtnl, which is safe because a phy resident on an SFP module
does not itself provide a downstream cage, so phy_sfp_probe() is a
no-op there.
- On PSE_REGISTERED: an rtnl-guarded bus walk retries the attach for
every registered phy whose psec is still NULL. This is the "phy
was enumerated before the PSE controller loaded" case, the root
cause of the boot-time probe-retry storm on systems with a modular
PSE controller driver.
- On PSE_UNREGISTERED: an rtnl-guarded bus walk releases every
phydev->psec that targets the departing controller before
pse_release_pis() frees pcdev->pi. Without this, a phy still
holding a pse_control reference would cause a use-after-free in
__pse_control_release()'s pcdev->pi[psec->id] access, and the PSE
driver module could not finish unloading while any phy still held a
reference.
A bad `pses` binding -- an error from of_pse_control_get() other than
-ENOENT (no phandle) or -EPROBE_DEFER (controller not yet registered)
-- is reported with phydev_warn() rather than silently dropped,
preserving the diagnostic that the removed fwnode_mdio lookup used to
provide.
The final pse_control_put() of phydev->psec moves from
phy_device_remove() to phy_device_release(), so it runs only after
every reference on the device -- including the bus-iterator references
taken by bus_for_each_dev() in the notifier walk -- has been dropped.
Finally, delete fwnode_find_pse_control() and its call site in
fwnode_mdiobus_register_phy(), and drop the PSE header from
fwnode_mdio.c. The MDIO/DSA probe no longer sees any PSE-originated
-EPROBE_DEFER, so the probe-retry storm is gone and fwnode_mdio is
now PSE-agnostic.
Reported-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Closes: https://lore.kernel.org/netdev/e00048dd-1ed3-40c3-9912-59bccf015ad5@gmail.com/
Signed-off-by: Corey Leavitt <corey@leavitt.info>
Co-developed-by: Carlo Szelinsky <github@szelinsky.de>
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Tested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
drivers/net/mdio/fwnode_mdio.c | 34 -------
drivers/net/phy/phy_device.c | 168 +++++++++++++++++++++++++++++++--
drivers/net/phy/sfp.c | 2 +-
drivers/net/pse-pd/pse_core.c | 14 +++
include/linux/phy.h | 2 +
include/linux/pse-pd/pse.h | 9 ++
6 files changed, 186 insertions(+), 43 deletions(-)
diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index ba7091518265..7bd979b59f49 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -11,33 +11,11 @@
#include <linux/fwnode_mdio.h>
#include <linux/of.h>
#include <linux/phy.h>
-#include <linux/pse-pd/pse.h>
MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("FWNODE MDIO bus (Ethernet PHY) accessors");
-static struct pse_control *
-fwnode_find_pse_control(struct fwnode_handle *fwnode,
- struct phy_device *phydev)
-{
- struct pse_control *psec;
- struct device_node *np;
-
- if (!IS_ENABLED(CONFIG_PSE_CONTROLLER))
- return NULL;
-
- np = to_of_node(fwnode);
- if (!np)
- return NULL;
-
- psec = of_pse_control_get(np, phydev);
- if (PTR_ERR(psec) == -ENOENT)
- return NULL;
-
- return psec;
-}
-
static struct mii_timestamper *
fwnode_find_mii_timestamper(struct fwnode_handle *fwnode)
{
@@ -118,7 +96,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
struct fwnode_handle *child, u32 addr)
{
struct mii_timestamper *mii_ts = NULL;
- struct pse_control *psec = NULL;
struct phy_device *phy;
bool is_c45;
u32 phy_id;
@@ -159,14 +136,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
goto clean_phy;
}
- psec = fwnode_find_pse_control(child, phy);
- if (IS_ERR(psec)) {
- rc = PTR_ERR(psec);
- goto unregister_phy;
- }
-
- phy->psec = psec;
-
/* phy->mii_ts may already be defined by the PHY driver. A
* mii_timestamper probed via the device tree will still have
* precedence.
@@ -176,9 +145,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
return 0;
-unregister_phy:
- if (is_acpi_node(child) || is_of_node(child))
- phy_device_remove(phy);
clean_phy:
phy_device_free(phy);
clean_mii_ts:
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0615228459ef..f5febff4b00b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -223,8 +223,19 @@ static void phy_mdio_device_free(struct mdio_device *mdiodev)
static void phy_device_release(struct device *dev)
{
+ struct phy_device *phydev = to_phy_device(dev);
+
+ /* bus_for_each_dev() holds get_device() across each iteration
+ * step, deferring this release callback until any in-flight PSE
+ * notifier walk has advanced past this phy. pse_control_put()
+ * takes pse_list_mutex, so this path must run in sleepable
+ * context.
+ */
+ might_sleep();
+ pse_control_put(phydev->psec);
+
fwnode_handle_put(dev->fwnode);
- kfree(to_phy_device(dev));
+ kfree(phydev);
}
static void phy_mdio_device_remove(struct mdio_device *mdiodev)
@@ -1102,11 +1113,103 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
}
EXPORT_SYMBOL(get_phy_device);
-/**
- * phy_device_register - Register the phy device on the MDIO bus
- * @phydev: phy_device structure to be added to the MDIO bus
+/* Best-effort attach of phydev->psec from a DT `pses = <&...>` phandle.
+ * Caller must hold rtnl. A missing phandle (-ENOENT) or a not-yet-registered
+ * controller (-EPROBE_DEFER) is silent; the notifier retries the latter at
+ * PSE_REGISTERED time. Any other error means a broken binding and is warned
+ * about, but left non-fatal so the phy still registers.
*/
-int phy_device_register(struct phy_device *phydev)
+static void phy_try_attach_pse(struct phy_device *phydev)
+{
+ struct pse_control *psec;
+ struct device_node *np;
+
+ ASSERT_RTNL();
+
+ np = phydev->mdio.dev.of_node;
+ if (!np)
+ return;
+
+ if (phydev->psec)
+ return;
+
+ psec = of_pse_control_get(np, phydev);
+ if (IS_ERR(psec)) {
+ if (PTR_ERR(psec) != -EPROBE_DEFER && PTR_ERR(psec) != -ENOENT)
+ phydev_warn(phydev, "failed to get PSE control: %pe\n",
+ psec);
+ return;
+ }
+
+ phydev->psec = psec;
+}
+
+static int phy_pse_attach_one(struct device *dev, void *data __maybe_unused)
+{
+ ASSERT_RTNL();
+
+ if (dev->type != &mdio_bus_phy_type)
+ return 0;
+
+ phy_try_attach_pse(to_phy_device(dev));
+ return 0;
+}
+
+static int phy_pse_detach_one(struct device *dev, void *data)
+{
+ struct pse_controller_dev *pcdev = data;
+ struct phy_device *phydev;
+ struct pse_control *psec;
+
+ ASSERT_RTNL();
+
+ if (dev->type != &mdio_bus_phy_type)
+ return 0;
+
+ phydev = to_phy_device(dev);
+ psec = phydev->psec;
+ if (!psec || !pse_control_matches_pcdev(psec, pcdev))
+ return 0;
+
+ phydev->psec = NULL;
+ pse_control_put(psec);
+ return 0;
+}
+
+static int phy_pse_notifier_event(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ switch (event) {
+ case PSE_REGISTERED:
+ rtnl_lock();
+ bus_for_each_dev(&mdio_bus_type, NULL, NULL,
+ phy_pse_attach_one);
+ rtnl_unlock();
+ return NOTIFY_OK;
+ case PSE_UNREGISTERED:
+ rtnl_lock();
+ bus_for_each_dev(&mdio_bus_type, NULL, data,
+ phy_pse_detach_one);
+ rtnl_unlock();
+ return NOTIFY_OK;
+ default:
+ return NOTIFY_DONE;
+ }
+}
+
+static struct notifier_block phy_pse_notifier __read_mostly = {
+ .notifier_call = phy_pse_notifier_event,
+};
+
+/* Core registration: add the phy to the MDIO bus. Does not touch rtnl or
+ * PSE. phydev->psec is attached by the callers below, after device_add()
+ * has made the phy visible on mdio_bus_type, so that a concurrent PSE
+ * notifier walk and the attach can never leave the phy unattached. Keeping
+ * device_add() out of rtnl also avoids deadlocking when binding a phy that
+ * itself provides an SFP cage (phy_probe() -> phy_sfp_probe() ->
+ * sfp_bus_add_upstream() takes rtnl).
+ */
+static int __phy_device_register(struct phy_device *phydev)
{
int err;
@@ -1135,10 +1238,54 @@ int phy_device_register(struct phy_device *phydev)
out:
/* Assert the reset signal */
phy_device_reset(phydev, 1);
-
mdiobus_unregister_device(&phydev->mdio);
return err;
}
+
+/**
+ * phy_device_register_locked - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Same as phy_device_register() but caller must already hold rtnl_lock().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register_locked(struct phy_device *phydev)
+{
+ int err;
+
+ ASSERT_RTNL();
+
+ err = __phy_device_register(phydev);
+ if (err)
+ return err;
+
+ phy_try_attach_pse(phydev);
+
+ return 0;
+}
+EXPORT_SYMBOL(phy_device_register_locked);
+
+/**
+ * phy_device_register - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register(struct phy_device *phydev)
+{
+ int err;
+
+ err = __phy_device_register(phydev);
+ if (err)
+ return err;
+
+ rtnl_lock();
+ phy_try_attach_pse(phydev);
+ rtnl_unlock();
+
+ return 0;
+}
EXPORT_SYMBOL(phy_device_register);
/**
@@ -1152,8 +1299,6 @@ EXPORT_SYMBOL(phy_device_register);
void phy_device_remove(struct phy_device *phydev)
{
unregister_mii_timestamper(phydev->mii_ts);
- pse_control_put(phydev->psec);
-
device_del(&phydev->mdio.dev);
/* Assert the reset signal */
@@ -3981,8 +4126,14 @@ static int __init phy_init(void)
if (rc)
goto err_c45;
+ rc = pse_register_notifier(&phy_pse_notifier);
+ if (rc)
+ goto err_genphy;
+
return 0;
+err_genphy:
+ phy_driver_unregister(&genphy_driver);
err_c45:
phy_driver_unregister(&genphy_c45_driver);
err_ethtool_phy_ops:
@@ -3999,6 +4150,7 @@ static int __init phy_init(void)
static void __exit phy_exit(void)
{
+ pse_unregister_notifier(&phy_pse_notifier);
phy_driver_unregister(&genphy_c45_driver);
phy_driver_unregister(&genphy_driver);
rtnl_lock();
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 03bfd8640db9..18868bdd6485 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2083,7 +2083,7 @@ static int sfp_sm_probe_phy(struct sfp *sfp, int addr, bool is_c45)
/* Mark this PHY as being on a SFP module */
phy->is_on_sfp_module = true;
- err = phy_device_register(phy);
+ err = phy_device_register_locked(phy);
if (err) {
phy_device_free(phy);
dev_err(sfp->dev, "phy_device_register failed: %pe\n",
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 0190fac33c78..611540df43bb 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -2021,3 +2021,17 @@ bool pse_has_c33(struct pse_control *psec)
return psec->pcdev->types & ETHTOOL_PSE_C33;
}
EXPORT_SYMBOL_GPL(pse_has_c33);
+
+/**
+ * pse_control_matches_pcdev - Test whether a pse_control targets a controller
+ * @psec: pse_control obtained from of_pse_control_get()
+ * @pcdev: PSE controller to compare against
+ *
+ * Return: %true if @psec was obtained from @pcdev, %false otherwise.
+ */
+bool pse_control_matches_pcdev(struct pse_control *psec,
+ struct pse_controller_dev *pcdev)
+{
+ return psec->pcdev == pcdev;
+}
+EXPORT_SYMBOL_GPL(pse_control_matches_pcdev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 199a7aaa341b..865b9baddb85 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -2158,6 +2158,8 @@ struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode);
struct fwnode_handle *fwnode_get_phy_node(const struct fwnode_handle *fwnode);
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
int phy_device_register(struct phy_device *phy);
+/* Caller must hold rtnl_lock(); see phy_device_register() for the public form. */
+int phy_device_register_locked(struct phy_device *phy);
void phy_device_free(struct phy_device *phydev);
void phy_device_remove(struct phy_device *phydev);
int phy_get_c45_ids(struct phy_device *phydev);
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 78fe3a2b1ea8..d4310ca71a3e 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -385,6 +385,9 @@ int pse_ethtool_set_prio(struct pse_control *psec,
bool pse_has_podl(struct pse_control *psec);
bool pse_has_c33(struct pse_control *psec);
+bool pse_control_matches_pcdev(struct pse_control *psec,
+ struct pse_controller_dev *pcdev);
+
int pse_register_notifier(struct notifier_block *nb);
int pse_unregister_notifier(struct notifier_block *nb);
@@ -438,6 +441,12 @@ static inline bool pse_has_c33(struct pse_control *psec)
return false;
}
+static inline bool pse_control_matches_pcdev(struct pse_control *psec,
+ struct pse_controller_dev *pcdev)
+{
+ return false;
+}
+
static inline int pse_register_notifier(struct notifier_block *nb)
{
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v4 0/3] net: pse-pd: decouple controller lookup from MDIO probe
From: Carlo Szelinsky @ 2026-06-30 9:11 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Corey Leavitt, Jonas Jelonek, Simon Horman, netdev, linux-kernel,
Carlo Szelinsky
This is v4 of Corey's series [1]. It takes the PSE controller lookup out
of the MDIO probe path, so a modular PSE driver no longer makes the
PHY/DSA probe spin on -EPROBE_DEFER until the PSE module loads.
The old patch 1 (a regulator handle fix) went to net on its own [2], so
this series is just the three notifier patches for net-next.
v3 [4] was posted during the merge window and deferred; net-next has
reopened, so here it is again, now with Jonas's Tested-by.
How it works: pse_core gets a notifier chain (REGISTERED / UNREGISTERED).
The phy layer subscribes, owns phydev->psec, and attaches the PSE handle
when the controller shows up instead of during probe. fwnode_mdio loses
its PSE awareness, so no -EPROBE_DEFER leaves it and the probe-retry loop
is gone.
Tested on a Realtek rtl93xx PoE switch with two HS104 PSE controllers on
i2c:
- clean boot, no probe-retry loop, no watchdog reset
- 10G SFP+ port: module hotplug works, no deadlock
- ethtool --set-pse enable/disable cuts and restores power to a PD
- i2c unbind -> rmmod -> modprobe: PSE detaches on unbind and re-attaches
on reload with power restored, no reboot. No lockdep splats.
Jonas confirmed the RTL8214FC deadlock he reported is gone.
Tested-by: Carlo Szelinsky <github@szelinsky.de>
Changes in v4:
- Add Tested-by from Jonas Jelonek. No code changes.
- Repost now that net-next has reopened (v3 was deferred during the
merge window).
Changes in v3:
- Drop patch 1 (regulator handle fix); it goes to net separately [2].
- Rebase on net-next. No code changes to the three patches.
v1 was an RFC by Corey [3].
[1] https://lore.kernel.org/netdev/20260620112440.1734404-1-github@szelinsky.de/
[2] https://lore.kernel.org/netdev/20260624204017.2752934-1-github@szelinsky.de/
[3] https://lore.kernel.org/netdev/20260423-pse-notifier-decouple-v1-0-86ed750a9d62@leavitt.info/
[4] https://lore.kernel.org/netdev/20260626165929.2908782-1-github@szelinsky.de/
Corey Leavitt (3):
net: pse-pd: add notifier chain for controller lifecycle events
net: pse-pd: fire lifecycle events on controller register/unregister
net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio
hook
drivers/net/mdio/fwnode_mdio.c | 34 -------
drivers/net/phy/phy_device.c | 168 +++++++++++++++++++++++++++++++--
drivers/net/phy/sfp.c | 2 +-
drivers/net/pse-pd/pse_core.c | 54 +++++++++++
include/linux/phy.h | 2 +
include/linux/pse-pd/pse.h | 41 ++++++++
6 files changed, 258 insertions(+), 43 deletions(-)
base-commit: cef9d6804030793cf8b8796fd6936197d065dd3e
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Krzysztof Kozlowski @ 2026-06-30 9:09 UTC (permalink / raw)
To: Konrad Dybcio, George Moussalem, Kathiravan Thirumoorthy
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <7348d7e6-18b3-4064-9fb2-932cce76816e@oss.qualcomm.com>
On 30/06/2026 11:06, Konrad Dybcio wrote:
> On 6/30/26 9:15 AM, Krzysztof Kozlowski wrote:
>> On Mon, Jun 29, 2026 at 05:01:44PM +0400, George Moussalem wrote:
>>> +unevaluatedProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> + #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
>>> +
>>> + bluetooth {
>>
>> Don't send new versions while discussion is still going. I need to
>> repeat my question - what bus does that sit on?
>>
>> Device nodes represent real devices. Real devices sit on a bus, usually.
>> Do you have here a bus?
>
> +Kathiravan would you know what the remoteproc-driven bluetooth is
> connected over on IPQ5018?
No need, this got resolved. I missed that this was merged with
remoteproc and remoteprocs we represent in top-level as it uses non-bus
way (APCS IPC or whatever its called). We could fix that and maybe this
should be a child of APCS... but maybe not and it feels like out of
scope of this patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Konrad Dybcio @ 2026-06-30 9:06 UTC (permalink / raw)
To: Krzysztof Kozlowski, George Moussalem, Kathiravan Thirumoorthy
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260630-wondrous-lean-stoat-be0b9a@quoll>
On 6/30/26 9:15 AM, Krzysztof Kozlowski wrote:
> On Mon, Jun 29, 2026 at 05:01:44PM +0400, George Moussalem wrote:
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
>> +
>> + bluetooth {
>
> Don't send new versions while discussion is still going. I need to
> repeat my question - what bus does that sit on?
>
> Device nodes represent real devices. Real devices sit on a bus, usually.
> Do you have here a bus?
+Kathiravan would you know what the remoteproc-driven bluetooth is
connected over on IPQ5018?
Konrad
^ permalink raw reply
* RE: [PATCH net] tipc: make sure bc_rcvlink is not dereferenced with NULL value
From: Tung Quang Nguyen @ 2026-06-30 9:00 UTC (permalink / raw)
To: Markov Gleb
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org,
Jon Maloy
In-Reply-To: <20260629130942.469-1-markov.gi@npc-ksb.ru>
>Subject: [PATCH net] tipc: make sure bc_rcvlink is not dereferenced with NULL
>value
>
>From: Gleb Markov <markov.gi@npc-ksb.ru>
>
>The direct dependence of the tipc_link_is_up() value on l->bc_rcvlink is not
>explicitly specified.
>
>If link is up, it is assumed that the sender and receiver have valid values
>(communication with the receiver is required for timeout synchronization),
>which is not guaranteed in this code segment.
>
>Turning independent conditions into nested conditions ensures that NULL
>cannot be dereferenced at tipc_link_build_proto_msg() and allows for the
>logical structure to be fixed at the functional interaction level.
>
>Make tipc_link_build_proto_msg() call only if l->bc_rcvlink is not NULL.
>
>Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
>Fixes: 047491ea334a ("tipc: set link tolerance correctly in broadcast link")
>Signed-off-by: Gleb Markov <markov.gi@npc-ksb.ru>
>---
> net/tipc/link.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/net/tipc/link.c b/net/tipc/link.c index 49dfc098d89b..b0a640c419c8
>100644
>--- a/net/tipc/link.c
>+++ b/net/tipc/link.c
>@@ -2863,10 +2863,12 @@ void tipc_link_set_tolerance(struct tipc_link *l,
>u32 tol,
> struct sk_buff_head *xmitq)
> {
> l->tolerance = tol;
>- if (l->bc_rcvlink)
>+ if (l->bc_rcvlink) {
> l->bc_rcvlink->tolerance = tol;
>- if (tipc_link_is_up(l))
>- tipc_link_build_proto_msg(l, STATE_MSG, 0, 0, 0, tol, 0, xmitq);
>+ if (tipc_link_is_up(l))
>+ tipc_link_build_proto_msg(l, STATE_MSG,
>+ 0, 0, 0, tol, 0, xmitq);
>+ }
This is not correct and redundant because:
1. ' l->bc_rcvlink' is non-NULL for any unicast link. Checking of ' l->bc_rcvlink' is even redundant in current code.
2. Checking of 'tipc_link_is_up(l)' does not depend on ' l->bc_rcvlink'. It just verifies if the unicast link is UP to populate the new tolerance to its peer.
> }
>
> void tipc_link_set_prio(struct tipc_link *l, u32 prio,
>--
>2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 0/5] netfilter: nf_flow_table_path: L2 bridge offload
From: Pablo Neira Ayuso @ 2026-06-30 8:45 UTC (permalink / raw)
To: Daniel Pawlik
Cc: netfilter-devel, netdev, fw, phil, davem, edumazet, kuba, pabeni,
horms, andrew+netdev, razor, idosch, matthias.bgg,
angelogioacchino.delregno, bridge, coreteam, linux-mediatek,
linux-arm-kernel, rchen14b, lorenzo
In-Reply-To: <20260630065735.3341614-1-pawlik.dan@gmail.com>
Hi,
On Tue, Jun 30, 2026 at 08:57:30AM +0200, Daniel Pawlik wrote:
> This series adds L2 bridge offload support to nft_flow_offload, allowing
> bridged IPv4/IPv6 flows to be accelerated by the flowtable fast path
> without requiring L3 routing.
>
> Background
> ----------
> Hardware flow offload engines (e.g. MediaTek PPE) can accelerate bridged
> traffic but require that nft_flow_offload detect and handle bridged flows
> differently from routed ones: no routing table lookup, MAC addresses from
> the Ethernet header, and VLAN context pre-populated from the bridge port.
>
> v2: Fix missing Returns: tags in kernel-doc comments for the three new
> bridge helpers (br_fdb_has_forwarding_entry_rcu,
> br_vlan_get_offload_info_rcu, br_vlan_is_enabled_rcu).
>
> Patches
> -------
> 1/5 net: export __dev_fill_forward_path
> Refactors dev_fill_forward_path() to expose __dev_fill_forward_path()
> which accepts a caller-supplied net_device_path_ctx, needed to
> pre-populate VLAN state before the forward path walk.
>
> 2/5 net: bridge: add flow offload helpers
> Adds br_fdb_has_forwarding_entry_rcu(), br_vlan_get_offload_info_rcu()
> and br_vlan_is_enabled_rcu() to expose bridge state to nft_flow_offload
> without requiring inclusion of net/bridge/br_private.h.
>
> 3/5 netfilter: nf_flow_table_path: add L2 bridge offload
> Core of the series. Adds nft_flow_offload_is_bridging() detection,
> nft_flow_route_bridging() which avoids nf_route() (fails for
> bridged-only subnets), MAC/VLAN pre-population for bridged flows,
> and a dst leak fix. nft_flow_route() becomes a thin dispatcher.
>
> 4/5 netfilter: nf_flow_table_path: handle DEV_PATH_MTK_WDMA in path info
> Fixes zero-source-MAC in PPE entries when a bridged flow traverses
> MT7996/MT7915 WiFi WDMA hardware.
>
> 5/5 netfilter: nf_flow_table_path: add VLAN passthrough support
> Records VLAN encap info for passthrough-mode bridge ports so hardware
> offload entries include the correct VLAN tag.
>
> Rebase note
> -----------
> Originally developed against OpenWrt pending-6.18 patches by Ryan Chen
> <rchen14b@gmail.com> and Bo-Cun Chen <bc-bocun.chen@mediatek.com>.
> Rebased to current upstream: path discovery infrastructure moved to
> nf_flow_table_path.c in commit 93d7a7ed0734 ("netfilter: flowtable: move
> path discovery infrastructure to its own file"), so all netfilter changes
> now land in that file rather than nft_flow_offload.c.
>
> How to enable bridge offload
> -----------------------------
> 1. Load kmod-br-netfilter so that bridged IP traffic traverses the
> netfilter forward chain.
>
> 2. Enable netfilter hooks on the bridge:
> echo 1 > /sys/class/net/<br>/bridge/nf_call_iptables
> echo 1 > /sys/class/net/<br>/bridge/nf_call_ip6tables
This requires br_netfilter which is a no go.
Sorry, but we should really target at the native nf_conntrack_bridge
support.
> 3. Register bridge member interfaces in the nft flowtable:
> table inet filter {
> flowtable f {
> hook ingress priority filter
> devices = { eth0, wlan0 }
> }
> chain forward {
> type filter hook forward priority filter
> meta l4proto { tcp, udp } flow add @f
> }
> }
Yes, but br_netfilter makes no sense for nftables.
br_netfilter was made to fill gap at the time ebtables was lagging a
lot behind iptables in terms of features. And getting ebtables on pair
with iptables in functionality was not feasible either, because it
required many new extensions that were specific of the bridge family,
which probably was not a big deal, but it also required to get
the ebtables command line tool on pair with iptables userspace, which
has received more development attention/effort that the bridge tool.
All of this does not stand true anymore with nftables, where the
bridge family capabilities are at pair with the inet families.
I am looking now at the native flowtable bridge support, I will get
back to you with updates.
^ permalink raw reply
* [PATCH v2 net-next] ipv4: fib: fix route re-dump in inet_dump_fib() on multi-batch dump
From: Pengfei Zhang @ 2026-06-30 8:42 UTC (permalink / raw)
To: dsahern, idosch
Cc: davem, edumazet, kuba, pabeni, horms, netdev, linux-kernel,
chenzhangqi, baohua, zhangpengfei16, Pengfei Zhang
inet_dump_fib() saves its progress in cb->args[1] as a positional
index within the current hash chain. Between batches, a concurrent
fib_new_table() can insert a new table at the chain head, shifting
all existing entries. On resume the saved index lands on a different
table, causing already-dumped tables to be re-dumped and the
originally suspended table to restart from the beginning.
Fix by storing tb->tb_id in cb->args[1] instead of a positional
index, mirroring the fix applied to inet6_dump_fib() in commit
9facb861dc6b ("ipv6: fib6: fix NULL deref in fib6_walk_continue()
on multi-batch dump").
Signed-off-by: Pengfei Zhang <zhangfeionline@gmail.com>
---
v2:
- Drop Fixes tag (not needed for net-next)
- Fix variable declaration order (reverse xmas tree)
- Reference IPv6 fix commit hash
v1: https://lore.kernel.org/netdev/20260626085636.1524451-1-zhangfeionline@gmail.com/
net/ipv4/fib_frontend.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 42212970d..248895e7e 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1019,10 +1019,11 @@ static int inet_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
.dump_routes = true,
.dump_exceptions = true,
};
- unsigned int e = 0, s_e, h, s_h;
struct hlist_head *head;
int dumped = 0, err = 0;
struct fib_table *tb;
+ unsigned int h, s_h;
+ u32 s_id;
rcu_read_lock();
if (cb->strict_check) {
@@ -1054,29 +1055,28 @@ static int inet_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
}
s_h = cb->args[0];
- s_e = cb->args[1];
+ s_id = cb->args[1];
err = 0;
- for (h = s_h; h < FIB_TABLE_HASHSZ; h++, s_e = 0) {
- e = 0;
+ for (h = s_h; h < FIB_TABLE_HASHSZ; h++, s_id = 0) {
head = &net->ipv4.fib_table_hash[h];
hlist_for_each_entry_rcu(tb, head, tb_hlist) {
- if (e < s_e)
- goto next;
+ if (s_id && tb->tb_id != s_id)
+ continue;
+
+ s_id = 0;
if (dumped)
memset(&cb->args[2], 0, sizeof(cb->args) -
2 * sizeof(cb->args[0]));
+ cb->args[1] = tb->tb_id;
err = fib_table_dump(tb, skb, cb, &filter);
if (err < 0)
goto out;
dumped = 1;
-next:
- e++;
}
}
out:
- cb->args[1] = e;
cb->args[0] = h;
unlock:
--
2.54.0
^ permalink raw reply related
* [PATCH] bpf: Fix smp_processor_id() call trace for preemptible kernels
From: Edward Adam Davis @ 2026-06-30 8:41 UTC (permalink / raw)
To: syzbot+fd7e415d891073b83e1f
Cc: andrii, ast, bpf, daniel, eddyz87, emil, jolsa, linux-kernel,
martin.lau, memxor, netdev, song, syzkaller-bugs, yonghong.song
In-Reply-To: <6a436023.b42ede87.8e801.0003.GAE@google.com>
bpf_mem_cache_free_rcu() maybe called in preemptible context, this
will trigger the below warning message:
BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
Call Trace:
check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
__rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
__sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1
this_cpu_ptr() calls smp_processor_id() in a preemptible context.
Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.
Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
kernel/bpf/memalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/memalloc.c b/kernel/bpf/memalloc.c
index bd45dda9dc35..151d9c8183bc 100644
--- a/kernel/bpf/memalloc.c
+++ b/kernel/bpf/memalloc.c
@@ -957,7 +957,7 @@ void notrace bpf_mem_cache_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
if (!ptr)
return;
- unit_free_rcu(this_cpu_ptr(ma->cache), ptr);
+ unit_free_rcu(per_cpu_ptr(ma->cache, raw_smp_processor_id()), ptr);
}
/* Directly does a kfree() without putting 'ptr' back to the free_llist
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] cxgb4: Fix decode strings dump for T6 adapters
From: Potnuri Bharat Teja @ 2026-06-30 8:35 UTC (permalink / raw)
To: Markov Gleb
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, open list,
lvc-project@linuxtesting.org
In-Reply-To: <20260629130856.1168-1-markov.gi@npc-ksb.ru>
On Monday, June 06/29/26, 2026 at 18:38:54 +0530, Markov Gleb wrote:
> From: Gleb Markov <markov.gi@npc-ksb.ru>
>
> Depending on the value of chip_version, the correct decode set is selected.
> However, the subsequent matching with the t4 encoding type in the if-else
> block results in a reassignment, which leads to the loss of support for
> t6_decode as well as reinitializing of values t4_decode and t5_decode.
>
> The component history shows that the if-else block previously used for
> this purpose, as well as the execution order, was not affected by the
> change.
> Furthermore, it is suggested by the execution order that the scenario with
> overwriting and loss of support will be implemented.
>
> Delete the if-else block.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: 6df397539cb0 ("cxgb4: Update correct encoding of SGE Ingress DMA States for T6 adapter")
> Signed-off-by: Gleb Markov <markov.gi@npc-ksb.ru>
> ---
Thank you, This redundant code can be removed.
Reviewed-by: Potnuri Bharat Teja <bharat@chelsio.com>
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
> index 8d719f82854a..f3e8153a7a0b 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
> @@ -6735,14 +6735,6 @@ void t4_sge_decode_idma_state(struct adapter *adapter, int state)
> return;
> }
>
> - if (is_t4(adapter->params.chip)) {
> - sge_idma_decode = (const char **)t4_decode;
> - sge_idma_decode_nstates = ARRAY_SIZE(t4_decode);
> - } else {
> - sge_idma_decode = (const char **)t5_decode;
> - sge_idma_decode_nstates = ARRAY_SIZE(t5_decode);
> - }
> -
> if (state < sge_idma_decode_nstates)
> CH_WARN(adapter, "idma state %s\n", sge_idma_decode[state]);
> else
> --
> 2.43.0
>
>
^ permalink raw reply
* [PATCH net-next] net: phylink: Drop references to the .validate() method in comments
From: Maxime Chevallier @ 2026-06-30 8:37 UTC (permalink / raw)
To: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni
The phylink_mac_ops '.validate()' has been removed in:
commit da5f6b80ad64 ("net: phylink: remove .validate() method")
There are still a few comments around in phylink that references that,
related to the ports fields as well as the Pause configuration. Let's
drop these references and update the comments related to Pause handling.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/phy/phylink.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 087ac63f9193..59dfe35afa54 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -153,8 +153,7 @@ static DECLARE_PHY_INTERFACE_MASK(phylink_sfp_interfaces);
* phylink_set_port_modes() - set the port type modes in the ethtool mask
* @mask: ethtool link mode mask
*
- * Sets all the port type modes in the ethtool mask. MAC drivers should
- * use this in their 'validate' callback.
+ * Sets all the port type modes in the ethtool mask.
*/
void phylink_set_port_modes(unsigned long *mask)
{
@@ -2095,9 +2094,9 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
/*
* This is the new way of dealing with flow control for PHYs,
* as described by Timur Tabi in commit 529ed1275263 ("net: phy:
- * phy drivers should not set SUPPORTED_[Asym_]Pause") except
- * using our validate call to the MAC, we rely upon the MAC
- * clearing the bits from both supported and advertising fields.
+ * phy drivers should not set SUPPORTED_[Asym_]Pause"). MAC drivers
+ * set their support using the MAC_SYM_PAUSE and MAC_ASYM_PAUSE
+ * capabilities and must NOT change the phy's pause settings directly.
*/
phy_support_asym_pause(phy);
@@ -3931,9 +3930,9 @@ static int phylink_sfp_connect_phy(void *upstream, struct phy_device *phy)
/*
* This is the new way of dealing with flow control for PHYs,
* as described by Timur Tabi in commit 529ed1275263 ("net: phy:
- * phy drivers should not set SUPPORTED_[Asym_]Pause") except
- * using our validate call to the MAC, we rely upon the MAC
- * clearing the bits from both supported and advertising fields.
+ * phy drivers should not set SUPPORTED_[Asym_]Pause"). MAC drivers
+ * set their support using the MAC_SYM_PAUSE and MAC_ASYM_PAUSE
+ * capabilities and must NOT change the phy's pause settings directly.
*/
phy_support_asym_pause(phy);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 3/7] cpufreq: rcpufreq_dt: use vertical import style
From: Miguel Ojeda @ 2026-06-30 8:35 UTC (permalink / raw)
To: Zhongqiu Han
Cc: Guru Das Srinagesh, Miguel Ojeda, rust-for-linux, linux-kernel,
Danilo Krummrich, Abdiel Janulgue, Daniel Almeida, Robin Murphy,
Andreas Hindborg, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Drew Fustini, Guo Ren, Fu Wei,
Michal Wilczynski, Uwe Kleine-König, Rafael J. Wysocki,
Viresh Kumar, Jens Axboe, FUJITA Tomonori, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, David Airlie, Simona Vetter,
driver-core, linux-riscv, linux-pwm, linux-pm, linux-block,
netdev, nova-gpu, dri-devel
In-Reply-To: <f0ed588a-6cfb-4079-a2fe-7c14f1b42727@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 2:43 PM Zhongqiu Han
<zhongqiu.han@oss.qualcomm.com> wrote:
>
> If the preferred style is to place each imported item on its own line,
> shouldn't imports such as
>
> cpu, cpufreq,
>
> be formatted similarly as well?
Indeed, good eyes.
To do what we want, `rustfmt` needs the `//` at the end of that level
too (in the future, it will be without the `//`), i.e. the patch
probably passes `rustfmtcheck`, but it still needs to split that line
and add the other `//`.
Cheers,
Miguel
^ permalink raw reply
* [PATCH 5.10.y] net/sched: fix pedit partial COW leading to page cache corruption
From: Dominique Martinet @ 2026-06-30 8:27 UTC (permalink / raw)
To: dominique.martinet, stable
Cc: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller,
Jakub Kicinski, Mat Martineau, Paolo Abeni, netdev, linux-kernel,
Rajat Gupta, Yiming Qian, Keenan Dong, Han Guidong, Zhang Cen,
Davide Caratti, Toke Høiland-Jørgensen, Victor Nogueira
In-Reply-To: <20260630-cve-2026-46331-v1-1-c1986f356f26@atmark-techno.com>
From: Rajat Gupta <rajat.gupta@oss.qualcomm.com>
[ Upstream commit 899ee91156e57784090c5565e4f31bd7dbffbc5a ]
tcf_pedit_act() computes the COW range for skb_ensure_writable()
once before the key loop using tcfp_off_max_hint, but the hint does
not account for the runtime header offset added by typed keys. This
can leave part of the write region un-COW'd.
Fix by moving skb_ensure_writable() inside the per-key loop where
the actual write offset is known, and add overflow checking on the
offset arithmetic. For negative offsets (e.g. Ethernet header edits
at ingress), use skb_cow() to COW the headroom instead. Guard
offset_valid() against INT_MIN, where negation is undefined.
Fixes: 8b796475fd78 ("net/sched: act_pedit: really ensure the skb is writable")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Reported-by: Keenan Dong <keenanat2000@gmail.com>
Reported-by: Han Guidong <2045gemini@gmail.com>
Reported-by: Zhang Cen <rollkingzzc@gmail.com>
Reviewed-by: Han Guidong <2045gemini@gmail.com>
Tested-by: Han Guidong <2045gemini@gmail.com>
Reviewed-by: Davide Caratti <dcaratti@redhat.com>
Tested-by: Davide Caratti <dcaratti@redhat.com>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Tested-by: Toke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Tested-by: Victor Nogueira <victor@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Rajat Gupta <rajat.gupta@oss.qualcomm.com>
Link: https://patch.msgid.link/20260531123221.48732-1-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[Dominique: plenty of context conflict but the code itself could still
mostly be used]
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
---
(Sorry for double-send to stable@vger, I hadn't intended to send the
Cc-free version...)
CVE-2026-46331 got attention and I've had to backport this to 5.10, so
here we are, this should fix it.
Unfortunately there are more conflicts with 5.15 so I didn't do this
one (but if anyone cares older 5.4/4.19 cherry-picks cleanly from this,
they're no longer stable kernels so I won't bother sending)
I've tested in egress with a trivial rule redirecting port inspired from
the man page (and checking on target with tcpdump because return path is
broken), so I hopefully didn't botch this too badly:
tc qdisc replace dev eth0 root handle 1: htb
tc filter add dev eth0 parent 1: u32 match ip dport 23 0xffff action pedit pedit munge ip dport set 22
---
include/net/tc_act/tc_pedit.h | 1 -
net/sched/act_pedit.c | 84 ++++++++++++++++++++++---------------------
2 files changed, 43 insertions(+), 42 deletions(-)
diff --git a/include/net/tc_act/tc_pedit.h b/include/net/tc_act/tc_pedit.h
index 3e02709a1df656931942be4851a115dd6bef8b4c..748cf87a4d7ea5c92b4fd48dd3302b8ad64944fe 100644
--- a/include/net/tc_act/tc_pedit.h
+++ b/include/net/tc_act/tc_pedit.h
@@ -14,7 +14,6 @@ struct tcf_pedit {
struct tc_action common;
unsigned char tcfp_nkeys;
unsigned char tcfp_flags;
- u32 tcfp_off_max_hint;
struct tc_pedit_key *tcfp_keys;
struct tcf_pedit_key_ex *tcfp_keys_ex;
};
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index a44101b2f441919b7d4b0be177aa735a3c547350..cebeed6214558b1e1dd717b411c9ffa108a2293d 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -14,6 +14,8 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
+#include <linux/overflow.h>
+#include <asm/unaligned.h>
#include <net/netlink.h>
#include <net/pkt_sched.h>
#include <linux/tc_act/tc_pedit.h>
@@ -229,21 +231,11 @@ static int tcf_pedit_init(struct net *net, struct nlattr *nla,
p->tcfp_nkeys = parm->nkeys;
}
memcpy(p->tcfp_keys, parm->keys, ksize);
- p->tcfp_off_max_hint = 0;
for (i = 0; i < p->tcfp_nkeys; ++i) {
- u32 cur = p->tcfp_keys[i].off;
-
/* sanitize the shift value for any later use */
p->tcfp_keys[i].shift = min_t(size_t, BITS_PER_TYPE(int) - 1,
p->tcfp_keys[i].shift);
- /* The AT option can read a single byte, we can bound the actual
- * value with uchar max.
- */
- cur += (0xff & p->tcfp_keys[i].offmask) >> p->tcfp_keys[i].shift;
-
- /* Each key touches 4 bytes starting from the computed offset */
- p->tcfp_off_max_hint = max(p->tcfp_off_max_hint, cur + 4);
}
p->tcfp_flags = parm->flags;
@@ -277,15 +269,12 @@ static void tcf_pedit_cleanup(struct tc_action *a)
kfree(p->tcfp_keys_ex);
}
-static bool offset_valid(struct sk_buff *skb, int offset)
+static bool offset_valid(struct sk_buff *skb, int offset, int len)
{
- if (offset > 0 && offset > skb->len)
+ if (offset < -(int)skb_headroom(skb))
return false;
- if (offset < 0 && -offset > skb_headroom(skb))
- return false;
-
- return true;
+ return offset <= (int)skb->len - len;
}
static int pedit_skb_hdr_offset(struct sk_buff *skb,
@@ -325,18 +314,10 @@ static int tcf_pedit_act(struct sk_buff *skb, const struct tc_action *a,
struct tcf_result *res)
{
struct tcf_pedit *p = to_pedit(a);
- u32 max_offset;
int i;
spin_lock(&p->tcf_lock);
- max_offset = (skb_transport_header_was_set(skb) ?
- skb_transport_offset(skb) :
- skb_network_offset(skb)) +
- p->tcfp_off_max_hint;
- if (skb_ensure_writable(skb, min(skb->len, max_offset)))
- goto unlock;
-
tcf_lastuse_update(&p->tcf_tm);
if (p->tcfp_nkeys > 0) {
@@ -347,10 +328,11 @@ static int tcf_pedit_act(struct sk_buff *skb, const struct tc_action *a,
enum pedit_cmd cmd = TCA_PEDIT_KEY_EX_CMD_SET;
for (i = p->tcfp_nkeys; i > 0; i--, tkey++) {
- u32 *ptr, hdata;
+ int write_offset, write_len;
int offset = tkey->off;
int hoffset;
- u32 val;
+ u32 cur_val, val;
+ u32 *ptr;
int rc;
if (tkey_ex) {
@@ -369,13 +351,15 @@ static int tcf_pedit_act(struct sk_buff *skb, const struct tc_action *a,
if (tkey->offmask) {
u8 *d, _d;
+ int at_offset;
- if (!offset_valid(skb, hoffset + tkey->at)) {
- pr_info("tc action pedit 'at' offset %d out of bounds\n",
- hoffset + tkey->at);
+ if (check_add_overflow(hoffset, (int)tkey->at, &at_offset) ||
+ !offset_valid(skb, at_offset, sizeof(_d))) {
+ pr_info_ratelimited("tc action pedit 'at' offset %d out of bounds\n",
+ hoffset + tkey->at);
goto bad;
}
- d = skb_header_pointer(skb, hoffset + tkey->at,
+ d = skb_header_pointer(skb, at_offset,
sizeof(_d), &_d);
if (!d)
goto bad;
@@ -387,23 +371,44 @@ static int tcf_pedit_act(struct sk_buff *skb, const struct tc_action *a,
goto bad;
}
- if (!offset_valid(skb, hoffset + offset)) {
- pr_info("tc action pedit offset %d out of bounds\n",
- hoffset + offset);
+ if (check_add_overflow(hoffset, offset, &write_offset)) {
+ pr_info_ratelimited("tc action pedit offset overflow\n");
goto bad;
}
- ptr = skb_header_pointer(skb, hoffset + offset,
- sizeof(hdata), &hdata);
- if (!ptr)
+ if (!offset_valid(skb, write_offset, sizeof(*ptr))) {
+ pr_info_ratelimited("tc action pedit offset %d out of bounds\n",
+ write_offset);
goto bad;
+ }
+
+ if (write_offset < 0) {
+ if (skb_cow(skb, -write_offset))
+ goto bad;
+ if (write_offset + (int)sizeof(*ptr) > 0) {
+ if (skb_ensure_writable(skb,
+ min_t(int, skb->len,
+ write_offset + (int)sizeof(*ptr))))
+ goto bad;
+ }
+ } else {
+ if (check_add_overflow(write_offset, (int)sizeof(*ptr),
+ &write_len))
+ goto bad;
+ if (skb_ensure_writable(skb, min_t(int, skb->len,
+ write_len)))
+ goto bad;
+ }
+
+ ptr = (u32 *)(skb->data + write_offset);
+ cur_val = get_unaligned(ptr);
/* just do it, baby */
switch (cmd) {
case TCA_PEDIT_KEY_EX_CMD_SET:
val = tkey->val;
break;
case TCA_PEDIT_KEY_EX_CMD_ADD:
- val = (*ptr + tkey->val) & ~tkey->mask;
+ val = (cur_val + tkey->val) & ~tkey->mask;
break;
default:
pr_info("tc action pedit bad command (%d)\n",
@@ -411,9 +416,7 @@ static int tcf_pedit_act(struct sk_buff *skb, const struct tc_action *a,
goto bad;
}
- *ptr = ((*ptr & tkey->mask) ^ val);
- if (ptr == &hdata)
- skb_store_bits(skb, hoffset + offset, ptr, 4);
+ put_unaligned((cur_val & tkey->mask) ^ val, ptr);
}
goto done;
@@ -425,7 +428,6 @@ static int tcf_pedit_act(struct sk_buff *skb, const struct tc_action *a,
p->tcf_qstats.overlimits++;
done:
bstats_update(&p->tcf_bstats, skb);
-unlock:
spin_unlock(&p->tcf_lock);
return p->tcf_action;
}
---
base-commit: d9666dca97c01de1c7395ac53041634eb75120e2
change-id: 20260630-cve-2026-46331-4f851ccf8244
Best regards,
--
Dominique Martinet <dominique.martinet@atmark-techno.com>
^ permalink raw reply related
* Re: [PATCH v2 1/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Krzysztof Kozlowski @ 2026-06-30 8:20 UTC (permalink / raw)
To: george.moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260629-ipq5018-bluetooth-v2-1-02770f03b6bb@outlook.com>
On 29/06/2026 15:01, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
>
> Document the Qualcomm IPQ5018 Bluetooth controller.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> .../bindings/net/bluetooth/qcom,ipq5018-bt.yaml | 86 ++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Krzysztof Kozlowski @ 2026-06-30 8:20 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <SN7PR19MB6736BB58C4F6E648CB3910949DF72@SN7PR19MB6736.namprd19.prod.outlook.com>
On 30/06/2026 09:55, George Moussalem wrote:
> On 6/30/26 11:40, Krzysztof Kozlowski wrote:
>> On 30/06/2026 09:31, George Moussalem wrote:
>>> On 6/30/26 11:15, Krzysztof Kozlowski wrote:
>>>> On Mon, Jun 29, 2026 at 05:01:44PM +0400, George Moussalem wrote:
>>>>> +unevaluatedProperties: false
>>>>> +
>>>>> +examples:
>>>>> + - |
>>>>> + #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
>>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> + #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
>>>>> +
>>>>> + bluetooth {
>>>>
>>>> Don't send new versions while discussion is still going. I need to
>>>> repeat my question - what bus does that sit on?
>>>>
>>>> Device nodes represent real devices. Real devices sit on a bus, usually.
>>>> Do you have here a bus?
>>>
>>> I'm afraid I don't have a definitive answer. Again, my understanding
>>> based on downstream code is that the 'controller' is basically a Cortex
>>> M0 processor running Bluetooth firmware connected to an RF. Data
>>> transport is over a shared memory carveout with APPS signaling the
>>> controller through writes to an IPC mailbox register, while the
>>> controller has an interrupt line back to signal APPS.
>>
>> So this looks like should be squashed into remoteproc node. There is no
>> reason or no data to express it as two separate device nodes.
>
> In this version, I've squashed them into one already but as a Bluetooth
> controller as that's what the 'processor' is dedicated to, also in line
> with Bjorn's guidance to manage the lifecycle of this processor and all
> other resources in one. Kindly let me know if this approach is satisfactory.
>
I read changelog twice and only then found it mentions squashing it. I
suggest writing concise entries and drop all boiler plate like "As per
further review comments". I just ignore such paragraphs.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 5/9] block: implement NVMEM provider
From: Bartosz Golaszewski @ 2026-06-30 7:59 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, Christian Marangi
In-Reply-To: <20260629-block-as-nvmem-v6-5-f02513dcd46d@oss.qualcomm.com>
On Mon, 29 Jun 2026 10:55:24 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> From: Daniel Golle <daniel@makrotopia.org>
>
> On embedded devices using an eMMC it is common that one or more partitions
> on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM
> data. Allow referencing the partition in device tree for the kernel and
> Wi-Fi drivers accessing it via the NVMEM layer.
>
> For now, NVMEM is only registered for the whole disk block device, as the
> OF node is currently only associated to it.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Co-developed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> block/Kconfig | 9 ++++
> block/Makefile | 1 +
> block/blk-nvmem.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++
> block/blk.h | 8 ++++
> block/genhd.c | 4 ++
> include/linux/blk_types.h | 3 ++
> include/linux/blkdev.h | 1 +
> 7 files changed, 137 insertions(+)
>
> diff --git a/block/Kconfig b/block/Kconfig
> index 15027963472d7b40e27b9097a5993c457b5b3054..0b33747e16dc33473683706f75c92bdf8b648f7c 100644
> --- a/block/Kconfig
> +++ b/block/Kconfig
> @@ -209,6 +209,15 @@ config BLK_INLINE_ENCRYPTION_FALLBACK
> by falling back to the kernel crypto API when inline
> encryption hardware is not present.
>
> +config BLK_NVMEM
> + bool "Block device NVMEM provider"
> + depends on OF
> + depends on NVMEM
> + help
> + Allow block devices (or partitions) to act as NVMEM providers,
> + typically used with eMMC to store MAC addresses or Wi-Fi
> + calibration data on embedded devices.
> +
> source "block/partitions/Kconfig"
>
> config BLK_PM
> diff --git a/block/Makefile b/block/Makefile
> index 7dce2e44276c4274c11a0a61121c83d9c43d6e0c..d7ac389e71902bc091a8800ea266190a43b3e63d 100644
> --- a/block/Makefile
> +++ b/block/Makefile
> @@ -36,3 +36,4 @@ obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += blk-crypto.o blk-crypto-profile.o \
> blk-crypto-sysfs.o
> obj-$(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) += blk-crypto-fallback.o
> obj-$(CONFIG_BLOCK_HOLDER_DEPRECATED) += holder.o
> +obj-$(CONFIG_BLK_NVMEM) += blk-nvmem.o
> diff --git a/block/blk-nvmem.c b/block/blk-nvmem.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..4b35a74255059320ef0cbd3c0003f1510bae5733
> --- /dev/null
> +++ b/block/blk-nvmem.c
> @@ -0,0 +1,111 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * block device NVMEM provider
> + *
> + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + *
> + * Useful on devices using a partition on an eMMC for MAC addresses or
> + * Wi-Fi calibration EEPROM data.
> + */
> +
Add linux/cleanup.h for __free() and linux/device.h for dev_err_probe().
> +#include <linux/file.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/pagemap.h>
> +#include <linux/property.h>
> +
> +#include "blk.h"
> +
> +static int blk_nvmem_reg_read(void *priv, unsigned int from, void *val, size_t bytes)
> +{
> + dev_t devt = (dev_t)(uintptr_t)priv;
> + size_t bytes_left = bytes;
> + loff_t pos = from;
> + int ret = 0;
> +
> + struct file *bdev_file __free(fput) =
> + bdev_file_open_by_dev(devt, BLK_OPEN_READ, NULL, NULL);
> + if (IS_ERR(bdev_file))
> + return PTR_ERR(bdev_file);
> +
> + while (bytes_left) {
> + pgoff_t f_index = pos >> PAGE_SHIFT;
> + struct folio *folio;
> + size_t folio_off;
> + size_t to_read;
> +
> + folio = read_mapping_folio(bdev_file->f_mapping, f_index, NULL);
> + if (IS_ERR(folio)) {
> + ret = PTR_ERR(folio);
> + break;
> + }
> +
> + folio_off = offset_in_folio(folio, pos);
> + to_read = min(bytes_left, folio_size(folio) - folio_off);
> + memcpy_from_folio(val, folio, folio_off, to_read);
> + pos += to_read;
> + bytes_left -= to_read;
> + val += to_read;
> + folio_put(folio);
> + }
> +
> + return ret;
> +}
> +
> +int blk_nvmem_add(struct block_device *bdev)
> +{
> + struct device *dev = &bdev->bd_device;
> + struct nvmem_config config = {};
> +
> + /* skip devices which do not have a device tree node */
> + if (!dev_of_node(dev))
> + return 0;
> +
> + /* skip devices without an nvmem layout defined */
> + struct device_node *child __free(device_node) =
> + of_get_child_by_name(dev_of_node(dev), "nvmem-layout");
> + if (!child)
> + return 0;
> +
> + /*
> + * skip block device too large to be represented as NVMEM devices,
> + * nvmem_config.size is a signed int
> + */
> + if (bdev_nr_bytes(bdev) > INT_MAX) {
> + dev_warn(dev, "block device too large to be an NVMEM provider\n");
> + return 0;
> + }
> +
> + config.id = NVMEM_DEVID_NONE;
> + config.dev = dev;
> + config.name = dev_name(dev);
> + config.owner = THIS_MODULE;
> + config.priv = (void *)(uintptr_t)dev->devt;
> + config.reg_read = blk_nvmem_reg_read;
> + config.size = bdev_nr_bytes(bdev);
> + config.word_size = 1;
> + config.stride = 1;
> + config.read_only = true;
> + config.root_only = true;
> + config.ignore_wp = true;
> + config.of_node = to_of_node(dev->fwnode);
> +
> + bdev->bd_nvmem = nvmem_register(&config);
> + if (IS_ERR(bdev->bd_nvmem)) {
> + int ret = PTR_ERR(bdev->bd_nvmem);
> +
> + bdev->bd_nvmem = NULL;
> + dev_err_probe(dev, ret, "Failed to register NVMEM device\n");
> + return ret;
Just do return dev_err_probe().
> + }
> +
> + return 0;
> +}
> +
> +void blk_nvmem_del(struct block_device *bdev)
> +{
> + nvmem_unregister(bdev->bd_nvmem);
> + bdev->bd_nvmem = NULL;
> +}
> diff --git a/block/blk.h b/block/blk.h
> index ec4674cdf2ead4fd259ff5fc42401f591e684ee9..ed0c10168ba7be10855509637f824a9cea2b9ccb 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -757,4 +757,12 @@ static inline void blk_debugfs_unlock(struct request_queue *q,
> memalloc_noio_restore(memflags);
> }
>
> +#ifdef CONFIG_BLK_NVMEM
> +int blk_nvmem_add(struct block_device *bdev);
> +void blk_nvmem_del(struct block_device *bdev);
> +#else
> +static inline int blk_nvmem_add(struct block_device *bdev) { return 0; }
> +static inline void blk_nvmem_del(struct block_device *bdev) {}
> +#endif
> +
> #endif /* BLK_INTERNAL_H */
> diff --git a/block/genhd.c b/block/genhd.c
> index 7d6854fd28e95ae9134309679a7c6a937f5b7db8..1b2382de6fb30c1e5f60f45c04dc03ed3bf5d5f2 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -421,6 +421,8 @@ static void add_disk_final(struct gendisk *disk)
> */
> dev_set_uevent_suppress(ddev, 0);
> disk_uevent(disk, KOBJ_ADD);
> +
> + blk_nvmem_add(disk->part0);
> }
>
> blk_apply_bdi_limits(disk->bdi, &disk->queue->limits);
> @@ -704,6 +706,8 @@ static void __del_gendisk(struct gendisk *disk)
>
> disk_del_events(disk);
>
> + blk_nvmem_del(disk->part0);
> +
> /*
> * Prevent new openers by unlinked the bdev inode.
> */
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index 8808ee76e73c09e0ceaac41ba59e86fb0c4efc64..ace6f59b860d0813665b2f62a1c03a1f4be94059 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -73,6 +73,9 @@ struct block_device {
> int bd_writers;
> #ifdef CONFIG_SECURITY
> void *bd_security;
> +#endif
> +#ifdef CONFIG_BLK_NVMEM
> + struct nvmem_device *bd_nvmem;
> #endif
> /*
> * keep this out-of-line as it's both big and not needed in the fast
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 890128cdea1ce66863c5baa36f3b336ec4550807..f15d2b5bf9e4fd2368b8a70416a978e22c0d4333 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -30,6 +30,7 @@
>
> struct module;
> struct request_queue;
> +struct nvmem_device;
Why is the forward declaration here and not in blk_types.h where it's needed?
> struct elevator_queue;
> struct blk_trace;
> struct request;
>
> --
> 2.34.1
>
>
With the above nits addressed, LGTM:
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Bart
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: George Moussalem @ 2026-06-30 7:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <ccbd320f-5a17-45f3-96cf-3fa0c9bd1e8f@kernel.org>
On 6/30/26 11:40, Krzysztof Kozlowski wrote:
> On 30/06/2026 09:31, George Moussalem wrote:
>> On 6/30/26 11:15, Krzysztof Kozlowski wrote:
>>> On Mon, Jun 29, 2026 at 05:01:44PM +0400, George Moussalem wrote:
>>>> +unevaluatedProperties: false
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/clock/qcom,gcc-ipq5018.h>
>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> + #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
>>>> +
>>>> + bluetooth {
>>>
>>> Don't send new versions while discussion is still going. I need to
>>> repeat my question - what bus does that sit on?
>>>
>>> Device nodes represent real devices. Real devices sit on a bus, usually.
>>> Do you have here a bus?
>>
>> I'm afraid I don't have a definitive answer. Again, my understanding
>> based on downstream code is that the 'controller' is basically a Cortex
>> M0 processor running Bluetooth firmware connected to an RF. Data
>> transport is over a shared memory carveout with APPS signaling the
>> controller through writes to an IPC mailbox register, while the
>> controller has an interrupt line back to signal APPS.
>
> So this looks like should be squashed into remoteproc node. There is no
> reason or no data to express it as two separate device nodes.
In this version, I've squashed them into one already but as a Bluetooth
controller as that's what the 'processor' is dedicated to, also in line
with Bjorn's guidance to manage the lifecycle of this processor and all
other resources in one. Kindly let me know if this approach is satisfactory.
>
> Best regards,
> Krzysztof
Best regards,
George
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: igmp: remove multicast group from hash table on device destruction
From: Yuyang Huang @ 2026-06-30 7:55 UTC (permalink / raw)
To: Jagielski, Jedrzej
Cc: David S. Miller, Cong Wang, David Ahern, Eric Dumazet,
Ido Schimmel, Jakub Kicinski, Paolo Abeni, Simon Horman,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <PH0PR11MB590210EC36E866B973378054F0F72@PH0PR11MB5902.namprd11.prod.outlook.com>
> Hi,
>
> why sending this to net-next not to net if that's a bug fix?
>
> In the v1 thread it was said
> >This is a long-standing bug, not a recent regression.
>
> so why do not cc stable kernel to get rid of this bug from
> stable kernels in such case?
Thanks for the advise, will send this patch to stable kernel.
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Bartosz Golaszewski @ 2026-06-30 7:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Mon, 29 Jun 2026 15:26:20 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
>
> Arnd
Thanks for doing this Arnd!
For the series:
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH net-next 14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Replace the open-coded struct_size() + kzalloc() pattern with the
kzalloc_flex() helper when allocating struct enetc_psfp_gate. This
removes the intermediate entries_size local variable and makes the
allocation site more concise.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc_qos.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
index 7b17bca24f26..2aa0fcaafcd2 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
@@ -1135,7 +1135,6 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
struct flow_action_entry *entry;
struct action_gate_entry *e;
u8 sfi_overwrite = 0;
- int entries_size;
int i, err;
if (f->common.chain_index >= priv->psfp_cap.max_streamid) {
@@ -1242,8 +1241,7 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
goto free_filter;
}
- entries_size = struct_size(sgi, entries, entryg->gate.num_entries);
- sgi = kzalloc(entries_size, GFP_KERNEL);
+ sgi = kzalloc_flex(*sgi, entries, entryg->gate.num_entries);
if (!sgi) {
err = -ENOMEM;
goto free_filter;
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox