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

Jiri Pirko <[email protected]>
Newsgroups org.kernel.vger.linux-doc,org.kernel.vger.linux-rdma,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?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.