LinuxLists.cc - [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

[permalink] [raw]

Subject: [PATCH v13 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource

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 <[email protected]>
---
MAINTAINERS | 5 ++++
include/linux/mfd/ocelot.h | 55 ++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
create mode 100644 include/linux/mfd/ocelot.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 28108e4fdb8f..f781caceeb38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14467,6 +14467,11 @@ F: net/dsa/tag_ocelot.c
F: net/dsa/tag_ocelot_8021q.c
F: tools/testing/selftests/drivers/net/ocelot/*

+OCELOT EXTERNAL SWITCH CONTROL
+M: Colin Foster <[email protected]>
+S: Supported
+F: include/linux/mfd/ocelot.h
+
OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
M: Frederic Barrat <[email protected]>
M: Andrew Donnellan <[email protected]>
diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
new file mode 100644
index 000000000000..353b7c2ee445
--- /dev/null
+++ b/include/linux/mfd/ocelot.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2022 Innovative Advantage Inc. */
+
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+struct resource;
+
+static inline struct regmap *
+ocelot_regmap_from_resource_optional(struct platform_device *pdev,
+ unsigned int index,
+ const struct regmap_config *config)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ u32 __iomem *regs;
+
+ /*
+ * Don't use get_and_ioremap_resource here, since that will invoke
+ * prints of "invalid resource" which simply add confusion
+ */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, index);
+ if (res) {
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return ERR_CAST(regs);
+ return devm_regmap_init_mmio(dev, regs, config);
+ }
+
+ /*
+ * Fall back to using REG and getting the resource from the parent
+ * device, which is possible in an MFD configuration
+ */
+ if (dev->parent) {
+ res = platform_get_resource(pdev, IORESOURCE_REG, index);
+ if (!res)
+ return NULL;
+
+ return dev_get_regmap(dev->parent, res->name);
+ }
+
+ return NULL;
+}
+
+static inline struct regmap *
+ocelot_regmap_from_resource(struct platform_device *pdev, unsigned int index,
+ const struct regmap_config *config)
+{
+ struct regmap *map;
+
+ map = ocelot_regmap_from_resource_optional(pdev, index, config);
+ return map ?: ERR_PTR(-ENOENT);
+}
--
2.25.1

2022-07-05 20:50:45

[permalink] [raw]

Subject: [PATCH v13 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration

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 <[email protected]>
---
drivers/pinctrl/pinctrl-microchip-sgpio.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index e56074b7e659..2b4167a09b3b 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -12,6 +12,7 @@
#include <linux/clk.h>
#include <linux/gpio/driver.h>
#include <linux/io.h>
+#include <linux/mfd/ocelot.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/pinctrl/pinmux.h>
@@ -904,7 +905,6 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
struct reset_control *reset;
struct sgpio_priv *priv;
struct clk *clk;
- u32 __iomem *regs;
u32 val;
struct regmap_config regmap_config = {
.reg_bits = 32,
@@ -937,11 +937,7 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
return -EINVAL;
}

- regs = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
-
- priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
+ priv->regs = ocelot_regmap_from_resource(pdev, 0, &regmap_config);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);

--
2.25.1

2022-07-05 20:51:13

[permalink] [raw]

Subject: [PATCH v13 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration

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 <[email protected]>
---
drivers/pinctrl/pinctrl-ocelot.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index d18047d2306d..80a3bba520cb 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,20 +1938,14 @@ 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, &regmap_config);
- if (IS_ERR(info->map)) {
- dev_err(dev, "Failed to create regmap\n");
- return PTR_ERR(info->map);
- }
+ info->map = ocelot_regmap_from_resource(pdev, 0, &regmap_config);
+ if (IS_ERR(info->map))
+ return dev_err_probe(dev, PTR_ERR(info->map),
+ "Failed to create regmap\n");
dev_set_drvdata(dev, info->map);
info->dev = dev;

--
2.25.1

2022-07-05 20:51:17

[permalink] [raw]

Subject: [PATCH v13 net-next 7/9] resource: add define macro for register address resources

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 <[email protected]>
---
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

2022-07-05 20:51:19

[permalink] [raw]

Subject: [PATCH v13 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512

Add devicetree bindings for SPI-controlled Ocelot chips, specifically the
VSC7512.

Signed-off-by: Colin Foster <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
---
.../devicetree/bindings/mfd/mscc,ocelot.yaml | 160 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 161 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml

diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
new file mode 100644
index 000000000000..8bf45a5673a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mscc,ocelot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ocelot Externally-Controlled Ethernet Switch
+
+maintainers:
+ - Colin Foster <[email protected]>
+
+description: |
+ The Ocelot ethernet switch family contains chips that have an internal CPU
+ (VSC7513, VSC7514) and chips that don't (VSC7511, VSC7512). All switches have
+ the option to be controlled externally, which is the purpose of this driver.
+
+ The switch family is a multi-port networking switch that supports many
+ interfaces. Additionally, the device can perform pin control, MDIO buses, and
+ external GPIO expanders.
+
+properties:
+ compatible:
+ enum:
+ - mscc,vsc7512
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ spi-max-frequency:
+ maxItems: 1
+
+patternProperties:
+ "^pinctrl@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/mscc,ocelot-pinctrl.yaml
+
+ "^gpio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/microchip,sparx5-sgpio.yaml
+ properties:
+ compatible:
+ enum:
+ - mscc,ocelot-sgpio
+
+ "^mdio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/net/mscc,miim.yaml
+ properties:
+ compatible:
+ enum:
+ - mscc,ocelot-miim
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+ - spi-max-frequency
+
+additionalProperties: false
+
+examples:
+ - |
+ ocelot_clock: ocelot-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ soc@0 {
+ compatible = "mscc,vsc7512";
+ spi-max-frequency = <2500000>;
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mdio@7107009c {
+ compatible = "mscc,ocelot-miim";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x7107009c 0x24>;
+
+ sw_phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+ };
+
+ mdio@710700c0 {
+ compatible = "mscc,ocelot-miim";
+ pinctrl-names = "default";
+ pinctrl-0 = <&miim1_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x710700c0 0x24>;
+
+ sw_phy4: ethernet-phy@4 {
+ reg = <0x4>;
+ };
+ };
+
+ gpio: pinctrl@71070034 {
+ compatible = "mscc,ocelot-pinctrl";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&gpio 0 0 22>;
+ reg = <0x71070034 0x6c>;
+
+ sgpio_pins: sgpio-pins {
+ pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
+ function = "sg0";
+ };
+
+ miim1_pins: miim1-pins {
+ pins = "GPIO_14", "GPIO_15";
+ function = "miim";
+ };
+ };
+
+ gpio@710700f8 {
+ compatible = "mscc,ocelot-sgpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-frequency = <12500000>;
+ clocks = <&ocelot_clock>;
+ microchip,sgpio-port-ranges = <0 15>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sgpio_pins>;
+ reg = <0x710700f8 0x100>;
+
+ sgpio_in0: gpio@0 {
+ compatible = "microchip,sparx5-sgpio-bank";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <64>;
+ };
+
+ sgpio_out1: gpio@1 {
+ compatible = "microchip,sparx5-sgpio-bank";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <64>;
+ };
+ };
+ };
+ };
+
+...
+
diff --git a/MAINTAINERS b/MAINTAINERS
index f781caceeb38..5e798c42fa08 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14470,6 +14470,7 @@ F: tools/testing/selftests/drivers/net/ocelot/*
OCELOT EXTERNAL SWITCH CONTROL
M: Colin Foster <[email protected]>
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

2022-07-05 20:51:30

[permalink] [raw]

Subject: [PATCH v13 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration

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 <[email protected]>
---
drivers/net/mdio/mdio-mscc-miim.c | 42 +++++++++----------------------
1 file changed, 12 insertions(+), 30 deletions(-)

diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 08541007b18a..51f68daac152 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,44 +271,25 @@ 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);
-
- if (IS_ERR(mii_regmap)) {
- dev_err(dev, "Unable to create MIIM regmap\n");
- return PTR_ERR(mii_regmap);
- }
+ mii_regmap = ocelot_regmap_from_resource(pdev, 0,
+ &mscc_miim_regmap_config);
+ if (IS_ERR(mii_regmap))
+ return dev_err_probe(dev, PTR_ERR(mii_regmap),
+ "Unable to create MIIM regmap\n");

/* This resource is optional */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (res) {
- phy_regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(phy_regs)) {
- dev_err(dev, "Unable to map internal phy registers\n");
- return PTR_ERR(phy_regs);
- }
-
- phy_regmap = devm_regmap_init_mmio(dev, phy_regs,
- &mscc_miim_phy_regmap_config);
- if (IS_ERR(phy_regmap)) {
- dev_err(dev, "Unable to create phy register regmap\n");
- return PTR_ERR(phy_regmap);
- }
- }
+ phy_regmap = ocelot_regmap_from_resource_optional(pdev, 1,
+ &mscc_miim_phy_regmap_config);
+ if (IS_ERR(phy_regmap))
+ return dev_err_probe(dev, PTR_ERR(phy_regmap),
+ "Unable to create phy register regmap\n");

ret = mscc_miim_setup(dev, &bus, "mscc_miim", mii_regmap, 0);
if (ret < 0) {
--
2.25.1

2022-07-05 20:56:43

[permalink] [raw]

Subject: [PATCH v13 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module

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 <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Reviewed-by: Vladimir Oltean <[email protected]>
---
drivers/pinctrl/Kconfig | 5 ++++-
drivers/pinctrl/pinctrl-microchip-sgpio.c | 6 +++++-
2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ba48ff8be6e2..4e8d0ae6c81e 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
@@ -310,6 +310,9 @@ config PINCTRL_MICROCHIP_SGPIO
connect control signals from SFP modules and to act as an
LED controller.

+ If compiled as a module, the module name will be
+ pinctrl-microchip-sgpio.
+
config PINCTRL_OCELOT
tristate "Pinctrl driver for the Microsemi Ocelot and Jaguar2 SoCs"
depends on OF
diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index 6f55bf7d5e05..e56074b7e659 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -999,6 +999,7 @@ static const struct of_device_id microchip_sgpio_gpio_of_match[] = {
/* sentinel */
}
};
+MODULE_DEVICE_TABLE(of, microchip_sgpio_gpio_of_match);

static struct platform_driver microchip_sgpio_pinctrl_driver = {
.driver = {
@@ -1008,4 +1009,7 @@ static struct platform_driver microchip_sgpio_pinctrl_driver = {
},
.probe = microchip_sgpio_probe,
};
-builtin_platform_driver(microchip_sgpio_pinctrl_driver);
+module_platform_driver(microchip_sgpio_pinctrl_driver);
+
+MODULE_DESCRIPTION("Microchip SGPIO Pinctrl Driver");
+MODULE_LICENSE("GPL");
--
2.25.1

2022-07-05 21:03:31

[permalink] [raw]

Subject: [PATCH v13 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module

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 <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Reviewed-by: Vladimir Oltean <[email protected]>
---
drivers/pinctrl/Kconfig | 7 ++++++-
drivers/pinctrl/pinctrl-ocelot.c | 6 +++++-
2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index f52960d2dfbe..ba48ff8be6e2 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
@@ -321,6 +321,11 @@ config PINCTRL_OCELOT
select GENERIC_PINMUX_FUNCTIONS
select OF_GPIO
select REGMAP_MMIO
+ help
+ Support for the internal GPIO interfaces on Microsemi Ocelot and
+ Jaguar2 SoCs.
+
+ If conpiled as a module, the module name will be pinctrl-ocelot.

config PINCTRL_OXNAS
bool
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 5f4a8c5c6650..d18047d2306d 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1889,6 +1889,7 @@ static const struct of_device_id ocelot_pinctrl_of_match[] = {
{ .compatible = "microchip,lan966x-pinctrl", .data = &lan966x_desc },
{},
};
+MODULE_DEVICE_TABLE(of, ocelot_pinctrl_of_match);

static struct regmap *ocelot_pinctrl_create_pincfg(struct platform_device *pdev)
{
@@ -1984,4 +1985,7 @@ static struct platform_driver ocelot_pinctrl_driver = {
},
.probe = ocelot_pinctrl_probe,
};
-builtin_platform_driver(ocelot_pinctrl_driver);
+module_platform_driver(ocelot_pinctrl_driver);
+
+MODULE_DESCRIPTION("Ocelot Chip Pinctrl Driver");
+MODULE_LICENSE("Dual MIT/GPL");
--
2.25.1

2022-07-05 21:22:20

[permalink] [raw]

Subject: [PATCH v13 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi

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 <[email protected]>
---
MAINTAINERS | 1 +
drivers/mfd/Kconfig | 21 +++
drivers/mfd/Makefile | 3 +
drivers/mfd/ocelot-core.c | 169 ++++++++++++++++++++
drivers/mfd/ocelot-spi.c | 317 ++++++++++++++++++++++++++++++++++++++
drivers/mfd/ocelot.h | 34 ++++
6 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 5e798c42fa08..e3299677cd4a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14471,6 +14471,7 @@ OCELOT EXTERNAL SWITCH CONTROL
M: Colin Foster <[email protected]>
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..0ef433d170dc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -962,6 +962,27 @@ config MFD_MENF21BMC
This driver can also be built as a module. If so the module
will be called menf21bmc.

+config MFD_OCELOT
+ tristate "Microsemi Ocelot External Control Support"
+ depends on SPI_MASTER
+ select MFD_CORE
+ select REGMAP_SPI
+ help
+ Ocelot is a family of networking chips that support multiple ethernet
+ and fibre interfaces. In addition to networking, they contain several
+ other functions, including pinctrl, MDIO, and communication with
+ external chips. While some chips have an internal processor capable of
+ running an OS, others don't. All chips can be controlled externally
+ through different interfaces, including SPI, I2C, and PCIe.
+
+ Say yes here to add support for Ocelot chips (VSC7511, VSC7512,
+ VSC7513, VSC7514) controlled externally.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ocelot-soc.
+
+ 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..0004b7e86220 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -120,6 +120,9 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o

obj-$(CONFIG_MFD_CORE) += mfd-core.o

+ocelot-soc-objs := ocelot-core.o ocelot-spi.o
+obj-$(CONFIG_MFD_OCELOT) += ocelot-soc.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..e07cd901e1b3
--- /dev/null
+++ b/drivers/mfd/ocelot-core.c
@@ -0,0 +1,169 @@
+// 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 <[email protected]>
+ */
+
+#include <linux/kernel.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/ocelot.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+#include <soc/mscc/ocelot.h>
+
+#include "ocelot.h"
+
+#define REG_GCB_SOFT_RST 0x0008
+
+#define BIT_SOFT_CHIP_RST BIT(0)
+
+#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_US 100
+#define VSC7512_GCB_RST_TIMEOUT_US 100000
+
+static int ocelot_gcb_chip_rst_status(struct ocelot_ddata *ddata)
+{
+ int val, err;
+
+ err = regmap_read(ddata->gcb_regmap, REG_GCB_SOFT_RST, &val);
+ if (err)
+ val = err;
+
+ 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, REG_GCB_SOFT_RST,
+ BIT_SOFT_CHIP_RST);
+ if (ret)
+ return ret;
+
+ ret = readx_poll_timeout(ocelot_gcb_chip_rst_status, ddata, val, !val,
+ VSC7512_GCB_RST_SLEEP_US,
+ VSC7512_GCB_RST_TIMEOUT_US);
+ if (ret)
+ return dev_err_probe(ddata->dev, ret, "timeout: chip reset\n");
+
+ return 0;
+}
+EXPORT_SYMBOL_NS(ocelot_chip_reset, MFD_OCELOT);
+
+static const struct resource vsc7512_miim0_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_MIIM0_RES_START, VSC7512_MIIM0_RES_SIZE,
+ "gcb_miim0"),
+ DEFINE_RES_REG_NAMED(VSC7512_PHY_RES_START, VSC7512_PHY_RES_SIZE,
+ "gcb_phy"),
+};
+
+static const struct resource vsc7512_miim1_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_MIIM1_RES_START, VSC7512_MIIM1_RES_SIZE,
+ "gcb_miim1"),
+};
+
+static const struct resource vsc7512_pinctrl_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_GPIO_RES_START, VSC7512_GPIO_RES_SIZE,
+ "gcb_gpio"),
+};
+
+static const struct resource vsc7512_sgpio_resources[] = {
+ DEFINE_RES_REG_NAMED(VSC7512_SIO_CTRL_RES_START,
+ VSC7512_SIO_CTRL_RES_SIZE,
+ "gcb_sio"),
+};
+
+static const struct mfd_cell vsc7512_devs[] = {
+ {
+ .name = "ocelot-pinctrl",
+ .of_compatible = "mscc,ocelot-pinctrl",
+ .num_resources = ARRAY_SIZE(vsc7512_pinctrl_resources),
+ .resources = vsc7512_pinctrl_resources,
+ }, {
+ .name = "ocelot-sgpio",
+ .of_compatible = "mscc,ocelot-sgpio",
+ .num_resources = ARRAY_SIZE(vsc7512_sgpio_resources),
+ .resources = vsc7512_sgpio_resources,
+ }, {
+ .name = "ocelot-miim0",
+ .of_compatible = "mscc,ocelot-miim",
+ .of_reg = VSC7512_MIIM0_RES_START,
+ .use_of_reg = true,
+ .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
+ .resources = vsc7512_miim0_resources,
+ }, {
+ .name = "ocelot-miim1",
+ .of_compatible = "mscc,ocelot-miim",
+ .of_reg = VSC7512_MIIM1_RES_START,
+ .use_of_reg = true,
+ .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
+ .resources = vsc7512_miim1_resources,
+ },
+};
+
+static void ocelot_core_try_add_regmap(struct device *dev,
+ const struct resource *res)
+{
+ if (!dev_get_regmap(dev, res->name))
+ ocelot_spi_init_regmap(dev, res);
+}
+
+static void ocelot_core_try_add_regmaps(struct device *dev,
+ const struct mfd_cell *cell)
+{
+ int i;
+
+ for (i = 0; i < cell->num_resources; i++)
+ ocelot_core_try_add_regmap(dev, &cell->resources[i]);
+}
+
+int ocelot_core_init(struct device *dev)
+{
+ int i, ndevs;
+
+ ndevs = ARRAY_SIZE(vsc7512_devs);
+
+ for (i = 0; i < ndevs; i++)
+ ocelot_core_try_add_regmaps(dev, &vsc7512_devs[i]);
+
+ return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
+ ndevs, NULL, 0, NULL);
+}
+EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
+
+MODULE_DESCRIPTION("Externally Controlled Ocelot Chip Driver");
+MODULE_AUTHOR("Colin Foster <[email protected]>");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS(MFD_OCELOT_SPI);
diff --git a/drivers/mfd/ocelot-spi.c b/drivers/mfd/ocelot-spi.c
new file mode 100644
index 000000000000..0c1c5215c706
--- /dev/null
+++ b/drivers/mfd/ocelot-spi.c
@@ -0,0 +1,317 @@
+// 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 <[email protected]>
+ */
+
+#include <linux/ioport.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 REG_DEV_CPUORG_IF_CTRL 0x0000
+#define REG_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
+
+struct spi_device;
+
+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, REG_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, REG_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, REG_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;
+ 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 = ddata->dummy_buf;
+ padding.dummy_data = 1;
+
+ spi_message_add_tail(&padding, &msg);
+ }
+
+ memset(&rx, 0, sizeof(rx));
+ rx.rx_buf = val;
+ rx.len = val_size;
+
+ spi_message_add_tail(&rx, &msg);
+
+ return spi_sync(spi, &msg);
+}
+
+static int ocelot_spi_regmap_bus_write(void *context, const void *data,
+ size_t count)
+{
+ struct ocelot_ddata *ddata = context;
+ struct spi_device *spi = ddata->spi;
+
+ return spi_write(spi, data, count);
+}
+
+static const struct regmap_bus ocelot_spi_regmap_bus = {
+ .write = ocelot_spi_regmap_bus_write,
+ .read = ocelot_spi_regmap_bus_read,
+};
+
+struct regmap *
+ocelot_spi_init_regmap(struct device *dev, const struct resource *res)
+{
+ struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+ struct regmap_config regmap_config;
+
+ memcpy(&regmap_config, &ocelot_spi_regmap_config,
+ sizeof(regmap_config));
+
+ regmap_config.name = res->name;
+ regmap_config.max_register = res->end - res->start;
+ regmap_config.reg_base = res->start;
+
+ return devm_regmap_init(dev, &ocelot_spi_regmap_bus, ddata,
+ &regmap_config);
+}
+EXPORT_SYMBOL_NS(ocelot_spi_init_regmap, MFD_OCELOT_SPI);
+
+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->dummy_buf = devm_kzalloc(dev, ddata->spi_padding_bytes,
+ GFP_KERNEL);
+ if (!ddata->dummy_buf)
+ return -ENOMEM;
+ }
+
+ ddata->spi = spi;
+ spi->bits_per_word = 8;
+
+ err = spi_setup(spi);
+ if (err < 0)
+ return dev_err_probe(&spi->dev, err,
+ "Error performing SPI setup\n");
+
+ r = ocelot_spi_init_regmap(dev, &vsc7512_dev_cpuorg_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->cpuorg_regmap = r;
+
+ r = ocelot_spi_init_regmap(dev, &vsc7512_gcb_resource);
+ if (IS_ERR(r))
+ return PTR_ERR(r);
+
+ ddata->gcb_regmap = r;
+
+ /*
+ * The chip must be set up for SPI before it gets initialized and reset.
+ * This must be done before calling init, and after a chip reset is
+ * performed.
+ */
+ err = ocelot_spi_initialize(dev);
+ if (err)
+ return dev_err_probe(dev, err, "Error initializing SPI bus\n");
+
+ err = ocelot_chip_reset(dev);
+ if (err)
+ return dev_err_probe(dev, err, "Error resetting device\n");
+
+ /*
+ * A chip reset will clear the SPI configuration, so it needs to be done
+ * again before we can access any registers
+ */
+ err = ocelot_spi_initialize(dev);
+ if (err)
+ return dev_err_probe(dev, err,
+ "Error initializing SPI bus after reset\n");
+
+ err = ocelot_core_init(dev);
+ if (err < 0)
+ return dev_err_probe(dev, err,
+ "Error initializing Ocelot core\n");
+
+ return 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-soc",
+ .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 <[email protected]>");
+MODULE_LICENSE("Dual MIT/GPL");
+MODULE_IMPORT_NS(MFD_OCELOT);
diff --git a/drivers/mfd/ocelot.h b/drivers/mfd/ocelot.h
new file mode 100644
index 000000000000..c86bd6990a3c
--- /dev/null
+++ b/drivers/mfd/ocelot.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright 2021, 2022 Innovative Advantage Inc. */
+
+#include <asm/byteorder.h>
+
+struct device;
+struct spi_device;
+struct regmap;
+struct resource;
+
+struct ocelot_ddata {
+ struct device *dev;
+ struct regmap *gcb_regmap;
+ struct regmap *cpuorg_regmap;
+ int spi_padding_bytes;
+ struct spi_device *spi;
+ void *dummy_buf;
+};
+
+int ocelot_chip_reset(struct device *dev);
+int ocelot_core_init(struct device *dev);
+
+/* SPI-specific routines that won't be necessary for other interfaces */
+struct regmap *ocelot_spi_init_regmap(struct device *dev,
+ const struct resource *res);
+
+#define OCELOT_SPI_BYTE_ORDER_LE 0x00000000
+#define OCELOT_SPI_BYTE_ORDER_BE 0x81818181
+
+#ifdef __LITTLE_ENDIAN
+#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_LE
+#else
+#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_BE
+#endif
--
2.25.1

2022-07-09 03:40:21

by Jakub Kicinski

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

On Tue, 5 Jul 2022 13:47:34 -0700 Colin Foster wrote:
> The patch set in general is to add support for the VSC7512, and
> eventually the VSC7511, VSC7513 and VSC7514 devices controlled over
> SPI. Specifically this patch set enables pinctrl, serial gpio expander
> access, and control of an internal and an external MDIO bus.

Can this go into net-next if there are no more complains over the
weekend? Anyone still planning to review?

Linus's ack on patch 6 and an MFD Ack from Lee would be great.

2022-07-09 19:01:24

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource

On Tue, Jul 05, 2022 at 01:47:35PM -0700, Colin Foster wrote:
> Several ocelot-related modules are designed for MMIO / regmaps. As such,
> they often use a combination of devm_platform_get_and_ioremap_resource and
> devm_regmap_init_mmio.
>
> Operating in an MFD might be different, in that it could be memory mapped,
> or it could be SPI, I2C... In these cases a fallback to use IORESOURCE_REG
> instead of IORESOURCE_MEM becomes necessary.
>
> When this happens, there's redundant logic that needs to be implemented in
> every driver. In order to avoid this redundancy, utilize a single function
> that, if the MFD scenario is enabled, will perform this fallback logic.
>
> Signed-off-by: Colin Foster <[email protected]>
> ---

To me this looks good, I'll just add a few minor comments which I think
you don't necessarily need to address by resending, they're just things
I noticed.

Reviewed-by: Vladimir Oltean <[email protected]>

> MAINTAINERS | 5 ++++
> include/linux/mfd/ocelot.h | 55 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
> create mode 100644 include/linux/mfd/ocelot.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 28108e4fdb8f..f781caceeb38 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14467,6 +14467,11 @@ F: net/dsa/tag_ocelot.c
> F: net/dsa/tag_ocelot_8021q.c
> F: tools/testing/selftests/drivers/net/ocelot/*
>
> +OCELOT EXTERNAL SWITCH CONTROL
> +M: Colin Foster <[email protected]>
> +S: Supported
> +F: include/linux/mfd/ocelot.h
> +
> OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
> M: Frederic Barrat <[email protected]>
> M: Andrew Donnellan <[email protected]>
> diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> new file mode 100644
> index 000000000000..353b7c2ee445
> --- /dev/null
> +++ b/include/linux/mfd/ocelot.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +/* Copyright 2022 Innovative Advantage Inc. */

A header file should have ifdefs which should prevent double inclusion,
like

#ifndef _MFD_OCELOT_H
#define _MFD_OCELOT_H

...

#endif

> +
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>
> +
> +struct resource;

IMO if include/linux/platform_device.h doesn't provide "struct resource"
that's a problem for that header to solve, not for its users.

> +
> +static inline struct regmap *
> +ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> + unsigned int index,
> + const struct regmap_config *config)
> +{
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + u32 __iomem *regs;

"regs" could be void *.

> +
> + /*
> + * Don't use get_and_ioremap_resource here, since that will invoke
> + * prints of "invalid resource" which simply add confusion
> + */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> + if (res) {
> + regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(regs))
> + return ERR_CAST(regs);
> + return devm_regmap_init_mmio(dev, regs, config);
> + }
> +
> + /*
> + * Fall back to using REG and getting the resource from the parent
> + * device, which is possible in an MFD configuration
> + */
> + if (dev->parent) {
> + res = platform_get_resource(pdev, IORESOURCE_REG, index);
> + if (!res)
> + return NULL;
> +
> + return dev_get_regmap(dev->parent, res->name);
> + }
> +
> + return NULL;
> +}
> +
> +static inline struct regmap *
> +ocelot_regmap_from_resource(struct platform_device *pdev, unsigned int index,
> + const struct regmap_config *config)
> +{
> + struct regmap *map;
> +
> + map = ocelot_regmap_from_resource_optional(pdev, index, config);
> + return map ?: ERR_PTR(-ENOENT);
> +}
> --
> 2.25.1
>

