On Thu, Apr 7, 2022 at 2:31 PM Vladimir Oltean <vladimir.olt...@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
