From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: TJA1100 100Base-T1 PHY features via ethtool? Date: Mon, 13 Aug 2018 12:53:35 -0700 Message-ID: References: <20180813193509.v6qlt2vsez6kyhag@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org, kernel@pengutronix.de To: Michael Grzeschik , davem@davemloft.net Return-path: Received: from mail-qt0-f182.google.com ([209.85.216.182]:40298 "EHLO mail-qt0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728763AbeHMWhY (ORCPT ); Mon, 13 Aug 2018 18:37:24 -0400 Received: by mail-qt0-f182.google.com with SMTP id h4-v6so18764987qtj.7 for ; Mon, 13 Aug 2018 12:53:43 -0700 (PDT) In-Reply-To: <20180813193509.v6qlt2vsez6kyhag@pengutronix.de> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 08/13/2018 12:35 PM, Michael Grzeschik wrote: > Hi David, > > I use a special 100Base-T1 phy (NXP TJA1100 [1]) that has some features > like: > > - enabling/disabling test modes > - fault detection > - switching managed/autonomous mode > - signal quality indication > - ... > > I already implemented the support of the features with the > ethtool --get/set-phy-tunables features by adding ethtool_phy_tunables: > > ETHTOOL_PHY_TEST_MODE > ETHTOOL_PHY_FAULT_DETECTION > ETHTOOL_PHY_MANAGED_MODE > ETHTOOL_PHY_SIGNAL_QUALITY > > Before posting my series I wanted to ensure that this is the preferred > interface for those options. The tunable interface is there, but is very limited. A few months ago, I had started proposing an interface to support PHY test modes [1] (the standard IEEE 802.3 defined ones) but a lot of it should now be migrated to the work that Michal is doing on the conversion of ethtool to netlink [2]. [1]: https://lkml.org/lkml/2018/4/27/1172 [2]: https://www.spinics.net/lists/netdev/msg516233.html > > I found a series from 2016 [2] that implements the userspace part for > the loopback feature of some phys, that did not get mainline so far > which makes me wonder if ethtool is still the way to go. ethtool is being converted to netlink, and that will be a much more flexible interface to work with since it is basically easily extensible (unlike the current ethtool + ioctl approach). Back when the patches were proposed, we just had mild disagreement on the loopback terminology being used, and then nothing happened. > > [1] https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf > [2] https://www.spinics.net/lists/netdev/msg406614.html > > Thanks, > Michael > -- Florian