[PATCH 00/20] ppc: qemu: Add eTSEC support

QEMU ppce500 machine can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as the Freescale eTSEC driver to support the QEMU ppce500 board.
Based-on: http://patchwork.ozlabs.org/project/uboot/list/?series=230985
This series is avaiable at u-boot-x86/eTSEC for testing.
Bin Meng (20): net: phy: xilinx: Remove non-DM prototype of phy_connect_gmii2rgmii() net: phy: xilinx: Convert to use APIs which support live DT net: phy: fixed: Remove non-DM prototype of phy_connect_fixed() net: phy: fixed: Convert to use APIs which support live DT dt-bindings: net: Add the old DT bindings for "fixed-link" of: extra: Introduce ofnode_phy_is_fixed_link() API test: dm: Add a case to test ofnode_phy_is_fixed_link() dm: mdio: Use ofnode_phy_is_fixed_link() API net: tsec: Use ofnode_phy_is_fixed_link() API net: phy: Simplify the logic of phy_connect_fixed() net: phy: fixed: Make driver ops static net: phy: fixed: Add the missing ending newline net: phy: fixed: Support the old DT binding dt-bindings: net: Update Freescale TSEC to support "queue-group" net: tsec: Support <reg> property from the subnode "queue-group" dm: core: Correctly read <ranges> of simple-bus test: dm: Add a test case for simple-bus <ranges> ppc: qemu: Create a virtual memory mapping of the platform bus ppc: qemu: Enable eTSEC support doc: board: qemu-ppce500: Document eTSEC usage
arch/sandbox/dts/test.dts | 11 ++++ board/emulation/qemu-ppce500/Kconfig | 6 +++ board/emulation/qemu-ppce500/qemu-ppce500.c | 18 +++++++ configs/qemu-ppce500_defconfig | 4 ++ doc/board/emulation/qemu-ppce500.rst | 5 ++ doc/device-tree-bindings/net/fixed-link.txt | 47 ++++++++++++----- doc/device-tree-bindings/net/fsl-tsec-phy.txt | 15 +++++- drivers/core/of_extra.c | 26 ++++++++++ drivers/core/simple-bus.c | 15 ++++-- drivers/net/phy/Kconfig | 1 + drivers/net/phy/fixed.c | 37 ++++++++++--- drivers/net/phy/phy.c | 52 ++++++------------- drivers/net/tsec.c | 30 +++++++++-- include/dm/of_extra.h | 18 +++++++ include/dm/simple_bus.h | 6 +-- net/mdio-uclass.c | 3 +- test/dm/Makefile | 1 + test/dm/of_extra.c | 18 +++++++ test/dm/simple-bus.c | 33 ++++++++++++ 19 files changed, 276 insertions(+), 70 deletions(-) create mode 100644 test/dm/simple-bus.c

At present phy_connect_gmii2rgmii() is implemented using a DM API dev_of_offset() hence it cannot support a non-DM configuration. Remove the non-DM version prototype of phy_connect_gmii2rgmii() and make the driver depend on CONFIG_DM_ETH.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/Kconfig | 1 + drivers/net/phy/phy.c | 6 ------ 2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index d69503067d..070ffa82cb 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -292,6 +292,7 @@ config PHY_XILINX
config PHY_XILINX_GMII2RGMII bool "Xilinx GMII to RGMII Ethernet PHYs support" + depends on DM_ETH help This adds support for Xilinx GMII to RGMII IP core. This IP acts as bridge between MAC connected over GMII and external phy that diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 89e3076bfd..d9e03baf7b 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -942,15 +942,9 @@ void phy_connect_dev(struct phy_device *phydev, struct eth_device *dev) }
#ifdef CONFIG_PHY_XILINX_GMII2RGMII -#ifdef CONFIG_DM_ETH static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus, struct udevice *dev, phy_interface_t interface) -#else -static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus, - struct eth_device *dev, - phy_interface_t interface) -#endif { struct phy_device *phydev = NULL; int sn = dev_of_offset(dev);

On 3/2/21 4:34 PM, Bin Meng wrote:
At present phy_connect_gmii2rgmii() is implemented using a DM API dev_of_offset() hence it cannot support a non-DM configuration. Remove the non-DM version prototype of phy_connect_gmii2rgmii() and make the driver depend on CONFIG_DM_ETH.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/Kconfig | 1 + drivers/net/phy/phy.c | 6 ------ 2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index d69503067d..070ffa82cb 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -292,6 +292,7 @@ config PHY_XILINX
config PHY_XILINX_GMII2RGMII bool "Xilinx GMII to RGMII Ethernet PHYs support"
- depends on DM_ETH help This adds support for Xilinx GMII to RGMII IP core. This IP acts as bridge between MAC connected over GMII and external phy that
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 89e3076bfd..d9e03baf7b 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -942,15 +942,9 @@ void phy_connect_dev(struct phy_device *phydev, struct eth_device *dev) }
#ifdef CONFIG_PHY_XILINX_GMII2RGMII -#ifdef CONFIG_DM_ETH static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus, struct udevice *dev, phy_interface_t interface) -#else -static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
struct eth_device *dev,
phy_interface_t interface)
-#endif { struct phy_device *phydev = NULL; int sn = dev_of_offset(dev);
Looks good to me.
Acked-by: Michal Simek michal.simek@xilinx.com
Thanks, Michal

On Tue, Mar 2, 2021 at 5:35 PM Bin Meng bmeng.cn@gmail.com wrote:
At present phy_connect_gmii2rgmii() is implemented using a DM API dev_of_offset() hence it cannot support a non-DM configuration. Remove the non-DM version prototype of phy_connect_gmii2rgmii() and make the driver depend on CONFIG_DM_ETH.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/Kconfig | 1 + drivers/net/phy/phy.c | 6 ------ 2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index d69503067d..070ffa82cb 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -292,6 +292,7 @@ config PHY_XILINX
config PHY_XILINX_GMII2RGMII bool "Xilinx GMII to RGMII Ethernet PHYs support"
depends on DM_ETH help This adds support for Xilinx GMII to RGMII IP core. This IP acts as bridge between MAC connected over GMII and external phy that
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 89e3076bfd..d9e03baf7b 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -942,15 +942,9 @@ void phy_connect_dev(struct phy_device *phydev, struct eth_device *dev) }
#ifdef CONFIG_PHY_XILINX_GMII2RGMII -#ifdef CONFIG_DM_ETH static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus, struct udevice *dev, phy_interface_t interface) -#else -static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
struct eth_device *dev,
phy_interface_t interface)
-#endif { struct phy_device *phydev = NULL; int sn = dev_of_offset(dev); -- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

Use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver can support live DT.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/phy.c | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index d9e03baf7b..f0522fc149 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -947,23 +947,18 @@ static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus, phy_interface_t interface) { struct phy_device *phydev = NULL; - int sn = dev_of_offset(dev); - int off; + ofnode node = dev_ofnode(dev);
- while (sn > 0) { - off = fdt_node_offset_by_compatible(gd->fdt_blob, sn, - "xlnx,gmii-to-rgmii-1.0"); - if (off > 0) { - phydev = phy_device_create(bus, off, + while (ofnode_valid(node)) { + node = ofnode_by_compatible(node, "xlnx,gmii-to-rgmii-1.0"); + if (ofnode_valid(node)) { + phydev = phy_device_create(bus, ofnode_to_offset(node), PHY_GMII2RGMII_ID, false, interface); break; } - if (off == -FDT_ERR_NOTFOUND) - sn = fdt_first_subnode(gd->fdt_blob, sn); - else - printf("%s: Error finding compat string:%d\n", - __func__, off); + + node = ofnode_first_subnode(node); }
return phydev;

Hi Bin,
On Tue, Mar 02, 2021 at 11:34:33PM +0800, Bin Meng wrote:
Use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver can support live DT.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Nice to see you work on this, but did you see my patches? https://patchwork.ozlabs.org/project/uboot/patch/20210216224804.3355044-2-ol...

Hi Vladimir,
On Tue, Mar 2, 2021 at 11:40 PM Vladimir Oltean vladimir.oltean@nxp.com wrote:
Hi Bin,
On Tue, Mar 02, 2021 at 11:34:33PM +0800, Bin Meng wrote:
Use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver can support live DT.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Nice to see you work on this, but did you see my patches?
I apparently missed your patches.
https://patchwork.ozlabs.org/project/uboot/patch/20210216224804.3355044-2-ol...
It looks that I need to rebase my series on top of yours?
Regards, Bin

On Thu, Mar 04, 2021 at 01:36:45PM +0800, Bin Meng wrote:
It looks that I need to rebase my series on top of yours?
That would be nice, thank you. It would also create some sort of incentive to finally get my patches accepted or at least looked at, they are in the 'Needs Review/Ack' state, you seem to be quite the adequate person for that :)

Hi Vladimir,
On Fri, Mar 5, 2021 at 7:05 AM Vladimir Oltean vladimir.oltean@nxp.com wrote:
On Thu, Mar 04, 2021 at 01:36:45PM +0800, Bin Meng wrote:
It looks that I need to rebase my series on top of yours?
That would be nice, thank you. It would also create some sort of incentive to finally get my patches accepted or at least looked at, they are in the 'Needs Review/Ack' state, you seem to be quite the adequate person for that :)
I want to include your series as part of my v2 series, to remove dependencies for different maintainers.
Are you okay with this?
Regards, Bin

On Thu, Mar 11, 2021 at 06:33:39PM +0800, Bin Meng wrote:
Hi Vladimir,
On Fri, Mar 5, 2021 at 7:05 AM Vladimir Oltean vladimir.oltean@nxp.com wrote:
On Thu, Mar 04, 2021 at 01:36:45PM +0800, Bin Meng wrote:
It looks that I need to rebase my series on top of yours?
That would be nice, thank you. It would also create some sort of incentive to finally get my patches accepted or at least looked at, they are in the 'Needs Review/Ack' state, you seem to be quite the adequate person for that :)
I want to include your series as part of my v2 series, to remove dependencies for different maintainers.
Are you okay with this?
Regards, Bin
Priyanka already merged your series and sent the pull request to Tom, frankly I don't think there's anything more for you to do.

Hi Vladimir,
On Thu, Mar 11, 2021 at 6:37 PM Vladimir Oltean vladimir.oltean@nxp.com wrote:
On Thu, Mar 11, 2021 at 06:33:39PM +0800, Bin Meng wrote:
Hi Vladimir,
On Fri, Mar 5, 2021 at 7:05 AM Vladimir Oltean vladimir.oltean@nxp.com wrote:
On Thu, Mar 04, 2021 at 01:36:45PM +0800, Bin Meng wrote:
It looks that I need to rebase my series on top of yours?
That would be nice, thank you. It would also create some sort of incentive to finally get my patches accepted or at least looked at, they are in the 'Needs Review/Ack' state, you seem to be quite the adequate person for that :)
I want to include your series as part of my v2 series, to remove dependencies for different maintainers.
Are you okay with this?
Regards, Bin
Priyanka already merged your series and sent the pull request to Tom, frankly I don't think there's anything more for you to do.
I did not see that. Did you mean the previous qemu ppc series?
Regards, Bin

