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:   Sun, 17 Nov 2019 20:25:29 +0100
From:   Andrew Lunn <>
To:     Russell King - ARM Linux admin <>
Cc:     Florian Fainelli <>,
        Heiner Kallweit <>,
        "David S. Miller" <>,
Subject: Re: [PATCH net-next v2 3/3] net: phy: marvell10g: add SFP+ support

> The answer is... it depends.

Hi Russell

One issue we have had with phylink is people using the interfaces
wrongly. When asking this question, i was thinking about
documentation. Your answer suggests this method is not simply about
the validation you are doing here, it could also be about
configuration of the PHY to fit the module.

Maybe it would be good to add documentation somewhere about the range
of things this call can do?

> So, this patch reflects what can be done with the SFP+ slots on
> Macchiatobin boards today.

This all sounds very hardware dependent. So we are going to need some
more DT properties i guess. Have you thought about this?

Maybe we need to add compatibles sff,sfp+ and sff,sff+ ? Indicate the
board is capable of the higher speeds? And when sfp+/sff+ is used,
maybe a boolean to indicate it is also sff/sfp compatible?
sfp_select_interface() can then look at these properties and return
PHY_INTERFACE_MODE_NA if the board is not capable of supporting the

Would it even make sense to make the PHY interface more like the MAC
interface? A validate function to indicate what it is capable of? A
configure function to configure its mode towards the SFP?


Powered by blists - more mailing lists