All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
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>
Subject: Re: Link modes representation in phylib
Date: Tue, 19 Jun 2018 11:30:53 +0200	[thread overview]
Message-ID: <20180619113053.11df78a2@bootlin.com> (raw)
In-Reply-To: <20180618154018.GB5865@lunn.ch>

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

  reply	other threads:[~2018-06-19  9:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 15:02 Link modes representation in phylib Maxime Chevallier
2018-06-18 15:40 ` Andrew Lunn
2018-06-19  9:30   ` Maxime Chevallier [this message]
2018-06-19 15:21     ` Andrew Lunn
2018-06-29 13:26       ` Maxime Chevallier
2018-06-29 13:43         ` Andrew Lunn
2018-06-29 15:09           ` Maxime Chevallier
2018-06-29 15:34             ` Andrew Lunn
2018-06-29 15:39               ` Maxime Chevallier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180619113053.11df78a2@bootlin.com \
    --to=maxime.chevallier@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=antoine.tenart@bootlin.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=gregory.clement@bootlin.com \
    --cc=linux@armlinux.org.uk \
    --cc=miquel.raynal@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.