[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7009d4cc-a008-49ea-8f50-1e9aec63b592@lunn.ch>
Date: Tue, 11 Mar 2025 22:22:16 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Sai Krishna <saikrishnag@...vell.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, sgoutham@...vell.com,
gakula@...vell.com, lcherian@...vell.com, jerinj@...vell.com,
hkelam@...vell.com, sbhatta@...vell.com, andrew+netdev@...n.ch,
bbhushan2@...vell.com, nathan@...nel.org, ndesaulniers@...gle.com,
morbo@...gle.com, justinstitt@...gle.com, llvm@...ts.linux.dev,
horms@...nel.org, kernel test robot <lkp@...el.com>
Subject: Re: [net-next PATCH v3 1/2] octeontx2-af: correct __iomem
annotations flagged by Sparse
> if (mbox->mbox.hwbase)
> - iounmap(mbox->mbox.hwbase);
> + iounmap((void __iomem *)mbox->mbox.hwbase);
This looks wrong. If you are unmapping it, you must of mapped it
somewhere. And that mapping would of returned an __iomem value. So
mbox.hwbase should be an __iomem value and you would not need this
cast.
> for (qidx = 0; qidx < pf->qset.cq_cnt; qidx++) {
> - ptr = otx2_get_regaddr(pf, NIX_LF_CQ_OP_INT);
> + ptr = (__force u64 *)otx2_get_regaddr(pf, NIX_LF_CQ_OP_INT);
> val = otx2_atomic64_add((qidx << 44), ptr);
This also looks questionable. You should be removing casts, not adding
them. otx2_get_regaddr() returns an __iomem. So maybe
otx2_atomic64_add() is actually broken here?
Andrew
---
pw-bot: cr
Powered by blists - more mailing lists