netdev - Re: 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:   Mon, 19 Aug 2019 06:32:31 +0000
From:   Christian Herber <christian.herber@....com>
To:     Heiner Kallweit <hkallweit1@...il.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: Re: [PATCH net-next 0/1] Add BASE-T1 PHY support

On 16.08.2019 22:59, Heiner Kallweit wrote:
> 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
> 

Hi Heiner,

I do not think the Aquantia part you are describing is publicly 
documented, so i cannot comment on that part.
There are multiple reasons why e.g. xBASE-T1 plus 1000BASE-T is 
unlikely. First, the is no use-case known to me, where this would be 
required. Second, there is no way that you can do an auto-negotiation 
between the two, as these both have their own auto-neg defined (Clause 
28/73 vs. Clause 98). Thirdly, if you would ever have a product with 
both, I believe it would just include two full PHYs and a way to select 
which flavor you want. Of course, this is the theory until proven 
otherwise, but to me it is sufficient to use a single driver.

The registers are different in the fields they include. It is just that 
the flags which are used by the Linux driver, like restarting auto-neg, 
are at the same position.

Christian