diff mbox series

[RESEND,v16,mfd,1/8] mfd: ocelot: add helper to get regmap from a resource

Message ID 20220905162132.2943088-2-colin.foster@in-advantage.com (mailing list archive)
State Not Applicable
Delegated to: Netdev Maintainers
Headers show
Series add support for VSC7512 control over SPI | expand

Checks

Context Check Description
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix success Link
netdev/cover_letter success Series has a cover letter
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers success CCed 2 of 2 maintainers
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 73 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Colin Foster Sept. 5, 2022, 4:21 p.m. UTC 
Several ocelot-related modules are designed for MMIO / regmaps. As such,
they often use a combination of devm_platform_get_and_ioremap_resource()
and devm_regmap_init_mmio().

Operating in an MFD might be different, in that it could be memory mapped,
or it could be SPI, I2C... In these cases a fallback to use IORESOURCE_REG
instead of IORESOURCE_MEM becomes necessary.

When this happens, there's redundant logic that needs to be implemented in
every driver. In order to avoid this redundancy, utilize a single function
that, if the MFD scenario is enabled, will perform this fallback logic.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
v16
    * Add Andy Reviewed-by tag

v15
    * Add missed errno.h and ioport.h includes
    * Add () to function references in both the commit log and comments

v14
    * Add header guard
    * Change regs type from u32* to void*
    * Add Reviewed-by tag

---
 MAINTAINERS                |  5 +++
 include/linux/mfd/ocelot.h | 62 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)
 create mode 100644 include/linux/mfd/ocelot.h

Comments

Lee Jones Sept. 8, 2022, 9:40 a.m. UTC | #1 
On Mon, 05 Sep 2022, Colin Foster wrote:

> Several ocelot-related modules are designed for MMIO / regmaps. As such,
> they often use a combination of devm_platform_get_and_ioremap_resource()
> and devm_regmap_init_mmio().
> 
> Operating in an MFD might be different, in that it could be memory mapped,
> or it could be SPI, I2C... In these cases a fallback to use IORESOURCE_REG
> instead of IORESOURCE_MEM becomes necessary.
> 
> When this happens, there's redundant logic that needs to be implemented in
> every driver. In order to avoid this redundancy, utilize a single function
> that, if the MFD scenario is enabled, will perform this fallback logic.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> ---
> v16
>     * Add Andy Reviewed-by tag
> 
> v15
>     * Add missed errno.h and ioport.h includes
>     * Add () to function references in both the commit log and comments
> 
> v14
>     * Add header guard
>     * Change regs type from u32* to void*
>     * Add Reviewed-by tag
> 
> ---
>  MAINTAINERS                |  5 +++
>  include/linux/mfd/ocelot.h | 62 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 67 insertions(+)
>  create mode 100644 include/linux/mfd/ocelot.h

Applied, thanks.
Vladimir Oltean Sept. 8, 2022, 2:22 p.m. UTC | #2 
On Thu, Sep 08, 2022 at 10:40:48AM +0100, Lee Jones wrote:
> Applied, thanks.

Hurray!

Colin, what plans do you have for the rest of VSC7512 upstreaming?
Do you need Lee to provide a stable branch for networking to pull, so
you can continue development in this kernel release cycle, or do you
expect that there won't be dependencies and you can therefore just test
on linux-next?
Colin Foster Sept. 8, 2022, 3:04 p.m. UTC | #3 
On Thu, Sep 08, 2022 at 02:22:56PM +0000, Vladimir Oltean wrote:
> On Thu, Sep 08, 2022 at 10:40:48AM +0100, Lee Jones wrote:
> > Applied, thanks.
> 
> Hurray!
> 
> Colin, what plans do you have for the rest of VSC7512 upstreaming?
> Do you need Lee to provide a stable branch for networking to pull, so
> you can continue development in this kernel release cycle, or do you
> expect that there won't be dependencies and you can therefore just test
> on linux-next?

Yay!

My plan was to start sending RFCs on the internal copper phys and get
some feedback there. I assume there'll be a couple rounds and I don't
expect to hit this next release (if I'm being honest).

So I'll turn this question around to the net people: would a round or
two of RFCs that don't cleanly apply to net-next be acceptable? Then I
could submit a patch right after the next merge window? I've been
dragging these patches around for quite some time, I can do it for
another month :-)
Colin Foster Sept. 8, 2022, 3:08 p.m. UTC | #4 
On Thu, Sep 08, 2022 at 10:40:48AM +0100, Lee Jones wrote:
> On Mon, 05 Sep 2022, Colin Foster wrote:
> Applied, thanks.
> 
> -- 
> Lee Jones [李琼斯]

Thanks Lee! I'm looking forward to adding the rest of the functionality
soon!
Lee Jones Sept. 9, 2022, 7:21 a.m. UTC | #5 
On Thu, 08 Sep 2022, Colin Foster wrote:

