From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Mateusz Polchlopek <mateusz.polchlopek@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
kernel@pengutronix.de, linux-doc@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>
Subject: Re: [PATCH net-next v1 6/7] phy: dp83td510: add statistics support
Date: Thu, 5 Dec 2024 11:58:59 +0100 [thread overview]
Message-ID: <Z1GHczyyzDFkV592@pengutronix.de> (raw)
In-Reply-To: <20241205-satisfied-gerbil-of-cookies-471293-mkl@pengutronix.de>
On Thu, Dec 05, 2024 at 10:01:10AM +0100, Marc Kleine-Budde wrote:
> On 05.12.2024 09:43:34, Mateusz Polchlopek wrote:
> >
> >
> > On 12/3/2024 8:56 AM, Oleksij Rempel wrote:
> > > Add support for reporting PHY statistics in the DP83TD510 driver. This
> > > includes cumulative tracking of transmit/receive packet counts, and
> > > error counts. Implemented functions to update and provide statistics via
> > > ethtool, with optional polling support enabled through `PHY_POLL_STATS`.
> > >
> > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > > ---
> > > drivers/net/phy/dp83td510.c | 98 ++++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 97 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/phy/dp83td510.c b/drivers/net/phy/dp83td510.c
> > > index 92aa3a2b9744..08d61a6a8c61 100644
> > > --- a/drivers/net/phy/dp83td510.c
> > > +++ b/drivers/net/phy/dp83td510.c
> > > @@ -34,6 +34,24 @@
> > > #define DP83TD510E_CTRL_HW_RESET BIT(15)
> > > #define DP83TD510E_CTRL_SW_RESET BIT(14)
> > > +#define DP83TD510E_PKT_STAT_1 0x12b
> > > +#define DP83TD510E_TX_PKT_CNT_15_0_MASK GENMASK(15, 0)
> > > +
> > > +#define DP83TD510E_PKT_STAT_2 0x12c
> > > +#define DP83TD510E_TX_PKT_CNT_31_16_MASK GENMASK(15, 0)
> >
> > Shouldn't it be GENMASK(31, 16) ? If not then I think that macro
> > name is a little bit misleading
>
> Yes, the name may be a bit misleading...
The naming is done according to the chip datasheet. This is preferable
way to name defines.
> [...]
>
> > > + */
> > > +static int dp83td510_update_stats(struct phy_device *phydev)
> > > +{
> > > + struct dp83td510_priv *priv = phydev->priv;
> > > + u64 count;
> > > + int ret;
> > > +
> > > + /* DP83TD510E_PKT_STAT_1 to DP83TD510E_PKT_STAT_6 registers are cleared
> > > + * after reading them in a sequence. A reading of this register not in
> > > + * sequence will prevent them from being cleared.
> > > + */
this comment is relevant for the following question by Marc.
> > > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_PKT_STAT_1);
> > > + if (ret < 0)
> > > + return ret;
> > > + count = FIELD_GET(DP83TD510E_TX_PKT_CNT_15_0_MASK, ret);
> > > +
> > > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_PKT_STAT_2);
> > > + if (ret < 0)
> > > + return ret;
> > > + count |= (u64)FIELD_GET(DP83TD510E_TX_PKT_CNT_31_16_MASK, ret) << 16;
> >
> > Ah... here you do shift. I think it would be better to just define
> >
> > #define DP83TD510E_TX_PKT_CNT_31_16_MASK GENMASK(31, 16)
>
> No. This would not be the same.
>
> The current code takes the lower 16 bit of "ret" and shifts it left 16
> bits.
>
> As far as I understand the code DP83TD510E_PKT_STAT_1 contain the lower
> 16 bits, while DP83TD510E_PKT_STAT_2 contain the upper 16 bits.
>
> DP83TD510E_PKT_STAT_1 gives 0x????aaaa
> DP83TD510E_PKT_STAT_2 gives 0x????bbbb
>
> count will be 0xbbbbaaaa
>
> This raises another question: Are these values latched?
>
> If not you can get funny results if DP83TD510E_PKT_STAT_1 rolls over. On
> unlatched MMIO busses you first read the upper part, then the lower,
> then the upper again and loop if the value of the upper part changed in
> between. Not sure how much overhead this means for the slow busses.
>
> Consult the doc of the chip if you can read both in one go and if the
> chip latches these values for that access mode.
It is not documented, what is documented is that PKT_STAT_1 to
PKT_STAT_3 should be read in sequence to trigger auto clear function of
this registers. If chip do not latches these values, we will have
additional problem - some counts will be lost in the PKT_STAT_1/2 till we with
PKT_STAT_3 will be done.
With other words, I'll do more testing and add corresponding comments in
the code..
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2024-12-05 10:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 7:56 [PATCH net-next v1 0/7] Introduce unified and structured PHY Oleksij Rempel
2024-12-03 7:56 ` [PATCH net-next v1 1/7] net: ethtool: plumb PHY stats to PHY drivers Oleksij Rempel
2024-12-03 8:30 ` Maxime Chevallier
2024-12-05 7:45 ` Mateusz Polchlopek
2024-12-05 11:57 ` Russell King (Oracle)
2024-12-06 1:19 ` Jakub Kicinski
2024-12-06 9:11 ` Russell King (Oracle)
2024-12-06 16:13 ` Jakub Kicinski
2024-12-10 12:03 ` Simon Horman
2024-12-03 7:56 ` [PATCH net-next v1 2/7] net: ethtool: add support for structured PHY statistics Oleksij Rempel
2024-12-05 12:00 ` Russell King (Oracle)
2024-12-03 7:56 ` [PATCH net-next v1 3/7] phy: replace bitwise flag definitions with BIT() macro Oleksij Rempel
2024-12-05 2:50 ` David Laight
2024-12-05 11:13 ` Oleksij Rempel
2024-12-05 12:02 ` Russell King (Oracle)
2024-12-05 12:06 ` Russell King (Oracle)
2024-12-03 7:56 ` [PATCH net-next v1 4/7] phy: introduce optional polling interface for PHY statistics Oleksij Rempel
2024-12-05 8:14 ` Mateusz Polchlopek
2024-12-05 12:09 ` Russell King (Oracle)
2024-12-06 11:14 ` Oleksij Rempel
2024-12-03 7:56 ` [PATCH net-next v1 5/7] ethtool: add helper to prevent invalid statistics exposure to userspace Oleksij Rempel
2024-12-05 8:45 ` Mateusz Polchlopek
2024-12-03 7:56 ` [PATCH net-next v1 6/7] phy: dp83td510: add statistics support Oleksij Rempel
2024-12-05 8:43 ` Mateusz Polchlopek
2024-12-05 9:01 ` Marc Kleine-Budde
2024-12-05 10:32 ` Mateusz Polchlopek
2024-12-05 10:58 ` Oleksij Rempel [this message]
2024-12-05 12:15 ` Russell King (Oracle)
2024-12-03 7:56 ` [PATCH net-next v1 7/7] phy: dp83tg720: " Oleksij Rempel
2024-12-05 11:48 ` [PATCH net-next v1 0/7] Introduce unified and structured PHY Russell King (Oracle)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z1GHczyyzDFkV592@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=andrew+netdev@lunn.ch \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mateusz.polchlopek@intel.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.