2022-07-09 19:04:08

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration

On Tue, Jul 05, 2022 at 01:47:36PM -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 <[email protected]>
> ---

Reviewed-by: Vladimir Oltean <[email protected]>

2022-07-09 19:05:37

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration

On Tue, Jul 05, 2022 at 01:47:40PM -0700, Colin Foster wrote:
> 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 <[email protected]>
> ---

Reviewed-by: Vladimir Oltean <[email protected]>

2022-07-09 19:53:36

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 7/9] resource: add define macro for register address resources

On Tue, Jul 05, 2022 at 01:47:41PM -0700, Colin Foster wrote:
> 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 <[email protected]>
> ---

Reviewed-by: Vladimir Oltean <[email protected]>

2022-07-09 20:03:16

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration

On Tue, Jul 05, 2022 at 01:47:38PM -0700, Colin Foster wrote:
> 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 <[email protected]>
> ---

Reviewed-by: Vladimir Oltean <[email protected]>

2022-07-11 08:01:28

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

On Fri, 08 Jul 2022, Jakub Kicinski wrote:

> On Tue, 5 Jul 2022 13:47:34 -0700 Colin Foster wrote:
> > The patch set in general is to add support for the VSC7512, and
> > eventually the VSC7511, VSC7513 and VSC7514 devices controlled over
> > SPI. Specifically this patch set enables pinctrl, serial gpio expander
> > access, and control of an internal and an external MDIO bus.
>
> Can this go into net-next if there are no more complains over the
> weekend? Anyone still planning to review?

