netdev - Re: [PATCH net-next 0/1] Add BASE-T1 PHY support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Aug 2019 22:59:29 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Christian Herber <christian.herber@....com>,
        "davem@...emloft.net" <davem@...emloft.net>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 0/1] Add BASE-T1 PHY support

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