On Thu, Mar 31, 2022 at 12:36 PM Vladimir Oltean
<vladimir.olt...@nxp.com> wrote:
>
> On Thu, Mar 31, 2022 at 10:48:55AM -0700, Tim Harvey wrote:
> > > On which branch does this apply? The context above
> > > fecmxc_read_rom_hwaddr()
> > > is different in the branches I've checked:
> > > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1276
> > > https://source.denx.de/u-boot/custodians/u-boot-net/-/blob/next/drivers/net/fec_mxc.c#L1276
> > >
> >
> > Sorry, I should have specified in my cover letter that this is on top
> > of next which removes the non dm-eth support from the driver which is
> > quite the cleanup.
>
> Ok, but now the next patch fails to apply to the 'next' branch:
I based on top of origin/next, specifically:
34d2b7f20369 (origin/next) Merge tag 'v2022.04-rc5' into next
>
> Applying: net: dsa: move cpu port probe to dsa_post_probe
> Applying: net: mdio-uclass: add wrappers for read/write/reset operations
> Applying: net: fec: add support for DM_MDIO
> Applying: net: add MV88E61xx DSA driver
> error: patch failed: drivers/net/Kconfig:428
> error: drivers/net/Kconfig: patch does not apply
> error: patch failed: drivers/net/Makefile:66
> error: drivers/net/Makefile: patch does not apply
> Patch failed at 0005 net: add MV88E61xx DSA driver
>
> > Also, after more testing I believe the dm-mdio driver code 'above' is
> > correct but the business of trying to use it and fallback 'below' is
> > wrong and needs work. It doesn't break current users of fec_mxc from
> > what I can tell but it also doesn't properly connect the dm_mdio
> > driver.
>
> Can you spell out what is wrong about the fallback logic?
>
Let me revisit later today and see if I can better explain the issue
here and/or come up with a proper fix.
Can you review 'net: add MV88E61xx DSA driver' for me?
> The whole thing with eth_phy_get_mdio_bus()/eth_phy_set_mdio_bus() has
> me so confused that I am not really following along anymore.
>
I'm pretty confused at CONFIG_DM_ETH_PHY as well. I think that got
added where dm_mdio should have been added instead. see commit
5fe419ef2a61 ("net: Add eth phy generic driver for shared MDIO").
I've added Ye and Peng to the list... maybe they could comment on why
dm_mdio wasn't a viable solution for sharing an mdio bus? Its only
used in for fec_mxc dwc_eth_qos which are only on IMX boards and
believe it was added for IMX8M boards. It's enabled in a whole slew of
imx defconfigs where most of them are likely not needed.
Tim
What I'm trying to accomplish here vs just simply using
dm_fec_bind_mdio(dev) and dm_eth_phy_connect(dev) is to provide a
fallback for the many users of fec_mxc that do not have a dt that
works with dm-mdio yet still have defconfig's that enable DM_MDIO.
Most of the users would not currently have an mdio subnode in the fec
node, nor have the required phy-mode 'and' phy-handle prop or
fixed-link subnode which would cause the dm_eth_phy_connect to fail.
Best Regards,
Tim
