| Message ID | 20220610175655.776153-1-colin.foster@in-advantage.com |
|---|---|
| Headers | show |
| Series | add support for VSC7512 control over SPI | expand |
On Fri, Jun 10, 2022 at 7:57 PM Colin Foster <colin.foster@in-advantage.com> wrote: > > There are a few Ocelot chips that contain the logic for this bus, but are > controlled externally. Specifically the VSC7511, 7512, 7513, and 7514. In > the externally controlled configurations these registers are not > memory-mapped. > > Add support for these non-memory-mapped configurations. ... > + ocelot_platform_init_regmap_from_resource(pdev, 0, &mii_regmap, NULL, > + &mscc_miim_regmap_config); This is a bit non-standard, why not to follow the previously used API design, i.e. mii_regmap.map = ... ? ... > + ocelot_platform_init_regmap_from_resource(pdev, 1, &phy_regmap, &res, > + &mscc_miim_phy_regmap_config); Ditto. Also here is the question how '_from_' is aligned with '&res'. If it's _from_ a resource then the resource is already a pointer. ... > if (res) { > - phy_regs = devm_ioremap_resource(dev, res); > - if (IS_ERR(phy_regs)) { > - dev_err(dev, "Unable to map internal phy registers\n"); > - return PTR_ERR(phy_regs); > - } > - > - phy_regmap = devm_regmap_init_mmio(dev, phy_regs, > - &mscc_miim_phy_regmap_config); > if (IS_ERR(phy_regmap)) { > dev_err(dev, "Unable to create phy register regmap\n"); > return PTR_ERR(phy_regmap); > } This looks weird. You check an error here instead of the API you called. It's a weird design, the rationale of which is doubtful and has to be at least explained. > + } else { > + phy_regmap = NULL; > } -- With Best Regards, Andy Shevchenko
On Sat, Jun 11, 2022 at 12:26:31PM +0200, Andy Shevchenko wrote: > On Fri, Jun 10, 2022 at 7:57 PM Colin Foster > <colin.foster@in-advantage.com> 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. > > ... > > > +#include <linux/err.h> > > +#include <linux/platform_device.h> > > +#include <linux/regmap.h> > > Since it's header the rule of thumb is to include headers this one is > a direct user of. Here I see missed > types.h > > Also missed forward declarations > > struct resource; Ahh, thank you. Yes, you mentioned this in v8 but I misuderstood what you were saying. I'll also include types.h. > > ... > > > + if (!IS_ERR(regs)) > > Why not positive conditional? > > > + *map = devm_regmap_init_mmio(&pdev->dev, regs, config); > > + else > > + *map = ERR_PTR(ENODEV); > > Missed -. Fixed. Thanks. > > -- > With Best Regards, > Andy Shevchenko
Hi Andy, On Sat, Jun 11, 2022 at 12:34:59PM +0200, Andy Shevchenko wrote: > On Fri, Jun 10, 2022 at 7:57 PM Colin Foster > <colin.foster@in-advantage.com> wrote: > > > > There are a few Ocelot chips that contain the logic for this bus, but are > > controlled externally. Specifically the VSC7511, 7512, 7513, and 7514. In > > the externally controlled configurations these registers are not > > memory-mapped. > > > > Add support for these non-memory-mapped configurations. > > ... > > > + ocelot_platform_init_regmap_from_resource(pdev, 0, &mii_regmap, NULL, > > + &mscc_miim_regmap_config); > > This is a bit non-standard, why not to follow the previously used API > design, i.e. > > mii_regmap.map = ... > > ? I see your point. It looks like there's no reason to pass in &mii_regmap and it can just be returned. > > ... > > > + ocelot_platform_init_regmap_from_resource(pdev, 1, &phy_regmap, &res, > > + &mscc_miim_phy_regmap_config); > > Ditto. > > Also here is the question how '_from_' is aligned with '&res'. If > it's _from_ a resource then the resource is already a pointer. Yes, this is probably worth a second look. During v8 you noted that I was repeating a lot of the same logic across several files, so I created ocelot_platform_init_regmap_from_resource. The "gotcha" is while most of those scenarios have a required resource, the phy_regmap is optional - so a scenario where the resource doesn't exist could be considered valid. Would it make sense to make the init_regmap_from_resource function return ERR_PTR(-ENOENT) if regs doesn't exist? That would clean up the API quite a bit: phy_regmap = ocelot_platform_init_regmap_from_resource(pdev, 1, &map_config); if (IS_ERR(phy_regmap) && phy_regmap != -ENOENT) { dev_err(); ... } It looks like none of the two functions that would get returned otherwise (devm_regmap_init or devm_regmap_init_mmio) would return that value... > > ... > > > if (res) { > > - phy_regs = devm_ioremap_resource(dev, res); > > - if (IS_ERR(phy_regs)) { > > - dev_err(dev, "Unable to map internal phy registers\n"); > > - return PTR_ERR(phy_regs); > > - } > > - > > - phy_regmap = devm_regmap_init_mmio(dev, phy_regs, > > - &mscc_miim_phy_regmap_config); > > if (IS_ERR(phy_regmap)) { > > dev_err(dev, "Unable to create phy register regmap\n"); > > return PTR_ERR(phy_regmap); > > } > > This looks weird. You check an error here instead of the API you > called. It's a weird design, the rationale of which is doubtful and > has to be at least explained. I agree. With the changes I'm suggesting above this block of code would become: if (IS_ERR(phy_regmap)) { if (phy_regmap == -ENOENT) { phy_regmap = NULL; } else { dev_err(dev, "..."); return PTR_ERR(phy_regmap); } } That seems easier to follow than the if(res) block... Thanks for the feedback! > > > + } else { > > + phy_regmap = NULL; > > } > > -- > With Best Regards, > Andy Shevchenko
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"; }; [ ... ] }; }; And I'll include the relevant dmesg prints - I don't love the "invalid resource" prints, as they seem to be misleading. They're a byproduct of looking for IO resources before falling back to REG, which succeeds. [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.18.0-12138-g89bf3be45d34 (colin@euler) (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #702 SMP PREEMPT Fri Jun 10 10:12:20 PDT 2022 ... [ 1.923330] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set [ 1.923498] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource [ 1.935102] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered [ 1.954499] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set [ 1.954708] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource [ 1.966000] mscc-miim ocelot-miim0.2.auto: DMA mask not set [ 1.966154] mscc-miim ocelot-miim0.2.auto: invalid resource [ 1.966307] mscc-miim ocelot-miim0.2.auto: invalid resource [ 2.995959] mscc-miim ocelot-miim1.3.auto: DMA mask not set [ 2.996118] mscc-miim ocelot-miim1.3.auto: invalid resource [ 2.996274] mscc-miim ocelot-miim1.3.auto: invalid resource [ 2.996286] mscc-miim ocelot-miim1.3.auto: error 00000000: Failed to get resource Lastly, I removed the Kconfig tristate patches for pinctrl and ocelot-mfd. They broke the last RFC build, so I'll probably want to add that at a later time. I only have hardware to test the last patch, so any testers are welcome. I've been extra cautious about the ocelot_platform_init_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 Colin Foster (7): 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: add ability to be used in a non-mmio configuration 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 | 18 + drivers/mfd/Makefile | 2 + drivers/mfd/ocelot-core.c | 184 ++++++++++ drivers/mfd/ocelot-spi.c | 313 ++++++++++++++++++ drivers/mfd/ocelot.h | 28 ++ drivers/net/mdio/mdio-mscc-miim.c | 27 +- drivers/pinctrl/pinctrl-microchip-sgpio.c | 9 +- drivers/pinctrl/pinctrl-ocelot.c | 10 +- include/linux/ioport.h | 5 + include/linux/mfd/ocelot.h | 32 ++ 12 files changed, 763 insertions(+), 32 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