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?