Thanks Mark for review,
On 18/06/2021 12:51, Mark Brown wrote:
On Fri, Jun 18, 2021 at 12:35:58PM +0100, Srinivas Kandagatla wrote:
The issue that I encountered is when doing regmap_update_bits on
a write only register. In regcache path this will not do the right
thing as the register is not readable and driver which is using
regmap_update_bits will never notice that it can not do a update
bits on write only register leading to inconsistent writes and
random hardware behavior.
Why will use of regmap_update_bits() mean that a driver will never
notice a write failure? Shouldn't remgap_update_bits() be fixed to
report any errors it isn't reporting, or the driver fixed to check
usecase is performing regmap_update_bits() on a *write-only* registers.
_regmap_update_bits() checks _regmap_read() return value before bailing
out. In non cache path we have this regmap_readable() check however in
cached patch we do not have this check, so _regmap_read() will return
success in this case so regmap_update_bits() never reports any error.
driver in question does check the return value.
error codes? I really don't understand the issue you're trying to
report - what is "the right thing" and what makes you believe that a
driver can't do an _update_bits() on a write only but cached register?
Can you specify in concrete terms what the problem is.
So one of recent patch ("ASoC: qcom: Fix for DMA interrupt clear reg
overwriting)
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20210618&id=da0363f7bfd3c32f8d5918e40bfddb9905c86ee1
broke audio on DragonBoard 410c.
This patch simply converts writes to regmap_update_bits for that
particular dma channel. The register that its updating is IRQ_CLEAR
register which is software "WRITE-ONLY" and Hardware read-only register.
The bits in particular case is updating is a period interrupt clear bit.
Because we are using regmap cache in this driver,
first regmap_update_bits(map, 0x1, 0x1) on first period interrupt will
update the cache and write to IRQ_CLEAR hardware register which then
clears the interrupt latch.
On second period interrupt we do regmap_update_bits(map, 0x1, 0x1) with
the same bits, Because we are using cache for this regmap caches sees no
change in the cache value vs the new value so it will never write/update
IRQ_CLEAR hardware register, so hardware is stuck here waiting for
IRQ_CLEAR write from driver and audio keeps repeating the last period.
There seems to be missing checks in regcache_read() which is
now added by moving the orignal check in _regmap_read() before
accessing regcache.
Cc: stable@xxxxxxxxxxxxxxx
Fixes: 5d1729e7f02f ("regmap: Incorporate the regcache core into regmap")
Are you *sure* you've identified the actual issue here - nobody has seen
I think so, my above triage does summarizes the problem in detail.
any problems with this in the past decade? Please don't just pick a
random commit for the sake of adding a Fixes tag.
I did git blame and picked up this changeset which is when the cache was
integrated.
@@ -2677,6 +2677,9 @@ static int _regmap_read(struct regmap *map, unsigned int reg,
int ret;
void *context = _regmap_map_get_context(map);
+ if (!regmap_readable(map, reg))
+ return -EIO;
+
if (!map->cache_bypass) {
ret = regcache_read(map, reg, val);
if (ret == 0)
@@ -2686,9 +2689,6 @@ static int _regmap_read(struct regmap *map, unsigned int reg,
if (map->cache_only)
return -EBUSY;
- if (!regmap_readable(map, reg))
- return -EIO;
-
This puts the readability check before the cache check which will break
all drivers using the cache on write only registers.
Initially I added check in regcache_read(), later I moved it to
_regmap_read. do you think check in regcache_read() is the correct place?
--srini
