linux-kernel - Re: [PATCH v3 00/24] pmdomain: Add generic ->sync

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFr4t7KjV+bSB2_4wRM0tsSNB7fosoJHAN+yDgc1g=7FgA@mail.gmail.com>
Date: Fri, 26 Sep 2025 14:23:09 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Saravana Kannan <saravanak@...gle.com>, Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: 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>, 
	Jonathan Hunter <jonathanh@...dia.com>, Hiago De Franco <hiago.franco@...adex.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH v3 00/24] pmdomain: Add generic ->sync_state() support to genpd

On Fri, 26 Sept 2025 at 08:57, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Fri, 26 Sept 2025 at 00:41, Saravana Kannan <saravanak@...gle.com> wrote:
> > On Thu, Aug 7, 2025 at 2:43 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Wed, 30 Jul 2025 at 12:29, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > > > On Wed, 30 Jul 2025 at 11:56, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > > > BTW, the "pending due to"-messages look weird to me.
> > > > > On R-Car M2-W (r8a7791.dtsi) I see e.g.:
> > > > >
> > > > >     genpd_provider ca15-cpu0: sync_state() pending due to e6020000.watchdog
> > > > >     renesas-cpg-mssr e6150000.clock-controller: sync_state() pending
> > > > > due to e6020000.watchdog
> > > > >
> > > > > ca15-cpu0 is the PM Domain holding the first CPU core, while
> > > > > the watchdog resides in the always-on Clock Domain, and uses the
> > > > > clock-controller for PM_CLK handling.
> > >
> > > Unfortunately the first PM Domain is "ca15-cpu0", which is blocked on
> > > these bogus pending states, and no PM Domain is powered off.
> >
> > Can you explain why you call these as bogus? Sorry if you already
> > explained it. But the reason I'm asking is to see if you can set a
> > flag for the watchdog device so fw_devlink will completely ignore it.
>
> "bogus" refers to "1." below.
>
> Furthermore, devices that are located in an alway-on domain should
> not block the sync state.
>
> > It looks like there's a driver for this watchdog node? Why is it not
> > probing then?
>
> Because this particular revision of the SoC has a hardware bug that
> prevents the watchdog timer from rebooting the system, and the driver
> detects that.
>
> Anyway, if the driver is not available, unused power domains should
> still be powered down, like before.
>
> > > If I remove the "sync_state = false" above, genpd_provider_sync_state()
> > > considers all domains, and does power down all unused domains (even
> > > multiple times, as expected).
> > >
> > > Upon closer look, all "pending due to" messages I see claim that the
> > > first (index 0) PM Domain is pending on some devices, while all of
> > > these devices are part of a different domain (usually the always-on
> > > domain, which is always the last (32 or 64) on R-Car).
> > >
> > > So I think there are two issues:
> > >   1. Devices are not attributed to the correct PM Domain using
> > >      fw_devlink sync_state,
> >
> > Is it a fw_devlink issue? Or is this a multi-domain controller?
>
> This is a multi-domain controller.
>
> > >   2. One PM Domain of a multi-domain controller being blocked should
> > >      not block all other domains handled by the same controller.
> >
> > This is going to take a while to sort out. But the current behavior is
> > the safest. How grumpy will you be if we don't fix this :)
>
> Depending on your definition of "safe".  Keeping all power domains on
> increases power consumption and heat generation, and may cause e.g. CPU
> frequency throttling to kick in, slowing down operation of the system.

FYI, I agree that we need to address these problems, in one way or the
other. I am trying to summarize them and have also proposed a CFP for
LPC (power/thermal MC) to discuss and try to solve them.

Now, as I also proposed in the other thread [1] just now. How about
changing the default behaviour from FW_DEVLINK_SYNC_STATE_STRICT to
FW_DEVLINK_SYNC_STATE_TIMEOUT? I think that would solve a lot of
problems for us, as it would provide a more similar behaviour to what
we had in genpd originally, hence it would be a smoother transition.

I think this would be true when trying to add ->sync_state() support
for other subsystems too, like clocks and regulators.

In the end, when platforms are ready to move to the "strict" mode,
they can do that via the command-line parameter, for example.

Kind regards
Uffe

[1]
https://lore.kernel.org/all/20250925115924.188257-1-ulf.hansson@linaro.org/