linux-kernel - Re: [PATCH 03/18] reset: rzv2h-usb2phy: Simplify pm

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: <c3e1e3da577de1370e7604560f0b42c0fcb7db44.camel@pengutronix.de>
Date: Mon, 06 Oct 2025 18:21:25 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>, 
	tomm.merciai@...il.com
Cc: linux-renesas-soc@...r.kernel.org, biju.das.jz@...renesas.com, Yoshihiro
 Shimoda <yoshihiro.shimoda.uh@...esas.com>, Vinod Koul <vkoul@...nel.org>,
 Kishon Vijay Abraham I	 <kishon@...nel.org>, Geert Uytterhoeven
 <geert+renesas@...der.be>, Magnus Damm	 <magnus.damm@...il.com>, Fabrizio
 Castro <fabrizio.castro.jz@...esas.com>,  Lad Prabhakar
 <prabhakar.mahadev-lad.rj@...renesas.com>, linux-phy@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/18] reset: rzv2h-usb2phy: Simplify pm_runtime driver
 handling

Hi Tommaso,

On Mi, 2025-10-01 at 23:26 +0200, Tommaso Merciai wrote:
> Remove redundant pm_runtime_resume_and_get() and pm_runtime_put() calls
> from the reset assert, deassert, and status paths.

These calls are only made redundant by this patch.

> These paths do not require runtime PM handling, as power management is
> already taken care of during probe and remove.

Only since you removed the pm_runtime_put() in
rzv2h_usb2phy_reset_probe(). It feels like the important part of this
patch is actually the side note:

> Additionally, the IP is active only when its clock is enabled.
> Previously, the clock was being turned off immediately after register
> configuration, which is incorrect. The code may have appeared to work
> if another module had incremented the clock usage count, but this
> behavior is unreliable.

So this is a reliability fix first and foremost?
The IP must be active to reliably keep reset lines at the configured
level?

If so, please make this clear in the commit subject and description.

regards
Philipp