[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<BYAPR02MB5958E09553F82C486DE8BDA483FB2@BYAPR02MB5958.namprd02.prod.outlook.com>
Date: Fri, 7 Jun 2024 04:40:33 +0000
From: Selvamani Rajagopal <Selvamani.Rajagopal@...emi.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "Parthiban.Veerasooran@...rochip.com"
<Parthiban.Veerasooran@...rochip.com>,
Piergiorgio Beruto
<Pier.Beruto@...emi.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
> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Thursday, June 6, 2024 6:12 AM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@...emi.com>
> Cc: Parthiban.Veerasooran@...rochip.com; Piergiorgio Beruto
> <Pier.Beruto@...emi.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@...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
>
> [External Email]: This email arrived from an external source - Please
> exercise caution when opening any attachments or clicking on links.
>
> > 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.
True. That would be better. Will work on the patches so that it is clear.
>
> 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
Powered by blists - more mailing lists