linux-kernel - Re: [PATCH] Revert "bus: ti-sysc: Probe for l4_wkup and l4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250320040955.GD4957@atomide.com>
Date: Thu, 20 Mar 2025 06:09:55 +0200
From: Tony Lindgren <tony@...mide.com>
To: Andreas Kemnade <andreas@...nade.info>
Cc: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>,
	"rogerq@...nel.org" <rogerq@...nel.org>,
	"aaro.koskinen@....fi" <aaro.koskinen@....fi>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"khilman@...libre.com" <khilman@...libre.com>
Subject: Re: [PATCH] Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg
 interconnect devices first"

* Andreas Kemnade <andreas@...nade.info> [250319 08:17]:
> Am Wed, 19 Mar 2025 05:56:06 +0200
> schrieb Tony Lindgren <tony@...mide.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