linux-kernel - Re: [PATCH] soc/tegra: pmc: Ensure power-domains are in a known state

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: <sgsi4wia74nbvme4ik27waec2yuipbw7hfh7jyygxlbfhvsc5q@4onfx46nle56>
Date: Tue, 26 Aug 2025 17:29:51 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Jon Hunter <jonathanh@...dia.com>, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc/tegra: pmc: Ensure power-domains are in a known state

On Mon, Aug 11, 2025 at 12:37:25PM +0200, Ulf Hansson wrote:
> On Thu, 31 Jul 2025 at 14:18, Jon Hunter <jonathanh@...dia.com> wrote:
> >
> > After commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on
> > until late_initcall_sync") was applied, the Tegra210 Jetson TX1 board
> > failed to boot. Looking into this issue, before this commit was applied,
> > if any of the Tegra power-domains were in 'on' state when the kernel
> > booted, they were being turned off by the genpd core before any driver
> > had chance to request them. This was purely by luck and a consequence of
> > the power-domains being turned off earlier during boot. After this
> > commit was applied, any power-domains in the 'on' state are kept on for
> > longer during boot and therefore, may never transitioned to the off
> > state before they are requested/used. The hang on the Tegra210 Jetson
> > TX1 is caused because devices in some power-domains are accessed without
> > the power-domain being turned off and on, indicating that the
> > power-domain is not in a completely on state.
> >
> > From reviewing the Tegra PMC driver code, if a power-domain is in the
> > 'on' state there is no guarantee that all the necessary clocks
> > associated with the power-domain are on and even if they are they would
> > not have been requested via the clock framework and so could be turned
> > off later. Some power-domains also have a 'clamping' register that needs
> > to be configured as well. In short, if a power-domain is already 'on' it
> > is difficult to know if it has been configured correctly. Given that the
> > power-domains happened to be switched off during boot previously, to
> > ensure that they are in a good known state on boot, fix this by
> > switching off any power-domains that are on initially when registering
> > the power-domains with the genpd framework.
> >
> > Note that commit 05cfb988a4d0 ("soc/tegra: pmc: Initialise resets
> > associated with a power partition") updated the
> > tegra_powergate_of_get_resets() function to pass the 'off' to ensure
> > that the resets for the power-domain are in the correct state on boot.
> > However, now that we may power off a domain on boot, if it is on, it is
> > better to move this logic into the tegra_powergate_add() function so
> > that there is a single place where we are handling the initial state of
> > the power-domain.
> >
> > Fixes: a38045121bf4 ("soc/tegra: pmc: Add generic PM domain support")
> > Signed-off-by: Jon Hunter <jonathanh@...dia.com>
> 
> Thanks for looking into this!
> 
> I have picked this up via my pmdomain tree and applied it as a fix
> with a stable tag. Please let me know if you prefer to take this via
> your soc tree instead.
> 
> That said, I guess we have some use-cases on Tegra where it actually
> would make sense to allow powered-on PM-domains to stay on during
> boot. Although, at this point, it seems better to deal with those on a
> case by case basis, as improvements on top.

We're actually running into one of these cases right now. This happens
for display hardware where we have simple-framebuffer device tree nodes
that are meant to allow a seamless transition from the firmware's early
framebuffer to the Linux framebuffer. But since Jon's patch disables all
of the power domains, the seamless transition no longer works.

I suppose we could argue that seamless display is less important than
systems booting, so I'm inclined to say we want to keep this patch to
fix the earlier regression and then apply a fix on top to address the
issue with the early display.

Do you have any thoughts on how to deal with specific power domains that
should remain powered on during boot? Ideally it would be something
standard, but worst case we can also special-case in the Tegra PMC
driver.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)