Received-SPF: pass (google.com: domain of linux-kernel+bounces-204330-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 6 Jun 2024 15:12:11 +0200
From: Andrew Lunn <andrew@lunn.ch>
To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
Cc: "Parthiban.Veerasooran@microchip.com" <Parthiban.Veerasooran@microchip.com>,
	Piergiorgio Beruto <Pier.Beruto@onsemi.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>,
	Viliam Vozar <Viliam.Vozar@onsemi.com>,
	Arndt Schuebel <Arndt.Schuebel@onsemi.com>
Subject: Re: [PATCH net-next v4 00/12] Add support for OPEN Alliance
 10BASE-T1x MACPHY Serial Interface
Message-ID: <79f61e42-c32f-4314-8b77-99880c2d7eeb@lunn.ch>
References: <BY5PR02MB6786619C0A0FCB2BEDC2F90D9DF52@BY5PR02MB6786.namprd02.prod.outlook.com>
 <0581b64a-dd7a-43d7-83f7-657ae93cefe5@lunn.ch>
 <BY5PR02MB6786FC4808B2947CA03977429DF32@BY5PR02MB6786.namprd02.prod.outlook.com>
 <39a62649-813a-426c-a2a6-4991e66de36e@microchip.com>
 <585d7709-bcee-4a0e-9879-612bf798ed45@lunn.ch>
 <BY5PR02MB6786649AEE8D66E4472BB9679DFC2@BY5PR02MB6786.namprd02.prod.outlook.com>
 <cbe5043b-5bb5-4b9f-ac09-5c767ceced36@microchip.com>
 <BYAPR02MB5958BD922DAE2D31F18241B283F92@BYAPR02MB5958.namprd02.prod.outlook.com>
 <732ce616-9ddc-4564-ab1f-ac7bbc591292@lunn.ch>
 <BYAPR02MB5958DE3C4FE820216153894B83FA2@BYAPR02MB5958.namprd02.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BYAPR02MB5958DE3C4FE820216153894B83FA2@BYAPR02MB5958.namprd02.prod.outlook.com>

> I believe my client is configured to wrap at 70th characters. 
> Not sure why it is not doing it.


It could be you also send a MIME obfuscated copy which is not wrapped
correctly?

> > > 1) Can we move memory map selector definitions
> > (OA_TC6_PHY_C45_PCS_MMS2 and other 4 definitions) to the header
> > file
> > >      include/linux/oa_tc6.h?
> > >      Also, if possible, could we add the MMS0, MMS1?. Our driver is
> > using them. Of course, we could add it when we submit our driver.
> > 
> > Interesting. So you have vendor registers outside of MMS 10-15?
> 
> This is not about vendor registers. The current oa_tc6 defines 
> MMS selector values for 2, 3, 4, 5, 6. I am asking, if 0, 1 can be added, 
> which are meant for "Standard Control and Status" and MAC respectively, 
> according to MMS assignment table 6 on OA standard.

But why would a MAC driver need access to those? Everything using
those registers should be defined in the standard. So the framework
should handle them.

> One example I can think of is, to handle PHYINT status bit
> that may be set in STATUS0 register. Another example could be,
> to give a vendor flexibility to not to use interrupt mode.

But that is part of the standard. Why would a driver need to do
anything, the framework should handle PHYINT, calling
phy_mac_interrupt(phydev).

I really think you need to post patches. We can then discuss each use
case, and i can give you concrete feedback.

But in general, if it is part of the standard it should be in the
framework. Support for features which are not part of the standard,
and workarounds for where a device violates the standard, should be in
the MAC driver, or the PHY driver.

	Andrew