linux-kernel - Re: [PATCH v1 2/5] ASoC: cs35l56: Add struct to index firmware registers

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: <4b00f887-143c-415d-a464-dc847b7d84d5@opensource.cirrus.com>
Date: Wed, 9 Apr 2025 12:33:50 +0100
From: Richard Fitzgerald <rf@...nsource.cirrus.com>
To: Mark Brown <broonie@...nel.org>
Cc: Stefan Binding <sbinding@...nsource.cirrus.com>,
        linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
        patches@...nsource.cirrus.com
Subject: Re: [PATCH v1 2/5] ASoC: cs35l56: Add struct to index firmware
 registers

On 08/04/2025 5:00 pm, Mark Brown wrote:
> On Tue, Apr 08, 2025 at 01:58:23PM +0100, Richard Fitzgerald wrote:
>> On 07/04/2025 8:16 pm, Mark Brown wrote:
> 
>>> This is fine but note that this is the use case that the regmap_field_
>>> APIs were created for, that also helps deal with things if anyone is
>>> clever and resizes fields or shifts within registers.  It's purely a
>>> question of taste if you want to use that.
> 
>> The regmap_field stuff looks like a lot of unnecessary complexity and
>> overhead just for 6 registers with alternate addresses.
> 
> Yeah, like I say it's a taste thing.
>

If you would prefer us to use it we'll make the changes.
If not, then we'd like to keep the code as it is for now and in
future we'll have a look at regmap_field.

>> (In fact, the regmap_field stuff looks like an over-complex way of
>> solving a non-problem. The original commit is talking about replacing
>> masks and shifts "all over the code" to make the code neater. But
>> really, all those extra structs and pointers and allocated memory just
>> to replace a logical & or | ? Every struct regmap_field has a pointer
>> to the struct regmap !!?! So if I've got 100 fields there are 100 copies
>> of the struct regmap pointer that my driver already has.)
> 
> It was for cases where the shifts and widths may also change, there's a
> bit more than applying a mask.  Like you say it's got some overhead
> hence the taste thing.

Yes. If we had registers where the fields were moving around then there
would be better justification for using regmap_field.