public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>,
	"rogerq@kernel.org" <rogerq@kernel.org>,
	"aaro.koskinen@iki.fi" <aaro.koskinen@iki.fi>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"khilman@baylibre.com" <khilman@baylibre.com>
Subject: Re: [PATCH] Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first"
Date: Wed, 19 Mar 2025 05:56:06 +0200	[thread overview]
Message-ID: <20250319035606.GA4957@atomide.com> (raw)
In-Reply-To: <20250313230148.792f224b@akair>

* 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

  reply	other threads:[~2025-03-19  4:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13  9:47 [PATCH] Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first" A. Sverdlin
2025-03-13 19:21 ` Andreas Kemnade
2025-03-13 20:42   ` Sverdlin, Alexander
2025-03-13 22:01     ` Andreas Kemnade
2025-03-19  3:56       ` Tony Lindgren [this message]
2025-03-19  6:54         ` Sverdlin, Alexander
2025-03-19  7:18         ` Sverdlin, Alexander
2025-03-19  7:39         ` Sverdlin, Alexander
2025-03-20  4:00           ` Tony Lindgren
2025-03-19  8:17         ` Andreas Kemnade
2025-03-20  4:09           ` Tony Lindgren
2025-03-31  9:00 ` Andreas Kemnade
2025-04-01  3:57   ` Tony Lindgren
2025-04-01  7:06     ` Sverdlin, Alexander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250319035606.GA4957@atomide.com \
    --to=tony@atomide.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=alexander.sverdlin@siemens.com \
    --cc=andreas@kemnade.info \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rogerq@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox