[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20231205105246.a0864cd10ff0252dec9ffabc@hugovil.com>
Date: Tue, 5 Dec 2023 10:52:46 -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 18:34:38 +0000
Mark Brown <broonie@...nel.org> wrote:
> On Fri, Dec 01, 2023 at 01:27:36PM -0500, Hugo Villeneuve wrote:
>
> > it is funny, as I am preparing to send a patch for the sc16is7xx driver
> > to convert FIFO R/W to use the _noinc_ versions of regmap functions,
> > inspired by your patch 3f42b142ea11 ("serial: max310x: fix IO data
> > corruption in batched operations").
>
> 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.
Hi Mark,
after our discussion about regmap range, it seems that the
efr_lock will need to stay.
In fact, all of this helped me to uncover another case where an
additional lock would be needed.
Hugo Villeneuve
Powered by blists - more mailing lists