As the subsystem with the fewest changes, I'm not sure why it would.

I'd planed to route this in via MFD and send out a pull-request for
other sub-system maintainers to pull from.

If you would like to co-ordinate it instead, you'd be welcome to.
However, I (and probably Linus) would need a succinct immutable branch
to pull from.

> Linus's ack on patch 6 and an MFD Ack from Lee would be great.

--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

2022-07-11 08:42:13

by Linus Walleij

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration

On Tue, Jul 5, 2022 at 10:48 PM Colin Foster
<[email protected]> wrote:

> 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 <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-07-11 09:08:18

by Linus Walleij

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration

On Tue, Jul 5, 2022 at 10:48 PM Colin Foster
<[email protected]> wrote:

> 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 <[email protected]>

Acked-by: Linus Walleij <[email protected]>

Yours,
Linus Walleij

2022-07-11 13:38:25

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi

On Tue, Jul 05, 2022 at 01:47:43PM -0700, Colin Foster wrote:
> The VSC7512 is a networking chip that contains several peripherals. Many of
> these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> controlled externally.
>
> Utilize the existing drivers by referencing the chip as an MFD. Add support
> for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.
>
> Signed-off-by: Colin Foster <[email protected]>
> ---

Reviewed-by: Vladimir Oltean <[email protected]>

2022-07-11 14:09:54

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512

