From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Colin Foster <colin.foster@in-advantage.com>,
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,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
clement.leger@bootlin.com
Subject: Re: [RFC v5 net-next 02/13] mfd: ocelot: offer an interface for MFD children to get regmaps
Date: Wed, 29 Dec 2021 20:34:44 +0100 [thread overview]
Message-ID: <Ycy4VPy+XVgYmfeg@piout.net> (raw)
In-Reply-To: <Ycx9j3bflcTGsb7b@google.com>
Hello Lee,
On 29/12/2021 15:23:59+0000, Lee Jones wrote:
> On Sat, 18 Dec 2021, Colin Foster wrote:
>
> > Child devices need to get a regmap from a resource struct, specifically
> > from the MFD parent. The MFD parent has the interface to the hardware
> > layer, which could be I2C, SPI, PCIe, etc.
> >
> > This is somewhat a hack... ideally child devices would interface with the
> > struct device* directly, by way of a function like
> > devm_get_regmap_from_resource which would be akin to
> > devm_get_and_ioremap_resource. A less ideal option would be to interface
> > directly with MFD to get a regmap from the parent.
> >
> > This solution is even less ideal than both of the two suggestions, so is
> > intentionally left in a separate commit after the initial MFD addition.
> >
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> > drivers/mfd/ocelot-core.c | 9 +++++++++
> > include/soc/mscc/ocelot.h | 12 ++++++++++++
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
> > index a65619a8190b..09132ea52760 100644
> > --- a/drivers/mfd/ocelot-core.c
> > +++ b/drivers/mfd/ocelot-core.c
> > @@ -94,6 +94,15 @@ static struct regmap *ocelot_mfd_regmap_init(struct ocelot_mfd_core *core,
> > return regmap;
> > }
> >
> > +struct regmap *ocelot_mfd_get_regmap_from_resource(struct device *dev,
> > + const struct resource *res)
> > +{
> > + struct ocelot_mfd_core *core = dev_get_drvdata(dev);
> > +
> > + return ocelot_mfd_regmap_init(core, res);
> > +}
> > +EXPORT_SYMBOL(ocelot_mfd_get_regmap_from_resource);
>
> This is almost certainly not the right way to do whatever it is you're
> trying to do!
>
> Please don't try to upstream "somewhat a hack"s into the Mainline
> kernel.
>
Please elaborate on the correct way to do that. What we have here is a
SoC (vsc7514) that has MMIO devices. This SoC has a MIPS CPU and
everything is fine when using it. However, the CPU can be disabled and
the SoC connected to another CPU using SPI or PCIe. What Colin is doing
here is using this SoC over SPI. Don't tell me this is not an MFD
because this is exactly what this is, a single chip with a collection of
devices that are also available separately.
The various drivers for the VSC7514 have been written using regmap
exactly for this use case. The missing piece is probing the devices over
SPI instead of MMIO.
Notice that all of that gets worse when using PCIe on architectures that
don't have device tree support and Clément will submit multiple series
trying to fix that.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2021-12-29 19:34 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
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 [this message]
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=Ycy4VPy+XVgYmfeg@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=clement.leger@bootlin.com \
--cc=colin.foster@in-advantage.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
all inboxes | Powered by JetHome®