linux-kernel - Re: [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support

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]

Message-ID: <20210607115448.GB5705@sirena.org.uk>
Date:   Mon, 7 Jun 2021 12:54:48 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Sander Vanheule <sander@...nheule.net>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support

On Fri, Jun 04, 2021 at 08:16:53PM +0200, Sander Vanheule wrote:
> On Fri, 2021-06-04 at 18:25 +0100, Mark Brown wrote:

> > I think these registers are in practice going to either need to be
> > volatile (how most of them work at the minute) or otherwise handled in
> > regmap (eg, the page support we've got).  Having two different names for
> > the same register feels like it's asking for bugs if any of the higher
> > level functions of regmap get used.

> This is actually an issue with a GPIO chip that I'm trying to implement [1]. To
> set an output, data is written to the register. To get an input value, data is
> read from the register. Since a register contains data for 16 GPIO lines, a
> regular read-modify-write could erroneously overwrite output values. A pin
> outside of the RMW mask could've changed to an input, and may now be reading a
> different value. The issue I was running into, had to do with a RMW not being
> written because the pin value apparently hadn't changed.

If the hardware isn't able to read back the status of the pins in output
mode (even if it's always reading back from the input circuit where is
it getting other inputs from?) you're probably better off with just
having an open coded cache separately than trying to make up fake
registers that rely on current implementation details to work.

> I didn't use the existing paging mechanism for this, since (I think) then I
> would need to specify a register that contains the page index. But as I don't
> have an actual page register, I would have to specify another existing register
> with an empty mask. This could lead to useless bus activity if I accidentally
> chose a volatile register.

This is clearly not paging, it would be totally inappropraite to use
paging for this.

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