On Thu, Mar 11, 2021 at 06:58:33PM +0800, Bin Meng wrote:
Hi Vladimir,
On Thu, Mar 11, 2021 at 6:37 PM Vladimir Oltean vladimir.oltean@nxp.com wrote:
On Thu, Mar 11, 2021 at 06:33:39PM +0800, Bin Meng wrote:
Hi Vladimir,
On Fri, Mar 5, 2021 at 7:05 AM Vladimir Oltean vladimir.oltean@nxp.com wrote:
On Thu, Mar 04, 2021 at 01:36:45PM +0800, Bin Meng wrote:
It looks that I need to rebase my series on top of yours?
That would be nice, thank you. It would also create some sort of incentive to finally get my patches accepted or at least looked at, they are in the 'Needs Review/Ack' state, you seem to be quite the adequate person for that :)
I want to include your series as part of my v2 series, to remove dependencies for different maintainers.
Are you okay with this?
Regards, Bin
Priyanka already merged your series and sent the pull request to Tom, frankly I don't think there's anything more for you to do.
I did not see that. Did you mean the previous qemu ppc series?
Ah, the series for the eTSEC in QEMU was different than the one for e500? Ok, in that case I'm wrong, your networking patches were not merged yet.
If you could pick up my patches that would be nice. Let me know if there's anything I can help with.

On Tue, Mar 2, 2021 at 5:35 PM Bin Meng bmeng.cn@gmail.com wrote:
Use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver can support live DT.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/phy.c | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index d9e03baf7b..f0522fc149 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -947,23 +947,18 @@ static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus, phy_interface_t interface) { struct phy_device *phydev = NULL;
int sn = dev_of_offset(dev);
int off;
ofnode node = dev_ofnode(dev);
while (sn > 0) {
off = fdt_node_offset_by_compatible(gd->fdt_blob, sn,
"xlnx,gmii-to-rgmii-1.0");
if (off > 0) {
phydev = phy_device_create(bus, off,
while (ofnode_valid(node)) {
node = ofnode_by_compatible(node, "xlnx,gmii-to-rgmii-1.0");
if (ofnode_valid(node)) {
phydev = phy_device_create(bus, ofnode_to_offset(node), PHY_GMII2RGMII_ID, false, interface); break; }
if (off == -FDT_ERR_NOTFOUND)
sn = fdt_first_subnode(gd->fdt_blob, sn);
else
printf("%s: Error finding compat string:%d\n",
__func__, off);
node = ofnode_first_subnode(node); } return phydev;
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

CONFIG_PHY_FIXED depends on CONFIG_DM_ETH. Remove the non-DM version prototype of phy_connect_fixed().
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/phy.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index f0522fc149..d08e8026ba 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -997,15 +997,9 @@ struct phy_device *fixed_phy_create(ofnode node) false, interface); }
-#ifdef CONFIG_DM_ETH static struct phy_device *phy_connect_fixed(struct mii_dev *bus, struct udevice *dev, phy_interface_t interface) -#else -static struct phy_device *phy_connect_fixed(struct mii_dev *bus, - struct eth_device *dev, - phy_interface_t interface) -#endif { struct phy_device *phydev = NULL; int sn;

On Tue, Mar 2, 2021 at 5:35 PM Bin Meng bmeng.cn@gmail.com wrote:
CONFIG_PHY_FIXED depends on CONFIG_DM_ETH. Remove the non-DM version prototype of phy_connect_fixed().
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/phy.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index f0522fc149..d08e8026ba 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -997,15 +997,9 @@ struct phy_device *fixed_phy_create(ofnode node) false, interface); }
-#ifdef CONFIG_DM_ETH static struct phy_device *phy_connect_fixed(struct mii_dev *bus, struct udevice *dev, phy_interface_t interface) -#else -static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
struct eth_device *dev,
phy_interface_t interface)
-#endif { struct phy_device *phydev = NULL; int sn; -- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

