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:   Tue, 3 Mar 2020 13:44:53 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Oleksij Rempel <o.rempel@...gutronix.de>, mkl@...gutronix.de,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>, kernel@...gutronix.de,
        netdev <netdev@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>, david@...tonic.nl,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v1] net: dsa: sja1105: add 100baseT1_Full support

On Tue, Mar 03, 2020 at 12:04:04PM +0200, Vladimir Oltean wrote:
> On Tue, 3 Mar 2020 at 09:44, Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> >
> > Validate 100baseT1_Full to make this driver work with TJA1102 PHY.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
> > ---
> 
> I was expecting this patch sooner or later.
> 
> Acked-by: Vladimir Oltean <olteanv@...il.com>
> 
> I should take this opportunity and express the fact that it is strange
> for MAC drivers to have to sign off all possible copper and fiber
> media types in their .phylink_validate method. Sooner or later
> somebody is going to want to add 1000Base-T1 too. I don't think it is
> going to scale very well. Russell, with your plan to make MAC drivers
> just populate a bitmap of phy_modes (MII side), is it also going to
> get rid of media side validation?

You're touching on a concern I've had for some time that the link modes
mix together several different parameters: speed, duplex, and media.

What we actually want for a MAC is to know which speeds and duplexes
they support for each interface mode, and then translate that to the
ethtool link modes as appropriate.  That isn't a problem I've addressed
yet, but something that could be addressed.

I've just updated my net-queue with a bunch of stuff that's been
sitting in other branches (some published, some not), which includes
the PHY_INTERFACE_MODE bitmap changes - everything from and including
"net: mvpp2: add port support helpers" concerns the bitmap stuff.

At the moment, it has to support both the new bitmap solution and the
legacy solution, but hopefully in time we can drop the legacy solution.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Powered by blists - more mailing lists