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@xxxxxxxxxxxxxxx> Closes: https://github.com/thesofproject/linux/issues/4371 Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > Signed-off-by: Mark Brown <broonie@xxxxxxxxxx> > --- > 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,
