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

[Vincent Jardin]

Hi Ioana,

> 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 think I isolated the difference: I guess you have smmu enabled while I
did disable it. I checked and when smmu is enabled back, the issue does
not show up anymore. But it is not my goal.

I do have with my dts,
        &smmu {
                status = "disabled";
        };

for the mc to load, you need:
        fsl_mc: fsl-mc@80c000000 {
                compatible = "fsl,qoriq-mc";
                ...
                iommu-map = <0 &smmu 0 0>;
                dma-coherent;
        };

it seems due to,
of_dma_configure_id() -> of_iommu_configure() ends up with "no IOMMU" and
it returns 0 instead of -EPROBE_DEFER.

So the root DPRC, populated at arch_initcall_sync, probes now
synchronously, before misc_init() registers misc_class at subsys_initcall
and so dprc.1 is created classless. (I hope I did not miss something).

> > 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 ?

Yes, see below, even without restarting the MC.

smmu disabled / without the patch of this serie:
   # grep dprc /proc/misc
   256 dprc.1
   # ls /sys/class/misc/ | grep dprc # nothing: not in the class
   # ls -l /sys/dev/char/10:256
   ... /sys/dev/char/10:256 -> ../../devices/dprc.1  <- not under devices/virtual/misc

Unbind: the minor is freed but the char link leaks:

   # echo dprc.1 > /sys/bus/fsl-mc/drivers/fsl_mc_dprc/unbind
   [  201.633695] fsl_mc_dprc dprc.1: DPRC device unbound from driver
   # grep dprc /proc/misc    <- gone (minor 256 freed)
   # ls -l /sys/dev/char/10:256
   ... /sys/dev/char/10:256 -> ../../devices/dprc.1  <- still here: leaked

Bind:

    # echo dprc.1 > /sys/bus/fsl-mc/drivers/fsl_mc_dprc/bind
    sh: write error: Resource temporarily unavailable
    [  203.306315] sysfs: cannot create duplicate filename '/dev/char/10:256'
    [  203.306356] Call trace:
     ...
    [  203.306440]  misc_register+0xcc/0x158
    [  203.306449]  fsl_mc_uapi_create_device_file+0x44/0x74
    [  203.306462]  dprc_setup+0x134/0x214
    [  203.306471]  dprc_probe+0x18/0xec
    [  203.306480]  fsl_mc_probe+0x1c/0x30
      ...
    [  203.306517]  bind_store+0xa8/0xc4

With the patch applied on the same board, smmu disabled, then, it is fine.

This apply patch should be ok for smmu and not smmu in order to cover any cases now.

best regards,
  Vincent