Hi Joe, On 7 August 2017 at 10:37, Joe Hershberger <joe.hershber...@gmail.com> wrote: > On Sun, Aug 6, 2017 at 12:16 AM, Simon Glass <s...@chromium.org> wrote: >> Hi Joe, >> >> On 27 July 2017 at 15:23, Joe Hershberger <joe.hershber...@ni.com> wrote: >>> On Tue, Jul 25, 2017 at 3:22 AM, Mario Six <mario....@gdsys.cc> wrote: >>>> Hi Simon, >>>> >>>> On Tue, Jul 18, 2017 at 4:01 PM, Simon Glass <s...@chromium.org> wrote: >>>>> Hi Mario, >>>>> >>>>> On 14 July 2017 at 05:54, Mario Six <mario....@gdsys.cc> wrote: >>>>>> From: Dirk Eibach <dirk.eib...@gdsys.cc> >>>>>> >>>>>> Implement support for the Marvell Alaska X 88X2242P Integrated Dual-port >>>>>> and Quad-port Multi-speed Ethernet Transceivers. >>>>>> >>>>>> Signed-off-by: Dirk Eibach <dirk.eib...@gdsys.cc> >>>>>> Signed-off-by: Mario Six <mario....@gdsys.cc> >>>>>> --- >>>>>> >>>>>> drivers/net/phy/Kconfig | 67 ++++ >>>>>> drivers/net/phy/Makefile | 1 + >>>>>> drivers/net/phy/marvell.c | 1 - >>>>>> drivers/net/phy/mv88x2.c | 846 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> drivers/net/phy/mv88x2.h | 12 + >>>>>> drivers/net/phy/phy.c | 3 + >>>>>> include/phy.h | 1 + >>>>>> 7 files changed, 930 insertions(+), 1 deletion(-) >>>>>> create mode 100644 drivers/net/phy/mv88x2.c >>>>>> create mode 100644 drivers/net/phy/mv88x2.h >>>>>> >>>>> >>>>> We should really be using driver model here. Is the generic phy uclass >>>>> good enough (generic-phy.h), or do we need a new uclass for Ethernet >>>>> PHY? >>>>> >>>> >>>> Wouldn't we also need a uclass for MDIO/MII interfaces then? I don't know >>>> the >>>> network subsystem too well, so I can't really tell where a ethernet phy >>>> uclass >>>> (or a MDIO uclass for that matter) would interface with the rest of it. >>> >>> The reason I've avoided implementing the uclass for phys so far is >>> that the DTs of various boards are quite different in how they relate >>> MDIO, PHY, and ETH. I suspect we'll end up needing some sort of ETH / >>> platform / board specific DT parsing code and some way to hook into >>> that. >>> >> >> Do you mean that we cannot have plain PHY driver (e.g. for MII) that >> works with multiple bords? Don't we have something similar already? >> What can we do to move this forward. > > I think the driver is not the issue. If we want to be able to leverage > the same DT bindings that Linux does, then it's not going to be > generic. How the MDIO driver is associated to an ETH driver and how > that ETH driver is associated with a PHY driver will all be unique to > each ETH driver. By that I mean the drivers can be shared for the > PHYs, but how they are bound will be unique. We can't have global PHY > binding code in the PHY uclass. > > Do we do something like this elsewhere? Maybe in PCI or something? I > haven't gone looking so far.
Yes. That seems fine to me. We already do that in some other cases (e.g. USB and PCI devices are detected at run-time and devices bound accordingly). How can we get started on this? > > Cheers, > -Joe Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
