Re: [net-next PATCH v2] octeontx2-af: fix build warnings flagged by clang, sparse ,kernel test robot

[Simon Horman]

On Wed, Mar 05, 2025 at 03:16:23PM +0530, Sai Krishna wrote:
> This cleanup patch avoids build warnings flagged by clang,
> sparse, kernel test robot.
> 
> Warning reported by clang:
> drivers/net/ethernet/marvell/octeontx2/af/rvu.c:2993:47:
> warning: arithmetic between different enumeration types
> ('enum rvu_af_int_vec_e' and 'enum rvu_pf_int_vec_e')
> [-Wenum-enum-conversion]
>  2993 | return (pfvf->msix.max >= RVU_AF_INT_VEC_CNT +
> RVU_PF_INT_VEC_CNT) &&

Hi Sai,

I think it would be good to address each set of errors in separate patches.
And in each case include a report of the errors the tools reported.

And I think that the subject(s) could be tightened up a bit.
E.g.:

	Subject: octeontx2-af: correct __iomem annotations

	Sparse flags a number of inconsistent usage of __iomem annotations:

	  .../otx2_pf.c:611:24: sparse:     expected void [noderef] __iomem *hwbase
          .../otx2_pf.c:611:24: sparse:     got void *
          .../otx2_pf.c:620:56: sparse: sparse: cast removes address space '__iomem' of expression
          .../otx2_pf.c:671:35: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *addr @@     got void *hwbase @@
          .../otx2_pf.c:671:35: sparse:     expected void volatile [noderef] __iomem *addr
          .../otx2_pf.c:671:35: sparse:     got void *hwbase
          .../otx2_pf.c:1344:21: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected unsigned long long [usertype] *ptr @@     got void [noderef] __iomem * @@
          .../otx2_pf.c:1344:21: sparse:     expected unsigned long long [usertype] *ptr
          .../otx2_pf.c:1344:21: sparse:     got void [noderef] __iomem *
          .../otx2_pf.c:1383:21: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected unsigned long long [usertype] *ptr @@     got void [noderef] __iomem * @@
          .../otx2_pf.c:1383:21: sparse:     expected unsigned long long [usertype] *ptr
          .../otx2_pf.c:1383:21: sparse:     got void [noderef] __iomem *
          .../otx2_pf.c: note: in included file (through .../mbox.h, .../otx2_common.h):

	Address this by, ...

	Reported-by: ...
	...

> 
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202410221614.07o9QVjo-lkp@xxxxxxxxx/
> Signed-off-by: Sai Krishna <saikrishnag@xxxxxxxxxxx>
> ---
>  drivers/net/ethernet/marvell/octeontx2/af/common.h |  2 +-
>  drivers/net/ethernet/marvell/octeontx2/af/rvu.c    | 14 ++++++++------
>  .../ethernet/marvell/octeontx2/nic/otx2_common.c   | 10 +++++-----
>  .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c   |  9 ++++-----
>  4 files changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/common.h b/drivers/net/ethernet/marvell/octeontx2/af/common.h
> index 406c59100a35..8a08bebf08c2 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/common.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/common.h
> @@ -39,7 +39,7 @@ struct qmem {
>  	void            *base;
>  	dma_addr_t	iova;
>  	int		alloc_sz;
> -	u16		entry_sz;
> +	u32		entry_sz;
>  	u8		align;
>  	u32		qsize;
>  };

Further to my point above, I am unsure what problem this is addressing.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> index cd0d7b7774f1..c850ea5d1960 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> @@ -591,7 +591,7 @@ static void rvu_check_min_msix_vec(struct rvu *rvu, int nvecs, int pf, int vf)
>  
>  check_pf:
>  	if (pf == 0)
> -		min_vecs = RVU_AF_INT_VEC_CNT + RVU_PF_INT_VEC_CNT;
> +		min_vecs = (int)RVU_AF_INT_VEC_CNT + (int)RVU_PF_INT_VEC_CNT;
>  	else
>  		min_vecs = RVU_PF_INT_VEC_CNT;
>  

I think that in the light of Linus's feedback and the subsequent patch
that demoted -Wenum-enum-conversion from W=1 to W=1 this is not necessary.

[1] https://lore.kernel.org/all/CAHk-=wjMux0w49bTdSbC3DOoc9FRctDrRvaqFUS4KFTmkbtKWg@xxxxxxxxxxxxxx/
[2] 8f6629c004b1 ("kbuild: Move -Wenum-enum-conversion to W=2")

> @@ -819,13 +819,14 @@ static int rvu_fwdata_init(struct rvu *rvu)
>  		goto fail;
>  
>  	BUILD_BUG_ON(offsetof(struct rvu_fwdata, cgx_fw_data) > FWDATA_CGX_LMAC_OFFSET);
> -	rvu->fwdata = ioremap_wc(fwdbase, sizeof(struct rvu_fwdata));
> +	rvu->fwdata = (__force struct rvu_fwdata *)
> +		ioremap_wc(fwdbase, sizeof(struct rvu_fwdata));

I am concerned that this and similar changes in this patch are masking
problems. In my view __iomem annotations are there for a reason, to help
use the correct access mechanism for iomem. So my question is why is that
not the case for fwdata?

Similarly for other cases in this patch where __iomem is cast or cast-away.

...