netdev - Re: Adding IEEE802.3cg Clause 148 PLCA support to Linux

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

Date:   Sun, 6 Nov 2022 00:40:32 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     piergiorgio.beruto@...il.com
Cc:     netdev@...r.kernel.org
Subject: Re: Adding IEEE802.3cg Clause 148 PLCA support to Linux

On Sat, Nov 05, 2022 at 06:42:10PM +0100, piergiorgio.beruto@...il.com wrote:
> Hello,
> I would like to add IEEE 802.3cg-2019 PLCA support to Linux.

Could you recommend any introductory document? 802.3 can be heavy
going.

> PLCA (Physical Layer Collision Avoidance) is an enhanced
> media-access protocol for multi-drop networks, and it is currently
> specified for the 10BASE-T1S PHY defined in Clause 147 of the same
> standard.

> This feature is fully integrated into PHY and MACPHY implementations
> such as the onsemi NCN26010 and Microchip LAN867x, which are
> available on the market.

Do the MAC and PHY need to negotiate this feature? Does the MAC need
to know if the PHY is PLCA capable? Ideally,
genphy_c45_pma_read_abilities() can determine if a PHY is PLCA
capable? And the MAC can then check the result of this and enable its
part of PLCA?

> In practice, what we need to do is configuring some additional
> parameters of the PHY: PLCA ID, TO_TIMER, NODE_COUNT, BURST.

Are these purely PHY configuration values? Is the MAC involved at all?

> The PHY registers for PLCA configuration are further documented in
> the OPEN alliance SIG public specifications (see
> https://www.opensig.org/about/specifications/ -> PLCA Management
> Registers)

Nice. But do the available PHYs actually follow this? Ideally you
should provide a set of helpers which implement these registers. But
you have to assume that silicon vendors will ignore the standard and
implement it differently. They often do. So the helpers are just
helpers, and the PHY driver needs to be able to implement these values
in there own way.

> The parameters I mentioned has to be configured dynamically.

How dynamically? And what is setting them? Do you see the need for a
user space daemon? Are values placed in /etc/network/interfaces?

Ethtool does seems like one option. But i would like to understand the
bigger picture before making a definitive answer.

       Andrew