Hi Tony,
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[1]
> > > > > 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)
^^^^^^^^^^^^^^^^^^^^^^
[2]
> > > > > [ 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?
This "missing" resource is pointed out above in [1] and [2].
And it's missing only because of the arbitrary 10 deferrals, which simply
do not happen on all systems if you'd configure less drivers or they are
ordered in a way that 10 deferrals are not necessary in the DT.
If your patch is "fixing the root cause", could you please elaborate the
number "10"? Why is it 10 and not 11 or 11000000?
Could it be "2" or "1" as well?
--
Alexander Sverdlin
Siemens AG
www.siemens.com
