linux-kernel - Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support for microchip lan937x

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:   Wed, 4 Aug 2021 02:54:01 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Prasanna Vengateshan <prasanna.vengateshan@...rochip.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        robh+dt@...nel.org, UNGLinuxDriver@...rochip.com,
        Woojung.Huh@...rochip.com, hkallweit1@...il.com,
        linux@...linux.org.uk, davem@...emloft.net, kuba@...nel.org,
        linux-kernel@...r.kernel.org, vivien.didelot@...il.com,
        f.fainelli@...il.com, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support
 for microchip lan937x

On Tue, Aug 03, 2021 at 10:24:27PM +0530, Prasanna Vengateshan wrote:
> Thanks Vladimir & Andrew for the right pointers and info. The thread talks about
> "rgmii-*" are going to be applied by the PHY only as per the doc. For fixed-
> link, MAC needs to add the delay. This fixed-link can be No-PHY or MAC-MAC or
> MAC to in-accessible PHY. In such case, i am not convinced in using rgmii-tx-
> delay-ps & rgmii-rx-delay-ps on the MAC side and apply delay. I still think
> proposed code in earlier mail thread should still be okay.

Why? I genuinely do not understand your reasoning

  - I read a thread that brings some arguments for which MACs should not
    add delays based on the delay type in the "rgmii-*" phy-mode string
    [ but based on explicit rgmii-tx-delay-ps and rgmii-rx-delay-ps
    properties under the MAC OF node; this is written in the same
    message as the quote that you chose ]

  - I acknowledge that in certain configurations I need the MAC to apply
    internal delays.

  => I disagree that I should parse the rgmii-tx-delay-ps and
     rgmii-rx-delay-ps OF properties of the MAC, just apply RGMII delays
     based on the "rgmii-*" phy-mode string value, when I am a DSA CPU
     port and in no other circumstance

?!

I mean, feel free to feel convinced or not, but you have not actually
brought any argument to the table here, or I'm not seeing it.

Anyway, I don't believe that whatever you decide to do with the RGMII
delays is likely to be a decisive factor in whether the patches are
accepted or not, considering the fact that traditionally, everyone did
what suited their board best and that's about it; I will stop pushing back.

I have a theory that all the RGMII setups driven by the Linux PHY
library cannot all work at the same time, with the same code base.
Someone will sooner or later come and change a driver to make it do what
they need, which will break what the original author intended, which
will then be again patched, which will again break ..., which ....

If a perpetual motion device will ever be built by mankind, I am sure it
will be powered by RGMII delays.