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]

Date:   Mon, 07 Jun 2021 14:06:26 +0200
From:   Sander Vanheule <sander@...nheule.net>
To:     Mark Brown <broonie@...nel.org>
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

Hi Mark,

On Mon, 2021-06-07 at 12:54 +0100, Mark Brown wrote:
> 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.

Thank you for the input. I'll take this to the RTL8231 thread, to see what I can
come up with as a cleaner solution, without abusing the regmap interface.


Best regards,
Sander