linux-kernel - Re: [RFC PATCH] i3c: dw: add option to disable runtime PM for DesignWare I3C controller

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: <20251030170929b5991b7d@mail.local>
Date: Thu, 30 Oct 2025 18:09:29 +0100
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: adrianhoyin.ng@...era.com, dinguyen@...nel.org, Frank.Li@....com,
	linux-i3c@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] i3c: dw: add option to disable runtime PM for
 DesignWare I3C controller

On 16/10/2025 09:37:53+0200, Wolfram Sang wrote:
> 
> > > Add a new Kconfig option, DW_I3C_DISABLE_RUNTIME_PM, that allows
> > > disabling all runtime power management (PM) operations for the
> > > Synopsys DesignWare I3C controller. When this option is selected,
> > > the driver skips all runtime PM calls such as pm_runtime_enable(),
> > > pm_runtime_get(), and pm_runtime_put(), keeping the controller
> > > permanently active.
> > 
> > While the quirk may make sense, it definitively can't be activated by a
> > Kconfig option. This should rather be tied to a new compatible string or
> > a property.
> 
> I wondered why this is a quirk, at all, and not default behaviour. Is it
> because it works with some RPM implementations and not with others,
> depending on the platform?
> 
> But even if that is the case, it might be worth to opt-in for power
> management instead of opting-out for buggy behaviour. Because I would
> not assume that IBI have been thoroughly tested when a new platform
> using this driver gets upstream. So, the buggy behaviour may only be
> recognized later. Or?
> 

I guess it depends on how the IP has been integrated on the SoC, hence
my suggestion to tie this to a compatible string. opt-in or opt-out, I
don't care too much but seeing this seems to work for AMD, we need to
keep the existing behaviour for them.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com