[PATCH 3/3] ARM: zynq: DT: Add Ethernet phys

[Florian Fainelli]

On 08/29/2014 04:22 PM, Jason Gunthorpe wrote:
> On Fri, Aug 29, 2014 at 11:23:57AM -0700, Florian Fainelli wrote:
>> On 08/29/2014 10:31 AM, Jason Gunthorpe wrote:
>>> On Fri, Aug 29, 2014 at 08:35:36AM -0700, Sören Brinkmann wrote:
>>>
>>>> The compatible string is listed as optional property for PHYs. So, not
>>>> having one is an option, I guess. But, I'd also prefer to at least keep
>>>> the -c22 one, since I saw problems when I tried using -c45 (the Zed phy
>>>> should support it...).
>>>
>>> -c45 and -c22 use a completely different MDIO protocol, Zed doesn't
>>> have a 10GE port, so it certainly doesn't use -c45.
>>
>> Most recent 1GbE PHYs should also implement clause 45. It is a nice
>> improvement if you are using lot of transactions, otherwise clause 45
>> over clause 22 is suitable and supported by the PHY library (for EEE in
>> particular).
> 
> Oh, that is interesting, I haven't actually seen one of those yet..
> 
> Hum. So that is messy, even if the Zed phy supports the C45 format,
> the macb driver (and by my reading, the Zynq hardware) lacks the
> capability to generate C45 frames.

We should restrict ourselves to clause 45 over clause 22 compatibility
mode, which requires no MDIO bus driver changes.

> 
> It could be supported, but you'd have to use the GPIO bitbang MDIO
> driver to talk to the phy.
> 
> So... that makes the compatible string for the phy even more
> confusing. 'Describe The HW' says it should have both c22 and c45
> listed - however we don't have software support in Linux to negotiate
> c22 and c45 support between the phy bus driver and attached phy :(

Right now, if you set the c45 compatible string, the MDIO bus driver and
the PHY must support native c45 transactions to set phydev->is_c45, if
one or the other, or neither of those work, we will fallback to c22.

The part that is not figured out properly yet is how do we want to
handle functions (e.g: EEE) that are only accessible using c45 (native
or in compatible mode), since the PHY library uses two pairs of
accessors, with the native accessors not falling back to the indirect
accessor...
--
Florian