[U-Boot] [PATCH v2 0/4] Marvell MDIO driver and new MDIO name property
This is a respin of the original Marvell MDIO driver submitted by Ken about one year ago, using the new MDIO DM code. Added binding documents for mdio and marvell-mdio and introduced a new optional property for naming MDIO buses in case the driver can't reasonably pick a nice name by itself.
Changes in v2: add "-mdio" to device-name for cpm/cps
Alex Marginean (4): net: mdio-uclass: name MDIO according to device-name property if preset doc: bindings: add mdio.txt describing generic MDIO properties drivers: net: add marvell MDIO driver arm: dts: Set custom names for cp110 master/slave MDIO buses
arch/arm/dts/armada-cp110-master.dtsi | 1 + arch/arm/dts/armada-cp110-slave.dtsi | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 15 ++ doc/device-tree-bindings/net/mdio.txt | 36 +++ drivers/net/Kconfig | 10 + drivers/net/Makefile | 1 + drivers/net/mvmdio.c | 236 ++++++++++++++++++ net/mdio-uclass.c | 11 + 8 files changed, 311 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 doc/device-tree-bindings/net/mdio.txt create mode 100644 drivers/net/mvmdio.c
Use the optional property device-name to name the MDIO bus. This works around limitations with using the DT node name on devices such as Armada-8040, which integrates two cp100 cores, both featuring MDIOs at the same relative offsets and with the same DT node names. The concept was originally proposed by Marvell as a custom property called mdio-name specific to Marvell driver. This patch uses the more generic property device-name and moves this into MDIO class code so other can use it as well.
Signed-off-by: Alex Marginean alexm.osslist@gmail.com Acked-by: Joe Hershberger joe.hershberger@ni.com Reviewed-by: Bin Meng bmeng.cn@gmail.com --- net/mdio-uclass.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c index 36a404ff44..428f3a994f 100644 --- a/net/mdio-uclass.c +++ b/net/mdio-uclass.c @@ -23,6 +23,17 @@ void dm_mdio_probe_devices(void)
static int dm_mdio_post_bind(struct udevice *dev) { + const char *dt_name; + + /* set a custom name for the MDIO device, if present in DT */ + if (ofnode_valid(dev->node)) { + dt_name = ofnode_read_string(dev->node, "device-name"); + if (dt_name) { + debug("renaming dev %s to %s\n", dev->name, dt_name); + device_set_name(dev, dt_name); + } + } + /* * MDIO command doesn't like spaces in names, don't allow them to keep * it happy
Hi Alex,
https://patchwork.ozlabs.org/patch/1136774/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks! -Joe
Adds a binding document for mdio. A notable deviation from corresponding Linux binding is the introduction of device-name optional property, which can be used to name MDIO buses. Two reset optional properties described by Linux binding are also not present as they don't seem to be used in U-Boot at this time.
Signed-off-by: Alex Marginean alexm.osslist@gmail.com Acked-by: Joe Hershberger joe.hershberger@ni.com Reviewed-by: Bin Meng bmeng.cn@gmail.com --- doc/device-tree-bindings/net/mdio.txt | 36 +++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/device-tree-bindings/net/mdio.txt
diff --git a/doc/device-tree-bindings/net/mdio.txt b/doc/device-tree-bindings/net/mdio.txt new file mode 100644 index 0000000000..1595325050 --- /dev/null +++ b/doc/device-tree-bindings/net/mdio.txt @@ -0,0 +1,36 @@ +Common MDIO bus properties. + +These are generic properties that can apply to any MDIO bus. + +Optional properties: + - device-name - If present it is used to name the device and MDIO bus. + The name must be unique and must not contain spaces. + +A list of child nodes, one per device on the bus is expected. These could be +PHYs, switches or similar devices and child nodes should follow the specific +binding for the device type. + +Example : +This example shows the structure used for the external MDIO bus on NXP LS1028A +RDB board. Note that this MDIO device is an integrated PCI function and +requires no compatible property for probing. + +/* definition in SoC dtsi file */ + pcie@1f0000000 { + + mdio0: pci@0,3 { + #address-cells=<0>; + #size-cells=<1>; + reg = <0x000300 0 0 0 0>; + status = "disabled"; + device-name = "emdio"; + }; + }; +/* definition of PHYs in RDB dts file */ +&mdio0 { + status = "okay"; + rdb_phy0: phy@2 { + reg = <2>; + }; +}; +
I added the optional property name in order that the legacy miiphy_get_dev_by_name() could be used with the mdio name.
And I think that my mdio searching way was much better than linux at least at last year. I do not know now how in linux net interface finds its phy's mdio bus now. But at last year, linux stored all phys' FDT node addesses under all mdio buses, and when searching network interface' phy, linux driver compared its phy fdt node addresses to each phy fdt node address it stored one by one. So I added mdio_device_get_from_phy/mdio_mii_bus_get_from_phy/mdio_device_get_from_eth to simply the mdio/phy searching.
Yours, Ken
-----Original Message----- From: Alex Marginean alexandru.marginean@nxp.com Sent: Thursday, July 25, 2019 11:33 AM To: u-boot@lists.denx.de Cc: Joe Hershberger joe.hershberger@ni.com; Ken Ma make@marvell.com; Nevo Hed nhed+uboot@starry.com; Alex Marginean alexandru.marginean@nxp.com; Alex Marginean alexm.osslist@gmail.com Subject: [EXT] [PATCH v2 2/4] doc: bindings: add mdio.txt describing generic MDIO properties
External Email
---------------------------------------------------------------------- Adds a binding document for mdio. A notable deviation from corresponding Linux binding is the introduction of device-name optional property, which can be used to name MDIO buses. Two reset optional properties described by Linux binding are also not present as they don't seem to be used in U-Boot at this time.
Signed-off-by: Alex Marginean alexm.osslist@gmail.com Acked-by: Joe Hershberger joe.hershberger@ni.com Reviewed-by: Bin Meng bmeng.cn@gmail.com --- doc/device-tree-bindings/net/mdio.txt | 36 +++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/device-tree-bindings/net/mdio.txt
diff --git a/doc/device-tree-bindings/net/mdio.txt b/doc/device-tree-bindings/net/mdio.txt new file mode 100644 index 0000000000..1595325050 --- /dev/null +++ b/doc/device-tree-bindings/net/mdio.txt @@ -0,0 +1,36 @@ +Common MDIO bus properties. + +These are generic properties that can apply to any MDIO bus. + +Optional properties: + - device-name - If present it is used to name the device and MDIO bus. + The name must be unique and must not contain spaces. + +A list of child nodes, one per device on the bus is expected. These +could be PHYs, switches or similar devices and child nodes should +follow the specific binding for the device type. + +Example : +This example shows the structure used for the external MDIO bus on NXP +LS1028A RDB board. Note that this MDIO device is an integrated PCI +function and requires no compatible property for probing. + +/* definition in SoC dtsi file */ + pcie@1f0000000 { + + mdio0: pci@0,3 { + #address-cells=<0>; + #size-cells=<1>; + reg = <0x000300 0 0 0 0>; + status = "disabled"; + device-name = "emdio"; + }; + }; +/* definition of PHYs in RDB dts file */ +&mdio0 { + status = "okay"; + rdb_phy0: phy@2 { + reg = <2>; + }; +}; + -- 2.17.1
On 7/25/2019 1:08 PM, Ken Ma wrote:
I added the optional property name in order that the legacy miiphy_get_dev_by_name() could be used with the mdio name.
That works with these patches, miiphy_get_dev_by_name is used, among others, by mdio command and mdio command shows the device with the name from DT, if the name property exists in DT. There are two differences. First is property name which is now device-name instead of mdio-name, I used that hoping that it caches on and other classes would use the same. The other difference is that the device-name binding is now part of mdio, rather than marvell-mdio, and the code is in the uclass rather than MDIO driver so all can use it.
And I think that my mdio searching way was much better than linux at least at last year. > I do not know now how in linux net interface finds its phy's mdio bus now. But at last year, linux stored all phys' FDT node addesses under all mdio buses, and when searching network interface' phy, linux driver compared its phy fdt node addresses to each phy fdt node address it stored one by one.
OK, you're probably looking at of_phy_find_device. It does search PHYs by DT node, which is useful for instance when using a phy-handle property in the ethernet node. I suppose your comment is that the search function could be simpler and I could agree with that. You could alternatively use mdiobus_get_phy which takes in a PHY address and doesn't care about DT nodes, but this only works if the PHY was probed already, I think. But that's all Linux implementation, it doesn't mean U-Boot has to do the exact same thing.
So I added mdio_device_get_from_phy/mdio_mii_bus_get_from_phy/mdio_device_get_from_eth to simply the mdio/phy searching. > Yours, Ken
For instance you would have a phy-handle property, eth driver would call mdio_device_get_from_phy on the phy node to get the MDIO bus and then call dm_mdio_phy_connect with the PHY address, correct?
I am planning to add a helper that actually does all that in one go, not just return a reference to MDIO bus based on PHY node or eth interface.
Wwe could have something similar to of_phy_get_and_connect in Linux. It would take in the ethernet udevice, read phy-handle from associated DT node, get PHY address and MDIO bus from DT and create the new PHY device. Right now I added that code to our eth driver (see [1]), but given that bindings are generic it would be nice to move all that code out into generic code as a helper function. The API would be something like this:
struct phy_device *dm_eth_phy_connect(struct udevice *eth); returning a phy device or null if something is missing.
It would be nice to also support fixed link bindings in there, but that is off-topic.
Does that look reasonable to you? Thanks! Alex
[1] enetc_start_phy in https://patchwork.ozlabs.org/patch/1126769/
-----Original Message----- From: Alex Marginean alexandru.marginean@nxp.com Sent: Thursday, July 25, 2019 11:33 AM To: u-boot@lists.denx.de Cc: Joe Hershberger joe.hershberger@ni.com; Ken Ma make@marvell.com; Nevo Hed nhed+uboot@starry.com; Alex Marginean alexandru.marginean@nxp.com; Alex Marginean alexm.osslist@gmail.com Subject: [EXT] [PATCH v2 2/4] doc: bindings: add mdio.txt describing generic MDIO properties
External Email
Adds a binding document for mdio. A notable deviation from corresponding Linux binding is the introduction of device-name optional property, which can be used to name MDIO buses. Two reset optional properties described by Linux binding are also not present as they don't seem to be used in U-Boot at this time.
Signed-off-by: Alex Marginean alexm.osslist@gmail.com Acked-by: Joe Hershberger joe.hershberger@ni.com Reviewed-by: Bin Meng bmeng.cn@gmail.com
doc/device-tree-bindings/net/mdio.txt | 36 +++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/device-tree-bindings/net/mdio.txt
diff --git a/doc/device-tree-bindings/net/mdio.txt b/doc/device-tree-bindings/net/mdio.txt new file mode 100644 index 0000000000..1595325050 --- /dev/null +++ b/doc/device-tree-bindings/net/mdio.txt @@ -0,0 +1,36 @@ +Common MDIO bus properties.
+These are generic properties that can apply to any MDIO bus.
+Optional properties:
- device-name - If present it is used to name the device and MDIO bus.
The name must be unique and must not contain spaces.+A list of child nodes, one per device on the bus is expected. These +could be PHYs, switches or similar devices and child nodes should +follow the specific binding for the device type.
+Example : +This example shows the structure used for the external MDIO bus on NXP +LS1028A RDB board. Note that this MDIO device is an integrated PCI +function and requires no compatible property for probing.
+/* definition in SoC dtsi file */
- pcie@1f0000000 {
mdio0: pci@0,3 {#address-cells=<0>;#size-cells=<1>;reg = <0x000300 0 0 0 0>;status = "disabled";device-name = "emdio";};- };
+/* definition of PHYs in RDB dts file */ +&mdio0 {
- status = "okay";
- rdb_phy0: phy@2 {
reg = <2>;- };
+};
-- 2.17.1
Please see my inline rely, thanks a lot!
On 7/25/2019 1:08 PM, Ken Ma wrote:
I added the optional property name in order that the legacy miiphy_get_dev_by_name() could be used with the mdio name.
That works with these patches, miiphy_get_dev_by_name is used, among others, by mdio command and mdio command shows the device with the name from DT, if the name property exists in DT. There are two differences. First is property name which is now device-name instead of mdio-name, I used that hoping that it caches on and other classes would use the same. The other difference is that the device-name binding is now part of mdio, rather than marvell-mdio, and the code is in the uclass rather than MDIO driver so all can use it. ###[Ken] Thank you very much for your detailed explanation, I have not read uboot codes for almost 1 year, 😊
And I think that my mdio searching way was much better than linux at least at last year. > I do not know now how in linux net interface finds its phy's mdio bus now. But at last year, linux stored all phys' FDT node addesses under all mdio buses, and when searching network interface' phy, linux driver compared its phy fdt node addresses to each phy fdt node address it stored one by one.
OK, you're probably looking at of_phy_find_device. It does search PHYs by DT node, which is useful for instance when using a phy-handle property in the ethernet node. I suppose your comment is that the search function could be simpler and I could agree with that. You could alternatively use mdiobus_get_phy which takes in a PHY address and doesn't care about DT nodes, but this only works if the PHY was probed already, I think. But that's all Linux implementation, it doesn't mean U-Boot has to do the exact same thing. ###[Ken] I think Linux cycle searching has too low efficiency, 😊
So I added mdio_device_get_from_phy/mdio_mii_bus_get_from_phy/mdio_device_get_fro m_eth to simply the mdio/phy searching. > Yours, Ken
For instance you would have a phy-handle property, eth driver would call mdio_device_get_from_phy on the phy node to get the MDIO bus and then call dm_mdio_phy_connect with the PHY address, correct?
I am planning to add a helper that actually does all that in one go, not just return a reference to MDIO bus based on PHY node or eth interface.
Wwe could have something similar to of_phy_get_and_connect in Linux. It would take in the ethernet udevice, read phy-handle from associated DT node, get PHY address and MDIO bus from DT and create the new PHY device. Right now I added that code to our eth driver (see [1]), but given that bindings are generic it would be nice to move all that code out into generic code as a helper function. The API would be something like this:
struct phy_device *dm_eth_phy_connect(struct udevice *eth); returning a phy device or null if something is missing.
It would be nice to also support fixed link bindings in there, but that is off-topic. ###[Ken] I had though this solution in my old design, but later I denied it because mdio_device_get_from_phy() should be called in eth device probe step while dm_mdio_phy_connect() should be called in eth device start step, eth probe and start are 2 different steps, 😊
Does that look reasonable to you? Thanks! Alex
[1] enetc_start_phy in https://patchwork.ozlabs.org/patch/1126769/
-----Original Message----- From: Alex Marginean alexandru.marginean@nxp.com Sent: Thursday, July 25, 2019 11:33 AM To: u-boot@lists.denx.de Cc: Joe Hershberger joe.hershberger@ni.com; Ken Ma make@marvell.com; Nevo Hed nhed+uboot@starry.com; Alex Marginean alexandru.marginean@nxp.com; Alex Marginean alexm.osslist@gmail.com Subject: [EXT] [PATCH v2 2/4] doc: bindings: add mdio.txt describing generic MDIO properties
External Email
Adds a binding document for mdio. A notable deviation from corresponding Linux binding is the introduction of device-name optional property, which can be used to name MDIO buses. Two reset optional properties described by Linux binding are also not present as they don't seem to be used in U-Boot at this time.
Signed-off-by: Alex Marginean alexm.osslist@gmail.com Acked-by: Joe Hershberger joe.hershberger@ni.com Reviewed-by: Bin Meng bmeng.cn@gmail.com
doc/device-tree-bindings/net/mdio.txt | 36 +++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/device-tree-bindings/net/mdio.txt
diff --git a/doc/device-tree-bindings/net/mdio.txt b/doc/device-tree-bindings/net/mdio.txt new file mode 100644 index 0000000000..1595325050 --- /dev/null +++ b/doc/device-tree-bindings/net/mdio.txt @@ -0,0 +1,36 @@ +Common MDIO bus properties.
+These are generic properties that can apply to any MDIO bus.
+Optional properties:
- device-name - If present it is used to name the device and MDIO bus.
The name must be unique and must not contain spaces.+A list of child nodes, one per device on the bus is expected. These +could be PHYs, switches or similar devices and child nodes should +follow the specific binding for the device type.
+Example : +This example shows the structure used for the external MDIO bus on +NXP LS1028A RDB board. Note that this MDIO device is an integrated +PCI function and requires no compatible property for probing.
+/* definition in SoC dtsi file */
- pcie@1f0000000 {
mdio0: pci@0,3 {#address-cells=<0>;#size-cells=<1>;reg = <0x000300 0 0 0 0>;status = "disabled";device-name = "emdio";};- };
+/* definition of PHYs in RDB dts file */ +&mdio0 {
- status = "okay";
- rdb_phy0: phy@2 {
reg = <2>;- };
+};
-- 2.17.1
Hi Alex,
https://patchwork.ozlabs.org/patch/1136772/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks! -Joe
This patch adds a separate driver for the MDIO interface of the Marvell Ethernet controllers based on driver model. There are two reasons to have a separate driver rather than including it inside the MAC driver itself: *) The MDIO interface is shared by all Ethernet ports, so a driver must guarantee non-concurrent accesses to this MDIO interface. The most logical way is to have a separate driver that handles this single MDIO interface, used by all Ethernet ports. *) The MDIO interface is the same between the existing mv643xx_eth driver and the new mvneta/mvpp2 driver. Even though it is for now only used by the mvneta/mvpp2 driver, it will in the future be used by the mv643xx_eth driver as well.
This driver supports SMI IEEE for 802.3 Clause 22 and XSMI for IEEE 802.3 Clause 45.
This patch also adds device tree binding for marvell MDIO driver.
Signed-off-by: Ken Ma make@marvell.com Signed-off-by: Alex Marginean alexm.osslist@gmail.com Acked-by: Joe Hershberger joe.hershberger@ni.com --- doc/device-tree-bindings/net/marvell-mdio.txt | 15 ++ drivers/net/Kconfig | 10 + drivers/net/Makefile | 1 + drivers/net/mvmdio.c | 236 ++++++++++++++++++ 4 files changed, 262 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 drivers/net/mvmdio.c
diff --git a/doc/device-tree-bindings/net/marvell-mdio.txt b/doc/device-tree-bindings/net/marvell-mdio.txt new file mode 100644 index 0000000000..e2038e2145 --- /dev/null +++ b/doc/device-tree-bindings/net/marvell-mdio.txt @@ -0,0 +1,15 @@ +* Marvell MDIO Ethernet Controller interface + +The Ethernet controllers of the Marvel Armada 3700 and Armada 7k/8k +have an identical unit that provides an interface with the MDIO bus. +This driver handles this MDIO interface. + +Mandatory properties: +SoC specific: + - #address-cells: Must be <1>. + - #size-cells: Must be <0>. + - compatible: Should be "marvell,orion-mdio" (for SMI) + "marvell,xmdio" (for XSMI) + - reg: Base address and size SMI/XMSI bus. + +Please refer to "mdio.txt" for generic MDIO bus bindings. diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 4d85fb1716..a982bc3ac5 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -595,4 +595,14 @@ config FSL_ENETC This driver supports the NXP ENETC Ethernet controller found on some of the NXP SoCs.
+config MVMDIO + bool "Marvell MDIO interface support" + depends on DM_MDIO + help + This driver supports the MDIO interface found in the network + interface units of the Marvell EBU SoCs (Kirkwood, Orion5x, + Dove, Armada 370, Armada XP, Armada 37xx and Armada7K/8K/8KP). + + This driver is used by the MVPP2 and MVNETA drivers. + endif # NETDEVICES diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 97119cec7c..5921fa3e9c 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -80,3 +80,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o obj-$(CONFIG_MDIO_MUX_SANDBOX) += mdio_mux_sandbox.o +obj-$(CONFIG_MVMDIO) += mvmdio.o diff --git a/drivers/net/mvmdio.c b/drivers/net/mvmdio.c new file mode 100644 index 0000000000..ec6805e536 --- /dev/null +++ b/drivers/net/mvmdio.c @@ -0,0 +1,236 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Marvell International Ltd. + * Author: Ken Mamake@marvell.com + */ + +#include <common.h> +#include <dm.h> +#include <dm/device-internal.h> +#include <dm/lists.h> +#include <miiphy.h> +#include <phy.h> +#include <asm/io.h> +#include <wait_bit.h> + +#define MVMDIO_SMI_DATA_SHIFT 0 +#define MVMDIO_SMI_PHY_ADDR_SHIFT 16 +#define MVMDIO_SMI_PHY_REG_SHIFT 21 +#define MVMDIO_SMI_READ_OPERATION BIT(26) +#define MVMDIO_SMI_WRITE_OPERATION 0 +#define MVMDIO_SMI_READ_VALID BIT(27) +#define MVMDIO_SMI_BUSY BIT(28) + +#define MVMDIO_XSMI_MGNT_REG 0x0 +#define MVMDIO_XSMI_PHYADDR_SHIFT 16 +#define MVMDIO_XSMI_DEVADDR_SHIFT 21 +#define MVMDIO_XSMI_WRITE_OPERATION (0x5 << 26) +#define MVMDIO_XSMI_READ_OPERATION (0x7 << 26) +#define MVMDIO_XSMI_READ_VALID BIT(29) +#define MVMDIO_XSMI_BUSY BIT(30) +#define MVMDIO_XSMI_ADDR_REG 0x8 + +enum mvmdio_bus_type { + BUS_TYPE_SMI, + BUS_TYPE_XSMI +}; + +struct mvmdio_priv { + void *mdio_base; + enum mvmdio_bus_type type; +}; + +static int mvmdio_smi_read(struct udevice *dev, int addr, + int devad, int reg) +{ + struct mvmdio_priv *priv = dev_get_priv(dev); + u32 val; + int ret; + + if (devad != MDIO_DEVAD_NONE) + return -EOPNOTSUPP; + + ret = wait_for_bit_le32(priv->mdio_base, MVMDIO_SMI_BUSY, + false, CONFIG_SYS_HZ, false); + if (ret < 0) + return ret; + + writel(((addr << MVMDIO_SMI_PHY_ADDR_SHIFT) | + (reg << MVMDIO_SMI_PHY_REG_SHIFT) | + MVMDIO_SMI_READ_OPERATION), + priv->mdio_base); + + ret = wait_for_bit_le32(priv->mdio_base, MVMDIO_SMI_BUSY, + false, CONFIG_SYS_HZ, false); + if (ret < 0) + return ret; + + val = readl(priv->mdio_base); + if (!(val & MVMDIO_SMI_READ_VALID)) { + pr_err("SMI bus read not valid\n"); + return -ENODEV; + } + + return val & GENMASK(15, 0); +} + +static int mvmdio_smi_write(struct udevice *dev, int addr, int devad, + int reg, u16 value) +{ + struct mvmdio_priv *priv = dev_get_priv(dev); + int ret; + + if (devad != MDIO_DEVAD_NONE) + return -EOPNOTSUPP; + + ret = wait_for_bit_le32(priv->mdio_base, MVMDIO_SMI_BUSY, + false, CONFIG_SYS_HZ, false); + if (ret < 0) + return ret; + + writel(((addr << MVMDIO_SMI_PHY_ADDR_SHIFT) | + (reg << MVMDIO_SMI_PHY_REG_SHIFT) | + MVMDIO_SMI_WRITE_OPERATION | + (value << MVMDIO_SMI_DATA_SHIFT)), + priv->mdio_base); + + return 0; +} + +static int mvmdio_xsmi_read(struct udevice *dev, int addr, + int devad, int reg) +{ + struct mvmdio_priv *priv = dev_get_priv(dev); + int ret; + + if (devad == MDIO_DEVAD_NONE) + return -EOPNOTSUPP; + + ret = wait_for_bit_le32(priv->mdio_base, MVMDIO_XSMI_BUSY, + false, CONFIG_SYS_HZ, false); + if (ret < 0) + return ret; + + writel(reg & GENMASK(15, 0), priv->mdio_base + MVMDIO_XSMI_ADDR_REG); + writel(((addr << MVMDIO_XSMI_PHYADDR_SHIFT) | + (devad << MVMDIO_XSMI_DEVADDR_SHIFT) | + MVMDIO_XSMI_READ_OPERATION), + priv->mdio_base + MVMDIO_XSMI_MGNT_REG); + + ret = wait_for_bit_le32(priv->mdio_base, MVMDIO_XSMI_BUSY, + false, CONFIG_SYS_HZ, false); + if (ret < 0) + return ret; + + if (!(readl(priv->mdio_base + MVMDIO_XSMI_MGNT_REG) & + MVMDIO_XSMI_READ_VALID)) { + pr_err("XSMI bus read not valid\n"); + return -ENODEV; + } + + return readl(priv->mdio_base + MVMDIO_XSMI_MGNT_REG) & GENMASK(15, 0); +} + +static int mvmdio_xsmi_write(struct udevice *dev, int addr, int devad, + int reg, u16 value) +{ + struct mvmdio_priv *priv = dev_get_priv(dev); + int ret; + + if (devad == MDIO_DEVAD_NONE) + return -EOPNOTSUPP; + + ret = wait_for_bit_le32(priv->mdio_base, MVMDIO_XSMI_BUSY, + false, CONFIG_SYS_HZ, false); + if (ret < 0) + return ret; + + writel(reg & GENMASK(15, 0), priv->mdio_base + MVMDIO_XSMI_ADDR_REG); + writel(((addr << MVMDIO_XSMI_PHYADDR_SHIFT) | + (devad << MVMDIO_XSMI_DEVADDR_SHIFT) | + MVMDIO_XSMI_WRITE_OPERATION | value), + priv->mdio_base + MVMDIO_XSMI_MGNT_REG); + + return 0; +} + +static int mvmdio_read(struct udevice *dev, int addr, int devad, int reg) +{ + struct mvmdio_priv *priv = dev_get_priv(dev); + int err = -ENOTSUPP; + + switch (priv->type) { + case BUS_TYPE_SMI: + err = mvmdio_smi_read(dev, addr, devad, reg); + break; + case BUS_TYPE_XSMI: + err = mvmdio_xsmi_read(dev, addr, devad, reg); + break; + } + + return err; +} + +static int mvmdio_write(struct udevice *dev, int addr, int devad, int reg, + u16 value) +{ + struct mvmdio_priv *priv = dev_get_priv(dev); + int err = -ENOTSUPP; + + switch (priv->type) { + case BUS_TYPE_SMI: + err = mvmdio_smi_write(dev, addr, devad, reg, value); + break; + case BUS_TYPE_XSMI: + err = mvmdio_xsmi_write(dev, addr, devad, reg, value); + break; + } + + return err; +} + +/* + * Name the device, we use the device tree node name. + * This can be overwritten by MDIO class code if device-name property is + * present. + */ +static int mvmdio_bind(struct udevice *dev) +{ + if (ofnode_valid(dev->node)) + device_set_name(dev, ofnode_get_name(dev->node)); + + return 0; +} + +/* Get device base address and type, either C22 SMII or C45 XSMI */ +static int mvmdio_probe(struct udevice *dev) +{ + struct mvmdio_priv *priv = dev_get_priv(dev); + + priv->mdio_base = (void *)dev_read_addr(dev); + priv->type = (enum mvmdio_bus_type)dev_get_driver_data(dev); + + return 0; +} + +static const struct mdio_ops mvmdio_ops = { + .read = mvmdio_read, + .write = mvmdio_write, +}; + +static const struct udevice_id mvmdio_ids[] = { + { .compatible = "marvell,orion-mdio", .data = BUS_TYPE_SMI }, + { .compatible = "marvell,xmdio", .data = BUS_TYPE_XSMI }, + { } +}; + +U_BOOT_DRIVER(mvmdio) = { + .name = "mvmdio", + .id = UCLASS_MDIO, + .of_match = mvmdio_ids, + .bind = mvmdio_bind, + .probe = mvmdio_probe, + .ops = &mvmdio_ops, + .priv_auto_alloc_size = sizeof(struct mvmdio_priv), +}; +
Hi Alex,
https://patchwork.ozlabs.org/patch/1136771/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks! -Joe
Implicitly Marvell MDIO driver uses DT node names for devices, but in this case that is not unique. Set MDIO device names for master/slave to cpm/cps.
Signed-off-by: Alex Marginean alexm.osslist@gmail.com Acked-by: Joe Hershberger joe.hershberger@ni.com --- arch/arm/dts/armada-cp110-master.dtsi | 1 + arch/arm/dts/armada-cp110-slave.dtsi | 1 + 2 files changed, 2 insertions(+)
diff --git a/arch/arm/dts/armada-cp110-master.dtsi b/arch/arm/dts/armada-cp110-master.dtsi index 551d00d774..e4c17e9f4b 100644 --- a/arch/arm/dts/armada-cp110-master.dtsi +++ b/arch/arm/dts/armada-cp110-master.dtsi @@ -96,6 +96,7 @@ #size-cells = <0>; compatible = "marvell,orion-mdio"; reg = <0x12a200 0x10>; + device-name = "cpm-mdio"; };
cpm_syscon0: system-controller@440000 { diff --git a/arch/arm/dts/armada-cp110-slave.dtsi b/arch/arm/dts/armada-cp110-slave.dtsi index 2ea9004f1d..2fbd7b5514 100644 --- a/arch/arm/dts/armada-cp110-slave.dtsi +++ b/arch/arm/dts/armada-cp110-slave.dtsi @@ -96,6 +96,7 @@ #size-cells = <0>; compatible = "marvell,orion-mdio"; reg = <0x12a200 0x10>; + device-name = "cps-mdio"; };
cps_syscon0: system-controller@440000 {
Hi Alex,
https://patchwork.ozlabs.org/patch/1136773/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks! -Joe
participants (4)
-
Alex Marginean -
Alex Marginean -
Joe Hershberger -
Ken Ma