From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, Florian Fainelli <f.fainelli@gmail.com>,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [RFC PATCH v2 linux-next 03/14] net: dsa: sja1105: the 0x1F0000 SGMII "base address" is actually MDIO_MMD_VEND2
Date: Wed, 26 May 2021 16:42:18 +0100 [thread overview]
Message-ID: <20210526154218.GI30436@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210526153447.yjgbj5uhxxnvxvbs@skbuf>
On Wed, May 26, 2021 at 06:34:47PM +0300, Vladimir Oltean wrote:
> Hi Russell,
>
> On Wed, May 26, 2021 at 04:24:54PM +0100, Russell King (Oracle) wrote:
> > On Wed, May 26, 2021 at 04:55:24PM +0300, Vladimir Oltean wrote:
> > > - const struct sja1105_regs *regs = priv->info->regs;
> > > + u64 addr = (mmd << 16) | pcs_reg;
> >
> > What is the reason for using "u64" here. pcs_reg is 16-bits, and mmd is
> > five bits, which is well below 32 bits. So, why not u32?
>
> The "addr" variable holds a SPI address, and in the sja1105 driver, the
> SPI addresses are universally held in u64 variables, mainly because of
> the packing() API (Documentation/core-api/packing.rst).
As you are passing it into a function, the argument of which is a u64,
the compiler will promote the u32 to a u64 by itself. I guess it
doesn't actually matter, but the current code just looks really weird.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-05-26 15:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 13:55 [RFC PATCH v2 linux-next 00/14] Add NXP SJA1110 support to the sja1105 DSA driver Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 01/14] net: dsa: sja1105: be compatible with "ethernet-ports" OF node name Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 02/14] net: dsa: sja1105: allow SGMII PCS configuration to be per port Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 03/14] net: dsa: sja1105: the 0x1F0000 SGMII "base address" is actually MDIO_MMD_VEND2 Vladimir Oltean
2021-05-26 15:24 ` Russell King (Oracle)
2021-05-26 15:34 ` Vladimir Oltean
2021-05-26 15:42 ` Russell King (Oracle) [this message]
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 04/14] net: dsa: sja1105: cache the phy-mode port property Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 05/14] net: dsa: sja1105: add a PHY interface type compatibility matrix Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 06/14] net: dsa: sja1105: add a translation table for port speeds Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 07/14] net: dsa: sja1105: always keep RGMII ports in the MAC role Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 08/14] net: dsa: sja1105: some table entries are always present when read dynamically Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 09/14] dt-bindings: net: dsa: sja1105: convert to YAML schema Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 10/14] dt-bindings: net: dsa: sja1105: add SJA1110 bindings Vladimir Oltean
2021-05-26 14:19 ` Rob Herring
2021-05-26 14:25 ` Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 11/14] net: dsa: sja1105: add support for the SJA1110 switch family Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 12/14] net: dsa: sja1105: register the MDIO buses for 100base-T1 and 100base-TX Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 13/14] net: dsa: sja1105: expose the SGMII PCS as an mdio_device Vladimir Oltean
2021-05-26 15:29 ` Russell King (Oracle)
2021-05-26 15:41 ` Vladimir Oltean
2021-05-26 15:46 ` Russell King (Oracle)
2021-05-26 21:26 ` Vladimir Oltean
2021-05-26 13:55 ` [RFC PATCH v2 linux-next 14/14] net: dsa: sja1105: add support for the SJA1110 SGMII/2500base-x PCS Vladimir Oltean
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=20210526154218.GI30436@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.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.