| Message ID | 20220905162132.2943088-2-colin.foster@in-advantage.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | add support for VSC7512 control over SPI | expand |
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.
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.
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.
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