linux-kernel - 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]

Date: Thu, 30 May 2024 21:37:04 +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>,
        Viliam Vozar
	<Viliam.Vozar@...emi.com>,
        Arndt Schuebel <Arndt.Schuebel@...emi.com>
Subject: RE: [PATCH net-next v4 00/12] Add support for OPEN Alliance
 10BASE-T1x MACPHY Serial Interface

> From an architecture perspicuity, PHY vendor specific registers should be in the PHY register address space. MAC vendor specific registers should be in the MAC register address space.
I agree 100%. The registers I'm talking about are not PHY or MAC specific. They are related to other functions. For example, configuring pins to output a clock, an SFD indication, a LED, or other.
Some devices also can configure events driven by the PTP timer to toggle GPIOs, capture the timer on rising/falling edge of a GPIO or similar.

> It seems like the Microchip device has some PHY vendor specific registers in the MAC address space. That is bad.
I was not aware of that. I can tell you this is not my case.

> Both your and Microchip device is a single piece of silicon. But i doubt there is anything in the standard which actually requires this. The PHY could be discrete, on the end of an MDIO bus and an MII bus. That is the typical design for the last 30 years, and what linux is built around. The MAC should not assume anything about the PHY, the PHY should not assume anything about the MAC, because they are interchangeable.
Yes, to me the MAC and PHY must be separate entities even for the OPEN Alliance TC14/6 protocol. Besides, you can stuff whatever PHY within your MACPHY chip (e.g. 10BASE-T1L).
In "my" driver you need to specify in the DTS the kind of net device and the PHY as a handle.

> The framework does allow you to poke any register anywhere. But i would strongly avoid breaking the layering, it is going to cause you long term maintenance problems, and is ugly.
On that we agree. Maybe I was just misunderstanding the earlier conversation where I thought you would not allow specific drivers to access MMS other than 0,1,4 and the ones that map to MMDs.
If this is not the case, then I think I'm good.

Thanks!
--Pier