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

[Tony Lindgren]

* Andreas Kemnade <andreas@xxxxxxxxxxxx> [250313 22:01]:
> Am Thu, 13 Mar 2025 20:42:23 +0000
> schrieb "Sverdlin, Alexander" <alexander.sverdlin@xxxxxxxxxxx>:
> 
> > Hi Andreas!
> > 
> > On Thu, 2025-03-13 at 20:21 +0100, Andreas Kemnade 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?

Reverting the commit does not really fix the root cause. It just ignores
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 :)

Regards,

Tony