* [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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
--
2.25.1
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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>
---
MAINTAINERS | 5 ++++
include/linux/mfd/ocelot.h | 51 ++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+)
create mode 100644 include/linux/mfd/ocelot.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c029ab73265..c2f61ed1b730 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14413,6 +14413,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..7e64870b75ca
--- /dev/null
+++ b/include/linux/mfd/ocelot.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2022 Innovative Advantage Inc. */
+
+#include <linux/err.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;
+ u32 __iomem *regs;
+
+ 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) ? map : ERR_PTR(-ENOENT);
+}
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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>
---
MAINTAINERS | 5 ++++
include/linux/mfd/ocelot.h | 51 ++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+)
create mode 100644 include/linux/mfd/ocelot.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c029ab73265..c2f61ed1b730 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14413,6 +14413,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..7e64870b75ca
--- /dev/null
+++ b/include/linux/mfd/ocelot.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2022 Innovative Advantage Inc. */
+
+#include <linux/err.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;
+ u32 __iomem *regs;
+
+ 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) ? map : ERR_PTR(-ENOENT);
+}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
drivers/net/mdio/mdio-mscc-miim.c | 34 ++++++++-----------------------
1 file changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 08541007b18a..c23a9fb5238c 100644
--- a/drivers/net/mdio/mdio-mscc-miim.c
+++ b/drivers/net/mdio/mdio-mscc-miim.c
@@ -12,6 +12,7 @@
#include <linux/iopoll.h>
#include <linux/kernel.h>
#include <linux/mdio/mdio-mscc-miim.h>
+#include <linux/mfd/ocelot.h>
#include <linux/module.h>
#include <linux/of_mdio.h>
#include <linux/phy.h>
@@ -270,43 +271,26 @@ static int mscc_miim_clk_set(struct mii_bus *bus)
static int mscc_miim_probe(struct platform_device *pdev)
{
- struct regmap *mii_regmap, *phy_regmap = NULL;
struct device_node *np = pdev->dev.of_node;
+ struct regmap *mii_regmap, *phy_regmap;
struct device *dev = &pdev->dev;
- void __iomem *regs, *phy_regs;
struct mscc_miim_dev *miim;
- struct resource *res;
struct mii_bus *bus;
int ret;
- regs = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
- if (IS_ERR(regs)) {
- dev_err(dev, "Unable to map MIIM registers\n");
- return PTR_ERR(regs);
- }
-
- mii_regmap = devm_regmap_init_mmio(dev, regs, &mscc_miim_regmap_config);
-
+ mii_regmap = ocelot_regmap_from_resource(pdev, 0,
+ &mscc_miim_regmap_config);
if (IS_ERR(mii_regmap)) {
dev_err(dev, "Unable to create MIIM regmap\n");
return PTR_ERR(mii_regmap);
}
/* This resource is optional */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- 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);
- }
+ 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);
}
ret = mscc_miim_setup(dev, &bus, "mscc_miim", mii_regmap, 0);
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
drivers/net/mdio/mdio-mscc-miim.c | 34 ++++++++-----------------------
1 file changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 08541007b18a..c23a9fb5238c 100644
--- a/drivers/net/mdio/mdio-mscc-miim.c
+++ b/drivers/net/mdio/mdio-mscc-miim.c
@@ -12,6 +12,7 @@
#include <linux/iopoll.h>
#include <linux/kernel.h>
#include <linux/mdio/mdio-mscc-miim.h>
+#include <linux/mfd/ocelot.h>
#include <linux/module.h>
#include <linux/of_mdio.h>
#include <linux/phy.h>
@@ -270,43 +271,26 @@ static int mscc_miim_clk_set(struct mii_bus *bus)
static int mscc_miim_probe(struct platform_device *pdev)
{
- struct regmap *mii_regmap, *phy_regmap = NULL;
struct device_node *np = pdev->dev.of_node;
+ struct regmap *mii_regmap, *phy_regmap;
struct device *dev = &pdev->dev;
- void __iomem *regs, *phy_regs;
struct mscc_miim_dev *miim;
- struct resource *res;
struct mii_bus *bus;
int ret;
- regs = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
- if (IS_ERR(regs)) {
- dev_err(dev, "Unable to map MIIM registers\n");
- return PTR_ERR(regs);
- }
-
- mii_regmap = devm_regmap_init_mmio(dev, regs, &mscc_miim_regmap_config);
-
+ mii_regmap = ocelot_regmap_from_resource(pdev, 0,
+ &mscc_miim_regmap_config);
if (IS_ERR(mii_regmap)) {
dev_err(dev, "Unable to create MIIM regmap\n");
return PTR_ERR(mii_regmap);
}
/* This resource is optional */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- 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);
- }
+ 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);
}
ret = mscc_miim_setup(dev, &bus, "mscc_miim", mii_regmap, 0);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris, Florian Fainelli
Work is being done to allow external control of Ocelot chips. When pinctrl
drivers are used internally, it wouldn't make much sense to allow them to
be loaded as modules. In the case where the Ocelot chip is controlled
externally, this scenario becomes practical.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/pinctrl/Kconfig | 2 +-
drivers/pinctrl/pinctrl-ocelot.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index f52960d2dfbe..257b06752747 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -311,7 +311,7 @@ config PINCTRL_MICROCHIP_SGPIO
LED controller.
config PINCTRL_OCELOT
- bool "Pinctrl driver for the Microsemi Ocelot and Jaguar2 SoCs"
+ tristate "Pinctrl driver for the Microsemi Ocelot and Jaguar2 SoCs"
depends on OF
depends on HAS_IOMEM
select GPIOLIB
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 5f4a8c5c6650..d18047d2306d 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1889,6 +1889,7 @@ static const struct of_device_id ocelot_pinctrl_of_match[] = {
{ .compatible = "microchip,lan966x-pinctrl", .data = &lan966x_desc },
{},
};
+MODULE_DEVICE_TABLE(of, ocelot_pinctrl_of_match);
static struct regmap *ocelot_pinctrl_create_pincfg(struct platform_device *pdev)
{
@@ -1984,4 +1985,7 @@ static struct platform_driver ocelot_pinctrl_driver = {
},
.probe = ocelot_pinctrl_probe,
};
-builtin_platform_driver(ocelot_pinctrl_driver);
+module_platform_driver(ocelot_pinctrl_driver);
+
+MODULE_DESCRIPTION("Ocelot Chip Pinctrl Driver");
+MODULE_LICENSE("Dual MIT/GPL");
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris, Florian Fainelli
Work is being done to allow external control of Ocelot chips. When pinctrl
drivers are used internally, it wouldn't make much sense to allow them to
be loaded as modules. In the case where the Ocelot chip is controlled
externally, this scenario becomes practical.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/pinctrl/Kconfig | 2 +-
drivers/pinctrl/pinctrl-ocelot.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index f52960d2dfbe..257b06752747 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -311,7 +311,7 @@ config PINCTRL_MICROCHIP_SGPIO
LED controller.
config PINCTRL_OCELOT
- bool "Pinctrl driver for the Microsemi Ocelot and Jaguar2 SoCs"
+ tristate "Pinctrl driver for the Microsemi Ocelot and Jaguar2 SoCs"
depends on OF
depends on HAS_IOMEM
select GPIOLIB
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 5f4a8c5c6650..d18047d2306d 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1889,6 +1889,7 @@ static const struct of_device_id ocelot_pinctrl_of_match[] = {
{ .compatible = "microchip,lan966x-pinctrl", .data = &lan966x_desc },
{},
};
+MODULE_DEVICE_TABLE(of, ocelot_pinctrl_of_match);
static struct regmap *ocelot_pinctrl_create_pincfg(struct platform_device *pdev)
{
@@ -1984,4 +1985,7 @@ static struct platform_driver ocelot_pinctrl_driver = {
},
.probe = ocelot_pinctrl_probe,
};
-builtin_platform_driver(ocelot_pinctrl_driver);
+module_platform_driver(ocelot_pinctrl_driver);
+
+MODULE_DESCRIPTION("Ocelot Chip Pinctrl Driver");
+MODULE_LICENSE("Dual MIT/GPL");
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
There are a few Ocelot chips that contain pinctrl logic, but can be
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
drivers/pinctrl/pinctrl-ocelot.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index d18047d2306d..2e51d313c049 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -10,6 +10,7 @@
#include <linux/gpio/driver.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/mfd/ocelot.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
@@ -1918,7 +1919,6 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
struct ocelot_pinctrl *info;
struct reset_control *reset;
struct regmap *pincfg;
- void __iomem *base;
int ret;
struct regmap_config regmap_config = {
.reg_bits = 32,
@@ -1938,16 +1938,11 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
"Failed to get reset\n");
reset_control_reset(reset);
- base = devm_ioremap_resource(dev,
- platform_get_resource(pdev, IORESOURCE_MEM, 0));
- if (IS_ERR(base))
- return PTR_ERR(base);
-
info->stride = 1 + (info->desc->npins - 1) / 32;
regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
- info->map = devm_regmap_init_mmio(dev, base, ®map_config);
+ info->map = ocelot_regmap_from_resource(pdev, 0, ®map_config);
if (IS_ERR(info->map)) {
dev_err(dev, "Failed to create regmap\n");
return PTR_ERR(info->map);
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
There are a few Ocelot chips that contain pinctrl logic, but can be
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
drivers/pinctrl/pinctrl-ocelot.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index d18047d2306d..2e51d313c049 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -10,6 +10,7 @@
#include <linux/gpio/driver.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/mfd/ocelot.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
@@ -1918,7 +1919,6 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
struct ocelot_pinctrl *info;
struct reset_control *reset;
struct regmap *pincfg;
- void __iomem *base;
int ret;
struct regmap_config regmap_config = {
.reg_bits = 32,
@@ -1938,16 +1938,11 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
"Failed to get reset\n");
reset_control_reset(reset);
- base = devm_ioremap_resource(dev,
- platform_get_resource(pdev, IORESOURCE_MEM, 0));
- if (IS_ERR(base))
- return PTR_ERR(base);
-
info->stride = 1 + (info->desc->npins - 1) / 32;
regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
- info->map = devm_regmap_init_mmio(dev, base, ®map_config);
+ info->map = ocelot_regmap_from_resource(pdev, 0, ®map_config);
if (IS_ERR(info->map)) {
dev_err(dev, "Failed to create regmap\n");
return PTR_ERR(info->map);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris, Florian Fainelli
As the commit message suggests, this simply adds the ability to select
SGPIO pinctrl as a module. This becomes more practical when the SGPIO
hardware exists on an external chip, controlled indirectly by I2C or SPI.
This commit enables that level of control.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/pinctrl/Kconfig | 2 +-
drivers/pinctrl/pinctrl-microchip-sgpio.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 257b06752747..40d243bc91f8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -292,7 +292,7 @@ config PINCTRL_MCP23S08
corresponding interrupt-controller.
config PINCTRL_MICROCHIP_SGPIO
- bool "Pinctrl driver for Microsemi/Microchip Serial GPIO"
+ tristate "Pinctrl driver for Microsemi/Microchip Serial GPIO"
depends on OF
depends on HAS_IOMEM
select GPIOLIB
diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index 6f55bf7d5e05..e56074b7e659 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -999,6 +999,7 @@ static const struct of_device_id microchip_sgpio_gpio_of_match[] = {
/* sentinel */
}
};
+MODULE_DEVICE_TABLE(of, microchip_sgpio_gpio_of_match);
static struct platform_driver microchip_sgpio_pinctrl_driver = {
.driver = {
@@ -1008,4 +1009,7 @@ static struct platform_driver microchip_sgpio_pinctrl_driver = {
},
.probe = microchip_sgpio_probe,
};
-builtin_platform_driver(microchip_sgpio_pinctrl_driver);
+module_platform_driver(microchip_sgpio_pinctrl_driver);
+
+MODULE_DESCRIPTION("Microchip SGPIO Pinctrl Driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris, Florian Fainelli
As the commit message suggests, this simply adds the ability to select
SGPIO pinctrl as a module. This becomes more practical when the SGPIO
hardware exists on an external chip, controlled indirectly by I2C or SPI.
This commit enables that level of control.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/pinctrl/Kconfig | 2 +-
drivers/pinctrl/pinctrl-microchip-sgpio.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 257b06752747..40d243bc91f8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -292,7 +292,7 @@ config PINCTRL_MCP23S08
corresponding interrupt-controller.
config PINCTRL_MICROCHIP_SGPIO
- bool "Pinctrl driver for Microsemi/Microchip Serial GPIO"
+ tristate "Pinctrl driver for Microsemi/Microchip Serial GPIO"
depends on OF
depends on HAS_IOMEM
select GPIOLIB
diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index 6f55bf7d5e05..e56074b7e659 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -999,6 +999,7 @@ static const struct of_device_id microchip_sgpio_gpio_of_match[] = {
/* sentinel */
}
};
+MODULE_DEVICE_TABLE(of, microchip_sgpio_gpio_of_match);
static struct platform_driver microchip_sgpio_pinctrl_driver = {
.driver = {
@@ -1008,4 +1009,7 @@ static struct platform_driver microchip_sgpio_pinctrl_driver = {
},
.probe = microchip_sgpio_probe,
};
-builtin_platform_driver(microchip_sgpio_pinctrl_driver);
+module_platform_driver(microchip_sgpio_pinctrl_driver);
+
+MODULE_DESCRIPTION("Microchip SGPIO Pinctrl Driver");
+MODULE_LICENSE("GPL");
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
There are a few Ocelot chips that can contain SGPIO logic, but can be
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
drivers/pinctrl/pinctrl-microchip-sgpio.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index e56074b7e659..2b4167a09b3b 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -12,6 +12,7 @@
#include <linux/clk.h>
#include <linux/gpio/driver.h>
#include <linux/io.h>
+#include <linux/mfd/ocelot.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/pinctrl/pinmux.h>
@@ -904,7 +905,6 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
struct reset_control *reset;
struct sgpio_priv *priv;
struct clk *clk;
- u32 __iomem *regs;
u32 val;
struct regmap_config regmap_config = {
.reg_bits = 32,
@@ -937,11 +937,7 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
return -EINVAL;
}
- regs = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
-
- priv->regs = devm_regmap_init_mmio(dev, regs, ®map_config);
+ priv->regs = ocelot_regmap_from_resource(pdev, 0, ®map_config);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
There are a few Ocelot chips that can contain SGPIO logic, but can be
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
drivers/pinctrl/pinctrl-microchip-sgpio.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index e56074b7e659..2b4167a09b3b 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -12,6 +12,7 @@
#include <linux/clk.h>
#include <linux/gpio/driver.h>
#include <linux/io.h>
+#include <linux/mfd/ocelot.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/pinctrl/pinmux.h>
@@ -904,7 +905,6 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
struct reset_control *reset;
struct sgpio_priv *priv;
struct clk *clk;
- u32 __iomem *regs;
u32 val;
struct regmap_config regmap_config = {
.reg_bits = 32,
@@ -937,11 +937,7 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
return -EINVAL;
}
- regs = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
-
- priv->regs = devm_regmap_init_mmio(dev, regs, ®map_config);
+ priv->regs = ocelot_regmap_from_resource(pdev, 0, ®map_config);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 7/9] resource: add define macro for register address resources
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
DEFINE_RES_ macros have been created for the commonly used resource types,
but not IORESOURCE_REG. Add the macro so it can be used in a similar manner
to all other resource types.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
include/linux/ioport.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index ec5f71f7135b..b0d09b6f2ecf 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -171,6 +171,11 @@ enum {
#define DEFINE_RES_MEM(_start, _size) \
DEFINE_RES_MEM_NAMED((_start), (_size), NULL)
+#define DEFINE_RES_REG_NAMED(_start, _size, _name) \
+ DEFINE_RES_NAMED((_start), (_size), (_name), IORESOURCE_REG)
+#define DEFINE_RES_REG(_start, _size) \
+ DEFINE_RES_REG_NAMED((_start), (_size), NULL)
+
#define DEFINE_RES_IRQ_NAMED(_irq, _name) \
DEFINE_RES_NAMED((_irq), 1, (_name), IORESOURCE_IRQ)
#define DEFINE_RES_IRQ(_irq) \
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 7/9] resource: add define macro for register address resources
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
DEFINE_RES_ macros have been created for the commonly used resource types,
but not IORESOURCE_REG. Add the macro so it can be used in a similar manner
to all other resource types.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
include/linux/ioport.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index ec5f71f7135b..b0d09b6f2ecf 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -171,6 +171,11 @@ enum {
#define DEFINE_RES_MEM(_start, _size) \
DEFINE_RES_MEM_NAMED((_start), (_size), NULL)
+#define DEFINE_RES_REG_NAMED(_start, _size, _name) \
+ DEFINE_RES_NAMED((_start), (_size), (_name), IORESOURCE_REG)
+#define DEFINE_RES_REG(_start, _size) \
+ DEFINE_RES_REG_NAMED((_start), (_size), NULL)
+
#define DEFINE_RES_IRQ_NAMED(_irq, _name) \
DEFINE_RES_NAMED((_irq), 1, (_name), IORESOURCE_IRQ)
#define DEFINE_RES_IRQ(_irq) \
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
Add devicetree bindings for SPI-controlled Ocelot chips, specifically the
VSC7512.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
.../devicetree/bindings/mfd/mscc,ocelot.yaml | 160 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 161 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
new file mode 100644
index 000000000000..8bf45a5673a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mscc,ocelot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ocelot Externally-Controlled Ethernet Switch
+
+maintainers:
+ - Colin Foster <colin.foster@in-advantage.com>
+
+description: |
+ The Ocelot ethernet switch family contains chips that have an internal CPU
+ (VSC7513, VSC7514) and chips that don't (VSC7511, VSC7512). All switches have
+ the option to be controlled externally, which is the purpose of this driver.
+
+ The switch family is a multi-port networking switch that supports many
+ interfaces. Additionally, the device can perform pin control, MDIO buses, and
+ external GPIO expanders.
+
+properties:
+ compatible:
+ enum:
+ - mscc,vsc7512
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ spi-max-frequency:
+ maxItems: 1
+
+patternProperties:
+ "^pinctrl@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/mscc,ocelot-pinctrl.yaml
+
+ "^gpio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/microchip,sparx5-sgpio.yaml
+ properties:
+ compatible:
+ enum:
+ - mscc,ocelot-sgpio
+
+ "^mdio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/net/mscc,miim.yaml
+ properties:
+ compatible:
+ enum:
+ - mscc,ocelot-miim
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+ - spi-max-frequency
+
+additionalProperties: false
+
+examples:
+ - |
+ ocelot_clock: ocelot-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ soc@0 {
+ compatible = "mscc,vsc7512";
+ spi-max-frequency = <2500000>;
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mdio@7107009c {
+ compatible = "mscc,ocelot-miim";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x7107009c 0x24>;
+
+ sw_phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+ };
+
+ mdio@710700c0 {
+ compatible = "mscc,ocelot-miim";
+ pinctrl-names = "default";
+ pinctrl-0 = <&miim1_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x710700c0 0x24>;
+
+ sw_phy4: ethernet-phy@4 {
+ reg = <0x4>;
+ };
+ };
+
+ gpio: pinctrl@71070034 {
+ compatible = "mscc,ocelot-pinctrl";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&gpio 0 0 22>;
+ reg = <0x71070034 0x6c>;
+
+ sgpio_pins: sgpio-pins {
+ pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
+ function = "sg0";
+ };
+
+ miim1_pins: miim1-pins {
+ pins = "GPIO_14", "GPIO_15";
+ function = "miim";
+ };
+ };
+
+ gpio@710700f8 {
+ compatible = "mscc,ocelot-sgpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-frequency = <12500000>;
+ clocks = <&ocelot_clock>;
+ microchip,sgpio-port-ranges = <0 15>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sgpio_pins>;
+ reg = <0x710700f8 0x100>;
+
+ sgpio_in0: gpio@0 {
+ compatible = "microchip,sparx5-sgpio-bank";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <64>;
+ };
+
+ sgpio_out1: gpio@1 {
+ compatible = "microchip,sparx5-sgpio-bank";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <64>;
+ };
+ };
+ };
+ };
+
+...
+
diff --git a/MAINTAINERS b/MAINTAINERS
index c2f61ed1b730..a67828cbda20 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14416,6 +14416,7 @@ F: tools/testing/selftests/drivers/net/ocelot/*
OCELOT EXTERNAL SWITCH CONTROL
M: Colin Foster <colin.foster@in-advantage.com>
S: Supported
+F: Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
F: include/linux/mfd/ocelot.h
OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
Add devicetree bindings for SPI-controlled Ocelot chips, specifically the
VSC7512.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
.../devicetree/bindings/mfd/mscc,ocelot.yaml | 160 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 161 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
new file mode 100644
index 000000000000..8bf45a5673a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mscc,ocelot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ocelot Externally-Controlled Ethernet Switch
+
+maintainers:
+ - Colin Foster <colin.foster@in-advantage.com>
+
+description: |
+ The Ocelot ethernet switch family contains chips that have an internal CPU
+ (VSC7513, VSC7514) and chips that don't (VSC7511, VSC7512). All switches have
+ the option to be controlled externally, which is the purpose of this driver.
+
+ The switch family is a multi-port networking switch that supports many
+ interfaces. Additionally, the device can perform pin control, MDIO buses, and
+ external GPIO expanders.
+
+properties:
+ compatible:
+ enum:
+ - mscc,vsc7512
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ spi-max-frequency:
+ maxItems: 1
+
+patternProperties:
+ "^pinctrl@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/mscc,ocelot-pinctrl.yaml
+
+ "^gpio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/microchip,sparx5-sgpio.yaml
+ properties:
+ compatible:
+ enum:
+ - mscc,ocelot-sgpio
+
+ "^mdio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/net/mscc,miim.yaml
+ properties:
+ compatible:
+ enum:
+ - mscc,ocelot-miim
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+ - spi-max-frequency
+
+additionalProperties: false
+
+examples:
+ - |
+ ocelot_clock: ocelot-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ soc@0 {
+ compatible = "mscc,vsc7512";
+ spi-max-frequency = <2500000>;
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mdio@7107009c {
+ compatible = "mscc,ocelot-miim";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x7107009c 0x24>;
+
+ sw_phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+ };
+
+ mdio@710700c0 {
+ compatible = "mscc,ocelot-miim";
+ pinctrl-names = "default";
+ pinctrl-0 = <&miim1_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x710700c0 0x24>;
+
+ sw_phy4: ethernet-phy@4 {
+ reg = <0x4>;
+ };
+ };
+
+ gpio: pinctrl@71070034 {
+ compatible = "mscc,ocelot-pinctrl";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&gpio 0 0 22>;
+ reg = <0x71070034 0x6c>;
+
+ sgpio_pins: sgpio-pins {
+ pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
+ function = "sg0";
+ };
+
+ miim1_pins: miim1-pins {
+ pins = "GPIO_14", "GPIO_15";
+ function = "miim";
+ };
+ };
+
+ gpio@710700f8 {
+ compatible = "mscc,ocelot-sgpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-frequency = <12500000>;
+ clocks = <&ocelot_clock>;
+ microchip,sgpio-port-ranges = <0 15>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sgpio_pins>;
+ reg = <0x710700f8 0x100>;
+
+ sgpio_in0: gpio@0 {
+ compatible = "microchip,sparx5-sgpio-bank";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <64>;
+ };
+
+ sgpio_out1: gpio@1 {
+ compatible = "microchip,sparx5-sgpio-bank";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <64>;
+ };
+ };
+ };
+ };
+
+...
+
diff --git a/MAINTAINERS b/MAINTAINERS
index c2f61ed1b730..a67828cbda20 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14416,6 +14416,7 @@ F: tools/testing/selftests/drivers/net/ocelot/*
OCELOT EXTERNAL SWITCH CONTROL
M: Colin Foster <colin.foster@in-advantage.com>
S: Supported
+F: Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
F: include/linux/mfd/ocelot.h
OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 19:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
MAINTAINERS | 1 +
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 ++++
6 files changed, 525 insertions(+)
create mode 100644 drivers/mfd/ocelot-core.c
create mode 100644 drivers/mfd/ocelot-spi.c
create mode 100644 drivers/mfd/ocelot.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a67828cbda20..3ce2853e01a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14417,6 +14417,7 @@ OCELOT EXTERNAL SWITCH CONTROL
M: Colin Foster <colin.foster@in-advantage.com>
S: Supported
F: Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
+F: drivers/mfd/ocelot*
F: include/linux/mfd/ocelot.h
OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3b59456f5545..21da9a92c2a8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -962,6 +962,24 @@ config MFD_MENF21BMC
This driver can also be built as a module. If so the module
will be called menf21bmc.
+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.
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 858cacf659d6..bc517632ba5f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -120,6 +120,8 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
obj-$(CONFIG_MFD_CORE) += mfd-core.o
+obj-$(CONFIG_MFD_OCELOT) += ocelot-core.o ocelot-spi.o
+
obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
obj-$(CONFIG_MFD_CPCAP) += motorola-cpcap.o
diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
new file mode 100644
index 000000000000..abb7b5034032
--- /dev/null
+++ b/drivers/mfd/ocelot-core.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Core driver for the Ocelot chip family.
+ *
+ * The VSC7511, 7512, 7513, and 7514 can be controlled internally via an
+ * on-chip MIPS processor, or externally via SPI, I2C, PCIe. This core driver is
+ * intended to be the bus-agnostic glue between, for example, the SPI bus and
+ * the child devices.
+ *
+ * Copyright 2021, 2022 Innovative Advantage Inc.
+ *
+ * Author: Colin Foster <colin.foster@in-advantage.com>
+ */
+
+#include <linux/mfd/core.h>
+#include <linux/mfd/ocelot.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <soc/mscc/ocelot.h>
+
+#include "ocelot.h"
+
+#define GCB_SOFT_RST 0x0008
+
+#define SOFT_CHIP_RST 0x1
+
+#define VSC7512_MIIM0_RES_START 0x7107009c
+#define VSC7512_MIIM0_RES_SIZE 0x24
+
+#define VSC7512_MIIM1_RES_START 0x710700c0
+#define VSC7512_MIIM1_RES_SIZE 0x24
+
+#define VSC7512_PHY_RES_START 0x710700f0
+#define VSC7512_PHY_RES_SIZE 0x4
+
+#define VSC7512_GPIO_RES_START 0x71070034
+#define VSC7512_GPIO_RES_SIZE 0x6c
+
+#define VSC7512_SIO_CTRL_RES_START 0x710700f8
+#define VSC7512_SIO_CTRL_RES_SIZE 0x100
+
+#define VSC7512_GCB_RST_SLEEP 100
+#define VSC7512_GCB_RST_TIMEOUT 100000
+
+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;
+
+ return val;
+}
+
+int ocelot_chip_reset(struct device *dev)
+{
+ struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+ int ret, val;
+
+ /*
+ * Reset the entire chip here to put it into a completely known state.
+ * Other drivers may want to reset their own subsystems. The register
+ * self-clears, so one write is all that is needed and wait for it to
+ * clear.
+ */
+ ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
+ if (ret)
+ return ret;
+
+ ret = readx_poll_timeout(ocelot_gcb_chip_rst_status, ddata, val, !val,
+ VSC7512_GCB_RST_SLEEP,
+ VSC7512_GCB_RST_TIMEOUT);
+ if (ret)
+ return dev_err_probe(ddata->dev, ret, "timeout: chip reset\n");
+
+ return 0;
+}
+EXPORT_SYMBOL_NS(ocelot_chip_reset, MFD_OCELOT);
+
+static const struct resource vsc7512_miim0_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_MIIM0_RES_START, VSC7512_MIIM0_RES_SIZE,
+ "gcb_miim0"),
+ DEFINE_RES_REG_NAMED(VSC7512_PHY_RES_START, VSC7512_PHY_RES_SIZE,
+ "gcb_phy"),
+};
+
+static const struct resource vsc7512_miim1_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_MIIM1_RES_START, VSC7512_MIIM1_RES_SIZE,
+ "gcb_miim1"),
+};
+
+static const struct resource vsc7512_pinctrl_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_GPIO_RES_START, VSC7512_GPIO_RES_SIZE,
+ "gcb_gpio"),
+};
+
+static const struct resource vsc7512_sgpio_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_SIO_CTRL_RES_START,
+ VSC7512_SIO_CTRL_RES_SIZE,
+ "gcb_sio"),
+};
+
+static const struct mfd_cell vsc7512_devs[] = {
+ {
+ .name = "ocelot-pinctrl",
+ .of_compatible = "mscc,ocelot-pinctrl",
+ .num_resources = ARRAY_SIZE(vsc7512_pinctrl_resources),
+ .resources = vsc7512_pinctrl_resources,
+ }, {
+ .name = "ocelot-sgpio",
+ .of_compatible = "mscc,ocelot-sgpio",
+ .num_resources = ARRAY_SIZE(vsc7512_sgpio_resources),
+ .resources = vsc7512_sgpio_resources,
+ }, {
+ .name = "ocelot-miim0",
+ .of_compatible = "mscc,ocelot-miim",
+ .of_reg = VSC7512_MIIM0_RES_START,
+ .use_of_reg = true,
+ .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
+ .resources = vsc7512_miim0_resources,
+ }, {
+ .name = "ocelot-miim1",
+ .of_compatible = "mscc,ocelot-miim",
+ .of_reg = VSC7512_MIIM1_RES_START,
+ .use_of_reg = true,
+ .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
+ .resources = vsc7512_miim1_resources,
+ },
+};
+
+static void ocelot_core_try_add_regmap(struct device *dev,
+ const struct resource *res)
+{
+ if (!dev_get_regmap(dev, res->name))
+ ocelot_spi_init_regmap(dev, res);
+}
+
+static void ocelot_core_try_add_regmaps(struct device *dev,
+ const struct mfd_cell *cell)
+{
+ int i;
+
+ for (i = 0; i < cell->num_resources; i++)
+ ocelot_core_try_add_regmap(dev, &cell->resources[i]);
+}
+
+int ocelot_core_init(struct device *dev)
+{
+ int i, ndevs;
+
+ ndevs = ARRAY_SIZE(vsc7512_devs);
+
+ for (i = 0; i < ndevs; i++)
+ ocelot_core_try_add_regmaps(dev, &vsc7512_devs[i]);
+
+ return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
+ ndevs, NULL, 0, NULL);
+}
+EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
+
+MODULE_DESCRIPTION("Externally Controlled Ocelot Chip Driver");
+MODULE_AUTHOR("Colin Foster <colin.foster@in-advantage.com>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/ocelot-spi.c b/drivers/mfd/ocelot-spi.c
new file mode 100644
index 000000000000..dd57f01db25c
--- /dev/null
+++ b/drivers/mfd/ocelot-spi.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * SPI core driver for the Ocelot chip family.
+ *
+ * This driver will handle everything necessary to allow for communication over
+ * SPI to the VSC7511, VSC7512, VSC7513 and VSC7514 chips. The main functions
+ * are to prepare the chip's SPI interface for a specific bus speed, and a host
+ * processor's endianness. This will create and distribute regmaps for any
+ * children.
+ *
+ * Copyright 2021, 2022 Innovative Advantage Inc.
+ *
+ * Author: Colin Foster <colin.foster@in-advantage.com>
+ */
+
+#include <linux/iopoll.h>
+#include <linux/kconfig.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/spi/spi.h>
+
+#include <asm/byteorder.h>
+
+#include "ocelot.h"
+
+#define DEV_CPUORG_IF_CTRL 0x0000
+#define DEV_CPUORG_IF_CFGSTAT 0x0004
+
+#define CFGSTAT_IF_NUM_VCORE (0 << 24)
+#define CFGSTAT_IF_NUM_VRAP (1 << 24)
+#define CFGSTAT_IF_NUM_SI (2 << 24)
+#define CFGSTAT_IF_NUM_MIIM (3 << 24)
+
+#define VSC7512_DEVCPU_ORG_RES_START 0x71000000
+#define VSC7512_DEVCPU_ORG_RES_SIZE 0x38
+
+#define VSC7512_CHIP_REGS_RES_START 0x71070000
+#define VSC7512_CHIP_REGS_RES_SIZE 0x14
+
+static const struct resource vsc7512_dev_cpuorg_resource =
+ DEFINE_RES_REG_NAMED(VSC7512_DEVCPU_ORG_RES_START,
+ VSC7512_DEVCPU_ORG_RES_SIZE,
+ "devcpu_org");
+
+static const struct resource vsc7512_gcb_resource =
+ DEFINE_RES_REG_NAMED(VSC7512_CHIP_REGS_RES_START,
+ VSC7512_CHIP_REGS_RES_SIZE,
+ "devcpu_gcb_chip_regs");
+
+static int ocelot_spi_initialize(struct device *dev)
+{
+ struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+ u32 val, check;
+ int err;
+
+ val = OCELOT_SPI_BYTE_ORDER;
+
+ /*
+ * The SPI address must be big-endian, but we want the payload to match
+ * our CPU. These are two bits (0 and 1) but they're repeated such that
+ * the write from any configuration will be valid. The four
+ * configurations are:
+ *
+ * 0b00: little-endian, MSB first
+ * | 111111 | 22221111 | 33222222 |
+ * | 76543210 | 54321098 | 32109876 | 10987654 |
+ *
+ * 0b01: big-endian, MSB first
+ * | 33222222 | 22221111 | 111111 | |
+ * | 10987654 | 32109876 | 54321098 | 76543210 |
+ *
+ * 0b10: little-endian, LSB first
+ * | 111111 | 11112222 | 22222233 |
+ * | 01234567 | 89012345 | 67890123 | 45678901 |
+ *
+ * 0b11: big-endian, LSB first
+ * | 22222233 | 11112222 | 111111 | |
+ * | 45678901 | 67890123 | 89012345 | 01234567 |
+ */
+ err = regmap_write(ddata->cpuorg_regmap, DEV_CPUORG_IF_CTRL, val);
+ if (err)
+ return err;
+
+ /*
+ * Apply the number of padding bytes between a read request and the data
+ * payload. Some registers have access times of up to 1us, so if the
+ * first payload bit is shifted out too quickly, the read will fail.
+ */
+ val = ddata->spi_padding_bytes;
+ err = regmap_write(ddata->cpuorg_regmap, DEV_CPUORG_IF_CFGSTAT, val);
+ if (err)
+ return err;
+
+ /*
+ * After we write the interface configuration, read it back here. This
+ * will verify several different things. The first is that the number of
+ * padding bytes actually got written correctly. These are found in bits
+ * 0:3.
+ *
+ * The second is that bit 16 is cleared. Bit 16 is IF_CFGSTAT:IF_STAT,
+ * and will be set if the register access is too fast. This would be in
+ * the condition that the number of padding bytes is insufficient for
+ * the SPI bus frequency.
+ *
+ * The last check is for bits 31:24, which define the interface by which
+ * the registers are being accessed. Since we're accessing them via the
+ * serial interface, it must return IF_NUM_SI.
+ */
+ check = val | CFGSTAT_IF_NUM_SI;
+
+ err = regmap_read(ddata->cpuorg_regmap, DEV_CPUORG_IF_CFGSTAT, &val);
+ if (err)
+ return err;
+
+ if (check != val)
+ return -ENODEV;
+
+ return 0;
+}
+
+static const struct regmap_config ocelot_spi_regmap_config = {
+ .reg_bits = 24,
+ .reg_stride = 4,
+ .reg_downshift = 2,
+ .val_bits = 32,
+
+ .write_flag_mask = 0x80,
+
+ .use_single_write = true,
+ .can_multi_write = false,
+
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_NATIVE,
+};
+
+static int ocelot_spi_regmap_bus_read(void *context,
+ const void *reg, size_t reg_size,
+ void *val, size_t val_size)
+{
+ struct ocelot_ddata *ddata = context;
+ static const u8 dummy_buf[16] = {0};
+ struct spi_transfer tx, padding, rx;
+ struct spi_device *spi = ddata->spi;
+ struct spi_message msg;
+
+ spi = ddata->spi;
+
+ spi_message_init(&msg);
+
+ memset(&tx, 0, sizeof(tx));
+
+ tx.tx_buf = reg;
+ tx.len = reg_size;
+
+ spi_message_add_tail(&tx, &msg);
+
+ if (ddata->spi_padding_bytes) {
+ memset(&padding, 0, sizeof(padding));
+
+ padding.len = ddata->spi_padding_bytes;
+ padding.tx_buf = dummy_buf;
+ padding.dummy_data = 1;
+
+ spi_message_add_tail(&padding, &msg);
+ }
+
+ memset(&rx, 0, sizeof(rx));
+ rx.rx_buf = val;
+ rx.len = val_size;
+
+ spi_message_add_tail(&rx, &msg);
+
+ return spi_sync(spi, &msg);
+}
+
+static int ocelot_spi_regmap_bus_write(void *context, const void *data,
+ size_t count)
+{
+ struct ocelot_ddata *ddata = context;
+ struct spi_device *spi = ddata->spi;
+
+ return spi_write(spi, data, count);
+}
+
+static const struct regmap_bus ocelot_spi_regmap_bus = {
+ .write = ocelot_spi_regmap_bus_write,
+ .read = ocelot_spi_regmap_bus_read,
+};
+
+struct regmap *
+ocelot_spi_init_regmap(struct device *dev, const struct resource *res)
+{
+ struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+ struct regmap_config regmap_config;
+
+ memcpy(®map_config, &ocelot_spi_regmap_config,
+ sizeof(regmap_config));
+
+ regmap_config.name = res->name;
+ regmap_config.max_register = res->end - res->start;
+ regmap_config.reg_base = res->start;
+
+ return devm_regmap_init(dev, &ocelot_spi_regmap_bus, ddata,
+ ®map_config);
+}
+
+static int ocelot_spi_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct ocelot_ddata *ddata;
+ struct regmap *r;
+ int err;
+
+ ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+ if (!ddata)
+ return -ENOMEM;
+
+ ddata->dev = dev;
+ dev_set_drvdata(dev, ddata);
+
+ if (spi->max_speed_hz <= 500000) {
+ ddata->spi_padding_bytes = 0;
+ } else {
+ /*
+ * Calculation taken from the manual for IF_CFGSTAT:IF_CFG.
+ * Register access time is 1us, so we need to configure and send
+ * out enough padding bytes between the read request and data
+ * transmission that lasts at least 1 microsecond.
+ */
+ ddata->spi_padding_bytes = 1 +
+ (spi->max_speed_hz / 1000000 + 2) / 8;
+ }
+
+ ddata->spi = spi;
+
+ spi->bits_per_word = 8;
+
+ err = spi_setup(spi);
+ if (err < 0) {
+ return dev_err_probe(&spi->dev, err,
+ "Error performing SPI setup\n");
+ }
+
+ r = ocelot_spi_init_regmap(dev, &vsc7512_dev_cpuorg_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->cpuorg_regmap = r;
+
+ r = ocelot_spi_init_regmap(dev, &vsc7512_gcb_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->gcb_regmap = r;
+
+ /*
+ * The chip must be set up for SPI before it gets initialized and reset.
+ * This must be done before calling init, and after a chip reset is
+ * performed.
+ */
+ err = ocelot_spi_initialize(dev);
+ if (err)
+ return dev_err_probe(dev, err, "Error initializing SPI bus\n");
+
+ err = ocelot_chip_reset(dev);
+ if (err)
+ return dev_err_probe(dev, err, "Error resetting device\n");
+
+ /*
+ * A chip reset will clear the SPI configuration, so it needs to be done
+ * again before we can access any registers
+ */
+ err = ocelot_spi_initialize(dev);
+ if (err) {
+ return dev_err_probe(dev, err,
+ "Error initializing SPI bus after reset\n");
+ }
+
+ err = ocelot_core_init(dev);
+ if (err < 0) {
+ return dev_err_probe(dev, err,
+ "Error initializing Ocelot core\n");
+ return err;
+ }
+
+ return 0;
+}
+
+static const struct spi_device_id ocelot_spi_ids[] = {
+ { "vsc7512", 0 },
+ { }
+};
+
+static const struct of_device_id ocelot_spi_of_match[] = {
+ { .compatible = "mscc,vsc7512" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
+
+static struct spi_driver ocelot_spi_driver = {
+ .driver = {
+ .name = "ocelot_spi",
+ .of_match_table = ocelot_spi_of_match,
+ },
+ .id_table = ocelot_spi_ids,
+ .probe = ocelot_spi_probe,
+};
+module_spi_driver(ocelot_spi_driver);
+
+MODULE_DESCRIPTION("SPI Controlled Ocelot Chip Driver");
+MODULE_AUTHOR("Colin Foster <colin.foster@in-advantage.com>");
+MODULE_LICENSE("Dual MIT/GPL");
diff --git a/drivers/mfd/ocelot.h b/drivers/mfd/ocelot.h
new file mode 100644
index 000000000000..4afb628ff7e6
--- /dev/null
+++ b/drivers/mfd/ocelot.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2021, 2022 Innovative Advantage Inc. */
+
+#include <asm/byteorder.h>
+
+struct ocelot_ddata {
+ struct device *dev;
+ struct regmap *gcb_regmap;
+ struct regmap *cpuorg_regmap;
+ int spi_padding_bytes;
+ struct spi_device *spi;
+};
+
+int ocelot_chip_reset(struct device *dev);
+int ocelot_core_init(struct device *dev);
+
+/* SPI-specific routines that won't be necessary for other interfaces */
+struct regmap *ocelot_spi_init_regmap(struct device *dev,
+ const struct resource *res);
+
+#define OCELOT_SPI_BYTE_ORDER_LE 0x00000000
+#define OCELOT_SPI_BYTE_ORDER_BE 0x81818181
+
+#ifdef __LITTLE_ENDIAN
+#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_LE
+#else
+#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_BE
+#endif
--
2.25.1
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-07-01 19:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 19:26 UTC (permalink / raw)
To: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio
Cc: Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
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.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
MAINTAINERS | 1 +
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 ++++
6 files changed, 525 insertions(+)
create mode 100644 drivers/mfd/ocelot-core.c
create mode 100644 drivers/mfd/ocelot-spi.c
create mode 100644 drivers/mfd/ocelot.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a67828cbda20..3ce2853e01a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14417,6 +14417,7 @@ OCELOT EXTERNAL SWITCH CONTROL
M: Colin Foster <colin.foster@in-advantage.com>
S: Supported
F: Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
+F: drivers/mfd/ocelot*
F: include/linux/mfd/ocelot.h
OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3b59456f5545..21da9a92c2a8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -962,6 +962,24 @@ config MFD_MENF21BMC
This driver can also be built as a module. If so the module
will be called menf21bmc.
+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.
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 858cacf659d6..bc517632ba5f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -120,6 +120,8 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
obj-$(CONFIG_MFD_CORE) += mfd-core.o
+obj-$(CONFIG_MFD_OCELOT) += ocelot-core.o ocelot-spi.o
+
obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
obj-$(CONFIG_MFD_CPCAP) += motorola-cpcap.o
diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
new file mode 100644
index 000000000000..abb7b5034032
--- /dev/null
+++ b/drivers/mfd/ocelot-core.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Core driver for the Ocelot chip family.
+ *
+ * The VSC7511, 7512, 7513, and 7514 can be controlled internally via an
+ * on-chip MIPS processor, or externally via SPI, I2C, PCIe. This core driver is
+ * intended to be the bus-agnostic glue between, for example, the SPI bus and
+ * the child devices.
+ *
+ * Copyright 2021, 2022 Innovative Advantage Inc.
+ *
+ * Author: Colin Foster <colin.foster@in-advantage.com>
+ */
+
+#include <linux/mfd/core.h>
+#include <linux/mfd/ocelot.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <soc/mscc/ocelot.h>
+
+#include "ocelot.h"
+
+#define GCB_SOFT_RST 0x0008
+
+#define SOFT_CHIP_RST 0x1
+
+#define VSC7512_MIIM0_RES_START 0x7107009c
+#define VSC7512_MIIM0_RES_SIZE 0x24
+
+#define VSC7512_MIIM1_RES_START 0x710700c0
+#define VSC7512_MIIM1_RES_SIZE 0x24
+
+#define VSC7512_PHY_RES_START 0x710700f0
+#define VSC7512_PHY_RES_SIZE 0x4
+
+#define VSC7512_GPIO_RES_START 0x71070034
+#define VSC7512_GPIO_RES_SIZE 0x6c
+
+#define VSC7512_SIO_CTRL_RES_START 0x710700f8
+#define VSC7512_SIO_CTRL_RES_SIZE 0x100
+
+#define VSC7512_GCB_RST_SLEEP 100
+#define VSC7512_GCB_RST_TIMEOUT 100000
+
+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;
+
+ return val;
+}
+
+int ocelot_chip_reset(struct device *dev)
+{
+ struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+ int ret, val;
+
+ /*
+ * Reset the entire chip here to put it into a completely known state.
+ * Other drivers may want to reset their own subsystems. The register
+ * self-clears, so one write is all that is needed and wait for it to
+ * clear.
+ */
+ ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
+ if (ret)
+ return ret;
+
+ ret = readx_poll_timeout(ocelot_gcb_chip_rst_status, ddata, val, !val,
+ VSC7512_GCB_RST_SLEEP,
+ VSC7512_GCB_RST_TIMEOUT);
+ if (ret)
+ return dev_err_probe(ddata->dev, ret, "timeout: chip reset\n");
+
+ return 0;
+}
+EXPORT_SYMBOL_NS(ocelot_chip_reset, MFD_OCELOT);
+
+static const struct resource vsc7512_miim0_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_MIIM0_RES_START, VSC7512_MIIM0_RES_SIZE,
+ "gcb_miim0"),
+ DEFINE_RES_REG_NAMED(VSC7512_PHY_RES_START, VSC7512_PHY_RES_SIZE,
+ "gcb_phy"),
+};
+
+static const struct resource vsc7512_miim1_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_MIIM1_RES_START, VSC7512_MIIM1_RES_SIZE,
+ "gcb_miim1"),
+};
+
+static const struct resource vsc7512_pinctrl_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_GPIO_RES_START, VSC7512_GPIO_RES_SIZE,
+ "gcb_gpio"),
+};
+
+static const struct resource vsc7512_sgpio_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_SIO_CTRL_RES_START,
+ VSC7512_SIO_CTRL_RES_SIZE,
+ "gcb_sio"),
+};
+
+static const struct mfd_cell vsc7512_devs[] = {
+ {
+ .name = "ocelot-pinctrl",
+ .of_compatible = "mscc,ocelot-pinctrl",
+ .num_resources = ARRAY_SIZE(vsc7512_pinctrl_resources),
+ .resources = vsc7512_pinctrl_resources,
+ }, {
+ .name = "ocelot-sgpio",
+ .of_compatible = "mscc,ocelot-sgpio",
+ .num_resources = ARRAY_SIZE(vsc7512_sgpio_resources),
+ .resources = vsc7512_sgpio_resources,
+ }, {
+ .name = "ocelot-miim0",
+ .of_compatible = "mscc,ocelot-miim",
+ .of_reg = VSC7512_MIIM0_RES_START,
+ .use_of_reg = true,
+ .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
+ .resources = vsc7512_miim0_resources,
+ }, {
+ .name = "ocelot-miim1",
+ .of_compatible = "mscc,ocelot-miim",
+ .of_reg = VSC7512_MIIM1_RES_START,
+ .use_of_reg = true,
+ .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
+ .resources = vsc7512_miim1_resources,
+ },
+};
+
+static void ocelot_core_try_add_regmap(struct device *dev,
+ const struct resource *res)
+{
+ if (!dev_get_regmap(dev, res->name))
+ ocelot_spi_init_regmap(dev, res);
+}
+
+static void ocelot_core_try_add_regmaps(struct device *dev,
+ const struct mfd_cell *cell)
+{
+ int i;
+
+ for (i = 0; i < cell->num_resources; i++)
+ ocelot_core_try_add_regmap(dev, &cell->resources[i]);
+}
+
+int ocelot_core_init(struct device *dev)
+{
+ int i, ndevs;
+
+ ndevs = ARRAY_SIZE(vsc7512_devs);
+
+ for (i = 0; i < ndevs; i++)
+ ocelot_core_try_add_regmaps(dev, &vsc7512_devs[i]);
+
+ return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
+ ndevs, NULL, 0, NULL);
+}
+EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
+
+MODULE_DESCRIPTION("Externally Controlled Ocelot Chip Driver");
+MODULE_AUTHOR("Colin Foster <colin.foster@in-advantage.com>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/ocelot-spi.c b/drivers/mfd/ocelot-spi.c
new file mode 100644
index 000000000000..dd57f01db25c
--- /dev/null
+++ b/drivers/mfd/ocelot-spi.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * SPI core driver for the Ocelot chip family.
+ *
+ * This driver will handle everything necessary to allow for communication over
+ * SPI to the VSC7511, VSC7512, VSC7513 and VSC7514 chips. The main functions
+ * are to prepare the chip's SPI interface for a specific bus speed, and a host
+ * processor's endianness. This will create and distribute regmaps for any
+ * children.
+ *
+ * Copyright 2021, 2022 Innovative Advantage Inc.
+ *
+ * Author: Colin Foster <colin.foster@in-advantage.com>
+ */
+
+#include <linux/iopoll.h>
+#include <linux/kconfig.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/spi/spi.h>
+
+#include <asm/byteorder.h>
+
+#include "ocelot.h"
+
+#define DEV_CPUORG_IF_CTRL 0x0000
+#define DEV_CPUORG_IF_CFGSTAT 0x0004
+
+#define CFGSTAT_IF_NUM_VCORE (0 << 24)
+#define CFGSTAT_IF_NUM_VRAP (1 << 24)
+#define CFGSTAT_IF_NUM_SI (2 << 24)
+#define CFGSTAT_IF_NUM_MIIM (3 << 24)
+
+#define VSC7512_DEVCPU_ORG_RES_START 0x71000000
+#define VSC7512_DEVCPU_ORG_RES_SIZE 0x38
+
+#define VSC7512_CHIP_REGS_RES_START 0x71070000
+#define VSC7512_CHIP_REGS_RES_SIZE 0x14
+
+static const struct resource vsc7512_dev_cpuorg_resource =
+ DEFINE_RES_REG_NAMED(VSC7512_DEVCPU_ORG_RES_START,
+ VSC7512_DEVCPU_ORG_RES_SIZE,
+ "devcpu_org");
+
+static const struct resource vsc7512_gcb_resource =
+ DEFINE_RES_REG_NAMED(VSC7512_CHIP_REGS_RES_START,
+ VSC7512_CHIP_REGS_RES_SIZE,
+ "devcpu_gcb_chip_regs");
+
+static int ocelot_spi_initialize(struct device *dev)
+{
+ struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+ u32 val, check;
+ int err;
+
+ val = OCELOT_SPI_BYTE_ORDER;
+
+ /*
+ * The SPI address must be big-endian, but we want the payload to match
+ * our CPU. These are two bits (0 and 1) but they're repeated such that
+ * the write from any configuration will be valid. The four
+ * configurations are:
+ *
+ * 0b00: little-endian, MSB first
+ * | 111111 | 22221111 | 33222222 |
+ * | 76543210 | 54321098 | 32109876 | 10987654 |
+ *
+ * 0b01: big-endian, MSB first
+ * | 33222222 | 22221111 | 111111 | |
+ * | 10987654 | 32109876 | 54321098 | 76543210 |
+ *
+ * 0b10: little-endian, LSB first
+ * | 111111 | 11112222 | 22222233 |
+ * | 01234567 | 89012345 | 67890123 | 45678901 |
+ *
+ * 0b11: big-endian, LSB first
+ * | 22222233 | 11112222 | 111111 | |
+ * | 45678901 | 67890123 | 89012345 | 01234567 |
+ */
+ err = regmap_write(ddata->cpuorg_regmap, DEV_CPUORG_IF_CTRL, val);
+ if (err)
+ return err;
+
+ /*
+ * Apply the number of padding bytes between a read request and the data
+ * payload. Some registers have access times of up to 1us, so if the
+ * first payload bit is shifted out too quickly, the read will fail.
+ */
+ val = ddata->spi_padding_bytes;
+ err = regmap_write(ddata->cpuorg_regmap, DEV_CPUORG_IF_CFGSTAT, val);
+ if (err)
+ return err;
+
+ /*
+ * After we write the interface configuration, read it back here. This
+ * will verify several different things. The first is that the number of
+ * padding bytes actually got written correctly. These are found in bits
+ * 0:3.
+ *
+ * The second is that bit 16 is cleared. Bit 16 is IF_CFGSTAT:IF_STAT,
+ * and will be set if the register access is too fast. This would be in
+ * the condition that the number of padding bytes is insufficient for
+ * the SPI bus frequency.
+ *
+ * The last check is for bits 31:24, which define the interface by which
+ * the registers are being accessed. Since we're accessing them via the
+ * serial interface, it must return IF_NUM_SI.
+ */
+ check = val | CFGSTAT_IF_NUM_SI;
+
+ err = regmap_read(ddata->cpuorg_regmap, DEV_CPUORG_IF_CFGSTAT, &val);
+ if (err)
+ return err;
+
+ if (check != val)
+ return -ENODEV;
+
+ return 0;
+}
+
+static const struct regmap_config ocelot_spi_regmap_config = {
+ .reg_bits = 24,
+ .reg_stride = 4,
+ .reg_downshift = 2,
+ .val_bits = 32,
+
+ .write_flag_mask = 0x80,
+
+ .use_single_write = true,
+ .can_multi_write = false,
+
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .val_format_endian = REGMAP_ENDIAN_NATIVE,
+};
+
+static int ocelot_spi_regmap_bus_read(void *context,
+ const void *reg, size_t reg_size,
+ void *val, size_t val_size)
+{
+ struct ocelot_ddata *ddata = context;
+ static const u8 dummy_buf[16] = {0};
+ struct spi_transfer tx, padding, rx;
+ struct spi_device *spi = ddata->spi;
+ struct spi_message msg;
+
+ spi = ddata->spi;
+
+ spi_message_init(&msg);
+
+ memset(&tx, 0, sizeof(tx));
+
+ tx.tx_buf = reg;
+ tx.len = reg_size;
+
+ spi_message_add_tail(&tx, &msg);
+
+ if (ddata->spi_padding_bytes) {
+ memset(&padding, 0, sizeof(padding));
+
+ padding.len = ddata->spi_padding_bytes;
+ padding.tx_buf = dummy_buf;
+ padding.dummy_data = 1;
+
+ spi_message_add_tail(&padding, &msg);
+ }
+
+ memset(&rx, 0, sizeof(rx));
+ rx.rx_buf = val;
+ rx.len = val_size;
+
+ spi_message_add_tail(&rx, &msg);
+
+ return spi_sync(spi, &msg);
+}
+
+static int ocelot_spi_regmap_bus_write(void *context, const void *data,
+ size_t count)
+{
+ struct ocelot_ddata *ddata = context;
+ struct spi_device *spi = ddata->spi;
+
+ return spi_write(spi, data, count);
+}
+
+static const struct regmap_bus ocelot_spi_regmap_bus = {
+ .write = ocelot_spi_regmap_bus_write,
+ .read = ocelot_spi_regmap_bus_read,
+};
+
+struct regmap *
+ocelot_spi_init_regmap(struct device *dev, const struct resource *res)
+{
+ struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+ struct regmap_config regmap_config;
+
+ memcpy(®map_config, &ocelot_spi_regmap_config,
+ sizeof(regmap_config));
+
+ regmap_config.name = res->name;
+ regmap_config.max_register = res->end - res->start;
+ regmap_config.reg_base = res->start;
+
+ return devm_regmap_init(dev, &ocelot_spi_regmap_bus, ddata,
+ ®map_config);
+}
+
+static int ocelot_spi_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct ocelot_ddata *ddata;
+ struct regmap *r;
+ int err;
+
+ ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+ if (!ddata)
+ return -ENOMEM;
+
+ ddata->dev = dev;
+ dev_set_drvdata(dev, ddata);
+
+ if (spi->max_speed_hz <= 500000) {
+ ddata->spi_padding_bytes = 0;
+ } else {
+ /*
+ * Calculation taken from the manual for IF_CFGSTAT:IF_CFG.
+ * Register access time is 1us, so we need to configure and send
+ * out enough padding bytes between the read request and data
+ * transmission that lasts at least 1 microsecond.
+ */
+ ddata->spi_padding_bytes = 1 +
+ (spi->max_speed_hz / 1000000 + 2) / 8;
+ }
+
+ ddata->spi = spi;
+
+ spi->bits_per_word = 8;
+
+ err = spi_setup(spi);
+ if (err < 0) {
+ return dev_err_probe(&spi->dev, err,
+ "Error performing SPI setup\n");
+ }
+
+ r = ocelot_spi_init_regmap(dev, &vsc7512_dev_cpuorg_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->cpuorg_regmap = r;
+
+ r = ocelot_spi_init_regmap(dev, &vsc7512_gcb_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->gcb_regmap = r;
+
+ /*
+ * The chip must be set up for SPI before it gets initialized and reset.
+ * This must be done before calling init, and after a chip reset is
+ * performed.
+ */
+ err = ocelot_spi_initialize(dev);
+ if (err)
+ return dev_err_probe(dev, err, "Error initializing SPI bus\n");
+
+ err = ocelot_chip_reset(dev);
+ if (err)
+ return dev_err_probe(dev, err, "Error resetting device\n");
+
+ /*
+ * A chip reset will clear the SPI configuration, so it needs to be done
+ * again before we can access any registers
+ */
+ err = ocelot_spi_initialize(dev);
+ if (err) {
+ return dev_err_probe(dev, err,
+ "Error initializing SPI bus after reset\n");
+ }
+
+ err = ocelot_core_init(dev);
+ if (err < 0) {
+ return dev_err_probe(dev, err,
+ "Error initializing Ocelot core\n");
+ return err;
+ }
+
+ return 0;
+}
+
+static const struct spi_device_id ocelot_spi_ids[] = {
+ { "vsc7512", 0 },
+ { }
+};
+
+static const struct of_device_id ocelot_spi_of_match[] = {
+ { .compatible = "mscc,vsc7512" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
+
+static struct spi_driver ocelot_spi_driver = {
+ .driver = {
+ .name = "ocelot_spi",
+ .of_match_table = ocelot_spi_of_match,
+ },
+ .id_table = ocelot_spi_ids,
+ .probe = ocelot_spi_probe,
+};
+module_spi_driver(ocelot_spi_driver);
+
+MODULE_DESCRIPTION("SPI Controlled Ocelot Chip Driver");
+MODULE_AUTHOR("Colin Foster <colin.foster@in-advantage.com>");
+MODULE_LICENSE("Dual MIT/GPL");
diff --git a/drivers/mfd/ocelot.h b/drivers/mfd/ocelot.h
new file mode 100644
index 000000000000..4afb628ff7e6
--- /dev/null
+++ b/drivers/mfd/ocelot.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2021, 2022 Innovative Advantage Inc. */
+
+#include <asm/byteorder.h>
+
+struct ocelot_ddata {
+ struct device *dev;
+ struct regmap *gcb_regmap;
+ struct regmap *cpuorg_regmap;
+ int spi_padding_bytes;
+ struct spi_device *spi;
+};
+
+int ocelot_chip_reset(struct device *dev);
+int ocelot_core_init(struct device *dev);
+
+/* SPI-specific routines that won't be necessary for other interfaces */
+struct regmap *ocelot_spi_init_regmap(struct device *dev,
+ const struct resource *res);
+
+#define OCELOT_SPI_BYTE_ORDER_LE 0x00000000
+#define OCELOT_SPI_BYTE_ORDER_BE 0x81818181
+
+#ifdef __LITTLE_ENDIAN
+#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_LE
+#else
+#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_BE
+#endif
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 20:23 ` Andy Shevchenko
-1 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:23 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-01 20:23 ` Andy Shevchenko
0 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:23 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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);
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 20:24 ` Andy Shevchenko
-1 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:24 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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(...); ?
> }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-07-01 20:24 ` Andy Shevchenko
0 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:24 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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(...); ?
> }
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-07-01 20:23 ` Andy Shevchenko
@ 2022-07-01 20:34 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 20:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-01 20:34 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 20:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
2022-07-01 20:24 ` Andy Shevchenko
@ 2022-07-01 20:38 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 20:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-07-01 20:38 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 20:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-07-01 19:26 ` Colin Foster
@ 2022-07-01 20:38 ` Andy Shevchenko
-1 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:38 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-07-01 20:38 ` Andy Shevchenko
0 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:38 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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;
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-07-01 20:34 ` Colin Foster
@ 2022-07-01 20:41 ` Andy Shevchenko
-1 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:41 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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".
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-01 20:41 ` Andy Shevchenko
0 siblings, 0 replies; 52+ messages in thread
From: Andy Shevchenko @ 2022-07-01 20:41 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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".
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-07-01 20:38 ` Andy Shevchenko
@ 2022-07-01 21:04 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 21:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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!
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-07-01 21:04 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-01 21:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Linus Walleij,
Wolfram Sang, Terry Bowman, katie.morris
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!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-07-01 19:26 ` Colin Foster
@ 2022-07-02 3:02 ` Jakub Kicinski
-1 siblings, 0 replies; 52+ messages in thread
From: Jakub Kicinski @ 2022-07-02 3:02 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-07-02 3:02 ` Jakub Kicinski
0 siblings, 0 replies; 52+ messages in thread
From: Jakub Kicinski @ 2022-07-02 3:02 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-07-01 19:26 ` Colin Foster
@ 2022-07-02 10:04 ` kernel test robot
-1 siblings, 0 replies; 52+ messages in thread
From: kernel test robot @ 2022-07-02 10:04 UTC (permalink / raw)
To: Colin Foster, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio
Cc: kbuild-all, Vladimir Oltean, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Andrew Lunn, Heiner Kallweit, Russell King,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
Hi Colin,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Colin-Foster/add-support-for-VSC7512-control-over-SPI/20220702-032824
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git dbdd9a28e1406ab8218a69e60f10a168b968c81d
config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20220702/202207021703.v9TWwjUK-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/86c3be9af85a12a7b190790d80944693dd07a132
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Colin-Foster/add-support-for-VSC7512-control-over-SPI/20220702-032824
git checkout 86c3be9af85a12a7b190790d80944693dd07a132
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> 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.
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-07-02 10:04 ` kernel test robot
0 siblings, 0 replies; 52+ messages in thread
From: kernel test robot @ 2022-07-02 10:04 UTC (permalink / raw)
To: Colin Foster, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio
Cc: kbuild-all, Vladimir Oltean, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Andrew Lunn, Heiner Kallweit, Russell King,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko, katie.morris
Hi Colin,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Colin-Foster/add-support-for-VSC7512-control-over-SPI/20220702-032824
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git dbdd9a28e1406ab8218a69e60f10a168b968c81d
config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20220702/202207021703.v9TWwjUK-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/86c3be9af85a12a7b190790d80944693dd07a132
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Colin-Foster/add-support-for-VSC7512-control-over-SPI/20220702-032824
git checkout 86c3be9af85a12a7b190790d80944693dd07a132
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> 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.
--
0-DAY CI Kernel Test Service
https://01.org/lkp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-07-02 3:02 ` Jakub Kicinski
@ 2022-07-02 16:26 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-02 16:26 UTC (permalink / raw)
To: Jakub Kicinski
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-07-02 16:26 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-02 16:26 UTC (permalink / raw)
To: Jakub Kicinski
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
2022-07-01 19:26 ` Colin Foster
@ 2022-07-05 20:24 ` Rob Herring
-1 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2022-07-05 20:24 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-07-05 20:24 ` Rob Herring
0 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2022-07-05 20:24 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
2022-07-01 19:26 ` Colin Foster
@ 2022-07-05 20:26 ` Rob Herring
-1 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2022-07-05 20:26 UTC (permalink / raw)
To: Colin Foster
Cc: Rob Herring, Lee Jones, Krzysztof Kozlowski, Andy Shevchenko,
Linus Walleij, Russell King, Vladimir Oltean, linux-arm-kernel,
Jakub Kicinski, Steen Hegelund, David S. Miller, Lars Povlsen,
linux-gpio, devicetree, netdev, linux-kernel, Paolo Abeni,
katie.morris, Wolfram Sang, Terry Bowman, UNGLinuxDriver,
Heiner Kallweit, Andrew Lunn, Eric Dumazet
On Fri, 01 Jul 2022 12:26:08 -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>
> ---
> .../devicetree/bindings/mfd/mscc,ocelot.yaml | 160 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 161 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
@ 2022-07-05 20:26 ` Rob Herring
0 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2022-07-05 20:26 UTC (permalink / raw)
To: Colin Foster
Cc: Rob Herring, Lee Jones, Krzysztof Kozlowski, Andy Shevchenko,
Linus Walleij, Russell King, Vladimir Oltean, linux-arm-kernel,
Jakub Kicinski, Steen Hegelund, David S. Miller, Lars Povlsen,
linux-gpio, devicetree, netdev, linux-kernel, Paolo Abeni,
katie.morris, Wolfram Sang, Terry Bowman, UNGLinuxDriver,
Heiner Kallweit, Andrew Lunn, Eric Dumazet
On Fri, 01 Jul 2022 12:26:08 -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>
> ---
> .../devicetree/bindings/mfd/mscc,ocelot.yaml | 160 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 161 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
2022-07-05 20:24 ` Rob Herring
@ 2022-07-05 20:30 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-05 20:30 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-07-05 20:30 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-05 20:30 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
Vladimir Oltean, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
2022-07-05 20:30 ` Colin Foster
@ 2022-07-05 22:04 ` Vladimir Oltean
-1 siblings, 0 replies; 52+ messages in thread
From: Vladimir Oltean @ 2022-07-05 22:04 UTC (permalink / raw)
To: Colin Foster
Cc: Rob Herring, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-07-05 22:04 ` Vladimir Oltean
0 siblings, 0 replies; 52+ messages in thread
From: Vladimir Oltean @ 2022-07-05 22:04 UTC (permalink / raw)
To: Colin Foster
Cc: Rob Herring, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
2022-07-05 22:04 ` Vladimir Oltean
@ 2022-07-05 22:56 ` Vladimir Oltean
-1 siblings, 0 replies; 52+ messages in thread
From: Vladimir Oltean @ 2022-07-05 22:56 UTC (permalink / raw)
To: Colin Foster
Cc: Rob Herring, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-07-05 22:56 ` Vladimir Oltean
0 siblings, 0 replies; 52+ messages in thread
From: Vladimir Oltean @ 2022-07-05 22:56 UTC (permalink / raw)
To: Colin Foster
Cc: Rob Herring, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
2022-07-05 22:56 ` Vladimir Oltean
@ 2022-07-06 4:34 ` Colin Foster
-1 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-06 4:34 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Rob Herring, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-07-06 4:34 ` Colin Foster
0 siblings, 0 replies; 52+ messages in thread
From: Colin Foster @ 2022-07-06 4:34 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Rob Herring, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, Lee Jones, Krzysztof Kozlowski, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lars Povlsen, Steen Hegelund,
UNGLinuxDriver, Linus Walleij, Wolfram Sang, Terry Bowman,
Andy Shevchenko, katie.morris
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2022-07-06 4:35 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-01 19:26 [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 19:26 ` [PATCH v12 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 20:23 ` Andy Shevchenko
2022-07-01 20:23 ` Andy Shevchenko
2022-07-01 20:34 ` Colin Foster
2022-07-01 20:34 ` Colin Foster
2022-07-01 20:41 ` Andy Shevchenko
2022-07-01 20:41 ` Andy Shevchenko
2022-07-01 19:26 ` [PATCH v12 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 20:24 ` Andy Shevchenko
2022-07-01 20:24 ` Andy Shevchenko
2022-07-01 20:38 ` Colin Foster
2022-07-01 20:38 ` Colin Foster
2022-07-01 19:26 ` [PATCH v12 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 19:26 ` [PATCH v12 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 19:26 ` [PATCH v12 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 19:26 ` [PATCH v12 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 19:26 ` [PATCH v12 net-next 7/9] resource: add define macro for register address resources Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 19:26 ` [PATCH v12 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512 Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-05 20:26 ` Rob Herring
2022-07-05 20:26 ` Rob Herring
2022-07-01 19:26 ` [PATCH v12 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster
2022-07-01 19:26 ` Colin Foster
2022-07-01 20:38 ` Andy Shevchenko
2022-07-01 20:38 ` Andy Shevchenko
2022-07-01 21:04 ` Colin Foster
2022-07-01 21:04 ` Colin Foster
2022-07-02 3:02 ` Jakub Kicinski
2022-07-02 3:02 ` Jakub Kicinski
2022-07-02 16:26 ` Colin Foster
2022-07-02 16:26 ` Colin Foster
2022-07-02 10:04 ` kernel test robot
2022-07-02 10:04 ` kernel test robot
2022-07-05 20:24 ` [PATCH v12 net-next 0/9] add support for VSC7512 control over SPI Rob Herring
2022-07-05 20:24 ` Rob Herring
2022-07-05 20:30 ` Colin Foster
2022-07-05 20:30 ` Colin Foster
2022-07-05 22:04 ` Vladimir Oltean
2022-07-05 22:04 ` Vladimir Oltean
2022-07-05 22:56 ` Vladimir Oltean
2022-07-05 22:56 ` Vladimir Oltean
2022-07-06 4:34 ` Colin Foster
2022-07-06 4:34 ` Colin Foster
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.