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: <YsXvk/GlFtswFyvk@shell.armlinux.org.uk>
Date:   Wed, 6 Jul 2022 21:24:51 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Hauke Mehrtens <hauke@...ke-m.de>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "David S. Miller" <davem@...emloft.net>,
        DENG Qingfang <dqfext@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        George McCollister <george.mccollister@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        Sean Wang <sean.wang@...iatek.com>,
        UNGLinuxDriver@...rochip.com,
        Vivien Didelot <vivien.didelot@...il.com>,
        Woojung Huh <woojung.huh@...rochip.com>
Subject: Re: [PATCH RFC net-next v2 0/5] net: dsa: always use phylink

On Wed, Jul 06, 2022 at 09:05:22PM +0200, Hauke Mehrtens wrote:
> On 7/6/22 18:27, Florian Fainelli wrote:
> > On 7/6/22 03:14, Vladimir Oltean wrote:
> > > Hi Florian,
> > > 
> > > On Tue, Jul 05, 2022 at 09:42:33AM -0700, Florian Fainelli wrote:
> > > > On 7/5/22 02:46, Russell King (Oracle) wrote:
> > > > > A new revision of the series which incorporates changes that Marek
> > > > > suggested. Specifically, the changes are:
> > > > > 
> > > > > 1. Patch 2 - use the phylink_get_caps method in mv88e6xxx to get the
> > > > >      default interface rather than re-using port_max_speed_mode()
> > > > > 
> > > > > 2. Patch 4 - if no default interface is provided, use the supported
> > > > >      interface mask to search for the first interface that gives the
> > > > >      fastest speed.
> > > > > 
> > > > > 3. Patch 5 - now also removes the port_max_speed_mode() method
> > > > 
> > > > This was tested with bcm_sf2.c and b53_srab.b and did not cause
> > > > regressions,
> > > > however we do have a 'fixed-link' property for the CPU port
> > > > (always have had
> > > > one), so there was no regression expected.
> > > 
> > > What about arch/arm/boot/dts/bcm47189-tenda-ac9.dts?
> > 
> > You found one of the devices that I do not have access to and did not
> > test, thanks. We do expect to run the port at 2GBits/sec on these
> > devices however there is no "official" way to advertise that a port can
> > run at 2Gbits/sec, as this is not even a "sanctioned" speed. I do have a
> > similar device however, so let me run some more tests, we won't see a
> > regression however since we do not use the NATP accelerator which would
> > be the reason to run the port at 2Gbits/sec.
> 
> I will try this change on some devices with the lantiq gswip driver at the
> weekend.
> 
> On the SoC supported by the lantiq gswip driver the switch is integrated in
> the SoC and there is a internal link with more than 1GBit/s connecting the
> switch to the rest of the system. I think it is also around 2GBit/s. We can
> not configure the interface speed or many other interface settings for the
> link between the switch and the CPU. How should the device tree ideally look
> for this setup?

I think this falls into Andrew's "don't specify anything" category,
which means that we should default to the maximum speed for the
port - which is in this case quite clearly fixed at whatever the
internal link actually is.

>From the get_caps() function, the fastest speed apparently supported is
1Gbps. I'm guessing the CPU port is one of ports 2..5 on xrx200 and
1..5 on xrx300 - in which case, PHY_INTERFACE_MODE_INTERNAL is likely
to be selected, which seems appropriate given what you've said above.
(PHY_INTERFACE_MODE_INTERNAL will be the first interface type found
that will give the highest speed as it permits any speed given in the
mac_capabilities.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