[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AM6PR0402MB379820688ED6E8D3FA60D45C86920@AM6PR0402MB3798.eurprd04.prod.outlook.com>
Date: Wed, 16 Oct 2019 13:19:06 +0000
From: Christian Herber <christian.herber@....com>
To: Lucas Stach <l.stach@...gutronix.de>,
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 October 16, 2019 10:37:30 AM Lucas Stach <l.stach@...gutronix.de> wrote:
> On Fr, 2019-08-16 at 22:59 +0200, 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.
>
> There are PHYs combining both Base-T1 and other Base-T capabilities.
> E.g. the Broadcom BCM54811 support both Base-T1, as well as 1000BASE-T
> and 100BASE-TX.
>
> Regards,
> Lucas
Interesting. To be precise, the device supports BroadR-Reach and not 100BASE-T1 according to their product brief. Therefore I would assume that the registers also do not follow the IEEE defined Clause 45 layout. While we cannot learn much then how to handle such devices in a generic clause 45 driver, this suggests that such devices can appear.
Still, IEEE 802.3 does not really define a way that these devices would coexist, so I would assume it is pretty much two PHYs in one IC and you can chose which flavor you want. Is my assumption on that correct?
In that case, you would have to structure the drivers in a way the you have separate functions for the standalone flavors of Clause 45 managed PHYs, while making as much reuse as possible between them.
Powered by blists - more mailing lists