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
WARNING: multiple messages have this Message-ID (diff)
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-12 9:49 UTC|newest]
Thread overview: 114+ 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 ` 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-08 18:52 ` Colin Foster
2022-05-09 10:05 ` Vladimir Oltean
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-08 18:52 ` Colin Foster
2022-05-09 10:05 ` Vladimir Oltean
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 ` 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 18:53 ` Colin Foster
2022-05-08 21:14 ` Andy Shevchenko
2022-05-08 21:14 ` Andy Shevchenko
2022-05-08 18:53 ` [RFC v8 net-next 05/16] pinctrl: ocelot: " Colin Foster
2022-05-08 18:53 ` Colin Foster
2022-05-09 8:37 ` Andy Shevchenko
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-08 18:53 ` Colin Foster
2022-05-09 8:44 ` Andy Shevchenko
2022-05-09 8:44 ` Andy Shevchenko
2022-05-09 22:19 ` Colin Foster
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 ` 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-08 18:53 ` Colin Foster
2022-05-09 9:02 ` Andy Shevchenko
2022-05-09 9:02 ` Andy Shevchenko
2022-05-09 23:15 ` Colin Foster
2022-05-09 23:15 ` Colin Foster
2022-08-19 16:50 ` Vladimir Oltean
2022-08-19 16:50 ` Vladimir Oltean
2022-05-09 10:52 ` Vladimir Oltean
2022-05-09 10:52 ` Vladimir Oltean
2022-05-09 23:49 ` Colin Foster
2022-05-09 23:49 ` Colin Foster
2022-05-09 17:20 ` Vladimir Oltean
2022-05-09 17:20 ` Vladimir Oltean
2022-05-10 0:30 ` Colin Foster
2022-05-10 0:30 ` Colin Foster
2022-05-10 15:32 ` Lee Jones
2022-05-10 15:32 ` Lee Jones
2022-05-10 16:13 ` Colin Foster
2022-05-10 16:13 ` Colin Foster
2022-05-12 9:49 ` Lee Jones [this message]
2022-05-12 9:49 ` Lee Jones
2022-05-12 15:03 ` Colin Foster
2022-05-12 15:03 ` Colin Foster
2022-05-10 15:58 ` Vladimir Oltean
2022-05-10 15:58 ` Vladimir Oltean
2022-05-10 16:02 ` Colin Foster
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 ` 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 ` 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-08 18:53 ` Colin Foster
2022-05-09 10:56 ` Vladimir Oltean
2022-05-09 10:56 ` Vladimir Oltean
2022-05-10 0:05 ` Colin Foster
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 ` 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 ` 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-08 18:53 ` Colin Foster
2022-05-09 16:27 ` Vladimir Oltean
2022-05-09 16:27 ` Vladimir Oltean
2022-05-10 0:02 ` Colin Foster
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-08 18:53 ` Colin Foster
2022-05-09 10:34 ` Vladimir Oltean
2022-05-09 10:34 ` Vladimir Oltean
2022-05-10 0:23 ` Colin Foster
2022-05-10 0:23 ` Colin Foster
2022-05-09 17:30 ` Vladimir Oltean
2022-05-09 17:30 ` Vladimir Oltean
2022-05-10 0:55 ` Colin Foster
2022-05-10 0:55 ` Colin Foster
2022-05-09 17:58 ` Vladimir Oltean
2022-05-09 17:58 ` Vladimir Oltean
2022-09-09 18:33 ` Colin Foster
2022-09-09 18:33 ` Colin Foster
2022-09-09 19:20 ` Russell King (Oracle)
2022-09-09 19:20 ` Russell King (Oracle)
2022-09-09 19:30 ` Colin Foster
2022-09-09 19:30 ` Colin Foster
2022-09-11 0:44 ` Vladimir Oltean
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-08 18:53 ` Colin Foster
2022-05-09 17:13 ` [RFC v8 net-next 00/16] add support for VSC7512 control over SPI Vladimir Oltean
2022-05-09 17:13 ` Vladimir Oltean
2022-05-10 1:43 ` Colin Foster
2022-05-10 1:43 ` Colin Foster
2022-05-10 2:57 ` Colin Foster
2022-05-10 2:57 ` Colin Foster
2022-05-10 16:18 ` Vladimir Oltean
2022-05-10 16:18 ` Vladimir Oltean
2022-05-14 22:00 ` Colin Foster
2022-05-14 22:00 ` Colin Foster
2022-05-19 14:44 ` Vladimir Oltean
2022-05-19 14:44 ` Vladimir Oltean
2022-05-19 16:15 ` Colin Foster
2022-05-19 16:15 ` Colin Foster
2022-05-19 17:09 ` Vladimir Oltean
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 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.