linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sander Vanheule <sander@svanheule.net>
To: Mark Brown <broonie@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support
Date: Mon, 07 Jun 2021 14:06:26 +0200	[thread overview]
Message-ID: <4fd1501f247e77c579a209cbf6a554aa3c8b73d2.camel@svanheule.net> (raw)
In-Reply-To: <20210607115448.GB5705@sirena.org.uk>

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


  reply	other threads:[~2021-06-07 12:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 18:25 [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support Sander Vanheule
2021-06-03 18:25 ` [RFC PATCH 1/2] regmap: mdio: Clean up invalid clause-22 addresses Sander Vanheule
2021-06-03 18:25 ` [RFC PATCH 2/2] regmap: mdio: Add clause-45 support Sander Vanheule
2021-06-04 17:25 ` [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support Mark Brown
2021-06-04 18:16   ` Sander Vanheule
2021-06-07 11:54     ` Mark Brown
2021-06-07 12:06       ` Sander Vanheule [this message]
2021-06-07 12:14       ` Andy Shevchenko
2021-06-04 20:38   ` Andrew Lunn
2021-06-04 23:55 ` Andrew Lunn
2021-06-05  8:31 ` [PATCH] regmap: mdio: Reject invalid clause-22 addresses Sander Vanheule
2021-06-07 11:03   ` Mark Brown
2021-06-07 11:12     ` Sander Vanheule
2021-06-09 11:51     ` Sander Vanheule
2021-06-08 16:06 ` [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4fd1501f247e77c579a209cbf6a554aa3c8b73d2.camel@svanheule.net \
    --to=sander@svanheule.net \
    --cc=andrew@lunn.ch \
    --cc=andy.shevchenko@gmail.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).