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: Thu, 20 Mar 2025 06:09:55 +0200	[thread overview]
Message-ID: <20250320040955.GD4957@atomide.com> (raw)
In-Reply-To: <20250319091741.5488592b@akair>

* 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

  reply	other threads:[~2025-03-20  4:10 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
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 [this message]
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=20250320040955.GD4957@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