Messages in this thread | | | From | Masahiro Yamada <> | Date | Sat, 21 Oct 2017 01:08:01 +0900 | Subject | Re: [PATCH 03/12] nvmem: mtk-efuse: fix different address space warnings of sparse |
| |
2017-10-20 23:49 GMT+09:00 Greg KH <gregkh@linuxfoundation.org>: > On Fri, Oct 20, 2017 at 10:55:04PM +0900, Masahiro Yamada wrote: >> 2017-10-20 22:34 GMT+09:00 Greg KH <gregkh@linuxfoundation.org>: >> > On Mon, Oct 09, 2017 at 03:26:32PM +0200, srinivas.kandagatla@linaro.org wrote: >> >> From: Masahiro Yamada <yamada.masahiro@socionext.com> >> >> >> >> Fix the following sparse warnings: >> >> >> >> drivers/nvmem/mtk-efuse.c:24:30: warning: incorrect type in initializer (different address spaces) >> >> drivers/nvmem/mtk-efuse.c:24:30: expected void [noderef] <asn:2>*base >> >> drivers/nvmem/mtk-efuse.c:24:30: got void *context >> >> drivers/nvmem/mtk-efuse.c:37:30: warning: incorrect type in initializer (different address spaces) >> >> drivers/nvmem/mtk-efuse.c:37:30: expected void [noderef] <asn:2>*base >> >> drivers/nvmem/mtk-efuse.c:37:30: got void *context >> >> drivers/nvmem/mtk-efuse.c:69:23: warning: incorrect type in assignment (different address spaces) >> >> drivers/nvmem/mtk-efuse.c:69:23: expected void *priv >> >> drivers/nvmem/mtk-efuse.c:69:23: got void [noderef] <asn:2>*[assigned] base >> >> >> >> The type of nvmem_config->priv is (void *), so sparse complains >> >> about assignment of the base address with (void __iomem *) type. >> >> >> >> Even if we cast it out, sparse still warns: >> >> warning: cast removes address space of expression >> >> >> >> Of course, we can shut up the sparse by marking __force, but a more >> >> correct way is to put the base address into driver private data. >> > >> > Ick, no, really? >> > >> > That's horrid. Do the __force cast as that is what you are really doing >> > here, and it is good to see the bad use of it (hint, perhaps the api >> > needs to be fixed up so you do not have to do that???) >> >> >> Other drivers take private data from the "void *context". >> >> In this driver, the priv just happens to have one member. >> What's the matter? >> >> >> >> >> >> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c >> >> index fa7a0f66b37e..c4058b598703 100644 >> >> --- a/drivers/nvmem/mtk-efuse.c >> >> +++ b/drivers/nvmem/mtk-efuse.c >> >> @@ -18,15 +18,19 @@ >> >> #include <linux/nvmem-provider.h> >> >> #include <linux/platform_device.h> >> >> >> >> +struct mtk_efuse_priv { >> >> + void __iomem *base; >> >> +}; >> >> + >> >> static int mtk_reg_read(void *context, >> > >> > >> > Make the read call take a __iomem *, not a random void *. That should >> > solve this issue, right? >> > >> >> NACK. >> >> See drivers/nvmem/imx-iim.c >> >> The ->reg_read hook needs more private data than __iomem *. > > Ok, that makes a bit more sense, but it still feels a bit of a hack, > don't you agree?
But, I have no choice but __force.
I disagree with using __force to hide things.
In my opinion, __force should be used only where it is really legitimate.
This driver is not the case, as we can fix it by writing correct code.
-- Best Regards Masahiro Yamada
| |