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

Jiri Pirko <[email protected]> Wed, 29 Jul 2026 11:11:53 +0200
Newsgroups org.kernel.vger.linux-rdma,org.kernel.vger.linux-doc,org.kernel.vger.netdev
Message-ID <amnDfSmMVzpiH2gE@FV6GYCPJ69>
Mon, Jul 27, 2026 at 10:10:33PM +0200, [email protected] wrote:
>On Sat, 25 Jul 2026 09:51:34 +0300 Mark Bloch wrote:
>> 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.
>
>It'd be great if Jiri, an nVidia employee and a devlink "maintainer",
>paid attention to at the very least revisions of nvidia's patches
>touching devlink. We discussed this on a prior revision and he didn't
>say anything.
>
>> 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?
>
>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()
?

>
>* better name welcome
>
>BTW AI reported that we reset the mode on reinit request. Based on
>the code this is entirely intentional but would be good to document?