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: <6154950.lOV4Wx5bFT@workhorse>
Date: Tue, 13 May 2025 16:27:02 +0200
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Shawn Lin <shawn.lin@...k-chips.com>, Heiko Stuebner <heiko@...ech.de>,
 Elaine Zhang <zhangqing@...k-chips.com>,
 Finley Xiao <finley.xiao@...k-chips.com>,
 Adrian Hunter <adrian.hunter@...el.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Detlev Casanova <detlev.casanova@...labora.com>, kernel@...labora.com,
 linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-mmc@...r.kernel.org
Subject: Re: [PATCH v3] mmc: sdhci-of-dwcmshc: add PD workaround on RK3576

On Tuesday, 29 April 2025 12:06:16 Central European Summer Time Ulf Hansson wrote:
> On Wed, 23 Apr 2025 at 09:54, Nicolas Frattaroli
> <nicolas.frattaroli@...labora.com> wrote:
> >
> > RK3576's power domains have a peculiar design where the PD_NVM power
> > domain, of which the sdhci controller is a part, seemingly does not have
> > idempotent runtime disable/enable. The end effect is that if PD_NVM gets
> > turned off by the generic power domain logic because all the devices
> > depending on it are suspended, then the next time the sdhci device is
> > unsuspended, it'll hang the SoC as soon as it tries accessing the CQHCI
> > registers.
> >
> > RK3576's UFS support needed a new dev_pm_genpd_rpm_always_on function
> > added to the generic power domains API to handle what appears to be a
> > similar hardware design.
> >
> > Use this new function to ask for the same treatment in the sdhci
> > controller by giving rk3576 its own platform data with its own postinit
> > function. The benefit of doing this instead of marking the power domains
> > always on in the power domain core is that we only do this if we know
> > the platform we're running on actually uses the sdhci controller. For
> > others, keeping PD_NVM always on would be a waste, as they won't run
> > into this specific issue. The only other IP in PD_NVM that could be
> > affected is FSPI0. If it gets a mainline driver, it will probably want
> > to do the same thing.
> >
> > Acked-by: Adrian Hunter <adrian.hunter@...el.com>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> 
> Applied for next, thanks!
> 
> Kind regards
> Uffe
> 

Hi Uffe,

I was wondering whether we can get this into 6.15 as a fix as well, as 6.15
should already have the genpd API additions this requires AFAIU.

Fixes tag could be something like:

  Fixes: cfee1b507758 ("pmdomain: rockchip: Add support for RK3576 SoC")

but may need some more flavorings to keep the stable robot overlords from
trying to apply it to 6.14 and earlier and then starting the robot uprising
in your inbox when they notice the API is missing.

I originally left out the Fixes tag on the rewrite of this using the new
API because I wanted to avoid those awkward backport scenarios for a fairly
freshly supported SoC, but it'd be great to have this in 6.15 because that
will be with us for a full release cycle to come.

Kind regards,
Nicolas Frattaroli




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