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