lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 1 Dec 2023 21:41:48 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Hugo Villeneuve <hugo@...ovil.com>
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, 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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