Re: [PATCH] tty: max310x: work around regmap->regcache data corruption

[Hugo Villeneuve <hugo@hugovil.com>]

On Fri, 1 Dec 2023 17:16:44 -0500
Hugo Villeneuve <hugo@hugovil.com> wrote:

> On Fri, 1 Dec 2023 21:41:48 +0000
> Mark Brown <broonie@kernel.org> wrote:
> 
> > On Fri, Dec 01, 2023 at 04:38:46PM -0500, Hugo Villeneuve wrote:
> > > Mark Brown <broonie@kernel.org> wrote:
> > 
> > > > If you're working on that driver it'd also be good to update the current
> > > > use of cache bypass for the enhanced features/interrupt identification
> > > > register (and anything else in there, that did seem to be the only one)
> > > > to use regmap ranges instead - that'd remove the need for the efr_lock
> > > > and be a much more sensible/idiomatic use of the regmap APIs.
> > 
> > > I will also look to remove the efr_lock, altough it has more
> > > implications since this ship has some registers that share a common
> > > address, and selected by bits in other registers, and I think this
> > > is why there is this efr_lock.
> > 
> > Right, the registers sharing a common address with the register selected
> > by bits in another register is what regmap ranges support - the less
> > creative use of this is banked blocks of registers with a selector
> > register which picks which page bank is in use, that's moderately common
> > especially for TI.
> 
> Hi Mark,
> thanks for the info, I was not aware of that, and will look into it.
> 
> Hugo Villeneuve.

Hi Mark,
I am having a hard time finding documentation on how regmap ranges
work.

Do you have an example of a driver which is using regmap ranges like it
should be done in this driver, that is using the exact same address for
two or more registers? I found an example, but it doesn't seem
applicable to the sc16is7xx driver because the two registers do not
share a common address, for example they have addresses like 0x01 and
0x81, even though with the proper page selection, they finally map to
address 0x01.

Thank you,
Hugo Villeneuve