linux-kernel - Re: [PATCH v5 1/2] stmmac: dwmac-mediatek: enable 2ns delay only for special cases

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:   Tue, 27 Dec 2022 07:09:11 +0000
From:   Biao Huang (黄彪) <Biao.Huang@...iatek.com>
To:     "andrew@...n.ch" <andrew@...n.ch>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "peppe.cavallaro@...com" <peppe.cavallaro@...com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "joabreu@...opsys.com" <joabreu@...opsys.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "alexandre.torgue@...s.st.com" <alexandre.torgue@...s.st.com>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        Macpaul Lin (林智斌) 
        <Macpaul.Lin@...iatek.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v5 1/2] stmmac: dwmac-mediatek: enable 2ns delay only for
 special cases

Dear Andrew,
	Thanks for your comments~

On Mon, 2022-12-26 at 16:19 +0100, Andrew Lunn wrote:
> > We don't want to restrict phy-mode to rgmii-id only, so I don't
> > think
> > we need mask RXID bit, then, User can use rgmii-rxid/-txid/-id as
> > their
> > will.
> 
> The phy-mode is a property of the board. It describes what delays are
> required, in addition to what the board itself provides via extra
> long
> lines. As such, there is no choice, it is set by physics.
> 
> How you implement those delays is then up to the MAC and PHY. 95% of
> all MAC drivers simply pass phy-mode to the PHY and let the PHY add
> the delays. The Renesas MAC driver is one of the exceptions, it often
> adds the delays, and then passes a different phy-mode to the PHY in
> order that there are not double delays.
> 
> So you can be different to everybody else, have MAC do one delay, and
> the PHY do the other. Just be aware that nobody else does this, no DT
> developers will expect it, etc.
> 
> Or you can just do what everybody else does and let the PHY add the
> delays.
> 
> What some MACs do is implement rx-internal-delay-ps and
> tx-internal-delay-ps These allow fine tuning of the delays. These are
> expected to be small values, adding 10s or 100s of pico seconds. They
> are not expected to be 2000ps.
OK, as to this series, Is the following modification enough?
    1. phy-mode = rgmii-id;  in dts.
    2. remove the fix_mac_speed() in driver.
> 
>     Andrew
Best Regards!
Biao