linux-kernel - Re: [PATCH v3 21/24] pmdomain: core: Leave powered-on genpds on until late_initcall

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <01646690-8964-49c8-bbed-556380844b14@nvidia.com>
Date: Tue, 15 Jul 2025 11:28:15 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Ulf Hansson <ulf.hansson@...aro.org>,
 Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Saravana Kannan <saravanak@...gle.com>, Stephen Boyd <sboyd@...nel.org>,
 linux-pm@...r.kernel.org, "Rafael J . Wysocki" <rafael@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Michael Grzeschik <m.grzeschik@...gutronix.de>,
 Bjorn Andersson <andersson@...nel.org>, Abel Vesa <abel.vesa@...aro.org>,
 Peng Fan <peng.fan@....nxp.com>,
 Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 Johan Hovold <johan@...nel.org>, Maulik Shah <maulik.shah@....qualcomm.com>,
 Michal Simek <michal.simek@....com>, Konrad Dybcio <konradybcio@...nel.org>,
 Thierry Reding <thierry.reding@...il.com>,
 Hiago De Franco <hiago.franco@...adex.com>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v3 21/24] pmdomain: core: Leave powered-on genpds on until
 late_initcall_sync

Hi Ulf,

On 10/07/2025 15:54, Ulf Hansson wrote:
> On Thu, 10 Jul 2025 at 14:26, Marek Szyprowski <m.szyprowski@...sung.com> wrote:
>>
>> On 01.07.2025 13:47, Ulf Hansson wrote:
>>> Powering-off a genpd that was on during boot, before all of its consumer
>>> devices have been probed, is certainly prone to problems.
>>>
>>> As a step to improve this situation, let's prevent these genpds from being
>>> powered-off until genpd_power_off_unused() gets called, which is a
>>> late_initcall_sync().
>>>
>>> Note that, this still doesn't guarantee that all the consumer devices has
>>> been probed before we allow to power-off the genpds. Yet, this should be a
>>> step in the right direction.
>>>
>>> Suggested-by: Saravana Kannan <saravanak@...gle.com>
>>> Tested-by: Hiago De Franco <hiago.franco@...adex.com> # Colibri iMX8X
>>> Tested-by: Tomi Valkeinen <tomi.valkeinen@...asonboard.com> # TI AM62A,Xilinx ZynqMP ZCU106
>>> Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
>>
>> This change has a side effect on some Exynos based boards, which have
>> display and bootloader is configured to setup a splash screen on it.
>> Since today's linux-next, those boards fails to boot, because of the
>> IOMMU page fault.
> 
> Thanks for reporting, let's try to fix this as soon as possible then.
> 
>>
>> This happens because the display controller is enabled and configured to
>> perform the scanout from the spash-screen buffer until the respective
>> driver will reset it in driver probe() function. This however doesn't
>> work with IOMMU, which is being probed earlier than the display
>> controller driver, what in turn causes IOMMU page fault once the IOMMU
>> driver gets attached. This worked before applying this patch, because
>> the power domain of display controller was simply turned off early
>> effectively reseting the display controller.
> 
> I can certainly try to help to find a solution, but I believe I need
> some more details of what is happening.
> 
> Perhaps you can point me to some relevant DTS file to start with?
> 
>>
>> This has been discussed a bit recently:
>> https://lore.kernel.org/all/544ad69cba52a9b87447e3ac1c7fa8c3@disroot.org/
>> and I can add a workaround for this issue in the bootloaders of those
>> boards, but this is something that has to be somehow addressed in a
>> generic way.
> 
> It kind of sounds like there is a missing power-domain not being
> described in DT for the IOMMU, but I might have understood the whole
> thing wrong.
> 
> Let's see if we can work something out in the next few days, otherwise
> we need to find another way to let some genpds for these platforms to
> opt out from this new behaviour.

Have you found any resolution for this? I have also noticed a boot 
regression on one of our Tegra210 boards and bisect is pointing to this 
commit. I don't see any particular crash, but a hang on boot.

If there is any debug we can enable to see which pmdomain is the problem 
let me know.

Thanks!
Jon

-- 
nvpublic