Use ofnode_ APIs instead of fdt_ APIs so that the fixed PHY driver can support live DT.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/phy.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index d08e8026ba..69e02685fa 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -1002,18 +1002,19 @@ static struct phy_device *phy_connect_fixed(struct mii_dev *bus, phy_interface_t interface) { struct phy_device *phydev = NULL; - int sn; + ofnode node = dev_ofnode(dev); const char *name;
- sn = fdt_first_subnode(gd->fdt_blob, dev_of_offset(dev)); - while (sn > 0) { - name = fdt_get_name(gd->fdt_blob, sn, NULL); + node = ofnode_first_subnode(node); + while (ofnode_valid(node)) { + name = ofnode_get_name(node); if (name && strcmp(name, "fixed-link") == 0) { - phydev = phy_device_create(bus, sn, PHY_FIXED_ID, false, + phydev = phy_device_create(bus, ofnode_to_offset(node), + PHY_FIXED_ID, false, interface); break; } - sn = fdt_next_subnode(gd->fdt_blob, sn); + node = ofnode_next_subnode(node); }
return phydev;

On Tue, Mar 2, 2021 at 5:35 PM Bin Meng bmeng.cn@gmail.com wrote:
Use ofnode_ APIs instead of fdt_ APIs so that the fixed PHY driver can support live DT.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/phy.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index d08e8026ba..69e02685fa 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -1002,18 +1002,19 @@ static struct phy_device *phy_connect_fixed(struct mii_dev *bus, phy_interface_t interface) { struct phy_device *phydev = NULL;
int sn;
ofnode node = dev_ofnode(dev); const char *name;
sn = fdt_first_subnode(gd->fdt_blob, dev_of_offset(dev));
while (sn > 0) {
name = fdt_get_name(gd->fdt_blob, sn, NULL);
node = ofnode_first_subnode(node);
while (ofnode_valid(node)) {
name = ofnode_get_name(node); if (name && strcmp(name, "fixed-link") == 0) {
phydev = phy_device_create(bus, sn, PHY_FIXED_ID, false,
phydev = phy_device_create(bus, ofnode_to_offset(node),
PHY_FIXED_ID, false, interface); break; }
sn = fdt_next_subnode(gd->fdt_blob, sn);
node = ofnode_next_subnode(node); } return phydev;
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

Per the upstream Linux kernel doc:
Documentation/devicetree/bindings/net/ethernet-controller.yaml
There are two ways to describe a fixed PHY attached to an Ethernet device. This updates our dt-bindings doc to add the old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
doc/device-tree-bindings/net/fixed-link.txt | 47 +++++++++++++++------ 1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/doc/device-tree-bindings/net/fixed-link.txt b/doc/device-tree-bindings/net/fixed-link.txt index 5829bd81a2..71ab480701 100644 --- a/doc/device-tree-bindings/net/fixed-link.txt +++ b/doc/device-tree-bindings/net/fixed-link.txt @@ -5,21 +5,36 @@ Some Ethernet MACs have a "fixed link", and are not connected to a normal MDIO-managed PHY device. For those situations, a Device Tree binding allows to describe a "fixed link".
-Such a fixed link situation is described by creating a 'fixed-link' -sub-node of the Ethernet MAC device node, with the following -properties: - -* 'speed' (integer, mandatory), to indicate the link speed. Accepted - values are 10, 100 and 1000 -* 'full-duplex' (boolean, optional), to indicate that full duplex is - used. When absent, half duplex is assumed. -* 'pause' (boolean, optional), to indicate that pause should be - enabled. -* 'asym-pause' (boolean, optional), to indicate that asym_pause should - be enabled. +Note there are two ways to describe a fixed PHY attached to an +Ethernet device: + +- The new DT binding, where 'fixed-link' is a sub-node of the Ethernet + MAC device node, with the following properties: + + * 'speed' (integer, mandatory), to indicate the link speed. Accepted + values are 10, 100 and 1000 + * 'full-duplex' (boolean, optional), to indicate that full duplex is + used. When absent, half duplex is assumed. + * 'pause' (boolean, optional), to indicate that pause should be + enabled. + * 'asym-pause' (boolean, optional), to indicate that asym_pause should + be enabled. + +- The old DT binding, where 'fixed-link' is a property with 5 cells + encoding various information about the fixed PHY, in the form of + <phy_id, full-duplex, speed, pause, asym-pause>. + + * 'phy_id', emulated PHY ID, choose any but unique to the all specified + fixed-links + * 'full-duplex', 0 for half duplex or 1 for full duplex + * 'speed', link speed in Mbits/sec, accepts only 10, 100 and 1000 + * 'pause', 0 for no pause, 1 for pause + * 'asym-pause', 0 for no asymmetric pause, 1 for asymmetric pause
Examples:
+The new binding: + ethernet@0 { ... fixed-link { @@ -28,3 +43,11 @@ ethernet@0 { }; ... }; + +The old binding: + +ethernet@0 { + ... + fixed-link = <0 1 1000 0 0>; + ... +};

On Tue, Mar 2, 2021 at 5:36 PM Bin Meng bmeng.cn@gmail.com wrote:
Per the upstream Linux kernel doc:
Documentation/devicetree/bindings/net/ethernet-controller.yaml
There are two ways to describe a fixed PHY attached to an Ethernet device. This updates our dt-bindings doc to add the old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/device-tree-bindings/net/fixed-link.txt | 47 +++++++++++++++------ 1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/doc/device-tree-bindings/net/fixed-link.txt b/doc/device-tree-bindings/net/fixed-link.txt index 5829bd81a2..71ab480701 100644 --- a/doc/device-tree-bindings/net/fixed-link.txt +++ b/doc/device-tree-bindings/net/fixed-link.txt @@ -5,21 +5,36 @@ Some Ethernet MACs have a "fixed link", and are not connected to a normal MDIO-managed PHY device. For those situations, a Device Tree binding allows to describe a "fixed link".
-Such a fixed link situation is described by creating a 'fixed-link' -sub-node of the Ethernet MAC device node, with the following -properties:
-* 'speed' (integer, mandatory), to indicate the link speed. Accepted
- values are 10, 100 and 1000
-* 'full-duplex' (boolean, optional), to indicate that full duplex is
- used. When absent, half duplex is assumed.
-* 'pause' (boolean, optional), to indicate that pause should be
- enabled.
-* 'asym-pause' (boolean, optional), to indicate that asym_pause should
- be enabled.
+Note there are two ways to describe a fixed PHY attached to an +Ethernet device:
+- The new DT binding, where 'fixed-link' is a sub-node of the Ethernet
- MAC device node, with the following properties:
- 'speed' (integer, mandatory), to indicate the link speed. Accepted
- values are 10, 100 and 1000
- 'full-duplex' (boolean, optional), to indicate that full duplex is
- used. When absent, half duplex is assumed.
- 'pause' (boolean, optional), to indicate that pause should be
- enabled.
- 'asym-pause' (boolean, optional), to indicate that asym_pause should
- be enabled.
+- The old DT binding, where 'fixed-link' is a property with 5 cells
- encoding various information about the fixed PHY, in the form of
- <phy_id, full-duplex, speed, pause, asym-pause>.
- 'phy_id', emulated PHY ID, choose any but unique to the all specified
- fixed-links
- 'full-duplex', 0 for half duplex or 1 for full duplex
- 'speed', link speed in Mbits/sec, accepts only 10, 100 and 1000
- 'pause', 0 for no pause, 1 for pause
- 'asym-pause', 0 for no asymmetric pause, 1 for asymmetric pause
Examples:
+The new binding:
ethernet@0 { ... fixed-link { @@ -28,3 +43,11 @@ ethernet@0 { }; ... };
+The old binding:
+ethernet@0 {
...
fixed-link = <0 1 1000 0 0>;
...
+};
2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

Introduce a helper API ofnode_phy_is_fixed_link() to detect whether the ethernet controller connects to a fixed-link pseudo-PHY device.
Note there are two ways to describe a fixed PHY attached to an Ethernet device:
- the new DT binding, where 'fixed-link' is a sub-node of the Ethernet device - the old DT binding, where 'fixed-link' is a property with 5 cells encoding various information about the fixed PHY
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/core/of_extra.c | 26 ++++++++++++++++++++++++++ include/dm/of_extra.h | 18 ++++++++++++++++++ 2 files changed, 44 insertions(+)
diff --git a/drivers/core/of_extra.c b/drivers/core/of_extra.c index 653344529e..a16f9a8dc1 100644 --- a/drivers/core/of_extra.c +++ b/drivers/core/of_extra.c @@ -130,3 +130,29 @@ int ofnode_decode_memory_region(ofnode config_node, const char *mem_type,
return 0; } + +bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode *phy_node) +{ + bool found = false; + ofnode node, subnode; + int len; + + /* new binding */ + subnode = ofnode_find_subnode(eth_node, "fixed-link"); + if (ofnode_valid(subnode)) { + node = subnode; + found = true; + } + + /* old binding */ + if (ofnode_get_property(eth_node, "fixed-link", &len) && + len == (5 * sizeof(__be32))) { + node = eth_node; + found = true; + } + + if (found && phy_node) + *phy_node = node; + + return found; +} diff --git a/include/dm/of_extra.h b/include/dm/of_extra.h index ca15df21b0..3641f68fe3 100644 --- a/include/dm/of_extra.h +++ b/include/dm/of_extra.h @@ -86,4 +86,22 @@ int ofnode_decode_memory_region(ofnode config_node, const char *mem_type, const char *suffix, fdt_addr_t *basep, fdt_size_t *sizep);
+/** + * ofnode_phy_is_fixed_link() - Detect fixed-link pseudo-PHY device + * + * This function detects whether the ethernet controller connects to a + * fixed-link pseudo-PHY device. + * + * This function supports the following two DT bindings: + * - the new DT binding, where 'fixed-link' is a sub-node of the + * Ethernet device + * - the old DT binding, where 'fixed-link' is a property with 5 + * cells encoding various information about the fixed PHY + * + * @param eth_node ofnode containing the fixed-link subnode/property + * @param phy_node if fixed-link PHY detected, containing the PHY ofnode + * @return true if a fixed-link pseudo-PHY device exists, false otherwise + */ +bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode *phy_node); + #endif

+Joe Hershberger
On Tue, 2 Mar 2021 at 10:35, Bin Meng bmeng.cn@gmail.com wrote:
Introduce a helper API ofnode_phy_is_fixed_link() to detect whether the ethernet controller connects to a fixed-link pseudo-PHY device.
Note there are two ways to describe a fixed PHY attached to an Ethernet device:
- the new DT binding, where 'fixed-link' is a sub-node of the Ethernet device
- the old DT binding, where 'fixed-link' is a property with 5 cells encoding various information about the fixed PHY
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/core/of_extra.c | 26 ++++++++++++++++++++++++++ include/dm/of_extra.h | 18 ++++++++++++++++++ 2 files changed, 44 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
Is the binding in U-Boot?

Hi Simon,
On Fri, Mar 5, 2021 at 12:08 PM Simon Glass sjg@chromium.org wrote:
+Joe Hershberger
On Tue, 2 Mar 2021 at 10:35, Bin Meng bmeng.cn@gmail.com wrote:
Introduce a helper API ofnode_phy_is_fixed_link() to detect whether the ethernet controller connects to a fixed-link pseudo-PHY device.
Note there are two ways to describe a fixed PHY attached to an Ethernet device:
- the new DT binding, where 'fixed-link' is a sub-node of the Ethernet device
- the old DT binding, where 'fixed-link' is a property with 5 cells encoding various information about the fixed PHY
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/core/of_extra.c | 26 ++++++++++++++++++++++++++ include/dm/of_extra.h | 18 ++++++++++++++++++ 2 files changed, 44 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
Is the binding in U-Boot?
Yes, in patch 5:
dt-bindings: net: Add the old DT bindings for "fixed-link" http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-6-bmeng...
Regards, Bin

This adds a test case to test the new ofnode_phy_is_fixed_link() API. Both the new and old DT bindings are covered.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/sandbox/dts/test.dts | 11 +++++++++++ test/dm/of_extra.c | 18 ++++++++++++++++++ 2 files changed, 29 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index 2600360224..995c93c95a 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -478,6 +478,17 @@ fake-host-hwaddr = [00 00 66 44 22 22]; };
+ fixed-link-test1 { + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + fixed-link-test2 { + fixed-link = <0 1 1000 0 0>; + }; + firmware { sandbox_firmware: sandbox-firmware { compatible = "sandbox,firmware"; diff --git a/test/dm/of_extra.c b/test/dm/of_extra.c index b19cd3787d..d7c584fa33 100644 --- a/test/dm/of_extra.c +++ b/test/dm/of_extra.c @@ -36,3 +36,21 @@ static int dm_test_ofnode_read_fmap_entry(struct unit_test_state *uts) return 0; } DM_TEST(dm_test_ofnode_read_fmap_entry, 0); + +static int dm_test_ofnode_phy_is_fixed_link(struct unit_test_state *uts) +{ + ofnode eth_node, phy_node, node; + + eth_node = ofnode_path("/fixed-link-test1"); + ut_assert(ofnode_phy_is_fixed_link(eth_node, &phy_node)); + node = ofnode_path("/fixed-link-test1/fixed-link"); + ut_asserteq_mem(&phy_node, &node, sizeof(ofnode)); + + eth_node = ofnode_path("/fixed-link-test2"); + ut_assert(ofnode_phy_is_fixed_link(eth_node, &phy_node)); + node = eth_node; + ut_asserteq_mem(&phy_node, &node, sizeof(ofnode)); + + return 0; +} +DM_TEST(dm_test_ofnode_phy_is_fixed_link, 0);

On Tue, 2 Mar 2021 at 10:35, Bin Meng bmeng.cn@gmail.com wrote:
This adds a test case to test the new ofnode_phy_is_fixed_link() API. Both the new and old DT bindings are covered.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/sandbox/dts/test.dts | 11 +++++++++++ test/dm/of_extra.c | 18 ++++++++++++++++++ 2 files changed, 29 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org

Switch to use the ofnode_phy_is_fixed_link() API which can support both the new and old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
net/mdio-uclass.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c index 5da984ca3f..2a9533c88b 100644 --- a/net/mdio-uclass.c +++ b/net/mdio-uclass.c @@ -11,6 +11,7 @@ #include <miiphy.h> #include <dm/device-internal.h> #include <dm/device_compat.h> +#include <dm/of_extra.h> #include <dm/uclass-internal.h> #include <linux/compat.h>
@@ -140,7 +141,7 @@ static struct phy_device *dm_eth_connect_phy_handle(struct udevice *ethdev, int i;
if (CONFIG_IS_ENABLED(PHY_FIXED) && - ofnode_valid(dev_read_subnode(ethdev, "fixed-link"))) { + ofnode_phy_is_fixed_link(dev_ofnode(ethdev), NULL)) { phy = phy_connect(NULL, -1, ethdev, interface); goto out; }

On Tue, Mar 2, 2021 at 5:35 PM Bin Meng bmeng.cn@gmail.com wrote:
Switch to use the ofnode_phy_is_fixed_link() API which can support both the new and old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
net/mdio-uclass.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c index 5da984ca3f..2a9533c88b 100644 --- a/net/mdio-uclass.c +++ b/net/mdio-uclass.c @@ -11,6 +11,7 @@ #include <miiphy.h> #include <dm/device-internal.h> #include <dm/device_compat.h> +#include <dm/of_extra.h> #include <dm/uclass-internal.h> #include <linux/compat.h>
@@ -140,7 +141,7 @@ static struct phy_device *dm_eth_connect_phy_handle(struct udevice *ethdev, int i;
if (CONFIG_IS_ENABLED(PHY_FIXED) &&
ofnode_valid(dev_read_subnode(ethdev, "fixed-link"))) {
ofnode_phy_is_fixed_link(dev_ofnode(ethdev), NULL)) { phy = phy_connect(NULL, -1, ethdev, interface); goto out; }
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

Switch to use the ofnode_phy_is_fixed_link() API which can support both the new and old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/tsec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index ec48689372..24f9962b82 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -15,6 +15,7 @@ #include <command.h> #include <tsec.h> #include <fsl_mdio.h> +#include <dm/of_extra.h> #include <linux/bitops.h> #include <linux/delay.h> #include <linux/errno.h> @@ -707,8 +708,7 @@ static int init_phy(struct tsec_private *priv) tsec_configure_serdes(priv);
#if defined(CONFIG_DM_ETH) && defined(CONFIG_DM_MDIO) - if (ofnode_valid(ofnode_find_subnode(dev_ofnode(priv->dev), - "fixed-link"))) + if (ofnode_phy_is_fixed_link(dev_ofnode(priv->dev), NULL)) phydev = phy_connect(NULL, 0, priv->dev, priv->interface); else phydev = dm_eth_phy_connect(priv->dev);

On Tue, Mar 2, 2021 at 5:35 PM Bin Meng bmeng.cn@gmail.com wrote:
Switch to use the ofnode_phy_is_fixed_link() API which can support both the new and old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/tsec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index ec48689372..24f9962b82 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -15,6 +15,7 @@ #include <command.h> #include <tsec.h> #include <fsl_mdio.h> +#include <dm/of_extra.h> #include <linux/bitops.h> #include <linux/delay.h> #include <linux/errno.h> @@ -707,8 +708,7 @@ static int init_phy(struct tsec_private *priv) tsec_configure_serdes(priv);
#if defined(CONFIG_DM_ETH) && defined(CONFIG_DM_MDIO)
if (ofnode_valid(ofnode_find_subnode(dev_ofnode(priv->dev),
"fixed-link")))
if (ofnode_phy_is_fixed_link(dev_ofnode(priv->dev), NULL)) phydev = phy_connect(NULL, 0, priv->dev, priv->interface); else phydev = dm_eth_phy_connect(priv->dev);
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

Simplify the logic of phy_connect_fixed() by using the new API ofnode_phy_is_fixed_link(), which brings additional bonus of supporting the old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/phy.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 69e02685fa..0e85a80761 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -18,6 +18,7 @@ #include <phy.h> #include <errno.h> #include <asm/global_data.h> +#include <dm/of_extra.h> #include <linux/bitops.h> #include <linux/delay.h> #include <linux/err.h> @@ -1002,19 +1003,12 @@ static struct phy_device *phy_connect_fixed(struct mii_dev *bus, phy_interface_t interface) { struct phy_device *phydev = NULL; - ofnode node = dev_ofnode(dev); - const char *name; + ofnode eth_node = dev_ofnode(dev); + ofnode phy_node;
- node = ofnode_first_subnode(node); - while (ofnode_valid(node)) { - name = ofnode_get_name(node); - if (name && strcmp(name, "fixed-link") == 0) { - phydev = phy_device_create(bus, ofnode_to_offset(node), - PHY_FIXED_ID, false, - interface); - break; - } - node = ofnode_next_subnode(node); + if (ofnode_phy_is_fixed_link(eth_node, &phy_node)) { + phydev = phy_device_create(bus, ofnode_to_offset(phy_node), + PHY_FIXED_ID, false, interface); }
return phydev;

On Tue, Mar 2, 2021 at 5:36 PM Bin Meng bmeng.cn@gmail.com wrote:
Simplify the logic of phy_connect_fixed() by using the new API ofnode_phy_is_fixed_link(), which brings additional bonus of supporting the old DT bindings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/phy.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 69e02685fa..0e85a80761 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -18,6 +18,7 @@ #include <phy.h> #include <errno.h> #include <asm/global_data.h> +#include <dm/of_extra.h> #include <linux/bitops.h> #include <linux/delay.h> #include <linux/err.h> @@ -1002,19 +1003,12 @@ static struct phy_device *phy_connect_fixed(struct mii_dev *bus, phy_interface_t interface) { struct phy_device *phydev = NULL;
ofnode node = dev_ofnode(dev);
const char *name;
ofnode eth_node = dev_ofnode(dev);
ofnode phy_node;
node = ofnode_first_subnode(node);
while (ofnode_valid(node)) {
name = ofnode_get_name(node);
if (name && strcmp(name, "fixed-link") == 0) {
phydev = phy_device_create(bus, ofnode_to_offset(node),
PHY_FIXED_ID, false,
interface);
break;
}
node = ofnode_next_subnode(node);
if (ofnode_phy_is_fixed_link(eth_node, &phy_node)) {
phydev = phy_device_create(bus, ofnode_to_offset(phy_node),
PHY_FIXED_ID, false, interface); } return phydev;
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

The PHY driver ops should be made static.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/fixed.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 1a38c29469..2a41baf8d7 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -15,7 +15,7 @@
DECLARE_GLOBAL_DATA_PTR;
-int fixedphy_probe(struct phy_device *phydev) +static int fixedphy_probe(struct phy_device *phydev) { struct fixed_link *priv; int ofnode = phydev->addr; @@ -48,7 +48,7 @@ int fixedphy_probe(struct phy_device *phydev) return 0; }
-int fixedphy_startup(struct phy_device *phydev) +static int fixedphy_startup(struct phy_device *phydev) { struct fixed_link *priv = phydev->priv;
@@ -61,7 +61,7 @@ int fixedphy_startup(struct phy_device *phydev) return 0; }
-int fixedphy_shutdown(struct phy_device *phydev) +static int fixedphy_shutdown(struct phy_device *phydev) { return 0; }

On Tue, Mar 2, 2021 at 5:36 PM Bin Meng bmeng.cn@gmail.com wrote:
The PHY driver ops should be made static.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/fixed.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 1a38c29469..2a41baf8d7 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -15,7 +15,7 @@
DECLARE_GLOBAL_DATA_PTR;
-int fixedphy_probe(struct phy_device *phydev) +static int fixedphy_probe(struct phy_device *phydev) { struct fixed_link *priv; int ofnode = phydev->addr; @@ -48,7 +48,7 @@ int fixedphy_probe(struct phy_device *phydev) return 0; }
-int fixedphy_startup(struct phy_device *phydev) +static int fixedphy_startup(struct phy_device *phydev) { struct fixed_link *priv = phydev->priv;
@@ -61,7 +61,7 @@ int fixedphy_startup(struct phy_device *phydev) return 0; }
-int fixedphy_shutdown(struct phy_device *phydev) +static int fixedphy_shutdown(struct phy_device *phydev) { return 0; } -- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

The printf statement doesn't end with a newline. Add it.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/fixed.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 2a41baf8d7..8fc9c66684 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -26,7 +26,7 @@ static int fixedphy_probe(struct phy_device *phydev) ofnode, 0, "speed", 0); if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 && val != SPEED_2500 && val != SPEED_10000) { - printf("ERROR: no/invalid speed given in fixed-link node!"); + printf("ERROR: no/invalid speed given in fixed-link node!\n"); return -EINVAL; }

On Tue, Mar 2, 2021 at 5:36 PM Bin Meng bmeng.cn@gmail.com wrote:
The printf statement doesn't end with a newline. Add it.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/fixed.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 2a41baf8d7..8fc9c66684 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -26,7 +26,7 @@ static int fixedphy_probe(struct phy_device *phydev) ofnode, 0, "speed", 0); if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 && val != SPEED_2500 && val != SPEED_10000) {
printf("ERROR: no/invalid speed given in fixed-link node!");
printf("ERROR: no/invalid speed given in fixed-link node!\n"); return -EINVAL; }
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

Update fixedphy_probe() to support the old DT binding.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/phy/fixed.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 8fc9c66684..6b720c7e4e 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -19,11 +19,25 @@ static int fixedphy_probe(struct phy_device *phydev) { struct fixed_link *priv; int ofnode = phydev->addr; + bool old_binding = false; u32 val; + u32 old_val[5];
/* check for mandatory properties within fixed-link node */ val = fdt_getprop_u32_default_node(gd->fdt_blob, ofnode, 0, "speed", 0); + + if (!val) { + /* try old binding */ + old_binding = true; + if (fdtdec_get_int_array(gd->fdt_blob, ofnode, "fixed-link", + old_val, ARRAY_SIZE(old_val))) { + printf("ERROR: no/invalid <fixed-link> property!\n"); + return -ENOENT; + } + val = old_val[2]; + } + if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 && val != SPEED_2500 && val != SPEED_10000) { printf("ERROR: no/invalid speed given in fixed-link node!\n"); @@ -38,9 +52,18 @@ static int fixedphy_probe(struct phy_device *phydev) phydev->priv = priv;
priv->link_speed = val; - priv->duplex = fdtdec_get_bool(gd->fdt_blob, ofnode, "full-duplex"); - priv->pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "pause"); - priv->asym_pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "asym-pause"); + if (!old_binding) { + priv->duplex = fdtdec_get_bool(gd->fdt_blob, ofnode, + "full-duplex"); + priv->pause = fdtdec_get_bool(gd->fdt_blob, ofnode, + "pause"); + priv->asym_pause = fdtdec_get_bool(gd->fdt_blob, ofnode, + "asym-pause"); + } else { + priv->duplex = old_val[1]; + priv->pause = old_val[3]; + priv->asym_pause = old_val[4]; + }
/* fixed-link phy must not be reset by core phy code */ phydev->flags |= PHY_FLAG_BROKEN_RESET;

On Tue, Mar 2, 2021 at 5:36 PM Bin Meng bmeng.cn@gmail.com wrote:
Update fixedphy_probe() to support the old DT binding.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/phy/fixed.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 8fc9c66684..6b720c7e4e 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -19,11 +19,25 @@ static int fixedphy_probe(struct phy_device *phydev) { struct fixed_link *priv; int ofnode = phydev->addr;
bool old_binding = false; u32 val;
u32 old_val[5]; /* check for mandatory properties within fixed-link node */ val = fdt_getprop_u32_default_node(gd->fdt_blob, ofnode, 0, "speed", 0);
if (!val) {
/* try old binding */
old_binding = true;
if (fdtdec_get_int_array(gd->fdt_blob, ofnode, "fixed-link",
old_val, ARRAY_SIZE(old_val))) {
printf("ERROR: no/invalid <fixed-link> property!\n");
return -ENOENT;
}
val = old_val[2];
}
if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 && val != SPEED_2500 && val != SPEED_10000) { printf("ERROR: no/invalid speed given in fixed-link node!\n");
@@ -38,9 +52,18 @@ static int fixedphy_probe(struct phy_device *phydev) phydev->priv = priv;
priv->link_speed = val;
priv->duplex = fdtdec_get_bool(gd->fdt_blob, ofnode, "full-duplex");
priv->pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "pause");
priv->asym_pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "asym-pause");
if (!old_binding) {
priv->duplex = fdtdec_get_bool(gd->fdt_blob, ofnode,
"full-duplex");
priv->pause = fdtdec_get_bool(gd->fdt_blob, ofnode,
"pause");
priv->asym_pause = fdtdec_get_bool(gd->fdt_blob, ofnode,
"asym-pause");
} else {
priv->duplex = old_val[1];
priv->pause = old_val[3];
priv->asym_pause = old_val[4];
} /* fixed-link phy must not be reset by core phy code */ phydev->flags |= PHY_FLAG_BROKEN_RESET;
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

At present the Freescale TSEC node DT bindings doc requires a <reg> property in the TSEC node. But this might not always be the case. In the upstream Linux kernel, there is no DT bindings doc for it but the kernel driver tests a subnode of a name prefixed with "queue-group", as we can see from gfar_of_init():
for_each_available_child_of_node(np, child) { if (!of_node_name_eq(child, "queue-group")) ...
in drivers/net/ethernet/freescale/gianfar.c
Update our DT bindings to describe this alternate description.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
doc/device-tree-bindings/net/fsl-tsec-phy.txt | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt b/doc/device-tree-bindings/net/fsl-tsec-phy.txt index a44c5fd9d9..2f9309839c 100644 --- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt +++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt @@ -3,7 +3,9 @@ Properties:
- compatible : Should be "fsl,etsec2" or "gianfar" - - reg : Offset and length of the register set for the device + - reg : Offset and length of the register set for the device. If this is + missing, a subnode with a name prefix "queue-group" must be provided to + provide the <reg> property. - phy-handle : See ethernet.txt file in the same directory. - phy-connection-type : See ethernet.txt file in the same directory. This property is only really needed if the connection is of type "rgmii-id", @@ -18,6 +20,17 @@ Example: phy-connection-type = "sgmii"; };
+An alternate description with "queue-group" subnode example: + ethernet@24000 { + compatible = "fsl,etsec2"; + phy-handle = <&phy0>; + phy-connection-type = "sgmii"; + + queue-group { + reg = <0x24000 0x1000>; + }; + }; + Child nodes of the TSEC controller are typically the individual PHY devices connected via the MDIO bus (sometimes the MDIO bus controller is separate).

On Tue, Mar 2, 2021 at 5:38 PM Bin Meng bmeng.cn@gmail.com wrote:
At present the Freescale TSEC node DT bindings doc requires a <reg> property in the TSEC node. But this might not always be the case. In the upstream Linux kernel, there is no DT bindings doc for it but the kernel driver tests a subnode of a name prefixed with "queue-group", as we can see from gfar_of_init():
for_each_available_child_of_node(np, child) { if (!of_node_name_eq(child, "queue-group")) ...
in drivers/net/ethernet/freescale/gianfar.c
Update our DT bindings to describe this alternate description.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/device-tree-bindings/net/fsl-tsec-phy.txt | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt b/doc/device-tree-bindings/net/fsl-tsec-phy.txt index a44c5fd9d9..2f9309839c 100644 --- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt +++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt @@ -3,7 +3,9 @@ Properties:
- compatible : Should be "fsl,etsec2" or "gianfar"
- reg : Offset and length of the register set for the device
- reg : Offset and length of the register set for the device. If this is
- missing, a subnode with a name prefix "queue-group" must be provided to
- provide the <reg> property.
property is only really needed if the connection is of type "rgmii-id",
- phy-handle : See ethernet.txt file in the same directory.
- phy-connection-type : See ethernet.txt file in the same directory. This
@@ -18,6 +20,17 @@ Example: phy-connection-type = "sgmii"; };
+An alternate description with "queue-group" subnode example:
ethernet@24000 {
compatible = "fsl,etsec2";
phy-handle = <&phy0>;
phy-connection-type = "sgmii";
queue-group {
reg = <0x24000 0x1000>;
};
};
Child nodes of the TSEC controller are typically the individual PHY devices connected via the MDIO bus (sometimes the MDIO bus controller is separate).
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

At present the tsec driver uses a non-standard DT bindings to get its <reg> base / size. The upstream Linux kernel seems to require the <reg> base / size to be put under a subnode of the eTSEC node with a name prefix "queue-group". This is not documented in the kernel DT bindings, but it looks every dtsi file that contains the eTSEC node was written like this.
This commit updates the tsec driver to handle this case.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/net/tsec.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index 24f9962b82..5012cd29f1 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -831,13 +831,35 @@ int tsec_probe(struct udevice *dev) struct tsec_data *data; const char *phy_mode; fdt_addr_t reg; - ofnode parent; + ofnode parent, child; int ret;
data = (struct tsec_data *)dev_get_driver_data(dev);
pdata->iobase = (phys_addr_t)dev_read_addr(dev); - priv->regs = dev_remap_addr(dev); + if (pdata->iobase != FDT_ADDR_T_NONE) { + priv->regs = dev_remap_addr(dev); + } else { + ofnode_for_each_subnode(child, dev_ofnode(dev)) { + if (!strncmp(ofnode_get_name(child), "queue-group", + strlen("queue-group"))) { + reg = ofnode_get_addr(child); + if (reg == FDT_ADDR_T_NONE) { + printf("No 'reg' property of <queue-group>\n"); + return -ENOENT; + } + pdata->iobase = reg; + priv->regs = map_physmem(pdata->iobase, 0, + MAP_NOCACHE); + break; + } + } + + if (!ofnode_valid(child)) { + printf("No child node for <queue-group>?\n"); + return -ENOENT; + } + }
ret = dev_read_phandle_with_args(dev, "tbi-handle", NULL, 0, 0, &phandle_args);

On Tue, Mar 2, 2021 at 5:36 PM Bin Meng bmeng.cn@gmail.com wrote:
At present the tsec driver uses a non-standard DT bindings to get its <reg> base / size. The upstream Linux kernel seems to require the <reg> base / size to be put under a subnode of the eTSEC node with a name prefix "queue-group". This is not documented in the kernel DT bindings, but it looks every dtsi file that contains the eTSEC node was written like this.
This commit updates the tsec driver to handle this case.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/net/tsec.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index 24f9962b82..5012cd29f1 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -831,13 +831,35 @@ int tsec_probe(struct udevice *dev) struct tsec_data *data; const char *phy_mode; fdt_addr_t reg;
ofnode parent;
ofnode parent, child; int ret; data = (struct tsec_data *)dev_get_driver_data(dev); pdata->iobase = (phys_addr_t)dev_read_addr(dev);
priv->regs = dev_remap_addr(dev);
if (pdata->iobase != FDT_ADDR_T_NONE) {
priv->regs = dev_remap_addr(dev);
} else {
ofnode_for_each_subnode(child, dev_ofnode(dev)) {
if (!strncmp(ofnode_get_name(child), "queue-group",
strlen("queue-group"))) {
reg = ofnode_get_addr(child);
if (reg == FDT_ADDR_T_NONE) {
printf("No 'reg' property of <queue-group>\n");
return -ENOENT;
}
pdata->iobase = reg;
priv->regs = map_physmem(pdata->iobase, 0,
MAP_NOCACHE);
break;
}
}
if (!ofnode_valid(child)) {
printf("No child node for <queue-group>?\n");
return -ENOENT;
}
} ret = dev_read_phandle_with_args(dev, "tbi-handle", NULL, 0, 0, &phandle_args);
-- 2.25.1
Reviewed-By: Ramon Fried rfried.dev@gmail.com

At present we decode simple bus <ranges> using the following assumption:
- parent #address-cells 1 - child #address-cells 1 - child #size-cells 1
However this might not always be the case.
Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and use fdt_read_ranges() to correctly decode it according to the actual parent and child #address-cells / #size-cells.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/core/simple-bus.c | 15 ++++++++++----- include/dm/simple_bus.h | 6 +++--- 2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c index b0c2c20958..b5863f2b2c 100644 --- a/drivers/core/simple-bus.c +++ b/drivers/core/simple-bus.c @@ -6,6 +6,9 @@ #include <common.h> #include <dm.h> #include <dm/simple_bus.h> +#include <fdt_support.h> + +DECLARE_GLOBAL_DATA_PTR;
fdt_addr_t simple_bus_translate(struct udevice *dev, fdt_addr_t addr) { @@ -22,16 +25,18 @@ static int simple_bus_post_bind(struct udevice *dev) #if CONFIG_IS_ENABLED(OF_PLATDATA) return 0; #else - u32 cell[3]; + uint64_t caddr, paddr, len; int ret;
- ret = dev_read_u32_array(dev, "ranges", cell, ARRAY_SIZE(cell)); + /* only read range index 0 */ + ret = fdt_read_range((void *)gd->fdt_blob, dev_of_offset(dev), 0, + &caddr, &paddr, &len); if (!ret) { struct simple_bus_plat *plat = dev_get_uclass_plat(dev);
- plat->base = cell[0]; - plat->target = cell[1]; - plat->size = cell[2]; + plat->base = caddr; + plat->target = paddr; + plat->size = len; }
return dm_scan_fdt_dev(dev); diff --git a/include/dm/simple_bus.h b/include/dm/simple_bus.h index 4ad4cc4051..b7104013c0 100644 --- a/include/dm/simple_bus.h +++ b/include/dm/simple_bus.h @@ -7,9 +7,9 @@ #define __DM_SIMPLE_BUS_H
struct simple_bus_plat { - u32 base; - u32 size; - u32 target; + fdt_addr_t base; + fdt_size_t size; + fdt_addr_t target; };
#endif

On Tue, Mar 02, 2021 at 11:34:47PM +0800, Bin Meng wrote:
At present we decode simple bus <ranges> using the following assumption:
- parent #address-cells 1
- child #address-cells 1
- child #size-cells 1
However this might not always be the case.
Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and use fdt_read_ranges() to correctly decode it according to the actual parent and child #address-cells / #size-cells.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/core/simple-bus.c | 15 ++++++++++----- include/dm/simple_bus.h | 6 +++--- 2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c index b0c2c20958..b5863f2b2c 100644 --- a/drivers/core/simple-bus.c +++ b/drivers/core/simple-bus.c @@ -6,6 +6,9 @@ #include <common.h> #include <dm.h> #include <dm/simple_bus.h> +#include <fdt_support.h>
+DECLARE_GLOBAL_DATA_PTR;
You need to add <asm/global_data.h> here too.

This adds a test case to verify reading <ranges> of a simple-bus is working as expected.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
test/dm/Makefile | 1 + test/dm/simple-bus.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) create mode 100644 test/dm/simple-bus.c
diff --git a/test/dm/Makefile b/test/dm/Makefile index 6275ec56ea..1e92625105 100644 --- a/test/dm/Makefile +++ b/test/dm/Makefile @@ -89,6 +89,7 @@ obj-$(CONFIG_DM_MDIO) += mdio.o obj-$(CONFIG_DM_MDIO_MUX) += mdio_mux.o obj-$(CONFIG_DM_RNG) += rng.o obj-$(CONFIG_CLK_K210_SET_RATE) += k210_pll.o +obj-$(CONFIG_SIMPLE_BUS) += simple-bus.o obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o obj-$(CONFIG_RESET_SYSCON) += syscon-reset.o obj-$(CONFIG_SCMI_FIRMWARE) += scmi.o diff --git a/test/dm/simple-bus.c b/test/dm/simple-bus.c new file mode 100644 index 0000000000..3530b47fac --- /dev/null +++ b/test/dm/simple-bus.c @@ -0,0 +1,33 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2021, Bin Meng bmeng.cn@gmail.com + */ + +#include <common.h> +#include <dm.h> +#include <dm/test.h> +#include <dm/simple_bus.h> +#include <dm/uclass-internal.h> +#include <test/ut.h> + +static int dm_test_simple_bus(struct unit_test_state *uts) +{ + struct udevice *dev; + struct simple_bus_plat *plat; + + /* locate the dummy device @ translation-test node */ + ut_assertok(uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, &dev)); + ut_asserteq_str("dev@0,0", dev->name); + + /* locate the parent node which is a simple-bus */ + ut_assertnonnull(dev = dev_get_parent(dev)); + ut_asserteq_str("translation-test@8000", dev->name); + + ut_assertnonnull(plat = dev_get_uclass_plat(dev)); + ut_asserteq(0, plat->base); + ut_asserteq(0x8000, plat->target); + ut_asserteq(0x1000, plat->size); + + return 0; +} +DM_TEST(dm_test_simple_bus, UT_TESTF_SCAN_FDT | UT_TESTF_FLAT_TREE);

On Tue, 2 Mar 2021 at 10:36, Bin Meng bmeng.cn@gmail.com wrote:
This adds a test case to verify reading <ranges> of a simple-bus is working as expected.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
test/dm/Makefile | 1 + test/dm/simple-bus.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) create mode 100644 test/dm/simple-bus.c
Reviewed-by: Simon Glass sjg@chromium.org

QEMU ppce500 target can dynamically instantiate an eTSEC device on a platform bus if "-device eTSEC" is given to QEMU. It is presented as a "simple-bus" in the device tree, with an additional compatible string "qemu,platform".
Let's create a virtual memory mapping for it in misc_init_r(), in preparation to adding eTSEC support.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/emulation/qemu-ppce500/Kconfig | 6 ++++++ board/emulation/qemu-ppce500/qemu-ppce500.c | 18 ++++++++++++++++++ 2 files changed, 24 insertions(+)
diff --git a/board/emulation/qemu-ppce500/Kconfig b/board/emulation/qemu-ppce500/Kconfig index 4312d986d8..1c5aa18aa9 100644 --- a/board/emulation/qemu-ppce500/Kconfig +++ b/board/emulation/qemu-ppce500/Kconfig @@ -9,4 +9,10 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "qemu-ppce500"
+config PLATFORM_BUS_MAP_ADDR + hex + default 0xf0000000 + help + The QEMU platform bus base mapped address in the virtual memory space. + endif diff --git a/board/emulation/qemu-ppce500/qemu-ppce500.c b/board/emulation/qemu-ppce500/qemu-ppce500.c index daa103c564..0960dd1f97 100644 --- a/board/emulation/qemu-ppce500/qemu-ppce500.c +++ b/board/emulation/qemu-ppce500/qemu-ppce500.c @@ -14,6 +14,8 @@ #include <net.h> #include <pci.h> #include <time.h> +#include <dm/simple_bus.h> +#include <dm/uclass-internal.h> #include <asm/global_data.h> #include <asm/processor.h> #include <asm/mmu.h> @@ -148,6 +150,22 @@ int misc_init_r(void) */ disable_tlb(find_tlb_idx((void *)CONFIG_SYS_TMPVIRT, 1));
+ /* + * Detect the presence of the platform bus node, and + * create a virtual memory mapping for it. + */ + for (ret = uclass_find_first_device(UCLASS_SIMPLE_BUS, &dev); + dev; + ret = uclass_find_next_device(&dev)) { + if (device_is_compatible(dev, "qemu,platform")) { + struct simple_bus_plat *plat = dev_get_uclass_plat(dev); + + assert(!tlb_map_range(CONFIG_PLATFORM_BUS_MAP_ADDR, + plat->target, plat->size, + TLB_MAP_IO)); + } + } + return 0; }

QEMU ppce500 target can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU. This commit enables eTSEC driver and the required fixed PHY driver to create a usable network configuration using eTSEC.
Unlike a real world 85xx board that usually stores the eTSEC MAC address in an EEPROM, CONFIG_NET_RANDOM_ETHADDR is required for QEMU otherwise U-Boot ethernet initialization complains no valid ethernet address is set.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
configs/qemu-ppce500_defconfig | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 536fe7d6e1..6d21aa48bc 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -27,6 +27,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_BOARD=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_BLK=y CONFIG_HAVE_BLOCK_DEVICE=y @@ -34,8 +35,11 @@ CONFIG_MPC8XXX_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_FSL=y # CONFIG_MMC is not set +CONFIG_PHY_FIXED=y CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y +CONFIG_TSEC_ENET=y CONFIG_DM_PCI=y CONFIG_PCI_MPC85XX=y CONFIG_DM_RTC=y

Document how to launch a QEMU session with eTSEC as a network device.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
doc/board/emulation/qemu-ppce500.rst | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/doc/board/emulation/qemu-ppce500.rst b/doc/board/emulation/qemu-ppce500.rst index 0a5c86c61a..5de0aaf55d 100644 --- a/doc/board/emulation/qemu-ppce500.rst +++ b/doc/board/emulation/qemu-ppce500.rst @@ -70,6 +70,11 @@ interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by:: $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot \ -nic tap,ifname=tap0,script=no,downscript=no,model=e1000
+The QEMU ppce500 machine can also dynamically instantiate an eTSEC device if +"-device eTSEC" is given to QEMU:: + + -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device eTSEC,netdev=net0 + VirtIO BLK driver is also enabled to support booting from a disk image where a kernel image is stored. Append the following to QEMU::

Hi Tom,
On Tue, Mar 2, 2021 at 11:35 PM Bin Meng bmeng.cn@gmail.com wrote:
QEMU ppce500 machine can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as the Freescale eTSEC driver to support the QEMU ppce500 board.
Based-on: http://patchwork.ozlabs.org/project/uboot/list/?series=230985
This series is avaiable at u-boot-x86/eTSEC for testing.
Azure results say there are several ARM boards fail to build due to size overflow with this series. https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=resul...
How do we handle this?
Regards, Bin

Hi Bin,
On Tue, 2 Mar 2021 at 18:08, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Tue, Mar 2, 2021 at 11:35 PM Bin Meng bmeng.cn@gmail.com wrote:
QEMU ppce500 machine can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as the Freescale eTSEC driver to support the QEMU ppce500 board.
Based-on: http://patchwork.ozlabs.org/project/uboot/list/?series=230985
This series is avaiable at u-boot-x86/eTSEC for testing.
Azure results say there are several ARM boards fail to build due to size overflow with this series. https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=resul...
How do we handle this?
The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. That's a very large growth, indicating that your series is doing something odd, perhaps?
I suppose you know this, but you can use:
buildman -b try imx6dl_mamoj buildman -b try -sS
to see which commit creates the size growth, and -B to see which functions.
Regards, Simon

Hi Simon,
On Wed, Mar 3, 2021 at 9:53 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Tue, 2 Mar 2021 at 18:08, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Tue, Mar 2, 2021 at 11:35 PM Bin Meng bmeng.cn@gmail.com wrote:
QEMU ppce500 machine can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as the Freescale eTSEC driver to support the QEMU ppce500 board.
Based-on: http://patchwork.ozlabs.org/project/uboot/list/?series=230985
This series is avaiable at u-boot-x86/eTSEC for testing.
Azure results say there are several ARM boards fail to build due to size overflow with this series. https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=resul...
How do we handle this?
The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. That's a very large growth, indicating that your series is doing something odd, perhaps?
I suppose you know this, but you can use:
buildman -b try imx6dl_mamoj buildman -b try -sS
to see which commit creates the size growth, and -B to see which functions.
Thanks, so it's caused by this patch: http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmen...
16: dm: core: Correctly read <ranges> of simple-bus arm: + imx6dl_mamoj arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0 spl/u-boot-spl:text +1028.0 text +306.0 imx6dl_mamoj : all +274 bss -32 spl/u-boot-spl:all +3232 spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180 spl/u-boot-spl:text +1028 text +306 spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046) function old new delta __of_translate_address - 404 +404 fdt_read_range - 208 +208 of_bus_default_map - 148 +148 of_bus_default_translate - 114 +114 fdt_read_prop - 66 +66 fdt_support_default_count_cells - 52 +52 fdt_getprop_u32_default_node - 36 +36 of_busses - 24 +24 fdt_translate_address - 12 +12 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24 u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292) function old new delta fdt_read_range - 208 +208 fdt_read_prop - 66 +66 fdt_getprop_u32_default_node - 36 +36 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24
But this patch is a bug fix. I am not sure how we can avoid the size increase.
Regards, Bin

On Wed, Mar 03, 2021 at 10:11:45AM +0800, Bin Meng wrote:
Hi Simon,
On Wed, Mar 3, 2021 at 9:53 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Tue, 2 Mar 2021 at 18:08, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Tue, Mar 2, 2021 at 11:35 PM Bin Meng bmeng.cn@gmail.com wrote:
QEMU ppce500 machine can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as the Freescale eTSEC driver to support the QEMU ppce500 board.
Based-on: http://patchwork.ozlabs.org/project/uboot/list/?series=230985
This series is avaiable at u-boot-x86/eTSEC for testing.
Azure results say there are several ARM boards fail to build due to size overflow with this series. https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=resul...
How do we handle this?
The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. That's a very large growth, indicating that your series is doing something odd, perhaps?
I suppose you know this, but you can use:
buildman -b try imx6dl_mamoj buildman -b try -sS
to see which commit creates the size growth, and -B to see which functions.
Thanks, so it's caused by this patch: http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmen...
16: dm: core: Correctly read <ranges> of simple-bus arm: + imx6dl_mamoj arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0 spl/u-boot-spl:text +1028.0 text +306.0 imx6dl_mamoj : all +274 bss -32 spl/u-boot-spl:all +3232 spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180 spl/u-boot-spl:text +1028 text +306 spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046) function old new delta __of_translate_address - 404 +404 fdt_read_range - 208 +208 of_bus_default_map - 148 +148 of_bus_default_translate - 114 +114 fdt_read_prop - 66 +66 fdt_support_default_count_cells - 52 +52 fdt_getprop_u32_default_node - 36 +36 of_busses - 24 +24 fdt_translate_address - 12 +12 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24 u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292) function old new delta fdt_read_range - 208 +208 fdt_read_prop - 66 +66 fdt_getprop_u32_default_node - 36 +36 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24
But this patch is a bug fix. I am not sure how we can avoid the size increase.
I'd love to hear there's a clever fix we can do here for SPL, but in the likely case there isn't, this might get stuck until the LTO series that was posted today goes in as well, as that will give us some size back. I assume this was a bug fix your series needed and not something you noticed while in the code.

Hi Bin,
On Wed, 3 Mar 2021 at 09:49, Tom Rini trini@konsulko.com wrote:
On Wed, Mar 03, 2021 at 10:11:45AM +0800, Bin Meng wrote:
Hi Simon,
On Wed, Mar 3, 2021 at 9:53 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Tue, 2 Mar 2021 at 18:08, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Tue, Mar 2, 2021 at 11:35 PM Bin Meng bmeng.cn@gmail.com wrote:
QEMU ppce500 machine can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as the Freescale eTSEC driver to support the QEMU ppce500 board.
Based-on: http://patchwork.ozlabs.org/project/uboot/list/?series=230985
This series is avaiable at u-boot-x86/eTSEC for testing.
Azure results say there are several ARM boards fail to build due to size overflow with this series. https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=resul...
How do we handle this?
The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. That's a very large growth, indicating that your series is doing something odd, perhaps?
I suppose you know this, but you can use:
buildman -b try imx6dl_mamoj buildman -b try -sS
to see which commit creates the size growth, and -B to see which functions.
Thanks, so it's caused by this patch: http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmen...
16: dm: core: Correctly read <ranges> of simple-bus arm: + imx6dl_mamoj arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0 spl/u-boot-spl:text +1028.0 text +306.0 imx6dl_mamoj : all +274 bss -32 spl/u-boot-spl:all +3232 spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180 spl/u-boot-spl:text +1028 text +306 spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046) function old new delta __of_translate_address - 404 +404 fdt_read_range - 208 +208 of_bus_default_map - 148 +148 of_bus_default_translate - 114 +114 fdt_read_prop - 66 +66 fdt_support_default_count_cells - 52 +52 fdt_getprop_u32_default_node - 36 +36 of_busses - 24 +24 fdt_translate_address - 12 +12 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24 u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292) function old new delta fdt_read_range - 208 +208 fdt_read_prop - 66 +66 fdt_getprop_u32_default_node - 36 +36 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24
But this patch is a bug fix. I am not sure how we can avoid the size increase.
I'd love to hear there's a clever fix we can do here for SPL, but in the likely case there isn't, this might get stuck until the LTO series that was posted today goes in as well, as that will give us some size back. I assume this was a bug fix your series needed and not something you noticed while in the code.
The size increase is so enormous that I'd argue for a new Kconfig that you can select for the board that needs it.
Regards, Simon

