[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180619152155.GC26796@lunn.ch>
Date: Tue, 19 Jun 2018 17:21:55 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: davem@...emloft.net,
Russell King - ARM Linux <linux@...linux.org.uk>,
Florian Fainelli <f.fainelli@...il.com>,
netdev <netdev@...r.kernel.org>,
Antoine Tenart <antoine.tenart@...tlin.com>,
"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
Gregory CLEMENT <gregory.clement@...tlin.com>,
Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Re: Link modes representation in phylib
> 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.
Hi Maxime
You can do this conversion in the core. If features == 0, and some
bits are set in the features link_mode, do the conversion at probe
time. The same can be done for lp_advertising, when the call into the
drivers read_status() has completed.
> Would that be acceptable ?
It sounds reasonable. Lets see what the code looks like.
Andrew
Powered by blists - more mailing lists