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

[Heiner Kallweit]

On 20.08.2019 15:36, Christian Herber wrote:
> On 19.08.2019 21:07, Heiner Kallweit wrote:
>> Caution: EXT Email
>>
>> On 19.08.2019 08:32, Christian Herber wrote:
>>> 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.
>> Right, datasheet isn't publicly available. All I wanted to say with
>> mentioning this PHY: It's not a rare exception that a PHY combines
>> standard BaseT modes with "non-consumer" modes for special purposes.
>> One practical use case of this proprietary 1000Base-T2 mode is
>> re-using existing 2-pair cabling in aircrafts.
>>
>>> 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.
>>>
>> I'm with you if you say it's unlikely. However your statement in the
>> commit message leaves the impression that there can't be such a device.
>> And that's a difference.
>>
>> Regarding "including two full PHYs":
>> This case we have already, there are PHYs combining different IP blocks,
>> each one supporting a specific mode (e.g. copper and fiber). There you
>> also have the case of different autoneg methods, clause 28 vs. clause 37.
>>
>>> 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.
>>>
>> Good to know. Your commit description doesn't mention any specific PHY.
>> I suppose you have PHYs you'd like to operate with the genphy_c45 driver.
>> Could you give an example? And ideally, is a public datasheet available?
>>
>>> Christian
>>>
>>>
>> Heiner
>>
> 
> There are no public BASE-T1 devices on the market right now that use 
> Clause 45 standard registers. The first such products were developed 
> before the IEEE standard (BroadR-Reach) and used Clause 22 access (see 
> e.g. the support in the Kernel for TJA110x).
> 
> The most convenient way to test with a BASE-T1 device would be to use an 
> SFP (e.g. 
> https://technica-engineering.de/produkt/1000base-t1-sfp-module/). 
> Alternative source could be Goepel.
> 
> There are also a number of media-converters around where one could break 
> out the MDIO and connect to a processor. Of course, in all cases it 
> should be made sure that this is a Clause-45 device.
> 
> As all relevant parts are NDA-restricted, this is pretty much all the 
> information I can share.
> 
If no such device is on the market yet, then I'd suggest:
- wait for such a device to see whether genphy_c45 driver is really
  sufficient or whether other chip features require a dedicated driver
  anyway. In the latter case it may be better to add dedicated T1
  functions to phylib.
- add the missing 10BASE-T1L and 10BASE-T1S support meanwhile

The current patch set IMO is a little bit hacky. I'm not 100% happy
with the implicit assumption that there can't be devices supporting
T1 and classic BaseT modes or fiber modes.

Andrew: Do you have an opinion on that?

> Christian
> 
> 
Heiner