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?