Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Message-ID: <655d41b4.050a0220.36e34.359e@mx.google.com>
Date:   Wed, 22 Nov 2023 00:48:01 +0100
From:   Christian Marangi <ansuelsmth@gmail.com>
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        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: make mailbox interface4 lsw
 addr mask more specific
References: <20231120193504.5922-1-ansuelsmth@gmail.com>
 <20231121150859.7f934627@kernel.org>
 <655d3e2b.df0a0220.50550.b235@mx.google.com>
 <20231121153918.4234973d@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231121153918.4234973d@kernel.org>
Precedence: bulk

On Tue, Nov 21, 2023 at 03:39:18PM -0800, Jakub Kicinski wrote:
> On Wed, 22 Nov 2023 00:32:56 +0100 Christian Marangi wrote:
> > the 2 addr comes from a define
> > 
> > #define DRAM_BASE_ADDR		0x3FFE0000
> > #define IRAM_BASE_ADDR		0x40000000
> > 
> > it wasn't clear to me if on BE these addrs gets saved differently or
> > not. PHY wants the addr in LE.
> > 
> > On testing by removing the cpu_to_le32 the error is correctly removed!
> > 
> > I guess on BE the addr was actually swapped and FIELD_GET was correctly
> > warning (and failing) as data was missing in applying the mask.
> 
> I think so. It's the responsibility of whether underlies 
> phy_write_mmd() to make sure the data is put on the bus in
> correct order (but that's still just within the u16 boundaries,
> splitting a constant into u16 halves is not endian dependent).
> 
> > If all of this makes sense, will send a followup patch that drop the
> > cpu_to_le32 and also the other in the bottom that does cpu_to_be32 (to a
> > __swab32 as FW is LE and mailbox calculate CRC in BE)
> 
> 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.

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?

-- 
	Ansuel