On Tue, Jul 25, 2017 at 3:22 AM, Mario Six <[email protected]> wrote: > Hi Simon, > > On Tue, Jul 18, 2017 at 4:01 PM, Simon Glass <[email protected]> wrote: >> Hi Mario, >> >> On 14 July 2017 at 05:54, Mario Six <[email protected]> wrote: >>> From: Dirk Eibach <[email protected]> >>> >>> Implement support for the Marvell Alaska X 88X2242P Integrated Dual-port >>> and Quad-port Multi-speed Ethernet Transceivers. >>> >>> Signed-off-by: Dirk Eibach <[email protected]> >>> Signed-off-by: Mario Six <[email protected]> >>> --- >>> >>> 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. I don't think the generic-phy is appropriate. Quite unrelated to Ethernet phys. > >> Regards, >> Simon > > Best regards, > > Mario > _______________________________________________ > U-Boot mailing list > [email protected] > https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
