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 09:43:56 +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

Hello Andrew,

I was reading back into the MACPHY specifications in OPEN Alliance, and it seems like MMS 10 to MMS 15 are actually allowed as vendor specific registers. See page 50.
The specifications further say that vendor specific registers of the PHY that would normally be in MMD30-31 (ie, excluding the PLCA registers and the other OPEN standard registers) would go into MMS10 to MMS15.

So I'm wondering, why is it bad to have vendor specific registers into MMD10 to MMD15?
I think the framework should allow non-standard stuff to be mapped into these, no?

Thanks,
Piergiorgio

-----Original Message-----
From: Andrew Lunn <andrew@...n.ch> 
Sent: 24 May, 2024 23:55
To: Piergiorgio Beruto <Pier.Beruto@...emi.com>
Cc: Selvamani Rajagopal <Selvamani.Rajagopal@...emi.com>; 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; Nicolas.Ferre@...rochip.com; benjamin.bigler@...nformulastudentch
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 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.).

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.

Anyway, we can do a real review when you post your code.

> 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.

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.

   Andrew