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 <[email protected]>
Reviewed-by: Vladimir Oltean <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
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
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 <[email protected]>
+S: Supported
+F: include/linux/mfd/ocelot.h
+
OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
M: Frederic Barrat <[email protected]>
M: Andrew Donnellan <[email protected]>
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
--
2.25.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 <[email protected]>
> Reviewed-by: Vladimir Oltean <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> ---
> 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.
--
Lee Jones [李琼斯]
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?
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 :-)
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!
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.
--
Lee Jones [李琼斯]
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.
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.