[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d020fd22f253f32622b6d150a4387ed0707f587.camel@analog.com>
Date: Tue, 13 Aug 2019 06:07:42 +0000
From: "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>
To: "andrew@...n.ch" <andrew@...n.ch>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>
Subject: Re: [PATCH v4 13/14] net: phy: adin: add ethtool get_stats support
On Mon, 2019-08-12 at 16:26 +0200, Andrew Lunn wrote:
> [External]
>
> > +/* Named just like in the datasheet */
> > +static struct adin_hw_stat adin_hw_stats[] = {
> > + { "RxErrCnt", 0x0014, },
> > + { "MseA", 0x8402, 0, true },
> > + { "MseB", 0x8403, 0, true },
> > + { "MseC", 0x8404, 0, true },
> > + { "MseD", 0x8405, 0, true },
> > + { "FcFrmCnt", 0x940A, 0x940B }, /* FcFrmCntH + FcFrmCntL */
> > + { "FcLenErrCnt", 0x940C },
> > + { "FcAlgnErrCnt", 0x940D },
> > + { "FcSymbErrCnt", 0x940E },
> > + { "FcOszCnt", 0x940F },
> > + { "FcUszCnt", 0x9410 },
> > + { "FcOddCnt", 0x9411 },
> > + { "FcOddPreCnt", 0x9412 },
> > + { "FcDribbleBitsCnt", 0x9413 },
> > + { "FcFalseCarrierCnt", 0x9414 },
>
> I see some value in using the names from the datasheet. However, i
> found it quite hard to now what these counters represent given there
> current name. What is Mse? How does MseA differ from MseB? You have up
> to ETH_GSTRING_LEN characters, so maybe longer names would be better?
I'll expand the names.
Regarding MseA/B/C/D, I'll admit I am also a bit fuzzy about them.
They describe link-quality settings, and the values have some meaning to the chip guys [when I talked witht them about
it], but I did not insist on getting a deep explanation about them [and what their values represent].
I guess for this PHY driver, we could drop them, and if they're needed they can be accessed via phytool, and if they're
really needed, I can try to add them later with more complete detail [about them and their use/value].
I included them here, because they are listed in the error-counter register "group" [in the datasheet], and I inertially
added them.
>
> Andrew
Powered by blists - more mailing lists