netdev - RE: [PATCH net-next v4 00/12] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface

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]

Message-ID: 
 <BY5PR02MB6786209192CB9B8A6EF5261F9DF52@BY5PR02MB6786.namprd02.prod.outlook.com>
Date: Fri, 24 May 2024 22:08:54 +0000
From: Piergiorgio Beruto <Pier.Beruto@...emi.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Selvamani Rajagopal <Selvamani.Rajagopal@...emi.com>,
        "Parthiban.Veerasooran@...rochip.com" <Parthiban.Veerasooran@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com"
	<edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "horms@...nel.org"
	<horms@...nel.org>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "anthony.l.nguyen@...el.com" <anthony.l.nguyen@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "Horatiu.Vultur@...rochip.com"
	<Horatiu.Vultur@...rochip.com>,
        "ruanjinjie@...wei.com"
	<ruanjinjie@...wei.com>,
        "Steen.Hegelund@...rochip.com"
	<Steen.Hegelund@...rochip.com>,
        "vladimir.oltean@....com"
	<vladimir.oltean@....com>,
        "UNGLinuxDriver@...rochip.com"
	<UNGLinuxDriver@...rochip.com>,
        "Thorsten.Kummermehr@...rochip.com"
	<Thorsten.Kummermehr@...rochip.com>,
        "Nicolas.Ferre@...rochip.com"
	<Nicolas.Ferre@...rochip.com>,
        "benjamin.bigler@...nformulastudent.ch"
	<benjamin.bigler@...nformulastudent.ch>
Subject: RE: [PATCH net-next v4 00/12] Add support for OPEN Alliance
 10BASE-T1x MACPHY Serial Interface

> Having a GPIO driver within the MAC driver is O.K. For hardware diagnostics you should be using devlink, which many MAC drivers have. So i don't see a need for the PHY driver to access MMS 12.
What I was trying to say is that I actually agree the PHY driver does not need to access MMS12.
But the MAC driver might need to access MMS-es for vendor specific stuff. In our case, there is a model specific register we need to access during probe.

> But we don't want vendor specific extensions. OS 101, the OS is there to make all hardware look the same. And in general, it is not often that vendors actually come up with anything unique. And if they do, and it is useful, other vendors will copy it. So rather than doing vendor specific extensions, you should be thinking about how to export it in a way which is common across multiple vendors.

Fair enough, let's keep it for "hacks" then. Still, I think there are features that -initially- are kind of vendor specific, but in the long run they turn into standards or de-facto standards.
I assume we want to help this happening (step-wise), don't we?

For example, one big feature I think at some point we should understand how to deal with, is topology discovery for multi-drop.
Maybe you've heard about it already, but in short it is a feature that allows one PHY to measure the distance (or rather, the propagation delay) to another node on the same multi-drop segment.
Knowing the cable Tpd (~5ns/m), this allows you to get also the physical distance.

It is a cool feature that has been also standardized in OPEN alliance and many vendors are already implemented it.
As for other stuff, we put a lot of effort in convincing the committees to standardize the registers too, and fortunately we did it.

The "problem" with topology discovery is that it involves both physical layer functions (to activate the functions that do the actual measurement) but also "upper layer" protocols to communicate with the nodes and carry on the actual measurement.
For this "upper layer" stuff we did not define a standard.

In my view, we should probably create some PHY extensions in the kernel to activate the physical layer part, leaving the "protocol" to the userland.
May I ask your opinion?

Thanks,
Piergiorgio