From: Hugo Villeneuve <hugo@hugovil.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Jan Kundrát" <jan.kundrat@cesnet.cz>,
"Cosmin Tanislav" <cosmin.tanislav@analog.com>,
linux-serial@vger.kernel.org,
"Andy Shevchenko" <andy.shevchenko@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tty: max310x: work around regmap->regcache data corruption
Date: Tue, 5 Dec 2023 10:52:46 -0500 [thread overview]
Message-ID: <20231205105246.a0864cd10ff0252dec9ffabc@hugovil.com> (raw)
In-Reply-To: <ce3eaa82-66e9-404b-9062-0f628dc6164f@sirena.org.uk>
On Fri, 1 Dec 2023 18:34:38 +0000
Mark Brown <broonie@kernel.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
next prev parent reply other threads:[~2023-12-05 15:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 14:51 Jan Kundrát
2023-12-01 16:14 ` Andy Shevchenko
2023-12-01 16:23 ` Mark Brown
2023-12-01 16:21 ` Mark Brown
2023-12-01 17:02 ` Andy Shevchenko
2023-12-02 10:29 ` Jan Kundrát
2023-12-01 18:27 ` Hugo Villeneuve
2023-12-01 18:34 ` Mark Brown
2023-12-01 21:38 ` Hugo Villeneuve
2023-12-01 21:41 ` Mark Brown
2023-12-01 22:16 ` Hugo Villeneuve
2023-12-04 16:29 ` Hugo Villeneuve
2023-12-04 16:35 ` Mark Brown
2023-12-04 17:01 ` Hugo Villeneuve
2023-12-04 17:19 ` Mark Brown
2023-12-04 18:59 ` Hugo Villeneuve
2023-12-04 19:16 ` Mark Brown
2023-12-04 19:41 ` Hugo Villeneuve
2023-12-04 19:48 ` Mark Brown
2023-12-04 20:02 ` Hugo Villeneuve
2023-12-04 22:09 ` Mark Brown
2023-12-05 15:52 ` Hugo Villeneuve [this message]
2023-12-05 16:00 ` Mark Brown
2023-12-01 21:40 ` Hugo Villeneuve
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231205105246.a0864cd10ff0252dec9ffabc@hugovil.com \
--to=hugo@hugovil.com \
--cc=andy.shevchenko@gmail.com \
--cc=broonie@kernel.org \
--cc=cosmin.tanislav@analog.com \
--cc=jan.kundrat@cesnet.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®