Thread (9 messages) 9 messages, 3 authors, 9h ago

Re: [PATCH net-next V7 4/4] devlink: Apply eswitch mode boot defaults

From: Mark Bloch <mbloch@nvidia.com>
Date: 2026-07-25 06:51:45
Also in: linux-doc, linux-rdma


On 25/07/2026 2:11, Jakub Kicinski wrote:
On Thu, 16 Jul 2026 11:48:52 +0300 Mark Bloch wrote:
quoted
 void devl_unlock(struct devlink *devlink)
 {
+	devlink_default_eswitch_mode_apply_pending(devlink);
 	mutex_unlock(&devlink->lock);
 }
Nack, please don't insert such hacks into core helpers :|
I thought we discussed this.
Yeah, we did.

AFAIU what we agreed on was to queue the fallback work from
devl_register(), and have a driver API for drivers which know
the exact point at which the device is ready.

That's what v4 implemented. Jiri objected to that design. v5
moved the queueing to devl_unlock(), and the following discussion
ended with both the work and the driver API being dropped. That
left the direct call from devl_unlock() which you're objecting to 
now.

So I think you and Jiri have different views on the basic design
here. It's hard to respin the series when addressing one review
takes it back to something the other reviewer objected to.

How about I drop the driver API from this series and submit it as
a follow-up? This series would only have the generic workqueue
fallback.

But where should the work be queued? 
- devl_register()
- devl_unlock()?

Can we settle that before I post the next version, so we don't go
in circles again?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help