On Tue, Jul 05, 2022 at 01:47:42PM -0700, Colin Foster wrote:
> Add devicetree bindings for SPI-controlled Ocelot chips, specifically the
> VSC7512.
>
> Signed-off-by: Colin Foster <[email protected]>
> Reviewed-by: Rob Herring <[email protected]>
> ---

Reviewed-by: Vladimir Oltean <[email protected]>

2022-07-11 18:25:03

by Jakub Kicinski

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote:
> > Can this go into net-next if there are no more complains over the
> > weekend? Anyone still planning to review?
>
> As the subsystem with the fewest changes, I'm not sure why it would.

Yeah, just going by the tag in the subject. I have no preference,
looks like it applies cleanly to Linus'.

> I'd planed to route this in via MFD and send out a pull-request for
> other sub-system maintainers to pull from.
>
> If you would like to co-ordinate it instead, you'd be welcome to.
> However, I (and probably Linus) would need a succinct immutable branch
> to pull from.

Oh, that'd be perfect, sorry, I didn't realize there was already a plan.
If you're willing to carry on as intended, please do.

Colin if there is another version please make a note of the above
merging plan in the cover letter and drop the net-next tag.
Just in case my goldfish brain forgets.

2022-07-11 18:39:58

by Jakub Kicinski

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration

On Tue, 5 Jul 2022 13:47:36 -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 <[email protected]>

Since the patch may go via MFD:

Acked-by: Jakub Kicinski <[email protected]>

2022-07-11 19:23:01

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

On Mon, Jul 11, 2022 at 11:21:16AM -0700, Jakub Kicinski wrote:
> On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote:
> > > Can this go into net-next if there are no more complains over the
> > > weekend? Anyone still planning to review?
> >
> > As the subsystem with the fewest changes, I'm not sure why it would.
>
> Yeah, just going by the tag in the subject. I have no preference,
> looks like it applies cleanly to Linus'.
>
> > I'd planed to route this in via MFD and send out a pull-request for
> > other sub-system maintainers to pull from.
> >
> > If you would like to co-ordinate it instead, you'd be welcome to.
> > However, I (and probably Linus) would need a succinct immutable branch
> > to pull from.
>
> Oh, that'd be perfect, sorry, I didn't realize there was already a plan.
> If you're willing to carry on as intended, please do.
>
> Colin if there is another version please make a note of the above
> merging plan in the cover letter and drop the net-next tag.
> Just in case my goldfish brain forgets.

I wasn't sure of the plan, but this makes sense to bring it through MFD.
Fortunately there's enough work for me on the DSA front that there's no
way that'll land before this merge window - so I have no objection to it
going any non-net-next path.

I'll look to Lee as to whether there should be a v14 with the header
guard addition per Vladimir's review, or whether that should be in a
future patch set. I'm happy to go either way.

2022-07-12 22:11:32

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

On Mon, Jul 11, 2022 at 07:10:48PM -0700, Colin Foster wrote:
> On Mon, Jul 11, 2022 at 11:21:16AM -0700, Jakub Kicinski wrote:
> > On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote:
> > > > Can this go into net-next if there are no more complains over the
> > > > weekend? Anyone still planning to review?
> > >
> > > As the subsystem with the fewest changes, I'm not sure why it would.
> >
> > Yeah, just going by the tag in the subject. I have no preference,
> > looks like it applies cleanly to Linus'.
> >
> > > I'd planed to route this in via MFD and send out a pull-request for
> > > other sub-system maintainers to pull from.
> > >
> > > If you would like to co-ordinate it instead, you'd be welcome to.
> > > However, I (and probably Linus) would need a succinct immutable branch
> > > to pull from.
> >
> > Oh, that'd be perfect, sorry, I didn't realize there was already a plan.
> > If you're willing to carry on as intended, please do.
> >
> > Colin if there is another version please make a note of the above
> > merging plan in the cover letter and drop the net-next tag.
> > Just in case my goldfish brain forgets.
>
> I wasn't sure of the plan, but this makes sense to bring it through MFD.
> Fortunately there's enough work for me on the DSA front that there's no
> way that'll land before this merge window - so I have no objection to it
> going any non-net-next path.
>
> I'll look to Lee as to whether there should be a v14 with the header
> guard addition per Vladimir's review, or whether that should be in a
> future patch set. I'm happy to go either way.

From my side, the changes to this patch set can be incremental, I'd be
happy if Lee would take them as is.

2022-07-15 17:08:41

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

On Tue, Jul 12, 2022 at 10:08:57PM +0000, Vladimir Oltean wrote:
> On Mon, Jul 11, 2022 at 07:10:48PM -0700, Colin Foster wrote:
> > On Mon, Jul 11, 2022 at 11:21:16AM -0700, Jakub Kicinski wrote:
> > > On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote:
> > > > > Can this go into net-next if there are no more complains over the
> > > > > weekend? Anyone still planning to review?
> > > >
> > > > As the subsystem with the fewest changes, I'm not sure why it would.
> > >
> > > Yeah, just going by the tag in the subject. I have no preference,
> > > looks like it applies cleanly to Linus'.
> > >
> > > > I'd planed to route this in via MFD and send out a pull-request for
> > > > other sub-system maintainers to pull from.
> > > >
> > > > If you would like to co-ordinate it instead, you'd be welcome to.
> > > > However, I (and probably Linus) would need a succinct immutable branch
> > > > to pull from.
> > >
> > > Oh, that'd be perfect, sorry, I didn't realize there was already a plan.
> > > If you're willing to carry on as intended, please do.
> > >
> > > Colin if there is another version please make a note of the above
> > > merging plan in the cover letter and drop the net-next tag.
> > > Just in case my goldfish brain forgets.
> >
> > I wasn't sure of the plan, but this makes sense to bring it through MFD.
> > Fortunately there's enough work for me on the DSA front that there's no
> > way that'll land before this merge window - so I have no objection to it
> > going any non-net-next path.
> >
> > I'll look to Lee as to whether there should be a v14 with the header
> > guard addition per Vladimir's review, or whether that should be in a
> > future patch set. I'm happy to go either way.
>
> From my side, the changes to this patch set can be incremental, I'd be
> happy if Lee would take them as is.

Just making sure this hasn't slipped through the cracks. Should I resend
this next week (Monday / Tuesday?) with the Reviewed-by tags and switch
it to MFD instead of net-next?

2022-07-18 08:19:45

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 0/9] add support for VSC7512 control over SPI

On Fri, 15 Jul 2022, Colin Foster wrote:

> On Tue, Jul 12, 2022 at 10:08:57PM +0000, Vladimir Oltean wrote:
> > On Mon, Jul 11, 2022 at 07:10:48PM -0700, Colin Foster wrote:
> > > On Mon, Jul 11, 2022 at 11:21:16AM -0700, Jakub Kicinski wrote:
> > > > On Mon, 11 Jul 2022 08:51:35 +0100 Lee Jones wrote:
> > > > > > Can this go into net-next if there are no more complains over the
> > > > > > weekend? Anyone still planning to review?
> > > > >
> > > > > As the subsystem with the fewest changes, I'm not sure why it would.
> > > >
> > > > Yeah, just going by the tag in the subject. I have no preference,
> > > > looks like it applies cleanly to Linus'.
> > > >
> > > > > I'd planed to route this in via MFD and send out a pull-request for
> > > > > other sub-system maintainers to pull from.
> > > > >
> > > > > If you would like to co-ordinate it instead, you'd be welcome to.
> > > > > However, I (and probably Linus) would need a succinct immutable branch
> > > > > to pull from.
> > > >
> > > > Oh, that'd be perfect, sorry, I didn't realize there was already a plan.
> > > > If you're willing to carry on as intended, please do.
> > > >
> > > > Colin if there is another version please make a note of the above
> > > > merging plan in the cover letter and drop the net-next tag.
> > > > Just in case my goldfish brain forgets.
> > >
> > > I wasn't sure of the plan, but this makes sense to bring it through MFD.
> > > Fortunately there's enough work for me on the DSA front that there's no
> > > way that'll land before this merge window - so I have no objection to it
> > > going any non-net-next path.
> > >
> > > I'll look to Lee as to whether there should be a v14 with the header
> > > guard addition per Vladimir's review, or whether that should be in a
> > > future patch set. I'm happy to go either way.
> >
> > From my side, the changes to this patch set can be incremental, I'd be
> > happy if Lee would take them as is.
>
> Just making sure this hasn't slipped through the cracks. Should I resend
> this next week (Monday / Tuesday?) with the Reviewed-by tags and switch
> it to MFD instead of net-next?

