From: Lee Jones <lee.jones@linaro.org>
To: Colin Foster <colin.foster@in-advantage.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Terry Bowman <terry.bowman@amd.com>,
Wolfram Sang <wsa@kernel.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Steen Hegelund <Steen.Hegelund@microchip.com>,
Lars Povlsen <lars.povlsen@microchip.com>,
Linus Walleij <linus.walleij@linaro.org>,
Russell King <linux@armlinux.org.uk>,
Heiner Kallweit <hkallweit1@gmail.com>,
Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"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" <UNGLinuxDriver@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>
Subject: Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
Date: Thu, 12 May 2022 10:49:39 +0100 [thread overview]
Message-ID: <YnzYM1kOJ9hcaaQ6@google.com> (raw)
In-Reply-To: <20220510161319.GA872@COLIN-DESKTOP1.localdomain>
On Tue, 10 May 2022, Colin Foster wrote:
> On Tue, May 10, 2022 at 04:32:26PM +0100, Lee Jones wrote:
> > On Mon, 09 May 2022, Vladimir Oltean wrote:
> >
> > > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > > > + const struct resource *res)
> > > > > > +{
> > > > > > + struct device *dev = child->parent;
> > > > > > +
> > > > > > + return ocelot_spi_devm_init_regmap(dev, child, res);
> > > > >
> > > > > So much for being bus-agnostic :-/
> > > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > > >
> > > > That was my initial design. "core" was calling into "spi" exclusively
> > > > via function pointers.
> > > >
> > > > The request was "Please find a clearer way to do this without function
> > > > pointers"
> > > >
> > > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> > >
> > > Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> > > with the comment that you aren't configuring a bus. In this context it
> > > seems more appropriate to call this function pointer "init_regmap", with
> > > different implementations per transport.
> >
> > FWIW, I'm still against using function pointers for this.
> >
> > What about making ocelot_init_regmap_from_resource() an inline
> > function and pushing it into one of the header files?
> >
> > [As an aside, you don't need to pass both dev (parent) and child]
>
> I see your point. This wasn't always the case, since ocelot-core prior
> to v8 would call ocelot_spi_devm_init_regmap. Since this was changed,
> the "dev, dev" part can all be handled internally. That's nice.
>
> >
> > In there you could simply do:
> >
> > inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
> > const struct resource *res)
> > {
> > if (dev_get_drvdata(dev->parent)->spi)
> > return ocelot_spi_devm_init_regmap(dev, res);
> >
> > return NULL;
> > }
>
> If I do this, won't I have to declare ocelot_spi_devm_init_regmap in a
> larger scope (include/soc/mscc/ocelot.h)? I like the idea of keeping it
> more hidden inside drivers/mfd/ocelot.h, assuming I can't keep it
> enclosed in drivers/mfd/ocelot-spi.c entirely.
Yes, it will have the same scope as ocelot_init_regmap_from_resource().
Have you considered include/linux/mfd?
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2022-05-12 9:49 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-08 18:52 [RFC v8 net-next 00/16] add support for VSC7512 control over SPI Colin Foster
2022-05-08 18:52 ` [RFC v8 net-next 01/16] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster
2022-05-09 10:05 ` Vladimir Oltean
2022-05-08 18:52 ` [RFC v8 net-next 02/16] pinctrl: microchip-sgpio: allow sgpio driver to be used " Colin Foster
2022-05-09 10:05 ` Vladimir Oltean
2022-05-08 18:53 ` [RFC v8 net-next 03/16] net: ocelot: add interface to get regmaps when exernally controlled Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 04/16] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster
2022-05-08 21:14 ` Andy Shevchenko
2022-05-08 18:53 ` [RFC v8 net-next 05/16] pinctrl: ocelot: " Colin Foster
2022-05-09 8:37 ` Andy Shevchenko
2022-05-08 18:53 ` [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: " Colin Foster
2022-05-09 8:44 ` Andy Shevchenko
2022-05-09 22:19 ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 07/16] resource: add define macro for register address resources Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster
2022-05-09 9:02 ` Andy Shevchenko
2022-05-09 23:15 ` Colin Foster
2022-08-19 16:50 ` Vladimir Oltean
2022-05-09 10:52 ` Vladimir Oltean
2022-05-09 23:49 ` Colin Foster
2022-05-09 17:20 ` Vladimir Oltean
2022-05-10 0:30 ` Colin Foster
2022-05-10 15:32 ` Lee Jones
2022-05-10 16:13 ` Colin Foster
2022-05-12 9:49 ` Lee Jones [this message]
2022-05-12 15:03 ` Colin Foster
2022-05-10 15:58 ` Vladimir Oltean
2022-05-10 16:02 ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 09/16] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 10/16] net: dsa: felix: add configurable device quirks Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers Colin Foster
2022-05-09 10:56 ` Vladimir Oltean
2022-05-10 0:05 ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 12/16] net: mscc: ocelot: expose stats layout " Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 13/16] net: mscc: ocelot: expose vcap_props structure Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control Colin Foster
2022-05-09 16:27 ` Vladimir Oltean
2022-05-10 0:02 ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability Colin Foster
2022-05-09 10:34 ` Vladimir Oltean
2022-05-10 0:23 ` Colin Foster
2022-05-09 17:30 ` Vladimir Oltean
2022-05-10 0:55 ` Colin Foster
2022-05-09 17:58 ` Vladimir Oltean
2022-09-09 18:33 ` Colin Foster
2022-09-09 19:20 ` Russell King (Oracle)
2022-09-09 19:30 ` Colin Foster
2022-09-11 0:44 ` Vladimir Oltean
2022-05-08 18:53 ` [RFC v8 net-next 16/16] net: dsa: ocelot: utilize phylink_generic_validate Colin Foster
2022-05-09 17:13 ` [RFC v8 net-next 00/16] add support for VSC7512 control over SPI Vladimir Oltean
2022-05-10 1:43 ` Colin Foster
2022-05-10 2:57 ` Colin Foster
2022-05-10 16:18 ` Vladimir Oltean
2022-05-14 22:00 ` Colin Foster
2022-05-19 14:44 ` Vladimir Oltean
2022-05-19 16:15 ` Colin Foster
2022-05-19 17:09 ` Vladimir Oltean
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=YnzYM1kOJ9hcaaQ6@google.com \
--to=lee.jones@linaro.org \
--cc=Steen.Hegelund@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@lunn.ch \
--cc=andy.shevchenko@gmail.com \
--cc=claudiu.manoil@nxp.com \
--cc=colin.foster@in-advantage.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=lars.povlsen@microchip.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=terry.bowman@amd.com \
--cc=vivien.didelot@gmail.com \
--cc=vladimir.oltean@nxp.com \
--cc=wsa@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).