netdev - Re: [PATCH] net: macb: reject unsupported rgmii delays

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, 17 Jun 2020 13:52:01 +0200
From:   Helmut Grohne <helmut.grohne@...enta.de>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
CC:     Nicolas Ferre <nicolas.ferre@...rochip.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: macb: reject unsupported rgmii delays

On Wed, Jun 17, 2020 at 01:40:25PM +0200, Russell King - ARM Linux admin wrote:
> > For a fixed-link, the validation function is never called. Therefore, it
> > cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice.
> 
> Hmm, I'm not so sure, but then I don't know exactly what code you're
> using.  Looking at mainline, even for a fixed link, you call
> phylink_create().  phylink_create() will spot the fixed link, and
> parse the description, calling the validation function.  If that
> fails, it will generate a warning at that point:
> 
>   "fixed link %s duplex %dMbps not recognised"
> 
> It doesn't cause an operational failure, but it means that you end up
> with a zero supported mask, which is likely not expected.
> 
> This is not an expected situation, so I'll modify your claim to "it
> works but issues a warning" which still means that it's not correct.

I do see that warning. I agree with your correction of my claim. Thank
you for your attention to detail.

So we have two good reasons for not rejecting delay configuration in the
validation function now.

The remaining open question seems to be whether configuring a delay on a
MAC to MAC connection should cause a failure or a only warning. Do you
have an opinion on that?

All in-tree bindings of the driver seem to use rmii when they specify a
phy-mode.

Helmut