linux-kernel - Re: [net-next 1/4] Octeontx2-af: Add programmed macaddr to RVU pfvf

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250717123118.GB27043@horms.kernel.org>
Date: Thu, 17 Jul 2025 13:31:18 +0100
From: Simon Horman <horms@...nel.org>
To: Hariprasad Kelam <hkelam@...vell.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kuba@...nel.org,
	davem@...emloft.net, sgoutham@...vell.com, gakula@...vell.com,
	jerinj@...vell.com, lcherian@...vell.com, sbhatta@...vell.com,
	naveenm@...vell.com, edumazet@...gle.com, pabeni@...hat.com,
	andrew+netdev@...n.ch, bbhushan2@...vell.com
Subject: Re: [net-next 1/4] Octeontx2-af: Add programmed macaddr to RVU pfvf

On Wed, Jul 16, 2025 at 10:11:55PM +0530, Hariprasad Kelam wrote:
> Octeontx2/CN10k MAC block supports DMAC filters. DMAC filters
> can be installed on the interface through ethtool.
> 
> When a user installs a DMAC filter, the interface's MAC address
> is implicitly added to the filter list. To ensure consistency,
> this MAC address must be kept in sync with the pfvf->mac_addr field,
> which is used to install MAC-based NPC rules.
> 
> This patch updates the pfvf->mac_addr field with the programmed MAC
> address and also enables VF interfaces to install DMAC filters.
> 
> Signed-off-by: Hariprasad Kelam <hkelam@...vell.com>
> ---
>  .../ethernet/marvell/octeontx2/af/rvu_cgx.c   | 23 ++++++++-----------
>  1 file changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> index 890a1a5df2de..dd589f9b10da 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> @@ -682,16 +682,19 @@ int rvu_mbox_handler_cgx_mac_addr_set(struct rvu *rvu,
>  				      struct cgx_mac_addr_set_or_get *rsp)
>  {
>  	int pf = rvu_get_pf(rvu->pdev, req->hdr.pcifunc);
> +	struct rvu_pfvf *pfvf;
>  	u8 cgx_id, lmac_id;
>  
> -	if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
> -		return -EPERM;
> +	if (!is_pf_cgxmapped(rvu, pf))
> +		return LMAC_AF_ERR_PF_NOT_MAPPED;
>  
>  	if (rvu_npc_exact_has_match_table(rvu))
>  		return rvu_npc_exact_mac_addr_set(rvu, req, rsp);
>  
>  	rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
>  
> +	pfvf = &rvu->pf[pf];
> +	memcpy(pfvf->mac_addr, req->mac_addr, ETH_ALEN);

nit: I think ether_addr_copy() can be used here.

>  	cgx_lmac_addr_set(cgx_id, lmac_id, req->mac_addr);
>  
>  	return 0;
> @@ -769,20 +772,12 @@ int rvu_mbox_handler_cgx_mac_addr_get(struct rvu *rvu,
>  				      struct cgx_mac_addr_set_or_get *req,
>  				      struct cgx_mac_addr_set_or_get *rsp)
>  {
> -	int pf = rvu_get_pf(rvu->pdev, req->hdr.pcifunc);
> -	u8 cgx_id, lmac_id;
> -	int rc = 0;
> -	u64 cfg;
> +	struct rvu_pfvf *pfvf = rvu_get_pfvf(rvu, req->hdr.pcifunc);
>  
> -	if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
> -		return -EPERM;
> -
> -	rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
> +	if (!is_pf_cgxmapped(rvu, rvu_get_pf(rvu->pdev, req->hdr.pcifunc)))
> +		return LMAC_AF_ERR_PF_NOT_MAPPED;
>  
> -	rsp->hdr.rc = rc;
> -	cfg = cgx_lmac_addr_get(cgx_id, lmac_id);
> -	/* copy 48 bit mac address to req->mac_addr */
> -	u64_to_ether_addr(cfg, rsp->mac_addr);
> +	memcpy(rsp->mac_addr, pfvf->mac_addr, ETH_ALEN);

Ditto.

>  	return 0;
>  }
>  
> -- 
> 2.34.1
> 
>