linux-kernel - Re: [RFC PATCH v2 8/8] arm64: dts: sparx5: Add the Sparx5 switch node

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, 23 Dec 2020 16:49:34 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Steen Hegelund <steen.hegelund@...rochip.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Device Tree List <devicetree@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Lars Povlsen <lars.povlsen@...rochip.com>,
        Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Mark Einon <mark.einon@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Arnd Bergmann <arnd@...db.de>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v2 8/8] arm64: dts: sparx5: Add the Sparx5 switch node

On Wed, Dec 23, 2020 at 03:31:24PM +0100, Steen Hegelund wrote:
> On 19.12.2020 21:24, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > > +             port13: port@13 {
> > > +                     reg = <13>;
> > > +                     /* Example: CU SFP, 1G speed */
> > > +                     max-speed = <10000>;
> > 
> > One too many 0's for 1G.
> 
> Ah, but this is allocation for the port, not the speed.

phylib will look for this property and change what the PHY advertises
based on this. There are some devices with Fast Ethernet but with a 1G
PHY, because they are cheaper. By setting max-speed=<100>; phylib will
stop the PHY advertising 1000Base-T/Full and 1000Base-T/Half. I can
imaging the same is used when the MAC can do 2.5G, but the PHY is 5G
capable, etc.

> This just used by the calendar module to allocate slots on the taxis
> as requested.  So I would say it is OK to overallocate in this case
> (but you could argue it does not make much sense).

Rather than misusing the max-speed property, it would be better to add
a property with your specific meaning.

  Andrew