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

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

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

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:

[    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.
Stable mmc enumeration can be achiever by filling /aliases node properly
(4700a00755fb commit's rationale).

After revert:

[    9.006816] IP-Config: Complete:
[    9.010058]      device=lan0, ...

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
 drivers/bus/ti-sysc.c | 49 -------------------------------------------
 1 file changed, 49 deletions(-)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index f67b927ae4caa..e5c02e950f2c1 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -677,51 +677,6 @@ static int sysc_parse_and_check_child_range(struct sysc *ddata)
 	return 0;
 }
 
-/* Interconnect instances to probe before l4_per instances */
-static struct resource early_bus_ranges[] = {
-	/* am3/4 l4_wkup */
-	{ .start = 0x44c00000, .end = 0x44c00000 + 0x300000, },
-	/* omap4/5 and dra7 l4_cfg */
-	{ .start = 0x4a000000, .end = 0x4a000000 + 0x300000, },
-	/* omap4 l4_wkup */
-	{ .start = 0x4a300000, .end = 0x4a300000 + 0x30000,  },
-	/* omap5 and dra7 l4_wkup without dra7 dcan segment */
-	{ .start = 0x4ae00000, .end = 0x4ae00000 + 0x30000,  },
-};
-
-static atomic_t sysc_defer = ATOMIC_INIT(10);
-
-/**
- * sysc_defer_non_critical - defer non_critical interconnect probing
- * @ddata: device driver data
- *
- * We want to probe l4_cfg and l4_wkup interconnect instances before any
- * l4_per instances as l4_per instances depend on resources on l4_cfg and
- * l4_wkup interconnects.
- */
-static int sysc_defer_non_critical(struct sysc *ddata)
-{
-	struct resource *res;
-	int i;
-
-	if (!atomic_read(&sysc_defer))
-		return 0;
-
-	for (i = 0; i < ARRAY_SIZE(early_bus_ranges); i++) {
-		res = &early_bus_ranges[i];
-		if (ddata->module_pa >= res->start &&
-		    ddata->module_pa <= res->end) {
-			atomic_set(&sysc_defer, 0);
-
-			return 0;
-		}
-	}
-
-	atomic_dec_if_positive(&sysc_defer);
-
-	return -EPROBE_DEFER;
-}
-
 static struct device_node *stdout_path;
 
 static void sysc_init_stdout_path(struct sysc *ddata)
@@ -947,10 +902,6 @@ static int sysc_map_and_check_registers(struct sysc *ddata)
 	if (error)
 		return error;
 
-	error = sysc_defer_non_critical(ddata);
-	if (error)
-		return error;
-
 	sysc_check_children(ddata);
 
 	if (!of_property_present(np, "reg"))
-- 
2.48.1

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

[Andreas Kemnade]

Hi Alexander,

Am Thu, 13 Mar 2025 10:47:06 +0100
schrieb "A. Sverdlin" <alexander.sverdlin@siemens.com>:

> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> 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...

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

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

Regards,
Andreas

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

[Sverdlin, Alexander]

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?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[Andreas Kemnade]

Am Thu, 13 Mar 2025 20:42:23 +0000
schrieb "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>:

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

Regards,
Andreas

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

[Tony Lindgren]

* Andreas Kemnade <andreas@kemnade.info> [250313 22:01]:
> Am Thu, 13 Mar 2025 20:42:23 +0000
> schrieb "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>:
> 
> > 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

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

[Sverdlin, Alexander]

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
www.siemens.com

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

[Sverdlin, Alexander]

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

...

> 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 :)

I suppose you still have the test case which didn't work for you back then?
Because in this case I could help you with proper mmc aliases.

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[Sverdlin, Alexander]

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

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

[Tony Lindgren]

* Sverdlin, Alexander <alexander.sverdlin@siemens.com> [250319 07:39]:
> 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.

Oh OK, sorry I misunderstood your problem. I thought you're missing some
resources like clocks or regulators. I did not realize this issue can
trigger on any system with just a few devices configured.

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

Heh a random number enough to quiet down things was the original idea :)
Does not exactly always work as you pointed out.

Regards,

Tony

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

[Andreas Kemnade]

Am Wed, 19 Mar 2025 05:56:06 +0200
schrieb Tony Lindgren <tony@atomide.com>:

