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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 05 May 2017 02:26:48 +0800
From:   Icenowy Zheng <icenowy@...c.io>
To:     f.fainelli@...il.com, Florian Fainelli <f.fainelli@...il.com>
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



于 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.
>
>This is absolutely not a correct understanding. The 'phy-mode' property
>defines the contract between the MAC and PHY. It is defined from the
>PHY's perspective of the delay, which means that the MAC has to either
>also provide an adequate delay (RX or TX) or not (RX or TX). So if you
>specified 'phy-mode' = "rgmii" this means that the MAC needs to adds
>the
>TX and RX delay, so implcitly this means that your MAC operates in

The MAC doesn't lose its responsibility to tweak RX/TX delays with this property set.

This situation is that, the PHY's RX delay tweaking function is broken. But it doesn't mean that the PHY can take over *all* responsibility to tweak TX, it still needs MAC to tweak TX.

>"rgmii-id", if the property was defined from the perspective of the
>MAC,
>which it is not.
>
>Both the Ethernet PHY driver and the MAC driver need to take care of
>adjusting the delays based on the phydev->interface value.
>
>The property you are introducing here is absolutely not appropriate
>because it is entirely redundant with what 'phy-mode' already defines,
>except the latter also covers a lot more cases.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