Received-SPF: pass (google.com: domain of linux-kernel+bounces-189167-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Piergiorgio Beruto <Pier.Beruto@onsemi.com>
To: Andrew Lunn <andrew@lunn.ch>
CC: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>,
        "Parthiban.Veerasooran@microchip.com" <Parthiban.Veerasooran@microchip.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "edumazet@google.com"
	<edumazet@google.com>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "horms@kernel.org"
	<horms@kernel.org>,
        "saeedm@nvidia.com" <saeedm@nvidia.com>,
        "anthony.l.nguyen@intel.com" <anthony.l.nguyen@intel.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "linux-doc@vger.kernel.org"
	<linux-doc@vger.kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>,
        "conor+dt@kernel.org" <conor+dt@kernel.org>,
        "devicetree@vger.kernel.org"
	<devicetree@vger.kernel.org>,
        "Horatiu.Vultur@microchip.com"
	<Horatiu.Vultur@microchip.com>,
        "ruanjinjie@huawei.com"
	<ruanjinjie@huawei.com>,
        "Steen.Hegelund@microchip.com"
	<Steen.Hegelund@microchip.com>,
        "vladimir.oltean@nxp.com"
	<vladimir.oltean@nxp.com>,
        "UNGLinuxDriver@microchip.com"
	<UNGLinuxDriver@microchip.com>,
        "Thorsten.Kummermehr@microchip.com"
	<Thorsten.Kummermehr@microchip.com>,
        "Nicolas.Ferre@microchip.com"
	<Nicolas.Ferre@microchip.com>,
        "benjamin.bigler@bernformulastudent.ch"
	<benjamin.bigler@bernformulastudent.ch>
Subject: RE: [PATCH net-next v4 00/12] Add support for OPEN Alliance
 10BASE-T1x MACPHY Serial Interface
Thread-Topic: [PATCH net-next v4 00/12] Add support for OPEN Alliance
 10BASE-T1x MACPHY Serial Interface
Thread-Index: 
 AQHakZAxosrycArunkaHEujJo3A4abF0voeAgAA2YYCAGHiwAIAAQuMAgAFPWgCAAH78AIAA9q2AgBaf7QCAAAnBAIAAAr5ggAAE7gCAAADH4A==
Date: Fri, 24 May 2024 22:08:54 +0000
Message-ID: 
 <BY5PR02MB6786209192CB9B8A6EF5261F9DF52@BY5PR02MB6786.namprd02.prod.outlook.com>
References: <5f73edc0-1a25-4d03-be21-5b1aa9e933b2@lunn.ch>
 <32160a96-c031-4e5a-bf32-fd5d4dee727e@lunn.ch>
 <2d9f523b-99b7-485d-a20a-80d071226ac9@microchip.com>
 <6ba7e1c8-5f89-4a0e-931f-3c117ccc7558@lunn.ch>
 <8b9f8c10-e6bf-47df-ad83-eaf2590d8625@microchip.com>
 <44cd0dc2-4b37-4e2f-be47-85f4c0e9f69c@lunn.ch>
 <b941aefd-dbc5-48ea-b9f4-30611354384d@microchip.com>
 <BYAPR02MB5958A4D667D13071E023B18F83F52@BYAPR02MB5958.namprd02.prod.outlook.com>
 <6e4c8336-2783-45dd-b907-6b31cf0dae6c@lunn.ch>
 <BY5PR02MB6786619C0A0FCB2BEDC2F90D9DF52@BY5PR02MB6786.namprd02.prod.outlook.com>
 <0581b64a-dd7a-43d7-83f7-657ae93cefe5@lunn.ch>
In-Reply-To: <0581b64a-dd7a-43d7-83f7-657ae93cefe5@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?Ma9qE/JNWrJ2BDcqSd2oQM1ZVqQhoWiWwA/5oDv+isQWoML4HCUegSxSwyUH?=
 =?us-ascii?Q?BxN8QlCdH1Tlb5zrEbbGODRonNMVMZ+S+UOFS3fdlxbhQD2z7iV+Xn/sZXUM?=
 =?us-ascii?Q?Qqd5IX8DYoYiQh5F+3yldi+ImtBY9uYSp48Tp4lrtwWG8PKIpg3hrgvsFcYE?=
 =?us-ascii?Q?T2aAPt4K2gWeYmPKXmPnLq1oo10WZFL1pB1ZFdGZwG4Ywvuj/rYMPyusjNXV?=
 =?us-ascii?Q?puBsxKq4+IChtdCZVWBbGVLNsnmbu4R2EuaHFHjppOZXgrzpx0fVoUKGhpqe?=
 =?us-ascii?Q?WmDMW1AjQJ/j/LxmkD9OAmr4QQlvXYNyKkBrKULs0nE0hRVX9lkqmm1SH6fr?=
 =?us-ascii?Q?idGSBnJ5DpZeJWL5QYs0Yr/FI4edc1/OstD9yYBEWOeD3bjmz16b+xdfpG/3?=
 =?us-ascii?Q?z9VFZSeCfghN8Hog06wE9/hX/hfZ4HP7cstVWxwPLmqAQZWuBNVcRmqLfkJA?=
 =?us-ascii?Q?QQ6GsGcXCUGj21HJcNdlF2mXWGlbfRFW+iUfPPz50ZkodFjhqiUH5LzmK/2T?=
 =?us-ascii?Q?CTGBe08RDQDZHp7CFVm2JWoZlIhY7fv6ZY5/ZpLxPmmKp8/jmyLvF/85Gr02?=
 =?us-ascii?Q?Tv2LGuf3t2kLRzcUPUorTn0W0sX8Fw7pkRA2RPT7SqV2dcoVng5q6Mefj+k3?=
 =?us-ascii?Q?CMQz0yg2ry9xfD+xbauyZyIZvsL1a+5k4+vBNKmnSuabi+o2GbtpDo+etwpk?=
 =?us-ascii?Q?1OdM14BgWe6eTOv9uJ9vwehnH7Lexm9pJiHcMlinpNRfMoBOVKxjYYNVs3qf?=
 =?us-ascii?Q?OHYJV3AGb8D6EgnJ0oa9eQf+u74FbB5el3u3Vz+o7LQrklEAfBblySa+85HE?=
 =?us-ascii?Q?m34plFN1zv7P4JBy8hOcqMwh1Wp/AIi/rsYQYn5NqGJMh2KPBMIvbsscAbLl?=
 =?us-ascii?Q?75CE3Lff2Go/v403w3EevYXsAR7SASZs19bFUUMYSdh56VmBhKorOpWVO1/Q?=
 =?us-ascii?Q?bghd/55VkKwwuzkts/EWcO3rYzh9elkSpWIBqvNMaEsMavNO8xHiPpIW1w14?=
 =?us-ascii?Q?SL2PKWJyr9qETgfcPXmQNWvTnaJVM4XWmoF9DD8fKAtkw7IHvpyTCA8d8JCG?=
 =?us-ascii?Q?9A1TuyS7jN6IWjJVan93hRf1Ssm7pz5KMm7QDuq76yHPIukuXHJSJAKDKZz7?=
 =?us-ascii?Q?WtIPJMognO8cqDdeZKn9MjtVdcW1hHQZ+KGp7xzFIfDqTxEEmCo+C0vk5LDe?=
 =?us-ascii?Q?Bqa0RV86snLfF/rCGhVBNstWyHfWfoCoGb+S57v7g1FTYabAhZ2rvXiyu44z?=
 =?us-ascii?Q?E1CVIVfsW2aiFGRGtdh/+GRRI2PuWUxlrXcT5kE8dx00CVdKnLoaEv+ox6XR?=
 =?us-ascii?Q?mSRIkujx1R/yLKK3zGWl50idfXgGItafuVQNd1tGIPifAV0wHo4SXh3dq4LY?=
 =?us-ascii?Q?ATD0UjECzlFMCXTCyUdkJICGWOxZFby9Zm8FAlQ2C7e4loKQbSc2cKvtKZsV?=
 =?us-ascii?Q?OjBg3QfHnNKPirjZaBFWsrX+JJjmH8XYfI/TQlHdp0KLBMMBYfuJebnlPtHQ?=
 =?us-ascii?Q?lZBXUwpdxbHYF6f6QN2wrSwlZ+9Ir9cZsD+sMVl2s03ejocD+P0Pz5YJBS2h?=
 =?us-ascii?Q?1Wk8fugUDD121BNYa3QGK5OA3gOvwwJztCmKp1XY?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: onsemi.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR02MB6786.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93615ff4-4946-487d-52f3-08dc7c3e1a06
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2024 22:08:54.6099
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 04e1674b-7af5-4d13-a082-64fc6e42384c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3Oxkvkf33oPASvMOBhQiUBvc7rDtF9uNXED5HGBr7Zevxk1+t0U+2hwermQZllqW+BOc5bruVJXf11igT0nXsw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR02MB7462
X-Proofpoint-GUID: uQpgz9y_c9s85-c90VH6TO1tq6MVH-Ic
X-Proofpoint-ORIG-GUID: uQpgz9y_c9s85-c90VH6TO1tq6MVH-Ic
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16
 definitions=2024-05-24_08,2024-05-24_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0
 suspectscore=0 mlxscore=0 phishscore=0 adultscore=0 clxscore=1015
 malwarescore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2405170001
 definitions=main-2405240160

> Having a GPIO driver within the MAC driver is O.K. For hardware diagnosti=
cs 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 n=
eed to access MMS12.
But the MAC driver might need to access MMS-es for vendor specific stuff. I=
n our case, there is a model specific register we need to access during pro=
be.

> 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 vendo=
rs 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 extension=
s, you should be thinking about how to export it in a way which is common a=
cross multiple vendors.

Fair enough, let's keep it for "hacks" then. Still, I think there are featu=
res 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 allo=
ws one PHY to measure the distance (or rather, the propagation delay) to an=
other node on the same multi-drop segment.
Knowing the cable Tpd (~5ns/m), this allows you to get also the physical di=
stance.

It is a cool feature that has been also standardized in OPEN alliance and m=
any 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 lay=
er functions (to activate the functions that do the actual measurement) but=
 also "upper layer" protocols to communicate with the nodes and carry on th=
e 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