linux-kernel - Re: [PATCH v3 0/6] RTL8231 GPIO expander 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:   Sun, 30 May 2021 23:22:21 +0200
From:   Michael Walle <michael@...le.cc>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Sander Vanheule <sander@...nheule.net>,
        Andrew Lunn <andrew@...n.ch>, Pavel Machek <pavel@....cz>,
        Rob Herring <robh+dt@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 0/6] RTL8231 GPIO expander support

Am 2021-05-30 20:16, schrieb Andy Shevchenko:
> On Sun, May 30, 2021 at 7:51 PM Hans de Goede <hdegoede@...hat.com> 
> wrote:
>> On 5/30/21 6:19 PM, Sander Vanheule wrote:
>> > On Fri, 2021-05-28 at 08:37 +0200, Michael Walle wrote:
> 
> ...
> 
>> > I think I found a solution!

nice!

>> > As Michael suggested, I tried raw register reads and writes, to eliminate any
>> > side effects of the intermediate code. I didn't use the ioctls (this isn't a
>> > netdev), but I found regmap's debugfs write functionality, which allowed me to
>> > do the same.
>> >
>> > I was trying to reproduce the behaviour I reported earlier, but couldn't. The
>> > output levels were always the intended ones. At some point I realised that the
>> > regmap_update_bits function does a read-modify-write, which might shadow the
>> > actual current output value.
>> > For example:
>> >  * Set output low: current out is low
>> >  * Change to input with pull-up: current out is still low, but DATAx reads high
>> >  * Set output high: RMW reads a high value (the input), so assumes a write is
>> >    not necessary, leaving the old output value (low).
>> >
>> > Currently, I see two options:
>> >  * Use regmap_update_bits_base to avoid the lazy RMW behaviour
>> >  * Add a cache for the output data values to the driver, and only use these
>> >    values to write to the output registers. This would allow keeping lazy RMW
>> >    behaviour, which may be a benefit on slow busses.
>> >
>> > With either of these implemented, if I set the output value before the
>> > direction, everything works! :-)
>> >
>> > Would you like this to be added to regmap-gpio, or should I revert back to a
>> > device-specific implementation?
>> 
>> Regmap allows you to mark certain ranges as volatile, so that they 
>> will not
>> be cached, these GPIO registers containing the current pin value seems 
>> like
>> a good candidate for this. This is also necessary to make reading the 
>> GPIO
>> work without getting back a stale, cached value.
> 
> After all it seems a simple missed proper register configuration in
> the driver for regmap.
> Oh, as usual something easy-to-solve requires tons of time to find it. 
> :-)
> 
> Sander, I think you may look at gpio-pca953x.c to understand how it
> works (volatility of registers).

But as far as I see is the regmap instantiated without a cache?

-michael