Hi Mark and Lee, On Tue, Jan 11, 2022 at 01:44:28PM +0000, Mark Brown wrote: > On Tue, Jan 11, 2022 at 10:13:43AM +0000, Lee Jones wrote: > > > Unless something has changed or my understanding is not correct, > > regmap does not support over-lapping register ranges. > > If there's no caches and we're always going direct to hardware it will > work a lot of the time since the buses generally have concurrency > protection at the lowest level, though if the drivers ever do any > read/modify/write operations the underlying hardware bus isn't going to > know about it so you could get data corruption if two drivers decide to > try to operate on the same register. If there's caches things will > probably go badly since the cache will tend to amplify the > read/modify/write issues. Good point about caches. No, nothing in these drivers utilize caches currently, but that doesn't mean it shouldn't... or won't. Any concurrency in this specific case would be around the SPI bus. I think the "overlapping regmaps" already exist in the current drivers... but actually I'm not so sure anymore. Either way, this is helping nudge me in the right direction. > > > However, even if that is required, I still think we can come up with > > something cleaner than creating a whole API based around creating > > and fetching different regmap configurations depending on how the > > system was initialised. > > Yeah, I'd expect the usual pattern is to have wrapper drivers that > instantiate a regmap then have the bulk of the driver be a library that > they call into should work. Understood. And I think this can make sense and clean things up. The "ocelot_core" mfd will register every regmap range, regardless of whether any child actually uses them. Every child can then get regmaps by name, via dev_get_regmap. That'll get rid of the back-and-forth regmap hooks. I think I know where to go from here. Thank you both! I'll send along another RFC soon, once I can get this all cleaned up.