[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20231201171644.6f7ade89d4c2f744fa3556b7@hugovil.com>
Date: Fri, 1 Dec 2023 17:16:44 -0500
From: Hugo Villeneuve <hugo@...ovil.com>
To: Mark Brown <broonie@...nel.org>
Cc: Jan Kundrát <jan.kundrat@...net.cz>,
Cosmin Tanislav <cosmin.tanislav@...log.com>,
linux-serial@...r.kernel.org,
Andy Shevchenko <andy.shevchenko@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tty: max310x: work around regmap->regcache data
corruption
On Fri, 1 Dec 2023 21:41:48 +0000
Mark Brown <broonie@...nel.org> wrote:
> On Fri, Dec 01, 2023 at 04:38:46PM -0500, Hugo Villeneuve wrote:
> > Mark Brown <broonie@...nel.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.
Powered by blists - more mailing lists