| Message ID | 20220705204743.3224692-1-colin.foster@in-advantage.com |
|---|---|
| Headers | show |
| Series | add support for VSC7512 control over SPI | expand |
On Tue, Jul 05, 2022 at 01:47:35PM -0700, 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> > --- To me this looks good, I'll just add a few minor comments which I think you don't necessarily need to address by resending, they're just things I noticed. Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> > MAINTAINERS | 5 ++++ > include/linux/mfd/ocelot.h | 55 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 60 insertions(+) > create mode 100644 include/linux/mfd/ocelot.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 28108e4fdb8f..f781caceeb38 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14467,6 +14467,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..353b7c2ee445 > --- /dev/null > +++ b/include/linux/mfd/ocelot.h > @@ -0,0 +1,55 @@ > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ > +/* Copyright 2022 Innovative Advantage Inc. */ A header file should have ifdefs which should prevent double inclusion, like #ifndef _MFD_OCELOT_H #define _MFD_OCELOT_H ... #endif > + > +#include <linux/err.h> > +#include <linux/platform_device.h> > +#include <linux/regmap.h> > +#include <linux/types.h> > + > +struct resource; IMO if include/linux/platform_device.h doesn't provide "struct resource" that's a problem for that header to solve, not for its users. > + > +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; > + u32 __iomem *regs; "regs" could be void *. > + > + /* > + * Don't use get_and_ioremap_resource here, since that will invoke > + * prints of "invalid resource" which 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); > +} > -- > 2.25.1 >
On Tue, Jul 05, 2022 at 01:47:42PM -0700, Colin Foster wrote: > Add devicetree bindings for SPI-controlled Ocelot chips, specifically the > VSC7512. > > Signed-off-by: Colin Foster <colin.foster@in-advantage.com> > Reviewed-by: Rob Herring <robh@kernel.org> > --- Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote: > > Can this go into net-next if there are no more complains over the > > weekend? Anyone still planning to review? > > As the subsystem with the fewest changes, I'm not sure why it would. Yeah, just going by the tag in the subject. I have no preference, looks like it applies cleanly to Linus'. > I'd planed to route this in via MFD and send out a pull-request for > other sub-system maintainers to pull from. > > If you would like to co-ordinate it instead, you'd be welcome to. > However, I (and probably Linus) would need a succinct immutable branch > to pull from. Oh, that'd be perfect, sorry, I didn't realize there was already a plan. If you're willing to carry on as intended, please do. Colin if there is another version please make a note of the above merging plan in the cover letter and drop the net-next tag. Just in case my goldfish brain forgets.
On Mon, Jul 11, 2022 at 11:21:16AM -0700, Jakub Kicinski wrote: > On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote: > > > Can this go into net-next if there are no more complains over the > > > weekend? Anyone still planning to review? > > > > As the subsystem with the fewest changes, I'm not sure why it would. > > Yeah, just going by the tag in the subject. I have no preference, > looks like it applies cleanly to Linus'. > > > I'd planed to route this in via MFD and send out a pull-request for > > other sub-system maintainers to pull from. > > > > If you would like to co-ordinate it instead, you'd be welcome to. > > However, I (and probably Linus) would need a succinct immutable branch > > to pull from. > > Oh, that'd be perfect, sorry, I didn't realize there was already a plan. > If you're willing to carry on as intended, please do. > > Colin if there is another version please make a note of the above > merging plan in the cover letter and drop the net-next tag. > Just in case my goldfish brain forgets. I wasn't sure of the plan, but this makes sense to bring it through MFD. Fortunately there's enough work for me on the DSA front that there's no way that'll land before this merge window - so I have no objection to it going any non-net-next path. I'll look to Lee as to whether there should be a v14 with the header guard addition per Vladimir's review, or whether that should be in a future patch set. I'm happy to go either way.
On Tue, Jul 12, 2022 at 10:08:57PM +0000, Vladimir Oltean wrote: > On Mon, Jul 11, 2022 at 07:10:48PM -0700, Colin Foster wrote: > > On Mon, Jul 11, 2022 at 11:21:16AM -0700, Jakub Kicinski wrote: > > > On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote: > > > > > Can this go into net-next if there are no more complains over the > > > > > weekend? Anyone still planning to review? > > > > > > > > As the subsystem with the fewest changes, I'm not sure why it would. > > > > > > Yeah, just going by the tag in the subject. I have no preference, > > > looks like it applies cleanly to Linus'. > > > > > > > I'd planed to route this in via MFD and send out a pull-request for > > > > other sub-system maintainers to pull from. > > > > > > > > If you would like to co-ordinate it instead, you'd be welcome to. > > > > However, I (and probably Linus) would need a succinct immutable branch > > > > to pull from. > > > > > > Oh, that'd be perfect, sorry, I didn't realize there was already a plan. > > > If you're willing to carry on as intended, please do. > > > > > > Colin if there is another version please make a note of the above > > > merging plan in the cover letter and drop the net-next tag. > > > Just in case my goldfish brain forgets. > > > > I wasn't sure of the plan, but this makes sense to bring it through MFD. > > Fortunately there's enough work for me on the DSA front that there's no > > way that'll land before this merge window - so I have no objection to it > > going any non-net-next path. > > > > I'll look to Lee as to whether there should be a v14 with the header > > guard addition per Vladimir's review, or whether that should be in a > > future patch set. I'm happy to go either way. > > From my side, the changes to this patch set can be incremental, I'd be > happy if Lee would take them as is. Just making sure this hasn't slipped through the cracks. Should I resend this next week (Monday / Tuesday?) with the Reviewed-by tags and switch it to MFD instead of net-next?
The patch set in general is to add support for the VSC7512, and eventually the VSC7511, VSC7513 and VSC7514 devices controlled over SPI. Specifically this patch set enables pinctrl, serial gpio expander access, and control of an internal and an external MDIO bus. I have mentioned previously: The hardware setup I'm using for development is a beaglebone black, with jumpers from SPI0 to the microchip VSC7512 dev board. The microchip dev board has been modified to not boot from flash, but wait for SPI. An ethernet cable is connected from the beaglebone ethernet to port 0 of the dev board. Network functionality will be included in a future patch set. The device tree I'm using is included in the documentation, so I'll not include that in this cover letter. I have exported the serial GPIOs to the LEDs, and verified functionality via "echo heartbeat > sys/class/leds/port0led/trigger" / { vscleds { compatible = "gpio-leds"; vscled@0 { label = "port0led"; gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>; default-state = "off"; }; vscled@1 { label = "port0led1"; gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>; default-state = "off"; }; [ ... ] }; }; I verified module functionality with modprobe ocelot-soc; modprobe pinctrl-ocelot; modprobe pinctrl-microchip-sgpio; I only have hardware to test the last patch, so any testers are welcome. I've been extra cautious about the ocelot_regmap_from_resource helper function, both before and after the last patch. I accidentally broke it in the past and would like to avoid doing so again. RFC history: v1 (accidentally named vN) * Initial architecture. Not functional * General concepts laid out v2 * Near functional. No CPU port communication, but control over all external ports * Cleaned up regmap implementation from v1 v3 * Functional * Shared MDIO transactions routed through mdio-mscc-miim * CPU / NPI port enabled by way of vsc7512_enable_npi_port / felix->info->enable_npi_port * NPI port tagging functional - Requires a CPU port driver that supports frames of 1520 bytes. Verified with a patch to the cpsw driver v4 * Functional * Device tree fixes * Add hooks for pinctrl-ocelot - some functionality by way of sysfs * Add hooks for pinctrl-microsemi-sgpio - not yet fully functional * Remove lynx_pcs interface for a generic phylink_pcs. The goal here is to have an ocelot_pcs that will work for each configuration of every port. v5 * Restructured to MFD * Several commits were split out, submitted, and accepted * pinctrl-ocelot believed to be fully functional (requires commits from the linux-pinctrl tree) * External MDIO bus believed to be fully functional v6 * Applied several suggestions from the last RFC from Lee Jones. I hope I didn't miss anything. * Clean up MFD core - SPI interaction. They no longer use callbacks. * regmaps get registered to the child device, and don't attempt to get shared. It seems if a regmap is to be shared, that should be solved with syscon, not dev or mfd. v7 * Applied as much as I could from Lee and Vladimir's suggestions. As always, the feedback is greatly appreciated! * Remove "ocelot_spi" container complication * Move internal MDIO bus from ocelot_ext to MFD, with a devicetree change to match * Add initial HSIO support * Switch to IORESOURCE_REG for resource definitions v8 * Applied another round of suggestions from Lee and Vladimir * Utilize regmap bus reads, which speeds bulk transfers up by an order of magnitude * Add two additional patches to utilize phylink_generic_validate * Changed GPL V2 to GPL in licenses where applicable (checkpatch) * Remove initial hsio/serdes changes from the RFC v9 * Submitting as a PATCH instead of an RFC * Remove switch functionality - will be a separate patch set * Remove Kconfig tristate module options * Another round of suggestions from Lee, Vladimir, and Andy. Many thanks! * Add documentation * Update maintainers v10 * Fix warming by removing unused function v11 * Suggestions from Rob and Andy. Thanks! * Add pinctrl module functionality back and fixing those features * Fix aarch64 compiler error v12 * Suggestions from Vladimir, Andy, Randy, and Rob. Thanks as always! * Utilize dev_get_regmap to clean up interfaces * MFD_OCELOT can be a module v13 * Suggestions from Andy for code cleanup, missed includes, forward declarations, module names. * Fix x86 allmodconfig build * MFD module name is now ocelot-soc * Add module names to Kconfig for pinctrl changes Colin Foster (9): mfd: ocelot: add helper to get regmap from a resource net: mdio: mscc-miim: add ability to be used in a non-mmio configuration pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module pinctrl: ocelot: add ability to be used in a non-mmio configuration pinctrl: microchip-sgpio: allow sgpio driver to be used as a module pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration resource: add define macro for register address resources dt-bindings: mfd: ocelot: add bindings for VSC7512 mfd: ocelot: add support for the vsc7512 chip via spi .../devicetree/bindings/mfd/mscc,ocelot.yaml | 160 +++++++++ MAINTAINERS | 7 + drivers/mfd/Kconfig | 21 ++ drivers/mfd/Makefile | 3 + drivers/mfd/ocelot-core.c | 169 ++++++++++ drivers/mfd/ocelot-spi.c | 317 ++++++++++++++++++ drivers/mfd/ocelot.h | 34 ++ drivers/net/mdio/mdio-mscc-miim.c | 42 +-- drivers/pinctrl/Kconfig | 12 +- drivers/pinctrl/pinctrl-microchip-sgpio.c | 14 +- drivers/pinctrl/pinctrl-ocelot.c | 22 +- include/linux/ioport.h | 5 + include/linux/mfd/ocelot.h | 55 +++ 13 files changed, 810 insertions(+), 51 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml create mode 100644 drivers/mfd/ocelot-core.c create mode 100644 drivers/mfd/ocelot-spi.c create mode 100644 drivers/mfd/ocelot.h create mode 100644 include/linux/mfd/ocelot.h