netdev - Re: [PATCH net-next v10 1/8] hinic3: Async Event Queue interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250723081908.GW2459@horms.kernel.org>
Date: Wed, 23 Jul 2025 09:19:08 +0100
From: Simon Horman <horms@...nel.org>
To: Fan Gong <gongfan1@...wei.com>
Cc: Zhu Yikai <zhuyikai1@...artners.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, linux-doc@...r.kernel.org,
	Jonathan Corbet <corbet@....net>,
	Bjorn Helgaas <helgaas@...nel.org>, luosifu <luosifu@...wei.com>,
	Xin Guo <guoxin09@...wei.com>,
	Shen Chenyang <shenchenyang1@...ilicon.com>,
	Zhou Shuai <zhoushuai28@...wei.com>, Wu Like <wulike1@...wei.com>,
	Shi Jing <shijing34@...wei.com>,
	Fu Guiming <fuguiming@...artners.com>,
	Meny Yossefi <meny.yossefi@...wei.com>,
	Gur Stavi <gur.stavi@...wei.com>, Lee Trager <lee@...ger.us>,
	Michael Ellerman <mpe@...erman.id.au>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Suman Ghosh <sumang@...vell.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Joe Damato <jdamato@...tly.com>,
	Christophe JAILLET <christophe.jaillet@...adoo.fr>
Subject: Re: [PATCH net-next v10 1/8] hinic3: Async Event Queue interfaces

On Tue, Jul 22, 2025 at 03:18:40PM +0800, Fan Gong wrote:
> Add async event queue interfaces initialization.
> It allows driver to handle async events reported by HW.
> 
> Co-developed-by: Xin Guo <guoxin09@...wei.com>
> Signed-off-by: Xin Guo <guoxin09@...wei.com>
> Co-developed-by: Zhu Yikai <zhuyikai1@...artners.com>
> Signed-off-by: Zhu Yikai <zhuyikai1@...artners.com>
> Signed-off-by: Fan Gong <gongfan1@...wei.com>

...

> diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_common.c b/drivers/net/ethernet/huawei/hinic3/hinic3_common.c
> index 0aa42068728c..a5aaf6febba9 100644
> --- a/drivers/net/ethernet/huawei/hinic3/hinic3_common.c
> +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_common.c
> @@ -51,3 +51,16 @@ void hinic3_dma_free_coherent_align(struct device *dev,
>  	dma_free_coherent(dev, mem_align->real_size,
>  			  mem_align->ori_vaddr, mem_align->ori_paddr);
>  }
> +
> +/* Data provided to/by cmdq is arranged in structs with little endian fields but
> + * every dword (32bits) should be swapped since HW swaps it again when it
> + * copies it from/to host memory.
> + */

This scheme may work on little endian hosts.
But if so it seems unlikely to work on big endian hosts.

I expect you want be32_to_cpu_array() for data coming from hw,
with a source buffer as an array of __be32 while
the destination buffer is an array of u32.

And cpu_to_be32_array() for data going to the hw,
with the types of the source and destination buffers reversed.

If those types don't match your data, then we have
a framework to have that discussion.


That said, it is more usual for drivers to keep structures in the byte
order they are received. Stored in structures with members with types, in
this case it seems that would be __be32, and accessed using a combination
of BIT/GENMASK, FIELD_PREP/FIELD_GET, and cpu_to_be*/be*_to_cpu (in this
case cpu_to_be32/be32_to_cpu).

An advantage of this approach is that the byte order of
data is only changed when needed. Another is that it is clear
what the byte order of data is.

> +void hinic3_cmdq_buf_swab32(void *data, int len)
> +{
> +	u32 *mem = data;
> +	u32 i;
> +
> +	for (i = 0; i < len / sizeof(u32); i++)
> +		mem[i] = swab32(mem[i]);
> +}

This seems to open code swab32_array().

...