Thread (24 messages) flat view 24 messages, 3 authors, 2021-05-26

Re: [RFC PATCH v2 linux-next 03/14] net: dsa: sja1105: the 0x1F0000 SGMII "base address" is actually MDIO_MMD_VEND2

From: Vladimir Oltean <olteanv@gmail.com>
Date: 2021-05-26 15:34:53

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:
quoted
-	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).

In this case, the "addr" is passed to the "u64 reg_addr" parameter of
sja1105_xfer_u32, which ends up being packed into bits 24:4 of the SPI
message header in sja1105_spi_message_pack().

You might ask: is the SPI address simply derived from (mmd << 16 | pcs_reg)?
The answer is yes, I'm a bit surprised by that too. The PCS doesn't
overlap with other SPI memory regions because only 2 MMDs are implemented
(this is explained in the commit message).

I would probably reconsider some things if I were to write the driver
again, including some accessors which are more streamlined than packing(),
but currently this is what we have.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help