[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180319132633.GL4519@kwain>
Date: Mon, 19 Mar 2018 14:26:33 +0100
From: Antoine Tenart <antoine.tenart@...tlin.com>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Antoine Tenart <antoine.tenart@...tlin.com>,
Andrew Lunn <andrew@...n.ch>, davem@...emloft.net,
kishon@...com, gregory.clement@...tlin.com, jason@...edaemon.net,
sebastian.hesselbarth@...il.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
maxime.chevallier@...tlin.com, miquel.raynal@...tlin.com,
nadavh@...vell.com, stefanc@...vell.com, ymarkman@...vell.com,
mw@...ihalf.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface
to use in-band negotiation
Hi Russell,
On Mon, Mar 19, 2018 at 01:18:05PM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2018 at 02:10:09PM +0100, Antoine Tenart wrote:
> >
> > On 7k/8k you have the following scheme for 10G only interfaces:
> >
> > MAC -- Comphy -- PHY -- SFP cage -- ...
> >
> > Or
> >
> > MAC -- Comphy -- SFP cage -- ...
> >
> > The comphy provides serdes lanes, and can be configured in various
> > modes (SGMII, 2500SGMII, 10GKR...).
>
> Right - the correct mode is dependent on the SFP module plugged into
> the cage. Trying to describe this by ignoring the SFP cage isn't
> going to work out well for end-user functionality, though is fine if
> you're just hacking a configuration to test (which would not be
> suitable for mainline kernels!)
>
> As I've recently replied to Yan, this is a configuration I haven't
> tested yet, and it's entirely possible that phylink may need some
> tweaks for it.
>
> What you have is a very similar setup to what is on Clearfog with
> its SFP cage, where the SFP cage is connected directly to the
> Armada 388. That only has to deal with 2500base-X / 1000base-X /
> SGMII and not 10G.
>
> What I want is to avoid hacks as much as possible here - if there is
> a short-coming with SFP/phylink here, we need to address that
> properly.
OK. So the proper solution would be to properly describe the SFP cages
in the device tree (and check if phylink deals with it nicely).
I'll update the patches in this way.
Thanks for the feedback,
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists