All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.