[PATCH] accel/rocket: search every core slot when a core is removed

[Igor Paunovic]

Answering the one question that is about this patch rather than about the
state it leaves behind, and confirming the rest.

> Because rocket_remove() doesn't clear the dev pointer or compact the
> array, wouldn't subsequent out-of-order unbinds match stale pointers
> since find_core_for_dev() now searches up to max_cores?

There are three callers: rocket_remove() and the two runtime PM callbacks.
The driver core calls remove once per device, and the PM callbacks cannot
run for an unbound one, because rocket_core_fini() has already called
pm_runtime_disable() on it. The slots the widened search adds are either
never filled, where .dev is NULL and matches nothing, or held by a device
that has been unbound - and nothing asks after such a device again.

What the narrower search did do was lose live cores. Unbind the core in
slot 0 of three: num_cores drops to two, so find_core_for_dev() stops
before slot 2. The core sitting there is still bound and still running,
but its own runtime suspend and resume callbacks start returning -ENODEV.
Searching every allocated slot fixes that as well.

An earlier version of this patch did clear .dev on removal and take a free
slot on probe. I dropped both. Clearing .dev turns rocket_open()'s
unconditional cores[0] into a NULL dereference whenever the core in slot 0
is unbound while its siblings stay bound, which is a worse failure than
the one it cures - and it is the same rocket_open() issue listed further
down. That is why the commit message says out-of-order unbind wants more
thought than a fix should carry, rather than quietly half-fixing it.

On the rest: all eight are pre-existing and I agree with all eight. Two of
them have names already.

The ERR_PTR left in the file-scoped rdev is fixed by Guangshuo Li's
"accel/rocket: clear rdev on device init failure", posted in July and
still unapplied:

  https://lore.kernel.org/dri-devel/20260708062845.716487-1-lgs201920130244@gmail.com/

It carries my Reviewed-by. It would be good to see that one land.

The devm point may explain something I measured this week and could not
account for. Unbinding and rebinding all three cores walks the DRM minor
upwards - 1 through 10 over ten rounds in one run - and only a module
reload puts it back to 0. I have not shown that the allocations are
leaked, only that something survives a rebind that should not, which is
consistent with what you describe.

Igor