Hello,
On Thu, 19 Feb 2026 at 10:06, Maxime Leroy <[email protected]> wrote:
> > > diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c
> > > index abdb0ad50d..a539753649 100644
> > > --- a/drivers/bus/fslmc/fslmc_bus.c
> > > +++ b/drivers/bus/fslmc/fslmc_bus.c
> > > @@ -596,6 +596,11 @@ fslmc_bus_plug(struct rte_device *rte_dev)
> > > struct rte_dpaa2_device, device);
> > > struct rte_dpaa2_driver *drv;
> > >
> > > + /* Refresh devargs from the EAL devargs list, as they may
> > > + * have been added after the initial bus scan (e.g. hotplug).
> > > + */
> > > + dev->device.devargs = fslmc_devargs_lookup(dev);
> > > +
> > > TAILQ_FOREACH(drv, &rte_fslmc_bus.driver_list, next) {
> > > ret = rte_fslmc_match(drv, dev);
> > > if (ret)
> >
> > This looks like a strange location for a fix.
> >
> > The hotplug path calls this bus ->scan() which is supposed to refresh
> > the devices.
> > Could you double check if something is wrong on this side?
> >
> Hi David,
>
> rte_fslmc_scan() is guarded by a process_once flag and returns
> immediately after the initial bus scan. During hotplug,
> local_dev_probe() does call bus->scan(), but it is a no-op -
> scan_one_fslmc_device()
> (which calls fslmc_devargs_lookup()) is never reached.
>
> The device already exists in the bus device list from the initial
> scan, so find_device() succeeds, but its devargs pointer is stale
> (NULL).
>
> You are right that insert_in_device_list() does not handle the comp ==
> 0 case (unlike PCI which refreshes the existing object and frees the
> duplicate). Fixing that and removing process_once would allow scan to
> properly refresh devargs on rescan.
>
> However it is a larger change: beyond the dedup fix, device_count
> would need to be kept consistent, and fslmc_vfio_process_group()
> removes infrastructure objects (DPMCP, DPRC, excess DPIO) from the
> device list during the initial probe, so a rescan would re-insert them
> as new entries that would need to be handled as well.
>
> Making the fslmc bus scan re-entrant is a significant rework of a
> critical code path, for a use case (true hotplug of dynamically
> created devices) that is not common on NXP platforms.
> I think this is best left to the NXP maintainers who know this code
> intimately. My use case is grout, which uses the EAL hotplug API to
> late-probe devices that already exist in the DPRC at boot time.
Ok, thanks for the explanations.
I agree, it seems too intrusive for fixing this issue.
>
> That said, you are right that scan is the proper place for this fix.
> Rather than making it fully re-entrant, a simpler approach is to
> refresh devargs on existing devices when scan is called again:
>
> if (process_once) {
> DPAA2_BUS_DEBUG("Fslmc bus already scanned. Not rescanning");
> TAILQ_FOREACH(dev, &rte_fslmc_bus.device_list, next)
> dev->device.devargs = fslmc_devargs_lookup(dev);
> return 0;
> }
>
> Let me know what you think of this approach.
That seems a good trade off, as it avoids mixing responsibilities in
this bus code.
What do you think Hemant?
--
David Marchand
