lkml.org 
[lkml]   [2023]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [net-next PATCH] net: phy: aquantia: make mailbox interface4 lsw addr mask more specific
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

\
 
 \ /
  Last update: 2023-11-22 01:04    [W:0.035 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site