From mboxrd@z Thu Jan  1 00:00:00 1970
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Subject: Re: Link modes representation in phylib
Date: Tue, 19 Jun 2018 11:30:53 +0200
Message-ID: <20180619113053.11df78a2@bootlin.com>
References: <20180618170224.321f8264@bootlin.com>
        <20180618154018.GB5865@lunn.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: davem@davemloft.net,
        Russell King - ARM Linux <linux@armlinux.org.uk>,
        Florian Fainelli <f.fainelli@gmail.com>,
        netdev <netdev@vger.kernel.org>,
        Antoine Tenart <antoine.tenart@bootlin.com>,
        "thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
        Gregory CLEMENT <gregory.clement@bootlin.com>,
        Miquel Raynal <miquel.raynal@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail.bootlin.com ([62.4.15.54]:37773 "EHLO mail.bootlin.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S937215AbeFSJbF (ORCPT <rfc822;netdev@vger.kernel.org>);
        Tue, 19 Jun 2018 05:31:05 -0400
In-Reply-To: <20180618154018.GB5865@lunn.ch>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Hello Andrew,

Thanks for your feedback !

>> I'm currently working on adding support for 2.5GBaseT on some Marvell
>> PHYs (the marvell10g family, including the 88X3310).
>> 
>> However, phylib doesn't quite support these modes yet. Its stores the
>> different supported and advertised modes in u32 fields, which can't
>> contain the relevant values for 2500BaseT mode (and all other modes that
>> come after the 31st one).  
>
>Hi Maxime
>
>Did you look at phylink? I think it already gets this right.  It could
>be, any MAC which needs to use > bit 31 should use phylink, not
>phylib.

Indeed, drivers that use phylink dont directly access these u32 fields.

>That narrows the problem down to just the PHY drivers. We might be
>able to mass convert those. Or maybe we can consider just doing some
>conversion work on PHYs which support > 1Gbps?

I think that we can consider converting only the concerned PHYs for the
moment.

What I propose is that we add 3 link_mode fields in phy_device, and keep
the legacy fields for now. It would be up to the driver to fill the new
"supported" field in config_init, kind of like what's done in the
marvell10g driver.

There already are phy_ethtool_ksettings_{g|s}et accessors, that are
used by phylink so that would easily integrate with the above solution
of only supporting phylink for these modes.

That would involve a bit of info duplication, but I think that would
allow for a smooth transition to a newer representation.

Would that be acceptable ?

Thanks,

Maxime