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;
MIME-Version: 1.0
References: <cover.1622743333.git.sander@svanheule.net> <20210604172515.GG4045@sirena.org.uk>
 <8899fbf306051fa3cdd8bde92634de8134bce0fb.camel@svanheule.net> <20210607115448.GB5705@sirena.org.uk>
In-Reply-To: <20210607115448.GB5705@sirena.org.uk>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon, 7 Jun 2021 15:14:39 +0300
Message-ID: <CAHp75VcsZqitqjdPkQMrssTS43Kh=rMnXDxa4yGnF_UAC+3NbQ@mail.gmail.com>
Subject: Re: [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support
To:     Mark Brown <broonie@kernel.org>
Cc:     Sander Vanheule <sander@svanheule.net>,
        Andrew Lunn <andrew@lunn.ch>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jun 7, 2021 at 2:55 PM Mark Brown <broonie@kernel.org> 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.

Isn't it a disadvantage of regmap APIs? The hardware that uses the
same offset for R and W with different semantics is quite normal. I
think it is a good exercise to implement regmap-8250 as an example of
how to deal with such hardware.


-- 
With Best Regards,
Andy Shevchenko