All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-08 18:52 ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:52 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The patch set in general is to add support for the VSC7512, and
eventually the VSC7511, VSC7513 and VSC7514 devices controlled over
SPI. The driver is believed to be fully functional for the internal
phy ports (0-3)  on the VSC7512. It is not yet functional for SGMII,
QSGMII, and SerDes ports.

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.

The relevant sections of the device tree I'm using for the VSC7512 is
below. Notably the SGPIO LEDs follow link status and speed from network
triggers.

In order to make this work, I have modified the cpsw driver, and now the
cpsw_new driver, to allow for frames over 1500 bytes. Otherwise the
tagging protocol will not work between the beaglebone and the VSC7512. I
plan to eventually try to get those changes in mainline, but I don't
want to get distracted from my initial goal. I also had to change
bonecommon.dtsi to avoid using VLAN 0.

I believe much of the MFD sections are very near feature-complete,
whereas the switch section will require ongoing work to enable
additional ports / features. This could lead to a couple potential
scenarios:

The first being patches 1-8 being split into a separate patch set, while
patches 9-16 remain in the RFC state. This would offer the pinctrl /
sgpio / mdio controller functionality, but no switch control until it is
ready.

The second would assume the current state of the switch driver is
acceptable (or at least very near so) and the current patch set gets an
official PATCH set (with minor changes as necessary - e.g. squashing
patch 16 into 14). That might be ambitious.

The third would be to keep this patch set in RFC until switch
functionality is more complete. I'd understand if this was the desired
path... but it would mean me having to bug more reviewers.


/ {
	vscleds {
		compatible = "gpio-leds";
		vscled@0 {
			label = "port0led";
			gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
			default-state = "off";
			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:link";
		};
		vscled@1 {
			label = "port0led1";
			gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
			default-state = "off";
			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:1Gbps";
		};
[ ... ]
	};
};

&spi0 {
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

	ocelot-chip@0 {
		compatible = "mscc,vsc7512_mfd_spi";
		spi-max-frequency = <2500000>;
		reg = <0>;

		ethernet-switch@0 {
			compatible = "mscc,vsc7512-ext-switch";
			ports {
				#address-cells = <1>;
				#size-cells = <0>;

				port@0 {
					reg = <0>;
					label = "cpu";
					status = "okay";
					ethernet = <&mac_sw>;
					phy-handle = <&sw_phy0>;
					phy-mode = "internal";
				};

				port@1 {
					reg = <1>;
					label = "swp1";
					status = "okay";
					phy-handle = <&sw_phy1>;
					phy-mode = "internal";
				};
			};
		};

		mdio0: mdio0@0 {
			compatible = "mscc,ocelot-miim";
			#address-cells = <1>;
			#size-cells = <0>;

			sw_phy0: ethernet-phy@0 {
				reg = <0x0>;
			};

			sw_phy1: ethernet-phy@1 {
				reg = <0x1>;
			};

			sw_phy2: ethernet-phy@2 {
				reg = <0x2>;
			};

			sw_phy3: ethernet-phy@3 {
				reg = <0x3>;
			};
		};

		mdio1: mdio1@1 {
			compatible = "mscc,ocelot-miim";
			pinctrl-names = "default";
			pinctrl-0 = <&miim1>;
			#address-cells = <1>;
			#size-cells = <0>;

			sw_phy4: ethernet-phy@4 {
				reg = <0x4>;
			};

			sw_phy5: ethernet-phy@5 {
				reg = <0x5>;
			};

			sw_phy6: ethernet-phy@6 {
				reg = <0x6>;
			};

			sw_phy7: ethernet-phy@7 {
				reg = <0x7>;
			};
		};

		gpio: pinctrl@0 {
			compatible = "mscc,ocelot-pinctrl";
			gpio-controller;
			#gpio_cells = <2>;
			gpio-ranges = <&gpio 0 0 22>;

			led_shift_reg_pins: led-shift-reg-pins {
				pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
				function = "sg0";
			};

			miim1: miim1 {
				pins = "GPIO_14", "GPIO_15";
				function = "miim";
			};
		};

		sgpio: sgpio {
			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 = <&led_shift_reg_pins>;

			sgpio_in0: sgpio@0 {
				compatible = "microchip,sparx5-sgpio-bank";
				reg = <0>;
				gpio-controller;
				#gpio-cells = <3>;
				ngpios = <64>;
			};

			sgpio_out1: sgpio@1 {
				compatible = "microchip,sparx5-sgpio-bank";
				reg = <1>;
				gpio-controller;
				#gpio-cells = <3>;
				ngpios = <64>;
			};
		};
	};
};

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.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.18.0-rc5-01295-g47053e327c52 (X@X) (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #630 SMP PREEMPT Sun May 8 10:56:51 PDT 2022
...
[    2.829319] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set
[    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
[    2.842717] gpiochip_find_base: found new base at 2026
[    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
[    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
[    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
[    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
[    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
[    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
[    2.870801] gpiochip_find_base: found new base at 1962
[    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
[    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
[    2.872364] gpiochip_find_base: found new base at 1898
[    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
[    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
[    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
[    2.886929] mscc-miim ocelot-miim0.2.auto: invalid resource
[    2.893738] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
[    2.893769] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
[    2.893802] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
[    2.893898] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
[    2.893996] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
[    2.894012] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
[    3.395738] mdio_bus ocelot-miim0.2.auto-mii:00: GPIO lookup for consumer reset
[    3.395777] mdio_bus ocelot-miim0.2.auto-mii:00: using device tree for GPIO lookup
[    3.395840] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
[    3.395959] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
[    3.396069] mdio_bus ocelot-miim0.2.auto-mii:00: using lookup tables for GPIO lookup
[    3.396086] mdio_bus ocelot-miim0.2.auto-mii:00: No GPIO consumer reset found
...
[    3.449187] ocelot-ext-switch ocelot-ext-switch.4.auto: DMA mask not set
[    5.336880] ocelot-ext-switch ocelot-ext-switch.4.auto: PHY [ocelot-miim0.2.auto-mii:00] driver [Generic PHY] (irq=POLL)
[    5.349087] ocelot-ext-switch ocelot-ext-switch.4.auto: configuring for phy/internal link mode
[    5.363619] ocelot-ext-switch ocelot-ext-switch.4.auto swp1 (uninitialized): PHY [ocelot-miim0.2.auto-mii:01] driver [Generic PHY] (irq=POLL)
[    5.381396] ocelot-ext-switch ocelot-ext-switch.4.auto swp2 (uninitialized): PHY [ocelot-miim0.2.auto-mii:02] driver [Generic PHY] (irq=POLL)
[    5.398525] ocelot-ext-switch ocelot-ext-switch.4.auto swp3 (uninitialized): PHY [ocelot-miim0.2.auto-mii:03] driver [Generic PHY] (irq=POLL)
[    5.422048] device eth0 entered promiscuous mode
[    5.426785] DSA: tree 0 setup
...
[    7.450067] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
[   21.556395] cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
[   21.648564] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
[   21.667970] 8021q: adding VLAN 0 to HW filter on device eth0
[   21.705360] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: configuring for phy/internal link mode
[   22.018230] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Down
[   23.771740] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
[   24.090929] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
[   25.853021] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: Link is Up - 1Gbps/Full - flow control rx/tx


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


Colin Foster (16):
  pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
  pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
  net: ocelot: add interface to get regmaps when exernally controlled
  net: mdio: mscc-miim: add ability to be used in a non-mmio
    configuration
  pinctrl: ocelot: add ability to be used in a non-mmio configuration
  pinctrl: microchip-sgpio: add ability to be used in a non-mmio
    configuration
  resource: add define macro for register address resources
  mfd: ocelot: add support for the vsc7512 chip via spi
  net: mscc: ocelot: expose ocelot wm functions
  net: dsa: felix: add configurable device quirks
  net: mscc: ocelot: expose regfield definition to be used by other
    drivers
  net: mscc: ocelot: expose stats layout definition to be used by other
    drivers
  net: mscc: ocelot: expose vcap_props structure
  net: dsa: ocelot: add external ocelot switch control
  net: dsa: felix: add phylink_get_caps capability
  net: dsa: ocelot: utilize phylink_generic_validate

 drivers/mfd/Kconfig                        |  18 +
 drivers/mfd/Makefile                       |   2 +
 drivers/mfd/ocelot-core.c                  | 138 ++++++++
 drivers/mfd/ocelot-spi.c                   | 311 +++++++++++++++++
 drivers/mfd/ocelot.h                       |  34 ++
 drivers/net/dsa/ocelot/Kconfig             |  14 +
 drivers/net/dsa/ocelot/Makefile            |   5 +
 drivers/net/dsa/ocelot/felix.c             |  29 +-
 drivers/net/dsa/ocelot/felix.h             |   3 +
 drivers/net/dsa/ocelot/felix_vsc9959.c     |   1 +
 drivers/net/dsa/ocelot/ocelot_ext.c        | 366 +++++++++++++++++++++
 drivers/net/dsa/ocelot/seville_vsc9953.c   |   1 +
 drivers/net/ethernet/mscc/ocelot_devlink.c |  31 ++
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 230 +------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 200 +++++++++++
 drivers/net/mdio/mdio-mscc-miim.c          |  31 +-
 drivers/pinctrl/Kconfig                    |   4 +-
 drivers/pinctrl/pinctrl-microchip-sgpio.c  |  26 +-
 drivers/pinctrl/pinctrl-ocelot.c           |  35 +-
 include/linux/ioport.h                     |   5 +
 include/soc/mscc/ocelot.h                  |  19 ++
 include/soc/mscc/vsc7514_regs.h            |   6 +
 22 files changed, 1251 insertions(+), 258 deletions(-)
 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 drivers/net/dsa/ocelot/ocelot_ext.c

-- 
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] 114+ messages in thread

* [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-08 18:52 ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:52 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The patch set in general is to add support for the VSC7512, and
eventually the VSC7511, VSC7513 and VSC7514 devices controlled over
SPI. The driver is believed to be fully functional for the internal
phy ports (0-3)  on the VSC7512. It is not yet functional for SGMII,
QSGMII, and SerDes ports.

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.

The relevant sections of the device tree I'm using for the VSC7512 is
below. Notably the SGPIO LEDs follow link status and speed from network
triggers.

In order to make this work, I have modified the cpsw driver, and now the
cpsw_new driver, to allow for frames over 1500 bytes. Otherwise the
tagging protocol will not work between the beaglebone and the VSC7512. I
plan to eventually try to get those changes in mainline, but I don't
want to get distracted from my initial goal. I also had to change
bonecommon.dtsi to avoid using VLAN 0.

I believe much of the MFD sections are very near feature-complete,
whereas the switch section will require ongoing work to enable
additional ports / features. This could lead to a couple potential
scenarios:

The first being patches 1-8 being split into a separate patch set, while
patches 9-16 remain in the RFC state. This would offer the pinctrl /
sgpio / mdio controller functionality, but no switch control until it is
ready.

The second would assume the current state of the switch driver is
acceptable (or at least very near so) and the current patch set gets an
official PATCH set (with minor changes as necessary - e.g. squashing
patch 16 into 14). That might be ambitious.

The third would be to keep this patch set in RFC until switch
functionality is more complete. I'd understand if this was the desired
path... but it would mean me having to bug more reviewers.


/ {
	vscleds {
		compatible = "gpio-leds";
		vscled@0 {
			label = "port0led";
			gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
			default-state = "off";
			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:link";
		};
		vscled@1 {
			label = "port0led1";
			gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
			default-state = "off";
			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:1Gbps";
		};
[ ... ]
	};
};

&spi0 {
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

	ocelot-chip@0 {
		compatible = "mscc,vsc7512_mfd_spi";
		spi-max-frequency = <2500000>;
		reg = <0>;

		ethernet-switch@0 {
			compatible = "mscc,vsc7512-ext-switch";
			ports {
				#address-cells = <1>;
				#size-cells = <0>;

				port@0 {
					reg = <0>;
					label = "cpu";
					status = "okay";
					ethernet = <&mac_sw>;
					phy-handle = <&sw_phy0>;
					phy-mode = "internal";
				};

				port@1 {
					reg = <1>;
					label = "swp1";
					status = "okay";
					phy-handle = <&sw_phy1>;
					phy-mode = "internal";
				};
			};
		};

		mdio0: mdio0@0 {
			compatible = "mscc,ocelot-miim";
			#address-cells = <1>;
			#size-cells = <0>;

			sw_phy0: ethernet-phy@0 {
				reg = <0x0>;
			};

			sw_phy1: ethernet-phy@1 {
				reg = <0x1>;
			};

			sw_phy2: ethernet-phy@2 {
				reg = <0x2>;
			};

			sw_phy3: ethernet-phy@3 {
				reg = <0x3>;
			};
		};

		mdio1: mdio1@1 {
			compatible = "mscc,ocelot-miim";
			pinctrl-names = "default";
			pinctrl-0 = <&miim1>;
			#address-cells = <1>;
			#size-cells = <0>;

			sw_phy4: ethernet-phy@4 {
				reg = <0x4>;
			};

			sw_phy5: ethernet-phy@5 {
				reg = <0x5>;
			};

			sw_phy6: ethernet-phy@6 {
				reg = <0x6>;
			};

			sw_phy7: ethernet-phy@7 {
				reg = <0x7>;
			};
		};

		gpio: pinctrl@0 {
			compatible = "mscc,ocelot-pinctrl";
			gpio-controller;
			#gpio_cells = <2>;
			gpio-ranges = <&gpio 0 0 22>;

			led_shift_reg_pins: led-shift-reg-pins {
				pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
				function = "sg0";
			};

			miim1: miim1 {
				pins = "GPIO_14", "GPIO_15";
				function = "miim";
			};
		};

		sgpio: sgpio {
			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 = <&led_shift_reg_pins>;

			sgpio_in0: sgpio@0 {
				compatible = "microchip,sparx5-sgpio-bank";
				reg = <0>;
				gpio-controller;
				#gpio-cells = <3>;
				ngpios = <64>;
			};

			sgpio_out1: sgpio@1 {
				compatible = "microchip,sparx5-sgpio-bank";
				reg = <1>;
				gpio-controller;
				#gpio-cells = <3>;
				ngpios = <64>;
			};
		};
	};
};

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.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.18.0-rc5-01295-g47053e327c52 (X@X) (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #630 SMP PREEMPT Sun May 8 10:56:51 PDT 2022
...
[    2.829319] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set
[    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
[    2.842717] gpiochip_find_base: found new base at 2026
[    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
[    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
[    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
[    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
[    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
[    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
[    2.870801] gpiochip_find_base: found new base at 1962
[    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
[    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
[    2.872364] gpiochip_find_base: found new base at 1898
[    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
[    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
[    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
[    2.886929] mscc-miim ocelot-miim0.2.auto: invalid resource
[    2.893738] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
[    2.893769] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
[    2.893802] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
[    2.893898] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
[    2.893996] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
[    2.894012] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
[    3.395738] mdio_bus ocelot-miim0.2.auto-mii:00: GPIO lookup for consumer reset
[    3.395777] mdio_bus ocelot-miim0.2.auto-mii:00: using device tree for GPIO lookup
[    3.395840] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
[    3.395959] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
[    3.396069] mdio_bus ocelot-miim0.2.auto-mii:00: using lookup tables for GPIO lookup
[    3.396086] mdio_bus ocelot-miim0.2.auto-mii:00: No GPIO consumer reset found
...
[    3.449187] ocelot-ext-switch ocelot-ext-switch.4.auto: DMA mask not set
[    5.336880] ocelot-ext-switch ocelot-ext-switch.4.auto: PHY [ocelot-miim0.2.auto-mii:00] driver [Generic PHY] (irq=POLL)
[    5.349087] ocelot-ext-switch ocelot-ext-switch.4.auto: configuring for phy/internal link mode
[    5.363619] ocelot-ext-switch ocelot-ext-switch.4.auto swp1 (uninitialized): PHY [ocelot-miim0.2.auto-mii:01] driver [Generic PHY] (irq=POLL)
[    5.381396] ocelot-ext-switch ocelot-ext-switch.4.auto swp2 (uninitialized): PHY [ocelot-miim0.2.auto-mii:02] driver [Generic PHY] (irq=POLL)
[    5.398525] ocelot-ext-switch ocelot-ext-switch.4.auto swp3 (uninitialized): PHY [ocelot-miim0.2.auto-mii:03] driver [Generic PHY] (irq=POLL)
[    5.422048] device eth0 entered promiscuous mode
[    5.426785] DSA: tree 0 setup
...
[    7.450067] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
[   21.556395] cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
[   21.648564] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
[   21.667970] 8021q: adding VLAN 0 to HW filter on device eth0
[   21.705360] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: configuring for phy/internal link mode
[   22.018230] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Down
[   23.771740] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
[   24.090929] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
[   25.853021] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: Link is Up - 1Gbps/Full - flow control rx/tx


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


Colin Foster (16):
  pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
  pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
  net: ocelot: add interface to get regmaps when exernally controlled
  net: mdio: mscc-miim: add ability to be used in a non-mmio
    configuration
  pinctrl: ocelot: add ability to be used in a non-mmio configuration
  pinctrl: microchip-sgpio: add ability to be used in a non-mmio
    configuration
  resource: add define macro for register address resources
  mfd: ocelot: add support for the vsc7512 chip via spi
  net: mscc: ocelot: expose ocelot wm functions
  net: dsa: felix: add configurable device quirks
  net: mscc: ocelot: expose regfield definition to be used by other
    drivers
  net: mscc: ocelot: expose stats layout definition to be used by other
    drivers
  net: mscc: ocelot: expose vcap_props structure
  net: dsa: ocelot: add external ocelot switch control
  net: dsa: felix: add phylink_get_caps capability
  net: dsa: ocelot: utilize phylink_generic_validate

 drivers/mfd/Kconfig                        |  18 +
 drivers/mfd/Makefile                       |   2 +
 drivers/mfd/ocelot-core.c                  | 138 ++++++++
 drivers/mfd/ocelot-spi.c                   | 311 +++++++++++++++++
 drivers/mfd/ocelot.h                       |  34 ++
 drivers/net/dsa/ocelot/Kconfig             |  14 +
 drivers/net/dsa/ocelot/Makefile            |   5 +
 drivers/net/dsa/ocelot/felix.c             |  29 +-
 drivers/net/dsa/ocelot/felix.h             |   3 +
 drivers/net/dsa/ocelot/felix_vsc9959.c     |   1 +
 drivers/net/dsa/ocelot/ocelot_ext.c        | 366 +++++++++++++++++++++
 drivers/net/dsa/ocelot/seville_vsc9953.c   |   1 +
 drivers/net/ethernet/mscc/ocelot_devlink.c |  31 ++
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 230 +------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 200 +++++++++++
 drivers/net/mdio/mdio-mscc-miim.c          |  31 +-
 drivers/pinctrl/Kconfig                    |   4 +-
 drivers/pinctrl/pinctrl-microchip-sgpio.c  |  26 +-
 drivers/pinctrl/pinctrl-ocelot.c           |  35 +-
 include/linux/ioport.h                     |   5 +
 include/soc/mscc/ocelot.h                  |  19 ++
 include/soc/mscc/vsc7514_regs.h            |   6 +
 22 files changed, 1251 insertions(+), 258 deletions(-)
 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 drivers/net/dsa/ocelot/ocelot_ext.c

-- 
2.25.1


^ permalink raw reply	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 01/16] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:52   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:52 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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>
---
 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 003fb0e34153..30577fedb7fc 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1880,6 +1880,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)
 {
@@ -1969,3 +1970,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] 114+ messages in thread

* [RFC v8 net-next 01/16] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-05-08 18:52   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:52 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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>
---
 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 003fb0e34153..30577fedb7fc 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1880,6 +1880,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)
 {
@@ -1969,3 +1970,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] 114+ messages in thread

* [RFC v8 net-next 02/16] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:52   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:52 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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>
---
 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 80a8939ad0c0..8953175c7e3e 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -995,6 +995,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 = {
@@ -1005,3 +1006,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] 114+ messages in thread

* [RFC v8 net-next 02/16] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
@ 2022-05-08 18:52   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:52 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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>
---
 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 80a8939ad0c0..8953175c7e3e 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -995,6 +995,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 = {
@@ -1005,3 +1006,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] 114+ messages in thread

* [RFC v8 net-next 03/16] net: ocelot: add interface to get regmaps when exernally controlled
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Ocelot chips have several peripherals: pinctrl, sgpio, miim... If the chip
is in a configuration where it is being externally controlled via SPI, the
child device will need to request a resource from the parent.

Add the function call that will be used in those scenarios so that drivers
can be updated before the full functionality is added.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 include/soc/mscc/ocelot.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 8d8d46778f7e..1897119ebb9a 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -1039,4 +1039,11 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
 }
 #endif
 
+static inline struct regmap *
+ocelot_init_regmap_from_resource(struct device *child,
+				 const struct resource *res)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+
 #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] 114+ messages in thread

* [RFC v8 net-next 03/16] net: ocelot: add interface to get regmaps when exernally controlled
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Ocelot chips have several peripherals: pinctrl, sgpio, miim... If the chip
is in a configuration where it is being externally controlled via SPI, the
child device will need to request a resource from the parent.

Add the function call that will be used in those scenarios so that drivers
can be updated before the full functionality is added.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 include/soc/mscc/ocelot.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 8d8d46778f7e..1897119ebb9a 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -1039,4 +1039,11 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
 }
 #endif
 
+static inline struct regmap *
+ocelot_init_regmap_from_resource(struct device *child,
+				 const struct resource *res)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+
 #endif
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 04/16] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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 | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 08541007b18a..728883f95edf 100644
--- a/drivers/net/mdio/mdio-mscc-miim.c
+++ b/drivers/net/mdio/mdio-mscc-miim.c
@@ -18,6 +18,7 @@
 #include <linux/platform_device.h>
 #include <linux/property.h>
 #include <linux/regmap.h>
+#include <soc/mscc/ocelot.h>
 
 #define MSCC_MIIM_REG_STATUS		0x0
 #define		MSCC_MIIM_STATUS_STAT_PENDING	BIT(2)
@@ -281,11 +282,20 @@ static int mscc_miim_probe(struct platform_device *pdev)
 
 	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);
-	}
+		/* Fall back to using IORESOURCE_REG, which is possible in an
+		 * MFD configuration
+		 */
+		res = platform_get_resource(pdev, IORESOURCE_REG, 0);
+		if (!res) {
+			dev_err(dev, "Unable to get MIIM resource\n");
+			return -ENODEV;
+		}
 
-	mii_regmap = devm_regmap_init_mmio(dev, regs, &mscc_miim_regmap_config);
+		mii_regmap = ocelot_init_regmap_from_resource(dev, res);
+	} else {
+		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");
@@ -303,10 +313,15 @@ static int mscc_miim_probe(struct platform_device *pdev)
 
 		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);
-		}
+	} else {
+		res = platform_get_resource(pdev, IORESOURCE_REG, 1);
+		if (res)
+			phy_regmap = ocelot_init_regmap_from_resource(dev, res);
+	}
+
+	if (IS_ERR(phy_regmap)) {
+		dev_err(dev, "Unable to create phy register regmap\n");
+		return PTR_ERR(phy_regmap);
 	}
 
 	ret = mscc_miim_setup(dev, &bus, "mscc_miim", mii_regmap, 0);
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 04/16] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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 | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 08541007b18a..728883f95edf 100644
--- a/drivers/net/mdio/mdio-mscc-miim.c
+++ b/drivers/net/mdio/mdio-mscc-miim.c
@@ -18,6 +18,7 @@
 #include <linux/platform_device.h>
 #include <linux/property.h>
 #include <linux/regmap.h>
+#include <soc/mscc/ocelot.h>
 
 #define MSCC_MIIM_REG_STATUS		0x0
 #define		MSCC_MIIM_STATUS_STAT_PENDING	BIT(2)
@@ -281,11 +282,20 @@ static int mscc_miim_probe(struct platform_device *pdev)
 
 	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);
-	}
+		/* Fall back to using IORESOURCE_REG, which is possible in an
+		 * MFD configuration
+		 */
+		res = platform_get_resource(pdev, IORESOURCE_REG, 0);
+		if (!res) {
+			dev_err(dev, "Unable to get MIIM resource\n");
+			return -ENODEV;
+		}
 
-	mii_regmap = devm_regmap_init_mmio(dev, regs, &mscc_miim_regmap_config);
+		mii_regmap = ocelot_init_regmap_from_resource(dev, res);
+	} else {
+		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");
@@ -303,10 +313,15 @@ static int mscc_miim_probe(struct platform_device *pdev)
 
 		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);
-		}
+	} else {
+		res = platform_get_resource(pdev, IORESOURCE_REG, 1);
+		if (res)
+			phy_regmap = ocelot_init_regmap_from_resource(dev, res);
+	}
+
+	if (IS_ERR(phy_regmap)) {
+		dev_err(dev, "Unable to create phy register regmap\n");
+		return PTR_ERR(phy_regmap);
 	}
 
 	ret = mscc_miim_setup(dev, &bus, "mscc_miim", mii_regmap, 0);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 05/16] pinctrl: ocelot: add ability to be used in a non-mmio configuration
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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 | 31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 30577fedb7fc..4995c90019c5 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include <linux/slab.h>
+#include <soc/mscc/ocelot.h>
 
 #include "core.h"
 #include "pinconf.h"
@@ -1215,6 +1216,9 @@ static int lan966x_pinmux_set_mux(struct pinctrl_dev *pctldev,
 	return 0;
 }
 
+#if defined(REG)
+#undef REG
+#endif
 #define REG(r, info, p) ((r) * (info)->stride + (4 * ((p) / 32)))
 
 static int ocelot_gpio_set_direction(struct pinctrl_dev *pctldev,
@@ -1908,6 +1912,7 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct ocelot_pinctrl *info;
 	struct regmap *pincfg;
+	struct resource *res;
 	void __iomem *base;
 	int ret;
 	struct regmap_config regmap_config = {
@@ -1922,16 +1927,28 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
 
 	info->desc = (struct pinctrl_desc *)device_get_match_data(dev);
 
-	base = devm_ioremap_resource(dev,
-			platform_get_resource(pdev, IORESOURCE_MEM, 0));
-	if (IS_ERR(base))
-		return PTR_ERR(base);
+	base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+	if (IS_ERR(base)) {
+		/*
+		 * Fall back to using IORESOURCE_REG, which is possible in an
+		 * MFD configuration
+		 */
+		res = platform_get_resource(pdev, IORESOURCE_REG, 0);
+		if (!res) {
+			dev_err(dev, "Failed to get resource\n");
+			return -ENODEV;
+		}
 
-	info->stride = 1 + (info->desc->npins - 1) / 32;
+		info->map = ocelot_init_regmap_from_resource(dev, res);
+	} else {
+		regmap_config.max_register =
+			OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
 
-	regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
+		info->map = devm_regmap_init_mmio(dev, base, &regmap_config);
+	}
+
+	info->stride = 1 + (info->desc->npins - 1) / 32;
 
-	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);
-- 
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] 114+ messages in thread

* [RFC v8 net-next 05/16] pinctrl: ocelot: add ability to be used in a non-mmio configuration
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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 | 31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 30577fedb7fc..4995c90019c5 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
 #include <linux/slab.h>
+#include <soc/mscc/ocelot.h>
 
 #include "core.h"
 #include "pinconf.h"
@@ -1215,6 +1216,9 @@ static int lan966x_pinmux_set_mux(struct pinctrl_dev *pctldev,
 	return 0;
 }
 
+#if defined(REG)
+#undef REG
+#endif
 #define REG(r, info, p) ((r) * (info)->stride + (4 * ((p) / 32)))
 
 static int ocelot_gpio_set_direction(struct pinctrl_dev *pctldev,
@@ -1908,6 +1912,7 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct ocelot_pinctrl *info;
 	struct regmap *pincfg;
+	struct resource *res;
 	void __iomem *base;
 	int ret;
 	struct regmap_config regmap_config = {
@@ -1922,16 +1927,28 @@ static int ocelot_pinctrl_probe(struct platform_device *pdev)
 
 	info->desc = (struct pinctrl_desc *)device_get_match_data(dev);
 
-	base = devm_ioremap_resource(dev,
-			platform_get_resource(pdev, IORESOURCE_MEM, 0));
-	if (IS_ERR(base))
-		return PTR_ERR(base);
+	base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+	if (IS_ERR(base)) {
+		/*
+		 * Fall back to using IORESOURCE_REG, which is possible in an
+		 * MFD configuration
+		 */
+		res = platform_get_resource(pdev, IORESOURCE_REG, 0);
+		if (!res) {
+			dev_err(dev, "Failed to get resource\n");
+			return -ENODEV;
+		}
 
-	info->stride = 1 + (info->desc->npins - 1) / 32;
+		info->map = ocelot_init_regmap_from_resource(dev, res);
+	} else {
+		regmap_config.max_register =
+			OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
 
-	regmap_config.max_register = OCELOT_GPIO_SD_MAP * info->stride + 15 * 4;
+		info->map = devm_regmap_init_mmio(dev, base, &regmap_config);
+	}
+
+	info->stride = 1 + (info->desc->npins - 1) / 32;
 
-	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);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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 | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index 8953175c7e3e..88ab961cc5b9 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -20,6 +20,7 @@
 #include <linux/regmap.h>
 #include <linux/reset.h>
 #include <linux/spinlock.h>
+#include <soc/mscc/ocelot.h>
 
 #include "core.h"
 #include "pinconf.h"
@@ -899,6 +900,7 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
 	struct fwnode_handle *fwnode;
 	struct reset_control *reset;
 	struct sgpio_priv *priv;
+	struct resource *res;
 	struct clk *clk;
 	u32 __iomem *regs;
 	u32 val;
@@ -933,11 +935,23 @@ 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);
+	regs = devm_platform_get_and_ioremap_resource(pdev, 0, 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, 0);
+		if (!res) {
+			dev_err(dev, "Failed to get resource\n");
+			return -ENODEV;
+		}
+
+		priv->regs = ocelot_init_regmap_from_resource(dev, res);
+	} else {
+		priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
+	}
 
-	priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
 	if (IS_ERR(priv->regs))
 		return PTR_ERR(priv->regs);
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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 | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-microchip-sgpio.c b/drivers/pinctrl/pinctrl-microchip-sgpio.c
index 8953175c7e3e..88ab961cc5b9 100644
--- a/drivers/pinctrl/pinctrl-microchip-sgpio.c
+++ b/drivers/pinctrl/pinctrl-microchip-sgpio.c
@@ -20,6 +20,7 @@
 #include <linux/regmap.h>
 #include <linux/reset.h>
 #include <linux/spinlock.h>
+#include <soc/mscc/ocelot.h>
 
 #include "core.h"
 #include "pinconf.h"
@@ -899,6 +900,7 @@ static int microchip_sgpio_probe(struct platform_device *pdev)
 	struct fwnode_handle *fwnode;
 	struct reset_control *reset;
 	struct sgpio_priv *priv;
+	struct resource *res;
 	struct clk *clk;
 	u32 __iomem *regs;
 	u32 val;
@@ -933,11 +935,23 @@ 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);
+	regs = devm_platform_get_and_ioremap_resource(pdev, 0, 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, 0);
+		if (!res) {
+			dev_err(dev, "Failed to get resource\n");
+			return -ENODEV;
+		}
+
+		priv->regs = ocelot_init_regmap_from_resource(dev, res);
+	} else {
+		priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
+	}
 
-	priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
 	if (IS_ERR(priv->regs))
 		return PTR_ERR(priv->regs);
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 07/16] resource: add define macro for register address resources
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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..f3b0e238c020 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_MEM_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] 114+ messages in thread

* [RFC v8 net-next 07/16] resource: add define macro for register address resources
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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..f3b0e238c020 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_MEM_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] 114+ messages in thread

* [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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>
---
 drivers/mfd/Kconfig       |  18 +++
 drivers/mfd/Makefile      |   2 +
 drivers/mfd/ocelot-core.c | 135 +++++++++++++++++
 drivers/mfd/ocelot-spi.c  | 311 ++++++++++++++++++++++++++++++++++++++
 drivers/mfd/ocelot.h      |  34 +++++
 include/soc/mscc/ocelot.h |   5 +
 6 files changed, 505 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/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3b59456f5545..ff177173ca11 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -962,6 +962,24 @@ config MFD_MENF21BMC
 	  This driver can also be built as a module. If so the module
 	  will be called menf21bmc.
 
+config MFD_OCELOT
+	tristate "Microsemi Ocelot External Control Support"
+	depends on SPI_MASTER
+	select MFD_CORE
+	select REGMAP_SPI
+	help
+	  Ocelot is a family of networking chips that support multiple ethernet
+	  and fibre interfaces. In addition to networking, they contain several
+	  other functions, including 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..117028f7d845
--- /dev/null
+++ b/drivers/mfd/ocelot-core.c
@@ -0,0 +1,135 @@
+// 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/module.h>
+#include <linux/regmap.h>
+#include <soc/mscc/ocelot.h>
+
+#include <asm/byteorder.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_RES_START	0x710700f8
+#define VSC7512_SIO_RES_SIZE	0x100
+
+int ocelot_chip_reset(struct device *dev)
+{
+	struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+	int ret;
+
+	/*
+	 * 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
+	 */
+	ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
+	if (ret)
+		return ret;
+
+	msleep(100);
+
+	return ret;
+}
+EXPORT_SYMBOL(ocelot_chip_reset);
+
+struct regmap *ocelot_init_regmap_from_resource(struct device *child,
+						const struct resource *res)
+{
+	struct device *dev = child->parent;
+
+	return ocelot_spi_devm_init_regmap(dev, child, res);
+}
+EXPORT_SYMBOL(ocelot_init_regmap_from_resource);
+
+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_RES_START, VSC7512_SIO_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",
+		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
+		.resources = vsc7512_miim0_resources,
+	}, {
+		.name = "ocelot-miim1",
+		.of_compatible = "mscc,ocelot-miim",
+		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
+		.resources = vsc7512_miim1_resources,
+	},
+};
+
+int ocelot_core_init(struct device *dev)
+{
+	int ret;
+
+	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
+				   ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
+	if (ret) {
+		dev_err(dev, "Failed to add sub-devices: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(ocelot_core_init);
+
+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..95754deb0b57
--- /dev/null
+++ b/drivers/mfd/ocelot-spi.c
@@ -0,0 +1,311 @@
+// 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 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/of.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_CPUORG_RES_START	0x71000000
+#define VSC7512_CPUORG_RES_SIZE		0x2ff
+
+#define VSC7512_GCB_RES_START	0x71070000
+#define VSC7512_GCB_RES_SIZE	0x14
+
+static const struct resource vsc7512_dev_cpuorg_resource =
+	DEFINE_RES_REG_NAMED(VSC7512_CPUORG_RES_START, VSC7512_CPUORG_RES_SIZE,
+			     "devcpu_org");
+
+static const struct resource vsc7512_gcb_resource =
+	DEFINE_RES_REG_NAMED(VSC7512_GCB_RES_START, VSC7512_GCB_RES_SIZE,
+			     "devcpu_gcb_chip_regs");
+
+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;
+}
+EXPORT_SYMBOL(ocelot_spi_initialize);
+
+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,
+
+	.max_register = 0xffffffff,
+	.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)
+{
+	static const u8 dummy_buf[16] = {0};
+	struct spi_transfer tx, padding, rx;
+	struct ocelot_ddata *ddata = context;
+	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 > 0) {
+		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_devm_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(&regmap_config, &ocelot_spi_regmap_config,
+	       sizeof(ocelot_spi_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,
+				&regmap_config);
+}
+
+static int ocelot_spi_probe(struct spi_device *spi)
+{
+	struct device *dev = &spi->dev;
+	struct ocelot_ddata *ddata;
+	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) {
+		dev_err(&spi->dev, "Error %d initializing SPI\n", err);
+		return err;
+	}
+
+	ddata->cpuorg_regmap =
+		ocelot_spi_devm_init_regmap(dev, dev,
+					    &vsc7512_dev_cpuorg_resource);
+	if (IS_ERR(ddata->cpuorg_regmap))
+		return -ENOMEM;
+
+	ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
+							&vsc7512_gcb_resource);
+	if (IS_ERR(ddata->gcb_regmap))
+		return -ENOMEM;
+
+	/*
+	 * 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) {
+		dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
+		return err;
+	}
+
+	err = ocelot_chip_reset(dev);
+	if (err) {
+		dev_err(dev, "Failed to reset device: %d\n", err);
+		return err;
+	}
+
+	/*
+	 * 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) {
+		dev_err(dev,
+			"Failed to initialize Ocelot SPI bus after reset: %d\n",
+			err);
+		return err;
+	}
+
+	err = ocelot_core_init(dev);
+	if (err < 0) {
+		dev_err(dev, "Error %d initializing Ocelot core\n", err);
+		return err;
+	}
+
+	return 0;
+}
+
+const struct of_device_id ocelot_spi_of_match[] = {
+	{ .compatible = "mscc,vsc7512_mfd_spi" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
+
+static struct spi_driver ocelot_spi_driver = {
+	.driver = {
+		.name = "ocelot_mfd_spi",
+		.of_match_table = of_match_ptr(ocelot_spi_of_match),
+	},
+	.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..b68e6343caca
--- /dev/null
+++ b/drivers/mfd/ocelot.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/*
+ * Copyright 2021 Innovative Advantage Inc.
+ */
+
+#include <linux/regmap.h>
+
+#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_devm_init_regmap(struct device *dev,
+					   struct device *child,
+					   const struct resource *res);
+int ocelot_spi_initialize(struct device *dev);
+
+#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/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 1897119ebb9a..f9124a66e386 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -1039,11 +1039,16 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
 }
 #endif
 
+#if IS_ENABLED(CONFIG_MFD_OCELOT)
+struct regmap *ocelot_init_regmap_from_resource(struct device *child,
+						const struct resource *res);
+#else
 static inline struct regmap *
 ocelot_init_regmap_from_resource(struct device *child,
 				 const struct resource *res)
 {
 	return ERR_PTR(-EOPNOTSUPP);
 }
+#endif
 
 #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] 114+ messages in thread

* [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

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>
---
 drivers/mfd/Kconfig       |  18 +++
 drivers/mfd/Makefile      |   2 +
 drivers/mfd/ocelot-core.c | 135 +++++++++++++++++
 drivers/mfd/ocelot-spi.c  | 311 ++++++++++++++++++++++++++++++++++++++
 drivers/mfd/ocelot.h      |  34 +++++
 include/soc/mscc/ocelot.h |   5 +
 6 files changed, 505 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/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3b59456f5545..ff177173ca11 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -962,6 +962,24 @@ config MFD_MENF21BMC
 	  This driver can also be built as a module. If so the module
 	  will be called menf21bmc.
 
+config MFD_OCELOT
+	tristate "Microsemi Ocelot External Control Support"
+	depends on SPI_MASTER
+	select MFD_CORE
+	select REGMAP_SPI
+	help
+	  Ocelot is a family of networking chips that support multiple ethernet
+	  and fibre interfaces. In addition to networking, they contain several
+	  other functions, including 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..117028f7d845
--- /dev/null
+++ b/drivers/mfd/ocelot-core.c
@@ -0,0 +1,135 @@
+// 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/module.h>
+#include <linux/regmap.h>
+#include <soc/mscc/ocelot.h>
+
+#include <asm/byteorder.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_RES_START	0x710700f8
+#define VSC7512_SIO_RES_SIZE	0x100
+
+int ocelot_chip_reset(struct device *dev)
+{
+	struct ocelot_ddata *ddata = dev_get_drvdata(dev);
+	int ret;
+
+	/*
+	 * 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
+	 */
+	ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
+	if (ret)
+		return ret;
+
+	msleep(100);
+
+	return ret;
+}
+EXPORT_SYMBOL(ocelot_chip_reset);
+
+struct regmap *ocelot_init_regmap_from_resource(struct device *child,
+						const struct resource *res)
+{
+	struct device *dev = child->parent;
+
+	return ocelot_spi_devm_init_regmap(dev, child, res);
+}
+EXPORT_SYMBOL(ocelot_init_regmap_from_resource);
+
+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_RES_START, VSC7512_SIO_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",
+		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
+		.resources = vsc7512_miim0_resources,
+	}, {
+		.name = "ocelot-miim1",
+		.of_compatible = "mscc,ocelot-miim",
+		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
+		.resources = vsc7512_miim1_resources,
+	},
+};
+
+int ocelot_core_init(struct device *dev)
+{
+	int ret;
+
+	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
+				   ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
+	if (ret) {
+		dev_err(dev, "Failed to add sub-devices: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(ocelot_core_init);
+
+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..95754deb0b57
--- /dev/null
+++ b/drivers/mfd/ocelot-spi.c
@@ -0,0 +1,311 @@
+// 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 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/of.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_CPUORG_RES_START	0x71000000
+#define VSC7512_CPUORG_RES_SIZE		0x2ff
+
+#define VSC7512_GCB_RES_START	0x71070000
+#define VSC7512_GCB_RES_SIZE	0x14
+
+static const struct resource vsc7512_dev_cpuorg_resource =
+	DEFINE_RES_REG_NAMED(VSC7512_CPUORG_RES_START, VSC7512_CPUORG_RES_SIZE,
+			     "devcpu_org");
+
+static const struct resource vsc7512_gcb_resource =
+	DEFINE_RES_REG_NAMED(VSC7512_GCB_RES_START, VSC7512_GCB_RES_SIZE,
+			     "devcpu_gcb_chip_regs");
+
+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;
+}
+EXPORT_SYMBOL(ocelot_spi_initialize);
+
+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,
+
+	.max_register = 0xffffffff,
+	.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)
+{
+	static const u8 dummy_buf[16] = {0};
+	struct spi_transfer tx, padding, rx;
+	struct ocelot_ddata *ddata = context;
+	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 > 0) {
+		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_devm_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(&regmap_config, &ocelot_spi_regmap_config,
+	       sizeof(ocelot_spi_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,
+				&regmap_config);
+}
+
+static int ocelot_spi_probe(struct spi_device *spi)
+{
+	struct device *dev = &spi->dev;
+	struct ocelot_ddata *ddata;
+	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) {
+		dev_err(&spi->dev, "Error %d initializing SPI\n", err);
+		return err;
+	}
+
+	ddata->cpuorg_regmap =
+		ocelot_spi_devm_init_regmap(dev, dev,
+					    &vsc7512_dev_cpuorg_resource);
+	if (IS_ERR(ddata->cpuorg_regmap))
+		return -ENOMEM;
+
+	ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
+							&vsc7512_gcb_resource);
+	if (IS_ERR(ddata->gcb_regmap))
+		return -ENOMEM;
+
+	/*
+	 * 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) {
+		dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
+		return err;
+	}
+
+	err = ocelot_chip_reset(dev);
+	if (err) {
+		dev_err(dev, "Failed to reset device: %d\n", err);
+		return err;
+	}
+
+	/*
+	 * 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) {
+		dev_err(dev,
+			"Failed to initialize Ocelot SPI bus after reset: %d\n",
+			err);
+		return err;
+	}
+
+	err = ocelot_core_init(dev);
+	if (err < 0) {
+		dev_err(dev, "Error %d initializing Ocelot core\n", err);
+		return err;
+	}
+
+	return 0;
+}
+
+const struct of_device_id ocelot_spi_of_match[] = {
+	{ .compatible = "mscc,vsc7512_mfd_spi" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
+
+static struct spi_driver ocelot_spi_driver = {
+	.driver = {
+		.name = "ocelot_mfd_spi",
+		.of_match_table = of_match_ptr(ocelot_spi_of_match),
+	},
+	.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..b68e6343caca
--- /dev/null
+++ b/drivers/mfd/ocelot.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/*
+ * Copyright 2021 Innovative Advantage Inc.
+ */
+
+#include <linux/regmap.h>
+
+#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_devm_init_regmap(struct device *dev,
+					   struct device *child,
+					   const struct resource *res);
+int ocelot_spi_initialize(struct device *dev);
+
+#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/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 1897119ebb9a..f9124a66e386 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -1039,11 +1039,16 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
 }
 #endif
 
+#if IS_ENABLED(CONFIG_MFD_OCELOT)
+struct regmap *ocelot_init_regmap_from_resource(struct device *child,
+						const struct resource *res);
+#else
 static inline struct regmap *
 ocelot_init_regmap_from_resource(struct device *child,
 				 const struct resource *res)
 {
 	return ERR_PTR(-EOPNOTSUPP);
 }
+#endif
 
 #endif
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 09/16] net: mscc: ocelot: expose ocelot wm functions
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Expose ocelot_wm functions so they can be shared with other drivers.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/ethernet/mscc/ocelot_devlink.c | 31 ++++++++++++++++++++++
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 28 -------------------
 include/soc/mscc/ocelot.h                  |  5 ++++
 3 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_devlink.c b/drivers/net/ethernet/mscc/ocelot_devlink.c
index b8737efd2a85..d9ea75a14f2f 100644
--- a/drivers/net/ethernet/mscc/ocelot_devlink.c
+++ b/drivers/net/ethernet/mscc/ocelot_devlink.c
@@ -487,6 +487,37 @@ static void ocelot_watermark_init(struct ocelot *ocelot)
 	ocelot_setup_sharing_watermarks(ocelot);
 }
 
+/* Watermark encode
+ * Bit 8:   Unit; 0:1, 1:16
+ * Bit 7-0: Value to be multiplied with unit
+ */
+u16 ocelot_wm_enc(u16 value)
+{
+	WARN_ON(value >= 16 * BIT(8));
+
+	if (value >= BIT(8))
+		return BIT(8) | (value / 16);
+
+	return value;
+}
+EXPORT_SYMBOL(ocelot_wm_enc);
+
+u16 ocelot_wm_dec(u16 wm)
+{
+	if (wm & BIT(8))
+		return (wm & GENMASK(7, 0)) * 16;
+
+	return wm;
+}
+EXPORT_SYMBOL(ocelot_wm_dec);
+
+void ocelot_wm_stat(u32 val, u32 *inuse, u32 *maxuse)
+{
+	*inuse = (val & GENMASK(23, 12)) >> 12;
+	*maxuse = val & GENMASK(11, 0);
+}
+EXPORT_SYMBOL(ocelot_wm_stat);
+
 /* Pool size and type are fixed up at runtime. Keeping this structure to
  * look up the cell size multipliers.
  */
diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index 961f803aca19..68d205088665 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -307,34 +307,6 @@ static int ocelot_reset(struct ocelot *ocelot)
 	return 0;
 }
 
-/* Watermark encode
- * Bit 8:   Unit; 0:1, 1:16
- * Bit 7-0: Value to be multiplied with unit
- */
-static u16 ocelot_wm_enc(u16 value)
-{
-	WARN_ON(value >= 16 * BIT(8));
-
-	if (value >= BIT(8))
-		return BIT(8) | (value / 16);
-
-	return value;
-}
-
-static u16 ocelot_wm_dec(u16 wm)
-{
-	if (wm & BIT(8))
-		return (wm & GENMASK(7, 0)) * 16;
-
-	return wm;
-}
-
-static void ocelot_wm_stat(u32 val, u32 *inuse, u32 *maxuse)
-{
-	*inuse = (val & GENMASK(23, 12)) >> 12;
-	*maxuse = val & GENMASK(11, 0);
-}
-
 static const struct ocelot_ops ocelot_ops = {
 	.reset			= ocelot_reset,
 	.wm_enc			= ocelot_wm_enc,
diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index f9124a66e386..61888453f913 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -865,6 +865,11 @@ void ocelot_deinit_port(struct ocelot *ocelot, int port);
 void ocelot_port_set_dsa_8021q_cpu(struct ocelot *ocelot, int port);
 void ocelot_port_unset_dsa_8021q_cpu(struct ocelot *ocelot, int port);
 
+/* Watermark interface */
+u16 ocelot_wm_enc(u16 value);
+u16 ocelot_wm_dec(u16 wm);
+void ocelot_wm_stat(u32 val, u32 *inuse, u32 *maxuse);
+
 /* DSA callbacks */
 void ocelot_get_strings(struct ocelot *ocelot, int port, u32 sset, u8 *data);
 void ocelot_get_ethtool_stats(struct ocelot *ocelot, int port, u64 *data);
-- 
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] 114+ messages in thread

* [RFC v8 net-next 09/16] net: mscc: ocelot: expose ocelot wm functions
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Expose ocelot_wm functions so they can be shared with other drivers.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/ethernet/mscc/ocelot_devlink.c | 31 ++++++++++++++++++++++
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 28 -------------------
 include/soc/mscc/ocelot.h                  |  5 ++++
 3 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_devlink.c b/drivers/net/ethernet/mscc/ocelot_devlink.c
index b8737efd2a85..d9ea75a14f2f 100644
--- a/drivers/net/ethernet/mscc/ocelot_devlink.c
+++ b/drivers/net/ethernet/mscc/ocelot_devlink.c
@@ -487,6 +487,37 @@ static void ocelot_watermark_init(struct ocelot *ocelot)
 	ocelot_setup_sharing_watermarks(ocelot);
 }
 
+/* Watermark encode
+ * Bit 8:   Unit; 0:1, 1:16
+ * Bit 7-0: Value to be multiplied with unit
+ */
+u16 ocelot_wm_enc(u16 value)
+{
+	WARN_ON(value >= 16 * BIT(8));
+
+	if (value >= BIT(8))
+		return BIT(8) | (value / 16);
+
+	return value;
+}
+EXPORT_SYMBOL(ocelot_wm_enc);
+
+u16 ocelot_wm_dec(u16 wm)
+{
+	if (wm & BIT(8))
+		return (wm & GENMASK(7, 0)) * 16;
+
+	return wm;
+}
+EXPORT_SYMBOL(ocelot_wm_dec);
+
+void ocelot_wm_stat(u32 val, u32 *inuse, u32 *maxuse)
+{
+	*inuse = (val & GENMASK(23, 12)) >> 12;
+	*maxuse = val & GENMASK(11, 0);
+}
+EXPORT_SYMBOL(ocelot_wm_stat);
+
 /* Pool size and type are fixed up at runtime. Keeping this structure to
  * look up the cell size multipliers.
  */
diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index 961f803aca19..68d205088665 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -307,34 +307,6 @@ static int ocelot_reset(struct ocelot *ocelot)
 	return 0;
 }
 
-/* Watermark encode
- * Bit 8:   Unit; 0:1, 1:16
- * Bit 7-0: Value to be multiplied with unit
- */
-static u16 ocelot_wm_enc(u16 value)
-{
-	WARN_ON(value >= 16 * BIT(8));
-
-	if (value >= BIT(8))
-		return BIT(8) | (value / 16);
-
-	return value;
-}
-
-static u16 ocelot_wm_dec(u16 wm)
-{
-	if (wm & BIT(8))
-		return (wm & GENMASK(7, 0)) * 16;
-
-	return wm;
-}
-
-static void ocelot_wm_stat(u32 val, u32 *inuse, u32 *maxuse)
-{
-	*inuse = (val & GENMASK(23, 12)) >> 12;
-	*maxuse = val & GENMASK(11, 0);
-}
-
 static const struct ocelot_ops ocelot_ops = {
 	.reset			= ocelot_reset,
 	.wm_enc			= ocelot_wm_enc,
diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index f9124a66e386..61888453f913 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -865,6 +865,11 @@ void ocelot_deinit_port(struct ocelot *ocelot, int port);
 void ocelot_port_set_dsa_8021q_cpu(struct ocelot *ocelot, int port);
 void ocelot_port_unset_dsa_8021q_cpu(struct ocelot *ocelot, int port);
 
+/* Watermark interface */
+u16 ocelot_wm_enc(u16 value);
+u16 ocelot_wm_dec(u16 wm);
+void ocelot_wm_stat(u32 val, u32 *inuse, u32 *maxuse);
+
 /* DSA callbacks */
 void ocelot_get_strings(struct ocelot *ocelot, int port, u32 sset, u8 *data);
 void ocelot_get_ethtool_stats(struct ocelot *ocelot, int port, u64 *data);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 10/16] net: dsa: felix: add configurable device quirks
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The define FELIX_MAC_QUIRKS was used directly in the felix.c shared driver.
Other devices (VSC7512 for example) don't require the same quirks, so they
need to be configured on a per-device basis.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/dsa/ocelot/felix.c           | 7 +++++--
 drivers/net/dsa/ocelot/felix.h           | 1 +
 drivers/net/dsa/ocelot/felix_vsc9959.c   | 1 +
 drivers/net/dsa/ocelot/seville_vsc9953.c | 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 33cb124ca912..d09408baaab7 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -1023,9 +1023,12 @@ static void felix_phylink_mac_link_down(struct dsa_switch *ds, int port,
 					phy_interface_t interface)
 {
 	struct ocelot *ocelot = ds->priv;
+	struct felix *felix;
+
+	felix = ocelot_to_felix(ocelot);
 
 	ocelot_phylink_mac_link_down(ocelot, port, link_an_mode, interface,
-				     FELIX_MAC_QUIRKS);
+				     felix->info->quirks);
 }
 
 static void felix_phylink_mac_link_up(struct dsa_switch *ds, int port,
@@ -1040,7 +1043,7 @@ static void felix_phylink_mac_link_up(struct dsa_switch *ds, int port,
 
 	ocelot_phylink_mac_link_up(ocelot, port, phydev, link_an_mode,
 				   interface, speed, duplex, tx_pause, rx_pause,
-				   FELIX_MAC_QUIRKS);
+				   felix->info->quirks);
 
 	if (felix->info->port_sched_speed_set)
 		felix->info->port_sched_speed_set(ocelot, port, speed);
diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
index 39faf1027965..3ecac79bbf09 100644
--- a/drivers/net/dsa/ocelot/felix.h
+++ b/drivers/net/dsa/ocelot/felix.h
@@ -32,6 +32,7 @@ struct felix_info {
 	u16				vcap_pol_base2;
 	u16				vcap_pol_max2;
 	const struct ptp_clock_info	*ptp_caps;
+	unsigned long			quirks;
 
 	/* Some Ocelot switches are integrated into the SoC without the
 	 * extraction IRQ line connected to the ARM GIC. By enabling this
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c b/drivers/net/dsa/ocelot/felix_vsc9959.c
index 081871824eaf..95e165a12382 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -2225,6 +2225,7 @@ static const struct felix_info felix_info_vsc9959 = {
 	.num_mact_rows		= 2048,
 	.num_ports		= VSC9959_NUM_PORTS,
 	.num_tx_queues		= OCELOT_NUM_TC,
+	.quirks			= FELIX_MAC_QUIRKS,
 	.quirk_no_xtr_irq	= true,
 	.ptp_caps		= &vsc9959_ptp_caps,
 	.mdio_bus_alloc		= vsc9959_mdio_bus_alloc,
diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c b/drivers/net/dsa/ocelot/seville_vsc9953.c
index 48fd43a93364..e1400fadf064 100644
--- a/drivers/net/dsa/ocelot/seville_vsc9953.c
+++ b/drivers/net/dsa/ocelot/seville_vsc9953.c
@@ -1092,6 +1092,7 @@ static const struct felix_info seville_info_vsc9953 = {
 	.vcap_pol_max		= VSC9953_VCAP_POLICER_MAX,
 	.vcap_pol_base2		= VSC9953_VCAP_POLICER_BASE2,
 	.vcap_pol_max2		= VSC9953_VCAP_POLICER_MAX2,
+	.quirks			= FELIX_MAC_QUIRKS,
 	.num_mact_rows		= 2048,
 	.num_ports		= VSC9953_NUM_PORTS,
 	.num_tx_queues		= OCELOT_NUM_TC,
-- 
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] 114+ messages in thread

* [RFC v8 net-next 10/16] net: dsa: felix: add configurable device quirks
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The define FELIX_MAC_QUIRKS was used directly in the felix.c shared driver.
Other devices (VSC7512 for example) don't require the same quirks, so they
need to be configured on a per-device basis.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/dsa/ocelot/felix.c           | 7 +++++--
 drivers/net/dsa/ocelot/felix.h           | 1 +
 drivers/net/dsa/ocelot/felix_vsc9959.c   | 1 +
 drivers/net/dsa/ocelot/seville_vsc9953.c | 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 33cb124ca912..d09408baaab7 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -1023,9 +1023,12 @@ static void felix_phylink_mac_link_down(struct dsa_switch *ds, int port,
 					phy_interface_t interface)
 {
 	struct ocelot *ocelot = ds->priv;
+	struct felix *felix;
+
+	felix = ocelot_to_felix(ocelot);
 
 	ocelot_phylink_mac_link_down(ocelot, port, link_an_mode, interface,
-				     FELIX_MAC_QUIRKS);
+				     felix->info->quirks);
 }
 
 static void felix_phylink_mac_link_up(struct dsa_switch *ds, int port,
@@ -1040,7 +1043,7 @@ static void felix_phylink_mac_link_up(struct dsa_switch *ds, int port,
 
 	ocelot_phylink_mac_link_up(ocelot, port, phydev, link_an_mode,
 				   interface, speed, duplex, tx_pause, rx_pause,
-				   FELIX_MAC_QUIRKS);
+				   felix->info->quirks);
 
 	if (felix->info->port_sched_speed_set)
 		felix->info->port_sched_speed_set(ocelot, port, speed);
diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
index 39faf1027965..3ecac79bbf09 100644
--- a/drivers/net/dsa/ocelot/felix.h
+++ b/drivers/net/dsa/ocelot/felix.h
@@ -32,6 +32,7 @@ struct felix_info {
 	u16				vcap_pol_base2;
 	u16				vcap_pol_max2;
 	const struct ptp_clock_info	*ptp_caps;
+	unsigned long			quirks;
 
 	/* Some Ocelot switches are integrated into the SoC without the
 	 * extraction IRQ line connected to the ARM GIC. By enabling this
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c b/drivers/net/dsa/ocelot/felix_vsc9959.c
index 081871824eaf..95e165a12382 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -2225,6 +2225,7 @@ static const struct felix_info felix_info_vsc9959 = {
 	.num_mact_rows		= 2048,
 	.num_ports		= VSC9959_NUM_PORTS,
 	.num_tx_queues		= OCELOT_NUM_TC,
+	.quirks			= FELIX_MAC_QUIRKS,
 	.quirk_no_xtr_irq	= true,
 	.ptp_caps		= &vsc9959_ptp_caps,
 	.mdio_bus_alloc		= vsc9959_mdio_bus_alloc,
diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c b/drivers/net/dsa/ocelot/seville_vsc9953.c
index 48fd43a93364..e1400fadf064 100644
--- a/drivers/net/dsa/ocelot/seville_vsc9953.c
+++ b/drivers/net/dsa/ocelot/seville_vsc9953.c
@@ -1092,6 +1092,7 @@ static const struct felix_info seville_info_vsc9953 = {
 	.vcap_pol_max		= VSC9953_VCAP_POLICER_MAX,
 	.vcap_pol_base2		= VSC9953_VCAP_POLICER_BASE2,
 	.vcap_pol_max2		= VSC9953_VCAP_POLICER_MAX2,
+	.quirks			= FELIX_MAC_QUIRKS,
 	.num_mact_rows		= 2048,
 	.num_ports		= VSC9953_NUM_PORTS,
 	.num_tx_queues		= OCELOT_NUM_TC,
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The ocelot_regfields struct is common between several different chips, some
of which can only be controlled externally. Export this structure so it
doesn't have to be duplicated in these other drivers.

Rename the structure as well, to follow the conventions of other shared
resources.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 60 +---------------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 59 +++++++++++++++++++++
 include/soc/mscc/vsc7514_regs.h            |  2 +
 3 files changed, 62 insertions(+), 59 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index 68d205088665..a13fec7247d6 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -38,64 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
 	[DEV_GMII] = vsc7514_dev_gmii_regmap,
 };
 
-static const struct reg_field ocelot_regfields[REGFIELD_MAX] = {
-	[ANA_ADVLEARN_VLAN_CHK] = REG_FIELD(ANA_ADVLEARN, 11, 11),
-	[ANA_ADVLEARN_LEARN_MIRROR] = REG_FIELD(ANA_ADVLEARN, 0, 10),
-	[ANA_ANEVENTS_MSTI_DROP] = REG_FIELD(ANA_ANEVENTS, 27, 27),
-	[ANA_ANEVENTS_ACLKILL] = REG_FIELD(ANA_ANEVENTS, 26, 26),
-	[ANA_ANEVENTS_ACLUSED] = REG_FIELD(ANA_ANEVENTS, 25, 25),
-	[ANA_ANEVENTS_AUTOAGE] = REG_FIELD(ANA_ANEVENTS, 24, 24),
-	[ANA_ANEVENTS_VS2TTL1] = REG_FIELD(ANA_ANEVENTS, 23, 23),
-	[ANA_ANEVENTS_STORM_DROP] = REG_FIELD(ANA_ANEVENTS, 22, 22),
-	[ANA_ANEVENTS_LEARN_DROP] = REG_FIELD(ANA_ANEVENTS, 21, 21),
-	[ANA_ANEVENTS_AGED_ENTRY] = REG_FIELD(ANA_ANEVENTS, 20, 20),
-	[ANA_ANEVENTS_CPU_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 19, 19),
-	[ANA_ANEVENTS_AUTO_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 18, 18),
-	[ANA_ANEVENTS_LEARN_REMOVE] = REG_FIELD(ANA_ANEVENTS, 17, 17),
-	[ANA_ANEVENTS_AUTO_LEARNED] = REG_FIELD(ANA_ANEVENTS, 16, 16),
-	[ANA_ANEVENTS_AUTO_MOVED] = REG_FIELD(ANA_ANEVENTS, 15, 15),
-	[ANA_ANEVENTS_DROPPED] = REG_FIELD(ANA_ANEVENTS, 14, 14),
-	[ANA_ANEVENTS_CLASSIFIED_DROP] = REG_FIELD(ANA_ANEVENTS, 13, 13),
-	[ANA_ANEVENTS_CLASSIFIED_COPY] = REG_FIELD(ANA_ANEVENTS, 12, 12),
-	[ANA_ANEVENTS_VLAN_DISCARD] = REG_FIELD(ANA_ANEVENTS, 11, 11),
-	[ANA_ANEVENTS_FWD_DISCARD] = REG_FIELD(ANA_ANEVENTS, 10, 10),
-	[ANA_ANEVENTS_MULTICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 9, 9),
-	[ANA_ANEVENTS_UNICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 8, 8),
-	[ANA_ANEVENTS_DEST_KNOWN] = REG_FIELD(ANA_ANEVENTS, 7, 7),
-	[ANA_ANEVENTS_BUCKET3_MATCH] = REG_FIELD(ANA_ANEVENTS, 6, 6),
-	[ANA_ANEVENTS_BUCKET2_MATCH] = REG_FIELD(ANA_ANEVENTS, 5, 5),
-	[ANA_ANEVENTS_BUCKET1_MATCH] = REG_FIELD(ANA_ANEVENTS, 4, 4),
-	[ANA_ANEVENTS_BUCKET0_MATCH] = REG_FIELD(ANA_ANEVENTS, 3, 3),
-	[ANA_ANEVENTS_CPU_OPERATION] = REG_FIELD(ANA_ANEVENTS, 2, 2),
-	[ANA_ANEVENTS_DMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 1, 1),
-	[ANA_ANEVENTS_SMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 0, 0),
-	[ANA_TABLES_MACACCESS_B_DOM] = REG_FIELD(ANA_TABLES_MACACCESS, 18, 18),
-	[ANA_TABLES_MACTINDX_BUCKET] = REG_FIELD(ANA_TABLES_MACTINDX, 10, 11),
-	[ANA_TABLES_MACTINDX_M_INDEX] = REG_FIELD(ANA_TABLES_MACTINDX, 0, 9),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_VLD] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 20, 20),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_FP] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 8, 19),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_PORTNO] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 4, 7),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_SEL] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 1, 3),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_T] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 0, 0),
-	[SYS_RESET_CFG_CORE_ENA] = REG_FIELD(SYS_RESET_CFG, 2, 2),
-	[SYS_RESET_CFG_MEM_ENA] = REG_FIELD(SYS_RESET_CFG, 1, 1),
-	[SYS_RESET_CFG_MEM_INIT] = REG_FIELD(SYS_RESET_CFG, 0, 0),
-	/* Replicated per number of ports (12), register size 4 per port */
-	[QSYS_SWITCH_PORT_MODE_PORT_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 14, 14, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 11, 13, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_YEL_RSRVD] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 10, 10, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 9, 9, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_TX_PFC_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 1, 8, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_TX_PFC_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 0, 0, 12, 4),
-	[SYS_PORT_MODE_DATA_WO_TS] = REG_FIELD_ID(SYS_PORT_MODE, 5, 6, 12, 4),
-	[SYS_PORT_MODE_INCL_INJ_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 3, 4, 12, 4),
-	[SYS_PORT_MODE_INCL_XTR_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 1, 2, 12, 4),
-	[SYS_PORT_MODE_INCL_HDR_ERR] = REG_FIELD_ID(SYS_PORT_MODE, 0, 0, 12, 4),
-	[SYS_PAUSE_CFG_PAUSE_START] = REG_FIELD_ID(SYS_PAUSE_CFG, 10, 18, 12, 4),
-	[SYS_PAUSE_CFG_PAUSE_STOP] = REG_FIELD_ID(SYS_PAUSE_CFG, 1, 9, 12, 4),
-	[SYS_PAUSE_CFG_PAUSE_ENA] = REG_FIELD_ID(SYS_PAUSE_CFG, 0, 1, 12, 4),
-};
-
 static const struct ocelot_stat_layout ocelot_stats_layout[] = {
 	{ .name = "rx_octets", .offset = 0x00, },
 	{ .name = "rx_unicast", .offset = 0x01, },
@@ -231,7 +173,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
 	ocelot->num_mact_rows = 1024;
 	ocelot->ops = ops;
 
-	ret = ocelot_regfields_init(ocelot, ocelot_regfields);
+	ret = ocelot_regfields_init(ocelot, vsc7514_regfields);
 	if (ret)
 		return ret;
 
diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
index c2af4eb8ca5d..847e64d11075 100644
--- a/drivers/net/ethernet/mscc/vsc7514_regs.c
+++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
@@ -9,6 +9,65 @@
 #include <soc/mscc/vsc7514_regs.h>
 #include "ocelot.h"
 
+const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
+	[ANA_ADVLEARN_VLAN_CHK] = REG_FIELD(ANA_ADVLEARN, 11, 11),
+	[ANA_ADVLEARN_LEARN_MIRROR] = REG_FIELD(ANA_ADVLEARN, 0, 10),
+	[ANA_ANEVENTS_MSTI_DROP] = REG_FIELD(ANA_ANEVENTS, 27, 27),
+	[ANA_ANEVENTS_ACLKILL] = REG_FIELD(ANA_ANEVENTS, 26, 26),
+	[ANA_ANEVENTS_ACLUSED] = REG_FIELD(ANA_ANEVENTS, 25, 25),
+	[ANA_ANEVENTS_AUTOAGE] = REG_FIELD(ANA_ANEVENTS, 24, 24),
+	[ANA_ANEVENTS_VS2TTL1] = REG_FIELD(ANA_ANEVENTS, 23, 23),
+	[ANA_ANEVENTS_STORM_DROP] = REG_FIELD(ANA_ANEVENTS, 22, 22),
+	[ANA_ANEVENTS_LEARN_DROP] = REG_FIELD(ANA_ANEVENTS, 21, 21),
+	[ANA_ANEVENTS_AGED_ENTRY] = REG_FIELD(ANA_ANEVENTS, 20, 20),
+	[ANA_ANEVENTS_CPU_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 19, 19),
+	[ANA_ANEVENTS_AUTO_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 18, 18),
+	[ANA_ANEVENTS_LEARN_REMOVE] = REG_FIELD(ANA_ANEVENTS, 17, 17),
+	[ANA_ANEVENTS_AUTO_LEARNED] = REG_FIELD(ANA_ANEVENTS, 16, 16),
+	[ANA_ANEVENTS_AUTO_MOVED] = REG_FIELD(ANA_ANEVENTS, 15, 15),
+	[ANA_ANEVENTS_DROPPED] = REG_FIELD(ANA_ANEVENTS, 14, 14),
+	[ANA_ANEVENTS_CLASSIFIED_DROP] = REG_FIELD(ANA_ANEVENTS, 13, 13),
+	[ANA_ANEVENTS_CLASSIFIED_COPY] = REG_FIELD(ANA_ANEVENTS, 12, 12),
+	[ANA_ANEVENTS_VLAN_DISCARD] = REG_FIELD(ANA_ANEVENTS, 11, 11),
+	[ANA_ANEVENTS_FWD_DISCARD] = REG_FIELD(ANA_ANEVENTS, 10, 10),
+	[ANA_ANEVENTS_MULTICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 9, 9),
+	[ANA_ANEVENTS_UNICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 8, 8),
+	[ANA_ANEVENTS_DEST_KNOWN] = REG_FIELD(ANA_ANEVENTS, 7, 7),
+	[ANA_ANEVENTS_BUCKET3_MATCH] = REG_FIELD(ANA_ANEVENTS, 6, 6),
+	[ANA_ANEVENTS_BUCKET2_MATCH] = REG_FIELD(ANA_ANEVENTS, 5, 5),
+	[ANA_ANEVENTS_BUCKET1_MATCH] = REG_FIELD(ANA_ANEVENTS, 4, 4),
+	[ANA_ANEVENTS_BUCKET0_MATCH] = REG_FIELD(ANA_ANEVENTS, 3, 3),
+	[ANA_ANEVENTS_CPU_OPERATION] = REG_FIELD(ANA_ANEVENTS, 2, 2),
+	[ANA_ANEVENTS_DMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 1, 1),
+	[ANA_ANEVENTS_SMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 0, 0),
+	[ANA_TABLES_MACACCESS_B_DOM] = REG_FIELD(ANA_TABLES_MACACCESS, 18, 18),
+	[ANA_TABLES_MACTINDX_BUCKET] = REG_FIELD(ANA_TABLES_MACTINDX, 10, 11),
+	[ANA_TABLES_MACTINDX_M_INDEX] = REG_FIELD(ANA_TABLES_MACTINDX, 0, 9),
+	[GCB_SOFT_RST_SWC_RST] = REG_FIELD(GCB_SOFT_RST, 1, 1),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_VLD] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 20, 20),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_FP] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 8, 19),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_PORTNO] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 4, 7),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_SEL] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 1, 3),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_T] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 0, 0),
+	[SYS_RESET_CFG_CORE_ENA] = REG_FIELD(SYS_RESET_CFG, 2, 2),
+	[SYS_RESET_CFG_MEM_ENA] = REG_FIELD(SYS_RESET_CFG, 1, 1),
+	[SYS_RESET_CFG_MEM_INIT] = REG_FIELD(SYS_RESET_CFG, 0, 0),
+	/* Replicated per number of ports (12), register size 4 per port */
+	[QSYS_SWITCH_PORT_MODE_PORT_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 14, 14, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 11, 13, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_YEL_RSRVD] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 10, 10, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 9, 9, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_TX_PFC_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 1, 8, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_TX_PFC_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 0, 0, 12, 4),
+	[SYS_PORT_MODE_DATA_WO_TS] = REG_FIELD_ID(SYS_PORT_MODE, 5, 6, 12, 4),
+	[SYS_PORT_MODE_INCL_INJ_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 3, 4, 12, 4),
+	[SYS_PORT_MODE_INCL_XTR_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 1, 2, 12, 4),
+	[SYS_PORT_MODE_INCL_HDR_ERR] = REG_FIELD_ID(SYS_PORT_MODE, 0, 0, 12, 4),
+	[SYS_PAUSE_CFG_PAUSE_START] = REG_FIELD_ID(SYS_PAUSE_CFG, 10, 18, 12, 4),
+	[SYS_PAUSE_CFG_PAUSE_STOP] = REG_FIELD_ID(SYS_PAUSE_CFG, 1, 9, 12, 4),
+	[SYS_PAUSE_CFG_PAUSE_ENA] = REG_FIELD_ID(SYS_PAUSE_CFG, 0, 1, 12, 4),
+};
+
 const u32 vsc7514_ana_regmap[] = {
 	REG(ANA_ADVLEARN,				0x009000),
 	REG(ANA_VLANMASK,				0x009004),
diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
index ceee26c96959..9b40e7d00ec5 100644
--- a/include/soc/mscc/vsc7514_regs.h
+++ b/include/soc/mscc/vsc7514_regs.h
@@ -10,6 +10,8 @@
 
 #include <soc/mscc/ocelot_vcap.h>
 
+extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
+
 extern const u32 vsc7514_ana_regmap[];
 extern const u32 vsc7514_qs_regmap[];
 extern const u32 vsc7514_qsys_regmap[];
-- 
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] 114+ messages in thread

* [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The ocelot_regfields struct is common between several different chips, some
of which can only be controlled externally. Export this structure so it
doesn't have to be duplicated in these other drivers.

Rename the structure as well, to follow the conventions of other shared
resources.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 60 +---------------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 59 +++++++++++++++++++++
 include/soc/mscc/vsc7514_regs.h            |  2 +
 3 files changed, 62 insertions(+), 59 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index 68d205088665..a13fec7247d6 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -38,64 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
 	[DEV_GMII] = vsc7514_dev_gmii_regmap,
 };
 
-static const struct reg_field ocelot_regfields[REGFIELD_MAX] = {
-	[ANA_ADVLEARN_VLAN_CHK] = REG_FIELD(ANA_ADVLEARN, 11, 11),
-	[ANA_ADVLEARN_LEARN_MIRROR] = REG_FIELD(ANA_ADVLEARN, 0, 10),
-	[ANA_ANEVENTS_MSTI_DROP] = REG_FIELD(ANA_ANEVENTS, 27, 27),
-	[ANA_ANEVENTS_ACLKILL] = REG_FIELD(ANA_ANEVENTS, 26, 26),
-	[ANA_ANEVENTS_ACLUSED] = REG_FIELD(ANA_ANEVENTS, 25, 25),
-	[ANA_ANEVENTS_AUTOAGE] = REG_FIELD(ANA_ANEVENTS, 24, 24),
-	[ANA_ANEVENTS_VS2TTL1] = REG_FIELD(ANA_ANEVENTS, 23, 23),
-	[ANA_ANEVENTS_STORM_DROP] = REG_FIELD(ANA_ANEVENTS, 22, 22),
-	[ANA_ANEVENTS_LEARN_DROP] = REG_FIELD(ANA_ANEVENTS, 21, 21),
-	[ANA_ANEVENTS_AGED_ENTRY] = REG_FIELD(ANA_ANEVENTS, 20, 20),
-	[ANA_ANEVENTS_CPU_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 19, 19),
-	[ANA_ANEVENTS_AUTO_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 18, 18),
-	[ANA_ANEVENTS_LEARN_REMOVE] = REG_FIELD(ANA_ANEVENTS, 17, 17),
-	[ANA_ANEVENTS_AUTO_LEARNED] = REG_FIELD(ANA_ANEVENTS, 16, 16),
-	[ANA_ANEVENTS_AUTO_MOVED] = REG_FIELD(ANA_ANEVENTS, 15, 15),
-	[ANA_ANEVENTS_DROPPED] = REG_FIELD(ANA_ANEVENTS, 14, 14),
-	[ANA_ANEVENTS_CLASSIFIED_DROP] = REG_FIELD(ANA_ANEVENTS, 13, 13),
-	[ANA_ANEVENTS_CLASSIFIED_COPY] = REG_FIELD(ANA_ANEVENTS, 12, 12),
-	[ANA_ANEVENTS_VLAN_DISCARD] = REG_FIELD(ANA_ANEVENTS, 11, 11),
-	[ANA_ANEVENTS_FWD_DISCARD] = REG_FIELD(ANA_ANEVENTS, 10, 10),
-	[ANA_ANEVENTS_MULTICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 9, 9),
-	[ANA_ANEVENTS_UNICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 8, 8),
-	[ANA_ANEVENTS_DEST_KNOWN] = REG_FIELD(ANA_ANEVENTS, 7, 7),
-	[ANA_ANEVENTS_BUCKET3_MATCH] = REG_FIELD(ANA_ANEVENTS, 6, 6),
-	[ANA_ANEVENTS_BUCKET2_MATCH] = REG_FIELD(ANA_ANEVENTS, 5, 5),
-	[ANA_ANEVENTS_BUCKET1_MATCH] = REG_FIELD(ANA_ANEVENTS, 4, 4),
-	[ANA_ANEVENTS_BUCKET0_MATCH] = REG_FIELD(ANA_ANEVENTS, 3, 3),
-	[ANA_ANEVENTS_CPU_OPERATION] = REG_FIELD(ANA_ANEVENTS, 2, 2),
-	[ANA_ANEVENTS_DMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 1, 1),
-	[ANA_ANEVENTS_SMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 0, 0),
-	[ANA_TABLES_MACACCESS_B_DOM] = REG_FIELD(ANA_TABLES_MACACCESS, 18, 18),
-	[ANA_TABLES_MACTINDX_BUCKET] = REG_FIELD(ANA_TABLES_MACTINDX, 10, 11),
-	[ANA_TABLES_MACTINDX_M_INDEX] = REG_FIELD(ANA_TABLES_MACTINDX, 0, 9),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_VLD] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 20, 20),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_FP] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 8, 19),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_PORTNO] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 4, 7),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_SEL] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 1, 3),
-	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_T] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 0, 0),
-	[SYS_RESET_CFG_CORE_ENA] = REG_FIELD(SYS_RESET_CFG, 2, 2),
-	[SYS_RESET_CFG_MEM_ENA] = REG_FIELD(SYS_RESET_CFG, 1, 1),
-	[SYS_RESET_CFG_MEM_INIT] = REG_FIELD(SYS_RESET_CFG, 0, 0),
-	/* Replicated per number of ports (12), register size 4 per port */
-	[QSYS_SWITCH_PORT_MODE_PORT_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 14, 14, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 11, 13, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_YEL_RSRVD] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 10, 10, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 9, 9, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_TX_PFC_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 1, 8, 12, 4),
-	[QSYS_SWITCH_PORT_MODE_TX_PFC_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 0, 0, 12, 4),
-	[SYS_PORT_MODE_DATA_WO_TS] = REG_FIELD_ID(SYS_PORT_MODE, 5, 6, 12, 4),
-	[SYS_PORT_MODE_INCL_INJ_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 3, 4, 12, 4),
-	[SYS_PORT_MODE_INCL_XTR_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 1, 2, 12, 4),
-	[SYS_PORT_MODE_INCL_HDR_ERR] = REG_FIELD_ID(SYS_PORT_MODE, 0, 0, 12, 4),
-	[SYS_PAUSE_CFG_PAUSE_START] = REG_FIELD_ID(SYS_PAUSE_CFG, 10, 18, 12, 4),
-	[SYS_PAUSE_CFG_PAUSE_STOP] = REG_FIELD_ID(SYS_PAUSE_CFG, 1, 9, 12, 4),
-	[SYS_PAUSE_CFG_PAUSE_ENA] = REG_FIELD_ID(SYS_PAUSE_CFG, 0, 1, 12, 4),
-};
-
 static const struct ocelot_stat_layout ocelot_stats_layout[] = {
 	{ .name = "rx_octets", .offset = 0x00, },
 	{ .name = "rx_unicast", .offset = 0x01, },
@@ -231,7 +173,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
 	ocelot->num_mact_rows = 1024;
 	ocelot->ops = ops;
 
-	ret = ocelot_regfields_init(ocelot, ocelot_regfields);
+	ret = ocelot_regfields_init(ocelot, vsc7514_regfields);
 	if (ret)
 		return ret;
 
diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
index c2af4eb8ca5d..847e64d11075 100644
--- a/drivers/net/ethernet/mscc/vsc7514_regs.c
+++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
@@ -9,6 +9,65 @@
 #include <soc/mscc/vsc7514_regs.h>
 #include "ocelot.h"
 
+const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
+	[ANA_ADVLEARN_VLAN_CHK] = REG_FIELD(ANA_ADVLEARN, 11, 11),
+	[ANA_ADVLEARN_LEARN_MIRROR] = REG_FIELD(ANA_ADVLEARN, 0, 10),
+	[ANA_ANEVENTS_MSTI_DROP] = REG_FIELD(ANA_ANEVENTS, 27, 27),
+	[ANA_ANEVENTS_ACLKILL] = REG_FIELD(ANA_ANEVENTS, 26, 26),
+	[ANA_ANEVENTS_ACLUSED] = REG_FIELD(ANA_ANEVENTS, 25, 25),
+	[ANA_ANEVENTS_AUTOAGE] = REG_FIELD(ANA_ANEVENTS, 24, 24),
+	[ANA_ANEVENTS_VS2TTL1] = REG_FIELD(ANA_ANEVENTS, 23, 23),
+	[ANA_ANEVENTS_STORM_DROP] = REG_FIELD(ANA_ANEVENTS, 22, 22),
+	[ANA_ANEVENTS_LEARN_DROP] = REG_FIELD(ANA_ANEVENTS, 21, 21),
+	[ANA_ANEVENTS_AGED_ENTRY] = REG_FIELD(ANA_ANEVENTS, 20, 20),
+	[ANA_ANEVENTS_CPU_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 19, 19),
+	[ANA_ANEVENTS_AUTO_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 18, 18),
+	[ANA_ANEVENTS_LEARN_REMOVE] = REG_FIELD(ANA_ANEVENTS, 17, 17),
+	[ANA_ANEVENTS_AUTO_LEARNED] = REG_FIELD(ANA_ANEVENTS, 16, 16),
+	[ANA_ANEVENTS_AUTO_MOVED] = REG_FIELD(ANA_ANEVENTS, 15, 15),
+	[ANA_ANEVENTS_DROPPED] = REG_FIELD(ANA_ANEVENTS, 14, 14),
+	[ANA_ANEVENTS_CLASSIFIED_DROP] = REG_FIELD(ANA_ANEVENTS, 13, 13),
+	[ANA_ANEVENTS_CLASSIFIED_COPY] = REG_FIELD(ANA_ANEVENTS, 12, 12),
+	[ANA_ANEVENTS_VLAN_DISCARD] = REG_FIELD(ANA_ANEVENTS, 11, 11),
+	[ANA_ANEVENTS_FWD_DISCARD] = REG_FIELD(ANA_ANEVENTS, 10, 10),
+	[ANA_ANEVENTS_MULTICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 9, 9),
+	[ANA_ANEVENTS_UNICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 8, 8),
+	[ANA_ANEVENTS_DEST_KNOWN] = REG_FIELD(ANA_ANEVENTS, 7, 7),
+	[ANA_ANEVENTS_BUCKET3_MATCH] = REG_FIELD(ANA_ANEVENTS, 6, 6),
+	[ANA_ANEVENTS_BUCKET2_MATCH] = REG_FIELD(ANA_ANEVENTS, 5, 5),
+	[ANA_ANEVENTS_BUCKET1_MATCH] = REG_FIELD(ANA_ANEVENTS, 4, 4),
+	[ANA_ANEVENTS_BUCKET0_MATCH] = REG_FIELD(ANA_ANEVENTS, 3, 3),
+	[ANA_ANEVENTS_CPU_OPERATION] = REG_FIELD(ANA_ANEVENTS, 2, 2),
+	[ANA_ANEVENTS_DMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 1, 1),
+	[ANA_ANEVENTS_SMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 0, 0),
+	[ANA_TABLES_MACACCESS_B_DOM] = REG_FIELD(ANA_TABLES_MACACCESS, 18, 18),
+	[ANA_TABLES_MACTINDX_BUCKET] = REG_FIELD(ANA_TABLES_MACTINDX, 10, 11),
+	[ANA_TABLES_MACTINDX_M_INDEX] = REG_FIELD(ANA_TABLES_MACTINDX, 0, 9),
+	[GCB_SOFT_RST_SWC_RST] = REG_FIELD(GCB_SOFT_RST, 1, 1),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_VLD] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 20, 20),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_FP] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 8, 19),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_PORTNO] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 4, 7),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_SEL] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 1, 3),
+	[QSYS_TIMED_FRAME_ENTRY_TFRM_TM_T] = REG_FIELD(QSYS_TIMED_FRAME_ENTRY, 0, 0),
+	[SYS_RESET_CFG_CORE_ENA] = REG_FIELD(SYS_RESET_CFG, 2, 2),
+	[SYS_RESET_CFG_MEM_ENA] = REG_FIELD(SYS_RESET_CFG, 1, 1),
+	[SYS_RESET_CFG_MEM_INIT] = REG_FIELD(SYS_RESET_CFG, 0, 0),
+	/* Replicated per number of ports (12), register size 4 per port */
+	[QSYS_SWITCH_PORT_MODE_PORT_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 14, 14, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 11, 13, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_YEL_RSRVD] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 10, 10, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 9, 9, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_TX_PFC_ENA] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 1, 8, 12, 4),
+	[QSYS_SWITCH_PORT_MODE_TX_PFC_MODE] = REG_FIELD_ID(QSYS_SWITCH_PORT_MODE, 0, 0, 12, 4),
+	[SYS_PORT_MODE_DATA_WO_TS] = REG_FIELD_ID(SYS_PORT_MODE, 5, 6, 12, 4),
+	[SYS_PORT_MODE_INCL_INJ_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 3, 4, 12, 4),
+	[SYS_PORT_MODE_INCL_XTR_HDR] = REG_FIELD_ID(SYS_PORT_MODE, 1, 2, 12, 4),
+	[SYS_PORT_MODE_INCL_HDR_ERR] = REG_FIELD_ID(SYS_PORT_MODE, 0, 0, 12, 4),
+	[SYS_PAUSE_CFG_PAUSE_START] = REG_FIELD_ID(SYS_PAUSE_CFG, 10, 18, 12, 4),
+	[SYS_PAUSE_CFG_PAUSE_STOP] = REG_FIELD_ID(SYS_PAUSE_CFG, 1, 9, 12, 4),
+	[SYS_PAUSE_CFG_PAUSE_ENA] = REG_FIELD_ID(SYS_PAUSE_CFG, 0, 1, 12, 4),
+};
+
 const u32 vsc7514_ana_regmap[] = {
 	REG(ANA_ADVLEARN,				0x009000),
 	REG(ANA_VLANMASK,				0x009004),
diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
index ceee26c96959..9b40e7d00ec5 100644
--- a/include/soc/mscc/vsc7514_regs.h
+++ b/include/soc/mscc/vsc7514_regs.h
@@ -10,6 +10,8 @@
 
 #include <soc/mscc/ocelot_vcap.h>
 
+extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
+
 extern const u32 vsc7514_ana_regmap[];
 extern const u32 vsc7514_qs_regmap[];
 extern const u32 vsc7514_qsys_regmap[];
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 12/16] net: mscc: ocelot: expose stats layout definition to be used by other drivers
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The ocelot_stats_layout array is common between several different chips,
some of which can only be controlled externally. Export this structure so
it doesn't have to be duplicated in these other drivers.

Rename the structure as well, to follow the conventions of other shared
resources.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 99 +---------------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 97 +++++++++++++++++++++
 include/soc/mscc/vsc7514_regs.h            |  3 +
 3 files changed, 101 insertions(+), 98 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index a13fec7247d6..7673ed76358b 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -38,103 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
 	[DEV_GMII] = vsc7514_dev_gmii_regmap,
 };
 
-static const struct ocelot_stat_layout ocelot_stats_layout[] = {
-	{ .name = "rx_octets", .offset = 0x00, },
-	{ .name = "rx_unicast", .offset = 0x01, },
-	{ .name = "rx_multicast", .offset = 0x02, },
-	{ .name = "rx_broadcast", .offset = 0x03, },
-	{ .name = "rx_shorts", .offset = 0x04, },
-	{ .name = "rx_fragments", .offset = 0x05, },
-	{ .name = "rx_jabbers", .offset = 0x06, },
-	{ .name = "rx_crc_align_errs", .offset = 0x07, },
-	{ .name = "rx_sym_errs", .offset = 0x08, },
-	{ .name = "rx_frames_below_65_octets", .offset = 0x09, },
-	{ .name = "rx_frames_65_to_127_octets", .offset = 0x0A, },
-	{ .name = "rx_frames_128_to_255_octets", .offset = 0x0B, },
-	{ .name = "rx_frames_256_to_511_octets", .offset = 0x0C, },
-	{ .name = "rx_frames_512_to_1023_octets", .offset = 0x0D, },
-	{ .name = "rx_frames_1024_to_1526_octets", .offset = 0x0E, },
-	{ .name = "rx_frames_over_1526_octets", .offset = 0x0F, },
-	{ .name = "rx_pause", .offset = 0x10, },
-	{ .name = "rx_control", .offset = 0x11, },
-	{ .name = "rx_longs", .offset = 0x12, },
-	{ .name = "rx_classified_drops", .offset = 0x13, },
-	{ .name = "rx_red_prio_0", .offset = 0x14, },
-	{ .name = "rx_red_prio_1", .offset = 0x15, },
-	{ .name = "rx_red_prio_2", .offset = 0x16, },
-	{ .name = "rx_red_prio_3", .offset = 0x17, },
-	{ .name = "rx_red_prio_4", .offset = 0x18, },
-	{ .name = "rx_red_prio_5", .offset = 0x19, },
-	{ .name = "rx_red_prio_6", .offset = 0x1A, },
-	{ .name = "rx_red_prio_7", .offset = 0x1B, },
-	{ .name = "rx_yellow_prio_0", .offset = 0x1C, },
-	{ .name = "rx_yellow_prio_1", .offset = 0x1D, },
-	{ .name = "rx_yellow_prio_2", .offset = 0x1E, },
-	{ .name = "rx_yellow_prio_3", .offset = 0x1F, },
-	{ .name = "rx_yellow_prio_4", .offset = 0x20, },
-	{ .name = "rx_yellow_prio_5", .offset = 0x21, },
-	{ .name = "rx_yellow_prio_6", .offset = 0x22, },
-	{ .name = "rx_yellow_prio_7", .offset = 0x23, },
-	{ .name = "rx_green_prio_0", .offset = 0x24, },
-	{ .name = "rx_green_prio_1", .offset = 0x25, },
-	{ .name = "rx_green_prio_2", .offset = 0x26, },
-	{ .name = "rx_green_prio_3", .offset = 0x27, },
-	{ .name = "rx_green_prio_4", .offset = 0x28, },
-	{ .name = "rx_green_prio_5", .offset = 0x29, },
-	{ .name = "rx_green_prio_6", .offset = 0x2A, },
-	{ .name = "rx_green_prio_7", .offset = 0x2B, },
-	{ .name = "tx_octets", .offset = 0x40, },
-	{ .name = "tx_unicast", .offset = 0x41, },
-	{ .name = "tx_multicast", .offset = 0x42, },
-	{ .name = "tx_broadcast", .offset = 0x43, },
-	{ .name = "tx_collision", .offset = 0x44, },
-	{ .name = "tx_drops", .offset = 0x45, },
-	{ .name = "tx_pause", .offset = 0x46, },
-	{ .name = "tx_frames_below_65_octets", .offset = 0x47, },
-	{ .name = "tx_frames_65_to_127_octets", .offset = 0x48, },
-	{ .name = "tx_frames_128_255_octets", .offset = 0x49, },
-	{ .name = "tx_frames_256_511_octets", .offset = 0x4A, },
-	{ .name = "tx_frames_512_1023_octets", .offset = 0x4B, },
-	{ .name = "tx_frames_1024_1526_octets", .offset = 0x4C, },
-	{ .name = "tx_frames_over_1526_octets", .offset = 0x4D, },
-	{ .name = "tx_yellow_prio_0", .offset = 0x4E, },
-	{ .name = "tx_yellow_prio_1", .offset = 0x4F, },
-	{ .name = "tx_yellow_prio_2", .offset = 0x50, },
-	{ .name = "tx_yellow_prio_3", .offset = 0x51, },
-	{ .name = "tx_yellow_prio_4", .offset = 0x52, },
-	{ .name = "tx_yellow_prio_5", .offset = 0x53, },
-	{ .name = "tx_yellow_prio_6", .offset = 0x54, },
-	{ .name = "tx_yellow_prio_7", .offset = 0x55, },
-	{ .name = "tx_green_prio_0", .offset = 0x56, },
-	{ .name = "tx_green_prio_1", .offset = 0x57, },
-	{ .name = "tx_green_prio_2", .offset = 0x58, },
-	{ .name = "tx_green_prio_3", .offset = 0x59, },
-	{ .name = "tx_green_prio_4", .offset = 0x5A, },
-	{ .name = "tx_green_prio_5", .offset = 0x5B, },
-	{ .name = "tx_green_prio_6", .offset = 0x5C, },
-	{ .name = "tx_green_prio_7", .offset = 0x5D, },
-	{ .name = "tx_aged", .offset = 0x5E, },
-	{ .name = "drop_local", .offset = 0x80, },
-	{ .name = "drop_tail", .offset = 0x81, },
-	{ .name = "drop_yellow_prio_0", .offset = 0x82, },
-	{ .name = "drop_yellow_prio_1", .offset = 0x83, },
-	{ .name = "drop_yellow_prio_2", .offset = 0x84, },
-	{ .name = "drop_yellow_prio_3", .offset = 0x85, },
-	{ .name = "drop_yellow_prio_4", .offset = 0x86, },
-	{ .name = "drop_yellow_prio_5", .offset = 0x87, },
-	{ .name = "drop_yellow_prio_6", .offset = 0x88, },
-	{ .name = "drop_yellow_prio_7", .offset = 0x89, },
-	{ .name = "drop_green_prio_0", .offset = 0x8A, },
-	{ .name = "drop_green_prio_1", .offset = 0x8B, },
-	{ .name = "drop_green_prio_2", .offset = 0x8C, },
-	{ .name = "drop_green_prio_3", .offset = 0x8D, },
-	{ .name = "drop_green_prio_4", .offset = 0x8E, },
-	{ .name = "drop_green_prio_5", .offset = 0x8F, },
-	{ .name = "drop_green_prio_6", .offset = 0x90, },
-	{ .name = "drop_green_prio_7", .offset = 0x91, },
-	OCELOT_STAT_END
-};
-
 static void ocelot_pll5_init(struct ocelot *ocelot)
 {
 	/* Configure PLL5. This will need a proper CCF driver
@@ -169,7 +72,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
 	int ret;
 
 	ocelot->map = ocelot_regmap;
-	ocelot->stats_layout = ocelot_stats_layout;
+	ocelot->stats_layout = vsc7514_stats_layout;
 	ocelot->num_mact_rows = 1024;
 	ocelot->ops = ops;
 
diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
index 847e64d11075..2b75753da4e2 100644
--- a/drivers/net/ethernet/mscc/vsc7514_regs.c
+++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
@@ -9,6 +9,103 @@
 #include <soc/mscc/vsc7514_regs.h>
 #include "ocelot.h"
 
+const struct ocelot_stat_layout vsc7514_stats_layout[] = {
+	{ .name = "rx_octets", .offset = 0x00, },
+	{ .name = "rx_unicast", .offset = 0x01, },
+	{ .name = "rx_multicast", .offset = 0x02, },
+	{ .name = "rx_broadcast", .offset = 0x03, },
+	{ .name = "rx_shorts", .offset = 0x04, },
+	{ .name = "rx_fragments", .offset = 0x05, },
+	{ .name = "rx_jabbers", .offset = 0x06, },
+	{ .name = "rx_crc_align_errs", .offset = 0x07, },
+	{ .name = "rx_sym_errs", .offset = 0x08, },
+	{ .name = "rx_frames_below_65_octets", .offset = 0x09, },
+	{ .name = "rx_frames_65_to_127_octets", .offset = 0x0A, },
+	{ .name = "rx_frames_128_to_255_octets", .offset = 0x0B, },
+	{ .name = "rx_frames_256_to_511_octets", .offset = 0x0C, },
+	{ .name = "rx_frames_512_to_1023_octets", .offset = 0x0D, },
+	{ .name = "rx_frames_1024_to_1526_octets", .offset = 0x0E, },
+	{ .name = "rx_frames_over_1526_octets", .offset = 0x0F, },
+	{ .name = "rx_pause", .offset = 0x10, },
+	{ .name = "rx_control", .offset = 0x11, },
+	{ .name = "rx_longs", .offset = 0x12, },
+	{ .name = "rx_classified_drops", .offset = 0x13, },
+	{ .name = "rx_red_prio_0", .offset = 0x14, },
+	{ .name = "rx_red_prio_1", .offset = 0x15, },
+	{ .name = "rx_red_prio_2", .offset = 0x16, },
+	{ .name = "rx_red_prio_3", .offset = 0x17, },
+	{ .name = "rx_red_prio_4", .offset = 0x18, },
+	{ .name = "rx_red_prio_5", .offset = 0x19, },
+	{ .name = "rx_red_prio_6", .offset = 0x1A, },
+	{ .name = "rx_red_prio_7", .offset = 0x1B, },
+	{ .name = "rx_yellow_prio_0", .offset = 0x1C, },
+	{ .name = "rx_yellow_prio_1", .offset = 0x1D, },
+	{ .name = "rx_yellow_prio_2", .offset = 0x1E, },
+	{ .name = "rx_yellow_prio_3", .offset = 0x1F, },
+	{ .name = "rx_yellow_prio_4", .offset = 0x20, },
+	{ .name = "rx_yellow_prio_5", .offset = 0x21, },
+	{ .name = "rx_yellow_prio_6", .offset = 0x22, },
+	{ .name = "rx_yellow_prio_7", .offset = 0x23, },
+	{ .name = "rx_green_prio_0", .offset = 0x24, },
+	{ .name = "rx_green_prio_1", .offset = 0x25, },
+	{ .name = "rx_green_prio_2", .offset = 0x26, },
+	{ .name = "rx_green_prio_3", .offset = 0x27, },
+	{ .name = "rx_green_prio_4", .offset = 0x28, },
+	{ .name = "rx_green_prio_5", .offset = 0x29, },
+	{ .name = "rx_green_prio_6", .offset = 0x2A, },
+	{ .name = "rx_green_prio_7", .offset = 0x2B, },
+	{ .name = "tx_octets", .offset = 0x40, },
+	{ .name = "tx_unicast", .offset = 0x41, },
+	{ .name = "tx_multicast", .offset = 0x42, },
+	{ .name = "tx_broadcast", .offset = 0x43, },
+	{ .name = "tx_collision", .offset = 0x44, },
+	{ .name = "tx_drops", .offset = 0x45, },
+	{ .name = "tx_pause", .offset = 0x46, },
+	{ .name = "tx_frames_below_65_octets", .offset = 0x47, },
+	{ .name = "tx_frames_65_to_127_octets", .offset = 0x48, },
+	{ .name = "tx_frames_128_255_octets", .offset = 0x49, },
+	{ .name = "tx_frames_256_511_octets", .offset = 0x4A, },
+	{ .name = "tx_frames_512_1023_octets", .offset = 0x4B, },
+	{ .name = "tx_frames_1024_1526_octets", .offset = 0x4C, },
+	{ .name = "tx_frames_over_1526_octets", .offset = 0x4D, },
+	{ .name = "tx_yellow_prio_0", .offset = 0x4E, },
+	{ .name = "tx_yellow_prio_1", .offset = 0x4F, },
+	{ .name = "tx_yellow_prio_2", .offset = 0x50, },
+	{ .name = "tx_yellow_prio_3", .offset = 0x51, },
+	{ .name = "tx_yellow_prio_4", .offset = 0x52, },
+	{ .name = "tx_yellow_prio_5", .offset = 0x53, },
+	{ .name = "tx_yellow_prio_6", .offset = 0x54, },
+	{ .name = "tx_yellow_prio_7", .offset = 0x55, },
+	{ .name = "tx_green_prio_0", .offset = 0x56, },
+	{ .name = "tx_green_prio_1", .offset = 0x57, },
+	{ .name = "tx_green_prio_2", .offset = 0x58, },
+	{ .name = "tx_green_prio_3", .offset = 0x59, },
+	{ .name = "tx_green_prio_4", .offset = 0x5A, },
+	{ .name = "tx_green_prio_5", .offset = 0x5B, },
+	{ .name = "tx_green_prio_6", .offset = 0x5C, },
+	{ .name = "tx_green_prio_7", .offset = 0x5D, },
+	{ .name = "tx_aged", .offset = 0x5E, },
+	{ .name = "drop_local", .offset = 0x80, },
+	{ .name = "drop_tail", .offset = 0x81, },
+	{ .name = "drop_yellow_prio_0", .offset = 0x82, },
+	{ .name = "drop_yellow_prio_1", .offset = 0x83, },
+	{ .name = "drop_yellow_prio_2", .offset = 0x84, },
+	{ .name = "drop_yellow_prio_3", .offset = 0x85, },
+	{ .name = "drop_yellow_prio_4", .offset = 0x86, },
+	{ .name = "drop_yellow_prio_5", .offset = 0x87, },
+	{ .name = "drop_yellow_prio_6", .offset = 0x88, },
+	{ .name = "drop_yellow_prio_7", .offset = 0x89, },
+	{ .name = "drop_green_prio_0", .offset = 0x8A, },
+	{ .name = "drop_green_prio_1", .offset = 0x8B, },
+	{ .name = "drop_green_prio_2", .offset = 0x8C, },
+	{ .name = "drop_green_prio_3", .offset = 0x8D, },
+	{ .name = "drop_green_prio_4", .offset = 0x8E, },
+	{ .name = "drop_green_prio_5", .offset = 0x8F, },
+	{ .name = "drop_green_prio_6", .offset = 0x90, },
+	{ .name = "drop_green_prio_7", .offset = 0x91, },
+	OCELOT_STAT_END
+};
+
 const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
 	[ANA_ADVLEARN_VLAN_CHK] = REG_FIELD(ANA_ADVLEARN, 11, 11),
 	[ANA_ADVLEARN_LEARN_MIRROR] = REG_FIELD(ANA_ADVLEARN, 0, 10),
diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
index 9b40e7d00ec5..d2b5b6b86aff 100644
--- a/include/soc/mscc/vsc7514_regs.h
+++ b/include/soc/mscc/vsc7514_regs.h
@@ -8,8 +8,11 @@
 #ifndef VSC7514_REGS_H
 #define VSC7514_REGS_H
 
+#include <soc/mscc/ocelot.h>
 #include <soc/mscc/ocelot_vcap.h>
 
+extern const struct ocelot_stat_layout vsc7514_stats_layout[];
+
 extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
 
 extern const u32 vsc7514_ana_regmap[];
-- 
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] 114+ messages in thread

* [RFC v8 net-next 12/16] net: mscc: ocelot: expose stats layout definition to be used by other drivers
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The ocelot_stats_layout array is common between several different chips,
some of which can only be controlled externally. Export this structure so
it doesn't have to be duplicated in these other drivers.

Rename the structure as well, to follow the conventions of other shared
resources.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 99 +---------------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 97 +++++++++++++++++++++
 include/soc/mscc/vsc7514_regs.h            |  3 +
 3 files changed, 101 insertions(+), 98 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index a13fec7247d6..7673ed76358b 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -38,103 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
 	[DEV_GMII] = vsc7514_dev_gmii_regmap,
 };
 
-static const struct ocelot_stat_layout ocelot_stats_layout[] = {
-	{ .name = "rx_octets", .offset = 0x00, },
-	{ .name = "rx_unicast", .offset = 0x01, },
-	{ .name = "rx_multicast", .offset = 0x02, },
-	{ .name = "rx_broadcast", .offset = 0x03, },
-	{ .name = "rx_shorts", .offset = 0x04, },
-	{ .name = "rx_fragments", .offset = 0x05, },
-	{ .name = "rx_jabbers", .offset = 0x06, },
-	{ .name = "rx_crc_align_errs", .offset = 0x07, },
-	{ .name = "rx_sym_errs", .offset = 0x08, },
-	{ .name = "rx_frames_below_65_octets", .offset = 0x09, },
-	{ .name = "rx_frames_65_to_127_octets", .offset = 0x0A, },
-	{ .name = "rx_frames_128_to_255_octets", .offset = 0x0B, },
-	{ .name = "rx_frames_256_to_511_octets", .offset = 0x0C, },
-	{ .name = "rx_frames_512_to_1023_octets", .offset = 0x0D, },
-	{ .name = "rx_frames_1024_to_1526_octets", .offset = 0x0E, },
-	{ .name = "rx_frames_over_1526_octets", .offset = 0x0F, },
-	{ .name = "rx_pause", .offset = 0x10, },
-	{ .name = "rx_control", .offset = 0x11, },
-	{ .name = "rx_longs", .offset = 0x12, },
-	{ .name = "rx_classified_drops", .offset = 0x13, },
-	{ .name = "rx_red_prio_0", .offset = 0x14, },
-	{ .name = "rx_red_prio_1", .offset = 0x15, },
-	{ .name = "rx_red_prio_2", .offset = 0x16, },
-	{ .name = "rx_red_prio_3", .offset = 0x17, },
-	{ .name = "rx_red_prio_4", .offset = 0x18, },
-	{ .name = "rx_red_prio_5", .offset = 0x19, },
-	{ .name = "rx_red_prio_6", .offset = 0x1A, },
-	{ .name = "rx_red_prio_7", .offset = 0x1B, },
-	{ .name = "rx_yellow_prio_0", .offset = 0x1C, },
-	{ .name = "rx_yellow_prio_1", .offset = 0x1D, },
-	{ .name = "rx_yellow_prio_2", .offset = 0x1E, },
-	{ .name = "rx_yellow_prio_3", .offset = 0x1F, },
-	{ .name = "rx_yellow_prio_4", .offset = 0x20, },
-	{ .name = "rx_yellow_prio_5", .offset = 0x21, },
-	{ .name = "rx_yellow_prio_6", .offset = 0x22, },
-	{ .name = "rx_yellow_prio_7", .offset = 0x23, },
-	{ .name = "rx_green_prio_0", .offset = 0x24, },
-	{ .name = "rx_green_prio_1", .offset = 0x25, },
-	{ .name = "rx_green_prio_2", .offset = 0x26, },
-	{ .name = "rx_green_prio_3", .offset = 0x27, },
-	{ .name = "rx_green_prio_4", .offset = 0x28, },
-	{ .name = "rx_green_prio_5", .offset = 0x29, },
-	{ .name = "rx_green_prio_6", .offset = 0x2A, },
-	{ .name = "rx_green_prio_7", .offset = 0x2B, },
-	{ .name = "tx_octets", .offset = 0x40, },
-	{ .name = "tx_unicast", .offset = 0x41, },
-	{ .name = "tx_multicast", .offset = 0x42, },
-	{ .name = "tx_broadcast", .offset = 0x43, },
-	{ .name = "tx_collision", .offset = 0x44, },
-	{ .name = "tx_drops", .offset = 0x45, },
-	{ .name = "tx_pause", .offset = 0x46, },
-	{ .name = "tx_frames_below_65_octets", .offset = 0x47, },
-	{ .name = "tx_frames_65_to_127_octets", .offset = 0x48, },
-	{ .name = "tx_frames_128_255_octets", .offset = 0x49, },
-	{ .name = "tx_frames_256_511_octets", .offset = 0x4A, },
-	{ .name = "tx_frames_512_1023_octets", .offset = 0x4B, },
-	{ .name = "tx_frames_1024_1526_octets", .offset = 0x4C, },
-	{ .name = "tx_frames_over_1526_octets", .offset = 0x4D, },
-	{ .name = "tx_yellow_prio_0", .offset = 0x4E, },
-	{ .name = "tx_yellow_prio_1", .offset = 0x4F, },
-	{ .name = "tx_yellow_prio_2", .offset = 0x50, },
-	{ .name = "tx_yellow_prio_3", .offset = 0x51, },
-	{ .name = "tx_yellow_prio_4", .offset = 0x52, },
-	{ .name = "tx_yellow_prio_5", .offset = 0x53, },
-	{ .name = "tx_yellow_prio_6", .offset = 0x54, },
-	{ .name = "tx_yellow_prio_7", .offset = 0x55, },
-	{ .name = "tx_green_prio_0", .offset = 0x56, },
-	{ .name = "tx_green_prio_1", .offset = 0x57, },
-	{ .name = "tx_green_prio_2", .offset = 0x58, },
-	{ .name = "tx_green_prio_3", .offset = 0x59, },
-	{ .name = "tx_green_prio_4", .offset = 0x5A, },
-	{ .name = "tx_green_prio_5", .offset = 0x5B, },
-	{ .name = "tx_green_prio_6", .offset = 0x5C, },
-	{ .name = "tx_green_prio_7", .offset = 0x5D, },
-	{ .name = "tx_aged", .offset = 0x5E, },
-	{ .name = "drop_local", .offset = 0x80, },
-	{ .name = "drop_tail", .offset = 0x81, },
-	{ .name = "drop_yellow_prio_0", .offset = 0x82, },
-	{ .name = "drop_yellow_prio_1", .offset = 0x83, },
-	{ .name = "drop_yellow_prio_2", .offset = 0x84, },
-	{ .name = "drop_yellow_prio_3", .offset = 0x85, },
-	{ .name = "drop_yellow_prio_4", .offset = 0x86, },
-	{ .name = "drop_yellow_prio_5", .offset = 0x87, },
-	{ .name = "drop_yellow_prio_6", .offset = 0x88, },
-	{ .name = "drop_yellow_prio_7", .offset = 0x89, },
-	{ .name = "drop_green_prio_0", .offset = 0x8A, },
-	{ .name = "drop_green_prio_1", .offset = 0x8B, },
-	{ .name = "drop_green_prio_2", .offset = 0x8C, },
-	{ .name = "drop_green_prio_3", .offset = 0x8D, },
-	{ .name = "drop_green_prio_4", .offset = 0x8E, },
-	{ .name = "drop_green_prio_5", .offset = 0x8F, },
-	{ .name = "drop_green_prio_6", .offset = 0x90, },
-	{ .name = "drop_green_prio_7", .offset = 0x91, },
-	OCELOT_STAT_END
-};
-
 static void ocelot_pll5_init(struct ocelot *ocelot)
 {
 	/* Configure PLL5. This will need a proper CCF driver
@@ -169,7 +72,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
 	int ret;
 
 	ocelot->map = ocelot_regmap;
-	ocelot->stats_layout = ocelot_stats_layout;
+	ocelot->stats_layout = vsc7514_stats_layout;
 	ocelot->num_mact_rows = 1024;
 	ocelot->ops = ops;
 
diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
index 847e64d11075..2b75753da4e2 100644
--- a/drivers/net/ethernet/mscc/vsc7514_regs.c
+++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
@@ -9,6 +9,103 @@
 #include <soc/mscc/vsc7514_regs.h>
 #include "ocelot.h"
 
+const struct ocelot_stat_layout vsc7514_stats_layout[] = {
+	{ .name = "rx_octets", .offset = 0x00, },
+	{ .name = "rx_unicast", .offset = 0x01, },
+	{ .name = "rx_multicast", .offset = 0x02, },
+	{ .name = "rx_broadcast", .offset = 0x03, },
+	{ .name = "rx_shorts", .offset = 0x04, },
+	{ .name = "rx_fragments", .offset = 0x05, },
+	{ .name = "rx_jabbers", .offset = 0x06, },
+	{ .name = "rx_crc_align_errs", .offset = 0x07, },
+	{ .name = "rx_sym_errs", .offset = 0x08, },
+	{ .name = "rx_frames_below_65_octets", .offset = 0x09, },
+	{ .name = "rx_frames_65_to_127_octets", .offset = 0x0A, },
+	{ .name = "rx_frames_128_to_255_octets", .offset = 0x0B, },
+	{ .name = "rx_frames_256_to_511_octets", .offset = 0x0C, },
+	{ .name = "rx_frames_512_to_1023_octets", .offset = 0x0D, },
+	{ .name = "rx_frames_1024_to_1526_octets", .offset = 0x0E, },
+	{ .name = "rx_frames_over_1526_octets", .offset = 0x0F, },
+	{ .name = "rx_pause", .offset = 0x10, },
+	{ .name = "rx_control", .offset = 0x11, },
+	{ .name = "rx_longs", .offset = 0x12, },
+	{ .name = "rx_classified_drops", .offset = 0x13, },
+	{ .name = "rx_red_prio_0", .offset = 0x14, },
+	{ .name = "rx_red_prio_1", .offset = 0x15, },
+	{ .name = "rx_red_prio_2", .offset = 0x16, },
+	{ .name = "rx_red_prio_3", .offset = 0x17, },
+	{ .name = "rx_red_prio_4", .offset = 0x18, },
+	{ .name = "rx_red_prio_5", .offset = 0x19, },
+	{ .name = "rx_red_prio_6", .offset = 0x1A, },
+	{ .name = "rx_red_prio_7", .offset = 0x1B, },
+	{ .name = "rx_yellow_prio_0", .offset = 0x1C, },
+	{ .name = "rx_yellow_prio_1", .offset = 0x1D, },
+	{ .name = "rx_yellow_prio_2", .offset = 0x1E, },
+	{ .name = "rx_yellow_prio_3", .offset = 0x1F, },
+	{ .name = "rx_yellow_prio_4", .offset = 0x20, },
+	{ .name = "rx_yellow_prio_5", .offset = 0x21, },
+	{ .name = "rx_yellow_prio_6", .offset = 0x22, },
+	{ .name = "rx_yellow_prio_7", .offset = 0x23, },
+	{ .name = "rx_green_prio_0", .offset = 0x24, },
+	{ .name = "rx_green_prio_1", .offset = 0x25, },
+	{ .name = "rx_green_prio_2", .offset = 0x26, },
+	{ .name = "rx_green_prio_3", .offset = 0x27, },
+	{ .name = "rx_green_prio_4", .offset = 0x28, },
+	{ .name = "rx_green_prio_5", .offset = 0x29, },
+	{ .name = "rx_green_prio_6", .offset = 0x2A, },
+	{ .name = "rx_green_prio_7", .offset = 0x2B, },
+	{ .name = "tx_octets", .offset = 0x40, },
+	{ .name = "tx_unicast", .offset = 0x41, },
+	{ .name = "tx_multicast", .offset = 0x42, },
+	{ .name = "tx_broadcast", .offset = 0x43, },
+	{ .name = "tx_collision", .offset = 0x44, },
+	{ .name = "tx_drops", .offset = 0x45, },
+	{ .name = "tx_pause", .offset = 0x46, },
+	{ .name = "tx_frames_below_65_octets", .offset = 0x47, },
+	{ .name = "tx_frames_65_to_127_octets", .offset = 0x48, },
+	{ .name = "tx_frames_128_255_octets", .offset = 0x49, },
+	{ .name = "tx_frames_256_511_octets", .offset = 0x4A, },
+	{ .name = "tx_frames_512_1023_octets", .offset = 0x4B, },
+	{ .name = "tx_frames_1024_1526_octets", .offset = 0x4C, },
+	{ .name = "tx_frames_over_1526_octets", .offset = 0x4D, },
+	{ .name = "tx_yellow_prio_0", .offset = 0x4E, },
+	{ .name = "tx_yellow_prio_1", .offset = 0x4F, },
+	{ .name = "tx_yellow_prio_2", .offset = 0x50, },
+	{ .name = "tx_yellow_prio_3", .offset = 0x51, },
+	{ .name = "tx_yellow_prio_4", .offset = 0x52, },
+	{ .name = "tx_yellow_prio_5", .offset = 0x53, },
+	{ .name = "tx_yellow_prio_6", .offset = 0x54, },
+	{ .name = "tx_yellow_prio_7", .offset = 0x55, },
+	{ .name = "tx_green_prio_0", .offset = 0x56, },
+	{ .name = "tx_green_prio_1", .offset = 0x57, },
+	{ .name = "tx_green_prio_2", .offset = 0x58, },
+	{ .name = "tx_green_prio_3", .offset = 0x59, },
+	{ .name = "tx_green_prio_4", .offset = 0x5A, },
+	{ .name = "tx_green_prio_5", .offset = 0x5B, },
+	{ .name = "tx_green_prio_6", .offset = 0x5C, },
+	{ .name = "tx_green_prio_7", .offset = 0x5D, },
+	{ .name = "tx_aged", .offset = 0x5E, },
+	{ .name = "drop_local", .offset = 0x80, },
+	{ .name = "drop_tail", .offset = 0x81, },
+	{ .name = "drop_yellow_prio_0", .offset = 0x82, },
+	{ .name = "drop_yellow_prio_1", .offset = 0x83, },
+	{ .name = "drop_yellow_prio_2", .offset = 0x84, },
+	{ .name = "drop_yellow_prio_3", .offset = 0x85, },
+	{ .name = "drop_yellow_prio_4", .offset = 0x86, },
+	{ .name = "drop_yellow_prio_5", .offset = 0x87, },
+	{ .name = "drop_yellow_prio_6", .offset = 0x88, },
+	{ .name = "drop_yellow_prio_7", .offset = 0x89, },
+	{ .name = "drop_green_prio_0", .offset = 0x8A, },
+	{ .name = "drop_green_prio_1", .offset = 0x8B, },
+	{ .name = "drop_green_prio_2", .offset = 0x8C, },
+	{ .name = "drop_green_prio_3", .offset = 0x8D, },
+	{ .name = "drop_green_prio_4", .offset = 0x8E, },
+	{ .name = "drop_green_prio_5", .offset = 0x8F, },
+	{ .name = "drop_green_prio_6", .offset = 0x90, },
+	{ .name = "drop_green_prio_7", .offset = 0x91, },
+	OCELOT_STAT_END
+};
+
 const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
 	[ANA_ADVLEARN_VLAN_CHK] = REG_FIELD(ANA_ADVLEARN, 11, 11),
 	[ANA_ADVLEARN_LEARN_MIRROR] = REG_FIELD(ANA_ADVLEARN, 0, 10),
diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
index 9b40e7d00ec5..d2b5b6b86aff 100644
--- a/include/soc/mscc/vsc7514_regs.h
+++ b/include/soc/mscc/vsc7514_regs.h
@@ -8,8 +8,11 @@
 #ifndef VSC7514_REGS_H
 #define VSC7514_REGS_H
 
+#include <soc/mscc/ocelot.h>
 #include <soc/mscc/ocelot_vcap.h>
 
+extern const struct ocelot_stat_layout vsc7514_stats_layout[];
+
 extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
 
 extern const u32 vsc7514_ana_regmap[];
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 13/16] net: mscc: ocelot: expose vcap_props structure
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The vcap_props structure is common to other devices, specifically the
VSC7512 chip that can only be controlled externally. Export this structure
so it doesn't need to be recreated.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 43 ---------------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 44 ++++++++++++++++++++++
 include/soc/mscc/vsc7514_regs.h            |  1 +
 3 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index 7673ed76358b..6191bca7a9c4 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -161,49 +161,6 @@ static const struct ocelot_ops ocelot_ops = {
 	.netdev_to_port		= ocelot_netdev_to_port,
 };
 
-static struct vcap_props vsc7514_vcap_props[] = {
-	[VCAP_ES0] = {
-		.action_type_width = 0,
-		.action_table = {
-			[ES0_ACTION_TYPE_NORMAL] = {
-				.width = 73, /* HIT_STICKY not included */
-				.count = 1,
-			},
-		},
-		.target = S0,
-		.keys = vsc7514_vcap_es0_keys,
-		.actions = vsc7514_vcap_es0_actions,
-	},
-	[VCAP_IS1] = {
-		.action_type_width = 0,
-		.action_table = {
-			[IS1_ACTION_TYPE_NORMAL] = {
-				.width = 78, /* HIT_STICKY not included */
-				.count = 4,
-			},
-		},
-		.target = S1,
-		.keys = vsc7514_vcap_is1_keys,
-		.actions = vsc7514_vcap_is1_actions,
-	},
-	[VCAP_IS2] = {
-		.action_type_width = 1,
-		.action_table = {
-			[IS2_ACTION_TYPE_NORMAL] = {
-				.width = 49,
-				.count = 2
-			},
-			[IS2_ACTION_TYPE_SMAC_SIP] = {
-				.width = 6,
-				.count = 4
-			},
-		},
-		.target = S2,
-		.keys = vsc7514_vcap_is2_keys,
-		.actions = vsc7514_vcap_is2_actions,
-	},
-};
-
 static struct ptp_clock_info ocelot_ptp_clock_info = {
 	.owner		= THIS_MODULE,
 	.name		= "ocelot ptp",
diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
index 2b75753da4e2..d538b05306f8 100644
--- a/drivers/net/ethernet/mscc/vsc7514_regs.c
+++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
@@ -677,3 +677,47 @@ const struct vcap_field vsc7514_vcap_is2_actions[] = {
 	[VCAP_IS2_ACT_HIT_CNT]			= { 49, 32 },
 };
 EXPORT_SYMBOL(vsc7514_vcap_is2_actions);
+
+struct vcap_props vsc7514_vcap_props[] = {
+	[VCAP_ES0] = {
+		.action_type_width = 0,
+		.action_table = {
+			[ES0_ACTION_TYPE_NORMAL] = {
+				.width = 73, /* HIT_STICKY not included */
+				.count = 1,
+			},
+		},
+		.target = S0,
+		.keys = vsc7514_vcap_es0_keys,
+		.actions = vsc7514_vcap_es0_actions,
+	},
+	[VCAP_IS1] = {
+		.action_type_width = 0,
+		.action_table = {
+			[IS1_ACTION_TYPE_NORMAL] = {
+				.width = 78, /* HIT_STICKY not included */
+				.count = 4,
+			},
+		},
+		.target = S1,
+		.keys = vsc7514_vcap_is1_keys,
+		.actions = vsc7514_vcap_is1_actions,
+	},
+	[VCAP_IS2] = {
+		.action_type_width = 1,
+		.action_table = {
+			[IS2_ACTION_TYPE_NORMAL] = {
+				.width = 49,
+				.count = 2
+			},
+			[IS2_ACTION_TYPE_SMAC_SIP] = {
+				.width = 6,
+				.count = 4
+			},
+		},
+		.target = S2,
+		.keys = vsc7514_vcap_is2_keys,
+		.actions = vsc7514_vcap_is2_actions,
+	},
+};
+EXPORT_SYMBOL(vsc7514_vcap_props);
diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
index d2b5b6b86aff..a939849efd91 100644
--- a/include/soc/mscc/vsc7514_regs.h
+++ b/include/soc/mscc/vsc7514_regs.h
@@ -12,6 +12,7 @@
 #include <soc/mscc/ocelot_vcap.h>
 
 extern const struct ocelot_stat_layout vsc7514_stats_layout[];
+extern struct vcap_props vsc7514_vcap_props[];
 
 extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
 
-- 
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] 114+ messages in thread

* [RFC v8 net-next 13/16] net: mscc: ocelot: expose vcap_props structure
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

The vcap_props structure is common to other devices, specifically the
VSC7512 chip that can only be controlled externally. Export this structure
so it doesn't need to be recreated.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/mscc/ocelot_vsc7514.c | 43 ---------------------
 drivers/net/ethernet/mscc/vsc7514_regs.c   | 44 ++++++++++++++++++++++
 include/soc/mscc/vsc7514_regs.h            |  1 +
 3 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
index 7673ed76358b..6191bca7a9c4 100644
--- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
+++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
@@ -161,49 +161,6 @@ static const struct ocelot_ops ocelot_ops = {
 	.netdev_to_port		= ocelot_netdev_to_port,
 };
 
-static struct vcap_props vsc7514_vcap_props[] = {
-	[VCAP_ES0] = {
-		.action_type_width = 0,
-		.action_table = {
-			[ES0_ACTION_TYPE_NORMAL] = {
-				.width = 73, /* HIT_STICKY not included */
-				.count = 1,
-			},
-		},
-		.target = S0,
-		.keys = vsc7514_vcap_es0_keys,
-		.actions = vsc7514_vcap_es0_actions,
-	},
-	[VCAP_IS1] = {
-		.action_type_width = 0,
-		.action_table = {
-			[IS1_ACTION_TYPE_NORMAL] = {
-				.width = 78, /* HIT_STICKY not included */
-				.count = 4,
-			},
-		},
-		.target = S1,
-		.keys = vsc7514_vcap_is1_keys,
-		.actions = vsc7514_vcap_is1_actions,
-	},
-	[VCAP_IS2] = {
-		.action_type_width = 1,
-		.action_table = {
-			[IS2_ACTION_TYPE_NORMAL] = {
-				.width = 49,
-				.count = 2
-			},
-			[IS2_ACTION_TYPE_SMAC_SIP] = {
-				.width = 6,
-				.count = 4
-			},
-		},
-		.target = S2,
-		.keys = vsc7514_vcap_is2_keys,
-		.actions = vsc7514_vcap_is2_actions,
-	},
-};
-
 static struct ptp_clock_info ocelot_ptp_clock_info = {
 	.owner		= THIS_MODULE,
 	.name		= "ocelot ptp",
diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
index 2b75753da4e2..d538b05306f8 100644
--- a/drivers/net/ethernet/mscc/vsc7514_regs.c
+++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
@@ -677,3 +677,47 @@ const struct vcap_field vsc7514_vcap_is2_actions[] = {
 	[VCAP_IS2_ACT_HIT_CNT]			= { 49, 32 },
 };
 EXPORT_SYMBOL(vsc7514_vcap_is2_actions);
+
+struct vcap_props vsc7514_vcap_props[] = {
+	[VCAP_ES0] = {
+		.action_type_width = 0,
+		.action_table = {
+			[ES0_ACTION_TYPE_NORMAL] = {
+				.width = 73, /* HIT_STICKY not included */
+				.count = 1,
+			},
+		},
+		.target = S0,
+		.keys = vsc7514_vcap_es0_keys,
+		.actions = vsc7514_vcap_es0_actions,
+	},
+	[VCAP_IS1] = {
+		.action_type_width = 0,
+		.action_table = {
+			[IS1_ACTION_TYPE_NORMAL] = {
+				.width = 78, /* HIT_STICKY not included */
+				.count = 4,
+			},
+		},
+		.target = S1,
+		.keys = vsc7514_vcap_is1_keys,
+		.actions = vsc7514_vcap_is1_actions,
+	},
+	[VCAP_IS2] = {
+		.action_type_width = 1,
+		.action_table = {
+			[IS2_ACTION_TYPE_NORMAL] = {
+				.width = 49,
+				.count = 2
+			},
+			[IS2_ACTION_TYPE_SMAC_SIP] = {
+				.width = 6,
+				.count = 4
+			},
+		},
+		.target = S2,
+		.keys = vsc7514_vcap_is2_keys,
+		.actions = vsc7514_vcap_is2_actions,
+	},
+};
+EXPORT_SYMBOL(vsc7514_vcap_props);
diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
index d2b5b6b86aff..a939849efd91 100644
--- a/include/soc/mscc/vsc7514_regs.h
+++ b/include/soc/mscc/vsc7514_regs.h
@@ -12,6 +12,7 @@
 #include <soc/mscc/ocelot_vcap.h>
 
 extern const struct ocelot_stat_layout vsc7514_stats_layout[];
+extern struct vcap_props vsc7514_vcap_props[];
 
 extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Add control of an external VSC7512 chip by way of the ocelot-mfd interface.

Currently the four copper phy ports are fully functional. Communication to
external phys is also functional, but the SGMII / QSGMII interfaces are
currently non-functional.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/mfd/ocelot-core.c           |   3 +
 drivers/net/dsa/ocelot/Kconfig      |  14 ++
 drivers/net/dsa/ocelot/Makefile     |   5 +
 drivers/net/dsa/ocelot/ocelot_ext.c | 368 ++++++++++++++++++++++++++++
 include/soc/mscc/ocelot.h           |   2 +
 5 files changed, 392 insertions(+)
 create mode 100644 drivers/net/dsa/ocelot/ocelot_ext.c

diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
index 117028f7d845..c582b409a9f3 100644
--- a/drivers/mfd/ocelot-core.c
+++ b/drivers/mfd/ocelot-core.c
@@ -112,6 +112,9 @@ static const struct mfd_cell vsc7512_devs[] = {
 		.of_compatible = "mscc,ocelot-miim",
 		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
 		.resources = vsc7512_miim1_resources,
+	}, {
+		.name = "ocelot-ext-switch",
+		.of_compatible = "mscc,vsc7512-ext-switch",
 	},
 };
 
diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
index 220b0b027b55..f40b2c7171ad 100644
--- a/drivers/net/dsa/ocelot/Kconfig
+++ b/drivers/net/dsa/ocelot/Kconfig
@@ -1,4 +1,18 @@
 # SPDX-License-Identifier: GPL-2.0-only
+config NET_DSA_MSCC_OCELOT_EXT
+	tristate "Ocelot External Ethernet switch support"
+	depends on NET_DSA && SPI
+	depends on NET_VENDOR_MICROSEMI
+	select MDIO_MSCC_MIIM
+	select MFD_OCELOT_CORE
+	select MSCC_OCELOT_SWITCH_LIB
+	select NET_DSA_TAG_OCELOT_8021Q
+	select NET_DSA_TAG_OCELOT
+	help
+	  This driver supports the VSC7511, VSC7512, VSC7513 and VSC7514 chips
+	  when controlled through SPI. It can be used with the Microsemi dev
+	  boards and an external CPU or custom hardware.
+
 config NET_DSA_MSCC_FELIX
 	tristate "Ocelot / Felix Ethernet switch support"
 	depends on NET_DSA && PCI
diff --git a/drivers/net/dsa/ocelot/Makefile b/drivers/net/dsa/ocelot/Makefile
index f6dd131e7491..d7f3f5a4461c 100644
--- a/drivers/net/dsa/ocelot/Makefile
+++ b/drivers/net/dsa/ocelot/Makefile
@@ -1,11 +1,16 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_NET_DSA_MSCC_FELIX) += mscc_felix.o
+obj-$(CONFIG_NET_DSA_MSCC_OCELOT_EXT) += mscc_ocelot_ext.o
 obj-$(CONFIG_NET_DSA_MSCC_SEVILLE) += mscc_seville.o
 
 mscc_felix-objs := \
 	felix.o \
 	felix_vsc9959.o
 
+mscc_ocelot_ext-objs := \
+	felix.o \
+	ocelot_ext.o
+
 mscc_seville-objs := \
 	felix.o \
 	seville_vsc9953.o
diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
new file mode 100644
index 000000000000..ba924f6b8d12
--- /dev/null
+++ b/drivers/net/dsa/ocelot/ocelot_ext.c
@@ -0,0 +1,368 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021-2022 Innovative Advantage Inc.
+ */
+
+#include <asm/byteorder.h>
+#include <linux/iopoll.h>
+#include <linux/kconfig.h>
+#include <linux/phylink.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <soc/mscc/ocelot_ana.h>
+#include <soc/mscc/ocelot_dev.h>
+#include <soc/mscc/ocelot_qsys.h>
+#include <soc/mscc/ocelot_vcap.h>
+#include <soc/mscc/ocelot_ptp.h>
+#include <soc/mscc/ocelot_sys.h>
+#include <soc/mscc/ocelot.h>
+#include <soc/mscc/vsc7514_regs.h>
+#include "felix.h"
+
+#define VSC7512_NUM_PORTS		11
+
+static const u32 vsc7512_port_modes[VSC7512_NUM_PORTS] = {
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+};
+
+static const u32 vsc7512_gcb_regmap[] = {
+	REG(GCB_SOFT_RST,			0x0008),
+	REG(GCB_MIIM_MII_STATUS,		0x009c),
+	REG(GCB_PHY_PHY_CFG,			0x00f0),
+	REG(GCB_PHY_PHY_STAT,			0x00f4),
+};
+
+static const u32 *vsc7512_regmap[TARGET_MAX] = {
+	[ANA] = vsc7514_ana_regmap,
+	[QS] = vsc7514_qs_regmap,
+	[QSYS] = vsc7514_qsys_regmap,
+	[REW] = vsc7514_rew_regmap,
+	[SYS] = vsc7514_sys_regmap,
+	[S0] = vsc7514_vcap_regmap,
+	[S1] = vsc7514_vcap_regmap,
+	[S2] = vsc7514_vcap_regmap,
+	[PTP] = vsc7514_ptp_regmap,
+	[GCB] = vsc7512_gcb_regmap,
+	[DEV_GMII] = vsc7514_dev_gmii_regmap,
+};
+
+static void ocelot_ext_reset_phys(struct ocelot *ocelot)
+{
+	ocelot_write(ocelot, 0, GCB_PHY_PHY_CFG);
+	ocelot_write(ocelot, 0x1ff, GCB_PHY_PHY_CFG);
+	mdelay(500);
+}
+
+static int ocelot_ext_reset(struct ocelot *ocelot)
+{
+	int retries = 100;
+	int err, val;
+
+	ocelot_ext_reset_phys(ocelot);
+
+	/* Initialize chip memories */
+	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
+	if (err)
+		return err;
+
+	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
+	if (err)
+		return err;
+
+	/* MEM_INIT is a self-clearing bit. Wait for it to be clear (should be
+	 * 100us) before enabling the switch core
+	 */
+	do {
+		msleep(1);
+		err = regmap_field_read(ocelot->regfields[SYS_RESET_CFG_MEM_INIT],
+					&val);
+		if (err)
+			return err;
+	} while (val && --retries);
+
+	if (!retries)
+		return -ETIMEDOUT;
+
+	return regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1);
+}
+
+static const struct ocelot_ops ocelot_ext_ops = {
+	.reset		= ocelot_ext_reset,
+	.wm_enc		= ocelot_wm_enc,
+	.wm_dec		= ocelot_wm_dec,
+	.wm_stat	= ocelot_wm_stat,
+	.port_to_netdev	= felix_port_to_netdev,
+	.netdev_to_port	= felix_netdev_to_port,
+};
+
+static const struct resource vsc7512_target_io_res[TARGET_MAX] = {
+	[ANA] = {
+		.start	= 0x71880000,
+		.end	= 0x7188ffff,
+		.name	= "ana",
+	},
+	[QS] = {
+		.start	= 0x71080000,
+		.end	= 0x710800ff,
+		.name	= "qs",
+	},
+	[QSYS] = {
+		.start	= 0x71800000,
+		.end	= 0x719fffff,
+		.name	= "qsys",
+	},
+	[REW] = {
+		.start	= 0x71030000,
+		.end	= 0x7103ffff,
+		.name	= "rew",
+	},
+	[SYS] = {
+		.start	= 0x71010000,
+		.end	= 0x7101ffff,
+		.name	= "sys",
+	},
+	[S0] = {
+		.start	= 0x71040000,
+		.end	= 0x710403ff,
+		.name	= "s0",
+	},
+	[S1] = {
+		.start	= 0x71050000,
+		.end	= 0x710503ff,
+		.name	= "s1",
+	},
+	[S2] = {
+		.start	= 0x71060000,
+		.end	= 0x710603ff,
+		.name	= "s2",
+	},
+	[GCB] =	{
+		.start	= 0x71070000,
+		.end	= 0x7107022b,
+		.name	= "devcpu_gcb",
+	},
+};
+
+static const struct resource vsc7512_port_io_res[] = {
+	{
+		.start	= 0x711e0000,
+		.end	= 0x711effff,
+		.name	= "port0",
+	},
+	{
+		.start	= 0x711f0000,
+		.end	= 0x711fffff,
+		.name	= "port1",
+	},
+	{
+		.start	= 0x71200000,
+		.end	= 0x7120ffff,
+		.name	= "port2",
+	},
+	{
+		.start	= 0x71210000,
+		.end	= 0x7121ffff,
+		.name	= "port3",
+	},
+	{
+		.start	= 0x71220000,
+		.end	= 0x7122ffff,
+		.name	= "port4",
+	},
+	{
+		.start	= 0x71230000,
+		.end	= 0x7123ffff,
+		.name	= "port5",
+	},
+	{
+		.start	= 0x71240000,
+		.end	= 0x7124ffff,
+		.name	= "port6",
+	},
+	{
+		.start	= 0x71250000,
+		.end	= 0x7125ffff,
+		.name	= "port7",
+	},
+	{
+		.start	= 0x71260000,
+		.end	= 0x7126ffff,
+		.name	= "port8",
+	},
+	{
+		.start	= 0x71270000,
+		.end	= 0x7127ffff,
+		.name	= "port9",
+	},
+	{
+		.start	= 0x71280000,
+		.end	= 0x7128ffff,
+		.name	= "port10",
+	},
+};
+
+static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
+					unsigned long *supported,
+					struct phylink_link_state *state)
+{
+	struct ocelot_port *ocelot_port = ocelot->ports[port];
+
+	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+	if (state->interface != PHY_INTERFACE_MODE_NA &&
+	    state->interface != ocelot_port->phy_mode) {
+		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+		return;
+	}
+
+	phylink_set_port_modes(mask);
+
+	phylink_set(mask, Pause);
+	phylink_set(mask, Autoneg);
+	phylink_set(mask, Asym_Pause);
+	phylink_set(mask, 10baseT_Half);
+	phylink_set(mask, 10baseT_Full);
+	phylink_set(mask, 100baseT_Half);
+	phylink_set(mask, 100baseT_Full);
+	phylink_set(mask, 1000baseT_Half);
+	phylink_set(mask, 1000baseT_Full);
+
+	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
+	bitmap_and(state->advertising, state->advertising, mask,
+		   __ETHTOOL_LINK_MODE_MASK_NBITS);
+}
+
+static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
+					     struct resource *res)
+{
+	return ocelot_init_regmap_from_resource(ocelot->dev, res);
+}
+
+static const struct felix_info vsc7512_info = {
+	.target_io_res			= vsc7512_target_io_res,
+	.port_io_res			= vsc7512_port_io_res,
+	.regfields			= vsc7514_regfields,
+	.map				= vsc7512_regmap,
+	.ops				= &ocelot_ext_ops,
+	.stats_layout			= vsc7514_stats_layout,
+	.vcap				= vsc7514_vcap_props,
+	.num_mact_rows			= 1024,
+	.num_ports			= VSC7512_NUM_PORTS,
+	.num_tx_queues			= OCELOT_NUM_TC,
+	.phylink_validate		= ocelot_ext_phylink_validate,
+	.port_modes			= vsc7512_port_modes,
+	.init_regmap			= ocelot_ext_regmap_init,
+};
+
+static int ocelot_ext_probe(struct platform_device *pdev)
+{
+	struct dsa_switch *ds;
+	struct ocelot *ocelot;
+	struct felix *felix;
+	struct device *dev;
+	int err;
+
+	dev = &pdev->dev;
+
+	felix = kzalloc(sizeof(*felix), GFP_KERNEL);
+	if (!felix)
+		return -ENOMEM;
+
+	dev_set_drvdata(dev, felix);
+
+	ocelot = &felix->ocelot;
+	ocelot->dev = dev;
+
+	ocelot->num_flooding_pgids = 1;
+
+	felix->info = &vsc7512_info;
+
+	ds = kzalloc(sizeof(*ds), GFP_KERNEL);
+	if (!ds) {
+		err = -ENOMEM;
+		dev_err(dev, "Failed to allocate DSA switch\n");
+		goto err_free_felix;
+	}
+
+	ds->dev = dev;
+	ds->num_ports = felix->info->num_ports;
+	ds->num_tx_queues = felix->info->num_tx_queues;
+
+	ds->ops = &felix_switch_ops;
+	ds->priv = ocelot;
+	felix->ds = ds;
+	felix->tag_proto = DSA_TAG_PROTO_OCELOT;
+
+	err = dsa_register_switch(ds);
+	if (err) {
+		dev_err(dev, "Failed to register DSA switch: %d\n", err);
+		goto err_free_ds;
+	}
+
+	return 0;
+
+err_free_ds:
+	kfree(ds);
+err_free_felix:
+	kfree(felix);
+	return err;
+}
+
+static int ocelot_ext_remove(struct platform_device *pdev)
+{
+	struct felix *felix = dev_get_drvdata(&pdev->dev);
+
+	if (!felix)
+		return 0;
+
+	dsa_unregister_switch(felix->ds);
+
+	kfree(felix->ds);
+	kfree(felix);
+
+	dev_set_drvdata(&pdev->dev, NULL);
+
+	return 0;
+}
+
+static void ocelot_ext_shutdown(struct platform_device *pdev)
+{
+	struct felix *felix = dev_get_drvdata(&pdev->dev);
+
+	if (!felix)
+		return;
+
+	dsa_switch_shutdown(felix->ds);
+
+	dev_set_drvdata(&pdev->dev, NULL);
+}
+
+const struct of_device_id ocelot_ext_switch_of_match[] = {
+	{ .compatible = "mscc,vsc7512-ext-switch" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);
+
+static struct platform_driver ocelot_ext_switch_driver = {
+	.driver = {
+		.name = "ocelot-ext-switch",
+		.of_match_table = of_match_ptr(ocelot_ext_switch_of_match),
+	},
+	.probe = ocelot_ext_probe,
+	.remove = ocelot_ext_remove,
+	.shutdown = ocelot_ext_shutdown,
+};
+module_platform_driver(ocelot_ext_switch_driver);
+
+MODULE_DESCRIPTION("External Ocelot Switch driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 61888453f913..ade84e86741e 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -402,6 +402,8 @@ enum ocelot_reg {
 	GCB_MIIM_MII_STATUS,
 	GCB_MIIM_MII_CMD,
 	GCB_MIIM_MII_DATA,
+	GCB_PHY_PHY_CFG,
+	GCB_PHY_PHY_STAT,
 	DEV_CLOCK_CFG = DEV_GMII << TARGET_OFFSET,
 	DEV_PORT_MISC,
 	DEV_EVENTS,
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Add control of an external VSC7512 chip by way of the ocelot-mfd interface.

Currently the four copper phy ports are fully functional. Communication to
external phys is also functional, but the SGMII / QSGMII interfaces are
currently non-functional.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/mfd/ocelot-core.c           |   3 +
 drivers/net/dsa/ocelot/Kconfig      |  14 ++
 drivers/net/dsa/ocelot/Makefile     |   5 +
 drivers/net/dsa/ocelot/ocelot_ext.c | 368 ++++++++++++++++++++++++++++
 include/soc/mscc/ocelot.h           |   2 +
 5 files changed, 392 insertions(+)
 create mode 100644 drivers/net/dsa/ocelot/ocelot_ext.c

diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
index 117028f7d845..c582b409a9f3 100644
--- a/drivers/mfd/ocelot-core.c
+++ b/drivers/mfd/ocelot-core.c
@@ -112,6 +112,9 @@ static const struct mfd_cell vsc7512_devs[] = {
 		.of_compatible = "mscc,ocelot-miim",
 		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
 		.resources = vsc7512_miim1_resources,
+	}, {
+		.name = "ocelot-ext-switch",
+		.of_compatible = "mscc,vsc7512-ext-switch",
 	},
 };
 
diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
index 220b0b027b55..f40b2c7171ad 100644
--- a/drivers/net/dsa/ocelot/Kconfig
+++ b/drivers/net/dsa/ocelot/Kconfig
@@ -1,4 +1,18 @@
 # SPDX-License-Identifier: GPL-2.0-only
+config NET_DSA_MSCC_OCELOT_EXT
+	tristate "Ocelot External Ethernet switch support"
+	depends on NET_DSA && SPI
+	depends on NET_VENDOR_MICROSEMI
+	select MDIO_MSCC_MIIM
+	select MFD_OCELOT_CORE
+	select MSCC_OCELOT_SWITCH_LIB
+	select NET_DSA_TAG_OCELOT_8021Q
+	select NET_DSA_TAG_OCELOT
+	help
+	  This driver supports the VSC7511, VSC7512, VSC7513 and VSC7514 chips
+	  when controlled through SPI. It can be used with the Microsemi dev
+	  boards and an external CPU or custom hardware.
+
 config NET_DSA_MSCC_FELIX
 	tristate "Ocelot / Felix Ethernet switch support"
 	depends on NET_DSA && PCI
diff --git a/drivers/net/dsa/ocelot/Makefile b/drivers/net/dsa/ocelot/Makefile
index f6dd131e7491..d7f3f5a4461c 100644
--- a/drivers/net/dsa/ocelot/Makefile
+++ b/drivers/net/dsa/ocelot/Makefile
@@ -1,11 +1,16 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_NET_DSA_MSCC_FELIX) += mscc_felix.o
+obj-$(CONFIG_NET_DSA_MSCC_OCELOT_EXT) += mscc_ocelot_ext.o
 obj-$(CONFIG_NET_DSA_MSCC_SEVILLE) += mscc_seville.o
 
 mscc_felix-objs := \
 	felix.o \
 	felix_vsc9959.o
 
+mscc_ocelot_ext-objs := \
+	felix.o \
+	ocelot_ext.o
+
 mscc_seville-objs := \
 	felix.o \
 	seville_vsc9953.o
diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
new file mode 100644
index 000000000000..ba924f6b8d12
--- /dev/null
+++ b/drivers/net/dsa/ocelot/ocelot_ext.c
@@ -0,0 +1,368 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021-2022 Innovative Advantage Inc.
+ */
+
+#include <asm/byteorder.h>
+#include <linux/iopoll.h>
+#include <linux/kconfig.h>
+#include <linux/phylink.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <soc/mscc/ocelot_ana.h>
+#include <soc/mscc/ocelot_dev.h>
+#include <soc/mscc/ocelot_qsys.h>
+#include <soc/mscc/ocelot_vcap.h>
+#include <soc/mscc/ocelot_ptp.h>
+#include <soc/mscc/ocelot_sys.h>
+#include <soc/mscc/ocelot.h>
+#include <soc/mscc/vsc7514_regs.h>
+#include "felix.h"
+
+#define VSC7512_NUM_PORTS		11
+
+static const u32 vsc7512_port_modes[VSC7512_NUM_PORTS] = {
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_INTERNAL,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+	OCELOT_PORT_MODE_SGMII,
+	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
+};
+
+static const u32 vsc7512_gcb_regmap[] = {
+	REG(GCB_SOFT_RST,			0x0008),
+	REG(GCB_MIIM_MII_STATUS,		0x009c),
+	REG(GCB_PHY_PHY_CFG,			0x00f0),
+	REG(GCB_PHY_PHY_STAT,			0x00f4),
+};
+
+static const u32 *vsc7512_regmap[TARGET_MAX] = {
+	[ANA] = vsc7514_ana_regmap,
+	[QS] = vsc7514_qs_regmap,
+	[QSYS] = vsc7514_qsys_regmap,
+	[REW] = vsc7514_rew_regmap,
+	[SYS] = vsc7514_sys_regmap,
+	[S0] = vsc7514_vcap_regmap,
+	[S1] = vsc7514_vcap_regmap,
+	[S2] = vsc7514_vcap_regmap,
+	[PTP] = vsc7514_ptp_regmap,
+	[GCB] = vsc7512_gcb_regmap,
+	[DEV_GMII] = vsc7514_dev_gmii_regmap,
+};
+
+static void ocelot_ext_reset_phys(struct ocelot *ocelot)
+{
+	ocelot_write(ocelot, 0, GCB_PHY_PHY_CFG);
+	ocelot_write(ocelot, 0x1ff, GCB_PHY_PHY_CFG);
+	mdelay(500);
+}
+
+static int ocelot_ext_reset(struct ocelot *ocelot)
+{
+	int retries = 100;
+	int err, val;
+
+	ocelot_ext_reset_phys(ocelot);
+
+	/* Initialize chip memories */
+	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
+	if (err)
+		return err;
+
+	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
+	if (err)
+		return err;
+
+	/* MEM_INIT is a self-clearing bit. Wait for it to be clear (should be
+	 * 100us) before enabling the switch core
+	 */
+	do {
+		msleep(1);
+		err = regmap_field_read(ocelot->regfields[SYS_RESET_CFG_MEM_INIT],
+					&val);
+		if (err)
+			return err;
+	} while (val && --retries);
+
+	if (!retries)
+		return -ETIMEDOUT;
+
+	return regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1);
+}
+
+static const struct ocelot_ops ocelot_ext_ops = {
+	.reset		= ocelot_ext_reset,
+	.wm_enc		= ocelot_wm_enc,
+	.wm_dec		= ocelot_wm_dec,
+	.wm_stat	= ocelot_wm_stat,
+	.port_to_netdev	= felix_port_to_netdev,
+	.netdev_to_port	= felix_netdev_to_port,
+};
+
+static const struct resource vsc7512_target_io_res[TARGET_MAX] = {
+	[ANA] = {
+		.start	= 0x71880000,
+		.end	= 0x7188ffff,
+		.name	= "ana",
+	},
+	[QS] = {
+		.start	= 0x71080000,
+		.end	= 0x710800ff,
+		.name	= "qs",
+	},
+	[QSYS] = {
+		.start	= 0x71800000,
+		.end	= 0x719fffff,
+		.name	= "qsys",
+	},
+	[REW] = {
+		.start	= 0x71030000,
+		.end	= 0x7103ffff,
+		.name	= "rew",
+	},
+	[SYS] = {
+		.start	= 0x71010000,
+		.end	= 0x7101ffff,
+		.name	= "sys",
+	},
+	[S0] = {
+		.start	= 0x71040000,
+		.end	= 0x710403ff,
+		.name	= "s0",
+	},
+	[S1] = {
+		.start	= 0x71050000,
+		.end	= 0x710503ff,
+		.name	= "s1",
+	},
+	[S2] = {
+		.start	= 0x71060000,
+		.end	= 0x710603ff,
+		.name	= "s2",
+	},
+	[GCB] =	{
+		.start	= 0x71070000,
+		.end	= 0x7107022b,
+		.name	= "devcpu_gcb",
+	},
+};
+
+static const struct resource vsc7512_port_io_res[] = {
+	{
+		.start	= 0x711e0000,
+		.end	= 0x711effff,
+		.name	= "port0",
+	},
+	{
+		.start	= 0x711f0000,
+		.end	= 0x711fffff,
+		.name	= "port1",
+	},
+	{
+		.start	= 0x71200000,
+		.end	= 0x7120ffff,
+		.name	= "port2",
+	},
+	{
+		.start	= 0x71210000,
+		.end	= 0x7121ffff,
+		.name	= "port3",
+	},
+	{
+		.start	= 0x71220000,
+		.end	= 0x7122ffff,
+		.name	= "port4",
+	},
+	{
+		.start	= 0x71230000,
+		.end	= 0x7123ffff,
+		.name	= "port5",
+	},
+	{
+		.start	= 0x71240000,
+		.end	= 0x7124ffff,
+		.name	= "port6",
+	},
+	{
+		.start	= 0x71250000,
+		.end	= 0x7125ffff,
+		.name	= "port7",
+	},
+	{
+		.start	= 0x71260000,
+		.end	= 0x7126ffff,
+		.name	= "port8",
+	},
+	{
+		.start	= 0x71270000,
+		.end	= 0x7127ffff,
+		.name	= "port9",
+	},
+	{
+		.start	= 0x71280000,
+		.end	= 0x7128ffff,
+		.name	= "port10",
+	},
+};
+
+static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
+					unsigned long *supported,
+					struct phylink_link_state *state)
+{
+	struct ocelot_port *ocelot_port = ocelot->ports[port];
+
+	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+	if (state->interface != PHY_INTERFACE_MODE_NA &&
+	    state->interface != ocelot_port->phy_mode) {
+		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+		return;
+	}
+
+	phylink_set_port_modes(mask);
+
+	phylink_set(mask, Pause);
+	phylink_set(mask, Autoneg);
+	phylink_set(mask, Asym_Pause);
+	phylink_set(mask, 10baseT_Half);
+	phylink_set(mask, 10baseT_Full);
+	phylink_set(mask, 100baseT_Half);
+	phylink_set(mask, 100baseT_Full);
+	phylink_set(mask, 1000baseT_Half);
+	phylink_set(mask, 1000baseT_Full);
+
+	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
+	bitmap_and(state->advertising, state->advertising, mask,
+		   __ETHTOOL_LINK_MODE_MASK_NBITS);
+}
+
+static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
+					     struct resource *res)
+{
+	return ocelot_init_regmap_from_resource(ocelot->dev, res);
+}
+
+static const struct felix_info vsc7512_info = {
+	.target_io_res			= vsc7512_target_io_res,
+	.port_io_res			= vsc7512_port_io_res,
+	.regfields			= vsc7514_regfields,
+	.map				= vsc7512_regmap,
+	.ops				= &ocelot_ext_ops,
+	.stats_layout			= vsc7514_stats_layout,
+	.vcap				= vsc7514_vcap_props,
+	.num_mact_rows			= 1024,
+	.num_ports			= VSC7512_NUM_PORTS,
+	.num_tx_queues			= OCELOT_NUM_TC,
+	.phylink_validate		= ocelot_ext_phylink_validate,
+	.port_modes			= vsc7512_port_modes,
+	.init_regmap			= ocelot_ext_regmap_init,
+};
+
+static int ocelot_ext_probe(struct platform_device *pdev)
+{
+	struct dsa_switch *ds;
+	struct ocelot *ocelot;
+	struct felix *felix;
+	struct device *dev;
+	int err;
+
+	dev = &pdev->dev;
+
+	felix = kzalloc(sizeof(*felix), GFP_KERNEL);
+	if (!felix)
+		return -ENOMEM;
+
+	dev_set_drvdata(dev, felix);
+
+	ocelot = &felix->ocelot;
+	ocelot->dev = dev;
+
+	ocelot->num_flooding_pgids = 1;
+
+	felix->info = &vsc7512_info;
+
+	ds = kzalloc(sizeof(*ds), GFP_KERNEL);
+	if (!ds) {
+		err = -ENOMEM;
+		dev_err(dev, "Failed to allocate DSA switch\n");
+		goto err_free_felix;
+	}
+
+	ds->dev = dev;
+	ds->num_ports = felix->info->num_ports;
+	ds->num_tx_queues = felix->info->num_tx_queues;
+
+	ds->ops = &felix_switch_ops;
+	ds->priv = ocelot;
+	felix->ds = ds;
+	felix->tag_proto = DSA_TAG_PROTO_OCELOT;
+
+	err = dsa_register_switch(ds);
+	if (err) {
+		dev_err(dev, "Failed to register DSA switch: %d\n", err);
+		goto err_free_ds;
+	}
+
+	return 0;
+
+err_free_ds:
+	kfree(ds);
+err_free_felix:
+	kfree(felix);
+	return err;
+}
+
+static int ocelot_ext_remove(struct platform_device *pdev)
+{
+	struct felix *felix = dev_get_drvdata(&pdev->dev);
+
+	if (!felix)
+		return 0;
+
+	dsa_unregister_switch(felix->ds);
+
+	kfree(felix->ds);
+	kfree(felix);
+
+	dev_set_drvdata(&pdev->dev, NULL);
+
+	return 0;
+}
+
+static void ocelot_ext_shutdown(struct platform_device *pdev)
+{
+	struct felix *felix = dev_get_drvdata(&pdev->dev);
+
+	if (!felix)
+		return;
+
+	dsa_switch_shutdown(felix->ds);
+
+	dev_set_drvdata(&pdev->dev, NULL);
+}
+
+const struct of_device_id ocelot_ext_switch_of_match[] = {
+	{ .compatible = "mscc,vsc7512-ext-switch" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);
+
+static struct platform_driver ocelot_ext_switch_driver = {
+	.driver = {
+		.name = "ocelot-ext-switch",
+		.of_match_table = of_match_ptr(ocelot_ext_switch_of_match),
+	},
+	.probe = ocelot_ext_probe,
+	.remove = ocelot_ext_remove,
+	.shutdown = ocelot_ext_shutdown,
+};
+module_platform_driver(ocelot_ext_switch_driver);
+
+MODULE_DESCRIPTION("External Ocelot Switch driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 61888453f913..ade84e86741e 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -402,6 +402,8 @@ enum ocelot_reg {
 	GCB_MIIM_MII_STATUS,
 	GCB_MIIM_MII_CMD,
 	GCB_MIIM_MII_DATA,
+	GCB_PHY_PHY_CFG,
+	GCB_PHY_PHY_STAT,
 	DEV_CLOCK_CFG = DEV_GMII << TARGET_OFFSET,
 	DEV_PORT_MISC,
 	DEV_EVENTS,
-- 
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] 114+ messages in thread

* [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Add the ability for felix users to announce their capabilities to DSA
switches by way of phylink_get_caps. This will allow those users the
ability to use phylink_generic_validate, which otherwise wouldn't be
possible.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/dsa/ocelot/felix.c | 22 +++++++++++++++-------
 drivers/net/dsa/ocelot/felix.h |  2 ++
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index d09408baaab7..32ed093f47c6 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
 				   struct phylink_config *config)
 {
 	struct ocelot *ocelot = ds->priv;
+	struct felix *felix;
 
-	/* This driver does not make use of the speed, duplex, pause or the
-	 * advertisement in its mac_config, so it is safe to mark this driver
-	 * as non-legacy.
-	 */
-	config->legacy_pre_march2020 = false;
+	felix = ocelot_to_felix(ocelot);
+
+	if (felix->info->phylink_get_caps) {
+		felix->info->phylink_get_caps(ocelot, port, config);
+	} else {
 
-	__set_bit(ocelot->ports[port]->phy_mode,
-		  config->supported_interfaces);
+		/* This driver does not make use of the speed, duplex, pause or
+		 * the advertisement in its mac_config, so it is safe to mark
+		 * this driver as non-legacy.
+		 */
+		config->legacy_pre_march2020 = false;
+
+		__set_bit(ocelot->ports[port]->phy_mode,
+			  config->supported_interfaces);
+	}
 }
 
 static void felix_phylink_validate(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
index 3ecac79bbf09..33281370f415 100644
--- a/drivers/net/dsa/ocelot/felix.h
+++ b/drivers/net/dsa/ocelot/felix.h
@@ -57,6 +57,8 @@ struct felix_info {
 					u32 speed);
 	struct regmap *(*init_regmap)(struct ocelot *ocelot,
 				      struct resource *res);
+	void	(*phylink_get_caps)(struct ocelot *ocelot, int port,
+				    struct phylink_config *pl_config);
 };
 
 extern const struct dsa_switch_ops felix_switch_ops;
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Add the ability for felix users to announce their capabilities to DSA
switches by way of phylink_get_caps. This will allow those users the
ability to use phylink_generic_validate, which otherwise wouldn't be
possible.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/dsa/ocelot/felix.c | 22 +++++++++++++++-------
 drivers/net/dsa/ocelot/felix.h |  2 ++
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index d09408baaab7..32ed093f47c6 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
 				   struct phylink_config *config)
 {
 	struct ocelot *ocelot = ds->priv;
+	struct felix *felix;
 
-	/* This driver does not make use of the speed, duplex, pause or the
-	 * advertisement in its mac_config, so it is safe to mark this driver
-	 * as non-legacy.
-	 */
-	config->legacy_pre_march2020 = false;
+	felix = ocelot_to_felix(ocelot);
+
+	if (felix->info->phylink_get_caps) {
+		felix->info->phylink_get_caps(ocelot, port, config);
+	} else {
 
-	__set_bit(ocelot->ports[port]->phy_mode,
-		  config->supported_interfaces);
+		/* This driver does not make use of the speed, duplex, pause or
+		 * the advertisement in its mac_config, so it is safe to mark
+		 * this driver as non-legacy.
+		 */
+		config->legacy_pre_march2020 = false;
+
+		__set_bit(ocelot->ports[port]->phy_mode,
+			  config->supported_interfaces);
+	}
 }
 
 static void felix_phylink_validate(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
index 3ecac79bbf09..33281370f415 100644
--- a/drivers/net/dsa/ocelot/felix.h
+++ b/drivers/net/dsa/ocelot/felix.h
@@ -57,6 +57,8 @@ struct felix_info {
 					u32 speed);
 	struct regmap *(*init_regmap)(struct ocelot *ocelot,
 				      struct resource *res);
+	void	(*phylink_get_caps)(struct ocelot *ocelot, int port,
+				    struct phylink_config *pl_config);
 };
 
 extern const struct dsa_switch_ops felix_switch_ops;
-- 
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] 114+ messages in thread

* [RFC v8 net-next 16/16] net: dsa: ocelot: utilize phylink_generic_validate
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-08 18:53   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Utilize the phylink_generic_validate function to validate port interfaces
and speeds.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/dsa/ocelot/ocelot_ext.c | 42 ++++++++++++++---------------
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
index ba924f6b8d12..21a85e95c217 100644
--- a/drivers/net/dsa/ocelot/ocelot_ext.c
+++ b/drivers/net/dsa/ocelot/ocelot_ext.c
@@ -215,31 +215,28 @@ static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
 					unsigned long *supported,
 					struct phylink_link_state *state)
 {
-	struct ocelot_port *ocelot_port = ocelot->ports[port];
+	struct felix *felix = ocelot_to_felix(ocelot);
+	struct dsa_switch *ds = felix->ds;
+	struct phylink_config *pl_config;
+	struct dsa_port *dp;
 
-	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+	dp = dsa_to_port(ds, port);
+	pl_config = &dp->pl_config;
 
-	if (state->interface != PHY_INTERFACE_MODE_NA &&
-	    state->interface != ocelot_port->phy_mode) {
-		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
-		return;
-	}
+	phylink_generic_validate(pl_config, supported, state);
+}
+
+static void ocelot_ext_phylink_get_caps(struct ocelot *ocelot, int port,
+					struct phylink_config *pl_config)
+{
+	struct felix *felix = ocelot_to_felix(ocelot);
+
+	if (felix->info->port_modes[port] & OCELOT_PORT_MODE_INTERNAL)
+		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
+			  pl_config->supported_interfaces);
 
-	phylink_set_port_modes(mask);
-
-	phylink_set(mask, Pause);
-	phylink_set(mask, Autoneg);
-	phylink_set(mask, Asym_Pause);
-	phylink_set(mask, 10baseT_Half);
-	phylink_set(mask, 10baseT_Full);
-	phylink_set(mask, 100baseT_Half);
-	phylink_set(mask, 100baseT_Full);
-	phylink_set(mask, 1000baseT_Half);
-	phylink_set(mask, 1000baseT_Full);
-
-	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
-	bitmap_and(state->advertising, state->advertising, mask,
-		   __ETHTOOL_LINK_MODE_MASK_NBITS);
+	pl_config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 |
+				      MAC_100 | MAC_1000FD;
 }
 
 static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
@@ -262,6 +259,7 @@ static const struct felix_info vsc7512_info = {
 	.phylink_validate		= ocelot_ext_phylink_validate,
 	.port_modes			= vsc7512_port_modes,
 	.init_regmap			= ocelot_ext_regmap_init,
+	.phylink_get_caps		= ocelot_ext_phylink_get_caps,
 };
 
 static int ocelot_ext_probe(struct platform_device *pdev)
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 114+ messages in thread

* [RFC v8 net-next 16/16] net: dsa: ocelot: utilize phylink_generic_validate
@ 2022-05-08 18:53   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-08 18:53 UTC (permalink / raw)
  To: linux-arm-kernel, linux-gpio, netdev
  Cc: Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil, Vladimir Oltean, Lee Jones

Utilize the phylink_generic_validate function to validate port interfaces
and speeds.

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/dsa/ocelot/ocelot_ext.c | 42 ++++++++++++++---------------
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
index ba924f6b8d12..21a85e95c217 100644
--- a/drivers/net/dsa/ocelot/ocelot_ext.c
+++ b/drivers/net/dsa/ocelot/ocelot_ext.c
@@ -215,31 +215,28 @@ static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
 					unsigned long *supported,
 					struct phylink_link_state *state)
 {
-	struct ocelot_port *ocelot_port = ocelot->ports[port];
+	struct felix *felix = ocelot_to_felix(ocelot);
+	struct dsa_switch *ds = felix->ds;
+	struct phylink_config *pl_config;
+	struct dsa_port *dp;
 
-	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+	dp = dsa_to_port(ds, port);
+	pl_config = &dp->pl_config;
 
-	if (state->interface != PHY_INTERFACE_MODE_NA &&
-	    state->interface != ocelot_port->phy_mode) {
-		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
-		return;
-	}
+	phylink_generic_validate(pl_config, supported, state);
+}
+
+static void ocelot_ext_phylink_get_caps(struct ocelot *ocelot, int port,
+					struct phylink_config *pl_config)
+{
+	struct felix *felix = ocelot_to_felix(ocelot);
+
+	if (felix->info->port_modes[port] & OCELOT_PORT_MODE_INTERNAL)
+		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
+			  pl_config->supported_interfaces);
 
-	phylink_set_port_modes(mask);
-
-	phylink_set(mask, Pause);
-	phylink_set(mask, Autoneg);
-	phylink_set(mask, Asym_Pause);
-	phylink_set(mask, 10baseT_Half);
-	phylink_set(mask, 10baseT_Full);
-	phylink_set(mask, 100baseT_Half);
-	phylink_set(mask, 100baseT_Full);
-	phylink_set(mask, 1000baseT_Half);
-	phylink_set(mask, 1000baseT_Full);
-
-	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
-	bitmap_and(state->advertising, state->advertising, mask,
-		   __ETHTOOL_LINK_MODE_MASK_NBITS);
+	pl_config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 |
+				      MAC_100 | MAC_1000FD;
 }
 
 static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
@@ -262,6 +259,7 @@ static const struct felix_info vsc7512_info = {
 	.phylink_validate		= ocelot_ext_phylink_validate,
 	.port_modes			= vsc7512_port_modes,
 	.init_regmap			= ocelot_ext_regmap_init,
+	.phylink_get_caps		= ocelot_ext_phylink_get_caps,
 };
 
 static int ocelot_ext_probe(struct platform_device *pdev)
-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 04/16] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-08 21:14     ` Andy Shevchenko
  -1 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-08 21:14 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> There are a few Ocelot chips that contain the logic for this bus, but are
> controlled externally. Specifically the VSC7511, 7512, 7513, and 7514. In
> the externally controlled configurations these registers are not
> memory-mapped.
>
> Add support for these non-memory-mapped configurations.

...

> +               res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> +               if (!res) {
> +                       dev_err(dev, "Unable to get MIIM resource\n");
> +                       return -ENODEV;

return dev_err_probe(...); ?

> +               }

...

> +       if (IS_ERR(phy_regmap)) {
> +               dev_err(dev, "Unable to create phy register regmap\n");
> +               return PTR_ERR(phy_regmap);

Ditto.

>         }

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 04/16] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration
@ 2022-05-08 21:14     ` Andy Shevchenko
  0 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-08 21:14 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> There are a few Ocelot chips that contain the logic for this bus, but are
> controlled externally. Specifically the VSC7511, 7512, 7513, and 7514. In
> the externally controlled configurations these registers are not
> memory-mapped.
>
> Add support for these non-memory-mapped configurations.

...

> +               res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> +               if (!res) {
> +                       dev_err(dev, "Unable to get MIIM resource\n");
> +                       return -ENODEV;

return dev_err_probe(...); ?

> +               }

...

> +       if (IS_ERR(phy_regmap)) {
> +               dev_err(dev, "Unable to create phy register regmap\n");
> +               return PTR_ERR(phy_regmap);

Ditto.

>         }

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 05/16] pinctrl: ocelot: add ability to be used in a non-mmio configuration
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-09  8:37     ` Andy Shevchenko
  -1 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-09  8:37 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> 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.

...

> +#if defined(REG)

Redundant.

> +#undef REG
> +#endif

...

> +               res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> +               if (!res) {
> +                       dev_err(dev, "Failed to get resource\n");
> +                       return -ENODEV;

return dev_err_probe(...); ?

> +               }

...

>         if (IS_ERR(info->map)) {
>                 dev_err(dev, "Failed to create regmap\n");
>                 return PTR_ERR(info->map);

Ditto.

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 05/16] pinctrl: ocelot: add ability to be used in a non-mmio configuration
@ 2022-05-09  8:37     ` Andy Shevchenko
  0 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-09  8:37 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> 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.

...

> +#if defined(REG)

Redundant.

> +#undef REG
> +#endif

...

> +               res = platform_get_resource(pdev, IORESOURCE_REG, 0);
> +               if (!res) {
> +                       dev_err(dev, "Failed to get resource\n");
> +                       return -ENODEV;

return dev_err_probe(...); ?

> +               }

...

>         if (IS_ERR(info->map)) {
>                 dev_err(dev, "Failed to create regmap\n");
>                 return PTR_ERR(info->map);

Ditto.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-09  8:44     ` Andy Shevchenko
  -1 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-09  8:44 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> 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.

...

> -       regs = devm_platform_ioremap_resource(pdev, 0);
> -       if (IS_ERR(regs))
> -               return PTR_ERR(regs);
> +       regs = devm_platform_get_and_ioremap_resource(pdev, 0, 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, 0);
> +               if (!res) {
> +                       dev_err(dev, "Failed to get resource\n");
> +                       return -ENODEV;
> +               }
> +
> +               priv->regs = ocelot_init_regmap_from_resource(dev, res);
> +       } else {
> +               priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
> +       }
>
> -       priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
>         if (IS_ERR(priv->regs))
>                 return PTR_ERR(priv->regs);

This looks like repetition of something you have done in a few
previous patches. Can you avoid code duplication by introducing a
corresponding helper function?

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
@ 2022-05-09  8:44     ` Andy Shevchenko
  0 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-09  8:44 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> 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.

...

> -       regs = devm_platform_ioremap_resource(pdev, 0);
> -       if (IS_ERR(regs))
> -               return PTR_ERR(regs);
> +       regs = devm_platform_get_and_ioremap_resource(pdev, 0, 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, 0);
> +               if (!res) {
> +                       dev_err(dev, "Failed to get resource\n");
> +                       return -ENODEV;
> +               }
> +
> +               priv->regs = ocelot_init_regmap_from_resource(dev, res);
> +       } else {
> +               priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
> +       }
>
> -       priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
>         if (IS_ERR(priv->regs))
>                 return PTR_ERR(priv->regs);

This looks like repetition of something you have done in a few
previous patches. Can you avoid code duplication by introducing a
corresponding helper function?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-09  9:02     ` Andy Shevchenko
  -1 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-09  9:02 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> The VSC7512 is a networking chip that contains several peripherals. Many of
> these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> controlled externally.
>
> Utilize the existing drivers by referencing the chip as an MFD. Add support
> for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.

...

> +         If unsure, say N

Seems like an abrupt sentence.

...

> +EXPORT_SYMBOL(ocelot_chip_reset);

Please, switch to the namespace (_NS) variant of the exported-imported
symbols for these drivers.

...

> +int ocelot_core_init(struct device *dev)
> +{
> +       int ret;
> +
> +       ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> +                                  ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> +       if (ret) {
> +               dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> +               return ret;
> +       }
> +
> +       return 0;

Isn't it simple

  return devm_mfd_add_devices(...);

?

> +}

...

> +#include <linux/of.h>

Do you really use this? (See also below).

...

> +#define VSC7512_CPUORG_RES_START       0x71000000
> +#define VSC7512_CPUORG_RES_SIZE                0x2ff

Doesn't look right.
I'm expecting to see 0x300 here and -1 where it's needed in the code.

...

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

> +       .max_register = 0xffffffff,

Is it for real?! Have you considered what happens if someone actually
tries to read all these registers (and for the record it's not a
theoretical case, since the user may do it via debugfs)?

> +       .use_single_write = true,
> +       .can_multi_write = false,
> +
> +       .reg_format_endian = REGMAP_ENDIAN_BIG,
> +       .val_format_endian = REGMAP_ENDIAN_NATIVE,
> +};

...

> +       if (ddata->spi_padding_bytes > 0) {

' > 0' part is redundant.

> +               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);
> +       }

...

> +       memcpy(&regmap_config, &ocelot_spi_regmap_config,
> +              sizeof(ocelot_spi_regmap_config));

sizeof(regmap_config) is a bit safer (in case somebody changes the
types of the src and dst).

...

> +       err = spi_setup(spi);
> +       if (err < 0) {
> +               dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> +               return err;

return dev_err_probe(...);

> +       }
...

> +       ddata->cpuorg_regmap =
> +               ocelot_spi_devm_init_regmap(dev, dev,
> +                                           &vsc7512_dev_cpuorg_resource);

It's easier to read when it's a longer line. At least the last two can
be on one line.

...

> +       ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> +                                                       &vsc7512_gcb_resource);

Do you have different cases for two first parameters? If not, drop duplication.

...

> +       if (err) {
> +               dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
> +               return err;

return dev_err_probe(...);

And everywhere else where it's appropriate.

> +       }

...

> +const struct of_device_id ocelot_spi_of_match[] = {
> +       { .compatible = "mscc,vsc7512_mfd_spi" },
> +       { },

No comma for terminator entry.

> +};

...

> +               .of_match_table = of_match_ptr(ocelot_spi_of_match),

of_match_ptr() is rather harmful than useful. We have a lot of
compiler warnings due to misuse of this. Besides that it prevents to
use driver in non-OF environments (if it is / will be the case).

...

> +/*
> + * Copyright 2021 Innovative Advantage Inc.
> + */

One line.

...

> +#include <linux/regmap.h>

I don't see the users of this. Use forward declarations (many of them
are actually missed).

Also, seems kconfig.h, err.h and errno.h missed.

> +#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;
> +};

...

> +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> +                                               const struct resource *res);
> +#else
>  static inline struct regmap *
>  ocelot_init_regmap_from_resource(struct device *child,
>                                  const struct resource *res)
>  {
>         return ERR_PTR(-EOPNOTSUPP);
>  }

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-09  9:02     ` Andy Shevchenko
  0 siblings, 0 replies; 114+ messages in thread
From: Andy Shevchenko @ 2022-05-09  9:02 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

On Sun, May 8, 2022 at 8:53 PM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> The VSC7512 is a networking chip that contains several peripherals. Many of
> these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> controlled externally.
>
> Utilize the existing drivers by referencing the chip as an MFD. Add support
> for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.

...

> +         If unsure, say N

Seems like an abrupt sentence.

...

> +EXPORT_SYMBOL(ocelot_chip_reset);

Please, switch to the namespace (_NS) variant of the exported-imported
symbols for these drivers.

...

> +int ocelot_core_init(struct device *dev)
> +{
> +       int ret;
> +
> +       ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> +                                  ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> +       if (ret) {
> +               dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> +               return ret;
> +       }
> +
> +       return 0;

Isn't it simple

  return devm_mfd_add_devices(...);

?

> +}

...

> +#include <linux/of.h>

Do you really use this? (See also below).

...

> +#define VSC7512_CPUORG_RES_START       0x71000000
> +#define VSC7512_CPUORG_RES_SIZE                0x2ff

Doesn't look right.
I'm expecting to see 0x300 here and -1 where it's needed in the code.

...

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

> +       .max_register = 0xffffffff,

Is it for real?! Have you considered what happens if someone actually
tries to read all these registers (and for the record it's not a
theoretical case, since the user may do it via debugfs)?

> +       .use_single_write = true,
> +       .can_multi_write = false,
> +
> +       .reg_format_endian = REGMAP_ENDIAN_BIG,
> +       .val_format_endian = REGMAP_ENDIAN_NATIVE,
> +};

...

> +       if (ddata->spi_padding_bytes > 0) {

' > 0' part is redundant.

> +               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);
> +       }

...

> +       memcpy(&regmap_config, &ocelot_spi_regmap_config,
> +              sizeof(ocelot_spi_regmap_config));

sizeof(regmap_config) is a bit safer (in case somebody changes the
types of the src and dst).

...

> +       err = spi_setup(spi);
> +       if (err < 0) {
> +               dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> +               return err;

return dev_err_probe(...);

> +       }
...

> +       ddata->cpuorg_regmap =
> +               ocelot_spi_devm_init_regmap(dev, dev,
> +                                           &vsc7512_dev_cpuorg_resource);

It's easier to read when it's a longer line. At least the last two can
be on one line.

...

> +       ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> +                                                       &vsc7512_gcb_resource);

Do you have different cases for two first parameters? If not, drop duplication.

...

> +       if (err) {
> +               dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
> +               return err;

return dev_err_probe(...);

And everywhere else where it's appropriate.

> +       }

...

> +const struct of_device_id ocelot_spi_of_match[] = {
> +       { .compatible = "mscc,vsc7512_mfd_spi" },
> +       { },

No comma for terminator entry.

> +};

...

> +               .of_match_table = of_match_ptr(ocelot_spi_of_match),

of_match_ptr() is rather harmful than useful. We have a lot of
compiler warnings due to misuse of this. Besides that it prevents to
use driver in non-OF environments (if it is / will be the case).

...

> +/*
> + * Copyright 2021 Innovative Advantage Inc.
> + */

One line.

...

> +#include <linux/regmap.h>

I don't see the users of this. Use forward declarations (many of them
are actually missed).

Also, seems kconfig.h, err.h and errno.h missed.

> +#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;
> +};

...

> +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> +                                               const struct resource *res);
> +#else
>  static inline struct regmap *
>  ocelot_init_regmap_from_resource(struct device *child,
>                                  const struct resource *res)
>  {
>         return ERR_PTR(-EOPNOTSUPP);
>  }

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 01/16] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
  2022-05-08 18:52   ` Colin Foster
@ 2022-05-09 10:05     ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:05 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:52:58AM -0700, Colin Foster 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.
> 
> 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>
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 01/16] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
@ 2022-05-09 10:05     ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:05 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:52:58AM -0700, Colin Foster 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.
> 
> 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>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 02/16] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
  2022-05-08 18:52   ` Colin Foster
@ 2022-05-09 10:05     ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:05 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:52:59AM -0700, Colin Foster 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.
> 
> 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>
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 02/16] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
@ 2022-05-09 10:05     ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:05 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:52:59AM -0700, Colin Foster 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.
> 
> 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>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-09 10:34     ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:34 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:12AM -0700, Colin Foster wrote:
> Add the ability for felix users to announce their capabilities to DSA
> switches by way of phylink_get_caps. This will allow those users the
> ability to use phylink_generic_validate, which otherwise wouldn't be
> possible.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
>  drivers/net/dsa/ocelot/felix.c | 22 +++++++++++++++-------
>  drivers/net/dsa/ocelot/felix.h |  2 ++
>  2 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
> index d09408baaab7..32ed093f47c6 100644
> --- a/drivers/net/dsa/ocelot/felix.c
> +++ b/drivers/net/dsa/ocelot/felix.c
> @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
>  				   struct phylink_config *config)
>  {
>  	struct ocelot *ocelot = ds->priv;
> +	struct felix *felix;
>  
> -	/* This driver does not make use of the speed, duplex, pause or the
> -	 * advertisement in its mac_config, so it is safe to mark this driver
> -	 * as non-legacy.
> -	 */
> -	config->legacy_pre_march2020 = false;
> +	felix = ocelot_to_felix(ocelot);
> +
> +	if (felix->info->phylink_get_caps) {
> +		felix->info->phylink_get_caps(ocelot, port, config);
> +	} else {
>  
> -	__set_bit(ocelot->ports[port]->phy_mode,
> -		  config->supported_interfaces);
> +		/* This driver does not make use of the speed, duplex, pause or
> +		 * the advertisement in its mac_config, so it is safe to mark
> +		 * this driver as non-legacy.
> +		 */
> +		config->legacy_pre_march2020 = false;

I don't think you mean to set legacy_pre_march2020 to true only
felix->info->phylink_get_caps is absent, do you?

Also, I'm thinking maybe we could provide an implementation of this
function for all switches, not just for vsc7512.

> +
> +		__set_bit(ocelot->ports[port]->phy_mode,
> +			  config->supported_interfaces);
> +	}
>  }
>  
>  static void felix_phylink_validate(struct dsa_switch *ds, int port,
> diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
> index 3ecac79bbf09..33281370f415 100644
> --- a/drivers/net/dsa/ocelot/felix.h
> +++ b/drivers/net/dsa/ocelot/felix.h
> @@ -57,6 +57,8 @@ struct felix_info {
>  					u32 speed);
>  	struct regmap *(*init_regmap)(struct ocelot *ocelot,
>  				      struct resource *res);
> +	void	(*phylink_get_caps)(struct ocelot *ocelot, int port,
> +				    struct phylink_config *pl_config);
>  };
>  
>  extern const struct dsa_switch_ops felix_switch_ops;
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-05-09 10:34     ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:34 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:12AM -0700, Colin Foster wrote:
> Add the ability for felix users to announce their capabilities to DSA
> switches by way of phylink_get_caps. This will allow those users the
> ability to use phylink_generic_validate, which otherwise wouldn't be
> possible.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
>  drivers/net/dsa/ocelot/felix.c | 22 +++++++++++++++-------
>  drivers/net/dsa/ocelot/felix.h |  2 ++
>  2 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
> index d09408baaab7..32ed093f47c6 100644
> --- a/drivers/net/dsa/ocelot/felix.c
> +++ b/drivers/net/dsa/ocelot/felix.c
> @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
>  				   struct phylink_config *config)
>  {
>  	struct ocelot *ocelot = ds->priv;
> +	struct felix *felix;
>  
> -	/* This driver does not make use of the speed, duplex, pause or the
> -	 * advertisement in its mac_config, so it is safe to mark this driver
> -	 * as non-legacy.
> -	 */
> -	config->legacy_pre_march2020 = false;
> +	felix = ocelot_to_felix(ocelot);
> +
> +	if (felix->info->phylink_get_caps) {
> +		felix->info->phylink_get_caps(ocelot, port, config);
> +	} else {
>  
> -	__set_bit(ocelot->ports[port]->phy_mode,
> -		  config->supported_interfaces);
> +		/* This driver does not make use of the speed, duplex, pause or
> +		 * the advertisement in its mac_config, so it is safe to mark
> +		 * this driver as non-legacy.
> +		 */
> +		config->legacy_pre_march2020 = false;

I don't think you mean to set legacy_pre_march2020 to true only
felix->info->phylink_get_caps is absent, do you?

Also, I'm thinking maybe we could provide an implementation of this
function for all switches, not just for vsc7512.

> +
> +		__set_bit(ocelot->ports[port]->phy_mode,
> +			  config->supported_interfaces);
> +	}
>  }
>  
>  static void felix_phylink_validate(struct dsa_switch *ds, int port,
> diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
> index 3ecac79bbf09..33281370f415 100644
> --- a/drivers/net/dsa/ocelot/felix.h
> +++ b/drivers/net/dsa/ocelot/felix.h
> @@ -57,6 +57,8 @@ struct felix_info {
>  					u32 speed);
>  	struct regmap *(*init_regmap)(struct ocelot *ocelot,
>  				      struct resource *res);
> +	void	(*phylink_get_caps)(struct ocelot *ocelot, int port,
> +				    struct phylink_config *pl_config);
>  };
>  
>  extern const struct dsa_switch_ops felix_switch_ops;
> -- 
> 2.25.1
>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-09 10:52     ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:52 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:05AM -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 <colin.foster@in-advantage.com>
> ---
>  drivers/mfd/Kconfig       |  18 +++
>  drivers/mfd/Makefile      |   2 +
>  drivers/mfd/ocelot-core.c | 135 +++++++++++++++++
>  drivers/mfd/ocelot-spi.c  | 311 ++++++++++++++++++++++++++++++++++++++
>  drivers/mfd/ocelot.h      |  34 +++++
>  include/soc/mscc/ocelot.h |   5 +
>  6 files changed, 505 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/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 3b59456f5545..ff177173ca11 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -962,6 +962,24 @@ config MFD_MENF21BMC
>  	  This driver can also be built as a module. If so the module
>  	  will be called menf21bmc.
>  
> +config MFD_OCELOT
> +	tristate "Microsemi Ocelot External Control Support"
> +	depends on SPI_MASTER
> +	select MFD_CORE
> +	select REGMAP_SPI
> +	help
> +	  Ocelot is a family of networking chips that support multiple ethernet
> +	  and fibre interfaces. In addition to networking, they contain several
> +	  other functions, including 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..117028f7d845
> --- /dev/null
> +++ b/drivers/mfd/ocelot-core.c
> @@ -0,0 +1,135 @@
> +// 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/module.h>
> +#include <linux/regmap.h>
> +#include <soc/mscc/ocelot.h>
> +
> +#include <asm/byteorder.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_RES_START	0x710700f8
> +#define VSC7512_SIO_RES_SIZE	0x100
> +
> +int ocelot_chip_reset(struct device *dev)
> +{
> +	struct ocelot_ddata *ddata = dev_get_drvdata(dev);
> +	int ret;
> +
> +	/*
> +	 * 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
> +	 */
> +	ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
> +	if (ret)
> +		return ret;
> +
> +	msleep(100);

Isn't this a bit too long?

> +
> +	return ret;

return 0

> +}
> +EXPORT_SYMBOL(ocelot_chip_reset);
> +
> +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> +						const struct resource *res)
> +{
> +	struct device *dev = child->parent;
> +
> +	return ocelot_spi_devm_init_regmap(dev, child, res);

So much for being bus-agnostic :-/
Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
via a function pointer which is populated by ocelot-spi.c? If you do
that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.

> +}
> +EXPORT_SYMBOL(ocelot_init_regmap_from_resource);
> +
> +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_RES_START, VSC7512_SIO_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",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> +		.resources = vsc7512_miim0_resources,
> +	}, {
> +		.name = "ocelot-miim1",
> +		.of_compatible = "mscc,ocelot-miim",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> +		.resources = vsc7512_miim1_resources,
> +	},
> +};
> +
> +int ocelot_core_init(struct device *dev)
> +{
> +	int ret;
> +
> +	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> +				   ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> +	if (ret) {
> +		dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(ocelot_core_init);
> +
> +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..95754deb0b57
> --- /dev/null
> +++ b/drivers/mfd/ocelot-spi.c
> @@ -0,0 +1,311 @@
> +// 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 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/of.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_CPUORG_RES_START	0x71000000
> +#define VSC7512_CPUORG_RES_SIZE		0x2ff
> +
> +#define VSC7512_GCB_RES_START	0x71070000
> +#define VSC7512_GCB_RES_SIZE	0x14
> +
> +static const struct resource vsc7512_dev_cpuorg_resource =
> +	DEFINE_RES_REG_NAMED(VSC7512_CPUORG_RES_START, VSC7512_CPUORG_RES_SIZE,
> +			     "devcpu_org");
> +
> +static const struct resource vsc7512_gcb_resource =
> +	DEFINE_RES_REG_NAMED(VSC7512_GCB_RES_START, VSC7512_GCB_RES_SIZE,
> +			     "devcpu_gcb_chip_regs");
> +
> +int ocelot_spi_initialize(struct device *dev)

Should be static and unexported.

> +{
> +	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;
> +}
> +EXPORT_SYMBOL(ocelot_spi_initialize);
> +
> +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,
> +
> +	.max_register = 0xffffffff,
> +	.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)
> +{
> +	static const u8 dummy_buf[16] = {0};
> +	struct spi_transfer tx, padding, rx;
> +	struct ocelot_ddata *ddata = context;
> +	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 > 0) {
> +		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_devm_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(&regmap_config, &ocelot_spi_regmap_config,
> +	       sizeof(ocelot_spi_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,
> +				&regmap_config);
> +}
> +
> +static int ocelot_spi_probe(struct spi_device *spi)
> +{
> +	struct device *dev = &spi->dev;
> +	struct ocelot_ddata *ddata;
> +	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) {
> +		dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> +		return err;
> +	}
> +

Personally I'd prefer:

	struct regmap *r;

	r = ocelot_spi_devm_init_regmap(dev, dev,
					&vsc7512_dev_cpuorg_resource);
	if (IS_ERR(r))
		return ERR_PTR(r);

	ddata->cpuorg_regmap = r;

and so on.

> +	ddata->cpuorg_regmap =
> +		ocelot_spi_devm_init_regmap(dev, dev,
> +					    &vsc7512_dev_cpuorg_resource);
> +	if (IS_ERR(ddata->cpuorg_regmap))
> +		return -ENOMEM;
> +
> +	ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> +							&vsc7512_gcb_resource);
> +	if (IS_ERR(ddata->gcb_regmap))
> +		return -ENOMEM;
> +
> +	/*
> +	 * 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) {
> +		dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);

Maybe showing the symbolic value behind the error number would be
helpful?

		dev_err(dev, "Initializing SPI bus returned %pe\n", ERR_PTR(err));

Similar for other places where you print the error using %d, I won't
repeat this comment.

> +		return err;
> +	}
> +
> +	err = ocelot_chip_reset(dev);
> +	if (err) {
> +		dev_err(dev, "Failed to reset device: %d\n", err);
> +		return err;
> +	}
> +
> +	/*
> +	 * 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) {
> +		dev_err(dev,
> +			"Failed to initialize Ocelot SPI bus after reset: %d\n",
> +			err);
> +		return err;
> +	}
> +
> +	err = ocelot_core_init(dev);
> +	if (err < 0) {
> +		dev_err(dev, "Error %d initializing Ocelot core\n", err);
> +		return err;
> +	}
> +
> +	return 0;
> +}
> +
> +const struct of_device_id ocelot_spi_of_match[] = {

static

> +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
> +
> +static struct spi_driver ocelot_spi_driver = {
> +	.driver = {
> +		.name = "ocelot_mfd_spi",
> +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> +	},
> +	.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..b68e6343caca
> --- /dev/null
> +++ b/drivers/mfd/ocelot.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +/*
> + * Copyright 2021 Innovative Advantage Inc.
> + */
> +
> +#include <linux/regmap.h>
> +
> +#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_devm_init_regmap(struct device *dev,
> +					   struct device *child,
> +					   const struct resource *res);
> +int ocelot_spi_initialize(struct device *dev);
> +
> +#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/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> index 1897119ebb9a..f9124a66e386 100644
> --- a/include/soc/mscc/ocelot.h
> +++ b/include/soc/mscc/ocelot.h
> @@ -1039,11 +1039,16 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
>  }
>  #endif
>  
> +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> +						const struct resource *res);
> +#else
>  static inline struct regmap *
>  ocelot_init_regmap_from_resource(struct device *child,
>  				 const struct resource *res)
>  {
>  	return ERR_PTR(-EOPNOTSUPP);
>  }
> +#endif
>  
>  #endif
> -- 
> 2.25.1
>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-09 10:52     ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:52 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:05AM -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 <colin.foster@in-advantage.com>
> ---
>  drivers/mfd/Kconfig       |  18 +++
>  drivers/mfd/Makefile      |   2 +
>  drivers/mfd/ocelot-core.c | 135 +++++++++++++++++
>  drivers/mfd/ocelot-spi.c  | 311 ++++++++++++++++++++++++++++++++++++++
>  drivers/mfd/ocelot.h      |  34 +++++
>  include/soc/mscc/ocelot.h |   5 +
>  6 files changed, 505 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/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 3b59456f5545..ff177173ca11 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -962,6 +962,24 @@ config MFD_MENF21BMC
>  	  This driver can also be built as a module. If so the module
>  	  will be called menf21bmc.
>  
> +config MFD_OCELOT
> +	tristate "Microsemi Ocelot External Control Support"
> +	depends on SPI_MASTER
> +	select MFD_CORE
> +	select REGMAP_SPI
> +	help
> +	  Ocelot is a family of networking chips that support multiple ethernet
> +	  and fibre interfaces. In addition to networking, they contain several
> +	  other functions, including 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..117028f7d845
> --- /dev/null
> +++ b/drivers/mfd/ocelot-core.c
> @@ -0,0 +1,135 @@
> +// 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/module.h>
> +#include <linux/regmap.h>
> +#include <soc/mscc/ocelot.h>
> +
> +#include <asm/byteorder.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_RES_START	0x710700f8
> +#define VSC7512_SIO_RES_SIZE	0x100
> +
> +int ocelot_chip_reset(struct device *dev)
> +{
> +	struct ocelot_ddata *ddata = dev_get_drvdata(dev);
> +	int ret;
> +
> +	/*
> +	 * 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
> +	 */
> +	ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
> +	if (ret)
> +		return ret;
> +
> +	msleep(100);

Isn't this a bit too long?

> +
> +	return ret;

return 0

> +}
> +EXPORT_SYMBOL(ocelot_chip_reset);
> +
> +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> +						const struct resource *res)
> +{
> +	struct device *dev = child->parent;
> +
> +	return ocelot_spi_devm_init_regmap(dev, child, res);

So much for being bus-agnostic :-/
Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
via a function pointer which is populated by ocelot-spi.c? If you do
that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.

> +}
> +EXPORT_SYMBOL(ocelot_init_regmap_from_resource);
> +
> +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_RES_START, VSC7512_SIO_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",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> +		.resources = vsc7512_miim0_resources,
> +	}, {
> +		.name = "ocelot-miim1",
> +		.of_compatible = "mscc,ocelot-miim",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> +		.resources = vsc7512_miim1_resources,
> +	},
> +};
> +
> +int ocelot_core_init(struct device *dev)
> +{
> +	int ret;
> +
> +	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> +				   ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> +	if (ret) {
> +		dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(ocelot_core_init);
> +
> +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..95754deb0b57
> --- /dev/null
> +++ b/drivers/mfd/ocelot-spi.c
> @@ -0,0 +1,311 @@
> +// 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 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/of.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_CPUORG_RES_START	0x71000000
> +#define VSC7512_CPUORG_RES_SIZE		0x2ff
> +
> +#define VSC7512_GCB_RES_START	0x71070000
> +#define VSC7512_GCB_RES_SIZE	0x14
> +
> +static const struct resource vsc7512_dev_cpuorg_resource =
> +	DEFINE_RES_REG_NAMED(VSC7512_CPUORG_RES_START, VSC7512_CPUORG_RES_SIZE,
> +			     "devcpu_org");
> +
> +static const struct resource vsc7512_gcb_resource =
> +	DEFINE_RES_REG_NAMED(VSC7512_GCB_RES_START, VSC7512_GCB_RES_SIZE,
> +			     "devcpu_gcb_chip_regs");
> +
> +int ocelot_spi_initialize(struct device *dev)

Should be static and unexported.

> +{
> +	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;
> +}
> +EXPORT_SYMBOL(ocelot_spi_initialize);
> +
> +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,
> +
> +	.max_register = 0xffffffff,
> +	.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)
> +{
> +	static const u8 dummy_buf[16] = {0};
> +	struct spi_transfer tx, padding, rx;
> +	struct ocelot_ddata *ddata = context;
> +	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 > 0) {
> +		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_devm_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(&regmap_config, &ocelot_spi_regmap_config,
> +	       sizeof(ocelot_spi_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,
> +				&regmap_config);
> +}
> +
> +static int ocelot_spi_probe(struct spi_device *spi)
> +{
> +	struct device *dev = &spi->dev;
> +	struct ocelot_ddata *ddata;
> +	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) {
> +		dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> +		return err;
> +	}
> +

Personally I'd prefer:

	struct regmap *r;

	r = ocelot_spi_devm_init_regmap(dev, dev,
					&vsc7512_dev_cpuorg_resource);
	if (IS_ERR(r))
		return ERR_PTR(r);

	ddata->cpuorg_regmap = r;

and so on.

> +	ddata->cpuorg_regmap =
> +		ocelot_spi_devm_init_regmap(dev, dev,
> +					    &vsc7512_dev_cpuorg_resource);
> +	if (IS_ERR(ddata->cpuorg_regmap))
> +		return -ENOMEM;
> +
> +	ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> +							&vsc7512_gcb_resource);
> +	if (IS_ERR(ddata->gcb_regmap))
> +		return -ENOMEM;
> +
> +	/*
> +	 * 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) {
> +		dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);

Maybe showing the symbolic value behind the error number would be
helpful?

		dev_err(dev, "Initializing SPI bus returned %pe\n", ERR_PTR(err));

Similar for other places where you print the error using %d, I won't
repeat this comment.

> +		return err;
> +	}
> +
> +	err = ocelot_chip_reset(dev);
> +	if (err) {
> +		dev_err(dev, "Failed to reset device: %d\n", err);
> +		return err;
> +	}
> +
> +	/*
> +	 * 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) {
> +		dev_err(dev,
> +			"Failed to initialize Ocelot SPI bus after reset: %d\n",
> +			err);
> +		return err;
> +	}
> +
> +	err = ocelot_core_init(dev);
> +	if (err < 0) {
> +		dev_err(dev, "Error %d initializing Ocelot core\n", err);
> +		return err;
> +	}
> +
> +	return 0;
> +}
> +
> +const struct of_device_id ocelot_spi_of_match[] = {

static

> +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
> +
> +static struct spi_driver ocelot_spi_driver = {
> +	.driver = {
> +		.name = "ocelot_mfd_spi",
> +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> +	},
> +	.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..b68e6343caca
> --- /dev/null
> +++ b/drivers/mfd/ocelot.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +/*
> + * Copyright 2021 Innovative Advantage Inc.
> + */
> +
> +#include <linux/regmap.h>
> +
> +#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_devm_init_regmap(struct device *dev,
> +					   struct device *child,
> +					   const struct resource *res);
> +int ocelot_spi_initialize(struct device *dev);
> +
> +#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/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> index 1897119ebb9a..f9124a66e386 100644
> --- a/include/soc/mscc/ocelot.h
> +++ b/include/soc/mscc/ocelot.h
> @@ -1039,11 +1039,16 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
>  }
>  #endif
>  
> +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> +						const struct resource *res);
> +#else
>  static inline struct regmap *
>  ocelot_init_regmap_from_resource(struct device *child,
>  				 const struct resource *res)
>  {
>  	return ERR_PTR(-EOPNOTSUPP);
>  }
> +#endif
>  
>  #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	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-09 10:56     ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:56 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:08AM -0700, Colin Foster wrote:
> The ocelot_regfields struct is common between several different chips, some
> of which can only be controlled externally. Export this structure so it
> doesn't have to be duplicated in these other drivers.
> 
> Rename the structure as well, to follow the conventions of other shared
> resources.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---

Doesn't the symbol need to be actually _exported_ (EXPORT_SYMBOL) to
work when CONFIG_MSCC_OCELOT_SWITCH_LIB is a module?

>  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 60 +---------------------
>  drivers/net/ethernet/mscc/vsc7514_regs.c   | 59 +++++++++++++++++++++
>  include/soc/mscc/vsc7514_regs.h            |  2 +
>  3 files changed, 62 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> index 68d205088665..a13fec7247d6 100644
> --- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> +++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> @@ -38,64 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
>  	[DEV_GMII] = vsc7514_dev_gmii_regmap,
>  };
>  
> -static const struct reg_field ocelot_regfields[REGFIELD_MAX] = {
> -};
> -
>  static const struct ocelot_stat_layout ocelot_stats_layout[] = {
>  	{ .name = "rx_octets", .offset = 0x00, },
>  	{ .name = "rx_unicast", .offset = 0x01, },
> @@ -231,7 +173,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
>  	ocelot->num_mact_rows = 1024;
>  	ocelot->ops = ops;
>  
> -	ret = ocelot_regfields_init(ocelot, ocelot_regfields);
> +	ret = ocelot_regfields_init(ocelot, vsc7514_regfields);
>  	if (ret)
>  		return ret;
>  
> diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
> index c2af4eb8ca5d..847e64d11075 100644
> --- a/drivers/net/ethernet/mscc/vsc7514_regs.c
> +++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
> @@ -9,6 +9,65 @@
>  #include <soc/mscc/vsc7514_regs.h>
>  #include "ocelot.h"
>  
> +const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
> +};
> +
>  const u32 vsc7514_ana_regmap[] = {
>  	REG(ANA_ADVLEARN,				0x009000),
>  	REG(ANA_VLANMASK,				0x009004),
> diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
> index ceee26c96959..9b40e7d00ec5 100644
> --- a/include/soc/mscc/vsc7514_regs.h
> +++ b/include/soc/mscc/vsc7514_regs.h
> @@ -10,6 +10,8 @@
>  
>  #include <soc/mscc/ocelot_vcap.h>
>  
> +extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
> +
>  extern const u32 vsc7514_ana_regmap[];
>  extern const u32 vsc7514_qs_regmap[];
>  extern const u32 vsc7514_qsys_regmap[];
> -- 
> 2.25.1
>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers
@ 2022-05-09 10:56     ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 10:56 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:08AM -0700, Colin Foster wrote:
> The ocelot_regfields struct is common between several different chips, some
> of which can only be controlled externally. Export this structure so it
> doesn't have to be duplicated in these other drivers.
> 
> Rename the structure as well, to follow the conventions of other shared
> resources.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---

Doesn't the symbol need to be actually _exported_ (EXPORT_SYMBOL) to
work when CONFIG_MSCC_OCELOT_SWITCH_LIB is a module?

>  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 60 +---------------------
>  drivers/net/ethernet/mscc/vsc7514_regs.c   | 59 +++++++++++++++++++++
>  include/soc/mscc/vsc7514_regs.h            |  2 +
>  3 files changed, 62 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> index 68d205088665..a13fec7247d6 100644
> --- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> +++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> @@ -38,64 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
>  	[DEV_GMII] = vsc7514_dev_gmii_regmap,
>  };
>  
> -static const struct reg_field ocelot_regfields[REGFIELD_MAX] = {
> -};
> -
>  static const struct ocelot_stat_layout ocelot_stats_layout[] = {
>  	{ .name = "rx_octets", .offset = 0x00, },
>  	{ .name = "rx_unicast", .offset = 0x01, },
> @@ -231,7 +173,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
>  	ocelot->num_mact_rows = 1024;
>  	ocelot->ops = ops;
>  
> -	ret = ocelot_regfields_init(ocelot, ocelot_regfields);
> +	ret = ocelot_regfields_init(ocelot, vsc7514_regfields);
>  	if (ret)
>  		return ret;
>  
> diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
> index c2af4eb8ca5d..847e64d11075 100644
> --- a/drivers/net/ethernet/mscc/vsc7514_regs.c
> +++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
> @@ -9,6 +9,65 @@
>  #include <soc/mscc/vsc7514_regs.h>
>  #include "ocelot.h"
>  
> +const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
> +};
> +
>  const u32 vsc7514_ana_regmap[] = {
>  	REG(ANA_ADVLEARN,				0x009000),
>  	REG(ANA_VLANMASK,				0x009004),
> diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
> index ceee26c96959..9b40e7d00ec5 100644
> --- a/include/soc/mscc/vsc7514_regs.h
> +++ b/include/soc/mscc/vsc7514_regs.h
> @@ -10,6 +10,8 @@
>  
>  #include <soc/mscc/ocelot_vcap.h>
>  
> +extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
> +
>  extern const u32 vsc7514_ana_regmap[];
>  extern const u32 vsc7514_qs_regmap[];
>  extern const u32 vsc7514_qsys_regmap[];
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-09 16:27     ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 16:27 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:11AM -0700, Colin Foster wrote:
> Add control of an external VSC7512 chip by way of the ocelot-mfd interface.
> 
> Currently the four copper phy ports are fully functional. Communication to
> external phys is also functional, but the SGMII / QSGMII interfaces are
> currently non-functional.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
>  drivers/mfd/ocelot-core.c           |   3 +
>  drivers/net/dsa/ocelot/Kconfig      |  14 ++
>  drivers/net/dsa/ocelot/Makefile     |   5 +
>  drivers/net/dsa/ocelot/ocelot_ext.c | 368 ++++++++++++++++++++++++++++
>  include/soc/mscc/ocelot.h           |   2 +
>  5 files changed, 392 insertions(+)
>  create mode 100644 drivers/net/dsa/ocelot/ocelot_ext.c
> 
> diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
> index 117028f7d845..c582b409a9f3 100644
> --- a/drivers/mfd/ocelot-core.c
> +++ b/drivers/mfd/ocelot-core.c
> @@ -112,6 +112,9 @@ static const struct mfd_cell vsc7512_devs[] = {
>  		.of_compatible = "mscc,ocelot-miim",
>  		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
>  		.resources = vsc7512_miim1_resources,
> +	}, {
> +		.name = "ocelot-ext-switch",
> +		.of_compatible = "mscc,vsc7512-ext-switch",
>  	},
>  };
>  
> diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
> index 220b0b027b55..f40b2c7171ad 100644
> --- a/drivers/net/dsa/ocelot/Kconfig
> +++ b/drivers/net/dsa/ocelot/Kconfig
> @@ -1,4 +1,18 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +config NET_DSA_MSCC_OCELOT_EXT
> +	tristate "Ocelot External Ethernet switch support"
> +	depends on NET_DSA && SPI
> +	depends on NET_VENDOR_MICROSEMI
> +	select MDIO_MSCC_MIIM
> +	select MFD_OCELOT_CORE
> +	select MSCC_OCELOT_SWITCH_LIB
> +	select NET_DSA_TAG_OCELOT_8021Q
> +	select NET_DSA_TAG_OCELOT
> +	help
> +	  This driver supports the VSC7511, VSC7512, VSC7513 and VSC7514 chips
> +	  when controlled through SPI. It can be used with the Microsemi dev
> +	  boards and an external CPU or custom hardware.
> +
>  config NET_DSA_MSCC_FELIX
>  	tristate "Ocelot / Felix Ethernet switch support"
>  	depends on NET_DSA && PCI
> diff --git a/drivers/net/dsa/ocelot/Makefile b/drivers/net/dsa/ocelot/Makefile
> index f6dd131e7491..d7f3f5a4461c 100644
> --- a/drivers/net/dsa/ocelot/Makefile
> +++ b/drivers/net/dsa/ocelot/Makefile
> @@ -1,11 +1,16 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_NET_DSA_MSCC_FELIX) += mscc_felix.o
> +obj-$(CONFIG_NET_DSA_MSCC_OCELOT_EXT) += mscc_ocelot_ext.o
>  obj-$(CONFIG_NET_DSA_MSCC_SEVILLE) += mscc_seville.o
>  
>  mscc_felix-objs := \
>  	felix.o \
>  	felix_vsc9959.o
>  
> +mscc_ocelot_ext-objs := \
> +	felix.o \
> +	ocelot_ext.o
> +
>  mscc_seville-objs := \
>  	felix.o \
>  	seville_vsc9953.o
> diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
> new file mode 100644
> index 000000000000..ba924f6b8d12
> --- /dev/null
> +++ b/drivers/net/dsa/ocelot/ocelot_ext.c
> @@ -0,0 +1,368 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021-2022 Innovative Advantage Inc.
> + */
> +
> +#include <asm/byteorder.h>
> +#include <linux/iopoll.h>
> +#include <linux/kconfig.h>
> +#include <linux/phylink.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <soc/mscc/ocelot_ana.h>
> +#include <soc/mscc/ocelot_dev.h>
> +#include <soc/mscc/ocelot_qsys.h>
> +#include <soc/mscc/ocelot_vcap.h>
> +#include <soc/mscc/ocelot_ptp.h>
> +#include <soc/mscc/ocelot_sys.h>
> +#include <soc/mscc/ocelot.h>
> +#include <soc/mscc/vsc7514_regs.h>
> +#include "felix.h"
> +
> +#define VSC7512_NUM_PORTS		11
> +
> +static const u32 vsc7512_port_modes[VSC7512_NUM_PORTS] = {
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +};
> +
> +static const u32 vsc7512_gcb_regmap[] = {
> +	REG(GCB_SOFT_RST,			0x0008),
> +	REG(GCB_MIIM_MII_STATUS,		0x009c),
> +	REG(GCB_PHY_PHY_CFG,			0x00f0),
> +	REG(GCB_PHY_PHY_STAT,			0x00f4),
> +};
> +
> +static const u32 *vsc7512_regmap[TARGET_MAX] = {
> +	[ANA] = vsc7514_ana_regmap,
> +	[QS] = vsc7514_qs_regmap,
> +	[QSYS] = vsc7514_qsys_regmap,
> +	[REW] = vsc7514_rew_regmap,
> +	[SYS] = vsc7514_sys_regmap,
> +	[S0] = vsc7514_vcap_regmap,
> +	[S1] = vsc7514_vcap_regmap,
> +	[S2] = vsc7514_vcap_regmap,
> +	[PTP] = vsc7514_ptp_regmap,
> +	[GCB] = vsc7512_gcb_regmap,
> +	[DEV_GMII] = vsc7514_dev_gmii_regmap,
> +};
> +
> +static void ocelot_ext_reset_phys(struct ocelot *ocelot)
> +{
> +	ocelot_write(ocelot, 0, GCB_PHY_PHY_CFG);
> +	ocelot_write(ocelot, 0x1ff, GCB_PHY_PHY_CFG);
> +	mdelay(500);
> +}
> +
> +static int ocelot_ext_reset(struct ocelot *ocelot)
> +{
> +	int retries = 100;
> +	int err, val;
> +
> +	ocelot_ext_reset_phys(ocelot);
> +
> +	/* Initialize chip memories */
> +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
> +	if (err)
> +		return err;
> +
> +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
> +	if (err)
> +		return err;
> +
> +	/* MEM_INIT is a self-clearing bit. Wait for it to be clear (should be
> +	 * 100us) before enabling the switch core
> +	 */
> +	do {
> +		msleep(1);
> +		err = regmap_field_read(ocelot->regfields[SYS_RESET_CFG_MEM_INIT],
> +					&val);
> +		if (err)
> +			return err;
> +	} while (val && --retries);

Can you use readx_poll_timeout() here?

> +
> +	if (!retries)
> +		return -ETIMEDOUT;
> +
> +	return regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1);
> +}
> +
> +static const struct ocelot_ops ocelot_ext_ops = {
> +	.reset		= ocelot_ext_reset,
> +	.wm_enc		= ocelot_wm_enc,
> +	.wm_dec		= ocelot_wm_dec,
> +	.wm_stat	= ocelot_wm_stat,
> +	.port_to_netdev	= felix_port_to_netdev,
> +	.netdev_to_port	= felix_netdev_to_port,
> +};
> +
> +static const struct resource vsc7512_target_io_res[TARGET_MAX] = {
> +	[ANA] = {
> +		.start	= 0x71880000,
> +		.end	= 0x7188ffff,
> +		.name	= "ana",
> +	},
> +	[QS] = {
> +		.start	= 0x71080000,
> +		.end	= 0x710800ff,
> +		.name	= "qs",
> +	},
> +	[QSYS] = {
> +		.start	= 0x71800000,
> +		.end	= 0x719fffff,
> +		.name	= "qsys",
> +	},
> +	[REW] = {
> +		.start	= 0x71030000,
> +		.end	= 0x7103ffff,
> +		.name	= "rew",
> +	},
> +	[SYS] = {
> +		.start	= 0x71010000,
> +		.end	= 0x7101ffff,
> +		.name	= "sys",
> +	},
> +	[S0] = {
> +		.start	= 0x71040000,
> +		.end	= 0x710403ff,
> +		.name	= "s0",
> +	},
> +	[S1] = {
> +		.start	= 0x71050000,
> +		.end	= 0x710503ff,
> +		.name	= "s1",
> +	},
> +	[S2] = {
> +		.start	= 0x71060000,
> +		.end	= 0x710603ff,
> +		.name	= "s2",
> +	},
> +	[GCB] =	{
> +		.start	= 0x71070000,
> +		.end	= 0x7107022b,
> +		.name	= "devcpu_gcb",
> +	},
> +};
> +
> +static const struct resource vsc7512_port_io_res[] = {
> +	{
> +		.start	= 0x711e0000,
> +		.end	= 0x711effff,
> +		.name	= "port0",
> +	},
> +	{
> +		.start	= 0x711f0000,
> +		.end	= 0x711fffff,
> +		.name	= "port1",
> +	},
> +	{
> +		.start	= 0x71200000,
> +		.end	= 0x7120ffff,
> +		.name	= "port2",
> +	},
> +	{
> +		.start	= 0x71210000,
> +		.end	= 0x7121ffff,
> +		.name	= "port3",
> +	},
> +	{
> +		.start	= 0x71220000,
> +		.end	= 0x7122ffff,
> +		.name	= "port4",
> +	},
> +	{
> +		.start	= 0x71230000,
> +		.end	= 0x7123ffff,
> +		.name	= "port5",
> +	},
> +	{
> +		.start	= 0x71240000,
> +		.end	= 0x7124ffff,
> +		.name	= "port6",
> +	},
> +	{
> +		.start	= 0x71250000,
> +		.end	= 0x7125ffff,
> +		.name	= "port7",
> +	},
> +	{
> +		.start	= 0x71260000,
> +		.end	= 0x7126ffff,
> +		.name	= "port8",
> +	},
> +	{
> +		.start	= 0x71270000,
> +		.end	= 0x7127ffff,
> +		.name	= "port9",
> +	},
> +	{
> +		.start	= 0x71280000,
> +		.end	= 0x7128ffff,
> +		.name	= "port10",
> +	},
> +};
> +
> +static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
> +					unsigned long *supported,
> +					struct phylink_link_state *state)
> +{
> +	struct ocelot_port *ocelot_port = ocelot->ports[port];
> +
> +	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> +
> +	if (state->interface != PHY_INTERFACE_MODE_NA &&

This check is no longer necessary, please look again at the other
phylink validation functions.

> +	    state->interface != ocelot_port->phy_mode) {

Also, I don't see what is the point of providing one phylink validation
method only to replace it later in the patchset with the generic one.
Please squash "net: dsa: ocelot: utilize phylink_generic_validate" into
this.

> +		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> +		return;
> +	}
> +
> +	phylink_set_port_modes(mask);
> +
> +	phylink_set(mask, Pause);
> +	phylink_set(mask, Autoneg);
> +	phylink_set(mask, Asym_Pause);
> +	phylink_set(mask, 10baseT_Half);
> +	phylink_set(mask, 10baseT_Full);
> +	phylink_set(mask, 100baseT_Half);
> +	phylink_set(mask, 100baseT_Full);
> +	phylink_set(mask, 1000baseT_Half);
> +	phylink_set(mask, 1000baseT_Full);
> +
> +	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
> +	bitmap_and(state->advertising, state->advertising, mask,
> +		   __ETHTOOL_LINK_MODE_MASK_NBITS);
> +}
> +
> +static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
> +					     struct resource *res)
> +{
> +	return ocelot_init_regmap_from_resource(ocelot->dev, res);
> +}
> +
> +static const struct felix_info vsc7512_info = {
> +	.target_io_res			= vsc7512_target_io_res,
> +	.port_io_res			= vsc7512_port_io_res,
> +	.regfields			= vsc7514_regfields,
> +	.map				= vsc7512_regmap,
> +	.ops				= &ocelot_ext_ops,
> +	.stats_layout			= vsc7514_stats_layout,
> +	.vcap				= vsc7514_vcap_props,
> +	.num_mact_rows			= 1024,
> +	.num_ports			= VSC7512_NUM_PORTS,
> +	.num_tx_queues			= OCELOT_NUM_TC,
> +	.phylink_validate		= ocelot_ext_phylink_validate,
> +	.port_modes			= vsc7512_port_modes,
> +	.init_regmap			= ocelot_ext_regmap_init,
> +};
> +
> +static int ocelot_ext_probe(struct platform_device *pdev)
> +{
> +	struct dsa_switch *ds;
> +	struct ocelot *ocelot;
> +	struct felix *felix;
> +	struct device *dev;
> +	int err;
> +
> +	dev = &pdev->dev;

I would prefer if this assignment was part of the variable declaration.

> +
> +	felix = kzalloc(sizeof(*felix), GFP_KERNEL);
> +	if (!felix)
> +		return -ENOMEM;
> +
> +	dev_set_drvdata(dev, felix);
> +
> +	ocelot = &felix->ocelot;
> +	ocelot->dev = dev;
> +
> +	ocelot->num_flooding_pgids = 1;
> +
> +	felix->info = &vsc7512_info;
> +
> +	ds = kzalloc(sizeof(*ds), GFP_KERNEL);
> +	if (!ds) {
> +		err = -ENOMEM;
> +		dev_err(dev, "Failed to allocate DSA switch\n");
> +		goto err_free_felix;
> +	}
> +
> +	ds->dev = dev;
> +	ds->num_ports = felix->info->num_ports;
> +	ds->num_tx_queues = felix->info->num_tx_queues;
> +
> +	ds->ops = &felix_switch_ops;
> +	ds->priv = ocelot;
> +	felix->ds = ds;
> +	felix->tag_proto = DSA_TAG_PROTO_OCELOT;
> +
> +	err = dsa_register_switch(ds);
> +	if (err) {
> +		dev_err(dev, "Failed to register DSA switch: %d\n", err);

dev_err_probe please (look at the other drivers)

> +		goto err_free_ds;
> +	}
> +
> +	return 0;
> +
> +err_free_ds:
> +	kfree(ds);
> +err_free_felix:
> +	kfree(felix);
> +	return err;
> +}
> +
> +static int ocelot_ext_remove(struct platform_device *pdev)
> +{
> +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> +
> +	if (!felix)
> +		return 0;
> +
> +	dsa_unregister_switch(felix->ds);
> +
> +	kfree(felix->ds);
> +	kfree(felix);
> +
> +	dev_set_drvdata(&pdev->dev, NULL);
> +
> +	return 0;
> +}
> +
> +static void ocelot_ext_shutdown(struct platform_device *pdev)
> +{
> +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> +
> +	if (!felix)
> +		return;
> +
> +	dsa_switch_shutdown(felix->ds);
> +
> +	dev_set_drvdata(&pdev->dev, NULL);
> +}
> +
> +const struct of_device_id ocelot_ext_switch_of_match[] = {

static

> +	{ .compatible = "mscc,vsc7512-ext-switch" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);
> +
> +static struct platform_driver ocelot_ext_switch_driver = {
> +	.driver = {
> +		.name = "ocelot-ext-switch",
> +		.of_match_table = of_match_ptr(ocelot_ext_switch_of_match),
> +	},
> +	.probe = ocelot_ext_probe,
> +	.remove = ocelot_ext_remove,
> +	.shutdown = ocelot_ext_shutdown,
> +};
> +module_platform_driver(ocelot_ext_switch_driver);
> +
> +MODULE_DESCRIPTION("External Ocelot Switch driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> index 61888453f913..ade84e86741e 100644
> --- a/include/soc/mscc/ocelot.h
> +++ b/include/soc/mscc/ocelot.h
> @@ -402,6 +402,8 @@ enum ocelot_reg {
>  	GCB_MIIM_MII_STATUS,
>  	GCB_MIIM_MII_CMD,
>  	GCB_MIIM_MII_DATA,
> +	GCB_PHY_PHY_CFG,
> +	GCB_PHY_PHY_STAT,
>  	DEV_CLOCK_CFG = DEV_GMII << TARGET_OFFSET,
>  	DEV_PORT_MISC,
>  	DEV_EVENTS,
> -- 
> 2.25.1
>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control
@ 2022-05-09 16:27     ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 16:27 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:11AM -0700, Colin Foster wrote:
> Add control of an external VSC7512 chip by way of the ocelot-mfd interface.
> 
> Currently the four copper phy ports are fully functional. Communication to
> external phys is also functional, but the SGMII / QSGMII interfaces are
> currently non-functional.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
>  drivers/mfd/ocelot-core.c           |   3 +
>  drivers/net/dsa/ocelot/Kconfig      |  14 ++
>  drivers/net/dsa/ocelot/Makefile     |   5 +
>  drivers/net/dsa/ocelot/ocelot_ext.c | 368 ++++++++++++++++++++++++++++
>  include/soc/mscc/ocelot.h           |   2 +
>  5 files changed, 392 insertions(+)
>  create mode 100644 drivers/net/dsa/ocelot/ocelot_ext.c
> 
> diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
> index 117028f7d845..c582b409a9f3 100644
> --- a/drivers/mfd/ocelot-core.c
> +++ b/drivers/mfd/ocelot-core.c
> @@ -112,6 +112,9 @@ static const struct mfd_cell vsc7512_devs[] = {
>  		.of_compatible = "mscc,ocelot-miim",
>  		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
>  		.resources = vsc7512_miim1_resources,
> +	}, {
> +		.name = "ocelot-ext-switch",
> +		.of_compatible = "mscc,vsc7512-ext-switch",
>  	},
>  };
>  
> diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
> index 220b0b027b55..f40b2c7171ad 100644
> --- a/drivers/net/dsa/ocelot/Kconfig
> +++ b/drivers/net/dsa/ocelot/Kconfig
> @@ -1,4 +1,18 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +config NET_DSA_MSCC_OCELOT_EXT
> +	tristate "Ocelot External Ethernet switch support"
> +	depends on NET_DSA && SPI
> +	depends on NET_VENDOR_MICROSEMI
> +	select MDIO_MSCC_MIIM
> +	select MFD_OCELOT_CORE
> +	select MSCC_OCELOT_SWITCH_LIB
> +	select NET_DSA_TAG_OCELOT_8021Q
> +	select NET_DSA_TAG_OCELOT
> +	help
> +	  This driver supports the VSC7511, VSC7512, VSC7513 and VSC7514 chips
> +	  when controlled through SPI. It can be used with the Microsemi dev
> +	  boards and an external CPU or custom hardware.
> +
>  config NET_DSA_MSCC_FELIX
>  	tristate "Ocelot / Felix Ethernet switch support"
>  	depends on NET_DSA && PCI
> diff --git a/drivers/net/dsa/ocelot/Makefile b/drivers/net/dsa/ocelot/Makefile
> index f6dd131e7491..d7f3f5a4461c 100644
> --- a/drivers/net/dsa/ocelot/Makefile
> +++ b/drivers/net/dsa/ocelot/Makefile
> @@ -1,11 +1,16 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_NET_DSA_MSCC_FELIX) += mscc_felix.o
> +obj-$(CONFIG_NET_DSA_MSCC_OCELOT_EXT) += mscc_ocelot_ext.o
>  obj-$(CONFIG_NET_DSA_MSCC_SEVILLE) += mscc_seville.o
>  
>  mscc_felix-objs := \
>  	felix.o \
>  	felix_vsc9959.o
>  
> +mscc_ocelot_ext-objs := \
> +	felix.o \
> +	ocelot_ext.o
> +
>  mscc_seville-objs := \
>  	felix.o \
>  	seville_vsc9953.o
> diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
> new file mode 100644
> index 000000000000..ba924f6b8d12
> --- /dev/null
> +++ b/drivers/net/dsa/ocelot/ocelot_ext.c
> @@ -0,0 +1,368 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021-2022 Innovative Advantage Inc.
> + */
> +
> +#include <asm/byteorder.h>
> +#include <linux/iopoll.h>
> +#include <linux/kconfig.h>
> +#include <linux/phylink.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <soc/mscc/ocelot_ana.h>
> +#include <soc/mscc/ocelot_dev.h>
> +#include <soc/mscc/ocelot_qsys.h>
> +#include <soc/mscc/ocelot_vcap.h>
> +#include <soc/mscc/ocelot_ptp.h>
> +#include <soc/mscc/ocelot_sys.h>
> +#include <soc/mscc/ocelot.h>
> +#include <soc/mscc/vsc7514_regs.h>
> +#include "felix.h"
> +
> +#define VSC7512_NUM_PORTS		11
> +
> +static const u32 vsc7512_port_modes[VSC7512_NUM_PORTS] = {
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_INTERNAL,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +	OCELOT_PORT_MODE_SGMII,
> +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> +};
> +
> +static const u32 vsc7512_gcb_regmap[] = {
> +	REG(GCB_SOFT_RST,			0x0008),
> +	REG(GCB_MIIM_MII_STATUS,		0x009c),
> +	REG(GCB_PHY_PHY_CFG,			0x00f0),
> +	REG(GCB_PHY_PHY_STAT,			0x00f4),
> +};
> +
> +static const u32 *vsc7512_regmap[TARGET_MAX] = {
> +	[ANA] = vsc7514_ana_regmap,
> +	[QS] = vsc7514_qs_regmap,
> +	[QSYS] = vsc7514_qsys_regmap,
> +	[REW] = vsc7514_rew_regmap,
> +	[SYS] = vsc7514_sys_regmap,
> +	[S0] = vsc7514_vcap_regmap,
> +	[S1] = vsc7514_vcap_regmap,
> +	[S2] = vsc7514_vcap_regmap,
> +	[PTP] = vsc7514_ptp_regmap,
> +	[GCB] = vsc7512_gcb_regmap,
> +	[DEV_GMII] = vsc7514_dev_gmii_regmap,
> +};
> +
> +static void ocelot_ext_reset_phys(struct ocelot *ocelot)
> +{
> +	ocelot_write(ocelot, 0, GCB_PHY_PHY_CFG);
> +	ocelot_write(ocelot, 0x1ff, GCB_PHY_PHY_CFG);
> +	mdelay(500);
> +}
> +
> +static int ocelot_ext_reset(struct ocelot *ocelot)
> +{
> +	int retries = 100;
> +	int err, val;
> +
> +	ocelot_ext_reset_phys(ocelot);
> +
> +	/* Initialize chip memories */
> +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
> +	if (err)
> +		return err;
> +
> +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
> +	if (err)
> +		return err;
> +
> +	/* MEM_INIT is a self-clearing bit. Wait for it to be clear (should be
> +	 * 100us) before enabling the switch core
> +	 */
> +	do {
> +		msleep(1);
> +		err = regmap_field_read(ocelot->regfields[SYS_RESET_CFG_MEM_INIT],
> +					&val);
> +		if (err)
> +			return err;
> +	} while (val && --retries);

Can you use readx_poll_timeout() here?

> +
> +	if (!retries)
> +		return -ETIMEDOUT;
> +
> +	return regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1);
> +}
> +
> +static const struct ocelot_ops ocelot_ext_ops = {
> +	.reset		= ocelot_ext_reset,
> +	.wm_enc		= ocelot_wm_enc,
> +	.wm_dec		= ocelot_wm_dec,
> +	.wm_stat	= ocelot_wm_stat,
> +	.port_to_netdev	= felix_port_to_netdev,
> +	.netdev_to_port	= felix_netdev_to_port,
> +};
> +
> +static const struct resource vsc7512_target_io_res[TARGET_MAX] = {
> +	[ANA] = {
> +		.start	= 0x71880000,
> +		.end	= 0x7188ffff,
> +		.name	= "ana",
> +	},
> +	[QS] = {
> +		.start	= 0x71080000,
> +		.end	= 0x710800ff,
> +		.name	= "qs",
> +	},
> +	[QSYS] = {
> +		.start	= 0x71800000,
> +		.end	= 0x719fffff,
> +		.name	= "qsys",
> +	},
> +	[REW] = {
> +		.start	= 0x71030000,
> +		.end	= 0x7103ffff,
> +		.name	= "rew",
> +	},
> +	[SYS] = {
> +		.start	= 0x71010000,
> +		.end	= 0x7101ffff,
> +		.name	= "sys",
> +	},
> +	[S0] = {
> +		.start	= 0x71040000,
> +		.end	= 0x710403ff,
> +		.name	= "s0",
> +	},
> +	[S1] = {
> +		.start	= 0x71050000,
> +		.end	= 0x710503ff,
> +		.name	= "s1",
> +	},
> +	[S2] = {
> +		.start	= 0x71060000,
> +		.end	= 0x710603ff,
> +		.name	= "s2",
> +	},
> +	[GCB] =	{
> +		.start	= 0x71070000,
> +		.end	= 0x7107022b,
> +		.name	= "devcpu_gcb",
> +	},
> +};
> +
> +static const struct resource vsc7512_port_io_res[] = {
> +	{
> +		.start	= 0x711e0000,
> +		.end	= 0x711effff,
> +		.name	= "port0",
> +	},
> +	{
> +		.start	= 0x711f0000,
> +		.end	= 0x711fffff,
> +		.name	= "port1",
> +	},
> +	{
> +		.start	= 0x71200000,
> +		.end	= 0x7120ffff,
> +		.name	= "port2",
> +	},
> +	{
> +		.start	= 0x71210000,
> +		.end	= 0x7121ffff,
> +		.name	= "port3",
> +	},
> +	{
> +		.start	= 0x71220000,
> +		.end	= 0x7122ffff,
> +		.name	= "port4",
> +	},
> +	{
> +		.start	= 0x71230000,
> +		.end	= 0x7123ffff,
> +		.name	= "port5",
> +	},
> +	{
> +		.start	= 0x71240000,
> +		.end	= 0x7124ffff,
> +		.name	= "port6",
> +	},
> +	{
> +		.start	= 0x71250000,
> +		.end	= 0x7125ffff,
> +		.name	= "port7",
> +	},
> +	{
> +		.start	= 0x71260000,
> +		.end	= 0x7126ffff,
> +		.name	= "port8",
> +	},
> +	{
> +		.start	= 0x71270000,
> +		.end	= 0x7127ffff,
> +		.name	= "port9",
> +	},
> +	{
> +		.start	= 0x71280000,
> +		.end	= 0x7128ffff,
> +		.name	= "port10",
> +	},
> +};
> +
> +static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
> +					unsigned long *supported,
> +					struct phylink_link_state *state)
> +{
> +	struct ocelot_port *ocelot_port = ocelot->ports[port];
> +
> +	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> +
> +	if (state->interface != PHY_INTERFACE_MODE_NA &&

This check is no longer necessary, please look again at the other
phylink validation functions.

> +	    state->interface != ocelot_port->phy_mode) {

Also, I don't see what is the point of providing one phylink validation
method only to replace it later in the patchset with the generic one.
Please squash "net: dsa: ocelot: utilize phylink_generic_validate" into
this.

> +		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> +		return;
> +	}
> +
> +	phylink_set_port_modes(mask);
> +
> +	phylink_set(mask, Pause);
> +	phylink_set(mask, Autoneg);
> +	phylink_set(mask, Asym_Pause);
> +	phylink_set(mask, 10baseT_Half);
> +	phylink_set(mask, 10baseT_Full);
> +	phylink_set(mask, 100baseT_Half);
> +	phylink_set(mask, 100baseT_Full);
> +	phylink_set(mask, 1000baseT_Half);
> +	phylink_set(mask, 1000baseT_Full);
> +
> +	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
> +	bitmap_and(state->advertising, state->advertising, mask,
> +		   __ETHTOOL_LINK_MODE_MASK_NBITS);
> +}
> +
> +static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
> +					     struct resource *res)
> +{
> +	return ocelot_init_regmap_from_resource(ocelot->dev, res);
> +}
> +
> +static const struct felix_info vsc7512_info = {
> +	.target_io_res			= vsc7512_target_io_res,
> +	.port_io_res			= vsc7512_port_io_res,
> +	.regfields			= vsc7514_regfields,
> +	.map				= vsc7512_regmap,
> +	.ops				= &ocelot_ext_ops,
> +	.stats_layout			= vsc7514_stats_layout,
> +	.vcap				= vsc7514_vcap_props,
> +	.num_mact_rows			= 1024,
> +	.num_ports			= VSC7512_NUM_PORTS,
> +	.num_tx_queues			= OCELOT_NUM_TC,
> +	.phylink_validate		= ocelot_ext_phylink_validate,
> +	.port_modes			= vsc7512_port_modes,
> +	.init_regmap			= ocelot_ext_regmap_init,
> +};
> +
> +static int ocelot_ext_probe(struct platform_device *pdev)
> +{
> +	struct dsa_switch *ds;
> +	struct ocelot *ocelot;
> +	struct felix *felix;
> +	struct device *dev;
> +	int err;
> +
> +	dev = &pdev->dev;

I would prefer if this assignment was part of the variable declaration.

> +
> +	felix = kzalloc(sizeof(*felix), GFP_KERNEL);
> +	if (!felix)
> +		return -ENOMEM;
> +
> +	dev_set_drvdata(dev, felix);
> +
> +	ocelot = &felix->ocelot;
> +	ocelot->dev = dev;
> +
> +	ocelot->num_flooding_pgids = 1;
> +
> +	felix->info = &vsc7512_info;
> +
> +	ds = kzalloc(sizeof(*ds), GFP_KERNEL);
> +	if (!ds) {
> +		err = -ENOMEM;
> +		dev_err(dev, "Failed to allocate DSA switch\n");
> +		goto err_free_felix;
> +	}
> +
> +	ds->dev = dev;
> +	ds->num_ports = felix->info->num_ports;
> +	ds->num_tx_queues = felix->info->num_tx_queues;
> +
> +	ds->ops = &felix_switch_ops;
> +	ds->priv = ocelot;
> +	felix->ds = ds;
> +	felix->tag_proto = DSA_TAG_PROTO_OCELOT;
> +
> +	err = dsa_register_switch(ds);
> +	if (err) {
> +		dev_err(dev, "Failed to register DSA switch: %d\n", err);

dev_err_probe please (look at the other drivers)

> +		goto err_free_ds;
> +	}
> +
> +	return 0;
> +
> +err_free_ds:
> +	kfree(ds);
> +err_free_felix:
> +	kfree(felix);
> +	return err;
> +}
> +
> +static int ocelot_ext_remove(struct platform_device *pdev)
> +{
> +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> +
> +	if (!felix)
> +		return 0;
> +
> +	dsa_unregister_switch(felix->ds);
> +
> +	kfree(felix->ds);
> +	kfree(felix);
> +
> +	dev_set_drvdata(&pdev->dev, NULL);
> +
> +	return 0;
> +}
> +
> +static void ocelot_ext_shutdown(struct platform_device *pdev)
> +{
> +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> +
> +	if (!felix)
> +		return;
> +
> +	dsa_switch_shutdown(felix->ds);
> +
> +	dev_set_drvdata(&pdev->dev, NULL);
> +}
> +
> +const struct of_device_id ocelot_ext_switch_of_match[] = {

static

> +	{ .compatible = "mscc,vsc7512-ext-switch" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);
> +
> +static struct platform_driver ocelot_ext_switch_driver = {
> +	.driver = {
> +		.name = "ocelot-ext-switch",
> +		.of_match_table = of_match_ptr(ocelot_ext_switch_of_match),
> +	},
> +	.probe = ocelot_ext_probe,
> +	.remove = ocelot_ext_remove,
> +	.shutdown = ocelot_ext_shutdown,
> +};
> +module_platform_driver(ocelot_ext_switch_driver);
> +
> +MODULE_DESCRIPTION("External Ocelot Switch driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> index 61888453f913..ade84e86741e 100644
> --- a/include/soc/mscc/ocelot.h
> +++ b/include/soc/mscc/ocelot.h
> @@ -402,6 +402,8 @@ enum ocelot_reg {
>  	GCB_MIIM_MII_STATUS,
>  	GCB_MIIM_MII_CMD,
>  	GCB_MIIM_MII_DATA,
> +	GCB_PHY_PHY_CFG,
> +	GCB_PHY_PHY_STAT,
>  	DEV_CLOCK_CFG = DEV_GMII << TARGET_OFFSET,
>  	DEV_PORT_MISC,
>  	DEV_EVENTS,
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-08 18:52 ` Colin Foster
@ 2022-05-09 17:13   ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:13 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Colin,

On Sun, May 08, 2022 at 11:52:57AM -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. The driver is believed to be fully functional for the internal
> phy ports (0-3)  on the VSC7512. It is not yet functional for SGMII,
> QSGMII, and SerDes ports.
> 
> 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.
> 
> The relevant sections of the device tree I'm using for the VSC7512 is
> below. Notably the SGPIO LEDs follow link status and speed from network
> triggers.
> 
> In order to make this work, I have modified the cpsw driver, and now the
> cpsw_new driver, to allow for frames over 1500 bytes. Otherwise the
> tagging protocol will not work between the beaglebone and the VSC7512. I
> plan to eventually try to get those changes in mainline, but I don't
> want to get distracted from my initial goal. I also had to change
> bonecommon.dtsi to avoid using VLAN 0.

This ti,dual-emac-pvid thing is a really odd thing to put in the device
tree. But what's the problem with VLAN 0 anyway?

> 
> I believe much of the MFD sections are very near feature-complete,
> whereas the switch section will require ongoing work to enable
> additional ports / features. This could lead to a couple potential
> scenarios:
> 
> The first being patches 1-8 being split into a separate patch set, while
> patches 9-16 remain in the RFC state. This would offer the pinctrl /
> sgpio / mdio controller functionality, but no switch control until it is
> ready.
> 
> The second would assume the current state of the switch driver is
> acceptable (or at least very near so) and the current patch set gets an
> official PATCH set (with minor changes as necessary - e.g. squashing
> patch 16 into 14). That might be ambitious.
> 
> The third would be to keep this patch set in RFC until switch
> functionality is more complete. I'd understand if this was the desired
> path... but it would mean me having to bug more reviewers.

Considering that the merge window is approaching, I'd say get the
non-DSA stuff accepted until then, then repost the DSA stuff in ~3 weeks
from now as non-RFC, once v5.18 is cut and the development for v5.20
(or whatever the number will be) begins.

> / {
> 	vscleds {
> 		compatible = "gpio-leds";
> 		vscled@0 {
> 			label = "port0led";
> 			gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
> 			default-state = "off";
> 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:link";
> 		};
> 		vscled@1 {
> 			label = "port0led1";
> 			gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
> 			default-state = "off";
> 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:1Gbps";
> 		};
> [ ... ]
> 	};
> };
> 
> &spi0 {
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> 	status = "okay";
> 
> 	ocelot-chip@0 {
> 		compatible = "mscc,vsc7512_mfd_spi";

Can you use hyphens instead of underscores in this compatible string?

> 		spi-max-frequency = <2500000>;
> 		reg = <0>;
> 
> 		ethernet-switch@0 {

I don't think the switch node should have any address?

> 			compatible = "mscc,vsc7512-ext-switch";
> 			ports {
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
> 				port@0 {
> 					reg = <0>;
> 					label = "cpu";
> 					status = "okay";
> 					ethernet = <&mac_sw>;
> 					phy-handle = <&sw_phy0>;
> 					phy-mode = "internal";
> 				};
> 
> 				port@1 {
> 					reg = <1>;
> 					label = "swp1";
> 					status = "okay";
> 					phy-handle = <&sw_phy1>;
> 					phy-mode = "internal";
> 				};
> 			};
> 		};
> 
> 		mdio0: mdio0@0 {

This is going to be interesting. Some drivers with multiple MDIO buses
create an "mdios" container with #address-cells = <1> and put the MDIO
bus nodes under that. Others create an "mdio" node and an "mdio0" node
(and no address for either of them).

The problem with the latter approach is that
Documentation/devicetree/bindings/net/mdio.yaml does not accept the
"mdio0"/"mdio1" node name for an MDIO bus.

> 			compatible = "mscc,ocelot-miim";
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			sw_phy0: ethernet-phy@0 {
> 				reg = <0x0>;
> 			};
> 
> 			sw_phy1: ethernet-phy@1 {
> 				reg = <0x1>;
> 			};
> 
> 			sw_phy2: ethernet-phy@2 {
> 				reg = <0x2>;
> 			};
> 
> 			sw_phy3: ethernet-phy@3 {
> 				reg = <0x3>;
> 			};
> 		};
> 
> 		mdio1: mdio1@1 {
> 			compatible = "mscc,ocelot-miim";
> 			pinctrl-names = "default";
> 			pinctrl-0 = <&miim1>;
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			sw_phy4: ethernet-phy@4 {
> 				reg = <0x4>;
> 			};
> 
> 			sw_phy5: ethernet-phy@5 {
> 				reg = <0x5>;
> 			};
> 
> 			sw_phy6: ethernet-phy@6 {
> 				reg = <0x6>;
> 			};
> 
> 			sw_phy7: ethernet-phy@7 {
> 				reg = <0x7>;
> 			};
> 		};
> 
> 		gpio: pinctrl@0 {

Similar thing with the address. All these @0 addresses actually conflict
with each other.

> 			compatible = "mscc,ocelot-pinctrl";
> 			gpio-controller;
> 			#gpio_cells = <2>;
> 			gpio-ranges = <&gpio 0 0 22>;
> 
> 			led_shift_reg_pins: led-shift-reg-pins {
> 				pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
> 				function = "sg0";
> 			};
> 
> 			miim1: miim1 {
> 				pins = "GPIO_14", "GPIO_15";
> 				function = "miim";
> 			};
> 		};
> 
> 		sgpio: sgpio {

And mixing nodes with addresses with nodes without addresses is broken too.

> 			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 = <&led_shift_reg_pins>;
> 
> 			sgpio_in0: sgpio@0 {
> 				compatible = "microchip,sparx5-sgpio-bank";
> 				reg = <0>;
> 				gpio-controller;
> 				#gpio-cells = <3>;
> 				ngpios = <64>;
> 			};
> 
> 			sgpio_out1: sgpio@1 {
> 				compatible = "microchip,sparx5-sgpio-bank";
> 				reg = <1>;
> 				gpio-controller;
> 				#gpio-cells = <3>;
> 				ngpios = <64>;
> 			};
> 		};
> 	};
> };
> 
> 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.
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.18.0-rc5-01295-g47053e327c52 (X@X) (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #630 SMP PREEMPT Sun May 8 10:56:51 PDT 2022
> ...
> [    2.829319] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set

Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?

> [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> [    2.842717] gpiochip_find_base: found new base at 2026
> [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> [    2.870801] gpiochip_find_base: found new base at 1962
> [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> [    2.872364] gpiochip_find_base: found new base at 1898
> [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
> [    2.886929] mscc-miim ocelot-miim0.2.auto: invalid resource
> [    2.893738] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
> [    2.893769] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
> [    2.893802] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> [    2.893898] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> [    2.893996] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
> [    2.894012] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
> [    3.395738] mdio_bus ocelot-miim0.2.auto-mii:00: GPIO lookup for consumer reset
> [    3.395777] mdio_bus ocelot-miim0.2.auto-mii:00: using device tree for GPIO lookup
> [    3.395840] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> [    3.395959] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> [    3.396069] mdio_bus ocelot-miim0.2.auto-mii:00: using lookup tables for GPIO lookup
> [    3.396086] mdio_bus ocelot-miim0.2.auto-mii:00: No GPIO consumer reset found
> ...
> [    3.449187] ocelot-ext-switch ocelot-ext-switch.4.auto: DMA mask not set
> [    5.336880] ocelot-ext-switch ocelot-ext-switch.4.auto: PHY [ocelot-miim0.2.auto-mii:00] driver [Generic PHY] (irq=POLL)
> [    5.349087] ocelot-ext-switch ocelot-ext-switch.4.auto: configuring for phy/internal link mode
> [    5.363619] ocelot-ext-switch ocelot-ext-switch.4.auto swp1 (uninitialized): PHY [ocelot-miim0.2.auto-mii:01] driver [Generic PHY] (irq=POLL)
> [    5.381396] ocelot-ext-switch ocelot-ext-switch.4.auto swp2 (uninitialized): PHY [ocelot-miim0.2.auto-mii:02] driver [Generic PHY] (irq=POLL)
> [    5.398525] ocelot-ext-switch ocelot-ext-switch.4.auto swp3 (uninitialized): PHY [ocelot-miim0.2.auto-mii:03] driver [Generic PHY] (irq=POLL)

Do the PHYs not have a specific driver?

> [    5.422048] device eth0 entered promiscuous mode
> [    5.426785] DSA: tree 0 setup
> ...
> [    7.450067] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> [   21.556395] cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
> [   21.648564] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
> [   21.667970] 8021q: adding VLAN 0 to HW filter on device eth0
> [   21.705360] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: configuring for phy/internal link mode
> [   22.018230] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Down
> [   23.771740] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
> [   24.090929] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> [   25.853021] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: Link is Up - 1Gbps/Full - flow control rx/tx
> 
> 
> 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

bus -> bulk?

>       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
> 
> 
> Colin Foster (16):
>   pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
>   pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
>   net: ocelot: add interface to get regmaps when exernally controlled
>   net: mdio: mscc-miim: add ability to be used in a non-mmio
>     configuration
>   pinctrl: ocelot: add ability to be used in a non-mmio configuration
>   pinctrl: microchip-sgpio: add ability to be used in a non-mmio
>     configuration
>   resource: add define macro for register address resources
>   mfd: ocelot: add support for the vsc7512 chip via spi
>   net: mscc: ocelot: expose ocelot wm functions
>   net: dsa: felix: add configurable device quirks
>   net: mscc: ocelot: expose regfield definition to be used by other
>     drivers
>   net: mscc: ocelot: expose stats layout definition to be used by other
>     drivers
>   net: mscc: ocelot: expose vcap_props structure
>   net: dsa: ocelot: add external ocelot switch control
>   net: dsa: felix: add phylink_get_caps capability
>   net: dsa: ocelot: utilize phylink_generic_validate
> 
>  drivers/mfd/Kconfig                        |  18 +
>  drivers/mfd/Makefile                       |   2 +
>  drivers/mfd/ocelot-core.c                  | 138 ++++++++
>  drivers/mfd/ocelot-spi.c                   | 311 +++++++++++++++++
>  drivers/mfd/ocelot.h                       |  34 ++
>  drivers/net/dsa/ocelot/Kconfig             |  14 +
>  drivers/net/dsa/ocelot/Makefile            |   5 +
>  drivers/net/dsa/ocelot/felix.c             |  29 +-
>  drivers/net/dsa/ocelot/felix.h             |   3 +
>  drivers/net/dsa/ocelot/felix_vsc9959.c     |   1 +
>  drivers/net/dsa/ocelot/ocelot_ext.c        | 366 +++++++++++++++++++++
>  drivers/net/dsa/ocelot/seville_vsc9953.c   |   1 +
>  drivers/net/ethernet/mscc/ocelot_devlink.c |  31 ++
>  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 230 +------------
>  drivers/net/ethernet/mscc/vsc7514_regs.c   | 200 +++++++++++
>  drivers/net/mdio/mdio-mscc-miim.c          |  31 +-
>  drivers/pinctrl/Kconfig                    |   4 +-
>  drivers/pinctrl/pinctrl-microchip-sgpio.c  |  26 +-
>  drivers/pinctrl/pinctrl-ocelot.c           |  35 +-
>  include/linux/ioport.h                     |   5 +
>  include/soc/mscc/ocelot.h                  |  19 ++
>  include/soc/mscc/vsc7514_regs.h            |   6 +
>  22 files changed, 1251 insertions(+), 258 deletions(-)
>  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 drivers/net/dsa/ocelot/ocelot_ext.c
> 
> -- 
> 2.25.1
>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-09 17:13   ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:13 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Colin,

On Sun, May 08, 2022 at 11:52:57AM -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. The driver is believed to be fully functional for the internal
> phy ports (0-3)  on the VSC7512. It is not yet functional for SGMII,
> QSGMII, and SerDes ports.
> 
> 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.
> 
> The relevant sections of the device tree I'm using for the VSC7512 is
> below. Notably the SGPIO LEDs follow link status and speed from network
> triggers.
> 
> In order to make this work, I have modified the cpsw driver, and now the
> cpsw_new driver, to allow for frames over 1500 bytes. Otherwise the
> tagging protocol will not work between the beaglebone and the VSC7512. I
> plan to eventually try to get those changes in mainline, but I don't
> want to get distracted from my initial goal. I also had to change
> bonecommon.dtsi to avoid using VLAN 0.

This ti,dual-emac-pvid thing is a really odd thing to put in the device
tree. But what's the problem with VLAN 0 anyway?

> 
> I believe much of the MFD sections are very near feature-complete,
> whereas the switch section will require ongoing work to enable
> additional ports / features. This could lead to a couple potential
> scenarios:
> 
> The first being patches 1-8 being split into a separate patch set, while
> patches 9-16 remain in the RFC state. This would offer the pinctrl /
> sgpio / mdio controller functionality, but no switch control until it is
> ready.
> 
> The second would assume the current state of the switch driver is
> acceptable (or at least very near so) and the current patch set gets an
> official PATCH set (with minor changes as necessary - e.g. squashing
> patch 16 into 14). That might be ambitious.
> 
> The third would be to keep this patch set in RFC until switch
> functionality is more complete. I'd understand if this was the desired
> path... but it would mean me having to bug more reviewers.

Considering that the merge window is approaching, I'd say get the
non-DSA stuff accepted until then, then repost the DSA stuff in ~3 weeks
from now as non-RFC, once v5.18 is cut and the development for v5.20
(or whatever the number will be) begins.

> / {
> 	vscleds {
> 		compatible = "gpio-leds";
> 		vscled@0 {
> 			label = "port0led";
> 			gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
> 			default-state = "off";
> 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:link";
> 		};
> 		vscled@1 {
> 			label = "port0led1";
> 			gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
> 			default-state = "off";
> 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:1Gbps";
> 		};
> [ ... ]
> 	};
> };
> 
> &spi0 {
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> 	status = "okay";
> 
> 	ocelot-chip@0 {
> 		compatible = "mscc,vsc7512_mfd_spi";

Can you use hyphens instead of underscores in this compatible string?

> 		spi-max-frequency = <2500000>;
> 		reg = <0>;
> 
> 		ethernet-switch@0 {

I don't think the switch node should have any address?

> 			compatible = "mscc,vsc7512-ext-switch";
> 			ports {
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
> 				port@0 {
> 					reg = <0>;
> 					label = "cpu";
> 					status = "okay";
> 					ethernet = <&mac_sw>;
> 					phy-handle = <&sw_phy0>;
> 					phy-mode = "internal";
> 				};
> 
> 				port@1 {
> 					reg = <1>;
> 					label = "swp1";
> 					status = "okay";
> 					phy-handle = <&sw_phy1>;
> 					phy-mode = "internal";
> 				};
> 			};
> 		};
> 
> 		mdio0: mdio0@0 {

This is going to be interesting. Some drivers with multiple MDIO buses
create an "mdios" container with #address-cells = <1> and put the MDIO
bus nodes under that. Others create an "mdio" node and an "mdio0" node
(and no address for either of them).

The problem with the latter approach is that
Documentation/devicetree/bindings/net/mdio.yaml does not accept the
"mdio0"/"mdio1" node name for an MDIO bus.

> 			compatible = "mscc,ocelot-miim";
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			sw_phy0: ethernet-phy@0 {
> 				reg = <0x0>;
> 			};
> 
> 			sw_phy1: ethernet-phy@1 {
> 				reg = <0x1>;
> 			};
> 
> 			sw_phy2: ethernet-phy@2 {
> 				reg = <0x2>;
> 			};
> 
> 			sw_phy3: ethernet-phy@3 {
> 				reg = <0x3>;
> 			};
> 		};
> 
> 		mdio1: mdio1@1 {
> 			compatible = "mscc,ocelot-miim";
> 			pinctrl-names = "default";
> 			pinctrl-0 = <&miim1>;
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			sw_phy4: ethernet-phy@4 {
> 				reg = <0x4>;
> 			};
> 
> 			sw_phy5: ethernet-phy@5 {
> 				reg = <0x5>;
> 			};
> 
> 			sw_phy6: ethernet-phy@6 {
> 				reg = <0x6>;
> 			};
> 
> 			sw_phy7: ethernet-phy@7 {
> 				reg = <0x7>;
> 			};
> 		};
> 
> 		gpio: pinctrl@0 {

Similar thing with the address. All these @0 addresses actually conflict
with each other.

> 			compatible = "mscc,ocelot-pinctrl";
> 			gpio-controller;
> 			#gpio_cells = <2>;
> 			gpio-ranges = <&gpio 0 0 22>;
> 
> 			led_shift_reg_pins: led-shift-reg-pins {
> 				pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
> 				function = "sg0";
> 			};
> 
> 			miim1: miim1 {
> 				pins = "GPIO_14", "GPIO_15";
> 				function = "miim";
> 			};
> 		};
> 
> 		sgpio: sgpio {

And mixing nodes with addresses with nodes without addresses is broken too.

> 			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 = <&led_shift_reg_pins>;
> 
> 			sgpio_in0: sgpio@0 {
> 				compatible = "microchip,sparx5-sgpio-bank";
> 				reg = <0>;
> 				gpio-controller;
> 				#gpio-cells = <3>;
> 				ngpios = <64>;
> 			};
> 
> 			sgpio_out1: sgpio@1 {
> 				compatible = "microchip,sparx5-sgpio-bank";
> 				reg = <1>;
> 				gpio-controller;
> 				#gpio-cells = <3>;
> 				ngpios = <64>;
> 			};
> 		};
> 	};
> };
> 
> 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.
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.18.0-rc5-01295-g47053e327c52 (X@X) (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #630 SMP PREEMPT Sun May 8 10:56:51 PDT 2022
> ...
> [    2.829319] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set

Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?

> [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> [    2.842717] gpiochip_find_base: found new base at 2026
> [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> [    2.870801] gpiochip_find_base: found new base at 1962
> [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> [    2.872364] gpiochip_find_base: found new base at 1898
> [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
> [    2.886929] mscc-miim ocelot-miim0.2.auto: invalid resource
> [    2.893738] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
> [    2.893769] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
> [    2.893802] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> [    2.893898] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> [    2.893996] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
> [    2.894012] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
> [    3.395738] mdio_bus ocelot-miim0.2.auto-mii:00: GPIO lookup for consumer reset
> [    3.395777] mdio_bus ocelot-miim0.2.auto-mii:00: using device tree for GPIO lookup
> [    3.395840] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> [    3.395959] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> [    3.396069] mdio_bus ocelot-miim0.2.auto-mii:00: using lookup tables for GPIO lookup
> [    3.396086] mdio_bus ocelot-miim0.2.auto-mii:00: No GPIO consumer reset found
> ...
> [    3.449187] ocelot-ext-switch ocelot-ext-switch.4.auto: DMA mask not set
> [    5.336880] ocelot-ext-switch ocelot-ext-switch.4.auto: PHY [ocelot-miim0.2.auto-mii:00] driver [Generic PHY] (irq=POLL)
> [    5.349087] ocelot-ext-switch ocelot-ext-switch.4.auto: configuring for phy/internal link mode
> [    5.363619] ocelot-ext-switch ocelot-ext-switch.4.auto swp1 (uninitialized): PHY [ocelot-miim0.2.auto-mii:01] driver [Generic PHY] (irq=POLL)
> [    5.381396] ocelot-ext-switch ocelot-ext-switch.4.auto swp2 (uninitialized): PHY [ocelot-miim0.2.auto-mii:02] driver [Generic PHY] (irq=POLL)
> [    5.398525] ocelot-ext-switch ocelot-ext-switch.4.auto swp3 (uninitialized): PHY [ocelot-miim0.2.auto-mii:03] driver [Generic PHY] (irq=POLL)

Do the PHYs not have a specific driver?

> [    5.422048] device eth0 entered promiscuous mode
> [    5.426785] DSA: tree 0 setup
> ...
> [    7.450067] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> [   21.556395] cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
> [   21.648564] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
> [   21.667970] 8021q: adding VLAN 0 to HW filter on device eth0
> [   21.705360] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: configuring for phy/internal link mode
> [   22.018230] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Down
> [   23.771740] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
> [   24.090929] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> [   25.853021] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: Link is Up - 1Gbps/Full - flow control rx/tx
> 
> 
> 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

bus -> bulk?

>       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
> 
> 
> Colin Foster (16):
>   pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
>   pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
>   net: ocelot: add interface to get regmaps when exernally controlled
>   net: mdio: mscc-miim: add ability to be used in a non-mmio
>     configuration
>   pinctrl: ocelot: add ability to be used in a non-mmio configuration
>   pinctrl: microchip-sgpio: add ability to be used in a non-mmio
>     configuration
>   resource: add define macro for register address resources
>   mfd: ocelot: add support for the vsc7512 chip via spi
>   net: mscc: ocelot: expose ocelot wm functions
>   net: dsa: felix: add configurable device quirks
>   net: mscc: ocelot: expose regfield definition to be used by other
>     drivers
>   net: mscc: ocelot: expose stats layout definition to be used by other
>     drivers
>   net: mscc: ocelot: expose vcap_props structure
>   net: dsa: ocelot: add external ocelot switch control
>   net: dsa: felix: add phylink_get_caps capability
>   net: dsa: ocelot: utilize phylink_generic_validate
> 
>  drivers/mfd/Kconfig                        |  18 +
>  drivers/mfd/Makefile                       |   2 +
>  drivers/mfd/ocelot-core.c                  | 138 ++++++++
>  drivers/mfd/ocelot-spi.c                   | 311 +++++++++++++++++
>  drivers/mfd/ocelot.h                       |  34 ++
>  drivers/net/dsa/ocelot/Kconfig             |  14 +
>  drivers/net/dsa/ocelot/Makefile            |   5 +
>  drivers/net/dsa/ocelot/felix.c             |  29 +-
>  drivers/net/dsa/ocelot/felix.h             |   3 +
>  drivers/net/dsa/ocelot/felix_vsc9959.c     |   1 +
>  drivers/net/dsa/ocelot/ocelot_ext.c        | 366 +++++++++++++++++++++
>  drivers/net/dsa/ocelot/seville_vsc9953.c   |   1 +
>  drivers/net/ethernet/mscc/ocelot_devlink.c |  31 ++
>  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 230 +------------
>  drivers/net/ethernet/mscc/vsc7514_regs.c   | 200 +++++++++++
>  drivers/net/mdio/mdio-mscc-miim.c          |  31 +-
>  drivers/pinctrl/Kconfig                    |   4 +-
>  drivers/pinctrl/pinctrl-microchip-sgpio.c  |  26 +-
>  drivers/pinctrl/pinctrl-ocelot.c           |  35 +-
>  include/linux/ioport.h                     |   5 +
>  include/soc/mscc/ocelot.h                  |  19 ++
>  include/soc/mscc/vsc7514_regs.h            |   6 +
>  22 files changed, 1251 insertions(+), 258 deletions(-)
>  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 drivers/net/dsa/ocelot/ocelot_ext.c
> 
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-09 23:49       ` Colin Foster
@ 2022-05-09 17:20         ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:20 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > +						const struct resource *res)
> > > +{
> > > +	struct device *dev = child->parent;
> > > +
> > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > 
> > So much for being bus-agnostic :-/
> > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > via a function pointer which is populated by ocelot-spi.c? If you do
> > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> 
> That was my initial design. "core" was calling into "spi" exclusively
> via function pointers.
> 
> The request was "Please find a clearer way to do this without function
> pointers"
> 
> https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/

Yeah, I'm not sure what Lee was looking for, either. In any case I agree
with the comment that you aren't configuring a bus. In this context it
seems more appropriate to call this function pointer "init_regmap", with
different implementations per transport.

Or alternatively you could leave the "core"/"spi" pseudo-separation up
to the next person who needs to add support for some other register I/O
method.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-09 17:20         ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:20 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > +						const struct resource *res)
> > > +{
> > > +	struct device *dev = child->parent;
> > > +
> > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > 
> > So much for being bus-agnostic :-/
> > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > via a function pointer which is populated by ocelot-spi.c? If you do
> > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> 
> That was my initial design. "core" was calling into "spi" exclusively
> via function pointers.
> 
> The request was "Please find a clearer way to do this without function
> pointers"
> 
> https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/

Yeah, I'm not sure what Lee was looking for, either. In any case I agree
with the comment that you aren't configuring a bus. In this context it
seems more appropriate to call this function pointer "init_regmap", with
different implementations per transport.

Or alternatively you could leave the "core"/"spi" pseudo-separation up
to the next person who needs to add support for some other register I/O
method.
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-05-10  0:23       ` Colin Foster
@ 2022-05-09 17:30         ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:30 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:23:32PM -0700, Colin Foster wrote:
> > > @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
> > >  				   struct phylink_config *config)
> > >  {
> > >  	struct ocelot *ocelot = ds->priv;
> > > +	struct felix *felix;
> > >  
> > > -	/* This driver does not make use of the speed, duplex, pause or the
> > > -	 * advertisement in its mac_config, so it is safe to mark this driver
> > > -	 * as non-legacy.
> > > -	 */
> > > -	config->legacy_pre_march2020 = false;
> > > +	felix = ocelot_to_felix(ocelot);
> > > +
> > > +	if (felix->info->phylink_get_caps) {
> > > +		felix->info->phylink_get_caps(ocelot, port, config);
> > > +	} else {
> > >  
> > > -	__set_bit(ocelot->ports[port]->phy_mode,
> > > -		  config->supported_interfaces);
> > > +		/* This driver does not make use of the speed, duplex, pause or
> > > +		 * the advertisement in its mac_config, so it is safe to mark
> > > +		 * this driver as non-legacy.
> > > +		 */
> > > +		config->legacy_pre_march2020 = false;
> > 
> > I don't think you mean to set legacy_pre_march2020 to true only
> > felix->info->phylink_get_caps is absent, do you?
> > 
> > Also, I'm thinking maybe we could provide an implementation of this
> > function for all switches, not just for vsc7512.
> 
> I had assumed these last two patches might spark more discussion, which
> is why I kept them separate (specifically the last patch).
> 
> With this, are you simply suggesting to take everything that is
> currently in felix_phylink_get_caps and doing it in the felix / seville
> implementations? This is because the default condition is no longer the
> "only" condition. Sounds easy enough.

No, not everything, just the way in which config->supported_interfaces
is populated. We have different PCS implementations, so it's likely that
the procedures to retrieve the valid SERDES protocols (when changing
them will be supported) are different.

But in fact I seriously doubt that the current way in which supported_interfaces
gets populated is limiting you from doing anything right now, precisely
because you don't have any code that supports changing the phy-mode.

Also, it's unlikely (I'd say impossible) for one driver to be
unconverted to the post-March-2020 requirements and the other not to be.
The simple reason is that they share the same mac_config implementation.
So it's perfectly ok to keep "config->legacy_pre_march2020 = false"
right where it is.

So I'd say it's up to you, but I'd drop this patch right now.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-05-09 17:30         ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:30 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:23:32PM -0700, Colin Foster wrote:
> > > @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
> > >  				   struct phylink_config *config)
> > >  {
> > >  	struct ocelot *ocelot = ds->priv;
> > > +	struct felix *felix;
> > >  
> > > -	/* This driver does not make use of the speed, duplex, pause or the
> > > -	 * advertisement in its mac_config, so it is safe to mark this driver
> > > -	 * as non-legacy.
> > > -	 */
> > > -	config->legacy_pre_march2020 = false;
> > > +	felix = ocelot_to_felix(ocelot);
> > > +
> > > +	if (felix->info->phylink_get_caps) {
> > > +		felix->info->phylink_get_caps(ocelot, port, config);
> > > +	} else {
> > >  
> > > -	__set_bit(ocelot->ports[port]->phy_mode,
> > > -		  config->supported_interfaces);
> > > +		/* This driver does not make use of the speed, duplex, pause or
> > > +		 * the advertisement in its mac_config, so it is safe to mark
> > > +		 * this driver as non-legacy.
> > > +		 */
> > > +		config->legacy_pre_march2020 = false;
> > 
> > I don't think you mean to set legacy_pre_march2020 to true only
> > felix->info->phylink_get_caps is absent, do you?
> > 
> > Also, I'm thinking maybe we could provide an implementation of this
> > function for all switches, not just for vsc7512.
> 
> I had assumed these last two patches might spark more discussion, which
> is why I kept them separate (specifically the last patch).
> 
> With this, are you simply suggesting to take everything that is
> currently in felix_phylink_get_caps and doing it in the felix / seville
> implementations? This is because the default condition is no longer the
> "only" condition. Sounds easy enough.

No, not everything, just the way in which config->supported_interfaces
is populated. We have different PCS implementations, so it's likely that
the procedures to retrieve the valid SERDES protocols (when changing
them will be supported) are different.

But in fact I seriously doubt that the current way in which supported_interfaces
gets populated is limiting you from doing anything right now, precisely
because you don't have any code that supports changing the phy-mode.

Also, it's unlikely (I'd say impossible) for one driver to be
unconverted to the post-March-2020 requirements and the other not to be.
The simple reason is that they share the same mac_config implementation.
So it's perfectly ok to keep "config->legacy_pre_march2020 = false"
right where it is.

So I'd say it's up to you, but I'd drop this patch right now.
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-05-10  0:55           ` Colin Foster
@ 2022-05-09 17:58             ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:58 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:55:37PM -0700, Colin Foster wrote:
> Hmm... So the main reason I needed get_caps was because
> phylink_generic_validate looks at mac_capabilities. I know I'll have to
> deal with supported_interfaces once I finally get the other four ports
> working, but for now the main purpose of this patch is to allow me to
> populate the mac_capabilities entry for phylink_generic_validate.
> 
> Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
> of the patch makes sense.

But still. Just populate mac_capabilities for everybody in the common
felix_phylink_get_caps(), and use the generic phylink validation only
for your driver.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-05-09 17:58             ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-09 17:58 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:55:37PM -0700, Colin Foster wrote:
> Hmm... So the main reason I needed get_caps was because
> phylink_generic_validate looks at mac_capabilities. I know I'll have to
> deal with supported_interfaces once I finally get the other four ports
> working, but for now the main purpose of this patch is to allow me to
> populate the mac_capabilities entry for phylink_generic_validate.
> 
> Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
> of the patch makes sense.

But still. Just populate mac_capabilities for everybody in the common
felix_phylink_get_caps(), and use the generic phylink validation only
for your driver.
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
  2022-05-09  8:44     ` Andy Shevchenko
@ 2022-05-09 22:19       ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-09 22:19 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

Hi Andy,

On Mon, May 09, 2022 at 10:44:42AM +0200, Andy Shevchenko wrote:
> On Sun, May 8, 2022 at 8:53 PM Colin Foster
> <colin.foster@in-advantage.com> 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.
> 
> ...
> 
> > -       regs = devm_platform_ioremap_resource(pdev, 0);
> > -       if (IS_ERR(regs))
> > -               return PTR_ERR(regs);
> > +       regs = devm_platform_get_and_ioremap_resource(pdev, 0, 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, 0);
> > +               if (!res) {
> > +                       dev_err(dev, "Failed to get resource\n");
> > +                       return -ENODEV;
> > +               }
> > +
> > +               priv->regs = ocelot_init_regmap_from_resource(dev, res);
> > +       } else {
> > +               priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
> > +       }
> >
> > -       priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
> >         if (IS_ERR(priv->regs))
> >                 return PTR_ERR(priv->regs);
> 
> This looks like repetition of something you have done in a few
> previous patches. Can you avoid code duplication by introducing a
> corresponding helper function?

That's a good idea. Thanks for the feedback!

> 
> -- 
> With Best Regards,
> Andy Shevchenko

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration
@ 2022-05-09 22:19       ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-09 22:19 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

Hi Andy,

On Mon, May 09, 2022 at 10:44:42AM +0200, Andy Shevchenko wrote:
> On Sun, May 8, 2022 at 8:53 PM Colin Foster
> <colin.foster@in-advantage.com> 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.
> 
> ...
> 
> > -       regs = devm_platform_ioremap_resource(pdev, 0);
> > -       if (IS_ERR(regs))
> > -               return PTR_ERR(regs);
> > +       regs = devm_platform_get_and_ioremap_resource(pdev, 0, 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, 0);
> > +               if (!res) {
> > +                       dev_err(dev, "Failed to get resource\n");
> > +                       return -ENODEV;
> > +               }
> > +
> > +               priv->regs = ocelot_init_regmap_from_resource(dev, res);
> > +       } else {
> > +               priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
> > +       }
> >
> > -       priv->regs = devm_regmap_init_mmio(dev, regs, &regmap_config);
> >         if (IS_ERR(priv->regs))
> >                 return PTR_ERR(priv->regs);
> 
> This looks like repetition of something you have done in a few
> previous patches. Can you avoid code duplication by introducing a
> corresponding helper function?

That's a good idea. Thanks for the feedback!

> 
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-09  9:02     ` Andy Shevchenko
@ 2022-05-09 23:15       ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-09 23:15 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

Hi Andy,

Thanks for all the feedback (on this and the other patches). They all
seem straightforward for me to implement. 

On Mon, May 09, 2022 at 11:02:42AM +0200, Andy Shevchenko wrote:
> On Sun, May 8, 2022 at 8:53 PM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> >
> > The VSC7512 is a networking chip that contains several peripherals. Many of
> > these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> > controlled externally.
> >
> > Utilize the existing drivers by referencing the chip as an MFD. Add support
> > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.
> 
> ...
> 
> > +         If unsure, say N
> 
> Seems like an abrupt sentence.

It seems to match a common theme in Kconfigs (1149 hits)... although
I notice they all have a '.' at the end, which I'll add.

> 
> ...
> 
> > +EXPORT_SYMBOL(ocelot_chip_reset);
> 
> Please, switch to the namespace (_NS) variant of the exported-imported
> symbols for these drivers.
> 
> ...
> 
> > +int ocelot_core_init(struct device *dev)
> > +{
> > +       int ret;
> > +
> > +       ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> > +                                  ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> > +       if (ret) {
> > +               dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> > +               return ret;
> > +       }
> > +
> > +       return 0;
> 
> Isn't it simple
> 
>   return devm_mfd_add_devices(...);
> 
> ?
> 
> > +}
> 
> ...
> 
> > +#include <linux/of.h>
> 
> Do you really use this? (See also below).
> 
> ...
> 
> > +#define VSC7512_CPUORG_RES_START       0x71000000
> > +#define VSC7512_CPUORG_RES_SIZE                0x2ff
> 
> Doesn't look right.
> I'm expecting to see 0x300 here and -1 where it's needed in the code.

I see what you're saying. I can do that. Also, this number is larger
than it needs to be - the max defined register in this block is 0x34.
Thanks for pointing this out!

> 
> ...
> 
> > +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,
> 
> > +       .max_register = 0xffffffff,
> 
> Is it for real?! Have you considered what happens if someone actually
> tries to read all these registers (and for the record it's not a
> theoretical case, since the user may do it via debugfs)?

You had me worried for a second there. This is a useless assignment,
since the max_register gets calculated when the regmap is actually
initialized, based on the struct resoruce. I'll remove this.

> 
> > +       .use_single_write = true,
> > +       .can_multi_write = false,
> > +
> > +       .reg_format_endian = REGMAP_ENDIAN_BIG,
> > +       .val_format_endian = REGMAP_ENDIAN_NATIVE,
> > +};
> 
> ...
> 
> > +       if (ddata->spi_padding_bytes > 0) {
> 
> ' > 0' part is redundant.
> 
> > +               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);
> > +       }
> 
> ...
> 
> > +       memcpy(&regmap_config, &ocelot_spi_regmap_config,
> > +              sizeof(ocelot_spi_regmap_config));
> 
> sizeof(regmap_config) is a bit safer (in case somebody changes the
> types of the src and dst).
> 
> ...
> 
> > +       err = spi_setup(spi);
> > +       if (err < 0) {
> > +               dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> > +               return err;
> 
> return dev_err_probe(...);
> 
> > +       }
> ...
> 
> > +       ddata->cpuorg_regmap =
> > +               ocelot_spi_devm_init_regmap(dev, dev,
> > +                                           &vsc7512_dev_cpuorg_resource);
> 
> It's easier to read when it's a longer line. At least the last two can
> be on one line.
> 
> ...
> 
> > +       ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> > +                                                       &vsc7512_gcb_resource);
> 
> Do you have different cases for two first parameters? If not, drop duplication.

Yes. The thought here is the first "dev" is everything needed to
communicate with the chip. SPI bus, frequency, padding, etc.

The second "dev" is child device, to which the regmap gets
devm-attached. That should allow modules of the child devices to be
loaded / unloaded.

> 
> ...
> 
> > +       if (err) {
> > +               dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
> > +               return err;
> 
> return dev_err_probe(...);
> 
> And everywhere else where it's appropriate.
> 
> > +       }
> 
> ...
> 
> > +const struct of_device_id ocelot_spi_of_match[] = {
> > +       { .compatible = "mscc,vsc7512_mfd_spi" },
> > +       { },
> 
> No comma for terminator entry.
> 
> > +};
> 
> ...
> 
> > +               .of_match_table = of_match_ptr(ocelot_spi_of_match),
> 
> of_match_ptr() is rather harmful than useful. We have a lot of
> compiler warnings due to misuse of this. Besides that it prevents to
> use driver in non-OF environments (if it is / will be the case).

I used drivers/mfd/madera* as my template, since it seemed the closest
to what I was trying to achieve. Are you saying just to omit the
of_match_ptr wrapper (like in drivers/mfd/sprd-sc27xx-spi.c?)

> 
> ...
> 
> > +/*
> > + * Copyright 2021 Innovative Advantage Inc.
> > + */
> 
> One line.
> 
> ...
> 
> > +#include <linux/regmap.h>
> 
> I don't see the users of this. Use forward declarations (many of them
> are actually missed).
> 
> Also, seems kconfig.h, err.h and errno.h missed.

Thanks for pointing this out. I'll check these.

> 
> > +#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;
> > +};
> 
> ...
> 
> > +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > +                                               const struct resource *res);
> > +#else
> >  static inline struct regmap *
> >  ocelot_init_regmap_from_resource(struct device *child,
> >                                  const struct resource *res)
> >  {
> >         return ERR_PTR(-EOPNOTSUPP);
> >  }
> 
> -- 
> With Best Regards,
> Andy Shevchenko

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-09 23:15       ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-09 23:15 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Steen Hegelund, Lars Povlsen, Linus Walleij, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Vladimir Oltean, Lee Jones

Hi Andy,

Thanks for all the feedback (on this and the other patches). They all
seem straightforward for me to implement. 

On Mon, May 09, 2022 at 11:02:42AM +0200, Andy Shevchenko wrote:
> On Sun, May 8, 2022 at 8:53 PM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> >
> > The VSC7512 is a networking chip that contains several peripherals. Many of
> > these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> > controlled externally.
> >
> > Utilize the existing drivers by referencing the chip as an MFD. Add support
> > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.
> 
> ...
> 
> > +         If unsure, say N
> 
> Seems like an abrupt sentence.

It seems to match a common theme in Kconfigs (1149 hits)... although
I notice they all have a '.' at the end, which I'll add.

> 
> ...
> 
> > +EXPORT_SYMBOL(ocelot_chip_reset);
> 
> Please, switch to the namespace (_NS) variant of the exported-imported
> symbols for these drivers.
> 
> ...
> 
> > +int ocelot_core_init(struct device *dev)
> > +{
> > +       int ret;
> > +
> > +       ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> > +                                  ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> > +       if (ret) {
> > +               dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> > +               return ret;
> > +       }
> > +
> > +       return 0;
> 
> Isn't it simple
> 
>   return devm_mfd_add_devices(...);
> 
> ?
> 
> > +}
> 
> ...
> 
> > +#include <linux/of.h>
> 
> Do you really use this? (See also below).
> 
> ...
> 
> > +#define VSC7512_CPUORG_RES_START       0x71000000
> > +#define VSC7512_CPUORG_RES_SIZE                0x2ff
> 
> Doesn't look right.
> I'm expecting to see 0x300 here and -1 where it's needed in the code.

I see what you're saying. I can do that. Also, this number is larger
than it needs to be - the max defined register in this block is 0x34.
Thanks for pointing this out!

> 
> ...
> 
> > +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,
> 
> > +       .max_register = 0xffffffff,
> 
> Is it for real?! Have you considered what happens if someone actually
> tries to read all these registers (and for the record it's not a
> theoretical case, since the user may do it via debugfs)?

You had me worried for a second there. This is a useless assignment,
since the max_register gets calculated when the regmap is actually
initialized, based on the struct resoruce. I'll remove this.

> 
> > +       .use_single_write = true,
> > +       .can_multi_write = false,
> > +
> > +       .reg_format_endian = REGMAP_ENDIAN_BIG,
> > +       .val_format_endian = REGMAP_ENDIAN_NATIVE,
> > +};
> 
> ...
> 
> > +       if (ddata->spi_padding_bytes > 0) {
> 
> ' > 0' part is redundant.
> 
> > +               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);
> > +       }
> 
> ...
> 
> > +       memcpy(&regmap_config, &ocelot_spi_regmap_config,
> > +              sizeof(ocelot_spi_regmap_config));
> 
> sizeof(regmap_config) is a bit safer (in case somebody changes the
> types of the src and dst).
> 
> ...
> 
> > +       err = spi_setup(spi);
> > +       if (err < 0) {
> > +               dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> > +               return err;
> 
> return dev_err_probe(...);
> 
> > +       }
> ...
> 
> > +       ddata->cpuorg_regmap =
> > +               ocelot_spi_devm_init_regmap(dev, dev,
> > +                                           &vsc7512_dev_cpuorg_resource);
> 
> It's easier to read when it's a longer line. At least the last two can
> be on one line.
> 
> ...
> 
> > +       ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> > +                                                       &vsc7512_gcb_resource);
> 
> Do you have different cases for two first parameters? If not, drop duplication.

Yes. The thought here is the first "dev" is everything needed to
communicate with the chip. SPI bus, frequency, padding, etc.

The second "dev" is child device, to which the regmap gets
devm-attached. That should allow modules of the child devices to be
loaded / unloaded.

> 
> ...
> 
> > +       if (err) {
> > +               dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
> > +               return err;
> 
> return dev_err_probe(...);
> 
> And everywhere else where it's appropriate.
> 
> > +       }
> 
> ...
> 
> > +const struct of_device_id ocelot_spi_of_match[] = {
> > +       { .compatible = "mscc,vsc7512_mfd_spi" },
> > +       { },
> 
> No comma for terminator entry.
> 
> > +};
> 
> ...
> 
> > +               .of_match_table = of_match_ptr(ocelot_spi_of_match),
> 
> of_match_ptr() is rather harmful than useful. We have a lot of
> compiler warnings due to misuse of this. Besides that it prevents to
> use driver in non-OF environments (if it is / will be the case).

I used drivers/mfd/madera* as my template, since it seemed the closest
to what I was trying to achieve. Are you saying just to omit the
of_match_ptr wrapper (like in drivers/mfd/sprd-sc27xx-spi.c?)

> 
> ...
> 
> > +/*
> > + * Copyright 2021 Innovative Advantage Inc.
> > + */
> 
> One line.
> 
> ...
> 
> > +#include <linux/regmap.h>
> 
> I don't see the users of this. Use forward declarations (many of them
> are actually missed).
> 
> Also, seems kconfig.h, err.h and errno.h missed.

Thanks for pointing this out. I'll check these.

> 
> > +#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;
> > +};
> 
> ...
> 
> > +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > +                                               const struct resource *res);
> > +#else
> >  static inline struct regmap *
> >  ocelot_init_regmap_from_resource(struct device *child,
> >                                  const struct resource *res)
> >  {
> >         return ERR_PTR(-EOPNOTSUPP);
> >  }
> 
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-09 10:52     ` Vladimir Oltean
@ 2022-05-09 23:49       ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-09 23:49 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Vladimir,

On Mon, May 09, 2022 at 10:52:40AM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:05AM -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 <colin.foster@in-advantage.com>
> > ---
> >  drivers/mfd/Kconfig       |  18 +++
> >  drivers/mfd/Makefile      |   2 +
> >  drivers/mfd/ocelot-core.c | 135 +++++++++++++++++
> >  drivers/mfd/ocelot-spi.c  | 311 ++++++++++++++++++++++++++++++++++++++
> >  drivers/mfd/ocelot.h      |  34 +++++
> >  include/soc/mscc/ocelot.h |   5 +
> >  6 files changed, 505 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/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 3b59456f5545..ff177173ca11 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -962,6 +962,24 @@ config MFD_MENF21BMC
> >  	  This driver can also be built as a module. If so the module
> >  	  will be called menf21bmc.
> >  
> > +config MFD_OCELOT
> > +	tristate "Microsemi Ocelot External Control Support"
> > +	depends on SPI_MASTER
> > +	select MFD_CORE
> > +	select REGMAP_SPI
> > +	help
> > +	  Ocelot is a family of networking chips that support multiple ethernet
> > +	  and fibre interfaces. In addition to networking, they contain several
> > +	  other functions, including 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..117028f7d845
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot-core.c
> > @@ -0,0 +1,135 @@
> > +// 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/module.h>
> > +#include <linux/regmap.h>
> > +#include <soc/mscc/ocelot.h>
> > +
> > +#include <asm/byteorder.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_RES_START	0x710700f8
> > +#define VSC7512_SIO_RES_SIZE	0x100
> > +
> > +int ocelot_chip_reset(struct device *dev)
> > +{
> > +	struct ocelot_ddata *ddata = dev_get_drvdata(dev);
> > +	int ret;
> > +
> > +	/*
> > +	 * 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
> > +	 */
> > +	ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
> > +	if (ret)
> > +		return ret;
> > +
> > +	msleep(100);
> 
> Isn't this a bit too long?

A few orders of magnitude :-(  microseconds != milliseconds.

I'll change this.


Actually I'll need to do more digging. The manual talks about 100us, but
doesn't talk about SPI. My comments from previous submissions say it was
adopted from the PCIe reset procedure, which says "The endpoint is ready
approximately 50ms after release of the device's nRESET" so that might
have been my confusion. Thanks for pointing this out.

> 
> > +
> > +	return ret;
> 
> return 0
> 
> > +}
> > +EXPORT_SYMBOL(ocelot_chip_reset);
> > +
> > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > +						const struct resource *res)
> > +{
> > +	struct device *dev = child->parent;
> > +
> > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> 
> So much for being bus-agnostic :-/
> Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> via a function pointer which is populated by ocelot-spi.c? If you do
> that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.

That was my initial design. "core" was calling into "spi" exclusively
via function pointers.

The request was "Please find a clearer way to do this without function
pointers"

https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/

> 
> > +}
> > +EXPORT_SYMBOL(ocelot_init_regmap_from_resource);
> > +
> > +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_RES_START, VSC7512_SIO_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",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> > +		.resources = vsc7512_miim0_resources,
> > +	}, {
> > +		.name = "ocelot-miim1",
> > +		.of_compatible = "mscc,ocelot-miim",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> > +		.resources = vsc7512_miim1_resources,
> > +	},
> > +};
> > +
> > +int ocelot_core_init(struct device *dev)
> > +{
> > +	int ret;
> > +
> > +	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> > +				   ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(ocelot_core_init);
> > +
> > +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..95754deb0b57
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot-spi.c
> > @@ -0,0 +1,311 @@
> > +// 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 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/of.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_CPUORG_RES_START	0x71000000
> > +#define VSC7512_CPUORG_RES_SIZE		0x2ff
> > +
> > +#define VSC7512_GCB_RES_START	0x71070000
> > +#define VSC7512_GCB_RES_SIZE	0x14
> > +
> > +static const struct resource vsc7512_dev_cpuorg_resource =
> > +	DEFINE_RES_REG_NAMED(VSC7512_CPUORG_RES_START, VSC7512_CPUORG_RES_SIZE,
> > +			     "devcpu_org");
> > +
> > +static const struct resource vsc7512_gcb_resource =
> > +	DEFINE_RES_REG_NAMED(VSC7512_GCB_RES_START, VSC7512_GCB_RES_SIZE,
> > +			     "devcpu_gcb_chip_regs");
> > +
> > +int ocelot_spi_initialize(struct device *dev)
> 
> Should be static and unexported.

Good catch. I changed this from v7 so it can now be static. Thanks!

Everything else in your review looks good too, so I won't address each
of them.

> 
> > +{
> > +	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;
> > +}
> > +EXPORT_SYMBOL(ocelot_spi_initialize);
> > +
> > +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,
> > +
> > +	.max_register = 0xffffffff,
> > +	.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)
> > +{
> > +	static const u8 dummy_buf[16] = {0};
> > +	struct spi_transfer tx, padding, rx;
> > +	struct ocelot_ddata *ddata = context;
> > +	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 > 0) {
> > +		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_devm_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(&regmap_config, &ocelot_spi_regmap_config,
> > +	       sizeof(ocelot_spi_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,
> > +				&regmap_config);
> > +}
> > +
> > +static int ocelot_spi_probe(struct spi_device *spi)
> > +{
> > +	struct device *dev = &spi->dev;
> > +	struct ocelot_ddata *ddata;
> > +	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) {
> > +		dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> > +		return err;
> > +	}
> > +
> 
> Personally I'd prefer:
> 
> 	struct regmap *r;
> 
> 	r = ocelot_spi_devm_init_regmap(dev, dev,
> 					&vsc7512_dev_cpuorg_resource);
> 	if (IS_ERR(r))
> 		return ERR_PTR(r);
> 
> 	ddata->cpuorg_regmap = r;
> 
> and so on.
> 
> > +	ddata->cpuorg_regmap =
> > +		ocelot_spi_devm_init_regmap(dev, dev,
> > +					    &vsc7512_dev_cpuorg_resource);
> > +	if (IS_ERR(ddata->cpuorg_regmap))
> > +		return -ENOMEM;
> > +
> > +	ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> > +							&vsc7512_gcb_resource);
> > +	if (IS_ERR(ddata->gcb_regmap))
> > +		return -ENOMEM;
> > +
> > +	/*
> > +	 * 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) {
> > +		dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
> 
> Maybe showing the symbolic value behind the error number would be
> helpful?
> 
> 		dev_err(dev, "Initializing SPI bus returned %pe\n", ERR_PTR(err));
> 
> Similar for other places where you print the error using %d, I won't
> repeat this comment.
> 
> > +		return err;
> > +	}
> > +
> > +	err = ocelot_chip_reset(dev);
> > +	if (err) {
> > +		dev_err(dev, "Failed to reset device: %d\n", err);
> > +		return err;
> > +	}
> > +
> > +	/*
> > +	 * 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) {
> > +		dev_err(dev,
> > +			"Failed to initialize Ocelot SPI bus after reset: %d\n",
> > +			err);
> > +		return err;
> > +	}
> > +
> > +	err = ocelot_core_init(dev);
> > +	if (err < 0) {
> > +		dev_err(dev, "Error %d initializing Ocelot core\n", err);
> > +		return err;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +const struct of_device_id ocelot_spi_of_match[] = {
> 
> static
> 
> > +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
> > +
> > +static struct spi_driver ocelot_spi_driver = {
> > +	.driver = {
> > +		.name = "ocelot_mfd_spi",
> > +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> > +	},
> > +	.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..b68e6343caca
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot.h
> > @@ -0,0 +1,34 @@
> > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> > +/*
> > + * Copyright 2021 Innovative Advantage Inc.
> > + */
> > +
> > +#include <linux/regmap.h>
> > +
> > +#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_devm_init_regmap(struct device *dev,
> > +					   struct device *child,
> > +					   const struct resource *res);
> > +int ocelot_spi_initialize(struct device *dev);
> > +
> > +#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/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> > index 1897119ebb9a..f9124a66e386 100644
> > --- a/include/soc/mscc/ocelot.h
> > +++ b/include/soc/mscc/ocelot.h
> > @@ -1039,11 +1039,16 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
> >  }
> >  #endif
> >  
> > +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > +						const struct resource *res);
> > +#else
> >  static inline struct regmap *
> >  ocelot_init_regmap_from_resource(struct device *child,
> >  				 const struct resource *res)
> >  {
> >  	return ERR_PTR(-EOPNOTSUPP);
> >  }
> > +#endif
> >  
> >  #endif
> > -- 
> > 2.25.1
> >

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-09 23:49       ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-09 23:49 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Vladimir,

On Mon, May 09, 2022 at 10:52:40AM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:05AM -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 <colin.foster@in-advantage.com>
> > ---
> >  drivers/mfd/Kconfig       |  18 +++
> >  drivers/mfd/Makefile      |   2 +
> >  drivers/mfd/ocelot-core.c | 135 +++++++++++++++++
> >  drivers/mfd/ocelot-spi.c  | 311 ++++++++++++++++++++++++++++++++++++++
> >  drivers/mfd/ocelot.h      |  34 +++++
> >  include/soc/mscc/ocelot.h |   5 +
> >  6 files changed, 505 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/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 3b59456f5545..ff177173ca11 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -962,6 +962,24 @@ config MFD_MENF21BMC
> >  	  This driver can also be built as a module. If so the module
> >  	  will be called menf21bmc.
> >  
> > +config MFD_OCELOT
> > +	tristate "Microsemi Ocelot External Control Support"
> > +	depends on SPI_MASTER
> > +	select MFD_CORE
> > +	select REGMAP_SPI
> > +	help
> > +	  Ocelot is a family of networking chips that support multiple ethernet
> > +	  and fibre interfaces. In addition to networking, they contain several
> > +	  other functions, including 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..117028f7d845
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot-core.c
> > @@ -0,0 +1,135 @@
> > +// 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/module.h>
> > +#include <linux/regmap.h>
> > +#include <soc/mscc/ocelot.h>
> > +
> > +#include <asm/byteorder.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_RES_START	0x710700f8
> > +#define VSC7512_SIO_RES_SIZE	0x100
> > +
> > +int ocelot_chip_reset(struct device *dev)
> > +{
> > +	struct ocelot_ddata *ddata = dev_get_drvdata(dev);
> > +	int ret;
> > +
> > +	/*
> > +	 * 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
> > +	 */
> > +	ret = regmap_write(ddata->gcb_regmap, GCB_SOFT_RST, SOFT_CHIP_RST);
> > +	if (ret)
> > +		return ret;
> > +
> > +	msleep(100);
> 
> Isn't this a bit too long?

A few orders of magnitude :-(  microseconds != milliseconds.

I'll change this.


Actually I'll need to do more digging. The manual talks about 100us, but
doesn't talk about SPI. My comments from previous submissions say it was
adopted from the PCIe reset procedure, which says "The endpoint is ready
approximately 50ms after release of the device's nRESET" so that might
have been my confusion. Thanks for pointing this out.

> 
> > +
> > +	return ret;
> 
> return 0
> 
> > +}
> > +EXPORT_SYMBOL(ocelot_chip_reset);
> > +
> > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > +						const struct resource *res)
> > +{
> > +	struct device *dev = child->parent;
> > +
> > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> 
> So much for being bus-agnostic :-/
> Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> via a function pointer which is populated by ocelot-spi.c? If you do
> that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.

That was my initial design. "core" was calling into "spi" exclusively
via function pointers.

The request was "Please find a clearer way to do this without function
pointers"

https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/

> 
> > +}
> > +EXPORT_SYMBOL(ocelot_init_regmap_from_resource);
> > +
> > +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_RES_START, VSC7512_SIO_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",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> > +		.resources = vsc7512_miim0_resources,
> > +	}, {
> > +		.name = "ocelot-miim1",
> > +		.of_compatible = "mscc,ocelot-miim",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> > +		.resources = vsc7512_miim1_resources,
> > +	},
> > +};
> > +
> > +int ocelot_core_init(struct device *dev)
> > +{
> > +	int ret;
> > +
> > +	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> > +				   ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(ocelot_core_init);
> > +
> > +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..95754deb0b57
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot-spi.c
> > @@ -0,0 +1,311 @@
> > +// 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 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/of.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_CPUORG_RES_START	0x71000000
> > +#define VSC7512_CPUORG_RES_SIZE		0x2ff
> > +
> > +#define VSC7512_GCB_RES_START	0x71070000
> > +#define VSC7512_GCB_RES_SIZE	0x14
> > +
> > +static const struct resource vsc7512_dev_cpuorg_resource =
> > +	DEFINE_RES_REG_NAMED(VSC7512_CPUORG_RES_START, VSC7512_CPUORG_RES_SIZE,
> > +			     "devcpu_org");
> > +
> > +static const struct resource vsc7512_gcb_resource =
> > +	DEFINE_RES_REG_NAMED(VSC7512_GCB_RES_START, VSC7512_GCB_RES_SIZE,
> > +			     "devcpu_gcb_chip_regs");
> > +
> > +int ocelot_spi_initialize(struct device *dev)
> 
> Should be static and unexported.

Good catch. I changed this from v7 so it can now be static. Thanks!

Everything else in your review looks good too, so I won't address each
of them.

> 
> > +{
> > +	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;
> > +}
> > +EXPORT_SYMBOL(ocelot_spi_initialize);
> > +
> > +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,
> > +
> > +	.max_register = 0xffffffff,
> > +	.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)
> > +{
> > +	static const u8 dummy_buf[16] = {0};
> > +	struct spi_transfer tx, padding, rx;
> > +	struct ocelot_ddata *ddata = context;
> > +	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 > 0) {
> > +		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_devm_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(&regmap_config, &ocelot_spi_regmap_config,
> > +	       sizeof(ocelot_spi_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,
> > +				&regmap_config);
> > +}
> > +
> > +static int ocelot_spi_probe(struct spi_device *spi)
> > +{
> > +	struct device *dev = &spi->dev;
> > +	struct ocelot_ddata *ddata;
> > +	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) {
> > +		dev_err(&spi->dev, "Error %d initializing SPI\n", err);
> > +		return err;
> > +	}
> > +
> 
> Personally I'd prefer:
> 
> 	struct regmap *r;
> 
> 	r = ocelot_spi_devm_init_regmap(dev, dev,
> 					&vsc7512_dev_cpuorg_resource);
> 	if (IS_ERR(r))
> 		return ERR_PTR(r);
> 
> 	ddata->cpuorg_regmap = r;
> 
> and so on.
> 
> > +	ddata->cpuorg_regmap =
> > +		ocelot_spi_devm_init_regmap(dev, dev,
> > +					    &vsc7512_dev_cpuorg_resource);
> > +	if (IS_ERR(ddata->cpuorg_regmap))
> > +		return -ENOMEM;
> > +
> > +	ddata->gcb_regmap = ocelot_spi_devm_init_regmap(dev, dev,
> > +							&vsc7512_gcb_resource);
> > +	if (IS_ERR(ddata->gcb_regmap))
> > +		return -ENOMEM;
> > +
> > +	/*
> > +	 * 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) {
> > +		dev_err(dev, "Error %d initializing Ocelot SPI bus\n", err);
> 
> Maybe showing the symbolic value behind the error number would be
> helpful?
> 
> 		dev_err(dev, "Initializing SPI bus returned %pe\n", ERR_PTR(err));
> 
> Similar for other places where you print the error using %d, I won't
> repeat this comment.
> 
> > +		return err;
> > +	}
> > +
> > +	err = ocelot_chip_reset(dev);
> > +	if (err) {
> > +		dev_err(dev, "Failed to reset device: %d\n", err);
> > +		return err;
> > +	}
> > +
> > +	/*
> > +	 * 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) {
> > +		dev_err(dev,
> > +			"Failed to initialize Ocelot SPI bus after reset: %d\n",
> > +			err);
> > +		return err;
> > +	}
> > +
> > +	err = ocelot_core_init(dev);
> > +	if (err < 0) {
> > +		dev_err(dev, "Error %d initializing Ocelot core\n", err);
> > +		return err;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +const struct of_device_id ocelot_spi_of_match[] = {
> 
> static
> 
> > +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
> > +
> > +static struct spi_driver ocelot_spi_driver = {
> > +	.driver = {
> > +		.name = "ocelot_mfd_spi",
> > +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> > +	},
> > +	.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..b68e6343caca
> > --- /dev/null
> > +++ b/drivers/mfd/ocelot.h
> > @@ -0,0 +1,34 @@
> > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> > +/*
> > + * Copyright 2021 Innovative Advantage Inc.
> > + */
> > +
> > +#include <linux/regmap.h>
> > +
> > +#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_devm_init_regmap(struct device *dev,
> > +					   struct device *child,
> > +					   const struct resource *res);
> > +int ocelot_spi_initialize(struct device *dev);
> > +
> > +#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/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> > index 1897119ebb9a..f9124a66e386 100644
> > --- a/include/soc/mscc/ocelot.h
> > +++ b/include/soc/mscc/ocelot.h
> > @@ -1039,11 +1039,16 @@ ocelot_mrp_del_ring_role(struct ocelot *ocelot, int port,
> >  }
> >  #endif
> >  
> > +#if IS_ENABLED(CONFIG_MFD_OCELOT)
> > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > +						const struct resource *res);
> > +#else
> >  static inline struct regmap *
> >  ocelot_init_regmap_from_resource(struct device *child,
> >  				 const struct resource *res)
> >  {
> >  	return ERR_PTR(-EOPNOTSUPP);
> >  }
> > +#endif
> >  
> >  #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	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control
  2022-05-09 16:27     ` Vladimir Oltean
@ 2022-05-10  0:02       ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:02 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 04:27:22PM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:11AM -0700, Colin Foster wrote:
> > Add control of an external VSC7512 chip by way of the ocelot-mfd interface.
> > 
> > Currently the four copper phy ports are fully functional. Communication to
> > external phys is also functional, but the SGMII / QSGMII interfaces are
> > currently non-functional.
> > 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> >  drivers/mfd/ocelot-core.c           |   3 +
> >  drivers/net/dsa/ocelot/Kconfig      |  14 ++
> >  drivers/net/dsa/ocelot/Makefile     |   5 +
> >  drivers/net/dsa/ocelot/ocelot_ext.c | 368 ++++++++++++++++++++++++++++
> >  include/soc/mscc/ocelot.h           |   2 +
> >  5 files changed, 392 insertions(+)
> >  create mode 100644 drivers/net/dsa/ocelot/ocelot_ext.c
> > 
> > diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
> > index 117028f7d845..c582b409a9f3 100644
> > --- a/drivers/mfd/ocelot-core.c
> > +++ b/drivers/mfd/ocelot-core.c
> > @@ -112,6 +112,9 @@ static const struct mfd_cell vsc7512_devs[] = {
> >  		.of_compatible = "mscc,ocelot-miim",
> >  		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> >  		.resources = vsc7512_miim1_resources,
> > +	}, {
> > +		.name = "ocelot-ext-switch",
> > +		.of_compatible = "mscc,vsc7512-ext-switch",
> >  	},
> >  };
> >  
> > diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
> > index 220b0b027b55..f40b2c7171ad 100644
> > --- a/drivers/net/dsa/ocelot/Kconfig
> > +++ b/drivers/net/dsa/ocelot/Kconfig
> > @@ -1,4 +1,18 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> > +config NET_DSA_MSCC_OCELOT_EXT
> > +	tristate "Ocelot External Ethernet switch support"
> > +	depends on NET_DSA && SPI
> > +	depends on NET_VENDOR_MICROSEMI
> > +	select MDIO_MSCC_MIIM
> > +	select MFD_OCELOT_CORE
> > +	select MSCC_OCELOT_SWITCH_LIB
> > +	select NET_DSA_TAG_OCELOT_8021Q
> > +	select NET_DSA_TAG_OCELOT
> > +	help
> > +	  This driver supports the VSC7511, VSC7512, VSC7513 and VSC7514 chips
> > +	  when controlled through SPI. It can be used with the Microsemi dev
> > +	  boards and an external CPU or custom hardware.
> > +
> >  config NET_DSA_MSCC_FELIX
> >  	tristate "Ocelot / Felix Ethernet switch support"
> >  	depends on NET_DSA && PCI
> > diff --git a/drivers/net/dsa/ocelot/Makefile b/drivers/net/dsa/ocelot/Makefile
> > index f6dd131e7491..d7f3f5a4461c 100644
> > --- a/drivers/net/dsa/ocelot/Makefile
> > +++ b/drivers/net/dsa/ocelot/Makefile
> > @@ -1,11 +1,16 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_NET_DSA_MSCC_FELIX) += mscc_felix.o
> > +obj-$(CONFIG_NET_DSA_MSCC_OCELOT_EXT) += mscc_ocelot_ext.o
> >  obj-$(CONFIG_NET_DSA_MSCC_SEVILLE) += mscc_seville.o
> >  
> >  mscc_felix-objs := \
> >  	felix.o \
> >  	felix_vsc9959.o
> >  
> > +mscc_ocelot_ext-objs := \
> > +	felix.o \
> > +	ocelot_ext.o
> > +
> >  mscc_seville-objs := \
> >  	felix.o \
> >  	seville_vsc9953.o
> > diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
> > new file mode 100644
> > index 000000000000..ba924f6b8d12
> > --- /dev/null
> > +++ b/drivers/net/dsa/ocelot/ocelot_ext.c
> > @@ -0,0 +1,368 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2021-2022 Innovative Advantage Inc.
> > + */
> > +
> > +#include <asm/byteorder.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/kconfig.h>
> > +#include <linux/phylink.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <soc/mscc/ocelot_ana.h>
> > +#include <soc/mscc/ocelot_dev.h>
> > +#include <soc/mscc/ocelot_qsys.h>
> > +#include <soc/mscc/ocelot_vcap.h>
> > +#include <soc/mscc/ocelot_ptp.h>
> > +#include <soc/mscc/ocelot_sys.h>
> > +#include <soc/mscc/ocelot.h>
> > +#include <soc/mscc/vsc7514_regs.h>
> > +#include "felix.h"
> > +
> > +#define VSC7512_NUM_PORTS		11
> > +
> > +static const u32 vsc7512_port_modes[VSC7512_NUM_PORTS] = {
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +};
> > +
> > +static const u32 vsc7512_gcb_regmap[] = {
> > +	REG(GCB_SOFT_RST,			0x0008),
> > +	REG(GCB_MIIM_MII_STATUS,		0x009c),
> > +	REG(GCB_PHY_PHY_CFG,			0x00f0),
> > +	REG(GCB_PHY_PHY_STAT,			0x00f4),
> > +};
> > +
> > +static const u32 *vsc7512_regmap[TARGET_MAX] = {
> > +	[ANA] = vsc7514_ana_regmap,
> > +	[QS] = vsc7514_qs_regmap,
> > +	[QSYS] = vsc7514_qsys_regmap,
> > +	[REW] = vsc7514_rew_regmap,
> > +	[SYS] = vsc7514_sys_regmap,
> > +	[S0] = vsc7514_vcap_regmap,
> > +	[S1] = vsc7514_vcap_regmap,
> > +	[S2] = vsc7514_vcap_regmap,
> > +	[PTP] = vsc7514_ptp_regmap,
> > +	[GCB] = vsc7512_gcb_regmap,
> > +	[DEV_GMII] = vsc7514_dev_gmii_regmap,
> > +};
> > +
> > +static void ocelot_ext_reset_phys(struct ocelot *ocelot)
> > +{
> > +	ocelot_write(ocelot, 0, GCB_PHY_PHY_CFG);
> > +	ocelot_write(ocelot, 0x1ff, GCB_PHY_PHY_CFG);
> > +	mdelay(500);
> > +}
> > +
> > +static int ocelot_ext_reset(struct ocelot *ocelot)
> > +{
> > +	int retries = 100;
> > +	int err, val;
> > +
> > +	ocelot_ext_reset_phys(ocelot);
> > +
> > +	/* Initialize chip memories */
> > +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
> > +	if (err)
> > +		return err;
> > +
> > +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
> > +	if (err)
> > +		return err;
> > +
> > +	/* MEM_INIT is a self-clearing bit. Wait for it to be clear (should be
> > +	 * 100us) before enabling the switch core
> > +	 */
> > +	do {
> > +		msleep(1);
> > +		err = regmap_field_read(ocelot->regfields[SYS_RESET_CFG_MEM_INIT],
> > +					&val);
> > +		if (err)
> > +			return err;
> > +	} while (val && --retries);
> 
> Can you use readx_poll_timeout() here?

It looks like I can, yes. I'll update.

> 
> > +
> > +	if (!retries)
> > +		return -ETIMEDOUT;
> > +
> > +	return regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1);
> > +}
> > +
> > +static const struct ocelot_ops ocelot_ext_ops = {
> > +	.reset		= ocelot_ext_reset,
> > +	.wm_enc		= ocelot_wm_enc,
> > +	.wm_dec		= ocelot_wm_dec,
> > +	.wm_stat	= ocelot_wm_stat,
> > +	.port_to_netdev	= felix_port_to_netdev,
> > +	.netdev_to_port	= felix_netdev_to_port,
> > +};
> > +
> > +static const struct resource vsc7512_target_io_res[TARGET_MAX] = {
> > +	[ANA] = {
> > +		.start	= 0x71880000,
> > +		.end	= 0x7188ffff,
> > +		.name	= "ana",
> > +	},
> > +	[QS] = {
> > +		.start	= 0x71080000,
> > +		.end	= 0x710800ff,
> > +		.name	= "qs",
> > +	},
> > +	[QSYS] = {
> > +		.start	= 0x71800000,
> > +		.end	= 0x719fffff,
> > +		.name	= "qsys",
> > +	},
> > +	[REW] = {
> > +		.start	= 0x71030000,
> > +		.end	= 0x7103ffff,
> > +		.name	= "rew",
> > +	},
> > +	[SYS] = {
> > +		.start	= 0x71010000,
> > +		.end	= 0x7101ffff,
> > +		.name	= "sys",
> > +	},
> > +	[S0] = {
> > +		.start	= 0x71040000,
> > +		.end	= 0x710403ff,
> > +		.name	= "s0",
> > +	},
> > +	[S1] = {
> > +		.start	= 0x71050000,
> > +		.end	= 0x710503ff,
> > +		.name	= "s1",
> > +	},
> > +	[S2] = {
> > +		.start	= 0x71060000,
> > +		.end	= 0x710603ff,
> > +		.name	= "s2",
> > +	},
> > +	[GCB] =	{
> > +		.start	= 0x71070000,
> > +		.end	= 0x7107022b,
> > +		.name	= "devcpu_gcb",
> > +	},
> > +};
> > +
> > +static const struct resource vsc7512_port_io_res[] = {
> > +	{
> > +		.start	= 0x711e0000,
> > +		.end	= 0x711effff,
> > +		.name	= "port0",
> > +	},
> > +	{
> > +		.start	= 0x711f0000,
> > +		.end	= 0x711fffff,
> > +		.name	= "port1",
> > +	},
> > +	{
> > +		.start	= 0x71200000,
> > +		.end	= 0x7120ffff,
> > +		.name	= "port2",
> > +	},
> > +	{
> > +		.start	= 0x71210000,
> > +		.end	= 0x7121ffff,
> > +		.name	= "port3",
> > +	},
> > +	{
> > +		.start	= 0x71220000,
> > +		.end	= 0x7122ffff,
> > +		.name	= "port4",
> > +	},
> > +	{
> > +		.start	= 0x71230000,
> > +		.end	= 0x7123ffff,
> > +		.name	= "port5",
> > +	},
> > +	{
> > +		.start	= 0x71240000,
> > +		.end	= 0x7124ffff,
> > +		.name	= "port6",
> > +	},
> > +	{
> > +		.start	= 0x71250000,
> > +		.end	= 0x7125ffff,
> > +		.name	= "port7",
> > +	},
> > +	{
> > +		.start	= 0x71260000,
> > +		.end	= 0x7126ffff,
> > +		.name	= "port8",
> > +	},
> > +	{
> > +		.start	= 0x71270000,
> > +		.end	= 0x7127ffff,
> > +		.name	= "port9",
> > +	},
> > +	{
> > +		.start	= 0x71280000,
> > +		.end	= 0x7128ffff,
> > +		.name	= "port10",
> > +	},
> > +};
> > +
> > +static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
> > +					unsigned long *supported,
> > +					struct phylink_link_state *state)
> > +{
> > +	struct ocelot_port *ocelot_port = ocelot->ports[port];
> > +
> > +	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > +
> > +	if (state->interface != PHY_INTERFACE_MODE_NA &&
> 
> This check is no longer necessary, please look again at the other
> phylink validation functions.
> 
> > +	    state->interface != ocelot_port->phy_mode) {
> 
> Also, I don't see what is the point of providing one phylink validation
> method only to replace it later in the patchset with the generic one.
> Please squash "net: dsa: ocelot: utilize phylink_generic_validate" into
> this.

Yes, that was a poor decision on my part to keep that patch separate. I
should have squashed it, since you already pointed this out last round
and that is exactly what the last commit of this series was addressing.

> 
> > +		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +		return;
> > +	}
> > +
> > +	phylink_set_port_modes(mask);
> > +
> > +	phylink_set(mask, Pause);
> > +	phylink_set(mask, Autoneg);
> > +	phylink_set(mask, Asym_Pause);
> > +	phylink_set(mask, 10baseT_Half);
> > +	phylink_set(mask, 10baseT_Full);
> > +	phylink_set(mask, 100baseT_Half);
> > +	phylink_set(mask, 100baseT_Full);
> > +	phylink_set(mask, 1000baseT_Half);
> > +	phylink_set(mask, 1000baseT_Full);
> > +
> > +	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +	bitmap_and(state->advertising, state->advertising, mask,
> > +		   __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +}
> > +
> > +static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
> > +					     struct resource *res)
> > +{
> > +	return ocelot_init_regmap_from_resource(ocelot->dev, res);
> > +}
> > +
> > +static const struct felix_info vsc7512_info = {
> > +	.target_io_res			= vsc7512_target_io_res,
> > +	.port_io_res			= vsc7512_port_io_res,
> > +	.regfields			= vsc7514_regfields,
> > +	.map				= vsc7512_regmap,
> > +	.ops				= &ocelot_ext_ops,
> > +	.stats_layout			= vsc7514_stats_layout,
> > +	.vcap				= vsc7514_vcap_props,
> > +	.num_mact_rows			= 1024,
> > +	.num_ports			= VSC7512_NUM_PORTS,
> > +	.num_tx_queues			= OCELOT_NUM_TC,
> > +	.phylink_validate		= ocelot_ext_phylink_validate,
> > +	.port_modes			= vsc7512_port_modes,
> > +	.init_regmap			= ocelot_ext_regmap_init,
> > +};
> > +
> > +static int ocelot_ext_probe(struct platform_device *pdev)
> > +{
> > +	struct dsa_switch *ds;
> > +	struct ocelot *ocelot;
> > +	struct felix *felix;
> > +	struct device *dev;
> > +	int err;
> > +
> > +	dev = &pdev->dev;
> 
> I would prefer if this assignment was part of the variable declaration.
> 
> > +
> > +	felix = kzalloc(sizeof(*felix), GFP_KERNEL);
> > +	if (!felix)
> > +		return -ENOMEM;
> > +
> > +	dev_set_drvdata(dev, felix);
> > +
> > +	ocelot = &felix->ocelot;
> > +	ocelot->dev = dev;
> > +
> > +	ocelot->num_flooding_pgids = 1;
> > +
> > +	felix->info = &vsc7512_info;
> > +
> > +	ds = kzalloc(sizeof(*ds), GFP_KERNEL);
> > +	if (!ds) {
> > +		err = -ENOMEM;
> > +		dev_err(dev, "Failed to allocate DSA switch\n");
> > +		goto err_free_felix;
> > +	}
> > +
> > +	ds->dev = dev;
> > +	ds->num_ports = felix->info->num_ports;
> > +	ds->num_tx_queues = felix->info->num_tx_queues;
> > +
> > +	ds->ops = &felix_switch_ops;
> > +	ds->priv = ocelot;
> > +	felix->ds = ds;
> > +	felix->tag_proto = DSA_TAG_PROTO_OCELOT;
> > +
> > +	err = dsa_register_switch(ds);
> > +	if (err) {
> > +		dev_err(dev, "Failed to register DSA switch: %d\n", err);
> 
> dev_err_probe please (look at the other drivers)
> 
> > +		goto err_free_ds;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_free_ds:
> > +	kfree(ds);
> > +err_free_felix:
> > +	kfree(felix);
> > +	return err;
> > +}
> > +
> > +static int ocelot_ext_remove(struct platform_device *pdev)
> > +{
> > +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> > +
> > +	if (!felix)
> > +		return 0;
> > +
> > +	dsa_unregister_switch(felix->ds);
> > +
> > +	kfree(felix->ds);
> > +	kfree(felix);
> > +
> > +	dev_set_drvdata(&pdev->dev, NULL);
> > +
> > +	return 0;
> > +}
> > +
> > +static void ocelot_ext_shutdown(struct platform_device *pdev)
> > +{
> > +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> > +
> > +	if (!felix)
> > +		return;
> > +
> > +	dsa_switch_shutdown(felix->ds);
> > +
> > +	dev_set_drvdata(&pdev->dev, NULL);
> > +}
> > +
> > +const struct of_device_id ocelot_ext_switch_of_match[] = {
> 
> static
> 
> > +	{ .compatible = "mscc,vsc7512-ext-switch" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);
> > +
> > +static struct platform_driver ocelot_ext_switch_driver = {
> > +	.driver = {
> > +		.name = "ocelot-ext-switch",
> > +		.of_match_table = of_match_ptr(ocelot_ext_switch_of_match),
> > +	},
> > +	.probe = ocelot_ext_probe,
> > +	.remove = ocelot_ext_remove,
> > +	.shutdown = ocelot_ext_shutdown,
> > +};
> > +module_platform_driver(ocelot_ext_switch_driver);
> > +
> > +MODULE_DESCRIPTION("External Ocelot Switch driver");
> > +MODULE_LICENSE("GPL");
> > diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> > index 61888453f913..ade84e86741e 100644
> > --- a/include/soc/mscc/ocelot.h
> > +++ b/include/soc/mscc/ocelot.h
> > @@ -402,6 +402,8 @@ enum ocelot_reg {
> >  	GCB_MIIM_MII_STATUS,
> >  	GCB_MIIM_MII_CMD,
> >  	GCB_MIIM_MII_DATA,
> > +	GCB_PHY_PHY_CFG,
> > +	GCB_PHY_PHY_STAT,
> >  	DEV_CLOCK_CFG = DEV_GMII << TARGET_OFFSET,
> >  	DEV_PORT_MISC,
> >  	DEV_EVENTS,
> > -- 
> > 2.25.1
> >

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control
@ 2022-05-10  0:02       ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:02 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 04:27:22PM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:11AM -0700, Colin Foster wrote:
> > Add control of an external VSC7512 chip by way of the ocelot-mfd interface.
> > 
> > Currently the four copper phy ports are fully functional. Communication to
> > external phys is also functional, but the SGMII / QSGMII interfaces are
> > currently non-functional.
> > 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> >  drivers/mfd/ocelot-core.c           |   3 +
> >  drivers/net/dsa/ocelot/Kconfig      |  14 ++
> >  drivers/net/dsa/ocelot/Makefile     |   5 +
> >  drivers/net/dsa/ocelot/ocelot_ext.c | 368 ++++++++++++++++++++++++++++
> >  include/soc/mscc/ocelot.h           |   2 +
> >  5 files changed, 392 insertions(+)
> >  create mode 100644 drivers/net/dsa/ocelot/ocelot_ext.c
> > 
> > diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
> > index 117028f7d845..c582b409a9f3 100644
> > --- a/drivers/mfd/ocelot-core.c
> > +++ b/drivers/mfd/ocelot-core.c
> > @@ -112,6 +112,9 @@ static const struct mfd_cell vsc7512_devs[] = {
> >  		.of_compatible = "mscc,ocelot-miim",
> >  		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> >  		.resources = vsc7512_miim1_resources,
> > +	}, {
> > +		.name = "ocelot-ext-switch",
> > +		.of_compatible = "mscc,vsc7512-ext-switch",
> >  	},
> >  };
> >  
> > diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
> > index 220b0b027b55..f40b2c7171ad 100644
> > --- a/drivers/net/dsa/ocelot/Kconfig
> > +++ b/drivers/net/dsa/ocelot/Kconfig
> > @@ -1,4 +1,18 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> > +config NET_DSA_MSCC_OCELOT_EXT
> > +	tristate "Ocelot External Ethernet switch support"
> > +	depends on NET_DSA && SPI
> > +	depends on NET_VENDOR_MICROSEMI
> > +	select MDIO_MSCC_MIIM
> > +	select MFD_OCELOT_CORE
> > +	select MSCC_OCELOT_SWITCH_LIB
> > +	select NET_DSA_TAG_OCELOT_8021Q
> > +	select NET_DSA_TAG_OCELOT
> > +	help
> > +	  This driver supports the VSC7511, VSC7512, VSC7513 and VSC7514 chips
> > +	  when controlled through SPI. It can be used with the Microsemi dev
> > +	  boards and an external CPU or custom hardware.
> > +
> >  config NET_DSA_MSCC_FELIX
> >  	tristate "Ocelot / Felix Ethernet switch support"
> >  	depends on NET_DSA && PCI
> > diff --git a/drivers/net/dsa/ocelot/Makefile b/drivers/net/dsa/ocelot/Makefile
> > index f6dd131e7491..d7f3f5a4461c 100644
> > --- a/drivers/net/dsa/ocelot/Makefile
> > +++ b/drivers/net/dsa/ocelot/Makefile
> > @@ -1,11 +1,16 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  obj-$(CONFIG_NET_DSA_MSCC_FELIX) += mscc_felix.o
> > +obj-$(CONFIG_NET_DSA_MSCC_OCELOT_EXT) += mscc_ocelot_ext.o
> >  obj-$(CONFIG_NET_DSA_MSCC_SEVILLE) += mscc_seville.o
> >  
> >  mscc_felix-objs := \
> >  	felix.o \
> >  	felix_vsc9959.o
> >  
> > +mscc_ocelot_ext-objs := \
> > +	felix.o \
> > +	ocelot_ext.o
> > +
> >  mscc_seville-objs := \
> >  	felix.o \
> >  	seville_vsc9953.o
> > diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
> > new file mode 100644
> > index 000000000000..ba924f6b8d12
> > --- /dev/null
> > +++ b/drivers/net/dsa/ocelot/ocelot_ext.c
> > @@ -0,0 +1,368 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2021-2022 Innovative Advantage Inc.
> > + */
> > +
> > +#include <asm/byteorder.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/kconfig.h>
> > +#include <linux/phylink.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <soc/mscc/ocelot_ana.h>
> > +#include <soc/mscc/ocelot_dev.h>
> > +#include <soc/mscc/ocelot_qsys.h>
> > +#include <soc/mscc/ocelot_vcap.h>
> > +#include <soc/mscc/ocelot_ptp.h>
> > +#include <soc/mscc/ocelot_sys.h>
> > +#include <soc/mscc/ocelot.h>
> > +#include <soc/mscc/vsc7514_regs.h>
> > +#include "felix.h"
> > +
> > +#define VSC7512_NUM_PORTS		11
> > +
> > +static const u32 vsc7512_port_modes[VSC7512_NUM_PORTS] = {
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_INTERNAL,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +	OCELOT_PORT_MODE_SGMII,
> > +	OCELOT_PORT_MODE_SGMII | OCELOT_PORT_MODE_QSGMII,
> > +};
> > +
> > +static const u32 vsc7512_gcb_regmap[] = {
> > +	REG(GCB_SOFT_RST,			0x0008),
> > +	REG(GCB_MIIM_MII_STATUS,		0x009c),
> > +	REG(GCB_PHY_PHY_CFG,			0x00f0),
> > +	REG(GCB_PHY_PHY_STAT,			0x00f4),
> > +};
> > +
> > +static const u32 *vsc7512_regmap[TARGET_MAX] = {
> > +	[ANA] = vsc7514_ana_regmap,
> > +	[QS] = vsc7514_qs_regmap,
> > +	[QSYS] = vsc7514_qsys_regmap,
> > +	[REW] = vsc7514_rew_regmap,
> > +	[SYS] = vsc7514_sys_regmap,
> > +	[S0] = vsc7514_vcap_regmap,
> > +	[S1] = vsc7514_vcap_regmap,
> > +	[S2] = vsc7514_vcap_regmap,
> > +	[PTP] = vsc7514_ptp_regmap,
> > +	[GCB] = vsc7512_gcb_regmap,
> > +	[DEV_GMII] = vsc7514_dev_gmii_regmap,
> > +};
> > +
> > +static void ocelot_ext_reset_phys(struct ocelot *ocelot)
> > +{
> > +	ocelot_write(ocelot, 0, GCB_PHY_PHY_CFG);
> > +	ocelot_write(ocelot, 0x1ff, GCB_PHY_PHY_CFG);
> > +	mdelay(500);
> > +}
> > +
> > +static int ocelot_ext_reset(struct ocelot *ocelot)
> > +{
> > +	int retries = 100;
> > +	int err, val;
> > +
> > +	ocelot_ext_reset_phys(ocelot);
> > +
> > +	/* Initialize chip memories */
> > +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
> > +	if (err)
> > +		return err;
> > +
> > +	err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
> > +	if (err)
> > +		return err;
> > +
> > +	/* MEM_INIT is a self-clearing bit. Wait for it to be clear (should be
> > +	 * 100us) before enabling the switch core
> > +	 */
> > +	do {
> > +		msleep(1);
> > +		err = regmap_field_read(ocelot->regfields[SYS_RESET_CFG_MEM_INIT],
> > +					&val);
> > +		if (err)
> > +			return err;
> > +	} while (val && --retries);
> 
> Can you use readx_poll_timeout() here?

It looks like I can, yes. I'll update.

> 
> > +
> > +	if (!retries)
> > +		return -ETIMEDOUT;
> > +
> > +	return regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1);
> > +}
> > +
> > +static const struct ocelot_ops ocelot_ext_ops = {
> > +	.reset		= ocelot_ext_reset,
> > +	.wm_enc		= ocelot_wm_enc,
> > +	.wm_dec		= ocelot_wm_dec,
> > +	.wm_stat	= ocelot_wm_stat,
> > +	.port_to_netdev	= felix_port_to_netdev,
> > +	.netdev_to_port	= felix_netdev_to_port,
> > +};
> > +
> > +static const struct resource vsc7512_target_io_res[TARGET_MAX] = {
> > +	[ANA] = {
> > +		.start	= 0x71880000,
> > +		.end	= 0x7188ffff,
> > +		.name	= "ana",
> > +	},
> > +	[QS] = {
> > +		.start	= 0x71080000,
> > +		.end	= 0x710800ff,
> > +		.name	= "qs",
> > +	},
> > +	[QSYS] = {
> > +		.start	= 0x71800000,
> > +		.end	= 0x719fffff,
> > +		.name	= "qsys",
> > +	},
> > +	[REW] = {
> > +		.start	= 0x71030000,
> > +		.end	= 0x7103ffff,
> > +		.name	= "rew",
> > +	},
> > +	[SYS] = {
> > +		.start	= 0x71010000,
> > +		.end	= 0x7101ffff,
> > +		.name	= "sys",
> > +	},
> > +	[S0] = {
> > +		.start	= 0x71040000,
> > +		.end	= 0x710403ff,
> > +		.name	= "s0",
> > +	},
> > +	[S1] = {
> > +		.start	= 0x71050000,
> > +		.end	= 0x710503ff,
> > +		.name	= "s1",
> > +	},
> > +	[S2] = {
> > +		.start	= 0x71060000,
> > +		.end	= 0x710603ff,
> > +		.name	= "s2",
> > +	},
> > +	[GCB] =	{
> > +		.start	= 0x71070000,
> > +		.end	= 0x7107022b,
> > +		.name	= "devcpu_gcb",
> > +	},
> > +};
> > +
> > +static const struct resource vsc7512_port_io_res[] = {
> > +	{
> > +		.start	= 0x711e0000,
> > +		.end	= 0x711effff,
> > +		.name	= "port0",
> > +	},
> > +	{
> > +		.start	= 0x711f0000,
> > +		.end	= 0x711fffff,
> > +		.name	= "port1",
> > +	},
> > +	{
> > +		.start	= 0x71200000,
> > +		.end	= 0x7120ffff,
> > +		.name	= "port2",
> > +	},
> > +	{
> > +		.start	= 0x71210000,
> > +		.end	= 0x7121ffff,
> > +		.name	= "port3",
> > +	},
> > +	{
> > +		.start	= 0x71220000,
> > +		.end	= 0x7122ffff,
> > +		.name	= "port4",
> > +	},
> > +	{
> > +		.start	= 0x71230000,
> > +		.end	= 0x7123ffff,
> > +		.name	= "port5",
> > +	},
> > +	{
> > +		.start	= 0x71240000,
> > +		.end	= 0x7124ffff,
> > +		.name	= "port6",
> > +	},
> > +	{
> > +		.start	= 0x71250000,
> > +		.end	= 0x7125ffff,
> > +		.name	= "port7",
> > +	},
> > +	{
> > +		.start	= 0x71260000,
> > +		.end	= 0x7126ffff,
> > +		.name	= "port8",
> > +	},
> > +	{
> > +		.start	= 0x71270000,
> > +		.end	= 0x7127ffff,
> > +		.name	= "port9",
> > +	},
> > +	{
> > +		.start	= 0x71280000,
> > +		.end	= 0x7128ffff,
> > +		.name	= "port10",
> > +	},
> > +};
> > +
> > +static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
> > +					unsigned long *supported,
> > +					struct phylink_link_state *state)
> > +{
> > +	struct ocelot_port *ocelot_port = ocelot->ports[port];
> > +
> > +	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > +
> > +	if (state->interface != PHY_INTERFACE_MODE_NA &&
> 
> This check is no longer necessary, please look again at the other
> phylink validation functions.
> 
> > +	    state->interface != ocelot_port->phy_mode) {
> 
> Also, I don't see what is the point of providing one phylink validation
> method only to replace it later in the patchset with the generic one.
> Please squash "net: dsa: ocelot: utilize phylink_generic_validate" into
> this.

Yes, that was a poor decision on my part to keep that patch separate. I
should have squashed it, since you already pointed this out last round
and that is exactly what the last commit of this series was addressing.

> 
> > +		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +		return;
> > +	}
> > +
> > +	phylink_set_port_modes(mask);
> > +
> > +	phylink_set(mask, Pause);
> > +	phylink_set(mask, Autoneg);
> > +	phylink_set(mask, Asym_Pause);
> > +	phylink_set(mask, 10baseT_Half);
> > +	phylink_set(mask, 10baseT_Full);
> > +	phylink_set(mask, 100baseT_Half);
> > +	phylink_set(mask, 100baseT_Full);
> > +	phylink_set(mask, 1000baseT_Half);
> > +	phylink_set(mask, 1000baseT_Full);
> > +
> > +	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +	bitmap_and(state->advertising, state->advertising, mask,
> > +		   __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +}
> > +
> > +static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
> > +					     struct resource *res)
> > +{
> > +	return ocelot_init_regmap_from_resource(ocelot->dev, res);
> > +}
> > +
> > +static const struct felix_info vsc7512_info = {
> > +	.target_io_res			= vsc7512_target_io_res,
> > +	.port_io_res			= vsc7512_port_io_res,
> > +	.regfields			= vsc7514_regfields,
> > +	.map				= vsc7512_regmap,
> > +	.ops				= &ocelot_ext_ops,
> > +	.stats_layout			= vsc7514_stats_layout,
> > +	.vcap				= vsc7514_vcap_props,
> > +	.num_mact_rows			= 1024,
> > +	.num_ports			= VSC7512_NUM_PORTS,
> > +	.num_tx_queues			= OCELOT_NUM_TC,
> > +	.phylink_validate		= ocelot_ext_phylink_validate,
> > +	.port_modes			= vsc7512_port_modes,
> > +	.init_regmap			= ocelot_ext_regmap_init,
> > +};
> > +
> > +static int ocelot_ext_probe(struct platform_device *pdev)
> > +{
> > +	struct dsa_switch *ds;
> > +	struct ocelot *ocelot;
> > +	struct felix *felix;
> > +	struct device *dev;
> > +	int err;
> > +
> > +	dev = &pdev->dev;
> 
> I would prefer if this assignment was part of the variable declaration.
> 
> > +
> > +	felix = kzalloc(sizeof(*felix), GFP_KERNEL);
> > +	if (!felix)
> > +		return -ENOMEM;
> > +
> > +	dev_set_drvdata(dev, felix);
> > +
> > +	ocelot = &felix->ocelot;
> > +	ocelot->dev = dev;
> > +
> > +	ocelot->num_flooding_pgids = 1;
> > +
> > +	felix->info = &vsc7512_info;
> > +
> > +	ds = kzalloc(sizeof(*ds), GFP_KERNEL);
> > +	if (!ds) {
> > +		err = -ENOMEM;
> > +		dev_err(dev, "Failed to allocate DSA switch\n");
> > +		goto err_free_felix;
> > +	}
> > +
> > +	ds->dev = dev;
> > +	ds->num_ports = felix->info->num_ports;
> > +	ds->num_tx_queues = felix->info->num_tx_queues;
> > +
> > +	ds->ops = &felix_switch_ops;
> > +	ds->priv = ocelot;
> > +	felix->ds = ds;
> > +	felix->tag_proto = DSA_TAG_PROTO_OCELOT;
> > +
> > +	err = dsa_register_switch(ds);
> > +	if (err) {
> > +		dev_err(dev, "Failed to register DSA switch: %d\n", err);
> 
> dev_err_probe please (look at the other drivers)
> 
> > +		goto err_free_ds;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_free_ds:
> > +	kfree(ds);
> > +err_free_felix:
> > +	kfree(felix);
> > +	return err;
> > +}
> > +
> > +static int ocelot_ext_remove(struct platform_device *pdev)
> > +{
> > +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> > +
> > +	if (!felix)
> > +		return 0;
> > +
> > +	dsa_unregister_switch(felix->ds);
> > +
> > +	kfree(felix->ds);
> > +	kfree(felix);
> > +
> > +	dev_set_drvdata(&pdev->dev, NULL);
> > +
> > +	return 0;
> > +}
> > +
> > +static void ocelot_ext_shutdown(struct platform_device *pdev)
> > +{
> > +	struct felix *felix = dev_get_drvdata(&pdev->dev);
> > +
> > +	if (!felix)
> > +		return;
> > +
> > +	dsa_switch_shutdown(felix->ds);
> > +
> > +	dev_set_drvdata(&pdev->dev, NULL);
> > +}
> > +
> > +const struct of_device_id ocelot_ext_switch_of_match[] = {
> 
> static
> 
> > +	{ .compatible = "mscc,vsc7512-ext-switch" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);
> > +
> > +static struct platform_driver ocelot_ext_switch_driver = {
> > +	.driver = {
> > +		.name = "ocelot-ext-switch",
> > +		.of_match_table = of_match_ptr(ocelot_ext_switch_of_match),
> > +	},
> > +	.probe = ocelot_ext_probe,
> > +	.remove = ocelot_ext_remove,
> > +	.shutdown = ocelot_ext_shutdown,
> > +};
> > +module_platform_driver(ocelot_ext_switch_driver);
> > +
> > +MODULE_DESCRIPTION("External Ocelot Switch driver");
> > +MODULE_LICENSE("GPL");
> > diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> > index 61888453f913..ade84e86741e 100644
> > --- a/include/soc/mscc/ocelot.h
> > +++ b/include/soc/mscc/ocelot.h
> > @@ -402,6 +402,8 @@ enum ocelot_reg {
> >  	GCB_MIIM_MII_STATUS,
> >  	GCB_MIIM_MII_CMD,
> >  	GCB_MIIM_MII_DATA,
> > +	GCB_PHY_PHY_CFG,
> > +	GCB_PHY_PHY_STAT,
> >  	DEV_CLOCK_CFG = DEV_GMII << TARGET_OFFSET,
> >  	DEV_PORT_MISC,
> >  	DEV_EVENTS,
> > -- 
> > 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] 114+ messages in thread

* Re: [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers
  2022-05-09 10:56     ` Vladimir Oltean
@ 2022-05-10  0:05       ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:05 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 10:56:39AM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:08AM -0700, Colin Foster wrote:
> > The ocelot_regfields struct is common between several different chips, some
> > of which can only be controlled externally. Export this structure so it
> > doesn't have to be duplicated in these other drivers.
> > 
> > Rename the structure as well, to follow the conventions of other shared
> > resources.
> > 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> 
> Doesn't the symbol need to be actually _exported_ (EXPORT_SYMBOL) to
> work when CONFIG_MSCC_OCELOT_SWITCH_LIB is a module?

Yes. I'll test the module configurations again before future rounds - I
admittedly haven't tested those cases in a while.

> 
> >  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 60 +---------------------
> >  drivers/net/ethernet/mscc/vsc7514_regs.c   | 59 +++++++++++++++++++++
> >  include/soc/mscc/vsc7514_regs.h            |  2 +
> >  3 files changed, 62 insertions(+), 59 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> > index 68d205088665..a13fec7247d6 100644
> > --- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> > +++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> > @@ -38,64 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
> >  	[DEV_GMII] = vsc7514_dev_gmii_regmap,
> >  };
> >  
> > -static const struct reg_field ocelot_regfields[REGFIELD_MAX] = {
> > -};
> > -
> >  static const struct ocelot_stat_layout ocelot_stats_layout[] = {
> >  	{ .name = "rx_octets", .offset = 0x00, },
> >  	{ .name = "rx_unicast", .offset = 0x01, },
> > @@ -231,7 +173,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
> >  	ocelot->num_mact_rows = 1024;
> >  	ocelot->ops = ops;
> >  
> > -	ret = ocelot_regfields_init(ocelot, ocelot_regfields);
> > +	ret = ocelot_regfields_init(ocelot, vsc7514_regfields);
> >  	if (ret)
> >  		return ret;
> >  
> > diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
> > index c2af4eb8ca5d..847e64d11075 100644
> > --- a/drivers/net/ethernet/mscc/vsc7514_regs.c
> > +++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
> > @@ -9,6 +9,65 @@
> >  #include <soc/mscc/vsc7514_regs.h>
> >  #include "ocelot.h"
> >  
> > +const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
> > +};
> > +
> >  const u32 vsc7514_ana_regmap[] = {
> >  	REG(ANA_ADVLEARN,				0x009000),
> >  	REG(ANA_VLANMASK,				0x009004),
> > diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
> > index ceee26c96959..9b40e7d00ec5 100644
> > --- a/include/soc/mscc/vsc7514_regs.h
> > +++ b/include/soc/mscc/vsc7514_regs.h
> > @@ -10,6 +10,8 @@
> >  
> >  #include <soc/mscc/ocelot_vcap.h>
> >  
> > +extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
> > +
> >  extern const u32 vsc7514_ana_regmap[];
> >  extern const u32 vsc7514_qs_regmap[];
> >  extern const u32 vsc7514_qsys_regmap[];
> > -- 
> > 2.25.1
> >

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers
@ 2022-05-10  0:05       ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:05 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 10:56:39AM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:08AM -0700, Colin Foster wrote:
> > The ocelot_regfields struct is common between several different chips, some
> > of which can only be controlled externally. Export this structure so it
> > doesn't have to be duplicated in these other drivers.
> > 
> > Rename the structure as well, to follow the conventions of other shared
> > resources.
> > 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> 
> Doesn't the symbol need to be actually _exported_ (EXPORT_SYMBOL) to
> work when CONFIG_MSCC_OCELOT_SWITCH_LIB is a module?

Yes. I'll test the module configurations again before future rounds - I
admittedly haven't tested those cases in a while.

> 
> >  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 60 +---------------------
> >  drivers/net/ethernet/mscc/vsc7514_regs.c   | 59 +++++++++++++++++++++
> >  include/soc/mscc/vsc7514_regs.h            |  2 +
> >  3 files changed, 62 insertions(+), 59 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/mscc/ocelot_vsc7514.c b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> > index 68d205088665..a13fec7247d6 100644
> > --- a/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> > +++ b/drivers/net/ethernet/mscc/ocelot_vsc7514.c
> > @@ -38,64 +38,6 @@ static const u32 *ocelot_regmap[TARGET_MAX] = {
> >  	[DEV_GMII] = vsc7514_dev_gmii_regmap,
> >  };
> >  
> > -static const struct reg_field ocelot_regfields[REGFIELD_MAX] = {
> > -};
> > -
> >  static const struct ocelot_stat_layout ocelot_stats_layout[] = {
> >  	{ .name = "rx_octets", .offset = 0x00, },
> >  	{ .name = "rx_unicast", .offset = 0x01, },
> > @@ -231,7 +173,7 @@ static int ocelot_chip_init(struct ocelot *ocelot, const struct ocelot_ops *ops)
> >  	ocelot->num_mact_rows = 1024;
> >  	ocelot->ops = ops;
> >  
> > -	ret = ocelot_regfields_init(ocelot, ocelot_regfields);
> > +	ret = ocelot_regfields_init(ocelot, vsc7514_regfields);
> >  	if (ret)
> >  		return ret;
> >  
> > diff --git a/drivers/net/ethernet/mscc/vsc7514_regs.c b/drivers/net/ethernet/mscc/vsc7514_regs.c
> > index c2af4eb8ca5d..847e64d11075 100644
> > --- a/drivers/net/ethernet/mscc/vsc7514_regs.c
> > +++ b/drivers/net/ethernet/mscc/vsc7514_regs.c
> > @@ -9,6 +9,65 @@
> >  #include <soc/mscc/vsc7514_regs.h>
> >  #include "ocelot.h"
> >  
> > +const struct reg_field vsc7514_regfields[REGFIELD_MAX] = {
> > +};
> > +
> >  const u32 vsc7514_ana_regmap[] = {
> >  	REG(ANA_ADVLEARN,				0x009000),
> >  	REG(ANA_VLANMASK,				0x009004),
> > diff --git a/include/soc/mscc/vsc7514_regs.h b/include/soc/mscc/vsc7514_regs.h
> > index ceee26c96959..9b40e7d00ec5 100644
> > --- a/include/soc/mscc/vsc7514_regs.h
> > +++ b/include/soc/mscc/vsc7514_regs.h
> > @@ -10,6 +10,8 @@
> >  
> >  #include <soc/mscc/ocelot_vcap.h>
> >  
> > +extern const struct reg_field vsc7514_regfields[REGFIELD_MAX];
> > +
> >  extern const u32 vsc7514_ana_regmap[];
> >  extern const u32 vsc7514_qs_regmap[];
> >  extern const u32 vsc7514_qsys_regmap[];
> > -- 
> > 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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-05-09 10:34     ` Vladimir Oltean
@ 2022-05-10  0:23       ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:23 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 10:34:45AM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:12AM -0700, Colin Foster wrote:
> > Add the ability for felix users to announce their capabilities to DSA
> > switches by way of phylink_get_caps. This will allow those users the
> > ability to use phylink_generic_validate, which otherwise wouldn't be
> > possible.
> > 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> >  drivers/net/dsa/ocelot/felix.c | 22 +++++++++++++++-------
> >  drivers/net/dsa/ocelot/felix.h |  2 ++
> >  2 files changed, 17 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
> > index d09408baaab7..32ed093f47c6 100644
> > --- a/drivers/net/dsa/ocelot/felix.c
> > +++ b/drivers/net/dsa/ocelot/felix.c
> > @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
> >  				   struct phylink_config *config)
> >  {
> >  	struct ocelot *ocelot = ds->priv;
> > +	struct felix *felix;
> >  
> > -	/* This driver does not make use of the speed, duplex, pause or the
> > -	 * advertisement in its mac_config, so it is safe to mark this driver
> > -	 * as non-legacy.
> > -	 */
> > -	config->legacy_pre_march2020 = false;
> > +	felix = ocelot_to_felix(ocelot);
> > +
> > +	if (felix->info->phylink_get_caps) {
> > +		felix->info->phylink_get_caps(ocelot, port, config);
> > +	} else {
> >  
> > -	__set_bit(ocelot->ports[port]->phy_mode,
> > -		  config->supported_interfaces);
> > +		/* This driver does not make use of the speed, duplex, pause or
> > +		 * the advertisement in its mac_config, so it is safe to mark
> > +		 * this driver as non-legacy.
> > +		 */
> > +		config->legacy_pre_march2020 = false;
> 
> I don't think you mean to set legacy_pre_march2020 to true only
> felix->info->phylink_get_caps is absent, do you?
> 
> Also, I'm thinking maybe we could provide an implementation of this
> function for all switches, not just for vsc7512.

I had assumed these last two patches might spark more discussion, which
is why I kept them separate (specifically the last patch).

With this, are you simply suggesting to take everything that is
currently in felix_phylink_get_caps and doing it in the felix / seville
implementations? This is because the default condition is no longer the
"only" condition. Sounds easy enough.

> 
> > +
> > +		__set_bit(ocelot->ports[port]->phy_mode,
> > +			  config->supported_interfaces);
> > +	}
> >  }
> >  
> >  static void felix_phylink_validate(struct dsa_switch *ds, int port,
> > diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
> > index 3ecac79bbf09..33281370f415 100644
> > --- a/drivers/net/dsa/ocelot/felix.h
> > +++ b/drivers/net/dsa/ocelot/felix.h
> > @@ -57,6 +57,8 @@ struct felix_info {
> >  					u32 speed);
> >  	struct regmap *(*init_regmap)(struct ocelot *ocelot,
> >  				      struct resource *res);
> > +	void	(*phylink_get_caps)(struct ocelot *ocelot, int port,
> > +				    struct phylink_config *pl_config);
> >  };
> >  
> >  extern const struct dsa_switch_ops felix_switch_ops;
> > -- 
> > 2.25.1
> >

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-05-10  0:23       ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:23 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 10:34:45AM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:12AM -0700, Colin Foster wrote:
> > Add the ability for felix users to announce their capabilities to DSA
> > switches by way of phylink_get_caps. This will allow those users the
> > ability to use phylink_generic_validate, which otherwise wouldn't be
> > possible.
> > 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> >  drivers/net/dsa/ocelot/felix.c | 22 +++++++++++++++-------
> >  drivers/net/dsa/ocelot/felix.h |  2 ++
> >  2 files changed, 17 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
> > index d09408baaab7..32ed093f47c6 100644
> > --- a/drivers/net/dsa/ocelot/felix.c
> > +++ b/drivers/net/dsa/ocelot/felix.c
> > @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
> >  				   struct phylink_config *config)
> >  {
> >  	struct ocelot *ocelot = ds->priv;
> > +	struct felix *felix;
> >  
> > -	/* This driver does not make use of the speed, duplex, pause or the
> > -	 * advertisement in its mac_config, so it is safe to mark this driver
> > -	 * as non-legacy.
> > -	 */
> > -	config->legacy_pre_march2020 = false;
> > +	felix = ocelot_to_felix(ocelot);
> > +
> > +	if (felix->info->phylink_get_caps) {
> > +		felix->info->phylink_get_caps(ocelot, port, config);
> > +	} else {
> >  
> > -	__set_bit(ocelot->ports[port]->phy_mode,
> > -		  config->supported_interfaces);
> > +		/* This driver does not make use of the speed, duplex, pause or
> > +		 * the advertisement in its mac_config, so it is safe to mark
> > +		 * this driver as non-legacy.
> > +		 */
> > +		config->legacy_pre_march2020 = false;
> 
> I don't think you mean to set legacy_pre_march2020 to true only
> felix->info->phylink_get_caps is absent, do you?
> 
> Also, I'm thinking maybe we could provide an implementation of this
> function for all switches, not just for vsc7512.

I had assumed these last two patches might spark more discussion, which
is why I kept them separate (specifically the last patch).

With this, are you simply suggesting to take everything that is
currently in felix_phylink_get_caps and doing it in the felix / seville
implementations? This is because the default condition is no longer the
"only" condition. Sounds easy enough.

> 
> > +
> > +		__set_bit(ocelot->ports[port]->phy_mode,
> > +			  config->supported_interfaces);
> > +	}
> >  }
> >  
> >  static void felix_phylink_validate(struct dsa_switch *ds, int port,
> > diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
> > index 3ecac79bbf09..33281370f415 100644
> > --- a/drivers/net/dsa/ocelot/felix.h
> > +++ b/drivers/net/dsa/ocelot/felix.h
> > @@ -57,6 +57,8 @@ struct felix_info {
> >  					u32 speed);
> >  	struct regmap *(*init_regmap)(struct ocelot *ocelot,
> >  				      struct resource *res);
> > +	void	(*phylink_get_caps)(struct ocelot *ocelot, int port,
> > +				    struct phylink_config *pl_config);
> >  };
> >  
> >  extern const struct dsa_switch_ops felix_switch_ops;
> > -- 
> > 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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-09 17:20         ` Vladimir Oltean
@ 2022-05-10  0:30           ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:30 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:20:29PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > +						const struct resource *res)
> > > > +{
> > > > +	struct device *dev = child->parent;
> > > > +
> > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > 
> > > So much for being bus-agnostic :-/
> > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > 
> > That was my initial design. "core" was calling into "spi" exclusively
> > via function pointers.
> > 
> > The request was "Please find a clearer way to do this without function
> > pointers"
> > 
> > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> 
> Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> with the comment that you aren't configuring a bus. In this context it
> seems more appropriate to call this function pointer "init_regmap", with
> different implementations per transport.
> 
> Or alternatively you could leave the "core"/"spi" pseudo-separation up
> to the next person who needs to add support for some other register I/O
> method.

That's true. If it comes down to it I can do that. Though I really do
like having the SPI-specific stuff clearly separated, I can bring them
together if it speeds things up. I'll wait for feedback.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-10  0:30           ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:30 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:20:29PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > +						const struct resource *res)
> > > > +{
> > > > +	struct device *dev = child->parent;
> > > > +
> > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > 
> > > So much for being bus-agnostic :-/
> > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > 
> > That was my initial design. "core" was calling into "spi" exclusively
> > via function pointers.
> > 
> > The request was "Please find a clearer way to do this without function
> > pointers"
> > 
> > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> 
> Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> with the comment that you aren't configuring a bus. In this context it
> seems more appropriate to call this function pointer "init_regmap", with
> different implementations per transport.
> 
> Or alternatively you could leave the "core"/"spi" pseudo-separation up
> to the next person who needs to add support for some other register I/O
> method.

That's true. If it comes down to it I can do that. Though I really do
like having the SPI-specific stuff clearly separated, I can bring them
together if it speeds things up. I'll wait for feedback.

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-05-09 17:30         ` Vladimir Oltean
@ 2022-05-10  0:55           ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:55 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:30:30PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 05:23:32PM -0700, Colin Foster wrote:
> > > > @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
> > > >  				   struct phylink_config *config)
> > > >  {
> > > >  	struct ocelot *ocelot = ds->priv;
> > > > +	struct felix *felix;
> > > >  
> > > > -	/* This driver does not make use of the speed, duplex, pause or the
> > > > -	 * advertisement in its mac_config, so it is safe to mark this driver
> > > > -	 * as non-legacy.
> > > > -	 */
> > > > -	config->legacy_pre_march2020 = false;
> > > > +	felix = ocelot_to_felix(ocelot);
> > > > +
> > > > +	if (felix->info->phylink_get_caps) {
> > > > +		felix->info->phylink_get_caps(ocelot, port, config);
> > > > +	} else {
> > > >  
> > > > -	__set_bit(ocelot->ports[port]->phy_mode,
> > > > -		  config->supported_interfaces);
> > > > +		/* This driver does not make use of the speed, duplex, pause or
> > > > +		 * the advertisement in its mac_config, so it is safe to mark
> > > > +		 * this driver as non-legacy.
> > > > +		 */
> > > > +		config->legacy_pre_march2020 = false;
> > > 
> > > I don't think you mean to set legacy_pre_march2020 to true only
> > > felix->info->phylink_get_caps is absent, do you?
> > > 
> > > Also, I'm thinking maybe we could provide an implementation of this
> > > function for all switches, not just for vsc7512.
> > 
> > I had assumed these last two patches might spark more discussion, which
> > is why I kept them separate (specifically the last patch).
> > 
> > With this, are you simply suggesting to take everything that is
> > currently in felix_phylink_get_caps and doing it in the felix / seville
> > implementations? This is because the default condition is no longer the
> > "only" condition. Sounds easy enough.
> 
> No, not everything, just the way in which config->supported_interfaces
> is populated. We have different PCS implementations, so it's likely that
> the procedures to retrieve the valid SERDES protocols (when changing
> them will be supported) are different.
> 
> But in fact I seriously doubt that the current way in which supported_interfaces
> gets populated is limiting you from doing anything right now, precisely
> because you don't have any code that supports changing the phy-mode.

Hmm... So the main reason I needed get_caps was because
phylink_generic_validate looks at mac_capabilities. I know I'll have to
deal with supported_interfaces once I finally get the other four ports
working, but for now the main purpose of this patch is to allow me to
populate the mac_capabilities entry for phylink_generic_validate.

Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
of the patch makes sense.

> 
> Also, it's unlikely (I'd say impossible) for one driver to be
> unconverted to the post-March-2020 requirements and the other not to be.
> The simple reason is that they share the same mac_config implementation.
> So it's perfectly ok to keep "config->legacy_pre_march2020 = false"
> right where it is.
> 
> So I'd say it's up to you, but I'd drop this patch right now.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-05-10  0:55           ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  0:55 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:30:30PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 05:23:32PM -0700, Colin Foster wrote:
> > > > @@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
> > > >  				   struct phylink_config *config)
> > > >  {
> > > >  	struct ocelot *ocelot = ds->priv;
> > > > +	struct felix *felix;
> > > >  
> > > > -	/* This driver does not make use of the speed, duplex, pause or the
> > > > -	 * advertisement in its mac_config, so it is safe to mark this driver
> > > > -	 * as non-legacy.
> > > > -	 */
> > > > -	config->legacy_pre_march2020 = false;
> > > > +	felix = ocelot_to_felix(ocelot);
> > > > +
> > > > +	if (felix->info->phylink_get_caps) {
> > > > +		felix->info->phylink_get_caps(ocelot, port, config);
> > > > +	} else {
> > > >  
> > > > -	__set_bit(ocelot->ports[port]->phy_mode,
> > > > -		  config->supported_interfaces);
> > > > +		/* This driver does not make use of the speed, duplex, pause or
> > > > +		 * the advertisement in its mac_config, so it is safe to mark
> > > > +		 * this driver as non-legacy.
> > > > +		 */
> > > > +		config->legacy_pre_march2020 = false;
> > > 
> > > I don't think you mean to set legacy_pre_march2020 to true only
> > > felix->info->phylink_get_caps is absent, do you?
> > > 
> > > Also, I'm thinking maybe we could provide an implementation of this
> > > function for all switches, not just for vsc7512.
> > 
> > I had assumed these last two patches might spark more discussion, which
> > is why I kept them separate (specifically the last patch).
> > 
> > With this, are you simply suggesting to take everything that is
> > currently in felix_phylink_get_caps and doing it in the felix / seville
> > implementations? This is because the default condition is no longer the
> > "only" condition. Sounds easy enough.
> 
> No, not everything, just the way in which config->supported_interfaces
> is populated. We have different PCS implementations, so it's likely that
> the procedures to retrieve the valid SERDES protocols (when changing
> them will be supported) are different.
> 
> But in fact I seriously doubt that the current way in which supported_interfaces
> gets populated is limiting you from doing anything right now, precisely
> because you don't have any code that supports changing the phy-mode.

Hmm... So the main reason I needed get_caps was because
phylink_generic_validate looks at mac_capabilities. I know I'll have to
deal with supported_interfaces once I finally get the other four ports
working, but for now the main purpose of this patch is to allow me to
populate the mac_capabilities entry for phylink_generic_validate.

Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
of the patch makes sense.

> 
> Also, it's unlikely (I'd say impossible) for one driver to be
> unconverted to the post-March-2020 requirements and the other not to be.
> The simple reason is that they share the same mac_config implementation.
> So it's perfectly ok to keep "config->legacy_pre_march2020 = false"
> right where it is.
> 
> So I'd say it's up to you, but I'd drop this patch right now.

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-09 17:13   ` Vladimir Oltean
@ 2022-05-10  1:43     ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  1:43 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sun, May 08, 2022 at 11:52:57AM -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. The driver is believed to be fully functional for the internal
> > phy ports (0-3)  on the VSC7512. It is not yet functional for SGMII,
> > QSGMII, and SerDes ports.
> > 
> > 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.
> > 
> > The relevant sections of the device tree I'm using for the VSC7512 is
> > below. Notably the SGPIO LEDs follow link status and speed from network
> > triggers.
> > 
> > In order to make this work, I have modified the cpsw driver, and now the
> > cpsw_new driver, to allow for frames over 1500 bytes. Otherwise the
> > tagging protocol will not work between the beaglebone and the VSC7512. I
> > plan to eventually try to get those changes in mainline, but I don't
> > want to get distracted from my initial goal. I also had to change
> > bonecommon.dtsi to avoid using VLAN 0.
> 
> This ti,dual-emac-pvid thing is a really odd thing to put in the device
> tree. But what's the problem with VLAN 0 anyway?

Ahh, I see that was an exchange between me and Grygorii Strashko that
wasn't public. Looking now, it might be VLAN 1...

I'd see "failed to initialize vlan filtering" when I ran "ip link set
dev swp1 master br0" because the default bridge vlan conflicted with
slave_data->dual_emac_res_vlan = port_id;
(drivers/net/ethernet/ti/cpsw_new.c, around line 1325)

My initial attempt was to just change cpsw_port1
ti,dual-emac-pvid=<12>; but that didn't change the behavior. Maybe if I
went back to it again, seeing as I'm much older and wiser than I was
before, I could find the correct device tree solution... Ideally I think
I should have the ability to not enable cpsw_port1 and be good.

But I think the magic was really just to set
slave_data->dual_emac_res_vlan = 10 + port_id; to avoid conflicts.


This became an issue at 5.15, when cpsw_new was rolled in to the .dtsis
I've been using.

> 
> > 
> > I believe much of the MFD sections are very near feature-complete,
> > whereas the switch section will require ongoing work to enable
> > additional ports / features. This could lead to a couple potential
> > scenarios:
> > 
> > The first being patches 1-8 being split into a separate patch set, while
> > patches 9-16 remain in the RFC state. This would offer the pinctrl /
> > sgpio / mdio controller functionality, but no switch control until it is
> > ready.
> > 
> > The second would assume the current state of the switch driver is
> > acceptable (or at least very near so) and the current patch set gets an
> > official PATCH set (with minor changes as necessary - e.g. squashing
> > patch 16 into 14). That might be ambitious.
> > 
> > The third would be to keep this patch set in RFC until switch
> > functionality is more complete. I'd understand if this was the desired
> > path... but it would mean me having to bug more reviewers.
> 
> Considering that the merge window is approaching, I'd say get the
> non-DSA stuff accepted until then, then repost the DSA stuff in ~3 weeks
> from now as non-RFC, once v5.18 is cut and the development for v5.20
> (or whatever the number will be) begins.

That's the approach I'd prefer as well.

> 
> > / {
> > 	vscleds {
> > 		compatible = "gpio-leds";
> > 		vscled@0 {
> > 			label = "port0led";
> > 			gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
> > 			default-state = "off";
> > 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:link";
> > 		};
> > 		vscled@1 {
> > 			label = "port0led1";
> > 			gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
> > 			default-state = "off";
> > 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:1Gbps";
> > 		};
> > [ ... ]
> > 	};
> > };
> > 
> > &spi0 {
> > 	#address-cells = <1>;
> > 	#size-cells = <0>;
> > 	status = "okay";
> > 
> > 	ocelot-chip@0 {
> > 		compatible = "mscc,vsc7512_mfd_spi";
> 
> Can you use hyphens instead of underscores in this compatible string?
> 
> > 		spi-max-frequency = <2500000>;
> > 		reg = <0>;
> > 
> > 		ethernet-switch@0 {
> 
> I don't think the switch node should have any address?
> 
> > 			compatible = "mscc,vsc7512-ext-switch";
> > 			ports {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 
> > 				port@0 {
> > 					reg = <0>;
> > 					label = "cpu";
> > 					status = "okay";
> > 					ethernet = <&mac_sw>;
> > 					phy-handle = <&sw_phy0>;
> > 					phy-mode = "internal";
> > 				};
> > 
> > 				port@1 {
> > 					reg = <1>;
> > 					label = "swp1";
> > 					status = "okay";
> > 					phy-handle = <&sw_phy1>;
> > 					phy-mode = "internal";
> > 				};
> > 			};
> > 		};
> > 
> > 		mdio0: mdio0@0 {
> 
> This is going to be interesting. Some drivers with multiple MDIO buses
> create an "mdios" container with #address-cells = <1> and put the MDIO
> bus nodes under that. Others create an "mdio" node and an "mdio0" node
> (and no address for either of them).
> 
> The problem with the latter approach is that
> Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> "mdio0"/"mdio1" node name for an MDIO bus.

Hmm... That'll be interesting indeed. The 7514
(arch/mips/boot/dts/mscc/ocelot.dtsi) is where I undoubtedly started.
Is there an issue with the 7514, or is it just an issue with my
implementation, which should be:

mdio0: mdio@0 {

instead of mdio0@0?

> 
> > 			compatible = "mscc,ocelot-miim";
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy0: ethernet-phy@0 {
> > 				reg = <0x0>;
> > 			};
> > 
> > 			sw_phy1: ethernet-phy@1 {
> > 				reg = <0x1>;
> > 			};
> > 
> > 			sw_phy2: ethernet-phy@2 {
> > 				reg = <0x2>;
> > 			};
> > 
> > 			sw_phy3: ethernet-phy@3 {
> > 				reg = <0x3>;
> > 			};
> > 		};
> > 
> > 		mdio1: mdio1@1 {
> > 			compatible = "mscc,ocelot-miim";
> > 			pinctrl-names = "default";
> > 			pinctrl-0 = <&miim1>;
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy4: ethernet-phy@4 {
> > 				reg = <0x4>;
> > 			};
> > 
> > 			sw_phy5: ethernet-phy@5 {
> > 				reg = <0x5>;
> > 			};
> > 
> > 			sw_phy6: ethernet-phy@6 {
> > 				reg = <0x6>;
> > 			};
> > 
> > 			sw_phy7: ethernet-phy@7 {
> > 				reg = <0x7>;
> > 			};
> > 		};
> > 
> > 		gpio: pinctrl@0 {
> 
> Similar thing with the address. All these @0 addresses actually conflict
> with each other.
> 
> > 			compatible = "mscc,ocelot-pinctrl";
> > 			gpio-controller;
> > 			#gpio_cells = <2>;
> > 			gpio-ranges = <&gpio 0 0 22>;
> > 
> > 			led_shift_reg_pins: led-shift-reg-pins {
> > 				pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
> > 				function = "sg0";
> > 			};
> > 
> > 			miim1: miim1 {
> > 				pins = "GPIO_14", "GPIO_15";
> > 				function = "miim";
> > 			};
> > 		};
> > 
> > 		sgpio: sgpio {
> 
> And mixing nodes with addresses with nodes without addresses is broken too.
> 
> > 			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 = <&led_shift_reg_pins>;
> > 
> > 			sgpio_in0: sgpio@0 {
> > 				compatible = "microchip,sparx5-sgpio-bank";
> > 				reg = <0>;
> > 				gpio-controller;
> > 				#gpio-cells = <3>;
> > 				ngpios = <64>;
> > 			};
> > 
> > 			sgpio_out1: sgpio@1 {
> > 				compatible = "microchip,sparx5-sgpio-bank";
> > 				reg = <1>;
> > 				gpio-controller;
> > 				#gpio-cells = <3>;
> > 				ngpios = <64>;
> > 			};
> > 		};
> > 	};
> > };
> > 
> > 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.
> > 
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 5.18.0-rc5-01295-g47053e327c52 (X@X) (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #630 SMP PREEMPT Sun May 8 10:56:51 PDT 2022
> > ...
> > [    2.829319] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set
> 
> Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?

I'll run that tonight.

> 
> > [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> > [    2.842717] gpiochip_find_base: found new base at 2026
> > [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> > [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> > [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> > [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> > [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> > [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> > [    2.870801] gpiochip_find_base: found new base at 1962
> > [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> > [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> > [    2.872364] gpiochip_find_base: found new base at 1898
> > [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> > [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> > [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
> > [    2.886929] mscc-miim ocelot-miim0.2.auto: invalid resource
> > [    2.893738] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
> > [    2.893769] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
> > [    2.893802] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> > [    2.893898] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> > [    2.893996] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
> > [    2.894012] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
> > [    3.395738] mdio_bus ocelot-miim0.2.auto-mii:00: GPIO lookup for consumer reset
> > [    3.395777] mdio_bus ocelot-miim0.2.auto-mii:00: using device tree for GPIO lookup
> > [    3.395840] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> > [    3.395959] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> > [    3.396069] mdio_bus ocelot-miim0.2.auto-mii:00: using lookup tables for GPIO lookup
> > [    3.396086] mdio_bus ocelot-miim0.2.auto-mii:00: No GPIO consumer reset found
> > ...
> > [    3.449187] ocelot-ext-switch ocelot-ext-switch.4.auto: DMA mask not set
> > [    5.336880] ocelot-ext-switch ocelot-ext-switch.4.auto: PHY [ocelot-miim0.2.auto-mii:00] driver [Generic PHY] (irq=POLL)
> > [    5.349087] ocelot-ext-switch ocelot-ext-switch.4.auto: configuring for phy/internal link mode
> > [    5.363619] ocelot-ext-switch ocelot-ext-switch.4.auto swp1 (uninitialized): PHY [ocelot-miim0.2.auto-mii:01] driver [Generic PHY] (irq=POLL)
> > [    5.381396] ocelot-ext-switch ocelot-ext-switch.4.auto swp2 (uninitialized): PHY [ocelot-miim0.2.auto-mii:02] driver [Generic PHY] (irq=POLL)
> > [    5.398525] ocelot-ext-switch ocelot-ext-switch.4.auto swp3 (uninitialized): PHY [ocelot-miim0.2.auto-mii:03] driver [Generic PHY] (irq=POLL)
> 
> Do the PHYs not have a specific driver?

When I have the other four ports defined, those correctly find the
vsc85xx driver, perform serdes calibration, etc. (assuming I have that
phy support compiled in) The internal phys I believe have always just
been using a generic driver.

> 
> > [    5.422048] device eth0 entered promiscuous mode
> > [    5.426785] DSA: tree 0 setup
> > ...
> > [    7.450067] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> > [   21.556395] cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
> > [   21.648564] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
> > [   21.667970] 8021q: adding VLAN 0 to HW filter on device eth0
> > [   21.705360] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: configuring for phy/internal link mode
> > [   22.018230] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Down
> > [   23.771740] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
> > [   24.090929] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> > [   25.853021] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: Link is Up - 1Gbps/Full - flow control rx/tx
> > 
> > 
> > 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
> 
> bus -> bulk?

Either is probably valid. Here I'm referencing struct regmap_bus, 
so _regmap_bus_read allows the utilization of bulk transfers for stats.

> 
> >       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
> > 
> > 
> > Colin Foster (16):
> >   pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
> >   pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
> >   net: ocelot: add interface to get regmaps when exernally controlled
> >   net: mdio: mscc-miim: add ability to be used in a non-mmio
> >     configuration
> >   pinctrl: ocelot: add ability to be used in a non-mmio configuration
> >   pinctrl: microchip-sgpio: add ability to be used in a non-mmio
> >     configuration
> >   resource: add define macro for register address resources
> >   mfd: ocelot: add support for the vsc7512 chip via spi
> >   net: mscc: ocelot: expose ocelot wm functions
> >   net: dsa: felix: add configurable device quirks
> >   net: mscc: ocelot: expose regfield definition to be used by other
> >     drivers
> >   net: mscc: ocelot: expose stats layout definition to be used by other
> >     drivers
> >   net: mscc: ocelot: expose vcap_props structure
> >   net: dsa: ocelot: add external ocelot switch control
> >   net: dsa: felix: add phylink_get_caps capability
> >   net: dsa: ocelot: utilize phylink_generic_validate
> > 
> >  drivers/mfd/Kconfig                        |  18 +
> >  drivers/mfd/Makefile                       |   2 +
> >  drivers/mfd/ocelot-core.c                  | 138 ++++++++
> >  drivers/mfd/ocelot-spi.c                   | 311 +++++++++++++++++
> >  drivers/mfd/ocelot.h                       |  34 ++
> >  drivers/net/dsa/ocelot/Kconfig             |  14 +
> >  drivers/net/dsa/ocelot/Makefile            |   5 +
> >  drivers/net/dsa/ocelot/felix.c             |  29 +-
> >  drivers/net/dsa/ocelot/felix.h             |   3 +
> >  drivers/net/dsa/ocelot/felix_vsc9959.c     |   1 +
> >  drivers/net/dsa/ocelot/ocelot_ext.c        | 366 +++++++++++++++++++++
> >  drivers/net/dsa/ocelot/seville_vsc9953.c   |   1 +
> >  drivers/net/ethernet/mscc/ocelot_devlink.c |  31 ++
> >  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 230 +------------
> >  drivers/net/ethernet/mscc/vsc7514_regs.c   | 200 +++++++++++
> >  drivers/net/mdio/mdio-mscc-miim.c          |  31 +-
> >  drivers/pinctrl/Kconfig                    |   4 +-
> >  drivers/pinctrl/pinctrl-microchip-sgpio.c  |  26 +-
> >  drivers/pinctrl/pinctrl-ocelot.c           |  35 +-
> >  include/linux/ioport.h                     |   5 +
> >  include/soc/mscc/ocelot.h                  |  19 ++
> >  include/soc/mscc/vsc7514_regs.h            |   6 +
> >  22 files changed, 1251 insertions(+), 258 deletions(-)
> >  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 drivers/net/dsa/ocelot/ocelot_ext.c
> > 
> > -- 
> > 2.25.1
> >

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-10  1:43     ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  1:43 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sun, May 08, 2022 at 11:52:57AM -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. The driver is believed to be fully functional for the internal
> > phy ports (0-3)  on the VSC7512. It is not yet functional for SGMII,
> > QSGMII, and SerDes ports.
> > 
> > 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.
> > 
> > The relevant sections of the device tree I'm using for the VSC7512 is
> > below. Notably the SGPIO LEDs follow link status and speed from network
> > triggers.
> > 
> > In order to make this work, I have modified the cpsw driver, and now the
> > cpsw_new driver, to allow for frames over 1500 bytes. Otherwise the
> > tagging protocol will not work between the beaglebone and the VSC7512. I
> > plan to eventually try to get those changes in mainline, but I don't
> > want to get distracted from my initial goal. I also had to change
> > bonecommon.dtsi to avoid using VLAN 0.
> 
> This ti,dual-emac-pvid thing is a really odd thing to put in the device
> tree. But what's the problem with VLAN 0 anyway?

Ahh, I see that was an exchange between me and Grygorii Strashko that
wasn't public. Looking now, it might be VLAN 1...

I'd see "failed to initialize vlan filtering" when I ran "ip link set
dev swp1 master br0" because the default bridge vlan conflicted with
slave_data->dual_emac_res_vlan = port_id;
(drivers/net/ethernet/ti/cpsw_new.c, around line 1325)

My initial attempt was to just change cpsw_port1
ti,dual-emac-pvid=<12>; but that didn't change the behavior. Maybe if I
went back to it again, seeing as I'm much older and wiser than I was
before, I could find the correct device tree solution... Ideally I think
I should have the ability to not enable cpsw_port1 and be good.

But I think the magic was really just to set
slave_data->dual_emac_res_vlan = 10 + port_id; to avoid conflicts.


This became an issue at 5.15, when cpsw_new was rolled in to the .dtsis
I've been using.

> 
> > 
> > I believe much of the MFD sections are very near feature-complete,
> > whereas the switch section will require ongoing work to enable
> > additional ports / features. This could lead to a couple potential
> > scenarios:
> > 
> > The first being patches 1-8 being split into a separate patch set, while
> > patches 9-16 remain in the RFC state. This would offer the pinctrl /
> > sgpio / mdio controller functionality, but no switch control until it is
> > ready.
> > 
> > The second would assume the current state of the switch driver is
> > acceptable (or at least very near so) and the current patch set gets an
> > official PATCH set (with minor changes as necessary - e.g. squashing
> > patch 16 into 14). That might be ambitious.
> > 
> > The third would be to keep this patch set in RFC until switch
> > functionality is more complete. I'd understand if this was the desired
> > path... but it would mean me having to bug more reviewers.
> 
> Considering that the merge window is approaching, I'd say get the
> non-DSA stuff accepted until then, then repost the DSA stuff in ~3 weeks
> from now as non-RFC, once v5.18 is cut and the development for v5.20
> (or whatever the number will be) begins.

That's the approach I'd prefer as well.

> 
> > / {
> > 	vscleds {
> > 		compatible = "gpio-leds";
> > 		vscled@0 {
> > 			label = "port0led";
> > 			gpios = <&sgpio_out1 0 0 GPIO_ACTIVE_LOW>;
> > 			default-state = "off";
> > 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:link";
> > 		};
> > 		vscled@1 {
> > 			label = "port0led1";
> > 			gpios = <&sgpio_out1 0 1 GPIO_ACTIVE_LOW>;
> > 			default-state = "off";
> > 			linux,default-trigger = "ocelot-miim0.2.auto-mii:00:1Gbps";
> > 		};
> > [ ... ]
> > 	};
> > };
> > 
> > &spi0 {
> > 	#address-cells = <1>;
> > 	#size-cells = <0>;
> > 	status = "okay";
> > 
> > 	ocelot-chip@0 {
> > 		compatible = "mscc,vsc7512_mfd_spi";
> 
> Can you use hyphens instead of underscores in this compatible string?
> 
> > 		spi-max-frequency = <2500000>;
> > 		reg = <0>;
> > 
> > 		ethernet-switch@0 {
> 
> I don't think the switch node should have any address?
> 
> > 			compatible = "mscc,vsc7512-ext-switch";
> > 			ports {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 
> > 				port@0 {
> > 					reg = <0>;
> > 					label = "cpu";
> > 					status = "okay";
> > 					ethernet = <&mac_sw>;
> > 					phy-handle = <&sw_phy0>;
> > 					phy-mode = "internal";
> > 				};
> > 
> > 				port@1 {
> > 					reg = <1>;
> > 					label = "swp1";
> > 					status = "okay";
> > 					phy-handle = <&sw_phy1>;
> > 					phy-mode = "internal";
> > 				};
> > 			};
> > 		};
> > 
> > 		mdio0: mdio0@0 {
> 
> This is going to be interesting. Some drivers with multiple MDIO buses
> create an "mdios" container with #address-cells = <1> and put the MDIO
> bus nodes under that. Others create an "mdio" node and an "mdio0" node
> (and no address for either of them).
> 
> The problem with the latter approach is that
> Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> "mdio0"/"mdio1" node name for an MDIO bus.

Hmm... That'll be interesting indeed. The 7514
(arch/mips/boot/dts/mscc/ocelot.dtsi) is where I undoubtedly started.
Is there an issue with the 7514, or is it just an issue with my
implementation, which should be:

mdio0: mdio@0 {

instead of mdio0@0?

> 
> > 			compatible = "mscc,ocelot-miim";
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy0: ethernet-phy@0 {
> > 				reg = <0x0>;
> > 			};
> > 
> > 			sw_phy1: ethernet-phy@1 {
> > 				reg = <0x1>;
> > 			};
> > 
> > 			sw_phy2: ethernet-phy@2 {
> > 				reg = <0x2>;
> > 			};
> > 
> > 			sw_phy3: ethernet-phy@3 {
> > 				reg = <0x3>;
> > 			};
> > 		};
> > 
> > 		mdio1: mdio1@1 {
> > 			compatible = "mscc,ocelot-miim";
> > 			pinctrl-names = "default";
> > 			pinctrl-0 = <&miim1>;
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy4: ethernet-phy@4 {
> > 				reg = <0x4>;
> > 			};
> > 
> > 			sw_phy5: ethernet-phy@5 {
> > 				reg = <0x5>;
> > 			};
> > 
> > 			sw_phy6: ethernet-phy@6 {
> > 				reg = <0x6>;
> > 			};
> > 
> > 			sw_phy7: ethernet-phy@7 {
> > 				reg = <0x7>;
> > 			};
> > 		};
> > 
> > 		gpio: pinctrl@0 {
> 
> Similar thing with the address. All these @0 addresses actually conflict
> with each other.
> 
> > 			compatible = "mscc,ocelot-pinctrl";
> > 			gpio-controller;
> > 			#gpio_cells = <2>;
> > 			gpio-ranges = <&gpio 0 0 22>;
> > 
> > 			led_shift_reg_pins: led-shift-reg-pins {
> > 				pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
> > 				function = "sg0";
> > 			};
> > 
> > 			miim1: miim1 {
> > 				pins = "GPIO_14", "GPIO_15";
> > 				function = "miim";
> > 			};
> > 		};
> > 
> > 		sgpio: sgpio {
> 
> And mixing nodes with addresses with nodes without addresses is broken too.
> 
> > 			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 = <&led_shift_reg_pins>;
> > 
> > 			sgpio_in0: sgpio@0 {
> > 				compatible = "microchip,sparx5-sgpio-bank";
> > 				reg = <0>;
> > 				gpio-controller;
> > 				#gpio-cells = <3>;
> > 				ngpios = <64>;
> > 			};
> > 
> > 			sgpio_out1: sgpio@1 {
> > 				compatible = "microchip,sparx5-sgpio-bank";
> > 				reg = <1>;
> > 				gpio-controller;
> > 				#gpio-cells = <3>;
> > 				ngpios = <64>;
> > 			};
> > 		};
> > 	};
> > };
> > 
> > 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.
> > 
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 5.18.0-rc5-01295-g47053e327c52 (X@X) (arm-linux-gnueabi-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #630 SMP PREEMPT Sun May 8 10:56:51 PDT 2022
> > ...
> > [    2.829319] pinctrl-ocelot ocelot-pinctrl.0.auto: DMA mask not set
> 
> Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?

I'll run that tonight.

> 
> > [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> > [    2.842717] gpiochip_find_base: found new base at 2026
> > [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> > [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> > [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> > [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> > [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> > [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> > [    2.870801] gpiochip_find_base: found new base at 1962
> > [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> > [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> > [    2.872364] gpiochip_find_base: found new base at 1898
> > [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> > [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> > [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
> > [    2.886929] mscc-miim ocelot-miim0.2.auto: invalid resource
> > [    2.893738] mdio_bus ocelot-miim0.2.auto-mii: GPIO lookup for consumer reset
> > [    2.893769] mdio_bus ocelot-miim0.2.auto-mii: using device tree for GPIO lookup
> > [    2.893802] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> > [    2.893898] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0[0]'
> > [    2.893996] mdio_bus ocelot-miim0.2.auto-mii: using lookup tables for GPIO lookup
> > [    2.894012] mdio_bus ocelot-miim0.2.auto-mii: No GPIO consumer reset found
> > [    3.395738] mdio_bus ocelot-miim0.2.auto-mii:00: GPIO lookup for consumer reset
> > [    3.395777] mdio_bus ocelot-miim0.2.auto-mii:00: using device tree for GPIO lookup
> > [    3.395840] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> > [    3.395959] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/ocelot-chip@0/mdio0/ethernet-phy@0[0]'
> > [    3.396069] mdio_bus ocelot-miim0.2.auto-mii:00: using lookup tables for GPIO lookup
> > [    3.396086] mdio_bus ocelot-miim0.2.auto-mii:00: No GPIO consumer reset found
> > ...
> > [    3.449187] ocelot-ext-switch ocelot-ext-switch.4.auto: DMA mask not set
> > [    5.336880] ocelot-ext-switch ocelot-ext-switch.4.auto: PHY [ocelot-miim0.2.auto-mii:00] driver [Generic PHY] (irq=POLL)
> > [    5.349087] ocelot-ext-switch ocelot-ext-switch.4.auto: configuring for phy/internal link mode
> > [    5.363619] ocelot-ext-switch ocelot-ext-switch.4.auto swp1 (uninitialized): PHY [ocelot-miim0.2.auto-mii:01] driver [Generic PHY] (irq=POLL)
> > [    5.381396] ocelot-ext-switch ocelot-ext-switch.4.auto swp2 (uninitialized): PHY [ocelot-miim0.2.auto-mii:02] driver [Generic PHY] (irq=POLL)
> > [    5.398525] ocelot-ext-switch ocelot-ext-switch.4.auto swp3 (uninitialized): PHY [ocelot-miim0.2.auto-mii:03] driver [Generic PHY] (irq=POLL)
> 
> Do the PHYs not have a specific driver?

When I have the other four ports defined, those correctly find the
vsc85xx driver, perform serdes calibration, etc. (assuming I have that
phy support compiled in) The internal phys I believe have always just
been using a generic driver.

> 
> > [    5.422048] device eth0 entered promiscuous mode
> > [    5.426785] DSA: tree 0 setup
> > ...
> > [    7.450067] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> > [   21.556395] cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
> > [   21.648564] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
> > [   21.667970] 8021q: adding VLAN 0 to HW filter on device eth0
> > [   21.705360] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: configuring for phy/internal link mode
> > [   22.018230] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Down
> > [   23.771740] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
> > [   24.090929] ocelot-ext-switch ocelot-ext-switch.4.auto: Link is Up - 100Mbps/Full - flow control off
> > [   25.853021] ocelot-ext-switch ocelot-ext-switch.4.auto swp1: Link is Up - 1Gbps/Full - flow control rx/tx
> > 
> > 
> > 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
> 
> bus -> bulk?

Either is probably valid. Here I'm referencing struct regmap_bus, 
so _regmap_bus_read allows the utilization of bulk transfers for stats.

> 
> >       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
> > 
> > 
> > Colin Foster (16):
> >   pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module
> >   pinctrl: microchip-sgpio: allow sgpio driver to be used as a module
> >   net: ocelot: add interface to get regmaps when exernally controlled
> >   net: mdio: mscc-miim: add ability to be used in a non-mmio
> >     configuration
> >   pinctrl: ocelot: add ability to be used in a non-mmio configuration
> >   pinctrl: microchip-sgpio: add ability to be used in a non-mmio
> >     configuration
> >   resource: add define macro for register address resources
> >   mfd: ocelot: add support for the vsc7512 chip via spi
> >   net: mscc: ocelot: expose ocelot wm functions
> >   net: dsa: felix: add configurable device quirks
> >   net: mscc: ocelot: expose regfield definition to be used by other
> >     drivers
> >   net: mscc: ocelot: expose stats layout definition to be used by other
> >     drivers
> >   net: mscc: ocelot: expose vcap_props structure
> >   net: dsa: ocelot: add external ocelot switch control
> >   net: dsa: felix: add phylink_get_caps capability
> >   net: dsa: ocelot: utilize phylink_generic_validate
> > 
> >  drivers/mfd/Kconfig                        |  18 +
> >  drivers/mfd/Makefile                       |   2 +
> >  drivers/mfd/ocelot-core.c                  | 138 ++++++++
> >  drivers/mfd/ocelot-spi.c                   | 311 +++++++++++++++++
> >  drivers/mfd/ocelot.h                       |  34 ++
> >  drivers/net/dsa/ocelot/Kconfig             |  14 +
> >  drivers/net/dsa/ocelot/Makefile            |   5 +
> >  drivers/net/dsa/ocelot/felix.c             |  29 +-
> >  drivers/net/dsa/ocelot/felix.h             |   3 +
> >  drivers/net/dsa/ocelot/felix_vsc9959.c     |   1 +
> >  drivers/net/dsa/ocelot/ocelot_ext.c        | 366 +++++++++++++++++++++
> >  drivers/net/dsa/ocelot/seville_vsc9953.c   |   1 +
> >  drivers/net/ethernet/mscc/ocelot_devlink.c |  31 ++
> >  drivers/net/ethernet/mscc/ocelot_vsc7514.c | 230 +------------
> >  drivers/net/ethernet/mscc/vsc7514_regs.c   | 200 +++++++++++
> >  drivers/net/mdio/mdio-mscc-miim.c          |  31 +-
> >  drivers/pinctrl/Kconfig                    |   4 +-
> >  drivers/pinctrl/pinctrl-microchip-sgpio.c  |  26 +-
> >  drivers/pinctrl/pinctrl-ocelot.c           |  35 +-
> >  include/linux/ioport.h                     |   5 +
> >  include/soc/mscc/ocelot.h                  |  19 ++
> >  include/soc/mscc/vsc7514_regs.h            |   6 +
> >  22 files changed, 1251 insertions(+), 258 deletions(-)
> >  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 drivers/net/dsa/ocelot/ocelot_ext.c
> > 
> > -- 
> > 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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-09 17:13   ` Vladimir Oltean
@ 2022-05-10  2:57     ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  2:57 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> 
> Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?

Below. I'm one of the only users of IORESOURCE_REG, from what I can
tell... Not sure if that's any consolation.

> 
> > [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> > [    2.842717] gpiochip_find_base: found new base at 2026
> > [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> > [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> > [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> > [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> > [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> > [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> > [    2.870801] gpiochip_find_base: found new base at 1962
> > [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> > [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> > [    2.872364] gpiochip_find_base: found new base at 1898
> > [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> > [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> > [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set

[   16.699517] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.18.0-rc5-01315-g0a0ea78e3a79-dirty #632
[   16.708574] Hardware name: Generic AM33XX (Flattened Device Tree)
[   16.714704] Workqueue: events_unbound deferred_probe_work_func
[   16.720608] Backtrace: 
[   16.723071]  dump_backtrace from show_stack+0x20/0x24
[   16.728179]  r7:c31bcc10 r6:00000000 r5:c1647b38 r4:a0000013
[   16.733863]  show_stack from dump_stack_lvl+0x60/0x78
[   16.738954]  dump_stack_lvl from dump_stack+0x18/0x1c
[   16.744040]  r7:c31bcc10 r6:c31bcc10 r5:c31bcc10 r4:00000000
[   16.749724]  dump_stack from of_dma_configure_id+0x48/0x314
[   16.755335]  of_dma_configure_id from platform_dma_configure+0x2c/0x38
[   16.761911]  r10:df9bf424 r9:df9bf424 r8:00000069 r7:c31bcc10 r6:c1bbac5c r5:c31bcc10
[   16.769777]  r4:00000000
[   16.772320]  platform_dma_configure from really_probe+0x78/0x298

platform_dma_configure gets called because...

[   16.778360]  really_probe from __driver_probe_device+0x94/0xf4
[   16.784230]  r7:c31bcc10 r6:c31bcc10 r5:c1bbac5c r4:c31bcc10
[   16.789913]  __driver_probe_device from driver_probe_device+0x44/0xe0
[   16.796391]  r5:c1c51f28 r4:c1c51f24
[   16.799980]  driver_probe_device from __device_attach_driver+0x9c/0xc4
[   16.806548]  r9:df9bf424 r8:c1b9c728 r7:c1c51ef8 r6:c31bcc10 r5:e002191c r4:c1bbac5c
[   16.814326]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
[   16.820635]  r7:c1c51ef8 r6:c0a012e4 r5:e002191c r4:00000000
[   16.826319]  bus_for_each_drv from __device_attach+0x104/0x170
[   16.832190]  r6:00000001 r5:c31bcc54 r4:c31bcc10
[   16.836827]  __device_attach from device_initial_probe+0x1c/0x20
[   16.842871]  r6:c31bcc10 r5:c1b9ccd0 r4:c31bcc10
[   16.847507]  device_initial_probe from bus_probe_device+0x94/0x9c
[   16.853637]  bus_probe_device from device_add+0x3ec/0x8b4
[   16.859073]  r7:c1c51ef8 r6:c31b9c00 r5:00000000 r4:c31bcc10
[   16.864756]  device_add from platform_device_add+0x100/0x210
[   16.870455]  r10:c1a21744 r9:c1a21724 r8:c31bcc10 r7:00000002 r6:c31bcc00 r5:c3201aa0
[   16.878320]  r4:00000002
[   16.880864]  platform_device_add from mfd_add_devices+0x308/0x62c

platform_device_add sets up pdev->bus = &platform_bus_type;

That assignment looks to date back to the before times... Now you have
me curious. And a little scared :-)

[   16.887008]  r10:00000000 r9:00000000 r8:00000000 r7:00000002 r6:c31bcc00 r5:c3201a40
[   16.894875]  r4:c12be398 r3:00000000
[   16.898465]  mfd_add_devices from devm_mfd_add_devices+0x80/0xc0
[   16.904514]  r10:df9be9bc r9:df9be9bc r8:00000005 r7:c12be2e8 r6:fffffffe r5:c31b9c00
[   16.912381]  r4:c31ecc40
[   16.914924]  devm_mfd_add_devices from ocelot_core_init+0x40/0x6c
[   16.921058]  r8:00000065 r7:c31b9c00 r6:c31ec9c0 r5:00000000 r4:c31b9c00
[   16.927790]  ocelot_core_init from ocelot_spi_probe+0xf4/0x188
[   16.933662]  r5:00000000 r4:c31b9c00
[   16.937251]  ocelot_spi_probe from spi_probe+0x94/0xb8
[   16.942434]  r7:c31b9c00 r6:c1b9fc60 r5:c31b9c00 r4:00000000
[   16.948118]  spi_probe from really_probe+0x110/0x298
[   16.953116]  r7:c31b9c00 r6:c1b9fc70 r5:c31b9c00 r4:00000000
[   16.958800]  really_probe from __driver_probe_device+0x94/0xf4
[   16.964669]  r7:c31b9c00 r6:c31b9c00 r5:c1b9fc70 r4:c31b9c00
[   16.970354]  __driver_probe_device from driver_probe_device+0x44/0xe0
[   16.976832]  r5:c1c51f28 r4:c1c51f24
[   16.980422]  driver_probe_device from __device_attach_driver+0x9c/0xc4
[   16.986991]  r9:df9be9bc r8:c1b9c728 r7:c1c51ef8 r6:c31b9c00 r5:e0021bc4 r4:c1b9fc70
[   16.994768]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
[   17.001077]  r7:c1c51ef8 r6:c0a012e4 r5:e0021bc4 r4:00000000
[   17.006762]  bus_for_each_drv from __device_attach+0x104/0x170
[   17.012632]  r6:00000001 r5:c31b9c44 r4:c31b9c00
[   17.017269]  __device_attach from device_initial_probe+0x1c/0x20
[   17.023311]  r6:c31b9c00 r5:c1bb0a50 r4:c31b9c00
[   17.027948]  device_initial_probe from bus_probe_device+0x94/0x9c
[   17.034077]  bus_probe_device from device_add+0x3ec/0x8b4
[   17.039513]  r7:c1c51ef8 r6:c31b9800 r5:00000000 r4:c31b9c00
[   17.045197]  device_add from __spi_add_device+0x7c/0x10c
[   17.050550]  r10:c1c53844 r9:c30ec810 r8:00000001 r7:c30ec810 r6:c31b9800 r5:c31b9c00
[   17.058415]  r4:00000000
[   17.060959]  __spi_add_device from spi_add_device+0x48/0x78
[   17.066568]  r7:00000000 r6:c31b9800 r5:c31b9c00 r4:c31b9a1c
[   17.072252]  spi_add_device from of_register_spi_device+0x258/0x390
[   17.078556]  r5:df9be9a0 r4:c31b9c00
[   17.082147]  of_register_spi_device from spi_register_controller+0x26c/0x6d8
[   17.089239]  r8:c17105c0 r7:df9bea04 r6:df9be9a0 r5:00000000 r4:c31b9800
[   17.095970]  spi_register_controller from devm_spi_register_controller+0x24/0x60
[   17.103412]  r10:c1c53844 r9:c31e9584 r8:c31b9800 r7:c31b9800 r6:c30ec810 r5:c31b9800
[   17.111278]  r4:c31b9bc0
[   17.113822]  devm_spi_register_controller from omap2_mcspi_probe+0x4c8/0x574
[   17.120924]  r7:c31b9800 r6:00000000 r5:c30ec940 r4:c31b9bc0
[   17.126608]  omap2_mcspi_probe from platform_probe+0x6c/0xc8
[   17.132308]  r10:c1bf0f80 r9:c202f00d r8:00000065 r7:c30ec810 r6:c1bb1d00 r5:c30ec810
[   17.140174]  r4:00000000
[   17.142717]  platform_probe from really_probe+0x110/0x298
[   17.148151]  r7:c30ec810 r6:c1bb1d00 r5:c30ec810 r4:00000000
[   17.153835]  really_probe from __driver_probe_device+0x94/0xf4
[   17.159704]  r7:c30ec810 r6:c30ec810 r5:c1bb1d00 r4:c30ec810
[   17.165387]  __driver_probe_device from driver_probe_device+0x44/0xe0
[   17.171865]  r5:c1c51f28 r4:c1c51f24
[   17.175455]  driver_probe_device from __device_attach_driver+0x9c/0xc4
[   17.182023]  r9:c202f00d r8:c1b9ca1c r7:00000000 r6:c30ec810 r5:e0021e84 r4:c1bb1d00
[   17.189800]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
[   17.196108]  r7:00000000 r6:c0a012e4 r5:e0021e84 r4:00000000
[   17.201792]  bus_for_each_drv from __device_attach+0x104/0x170
[   17.207661]  r6:00000001 r5:c30ec854 r4:c30ec810
[   17.212299]  __device_attach from device_initial_probe+0x1c/0x20
[   17.218342]  r6:c30ec810 r5:c1b9ccd0 r4:c30ec810
[   17.222979]  device_initial_probe from bus_probe_device+0x94/0x9c
[   17.229109]  bus_probe_device from deferred_probe_work_func+0x8c/0xb8
[   17.235594]  r7:00000000 r6:c1b9ca30 r5:c1b9ca1c r4:c30ec810
[   17.241277]  deferred_probe_work_func from process_one_work+0x1e0/0x53c
[   17.247950]  r9:c202f00d r8:00000000 r7:c202f000 r6:c2020a00 r5:c2156500 r4:c1b9ca5c
[   17.255728]  process_one_work from worker_thread+0x238/0x4fc
[   17.261428]  r10:c2020a00 r9:00000088 r8:c1a03d00 r7:c2020a1c r6:c2156518 r5:c2020a00
[   17.269293]  r4:c2156500
[   17.271836]  worker_thread from kthread+0x108/0x138
[   17.276757]  r10:00000000 r9:e0009e4c r8:c2160cc0 r7:c21a6a80 r6:c2156500 r5:c036aac8
[   17.284624]  r4:c2160900
[   17.287168]  kthread from ret_from_fork+0x14/0x2c
[   17.291904] Exception stack(0xe0021fb0 to 0xe0021ff8)
[   17.296982] 1fa0:                                     00000000 00000000 00000000 00000000
[   17.305202] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   17.313420] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[   17.320069]  r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c037341c r4:c2160900
[   17.328184] mscc-miim ocelot-miim0.2.auto: DMA mask not set

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-10  2:57     ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10  2:57 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> 
> Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?

Below. I'm one of the only users of IORESOURCE_REG, from what I can
tell... Not sure if that's any consolation.

> 
> > [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> > [    2.842717] gpiochip_find_base: found new base at 2026
> > [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> > [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> > [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> > [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> > [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> > [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> > [    2.870801] gpiochip_find_base: found new base at 1962
> > [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> > [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> > [    2.872364] gpiochip_find_base: found new base at 1898
> > [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> > [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> > [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set

[   16.699517] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.18.0-rc5-01315-g0a0ea78e3a79-dirty #632
[   16.708574] Hardware name: Generic AM33XX (Flattened Device Tree)
[   16.714704] Workqueue: events_unbound deferred_probe_work_func
[   16.720608] Backtrace: 
[   16.723071]  dump_backtrace from show_stack+0x20/0x24
[   16.728179]  r7:c31bcc10 r6:00000000 r5:c1647b38 r4:a0000013
[   16.733863]  show_stack from dump_stack_lvl+0x60/0x78
[   16.738954]  dump_stack_lvl from dump_stack+0x18/0x1c
[   16.744040]  r7:c31bcc10 r6:c31bcc10 r5:c31bcc10 r4:00000000
[   16.749724]  dump_stack from of_dma_configure_id+0x48/0x314
[   16.755335]  of_dma_configure_id from platform_dma_configure+0x2c/0x38
[   16.761911]  r10:df9bf424 r9:df9bf424 r8:00000069 r7:c31bcc10 r6:c1bbac5c r5:c31bcc10
[   16.769777]  r4:00000000
[   16.772320]  platform_dma_configure from really_probe+0x78/0x298

platform_dma_configure gets called because...

[   16.778360]  really_probe from __driver_probe_device+0x94/0xf4
[   16.784230]  r7:c31bcc10 r6:c31bcc10 r5:c1bbac5c r4:c31bcc10
[   16.789913]  __driver_probe_device from driver_probe_device+0x44/0xe0
[   16.796391]  r5:c1c51f28 r4:c1c51f24
[   16.799980]  driver_probe_device from __device_attach_driver+0x9c/0xc4
[   16.806548]  r9:df9bf424 r8:c1b9c728 r7:c1c51ef8 r6:c31bcc10 r5:e002191c r4:c1bbac5c
[   16.814326]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
[   16.820635]  r7:c1c51ef8 r6:c0a012e4 r5:e002191c r4:00000000
[   16.826319]  bus_for_each_drv from __device_attach+0x104/0x170
[   16.832190]  r6:00000001 r5:c31bcc54 r4:c31bcc10
[   16.836827]  __device_attach from device_initial_probe+0x1c/0x20
[   16.842871]  r6:c31bcc10 r5:c1b9ccd0 r4:c31bcc10
[   16.847507]  device_initial_probe from bus_probe_device+0x94/0x9c
[   16.853637]  bus_probe_device from device_add+0x3ec/0x8b4
[   16.859073]  r7:c1c51ef8 r6:c31b9c00 r5:00000000 r4:c31bcc10
[   16.864756]  device_add from platform_device_add+0x100/0x210
[   16.870455]  r10:c1a21744 r9:c1a21724 r8:c31bcc10 r7:00000002 r6:c31bcc00 r5:c3201aa0
[   16.878320]  r4:00000002
[   16.880864]  platform_device_add from mfd_add_devices+0x308/0x62c

platform_device_add sets up pdev->bus = &platform_bus_type;

That assignment looks to date back to the before times... Now you have
me curious. And a little scared :-)

[   16.887008]  r10:00000000 r9:00000000 r8:00000000 r7:00000002 r6:c31bcc00 r5:c3201a40
[   16.894875]  r4:c12be398 r3:00000000
[   16.898465]  mfd_add_devices from devm_mfd_add_devices+0x80/0xc0
[   16.904514]  r10:df9be9bc r9:df9be9bc r8:00000005 r7:c12be2e8 r6:fffffffe r5:c31b9c00
[   16.912381]  r4:c31ecc40
[   16.914924]  devm_mfd_add_devices from ocelot_core_init+0x40/0x6c
[   16.921058]  r8:00000065 r7:c31b9c00 r6:c31ec9c0 r5:00000000 r4:c31b9c00
[   16.927790]  ocelot_core_init from ocelot_spi_probe+0xf4/0x188
[   16.933662]  r5:00000000 r4:c31b9c00
[   16.937251]  ocelot_spi_probe from spi_probe+0x94/0xb8
[   16.942434]  r7:c31b9c00 r6:c1b9fc60 r5:c31b9c00 r4:00000000
[   16.948118]  spi_probe from really_probe+0x110/0x298
[   16.953116]  r7:c31b9c00 r6:c1b9fc70 r5:c31b9c00 r4:00000000
[   16.958800]  really_probe from __driver_probe_device+0x94/0xf4
[   16.964669]  r7:c31b9c00 r6:c31b9c00 r5:c1b9fc70 r4:c31b9c00
[   16.970354]  __driver_probe_device from driver_probe_device+0x44/0xe0
[   16.976832]  r5:c1c51f28 r4:c1c51f24
[   16.980422]  driver_probe_device from __device_attach_driver+0x9c/0xc4
[   16.986991]  r9:df9be9bc r8:c1b9c728 r7:c1c51ef8 r6:c31b9c00 r5:e0021bc4 r4:c1b9fc70
[   16.994768]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
[   17.001077]  r7:c1c51ef8 r6:c0a012e4 r5:e0021bc4 r4:00000000
[   17.006762]  bus_for_each_drv from __device_attach+0x104/0x170
[   17.012632]  r6:00000001 r5:c31b9c44 r4:c31b9c00
[   17.017269]  __device_attach from device_initial_probe+0x1c/0x20
[   17.023311]  r6:c31b9c00 r5:c1bb0a50 r4:c31b9c00
[   17.027948]  device_initial_probe from bus_probe_device+0x94/0x9c
[   17.034077]  bus_probe_device from device_add+0x3ec/0x8b4
[   17.039513]  r7:c1c51ef8 r6:c31b9800 r5:00000000 r4:c31b9c00
[   17.045197]  device_add from __spi_add_device+0x7c/0x10c
[   17.050550]  r10:c1c53844 r9:c30ec810 r8:00000001 r7:c30ec810 r6:c31b9800 r5:c31b9c00
[   17.058415]  r4:00000000
[   17.060959]  __spi_add_device from spi_add_device+0x48/0x78
[   17.066568]  r7:00000000 r6:c31b9800 r5:c31b9c00 r4:c31b9a1c
[   17.072252]  spi_add_device from of_register_spi_device+0x258/0x390
[   17.078556]  r5:df9be9a0 r4:c31b9c00
[   17.082147]  of_register_spi_device from spi_register_controller+0x26c/0x6d8
[   17.089239]  r8:c17105c0 r7:df9bea04 r6:df9be9a0 r5:00000000 r4:c31b9800
[   17.095970]  spi_register_controller from devm_spi_register_controller+0x24/0x60
[   17.103412]  r10:c1c53844 r9:c31e9584 r8:c31b9800 r7:c31b9800 r6:c30ec810 r5:c31b9800
[   17.111278]  r4:c31b9bc0
[   17.113822]  devm_spi_register_controller from omap2_mcspi_probe+0x4c8/0x574
[   17.120924]  r7:c31b9800 r6:00000000 r5:c30ec940 r4:c31b9bc0
[   17.126608]  omap2_mcspi_probe from platform_probe+0x6c/0xc8
[   17.132308]  r10:c1bf0f80 r9:c202f00d r8:00000065 r7:c30ec810 r6:c1bb1d00 r5:c30ec810
[   17.140174]  r4:00000000
[   17.142717]  platform_probe from really_probe+0x110/0x298
[   17.148151]  r7:c30ec810 r6:c1bb1d00 r5:c30ec810 r4:00000000
[   17.153835]  really_probe from __driver_probe_device+0x94/0xf4
[   17.159704]  r7:c30ec810 r6:c30ec810 r5:c1bb1d00 r4:c30ec810
[   17.165387]  __driver_probe_device from driver_probe_device+0x44/0xe0
[   17.171865]  r5:c1c51f28 r4:c1c51f24
[   17.175455]  driver_probe_device from __device_attach_driver+0x9c/0xc4
[   17.182023]  r9:c202f00d r8:c1b9ca1c r7:00000000 r6:c30ec810 r5:e0021e84 r4:c1bb1d00
[   17.189800]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
[   17.196108]  r7:00000000 r6:c0a012e4 r5:e0021e84 r4:00000000
[   17.201792]  bus_for_each_drv from __device_attach+0x104/0x170
[   17.207661]  r6:00000001 r5:c30ec854 r4:c30ec810
[   17.212299]  __device_attach from device_initial_probe+0x1c/0x20
[   17.218342]  r6:c30ec810 r5:c1b9ccd0 r4:c30ec810
[   17.222979]  device_initial_probe from bus_probe_device+0x94/0x9c
[   17.229109]  bus_probe_device from deferred_probe_work_func+0x8c/0xb8
[   17.235594]  r7:00000000 r6:c1b9ca30 r5:c1b9ca1c r4:c30ec810
[   17.241277]  deferred_probe_work_func from process_one_work+0x1e0/0x53c
[   17.247950]  r9:c202f00d r8:00000000 r7:c202f000 r6:c2020a00 r5:c2156500 r4:c1b9ca5c
[   17.255728]  process_one_work from worker_thread+0x238/0x4fc
[   17.261428]  r10:c2020a00 r9:00000088 r8:c1a03d00 r7:c2020a1c r6:c2156518 r5:c2020a00
[   17.269293]  r4:c2156500
[   17.271836]  worker_thread from kthread+0x108/0x138
[   17.276757]  r10:00000000 r9:e0009e4c r8:c2160cc0 r7:c21a6a80 r6:c2156500 r5:c036aac8
[   17.284624]  r4:c2160900
[   17.287168]  kthread from ret_from_fork+0x14/0x2c
[   17.291904] Exception stack(0xe0021fb0 to 0xe0021ff8)
[   17.296982] 1fa0:                                     00000000 00000000 00000000 00000000
[   17.305202] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   17.313420] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[   17.320069]  r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c037341c r4:c2160900
[   17.328184] mscc-miim ocelot-miim0.2.auto: DMA mask not set

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-09 17:20         ` Vladimir Oltean
@ 2022-05-10 15:32           ` Lee Jones
  -1 siblings, 0 replies; 114+ messages in thread
From: Lee Jones @ 2022-05-10 15:32 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Colin Foster, linux-arm-kernel, linux-gpio, netdev, Terry Bowman,
	Wolfram Sang, Andy Shevchenko, Steen Hegelund, Lars Povlsen,
	Linus Walleij, Russell King, Heiner Kallweit, Paolo Abeni,
	Jakub Kicinski, Eric Dumazet, David S. Miller, Florian Fainelli,
	Vivien Didelot, Andrew Lunn, UNGLinuxDriver, Alexandre Belloni,
	Claudiu Manoil

On Mon, 09 May 2022, Vladimir Oltean wrote:

> On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > +						const struct resource *res)
> > > > +{
> > > > +	struct device *dev = child->parent;
> > > > +
> > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > 
> > > So much for being bus-agnostic :-/
> > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > 
> > That was my initial design. "core" was calling into "spi" exclusively
> > via function pointers.
> > 
> > The request was "Please find a clearer way to do this without function
> > pointers"
> > 
> > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> 
> Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> with the comment that you aren't configuring a bus. In this context it
> seems more appropriate to call this function pointer "init_regmap", with
> different implementations per transport.

FWIW, I'm still against using function pointers for this.

What about making ocelot_init_regmap_from_resource() an inline
function and pushing it into one of the header files?

[As an aside, you don't need to pass both dev (parent) and child]

In there you could simply do:

inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
						       const struct resource *res)
{
	if (dev_get_drvdata(dev->parent)->spi)
		return ocelot_spi_devm_init_regmap(dev, res);

	return NULL;
}

Also, do you really need devm in the title?

> Or alternatively you could leave the "core"/"spi" pseudo-separation up
> to the next person who needs to add support for some other register I/O
> method.

Or this.  Your call.

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-10 15:32           ` Lee Jones
  0 siblings, 0 replies; 114+ messages in thread
From: Lee Jones @ 2022-05-10 15:32 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Colin Foster, linux-arm-kernel, linux-gpio, netdev, Terry Bowman,
	Wolfram Sang, Andy Shevchenko, Steen Hegelund, Lars Povlsen,
	Linus Walleij, Russell King, Heiner Kallweit, Paolo Abeni,
	Jakub Kicinski, Eric Dumazet, David S. Miller, Florian Fainelli,
	Vivien Didelot, Andrew Lunn, UNGLinuxDriver, Alexandre Belloni,
	Claudiu Manoil

On Mon, 09 May 2022, Vladimir Oltean wrote:

> On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > +						const struct resource *res)
> > > > +{
> > > > +	struct device *dev = child->parent;
> > > > +
> > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > 
> > > So much for being bus-agnostic :-/
> > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > 
> > That was my initial design. "core" was calling into "spi" exclusively
> > via function pointers.
> > 
> > The request was "Please find a clearer way to do this without function
> > pointers"
> > 
> > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> 
> Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> with the comment that you aren't configuring a bus. In this context it
> seems more appropriate to call this function pointer "init_regmap", with
> different implementations per transport.

FWIW, I'm still against using function pointers for this.

What about making ocelot_init_regmap_from_resource() an inline
function and pushing it into one of the header files?

[As an aside, you don't need to pass both dev (parent) and child]

In there you could simply do:

inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
						       const struct resource *res)
{
	if (dev_get_drvdata(dev->parent)->spi)
		return ocelot_spi_devm_init_regmap(dev, res);

	return NULL;
}

Also, do you really need devm in the title?

> Or alternatively you could leave the "core"/"spi" pseudo-separation up
> to the next person who needs to add support for some other register I/O
> method.

Or this.  Your call.

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-08 18:53   ` Colin Foster
@ 2022-05-10 15:58     ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-10 15:58 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:05AM -0700, Colin Foster wrote:
> +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",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> +		.resources = vsc7512_miim0_resources,

I wonder whether you can differentiate these 2 MFD cells by "use_of_reg"
+ "of_reg".

> +	}, {
> +		.name = "ocelot-miim1",
> +		.of_compatible = "mscc,ocelot-miim",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> +		.resources = vsc7512_miim1_resources,
> +	},
> +};
> +
> +const struct of_device_id ocelot_spi_of_match[] = {
> +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);

Don't forget to add a struct spi_device_id table for the driver.

> +
> +static struct spi_driver ocelot_spi_driver = {
> +	.driver = {
> +		.name = "ocelot_mfd_spi",
> +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> +	},
> +	.probe = ocelot_spi_probe,
> +};
> +module_spi_driver(ocelot_spi_driver);
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-10 15:58     ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-10 15:58 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Sun, May 08, 2022 at 11:53:05AM -0700, Colin Foster wrote:
> +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",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> +		.resources = vsc7512_miim0_resources,

I wonder whether you can differentiate these 2 MFD cells by "use_of_reg"
+ "of_reg".

> +	}, {
> +		.name = "ocelot-miim1",
> +		.of_compatible = "mscc,ocelot-miim",
> +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> +		.resources = vsc7512_miim1_resources,
> +	},
> +};
> +
> +const struct of_device_id ocelot_spi_of_match[] = {
> +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);

Don't forget to add a struct spi_device_id table for the driver.

> +
> +static struct spi_driver ocelot_spi_driver = {
> +	.driver = {
> +		.name = "ocelot_mfd_spi",
> +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> +	},
> +	.probe = ocelot_spi_probe,
> +};
> +module_spi_driver(ocelot_spi_driver);

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-10 15:58     ` Vladimir Oltean
@ 2022-05-10 16:02       ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10 16:02 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Tue, May 10, 2022 at 03:58:54PM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:05AM -0700, Colin Foster wrote:
> > +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",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> > +		.resources = vsc7512_miim0_resources,
> 
> I wonder whether you can differentiate these 2 MFD cells by "use_of_reg"
> + "of_reg".

I'll look into this. I figured your question regarding this during
the last v7 wasn't directed at me. If it was: I'm sorry I ignored it.

> 
> > +	}, {
> > +		.name = "ocelot-miim1",
> > +		.of_compatible = "mscc,ocelot-miim",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> > +		.resources = vsc7512_miim1_resources,
> > +	},
> > +};
> > +
> > +const struct of_device_id ocelot_spi_of_match[] = {
> > +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
> 
> Don't forget to add a struct spi_device_id table for the driver.
> 
> > +
> > +static struct spi_driver ocelot_spi_driver = {
> > +	.driver = {
> > +		.name = "ocelot_mfd_spi",
> > +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> > +	},
> > +	.probe = ocelot_spi_probe,
> > +};
> > +module_spi_driver(ocelot_spi_driver);

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-10 16:02       ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10 16:02 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Tue, May 10, 2022 at 03:58:54PM +0000, Vladimir Oltean wrote:
> On Sun, May 08, 2022 at 11:53:05AM -0700, Colin Foster wrote:
> > +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",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
> > +		.resources = vsc7512_miim0_resources,
> 
> I wonder whether you can differentiate these 2 MFD cells by "use_of_reg"
> + "of_reg".

I'll look into this. I figured your question regarding this during
the last v7 wasn't directed at me. If it was: I'm sorry I ignored it.

> 
> > +	}, {
> > +		.name = "ocelot-miim1",
> > +		.of_compatible = "mscc,ocelot-miim",
> > +		.num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
> > +		.resources = vsc7512_miim1_resources,
> > +	},
> > +};
> > +
> > +const struct of_device_id ocelot_spi_of_match[] = {
> > +	{ .compatible = "mscc,vsc7512_mfd_spi" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ocelot_spi_of_match);
> 
> Don't forget to add a struct spi_device_id table for the driver.
> 
> > +
> > +static struct spi_driver ocelot_spi_driver = {
> > +	.driver = {
> > +		.name = "ocelot_mfd_spi",
> > +		.of_match_table = of_match_ptr(ocelot_spi_of_match),
> > +	},
> > +	.probe = ocelot_spi_probe,
> > +};
> > +module_spi_driver(ocelot_spi_driver);

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-10 15:32           ` Lee Jones
@ 2022-05-10 16:13             ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10 16:13 UTC (permalink / raw)
  To: Lee Jones
  Cc: Vladimir Oltean, linux-arm-kernel, linux-gpio, netdev,
	Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil

On Tue, May 10, 2022 at 04:32:26PM +0100, Lee Jones wrote:
> On Mon, 09 May 2022, Vladimir Oltean wrote:
> 
> > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > > +						const struct resource *res)
> > > > > +{
> > > > > +	struct device *dev = child->parent;
> > > > > +
> > > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > > 
> > > > So much for being bus-agnostic :-/
> > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > > 
> > > That was my initial design. "core" was calling into "spi" exclusively
> > > via function pointers.
> > > 
> > > The request was "Please find a clearer way to do this without function
> > > pointers"
> > > 
> > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> > 
> > Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> > with the comment that you aren't configuring a bus. In this context it
> > seems more appropriate to call this function pointer "init_regmap", with
> > different implementations per transport.
> 
> FWIW, I'm still against using function pointers for this.
> 
> What about making ocelot_init_regmap_from_resource() an inline
> function and pushing it into one of the header files?
> 
> [As an aside, you don't need to pass both dev (parent) and child]

I see your point. This wasn't always the case, since ocelot-core prior
to v8 would call ocelot_spi_devm_init_regmap. Since this was changed,
the "dev, dev" part can all be handled internally. That's nice.

> 
> In there you could simply do:
> 
> inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
> 						       const struct resource *res)
> {
> 	if (dev_get_drvdata(dev->parent)->spi)
> 		return ocelot_spi_devm_init_regmap(dev, res);
> 
> 	return NULL;
> }

If I do this, won't I have to declare ocelot_spi_devm_init_regmap in a
larger scope (include/soc/mscc/ocelot.h)? I like the idea of keeping it
more hidden inside drivers/mfd/ocelot.h, assuming I can't keep it
enclosed in drivers/mfd/ocelot-spi.c entirely.

> 
> Also, do you really need devm in the title?

Understood. I figured adding devm made it clearer about what is going
on. I don't have a strong opinion one way or another. If nothing else,
it'll shorten my function names which can be wordy... But as I say this
I noticed "ocelot_init_regmap_from_resource" doesn't have devm. I'll
remove it.

> 
> > Or alternatively you could leave the "core"/"spi" pseudo-separation up
> > to the next person who needs to add support for some other register I/O
> > method.
> 
> Or this.  Your call.

I do like having them separate. Even as I've been working on v8, it has
been clear that "these commits go toward improving the spi section"
while others are implementing core features (serdes, for example.)

I feel like v8 has landed in a pretty good spot between keeping
everything completely separate and having everything be one file.

> 
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-10 16:13             ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-10 16:13 UTC (permalink / raw)
  To: Lee Jones
  Cc: Vladimir Oltean, linux-arm-kernel, linux-gpio, netdev,
	Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil

On Tue, May 10, 2022 at 04:32:26PM +0100, Lee Jones wrote:
> On Mon, 09 May 2022, Vladimir Oltean wrote:
> 
> > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > > +						const struct resource *res)
> > > > > +{
> > > > > +	struct device *dev = child->parent;
> > > > > +
> > > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > > 
> > > > So much for being bus-agnostic :-/
> > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > > 
> > > That was my initial design. "core" was calling into "spi" exclusively
> > > via function pointers.
> > > 
> > > The request was "Please find a clearer way to do this without function
> > > pointers"
> > > 
> > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> > 
> > Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> > with the comment that you aren't configuring a bus. In this context it
> > seems more appropriate to call this function pointer "init_regmap", with
> > different implementations per transport.
> 
> FWIW, I'm still against using function pointers for this.
> 
> What about making ocelot_init_regmap_from_resource() an inline
> function and pushing it into one of the header files?
> 
> [As an aside, you don't need to pass both dev (parent) and child]

I see your point. This wasn't always the case, since ocelot-core prior
to v8 would call ocelot_spi_devm_init_regmap. Since this was changed,
the "dev, dev" part can all be handled internally. That's nice.

> 
> In there you could simply do:
> 
> inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
> 						       const struct resource *res)
> {
> 	if (dev_get_drvdata(dev->parent)->spi)
> 		return ocelot_spi_devm_init_regmap(dev, res);
> 
> 	return NULL;
> }

If I do this, won't I have to declare ocelot_spi_devm_init_regmap in a
larger scope (include/soc/mscc/ocelot.h)? I like the idea of keeping it
more hidden inside drivers/mfd/ocelot.h, assuming I can't keep it
enclosed in drivers/mfd/ocelot-spi.c entirely.

> 
> Also, do you really need devm in the title?

Understood. I figured adding devm made it clearer about what is going
on. I don't have a strong opinion one way or another. If nothing else,
it'll shorten my function names which can be wordy... But as I say this
I noticed "ocelot_init_regmap_from_resource" doesn't have devm. I'll
remove it.

> 
> > Or alternatively you could leave the "core"/"spi" pseudo-separation up
> > to the next person who needs to add support for some other register I/O
> > method.
> 
> Or this.  Your call.

I do like having them separate. Even as I've been working on v8, it has
been clear that "these commits go toward improving the spi section"
while others are implementing core features (serdes, for example.)

I feel like v8 has landed in a pretty good spot between keeping
everything completely separate and having everything be one file.

> 
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-10  2:57     ` Colin Foster
@ 2022-05-10 16:18       ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-10 16:18 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 07:57:48PM -0700, Colin Foster wrote:
> On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > Hi Colin,
> > 
> > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > 
> > Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?
> 
> Below. I'm one of the only users of IORESOURCE_REG, from what I can
> tell... Not sure if that's any consolation.
> 
> > 
> > > [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> > > [    2.842717] gpiochip_find_base: found new base at 2026
> > > [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> > > [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> > > [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> > > [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> > > [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> > > [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> > > [    2.870801] gpiochip_find_base: found new base at 1962
> > > [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> > > [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> > > [    2.872364] gpiochip_find_base: found new base at 1898
> > > [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> > > [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> > > [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
> 
> [   16.699517] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.18.0-rc5-01315-g0a0ea78e3a79-dirty #632
> [   16.708574] Hardware name: Generic AM33XX (Flattened Device Tree)
> [   16.714704] Workqueue: events_unbound deferred_probe_work_func
> [   16.720608] Backtrace: 
> [   16.755335]  of_dma_configure_id from platform_dma_configure+0x2c/0x38
> [   16.772320]  platform_dma_configure from really_probe+0x78/0x298
> 
> platform_dma_configure gets called because...
> 
> [   16.778360]  really_probe from __driver_probe_device+0x94/0xf4
> [   16.789913]  __driver_probe_device from driver_probe_device+0x44/0xe0
> [   16.799980]  driver_probe_device from __device_attach_driver+0x9c/0xc4
> [   16.814326]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
> [   16.826319]  bus_for_each_drv from __device_attach+0x104/0x170
> [   16.836827]  __device_attach from device_initial_probe+0x1c/0x20
> [   16.847507]  device_initial_probe from bus_probe_device+0x94/0x9c
> [   16.853637]  bus_probe_device from device_add+0x3ec/0x8b4
> [   16.864756]  device_add from platform_device_add+0x100/0x210
> [   16.880864]  platform_device_add from mfd_add_devices+0x308/0x62c
> 
> platform_device_add sets up pdev->bus = &platform_bus_type;

This part is clear. MFD cells are platform devices which have an
of_node, so platform_dma_configure() calls of_dma_configure_id().

> That assignment looks to date back to the before times... Now you have
> me curious. And a little scared :-)
> 
> [   16.898465]  mfd_add_devices from devm_mfd_add_devices+0x80/0xc0
> [   16.914924]  devm_mfd_add_devices from ocelot_core_init+0x40/0x6c
> [   16.927790]  ocelot_core_init from ocelot_spi_probe+0xf4/0x188
> [   16.937251]  ocelot_spi_probe from spi_probe+0x94/0xb8
> [   16.948118]  spi_probe from really_probe+0x110/0x298
> [   16.958800]  really_probe from __driver_probe_device+0x94/0xf4
> [   16.970354]  __driver_probe_device from driver_probe_device+0x44/0xe0
> [   16.980422]  driver_probe_device from __device_attach_driver+0x9c/0xc4
> [   16.994768]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
> [   17.006762]  bus_for_each_drv from __device_attach+0x104/0x170
> [   17.017269]  __device_attach from device_initial_probe+0x1c/0x20
> [   17.027948]  device_initial_probe from bus_probe_device+0x94/0x9c
> [   17.034077]  bus_probe_device from device_add+0x3ec/0x8b4
> [   17.045197]  device_add from __spi_add_device+0x7c/0x10c
> [   17.060959]  __spi_add_device from spi_add_device+0x48/0x78
> [   17.072252]  spi_add_device from of_register_spi_device+0x258/0x390
> [   17.082147]  of_register_spi_device from spi_register_controller+0x26c/0x6d8
> [   17.095970]  spi_register_controller from devm_spi_register_controller+0x24/0x60
> [   17.113822]  devm_spi_register_controller from omap2_mcspi_probe+0x4c8/0x574
> [   17.126608]  omap2_mcspi_probe from platform_probe+0x6c/0xc8
> [   17.142717]  platform_probe from really_probe+0x110/0x298
> [   17.153835]  really_probe from __driver_probe_device+0x94/0xf4
> [   17.165387]  __driver_probe_device from driver_probe_device+0x44/0xe0
> [   17.175455]  driver_probe_device from __device_attach_driver+0x9c/0xc4
> [   17.189800]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
> [   17.201792]  bus_for_each_drv from __device_attach+0x104/0x170
> [   17.212299]  __device_attach from device_initial_probe+0x1c/0x20
> [   17.222979]  device_initial_probe from bus_probe_device+0x94/0x9c
> [   17.229109]  bus_probe_device from deferred_probe_work_func+0x8c/0xb8
> [   17.241277]  deferred_probe_work_func from process_one_work+0x1e0/0x53c
> [   17.255728]  process_one_work from worker_thread+0x238/0x4fc
> [   17.271836]  worker_thread from kthread+0x108/0x138
> [   17.328184] mscc-miim ocelot-miim0.2.auto: DMA mask not set

Unfortunately I don't have any hardware to test, but I think what
happens is:

mfd_add_device()
{
	calls platform_device_alloc()
		calls setup_pdev_dma_masks()
			sets up the default pdev->dev.dma_mask pointer

	overwrites pdev->dev.dma_mask with parent->dma_mask;
	// your parent->dma_mask is NULL

	calls platform_device_add()
		...
		calls of_dma_configure_id
			complains that pdev->dev.dma_mask is NULL (i.e.
			the bus hasn't bothered setting up a default DMA
			mask, which in fact it did)
}

I don't have enough background regarding the justification for commit
b018e1361bad ("mfd: core: Copy DMA mask and params from parent"), but it
might be detrimential in some cases?

The warning is printed since the slightly unrelated commit 4d8bde883bfb
("OF: Don't set default coherent DMA mask").

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-10 16:18       ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-10 16:18 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 07:57:48PM -0700, Colin Foster wrote:
> On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > Hi Colin,
> > 
> > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > 
> > Why does this get printed, if you put a dump_stack() in of_dma_configure_id()?
> 
> Below. I'm one of the only users of IORESOURCE_REG, from what I can
> tell... Not sure if that's any consolation.
> 
> > 
> > > [    2.835718] pinctrl-ocelot ocelot-pinctrl.0.auto: invalid resource
> > > [    2.842717] gpiochip_find_base: found new base at 2026
> > > [    2.842774] gpio gpiochip4: (ocelot-gpio): created GPIO range 0->21 ==> ocelot-pinctrl.0.auto PIN 0->21
> > > [    2.845693] gpio gpiochip4: (ocelot-gpio): added GPIO chardev (254:4)
> > > [    2.845828] gpio gpiochip4: registered GPIOs 2026 to 2047 on ocelot-gpio
> > > [    2.845855] pinctrl-ocelot ocelot-pinctrl.0.auto: driver registered
> > > [    2.855925] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: DMA mask not set
> > > [    2.863089] pinctrl-microchip-sgpio ocelot-sgpio.1.auto: invalid resource
> > > [    2.870801] gpiochip_find_base: found new base at 1962
> > > [    2.871528] gpio_stub_drv gpiochip5: (ocelot-sgpio.1.auto-input): added GPIO chardev (254:5)
> > > [    2.871666] gpio_stub_drv gpiochip5: registered GPIOs 1962 to 2025 on ocelot-sgpio.1.auto-input
> > > [    2.872364] gpiochip_find_base: found new base at 1898
> > > [    2.873244] gpio_stub_drv gpiochip6: (ocelot-sgpio.1.auto-output): added GPIO chardev (254:6)
> > > [    2.873354] gpio_stub_drv gpiochip6: registered GPIOs 1898 to 1961 on ocelot-sgpio.1.auto-output
> > > [    2.881148] mscc-miim ocelot-miim0.2.auto: DMA mask not set
> 
> [   16.699517] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.18.0-rc5-01315-g0a0ea78e3a79-dirty #632
> [   16.708574] Hardware name: Generic AM33XX (Flattened Device Tree)
> [   16.714704] Workqueue: events_unbound deferred_probe_work_func
> [   16.720608] Backtrace: 
> [   16.755335]  of_dma_configure_id from platform_dma_configure+0x2c/0x38
> [   16.772320]  platform_dma_configure from really_probe+0x78/0x298
> 
> platform_dma_configure gets called because...
> 
> [   16.778360]  really_probe from __driver_probe_device+0x94/0xf4
> [   16.789913]  __driver_probe_device from driver_probe_device+0x44/0xe0
> [   16.799980]  driver_probe_device from __device_attach_driver+0x9c/0xc4
> [   16.814326]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
> [   16.826319]  bus_for_each_drv from __device_attach+0x104/0x170
> [   16.836827]  __device_attach from device_initial_probe+0x1c/0x20
> [   16.847507]  device_initial_probe from bus_probe_device+0x94/0x9c
> [   16.853637]  bus_probe_device from device_add+0x3ec/0x8b4
> [   16.864756]  device_add from platform_device_add+0x100/0x210
> [   16.880864]  platform_device_add from mfd_add_devices+0x308/0x62c
> 
> platform_device_add sets up pdev->bus = &platform_bus_type;

This part is clear. MFD cells are platform devices which have an
of_node, so platform_dma_configure() calls of_dma_configure_id().

> That assignment looks to date back to the before times... Now you have
> me curious. And a little scared :-)
> 
> [   16.898465]  mfd_add_devices from devm_mfd_add_devices+0x80/0xc0
> [   16.914924]  devm_mfd_add_devices from ocelot_core_init+0x40/0x6c
> [   16.927790]  ocelot_core_init from ocelot_spi_probe+0xf4/0x188
> [   16.937251]  ocelot_spi_probe from spi_probe+0x94/0xb8
> [   16.948118]  spi_probe from really_probe+0x110/0x298
> [   16.958800]  really_probe from __driver_probe_device+0x94/0xf4
> [   16.970354]  __driver_probe_device from driver_probe_device+0x44/0xe0
> [   16.980422]  driver_probe_device from __device_attach_driver+0x9c/0xc4
> [   16.994768]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
> [   17.006762]  bus_for_each_drv from __device_attach+0x104/0x170
> [   17.017269]  __device_attach from device_initial_probe+0x1c/0x20
> [   17.027948]  device_initial_probe from bus_probe_device+0x94/0x9c
> [   17.034077]  bus_probe_device from device_add+0x3ec/0x8b4
> [   17.045197]  device_add from __spi_add_device+0x7c/0x10c
> [   17.060959]  __spi_add_device from spi_add_device+0x48/0x78
> [   17.072252]  spi_add_device from of_register_spi_device+0x258/0x390
> [   17.082147]  of_register_spi_device from spi_register_controller+0x26c/0x6d8
> [   17.095970]  spi_register_controller from devm_spi_register_controller+0x24/0x60
> [   17.113822]  devm_spi_register_controller from omap2_mcspi_probe+0x4c8/0x574
> [   17.126608]  omap2_mcspi_probe from platform_probe+0x6c/0xc8
> [   17.142717]  platform_probe from really_probe+0x110/0x298
> [   17.153835]  really_probe from __driver_probe_device+0x94/0xf4
> [   17.165387]  __driver_probe_device from driver_probe_device+0x44/0xe0
> [   17.175455]  driver_probe_device from __device_attach_driver+0x9c/0xc4
> [   17.189800]  __device_attach_driver from bus_for_each_drv+0x94/0xe4
> [   17.201792]  bus_for_each_drv from __device_attach+0x104/0x170
> [   17.212299]  __device_attach from device_initial_probe+0x1c/0x20
> [   17.222979]  device_initial_probe from bus_probe_device+0x94/0x9c
> [   17.229109]  bus_probe_device from deferred_probe_work_func+0x8c/0xb8
> [   17.241277]  deferred_probe_work_func from process_one_work+0x1e0/0x53c
> [   17.255728]  process_one_work from worker_thread+0x238/0x4fc
> [   17.271836]  worker_thread from kthread+0x108/0x138
> [   17.328184] mscc-miim ocelot-miim0.2.auto: DMA mask not set

Unfortunately I don't have any hardware to test, but I think what
happens is:

mfd_add_device()
{
	calls platform_device_alloc()
		calls setup_pdev_dma_masks()
			sets up the default pdev->dev.dma_mask pointer

	overwrites pdev->dev.dma_mask with parent->dma_mask;
	// your parent->dma_mask is NULL

	calls platform_device_add()
		...
		calls of_dma_configure_id
			complains that pdev->dev.dma_mask is NULL (i.e.
			the bus hasn't bothered setting up a default DMA
			mask, which in fact it did)
}

I don't have enough background regarding the justification for commit
b018e1361bad ("mfd: core: Copy DMA mask and params from parent"), but it
might be detrimential in some cases?

The warning is printed since the slightly unrelated commit 4d8bde883bfb
("OF: Don't set default coherent DMA mask").
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-10 16:13             ` Colin Foster
@ 2022-05-12  9:49               ` Lee Jones
  -1 siblings, 0 replies; 114+ messages in thread
From: Lee Jones @ 2022-05-12  9:49 UTC (permalink / raw)
  To: Colin Foster
  Cc: Vladimir Oltean, linux-arm-kernel, linux-gpio, netdev,
	Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil

On Tue, 10 May 2022, Colin Foster wrote:

> On Tue, May 10, 2022 at 04:32:26PM +0100, Lee Jones wrote:
> > On Mon, 09 May 2022, Vladimir Oltean wrote:
> > 
> > > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > > > +						const struct resource *res)
> > > > > > +{
> > > > > > +	struct device *dev = child->parent;
> > > > > > +
> > > > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > > > 
> > > > > So much for being bus-agnostic :-/
> > > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > > > 
> > > > That was my initial design. "core" was calling into "spi" exclusively
> > > > via function pointers.
> > > > 
> > > > The request was "Please find a clearer way to do this without function
> > > > pointers"
> > > > 
> > > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> > > 
> > > Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> > > with the comment that you aren't configuring a bus. In this context it
> > > seems more appropriate to call this function pointer "init_regmap", with
> > > different implementations per transport.
> > 
> > FWIW, I'm still against using function pointers for this.
> > 
> > What about making ocelot_init_regmap_from_resource() an inline
> > function and pushing it into one of the header files?
> > 
> > [As an aside, you don't need to pass both dev (parent) and child]
> 
> I see your point. This wasn't always the case, since ocelot-core prior
> to v8 would call ocelot_spi_devm_init_regmap. Since this was changed,
> the "dev, dev" part can all be handled internally. That's nice.
> 
> > 
> > In there you could simply do:
> > 
> > inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
> > 						       const struct resource *res)
> > {
> > 	if (dev_get_drvdata(dev->parent)->spi)
> > 		return ocelot_spi_devm_init_regmap(dev, res);
> > 
> > 	return NULL;
> > }
> 
> If I do this, won't I have to declare ocelot_spi_devm_init_regmap in a
> larger scope (include/soc/mscc/ocelot.h)? I like the idea of keeping it
> more hidden inside drivers/mfd/ocelot.h, assuming I can't keep it
> enclosed in drivers/mfd/ocelot-spi.c entirely.

Yes, it will have the same scope as ocelot_init_regmap_from_resource().

Have you considered include/linux/mfd?

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-12  9:49               ` Lee Jones
  0 siblings, 0 replies; 114+ messages in thread
From: Lee Jones @ 2022-05-12  9:49 UTC (permalink / raw)
  To: Colin Foster
  Cc: Vladimir Oltean, linux-arm-kernel, linux-gpio, netdev,
	Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil

On Tue, 10 May 2022, Colin Foster wrote:

> On Tue, May 10, 2022 at 04:32:26PM +0100, Lee Jones wrote:
> > On Mon, 09 May 2022, Vladimir Oltean wrote:
> > 
> > > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > > > +						const struct resource *res)
> > > > > > +{
> > > > > > +	struct device *dev = child->parent;
> > > > > > +
> > > > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > > > 
> > > > > So much for being bus-agnostic :-/
> > > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > > > 
> > > > That was my initial design. "core" was calling into "spi" exclusively
> > > > via function pointers.
> > > > 
> > > > The request was "Please find a clearer way to do this without function
> > > > pointers"
> > > > 
> > > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> > > 
> > > Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> > > with the comment that you aren't configuring a bus. In this context it
> > > seems more appropriate to call this function pointer "init_regmap", with
> > > different implementations per transport.
> > 
> > FWIW, I'm still against using function pointers for this.
> > 
> > What about making ocelot_init_regmap_from_resource() an inline
> > function and pushing it into one of the header files?
> > 
> > [As an aside, you don't need to pass both dev (parent) and child]
> 
> I see your point. This wasn't always the case, since ocelot-core prior
> to v8 would call ocelot_spi_devm_init_regmap. Since this was changed,
> the "dev, dev" part can all be handled internally. That's nice.
> 
> > 
> > In there you could simply do:
> > 
> > inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
> > 						       const struct resource *res)
> > {
> > 	if (dev_get_drvdata(dev->parent)->spi)
> > 		return ocelot_spi_devm_init_regmap(dev, res);
> > 
> > 	return NULL;
> > }
> 
> If I do this, won't I have to declare ocelot_spi_devm_init_regmap in a
> larger scope (include/soc/mscc/ocelot.h)? I like the idea of keeping it
> more hidden inside drivers/mfd/ocelot.h, assuming I can't keep it
> enclosed in drivers/mfd/ocelot-spi.c entirely.

Yes, it will have the same scope as ocelot_init_regmap_from_resource().

Have you considered include/linux/mfd?

-- 
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-12  9:49               ` Lee Jones
@ 2022-05-12 15:03                 ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-12 15:03 UTC (permalink / raw)
  To: Lee Jones
  Cc: Vladimir Oltean, linux-arm-kernel, linux-gpio, netdev,
	Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil

On Thu, May 12, 2022 at 10:49:39AM +0100, Lee Jones wrote:
> On Tue, 10 May 2022, Colin Foster wrote:
> 
> > On Tue, May 10, 2022 at 04:32:26PM +0100, Lee Jones wrote:
> > > On Mon, 09 May 2022, Vladimir Oltean wrote:
> > > 
> > > > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > > > > +						const struct resource *res)
> > > > > > > +{
> > > > > > > +	struct device *dev = child->parent;
> > > > > > > +
> > > > > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > > > > 
> > > > > > So much for being bus-agnostic :-/
> > > > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > > > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > > > > 
> > > > > That was my initial design. "core" was calling into "spi" exclusively
> > > > > via function pointers.
> > > > > 
> > > > > The request was "Please find a clearer way to do this without function
> > > > > pointers"
> > > > > 
> > > > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> > > > 
> > > > Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> > > > with the comment that you aren't configuring a bus. In this context it
> > > > seems more appropriate to call this function pointer "init_regmap", with
> > > > different implementations per transport.
> > > 
> > > FWIW, I'm still against using function pointers for this.
> > > 
> > > What about making ocelot_init_regmap_from_resource() an inline
> > > function and pushing it into one of the header files?
> > > 
> > > [As an aside, you don't need to pass both dev (parent) and child]
> > 
> > I see your point. This wasn't always the case, since ocelot-core prior
> > to v8 would call ocelot_spi_devm_init_regmap. Since this was changed,
> > the "dev, dev" part can all be handled internally. That's nice.
> > 
> > > 
> > > In there you could simply do:
> > > 
> > > inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
> > > 						       const struct resource *res)
> > > {
> > > 	if (dev_get_drvdata(dev->parent)->spi)
> > > 		return ocelot_spi_devm_init_regmap(dev, res);
> > > 
> > > 	return NULL;
> > > }
> > 
> > If I do this, won't I have to declare ocelot_spi_devm_init_regmap in a
> > larger scope (include/soc/mscc/ocelot.h)? I like the idea of keeping it
> > more hidden inside drivers/mfd/ocelot.h, assuming I can't keep it
> > enclosed in drivers/mfd/ocelot-spi.c entirely.
> 
> Yes, it will have the same scope as ocelot_init_regmap_from_resource().
> 
> Have you considered include/linux/mfd?

I hadn't, but that seems to make sense here. I'll try to get all the
suggestions implemented in the next few days and send something back
out.

Thanks for the feedback!

> 
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-05-12 15:03                 ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-12 15:03 UTC (permalink / raw)
  To: Lee Jones
  Cc: Vladimir Oltean, linux-arm-kernel, linux-gpio, netdev,
	Terry Bowman, Wolfram Sang, Andy Shevchenko, Steen Hegelund,
	Lars Povlsen, Linus Walleij, Russell King, Heiner Kallweit,
	Paolo Abeni, Jakub Kicinski, Eric Dumazet, David S. Miller,
	Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
	Alexandre Belloni, Claudiu Manoil

On Thu, May 12, 2022 at 10:49:39AM +0100, Lee Jones wrote:
> On Tue, 10 May 2022, Colin Foster wrote:
> 
> > On Tue, May 10, 2022 at 04:32:26PM +0100, Lee Jones wrote:
> > > On Mon, 09 May 2022, Vladimir Oltean wrote:
> > > 
> > > > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
> > > > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child,
> > > > > > > +						const struct resource *res)
> > > > > > > +{
> > > > > > > +	struct device *dev = child->parent;
> > > > > > > +
> > > > > > > +	return ocelot_spi_devm_init_regmap(dev, child, res);
> > > > > > 
> > > > > > So much for being bus-agnostic :-/
> > > > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap()
> > > > > > via a function pointer which is populated by ocelot-spi.c? If you do
> > > > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff.
> > > > > 
> > > > > That was my initial design. "core" was calling into "spi" exclusively
> > > > > via function pointers.
> > > > > 
> > > > > The request was "Please find a clearer way to do this without function
> > > > > pointers"
> > > > > 
> > > > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@google.com/
> > > > 
> > > > Yeah, I'm not sure what Lee was looking for, either. In any case I agree
> > > > with the comment that you aren't configuring a bus. In this context it
> > > > seems more appropriate to call this function pointer "init_regmap", with
> > > > different implementations per transport.
> > > 
> > > FWIW, I'm still against using function pointers for this.
> > > 
> > > What about making ocelot_init_regmap_from_resource() an inline
> > > function and pushing it into one of the header files?
> > > 
> > > [As an aside, you don't need to pass both dev (parent) and child]
> > 
> > I see your point. This wasn't always the case, since ocelot-core prior
> > to v8 would call ocelot_spi_devm_init_regmap. Since this was changed,
> > the "dev, dev" part can all be handled internally. That's nice.
> > 
> > > 
> > > In there you could simply do:
> > > 
> > > inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev,
> > > 						       const struct resource *res)
> > > {
> > > 	if (dev_get_drvdata(dev->parent)->spi)
> > > 		return ocelot_spi_devm_init_regmap(dev, res);
> > > 
> > > 	return NULL;
> > > }
> > 
> > If I do this, won't I have to declare ocelot_spi_devm_init_regmap in a
> > larger scope (include/soc/mscc/ocelot.h)? I like the idea of keeping it
> > more hidden inside drivers/mfd/ocelot.h, assuming I can't keep it
> > enclosed in drivers/mfd/ocelot-spi.c entirely.
> 
> Yes, it will have the same scope as ocelot_init_regmap_from_resource().
> 
> Have you considered include/linux/mfd?

I hadn't, but that seems to make sense here. I'll try to get all the
suggestions implemented in the next few days and send something back
out.

Thanks for the feedback!

> 
> -- 
> 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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-09 17:13   ` Vladimir Oltean
@ 2022-05-14 22:00     ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-14 22:00 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > 
> > 		mdio0: mdio0@0 {
> 
> This is going to be interesting. Some drivers with multiple MDIO buses
> create an "mdios" container with #address-cells = <1> and put the MDIO
> bus nodes under that. Others create an "mdio" node and an "mdio0" node
> (and no address for either of them).
> 
> The problem with the latter approach is that
> Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> "mdio0"/"mdio1" node name for an MDIO bus.

I'm starting this implementation. Yep - it is interesting.

A quick grep for "mdios" only shows one hit:
arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts

While that has an mdios field (two, actually), each only has one mdio
bus, and they all seem to get parsed / registered through
sja1105_mdiobus_.*_register.


Is this change correct (I have a feeling it isn't):

ocelot-chip@0 {
    #address-cells = <1>;
    #size-cells = <0>;

    ...

    mdio0: mdio@0 {
        reg=<0>;
        ...
    };

    mdio1: mdio@1 {
        reg = <1>;
        ...
    };
    ...
};

When I run this with MFD's (use,)of_reg, things work as I'd expect. But
I don't directly have the option to use an "mdios" container here
because MFD runs "for_each_child_of_node" doesn't dig into
mdios->mdio0...

> 
> > 			compatible = "mscc,ocelot-miim";
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy0: ethernet-phy@0 {
> > 				reg = <0x0>;
> > 			};
> > 
> > 			sw_phy1: ethernet-phy@1 {
> > 				reg = <0x1>;
> > 			};
> > 
> > 			sw_phy2: ethernet-phy@2 {
> > 				reg = <0x2>;
> > 			};
> > 
> > 			sw_phy3: ethernet-phy@3 {
> > 				reg = <0x3>;
> > 			};
> > 		};
> > 
> > 		mdio1: mdio1@1 {
> > 			compatible = "mscc,ocelot-miim";
> > 			pinctrl-names = "default";
> > 			pinctrl-0 = <&miim1>;
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy4: ethernet-phy@4 {
> > 				reg = <0x4>;
> > 			};
> > 
> > 			sw_phy5: ethernet-phy@5 {
> > 				reg = <0x5>;
> > 			};
> > 
> > 			sw_phy6: ethernet-phy@6 {
> > 				reg = <0x6>;
> > 			};
> > 
> > 			sw_phy7: ethernet-phy@7 {
> > 				reg = <0x7>;
> > 			};
> > 		};
> > 

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-14 22:00     ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-14 22:00 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > 
> > 		mdio0: mdio0@0 {
> 
> This is going to be interesting. Some drivers with multiple MDIO buses
> create an "mdios" container with #address-cells = <1> and put the MDIO
> bus nodes under that. Others create an "mdio" node and an "mdio0" node
> (and no address for either of them).
> 
> The problem with the latter approach is that
> Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> "mdio0"/"mdio1" node name for an MDIO bus.

I'm starting this implementation. Yep - it is interesting.

A quick grep for "mdios" only shows one hit:
arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts

While that has an mdios field (two, actually), each only has one mdio
bus, and they all seem to get parsed / registered through
sja1105_mdiobus_.*_register.


Is this change correct (I have a feeling it isn't):

ocelot-chip@0 {
    #address-cells = <1>;
    #size-cells = <0>;

    ...

    mdio0: mdio@0 {
        reg=<0>;
        ...
    };

    mdio1: mdio@1 {
        reg = <1>;
        ...
    };
    ...
};

When I run this with MFD's (use,)of_reg, things work as I'd expect. But
I don't directly have the option to use an "mdios" container here
because MFD runs "for_each_child_of_node" doesn't dig into
mdios->mdio0...

> 
> > 			compatible = "mscc,ocelot-miim";
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy0: ethernet-phy@0 {
> > 				reg = <0x0>;
> > 			};
> > 
> > 			sw_phy1: ethernet-phy@1 {
> > 				reg = <0x1>;
> > 			};
> > 
> > 			sw_phy2: ethernet-phy@2 {
> > 				reg = <0x2>;
> > 			};
> > 
> > 			sw_phy3: ethernet-phy@3 {
> > 				reg = <0x3>;
> > 			};
> > 		};
> > 
> > 		mdio1: mdio1@1 {
> > 			compatible = "mscc,ocelot-miim";
> > 			pinctrl-names = "default";
> > 			pinctrl-0 = <&miim1>;
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy4: ethernet-phy@4 {
> > 				reg = <0x4>;
> > 			};
> > 
> > 			sw_phy5: ethernet-phy@5 {
> > 				reg = <0x5>;
> > 			};
> > 
> > 			sw_phy6: ethernet-phy@6 {
> > 				reg = <0x6>;
> > 			};
> > 
> > 			sw_phy7: ethernet-phy@7 {
> > 				reg = <0x7>;
> > 			};
> > 		};
> > 

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-14 22:00     ` Colin Foster
@ 2022-05-19 14:44       ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-19 14:44 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Colin,

On Sat, May 14, 2022 at 03:00:10PM -0700, Colin Foster wrote:
> On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > Hi Colin,
> > 
> > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > > 
> > > 		mdio0: mdio0@0 {
> > 
> > This is going to be interesting. Some drivers with multiple MDIO buses
> > create an "mdios" container with #address-cells = <1> and put the MDIO
> > bus nodes under that. Others create an "mdio" node and an "mdio0" node
> > (and no address for either of them).
> > 
> > The problem with the latter approach is that
> > Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> > "mdio0"/"mdio1" node name for an MDIO bus.
> 
> I'm starting this implementation. Yep - it is interesting.
> 
> A quick grep for "mdios" only shows one hit:
> arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
> 
> While that has an mdios field (two, actually), each only has one mdio
> bus, and they all seem to get parsed / registered through
> sja1105_mdiobus_.*_register.
> 
> 
> Is this change correct (I have a feeling it isn't):
> 
> ocelot-chip@0 {
>     #address-cells = <1>;
>     #size-cells = <0>;
> 
>     ...
> 
>     mdio0: mdio@0 {
>         reg=<0>;
>         ...
>     };
> 
>     mdio1: mdio@1 {
>         reg = <1>;
>         ...
>     };
>     ...
> };
> 
> When I run this with MFD's (use,)of_reg, things work as I'd expect. But
> I don't directly have the option to use an "mdios" container here
> because MFD runs "for_each_child_of_node" doesn't dig into
> mdios->mdio0...

Sorry for the delayed response. I think you can avoid creating an
"mdios" container node, but you need to provide some "reg" values based
on which the MDIO controllers can be distinguished. What is your convention
for "reg" values of MFD cells? Maybe pass the base address/size of this
device's regmap as the "reg", even if the driver itself won't use it?

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-19 14:44       ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-19 14:44 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Colin,

On Sat, May 14, 2022 at 03:00:10PM -0700, Colin Foster wrote:
> On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > Hi Colin,
> > 
> > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > > 
> > > 		mdio0: mdio0@0 {
> > 
> > This is going to be interesting. Some drivers with multiple MDIO buses
> > create an "mdios" container with #address-cells = <1> and put the MDIO
> > bus nodes under that. Others create an "mdio" node and an "mdio0" node
> > (and no address for either of them).
> > 
> > The problem with the latter approach is that
> > Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> > "mdio0"/"mdio1" node name for an MDIO bus.
> 
> I'm starting this implementation. Yep - it is interesting.
> 
> A quick grep for "mdios" only shows one hit:
> arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
> 
> While that has an mdios field (two, actually), each only has one mdio
> bus, and they all seem to get parsed / registered through
> sja1105_mdiobus_.*_register.
> 
> 
> Is this change correct (I have a feeling it isn't):
> 
> ocelot-chip@0 {
>     #address-cells = <1>;
>     #size-cells = <0>;
> 
>     ...
> 
>     mdio0: mdio@0 {
>         reg=<0>;
>         ...
>     };
> 
>     mdio1: mdio@1 {
>         reg = <1>;
>         ...
>     };
>     ...
> };
> 
> When I run this with MFD's (use,)of_reg, things work as I'd expect. But
> I don't directly have the option to use an "mdios" container here
> because MFD runs "for_each_child_of_node" doesn't dig into
> mdios->mdio0...

Sorry for the delayed response. I think you can avoid creating an
"mdios" container node, but you need to provide some "reg" values based
on which the MDIO controllers can be distinguished. What is your convention
for "reg" values of MFD cells? Maybe pass the base address/size of this
device's regmap as the "reg", even if the driver itself won't use it?
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-19 14:44       ` Vladimir Oltean
@ 2022-05-19 16:15         ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-19 16:15 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Vladimir,

On Thu, May 19, 2022 at 02:44:41PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sat, May 14, 2022 at 03:00:10PM -0700, Colin Foster wrote:
> > On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > > Hi Colin,
> > > 
> > > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > > > 
> > > > 		mdio0: mdio0@0 {
> > > 
> > > This is going to be interesting. Some drivers with multiple MDIO buses
> > > create an "mdios" container with #address-cells = <1> and put the MDIO
> > > bus nodes under that. Others create an "mdio" node and an "mdio0" node
> > > (and no address for either of them).
> > > 
> > > The problem with the latter approach is that
> > > Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> > > "mdio0"/"mdio1" node name for an MDIO bus.
> > 
> > I'm starting this implementation. Yep - it is interesting.
> > 
> > A quick grep for "mdios" only shows one hit:
> > arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
> > 
> > While that has an mdios field (two, actually), each only has one mdio
> > bus, and they all seem to get parsed / registered through
> > sja1105_mdiobus_.*_register.
> > 
> > 
> > Is this change correct (I have a feeling it isn't):
> > 
> > ocelot-chip@0 {
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> > 
> >     ...
> > 
> >     mdio0: mdio@0 {
> >         reg=<0>;
> >         ...
> >     };
> > 
> >     mdio1: mdio@1 {
> >         reg = <1>;
> >         ...
> >     };
> >     ...
> > };
> > 
> > When I run this with MFD's (use,)of_reg, things work as I'd expect. But
> > I don't directly have the option to use an "mdios" container here
> > because MFD runs "for_each_child_of_node" doesn't dig into
> > mdios->mdio0...
> 
> Sorry for the delayed response. I think you can avoid creating an
> "mdios" container node, but you need to provide some "reg" values based
> on which the MDIO controllers can be distinguished. What is your convention
> for "reg" values of MFD cells? Maybe pass the base address/size of this
> device's regmap as the "reg", even if the driver itself won't use it?

No worries. Everyone is busy.

Right now it looks like this:

}, {
    .name = "ocelot-miim0",
    .of_compatible = "mscc,ocelot-miim",
    .of_reg = 0,
    .use_of_reg = true,
    .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
    .resources = vsc7512_miim0_resources,
}, {
    .name = "ocelot-miim1",
    .of_compatible = "mscc,ocelot-miim",
    .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
    .of_reg = 1,
    .use_of_reg = true,
    .resources = vsc7512_miim1_resources,
}, {

"0" and "1" being somewhat arbitrary... although they are named as such
in the datasheet.


So you're thinking it might look more like:

.of_reg = vsc7512_miim0_resources[0].start,

and the device tree would be:

mdio0: mdio@0x7107009c {
    reg = <0x7107009c>;
};


I could see that making sense. The main thing I don't like is applying
the address-cells to every peripheral in the switch. It seems incorrect
to have:

switch {
    address-cells = <1>;
    mdio0: mdio@7107009c {
        reg = <0x7107009c>;
    };
    gpio: pinctrl {
        /* No reg parameter */
    };
};

That's what I currently have. To my surprise it actually doesn't throw
any warnings, which I would've expected.


I could see either 0/1 or the actual base addresses making sense.
Whichever you'd suggest.

I've got another day or two to button things up, so it looks like I
missed the boat for this release. This should be ready to go on day 1
after the window.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-19 16:15         ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-05-19 16:15 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Vladimir,

On Thu, May 19, 2022 at 02:44:41PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sat, May 14, 2022 at 03:00:10PM -0700, Colin Foster wrote:
> > On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > > Hi Colin,
> > > 
> > > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > > > 
> > > > 		mdio0: mdio0@0 {
> > > 
> > > This is going to be interesting. Some drivers with multiple MDIO buses
> > > create an "mdios" container with #address-cells = <1> and put the MDIO
> > > bus nodes under that. Others create an "mdio" node and an "mdio0" node
> > > (and no address for either of them).
> > > 
> > > The problem with the latter approach is that
> > > Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> > > "mdio0"/"mdio1" node name for an MDIO bus.
> > 
> > I'm starting this implementation. Yep - it is interesting.
> > 
> > A quick grep for "mdios" only shows one hit:
> > arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
> > 
> > While that has an mdios field (two, actually), each only has one mdio
> > bus, and they all seem to get parsed / registered through
> > sja1105_mdiobus_.*_register.
> > 
> > 
> > Is this change correct (I have a feeling it isn't):
> > 
> > ocelot-chip@0 {
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> > 
> >     ...
> > 
> >     mdio0: mdio@0 {
> >         reg=<0>;
> >         ...
> >     };
> > 
> >     mdio1: mdio@1 {
> >         reg = <1>;
> >         ...
> >     };
> >     ...
> > };
> > 
> > When I run this with MFD's (use,)of_reg, things work as I'd expect. But
> > I don't directly have the option to use an "mdios" container here
> > because MFD runs "for_each_child_of_node" doesn't dig into
> > mdios->mdio0...
> 
> Sorry for the delayed response. I think you can avoid creating an
> "mdios" container node, but you need to provide some "reg" values based
> on which the MDIO controllers can be distinguished. What is your convention
> for "reg" values of MFD cells? Maybe pass the base address/size of this
> device's regmap as the "reg", even if the driver itself won't use it?

No worries. Everyone is busy.

Right now it looks like this:

}, {
    .name = "ocelot-miim0",
    .of_compatible = "mscc,ocelot-miim",
    .of_reg = 0,
    .use_of_reg = true,
    .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
    .resources = vsc7512_miim0_resources,
}, {
    .name = "ocelot-miim1",
    .of_compatible = "mscc,ocelot-miim",
    .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
    .of_reg = 1,
    .use_of_reg = true,
    .resources = vsc7512_miim1_resources,
}, {

"0" and "1" being somewhat arbitrary... although they are named as such
in the datasheet.


So you're thinking it might look more like:

.of_reg = vsc7512_miim0_resources[0].start,

and the device tree would be:

mdio0: mdio@0x7107009c {
    reg = <0x7107009c>;
};


I could see that making sense. The main thing I don't like is applying
the address-cells to every peripheral in the switch. It seems incorrect
to have:

switch {
    address-cells = <1>;
    mdio0: mdio@7107009c {
        reg = <0x7107009c>;
    };
    gpio: pinctrl {
        /* No reg parameter */
    };
};

That's what I currently have. To my surprise it actually doesn't throw
any warnings, which I would've expected.


I could see either 0/1 or the actual base addresses making sense.
Whichever you'd suggest.

I've got another day or two to button things up, so it looks like I
missed the boat for this release. This should be ready to go on day 1
after the window.

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
  2022-05-19 16:15         ` Colin Foster
@ 2022-05-19 17:09           ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-19 17:09 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Thu, May 19, 2022 at 09:15:00AM -0700, Colin Foster wrote:
> Hi Vladimir,
> 
> On Thu, May 19, 2022 at 02:44:41PM +0000, Vladimir Oltean wrote:
> > Hi Colin,
> > 
> > On Sat, May 14, 2022 at 03:00:10PM -0700, Colin Foster wrote:
> > > On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > > > Hi Colin,
> > > > 
> > > > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > > > > 
> > > > > 		mdio0: mdio0@0 {
> > > > 
> > > > This is going to be interesting. Some drivers with multiple MDIO buses
> > > > create an "mdios" container with #address-cells = <1> and put the MDIO
> > > > bus nodes under that. Others create an "mdio" node and an "mdio0" node
> > > > (and no address for either of them).
> > > > 
> > > > The problem with the latter approach is that
> > > > Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> > > > "mdio0"/"mdio1" node name for an MDIO bus.
> > > 
> > > I'm starting this implementation. Yep - it is interesting.
> > > 
> > > A quick grep for "mdios" only shows one hit:
> > > arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
> > > 
> > > While that has an mdios field (two, actually), each only has one mdio
> > > bus, and they all seem to get parsed / registered through
> > > sja1105_mdiobus_.*_register.
> > > 
> > > 
> > > Is this change correct (I have a feeling it isn't):
> > > 
> > > ocelot-chip@0 {
> > >     #address-cells = <1>;
> > >     #size-cells = <0>;
> > > 
> > >     ...
> > > 
> > >     mdio0: mdio@0 {
> > >         reg=<0>;
> > >         ...
> > >     };
> > > 
> > >     mdio1: mdio@1 {
> > >         reg = <1>;
> > >         ...
> > >     };
> > >     ...
> > > };
> > > 
> > > When I run this with MFD's (use,)of_reg, things work as I'd expect. But
> > > I don't directly have the option to use an "mdios" container here
> > > because MFD runs "for_each_child_of_node" doesn't dig into
> > > mdios->mdio0...
> > 
> > Sorry for the delayed response. I think you can avoid creating an
> > "mdios" container node, but you need to provide some "reg" values based
> > on which the MDIO controllers can be distinguished. What is your convention
> > for "reg" values of MFD cells? Maybe pass the base address/size of this
> > device's regmap as the "reg", even if the driver itself won't use it?
> 
> No worries. Everyone is busy.
> 
> Right now it looks like this:
> 
> }, {
>     .name = "ocelot-miim0",
>     .of_compatible = "mscc,ocelot-miim",
>     .of_reg = 0,
>     .use_of_reg = true,
>     .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
>     .resources = vsc7512_miim0_resources,
> }, {
>     .name = "ocelot-miim1",
>     .of_compatible = "mscc,ocelot-miim",
>     .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
>     .of_reg = 1,
>     .use_of_reg = true,
>     .resources = vsc7512_miim1_resources,
> }, {
> 
> "0" and "1" being somewhat arbitrary... although they are named as such
> in the datasheet.
> 
> 
> So you're thinking it might look more like:
> 
> .of_reg = vsc7512_miim0_resources[0].start,
> 
> and the device tree would be:
> 
> mdio0: mdio@0x7107009c {
>     reg = <0x7107009c>;
> };

Yeah, this is what I was thinking.

> I could see that making sense. The main thing I don't like is applying
> the address-cells to every peripheral in the switch. It seems incorrect
> to have:
> 
> switch {
>     address-cells = <1>;
>     mdio0: mdio@7107009c {
>         reg = <0x7107009c>;
>     };
>     gpio: pinctrl {
>         /* No reg parameter */
>     };
> };
> 
> That's what I currently have. To my surprise it actually doesn't throw
> any warnings, which I would've expected.

I tried mangling some device trees and indeed it looks like dtc won't
warn, but I still think it's invalid to mix node address conventions
with the same #address-cells. Maybe if that wasn't the case things would
be easier.

> I could see either 0/1 or the actual base addresses making sense.
> Whichever you'd suggest.

The idea with putting the actual base addresses was that you could then
do that for all cells, like the pinctrl node, too, and they'd have a
coherent meaning.

> I've got another day or two to button things up, so it looks like I
> missed the boat for this release. This should be ready to go on day 1
> after the window.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI
@ 2022-05-19 17:09           ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-05-19 17:09 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, linux-gpio, netdev, Terry Bowman, Wolfram Sang,
	Andy Shevchenko, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

On Thu, May 19, 2022 at 09:15:00AM -0700, Colin Foster wrote:
> Hi Vladimir,
> 
> On Thu, May 19, 2022 at 02:44:41PM +0000, Vladimir Oltean wrote:
> > Hi Colin,
> > 
> > On Sat, May 14, 2022 at 03:00:10PM -0700, Colin Foster wrote:
> > > On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > > > Hi Colin,
> > > > 
> > > > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > > > > 
> > > > > 		mdio0: mdio0@0 {
> > > > 
> > > > This is going to be interesting. Some drivers with multiple MDIO buses
> > > > create an "mdios" container with #address-cells = <1> and put the MDIO
> > > > bus nodes under that. Others create an "mdio" node and an "mdio0" node
> > > > (and no address for either of them).
> > > > 
> > > > The problem with the latter approach is that
> > > > Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> > > > "mdio0"/"mdio1" node name for an MDIO bus.
> > > 
> > > I'm starting this implementation. Yep - it is interesting.
> > > 
> > > A quick grep for "mdios" only shows one hit:
> > > arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
> > > 
> > > While that has an mdios field (two, actually), each only has one mdio
> > > bus, and they all seem to get parsed / registered through
> > > sja1105_mdiobus_.*_register.
> > > 
> > > 
> > > Is this change correct (I have a feeling it isn't):
> > > 
> > > ocelot-chip@0 {
> > >     #address-cells = <1>;
> > >     #size-cells = <0>;
> > > 
> > >     ...
> > > 
> > >     mdio0: mdio@0 {
> > >         reg=<0>;
> > >         ...
> > >     };
> > > 
> > >     mdio1: mdio@1 {
> > >         reg = <1>;
> > >         ...
> > >     };
> > >     ...
> > > };
> > > 
> > > When I run this with MFD's (use,)of_reg, things work as I'd expect. But
> > > I don't directly have the option to use an "mdios" container here
> > > because MFD runs "for_each_child_of_node" doesn't dig into
> > > mdios->mdio0...
> > 
> > Sorry for the delayed response. I think you can avoid creating an
> > "mdios" container node, but you need to provide some "reg" values based
> > on which the MDIO controllers can be distinguished. What is your convention
> > for "reg" values of MFD cells? Maybe pass the base address/size of this
> > device's regmap as the "reg", even if the driver itself won't use it?
> 
> No worries. Everyone is busy.
> 
> Right now it looks like this:
> 
> }, {
>     .name = "ocelot-miim0",
>     .of_compatible = "mscc,ocelot-miim",
>     .of_reg = 0,
>     .use_of_reg = true,
>     .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
>     .resources = vsc7512_miim0_resources,
> }, {
>     .name = "ocelot-miim1",
>     .of_compatible = "mscc,ocelot-miim",
>     .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
>     .of_reg = 1,
>     .use_of_reg = true,
>     .resources = vsc7512_miim1_resources,
> }, {
> 
> "0" and "1" being somewhat arbitrary... although they are named as such
> in the datasheet.
> 
> 
> So you're thinking it might look more like:
> 
> .of_reg = vsc7512_miim0_resources[0].start,
> 
> and the device tree would be:
> 
> mdio0: mdio@0x7107009c {
>     reg = <0x7107009c>;
> };

Yeah, this is what I was thinking.

> I could see that making sense. The main thing I don't like is applying
> the address-cells to every peripheral in the switch. It seems incorrect
> to have:
> 
> switch {
>     address-cells = <1>;
>     mdio0: mdio@7107009c {
>         reg = <0x7107009c>;
>     };
>     gpio: pinctrl {
>         /* No reg parameter */
>     };
> };
> 
> That's what I currently have. To my surprise it actually doesn't throw
> any warnings, which I would've expected.

I tried mangling some device trees and indeed it looks like dtc won't
warn, but I still think it's invalid to mix node address conventions
with the same #address-cells. Maybe if that wasn't the case things would
be easier.

> I could see either 0/1 or the actual base addresses making sense.
> Whichever you'd suggest.

The idea with putting the actual base addresses was that you could then
do that for all cells, like the pinctrl node, too, and they'd have a
coherent meaning.

> I've got another day or two to button things up, so it looks like I
> missed the boat for this release. This should be ready to go on day 1
> after the window.
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
  2022-05-09  9:02     ` Andy Shevchenko
@ 2022-08-19 16:50       ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-08-19 16:50 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Colin Foster, linux-arm-kernel, linux-gpio, netdev, Terry Bowman,
	Wolfram Sang, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Andy,

On Mon, May 09, 2022 at 11:02:42AM +0200, Andy Shevchenko wrote:
> > +EXPORT_SYMBOL(ocelot_chip_reset);
> 
> Please, switch to the namespace (_NS) variant of the exported-imported
> symbols for these drivers.

This was recently brought to my attention by Colin. Could you please
explain what are the benefits of using symbol namespaces in this case?
_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi
@ 2022-08-19 16:50       ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-08-19 16:50 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Colin Foster, linux-arm-kernel, linux-gpio, netdev, Terry Bowman,
	Wolfram Sang, Steen Hegelund, Lars Povlsen, Linus Walleij,
	Russell King, Heiner Kallweit, Paolo Abeni, Jakub Kicinski,
	Eric Dumazet, David S. Miller, Florian Fainelli, Vivien Didelot,
	Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
	Lee Jones

Hi Andy,

On Mon, May 09, 2022 at 11:02:42AM +0200, Andy Shevchenko wrote:
> > +EXPORT_SYMBOL(ocelot_chip_reset);
> 
> Please, switch to the namespace (_NS) variant of the exported-imported
> symbols for these drivers.

This was recently brought to my attention by Colin. Could you please
explain what are the benefits of using symbol namespaces in this case?

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-05-09 17:58             ` Vladimir Oltean
@ 2022-09-09 18:33               ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-09-09 18:33 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, netdev, Steen Hegelund, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Mon, May 09, 2022 at 05:58:07PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 05:55:37PM -0700, Colin Foster wrote:
> > Hmm... So the main reason I needed get_caps was because
> > phylink_generic_validate looks at mac_capabilities. I know I'll have to
> > deal with supported_interfaces once I finally get the other four ports
> > working, but for now the main purpose of this patch is to allow me to
> > populate the mac_capabilities entry for phylink_generic_validate.
> > 
> > Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
> > of the patch makes sense.
> 
> But still. Just populate mac_capabilities for everybody in the common
> felix_phylink_get_caps(), and use the generic phylink validation only
> for your driver.

Resurrecting this thread, now that I'm back into the networking stuff. I
removed some people from the CC chain who I think were MFD / GPIO specific.

v1 of my upcoming "add dsa capabilities to the vsc7512" will build off
these suggestions, but these DSA patches were dropped in the MFD set.


Restoring context: my oritinal patch was:

+++ b/drivers/net/dsa/ocelot/felix.c
@@ -982,15 +982,23 @@  static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
 				   struct phylink_config *config)
 {
 	struct ocelot *ocelot = ds->priv;
+	struct felix *felix;

-	/* This driver does not make use of the speed, duplex, pause or the
-	 * advertisement in its mac_config, so it is safe to mark this driver
-	 * as non-legacy.
-	 */
-	config->legacy_pre_march2020 = false;
+	felix = ocelot_to_felix(ocelot);
+
+	if (felix->info->phylink_get_caps) {
+		felix->info->phylink_get_caps(ocelot, port, config);
+	} else {

-	__set_bit(ocelot->ports[port]->phy_mode,
-		  config->supported_interfaces);
+		/* This driver does not make use of the speed, duplex, pause or
+		 * the advertisement in its mac_config, so it is safe to mark
+		 * this driver as non-legacy.
+		 */
+		config->legacy_pre_march2020 = false;
+
+		__set_bit(ocelot->ports[port]->phy_mode,
+			  config->supported_interfaces);
+	}
 }


Regarding felix_phylink_get_caps() - does it make sense that
mac_capabilities would be the same for all ports? This is where I've
currently landed, and I want to make sure it doesn't have adverse
effects on vsc9959 or seville:

static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
                                   struct phylink_config *config)
{
        struct ocelot *ocelot = ds->priv;
        struct felix *felix;
        u32 modes;
        int i;

        felix = ocelot_to_felix(ocelot);
        modes = felix->info->port_modes[port];

        /* This driver does not make use of the speed, duplex, pause or
         * the advertisement in its mac_config, so it is safe to mark
         * this driver as non-legacy.
         */
        config->legacy_pre_march2020 = false;

        for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++)
                if (modes & felix_phy_match_table[i])
                        __set_bit(i, config->supported_interfaces);

        config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 |
                                   MAC_100 | MAC_1000FD;
}

(this might be two patches - one for the match table and one for the
mac_capabilities)

Seemingly because net/dsa/port.c checks for phylink_validate before it
checks for mac_capabilties, it won't make a difference there, but this
seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
ocelot_port_phylink_create())

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-09-09 18:33               ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-09-09 18:33 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-arm-kernel, netdev, Steen Hegelund, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Mon, May 09, 2022 at 05:58:07PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 05:55:37PM -0700, Colin Foster wrote:
> > Hmm... So the main reason I needed get_caps was because
> > phylink_generic_validate looks at mac_capabilities. I know I'll have to
> > deal with supported_interfaces once I finally get the other four ports
> > working, but for now the main purpose of this patch is to allow me to
> > populate the mac_capabilities entry for phylink_generic_validate.
> > 
> > Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
> > of the patch makes sense.
> 
> But still. Just populate mac_capabilities for everybody in the common
> felix_phylink_get_caps(), and use the generic phylink validation only
> for your driver.

Resurrecting this thread, now that I'm back into the networking stuff. I
removed some people from the CC chain who I think were MFD / GPIO specific.

v1 of my upcoming "add dsa capabilities to the vsc7512" will build off
these suggestions, but these DSA patches were dropped in the MFD set.


Restoring context: my oritinal patch was:

+++ b/drivers/net/dsa/ocelot/felix.c
@@ -982,15 +982,23 @@  static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
 				   struct phylink_config *config)
 {
 	struct ocelot *ocelot = ds->priv;
+	struct felix *felix;

-	/* This driver does not make use of the speed, duplex, pause or the
-	 * advertisement in its mac_config, so it is safe to mark this driver
-	 * as non-legacy.
-	 */
-	config->legacy_pre_march2020 = false;
+	felix = ocelot_to_felix(ocelot);
+
+	if (felix->info->phylink_get_caps) {
+		felix->info->phylink_get_caps(ocelot, port, config);
+	} else {

-	__set_bit(ocelot->ports[port]->phy_mode,
-		  config->supported_interfaces);
+		/* This driver does not make use of the speed, duplex, pause or
+		 * the advertisement in its mac_config, so it is safe to mark
+		 * this driver as non-legacy.
+		 */
+		config->legacy_pre_march2020 = false;
+
+		__set_bit(ocelot->ports[port]->phy_mode,
+			  config->supported_interfaces);
+	}
 }


Regarding felix_phylink_get_caps() - does it make sense that
mac_capabilities would be the same for all ports? This is where I've
currently landed, and I want to make sure it doesn't have adverse
effects on vsc9959 or seville:

static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
                                   struct phylink_config *config)
{
        struct ocelot *ocelot = ds->priv;
        struct felix *felix;
        u32 modes;
        int i;

        felix = ocelot_to_felix(ocelot);
        modes = felix->info->port_modes[port];

        /* This driver does not make use of the speed, duplex, pause or
         * the advertisement in its mac_config, so it is safe to mark
         * this driver as non-legacy.
         */
        config->legacy_pre_march2020 = false;

        for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++)
                if (modes & felix_phy_match_table[i])
                        __set_bit(i, config->supported_interfaces);

        config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 |
                                   MAC_100 | MAC_1000FD;
}

(this might be two patches - one for the match table and one for the
mac_capabilities)

Seemingly because net/dsa/port.c checks for phylink_validate before it
checks for mac_capabilties, it won't make a difference there, but this
seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
ocelot_port_phylink_create())

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-09-09 18:33               ` Colin Foster
@ 2022-09-09 19:20                 ` Russell King (Oracle)
  -1 siblings, 0 replies; 114+ messages in thread
From: Russell King (Oracle) @ 2022-09-09 19:20 UTC (permalink / raw)
  To: Colin Foster
  Cc: Vladimir Oltean, linux-arm-kernel, netdev, Steen Hegelund,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote:
> Seemingly because net/dsa/port.c checks for phylink_validate before it
> checks for mac_capabilties, it won't make a difference there, but this
> seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
> port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
> ocelot_port_phylink_create())

No, the code in dsa_port_phylink_validate() is exactly what I intend.

If there's a phylink_validate() function, then that gets used to cater
for Ocelot's rate adaption in the PCS (where the link modes are not
limited by the interface mode.)

If there isn't a phylink_validate() function, then we require that
mac_capabilities() is filled in, and if it is, we use the generic
validator - essentially I want to see everyone filling in both the
supported interface masks and the MAC capabilities no matter what.

The Ocelot rate adaption is something that needs to be tidied up, but
until that has been done, Ocelot needs to have the phylink_validate()
hook. Ocelot is currently the sole user of this hook.

I have some experimental patches to address this, but nothing that I
felt happy to send out yet.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-09-09 19:20                 ` Russell King (Oracle)
  0 siblings, 0 replies; 114+ messages in thread
From: Russell King (Oracle) @ 2022-09-09 19:20 UTC (permalink / raw)
  To: Colin Foster
  Cc: Vladimir Oltean, linux-arm-kernel, netdev, Steen Hegelund,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote:
> Seemingly because net/dsa/port.c checks for phylink_validate before it
> checks for mac_capabilties, it won't make a difference there, but this
> seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
> port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
> ocelot_port_phylink_create())

No, the code in dsa_port_phylink_validate() is exactly what I intend.

If there's a phylink_validate() function, then that gets used to cater
for Ocelot's rate adaption in the PCS (where the link modes are not
limited by the interface mode.)

If there isn't a phylink_validate() function, then we require that
mac_capabilities() is filled in, and if it is, we use the generic
validator - essentially I want to see everyone filling in both the
supported interface masks and the MAC capabilities no matter what.

The Ocelot rate adaption is something that needs to be tidied up, but
until that has been done, Ocelot needs to have the phylink_validate()
hook. Ocelot is currently the sole user of this hook.

I have some experimental patches to address this, but nothing that I
felt happy to send out yet.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-09-09 19:20                 ` Russell King (Oracle)
@ 2022-09-09 19:30                   ` Colin Foster
  -1 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-09-09 19:30 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Vladimir Oltean, linux-arm-kernel, netdev, Steen Hegelund,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Fri, Sep 09, 2022 at 08:20:03PM +0100, Russell King (Oracle) wrote:
> On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote:
> > Seemingly because net/dsa/port.c checks for phylink_validate before it
> > checks for mac_capabilties, it won't make a difference there, but this
> > seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
> > port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
> > ocelot_port_phylink_create())
> 
> No, the code in dsa_port_phylink_validate() is exactly what I intend.

My apologies... I meant "it seems wrong for me to blindly assign values to
mac_capabilities" not that there are any issues in the logic of
dsa_port_phylink_validate(). My phrasing was misleading.

> 
> If there's a phylink_validate() function, then that gets used to cater
> for Ocelot's rate adaption in the PCS (where the link modes are not
> limited by the interface mode.)
> 
> If there isn't a phylink_validate() function, then we require that
> mac_capabilities() is filled in, and if it is, we use the generic
> validator - essentially I want to see everyone filling in both the
> supported interface masks and the MAC capabilities no matter what.
> 
> The Ocelot rate adaption is something that needs to be tidied up, but
> until that has been done, Ocelot needs to have the phylink_validate()
> hook. Ocelot is currently the sole user of this hook.
> 
> I have some experimental patches to address this, but nothing that I
> felt happy to send out yet.

I think we're on the same page. My version of Ocelot phylink_validate
utilizes phylink_generic_validate while other Felix devices don't, as
intended. Hopefully I'll be able to tidy up this patch set and send it
out for full review soon.

> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-09-09 19:30                   ` Colin Foster
  0 siblings, 0 replies; 114+ messages in thread
From: Colin Foster @ 2022-09-09 19:30 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Vladimir Oltean, linux-arm-kernel, netdev, Steen Hegelund,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Fri, Sep 09, 2022 at 08:20:03PM +0100, Russell King (Oracle) wrote:
> On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote:
> > Seemingly because net/dsa/port.c checks for phylink_validate before it
> > checks for mac_capabilties, it won't make a difference there, but this
> > seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
> > port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
> > ocelot_port_phylink_create())
> 
> No, the code in dsa_port_phylink_validate() is exactly what I intend.

My apologies... I meant "it seems wrong for me to blindly assign values to
mac_capabilities" not that there are any issues in the logic of
dsa_port_phylink_validate(). My phrasing was misleading.

> 
> If there's a phylink_validate() function, then that gets used to cater
> for Ocelot's rate adaption in the PCS (where the link modes are not
> limited by the interface mode.)
> 
> If there isn't a phylink_validate() function, then we require that
> mac_capabilities() is filled in, and if it is, we use the generic
> validator - essentially I want to see everyone filling in both the
> supported interface masks and the MAC capabilities no matter what.
> 
> The Ocelot rate adaption is something that needs to be tidied up, but
> until that has been done, Ocelot needs to have the phylink_validate()
> hook. Ocelot is currently the sole user of this hook.
> 
> I have some experimental patches to address this, but nothing that I
> felt happy to send out yet.

I think we're on the same page. My version of Ocelot phylink_validate
utilizes phylink_generic_validate while other Felix devices don't, as
intended. Hopefully I'll be able to tidy up this patch set and send it
out for full review soon.

> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
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] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
  2022-09-09 18:33               ` Colin Foster
@ 2022-09-11  0:44                 ` Vladimir Oltean
  -1 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-09-11  0:44 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, netdev, Steen Hegelund, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote:
> Regarding felix_phylink_get_caps() - does it make sense that
> mac_capabilities would be the same for all ports? This is where I've
> currently landed, and I want to make sure it doesn't have adverse
> effects on vsc9959 or seville:
> 
> static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
>                                    struct phylink_config *config)
> {
>         struct ocelot *ocelot = ds->priv;
>         struct felix *felix;
>         u32 modes;
>         int i;
> 
>         felix = ocelot_to_felix(ocelot);
>         modes = felix->info->port_modes[port];
> 
>         /* This driver does not make use of the speed, duplex, pause or
>          * the advertisement in its mac_config, so it is safe to mark
>          * this driver as non-legacy.
>          */
>         config->legacy_pre_march2020 = false;
> 
>         for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++)
>                 if (modes & felix_phy_match_table[i])
>                         __set_bit(i, config->supported_interfaces);

The current shape of the SERDES driver used with VSC9959 and VSC9953 is
such that dynamic changes to the SERDES protocol are not supported. So
at least for these 2 switches, please keep setting just the current
ocelot->ports[port]->phy_mode (i.e. what was set in the device tree).

> 
>         config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 |
>                                    MAC_100 | MAC_1000FD;
> }
> 
> (this might be two patches - one for the match table and one for the
> mac_capabilities)
> 
> Seemingly because net/dsa/port.c checks for phylink_validate before it
> checks for mac_capabilties, it won't make a difference there, but this
> seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
> port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
> ocelot_port_phylink_create())

I don't think there is any QSGMII port that supports 2500FD in VSC7514.
In general, the frequency at which QSGMII operates would not be able to
support that data rate.

That must be an artefact of me copying and pasting code from Felix to
Ocelot in commit e6e12df625f2 ("net: mscc: ocelot: convert to phylink"),
later transformed by Russell in commit 7258aa5094db ("net: ocelot_net:
use phylink_generic_validate()").

How about you do the other way around: populate config->mac_capabilities
such that it unconditionally also includes MAC_2500FD. You may have
noticed that phylink_generic_validate() calls phylink_get_linkmodes(),
which contains a logical AND between the capabilities reported by the
MAC, and the plausible capabilities given by state->interface. So it
would be quite within the expectations of this API for phylink to
exclude MAC_2500FD from mac_capabilities if PHY_INTERFACE_MODE_QSGMII is
used.

On the other hand, VSC9959 and VSC9953 do support actual 2.5G on
internal interfaces (and on USXGMII, in the case of VSC9959). They don't
use the generic phylink validation method right now, but it would be
good, in case they get mechanically converted or something, to keep
reporting MAC_2500FD whatever code you add right now.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability
@ 2022-09-11  0:44                 ` Vladimir Oltean
  0 siblings, 0 replies; 114+ messages in thread
From: Vladimir Oltean @ 2022-09-11  0:44 UTC (permalink / raw)
  To: Colin Foster
  Cc: linux-arm-kernel, netdev, Steen Hegelund, Russell King,
	Heiner Kallweit, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
	David S. Miller, Florian Fainelli, Vivien Didelot, Andrew Lunn,
	UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil

On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote:
> Regarding felix_phylink_get_caps() - does it make sense that
> mac_capabilities would be the same for all ports? This is where I've
> currently landed, and I want to make sure it doesn't have adverse
> effects on vsc9959 or seville:
> 
> static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
>                                    struct phylink_config *config)
> {
>         struct ocelot *ocelot = ds->priv;
>         struct felix *felix;
>         u32 modes;
>         int i;
> 
>         felix = ocelot_to_felix(ocelot);
>         modes = felix->info->port_modes[port];
> 
>         /* This driver does not make use of the speed, duplex, pause or
>          * the advertisement in its mac_config, so it is safe to mark
>          * this driver as non-legacy.
>          */
>         config->legacy_pre_march2020 = false;
> 
>         for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++)
>                 if (modes & felix_phy_match_table[i])
>                         __set_bit(i, config->supported_interfaces);

The current shape of the SERDES driver used with VSC9959 and VSC9953 is
such that dynamic changes to the SERDES protocol are not supported. So
at least for these 2 switches, please keep setting just the current
ocelot->ports[port]->phy_mode (i.e. what was set in the device tree).

> 
>         config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 |
>                                    MAC_100 | MAC_1000FD;
> }
> 
> (this might be two patches - one for the match table and one for the
> mac_capabilities)
> 
> Seemingly because net/dsa/port.c checks for phylink_validate before it
> checks for mac_capabilties, it won't make a difference there, but this
> seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII
> port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c
> ocelot_port_phylink_create())

I don't think there is any QSGMII port that supports 2500FD in VSC7514.
In general, the frequency at which QSGMII operates would not be able to
support that data rate.

That must be an artefact of me copying and pasting code from Felix to
Ocelot in commit e6e12df625f2 ("net: mscc: ocelot: convert to phylink"),
later transformed by Russell in commit 7258aa5094db ("net: ocelot_net:
use phylink_generic_validate()").

How about you do the other way around: populate config->mac_capabilities
such that it unconditionally also includes MAC_2500FD. You may have
noticed that phylink_generic_validate() calls phylink_get_linkmodes(),
which contains a logical AND between the capabilities reported by the
MAC, and the plausible capabilities given by state->interface. So it
would be quite within the expectations of this API for phylink to
exclude MAC_2500FD from mac_capabilities if PHY_INTERFACE_MODE_QSGMII is
used.

On the other hand, VSC9959 and VSC9953 do support actual 2.5G on
internal interfaces (and on USXGMII, in the case of VSC9959). They don't
use the generic phylink validation method right now, but it would be
good, in case they get mechanically converted or something, to keep
reporting MAC_2500FD whatever code you add right now.
_______________________________________________
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] 114+ messages in thread

end of thread, other threads:[~2022-09-11  0:46 UTC | newest]

Thread overview: 114+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-08 18:52 [RFC v8 net-next 00/16] add support for VSC7512 control over SPI Colin Foster
2022-05-08 18:52 ` Colin Foster
2022-05-08 18:52 ` [RFC v8 net-next 01/16] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster
2022-05-08 18:52   ` Colin Foster
2022-05-09 10:05   ` Vladimir Oltean
2022-05-09 10:05     ` Vladimir Oltean
2022-05-08 18:52 ` [RFC v8 net-next 02/16] pinctrl: microchip-sgpio: allow sgpio driver to be used " Colin Foster
2022-05-08 18:52   ` Colin Foster
2022-05-09 10:05   ` Vladimir Oltean
2022-05-09 10:05     ` Vladimir Oltean
2022-05-08 18:53 ` [RFC v8 net-next 03/16] net: ocelot: add interface to get regmaps when exernally controlled Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 04/16] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-08 21:14   ` Andy Shevchenko
2022-05-08 21:14     ` Andy Shevchenko
2022-05-08 18:53 ` [RFC v8 net-next 05/16] pinctrl: ocelot: " Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-09  8:37   ` Andy Shevchenko
2022-05-09  8:37     ` Andy Shevchenko
2022-05-08 18:53 ` [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: " Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-09  8:44   ` Andy Shevchenko
2022-05-09  8:44     ` Andy Shevchenko
2022-05-09 22:19     ` Colin Foster
2022-05-09 22:19       ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 07/16] resource: add define macro for register address resources Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-09  9:02   ` Andy Shevchenko
2022-05-09  9:02     ` Andy Shevchenko
2022-05-09 23:15     ` Colin Foster
2022-05-09 23:15       ` Colin Foster
2022-08-19 16:50     ` Vladimir Oltean
2022-08-19 16:50       ` Vladimir Oltean
2022-05-09 10:52   ` Vladimir Oltean
2022-05-09 10:52     ` Vladimir Oltean
2022-05-09 23:49     ` Colin Foster
2022-05-09 23:49       ` Colin Foster
2022-05-09 17:20       ` Vladimir Oltean
2022-05-09 17:20         ` Vladimir Oltean
2022-05-10  0:30         ` Colin Foster
2022-05-10  0:30           ` Colin Foster
2022-05-10 15:32         ` Lee Jones
2022-05-10 15:32           ` Lee Jones
2022-05-10 16:13           ` Colin Foster
2022-05-10 16:13             ` Colin Foster
2022-05-12  9:49             ` Lee Jones
2022-05-12  9:49               ` Lee Jones
2022-05-12 15:03               ` Colin Foster
2022-05-12 15:03                 ` Colin Foster
2022-05-10 15:58   ` Vladimir Oltean
2022-05-10 15:58     ` Vladimir Oltean
2022-05-10 16:02     ` Colin Foster
2022-05-10 16:02       ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 09/16] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 10/16] net: dsa: felix: add configurable device quirks Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-09 10:56   ` Vladimir Oltean
2022-05-09 10:56     ` Vladimir Oltean
2022-05-10  0:05     ` Colin Foster
2022-05-10  0:05       ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 12/16] net: mscc: ocelot: expose stats layout " Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 13/16] net: mscc: ocelot: expose vcap_props structure Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-09 16:27   ` Vladimir Oltean
2022-05-09 16:27     ` Vladimir Oltean
2022-05-10  0:02     ` Colin Foster
2022-05-10  0:02       ` Colin Foster
2022-05-08 18:53 ` [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-09 10:34   ` Vladimir Oltean
2022-05-09 10:34     ` Vladimir Oltean
2022-05-10  0:23     ` Colin Foster
2022-05-10  0:23       ` Colin Foster
2022-05-09 17:30       ` Vladimir Oltean
2022-05-09 17:30         ` Vladimir Oltean
2022-05-10  0:55         ` Colin Foster
2022-05-10  0:55           ` Colin Foster
2022-05-09 17:58           ` Vladimir Oltean
2022-05-09 17:58             ` Vladimir Oltean
2022-09-09 18:33             ` Colin Foster
2022-09-09 18:33               ` Colin Foster
2022-09-09 19:20               ` Russell King (Oracle)
2022-09-09 19:20                 ` Russell King (Oracle)
2022-09-09 19:30                 ` Colin Foster
2022-09-09 19:30                   ` Colin Foster
2022-09-11  0:44               ` Vladimir Oltean
2022-09-11  0:44                 ` Vladimir Oltean
2022-05-08 18:53 ` [RFC v8 net-next 16/16] net: dsa: ocelot: utilize phylink_generic_validate Colin Foster
2022-05-08 18:53   ` Colin Foster
2022-05-09 17:13 ` [RFC v8 net-next 00/16] add support for VSC7512 control over SPI Vladimir Oltean
2022-05-09 17:13   ` Vladimir Oltean
2022-05-10  1:43   ` Colin Foster
2022-05-10  1:43     ` Colin Foster
2022-05-10  2:57   ` Colin Foster
2022-05-10  2:57     ` Colin Foster
2022-05-10 16:18     ` Vladimir Oltean
2022-05-10 16:18       ` Vladimir Oltean
2022-05-14 22:00   ` Colin Foster
2022-05-14 22:00     ` Colin Foster
2022-05-19 14:44     ` Vladimir Oltean
2022-05-19 14:44       ` Vladimir Oltean
2022-05-19 16:15       ` Colin Foster
2022-05-19 16:15         ` Colin Foster
2022-05-19 17:09         ` Vladimir Oltean
2022-05-19 17:09           ` Vladimir Oltean

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.