[PATCH 0/4] remoteproc: virtio: Fixes and cleanups in the vdev<->pdev relationship

[Francesco Valla <francesco@valla.it>]

Hello,

while proceeding on [1] I noticed a possible simplification on the
rproc-virtio registration and tracking path, which led to the discovery
of a couple of bugs. This series is the result of the work that followed
and thus contains both (proposed) fixes for the bugs and the
aforementioned simplification, which consists in less poking the backing
pdev from the vdev side.

Patches 1 and 2 can be collapsed into one, but I preferred to leave them
separate to show the reasoning behind (and to allow cherry-picking, if
that's the case).

If anyone is reviewing [1], or plans to: please consider this series
first. I'm in no rush to have that accepted, and some (critical, in the
case of iommu) details need to be squared out, while this series fixes
what I think to be real bugs. I would have preferred to spot them
before, but...

AI disclosure: an LLM was used to review the work, but all code is my
own, as well as the commit messages (I'll be happy to fix the english,
don't hesitate to correct me also on that).

Thank you!

Regards,
Francesco

[1] https://lore.kernel.org/linux-remoteproc/20261102-remoteproc_virtio_map-v2-0-26b300e01c62@valla.it/

Signed-off-by: Francesco Valla <francesco@valla.it>
---
Francesco Valla (4):
      remoteproc: virtio: Decouple vdev from the parent pdev
      remoteproc: virtio: Rework memory release
      remoteproc: virtio: Drop rvdevs list and associated functions
      remoteproc: virtio: Stop de-referencing pdev from its children

 drivers/remoteproc/remoteproc_core.c     | 34 ++++++++++----------
 drivers/remoteproc/remoteproc_internal.h |  4 +--
 drivers/remoteproc/remoteproc_virtio.c   | 53 +++++++++++++-------------------
 include/linux/remoteproc.h               | 10 ++----
 4 files changed, 43 insertions(+), 58 deletions(-)
---
base-commit: ec1f9ba57b02fe12a6fa5f141206d439ba3d044e
change-id: 20261107-remoteproc_pdev_decouple-9933eb3a5998

Best regards,
--  
Francesco Valla <francesco@valla.it>