On Tue, Dec 10, 2013 at 1:39 PM, Jason Gunthorpe
<[email protected]> wrote:
> This describes a compatible entry of the form:
> ethernet-phy-idAAAA,BBBB
> Which is modelled after the PCI structured compatible entry
> (pciVVVV,DDDD.SSSS.ssss.RR)
>
> If present the OF core will be able to use this information to
> directly create the correct phy without auto probing the bus.
>
> Signed-off-by: Jason Gunthorpe <[email protected]>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> Patch to parse this compatible string to follow if this binding is
> acceptable.
One minor comment below, otherwise:
Acked-by: Rob Herring <[email protected]>
> Please see
>
> http://www.spinics.net/lists/devicetree/msg13175.html
>
> For discussion and a conceptual parsing patch.
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index 7cd18fb..d70b535 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -23,10 +23,18 @@ Optional Properties:
> assume clause 22. The compatible list may also contain other
> elements.
>
> + If the phy's identifier is known then the list may contain an entry
> + of the form: "ethernet-phy-idAAAA,BBBB" where
I think this should be a period rather than a comma as we are not
separating a vendor ID from product ID.
Rob
On Wed, Jan 08, 2014 at 12:37:03PM -0600, Rob Herring wrote:
> > Patch to parse this compatible string to follow if this binding is
> > acceptable.
>
> One minor comment below, otherwise:
>
> Acked-by: Rob Herring <[email protected]>
K, I'll send a series hopefully in a few weeks after some travel.
> > + If the phy's identifier is known then the list may contain an entry
> > + of the form: "ethernet-phy-idAAAA,BBBB" where
>
> I think this should be a period rather than a comma as we are not
> separating a vendor ID from product ID.
OK, that makes sense.
Inspecting further, the format of the 32 bit AAAABBBB is actually
broken out into:
OUI[3:18] || OUI[19:24] || MODEL[5:0] || REV[3:0]
So a possible choice with the 'vendor ID,product ID' split is:
ethernet-phyOOOOO,MM.R
xlate is:
AAAABBBB = ((OOOOO >> 6) << 16) |
((OOOOO & 0x3f) << 10) |
(MM << 4) |
R
Which doesn't textually match the register value, or any other
phy ID constants in the kernel, however makes more sense from the
'vendor ID,product ID' angle.
Eg a Marvell 88E1310 would encode into the two options as:
ethernet-phy05043,29.0
ethernet-phy-id0141.0e90
And the kernel has constants like this:
include/linux/marvell_phy.h:#define MARVELL_PHY_ID_88E1318S 0x01410e90
In light of this detail do you still like 'ethernet-phy-id0141.0e90' ?
Thanks,
Jason
On Wed, Jan 8, 2014 at 3:16 PM, Jason Gunthorpe
<[email protected]> wrote:
> On Wed, Jan 08, 2014 at 12:37:03PM -0600, Rob Herring wrote:
>
>> > Patch to parse this compatible string to follow if this binding is
>> > acceptable.
>>
>> One minor comment below, otherwise:
>>
>> Acked-by: Rob Herring <[email protected]>
>
> K, I'll send a series hopefully in a few weeks after some travel.
>
>> > + If the phy's identifier is known then the list may contain an entry
>> > + of the form: "ethernet-phy-idAAAA,BBBB" where
>>
>> I think this should be a period rather than a comma as we are not
>> separating a vendor ID from product ID.
>
> OK, that makes sense.
>
> Inspecting further, the format of the 32 bit AAAABBBB is actually
> broken out into:
> OUI[3:18] || OUI[19:24] || MODEL[5:0] || REV[3:0]
>
> So a possible choice with the 'vendor ID,product ID' split is:
> ethernet-phyOOOOO,MM.R
>
> xlate is:
>
> AAAABBBB = ((OOOOO >> 6) << 16) |
> ((OOOOO & 0x3f) << 10) |
> (MM << 4) |
> R
>
> Which doesn't textually match the register value, or any other
> phy ID constants in the kernel, however makes more sense from the
> 'vendor ID,product ID' angle.
>
> Eg a Marvell 88E1310 would encode into the two options as:
> ethernet-phy05043,29.0
> ethernet-phy-id0141.0e90
>
> And the kernel has constants like this:
> include/linux/marvell_phy.h:#define MARVELL_PHY_ID_88E1318S 0x01410e90
>
> In light of this detail do you still like 'ethernet-phy-id0141.0e90' ?
I'm fine either way. Separating out the OUI had crossed my mind. That
probably does make the value in the DT more meaningful. Is the OUI
used anywhere in the kernel?
Rob