Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH net-next 0/1] Add BASE-T1 PHY support
To:     Christian Herber <christian.herber@nxp.com>,
        "davem@davemloft.net" <davem@davemloft.net>
Cc:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20190815153209.21529-1-christian.herber@nxp.com>
From:   Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <8c15b855-6947-9930-c3df-71a64fbff33b@gmail.com>
Date:   Fri, 16 Aug 2019 22:59:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190815153209.21529-1-christian.herber@nxp.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 15.08.2019 17:32, Christian Herber wrote:
> This patch adds basic support for BASE-T1 PHYs in the framework.
> BASE-T1 PHYs main area of application are automotive and industrial.
> BASE-T1 is standardized in IEEE 802.3, namely
> - IEEE 802.3bw: 100BASE-T1
> - IEEE 802.3bp 1000BASE-T1
> - IEEE 802.3cg: 10BASE-T1L and 10BASE-T1S
> 
> There are no products which contain BASE-T1 and consumer type PHYs like
> 1000BASE-T. However, devices exist which combine 100BASE-T1 and 1000BASE-T1
> PHYs with auto-negotiation.

Is this meant in a way that *currently* there are no PHY's combining Base-T1
with normal Base-T modes? Or are there reasons why this isn't possible in
general? I'm asking because we have PHY's combining copper and fiber, and e.g.
the mentioned Aquantia PHY that combines NBase-T with 1000Base-T2.

> 
> The intention of this patch is to make use of the existing Clause 45 functions.
> BASE-T1 adds some additional registers e.g. for aneg control, which follow a
> similiar register layout as the existing devices. The bits which are used in
> BASE-T1 specific registers are the same as in basic registers, thus the
> existing functions can be resued, with get_aneg_ctrl() selecting the correct
> register address.
> 
If Base-T1 can't be combined with other modes then at a first glance I see no
benefit in defining new registers e.g. for aneg control, and the standard ones
are unused. Why not using the standard registers? Can you shed some light on that?

Are the new registers internally shadowed to the standard location?
That's something I've seen on other PHY's: one register appears in different
places in different devices.

> The current version of ethtool has been prepared for 100/1000BASE-T1 and works
> with this patch. 10BASE-T1 needs to be added to ethtool.
> 
> Christian Herber (1):
>   Added BASE-T1 PHY support to PHY Subsystem
> 
>  drivers/net/phy/phy-c45.c    | 113 +++++++++++++++++++++++++++++++----
>  drivers/net/phy/phy-core.c   |   4 +-
>  include/uapi/linux/ethtool.h |   2 +
>  include/uapi/linux/mdio.h    |  21 +++++++
>  4 files changed, 129 insertions(+), 11 deletions(-)
> 

Heiner