All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	Lee Jones <lee.jones@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Lars Povlsen <lars.povlsen@microchip.com>,
	Steen Hegelund <Steen.Hegelund@microchip.com>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Wolfram Sang <wsa@kernel.org>,
	Terry Bowman <terry.bowman@amd.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Arnd Bergmann <arnd@kernel.org>
Subject: Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
Date: Tue, 28 Jun 2022 10:25:18 -0700	[thread overview]
Message-ID: <20220628172518.GA855398@euler> (raw)
In-Reply-To: <20220628160809.marto7t6k24lneau@skbuf>

Hi Vladimir,

On Tue, Jun 28, 2022 at 04:08:10PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 01:17:01AM -0700, Colin Foster wrote:
> > diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> > new file mode 100644
> > index 000000000000..5c95e4ee38a6
> > --- /dev/null
> > +++ b/include/linux/mfd/ocelot.h
> > @@ -0,0 +1,27 @@
> > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> > +/* Copyright 2022 Innovative Advantage Inc. */
> > +
> > +#include <linux/err.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/types.h>
> > +
> > +struct resource;
> > +
> > +static inline struct regmap *
> > +ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
> > +					  unsigned int index,
> > +					  const struct regmap_config *config)
> 
> I think this function name is too long (especially if you're going to
> also introduce ocelot_platform_init_regmap_from_resource_optional),
> and I have the impression that the "platform_init_" part of the name
> doesn't bring too much value. How about ocelot_regmap_from_resource()?

I thought the same thing after your first email. My thought was "how do
I indent that?" :-)

> 
> > +{
> > +	struct resource *res;
> > +	u32 __iomem *regs;
> > +
> > +	regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> > +
> > +	if (!res)
> > +		return ERR_PTR(-ENOENT);
> > +	else if (IS_ERR(regs))
> > +		return ERR_CAST(regs);
> > +	else
> > +		return devm_regmap_init_mmio(&pdev->dev, regs, config);
> > +}
> > -- 
> > 2.25.1
> >
> 
> To illustrate what I'm trying to say, these would be the shim
> definitions:
> 
> static inline struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> 			    unsigned int index,
> 			    const struct regmap_config *config)
> {
> 	struct resource *res;
> 	void __iomem *regs;
> 
> 	regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> 	if (IS_ERR(regs))
> 		return regs;
> 
> 	return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
> 
> static inline struct regmap *
> ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> 				     unsigned int index,
> 				     const struct regmap_config *config)
> {
> 	struct resource *res;
> 	void __iomem *regs;
> 
> 	res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> 	if (!res)
> 		return NULL;
> 
> 	regs = devm_ioremap_resource(&pdev->dev, r);
> 	if (IS_ERR(regs))
> 		return regs;
> 
> 	return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
> 
> and these would be the full versions:
> 
> static struct regmap *
> ocelot_regmap_from_mem_resource(struct device *dev, struct resource *res,
> 				const struct regmap_config *config)
> {
> 	void __iomem *regs;
> 
> 	regs = devm_ioremap_resource(dev, r);
> 	if (IS_ERR(regs))
> 		return regs;
> 
> 	return devm_regmap_init_mmio(dev, regs, config);
> }
> 
> static struct regmap *
> ocelot_regmap_from_reg_resource(struct device *dev, struct resource *res,
> 				const struct regmap_config *config)
> {
> 	/* Open question: how to differentiate SPI from I2C resources? */

My expectation is to set something up in drivers/mfd/ocelot-{spi,i2c}.c
and have an if/else / switch. PCIe might actually be our first hardware
spin.

> 	return ocelot_spi_init_regmap(dev->parent, dev, res);
> }
> 
> struct regmap *
> ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> 				     unsigned int index,
> 				     const struct regmap_config *config)
> {
> 	struct device *dev = &pdev->dev;
> 	struct resource *res;
> 
> 	res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> 	if (res)
> 		return ocelot_regmap_from_mem_resource(dev, res, config);
> 
> 	/*
> 	 * Fall back to using IORESOURCE_REG, which is possible in an
> 	 * MFD configuration
> 	 */
> 	res = platform_get_resource(pdev, IORESOURCE_REG, index);
> 	if (res)
> 		return ocelot_regmap_from_reg_resource(dev, res, config);
> 
> 	return NULL;
> }
> 
> struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> 			    unsigned int index,
> 			    const struct regmap_config *config)
> {
> 	struct regmap *map;
> 
> 	map = ocelot_regmap_from_resource_optional(pdev, index, config);
> 	return map ? : ERR_PTR(-ENOENT);
> }
> 
> I hope I didn't get something wrong, this is all code written within the
> email client, so it is obviously not compiled/tested....

