On 5/23/23 17:18, Mark Brown wrote:
Unfortunately the maple tree requires us to explicitly lock it so we need to take the RCU read lock while iterating. When syncing this means that we end up trying to write out register values while holding the RCU read lock which triggers lockdep issues since that is an atomic context but most buses can't be used in atomic context. Pause the iteration and drop the lock for each register we check to avoid this.
Reported-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Closes: https://github.com/thesofproject/linux/issues/4371 Tested-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown broonie@kernel.org
drivers/base/regmap/regcache-maple.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regcache-maple.c b/drivers/base/regmap/regcache-maple.c index 9b1b559107ef..c2e3a0f6c218 100644 --- a/drivers/base/regmap/regcache-maple.c +++ b/drivers/base/regmap/regcache-maple.c @@ -203,15 +203,18 @@ static int regcache_maple_sync(struct regmap *map, unsigned int min,
mas_for_each(&mas, entry, max) { for (r = max(mas.index, lmin); r <= min(mas.last, lmax); r++) {
mas_pause(&mas);rcu_read_unlock(); ret = regcache_sync_val(map, r, entry[r - mas.index]); if (ret != 0) goto out;rcu_read_lock();-out: rcu_read_unlock();
+out: map->cache_bypass = false;
return ret;
base-commit: 44c026a73be8038f03dbdeef028b642880cf1511 change-id: 20230523-regcache-maple-sync-lock-57ea356dc60b
Best regards,