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.
* 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?