All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Marangi <ansuelsmth@gmail.com>
To: Simon Horman <horms@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Robert Marko <robimarko@gmail.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [net-next RFC PATCH v6 3/4] net: phy: aquantia: add firmware load support
Date: Fri, 10 Nov 2023 23:28:36 +0100	[thread overview]
Message-ID: <654eae99.df0a0220.14db7.0cb8@mx.google.com> (raw)
In-Reply-To: <20231110195628.GA673918@kernel.org>

On Fri, Nov 10, 2023 at 07:57:02PM +0000, Simon Horman wrote:
> On Thu, Nov 09, 2023 at 01:32:52PM +0100, Christian Marangi wrote:
> > From: Robert Marko <robimarko@gmail.com>
> > 
> > Aquantia PHY-s require firmware to be loaded before they start operating.
> > It can be automatically loaded in case when there is a SPI-NOR connected
> > to Aquantia PHY-s or can be loaded from the host via MDIO.
> > 
> > This patch adds support for loading the firmware via MDIO as in most cases
> > there is no SPI-NOR being used to save on cost.
> > Firmware loading code itself is ported from mainline U-boot with cleanups.
> > 
> > The firmware has mixed values both in big and little endian.
> > PHY core itself is big-endian but it expects values to be in little-endian.
> > The firmware is little-endian but CRC-16 value for it is stored at the end
> > of firmware in big-endian.
> > 
> > It seems the PHY does the conversion internally from firmware that is
> > little-endian to the PHY that is big-endian on using the mailbox
> > but mailbox returns a big-endian CRC-16 to verify the written data
> > integrity.
> > 
> > Co-developed-by: Christian Marangi <ansuelsmth@gmail.com>
> > Signed-off-by: Robert Marko <robimarko@gmail.com>
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> 
> Hi Christian and Robert,
> 
> thanks for your patch-set.
> 
> I spotted some minor endien issues which I have highlighted below.
> 
> ...
>

Hi Simon,

thanks for the check!