Not yet please.

--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

2022-07-18 14:21:21

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi

On Tue, 05 Jul 2022, Colin Foster wrote:

> The VSC7512 is a networking chip that contains several peripherals. Many of
> these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> controlled externally.
>
> Utilize the existing drivers by referencing the chip as an MFD. Add support
> for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.
>
> Signed-off-by: Colin Foster <[email protected]>
> ---
> MAINTAINERS | 1 +
> drivers/mfd/Kconfig | 21 +++
> drivers/mfd/Makefile | 3 +
> drivers/mfd/ocelot-core.c | 169 ++++++++++++++++++++
> drivers/mfd/ocelot-spi.c | 317 ++++++++++++++++++++++++++++++++++++++
> drivers/mfd/ocelot.h | 34 ++++
> 6 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

Generally this is looking much better.

Almost ready for inclusion with just a few nits.

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5e798c42fa08..e3299677cd4a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14471,6 +14471,7 @@ OCELOT EXTERNAL SWITCH CONTROL
> M: Colin Foster <[email protected]>
> 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..0ef433d170dc 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -962,6 +962,27 @@ config MFD_MENF21BMC
> This driver can also be built as a module. If so the module
> will be called menf21bmc.
>
> +config MFD_OCELOT
> + tristate "Microsemi Ocelot External Control Support"
> + depends on SPI_MASTER
> + select MFD_CORE
> + select REGMAP_SPI
> + help
> + Ocelot is a family of networking chips that support multiple ethernet
> + and fibre interfaces. In addition to networking, they contain several
> + other functions, including pinctrl, MDIO, and communication with
> + external chips. While some chips have an internal processor capable of
> + running an OS, others don't. All chips can be controlled externally
> + through different interfaces, including SPI, I2C, and PCIe.
> +
> + Say yes here to add support for Ocelot chips (VSC7511, VSC7512,
> + VSC7513, VSC7514) controlled externally.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called ocelot-soc.
> +
> + 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..0004b7e86220 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -120,6 +120,9 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
>
> obj-$(CONFIG_MFD_CORE) += mfd-core.o
>
> +ocelot-soc-objs := ocelot-core.o ocelot-spi.o
> +obj-$(CONFIG_MFD_OCELOT) += ocelot-soc.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..e07cd901e1b3
> --- /dev/null
> +++ b/drivers/mfd/ocelot-core.c
> @@ -0,0 +1,169 @@
> +// 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.

Range?

> + * Author: Colin Foster <[email protected]>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/ocelot.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>
> +
> +#include <soc/mscc/ocelot.h>
> +
> +#include "ocelot.h"
> +
> +#define REG_GCB_SOFT_RST 0x0008
> +
> +#define BIT_SOFT_CHIP_RST BIT(0)
> +
> +#define VSC7512_MIIM0_RES_START 0x7107009c
> +#define VSC7512_MIIM0_RES_SIZE 0x24
> +
> +#define VSC7512_MIIM1_RES_START 0x710700c0
> +#define VSC7512_MIIM1_RES_SIZE 0x24

Maybe:

#define VSC7512_MIIM0_RES_START 0x7107009c
#define VSC7512_MIIM1_RES_START 0x710700c0
#define VSC7512_MIIM_RES_SIZE 0x24

No strong feelings about this though, just saves a line or two.

> +#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_US 100
> +#define VSC7512_GCB_RST_TIMEOUT_US 100000
> +
> +static int ocelot_gcb_chip_rst_status(struct ocelot_ddata *ddata)
> +{
> + int val, err;
> +
> + err = regmap_read(ddata->gcb_regmap, REG_GCB_SOFT_RST, &val);
> + if (err)
> + val = err;

I think just returning err is clearer.

> + 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, REG_GCB_SOFT_RST,
> + BIT_SOFT_CHIP_RST);

Lots of these line-breaks can be removed which will tidy-up the file
quite a bit. The new max is 100 chars. So long as checkpatch.pl
doesn't complain, I'm happy.

> + if (ret)
> + return ret;
> +
> + ret = readx_poll_timeout(ocelot_gcb_chip_rst_status, ddata, val, !val,
> + VSC7512_GCB_RST_SLEEP_US,
> + VSC7512_GCB_RST_TIMEOUT_US);
> + if (ret)
> + return dev_err_probe(ddata->dev, ret, "timeout: chip reset\n");

*This* function is not probe.

Also the last failure will produce 2 prints due to the dev_err_probe()
in actual .probe() below. Please fix that.

> + 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"),

Lots of early breaks coming up - I won't comment on them all.

> + DEFINE_RES_REG_NAMED(VSC7512_PHY_RES_START, VSC7512_PHY_RES_SIZE,
> + "gcb_phy"),
> +};
> +
> +static const struct resource vsc7512_miim1_resources[] = {
> + DEFINE_RES_REG_NAMED(VSC7512_MIIM1_RES_START, VSC7512_MIIM1_RES_SIZE,
> + "gcb_miim1"),
> +};
> +
> +static const struct resource vsc7512_pinctrl_resources[] = {
> + DEFINE_RES_REG_NAMED(VSC7512_GPIO_RES_START, VSC7512_GPIO_RES_SIZE,
> + "gcb_gpio"),
> +};
> +
> +static const struct resource vsc7512_sgpio_resources[] = {
> + DEFINE_RES_REG_NAMED(VSC7512_SIO_CTRL_RES_START,
> + VSC7512_SIO_CTRL_RES_SIZE,
> + "gcb_sio"),
> +};
> +
> +static const struct mfd_cell vsc7512_devs[] = {
> + {
> + .name = "ocelot-pinctrl",
> + .of_compatible = "mscc,ocelot-pinctrl",
> + .num_resources = ARRAY_SIZE(vsc7512_pinctrl_resources),
> + .resources = vsc7512_pinctrl_resources,
> + }, {
> + .name = "ocelot-sgpio",
> + .of_compatible = "mscc,ocelot-sgpio",
> + .num_resources = ARRAY_SIZE(vsc7512_sgpio_resources),
> + .resources = vsc7512_sgpio_resources,
> + }, {
> + .name = "ocelot-miim0",
> + .of_compatible = "mscc,ocelot-miim",
> + .of_reg = VSC7512_MIIM0_RES_START,
> + .use_of_reg = true,
> + .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> + .resources = vsc7512_miim0_resources,
> + }, {
> + .name = "ocelot-miim1",
> + .of_compatible = "mscc,ocelot-miim",
> + .of_reg = VSC7512_MIIM1_RES_START,
> + .use_of_reg = true,
> + .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> + .resources = vsc7512_miim1_resources,
> + },
> +};
> +
> +static void ocelot_core_try_add_regmap(struct device *dev,
> + const struct resource *res)
> +{
> + if (!dev_get_regmap(dev, res->name))
> + ocelot_spi_init_regmap(dev, res);

This is probably clearer at first-glance for readers:

if (dev_get_regmap(dev, res->name))
return;

ocelot_spi_init_regmap(dev, res);

> +}
> +
> +static void ocelot_core_try_add_regmaps(struct device *dev,
> + const struct mfd_cell *cell)
> +{
> + int i;
> +
> + for (i = 0; i < cell->num_resources; i++)
> + ocelot_core_try_add_regmap(dev, &cell->resources[i]);
> +}
> +
> +int ocelot_core_init(struct device *dev)
> +{
> + int i, ndevs;
> +
> + ndevs = ARRAY_SIZE(vsc7512_devs);
> +
> + for (i = 0; i < ndevs; i++)
> + ocelot_core_try_add_regmaps(dev, &vsc7512_devs[i]);
> +
> + return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> + ndevs, NULL, 0, NULL);
> +}
> +EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
> +
> +MODULE_DESCRIPTION("Externally Controlled Ocelot Chip Driver");
> +MODULE_AUTHOR("Colin Foster <[email protected]>");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS(MFD_OCELOT_SPI);
> diff --git a/drivers/mfd/ocelot-spi.c b/drivers/mfd/ocelot-spi.c
> new file mode 100644
> index 000000000000..0c1c5215c706
> --- /dev/null
> +++ b/drivers/mfd/ocelot-spi.c
> @@ -0,0 +1,317 @@
> +// 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 <[email protected]>
> + */
> +
> +#include <linux/ioport.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 REG_DEV_CPUORG_IF_CTRL 0x0000
> +#define REG_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
> +
> +struct spi_device;