Hi Simon,
On Thu, Mar 4, 2021 at 1:21 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Wed, 3 Mar 2021 at 09:49, Tom Rini trini@konsulko.com wrote:
On Wed, Mar 03, 2021 at 10:11:45AM +0800, Bin Meng wrote:
Hi Simon,
On Wed, Mar 3, 2021 at 9:53 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Tue, 2 Mar 2021 at 18:08, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Tue, Mar 2, 2021 at 11:35 PM Bin Meng bmeng.cn@gmail.com wrote:
QEMU ppce500 machine can dynamically instantiate an eTSEC device if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as the Freescale eTSEC driver to support the QEMU ppce500 board.
Based-on: http://patchwork.ozlabs.org/project/uboot/list/?series=230985
This series is avaiable at u-boot-x86/eTSEC for testing.
Azure results say there are several ARM boards fail to build due to size overflow with this series. https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=resul...
How do we handle this?
The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. That's a very large growth, indicating that your series is doing something odd, perhaps?
I suppose you know this, but you can use:
buildman -b try imx6dl_mamoj buildman -b try -sS
to see which commit creates the size growth, and -B to see which functions.
Thanks, so it's caused by this patch: http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmen...
16: dm: core: Correctly read <ranges> of simple-bus arm: + imx6dl_mamoj arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0 spl/u-boot-spl:text +1028.0 text +306.0 imx6dl_mamoj : all +274 bss -32 spl/u-boot-spl:all +3232 spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180 spl/u-boot-spl:text +1028 text +306 spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046) function old new delta __of_translate_address - 404 +404 fdt_read_range - 208 +208 of_bus_default_map - 148 +148 of_bus_default_translate - 114 +114 fdt_read_prop - 66 +66 fdt_support_default_count_cells - 52 +52 fdt_getprop_u32_default_node - 36 +36 of_busses - 24 +24 fdt_translate_address - 12 +12 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24 u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292) function old new delta fdt_read_range - 208 +208 fdt_read_prop - 66 +66 fdt_getprop_u32_default_node - 36 +36 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24
But this patch is a bug fix. I am not sure how we can avoid the size increase.
I'd love to hear there's a clever fix we can do here for SPL, but in the likely case there isn't, this might get stuck until the LTO series that was posted today goes in as well, as that will give us some size back. I assume this was a bug fix your series needed and not something you noticed while in the code.
The size increase is so enormous that I'd argue for a new Kconfig that you can select for the board that needs it.
OK, a new Kconfig seems to be odd, but it looks there is no better way of doing this.
Regards, Bin

