Re: [net-next PATCH] net: phy: aquantia: make mailbox interface4 lsw addr mask more specific

[Christian Marangi <ansuelsmth@gmail.com>]

On Tue, Nov 21, 2023 at 03:58:12PM -0800, Jakub Kicinski wrote:
> On Wed, 22 Nov 2023 00:48:01 +0100 Christian Marangi wrote:
> > > Not so sure about this one, it puts the u32 on the stack, and takes 
> > > the address of it:
> > > 
> > > 	u32 word;
> > > 
> > > 	word = (__force u32)cpu_to_be32(word);
> > > 	crc = crc_ccitt_false(crc, (u8 *)&word, sizeof(word));
> > > 
> > > so the endian will matter here. My guess is that this part is correct.  
> 
> Actually I'm wrong about this, you're reading and writing the data,
> so endian conversion happens twice. Canceling itself out.
> 
> > Ehhh this is problematic. Data comes from nvmem or filesystem, in theory
> > they should not be touched/converted.
> > 
> > nvmem_cell_read or request_firmware return pointer to u8 and it's the
> > firmware (that is always in LE)
> > 
> > If data is not converted and passed AS IS from what is read to the
> > allocated data, then data should be always swapped.
> > (this PHY is fun... it's probably BE internally but expect LE stuff in
> > the mailbox, as it does emit BE CRC.)
> > 
> > Any idea where I can verify if nvmem_cell_read or request_firmware makes
> > any kind of endianess conversion on the data it does read?
> 
> The underlying storage should be byte-accessible, so neither interface
> should change anything about the endian.
> 
> You should probably switch get_unaligned_le32() for reading it into 
> the word variable, tho.

I don't need to read it, I need to pass the data directly from what is
read to mailbox so using get_unaligned_le32 would actually make a
conversion. Anyway thanks a lot for putting some extra words and make me
check this further! Will send a v2 tomorrow!

-- 
	Ansuel