linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Sander Vanheule <sander@svanheule.net>
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: Fri, 4 Jun 2021 18:25:15 +0100	[thread overview]
Message-ID: <20210604172515.GG4045@sirena.org.uk> (raw)
In-Reply-To: <cover.1622743333.git.sander@svanheule.net>

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Thu, Jun 03, 2021 at 08:25:08PM +0200, Sander Vanheule wrote:

> 1. I've opted to just ignore any bits that lie beyond the allowed address
>    width. Would it be cleaner to raise an error instead?

It doesn't *really* matter, enforcement is probably a bit better as it
might catch bugs.

> 2. Packing of the clause-45 register addresses (16 bit) and adressed device
>    type (5 bit) is the same as in the mdio subsystem, resulting in a 21 bit
>    address. Is this an appropriate way to pack this information into one
>    address for the regmap interface?

Either that or pass the type in when instantiating the regmap (it sounds
like it should be the same for all registers on the device?).

> The reasoning behind (1) is to allow the regmap user to use extra bits
> as a way to virtually extend the address space. Note that this actually
> results in aliasing. This can be useful if the data read from to a
> register doesn't have the same meaning as the data written to it
> (e.g. GPIO pin input and output data). An alternative solution to this
> would be some concept of "aliased registers" in regmap -- like volatile or
> precious registers.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2021-06-04 17:25 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 ` Mark Brown [this message]
2021-06-04 18:16   ` [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support Sander Vanheule
2021-06-07 11:54     ` Mark Brown
2021-06-07 12:06       ` Sander Vanheule
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=20210604172515.GG4045@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=andy.shevchenko@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sander@svanheule.net \
    /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).