From: Jakub Kicinski <kuba@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, corbet@lwn.net, michael.chan@broadcom.com,
hkallweit1@gmail.com, linux@armlinux.org.uk,
huangguangbin2@huawei.com, chenhao288@hisilicon.com,
moshet@nvidia.com, linux@rempel-privat.de,
linux-doc@vger.kernel.org
Subject: Re: [PATCH net-next v2] ethtool: linkstate: add a statistic for PHY down events
Date: Fri, 28 Oct 2022 09:20:47 -0700 [thread overview]
Message-ID: <20221028092047.45fa3d19@kernel.org> (raw)
In-Reply-To: <Y1vIg8bR8NBnQ3J5@lunn.ch>
On Fri, 28 Oct 2022 14:18:11 +0200 Andrew Lunn wrote:
> > @@ -67,6 +67,7 @@ static void phy_link_down(struct phy_device *phydev)
> > {
> > phydev->phy_link_change(phydev, false);
> > phy_led_trigger_change_speed(phydev);
> > + WRITE_ONCE(phydev->link_down_events, phydev->link_down_events + 1);
>
> I'm not sure the WRITE_ONCE adds much value. Many systems using PHYLIB
> are 32 bit, and i don't think WRITE_ONCE will make that 64 bit write
> atomic on 32 bit systems. And as Florian pointed out, you have bigger
> problems if you manged to overflow a u32 into a u64.
>
> > @@ -723,6 +724,8 @@ struct phy_device {
> >
> > int pma_extable;
> >
> > + unsigned int link_down_events;
>
> And here is unsigned int, not u64? Or u32? It would be good to be
> consistent.
I made it 32b on the phylib side so that WRITE_ONCE() was sufficient
to ensure atomic writes.
Do you have a preference for it being 64b vs 32b at the uAPI level?
I was leaning slightly towards making both 32b in v3..
> > --- a/include/uapi/linux/ethtool_netlink.h
> > +++ b/include/uapi/linux/ethtool_netlink.h
> > @@ -262,6 +262,8 @@ enum {
> > ETHTOOL_A_LINKSTATE_SQI_MAX, /* u32 */
> > ETHTOOL_A_LINKSTATE_EXT_STATE, /* u8 */
> > ETHTOOL_A_LINKSTATE_EXT_SUBSTATE, /* u8 */
> > + ETHTOOL_A_LINKSTATE_PAD,
> > + ETHTOOL_A_LINKSTATE_EXT_DOWN_CNT, /* u64 */
>
> What is the PAD for?
64b values have to be padded in netlink to ensure alignment.
next prev parent reply other threads:[~2022-10-28 16:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 1:27 [PATCH net-next v2] ethtool: linkstate: add a statistic for PHY down events Jakub Kicinski
2022-10-28 2:50 ` Florian Fainelli
2022-10-28 3:08 ` Jakub Kicinski
2022-10-28 12:18 ` Andrew Lunn
2022-10-28 16:20 ` Jakub Kicinski [this message]
2022-10-28 22:09 ` Andrew Lunn
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=20221028092047.45fa3d19@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=chenhao288@hisilicon.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=huangguangbin2@huawei.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@rempel-privat.de \
--cc=michael.chan@broadcom.com \
--cc=moshet@nvidia.com \
--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.