lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 21 Aug 2017 12:54:40 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     icenowy@...c.io
Cc:     Andrew Lunn <andrew@...n.ch>, Rob Herring <robh+dt@...nel.org>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-sunxi@...glegroups.com, Icenowy Zheng <icenowy@...c.xyz>
Subject: Re: [linux-sunxi] Re: [PATCH 2/4] dt-bindings: add binding for
 RTL8211E Ethernet PHY

On 08/21/2017 07:53 AM, icenowy@...c.io wrote:
> 在 2017-05-05 02:29,Florian Fainelli 写道:
>> On 05/04/2017 11:26 AM, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年5月5日 GMT+08:00 上午2:21:29, Florian Fainelli
>>> <f.fainelli@...il.com> 写到:
>>>> On 05/04/2017 11:10 AM, icenowy@...c.io wrote:
>>>>> 在 2017-04-22 08:22,Florian Fainelli 写道:
>>>>>> On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
>>>>>>> From: Icenowy Zheng <icenowy@...c.xyz>
>>>>>>>
>>>>>>> Some RTL8211E Ethernet PHY have an issue that needs a workaround
>>>>>>> indicated with device tree.
>>>>>>>
>>>>>>> Add the binding for a property that indicates this workaround.
>>>>>>>
>>>>>>> Signed-off-by: Icenowy Zheng <icenowy@...c.xyz>
>>>>>>> ---
>>>>>>>  .../devicetree/bindings/net/realtek,rtl8211e.txt   | 22
>>>>>>> ++++++++++++++++++++++
>>>>>>>  1 file changed, 22 insertions(+)
>>>>>>>  create mode 100644
>>>>>>> Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>> b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..c1913301bfe8
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>> @@ -0,0 +1,22 @@
>>>>>>> +Realtek RTL8211E Ethernet PHY
>>>>>>> +
>>>>>>> +One batch of RTL8211E is slight broken, that needs some special
>>>> (and
>>>>>>> +full of magic numbers) tweaking in order to make GbE to operate
>>>>>>> properly.
>>>>>>> +The only well-known board that used the broken batch is Pine64+.
>>>>>>> +Configure it through an Ethernet OF device node.
>>>>>>> +
>>>>>>> +Optional properties:
>>>>>>> +
>>>>>>> +- realtek,disable-rx-delay:
>>>>>>> +  If set, RX delay will be completely disabled (according to
>>>>>>> Realtek). This
>>>>>>> +  will affect the performance on non-broken boards.
>>>>>>> +  default: do not disable RX delay.
>>>>>>
>>>>>> Please don't introduce custom properties to do that, instead correct
>>>>>> specify the "phy-mode" such that it is e.g: "rgmii-txid" which
>>>> indicates
>>>>>> that there should be no RX internal delay, but a TX internal delay
>>>> added
>>>>>> by the PHY.
>>>>>
>>>>> Checked the document, the meaning of "rgmii-txid" is not correct
>>>> here.
>>>>>
>>>>> This doesn't effect the MAC, and the MAC should still add TX delay.
>>>>>
>>>>> The definition of "rgmii-txid" in
>>>>> Documentation/devicetree/binding/net/ethernet.txt is "RGMII with
>>>>> internal TX delay provided by the PHY, the MAC should not add an TX
>>>> delay
>>>>> in this case". However, this do not indicate that the MAC doesn't add
>>>> TX
>>>>> delay; in fact that just totally disabled the PHY to provide the RX
>>>> delay.
>>>>> MAC still should to add delay on both TX/RX, which is the semantic of
>>>>> standard "rgmii".
>>>>>
>>>>> So I cannot used "rgmii-txid" here, but should continue to use this
>>>>> custom property.
> 
> Sorry for replying an old email, but it's because the driver of the MAC I
> used is merged (dwmac-sun8i).
> 
> The driver of the MAC currently only supports "mii", "rmii", and "rgmii",
> and according to the SoC's user manual, the MAC cannot has its delays
> disabled.
> 
> How should it handle this "rgmii-txid" here? Just treat it as "rgmii"?

Considering there are no configurable delays on the MAC side, all you
can do is treat all RGMII variants the same by configuring the MAC for
RGMII mode (with no additional capabilities and as opposed to MII, RMII
which are other clocking/data pins modes) and let the PHY configure the
delay accordingly based on "phy-mode"/phy_interface_t. You can use
phy_interface_is_rgmii() as a helper function to cover all 4 variants.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