[U-Boot] [PATCH 09/51] phy: Support Marvell 88X2242

[Joe Hershberger]

On Sun, Aug 6, 2017 at 12:16 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Joe,
>
> On 27 July 2017 at 15:23, Joe Hershberger <joe.hershberger at ni.com> wrote:
>> On Tue, Jul 25, 2017 at 3:22 AM, Mario Six <mario.six at gdsys.cc> wrote:
>>> Hi Simon,
>>>
>>> On Tue, Jul 18, 2017 at 4:01 PM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Mario,
>>>>
>>>> On 14 July 2017 at 05:54, Mario Six <mario.six at gdsys.cc> wrote:
>>>>> From: Dirk Eibach <dirk.eibach at 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.eibach at gdsys.cc>
>>>>> Signed-off-by: Mario Six <mario.six at 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.

Cheers,
-Joe