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: <20210604172515.GG4045@sirena.org.uk>
Date:   Fri, 4 Jun 2021 18:25:15 +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 Thu, Jun 03, 2021 at 08:25:08PM +0200, Sander Vanheule wrote:

> 1. I've opted to just ignore any bits that lie beyond the allowed address
>    width. Would it be cleaner to raise an error instead?

It doesn't *really* matter, enforcement is probably a bit better as it
might catch bugs.

> 2. Packing of the clause-45 register addresses (16 bit) and adressed device
>    type (5 bit) is the same as in the mdio subsystem, resulting in a 21 bit
>    address. Is this an appropriate way to pack this information into one
>    address for the regmap interface?

Either that or pass the type in when instantiating the regmap (it sounds
like it should be the same for all registers on the device?).

> The reasoning behind (1) is to allow the regmap user to use extra bits
> as a way to virtually extend the address space. Note that this actually
> results in aliasing. This can be useful if the data read from to a
> register doesn't have the same meaning as the data written to it
> (e.g. GPIO pin input and output data). An alternative solution to this
> would be some concept of "aliased registers" in regmap -- like volatile or
> precious registers.

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.

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