Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 8 Jul 2021 15:23:06 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Sander Vanheule <sander@svanheule.net>
Cc:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
        Lee Jones <lee.jones@linaro.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Michael Walle <michael@walle.cc>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Linux LED Subsystem <linux-leds@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Andrew Lunn <andrew@lunn.ch>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 2/8] gpio: regmap: Add quirk for aliased data registers
Message-ID: <20210708142306.GA4106@sirena.org.uk>
References: <cover.1623532208.git.sander@svanheule.net>
 <5d8e5e8a29ecf39da48beb94c42003a5c686ec4e.1623532208.git.sander@svanheule.net>
 <CAHp75VeOMb2xUJ+g2UQJnBybmehmYr0dGPEzDZObUGr=Q95+wA@mail.gmail.com>
 <dee12a4f5dc1a37feb14e20074cf365dbb86bc05.camel@svanheule.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs"
Content-Disposition: inline
In-Reply-To: <dee12a4f5dc1a37feb14e20074cf365dbb86bc05.camel@svanheule.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jul 07, 2021 at 10:53:19PM +0200, Sander Vanheule wrote:

> I've made an attempt at implementing a "regmap_aliased()", similar to
> "regmap_volatile()". However, this meant I had to make _regmap_read() aware of
> wether the read- or write-alias was being read (from cache), touching some parts
> of the regmap code I'm not using myself. Furthermore, this "aliased" property
> isn't really perpendicular to "volatile", since writes should never be volatile,
> and non-volatile reads don't make much sense (to me) on a read-only register.

As far as the abstractions in regmap are concerned these registers are
volatile, that's currently how regmap undertands registers where
readback won't give you the last written value.  Trying to convince the
framework to handle these registers as anything other than volatile is
going to of need be an invasive change.

> If a regmap_field could overwrite the specifiers of it's parent register, I
> think this may provide quite a natural solution to the aliasing problem: just
> create two regmap_field defintions. One definition would be 'write-only' (and
> cached for RMW), the other 'volatile read-only'. All regmap_fields could still
> rely on a single cached register value, I think. I didn't try to implement this
> though, so maybe I'm missing some behaviour that would disqualify this solution.
> Would you think this could be an acceptable way to move forward here?

This feels like a painful and potentially high overhead approach to
things - at the minute fields are layered on top of registers and are
totally invisible at the register level, pulling the two together would
touch a lot of places and make things tense, especially if we ended up
with two different fields aliasing each other.  I'd need to see code but
it feels like a difficult approach to take.

--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDnCkkACgkQJNaLcl1U
h9BgWQf9EXRMoRdnrVCUNqRa20ezBb+4TyMBmX2rqTraVIEfms7khy2lloQFA0t9
ArWkAGDXYDTGJE5e4sHFNTKNHqSbdWkFSjl0chkoamwv5GgpBuyA3YIOXplpet2J
eYxbvsuYh/TBYo2NFgKCVa0UXYjuD0aemNElyfrIltjBZqfAMlFJah40HsoZdDQj
LwNmxou2+oaRmQw7u9qtzQvHbxv4a4dRMga7KdP6QK2gpqIGK04DnFMjAqaiv5uk
L6BgvcrHDvhWOSNpguXdt4Actyyae0qPjs6258E4t1S3weKO5ZXOB8C1eQtQDxP2
+Zqh5cDxsxPtObuk4e7Bj2tJvlGEQw==
=4IS2
-----END PGP SIGNATURE-----

--82I3+IH0IqGh5yIs--