On Thu, Apr 7, 2022 at 2:31 PM Vladimir Oltean vladimir.oltean@nxp.com wrote:
On Thu, Apr 07, 2022 at 01:33:58PM -0700, Tim Harvey wrote:
I guess I'll have to invest in tagging packets if you won't accept the simplistic approach of not having to tag frames knowing that only one port is active at a time.
I genuinely don't know where you got the impression from that I don't accept the simplistic approach. I gave you an option to make the xmit and receive ops actually optional at the DSA uclass level so you don't have to come up with a make-believe tag parsing function. In the end it goes towards the simplification of the Marvell driver. Let's let them battle it out for a while and if tag insertion/parsing won't be necessary even for multi-switch systems we can discuss about removing that logic completely.
Ok... sorry I misunderstood.
That said, I have no idea if or when I will re-visit this. Adding a DSA version of this driver was something on my personal wish list and not something that was necessary by any means by my employer so I may have to just drop it as I don't have the personal time to work through this part of it or unravelling the mii bus mess in the fec_mxc driver. It seems to me there is an issue with trying to create DM_MDIO drivers in general as most dt's I've seen wouldn't support the requirements yet configure DM_MDIO anyway (meaning if you implemented it you would break those boards as I found).
I don't know why there are boards which set CONFIG_DM_MDIO and then fight against the current trying to survive that config being set. Maybe you can look into disabling that config option on boards that aren't prepared to handle it?
There might not be many boards that would 'break'. Here's what uses FEC_MXC and DM_MDIO: $ grep -H CONFIG_FEC_MXC configs/* | awk -F: '{ print $1 }' | xargs grep DM_MDIO configs/colibri_imx7_defconfig:CONFIG_DM_MDIO=y configs/colibri_imx7_emmc_defconfig:CONFIG_DM_MDIO=y configs/ge_b1x5v2_defconfig:CONFIG_DM_MDIO=y configs/gwventana_emmc_defconfig:CONFIG_DM_MDIO=y configs/gwventana_gw5904_defconfig:CONFIG_DM_MDIO=y configs/gwventana_nand_defconfig:CONFIG_DM_MDIO=y configs/imx7_cm_defconfig:CONFIG_DM_MDIO=y configs/imx7_cm_defconfig:CONFIG_DM_MDIO_MUX=y configs/imx8mm_venice_defconfig:CONFIG_DM_MDIO=y configs/imx8mn_venice_defconfig:CONFIG_DM_MDIO=y configs/imx8mp_venice_defconfig:CONFIG_DM_MDIO=y configs/m53menlo_defconfig:CONFIG_DM_MDIO=y configs/mx7dsabresd_defconfig:CONFIG_DM_MDIO=y configs/mx7dsabresd_defconfig:CONFIG_DM_MDIO_MUX=y configs/mx7dsabresd_qspi_defconfig:CONFIG_DM_MDIO=y configs/mx7dsabresd_qspi_defconfig:CONFIG_DM_MDIO_MUX=y configs/opos6uldev_defconfig:CONFIG_DM_MDIO=y configs/pcm058_defconfig:CONFIG_DM_MDIO=y configs/pico-dwarf-imx7d_defconfig:CONFIG_DM_MDIO=y configs/pico-hobbit-imx7d_defconfig:CONFIG_DM_MDIO=y configs/pico-imx7d_bl33_defconfig:CONFIG_DM_MDIO=y configs/pico-imx7d_defconfig:CONFIG_DM_MDIO=y configs/pico-nymph-imx7d_defconfig:CONFIG_DM_MDIO=y configs/pico-pi-imx7d_defconfig:CONFIG_DM_MDIO=y configs/udoo_neo_defconfig:CONFIG_DM_MDIO=y
The venice/gwventana ones are mine so I can easily test/fix. For the others just looking at their CONFIG_DEFAULT_DEVICE_TREE and eliminating duplicates I see:
I believe these would break: arch/arm/dts/imx7-colibri-rawnand.dts (no mdio subnode) arch/arm/dts/imx7-colibri-emmc.dts (no mdio subnode) arch/arm/dts/imx6sx-udoo-neo-basic.dts (no phy-mode)
These should be ok; have phy-mode, phy-handle, mdio subnode arch/arm/dts/imx6dl-b1x5v2.dts arch/arm/dts/imx7-cm.dts arch/arm/dts/imx53-m53menlo.dts arch/arm/dts/imx6ul-opos6uldev.dts arch/arm/dts/imx6q-phytec-mira-rdk-nand.dts arch/arm/dts/imx7d-pico-pi.dts
These may be ok; has phy-mode, phy-handle, mdio subnode for fec1, but missing mdio subnode for fec2 (but should use mdio from fec1) arch/arm/dts/imx7d-sdb.dts arch/arm/dts/imx7d-sdb-qspi.dts
I feel like I would need to get all board maintainers using FEC_MXC to sign-off that their boards still work.
But then there is this issue of CONFIG_DM_ETH_PHY that still throws around the concept of struct mii_dev* (which I think should have been handled by switching to DM_MDIO). There are now three drivers using this and I'm not sure what to do with that. There are 28 boards using CONFIG_DM_ETH_PHY (and likely some which are not even using one of the three drivers that even use CONFIG_DM_ETH_PHY).
Is there a move to try and move all network drivers to DM_MDIO eliminating the need for struct mii_dev* within those drivers?
Best Regards,
Tim