Yep - I definitely get the point. And thanks for the review.

The other (bigger?) issue is around how this MFD can be loaded as a
module. Right now it is pretty straightforward to say
#if IS_ENABLED(CONFIG_MFD_OCELOT). Theres a level of nuance if
CONFIG_MFD_OCELOT=m while the child devices are compiled in
(CONFIG_PINCTRL_MICROCHIP_SGPIO=y for example). It still feels like this
code belongs somewhere in platform / resource / device / mfd...?

It might be perfectly valid to have multiple SGPIO controllers - one
local and one remote / SPI. But without the CONFIG_MFD_OCELOT module
loaded, I don't think the SGPIO module would work.

This patch set deals with the issue by setting MFD_OCELOT to a boolean -
but in the long run I think a module makes sense. I admittedly haven't
spent enough time researching (bashing my head against the wall) this,
but this seems like a good opportunity to at least express that I'm
expecting to have to deal with this issue soon. I met with Alexandre at
ELC this past week, and he said Arnd (both added to CC) might be a good
resource - but again I'd like to do a little more searching before
throwing it over the wall.

WARNING: multiple messages have this Message-ID (diff)
From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	Lee Jones <lee.jones@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Lars Povlsen <lars.povlsen@microchip.com>,
	Steen Hegelund <Steen.Hegelund@microchip.com>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Wolfram Sang <wsa@kernel.org>,
	Terry Bowman <terry.bowman@amd.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Arnd Bergmann <arnd@kernel.org>
Subject: Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
Date: Tue, 28 Jun 2022 10:25:18 -0700	[thread overview]
Message-ID: <20220628172518.GA855398@euler> (raw)
In-Reply-To: <20220628160809.marto7t6k24lneau@skbuf>

Hi Vladimir,

On Tue, Jun 28, 2022 at 04:08:10PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 01:17:01AM -0700, Colin Foster wrote:
> > diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> > new file mode 100644
> > index 000000000000..5c95e4ee38a6
> > --- /dev/null
> > +++ b/include/linux/mfd/ocelot.h
> > @@ -0,0 +1,27 @@
> > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> > +/* Copyright 2022 Innovative Advantage Inc. */
> > +
> > +#include <linux/err.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/types.h>
> > +
> > +struct resource;
> > +
> > +static inline struct regmap *
> > +ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
> > +					  unsigned int index,
> > +					  const struct regmap_config *config)
> 
> I think this function name is too long (especially if you're going to
> also introduce ocelot_platform_init_regmap_from_resource_optional),
> and I have the impression that the "platform_init_" part of the name
> doesn't bring too much value. How about ocelot_regmap_from_resource()?

I thought the same thing after your first email. My thought was "how do
I indent that?" :-)

