Re: [PATCH] Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first"

Sverdlin, Alexander
2025-03-19T06:54:21Z

On Wed, 2025-03-19 at 05:56 +0200, Tony Lindgren wrote:
> > > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6.
> > > > >
> > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case
> > > > > when minimally-configured system tries to network-boot:
> > > > >
> > > > brakes or breaks? To unterstand the severity of the issue...
> > >
> > > Thanks for the correction, it should have been "breaks"...
> > >
> > > > > [    6.888776] probe of 2b300050.target-module returned 517 after 258 usecs
> > > > > [   17.129637] probe of 2b300050.target-module returned 517 after 708 usecs
> > > > > [   17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown)
> > > > > [   26.878471] Waiting up to 100 more seconds for network.
> > > > >
> > > > > Arbitrary 10 deferrals is really not a solution to any problem.
> > > >
> > > > So there is a point where no more probe of anything pending are
> > > > triggered and therefore things are not probed?
> > >
> > > Because there is a point indeed (if we configure quite minimal set of drivers just
> > > enough to mount NFS) when deferred probes are not triggered any longer.
> > >
> > > > > Stable mmc enumeration can be achiever by filling /aliases node properly
> > > > > (4700a00755fb commit's rationale).
> > > > >
> > > > yes, it does not look like a clean solution. And we have the
> > > > proper aliases node in many places. What I am a bit wondering about is
> > > > what kind of sleeping dogs we are going to wake up by this revert. So I
> > > > think this should be tested a lot esp. about possible pm issues.
> > > >
> > > > Not every dependency in the sysc probe area is properly defined.
> > >
> > > But the patch I propose to revert is really not a solution for missing
> > > dependencies on syscons. I'm fine with not propagating this to stable,
> > > but reverting in master should give enough time for older SoCs to test,
> > > WDYT?
> > >
> > I am not against your revert proposal and not against propagating it
> > to stable, I would just like to see some Tested-Bys before it gets
> > applied to anything. If anything nasty pops up, it should be solved in a
> > cleaner way then with the offending patch.
>
> Sounds like for the AM62x problem there is simply some resource missing
> that needs to be configured. Did you track down which resource is causing
> the deferred probe without the revert?

There is no resource missing in am62x without the revert.

> Reverting the commit does not really fix the root cause. It just ignores

It does, because the real problem is the commit itself. It aimed to reduce
the number of -EPROBEDEFER on am33x, but added much more on am62x (to the
point it stops working). There is no point of doing arbitrary deferrals on
one platform if it results in more deferrals on another.

> the problem of the hierarchy of the interconnect instances. Some of the
> interconnect instances are always-on, and contain devices providing
> resources for the other interconnect devices. So I would not consider
> patching MMC aliases all over the place as an alternative to fixing the
> real problem :)

If mmc aliases are missing and you experience unstable enumeration of those,
this is the real problem and someone has to correct the aliases.

I wonder, how this patch has passed the review if it has no other tags other
then SoB?

--
Alexander Sverdlin
Siemens AG