All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.