From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: Link modes representation in phylib Date: Tue, 19 Jun 2018 17:21:55 +0200 Message-ID: <20180619152155.GC26796@lunn.ch> References: <20180618170224.321f8264@bootlin.com> <20180618154018.GB5865@lunn.ch> <20180619113053.11df78a2@bootlin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: davem@davemloft.net, Russell King - ARM Linux , Florian Fainelli , netdev , Antoine Tenart , "thomas.petazzoni@bootlin.com" , Gregory CLEMENT , Miquel Raynal To: Maxime Chevallier Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:36582 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965599AbeFSPV7 (ORCPT ); Tue, 19 Jun 2018 11:21:59 -0400 Content-Disposition: inline In-Reply-To: <20180619113053.11df78a2@bootlin.com> Sender: netdev-owner@vger.kernel.org List-ID: > 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