[RFC PATCH 1/3] of: provide a binding for the 'fixed-link' property

[Florian Fainelli]

2013/7/30 Thomas Petazzoni <thomas.petazzoni at free-electrons.com>:
> Dear Florian Fainelli,
>
> On Tue, 30 Jul 2013 11:05:04 +0100, Florian Fainelli wrote:
>
>> > In fact, this value is used for two things:
>> >
>> >  * As the PHY address on the fake "fixed" MDIO bus.
>> >
>> >  * As the PHY identifier, as reported by the MII registers PHYS_ID1
>> >    (0x2) and PHYS_ID2 (0x3).
>>
>> Right, so I would start with disambiguating the two and just forget
>> about PHYS_ID1 and PHYS_ID2 for the moment since they probably do not
>> need to be per-PHY configurable.
>
> Agreed.
>
>> > I think this doesn't make sense, because the two things are completely
>> > unrelated. Ideally, we'd like the PHY identifier for fixed PHYs to be
>> > something fixed, identical for all fixed PHYs. The problem is finding
>> > an OUI and device number that is available for that, but maybe we can
>> > ask the OpenMoko people to allocate one (see
>> > http://wiki.openmoko.org/wiki/OUI).
>>
>> Well that would be ideal indeed, but I am wondering if we cannot just
>> go with some kind of magic value here anyway, regardless of
>> allocations since this is not a real hardware device.
>
> Well, isn't that exactly what I'm proposing? Have a fixed value for
> PHYS_ID1 and PHYS_ID2, that is used for /all/ fixed PHYs.
>
>> How about the Linux Foundation?
>
> I am concerned about the time it would take to get a new OUI
> attributed. The OpenMoko OUI is said to be open for free and open
> source projects, I think the Linux kernel qualifies :)
>
>> Is not that the same problem as with gadget USB
>> devices which should have some sort of real MAC address for instance?
>
> They are either provided by the user or generated randomly, as far as I
> can see.
>
>> > Then, the PHY address could be generated dynamically. This would
>> > require:
>> >
>> >  * Adding a fixed_phy_create() function that internally uses
>> >    fixed_phy_add(), but before that creates an unique PHY address for
>> >    this newly created PHY. Those unique addresses will be generated by
>> >    incrementing a global number of fixed PHYs, up to PHY_MAX_ADDR,
>> >    which is the maximum number of fixed PHYs that can anyway be
>> >    registered on the fixed MDIO bus.
>>
>> Even though these are purely software PHY implementations, I believe
>> that some sort of predictability would be welcome, so I would just use
>> the phy_id argument passed to fixed_phy_add() as the address on the
>> fixed MDIO bus like it is today.
>
> Well, the whole starting point of this discussion is precisely that
> both Grant and Mark disliked this phy ID that had to be globally
> unique, and they wanted it to be dynamically allocated by the kernel,
> because the DT shouldn't have to care about such internal details.

Ok, well, thinking about this some more, we do not need to be able to
specify the fixed PHY fake MDIO address in the binding anyway. My
concern was first with how to ensure that this would be relatively
stable from an Ethernet driver and user-space perspective, but this
will be stable if we allocate unique IDs in say, parsing/probing order
anyway.

>
>> > Grant, Mark, Florian, do you have other proposals?
>>
>> To sum up, let's just forget about the misuse of phy_id to fill in
>> PHYS_ID1 and PHYS_ID2 registers and keep the existing code with a
>> clear note that phy_id means the "PHY address on the fixed MDIO bus".
>
> Except that Grant and Mark point was precisely that the "PHY address on
> the fake MDIO bus" is not a description of the hardware, and therefore
> shouldn't be mentioned in the Device Tree but instead taken care of by
> the kernel itself.

Right, that works for me now.
--
Florian