public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Colin Foster <colin.foster@in-advantage.com>
To: Mark Brown <broonie@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>,
	linux-gpio@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	UNGLinuxDriver@microchip.com,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [RFC v5 net-next 01/13] mfd: ocelot: add support for external mfd control over SPI for the VSC7512
Date: Tue, 11 Jan 2022 08:53:30 -0800	[thread overview]
Message-ID: <20220111165330.GA28004@COLIN-DESKTOP1.localdomain> (raw)
In-Reply-To: <Yd2JvH/D2xmH8Ry7@sirena.org.uk>

Hi Mark and Lee,

On Tue, Jan 11, 2022 at 01:44:28PM +0000, Mark Brown wrote:
> On Tue, Jan 11, 2022 at 10:13:43AM +0000, Lee Jones wrote:
> 
> > Unless something has changed or my understanding is not correct,
> > regmap does not support over-lapping register ranges.
> 
> If there's no caches and we're always going direct to hardware it will
> work a lot of the time since the buses generally have concurrency
> protection at the lowest level, though if the drivers ever do any
> read/modify/write operations the underlying hardware bus isn't going to
> know about it so you could get data corruption if two drivers decide to
> try to operate on the same register.  If there's caches things will
> probably go badly since the cache will tend to amplify the
> read/modify/write issues.

Good point about caches. No, nothing in these drivers utilize caches
currently, but that doesn't mean it shouldn't... or won't. Any
concurrency in this specific case would be around the SPI bus.

I think the "overlapping regmaps" already exist in the current drivers... 
but actually I'm not so sure anymore.

Either way, this is helping nudge me in the right direction.

> 
> > However, even if that is required, I still think we can come up with
> > something cleaner than creating a whole API based around creating
> > and fetching different regmap configurations depending on how the
> > system was initialised.
> 
> Yeah, I'd expect the usual pattern is to have wrapper drivers that
> instantiate a regmap then have the bulk of the driver be a library that
> they call into should work.

Understood. And I think this can make sense and clean things up. The
"ocelot_core" mfd will register every regmap range, regardless of
whether any child actually uses them. Every child can then get regmaps
by name, via dev_get_regmap. That'll get rid of the back-and-forth
regmap hooks.

I think I know where to go from here. Thank you both! I'll send along
another RFC soon, once I can get this all cleaned up.



  reply	other threads:[~2022-01-11 16:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-18 21:49 [RFC v5 net-next 00/13] add support for VSC75XX control over SPI Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 01/13] mfd: ocelot: add support for external mfd control over SPI for the VSC7512 Colin Foster
2021-12-29 15:22   ` Lee Jones
2021-12-30  1:43     ` Colin Foster
2022-01-10 12:16       ` Lee Jones
2022-01-11  0:33         ` Colin Foster
2022-01-11 10:13           ` Lee Jones
2022-01-11 13:44             ` Mark Brown
2022-01-11 16:53               ` Colin Foster [this message]
2022-01-11 17:00                 ` Lee Jones
2022-01-11 18:28                   ` Colin Foster
2022-01-11 18:41                     ` Alexandre Belloni
2022-01-15  2:07                     ` Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 02/13] mfd: ocelot: offer an interface for MFD children to get regmaps Colin Foster
2021-12-29 15:23   ` Lee Jones
2021-12-29 19:34     ` Alexandre Belloni
2021-12-29 20:12       ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 03/13] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 04/13] net: dsa: felix: add configurable device quirks Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 05/13] net: mdio: mscc-miim: add ability to externally register phy reset control Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 06/13] net: dsa: ocelot: add external ocelot switch control Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 07/13] mfd: ocelot: enable the external switch interface Colin Foster
2021-12-29 15:24   ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 08/13] mfd: add interface to check whether a device is mfd Colin Foster
2021-12-29 15:25   ` Lee Jones
2021-12-30  2:04     ` Colin Foster
2021-12-30 13:43       ` Lee Jones
2021-12-30 20:12         ` Colin Foster
2022-01-10 12:23           ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 09/13] net: mdio: mscc-miim: add local dev variable to cleanup probe function Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 10/13] net: mdio: mscc-miim: add MFD functionality through ocelot-core Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 11/13] mfd: ocelot-core: add control for the external mdio interface Colin Foster
2021-12-29 15:26   ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 12/13] pinctrl: ocelot: add MFD functionality through ocelot-core Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 13/13] mfd: ocelot: add ocelot-pinctrl as a supported child interface Colin Foster
2021-12-29 15:26   ` Lee Jones

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=20220111165330.GA28004@COLIN-DESKTOP1.localdomain \
    --to=colin.foster@in-advantage.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    /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