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]

Message-ID: 
 <BY5PR02MB6786619C0A0FCB2BEDC2F90D9DF52@BY5PR02MB6786.namprd02.prod.outlook.com>
Date: Fri, 24 May 2024 21:45:22 +0000
From: Piergiorgio Beruto <Pier.Beruto@...emi.com>
To: Andrew Lunn <andrew@...n.ch>,
        Selvamani Rajagopal
	<Selvamani.Rajagopal@...emi.com>
CC: "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

Hi Andrew,
In reality, it is not the PHY having register in MMS12, and not even the MAC. These are really "chip-specific" registers, unrelated to networking (e.g., GPIOs, HW diagnostics, etc.).
They are in MMS12 exactly because they cannot be considered PHY functions, nor MAC functions.
And we have PHY specific registers in MMS4, just as you said.

Although, I think it is a good idea anyway to allow the MACPHY drivers to hook into / extend the MDIO access functions.
If anything, because of the hacks you mentioned. But also to allow vendor-specific extensions.

Makes sense?

Thanks,
Piergiorgio

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

[External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links.

> In our MDIO functions, we do certain things based on PHY ID, also our 
> driver deal with vendor specific register, MMS 12 (refer Table 6 in 
> section 9.1

That is a bad design. Vendor specific PHY registers should be in MMS 4 which is MMD 31, where the PHY driver can access them. Table 6 says:
"PHY – Vendor Specific" for MMS 4, so clearly that is where the standards committee expected PHY vendor registers to be.

Anyway, does the PHY driver actually need to access MMS 12? Or can the MAC driver do it? That is the same question i asked Ramón about the Microchip part. We really should avoid layering violations as much as we can, and we should not have the framework make it easy to violate layering. We want all such horrible hacks hidden in the MAC driver which needs such horrible hacks because of bad design.

	Andrew