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

2013/7/30 Thomas Petazzoni [off-list ref]:

Dear Florian Fainelli,

On Tue, 30 Jul 2013 11:05:04 +0100, Florian Fainelli wrote:

quoted

quoted

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.

quoted

quoted

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.

quoted

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 :)

quoted

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.

quoted

quoted

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.

quoted

quoted

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