> > +/* load data into the phy's memory */
> > +static int aqr_fw_load_memory(struct phy_device *phydev, u32 addr,
> > +			      const u8 *data, size_t len)
> > +{
> > +	u16 crc = 0, up_crc;
> > +	size_t pos;
> > +
> > +	/* PHY expect addr in LE */
> > +	addr = cpu_to_le32(addr);
> 
> The type of addr is host byte-order,
> but here it is assigned a little-endian value.
> 
> Flagged by Sparse.
> 
> > +
> > +	phy_write_mmd(phydev, MDIO_MMD_VEND1,
> > +		      VEND1_GLOBAL_MAILBOX_INTERFACE1,
> > +		      VEND1_GLOBAL_MAILBOX_INTERFACE1_CRC_RESET);
> > +	phy_write_mmd(phydev, MDIO_MMD_VEND1,
> > +		      VEND1_GLOBAL_MAILBOX_INTERFACE3,
> > +		      VEND1_GLOBAL_MAILBOX_INTERFACE3_MSW_ADDR(addr));
> 
> VEND1_GLOBAL_MAILBOX_INTERFACE3_MSW_ADDR() performs a bit-shift on addr,
> and applies a mask which is in host-byte order.
> But, as highlighted above, addr is a little-endian value.
> This does not seem right.
>

It's really just some magic to split the addr and swap if we are not
in little-endian. The passed addr are defined here in the code and are
hardcoded, they doesn't come from the firmware. What I can do is just
recast __le32 to u32 again with __force to mute the warning...

Resulting in this snippet:

	__le32 addr;
	size_t pos;

	/* PHY expect addr in LE */
	addr = cpu_to_le32(load_addr);

	phy_write_mmd(phydev, MDIO_MMD_VEND1,
		      VEND1_GLOBAL_MAILBOX_INTERFACE1,
		      VEND1_GLOBAL_MAILBOX_INTERFACE1_CRC_RESET);
	phy_write_mmd(phydev, MDIO_MMD_VEND1,
		      VEND1_GLOBAL_MAILBOX_INTERFACE3,
		      VEND1_GLOBAL_MAILBOX_INTERFACE3_MSW_ADDR((__force u32)addr));
	phy_write_mmd(phydev, MDIO_MMD_VEND1,
		      VEND1_GLOBAL_MAILBOX_INTERFACE4,
		      VEND1_GLOBAL_MAILBOX_INTERFACE4_LSW_ADDR((__force u32)addr));

Also things needs to be casted to u16 anyway as phy_write_mmd expect a
u16. And as you said FILED_PREP will use int (from the define) so I
wonder if a more clean way would be just addr = (__force u32)cpu_to_le32(load_addr)
resulting in a simple bswap32 if we are in big-endian.

Would love some feedback about this.

> This is all hidden by a cast in VEND1_GLOBAL_MAILBOX_INTERFACE3_MSW_ADDR()
> This seems dangerous to me.
> 
> 
> > +	phy_write_mmd(phydev, MDIO_MMD_VEND1,
> > +		      VEND1_GLOBAL_MAILBOX_INTERFACE4,
> > +		      VEND1_GLOBAL_MAILBOX_INTERFACE4_LSW_ADDR(addr));
> 
> There seem to be similar issues with the use of addr here.
> 
> > +
> > +	/* We assume and enforce the size to be word aligned.
> > +	 * If a firmware that is not word aligned is found, please report upstream.
> > +	 */
> > +	for (pos = 0; pos < len; pos += sizeof(u32)) {
> > +		u32 word = get_unaligned((const u32 *)(data + pos));
> > +
> > +		phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE5,
> > +			      VEND1_GLOBAL_MAILBOX_INTERFACE5_MSW_DATA(word));
> > +		phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE6,
> > +			      VEND1_GLOBAL_MAILBOX_INTERFACE6_LSW_DATA(word));
> > +
> > +		phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_GLOBAL_MAILBOX_INTERFACE1,
> > +			      VEND1_GLOBAL_MAILBOX_INTERFACE1_EXECUTE |
> > +			      VEND1_GLOBAL_MAILBOX_INTERFACE1_WRITE);
> > +
> > +		/* calculate CRC as we load data to the mailbox.
> > +		 * We convert word to big-endiang as PHY is BE and mailbox will
> > +		 * return a BE CRC.
> > +		 */
> > +		word = cpu_to_be32(word);
> 
> Similarly here, Sparse flags that a little-endian value is assigned to a
> host byte-order variable.
> 

Same here, I'm solving by declaring a new __be32 variable but in
crc_ccitt_false the thing needs to be casted anyway, doesn't that makes
the check useless?

> > +		crc = crc_ccitt_false(crc, (u8 *)&word, sizeof(word));
> > +	}
> 
> ...
> 
> pw-bot: changes-requested

-- 
	Ansuel

  reply	other threads:[~2023-11-10 22:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09 12:32 [net-next RFC PATCH v6 1/4] net: phy: aquantia: move to separate directory Christian Marangi
2023-11-09 12:32 ` [net-next RFC PATCH v6 2/4] net: phy: aquantia: move MMD_VEND define to header Christian Marangi
2023-11-09 12:32 ` [net-next RFC PATCH v6 3/4] net: phy: aquantia: add firmware load support Christian Marangi
2023-11-10  0:16   ` Andrew Lunn
2023-11-10 19:57   ` Simon Horman
2023-11-10 22:28     ` Christian Marangi [this message]
2023-11-11 15:46       ` Andrew Lunn
2023-11-11 18:16         ` Christian Marangi
2023-11-11 18:44           ` Christian Marangi
2023-11-11 18:29   ` Christophe JAILLET
2023-11-09 12:32 ` [net-next RFC PATCH v6 4/4] dt-bindings: Document Marvell Aquantia PHY Christian Marangi
2023-11-10 20:15   ` Rob Herring
2023-11-10  0:12 ` [net-next RFC PATCH v6 1/4] net: phy: aquantia: move to separate directory 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=654eae99.df0a0220.14db7.0cb8@mx.google.com \
    --to=ansuelsmth@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=robimarko@gmail.com \
    --cc=vladimir.oltean@nxp.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.