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>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