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

[Simon Glass]

Hi Joe,

On 7 August 2017 at 10:37, Joe Hershberger <joe.hershberger at gmail.com> wrote:
> 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.

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