> On Thu, Sep 08, 2022 at 02:22:56PM +0000, Vladimir Oltean wrote:
> > On Thu, Sep 08, 2022 at 10:40:48AM +0100, Lee Jones wrote:
> > > Applied, thanks.
> > 
> > Hurray!
> > 
> > Colin, what plans do you have for the rest of VSC7512 upstreaming?
> > Do you need Lee to provide a stable branch for networking to pull, so
> > you can continue development in this kernel release cycle, or do you
> > expect that there won't be dependencies and you can therefore just test
> > on linux-next?
> 
> Yay!
> 
> My plan was to start sending RFCs on the internal copper phys and get
> some feedback there. I assume there'll be a couple rounds and I don't
> expect to hit this next release (if I'm being honest).
> 
> So I'll turn this question around to the net people: would a round or
> two of RFCs that don't cleanly apply to net-next be acceptable? Then I
> could submit a patch right after the next merge window? I've been
> dragging these patches around for quite some time, I can do it for
> another month :-)

Immutable branch now tested and pushed.

See reply to cover-letter.
Jakub Kicinski Sept. 19, 2022, 5:14 p.m. UTC | #6 
On Thu, 8 Sep 2022 08:04:13 -0700 Colin Foster wrote:
> My plan was to start sending RFCs on the internal copper phys and get
> some feedback there. I assume there'll be a couple rounds and I don't
> expect to hit this next release (if I'm being honest).
> 
> So I'll turn this question around to the net people: would a round or
> two of RFCs that don't cleanly apply to net-next be acceptable? Then I
> could submit a patch right after the next merge window? I've been
> dragging these patches around for quite some time, I can do it for
> another month :-)

FWIW RFC patches which don't apply cleanly seem perfectly fine to me.
Perhaps note the base in the cover letter for those who may want to 
test them.

We can pull Lee's branch (thanks!) if it turns out the code is ready
long before the MW.
Colin Foster Sept. 19, 2022, 7:05 p.m. UTC | #7 
Hi Jakub,

On Mon, Sep 19, 2022 at 10:14:53AM -0700, Jakub Kicinski wrote:
> On Thu, 8 Sep 2022 08:04:13 -0700 Colin Foster wrote:
> > My plan was to start sending RFCs on the internal copper phys and get
> > some feedback there. I assume there'll be a couple rounds and I don't
> > expect to hit this next release (if I'm being honest).
> > 
> > So I'll turn this question around to the net people: would a round or
> > two of RFCs that don't cleanly apply to net-next be acceptable? Then I
> > could submit a patch right after the next merge window? I've been
> > dragging these patches around for quite some time, I can do it for
> > another month :-)
> 
> FWIW RFC patches which don't apply cleanly seem perfectly fine to me.
> Perhaps note the base in the cover letter for those who may want to 
> test them.
> 
> We can pull Lee's branch (thanks!) if it turns out the code is ready
> long before the MW.

I'll quote Vladimir Oltean: "It mostly looks ok to me"

https://lore.kernel.org/netdev/20220912155234.ds73xpn5ijjq3iif@skbuf/

If you pull in Lee's branch I would certainly make use of it in the next
2-3 weeks. I would probably send out the patch set for review in a day
or two.
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a5012ba6ff9..e0732e9f9090 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14741,6 +14741,11 @@  F:	net/dsa/tag_ocelot.c
 F:	net/dsa/tag_ocelot_8021q.c
 F:	tools/testing/selftests/drivers/net/ocelot/*
 
+OCELOT EXTERNAL SWITCH CONTROL
+M:	Colin Foster <colin.foster@in-advantage.com>
+S:	Supported
+F:	include/linux/mfd/ocelot.h
+
 OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
 M:	Frederic Barrat <fbarrat@linux.ibm.com>
 M:	Andrew Donnellan <ajd@linux.ibm.com>
diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
new file mode 100644
index 000000000000..dd72073d2d4f
--- /dev/null
+++ b/include/linux/mfd/ocelot.h
@@ -0,0 +1,62 @@ 
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2022 Innovative Advantage Inc. */
+
+#ifndef _LINUX_MFD_OCELOT_H
+#define _LINUX_MFD_OCELOT_H
+
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+struct resource;
+
+static inline 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;
+	void __iomem *regs;
+
+	/*
+	 * Don't use _get_and_ioremap_resource() here, since that will invoke
+	 * prints of "invalid resource" which will simply add confusion.
+	 */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, index);
+	if (res) {
+		regs = devm_ioremap_resource(dev, res);
+		if (IS_ERR(regs))
+			return ERR_CAST(regs);
+		return devm_regmap_init_mmio(dev, regs, config);
+	}
+
+	/*
+	 * Fall back to using REG and getting the resource from the parent
+	 * device, which is possible in an MFD configuration
+	 */
+	if (dev->parent) {
+		res = platform_get_resource(pdev, IORESOURCE_REG, index);
+		if (!res)
+			return NULL;
+
+		return dev_get_regmap(dev->parent, res->name);
+	}
+
+	return NULL;
+}
+
+static inline 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);
+}
+
+#endif