On Tue, Sep 08, 2026 at 06:17:24PM +0200, Vincent Jardin wrote:
> 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 am not trying to convince you that the patch is not necessary, I am
just trying to identify the scope of the issue correctly.
>
> 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).
With smmu disabled from the DT, I can now reproduce the problem.
Thanks!