> * Andreas Kemnade <andreas@kemnade.info> [250313 22:01]:
> > Am Thu, 13 Mar 2025 20:42:23 +0000
> > schrieb "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>:
> >   
> > > 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?
> 
I think you have not understand the real problem here. I guess, that
problem can be provoked on other systems, too, if you just limit the
devices to the absolute minimum required.
The problem is as far as I understand a bit different. The problem is
not a resource is missing totally, it is just the artificial deferral
here. If there are just a minimum devices configured, you can come to a
point where there is nothing to trigger a loop through all the deferred
devices causing them to never probe.
An arbitary, unrelated device with a driver popping up would unstall
that deferral. 

I will just play around with the systems I have access to and if nothing
pops up, I will add a Tested-By/Reviewed-By. If more serious problems
pops up (I do not think so), another clean fix should get in before
getting this reverted.

> 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 :)
>
So what is the real problem you wanted to fix? MMC aliases are there at
many places already. So is there anything besides MMC order?

Regards,
Andreas

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

[Tony Lindgren]

* Andreas Kemnade <andreas@kemnade.info> [250319 08:17]:
> Am Wed, 19 Mar 2025 05:56:06 +0200
> schrieb Tony Lindgren <tony@atomide.com>:
> > 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?
> > 
> I think you have not understand the real problem here. I guess, that
> problem can be provoked on other systems, too, if you just limit the
> devices to the absolute minimum required.

OK yup sorry I misunderstood the problem.

> The problem is as far as I understand a bit different. The problem is
> not a resource is missing totally, it is just the artificial deferral
> here. If there are just a minimum devices configured, you can come to a
> point where there is nothing to trigger a loop through all the deferred
> devices causing them to never probe.
> An arbitary, unrelated device with a driver popping up would unstall
> that deferral. 

Thanks for clarifying, yes that is broken.

> I will just play around with the systems I have access to and if nothing
> pops up, I will add a Tested-By/Reviewed-By. If more serious problems
> pops up (I do not think so), another clean fix should get in before
> getting this reverted.

Agreed now that I understand the probem :) Best to revert if no other
issues are found except for increased deferred probe.

> > 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 :)
> >
> So what is the real problem you wanted to fix? MMC aliases are there at
> many places already. So is there anything besides MMC order?

The "real problem" is that the probe order should consider the always-on
interconnect instances first. They provide resources for the other
interconnect instances. Ideally there would be a proper bus driver to take
care of that instead of relying on deferred probe.

Regards,

Tony

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

[Andreas Kemnade]

Am Thu, 13 Mar 2025 10:47:06 +0100
schrieb "A. Sverdlin" <alexander.sverdlin@siemens.com>:

> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> 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:
> 
> [    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.
> Stable mmc enumeration can be achiever by filling /aliases node properly
> (4700a00755fb commit's rationale).
> 
> After revert:
> 
> [    9.006816] IP-Config: Complete:
> [    9.010058]      device=lan0, ...
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>

No regressions seen on GTA04, Pandaboard and BT200.
So

Tested-by: Andreas Kemnade <andreas@kemnade.info> # GTA04, Panda, BT200

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

[Tony Lindgren]

* Andreas Kemnade <andreas@kemnade.info> [250331 09:00]:
> Am Thu, 13 Mar 2025 10:47:06 +0100
> schrieb "A. Sverdlin" <alexander.sverdlin@siemens.com>:
> 
> > From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> > 
> > 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:
> > 
> > [    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.
> > Stable mmc enumeration can be achiever by filling /aliases node properly
> > (4700a00755fb commit's rationale).

Would be nice to update the description to make it clear it breaks in all
cases if there are not enough devices.

> > After revert:
> > 
> > [    9.006816] IP-Config: Complete:
> > [    9.010058]      device=lan0, ...
> > 
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> No regressions seen on GTA04, Pandaboard and BT200.
> So
> 
> Tested-by: Andreas Kemnade <andreas@kemnade.info> # GTA04, Panda, BT200

Good to hear, best that you or Kevin pick this up:

Reviewed-by: Tony Lindgren <tony@atomide.com>

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

[Sverdlin, Alexander]

Thanks for review, Tony!

On Tue, 2025-04-01 at 06:57 +0300, 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:
> > > 
> > > [    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.
> > > Stable mmc enumeration can be achiever by filling /aliases node properly
> > > (4700a00755fb commit's rationale).
> 
> Would be nice to update the description to make it clear it breaks in all
> cases if there are not enough devices.

I'll re-spin with more clear description!

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com