| Message ID | 20220701192609.3970317-1-colin.foster@in-advantage.com |
|---|---|
| Headers | show |
| Series | add support for VSC7512 control over SPI | expand |
On Fri, Jul 1, 2022 at 9:26 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. ... > + res = platform_get_resource(pdev, IORESOURCE_MEM, index); > + if (res) { > + regs = devm_ioremap_resource(dev, res); > + if (IS_ERR(regs)) > + return ERR_CAST(regs); Why can't it be devm_platform_get_and_ioremap_resource() here? regs = devm_platform_get_and_ioremap_resource(); if (res) { if (IS_ERR(regs)) return ERR_CAST(); return ... } > + return devm_regmap_init_mmio(dev, regs, config); > + } ... > + return (map) ? map : ERR_PTR(-ENOENT); Too many parentheses. Also you may use short form of ternary operator: return map ?: ERR_PTR(-ENOENT);
On Fri, Jul 1, 2022 at 9:26 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. ... > + phy_regmap = ocelot_regmap_from_resource_optional(pdev, 1, > + &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); return dev_err_probe(...); ? > }
On Fri, Jul 01, 2022 at 10:23:36PM +0200, Andy Shevchenko wrote: > On Fri, Jul 1, 2022 at 9:26 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. > > ... > > > + res = platform_get_resource(pdev, IORESOURCE_MEM, index); > > + if (res) { > > + regs = devm_ioremap_resource(dev, res); > > + if (IS_ERR(regs)) > > + return ERR_CAST(regs); > > Why can't it be devm_platform_get_and_ioremap_resource() here? It can... but it invokes prints of "invalid resource" during initialization. Here it was implied that I should break the function call out: https://patchwork.kernel.org/project/netdevbpf/patch/20220628081709.829811-2-colin.foster@in-advantage.com/#24917551 > > regs = devm_platform_get_and_ioremap_resource(); > if (res) { > if (IS_ERR(regs)) > return ERR_CAST(); > return ... > } > > > + return devm_regmap_init_mmio(dev, regs, config); > > + } > > ... > > > + return (map) ? map : ERR_PTR(-ENOENT); > > Too many parentheses. > > Also you may use short form of ternary operator: > > return map ?: ERR_PTR(-ENOENT); Agreed, and I didn't know about that operator. When Vladimir suggested it I thought it was a typo. I should've known better. > > -- > With Best Regards, > Andy Shevchenko
On Fri, Jul 01, 2022 at 10:24:46PM +0200, Andy Shevchenko wrote: > On Fri, Jul 1, 2022 at 9:26 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. > > ... > > > + phy_regmap = ocelot_regmap_from_resource_optional(pdev, 1, > > + &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); > > return dev_err_probe(...); ? Thanks. Also the same is in pinctrl-ocelot. Fixing in my tree right now. > > > } > > -- > With Best Regards, > Andy Shevchenko
On Fri, Jul 1, 2022 at 9:26 PM Colin Foster <colin.foster@in-advantage.com> wrote: > > The VSC7512 is a networking chip that contains several peripherals. Many of > these peripherals are currently supported by the VSC7513 and VSC7514 chips, > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be > controlled externally. > > Utilize the existing drivers by referencing the chip as an MFD. Add support > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO. ... > +config MFD_OCELOT > + tristate "Microsemi Ocelot External Control Support" > + depends on SPI_MASTER > + select MFD_CORE > + select REGMAP_SPI > + help > + Ocelot is a family of networking chips that support multiple ethernet > + and fibre interfaces. In addition to networking, they contain several > + other functions, including pinctrl, MDIO, and communication with > + external chips. While some chips have an internal processor capable of > + running an OS, others don't. All chips can be controlled externally > + through different interfaces, including SPI, I2C, and PCIe. > + > + Say yes here to add support for Ocelot chips (VSC7511, VSC7512, > + VSC7513, VSC7514) controlled externally. > + > + If unsure, say N. What will be the module name? ... It misses a few inclusions, like kernel.h for ARRAY_SIZE() and types.h for booleans. > +#include <linux/mfd/core.h> > +#include <linux/mfd/ocelot.h> > +#include <linux/module.h> > +#include <linux/regmap.h> + blank line? > +#include <soc/mscc/ocelot.h> ... > +#define GCB_SOFT_RST 0x0008 > + > +#define SOFT_CHIP_RST 0x1 It's not clear what these values are: register offsets? Bit fields of the hardware registers? Commands to some IPC? > +#define VSC7512_GCB_RST_SLEEP 100 > +#define VSC7512_GCB_RST_TIMEOUT 100000 Missed units in both cases. ... > +static int ocelot_gcb_chip_rst_status(struct ocelot_ddata *ddata) > +{ > + int val, err; > + > + err = regmap_read(ddata->gcb_regmap, GCB_SOFT_RST, &val); > + if (err) > + val = -1; Can be returned directly. Why not a proper error code, btw? > + return val; > +} ... > +#include <linux/iopoll.h> What for? Maybe it should be ioport.h ? ... > + static const u8 dummy_buf[16] = {0}; On stack for DMA?! Hmm... ... > + err = spi_setup(spi); > + if (err < 0) { > + return dev_err_probe(&spi->dev, err, > + "Error performing SPI setup\n"); > + } {} are not needed. ... > + err = ocelot_spi_initialize(dev); > + if (err) { > + return dev_err_probe(dev, err, > + "Error initializing SPI bus after reset\n"); > + } {} are not needed. > + err = ocelot_core_init(dev); > + if (err < 0) { Ditto. > + return dev_err_probe(dev, err, > + "Error initializing Ocelot core\n"); > + return err; Dead code. > + } ... > +#include <asm/byteorder.h> You missed a lot of forward declarations that are used in this file. Like struct spi_device;
On Fri, Jul 1, 2022 at 10:35 PM Colin Foster <colin.foster@in-advantage.com> wrote: > On Fri, Jul 01, 2022 at 10:23:36PM +0200, Andy Shevchenko wrote: > > On Fri, Jul 1, 2022 at 9:26 PM Colin Foster > > <colin.foster@in-advantage.com> wrote: ... > > > + res = platform_get_resource(pdev, IORESOURCE_MEM, index); > > > + if (res) { > > > + regs = devm_ioremap_resource(dev, res); > > > + if (IS_ERR(regs)) > > > + return ERR_CAST(regs); > > > > Why can't it be devm_platform_get_and_ioremap_resource() here? > > It can... but it invokes prints of "invalid resource" during > initialization. > > Here it was implied that I should break the function call out: > https://patchwork.kernel.org/project/netdevbpf/patch/20220628081709.829811-2-colin.foster@in-advantage.com/#24917551 Perhaps a comment in the code, so nobody will try to optimize this in the future. > > > + return devm_regmap_init_mmio(dev, regs, config); > > > + } ... > > > + return (map) ? map : ERR_PTR(-ENOENT); > > > > Too many parentheses. > > > > Also you may use short form of ternary operator: > > > > return map ?: ERR_PTR(-ENOENT); > > Agreed, and I didn't know about that operator. When Vladimir suggested > it I thought it was a typo. I should've known better. It's easy to remember by thinking of "X ?: Y" as "X _or_ Y".
On Fri, Jul 01, 2022 at 10:38:46PM +0200, Andy Shevchenko wrote: > On Fri, Jul 1, 2022 at 9:26 PM Colin Foster > <colin.foster@in-advantage.com> wrote: > > > > The VSC7512 is a networking chip that contains several peripherals. Many of > > these peripherals are currently supported by the VSC7513 and VSC7514 chips, > > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be > > controlled externally. > > > > Utilize the existing drivers by referencing the chip as an MFD. Add support > > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO. > > ... > > > + static const u8 dummy_buf[16] = {0}; > > On stack for DMA?! Hmm... I'll respond to the rest of your comments as I go through them. But this one in particular I'll apologize for. Ew. I'll fix that right up!
On Fri, 1 Jul 2022 12:26:09 -0700 Colin Foster wrote: > The VSC7512 is a networking chip that contains several peripherals. Many of > these peripherals are currently supported by the VSC7513 and VSC7514 chips, > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be > controlled externally. > > Utilize the existing drivers by referencing the chip as an MFD. Add support > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO. allmodconfig is not happy, I didn't spot that being mentioned as expected: ERROR: modpost: "ocelot_spi_init_regmap" [drivers/mfd/ocelot-core.ko] undefined! WARNING: modpost: module ocelot-spi uses symbol ocelot_chip_reset from namespace MFD_OCELOT, but does not import it. WARNING: modpost: module ocelot-spi uses symbol ocelot_core_init from namespace MFD_OCELOT, but does not import it. make[2]: *** [../scripts/Makefile.modpost:128: modules-only.symvers] Error 1 make[1]: *** [/home/nipa/net-next/Makefile:1757: modules] Error 2
On Fri, Jul 01, 2022 at 08:02:41PM -0700, Jakub Kicinski wrote: > On Fri, 1 Jul 2022 12:26:09 -0700 Colin Foster wrote: > > The VSC7512 is a networking chip that contains several peripherals. Many of > > these peripherals are currently supported by the VSC7513 and VSC7514 chips, > > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be > > controlled externally. > > > > Utilize the existing drivers by referencing the chip as an MFD. Add support > > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO. > > allmodconfig is not happy, I didn't spot that being mentioned as > expected: > > ERROR: modpost: "ocelot_spi_init_regmap" [drivers/mfd/ocelot-core.ko] undefined! > WARNING: modpost: module ocelot-spi uses symbol ocelot_chip_reset from namespace MFD_OCELOT, but does not import it. > WARNING: modpost: module ocelot-spi uses symbol ocelot_core_init from namespace MFD_OCELOT, but does not import it. > make[2]: *** [../scripts/Makefile.modpost:128: modules-only.symvers] Error 1 > make[1]: *** [/home/nipa/net-next/Makefile:1757: modules] Error 2 Yikes. I'll button this up. I'm surprised that I need to import the namespace of my own module... but I don't have a strong enough understanding of what all is going on. Also, allmodconfig never compiles for me, so I can't really test it: make W=1 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j$(nproc) ... arch/arm/vdso/vgettimeofday.c:10:5: error: no previous prototype for ‘__vdso_clock_gettime’ [-Werror=missing-prototypes] 10 | int __vdso_clock_gettime(clockid_t clock, | ^~~~~~~~~~~~~~~~~~~~ arch/arm/vdso/vgettimeofday.c:16:5: error: no previous prototype for ‘__vdso_clock_gettime64’ [-Werror=missing-prototypes] 16 | int __vdso_clock_gettime64(clockid_t clock, | ^~~~~~~~~~~~~~~~~~~~~~ arch/arm/vdso/vgettimeofday.c:22:5: error: no previous prototype for ‘__vdso_gettimeofday’ [-Werror=missing-prototypes] 22 | int __vdso_gettimeofday(struct __kernel_old_timeval *tv, | ^~~~~~~~~~~~~~~~~~~ arch/arm/vdso/vgettimeofday.c:28:5: error: no previous prototype for ‘__vdso_clock_getres’ [-Werror=missing-prototypes] 28 | int __vdso_clock_getres(clockid_t clock_id, I'll try it without cross-compile and see if I have better luck.
On Fri, Jul 01, 2022 at 12:26:00PM -0700, Colin Foster wrote: > 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"; > }; > [ ... ] > }; > }; > > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 5.19.0-rc3-00745-g30c05ffbecdc (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #826 SMP PREEMPT Fri Jul 1 11:26:44 PDT 2022 > ... > [ 1.952616] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set > [ 1.956522] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered > [ 1.967188] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set > [ 1.983763] mscc-miim ocelot-miim0.2.auto: DMA mask not set > [ 3.020687] mscc-miim ocelot-miim1.3.auto: DMA mask not set > > > 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! Not all that useful as a changelog. I have no idea what I told you as that was probably 100s of reviews ago. When writing changelogs for patch revisions, you need to describe what changed. And it's best to put that into the relevant patch. IOW, I want to know what I said to change so I know what I need to look at again in particular. And now that I've found v11, 'suggestions from Rob' isn't really accurate as you fixed errors reported by running the tools. Rob
On Tue, Jul 05, 2022 at 02:24:22PM -0600, Rob Herring wrote: > On Fri, Jul 01, 2022 at 12:26:00PM -0700, Colin Foster wrote: > > 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"; > > }; > > [ ... ] > > }; > > }; > > > > [ 0.000000] Booting Linux on physical CPU 0x0 > > [ 0.000000] Linux version 5.19.0-rc3-00745-g30c05ffbecdc (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #826 SMP PREEMPT Fri Jul 1 11:26:44 PDT 2022 > > ... > > [ 1.952616] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set > > [ 1.956522] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered > > [ 1.967188] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set > > [ 1.983763] mscc-miim ocelot-miim0.2.auto: DMA mask not set > > [ 3.020687] mscc-miim ocelot-miim1.3.auto: DMA mask not set > > > > > > 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! > > Not all that useful as a changelog. I have no idea what I told you as > that was probably 100s of reviews ago. When writing changelogs for patch > revisions, you need to describe what changed. And it's best to put that > into the relevant patch. IOW, I want to know what I said to change so I > know what I need to look at again in particular. > > And now that I've found v11, 'suggestions from Rob' isn't really > accurate as you fixed errors reported by running the tools. > > Rob Good point - I'll be more clear going forward.
On Tue, Jul 05, 2022 at 01:30:15PM -0700, Colin Foster wrote: > > Not all that useful as a changelog. I have no idea what I told you as > > that was probably 100s of reviews ago. When writing changelogs for patch > > revisions, you need to describe what changed. And it's best to put that > > into the relevant patch. IOW, I want to know what I said to change so I > > know what I need to look at again in particular. > > > > And now that I've found v11, 'suggestions from Rob' isn't really > > accurate as you fixed errors reported by running the tools. > > > > Rob > > Good point - I'll be more clear going forward. I have to say I agree with Rob, and no, you weren't more clear in the v13 you've just posted. First, you need to understand that a patch set with 13 revisions is on the long side. You can't honestly expect reviewers' attention span to last months. Now, ok, you're at v13 already, entropy goes forward, what can you do. First, you can link to previous versions in the cover letter, and also parallel series containing sub-groups of patches. This information needs to be carried throughout. I spent too long tracking your patch set numbering system, with change sets that sometimes cover DSA and sometimes don't, then they sometimes fork into separate series. I lost track, let's put it this way. I'm not an expert, but I spent my fair share of time with VSC751X datasheets and I am theoretically aware what this patch set is trying to do, but I'm still lost. Then, each patch needs to contain a version history of its own, in between the "---" marker and the git short stat. Look at other patch sets for examples. This must contain a description of the delta compared to the previous version, including commit message rewording. In extreme cases of large patch sets with essentially minimal changes from version to version, maybe even the output of "git range-diff" could be considered to be posted in the cover letter (that's rare though, but it might help). Generally, what you want to avoid is changing your mind in the middle of a long patch set, especially without traceability (without being asked to do so). Traceability here also means including links to review feedback asking to make a design change. It may also help if you reply to your own patch sets stating that you've found a problem in your own code, and that you're thinking about solving it in this or that way, even if you don't intend to get any reply. You may even try to ask someone whom you're not working very closely with to proof-read your patch sets and get an honest feedback "hey, are you even following what I'm saying here? could you summarize why I'm making the changes I'm making, and is this series generally progressing towards a resolve?" You got some feedback at v11 (I believe) from Jakub about reposting too soon. The phrasing was relatively rude and I'm not sure that you got the central idea right. Large patch sets are generally less welcome when submitted back to back compared to small ones, but they still need to be posted frequent enough to not lose reviewers' attention. And small fixups to fix a build as module are not going to make a huge difference when reviewing, so it's best not to dig your own grave by gratuitously bumping the version number just for a compilation fix. Again, replying to your own patch saying "X was supposed to be Y, otherwise please go on reviewing", may help. Also, ordering. I don't necessarily care what changed between v1 and v2 when you post v13. So you could start with the changelog for v13 and go back in time from there, so that reviewers don't have to scroll more and more for each revision.
On Wed, Jul 06, 2022 at 01:04:32AM +0300, Vladimir Oltean wrote: > You got some feedback at v11 (I believe) from Jakub about reposting too > soon. The phrasing was relatively rude and I'm not sure that you got the > central idea right. Large patch sets are generally less welcome when > submitted back to back compared to small ones, but they still need to be > posted frequent enough to not lose reviewers' attention. And small > fixups to fix a build as module are not going to make a huge difference > when reviewing, so it's best not to dig your own grave by gratuitously > bumping the version number just for a compilation fix. Again, replying > to your own patch saying "X was supposed to be Y, otherwise please go on > reviewing", may help. I hope I'm not coming off as a know-it-all by saying this, and I didn't intend to make you feel bad. Ask me how do I know, and the answer will be by making the same mistakes, of course. Not sure if he's already on your radar, but you can watch and analyze the patches submitted by Russell King. For example the recent patch set for making phylink accept DSA CPU port OF nodes with no fixed-link or phy-handle. Perfect timing in resubmitting a new series when one was due, even when the previous one got no feedback whatsoever (which seems to be the hardest situation to deal with). You need to be able to take decisions even when you're doing so on your own, and much of that comes with experience.
On Tue, Jul 05, 2022 at 10:56:26PM +0000, Vladimir Oltean wrote: > On Wed, Jul 06, 2022 at 01:04:32AM +0300, Vladimir Oltean wrote: > > You got some feedback at v11 (I believe) from Jakub about reposting too > > soon. The phrasing was relatively rude and I'm not sure that you got the > > central idea right. Large patch sets are generally less welcome when > > submitted back to back compared to small ones, but they still need to be > > posted frequent enough to not lose reviewers' attention. And small > > fixups to fix a build as module are not going to make a huge difference > > when reviewing, so it's best not to dig your own grave by gratuitously > > bumping the version number just for a compilation fix. Again, replying > > to your own patch saying "X was supposed to be Y, otherwise please go on > > reviewing", may help. > > I hope I'm not coming off as a know-it-all by saying this, and I didn't > intend to make you feel bad. Ask me how do I know, and the answer will > be by making the same mistakes, of course. No worries, but thanks for the concern. I understand the v10 fiasco was my fault - I'm alright with being put in my place. This is very much a learning experience for me, so all this feedback helps. And I also am recognizing a difference being past the RFC stage. The changes are becoming more subtle, while the initial RFCs had pretty significant rewrites / restructures. I'll be mindful of this going forward, and call out any changes I come across in self-review. > > Not sure if he's already on your radar, but you can watch and analyze > the patches submitted by Russell King. For example the recent patch set > for making phylink accept DSA CPU port OF nodes with no fixed-link or > phy-handle. Perfect timing in resubmitting a new series when one was > due, even when the previous one got no feedback whatsoever (which seems > to be the hardest situation to deal with). You need to be able to take > decisions even when you're doing so on your own, and much of that comes > with experience. I see the cadence of every 5-7 days or so seems to be the sweet spot. I had thought this v13 would have been long enough since v12 (4 days) but that seems to have been incorrect (understanding it was over a weekend). I'll be more mindful of this in the future.
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"; }; [ ... ] }; }; [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.19.0-rc3-00745-g30c05ffbecdc (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #826 SMP PREEMPT Fri Jul 1 11:26:44 PDT 2022 ... [ 1.952616] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set [ 1.956522] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered [ 1.967188] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set [ 1.983763] mscc-miim ocelot-miim0.2.auto: DMA mask not set [ 3.020687] mscc-miim ocelot-miim1.3.auto: DMA mask not set 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 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 | 18 + drivers/mfd/Makefile | 2 + drivers/mfd/ocelot-core.c | 164 +++++++++ drivers/mfd/ocelot-spi.c | 312 ++++++++++++++++++ drivers/mfd/ocelot.h | 28 ++ drivers/net/mdio/mdio-mscc-miim.c | 34 +- drivers/pinctrl/Kconfig | 4 +- drivers/pinctrl/pinctrl-microchip-sgpio.c | 14 +- drivers/pinctrl/pinctrl-ocelot.c | 15 +- include/linux/ioport.h | 5 + include/linux/mfd/ocelot.h | 51 +++ 13 files changed, 772 insertions(+), 42 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