Hi Bin,
On Wed, 3 Mar 2021 at 20:58, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Mar 4, 2021 at 1:21 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Wed, 3 Mar 2021 at 09:49, Tom Rini trini@konsulko.com wrote:
On Wed, Mar 03, 2021 at 10:11:45AM +0800, Bin Meng wrote:
Hi Simon,
On Wed, Mar 3, 2021 at 9:53 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Tue, 2 Mar 2021 at 18:08, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Tue, Mar 2, 2021 at 11:35 PM Bin Meng bmeng.cn@gmail.com wrote: > > QEMU ppce500 machine can dynamically instantiate an eTSEC device > if "-device eTSEC" is given to QEMU. > > This series updates the fixed-link ethernet PHY driver as well as > the Freescale eTSEC driver to support the QEMU ppce500 board. > > Based-on: > http://patchwork.ozlabs.org/project/uboot/list/?series=230985 > > This series is avaiable at u-boot-x86/eTSEC for testing. > >
Azure results say there are several ARM boards fail to build due to size overflow with this series. https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=resul...
How do we handle this?
The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit. That's a very large growth, indicating that your series is doing something odd, perhaps?
I suppose you know this, but you can use:
buildman -b try imx6dl_mamoj buildman -b try -sS
to see which commit creates the size growth, and -B to see which functions.
Thanks, so it's caused by this patch: http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmen...
16: dm: core: Correctly read <ranges> of simple-bus arm: + imx6dl_mamoj arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0 spl/u-boot-spl:text +1028.0 text +306.0 imx6dl_mamoj : all +274 bss -32 spl/u-boot-spl:all +3232 spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180 spl/u-boot-spl:text +1028 text +306 spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046) function old new delta __of_translate_address - 404 +404 fdt_read_range - 208 +208 of_bus_default_map - 148 +148 of_bus_default_translate - 114 +114 fdt_read_prop - 66 +66 fdt_support_default_count_cells - 52 +52 fdt_getprop_u32_default_node - 36 +36 of_busses - 24 +24 fdt_translate_address - 12 +12 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24 u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292) function old new delta fdt_read_range - 208 +208 fdt_read_prop - 66 +66 fdt_getprop_u32_default_node - 36 +36 simple_bus_post_bind 52 58 +6 ofnode_read_u32_array 24 - -24
But this patch is a bug fix. I am not sure how we can avoid the size increase.
I'd love to hear there's a clever fix we can do here for SPL, but in the likely case there isn't, this might get stuck until the LTO series that was posted today goes in as well, as that will give us some size back. I assume this was a bug fix your series needed and not something you noticed while in the code.
The size increase is so enormous that I'd argue for a new Kconfig that you can select for the board that needs it.
OK, a new Kconfig seems to be odd, but it looks there is no better way of doing this.
OK then.
Regards, Simon
participants (6)
-
Bin Meng
-
Michal Simek
-
Ramon Fried
-
Simon Glass
-
Tom Rini
-
Vladimir Oltean