> 
> > +{
> > +	struct resource *res;
> > +	u32 __iomem *regs;
> > +
> > +	regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> > +
> > +	if (!res)
> > +		return ERR_PTR(-ENOENT);
> > +	else if (IS_ERR(regs))
> > +		return ERR_CAST(regs);
> > +	else
> > +		return devm_regmap_init_mmio(&pdev->dev, regs, config);
> > +}
> > -- 
> > 2.25.1
> >
> 
> To illustrate what I'm trying to say, these would be the shim
> definitions:
> 
> static inline struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> 			    unsigned int index,
> 			    const struct regmap_config *config)
> {
> 	struct resource *res;
> 	void __iomem *regs;
> 
> 	regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> 	if (IS_ERR(regs))
> 		return regs;
> 
> 	return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
> 
> static inline struct regmap *
> ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> 				     unsigned int index,
> 				     const struct regmap_config *config)
> {
> 	struct resource *res;
> 	void __iomem *regs;
> 
> 	res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> 	if (!res)
> 		return NULL;
> 
> 	regs = devm_ioremap_resource(&pdev->dev, r);
> 	if (IS_ERR(regs))
> 		return regs;
> 
> 	return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
> 
> and these would be the full versions:
> 
> static struct regmap *
> ocelot_regmap_from_mem_resource(struct device *dev, struct resource *res,
> 				const struct regmap_config *config)
> {
> 	void __iomem *regs;
> 
> 	regs = devm_ioremap_resource(dev, r);
> 	if (IS_ERR(regs))
> 		return regs;
> 
> 	return devm_regmap_init_mmio(dev, regs, config);
> }
> 
> static struct regmap *
> ocelot_regmap_from_reg_resource(struct device *dev, struct resource *res,
> 				const struct regmap_config *config)
> {
> 	/* Open question: how to differentiate SPI from I2C resources? */

My expectation is to set something up in drivers/mfd/ocelot-{spi,i2c}.c
and have an if/else / switch. PCIe might actually be our first hardware
spin.

> 	return ocelot_spi_init_regmap(dev->parent, dev, res);
> }
> 
> struct regmap *
> ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> 				     unsigned int index,
> 				     const struct regmap_config *config)
> {
> 	struct device *dev = &pdev->dev;
> 	struct resource *res;
> 
> 	res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> 	if (res)
> 		return ocelot_regmap_from_mem_resource(dev, res, config);
> 
> 	/*
> 	 * Fall back to using IORESOURCE_REG, which is possible in an
> 	 * MFD configuration
> 	 */
> 	res = platform_get_resource(pdev, IORESOURCE_REG, index);
> 	if (res)
> 		return ocelot_regmap_from_reg_resource(dev, res, config);
> 
> 	return NULL;
> }
> 
> struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> 			    unsigned int index,
> 			    const struct regmap_config *config)
> {
> 	struct regmap *map;
> 
> 	map = ocelot_regmap_from_resource_optional(pdev, index, config);
> 	return map ? : ERR_PTR(-ENOENT);
> }
> 
> I hope I didn't get something wrong, this is all code written within the
> email client, so it is obviously not compiled/tested....

Yep - I definitely get the point. And thanks for the review.

The other (bigger?) issue is around how this MFD can be loaded as a
module. Right now it is pretty straightforward to say
#if IS_ENABLED(CONFIG_MFD_OCELOT). Theres a level of nuance if
CONFIG_MFD_OCELOT=m while the child devices are compiled in
(CONFIG_PINCTRL_MICROCHIP_SGPIO=y for example). It still feels like this
code belongs somewhere in platform / resource / device / mfd...?

It might be perfectly valid to have multiple SGPIO controllers - one
local and one remote / SPI. But without the CONFIG_MFD_OCELOT module
loaded, I don't think the SGPIO module would work.

