From: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Oleksij Rempel <o.rempel@pengutronix.de>
Subject: Re: [PATCH net-next 4/4] driver/ncn26000: add PLCA support
Date: Sun, 4 Dec 2022 21:29:59 +0100 [thread overview]
Message-ID: <Y40DR1nsF1wIxnXh@gvm01> (raw)
In-Reply-To: <Y4zTqvSxLJG+G8V+@shell.armlinux.org.uk>
On Sun, Dec 04, 2022 at 05:06:50PM +0000, Russell King (Oracle) wrote:
> On Sun, Dec 04, 2022 at 03:32:06AM +0100, Piergiorgio Beruto wrote:
> > + /* HW bug workaround: the default value of the PLCA TO_TIMER should be
> > + * 32, where the current version of NCN26000 reports 24. This will be
> > + * fixed in future PHY versions. For the time being, we force the right
> > + * default here.
> > + */
> > + ret = phy_write_mmd(phydev,
> > + MDIO_MMD_OATC14,
> > + MDIO_OATC14_PLCA_TOTMR,
> > + TO_TMR_DEFAULT);
>
> Better formatting please.
>
> return phy_write_mmd(phydev, MDIO_MMD_OATC14, MDIO_OATC14_PLCA_TOTMR,
> TO_TMR_DEFAULT);
>
> is sufficient. No need for "ret" (and there are folk who will create a
> cleanup patch to do this, so might as well get it right on submission.)
Ok, I will change the formatting.
On the use of ret, I did that just because I was planning to add more
features to be pre-configured in the future. But for the time being I
can do it as you suggest.
> > +/**
> > + * genphy_c45_plca_get_cfg - get PLCA configuration from standard registers
> > + * @phydev: target phy_device struct
> > + * @plca_cfg: output structure to store the PLCA configuration
> > + *
> > + * Description: if the PHY complies to the Open Alliance TC14 10BASE-T1S PLCA
> > + * Management Registers specifications, this function can be used to retrieve
> > + * the current PLCA configuration from the standard registers in MMD 31.
> > + */
> > +int genphy_c45_plca_get_cfg(struct phy_device *phydev,
> > + struct phy_plca_cfg *plca_cfg)
> > +{
> > + int ret;
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_OATC14, MDIO_OATC14_PLCA_IDVER);
> > + if (ret < 0)
> > + return ret;
> > +
> > + plca_cfg->version = (u32)ret;
>
> ->version has type s32, so is signed. Clearly, from the above code, it
> can't be negative (since negative integer values are an error.) So why
> is ->version declared in patch 1 as signed? The cast here to u32 also
> seems strange.
>
> Also, since the register you're reading can be no more than 16 bits
> wide, using s32 seems like a waste.
Please, see the discussion I had with Andrew on this topic.
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_OATC14, MDIO_OATC14_PLCA_CTRL0);
> > + if (ret < 0)
> > + return ret;
> > +
> > + plca_cfg->enabled = !!(((u16)ret) & MDIO_OATC14_PLCA_EN);
>
> ->enabled has type s16, but it clearly boolean in nature. It could be
> a u8 instead. No need for that u16 cast either.
I'll remove all the casts. I apologize, but in some environments the
coding rules may be different, requiring unnecessary casts for
safety/verification reasons. So I still need to adapt my style to match
the kernel's. Please, have patience with me...
> > +
> > + // first of all, disable PLCA if required
> > + if (plca_cfg->enabled == 0) {
> > + ret = phy_clear_bits_mmd(phydev,
> > + MDIO_MMD_OATC14,
> > + MDIO_OATC14_PLCA_CTRL0,
> > + MDIO_OATC14_PLCA_EN);
> > +
> > + if (ret < 0)
> > + return ret;
> > + }
>
> Does this need to be disabled when making changes? Just wondering
> why you handle this disable explicitly early.
It is just a way to avoig configuration glitches. If we need to disable
PLCA, it is better to do it before changing any other parameter, so that
you don't disturb the other nodes on the multi-drop network.
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(genphy_c45_plca_get_status);
> > +
> > struct phy_driver genphy_c45_driver = {
> > .phy_id = 0xffffffff,
> > .phy_id_mask = 0xffffffff,
> > diff --git a/include/linux/phy.h b/include/linux/phy.h
> > index 2dfb85c6e596..4548c8e8f6a9 100644
> > --- a/include/linux/phy.h
> > +++ b/include/linux/phy.h
> > @@ -811,7 +811,7 @@ struct phy_plca_cfg {
> > * struct phy_plca_status - Status of the PLCA (Physical Layer Collision
> > * Avoidance) Reconciliation Sublayer.
> > *
> > - * @status: The PLCA status as reported by the PST bit in the PLCA STATUS
> > + * @pst: The PLCA status as reported by the PST bit in the PLCA STATUS
> > * register(31.CA03), indicating BEACON activity.
> > *
> > * A structure containing status information of the PLCA RS configuration.
> > @@ -819,7 +819,7 @@ struct phy_plca_cfg {
> > * what is actually used.
> > */
> > struct phy_plca_status {
> > - bool status;
> > + bool pst;
> > };
>
> Shouldn't this be in patch 1?
I thought to first promote the changes to the "higher layers" of
ethtool/netlink, then create the appropriate interface towards phylib.
Are you suggesting to merge patches 1 & 2?
> > +
> > #endif /* _UAPI__LINUX_MDIO_H__ */
> > diff --git a/net/ethtool/plca.c b/net/ethtool/plca.c
> > index 371d8098225e..ab50d8b48bd6 100644
> > --- a/net/ethtool/plca.c
> > +++ b/net/ethtool/plca.c
> > @@ -269,7 +269,7 @@ static int plca_get_status_fill_reply(struct sk_buff *skb,
> > const struct ethnl_reply_data *reply_base)
> > {
> > const struct plca_reply_data *data = PLCA_REPDATA(reply_base);
> > - const u8 status = data->plca_st.status;
> > + const u8 status = data->plca_st.pst;
>
> Shouldn't this be in a different patch?
Ah, logically, yes. I thought since it is an aesthetic change to leave
it there. But if you like I can try to merge it with patch 2.
Thanks,
Piergiorgio
prev parent reply other threads:[~2022-12-04 20:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1670119328.git.piergiorgio.beruto@gmail.com>
2022-12-04 2:30 ` [PATCH net-next 1/4] net/ethtool: Add netlink interface for the PLCA RS Piergiorgio Beruto
2022-12-04 2:37 ` Randy Dunlap
2022-12-04 2:49 ` Piergiorgio Beruto
2022-12-04 3:01 ` Randy Dunlap
2022-12-04 2:30 ` [PATCH net-next 2/4] phylib: Add support for 10BASE-T1S link modes and PLCA config Piergiorgio Beruto
2022-12-04 16:45 ` Russell King (Oracle)
2022-12-04 18:04 ` Piergiorgio Beruto
2022-12-04 18:12 ` Andrew Lunn
2022-12-04 20:09 ` Piergiorgio Beruto
2022-12-04 2:31 ` [PATCH net-next 3/4] drivers/net/phy: Add driver for the onsemi NCN26000 10BASE-T1S PHY Piergiorgio Beruto
2022-12-04 16:52 ` Russell King (Oracle)
2022-12-04 17:23 ` Andrew Lunn
2022-12-04 18:00 ` Andrew Lunn
2022-12-04 20:11 ` Piergiorgio Beruto
2022-12-04 18:40 ` Piergiorgio Beruto
2022-12-04 18:58 ` Andrew Lunn
2022-12-04 19:48 ` Piergiorgio Beruto
2022-12-04 2:32 ` [PATCH net-next 4/4] driver/ncn26000: add PLCA support Piergiorgio Beruto
2022-12-04 17:06 ` Russell King (Oracle)
2022-12-04 17:36 ` Andrew Lunn
2022-12-04 18:48 ` Andrew Lunn
2022-12-04 20:09 ` Piergiorgio Beruto
2022-12-04 20:22 ` Russell King (Oracle)
2022-12-04 20:33 ` Piergiorgio Beruto
2022-12-04 20:29 ` Piergiorgio Beruto [this message]
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=Y40DR1nsF1wIxnXh@gvm01 \
--to=piergiorgio.beruto@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox