On 3/26/26 06:20, Jiri Pirko wrote:
Wed, Mar 25, 2026 at 07:26:53AM +0100, [email protected] wrote:
Since shared devlink acts as a normal devlink instance, capable of all
usual devlink operations, it must unregister its resources.
I plan to make use of devlink resources on a shared instance for ice
driver by separate series, coming soon.
Signed-off-by: Przemek Kitszel <[email protected]>
---
net/devlink/sh_dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/devlink/sh_dev.c b/net/devlink/sh_dev.c
index b85e5cb1edbe..5de138bf3630 100644
--- a/net/devlink/sh_dev.c
+++ b/net/devlink/sh_dev.c
@@ -71,6 +71,7 @@ static void devlink_shd_destroy(struct devlink_shd *shd)
list_del(&shd->list);
devl_lock(devlink);
+ devl_resources_unregister(devlink);
Hmm. It is driver's responsibility to call this on appropriate place,
symmetric to resource register. Why to have this in code for sh?
The idea I had was to have callbacks to driver to do things like this
and more eventually. Would it work for you?
for driver stuff that could be useful (say, someone wants to have
an additional data structure to iterate and free), OTOH, each
entity that is sharing should "unplug" from shared devlink, so
those structures should be emptied anyway
for my stuff in ice I managed to do without destructor
coming back to devlink stuff - all things (resources, health)
would need same cleaning in all drives, so putting that in
devlink_shd_destroy() will simply take the burden off devs
(at the expense of less symmetric code for normal/shared
devlinks)
in short: I'm ok with any of
a. callback for all cleanup
b. callback for driver-specific cleanup
c. no callback and no driver-specific cleanup (until someone needs
that very much)
thanks!
devl_unregister(devlink);
devl_unlock(devlink);
kfree(shd->id);
--
2.51.1
