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

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 31 Jul 2026 16:52:25 +0300 Mark Bloch wrote:
> >> Maybe "after_init()" ? "in" sounds like we can release it multiple
> >> times but I think the idea is that it's the final, single "release 
> >> into the wild" unlock.  
> > 
> > ack  
> 
> Just to make sure I understand the proposal.
> 
> AFAIU devl_unlock_after_init() can be used in one of two ways:
> 
> Convert all devlink drivers to use it for the final unlock, including
> drivers which don't support eswitch mode setting.
> 
> That's a lot of churn for the few drivers which need this.
> We'd also need to make sure existing drivers are converted and new
> drivers use the right helper.

We can add a WARN_ON(!registered) to the normal unlock and it will
be impossible to miss the use of the wrong one?

> Convert only drivers which support eswitch mode setting.
> 
> Then applying the default becomes driver opt-in, which AFAIU we were
> trying to avoid. For this feature it also looks very similar to the
> explicit apply API Jiri objected to.

Well, it would be a change to the init flow into which more things
can be hooked. We could also make it a separate "driver ready" call,
I guess, instead of packing it with the unlock. The point is that it's
not a eswitch-mode dedicated callback that's easy to miss in a driver.

> Which one do you have in mind?
> 
> I don't think either option is great. Wouldn't it be simpler to queue
> work from devl_register(), as before? That keeps the logic out of
> devl_unlock() and doesn't require driver opt-in.

Having to edit the drivers is not a concern to me. That said, I do agree
that the API is somewhat awkward. It's a compromise. IDK.