linux-kernel - Re: [PATCH] regmap: support regmap_field

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: <20220719134251.GB92394@ediswmail.ad.cirrus.com>
Date:   Tue, 19 Jul 2022 13:42:51 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
CC:     Mark Brown <broonie@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        <linux-kernel@...r.kernel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH] regmap: support regmap_field_write() on non-readable
 fields

On Tue, Jul 19, 2022 at 03:13:11PM +0200, Krzysztof Kozlowski wrote:
> On 19/07/2022 14:54, Charles Keepax wrote:
> > On Tue, Jul 19, 2022 at 02:14:46PM +0200, Krzysztof Kozlowski wrote:
> >> Current implementation of regmap_field_write() performs an update of
> >> register (read+write), therefore it ignores regmap read-restrictions and
> >> is not suitable for write-only registers (e.g. interrupt clearing).
> >>
> >> Extend regmap_field_write() and regmap_field_force_write() to check if
> >> register is readable and only then perform an update.  In the other
> >> case, it is expected that mask of field covers entire register thus a
> >> full write is allowed.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> >>
> >> ---
> >> +	if (regmap_readable(field->regmap, field->reg))
> >> +		return regmap_update_bits_base(field->regmap, field->reg,
> >> +					       mask, val << field->shift,
> >> +					       change, async, force);
> >> +
> > 
> > I think this will break other valid use-cases, regmap_readable (I
> > believe) returns if the register is physically readable, however
> > it should still be possible to use update bits if the register is
> > in the cache even if it can't physically be read. So really you
> > need to fall into this path if it is readable or in the cache.
> 
> But what type of real use case this would be trying to solve? Either
> register is readable or not. The presence of cache is just optimization
> and does not change the fact that we cannot read from register thus no
> need to go via updates.
> 
> > 
> > Which does I guess also raise the question if your problem would
> > be better solved with caching the register?
> 
> And how the value would appear in the cache? Since register cannot be
> read, I expect the cache to be filled on first update. First update
> would be read+write, so we are stuck again.
> 

The cache is initialised from the defaults table, so normal
proceedure for unreadable registers is you start out with the
hardware default and since you know when you wrote it the value
stays in sync.

Thanks,
Charles