Re: [PATCH 10/11] bus/fslmc: fix devargs not propagated on hotplug

Maxime Leroy
2026-02-19T09:05:56Z

Le mer. 18 févr. 2026 à 17:45, David Marchand
<david.marchand@redhat.com> a écrit :
>
> On Wed, 18 Feb 2026 at 17:06, Maxime Leroy <maxime@leroys.fr> wrote:
> >
> > When a device is hotplugged via rte_dev_probe(), the EAL adds the
> > devargs to its global list before calling the bus plug callback.
> > However, fslmc_bus_plug() never refreshes dev->device.devargs from
> > the EAL list -- it was only set during the initial bus scan.
> >
> > As a result, PMD-specific devargs (e.g. drv_no_taildrop) passed
> > through rte_dev_probe() are silently ignored by the driver.
> >
> > Refresh devargs from the EAL list in fslmc_bus_plug() before probing,
> > the same way it is done during the initial bus scan.
> >
> > Fixes: b5721f271cbf ("bus/fslmc: support DPNI hotplug")
> > Signed-off-by: Maxime Leroy <maxime@leroys.fr>
> > ---
> > drivers/bus/fslmc/fslmc_bus.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > 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.

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.

-------------------------------
Maxime Leroy
maxime@leroys.fr