* [PATCH v11 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
The patch set in general is to add support for the VSC7512, and
eventually the VSC7511, VSC7513 and VSC7514 devices controlled over
SPI. Specifically this patch set enables pinctrl, serial gpio expander
access, and control of an internal and an external MDIO bus.
I have mentioned previously:
The hardware setup I'm using for development is a beaglebone black, with
jumpers from SPI0 to the microchip VSC7512 dev board. The microchip dev
board has been modified to not boot from flash, but wait for SPI. An
ethernet cable is connected from the beaglebone ethernet to port 0 of
the dev board. Network functionality will be included in a future patch set.
The device tree I'm using is included in the documentation, so I'll not
include that in this cover letter. I have exported the serial GPIOs to the
LEDs, and verified functionality via
"echo heartbeat > sys/class/leds/port0led/trigger"
/ {
vscleds {
compatible = "gpio-leds";
vscled@0 {
label = "port0led";
gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
vscled@1 {
label = "port0led1";
gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
[ ... ]
};
};
And I'll include the relevant dmesg prints - I don't love the "invalid
resource" prints, as they seem to be misleading. They're a byproduct of
looking for IO resources before falling back to REG, which succeeds.
Booting Linux on physical CPU 0x0
Linux version 5.19.0-rc3-00662-gb661f062e865
...
[ 1.930121] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set
[ 1.930287] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
[ 1.930861] gpiochip_find_base: found new base at 2026
[ 1.930912] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
[ 1.933211] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
[ 1.933358] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
[ 1.933378] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
[ 1.951876] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
[ 1.952100] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
[ 1.952971] gpiochip_find_base: found new base at 1962
[ 1.953710] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
[ 1.953822] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
[ 1.954612] gpiochip_find_base: found new base at 1898
[ 1.955513] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
[ 1.955611] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
[ 1.963280] mscc-miim ocelot-miim0.2.auto: DMA mask not set
[ 1.963432] mscc-miim ocelot-miim0.2.auto: invalid resource
[ 1.963585] mscc-miim ocelot-miim0.2.auto: invalid resource
[ 1.964633] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
[ 1.964651] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
[ 1.964676] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/switch@0/mdio@7107009c[0]'
[ 1.964767] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/switch@0/mdio@7107009c[0]'
[ 1.964857] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
[ 1.964868] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
I only have hardware to test the last patch, so any testers are welcome.
I've been extra cautious about the
ocelot_platform_init_regmap_from_resource helper function, both before
and after the last patch. I accidentally broke it in the past and would
like to avoid doing so again.
RFC history:
v1 (accidentally named vN)
* Initial architecture. Not functional
* General concepts laid out
v2
* Near functional. No CPU port communication, but control over all
external ports
* Cleaned up regmap implementation from v1
v3
* Functional
* Shared MDIO transactions routed through mdio-mscc-miim
* CPU / NPI port enabled by way of vsc7512_enable_npi_port /
felix->info->enable_npi_port
* NPI port tagging functional - Requires a CPU port driver that supports
frames of 1520 bytes. Verified with a patch to the cpsw driver
v4
* Functional
* Device tree fixes
* Add hooks for pinctrl-ocelot - some functionality by way of sysfs
* Add hooks for pinctrl-microsemi-sgpio - not yet fully functional
* Remove lynx_pcs interface for a generic phylink_pcs. The goal here
is to have an ocelot_pcs that will work for each configuration of
every port.
v5
* Restructured to MFD
* Several commits were split out, submitted, and accepted
* pinctrl-ocelot believed to be fully functional (requires commits
from the linux-pinctrl tree)
* External MDIO bus believed to be fully functional
v6
* Applied several suggestions from the last RFC from Lee Jones. I
hope I didn't miss anything.
* Clean up MFD core - SPI interaction. They no longer use callbacks.
* regmaps get registered to the child device, and don't attempt to
get shared. It seems if a regmap is to be shared, that should be
solved with syscon, not dev or mfd.
v7
* Applied as much as I could from Lee and Vladimir's suggestions. As
always, the feedback is greatly appreciated!
* Remove "ocelot_spi" container complication
* Move internal MDIO bus from ocelot_ext to MFD, with a devicetree
change to match
* Add initial HSIO support
* Switch to IORESOURCE_REG for resource definitions
v8
* Applied another round of suggestions from Lee and Vladimir
* Utilize regmap bus reads, which speeds bulk transfers up by an
order of magnitude
* Add two additional patches to utilize phylink_generic_validate
* Changed GPL V2 to GPL in licenses where applicable (checkpatch)
* Remove initial hsio/serdes changes from the RFC
v9
* Submitting as a PATCH instead of an RFC
* Remove switch functionality - will be a separate patch set
* Remove Kconfig tristate module options
* Another round of suggestions from Lee, Vladimir, and Andy. Many
thanks!
* Add documentation
* Update maintainers
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
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 | 175 ++++++++++
drivers/mfd/ocelot-spi.c | 313 ++++++++++++++++++
drivers/mfd/ocelot.h | 28 ++
drivers/net/mdio/mdio-mscc-miim.c | 35 +-
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 | 35 ++
13 files changed, 773 insertions(+), 38 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] 82+ messages in thread
* [PATCH v11 net-next 0/9] add support for VSC7512 control over SPI
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
The patch set in general is to add support for the VSC7512, and
eventually the VSC7511, VSC7513 and VSC7514 devices controlled over
SPI. Specifically this patch set enables pinctrl, serial gpio expander
access, and control of an internal and an external MDIO bus.
I have mentioned previously:
The hardware setup I'm using for development is a beaglebone black, with
jumpers from SPI0 to the microchip VSC7512 dev board. The microchip dev
board has been modified to not boot from flash, but wait for SPI. An
ethernet cable is connected from the beaglebone ethernet to port 0 of
the dev board. Network functionality will be included in a future patch set.
The device tree I'm using is included in the documentation, so I'll not
include that in this cover letter. I have exported the serial GPIOs to the
LEDs, and verified functionality via
"echo heartbeat > sys/class/leds/port0led/trigger"
/ {
vscleds {
compatible = "gpio-leds";
vscled@0 {
label = "port0led";
gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
vscled@1 {
label = "port0led1";
gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
[ ... ]
};
};
And I'll include the relevant dmesg prints - I don't love the "invalid
resource" prints, as they seem to be misleading. They're a byproduct of
looking for IO resources before falling back to REG, which succeeds.
Booting Linux on physical CPU 0x0
Linux version 5.19.0-rc3-00662-gb661f062e865
...
[ 1.930121] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set
[ 1.930287] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
[ 1.930861] gpiochip_find_base: found new base at 2026
[ 1.930912] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
[ 1.933211] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
[ 1.933358] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
[ 1.933378] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
[ 1.951876] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
[ 1.952100] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
[ 1.952971] gpiochip_find_base: found new base at 1962
[ 1.953710] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
[ 1.953822] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
[ 1.954612] gpiochip_find_base: found new base at 1898
[ 1.955513] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
[ 1.955611] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
[ 1.963280] mscc-miim ocelot-miim0.2.auto: DMA mask not set
[ 1.963432] mscc-miim ocelot-miim0.2.auto: invalid resource
[ 1.963585] mscc-miim ocelot-miim0.2.auto: invalid resource
[ 1.964633] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
[ 1.964651] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
[ 1.964676] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/switch@0/mdio@7107009c[0]'
[ 1.964767] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/switch@0/mdio@7107009c[0]'
[ 1.964857] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
[ 1.964868] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
I only have hardware to test the last patch, so any testers are welcome.
I've been extra cautious about the
ocelot_platform_init_regmap_from_resource helper function, both before
and after the last patch. I accidentally broke it in the past and would
like to avoid doing so again.
RFC history:
v1 (accidentally named vN)
* Initial architecture. Not functional
* General concepts laid out
v2
* Near functional. No CPU port communication, but control over all
external ports
* Cleaned up regmap implementation from v1
v3
* Functional
* Shared MDIO transactions routed through mdio-mscc-miim
* CPU / NPI port enabled by way of vsc7512_enable_npi_port /
felix->info->enable_npi_port
* NPI port tagging functional - Requires a CPU port driver that supports
frames of 1520 bytes. Verified with a patch to the cpsw driver
v4
* Functional
* Device tree fixes
* Add hooks for pinctrl-ocelot - some functionality by way of sysfs
* Add hooks for pinctrl-microsemi-sgpio - not yet fully functional
* Remove lynx_pcs interface for a generic phylink_pcs. The goal here
is to have an ocelot_pcs that will work for each configuration of
every port.
v5
* Restructured to MFD
* Several commits were split out, submitted, and accepted
* pinctrl-ocelot believed to be fully functional (requires commits
from the linux-pinctrl tree)
* External MDIO bus believed to be fully functional
v6
* Applied several suggestions from the last RFC from Lee Jones. I
hope I didn't miss anything.
* Clean up MFD core - SPI interaction. They no longer use callbacks.
* regmaps get registered to the child device, and don't attempt to
get shared. It seems if a regmap is to be shared, that should be
solved with syscon, not dev or mfd.
v7
* Applied as much as I could from Lee and Vladimir's suggestions. As
always, the feedback is greatly appreciated!
* Remove "ocelot_spi" container complication
* Move internal MDIO bus from ocelot_ext to MFD, with a devicetree
change to match
* Add initial HSIO support
* Switch to IORESOURCE_REG for resource definitions
v8
* Applied another round of suggestions from Lee and Vladimir
* Utilize regmap bus reads, which speeds bulk transfers up by an
order of magnitude
* Add two additional patches to utilize phylink_generic_validate
* Changed GPL V2 to GPL in licenses where applicable (checkpatch)
* Remove initial hsio/serdes changes from the RFC
v9
* Submitting as a PATCH instead of an RFC
* Remove switch functionality - will be a separate patch set
* Remove Kconfig tristate module options
* Another round of suggestions from Lee, Vladimir, and Andy. Many
thanks!
* Add documentation
* Update maintainers
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
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 | 175 ++++++++++
drivers/mfd/ocelot-spi.c | 313 ++++++++++++++++++
drivers/mfd/ocelot.h | 28 ++
drivers/net/mdio/mdio-mscc-miim.c | 35 +-
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 | 35 ++
13 files changed, 773 insertions(+), 38 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] 82+ messages in thread
* [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 27 +++++++++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 include/linux/mfd/ocelot.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 36f0a205c54a..4d9ccec78f18 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..5c95e4ee38a6
--- /dev/null
+++ b/include/linux/mfd/ocelot.h
@@ -0,0 +1,27 @@
+/* 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_platform_init_regmap_from_resource(struct platform_device *pdev,
+ unsigned int index,
+ const struct regmap_config *config)
+{
+ struct resource *res;
+ u32 __iomem *regs;
+
+ regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
+
+ if (!res)
+ return ERR_PTR(-ENOENT);
+ else if (IS_ERR(regs))
+ return ERR_CAST(regs);
+ else
+ return devm_regmap_init_mmio(&pdev->dev, regs, config);
+}
--
2.25.1
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 27 +++++++++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 include/linux/mfd/ocelot.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 36f0a205c54a..4d9ccec78f18 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..5c95e4ee38a6
--- /dev/null
+++ b/include/linux/mfd/ocelot.h
@@ -0,0 +1,27 @@
+/* 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_platform_init_regmap_from_resource(struct platform_device *pdev,
+ unsigned int index,
+ const struct regmap_config *config)
+{
+ struct resource *res;
+ u32 __iomem *regs;
+
+ regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
+
+ if (!res)
+ return ERR_PTR(-ENOENT);
+ else if (IS_ERR(regs))
+ return ERR_CAST(regs);
+ else
+ return devm_regmap_init_mmio(&pdev->dev, regs, config);
+}
--
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] 82+ messages in thread
* [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 35 +++++++++++--------------------
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 08541007b18a..157c0b196eab 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,40 +271,27 @@ 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_platform_init_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)) {
+ /* This resource is optional, so ENOENT can be ignored */
+ phy_regmap = ocelot_platform_init_regmap_from_resource(pdev, 1,
+ &mscc_miim_phy_regmap_config);
+ if (IS_ERR(phy_regmap)) {
+ if (phy_regmap == ERR_PTR(-ENOENT)) {
+ phy_regmap = NULL;
+ } else {
dev_err(dev, "Unable to create phy register regmap\n");
return PTR_ERR(phy_regmap);
}
@@ -404,3 +392,4 @@ module_platform_driver(mscc_miim_driver);
MODULE_DESCRIPTION("Microsemi MIIM driver");
MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@bootlin.com>");
MODULE_LICENSE("Dual MIT/GPL");
+MODULE_IMPORT_NS(MFD_OCELOT);
--
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] 82+ messages in thread
* [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 35 +++++++++++--------------------
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 08541007b18a..157c0b196eab 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,40 +271,27 @@ 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_platform_init_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)) {
+ /* This resource is optional, so ENOENT can be ignored */
+ phy_regmap = ocelot_platform_init_regmap_from_resource(pdev, 1,
+ &mscc_miim_phy_regmap_config);
+ if (IS_ERR(phy_regmap)) {
+ if (phy_regmap == ERR_PTR(-ENOENT)) {
+ phy_regmap = NULL;
+ } else {
dev_err(dev, "Unable to create phy register regmap\n");
return PTR_ERR(phy_regmap);
}
@@ -404,3 +392,4 @@ module_platform_driver(mscc_miim_driver);
MODULE_DESCRIPTION("Microsemi MIIM driver");
MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@bootlin.com>");
MODULE_LICENSE("Dual MIT/GPL");
+MODULE_IMPORT_NS(MFD_OCELOT);
--
2.25.1
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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, 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 | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
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..5554c3014448 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)
{
@@ -1985,3 +1986,6 @@ static struct platform_driver ocelot_pinctrl_driver = {
.probe = ocelot_pinctrl_probe,
};
builtin_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] 82+ messages in thread
* [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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, 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 | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
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..5554c3014448 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)
{
@@ -1985,3 +1986,6 @@ static struct platform_driver ocelot_pinctrl_driver = {
.probe = ocelot_pinctrl_probe,
};
builtin_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] 82+ messages in thread
* [PATCH v11 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 5554c3014448..655bada7cc4b 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,12 @@ 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_platform_init_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);
@@ -1989,3 +1985,4 @@ builtin_platform_driver(ocelot_pinctrl_driver);
MODULE_DESCRIPTION("Ocelot Chip Pinctrl Driver");
MODULE_LICENSE("Dual MIT/GPL");
+MODULE_IMPORT_NS(MFD_OCELOT);
--
2.25.1
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v11 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 5554c3014448..655bada7cc4b 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,12 @@ 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_platform_init_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);
@@ -1989,3 +1985,4 @@ builtin_platform_driver(ocelot_pinctrl_driver);
MODULE_DESCRIPTION("Ocelot Chip Pinctrl Driver");
MODULE_LICENSE("Dual MIT/GPL");
+MODULE_IMPORT_NS(MFD_OCELOT);
--
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] 82+ messages in thread
* [PATCH v11 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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, 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 | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
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..47b479c1fb7c 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 = {
@@ -1009,3 +1010,6 @@ static struct platform_driver microchip_sgpio_pinctrl_driver = {
.probe = microchip_sgpio_probe,
};
builtin_platform_driver(microchip_sgpio_pinctrl_driver);
+
+MODULE_DESCRIPTION("Microchip SGPIO Pinctrl Driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v11 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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, 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 | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
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..47b479c1fb7c 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 = {
@@ -1009,3 +1010,6 @@ static struct platform_driver microchip_sgpio_pinctrl_driver = {
.probe = microchip_sgpio_probe,
};
builtin_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] 82+ messages in thread
* [PATCH v11 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index 47b479c1fb7c..c924605f9d03 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,8 @@ 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_platform_init_regmap_from_resource(pdev, 0,
+ ®map_config);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);
@@ -1013,3 +1010,4 @@ builtin_platform_driver(microchip_sgpio_pinctrl_driver);
MODULE_DESCRIPTION("Microchip SGPIO Pinctrl Driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS(MFD_OCELOT);
--
2.25.1
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v11 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index 47b479c1fb7c..c924605f9d03 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,8 @@ 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_platform_init_regmap_from_resource(pdev, 0,
+ ®map_config);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);
@@ -1013,3 +1010,4 @@ builtin_platform_driver(microchip_sgpio_pinctrl_driver);
MODULE_DESCRIPTION("Microchip SGPIO Pinctrl Driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS(MFD_OCELOT);
--
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] 82+ messages in thread
* [PATCH v11 net-next 7/9] resource: add define macro for register address resources
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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] 82+ messages in thread
* [PATCH v11 net-next 7/9] resource: add define macro for register address resources
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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] 82+ messages in thread
* [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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..24fab9f5e319
--- /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-spi
+
+ 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>;
+
+ switch@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 4d9ccec78f18..03eba7fd2141 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] 82+ messages in thread
* [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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..24fab9f5e319
--- /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-spi
+
+ 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>;
+
+ switch@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 4d9ccec78f18..03eba7fd2141 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] 82+ messages in thread
* [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 8:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 175 +++++++++++++++++++++
drivers/mfd/ocelot-spi.c | 313 +++++++++++++++++++++++++++++++++++++
drivers/mfd/ocelot.h | 28 ++++
include/linux/mfd/ocelot.h | 8 +
7 files changed, 545 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 03eba7fd2141..9f2df8906ab6 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..6887b513b3fb 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
+ bool "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 pictrl, 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..18cbe5b8a4ef
--- /dev/null
+++ b/drivers/mfd/ocelot-core.c
@@ -0,0 +1,175 @@
+// 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,
+ },
+};
+
+struct regmap *
+ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
+ unsigned int index,
+ const struct regmap_config *config)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct regmap *map;
+ u32 __iomem *regs;
+
+ map = ERR_PTR(-ENOENT);
+
+ regs = devm_platform_get_and_ioremap_resource(pdev, index, NULL);
+ if (IS_ERR(regs)) {
+ /*
+ * Fall back to using IORESOURCE_REG, which is possible in an
+ * MFD configuration
+ */
+ res = platform_get_resource(pdev, IORESOURCE_REG, index);
+ if (!res) {
+ dev_err_probe(dev, PTR_ERR(res),
+ "Failed to get resource\n");
+ return map;
+ }
+
+ map = ocelot_spi_init_regmap(dev->parent, dev, res);
+ } else {
+ map = devm_regmap_init_mmio(dev, regs, config);
+ }
+
+ return map;
+}
+EXPORT_SYMBOL_NS(ocelot_platform_init_regmap_from_resource, MFD_OCELOT);
+
+int ocelot_core_init(struct device *dev)
+{
+ return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
+ ARRAY_SIZE(vsc7512_devs), 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..9b08d2f6a855
--- /dev/null
+++ b/drivers/mfd/ocelot-spi.c
@@ -0,0 +1,313 @@
+// 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, struct device *child,
+ 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(child, &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, dev, &vsc7512_dev_cpuorg_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->cpuorg_regmap = r;
+
+ r = ocelot_spi_init_regmap(dev, 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..cf33c3ab89c2
--- /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, struct device *child,
+ 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
diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
index 5c95e4ee38a6..86c7ae57d0cb 100644
--- a/include/linux/mfd/ocelot.h
+++ b/include/linux/mfd/ocelot.h
@@ -2,12 +2,19 @@
/* Copyright 2022 Innovative Advantage Inc. */
#include <linux/err.h>
+#include <linux/kconfig.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/types.h>
struct resource;
+#if IS_ENABLED(CONFIG_MFD_OCELOT)
+struct regmap *
+ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
+ unsigned int index,
+ const struct regmap_config *config);
+#else
static inline struct regmap *
ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
unsigned int index,
@@ -25,3 +32,4 @@ ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
else
return devm_regmap_init_mmio(&pdev->dev, regs, config);
}
+#endif
--
2.25.1
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-06-28 8:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 8:17 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
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 | 175 +++++++++++++++++++++
drivers/mfd/ocelot-spi.c | 313 +++++++++++++++++++++++++++++++++++++
drivers/mfd/ocelot.h | 28 ++++
include/linux/mfd/ocelot.h | 8 +
7 files changed, 545 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 03eba7fd2141..9f2df8906ab6 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..6887b513b3fb 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
+ bool "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 pictrl, 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..18cbe5b8a4ef
--- /dev/null
+++ b/drivers/mfd/ocelot-core.c
@@ -0,0 +1,175 @@
+// 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,
+ },
+};
+
+struct regmap *
+ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
+ unsigned int index,
+ const struct regmap_config *config)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct regmap *map;
+ u32 __iomem *regs;
+
+ map = ERR_PTR(-ENOENT);
+
+ regs = devm_platform_get_and_ioremap_resource(pdev, index, NULL);
+ if (IS_ERR(regs)) {
+ /*
+ * Fall back to using IORESOURCE_REG, which is possible in an
+ * MFD configuration
+ */
+ res = platform_get_resource(pdev, IORESOURCE_REG, index);
+ if (!res) {
+ dev_err_probe(dev, PTR_ERR(res),
+ "Failed to get resource\n");
+ return map;
+ }
+
+ map = ocelot_spi_init_regmap(dev->parent, dev, res);
+ } else {
+ map = devm_regmap_init_mmio(dev, regs, config);
+ }
+
+ return map;
+}
+EXPORT_SYMBOL_NS(ocelot_platform_init_regmap_from_resource, MFD_OCELOT);
+
+int ocelot_core_init(struct device *dev)
+{
+ return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
+ ARRAY_SIZE(vsc7512_devs), 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..9b08d2f6a855
--- /dev/null
+++ b/drivers/mfd/ocelot-spi.c
@@ -0,0 +1,313 @@
+// 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, struct device *child,
+ 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(child, &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, dev, &vsc7512_dev_cpuorg_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->cpuorg_regmap = r;
+
+ r = ocelot_spi_init_regmap(dev, 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..cf33c3ab89c2
--- /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, struct device *child,
+ 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
diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
index 5c95e4ee38a6..86c7ae57d0cb 100644
--- a/include/linux/mfd/ocelot.h
+++ b/include/linux/mfd/ocelot.h
@@ -2,12 +2,19 @@
/* Copyright 2022 Innovative Advantage Inc. */
#include <linux/err.h>
+#include <linux/kconfig.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/types.h>
struct resource;
+#if IS_ENABLED(CONFIG_MFD_OCELOT)
+struct regmap *
+ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
+ unsigned int index,
+ const struct regmap_config *config);
+#else
static inline struct regmap *
ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
unsigned int index,
@@ -25,3 +32,4 @@ ocelot_platform_init_regmap_from_resource(struct platform_device *pdev,
else
return devm_regmap_init_mmio(&pdev->dev, regs, config);
}
+#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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 12:50 ` Andy Shevchenko
-1 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 12:50 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
On Tue, Jun 28, 2022 at 10:17 AM 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.
> + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> +
> + if (!res)
> + return ERR_PTR(-ENOENT);
This needs a comment why the original error code from devm_ call above
is not good here.
> + else if (IS_ERR(regs))
> + return ERR_CAST(regs);
> + else
> + return devm_regmap_init_mmio(&pdev->dev, regs, config);
> +}
'else' is redundant in all cases above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 12:50 ` Andy Shevchenko
0 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 12:50 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
On Tue, Jun 28, 2022 at 10:17 AM 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.
> + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> +
> + if (!res)
> + return ERR_PTR(-ENOENT);
This needs a comment why the original error code from devm_ call above
is not good here.
> + else if (IS_ERR(regs))
> + return ERR_CAST(regs);
> + else
> + return devm_regmap_init_mmio(&pdev->dev, regs, config);
> +}
'else' is redundant in all cases above.
--
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] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 12:53 ` Andy Shevchenko
-1 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 12:53 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, Florian Fainelli
On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> 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.
...
> builtin_platform_driver(ocelot_pinctrl_driver);
This contradicts the logic behind this change. Perhaps you need to
move to module_platform_driver(). (Yes, I think functionally it won't
be any changes if ->remove() is not needed, but for the sake of
logical correctness...)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-06-28 12:53 ` Andy Shevchenko
0 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 12:53 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, Florian Fainelli
On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> 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.
...
> builtin_platform_driver(ocelot_pinctrl_driver);
This contradicts the logic behind this change. Perhaps you need to
move to module_platform_driver(). (Yes, I think functionally it won't
be any changes if ->remove() is not needed, but for the sake of
logical correctness...)
--
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] 82+ messages in thread
* Re: [PATCH v11 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 12:55 ` Andy Shevchenko
-1 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 12:55 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, Florian Fainelli
On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> 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.
...
> builtin_platform_driver(microchip_sgpio_pinctrl_driver);
As per one of the previous patches. And repetitive if needed.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
@ 2022-06-28 12:55 ` Andy Shevchenko
0 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 12:55 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, Florian Fainelli
On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> 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.
...
> builtin_platform_driver(microchip_sgpio_pinctrl_driver);
As per one of the previous patches. And repetitive if needed.
--
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] 82+ messages in thread
* Re: [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 13:15 ` Rob Herring
-1 siblings, 0 replies; 82+ messages in thread
From: Rob Herring @ 2022-06-28 13:15 UTC (permalink / raw)
To: Colin Foster
Cc: Terry Bowman, UNGLinuxDriver, linux-kernel, netdev,
Jakub Kicinski, David S. Miller, Andy Shevchenko, Wolfram Sang,
Andrew Lunn, Krzysztof Kozlowski, Paolo Abeni, Russell King,
devicetree, Heiner Kallweit, linux-gpio, Rob Herring,
linux-arm-kernel, Steen Hegelund, Lee Jones, Eric Dumazet,
Linus Walleij, Lars Povlsen, Vladimir Oltean
On Tue, 28 Jun 2022 01:17: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
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/mfd/mscc,ocelot.example.dtb:0:0: /example-0/spi/switch@0: failed to match any schema with compatible: ['mscc,vsc7512']
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
@ 2022-06-28 13:15 ` Rob Herring
0 siblings, 0 replies; 82+ messages in thread
From: Rob Herring @ 2022-06-28 13:15 UTC (permalink / raw)
To: Colin Foster
Cc: Terry Bowman, UNGLinuxDriver, linux-kernel, netdev,
Jakub Kicinski, David S. Miller, Andy Shevchenko, Wolfram Sang,
Andrew Lunn, Krzysztof Kozlowski, Paolo Abeni, Russell King,
devicetree, Heiner Kallweit, linux-gpio, Rob Herring,
linux-arm-kernel, Steen Hegelund, Lee Jones, Eric Dumazet,
Linus Walleij, Lars Povlsen, Vladimir Oltean
On Tue, 28 Jun 2022 01:17: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
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/mfd/mscc,ocelot.example.dtb:0:0: /example-0/spi/switch@0: failed to match any schema with compatible: ['mscc,vsc7512']
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 12:50 ` Andy Shevchenko
@ 2022-06-28 15:33 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 15:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Colin Foster, devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM, 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
On Tue, Jun 28, 2022 at 02:50:36PM +0200, Andy Shevchenko wrote:
> On Tue, Jun 28, 2022 at 10:17 AM 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.
>
> > + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> > +
> > + if (!res)
> > + return ERR_PTR(-ENOENT);
>
> This needs a comment why the original error code from devm_ call above
> is not good here.
I think what is really needed is an _optional() variant of
ocelot_platform_init_regmap_from_resource(), which just returns NULL on
missing resource and doesn't ioremap anything. It can be easily open
coded, i.e. instead of creating devm_platform_get_and_ioremap_resource_optional(),
we could just call platform_get_resource() and devm_ioremap_resource()
individually.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 15:33 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 15:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Colin Foster, devicetree, Linux Kernel Mailing List, netdev,
linux-arm Mailing List, open list:GPIO SUBSYSTEM, 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
On Tue, Jun 28, 2022 at 02:50:36PM +0200, Andy Shevchenko wrote:
> On Tue, Jun 28, 2022 at 10:17 AM 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.
>
> > + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> > +
> > + if (!res)
> > + return ERR_PTR(-ENOENT);
>
> This needs a comment why the original error code from devm_ call above
> is not good here.
I think what is really needed is an _optional() variant of
ocelot_platform_init_regmap_from_resource(), which just returns NULL on
missing resource and doesn't ioremap anything. It can be easily open
coded, i.e. instead of creating devm_platform_get_and_ioremap_resource_optional(),
we could just call platform_get_resource() and devm_ioremap_resource()
individually.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 16:08 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 16:08 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
On Tue, Jun 28, 2022 at 01:17:01AM -0700, Colin Foster wrote:
> diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> new file mode 100644
> index 000000000000..5c95e4ee38a6
> --- /dev/null
> +++ b/include/linux/mfd/ocelot.h
> @@ -0,0 +1,27 @@
> +/* 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_platform_init_regmap_from_resource(struct platform_device *pdev,
> + unsigned int index,
> + const struct regmap_config *config)
I think this function name is too long (especially if you're going to
also introduce ocelot_platform_init_regmap_from_resource_optional),
and I have the impression that the "platform_init_" part of the name
doesn't bring too much value. How about ocelot_regmap_from_resource()?
> +{
> + struct resource *res;
> + u32 __iomem *regs;
> +
> + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> +
> + if (!res)
> + return ERR_PTR(-ENOENT);
> + else if (IS_ERR(regs))
> + return ERR_CAST(regs);
> + else
> + return devm_regmap_init_mmio(&pdev->dev, regs, config);
> +}
> --
> 2.25.1
>
To illustrate what I'm trying to say, these would be the shim
definitions:
static inline struct regmap *
ocelot_regmap_from_resource(struct platform_device *pdev,
unsigned int index,
const struct regmap_config *config)
{
struct resource *res;
void __iomem *regs;
regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
if (IS_ERR(regs))
return regs;
return devm_regmap_init_mmio(&pdev->dev, regs, config);
}
static inline struct regmap *
ocelot_regmap_from_resource_optional(struct platform_device *pdev,
unsigned int index,
const struct regmap_config *config)
{
struct resource *res;
void __iomem *regs;
res = platform_get_resource(pdev, IORESOURCE_MEM, index);
if (!res)
return NULL;
regs = devm_ioremap_resource(&pdev->dev, r);
if (IS_ERR(regs))
return regs;
return devm_regmap_init_mmio(&pdev->dev, regs, config);
}
and these would be the full versions:
static struct regmap *
ocelot_regmap_from_mem_resource(struct device *dev, struct resource *res,
const struct regmap_config *config)
{
void __iomem *regs;
regs = devm_ioremap_resource(dev, r);
if (IS_ERR(regs))
return regs;
return devm_regmap_init_mmio(dev, regs, config);
}
static struct regmap *
ocelot_regmap_from_reg_resource(struct device *dev, struct resource *res,
const struct regmap_config *config)
{
/* Open question: how to differentiate SPI from I2C resources? */
return ocelot_spi_init_regmap(dev->parent, dev, res);
}
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;
res = platform_get_resource(pdev, IORESOURCE_MEM, index);
if (res)
return ocelot_regmap_from_mem_resource(dev, res, config);
/*
* Fall back to using IORESOURCE_REG, which is possible in an
* MFD configuration
*/
res = platform_get_resource(pdev, IORESOURCE_REG, index);
if (res)
return ocelot_regmap_from_reg_resource(dev, res, config);
return NULL;
}
struct regmap *
ocelot_regmap_from_resource(struct platform_device *pdev,
unsigned int index,
const struct regmap_config *config)
{
struct regmap *map;
map = ocelot_regmap_from_resource_optional(pdev, index, config);
return map ? : ERR_PTR(-ENOENT);
}
I hope I didn't get something wrong, this is all code written within the
email client, so it is obviously not compiled/tested....
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 16:08 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 16:08 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
On Tue, Jun 28, 2022 at 01:17:01AM -0700, Colin Foster wrote:
> diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> new file mode 100644
> index 000000000000..5c95e4ee38a6
> --- /dev/null
> +++ b/include/linux/mfd/ocelot.h
> @@ -0,0 +1,27 @@
> +/* 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_platform_init_regmap_from_resource(struct platform_device *pdev,
> + unsigned int index,
> + const struct regmap_config *config)
I think this function name is too long (especially if you're going to
also introduce ocelot_platform_init_regmap_from_resource_optional),
and I have the impression that the "platform_init_" part of the name
doesn't bring too much value. How about ocelot_regmap_from_resource()?
> +{
> + struct resource *res;
> + u32 __iomem *regs;
> +
> + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> +
> + if (!res)
> + return ERR_PTR(-ENOENT);
> + else if (IS_ERR(regs))
> + return ERR_CAST(regs);
> + else
> + return devm_regmap_init_mmio(&pdev->dev, regs, config);
> +}
> --
> 2.25.1
>
To illustrate what I'm trying to say, these would be the shim
definitions:
static inline struct regmap *
ocelot_regmap_from_resource(struct platform_device *pdev,
unsigned int index,
const struct regmap_config *config)
{
struct resource *res;
void __iomem *regs;
regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
if (IS_ERR(regs))
return regs;
return devm_regmap_init_mmio(&pdev->dev, regs, config);
}
static inline struct regmap *
ocelot_regmap_from_resource_optional(struct platform_device *pdev,
unsigned int index,
const struct regmap_config *config)
{
struct resource *res;
void __iomem *regs;
res = platform_get_resource(pdev, IORESOURCE_MEM, index);
if (!res)
return NULL;
regs = devm_ioremap_resource(&pdev->dev, r);
if (IS_ERR(regs))
return regs;
return devm_regmap_init_mmio(&pdev->dev, regs, config);
}
and these would be the full versions:
static struct regmap *
ocelot_regmap_from_mem_resource(struct device *dev, struct resource *res,
const struct regmap_config *config)
{
void __iomem *regs;
regs = devm_ioremap_resource(dev, r);
if (IS_ERR(regs))
return regs;
return devm_regmap_init_mmio(dev, regs, config);
}
static struct regmap *
ocelot_regmap_from_reg_resource(struct device *dev, struct resource *res,
const struct regmap_config *config)
{
/* Open question: how to differentiate SPI from I2C resources? */
return ocelot_spi_init_regmap(dev->parent, dev, res);
}
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;
res = platform_get_resource(pdev, IORESOURCE_MEM, index);
if (res)
return ocelot_regmap_from_mem_resource(dev, res, config);
/*
* Fall back to using IORESOURCE_REG, which is possible in an
* MFD configuration
*/
res = platform_get_resource(pdev, IORESOURCE_REG, index);
if (res)
return ocelot_regmap_from_reg_resource(dev, res, config);
return NULL;
}
struct regmap *
ocelot_regmap_from_resource(struct platform_device *pdev,
unsigned int index,
const struct regmap_config *config)
{
struct regmap *map;
map = ocelot_regmap_from_resource_optional(pdev, index, config);
return map ? : ERR_PTR(-ENOENT);
}
I hope I didn't get something wrong, this is all code written within the
email client, so it is obviously not compiled/tested....
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 16:26 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 16:26 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
On Tue, Jun 28, 2022 at 01:17:02AM -0700, Colin Foster 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.
>
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
These "add ability to be used in a non-MMIO configuration" commit
messages are very confusing when you are only adding support for
non-MMIO in ocelot_platform_init_regmap_from_resource() in patch 9/9.
May I suggest a reorder?
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-06-28 16:26 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 16:26 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
On Tue, Jun 28, 2022 at 01:17:02AM -0700, Colin Foster 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.
>
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
These "add ability to be used in a non-MMIO configuration" commit
messages are very confusing when you are only adding support for
non-MMIO in ocelot_platform_init_regmap_from_resource() in patch 9/9.
May I suggest a reorder?
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 16:08 ` Vladimir Oltean
@ 2022-06-28 17:25 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 17:25 UTC (permalink / raw)
To: Vladimir Oltean
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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, Alexandre Belloni, Arnd Bergmann
Hi Vladimir,
On Tue, Jun 28, 2022 at 04:08:10PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 01:17:01AM -0700, Colin Foster wrote:
> > diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> > new file mode 100644
> > index 000000000000..5c95e4ee38a6
> > --- /dev/null
> > +++ b/include/linux/mfd/ocelot.h
> > @@ -0,0 +1,27 @@
> > +/* 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_platform_init_regmap_from_resource(struct platform_device *pdev,
> > + unsigned int index,
> > + const struct regmap_config *config)
>
> I think this function name is too long (especially if you're going to
> also introduce ocelot_platform_init_regmap_from_resource_optional),
> and I have the impression that the "platform_init_" part of the name
> doesn't bring too much value. How about ocelot_regmap_from_resource()?
I thought the same thing after your first email. My thought was "how do
I indent that?" :-)
>
> > +{
> > + struct resource *res;
> > + u32 __iomem *regs;
> > +
> > + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> > +
> > + if (!res)
> > + return ERR_PTR(-ENOENT);
> > + else if (IS_ERR(regs))
> > + return ERR_CAST(regs);
> > + else
> > + return devm_regmap_init_mmio(&pdev->dev, regs, config);
> > +}
> > --
> > 2.25.1
> >
>
> To illustrate what I'm trying to say, these would be the shim
> definitions:
>
> static inline struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> unsigned int index,
> const struct regmap_config *config)
> {
> struct resource *res;
> void __iomem *regs;
>
> regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> if (IS_ERR(regs))
> return regs;
>
> return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
>
> static inline struct regmap *
> ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> unsigned int index,
> const struct regmap_config *config)
> {
> struct resource *res;
> void __iomem *regs;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> if (!res)
> return NULL;
>
> regs = devm_ioremap_resource(&pdev->dev, r);
> if (IS_ERR(regs))
> return regs;
>
> return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
>
> and these would be the full versions:
>
> static struct regmap *
> ocelot_regmap_from_mem_resource(struct device *dev, struct resource *res,
> const struct regmap_config *config)
> {
> void __iomem *regs;
>
> regs = devm_ioremap_resource(dev, r);
> if (IS_ERR(regs))
> return regs;
>
> return devm_regmap_init_mmio(dev, regs, config);
> }
>
> static struct regmap *
> ocelot_regmap_from_reg_resource(struct device *dev, struct resource *res,
> const struct regmap_config *config)
> {
> /* Open question: how to differentiate SPI from I2C resources? */
My expectation is to set something up in drivers/mfd/ocelot-{spi,i2c}.c
and have an if/else / switch. PCIe might actually be our first hardware
spin.
> return ocelot_spi_init_regmap(dev->parent, dev, res);
> }
>
> 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;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> if (res)
> return ocelot_regmap_from_mem_resource(dev, res, config);
>
> /*
> * Fall back to using IORESOURCE_REG, which is possible in an
> * MFD configuration
> */
> res = platform_get_resource(pdev, IORESOURCE_REG, index);
> if (res)
> return ocelot_regmap_from_reg_resource(dev, res, config);
>
> return NULL;
> }
>
> struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> unsigned int index,
> const struct regmap_config *config)
> {
> struct regmap *map;
>
> map = ocelot_regmap_from_resource_optional(pdev, index, config);
> return map ? : ERR_PTR(-ENOENT);
> }
>
> I hope I didn't get something wrong, this is all code written within the
> email client, so it is obviously not compiled/tested....
Yep - I definitely get the point. And thanks for the review.
The other (bigger?) issue is around how this MFD can be loaded as a
module. Right now it is pretty straightforward to say
#if IS_ENABLED(CONFIG_MFD_OCELOT). Theres a level of nuance if
CONFIG_MFD_OCELOT=m while the child devices are compiled in
(CONFIG_PINCTRL_MICROCHIP_SGPIO=y for example). It still feels like this
code belongs somewhere in platform / resource / device / mfd...?
It might be perfectly valid to have multiple SGPIO controllers - one
local and one remote / SPI. But without the CONFIG_MFD_OCELOT module
loaded, I don't think the SGPIO module would work.
This patch set deals with the issue by setting MFD_OCELOT to a boolean -
but in the long run I think a module makes sense. I admittedly haven't
spent enough time researching (bashing my head against the wall) this,
but this seems like a good opportunity to at least express that I'm
expecting to have to deal with this issue soon. I met with Alexandre at
ELC this past week, and he said Arnd (both added to CC) might be a good
resource - but again I'd like to do a little more searching before
throwing it over the wall.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 17:25 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 17:25 UTC (permalink / raw)
To: Vladimir Oltean
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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, Alexandre Belloni, Arnd Bergmann
Hi Vladimir,
On Tue, Jun 28, 2022 at 04:08:10PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 01:17:01AM -0700, Colin Foster wrote:
> > diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> > new file mode 100644
> > index 000000000000..5c95e4ee38a6
> > --- /dev/null
> > +++ b/include/linux/mfd/ocelot.h
> > @@ -0,0 +1,27 @@
> > +/* 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_platform_init_regmap_from_resource(struct platform_device *pdev,
> > + unsigned int index,
> > + const struct regmap_config *config)
>
> I think this function name is too long (especially if you're going to
> also introduce ocelot_platform_init_regmap_from_resource_optional),
> and I have the impression that the "platform_init_" part of the name
> doesn't bring too much value. How about ocelot_regmap_from_resource()?
I thought the same thing after your first email. My thought was "how do
I indent that?" :-)
>
> > +{
> > + struct resource *res;
> > + u32 __iomem *regs;
> > +
> > + regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> > +
> > + if (!res)
> > + return ERR_PTR(-ENOENT);
> > + else if (IS_ERR(regs))
> > + return ERR_CAST(regs);
> > + else
> > + return devm_regmap_init_mmio(&pdev->dev, regs, config);
> > +}
> > --
> > 2.25.1
> >
>
> To illustrate what I'm trying to say, these would be the shim
> definitions:
>
> static inline struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> unsigned int index,
> const struct regmap_config *config)
> {
> struct resource *res;
> void __iomem *regs;
>
> regs = devm_platform_get_and_ioremap_resource(pdev, index, &res);
> if (IS_ERR(regs))
> return regs;
>
> return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
>
> static inline struct regmap *
> ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> unsigned int index,
> const struct regmap_config *config)
> {
> struct resource *res;
> void __iomem *regs;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> if (!res)
> return NULL;
>
> regs = devm_ioremap_resource(&pdev->dev, r);
> if (IS_ERR(regs))
> return regs;
>
> return devm_regmap_init_mmio(&pdev->dev, regs, config);
> }
>
> and these would be the full versions:
>
> static struct regmap *
> ocelot_regmap_from_mem_resource(struct device *dev, struct resource *res,
> const struct regmap_config *config)
> {
> void __iomem *regs;
>
> regs = devm_ioremap_resource(dev, r);
> if (IS_ERR(regs))
> return regs;
>
> return devm_regmap_init_mmio(dev, regs, config);
> }
>
> static struct regmap *
> ocelot_regmap_from_reg_resource(struct device *dev, struct resource *res,
> const struct regmap_config *config)
> {
> /* Open question: how to differentiate SPI from I2C resources? */
My expectation is to set something up in drivers/mfd/ocelot-{spi,i2c}.c
and have an if/else / switch. PCIe might actually be our first hardware
spin.
> return ocelot_spi_init_regmap(dev->parent, dev, res);
> }
>
> 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;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> if (res)
> return ocelot_regmap_from_mem_resource(dev, res, config);
>
> /*
> * Fall back to using IORESOURCE_REG, which is possible in an
> * MFD configuration
> */
> res = platform_get_resource(pdev, IORESOURCE_REG, index);
> if (res)
> return ocelot_regmap_from_reg_resource(dev, res, config);
>
> return NULL;
> }
>
> struct regmap *
> ocelot_regmap_from_resource(struct platform_device *pdev,
> unsigned int index,
> const struct regmap_config *config)
> {
> struct regmap *map;
>
> map = ocelot_regmap_from_resource_optional(pdev, index, config);
> return map ? : ERR_PTR(-ENOENT);
> }
>
> I hope I didn't get something wrong, this is all code written within the
> email client, so it is obviously not compiled/tested....
Yep - I definitely get the point. And thanks for the review.
The other (bigger?) issue is around how this MFD can be loaded as a
module. Right now it is pretty straightforward to say
#if IS_ENABLED(CONFIG_MFD_OCELOT). Theres a level of nuance if
CONFIG_MFD_OCELOT=m while the child devices are compiled in
(CONFIG_PINCTRL_MICROCHIP_SGPIO=y for example). It still feels like this
code belongs somewhere in platform / resource / device / mfd...?
It might be perfectly valid to have multiple SGPIO controllers - one
local and one remote / SPI. But without the CONFIG_MFD_OCELOT module
loaded, I don't think the SGPIO module would work.
This patch set deals with the issue by setting MFD_OCELOT to a boolean -
but in the long run I think a module makes sense. I admittedly haven't
spent enough time researching (bashing my head against the wall) this,
but this seems like a good opportunity to at least express that I'm
expecting to have to deal with this issue soon. I met with Alexandre at
ELC this past week, and he said Arnd (both added to CC) might be a good
resource - but again I'd like to do a little more searching before
throwing it over the wall.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
2022-06-28 13:15 ` Rob Herring
@ 2022-06-28 18:19 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 18:19 UTC (permalink / raw)
To: Rob Herring
Cc: Terry Bowman, UNGLinuxDriver, linux-kernel, netdev,
Jakub Kicinski, David S. Miller, Andy Shevchenko, Wolfram Sang,
Andrew Lunn, Krzysztof Kozlowski, Paolo Abeni, Russell King,
devicetree, Heiner Kallweit, linux-gpio, Rob Herring,
linux-arm-kernel, Steen Hegelund, Lee Jones, Eric Dumazet,
Linus Walleij, Lars Povlsen, Vladimir Oltean
Hi Rob,
On Tue, Jun 28, 2022 at 07:15:23AM -0600, Rob Herring wrote:
> On Tue, 28 Jun 2022 01:17: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
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/mfd/mscc,ocelot.example.dtb:0:0: /example-0/spi/switch@0: failed to match any schema with compatible: ['mscc,vsc7512']
>
Thanks for this info. I'll run this on my end before the next go round.
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.ozlabs.org/patch/
>
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit.
>
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
@ 2022-06-28 18:19 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 18:19 UTC (permalink / raw)
To: Rob Herring
Cc: Terry Bowman, UNGLinuxDriver, linux-kernel, netdev,
Jakub Kicinski, David S. Miller, Andy Shevchenko, Wolfram Sang,
Andrew Lunn, Krzysztof Kozlowski, Paolo Abeni, Russell King,
devicetree, Heiner Kallweit, linux-gpio, Rob Herring,
linux-arm-kernel, Steen Hegelund, Lee Jones, Eric Dumazet,
Linus Walleij, Lars Povlsen, Vladimir Oltean
Hi Rob,
On Tue, Jun 28, 2022 at 07:15:23AM -0600, Rob Herring wrote:
> On Tue, 28 Jun 2022 01:17: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
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/mfd/mscc,ocelot.example.dtb:0:0: /example-0/spi/switch@0: failed to match any schema with compatible: ['mscc,vsc7512']
>
Thanks for this info. I'll run this on my end before the next go round.
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.ozlabs.org/patch/
>
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit.
>
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
2022-06-28 12:53 ` Andy Shevchenko
@ 2022-06-28 18:25 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 18:25 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, Florian Fainelli
Hi Andy,
On Tue, Jun 28, 2022 at 02:53:49PM +0200, Andy Shevchenko wrote:
> On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> >
> > 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.
>
> ...
>
> > builtin_platform_driver(ocelot_pinctrl_driver);
>
> This contradicts the logic behind this change. Perhaps you need to
> move to module_platform_driver(). (Yes, I think functionally it won't
> be any changes if ->remove() is not needed, but for the sake of
> logical correctness...)
I'll do this. Thanks.
Process question: If I make this change is it typical to remove all
Reviewed-By tags? I assume "yes"
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-06-28 18:25 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 18:25 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, Florian Fainelli
Hi Andy,
On Tue, Jun 28, 2022 at 02:53:49PM +0200, Andy Shevchenko wrote:
> On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> >
> > 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.
>
> ...
>
> > builtin_platform_driver(ocelot_pinctrl_driver);
>
> This contradicts the logic behind this change. Perhaps you need to
> move to module_platform_driver(). (Yes, I think functionally it won't
> be any changes if ->remove() is not needed, but for the sake of
> logical correctness...)
I'll do this. Thanks.
Process question: If I make this change is it typical to remove all
Reviewed-By tags? I assume "yes"
>
> --
> 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] 82+ messages in thread
* Re: [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
2022-06-28 16:26 ` Vladimir Oltean
@ 2022-06-28 18:31 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 18:31 UTC (permalink / raw)
To: Vladimir Oltean
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
Hi Vladimir,
On Tue, Jun 28, 2022 at 04:26:05PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 01:17:02AM -0700, Colin Foster 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.
> >
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
>
> These "add ability to be used in a non-MMIO configuration" commit
> messages are very confusing when you are only adding support for
> non-MMIO in ocelot_platform_init_regmap_from_resource() in patch 9/9.
> May I suggest a reorder?
Initially my plan was to get the MFD base functionality (SPI protocol,
chip reset, etc.) in and roll in each peripheral one at a time. That was
changed in v6 I believe...
Maybe a commit reword to suggest "utilize a helper function"?
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-06-28 18:31 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 18:31 UTC (permalink / raw)
To: Vladimir Oltean
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
Hi Vladimir,
On Tue, Jun 28, 2022 at 04:26:05PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 01:17:02AM -0700, Colin Foster 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.
> >
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
>
> These "add ability to be used in a non-MMIO configuration" commit
> messages are very confusing when you are only adding support for
> non-MMIO in ocelot_platform_init_regmap_from_resource() in patch 9/9.
> May I suggest a reorder?
Initially my plan was to get the MFD base functionality (SPI protocol,
chip reset, etc.) in and roll in each peripheral one at a time. That was
changed in v6 I believe...
Maybe a commit reword to suggest "utilize a helper function"?
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 17:25 ` Colin Foster
@ 2022-06-28 18:47 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 18:47 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 10:25:18AM -0700, Colin Foster wrote:
> > struct regmap *
> > ocelot_regmap_from_resource(struct platform_device *pdev,
> > unsigned int index,
> > const struct regmap_config *config)
> > {
> > struct regmap *map;
> >
> > map = ocelot_regmap_from_resource_optional(pdev, index, config);
> > return map ? : ERR_PTR(-ENOENT);
> > }
> >
> > I hope I didn't get something wrong, this is all code written within the
> > email client, so it is obviously not compiled/tested....
>
> Yep - I definitely get the point. And thanks for the review.
>
> The other (bigger?) issue is around how this MFD can be loaded as a
> module. Right now it is pretty straightforward to say
> #if IS_ENABLED(CONFIG_MFD_OCELOT). Theres a level of nuance if
> CONFIG_MFD_OCELOT=m while the child devices are compiled in
> (CONFIG_PINCTRL_MICROCHIP_SGPIO=y for example). It still feels like this
> code belongs somewhere in platform / resource / device / mfd...?
>
> It might be perfectly valid to have multiple SGPIO controllers - one
> local and one remote / SPI. But without the CONFIG_MFD_OCELOT module
> loaded, I don't think the SGPIO module would work.
>
> This patch set deals with the issue by setting MFD_OCELOT to a boolean -
> but in the long run I think a module makes sense. I admittedly haven't
> spent enough time researching (bashing my head against the wall) this,
> but this seems like a good opportunity to at least express that I'm
> expecting to have to deal with this issue soon. I met with Alexandre at
> ELC this past week, and he said Arnd (both added to CC) might be a good
> resource - but again I'd like to do a little more searching before
> throwing it over the wall.
Well, that's quite a different ball game. It sounds like what you want
is to have a dynamic list of regmap providers for a device, and when a
device probes, to not depend on all the modules of all the possible
providers being inserted at that particular time. Which makes sense,
and I agree it's something that should be handled by the kernel core if
you don't want the sgpio code to directly call symbols exported by the
ocelot mfd core.
I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
dev_get_regmap(), maybe those could be of help? I'm not completely sure
about the mechanics of it all, but what I'm searching for is something
through which the mfd core could attach a regmap to a platform device
through devres before calling platform_device_add(), such that the
driver can use it (or manually fall back to an MMIO regmap) via
dev_get_regmap().
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 18:47 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 18:47 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 10:25:18AM -0700, Colin Foster wrote:
> > struct regmap *
> > ocelot_regmap_from_resource(struct platform_device *pdev,
> > unsigned int index,
> > const struct regmap_config *config)
> > {
> > struct regmap *map;
> >
> > map = ocelot_regmap_from_resource_optional(pdev, index, config);
> > return map ? : ERR_PTR(-ENOENT);
> > }
> >
> > I hope I didn't get something wrong, this is all code written within the
> > email client, so it is obviously not compiled/tested....
>
> Yep - I definitely get the point. And thanks for the review.
>
> The other (bigger?) issue is around how this MFD can be loaded as a
> module. Right now it is pretty straightforward to say
> #if IS_ENABLED(CONFIG_MFD_OCELOT). Theres a level of nuance if
> CONFIG_MFD_OCELOT=m while the child devices are compiled in
> (CONFIG_PINCTRL_MICROCHIP_SGPIO=y for example). It still feels like this
> code belongs somewhere in platform / resource / device / mfd...?
>
> It might be perfectly valid to have multiple SGPIO controllers - one
> local and one remote / SPI. But without the CONFIG_MFD_OCELOT module
> loaded, I don't think the SGPIO module would work.
>
> This patch set deals with the issue by setting MFD_OCELOT to a boolean -
> but in the long run I think a module makes sense. I admittedly haven't
> spent enough time researching (bashing my head against the wall) this,
> but this seems like a good opportunity to at least express that I'm
> expecting to have to deal with this issue soon. I met with Alexandre at
> ELC this past week, and he said Arnd (both added to CC) might be a good
> resource - but again I'd like to do a little more searching before
> throwing it over the wall.
Well, that's quite a different ball game. It sounds like what you want
is to have a dynamic list of regmap providers for a device, and when a
device probes, to not depend on all the modules of all the possible
providers being inserted at that particular time. Which makes sense,
and I agree it's something that should be handled by the kernel core if
you don't want the sgpio code to directly call symbols exported by the
ocelot mfd core.
I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
dev_get_regmap(), maybe those could be of help? I'm not completely sure
about the mechanics of it all, but what I'm searching for is something
through which the mfd core could attach a regmap to a platform device
through devres before calling platform_device_add(), such that the
driver can use it (or manually fall back to an MMIO regmap) via
dev_get_regmap().
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 18:47 ` Vladimir Oltean
@ 2022-06-28 18:56 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 18:56 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> dev_get_regmap(), maybe those could be of help?
ah, I see I haven't really brought anything of value to the table,
dev_get_regmap() was discussed around v1 or so. I'll read the
discussions again in a couple of hours to remember what was wrong with
it such that you aren't using it anymore.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 18:56 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-28 18:56 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> dev_get_regmap(), maybe those could be of help?
ah, I see I haven't really brought anything of value to the table,
dev_get_regmap() was discussed around v1 or so. I'll read the
discussions again in a couple of hours to remember what was wrong with
it such that you aren't using it anymore.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
2022-06-28 18:25 ` Colin Foster
@ 2022-06-28 19:00 ` Andy Shevchenko
-1 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 19:00 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, Florian Fainelli
On Tue, Jun 28, 2022 at 8:25 PM Colin Foster
<colin.foster@in-advantage.com> wrote:
> On Tue, Jun 28, 2022 at 02:53:49PM +0200, Andy Shevchenko wrote:
> > On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
> > <colin.foster@in-advantage.com> wrote:
...
> > > builtin_platform_driver(ocelot_pinctrl_driver);
> >
> > This contradicts the logic behind this change. Perhaps you need to
> > move to module_platform_driver(). (Yes, I think functionally it won't
> > be any changes if ->remove() is not needed, but for the sake of
> > logical correctness...)
>
> I'll do this. Thanks.
>
> Process question: If I make this change is it typical to remove all
> Reviewed-By tags? I assume "yes"
I would not. This change is logical continuation and I truly believe
every reviewer will agree on it.
--
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] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-06-28 19:00 ` Andy Shevchenko
0 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 19:00 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, Florian Fainelli
On Tue, Jun 28, 2022 at 8:25 PM Colin Foster
<colin.foster@in-advantage.com> wrote:
> On Tue, Jun 28, 2022 at 02:53:49PM +0200, Andy Shevchenko wrote:
> > On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
> > <colin.foster@in-advantage.com> wrote:
...
> > > builtin_platform_driver(ocelot_pinctrl_driver);
> >
> > This contradicts the logic behind this change. Perhaps you need to
> > move to module_platform_driver(). (Yes, I think functionally it won't
> > be any changes if ->remove() is not needed, but for the sake of
> > logical correctness...)
>
> I'll do this. Thanks.
>
> Process question: If I make this change is it typical to remove all
> Reviewed-By tags? I assume "yes"
I would not. This change is logical continuation and I truly believe
every reviewer will agree on it.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 18:56 ` Vladimir Oltean
@ 2022-06-28 19:04 ` Andy Shevchenko
-1 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 19:04 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Colin Foster, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
>
> On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > dev_get_regmap(), maybe those could be of help?
>
> ah, I see I haven't really brought anything of value to the table,
> dev_get_regmap() was discussed around v1 or so. I'll read the
> discussions again in a couple of hours to remember what was wrong with
> it such that you aren't using it anymore.
It would be nice if you can comment after here to clarify that.
Because in another series (not related to this anyhow) somebody
insisted to use dev_get_regmap().
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 19:04 ` Andy Shevchenko
0 siblings, 0 replies; 82+ messages in thread
From: Andy Shevchenko @ 2022-06-28 19:04 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Colin Foster, devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
>
> On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > dev_get_regmap(), maybe those could be of help?
>
> ah, I see I haven't really brought anything of value to the table,
> dev_get_regmap() was discussed around v1 or so. I'll read the
> discussions again in a couple of hours to remember what was wrong with
> it such that you aren't using it anymore.
It would be nice if you can comment after here to clarify that.
Because in another series (not related to this anyhow) somebody
insisted to use dev_get_regmap().
--
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 19:04 ` Andy Shevchenko
@ 2022-06-28 19:56 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 19:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Vladimir Oltean, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 09:04:21PM +0200, Andy Shevchenko wrote:
> On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> >
> > On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > > dev_get_regmap(), maybe those could be of help?
> >
> > ah, I see I haven't really brought anything of value to the table,
> > dev_get_regmap() was discussed around v1 or so. I'll read the
> > discussions again in a couple of hours to remember what was wrong with
> > it such that you aren't using it anymore.
>
> It would be nice if you can comment after here to clarify that.
> Because in another series (not related to this anyhow) somebody
> insisted to use dev_get_regmap().
To add some info: The main issue at that time was "how do I get a spi
regmap instead of an mmio regmap from the device". V1 was very early,
and was before I knew about the pinctrl / mdio drivers that were to
come, so that led to the existing MFD implementation.
I came across the IORESOURCE_REG, which seems to be created for exactly
this purpose. Seemingly I'm pretty unique though, since IORESOURCE_REG
doesn't get used much compared to IORESOURCE_MEM.
Though I'll revisit this again. The switch portion of this driver (no
longer included in this patch set) is actually quite different from the
rest of the MFD in how it allocates regmaps, and that might have been
a major contributor at the time. So maybe I dismissed it at the time,
but it actually makes sense for the MFD portion 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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-28 19:56 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 19:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Vladimir Oltean, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 09:04:21PM +0200, Andy Shevchenko wrote:
> On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> >
> > On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > > dev_get_regmap(), maybe those could be of help?
> >
> > ah, I see I haven't really brought anything of value to the table,
> > dev_get_regmap() was discussed around v1 or so. I'll read the
> > discussions again in a couple of hours to remember what was wrong with
> > it such that you aren't using it anymore.
>
> It would be nice if you can comment after here to clarify that.
> Because in another series (not related to this anyhow) somebody
> insisted to use dev_get_regmap().
To add some info: The main issue at that time was "how do I get a spi
regmap instead of an mmio regmap from the device". V1 was very early,
and was before I knew about the pinctrl / mdio drivers that were to
come, so that led to the existing MFD implementation.
I came across the IORESOURCE_REG, which seems to be created for exactly
this purpose. Seemingly I'm pretty unique though, since IORESOURCE_REG
doesn't get used much compared to IORESOURCE_MEM.
Though I'll revisit this again. The switch portion of this driver (no
longer included in this patch set) is actually quite different from the
rest of the MFD in how it allocates regmaps, and that might have been
a major contributor at the time. So maybe I dismissed it at the time,
but it actually makes sense for the MFD portion now.
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-06-28 8:17 ` Colin Foster
@ 2022-06-28 20:07 ` Randy Dunlap
-1 siblings, 0 replies; 82+ messages in thread
From: Randy Dunlap @ 2022-06-28 20:07 UTC (permalink / raw)
To: Colin Foster, 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
On 6/28/22 01:17, Colin Foster wrote:
> --- 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
> + bool "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 pictrl, MDIO, and communication with
Is that pinctrl,
?
> + 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.
--
~Randy
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-06-28 20:07 ` Randy Dunlap
0 siblings, 0 replies; 82+ messages in thread
From: Randy Dunlap @ 2022-06-28 20:07 UTC (permalink / raw)
To: Colin Foster, 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
On 6/28/22 01:17, Colin Foster wrote:
> --- 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
> + bool "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 pictrl, MDIO, and communication with
Is that pinctrl,
?
> + 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.
--
~Randy
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
2022-06-28 20:07 ` Randy Dunlap
@ 2022-06-28 20:24 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 20:24 UTC (permalink / raw)
To: Randy Dunlap
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, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko
On Tue, Jun 28, 2022 at 01:07:51PM -0700, Randy Dunlap wrote:
>
>
> On 6/28/22 01:17, Colin Foster wrote:
> > --- 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
> > + bool "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 pictrl, MDIO, and communication with
>
> Is that pinctrl,
> ?
Yep. Good catch. Thanks!
>
> > + 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.
>
> --
> ~Randy
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-06-28 20:24 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-28 20:24 UTC (permalink / raw)
To: Randy Dunlap
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, Jakub Kicinski, Paolo Abeni, Lars Povlsen,
Steen Hegelund, UNGLinuxDriver, Linus Walleij, Wolfram Sang,
Terry Bowman, Andy Shevchenko
On Tue, Jun 28, 2022 at 01:07:51PM -0700, Randy Dunlap wrote:
>
>
> On 6/28/22 01:17, Colin Foster wrote:
> > --- 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
> > + bool "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 pictrl, MDIO, and communication with
>
> Is that pinctrl,
> ?
Yep. Good catch. Thanks!
>
> > + 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.
>
> --
> ~Randy
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-28 19:56 ` Colin Foster
@ 2022-06-29 17:53 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-29 17:53 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 12:56:54PM -0700, Colin Foster wrote:
> On Tue, Jun 28, 2022 at 09:04:21PM +0200, Andy Shevchenko wrote:
> > On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> > >
> > > On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > > > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > > > dev_get_regmap(), maybe those could be of help?
> > >
> > > ah, I see I haven't really brought anything of value to the table,
> > > dev_get_regmap() was discussed around v1 or so. I'll read the
> > > discussions again in a couple of hours to remember what was wrong with
> > > it such that you aren't using it anymore.
> >
> > It would be nice if you can comment after here to clarify that.
> > Because in another series (not related to this anyhow) somebody
> > insisted to use dev_get_regmap().
>
> To add some info: The main issue at that time was "how do I get a spi
> regmap instead of an mmio regmap from the device". V1 was very early,
> and was before I knew about the pinctrl / mdio drivers that were to
> come, so that led to the existing MFD implementation.
>
> I came across the IORESOURCE_REG, which seems to be created for exactly
> this purpose. Seemingly I'm pretty unique though, since IORESOURCE_REG
> doesn't get used much compared to IORESOURCE_MEM.
>
> Though I'll revisit this again. The switch portion of this driver (no
> longer included in this patch set) is actually quite different from the
> rest of the MFD in how it allocates regmaps, and that might have been
> a major contributor at the time. So maybe I dismissed it at the time,
> but it actually makes sense for the MFD portion now.
I'm sorry, I can't actually understand what went wrong, I'll need some
help from you, Colin.
So during your RFC v1 and then v1 proper (Nov. 19, 2021), you talked
about dev_get_regmap(dev->parent, res->name) yourself and proposed a
relatively simple interface where the mfd child drivers would just
request a regmap by its name:
https://patchwork.kernel.org/project/netdevbpf/patch/20211119224313.2803941-4-colin.foster@in-advantage.com/
In fact you implemented just this (Dec. 6, 2021):
https://patchwork.kernel.org/project/netdevbpf/patch/20211203211611.946658-1-colin.foster@in-advantage.com/#24637477
it's just that the pattern went something like:
@@ -1368,7 +1369,11 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
- info->map = devm_regmap_init_mmio(dev, base, ®map_config);
+ if (device_is_mfd(pdev))
+ info->map = dev_get_regmap(dev->parent, "GCB");
+ else
+ info->map = devm_regmap_init_mmio(dev, base, ®map_config);
where Lee Jones (rightfully) commented asking why can't you just first
check whether dev->parent has any GCB regmap to give you, and only then
resort to call devm_regmap_init_mmio? A small comment with a small
and pretty actionable change to be made.
As best as I can tell, RFC v5 (Dec. 18, 2021) is the first version after
v1 where you came back with proposed mfd patches:
https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-2-colin.foster@in-advantage.com/
And while dev_get_regmap() was technically still there, its usage
pattern changed radically. It was now just used as a sort of
optimization in ocelot_mfd_regmap_init() to not create twice a regmap
that already existed.
What you introduced in RFC v5 instead was this "interface for MFD
children to get regmaps":
https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-3-colin.foster@in-advantage.com/
to which Lee replied that "This is almost certainly not the right way to
do whatever it is you're trying to do!"
And rightfully so. What happened to dev_get_regmap() as the "interface
for MFD children to get regmaps" I wonder?
dev_get_regmap() just wants a name, not a full blown resource.
When you're a mfd child, you don't have a full resource, you just know
the name of the regmap you want to use. Only the top dog needs to have
access to the resources. And DSA as a MFD child is not top dog.
So of course I expect it to change. Otherwise said, what is currently
done in felix_init_structs() needs to be more or less replicated in its
entirety in drivers/mfd/ocelot-core.c.
All the regmaps of the switch SoC, created at mfd parent probe time, not
on demand, and attached via devres to the mfd parent device, so that
children can get them via dev_get_regmap.
Next thing would be to modify the felix DSA driver so that it only
attempts to create regmaps if it can do so (if it has the resource
structures). If it doesn't have the resource structures, it calls
dev_get_regmap(ocelot->dev->parent, target->name) and tries to get the
regmaps that way. If that fails => so sad, too bad, fail to probe, bye.
The point is that the ocelot-ext driver you're trying to introduce
should have no resources in struct resource *target_io_res, *port_io_res,
*imdio_res, etc. I really don't know why you're so fixated on this
"regmap from resource" thing when the resource shouldn't even be of
concern to the driver when used as a mfd child.
The contract is _not_ "here's the resource, give me the regmap".
The contract is "I want the regmap named XXX". And in order to fulfill
that contract, a mfd child driver should _not_ call a symbol exported by
the ocelot parent driver directly (for the builtin vs module dependency
reasons you've mentioned yourself), but get the regmap from the list of
regmaps managed by devres using devm_regmap_init().
Yes, there would need to exist a split between the target strings and
their start and end offsets, because the ocelot-ext driver would still
call dev_get_regmap() by the name. But that's a fairly minor rework, and
by the way, it turns out that the introduction of felix->info->init_regmap()
was indeed not the right thing to do, so you'll need to change that again.
I am really not sure what went with the plan above. You said a while ago
that you don't like the fact that regmaps exist in the parent
independently of the drivers that use them and continue to do so even
after the children unbind, and that feels "wrong". Yes, because?
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-29 17:53 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-29 17:53 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Tue, Jun 28, 2022 at 12:56:54PM -0700, Colin Foster wrote:
> On Tue, Jun 28, 2022 at 09:04:21PM +0200, Andy Shevchenko wrote:
> > On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> > >
> > > On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > > > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > > > dev_get_regmap(), maybe those could be of help?
> > >
> > > ah, I see I haven't really brought anything of value to the table,
> > > dev_get_regmap() was discussed around v1 or so. I'll read the
> > > discussions again in a couple of hours to remember what was wrong with
> > > it such that you aren't using it anymore.
> >
> > It would be nice if you can comment after here to clarify that.
> > Because in another series (not related to this anyhow) somebody
> > insisted to use dev_get_regmap().
>
> To add some info: The main issue at that time was "how do I get a spi
> regmap instead of an mmio regmap from the device". V1 was very early,
> and was before I knew about the pinctrl / mdio drivers that were to
> come, so that led to the existing MFD implementation.
>
> I came across the IORESOURCE_REG, which seems to be created for exactly
> this purpose. Seemingly I'm pretty unique though, since IORESOURCE_REG
> doesn't get used much compared to IORESOURCE_MEM.
>
> Though I'll revisit this again. The switch portion of this driver (no
> longer included in this patch set) is actually quite different from the
> rest of the MFD in how it allocates regmaps, and that might have been
> a major contributor at the time. So maybe I dismissed it at the time,
> but it actually makes sense for the MFD portion now.
I'm sorry, I can't actually understand what went wrong, I'll need some
help from you, Colin.
So during your RFC v1 and then v1 proper (Nov. 19, 2021), you talked
about dev_get_regmap(dev->parent, res->name) yourself and proposed a
relatively simple interface where the mfd child drivers would just
request a regmap by its name:
https://patchwork.kernel.org/project/netdevbpf/patch/20211119224313.2803941-4-colin.foster@in-advantage.com/
In fact you implemented just this (Dec. 6, 2021):
https://patchwork.kernel.org/project/netdevbpf/patch/20211203211611.946658-1-colin.foster@in-advantage.com/#24637477
it's just that the pattern went something like:
@@ -1368,7 +1369,11 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
- info->map = devm_regmap_init_mmio(dev, base, ®map_config);
+ if (device_is_mfd(pdev))
+ info->map = dev_get_regmap(dev->parent, "GCB");
+ else
+ info->map = devm_regmap_init_mmio(dev, base, ®map_config);
where Lee Jones (rightfully) commented asking why can't you just first
check whether dev->parent has any GCB regmap to give you, and only then
resort to call devm_regmap_init_mmio? A small comment with a small
and pretty actionable change to be made.
As best as I can tell, RFC v5 (Dec. 18, 2021) is the first version after
v1 where you came back with proposed mfd patches:
https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-2-colin.foster@in-advantage.com/
And while dev_get_regmap() was technically still there, its usage
pattern changed radically. It was now just used as a sort of
optimization in ocelot_mfd_regmap_init() to not create twice a regmap
that already existed.
What you introduced in RFC v5 instead was this "interface for MFD
children to get regmaps":
https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-3-colin.foster@in-advantage.com/
to which Lee replied that "This is almost certainly not the right way to
do whatever it is you're trying to do!"
And rightfully so. What happened to dev_get_regmap() as the "interface
for MFD children to get regmaps" I wonder?
dev_get_regmap() just wants a name, not a full blown resource.
When you're a mfd child, you don't have a full resource, you just know
the name of the regmap you want to use. Only the top dog needs to have
access to the resources. And DSA as a MFD child is not top dog.
So of course I expect it to change. Otherwise said, what is currently
done in felix_init_structs() needs to be more or less replicated in its
entirety in drivers/mfd/ocelot-core.c.
All the regmaps of the switch SoC, created at mfd parent probe time, not
on demand, and attached via devres to the mfd parent device, so that
children can get them via dev_get_regmap.
Next thing would be to modify the felix DSA driver so that it only
attempts to create regmaps if it can do so (if it has the resource
structures). If it doesn't have the resource structures, it calls
dev_get_regmap(ocelot->dev->parent, target->name) and tries to get the
regmaps that way. If that fails => so sad, too bad, fail to probe, bye.
The point is that the ocelot-ext driver you're trying to introduce
should have no resources in struct resource *target_io_res, *port_io_res,
*imdio_res, etc. I really don't know why you're so fixated on this
"regmap from resource" thing when the resource shouldn't even be of
concern to the driver when used as a mfd child.
The contract is _not_ "here's the resource, give me the regmap".
The contract is "I want the regmap named XXX". And in order to fulfill
that contract, a mfd child driver should _not_ call a symbol exported by
the ocelot parent driver directly (for the builtin vs module dependency
reasons you've mentioned yourself), but get the regmap from the list of
regmaps managed by devres using devm_regmap_init().
Yes, there would need to exist a split between the target strings and
their start and end offsets, because the ocelot-ext driver would still
call dev_get_regmap() by the name. But that's a fairly minor rework, and
by the way, it turns out that the introduction of felix->info->init_regmap()
was indeed not the right thing to do, so you'll need to change that again.
I am really not sure what went with the plan above. You said a while ago
that you don't like the fact that regmaps exist in the parent
independently of the drivers that use them and continue to do so even
after the children unbind, and that feels "wrong". Yes, because?
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-29 17:53 ` Vladimir Oltean
@ 2022-06-29 20:39 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-29 20:39 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
Hi Vladimir,
Wow, thanks for the summary! This is jogging my memory.
On Wed, Jun 29, 2022 at 05:53:06PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 12:56:54PM -0700, Colin Foster wrote:
> > On Tue, Jun 28, 2022 at 09:04:21PM +0200, Andy Shevchenko wrote:
> > > On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> > > >
> > > > On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > > > > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > > > > dev_get_regmap(), maybe those could be of help?
> > > >
> > > > ah, I see I haven't really brought anything of value to the table,
> > > > dev_get_regmap() was discussed around v1 or so. I'll read the
> > > > discussions again in a couple of hours to remember what was wrong with
> > > > it such that you aren't using it anymore.
> > >
> > > It would be nice if you can comment after here to clarify that.
> > > Because in another series (not related to this anyhow) somebody
> > > insisted to use dev_get_regmap().
> >
> > To add some info: The main issue at that time was "how do I get a spi
> > regmap instead of an mmio regmap from the device". V1 was very early,
> > and was before I knew about the pinctrl / mdio drivers that were to
> > come, so that led to the existing MFD implementation.
> >
> > I came across the IORESOURCE_REG, which seems to be created for exactly
> > this purpose. Seemingly I'm pretty unique though, since IORESOURCE_REG
> > doesn't get used much compared to IORESOURCE_MEM.
> >
> > Though I'll revisit this again. The switch portion of this driver (no
> > longer included in this patch set) is actually quite different from the
> > rest of the MFD in how it allocates regmaps, and that might have been
> > a major contributor at the time. So maybe I dismissed it at the time,
> > but it actually makes sense for the MFD portion now.
>
> I'm sorry, I can't actually understand what went wrong, I'll need some
> help from you, Colin.
>
> So during your RFC v1 and then v1 proper (Nov. 19, 2021), you talked
> about dev_get_regmap(dev->parent, res->name) yourself and proposed a
> relatively simple interface where the mfd child drivers would just
> request a regmap by its name:
> https://patchwork.kernel.org/project/netdevbpf/patch/20211119224313.2803941-4-colin.foster@in-advantage.com/
>
> In fact you implemented just this (Dec. 6, 2021):
> https://patchwork.kernel.org/project/netdevbpf/patch/20211203211611.946658-1-colin.foster@in-advantage.com/#24637477
> it's just that the pattern went something like:
>
> @@ -1368,7 +1369,11 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
> regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
>
> - info->map = devm_regmap_init_mmio(dev, base, ®map_config);
> + if (device_is_mfd(pdev))
> + info->map = dev_get_regmap(dev->parent, "GCB");
> + else
> + info->map = devm_regmap_init_mmio(dev, base, ®map_config);
>
> where Lee Jones (rightfully) commented asking why can't you just first
> check whether dev->parent has any GCB regmap to give you, and only then
> resort to call devm_regmap_init_mmio? A small comment with a small
> and pretty actionable change to be made.
>
>
> As best as I can tell, RFC v5 (Dec. 18, 2021) is the first version after
> v1 where you came back with proposed mfd patches:
> https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-2-colin.foster@in-advantage.com/
>
> And while dev_get_regmap() was technically still there, its usage
> pattern changed radically. It was now just used as a sort of
> optimization in ocelot_mfd_regmap_init() to not create twice a regmap
> that already existed.
> What you introduced in RFC v5 instead was this "interface for MFD
> children to get regmaps":
> https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-3-colin.foster@in-advantage.com/
>
> to which Lee replied that "This is almost certainly not the right way to
> do whatever it is you're trying to do!"
>
> And rightfully so. What happened to dev_get_regmap() as the "interface
> for MFD children to get regmaps" I wonder?
> dev_get_regmap() just wants a name, not a full blown resource.
> When you're a mfd child, you don't have a full resource, you just know
> the name of the regmap you want to use. Only the top dog needs to have
> access to the resources. And DSA as a MFD child is not top dog.
> So of course I expect it to change. Otherwise said, what is currently
> done in felix_init_structs() needs to be more or less replicated in its
> entirety in drivers/mfd/ocelot-core.c.
> All the regmaps of the switch SoC, created at mfd parent probe time, not
> on demand, and attached via devres to the mfd parent device, so that
> children can get them via dev_get_regmap.
>
I think you're pointing out exactly where I went wrong. And I think it
might be related to my starting with the felix dsa driver before
migrating to the MFD setup.
My misconception was "the felix dsa driver should be able to create whatever
regmaps from resources it needs" and maybe I was being to optimistic
that I wouldn't need to change felix dsa's implementation. Or naive.
> Next thing would be to modify the felix DSA driver so that it only
> attempts to create regmaps if it can do so (if it has the resource
> structures). If it doesn't have the resource structures, it calls
> dev_get_regmap(ocelot->dev->parent, target->name) and tries to get the
> regmaps that way. If that fails => so sad, too bad, fail to probe, bye.
>
> The point is that the ocelot-ext driver you're trying to introduce
> should have no resources in struct resource *target_io_res, *port_io_res,
> *imdio_res, etc. I really don't know why you're so fixated on this
> "regmap from resource" thing when the resource shouldn't even be of
> concern to the driver when used as a mfd child.
>
> The contract is _not_ "here's the resource, give me the regmap".
> The contract is "I want the regmap named XXX". And in order to fulfill
> that contract, a mfd child driver should _not_ call a symbol exported by
> the ocelot parent driver directly (for the builtin vs module dependency
> reasons you've mentioned yourself), but get the regmap from the list of
> regmaps managed by devres using devm_regmap_init().
>
> Yes, there would need to exist a split between the target strings and
> their start and end offsets, because the ocelot-ext driver would still
> call dev_get_regmap() by the name. But that's a fairly minor rework, and
> by the way, it turns out that the introduction of felix->info->init_regmap()
> was indeed not the right thing to do, so you'll need to change that again.
>
> I am really not sure what went with the plan above. You said a while ago
> that you don't like the fact that regmaps exist in the parent
> independently of the drivers that use them and continue to do so even
> after the children unbind, and that feels "wrong". Yes, because?
I liked the idea of the MFD being "code complete" so if future regmaps
were needed for the felix dsa driver came about, it wouldn't require
changes to the "parent." But I think that was a bad goal - especially
since MFD requires all the resources anyway.
Also at the time, I was trying a hybrid "create it if it doesn't exist,
return it if was already created" approach. I backed that out after an
RFC.
Focusing only on the non-felix drivers: it seems trivial for the parent
to create _all_ the possible child regmaps, register them to the parent
via by way of regmap_attach_dev().
At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
initalize like (untested, and apologies for indentation):
regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(regs)) {
map = dev_get_regmap(dev->parent, name);
} else {
map = devm_regmap_init_mmio(dev, regs, config);
}
In that case, "name" would either be hard-coded to match what is in
drivers/mfd/ocelot-core.c. The other option is to fall back to
platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
resource->name. I'll be able to deal with that when I try it. (hopefully
this evening)
This seems to be a solid design that I missed! As you mention, it'll
require changes to felix dsa... but not as much as I had feared. And I
think it solves all my fears about modules to boot. This seems too good
to be true - but maybe I was too deep and needed to take this step back.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-29 20:39 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-29 20:39 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
Hi Vladimir,
Wow, thanks for the summary! This is jogging my memory.
On Wed, Jun 29, 2022 at 05:53:06PM +0000, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 12:56:54PM -0700, Colin Foster wrote:
> > On Tue, Jun 28, 2022 at 09:04:21PM +0200, Andy Shevchenko wrote:
> > > On Tue, Jun 28, 2022 at 8:56 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> > > >
> > > > On Tue, Jun 28, 2022 at 09:46:59PM +0300, Vladimir Oltean wrote:
> > > > > I searched for 5 minutes or so, and I noticed regmap_attach_dev() and
> > > > > dev_get_regmap(), maybe those could be of help?
> > > >
> > > > ah, I see I haven't really brought anything of value to the table,
> > > > dev_get_regmap() was discussed around v1 or so. I'll read the
> > > > discussions again in a couple of hours to remember what was wrong with
> > > > it such that you aren't using it anymore.
> > >
> > > It would be nice if you can comment after here to clarify that.
> > > Because in another series (not related to this anyhow) somebody
> > > insisted to use dev_get_regmap().
> >
> > To add some info: The main issue at that time was "how do I get a spi
> > regmap instead of an mmio regmap from the device". V1 was very early,
> > and was before I knew about the pinctrl / mdio drivers that were to
> > come, so that led to the existing MFD implementation.
> >
> > I came across the IORESOURCE_REG, which seems to be created for exactly
> > this purpose. Seemingly I'm pretty unique though, since IORESOURCE_REG
> > doesn't get used much compared to IORESOURCE_MEM.
> >
> > Though I'll revisit this again. The switch portion of this driver (no
> > longer included in this patch set) is actually quite different from the
> > rest of the MFD in how it allocates regmaps, and that might have been
> > a major contributor at the time. So maybe I dismissed it at the time,
> > but it actually makes sense for the MFD portion now.
>
> I'm sorry, I can't actually understand what went wrong, I'll need some
> help from you, Colin.
>
> So during your RFC v1 and then v1 proper (Nov. 19, 2021), you talked
> about dev_get_regmap(dev->parent, res->name) yourself and proposed a
> relatively simple interface where the mfd child drivers would just
> request a regmap by its name:
> https://patchwork.kernel.org/project/netdevbpf/patch/20211119224313.2803941-4-colin.foster@in-advantage.com/
>
> In fact you implemented just this (Dec. 6, 2021):
> https://patchwork.kernel.org/project/netdevbpf/patch/20211203211611.946658-1-colin.foster@in-advantage.com/#24637477
> it's just that the pattern went something like:
>
> @@ -1368,7 +1369,11 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
> regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
>
> - info->map = devm_regmap_init_mmio(dev, base, ®map_config);
> + if (device_is_mfd(pdev))
> + info->map = dev_get_regmap(dev->parent, "GCB");
> + else
> + info->map = devm_regmap_init_mmio(dev, base, ®map_config);
>
> where Lee Jones (rightfully) commented asking why can't you just first
> check whether dev->parent has any GCB regmap to give you, and only then
> resort to call devm_regmap_init_mmio? A small comment with a small
> and pretty actionable change to be made.
>
>
> As best as I can tell, RFC v5 (Dec. 18, 2021) is the first version after
> v1 where you came back with proposed mfd patches:
> https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-2-colin.foster@in-advantage.com/
>
> And while dev_get_regmap() was technically still there, its usage
> pattern changed radically. It was now just used as a sort of
> optimization in ocelot_mfd_regmap_init() to not create twice a regmap
> that already existed.
> What you introduced in RFC v5 instead was this "interface for MFD
> children to get regmaps":
> https://patchwork.kernel.org/project/netdevbpf/patch/20211218214954.109755-3-colin.foster@in-advantage.com/
>
> to which Lee replied that "This is almost certainly not the right way to
> do whatever it is you're trying to do!"
>
> And rightfully so. What happened to dev_get_regmap() as the "interface
> for MFD children to get regmaps" I wonder?
> dev_get_regmap() just wants a name, not a full blown resource.
> When you're a mfd child, you don't have a full resource, you just know
> the name of the regmap you want to use. Only the top dog needs to have
> access to the resources. And DSA as a MFD child is not top dog.
> So of course I expect it to change. Otherwise said, what is currently
> done in felix_init_structs() needs to be more or less replicated in its
> entirety in drivers/mfd/ocelot-core.c.
> All the regmaps of the switch SoC, created at mfd parent probe time, not
> on demand, and attached via devres to the mfd parent device, so that
> children can get them via dev_get_regmap.
>
I think you're pointing out exactly where I went wrong. And I think it
might be related to my starting with the felix dsa driver before
migrating to the MFD setup.
My misconception was "the felix dsa driver should be able to create whatever
regmaps from resources it needs" and maybe I was being to optimistic
that I wouldn't need to change felix dsa's implementation. Or naive.
> Next thing would be to modify the felix DSA driver so that it only
> attempts to create regmaps if it can do so (if it has the resource
> structures). If it doesn't have the resource structures, it calls
> dev_get_regmap(ocelot->dev->parent, target->name) and tries to get the
> regmaps that way. If that fails => so sad, too bad, fail to probe, bye.
>
> The point is that the ocelot-ext driver you're trying to introduce
> should have no resources in struct resource *target_io_res, *port_io_res,
> *imdio_res, etc. I really don't know why you're so fixated on this
> "regmap from resource" thing when the resource shouldn't even be of
> concern to the driver when used as a mfd child.
>
> The contract is _not_ "here's the resource, give me the regmap".
> The contract is "I want the regmap named XXX". And in order to fulfill
> that contract, a mfd child driver should _not_ call a symbol exported by
> the ocelot parent driver directly (for the builtin vs module dependency
> reasons you've mentioned yourself), but get the regmap from the list of
> regmaps managed by devres using devm_regmap_init().
>
> Yes, there would need to exist a split between the target strings and
> their start and end offsets, because the ocelot-ext driver would still
> call dev_get_regmap() by the name. But that's a fairly minor rework, and
> by the way, it turns out that the introduction of felix->info->init_regmap()
> was indeed not the right thing to do, so you'll need to change that again.
>
> I am really not sure what went with the plan above. You said a while ago
> that you don't like the fact that regmaps exist in the parent
> independently of the drivers that use them and continue to do so even
> after the children unbind, and that feels "wrong". Yes, because?
I liked the idea of the MFD being "code complete" so if future regmaps
were needed for the felix dsa driver came about, it wouldn't require
changes to the "parent." But I think that was a bad goal - especially
since MFD requires all the resources anyway.
Also at the time, I was trying a hybrid "create it if it doesn't exist,
return it if was already created" approach. I backed that out after an
RFC.
Focusing only on the non-felix drivers: it seems trivial for the parent
to create _all_ the possible child regmaps, register them to the parent
via by way of regmap_attach_dev().
At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
initalize like (untested, and apologies for indentation):
regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(regs)) {
map = dev_get_regmap(dev->parent, name);
} else {
map = devm_regmap_init_mmio(dev, regs, config);
}
In that case, "name" would either be hard-coded to match what is in
drivers/mfd/ocelot-core.c. The other option is to fall back to
platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
resource->name. I'll be able to deal with that when I try it. (hopefully
this evening)
This seems to be a solid design that I missed! As you mention, it'll
require changes to felix dsa... but not as much as I had feared. And I
think it solves all my fears about modules to boot. This seems too good
to be true - but maybe I was too deep and needed to take this step back.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-29 20:39 ` Colin Foster
@ 2022-06-29 23:08 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-29 23:08 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, Jun 29, 2022 at 01:39:05PM -0700, Colin Foster wrote:
> I liked the idea of the MFD being "code complete" so if future regmaps
> were needed for the felix dsa driver came about, it wouldn't require
> changes to the "parent." But I think that was a bad goal - especially
> since MFD requires all the resources anyway.
>
> Also at the time, I was trying a hybrid "create it if it doesn't exist,
> return it if was already created" approach. I backed that out after an
> RFC.
>
> Focusing only on the non-felix drivers: it seems trivial for the parent
> to create _all_ the possible child regmaps, register them to the parent
> via by way of regmap_attach_dev().
>
> At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
> initalize like (untested, and apologies for indentation):
>
> regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> if (IS_ERR(regs)) {
> map = dev_get_regmap(dev->parent, name);
> } else {
> map = devm_regmap_init_mmio(dev, regs, config);
> }
Again, those dev_err(dev, "invalid resource\n"); prints you were
complaining about earlier are self-inflicted IMO, and caused exactly by
this pattern. I get why you prefer to call larger building blocks if
possible, but in this case, devm_platform_get_and_ioremap_resource()
calls exactly 2 sub-functions: platform_get_resource() and
devm_ioremap_resource(). The IS_ERR() that you check for is caused by
devm_ioremap_resource() being passed a NULL pointer, and same goes for
the print. Just call them individually, and put your dev_get_regmap()
hook in case platform_get_resource() returns NULL, rather than passing
NULL to devm_ioremap_resource() and waiting for that to fail.
> In that case, "name" would either be hard-coded to match what is in
> drivers/mfd/ocelot-core.c. The other option is to fall back to
> platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> resource->name. I'll be able to deal with that when I try it. (hopefully
> this evening)
I'm not exactly clear on what you'd do with the REG resource once you
get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
from the device tree, what next, who's going to set up the SPI regmap
for you?
> This seems to be a solid design that I missed! As you mention, it'll
> require changes to felix dsa... but not as much as I had feared. And I
> think it solves all my fears about modules to boot. This seems too good
> to be true - but maybe I was too deep and needed to take this step back.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-29 23:08 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-29 23:08 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, Jun 29, 2022 at 01:39:05PM -0700, Colin Foster wrote:
> I liked the idea of the MFD being "code complete" so if future regmaps
> were needed for the felix dsa driver came about, it wouldn't require
> changes to the "parent." But I think that was a bad goal - especially
> since MFD requires all the resources anyway.
>
> Also at the time, I was trying a hybrid "create it if it doesn't exist,
> return it if was already created" approach. I backed that out after an
> RFC.
>
> Focusing only on the non-felix drivers: it seems trivial for the parent
> to create _all_ the possible child regmaps, register them to the parent
> via by way of regmap_attach_dev().
>
> At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
> initalize like (untested, and apologies for indentation):
>
> regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> if (IS_ERR(regs)) {
> map = dev_get_regmap(dev->parent, name);
> } else {
> map = devm_regmap_init_mmio(dev, regs, config);
> }
Again, those dev_err(dev, "invalid resource\n"); prints you were
complaining about earlier are self-inflicted IMO, and caused exactly by
this pattern. I get why you prefer to call larger building blocks if
possible, but in this case, devm_platform_get_and_ioremap_resource()
calls exactly 2 sub-functions: platform_get_resource() and
devm_ioremap_resource(). The IS_ERR() that you check for is caused by
devm_ioremap_resource() being passed a NULL pointer, and same goes for
the print. Just call them individually, and put your dev_get_regmap()
hook in case platform_get_resource() returns NULL, rather than passing
NULL to devm_ioremap_resource() and waiting for that to fail.
> In that case, "name" would either be hard-coded to match what is in
> drivers/mfd/ocelot-core.c. The other option is to fall back to
> platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> resource->name. I'll be able to deal with that when I try it. (hopefully
> this evening)
I'm not exactly clear on what you'd do with the REG resource once you
get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
from the device tree, what next, who's going to set up the SPI regmap
for you?
> This seems to be a solid design that I missed! As you mention, it'll
> require changes to felix dsa... but not as much as I had feared. And I
> think it solves all my fears about modules to boot. This seems too good
> to be true - but maybe I was too deep and needed to take this step back.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-29 23:08 ` Vladimir Oltean
@ 2022-06-29 23:54 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-29 23:54 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, Jun 29, 2022 at 11:08:05PM +0000, Vladimir Oltean wrote:
> On Wed, Jun 29, 2022 at 01:39:05PM -0700, Colin Foster wrote:
> > I liked the idea of the MFD being "code complete" so if future regmaps
> > were needed for the felix dsa driver came about, it wouldn't require
> > changes to the "parent." But I think that was a bad goal - especially
> > since MFD requires all the resources anyway.
> >
> > Also at the time, I was trying a hybrid "create it if it doesn't exist,
> > return it if was already created" approach. I backed that out after an
> > RFC.
> >
> > Focusing only on the non-felix drivers: it seems trivial for the parent
> > to create _all_ the possible child regmaps, register them to the parent
> > via by way of regmap_attach_dev().
> >
> > At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
> > initalize like (untested, and apologies for indentation):
> >
> > regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> > if (IS_ERR(regs)) {
> > map = dev_get_regmap(dev->parent, name);
> > } else {
> > map = devm_regmap_init_mmio(dev, regs, config);
> > }
>
> Again, those dev_err(dev, "invalid resource\n"); prints you were
> complaining about earlier are self-inflicted IMO, and caused exactly by
> this pattern. I get why you prefer to call larger building blocks if
> possible, but in this case, devm_platform_get_and_ioremap_resource()
> calls exactly 2 sub-functions: platform_get_resource() and
> devm_ioremap_resource(). The IS_ERR() that you check for is caused by
> devm_ioremap_resource() being passed a NULL pointer, and same goes for
> the print. Just call them individually, and put your dev_get_regmap()
> hook in case platform_get_resource() returns NULL, rather than passing
> NULL to devm_ioremap_resource() and waiting for that to fail.
I see that now. Hoping this next version removes a lot of this
unnecessary complexity.
>
> > In that case, "name" would either be hard-coded to match what is in
> > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > resource->name. I'll be able to deal with that when I try it. (hopefully
> > this evening)
>
> I'm not exactly clear on what you'd do with the REG resource once you
> get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> from the device tree, what next, who's going to set up the SPI regmap
> for you?
The REG resource would only get the resource name, while the MFD core
driver would set up the regmaps.
e.g. drivers/mfd/ocelot-core.c has (annotated):
static const struct resource vsc7512_sgpio_resources[] = {
DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
gpio resource, and gets the resource by index.
So for this there seem to be two options:
Option 1:
drivers/pinctrl/pinctrl-ocelot.c:
res = platform_get_resource(pdev, IORESOURCE_REG, 0);
map = dev_get_regmap(dev->parent, res->name);
OR Option 2:
include/linux/mfd/ocelot.h has something like:
#define GCB_GPIO_REGMAP_NAME "gcb_gpio"
and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
(With error checking, macro reuse, etc.)
I like option 1, since it then makes ocelot-pinctrl.c have no reliance
on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
set up in advance during the start of ocelot_core_init, just before
devm_mfd_add_devices is called.
I should be able to test this all tonight.
>
> > This seems to be a solid design that I missed! As you mention, it'll
> > require changes to felix dsa... but not as much as I had feared. And I
> > think it solves all my fears about modules to boot. This seems too good
> > to be true - but maybe I was too deep and needed to take this step back.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-29 23:54 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-29 23:54 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, Jun 29, 2022 at 11:08:05PM +0000, Vladimir Oltean wrote:
> On Wed, Jun 29, 2022 at 01:39:05PM -0700, Colin Foster wrote:
> > I liked the idea of the MFD being "code complete" so if future regmaps
> > were needed for the felix dsa driver came about, it wouldn't require
> > changes to the "parent." But I think that was a bad goal - especially
> > since MFD requires all the resources anyway.
> >
> > Also at the time, I was trying a hybrid "create it if it doesn't exist,
> > return it if was already created" approach. I backed that out after an
> > RFC.
> >
> > Focusing only on the non-felix drivers: it seems trivial for the parent
> > to create _all_ the possible child regmaps, register them to the parent
> > via by way of regmap_attach_dev().
> >
> > At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
> > initalize like (untested, and apologies for indentation):
> >
> > regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> > if (IS_ERR(regs)) {
> > map = dev_get_regmap(dev->parent, name);
> > } else {
> > map = devm_regmap_init_mmio(dev, regs, config);
> > }
>
> Again, those dev_err(dev, "invalid resource\n"); prints you were
> complaining about earlier are self-inflicted IMO, and caused exactly by
> this pattern. I get why you prefer to call larger building blocks if
> possible, but in this case, devm_platform_get_and_ioremap_resource()
> calls exactly 2 sub-functions: platform_get_resource() and
> devm_ioremap_resource(). The IS_ERR() that you check for is caused by
> devm_ioremap_resource() being passed a NULL pointer, and same goes for
> the print. Just call them individually, and put your dev_get_regmap()
> hook in case platform_get_resource() returns NULL, rather than passing
> NULL to devm_ioremap_resource() and waiting for that to fail.
I see that now. Hoping this next version removes a lot of this
unnecessary complexity.
>
> > In that case, "name" would either be hard-coded to match what is in
> > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > resource->name. I'll be able to deal with that when I try it. (hopefully
> > this evening)
>
> I'm not exactly clear on what you'd do with the REG resource once you
> get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> from the device tree, what next, who's going to set up the SPI regmap
> for you?
The REG resource would only get the resource name, while the MFD core
driver would set up the regmaps.
e.g. drivers/mfd/ocelot-core.c has (annotated):
static const struct resource vsc7512_sgpio_resources[] = {
DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
gpio resource, and gets the resource by index.
So for this there seem to be two options:
Option 1:
drivers/pinctrl/pinctrl-ocelot.c:
res = platform_get_resource(pdev, IORESOURCE_REG, 0);
map = dev_get_regmap(dev->parent, res->name);
OR Option 2:
include/linux/mfd/ocelot.h has something like:
#define GCB_GPIO_REGMAP_NAME "gcb_gpio"
and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
(With error checking, macro reuse, etc.)
I like option 1, since it then makes ocelot-pinctrl.c have no reliance
on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
set up in advance during the start of ocelot_core_init, just before
devm_mfd_add_devices is called.
I should be able to test this all tonight.
>
> > This seems to be a solid design that I missed! As you mention, it'll
> > require changes to felix dsa... but not as much as I had feared. And I
> > think it solves all my fears about modules to boot. This seems too good
> > to be true - but maybe I was too deep and needed to take this step back.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-29 23:54 ` Colin Foster
@ 2022-06-30 7:54 ` Lee Jones
-1 siblings, 0 replies; 82+ messages in thread
From: Lee Jones @ 2022-06-30 7:54 UTC (permalink / raw)
To: Colin Foster
Cc: Vladimir Oltean, Andy Shevchenko, devicetree, linux-kernel,
netdev, linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, 29 Jun 2022, Colin Foster wrote:
> On Wed, Jun 29, 2022 at 11:08:05PM +0000, Vladimir Oltean wrote:
> > On Wed, Jun 29, 2022 at 01:39:05PM -0700, Colin Foster wrote:
> > > I liked the idea of the MFD being "code complete" so if future regmaps
> > > were needed for the felix dsa driver came about, it wouldn't require
> > > changes to the "parent." But I think that was a bad goal - especially
> > > since MFD requires all the resources anyway.
> > >
> > > Also at the time, I was trying a hybrid "create it if it doesn't exist,
> > > return it if was already created" approach. I backed that out after an
> > > RFC.
> > >
> > > Focusing only on the non-felix drivers: it seems trivial for the parent
> > > to create _all_ the possible child regmaps, register them to the parent
> > > via by way of regmap_attach_dev().
> > >
> > > At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
> > > initalize like (untested, and apologies for indentation):
> > >
> > > regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> > > if (IS_ERR(regs)) {
> > > map = dev_get_regmap(dev->parent, name);
> > > } else {
> > > map = devm_regmap_init_mmio(dev, regs, config);
> > > }
> >
> > Again, those dev_err(dev, "invalid resource\n"); prints you were
> > complaining about earlier are self-inflicted IMO, and caused exactly by
> > this pattern. I get why you prefer to call larger building blocks if
> > possible, but in this case, devm_platform_get_and_ioremap_resource()
> > calls exactly 2 sub-functions: platform_get_resource() and
> > devm_ioremap_resource(). The IS_ERR() that you check for is caused by
> > devm_ioremap_resource() being passed a NULL pointer, and same goes for
> > the print. Just call them individually, and put your dev_get_regmap()
> > hook in case platform_get_resource() returns NULL, rather than passing
> > NULL to devm_ioremap_resource() and waiting for that to fail.
>
> I see that now. Hoping this next version removes a lot of this
> unnecessary complexity.
>
> >
> > > In that case, "name" would either be hard-coded to match what is in
> > > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > > resource->name. I'll be able to deal with that when I try it. (hopefully
> > > this evening)
> >
> > I'm not exactly clear on what you'd do with the REG resource once you
> > get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> > from the device tree, what next, who's going to set up the SPI regmap
> > for you?
>
> The REG resource would only get the resource name, while the MFD core
> driver would set up the regmaps.
>
> e.g. drivers/mfd/ocelot-core.c has (annotated):
> static const struct resource vsc7512_sgpio_resources[] = {
> DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
>
> Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
> gpio resource, and gets the resource by index.
>
> So for this there seem to be two options:
> Option 1:
> drivers/pinctrl/pinctrl-ocelot.c:
> res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> map = dev_get_regmap(dev->parent, res->name);
>
>
> OR Option 2:
> include/linux/mfd/ocelot.h has something like:
> #define GCB_GPIO_REGMAP_NAME "gcb_gpio"
>
> and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
> map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
>
> (With error checking, macro reuse, etc.)
>
>
> I like option 1, since it then makes ocelot-pinctrl.c have no reliance
> on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
> set up in advance during the start of ocelot_core_init, just before
> devm_mfd_add_devices is called.
>
>
> I should be able to test this all tonight.
Thank you Vladimir for stepping in to clarify previous points.
Well done both of you for this collaborative effort. Great to see!
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-30 7:54 ` Lee Jones
0 siblings, 0 replies; 82+ messages in thread
From: Lee Jones @ 2022-06-30 7:54 UTC (permalink / raw)
To: Colin Foster
Cc: Vladimir Oltean, Andy Shevchenko, devicetree, linux-kernel,
netdev, linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, 29 Jun 2022, Colin Foster wrote:
> On Wed, Jun 29, 2022 at 11:08:05PM +0000, Vladimir Oltean wrote:
> > On Wed, Jun 29, 2022 at 01:39:05PM -0700, Colin Foster wrote:
> > > I liked the idea of the MFD being "code complete" so if future regmaps
> > > were needed for the felix dsa driver came about, it wouldn't require
> > > changes to the "parent." But I think that was a bad goal - especially
> > > since MFD requires all the resources anyway.
> > >
> > > Also at the time, I was trying a hybrid "create it if it doesn't exist,
> > > return it if was already created" approach. I backed that out after an
> > > RFC.
> > >
> > > Focusing only on the non-felix drivers: it seems trivial for the parent
> > > to create _all_ the possible child regmaps, register them to the parent
> > > via by way of regmap_attach_dev().
> > >
> > > At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
> > > initalize like (untested, and apologies for indentation):
> > >
> > > regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> > > if (IS_ERR(regs)) {
> > > map = dev_get_regmap(dev->parent, name);
> > > } else {
> > > map = devm_regmap_init_mmio(dev, regs, config);
> > > }
> >
> > Again, those dev_err(dev, "invalid resource\n"); prints you were
> > complaining about earlier are self-inflicted IMO, and caused exactly by
> > this pattern. I get why you prefer to call larger building blocks if
> > possible, but in this case, devm_platform_get_and_ioremap_resource()
> > calls exactly 2 sub-functions: platform_get_resource() and
> > devm_ioremap_resource(). The IS_ERR() that you check for is caused by
> > devm_ioremap_resource() being passed a NULL pointer, and same goes for
> > the print. Just call them individually, and put your dev_get_regmap()
> > hook in case platform_get_resource() returns NULL, rather than passing
> > NULL to devm_ioremap_resource() and waiting for that to fail.
>
> I see that now. Hoping this next version removes a lot of this
> unnecessary complexity.
>
> >
> > > In that case, "name" would either be hard-coded to match what is in
> > > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > > resource->name. I'll be able to deal with that when I try it. (hopefully
> > > this evening)
> >
> > I'm not exactly clear on what you'd do with the REG resource once you
> > get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> > from the device tree, what next, who's going to set up the SPI regmap
> > for you?
>
> The REG resource would only get the resource name, while the MFD core
> driver would set up the regmaps.
>
> e.g. drivers/mfd/ocelot-core.c has (annotated):
> static const struct resource vsc7512_sgpio_resources[] = {
> DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
>
> Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
> gpio resource, and gets the resource by index.
>
> So for this there seem to be two options:
> Option 1:
> drivers/pinctrl/pinctrl-ocelot.c:
> res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> map = dev_get_regmap(dev->parent, res->name);
>
>
> OR Option 2:
> include/linux/mfd/ocelot.h has something like:
> #define GCB_GPIO_REGMAP_NAME "gcb_gpio"
>
> and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
> map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
>
> (With error checking, macro reuse, etc.)
>
>
> I like option 1, since it then makes ocelot-pinctrl.c have no reliance
> on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
> set up in advance during the start of ocelot_core_init, just before
> devm_mfd_add_devices is called.
>
>
> I should be able to test this all tonight.
Thank you Vladimir for stepping in to clarify previous points.
Well done both of you for this collaborative effort. Great to see!
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
2022-06-28 19:00 ` Andy Shevchenko
@ 2022-06-30 11:56 ` Linus Walleij
-1 siblings, 0 replies; 82+ messages in thread
From: Linus Walleij @ 2022-06-30 11:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Colin Foster, 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, Wolfram Sang,
Terry Bowman, Florian Fainelli
On Tue, Jun 28, 2022 at 9:00 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Jun 28, 2022 at 8:25 PM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> > On Tue, Jun 28, 2022 at 02:53:49PM +0200, Andy Shevchenko wrote:
> > > On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
> > > <colin.foster@in-advantage.com> wrote:
>
> ...
>
> > > > builtin_platform_driver(ocelot_pinctrl_driver);
> > >
> > > This contradicts the logic behind this change. Perhaps you need to
> > > move to module_platform_driver(). (Yes, I think functionally it won't
> > > be any changes if ->remove() is not needed, but for the sake of
> > > logical correctness...)
> >
> > I'll do this. Thanks.
> >
> > Process question: If I make this change is it typical to remove all
> > Reviewed-By tags? I assume "yes"
>
> I would not. This change is logical continuation and I truly believe
> every reviewer will agree on it.
I would have to think hard to remember a single review comment from Andy
where I didn't think "ah, yeah he's right", so definately keep mine.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-06-30 11:56 ` Linus Walleij
0 siblings, 0 replies; 82+ messages in thread
From: Linus Walleij @ 2022-06-30 11:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Colin Foster, 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, Wolfram Sang,
Terry Bowman, Florian Fainelli
On Tue, Jun 28, 2022 at 9:00 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Jun 28, 2022 at 8:25 PM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> > On Tue, Jun 28, 2022 at 02:53:49PM +0200, Andy Shevchenko wrote:
> > > On Tue, Jun 28, 2022 at 10:17 AM Colin Foster
> > > <colin.foster@in-advantage.com> wrote:
>
> ...
>
> > > > builtin_platform_driver(ocelot_pinctrl_driver);
> > >
> > > This contradicts the logic behind this change. Perhaps you need to
> > > move to module_platform_driver(). (Yes, I think functionally it won't
> > > be any changes if ->remove() is not needed, but for the sake of
> > > logical correctness...)
> >
> > I'll do this. Thanks.
> >
> > Process question: If I make this change is it typical to remove all
> > Reviewed-By tags? I assume "yes"
>
> I would not. This change is logical continuation and I truly believe
> every reviewer will agree on it.
I would have to think hard to remember a single review comment from Andy
where I didn't think "ah, yeah he's right", so definately keep mine.
Yours,
Linus Walleij
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-29 23:54 ` Colin Foster
@ 2022-06-30 13:11 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-30 13:11 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, Jun 29, 2022 at 04:54:35PM -0700, Colin Foster wrote:
> > > In that case, "name" would either be hard-coded to match what is in
> > > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > > resource->name. I'll be able to deal with that when I try it. (hopefully
> > > this evening)
> >
> > I'm not exactly clear on what you'd do with the REG resource once you
> > get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> > from the device tree, what next, who's going to set up the SPI regmap
> > for you?
>
> The REG resource would only get the resource name, while the MFD core
> driver would set up the regmaps.
>
> e.g. drivers/mfd/ocelot-core.c has (annotated):
> static const struct resource vsc7512_sgpio_resources[] = {
> DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
>
> Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
> gpio resource, and gets the resource by index.
>
> So for this there seem to be two options:
> Option 1:
> drivers/pinctrl/pinctrl-ocelot.c:
> res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> map = dev_get_regmap(dev->parent, res->name);
>
>
> OR Option 2:
> include/linux/mfd/ocelot.h has something like:
> #define GCB_GPIO_REGMAP_NAME "gcb_gpio"
>
> and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
> map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
>
> (With error checking, macro reuse, etc.)
>
>
> I like option 1, since it then makes ocelot-pinctrl.c have no reliance
> on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
> set up in advance during the start of ocelot_core_init, just before
> devm_mfd_add_devices is called.
>
>
> I should be able to test this all tonight.
I see what you mean now with the named resources from drivers/mfd/ocelot-core.c.
I don't particularly like the platform_get_resource(0) option, because
it's not as obvious/searchable what resource the pinctrl driver is
asking for.
I suppose a compromise variant might be to combine the 2 options.
Put enum ocelot_target in a header included by both drivers/mfd/ocelot-core.c,
then create a _single_ resource table in the MFD driver, indexed by enum
ocelot_target:
static const struct resource vsc7512_resources[TARGET_MAX] = {
[ANA] = DEFINE_RES_REG_NAMED(start, end, "ana"),
...
};
then provide the exact same resource table to all children.
In the pinctrl driver you can then do:
res = platform_get_resource(pdev, IORESOURCE_REG, GPIO);
map = dev_get_regmap(dev->parent, res->name);
and you get both the benefit of not hardcoding the string twice, and the
benefit of having some obvious keyword which can be used to link the mfd
driver to the child driver via grep, for those trying to understand what
goes on.
In addition, if there's a single resource table used for all peripherals,
theoretically you need to modify less code in mfd/ocelot-core.c in case
one driver or another needs access to one more regmap, if that regmap
happened to be needed by some other driver already. Plus fewer tables to
lug around, in general.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-30 13:11 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-30 13:11 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Wed, Jun 29, 2022 at 04:54:35PM -0700, Colin Foster wrote:
> > > In that case, "name" would either be hard-coded to match what is in
> > > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > > resource->name. I'll be able to deal with that when I try it. (hopefully
> > > this evening)
> >
> > I'm not exactly clear on what you'd do with the REG resource once you
> > get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> > from the device tree, what next, who's going to set up the SPI regmap
> > for you?
>
> The REG resource would only get the resource name, while the MFD core
> driver would set up the regmaps.
>
> e.g. drivers/mfd/ocelot-core.c has (annotated):
> static const struct resource vsc7512_sgpio_resources[] = {
> DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
>
> Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
> gpio resource, and gets the resource by index.
>
> So for this there seem to be two options:
> Option 1:
> drivers/pinctrl/pinctrl-ocelot.c:
> res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> map = dev_get_regmap(dev->parent, res->name);
>
>
> OR Option 2:
> include/linux/mfd/ocelot.h has something like:
> #define GCB_GPIO_REGMAP_NAME "gcb_gpio"
>
> and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
> map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
>
> (With error checking, macro reuse, etc.)
>
>
> I like option 1, since it then makes ocelot-pinctrl.c have no reliance
> on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
> set up in advance during the start of ocelot_core_init, just before
> devm_mfd_add_devices is called.
>
>
> I should be able to test this all tonight.
I see what you mean now with the named resources from drivers/mfd/ocelot-core.c.
I don't particularly like the platform_get_resource(0) option, because
it's not as obvious/searchable what resource the pinctrl driver is
asking for.
I suppose a compromise variant might be to combine the 2 options.
Put enum ocelot_target in a header included by both drivers/mfd/ocelot-core.c,
then create a _single_ resource table in the MFD driver, indexed by enum
ocelot_target:
static const struct resource vsc7512_resources[TARGET_MAX] = {
[ANA] = DEFINE_RES_REG_NAMED(start, end, "ana"),
...
};
then provide the exact same resource table to all children.
In the pinctrl driver you can then do:
res = platform_get_resource(pdev, IORESOURCE_REG, GPIO);
map = dev_get_regmap(dev->parent, res->name);
and you get both the benefit of not hardcoding the string twice, and the
benefit of having some obvious keyword which can be used to link the mfd
driver to the child driver via grep, for those trying to understand what
goes on.
In addition, if there's a single resource table used for all peripherals,
theoretically you need to modify less code in mfd/ocelot-core.c in case
one driver or another needs access to one more regmap, if that regmap
happened to be needed by some other driver already. Plus fewer tables to
lug around, in general.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
2022-06-28 8:17 ` Colin Foster
@ 2022-06-30 13:17 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-30 13:17 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
On Tue, Jun 28, 2022 at 01:17:08AM -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
>
> diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
> new file mode 100644
> index 000000000000..24fab9f5e319
> --- /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-spi
> +
> + 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>;
> +
> + switch@0 {
I wonder if "switch" is the best name for the top-level node, since
there should also be another "switch" child node inside for the _actual_
DSA bindings, which this example is not showing (leading to further
confusion IMO).
Hmm, would "soc" be an exaggerated name? It's a SPI-controlled SoC after
all.
> + 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 4d9ccec78f18..03eba7fd2141 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 [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512
@ 2022-06-30 13:17 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-06-30 13:17 UTC (permalink / raw)
To: Colin Foster
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-gpio,
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
On Tue, Jun 28, 2022 at 01:17:08AM -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
>
> diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
> new file mode 100644
> index 000000000000..24fab9f5e319
> --- /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-spi
> +
> + 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>;
> +
> + switch@0 {
I wonder if "switch" is the best name for the top-level node, since
there should also be another "switch" child node inside for the _actual_
DSA bindings, which this example is not showing (leading to further
confusion IMO).
Hmm, would "soc" be an exaggerated name? It's a SPI-controlled SoC after
all.
> + 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 4d9ccec78f18..03eba7fd2141 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 [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-30 13:11 ` Vladimir Oltean
@ 2022-06-30 20:09 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-30 20:09 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Thu, Jun 30, 2022 at 01:11:56PM +0000, Vladimir Oltean wrote:
> On Wed, Jun 29, 2022 at 04:54:35PM -0700, Colin Foster wrote:
> > > > In that case, "name" would either be hard-coded to match what is in
> > > > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > > > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > > > resource->name. I'll be able to deal with that when I try it. (hopefully
> > > > this evening)
> > >
> > > I'm not exactly clear on what you'd do with the REG resource once you
> > > get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> > > from the device tree, what next, who's going to set up the SPI regmap
> > > for you?
> >
> > The REG resource would only get the resource name, while the MFD core
> > driver would set up the regmaps.
> >
> > e.g. drivers/mfd/ocelot-core.c has (annotated):
> > static const struct resource vsc7512_sgpio_resources[] = {
> > DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
> >
> > Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
> > gpio resource, and gets the resource by index.
> >
> > So for this there seem to be two options:
> > Option 1:
> > drivers/pinctrl/pinctrl-ocelot.c:
> > res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> > map = dev_get_regmap(dev->parent, res->name);
> >
> >
> > OR Option 2:
> > include/linux/mfd/ocelot.h has something like:
> > #define GCB_GPIO_REGMAP_NAME "gcb_gpio"
> >
> > and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
> > map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
> >
> > (With error checking, macro reuse, etc.)
> >
> >
> > I like option 1, since it then makes ocelot-pinctrl.c have no reliance
> > on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
> > set up in advance during the start of ocelot_core_init, just before
> > devm_mfd_add_devices is called.
> >
> >
> > I should be able to test this all tonight.
>
> I see what you mean now with the named resources from drivers/mfd/ocelot-core.c.
> I don't particularly like the platform_get_resource(0) option, because
> it's not as obvious/searchable what resource the pinctrl driver is
> asking for.
>
> I suppose a compromise variant might be to combine the 2 options.
> Put enum ocelot_target in a header included by both drivers/mfd/ocelot-core.c,
> then create a _single_ resource table in the MFD driver, indexed by enum
> ocelot_target:
>
> static const struct resource vsc7512_resources[TARGET_MAX] = {
> [ANA] = DEFINE_RES_REG_NAMED(start, end, "ana"),
> ...
> };
>
> then provide the exact same resource table to all children.
>
> In the pinctrl driver you can then do:
> res = platform_get_resource(pdev, IORESOURCE_REG, GPIO);
> map = dev_get_regmap(dev->parent, res->name);
>
> and you get both the benefit of not hardcoding the string twice, and the
> benefit of having some obvious keyword which can be used to link the mfd
> driver to the child driver via grep, for those trying to understand what
> goes on.
>
> In addition, if there's a single resource table used for all peripherals,
> theoretically you need to modify less code in mfd/ocelot-core.c in case
> one driver or another needs access to one more regmap, if that regmap
> happened to be needed by some other driver already. Plus fewer tables to
> lug around, in general.
Ok... so I haven't yet changed any of the pinctrl / mdio drivers yet,
but I'm liking this:
static inline struct regmap *
ocelot_regmap_from_resource(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
*/
res = platform_get_resource(pdev, IORESOURCE_REG, index);
if (!res)
return ERR_PTR(-ENOENT);
return (dev_get_regmap(dev->parent, res->name));
}
So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
an inline helper function. And so long as ocelot_core_init does this:
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);
we're good! (sorry about spaces / tabs... I have to up my mutt/vim/tmux
game still)
I like the enum / macro idea for cleanup, but I think that's a different
problem I can address. The main question I have now is this:
The ocelot_regmap_from_resource now has nothing to do with the ocelot
MFD system. It is generic. (If you listen carefully, you might hear me
cheering)
I can keep this in linux/mfd/ocelot.h, but is this actually something
that belongs elsewhere? platform? device? mfd-core?
And yes, I like the idea of changing the driver to
"ocelot_regmap_from_resource(pdev, GPIO, config);" from
"ocelot_regmap_from_resource(pdev, 0, config);"
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-06-30 20:09 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-06-30 20:09 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Thu, Jun 30, 2022 at 01:11:56PM +0000, Vladimir Oltean wrote:
> On Wed, Jun 29, 2022 at 04:54:35PM -0700, Colin Foster wrote:
> > > > In that case, "name" would either be hard-coded to match what is in
> > > > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > > > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > > > resource->name. I'll be able to deal with that when I try it. (hopefully
> > > > this evening)
> > >
> > > I'm not exactly clear on what you'd do with the REG resource once you
> > > get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> > > from the device tree, what next, who's going to set up the SPI regmap
> > > for you?
> >
> > The REG resource would only get the resource name, while the MFD core
> > driver would set up the regmaps.
> >
> > e.g. drivers/mfd/ocelot-core.c has (annotated):
> > static const struct resource vsc7512_sgpio_resources[] = {
> > DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };
> >
> > Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
> > gpio resource, and gets the resource by index.
> >
> > So for this there seem to be two options:
> > Option 1:
> > drivers/pinctrl/pinctrl-ocelot.c:
> > res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> > map = dev_get_regmap(dev->parent, res->name);
> >
> >
> > OR Option 2:
> > include/linux/mfd/ocelot.h has something like:
> > #define GCB_GPIO_REGMAP_NAME "gcb_gpio"
> >
> > and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
> > map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);
> >
> > (With error checking, macro reuse, etc.)
> >
> >
> > I like option 1, since it then makes ocelot-pinctrl.c have no reliance
> > on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
> > set up in advance during the start of ocelot_core_init, just before
> > devm_mfd_add_devices is called.
> >
> >
> > I should be able to test this all tonight.
>
> I see what you mean now with the named resources from drivers/mfd/ocelot-core.c.
> I don't particularly like the platform_get_resource(0) option, because
> it's not as obvious/searchable what resource the pinctrl driver is
> asking for.
>
> I suppose a compromise variant might be to combine the 2 options.
> Put enum ocelot_target in a header included by both drivers/mfd/ocelot-core.c,
> then create a _single_ resource table in the MFD driver, indexed by enum
> ocelot_target:
>
> static const struct resource vsc7512_resources[TARGET_MAX] = {
> [ANA] = DEFINE_RES_REG_NAMED(start, end, "ana"),
> ...
> };
>
> then provide the exact same resource table to all children.
>
> In the pinctrl driver you can then do:
> res = platform_get_resource(pdev, IORESOURCE_REG, GPIO);
> map = dev_get_regmap(dev->parent, res->name);
>
> and you get both the benefit of not hardcoding the string twice, and the
> benefit of having some obvious keyword which can be used to link the mfd
> driver to the child driver via grep, for those trying to understand what
> goes on.
>
> In addition, if there's a single resource table used for all peripherals,
> theoretically you need to modify less code in mfd/ocelot-core.c in case
> one driver or another needs access to one more regmap, if that regmap
> happened to be needed by some other driver already. Plus fewer tables to
> lug around, in general.
Ok... so I haven't yet changed any of the pinctrl / mdio drivers yet,
but I'm liking this:
static inline struct regmap *
ocelot_regmap_from_resource(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
*/
res = platform_get_resource(pdev, IORESOURCE_REG, index);
if (!res)
return ERR_PTR(-ENOENT);
return (dev_get_regmap(dev->parent, res->name));
}
So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
an inline helper function. And so long as ocelot_core_init does this:
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);
we're good! (sorry about spaces / tabs... I have to up my mutt/vim/tmux
game still)
I like the enum / macro idea for cleanup, but I think that's a different
problem I can address. The main question I have now is this:
The ocelot_regmap_from_resource now has nothing to do with the ocelot
MFD system. It is generic. (If you listen carefully, you might hear me
cheering)
I can keep this in linux/mfd/ocelot.h, but is this actually something
that belongs elsewhere? platform? device? mfd-core?
And yes, I like the idea of changing the driver to
"ocelot_regmap_from_resource(pdev, GPIO, config);" from
"ocelot_regmap_from_resource(pdev, 0, config);"
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-06-30 20:09 ` Colin Foster
@ 2022-07-01 16:21 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-07-01 16:21 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Thu, Jun 30, 2022 at 01:09:51PM -0700, Colin Foster wrote:
> Ok... so I haven't yet changed any of the pinctrl / mdio drivers yet,
> but I'm liking this:
>
> static inline struct regmap *
> ocelot_regmap_from_resource(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
> */
> res = platform_get_resource(pdev, IORESOURCE_REG, index);
> if (!res)
> return ERR_PTR(-ENOENT);
>
> return (dev_get_regmap(dev->parent, res->name));
parentheses not needed around dev_get_regmap.
> }
>
> So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> an inline helper function. And so long as ocelot_core_init does this:
>
> 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]);
Dumb question, why just "try"?
>
> return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> ndevs, NULL, 0, NULL);
> }
> EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
>
> we're good! (sorry about spaces / tabs... I have to up my mutt/vim/tmux
> game still)
>
>
> I like the enum / macro idea for cleanup, but I think that's a different
> problem I can address. The main question I have now is this:
>
> The ocelot_regmap_from_resource now has nothing to do with the ocelot
> MFD system. It is generic. (If you listen carefully, you might hear me
> cheering)
>
> I can keep this in linux/mfd/ocelot.h, but is this actually something
> that belongs elsewhere? platform? device? mfd-core?
Sounds like something which could be named devm_platform_get_regmap_from_resource_or_parent(),
but I'm not 100% clear where it should sit. Platform devices are independent
of regmap, regmap is independent of platform devices, device core of both.
FWIW platform devices are always built-in and have no config option;
regmap is bool and is selected by others.
Logically, the melting pot of regmaps and platform devices is mfd.
However, it seems that include/linux/mfd/core.h only provides API for
mfd parent drivers, not children. So a new header would be needed?
Alternatively, you could just duplicate this logic in the drivers
(by the way, only spelling out the function name takes up half of the
implementation). How many times would it be needed? Felix DSA would roll
its own thing, as mentioned. I'm thinking, let it be open coded for now,
let's agree on the entire solution in terms of operations that are
actually being done, and we can revisit proper placement for this later.
> And yes, I like the idea of changing the driver to
> "ocelot_regmap_from_resource(pdev, GPIO, config);" from
> "ocelot_regmap_from_resource(pdev, 0, config);"
Sorry, I just realized we need to junk this idea with GPIO instead of 0.
Presenting the entire resource table to all peripherals implies that
there is no more than one single peripheral of each kind. This is not
true for the MDIO controllers, where the driver would need to know it
has to request the region corresponding to MIIM1 or MIIM2 according to
some crystal ball.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-01 16:21 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-07-01 16:21 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Thu, Jun 30, 2022 at 01:09:51PM -0700, Colin Foster wrote:
> Ok... so I haven't yet changed any of the pinctrl / mdio drivers yet,
> but I'm liking this:
>
> static inline struct regmap *
> ocelot_regmap_from_resource(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
> */
> res = platform_get_resource(pdev, IORESOURCE_REG, index);
> if (!res)
> return ERR_PTR(-ENOENT);
>
> return (dev_get_regmap(dev->parent, res->name));
parentheses not needed around dev_get_regmap.
> }
>
> So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> an inline helper function. And so long as ocelot_core_init does this:
>
> 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]);
Dumb question, why just "try"?
>
> return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> ndevs, NULL, 0, NULL);
> }
> EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
>
> we're good! (sorry about spaces / tabs... I have to up my mutt/vim/tmux
> game still)
>
>
> I like the enum / macro idea for cleanup, but I think that's a different
> problem I can address. The main question I have now is this:
>
> The ocelot_regmap_from_resource now has nothing to do with the ocelot
> MFD system. It is generic. (If you listen carefully, you might hear me
> cheering)
>
> I can keep this in linux/mfd/ocelot.h, but is this actually something
> that belongs elsewhere? platform? device? mfd-core?
Sounds like something which could be named devm_platform_get_regmap_from_resource_or_parent(),
but I'm not 100% clear where it should sit. Platform devices are independent
of regmap, regmap is independent of platform devices, device core of both.
FWIW platform devices are always built-in and have no config option;
regmap is bool and is selected by others.
Logically, the melting pot of regmaps and platform devices is mfd.
However, it seems that include/linux/mfd/core.h only provides API for
mfd parent drivers, not children. So a new header would be needed?
Alternatively, you could just duplicate this logic in the drivers
(by the way, only spelling out the function name takes up half of the
implementation). How many times would it be needed? Felix DSA would roll
its own thing, as mentioned. I'm thinking, let it be open coded for now,
let's agree on the entire solution in terms of operations that are
actually being done, and we can revisit proper placement for this later.
> And yes, I like the idea of changing the driver to
> "ocelot_regmap_from_resource(pdev, GPIO, config);" from
> "ocelot_regmap_from_resource(pdev, 0, config);"
Sorry, I just realized we need to junk this idea with GPIO instead of 0.
Presenting the entire resource table to all peripherals implies that
there is no more than one single peripheral of each kind. This is not
true for the MDIO controllers, where the driver would need to know it
has to request the region corresponding to MIIM1 or MIIM2 according to
some crystal ball.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-07-01 16:21 ` Vladimir Oltean
@ 2022-07-01 17:18 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-07-01 17:18 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Fri, Jul 01, 2022 at 04:21:28PM +0000, Vladimir Oltean wrote:
> On Thu, Jun 30, 2022 at 01:09:51PM -0700, Colin Foster wrote:
> > Ok... so I haven't yet changed any of the pinctrl / mdio drivers yet,
> > but I'm liking this:
> >
> > static inline struct regmap *
> > ocelot_regmap_from_resource(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
> > */
> > res = platform_get_resource(pdev, IORESOURCE_REG, index);
> > if (!res)
> > return ERR_PTR(-ENOENT);
> >
> > return (dev_get_regmap(dev->parent, res->name));
>
> parentheses not needed around dev_get_regmap.
Oops.
While I have your ear: do I need to check for dev->parent == NULL before
calling dev_get_regmap? I see find_dr will call
(dev->parent)->devres_head... but specifically "does every device have a
valid parent?"
>
> > }
> >
> > So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> > an inline helper function. And so long as ocelot_core_init does this:
> >
> > 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]);
>
> Dumb question, why just "try"?
Because of this conditional:
> > if (!dev_get_regmap(dev, res->name)) {
Don't add it if it is already there.
This might get interesting... The soc uses the HSIO regmap by way of
syscon. Among other things, drivers/phy/mscc/phy-ocelot-serdes.c. If
dev->parent has all the regmaps, what role does syscon play?
But that's a problem for another day...
>
> >
> > return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> > ndevs, NULL, 0, NULL);
> > }
> > EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
> >
> > we're good! (sorry about spaces / tabs... I have to up my mutt/vim/tmux
> > game still)
> >
> >
> > I like the enum / macro idea for cleanup, but I think that's a different
> > problem I can address. The main question I have now is this:
> >
> > The ocelot_regmap_from_resource now has nothing to do with the ocelot
> > MFD system. It is generic. (If you listen carefully, you might hear me
> > cheering)
> >
> > I can keep this in linux/mfd/ocelot.h, but is this actually something
> > that belongs elsewhere? platform? device? mfd-core?
>
> Sounds like something which could be named devm_platform_get_regmap_from_resource_or_parent(),
> but I'm not 100% clear where it should sit. Platform devices are independent
> of regmap, regmap is independent of platform devices, device core of both.
>
> FWIW platform devices are always built-in and have no config option;
> regmap is bool and is selected by others.
>
> Logically, the melting pot of regmaps and platform devices is mfd.
> However, it seems that include/linux/mfd/core.h only provides API for
> mfd parent drivers, not children. So a new header would be needed?
>
> Alternatively, you could just duplicate this logic in the drivers
> (by the way, only spelling out the function name takes up half of the
> implementation). How many times would it be needed? Felix DSA would roll
> its own thing, as mentioned. I'm thinking, let it be open coded for now,
> let's agree on the entire solution in terms of operations that are
> actually being done, and we can revisit proper placement for this later.
I came to the same conclusion. Hopefully I'll button up v12 today.
>
> > And yes, I like the idea of changing the driver to
> > "ocelot_regmap_from_resource(pdev, GPIO, config);" from
> > "ocelot_regmap_from_resource(pdev, 0, config);"
>
> Sorry, I just realized we need to junk this idea with GPIO instead of 0.
> Presenting the entire resource table to all peripherals implies that
> there is no more than one single peripheral of each kind. This is not
> true for the MDIO controllers, where the driver would need to know it
> has to request the region corresponding to MIIM1 or MIIM2 according to
> some crystal ball.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-01 17:18 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-07-01 17:18 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Fri, Jul 01, 2022 at 04:21:28PM +0000, Vladimir Oltean wrote:
> On Thu, Jun 30, 2022 at 01:09:51PM -0700, Colin Foster wrote:
> > Ok... so I haven't yet changed any of the pinctrl / mdio drivers yet,
> > but I'm liking this:
> >
> > static inline struct regmap *
> > ocelot_regmap_from_resource(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
> > */
> > res = platform_get_resource(pdev, IORESOURCE_REG, index);
> > if (!res)
> > return ERR_PTR(-ENOENT);
> >
> > return (dev_get_regmap(dev->parent, res->name));
>
> parentheses not needed around dev_get_regmap.
Oops.
While I have your ear: do I need to check for dev->parent == NULL before
calling dev_get_regmap? I see find_dr will call
(dev->parent)->devres_head... but specifically "does every device have a
valid parent?"
>
> > }
> >
> > So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> > an inline helper function. And so long as ocelot_core_init does this:
> >
> > 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]);
>
> Dumb question, why just "try"?
Because of this conditional:
> > if (!dev_get_regmap(dev, res->name)) {
Don't add it if it is already there.
This might get interesting... The soc uses the HSIO regmap by way of
syscon. Among other things, drivers/phy/mscc/phy-ocelot-serdes.c. If
dev->parent has all the regmaps, what role does syscon play?
But that's a problem for another day...
>
> >
> > return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> > ndevs, NULL, 0, NULL);
> > }
> > EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
> >
> > we're good! (sorry about spaces / tabs... I have to up my mutt/vim/tmux
> > game still)
> >
> >
> > I like the enum / macro idea for cleanup, but I think that's a different
> > problem I can address. The main question I have now is this:
> >
> > The ocelot_regmap_from_resource now has nothing to do with the ocelot
> > MFD system. It is generic. (If you listen carefully, you might hear me
> > cheering)
> >
> > I can keep this in linux/mfd/ocelot.h, but is this actually something
> > that belongs elsewhere? platform? device? mfd-core?
>
> Sounds like something which could be named devm_platform_get_regmap_from_resource_or_parent(),
> but I'm not 100% clear where it should sit. Platform devices are independent
> of regmap, regmap is independent of platform devices, device core of both.
>
> FWIW platform devices are always built-in and have no config option;
> regmap is bool and is selected by others.
>
> Logically, the melting pot of regmaps and platform devices is mfd.
> However, it seems that include/linux/mfd/core.h only provides API for
> mfd parent drivers, not children. So a new header would be needed?
>
> Alternatively, you could just duplicate this logic in the drivers
> (by the way, only spelling out the function name takes up half of the
> implementation). How many times would it be needed? Felix DSA would roll
> its own thing, as mentioned. I'm thinking, let it be open coded for now,
> let's agree on the entire solution in terms of operations that are
> actually being done, and we can revisit proper placement for this later.
I came to the same conclusion. Hopefully I'll button up v12 today.
>
> > And yes, I like the idea of changing the driver to
> > "ocelot_regmap_from_resource(pdev, GPIO, config);" from
> > "ocelot_regmap_from_resource(pdev, 0, config);"
>
> Sorry, I just realized we need to junk this idea with GPIO instead of 0.
> Presenting the entire resource table to all peripherals implies that
> there is no more than one single peripheral of each kind. This is not
> true for the MDIO controllers, where the driver would need to know it
> has to request the region corresponding to MIIM1 or MIIM2 according to
> some crystal ball.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-07-01 17:18 ` Colin Foster
@ 2022-07-02 12:42 ` Vladimir Oltean
-1 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-07-02 12:42 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Fri, Jul 01, 2022 at 10:18:31AM -0700, Colin Foster wrote:
> While I have your ear: do I need to check for dev->parent == NULL before
> calling dev_get_regmap? I see find_dr will call
> (dev->parent)->devres_head... but specifically "does every device have a
> valid parent?"
While the technical answer is "no", the practical answer is "pretty much".
Platform devices sit at least on the "platform" bus created in drivers/base/platform.c,
and they are reparented to the "platform_bus" struct device named "platform"
within platform_device_add(), if they don't have a parent.
Additionally, for MMIO-controlled platform devices in Ocelot, these have
as parent a platform device probed by the drivers/bus/simple-pm-bus.c
driver on the "ahb@70000000" simple-bus OF node. That simple-bus
platform device has as parent the "platform_bus" device mentioned above.
So it's a pretty long way to the top in the device hierarchy, I wouldn't
concern myself too much with checking for NULL, unless you intend to
call dev_get_regmap() on a parent's parent's parent, or things like that.
> > > }
> > >
> > > So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> > > an inline helper function. And so long as ocelot_core_init does this:
> > >
> > > 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]);
> >
> > Dumb question, why just "try"?
>
> Because of this conditional:
> > > if (!dev_get_regmap(dev, res->name)) {
> Don't add it if it is already there.
Hmm. So that's because you add regmaps iterating by the resource table
of each device. What if you keep a single resource table for regmap
creation purposes, and the device resource tables as separate?
> This might get interesting... The soc uses the HSIO regmap by way of
> syscon. Among other things, drivers/phy/mscc/phy-ocelot-serdes.c. If
> dev->parent has all the regmaps, what role does syscon play?
>
> But that's a problem for another day...
Interesting question. I think part of the reason why syscon exists is to
not have OF nodes with overlapping address regions. In that sense, its
need does not go away here - I expect the layout of OF nodes beneath the
ocelot SPI device to be the same as their AHB variants. But in terms of
driver implementation, I don't know. Even if the OF nodes for your MFD
functions will contain all the regs that their AHB variants do, I'd
personally still be inclined to also hardcode those as resources in the
ocelot mfd parent driver and use those - case in which the OF regs will
more or less exist just as a formality. Maybe because the HSIO syscon is
already compatible with "simple-mfd", devices beneath it should just
probe. I haven't studied how syscon_node_to_regmap() behaves when the
syscon itself is probed as a MFD function. If that "just works", then
the phy-ocelot-serdes.c driver might not need to be modified.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-02 12:42 ` Vladimir Oltean
0 siblings, 0 replies; 82+ messages in thread
From: Vladimir Oltean @ 2022-07-02 12:42 UTC (permalink / raw)
To: Colin Foster
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Fri, Jul 01, 2022 at 10:18:31AM -0700, Colin Foster wrote:
> While I have your ear: do I need to check for dev->parent == NULL before
> calling dev_get_regmap? I see find_dr will call
> (dev->parent)->devres_head... but specifically "does every device have a
> valid parent?"
While the technical answer is "no", the practical answer is "pretty much".
Platform devices sit at least on the "platform" bus created in drivers/base/platform.c,
and they are reparented to the "platform_bus" struct device named "platform"
within platform_device_add(), if they don't have a parent.
Additionally, for MMIO-controlled platform devices in Ocelot, these have
as parent a platform device probed by the drivers/bus/simple-pm-bus.c
driver on the "ahb@70000000" simple-bus OF node. That simple-bus
platform device has as parent the "platform_bus" device mentioned above.
So it's a pretty long way to the top in the device hierarchy, I wouldn't
concern myself too much with checking for NULL, unless you intend to
call dev_get_regmap() on a parent's parent's parent, or things like that.
> > > }
> > >
> > > So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> > > an inline helper function. And so long as ocelot_core_init does this:
> > >
> > > 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]);
> >
> > Dumb question, why just "try"?
>
> Because of this conditional:
> > > if (!dev_get_regmap(dev, res->name)) {
> Don't add it if it is already there.
Hmm. So that's because you add regmaps iterating by the resource table
of each device. What if you keep a single resource table for regmap
creation purposes, and the device resource tables as separate?
> This might get interesting... The soc uses the HSIO regmap by way of
> syscon. Among other things, drivers/phy/mscc/phy-ocelot-serdes.c. If
> dev->parent has all the regmaps, what role does syscon play?
>
> But that's a problem for another day...
Interesting question. I think part of the reason why syscon exists is to
not have OF nodes with overlapping address regions. In that sense, its
need does not go away here - I expect the layout of OF nodes beneath the
ocelot SPI device to be the same as their AHB variants. But in terms of
driver implementation, I don't know. Even if the OF nodes for your MFD
functions will contain all the regs that their AHB variants do, I'd
personally still be inclined to also hardcode those as resources in the
ocelot mfd parent driver and use those - case in which the OF regs will
more or less exist just as a formality. Maybe because the HSIO syscon is
already compatible with "simple-mfd", devices beneath it should just
probe. I haven't studied how syscon_node_to_regmap() behaves when the
syscon itself is probed as a MFD function. If that "just works", then
the phy-ocelot-serdes.c driver might not need to be modified.
_______________________________________________
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] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
2022-07-02 12:42 ` Vladimir Oltean
@ 2022-07-02 16:17 ` Colin Foster
-1 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-07-02 16:17 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Sat, Jul 02, 2022 at 12:42:06PM +0000, Vladimir Oltean wrote:
> On Fri, Jul 01, 2022 at 10:18:31AM -0700, Colin Foster wrote:
> > While I have your ear: do I need to check for dev->parent == NULL before
> > calling dev_get_regmap? I see find_dr will call
> > (dev->parent)->devres_head... but specifically "does every device have a
> > valid parent?"
>
> While the technical answer is "no", the practical answer is "pretty much".
> Platform devices sit at least on the "platform" bus created in drivers/base/platform.c,
> and they are reparented to the "platform_bus" struct device named "platform"
> within platform_device_add(), if they don't have a parent.
>
> Additionally, for MMIO-controlled platform devices in Ocelot, these have
> as parent a platform device probed by the drivers/bus/simple-pm-bus.c
> driver on the "ahb@70000000" simple-bus OF node. That simple-bus
> platform device has as parent the "platform_bus" device mentioned above.
>
> So it's a pretty long way to the top in the device hierarchy, I wouldn't
> concern myself too much with checking for NULL, unless you intend to
> call dev_get_regmap() on a parent's parent's parent, or things like that.
Thanks for the info. I have the NULL check in there, since I followed
the code and didn't see anything in device initialization that always
initializes parent. Maybe a default initializer would be
dev->parent = dev;
>
> > > > }
> > > >
> > > > So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> > > > an inline helper function. And so long as ocelot_core_init does this:
> > > >
> > > > 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]);
> > >
> > > Dumb question, why just "try"?
> >
> > Because of this conditional:
> > > > if (!dev_get_regmap(dev, res->name)) {
> > Don't add it if it is already there.
>
> Hmm. So that's because you add regmaps iterating by the resource table
> of each device. What if you keep a single resource table for regmap
> creation purposes, and the device resource tables as separate?
That would work - though it seems like it might be adding extra info
that isn't necessary. I'll take a look.
>
> > This might get interesting... The soc uses the HSIO regmap by way of
> > syscon. Among other things, drivers/phy/mscc/phy-ocelot-serdes.c. If
> > dev->parent has all the regmaps, what role does syscon play?
> >
> > But that's a problem for another day...
>
> Interesting question. I think part of the reason why syscon exists is to
> not have OF nodes with overlapping address regions. In that sense, its
> need does not go away here - I expect the layout of OF nodes beneath the
> ocelot SPI device to be the same as their AHB variants. But in terms of
> driver implementation, I don't know. Even if the OF nodes for your MFD
> functions will contain all the regs that their AHB variants do, I'd
> personally still be inclined to also hardcode those as resources in the
> ocelot mfd parent driver and use those - case in which the OF regs will
> more or less exist just as a formality. Maybe because the HSIO syscon is
> already compatible with "simple-mfd", devices beneath it should just
> probe. I haven't studied how syscon_node_to_regmap() behaves when the
> syscon itself is probed as a MFD function. If that "just works", then
> the phy-ocelot-serdes.c driver might not need to be modified.
That'd be nice! When I looked into it a few months ago I came to the
conclusion that I'd need to implement "mscc,ocelot-hsio" but maybe
there's something I missed.
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource
@ 2022-07-02 16:17 ` Colin Foster
0 siblings, 0 replies; 82+ messages in thread
From: Colin Foster @ 2022-07-02 16:17 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andy Shevchenko, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-gpio, 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, Alexandre Belloni, Arnd Bergmann
On Sat, Jul 02, 2022 at 12:42:06PM +0000, Vladimir Oltean wrote:
> On Fri, Jul 01, 2022 at 10:18:31AM -0700, Colin Foster wrote:
> > While I have your ear: do I need to check for dev->parent == NULL before
> > calling dev_get_regmap? I see find_dr will call
> > (dev->parent)->devres_head... but specifically "does every device have a
> > valid parent?"
>
> While the technical answer is "no", the practical answer is "pretty much".
> Platform devices sit at least on the "platform" bus created in drivers/base/platform.c,
> and they are reparented to the "platform_bus" struct device named "platform"
> within platform_device_add(), if they don't have a parent.
>
> Additionally, for MMIO-controlled platform devices in Ocelot, these have
> as parent a platform device probed by the drivers/bus/simple-pm-bus.c
> driver on the "ahb@70000000" simple-bus OF node. That simple-bus
> platform device has as parent the "platform_bus" device mentioned above.
>
> So it's a pretty long way to the top in the device hierarchy, I wouldn't
> concern myself too much with checking for NULL, unless you intend to
> call dev_get_regmap() on a parent's parent's parent, or things like that.
Thanks for the info. I have the NULL check in there, since I followed
the code and didn't see anything in device initialization that always
initializes parent. Maybe a default initializer would be
dev->parent = dev;
>
> > > > }
> > > >
> > > > So now there's no need for #if (CONFIG_MFD_OCELOT) - it can just remain
> > > > an inline helper function. And so long as ocelot_core_init does this:
> > > >
> > > > 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]);
> > >
> > > Dumb question, why just "try"?
> >
> > Because of this conditional:
> > > > if (!dev_get_regmap(dev, res->name)) {
> > Don't add it if it is already there.
>
> Hmm. So that's because you add regmaps iterating by the resource table
> of each device. What if you keep a single resource table for regmap
> creation purposes, and the device resource tables as separate?
That would work - though it seems like it might be adding extra info
that isn't necessary. I'll take a look.
>
> > This might get interesting... The soc uses the HSIO regmap by way of
> > syscon. Among other things, drivers/phy/mscc/phy-ocelot-serdes.c. If
> > dev->parent has all the regmaps, what role does syscon play?
> >
> > But that's a problem for another day...
>
> Interesting question. I think part of the reason why syscon exists is to
> not have OF nodes with overlapping address regions. In that sense, its
> need does not go away here - I expect the layout of OF nodes beneath the
> ocelot SPI device to be the same as their AHB variants. But in terms of
> driver implementation, I don't know. Even if the OF nodes for your MFD
> functions will contain all the regs that their AHB variants do, I'd
> personally still be inclined to also hardcode those as resources in the
> ocelot mfd parent driver and use those - case in which the OF regs will
> more or less exist just as a formality. Maybe because the HSIO syscon is
> already compatible with "simple-mfd", devices beneath it should just
> probe. I haven't studied how syscon_node_to_regmap() behaves when the
> syscon itself is probed as a MFD function. If that "just works", then
> the phy-ocelot-serdes.c driver might not need to be modified.
That'd be nice! When I looked into it a few months ago I came to the
conclusion that I'd need to implement "mscc,ocelot-hsio" but maybe
there's something I missed.
_______________________________________________
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] 82+ messages in thread
end of thread, other threads:[~2022-07-02 16:18 UTC | newest]
Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-28 8:17 [PATCH v11 net-next 0/9] add support for VSC7512 control over SPI Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 12:50 ` Andy Shevchenko
2022-06-28 12:50 ` Andy Shevchenko
2022-06-28 15:33 ` Vladimir Oltean
2022-06-28 15:33 ` Vladimir Oltean
2022-06-28 16:08 ` Vladimir Oltean
2022-06-28 16:08 ` Vladimir Oltean
2022-06-28 17:25 ` Colin Foster
2022-06-28 17:25 ` Colin Foster
2022-06-28 18:47 ` Vladimir Oltean
2022-06-28 18:47 ` Vladimir Oltean
2022-06-28 18:56 ` Vladimir Oltean
2022-06-28 18:56 ` Vladimir Oltean
2022-06-28 19:04 ` Andy Shevchenko
2022-06-28 19:04 ` Andy Shevchenko
2022-06-28 19:56 ` Colin Foster
2022-06-28 19:56 ` Colin Foster
2022-06-29 17:53 ` Vladimir Oltean
2022-06-29 17:53 ` Vladimir Oltean
2022-06-29 20:39 ` Colin Foster
2022-06-29 20:39 ` Colin Foster
2022-06-29 23:08 ` Vladimir Oltean
2022-06-29 23:08 ` Vladimir Oltean
2022-06-29 23:54 ` Colin Foster
2022-06-29 23:54 ` Colin Foster
2022-06-30 7:54 ` Lee Jones
2022-06-30 7:54 ` Lee Jones
2022-06-30 13:11 ` Vladimir Oltean
2022-06-30 13:11 ` Vladimir Oltean
2022-06-30 20:09 ` Colin Foster
2022-06-30 20:09 ` Colin Foster
2022-07-01 16:21 ` Vladimir Oltean
2022-07-01 16:21 ` Vladimir Oltean
2022-07-01 17:18 ` Colin Foster
2022-07-01 17:18 ` Colin Foster
2022-07-02 12:42 ` Vladimir Oltean
2022-07-02 12:42 ` Vladimir Oltean
2022-07-02 16:17 ` Colin Foster
2022-07-02 16:17 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 16:26 ` Vladimir Oltean
2022-06-28 16:26 ` Vladimir Oltean
2022-06-28 18:31 ` Colin Foster
2022-06-28 18:31 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 12:53 ` Andy Shevchenko
2022-06-28 12:53 ` Andy Shevchenko
2022-06-28 18:25 ` Colin Foster
2022-06-28 18:25 ` Colin Foster
2022-06-28 19:00 ` Andy Shevchenko
2022-06-28 19:00 ` Andy Shevchenko
2022-06-30 11:56 ` Linus Walleij
2022-06-30 11:56 ` Linus Walleij
2022-06-28 8:17 ` [PATCH v11 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 12:55 ` Andy Shevchenko
2022-06-28 12:55 ` Andy Shevchenko
2022-06-28 8:17 ` [PATCH v11 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 7/9] resource: add define macro for register address resources Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512 Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 13:15 ` Rob Herring
2022-06-28 13:15 ` Rob Herring
2022-06-28 18:19 ` Colin Foster
2022-06-28 18:19 ` Colin Foster
2022-06-30 13:17 ` Vladimir Oltean
2022-06-30 13:17 ` Vladimir Oltean
2022-06-28 8:17 ` [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster
2022-06-28 8:17 ` Colin Foster
2022-06-28 20:07 ` Randy Dunlap
2022-06-28 20:07 ` Randy Dunlap
2022-06-28 20:24 ` Colin Foster
2022-06-28 20:24 ` 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.