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. Christian