Why not just #include?

> +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, REG_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, REG_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, REG_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;
> + struct spi_transfer tx, padding, rx;
> + struct spi_device *spi = ddata->spi;
> + struct spi_message msg;
> +
> + spi = ddata->spi;

Drop this line.

> + 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 = ddata->dummy_buf;
> + padding.dummy_data = 1;
> +
> + spi_message_add_tail(&padding, &msg);
> + }
> +
> + memset(&rx, 0, sizeof(rx));
> + rx.rx_buf = val;
> + rx.len = val_size;
> +
> + spi_message_add_tail(&rx, &msg);
> +
> + return spi_sync(spi, &msg);
> +}
> +
> +static int ocelot_spi_regmap_bus_write(void *context, const void *data,
> + size_t count)
> +{
> + struct ocelot_ddata *ddata = context;
> + struct spi_device *spi = ddata->spi;
> +
> + return spi_write(spi, data, count);
> +}
> +
> +static const struct regmap_bus ocelot_spi_regmap_bus = {
> + .write = ocelot_spi_regmap_bus_write,
> + .read = ocelot_spi_regmap_bus_read,
> +};
> +
> +struct regmap *
> +ocelot_spi_init_regmap(struct device *dev, const struct resource *res)

One line, along with all the others.

> +{
> + struct ocelot_ddata *ddata = dev_get_drvdata(dev);
> + struct regmap_config regmap_config;
> +
> + memcpy(&regmap_config, &ocelot_spi_regmap_config,
> + sizeof(regmap_config));
> +
> + regmap_config.name = res->name;
> + regmap_config.max_register = res->end - res->start;
> + regmap_config.reg_base = res->start;
> +
> + return devm_regmap_init(dev, &ocelot_spi_regmap_bus, ddata,
> + &regmap_config);
> +}
> +EXPORT_SYMBOL_NS(ocelot_spi_init_regmap, MFD_OCELOT_SPI);
> +
> +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;

How are you fetching ddata if you don't already have 'dev'?

> + dev_set_drvdata(dev, ddata);

This should use the spi_* variant.

> + 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->dummy_buf = devm_kzalloc(dev, ddata->spi_padding_bytes,
> + GFP_KERNEL);
> + if (!ddata->dummy_buf)
> + return -ENOMEM;
> + }
> +
> + ddata->spi = spi;

If you have 'spi' you definitely do not need 'dev'.

You can derive one from the other.

> + spi->bits_per_word = 8;
> +
> + err = spi_setup(spi);
> + if (err < 0)
> + return dev_err_probe(&spi->dev, err,
> + "Error performing SPI setup\n");
> +
> + r = ocelot_spi_init_regmap(dev, &vsc7512_dev_cpuorg_resource);
> + if (IS_ERR(r))
> + return PTR_ERR(r);
> +
> + ddata->cpuorg_regmap = r;
> +
> + r = ocelot_spi_init_regmap(dev, &vsc7512_gcb_resource);
> + if (IS_ERR(r))
> + return PTR_ERR(r);
> +
> + ddata->gcb_regmap = r;
> +
> + /*
> + * The chip must be set up for SPI before it gets initialized and reset.
> + * This must be done before calling init, and after a chip reset is
> + * performed.
> + */
> + err = ocelot_spi_initialize(dev);
> + if (err)
> + return dev_err_probe(dev, err, "Error initializing SPI bus\n");
> +
> + err = ocelot_chip_reset(dev);
> + if (err)
> + return dev_err_probe(dev, err, "Error resetting device\n");
> +
> + /*
> + * A chip reset will clear the SPI configuration, so it needs to be done
> + * again before we can access any registers
> + */
> + err = ocelot_spi_initialize(dev);
> + if (err)
> + return dev_err_probe(dev, err,
> + "Error initializing SPI bus after reset\n");
> +
> + err = ocelot_core_init(dev);
> + if (err < 0)
> + return dev_err_probe(dev, err,
> + "Error initializing Ocelot core\n");
> +
> + return 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-soc",
> + .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 <[email protected]>");
> +MODULE_LICENSE("Dual MIT/GPL");
> +MODULE_IMPORT_NS(MFD_OCELOT);
> diff --git a/drivers/mfd/ocelot.h b/drivers/mfd/ocelot.h
> new file mode 100644
> index 000000000000..c86bd6990a3c
> --- /dev/null
> +++ b/drivers/mfd/ocelot.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +/* Copyright 2021, 2022 Innovative Advantage Inc. */
> +
> +#include <asm/byteorder.h>
> +
> +struct device;
> +struct spi_device;
> +struct regmap;
> +struct resource;
> +
> +struct ocelot_ddata {
> + struct device *dev;
> + struct regmap *gcb_regmap;
> + struct regmap *cpuorg_regmap;
> + int spi_padding_bytes;
> + struct spi_device *spi;
> + void *dummy_buf;
> +};

This looks like it deserves a doc header.

> +int ocelot_chip_reset(struct device *dev);
> +int ocelot_core_init(struct device *dev);
> +
> +/* SPI-specific routines that won't be necessary for other interfaces */
> +struct regmap *ocelot_spi_init_regmap(struct device *dev,
> + const struct resource *res);
> +
> +#define OCELOT_SPI_BYTE_ORDER_LE 0x00000000
> +#define OCELOT_SPI_BYTE_ORDER_BE 0x81818181
> +
> +#ifdef __LITTLE_ENDIAN
> +#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_LE
> +#else
> +#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_BE
> +#endif

--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

2022-07-18 16:26:46

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi

On Mon, Jul 18, 2022 at 03:18:28PM +0100, Lee Jones wrote:
> On Tue, 05 Jul 2022, Colin Foster wrote:
>
> > The VSC7512 is a networking chip that contains several peripherals. Many of
> > these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> > controlled externally.
> >
> > Utilize the existing drivers by referencing the chip as an MFD. Add support
> > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.
> >
> > Signed-off-by: Colin Foster <[email protected]>
> > ---
> > MAINTAINERS | 1 +
> > drivers/mfd/Kconfig | 21 +++
> > drivers/mfd/Makefile | 3 +
> > drivers/mfd/ocelot-core.c | 169 ++++++++++++++++++++
> > drivers/mfd/ocelot-spi.c | 317 ++++++++++++++++++++++++++++++++++++++
> > drivers/mfd/ocelot.h | 34 ++++
> > 6 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
>
> Generally this is looking much better.
>
> Almost ready for inclusion with just a few nits.
>

