netdev - Re: [PATCH net-next v01 1/9] hinic3: Add PF framework

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] [day] [month] [year] [list]

Message-ID: <aP9CwKkLdgcqHvkc@horms.kernel.org>
Date: Mon, 27 Oct 2025 10:00:32 +0000
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>,
	Luo Yang <luoyang82@...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 v01 1/9] hinic3: Add PF framework

On Wed, Oct 15, 2025 at 03:15:27PM +0800, Fan Gong wrote:
> Add support for PF framework based on the VF code.
> 
> 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_nic_cfg.c b/drivers/net/ethernet/huawei/hinic3/hinic3_nic_cfg.c
> index 979f47ca77f9..2b93026845ff 100644
> --- a/drivers/net/ethernet/huawei/hinic3/hinic3_nic_cfg.c
> +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_nic_cfg.c
> @@ -117,17 +117,49 @@ int hinic3_set_port_mtu(struct net_device *netdev, u16 new_mtu)
>  					 &func_tbl_cfg);
>  }
>  
> +#define PF_SET_VF_MAC(hwdev, status) \
> +	(HINIC3_IS_VF(hwdev) && (status) == HINIC3_PF_SET_VF_ALREADY)
> +

nit: I think the above could be a function rather than a macro.

...

> @@ -157,9 +189,9 @@ int hinic3_set_mac(struct hinic3_hwdev *hwdev, const u8 *mac_addr, u16 vlan_id,
>  		return -EIO;
>  	}
>  
> -	if (mac_info.msg_head.status == MGMT_STATUS_PF_SET_VF_ALREADY) {
> +	if (PF_SET_VF_MAC(hwdev, mac_info.msg_head.status)) {
>  		dev_warn(hwdev->dev, "PF has already set VF mac, Ignore set operation\n");
> -		return 0;
> +		return HINIC3_PF_SET_VF_ALREADY;

It seems to me that this custom return value can be propagated up
and returned by the probe function. If so, this doesn't seem desirable.
And, overall, I would recommend against the custom calling convention
that custom return values imply.

>  	}
>  
>  	if (mac_info.msg_head.status == MGMT_STATUS_EXIST) {

...