From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Ronnie.Kunin@microchip.com, Raju.Lakkaraju@microchip.com,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com,
Bryan.Whitehead@microchip.com, UNGLinuxDriver@microchip.com,
maxime.chevallier@bootlin.com, rdunlap@infradead.org,
Steen.Hegelund@microchip.com, Daniel.Machon@microchip.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next V2 1/5] net: lan743x: Add SFP support check flag
Date: Mon, 16 Sep 2024 19:41:06 +0100 [thread overview]
Message-ID: <Zuh7wtfajqRWoAFs@shell.armlinux.org.uk> (raw)
In-Reply-To: <ad0813aa-1a11-4a26-8bc7-528ef51cf0c2@lunn.ch>
On Thu, Sep 12, 2024 at 05:58:14PM +0200, Andrew Lunn wrote:
> > > > > > + if (adapter->is_pci11x1x && !adapter->is_sgmii_en &&
> > > > > > + adapter->is_sfp_support_en) {
> > > > > > + netif_err(adapter, drv, adapter->netdev,
> > > > > > + "Invalid eeprom cfg: sfp enabled with sgmii disabled");
> > > > > > + return -EINVAL;
> > > > >
> > > > > is_sgmii_en actually means PCS? An SFP might need 1000BaseX or
> > > > > SGMII,
> > > >
> > > > No, not really.
> > > > The PCI11010/PCI1414 chip can support either an RGMII interface or an
> > > > SGMII/1000Base-X/2500Base-X interface.
> > >
> > > A generic name for SGMII/1000Base-X/2500Base-X would be PCS, or maybe SERDES. To me, is_sgmii_en
> > > means SGMII is enabled, but in fact it actually means SGMII/1000Base-X/2500Base-X is enabled. I just
> > > think this is badly named. It would be more understandable if it was is_pcs_en.
> > >
> > > > According to the datasheet,
> > > > the "Strap Register (STRAP)" bit 6 is described as "SGMII_EN_STRAP"
> > > > Therefore, the flag is named "is_sgmii_en".
> > >
> > > Just because the datasheet uses a bad name does not mean the driver has to also use it.
> > >
> > > Andrew
> >
> > The hardware architect, who is a very bright guy (it's not me :-), just called the strap SGMII_EN in order not to make the name too long and to contrast it with the opposite polarity of the bit which means the interface is set to RGMII; but in the description of the strap he clearly stated what it is:
> > SGMII_EN_STRAP
> > 0 = RGMII
> > 1 = SGMII / 1000/2500BASE-X
> >
> > I don't think PCS or Serdes (both of which get used in other technologies - some of which are also included in this chip and are therefore bound to create even more confusion if used) are good choices either.
While I can understand the desire to name stuff as documentation names
it, just because documentation calls an apple a banana does not mean
that everyone who doesn't have the documentation will understand that
is_a_banana will be true for an apple.
This is the problem here. SGMII has two meanings (and thanks to the
network industry for creating this in the first place).
First, there is Cisco SGMII, an adaptation of IEEE 802.3 1000base-X.
Secondly, there is its use as "Serial gigabit media independent
interface" which various manufacturers seem to use to refer to their
serial network interface supporting both Cisco SGMII, 1000base-X and
2500base-X.
_That_ is exactly where the problem is. "SGMII" is ambiguous. One can
not even use much in the way of context to separate out which it's
referring to, and naming a variable "is_sgmii_en" just doesn't have
the context. This ambiguous nature adds to the kernel maintenance
burden for those of us who look after subsystems.
It is unfortunate that people continue not to recognise this as the
problem that it is, but everyone loves acronyms... and acronyms are
a way of talking in code that excludes people from discussions or
understanding.
So, consider this a formal request _not_ to name your variable
"is_sgmii_en" but something else.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2024-09-16 18:41 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-11 16:10 [PATCH net-next V2 0/5] Add support to SFP for PCI11x1x chips Raju Lakkaraju
2024-09-11 16:10 ` [PATCH net-next V2 1/5] net: lan743x: Add SFP support check flag Raju Lakkaraju
2024-09-11 16:44 ` Christophe JAILLET
2024-09-12 6:12 ` Raju Lakkaraju
2024-09-11 17:06 ` Andrew Lunn
2024-09-12 6:29 ` Raju Lakkaraju
2024-09-12 14:52 ` Andrew Lunn
2024-09-12 15:36 ` Ronnie.Kunin
2024-09-12 15:58 ` Andrew Lunn
2024-09-12 16:36 ` Ronnie.Kunin
2024-09-16 18:41 ` Russell King (Oracle) [this message]
2024-09-16 18:30 ` Russell King (Oracle)
2024-09-11 16:10 ` [PATCH net-next V2 2/5] net: lan743x: Add support to software-nodes for sfp Raju Lakkaraju
2024-09-11 16:54 ` Christophe JAILLET
2024-09-12 6:32 ` Raju Lakkaraju
2024-09-16 19:31 ` Russell King (Oracle)
2024-09-16 20:37 ` Andrew Lunn
2024-09-11 17:17 ` Andrew Lunn
2024-09-12 6:38 ` Raju Lakkaraju
2024-09-12 15:19 ` Andrew Lunn
2024-09-16 19:34 ` Russell King (Oracle)
2024-09-14 17:37 ` kernel test robot
2024-09-11 16:10 ` [PATCH net-next V2 3/5] net: lan743x: Register the platform device for sfp pluggable module Raju Lakkaraju
2024-09-15 2:16 ` kernel test robot
2024-09-11 16:10 ` [PATCH net-next V2 4/5] net: lan743x: Implement phylink pcs Raju Lakkaraju
2024-09-11 17:24 ` Maxime Chevallier
2024-09-12 6:46 ` Raju Lakkaraju
2024-09-11 17:26 ` Andrew Lunn
2024-09-12 6:53 ` Raju Lakkaraju
2024-09-12 15:28 ` Andrew Lunn
2024-09-12 16:04 ` Ronnie.Kunin
2024-09-12 16:13 ` Andrew Lunn
2024-09-12 18:51 ` Ronnie.Kunin
2024-09-12 19:37 ` Andrew Lunn
2024-09-13 8:54 ` Raju Lakkaraju - I30499
2024-09-13 13:19 ` Andrew Lunn
2024-09-13 14:23 ` Ronnie.Kunin
2024-09-13 15:03 ` Andrew Lunn
2024-09-13 22:53 ` Ronnie.Kunin
2024-09-14 14:39 ` Andrew Lunn
2024-09-11 16:10 ` [PATCH net-next V2 5/5] net: lan743x: Add Support for 2.5G SFP with 2500Base-X Interface Raju Lakkaraju
2024-09-11 17:31 ` Andrew Lunn
2024-09-11 20:01 ` Maxime Chevallier
2024-09-12 7:01 ` Raju Lakkaraju
2024-09-12 11:49 ` Maxime Chevallier
2024-09-12 7:04 ` Raju Lakkaraju
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=Zuh7wtfajqRWoAFs@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Bryan.Whitehead@microchip.com \
--cc=Daniel.Machon@microchip.com \
--cc=Raju.Lakkaraju@microchip.com \
--cc=Ronnie.Kunin@microchip.com \
--cc=Steen.Hegelund@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).