mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: Mark Brown <broonie@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH] regmap: support regmap_field_write() on non-readable fields
Date: Tue, 19 Jul 2022 15:13:11 +0200	[thread overview]
Message-ID: <d04ef271-9404-481c-f2fa-268ff51ee3dc@linaro.org> (raw)
In-Reply-To: <20220719125401.GA92394@ediswmail.ad.cirrus.com>

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@linaro.org>
>>
>> ---
>>
>> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
>> ---
>>  drivers/base/regmap/regmap.c | 50 ++++++++++++++++++++++++++++++++++++
>>  include/linux/regmap.h       | 15 ++---------
>>  2 files changed, 52 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
>> index 0caa5690c560..4d18a34f7b2c 100644
>> --- a/drivers/base/regmap/regmap.c
>> +++ b/drivers/base/regmap/regmap.c
>> @@ -2192,6 +2192,56 @@ int regmap_noinc_write(struct regmap *map, unsigned int reg,
>>  }
>>  EXPORT_SYMBOL_GPL(regmap_noinc_write);
>>  
>> +static int _regmap_field_write_or_update(struct regmap_field *field,
>> +					 unsigned int val, bool *change,
>> +					 bool async, bool force)
>> +{
>> +	unsigned int mask = (~0 << field->shift) & field->mask;
>> +	unsigned int map_val_mask, map_val_mask_h;
>> +	int ret;
>> +
>> +	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.


Best regards,
Krzysztof

  parent reply	other threads:[~2022-07-19 14:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19 12:14 Krzysztof Kozlowski
2022-07-19 12:53 ` Mark Brown
2022-07-19 12:54 ` Charles Keepax
2022-07-19 13:04   ` Mark Brown
2022-07-19 13:13   ` Krzysztof Kozlowski [this message]
2022-07-19 13:41     ` Mark Brown
2022-07-19 14:30       ` Krzysztof Kozlowski
2022-07-19 16:00         ` Krzysztof Kozlowski
2022-07-19 13:42     ` Charles Keepax

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d04ef271-9404-481c-f2fa-268ff51ee3dc@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®