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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 12 Aug 2020 16:00:54 +0100
From:   Russell King - ARM Linux admin <>
To:     Marek BehĂșn <>
Cc:     Andrew Lunn <>,
        Maxime Chevallier <>,
        Baruch Siach <>,
        Chris Healy <>,
        Florian Fainelli <>,
Subject: Re: [PATCH RFC russell-king 3/4] net: phy: marvell10g: change
 MACTYPE according to phydev->interface

On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek BehĂșn wrote:
> There is another problem though: I think the PHY driver, when deciding
> whether to set MACTYPE from the XFI with rate matching mode to the
> 10GBASE-R/5GBASE-R/2500BASE-X/SGMII with AN mode, should check which
> modes the underlying MAC support.

I'm aware of that problem.  I have some experimental patches which add
PHY interface mode bitmaps to the MAC, PHY, and SFP module parsing
functions.  I have stumbled on some problems though - it's going to be
another API change (and people are already whinging about the phylink
API changing "too quickly", were too quickly seems to be defined as
once in three years), and in some cases, DSA, it's extremely hard to
work out how to properly set such a bitmap due to DSA's layered

Having bitmaps means that we can take the union of what the MAC and
PHY supports, and decide which MACTYPE setting would be most suitable.
However, to do that we're into also changing phylib's interfaces as

> driver to phylink in the call to phylink_create. But there is no way
> for the PHY driver to get this information from phylink currently, and
> even if phylink exposed a function to return the config member of
> struct phylink, the problem is that at the time when mv3310_power_up is
> called, the phydev->phylink is not yet set (this is done in
> phylink_bringup_phy, and mv3310_power_up is called sometime in the
> phylink_attach_phy).

We _really_ do not want phylib calling back into phylink functions.
That would tie phylink functionality into phylib and cause problems
when phylink is not being used.

I would prefer phylib to be passed "the MAC can use these interface
types, and would prefer to use this interface type" and have the
phylib layer (along with the phylib driver) make the decision about
which mode should be used.  That also means that non-phylink MACs
can also use it.

RMK's Patch system:
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists