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

[Mark Bloch <mbloch@nvidia.com>]

On 30/07/2026 14:00, Jiri Pirko wrote:
> Thu, Jul 30, 2026 at 01:06:08AM +0200, kuba@kernel.org wrote:
>> On Wed, 29 Jul 2026 11:11:53 +0200 Jiri Pirko wrote:
>>>> Maybe a middle ground would be to add a dedicated devl_init_unlock()*
>>>> were we can stick such init? Slap a WARN_ON(!registered) in the normal
>>>> unlock? I don't want the normal unlock to grow in complexity like
>>>> rtnl_unlock ended up growing.  
>>>
>>> Yep, that was +- my idea when I suggested this, to have this in a
>>> separate helper.
>>>
>>> devl_unlock_in_init()
>>> ?
>>
>> 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.

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.

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.

Mark