From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Christian Marangi <ansuelsmth@gmail.com>
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>,
Robert Marko <robimarko@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel test robot <lkp@intel.com>
Subject: Re: [net-next PATCH] net: phy: aquantia: drop wrong endianness conversion for addr and CRC
Date: Wed, 22 Nov 2023 17:24:33 +0000 [thread overview]
Message-ID: <ZV45UY6nYZ/WAHpG@shell.armlinux.org.uk> (raw)
In-Reply-To: <20231122170813.1222-1-ansuelsmth@gmail.com>
On Wed, Nov 22, 2023 at 06:08:13PM +0100, Christian Marangi wrote:
> On further testing on BE target with kernel test robot, it was notice
> that the endianness conversion for addr and CRC in fw_load_memory was
> wrong and actually not needed. Values in define doesn't get converted
> and are passed as is and hardcoded values are already in what the PHY
> require, that is LE.
>
> Also drop the cpu_to_be32 for CRC calculation as it's wrong and use
> _swab32 instead, the word is taked from firmware and is always LE, the
taken
> mailbox will emit a BE CRC hence the word needs to be always swapped and
> the endianness of the host needs to be ignored.
I'm not convinced. If the firmware is a bytestream (as most "files" are)
then for val = get_unaligned((u32 *)ptr), where ptr is an array of u8:
ptr[0] ptr[1] ptr[2] ptr[3] val on LE val on BE
0x01 0x02 0x03 0x04 0x04030201 0x01020304
So, endianness matters here, and I think as Jakub already suggested, you
need to use get_unaligned_le32().
> diff --git a/drivers/net/phy/aquantia/aquantia_firmware.c b/drivers/net/phy/aquantia/aquantia_firmware.c
> index c5f292b1c4c8..bd093633d0cf 100644
> --- a/drivers/net/phy/aquantia/aquantia_firmware.c
> +++ b/drivers/net/phy/aquantia/aquantia_firmware.c
> @@ -93,9 +93,9 @@ static int aqr_fw_load_memory(struct phy_device *phydev, u32 addr,
> u16 crc = 0, up_crc;
> size_t pos;
>
> - /* PHY expect addr in LE */
> - addr = (__force u32)cpu_to_le32(addr);
> -
> + /* PHY expect addr in LE. Hardcoded addr in defines are
> + * already in this format.
> + */
> phy_write_mmd(phydev, MDIO_MMD_VEND1,
> VEND1_GLOBAL_MAILBOX_INTERFACE1,
> VEND1_GLOBAL_MAILBOX_INTERFACE1_CRC_RESET);
> @@ -128,7 +128,7 @@ static int aqr_fw_load_memory(struct phy_device *phydev, u32 addr,
> * We convert word to big-endian as PHY is BE and mailbox will
> * return a BE CRC.
> */
> - word = (__force u32)cpu_to_be32(word);
> + word = __swab32(word);
> crc = crc_ccitt_false(crc, (u8 *)&word, sizeof(word));
Again, I think you need to be careful with the endianness here again.
From what I understand here, it seems the CRC needs to be generated by
looking at the byte at ptr[3] first, then ptr[2], ptr[1] and finally
ptr[0] ?
If that is the case, the problem is using __swab32() on LE will do the
job for you, but on BE machines, it will be wrong.
I would make this explicit:
u8 crc_data[4];
...
/* CRC is calculated using BE order */
crc_data[0] = word >> 24;
crc_data[1] = word >> 16;
crc_data[2] = word >> 8;
crc_data[3] = word;
crc = crc_ccitt_false(crc, crc_data, sizeof(crc_data));
which will be (a) completely unambiguous, and (b) completely
independent of the host endianness.
--
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:[~2023-11-22 17:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 17:08 [net-next PATCH] net: phy: aquantia: drop wrong endianness conversion for addr and CRC Christian Marangi
2023-11-22 17:24 ` Russell King (Oracle) [this message]
2023-11-22 17:53 ` Christian Marangi
2023-11-22 18:23 ` Jakub Kicinski
2023-11-22 18:39 ` Christian Marangi
2023-11-22 18:53 ` Russell King (Oracle)
2023-11-22 19:55 ` Christian Marangi
2023-11-22 20:25 ` Russell King (Oracle)
2023-11-22 21:09 ` Christian Marangi
2023-11-22 22:31 ` Russell King (Oracle)
2023-11-22 22:37 ` Christian Marangi
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=ZV45UY6nYZ/WAHpG@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robimarko@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.