This patch set deals with the issue by setting MFD_OCELOT to a boolean -
but in the long run I think a module makes sense. I admittedly haven't
spent enough time researching (bashing my head against the wall) this,
but this seems like a good opportunity to at least express that I'm
expecting to have to deal with this issue soon. I met with Alexandre at
ELC this past week, and he said Arnd (both added to CC) might be a good
resource - but again I'd like to do a little more searching before
throwing it over the wall.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-06-28 17:25 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28  8:17 [PATCH v11 net-next 0/9] add support for VSC7512 control over SPI Colin Foster
2022-06-28  8:17 ` Colin Foster
2022-06-28  8:17 ` [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28 12:50   ` Andy Shevchenko
2022-06-28 12:50     ` Andy Shevchenko
2022-06-28 15:33     ` Vladimir Oltean
2022-06-28 15:33       ` Vladimir Oltean
2022-06-28 16:08   ` Vladimir Oltean
2022-06-28 16:08     ` Vladimir Oltean
2022-06-28 17:25     ` Colin Foster [this message]
2022-06-28 17:25       ` Colin Foster
2022-06-28 18:47       ` Vladimir Oltean
2022-06-28 18:47         ` Vladimir Oltean
2022-06-28 18:56         ` Vladimir Oltean
2022-06-28 18:56           ` Vladimir Oltean
2022-06-28 19:04           ` Andy Shevchenko
2022-06-28 19:04             ` Andy Shevchenko
2022-06-28 19:56             ` Colin Foster
2022-06-28 19:56               ` Colin Foster
2022-06-29 17:53               ` Vladimir Oltean
2022-06-29 17:53                 ` Vladimir Oltean
2022-06-29 20:39                 ` Colin Foster
2022-06-29 20:39                   ` Colin Foster
2022-06-29 23:08                   ` Vladimir Oltean
2022-06-29 23:08                     ` Vladimir Oltean
2022-06-29 23:54                     ` Colin Foster
2022-06-29 23:54                       ` Colin Foster
2022-06-30  7:54                       ` Lee Jones
2022-06-30  7:54                         ` Lee Jones
2022-06-30 13:11                       ` Vladimir Oltean
2022-06-30 13:11                         ` Vladimir Oltean
2022-06-30 20:09                         ` Colin Foster
2022-06-30 20:09                           ` Colin Foster
2022-07-01 16:21                           ` Vladimir Oltean
2022-07-01 16:21                             ` Vladimir Oltean
2022-07-01 17:18                             ` Colin Foster
2022-07-01 17:18                               ` Colin Foster
2022-07-02 12:42                               ` Vladimir Oltean
2022-07-02 12:42                                 ` Vladimir Oltean
2022-07-02 16:17                                 ` Colin Foster
2022-07-02 16:17                                   ` Colin Foster
2022-06-28  8:17 ` [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28 16:26   ` Vladimir Oltean
2022-06-28 16:26     ` Vladimir Oltean
2022-06-28 18:31     ` Colin Foster
2022-06-28 18:31       ` Colin Foster
2022-06-28  8:17 ` [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28 12:53   ` Andy Shevchenko
2022-06-28 12:53     ` Andy Shevchenko
2022-06-28 18:25     ` Colin Foster
2022-06-28 18:25       ` Colin Foster
2022-06-28 19:00       ` Andy Shevchenko
2022-06-28 19:00         ` Andy Shevchenko
2022-06-30 11:56         ` Linus Walleij
2022-06-30 11:56           ` Linus Walleij
2022-06-28  8:17 ` [PATCH v11 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28  8:17 ` [PATCH v11 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28 12:55   ` Andy Shevchenko
2022-06-28 12:55     ` Andy Shevchenko
2022-06-28  8:17 ` [PATCH v11 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28  8:17 ` [PATCH v11 net-next 7/9] resource: add define macro for register address resources Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28  8:17 ` [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512 Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28 13:15   ` Rob Herring
2022-06-28 13:15     ` Rob Herring
2022-06-28 18:19     ` Colin Foster
2022-06-28 18:19       ` Colin Foster
2022-06-30 13:17   ` Vladimir Oltean
2022-06-30 13:17     ` Vladimir Oltean
2022-06-28  8:17 ` [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster
2022-06-28  8:17   ` Colin Foster
2022-06-28 20:07   ` Randy Dunlap
2022-06-28 20:07     ` Randy Dunlap
2022-06-28 20:24     ` Colin Foster
2022-06-28 20:24       ` Colin Foster

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=20220628172518.GA855398@euler \
    --to=colin.foster@in-advantage.com \
    --cc=Steen.Hegelund@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lars.povlsen@microchip.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=terry.bowman@amd.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.