[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <504c2c6ba951859cbd007cfd441dde7de1a8f479.camel@redhat.com>
Date: Tue, 17 Jan 2023 09:04:52 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Hao Lan <lanhao@...wei.com>, kuba@...nel.org,
Leon Romanovsky <leon@...nel.org>
Cc: yisen.zhuang@...wei.com, salil.mehta@...wei.com,
edumazet@...gle.com, richardcochran@...il.com,
shenjian15@...wei.com, wangjie125@...wei.com,
netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH net-next 2/2] net: hns3: add vf fault process in hns3 ras
Hello,
On Fri, 2023-01-13 at 10:08 +0800, Hao Lan wrote:
[...]
> +static void hclge_get_vf_fault_bitmap(struct hclge_desc *desc,
> + unsigned long *bitmap)
> +{
> +#define HCLGE_FIR_FAULT_BYTES 24
> +#define HCLGE_SEC_FAULT_BYTES 8
> +
> + u8 *buff;
> +
> + memcpy(bitmap, desc[0].data, HCLGE_FIR_FAULT_BYTES);
> + buff = (u8 *)bitmap + HCLGE_FIR_FAULT_BYTES;
> + memcpy(buff, desc[1].data, HCLGE_SEC_FAULT_BYTES);
> +}
The above works under the assumption that:
HCLGE_FIR_FAULT_BYTES + HCLGE_SEC_FAULT_BYTES == BITS_TO_BYTES(HCLGE_VPORT_NUM)
I think it's better to enforce such condition at build time with a
BUILD_BUG_ON(), to avoid future issues.
Also I think Leon still deserve a reply to one of his questions,
specifically: What will happen (at recovery time) with driver bound to
this VF?
Thanks!
Paolo
Powered by blists - more mailing lists