[U-Boot] [PATCH v4 4/5] doc: bindings: add mdio-handle property to ethernet nodes

[Grygorii Strashko]

On 19/11/2019 01:31, Alexandru Marginean wrote:
> 
> On 11/18/2019 8:11 PM, Grygorii Strashko wrote:
>>
>>
>> On 14/11/2019 17:04, Alex Marginean wrote:
>>> Adds an optional mdio-handle property which identifies a MDIO bus which can
>>> be scanned to find the relevant PHY.  The property is ignored if phy-handle
>>> is also present.
>>>
>>> Signed-off-by: Alex Marginean <alexandru.marginean at nxp.com>
>>> ---
>>>   doc/device-tree-bindings/net/ethernet.txt | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/doc/device-tree-bindings/net/ethernet.txt b/doc/device-tree-bindings/net/ethernet.txt
>>> index 3fc360523b..9f9629f8d6 100644
>>> --- a/doc/device-tree-bindings/net/ethernet.txt
>>> +++ b/doc/device-tree-bindings/net/ethernet.txt
>>> @@ -9,6 +9,8 @@ The following properties are common to the Ethernet controllers:
>>>   - max-speed: number, specifies maximum speed in Mbit/s supported by the device;
>>>   - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
>>>     the maximum frame size (there's contradiction in ePAPR).
>>> +- mdio-handle: phandle, specifies a reference to a MDIO bus to be scanned to
>>> +  find the PHY device.  Ignored if phy-handle is also present.
>>
>> Sry, but it looks redundant. The Ethernet-controller bindings
>> expects to use phy-handle which, in turn, allows to get MDIO node.
> 
> The problem I'm trying to solve is not that I don't want to get the
> parent MDIO bus of a PHY referenced though phy-handle, but rather that I
> want to avoid having a specific U-Boot DT for each PHY plug-in card that
> could be used in our systems.  I'll explain that in more detail.
> 
> We have these QDS systems which support plug-in cards with PHYs on them.
> The way it works is that a given ethernet interface is associated with
> one of the QDS slots that should contain a plug-in card.  Each of the
> slots has a MDIO bus associated with it, this bus is accessed through a
> MDIO MUX on the QDS board.
> The slot may be populated with one of several types of cards, which
> are different designs, have different types of PHYs and more importantly
> use different PHY addresses on the MDIO bus.
> 
> So now the summary is that an Ethernet interface is associated with a
> MDIO bus that could be scanned to find the relevant PHY, while using the
> existing phy-handle binding requires that U-Boot DT is edited whenever
> a different card is plugged in, which is not practical and avoidable.

Thank you for explanation. It's clear now.
I think above description is good to have as part of commit message.

> 
>>
>> So, if your platform is DT based and can use DT then it's reasonable to follow standard binding,
>> which, in addition, allows to specify Ethernet PHY properties.
> 
> Sure, and we do that on boards and for PHYs which are at fixed addresses
> on MDIO bus, but that is impractical with the swappable cards.
> 
>> More over, your series does not provide user for this new property.
> 
> That's true, I was planning to send the QDS DT after this was merged,
> but if it helps I can add it to this patch set.
> 
> Alex
> 
>> Personally I do not see even reasons to have doc/device-tree-bindings/net/ethernet.txt in u-boot
>> and think we should follow [1]
>>
>>>   - phy-mode: string, operation mode of the PHY interface; supported values are
>>>     "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
>>>     "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto
>>>
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/ethernet-controller.yaml
>>

-- 
Best regards,
grygorii