linux-kernel - Re: [PATCH 2/4] ASoC: codecs: Add support for Richtek rt9123

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: <Z/SdvomJQKwqte97@git-send.richtek.com>
Date: Tue, 8 Apr 2025 11:53:34 +0800
From: ChiYuan Huang <cy_huang@...htek.com>
To: Mark Brown <broonie@...nel.org>
CC: Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
	<conor+dt@...nel.org>, Rob Herring <robh@...nel.org>, Liam Girdwood
	<lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai
	<tiwai@...e.com>, Otto lin <otto_lin@...htek.com>, Allen Lin
	<allen_lin@...htek.com>, <devicetree@...r.kernel.org>,
	<linux-sound@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] ASoC: codecs: Add support for Richtek rt9123

On Mon, Apr 07, 2025 at 01:34:29PM +0100, Mark Brown wrote:
> On Mon, Apr 07, 2025 at 08:44:05AM +0800, ChiYuan Huang wrote:
> > On Fri, Apr 04, 2025 at 04:03:57PM +0100, Mark Brown wrote:
> 
> > > What's going on with the runtime PM stuff here?  Especially for the DAPM
> > > widget usually the ASoC core will be able to keep devices runtime PM
> > > enabled so long as they are in use so I'd expect this not to have any
> > > impact.  Why not just use a normal DAPM widget?
> 
> > That's because The RG 0x01 'RT9123_REG_AMPCTRL' is mixed with other volatile
> > status bitfield like as 'SW_RST', 'SYS_STATE'. That's why I use pm_runtime to
> > make sure the RG can really be accessed at that time. Actually, the
> > mixed RG bitfield  for 'RW' and 'RO' is a bad design.
> 
> You need some comments explaining what's going on here.  If the volatile
> fields are read only shouldn't you be OK, so long as the register is not
> cached you should be able to do a read modify write fine?  Unless the
> status bits are clear on read.

Okay, I'll left some comments to make it more clear for why special handling.
And yes, Since this register cannot be cached, to use pm_runtime can guarantee
the read modify write fine.

Is my understanding correct?