Re: [PATCH] bus: fsl-mc: register the object drivers after misc_class exists

On Mon, Sep 07, 2026 at 06:30:17PM +0200, Vincent Jardin wrote:

Hi Ioana,

quoted

Do you mean that the above error messages are triggered by an unbind and
bind sequence like below?

$ echo dprc.1 > /sys/bus/fsl-mc/drivers/fsl_mc_dprc/unbind
$ echo dprc.1 > /sys/bus/fsl-mc/drivers/fsl_mc_dprc/bind

Yes, same sequence on the root DPRC

quoted

I am asking this because I cannot seem to trigger it myself. There is a
misc_deregister() which should remove the char device upon unbinding the
root DPRC.

It does for every normal misc device, but not for this one, because the
root DPRC's misc device is created classless.

You can check the states with:
    grep dprc /proc/misc   # e.g. "256 dprc.1"  -> registered
    ls /sys/class/misc/ | grep dprc

If dprc.1 shows in /proc/misc but is absent from /sys/class/misc, its
misc device is classless and the unbind/bind should collide. If it is
present under /sys/class/misc, it was created after misc_class and the
sequence is clean on your setup.

Yes, it is present under /sys/class/misc.

	$ grep dprc /proc/misc
	260 dprc.1
	$ ls /sys/class/misc/ | grep dprc
	dprc.1

fsl_mc_bus_driver_init() is a postcore_initcall, it registers both the
platform and the dprc drivers.

The fsl-mc DT node is populated at arch_initcall_sync, so the root DPRC
probes synchronously.

dprc_setup() -> fsl_mc_uapi_create_device_file() -> misc_register() runs
before misc_init() does class_register(&misc_class) at subsys_initcall.

misc_register() does not fail in that window: device_create_with_groups()
with an unregistered class creates the device with no misc_class
membership and still returns 0.

-> So at unbind, misc_deregister() -> device_destroy(&misc_class, devt)
cannot find the device within misc_class, it returns without removing it,
and then it leaks the device + its /sys/dev/char/10:<minor> link while freeing
the minor. The next bind reuses the minor and dies on the
duplicate /sys/dev/char/ entry.

I guess, from my setup, it happens when the root DPRC's misc device is
created during the early probe, which needs CONFIG_FSL_MC_UAPI_SUPPORT=y,
fsl-mc built in (not a module), and the root DPRC probe not going through
EPROBE_DEFER.

If it defers, the retry runs after subsys_initcall, misc_class exists,
and unbind/bind is clean -> which is probably what you are seeing.

I am indeed in the case in which the uapi support is builtin but the
dprc.1 probing is deferred, thus it will get executed after misc_init()
had a chance to run.

The deferral happens because of_dma_configure_id() returns EPROBE_DEFER
since it waits for arm-ssmu to probe. How did you get past this
deferral?

I started to face this issue when I did try to restart
the MC from Linux userland instead of uboot in order to be able to adapt
with some DPC changes during the runtime.
 see https://github.com/vjardin/lx2160-sdx/blob/main/src/lx2160-mc.c
But I guess this issue should be quite generic.

Can you reproduce it without restarting the MC: boot to prompt, echo
dprc.1 > .../unbind, echo dprc.1 > ..../bind ?

Ioana