Hi Lee,

Thanks for the feedback. I'll get these fixes done this week!

2022-07-19 18:03:05

[permalink] [raw]

Subject: Re: [PATCH v13 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi

On Mon, Jul 18, 2022 at 03:18:28PM +0100, Lee Jones wrote:
> On Tue, 05 Jul 2022, Colin Foster wrote:
>
> > +MODULE_IMPORT_NS(MFD_OCELOT_SPI);
> > diff --git a/drivers/mfd/ocelot-spi.c b/drivers/mfd/ocelot-spi.c
> > new file mode 100644
> > index 000000000000..0c1c5215c706
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot-spi.c
> > @@ -0,0 +1,317 @@
> > +// 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 <[email protected]>
> > + */
> > +
> > +#include <linux/ioport.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 REG_DEV_CPUORG_IF_CTRL 0x0000
> > +#define REG_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
> > +
> > +struct spi_device;
>
> Why not just #include?

I mis-understood this to mean drivers/mfd/ocelot-spi.c when it meant
drivers/mfd/ocelot.h. Thanks.

https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/#24921057

"""
You missed a lot of forward declarations that are used in this file.

Like

struct spi_device;
"""

> > +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;
> > + struct spi_transfer tx, padding, rx;
> > + struct spi_device *spi = ddata->spi;
> > + struct spi_message msg;
> > +
> > + spi = ddata->spi;
>
> Drop this line.

Yes - and actually since I'm removing ddata->spi altogether it'll become
to_spi_device(ddata->dev) (obviously without the double-assignment that
you're pointing out here)

>
> > + 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 = ddata->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;

As above, I'm changing to to_spi_device(ddata->dev)

> > +
> > + return spi_write(spi, data, count);
> > +}
> > +
> > +static const struct regmap_bus ocelot_spi_regmap_bus = {
> > + .write = ocelot_spi_regmap_bus_write,
> > + .read = ocelot_spi_regmap_bus_read,
> > +};
> > +
> > +struct regmap *
> > +ocelot_spi_init_regmap(struct device *dev, const struct resource *res)
>
> One line, along with all the others.
>
> > +{
> > + struct ocelot_ddata *ddata = dev_get_drvdata(dev);
> > + struct regmap_config regmap_config;
> > +
> > + memcpy(&regmap_config, &ocelot_spi_regmap_config,
> > + sizeof(regmap_config));
> > +
> > + regmap_config.name = res->name;
> > + regmap_config.max_register = res->end - res->start;
> > + regmap_config.reg_base = res->start;
> > +
> > + return devm_regmap_init(dev, &ocelot_spi_regmap_bus, ddata,
> > + &regmap_config);
> > +}
> > +EXPORT_SYMBOL_NS(ocelot_spi_init_regmap, MFD_OCELOT_SPI);
> > +
> > +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;
>
> How are you fetching ddata if you don't already have 'dev'?

I don't think I fully understand this question...

Are you saying ddata doesn't need a dev instance? So instead of:

devm_regmap_init(dev, &bus, ddata, &regmap_config);

It could be:

devm_regmap_init(dev, &bus, dev, &regmap_config);

In that case, the context into ocelot_spi_regmap_bus_{read,write} would
be dev, instead of ddata.

Then I get ddata from device via:

static int ocelot_spi_regmap_bus_write(void *context,...)
{
struct device *dev = context;
struct ocelot_ddata *ddata = dev_get_drvdata(dev);
struct spi_device *spi = to_spi_device(dev);

/* ddata isn't actually needed for bus_write, just making a point */
...
}

I haven't tested this yet, but I think this is what you're suggesting.
So now I've removed both spi and dev from the ddata struct (as I mention
below). Cool.

>
> > + dev_set_drvdata(dev, ddata);
>
> This should use the spi_* variant.

Agreed.

>
> > + 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->dummy_buf = devm_kzalloc(dev, ddata->spi_padding_bytes,
> > + GFP_KERNEL);
> > + if (!ddata->dummy_buf)
> > + return -ENOMEM;
> > + }
> > +
> > + ddata->spi = spi;
>
> If you have 'spi' you definitely do not need 'dev'.
>
> You can derive one from the other.

Good point. As I implied above, I'm dropping "spi" from the ddata struct
and will recover spi from to_spi_device(dev)

That does some nice things like removes "struct spi_device" from
drivers/mfd/ocelot.h

> > + spi->bits_per_word = 8;
> > +
> > + err = spi_setup(spi);
> > + if (err < 0)
> > + return dev_err_probe(&spi->dev, err,
> > + "Error performing SPI setup\n");
> > +
> > + r = ocelot_spi_init_regmap(dev, &vsc7512_dev_cpuorg_resource);
> > + if (IS_ERR(r))
> > + return PTR_ERR(r);
> > +
> > + ddata->cpuorg_regmap = r;
> > +
> > + r = ocelot_spi_init_regmap(dev, &vsc7512_gcb_resource);
> > + if (IS_ERR(r))
> > + return PTR_ERR(r);
> > +
> > + ddata->gcb_regmap = r;
> > +
> > + /*
> > + * The chip must be set up for SPI before it gets initialized and reset.
> > + * This must be done before calling init, and after a chip reset is
> > + * performed.
> > + */
> > + err = ocelot_spi_initialize(dev);
> > + if (err)
> > + return dev_err_probe(dev, err, "Error initializing SPI bus\n");
> > +
> > + err = ocelot_chip_reset(dev);
> > + if (err)
> > + return dev_err_probe(dev, err, "Error resetting device\n");
> > +
> > + /*
> > + * A chip reset will clear the SPI configuration, so it needs to be done
> > + * again before we can access any registers
> > + */
> > + err = ocelot_spi_initialize(dev);
> > + if (err)
> > + return dev_err_probe(dev, err,
> > + "Error initializing SPI bus after reset\n");
> > +
> > + err = ocelot_core_init(dev);
> > + if (err < 0)
> > + return dev_err_probe(dev, err,
> > + "Error initializing Ocelot core\n");
> > +
> > + return 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-soc",
> > + .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 <[email protected]>");
> > +MODULE_LICENSE("Dual MIT/GPL");
> > +MODULE_IMPORT_NS(MFD_OCELOT);
> > diff --git a/drivers/mfd/ocelot.h b/drivers/mfd/ocelot.h
> > new file mode 100644
> > index 000000000000..c86bd6990a3c
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot.h
> > @@ -0,0 +1,34 @@
> > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> > +/* Copyright 2021, 2022 Innovative Advantage Inc. */
> > +
> > +#include <asm/byteorder.h>
> > +
> > +struct device;
> > +struct spi_device;
> > +struct regmap;
> > +struct resource;
> > +
> > +struct ocelot_ddata {
> > + struct device *dev;
> > + struct regmap *gcb_regmap;
> > + struct regmap *cpuorg_regmap;
> > + int spi_padding_bytes;
> > + struct spi_device *spi;
> > + void *dummy_buf;
> > +};
>
> This looks like it deserves a doc header.

Will do!

>
> > +int ocelot_chip_reset(struct device *dev);
> > +int ocelot_core_init(struct device *dev);
> > +
> > +/* SPI-specific routines that won't be necessary for other interfaces */
> > +struct regmap *ocelot_spi_init_regmap(struct device *dev,
> > + const struct resource *res);
> > +
> > +#define OCELOT_SPI_BYTE_ORDER_LE 0x00000000
> > +#define OCELOT_SPI_BYTE_ORDER_BE 0x81818181
> > +
> > +#ifdef __LITTLE_ENDIAN
> > +#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_LE
> > +#else
> > +#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_BE
> > +#endif
>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

2022-07-20 08:40:06