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]

Message-ID: <Y6m7eNdWVL3IKFj2@lunn.ch>
Date:   Mon, 26 Dec 2022 16:19:20 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Biao Huang (黄彪) <Biao.Huang@...iatek.com>
Cc:     "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peppe.cavallaro@...com" <peppe.cavallaro@...com>,
        "joabreu@...opsys.com" <joabreu@...opsys.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "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

> 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.

    Andrew