| Message ID | 1465299013-32369-1-git-send-email-ben.dooks@codethink.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 7 June 2016 at 17:00, Ben Dooks <ben.dooks@codethink.co.uk> wrote: > Fix the use of 0 instead of NULL to clk_get() call. This stops the > following warning: > > drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer > > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> > --- > Cc: Jason Cooper <jason@lakedaemon.net> > Cc: Andrew Lunn <andrew@lunn.ch> > Cc: Gregory Clement <gregory.clement@free-electrons.com> > Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-pm@vger.kernel.org > Cc: linux-kernel@lists.codethink.co.uk > --- > drivers/cpufreq/mvebu-cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
On 07/06/2016 13:30, Ben Dooks wrote: > Fix the use of 0 instead of NULL to clk_get() call. This stops the > following warning: > > drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer May I ask which compiler/version produced that diagnostic? > - clk = clk_get(cpu_dev, 0); > + clk = clk_get(cpu_dev, NULL); Quoting C99 6.3.2.3 Pointers clause 3 > An integer constant expression with the value 0, or such an expression cast to type > void *, is called a null pointer constant. If a null pointer constant is converted to a > pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal > to a pointer to any object or function. In fact, some implementations merely #define NULL 0 (which, admittedly, creates problems when NULL is used as a parameter to variadic functions) Regards.
On 08/06/16 08:56, Mason wrote: > On 07/06/2016 13:30, Ben Dooks wrote: > >> Fix the use of 0 instead of NULL to clk_get() call. This stops the >> following warning: >> >> drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer > > May I ask which compiler/version produced that diagnostic? I was running with "make C=2 bzImage" for ARM multi_v7_config $ sparse --version v0.5.0
On Wednesday, June 8, 2016 9:59:26 AM CEST Ben Dooks wrote: > On 08/06/16 08:56, Mason wrote: > > On 07/06/2016 13:30, Ben Dooks wrote: > > > >> Fix the use of 0 instead of NULL to clk_get() call. This stops the > >> following warning: > >> > >> drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer > > > > May I ask which compiler/version produced that diagnostic? > > I was running with "make C=2 bzImage" for ARM multi_v7_config > > $ sparse --version > v0.5.0 > I believe gcc-6 will also produce a similar warning when building with 'make W=1'. I've started looking into moving some of the warnings from W=1 level to default, which can probably be done with relatively little effort for many warnings. I see that you are making very good progress at eliminating the -Wmissing-declarations warnings, which are also at W=1 level. Do you have an estimate of how many there are? Do you plan to do them all, or just the ones for some subsystems? I've stayed away from this one for now since there are lots of such warnings, but it seems particularly worthwhile. Arnd
On 09/06/2016 09:07, Arnd Bergmann wrote: > On Wednesday, June 8, 2016 9:59:26 AM CEST Ben Dooks wrote: >> On 08/06/16 08:56, Mason wrote: >>> On 07/06/2016 13:30, Ben Dooks wrote: >>> >>>> Fix the use of 0 instead of NULL to clk_get() call. This stops the >>>> following warning: >>>> >>>> drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer >>> >>> May I ask which compiler/version produced that diagnostic? >> >> I was running with "make C=2 bzImage" for ARM multi_v7_config >> >> $ sparse --version >> v0.5.0 Ben, in my nitpicker's opinion, your patch subject is not quite correct. There is, obviously, no cast in the statement clk = clk_get(cpu_dev, 0); There is, however, an implicit conversion (as if by assignment) which converts the second argument (a null pointer constant) to an actual null pointer. I can't find a better wording than "Use NULL instead of unadorned 0 for null pointer constants" or "Use NULL explicitly for pointer arguments" As a funky side note, any constant expression with the value 0 is a valid null pointer constant. Thus the expression 42/666 is a valid equivalent to NULL ;-) Another one of C's historic warts. > I believe gcc-6 will also produce a similar warning when building with > 'make W=1'. Probably not. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html -Wzero-as-null-pointer-constant (C++ and Objective-C++ only) Warn when a literal '0' is used as null pointer constant. This can be useful to facilitate the conversion to nullptr in C++11. $ cat test.c extern void foo(void *p); void bar(void) { foo(0); } $ gcc-6 -Wall -Wextra -c test.c /* NO WARNING */ $ gcc-6 -Wall -Wextra -Wzero-as-null-pointer-constant -c test.c cc1: warning: command line option '-Wzero-as-null-pointer-constant' is valid for C++/ObjC++ but not for C Regards.
On 09/06/16 08:07, Arnd Bergmann wrote: > On Wednesday, June 8, 2016 9:59:26 AM CEST Ben Dooks wrote: >> On 08/06/16 08:56, Mason wrote: >>> On 07/06/2016 13:30, Ben Dooks wrote: >>> >>>> Fix the use of 0 instead of NULL to clk_get() call. This stops the >>>> following warning: >>>> >>>> drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer >>> >>> May I ask which compiler/version produced that diagnostic? >> >> I was running with "make C=2 bzImage" for ARM multi_v7_config >> >> $ sparse --version >> v0.5.0 >> > > I believe gcc-6 will also produce a similar warning when building with > 'make W=1'. I've started looking into moving some of the warnings from > W=1 level to default, which can probably be done with relatively little > effort for many warnings. Would be interesting to see, I tried W=2 and W=3 and ended up with hundreds of MiB of logs. Out of interest, which other warnings do you think would make good next targets? > I see that you are making very good progress at eliminating the > -Wmissing-declarations warnings, which are also at W=1 level. Do > you have an estimate of how many there are? Do you plan to do them > all, or just the ones for some subsystems? I've stayed away from > this one for now since there are lots of such warnings, but it > seems particularly worthwhile. Yes, got bored so went at a lot of the warnings that sparse produces and may consider having a go with gcc6 now it is being packaged by Debian. I've been building with multi_v7_defconfig I may look at some of the other ARM configurations and build options in the next few days. So far i've got 61 fix patches for issues such as missing includes or people doing very silly things with pointers. The branch as of last night is now up at: git://git.codethink.co.uk/public/linux bjdooks/fixup_warnings Ben Dooks (61): mmc: dw_mmc: fix 32bit little-endian access of des1 field cpufreq: mvebu: fix integer to pointer cast watchdog: sirf: fix __iomem * warnings irqchip/sirfsoc: fix sparse warnings on __iomem irqchip/tegra: fix fix sparse warnings on __iomem iommu/exynos: update to use iommu big-endian clk: hi6220: fix missing clk.h include clk: ti: fapll: fix address space warnings clocksource/drivers/digicolor: fix warning of non-static function clocksource/drivers/armada-370-xp: make syscore_ops static dmaengine: ste_dma40_ll: make d40_width_to_bits static dmaengine: sirf: fix un-exported struct warnings dmaengine: at_xdmac: fix un-exported functions dmaengine: bcm2835: fix unexported function gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings clk: iproc: fix missing include of clk-iproc.h clk: at91: make of_sama5d2_clk_generated_setup() static ata: sata_mv: fix mis-conversion in mv_write_cached_reg() pinctrl: nsp-gpio: fix non-static functions pinctrl: at91-pio4: fix non-exported functions phy-sun4i-usb: fix missing __iomem * pinctrl: sh-pfc: fix warnings by include core.h regulator: twl: fix use of integer as pointer ARM: bcm2835: remove unused __packet soc: brcmstb: fix warning from missing include serial: sirf: make fifo functions static serial: sirf: make uart register info static tty: serial: msm: fix definition of msm_stop_dma USB: core: fix missing include <linux/usb/of.h> net-sysfs: fix missing <linux/of_net.h> mvebu: fix missing includes in pmsu.c mvebu: fix missing include of common.h in pm.c mvebu: fix missing include of common.h in cpu-reset.c mvebu: make mvebu_armada375_smp_wa_init() static mvebu: add definition for coherency_base pinctrl: nomadik: fix warnings from unexported functions ARM: make unexported functions static arm: dma-mapping: make unexported items static ARM: bcm: fix missing include of kona_l2_cache.h ARM: tegra: irq: fix missing include of irq.h ARM: tegra: fix missing include <soc/tegra/cpuidle.h> ARM: tegra: fix missing include of cpuidle.h ARM: tegra: fix missing common.h include vexpress/spc: fix missing include of spc.h ARM: vexpress: fix missing core.h include ARM: versatile: fix missing <plat/platsmp.h> include ARM: imx: fix missing includes ARM: imx: fix missing include of common.h ARM: imx: fix missing cpuidle.h include EDAC: make dev_attr_sdram_scrub_rate static irqchip/bcm2836: make bcm2836_smp_boot_secondary static irqchip/omap-intc: fix missing <linux/irqchip/irq-omap-intc.h> include irqchip/gic-v2m: fix missing include of <linux/irqchip/arm-gic.h> irqchip/armada-370-xp: make syscore_ops static irqchip/bcm7120-l2: make probe functions static irqchip/brcmstb-l2: make of probe function static mfd: omap-usb-tll: fix include of omap-usb.h mmc: mmci: add missing include of mmci_qcom_dml.h stmmac: fix parameter to dwmac4_set_umac_addr() power: vexpress: make dev_attr_active static power/reset: make syscon_poweroff() static
On Thursday, June 9, 2016 9:11:38 AM CEST Ben Dooks wrote: > On 09/06/16 08:07, Arnd Bergmann wrote: > > On Wednesday, June 8, 2016 9:59:26 AM CEST Ben Dooks wrote: > >> On 08/06/16 08:56, Mason wrote: > >>> On 07/06/2016 13:30, Ben Dooks wrote: > >>> > >>>> Fix the use of 0 instead of NULL to clk_get() call. This stops the > >>>> following warning: > >>>> > >>>> drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer > >>> > >>> May I ask which compiler/version produced that diagnostic? > >> > >> I was running with "make C=2 bzImage" for ARM multi_v7_config > >> > >> $ sparse --version > >> v0.5.0 > >> > > > > I believe gcc-6 will also produce a similar warning when building with > > 'make W=1'. I've started looking into moving some of the warnings from > > W=1 level to default, which can probably be done with relatively little > > effort for many warnings. > > Would be interesting to see, I tried W=2 and W=3 and ended up with > hundreds of MiB of logs. > > Out of interest, which other warnings do you think would make good > next targets? I fixed all the bugs for -Wmissing-include-dirs, -Woverride-init, -Wold-style-declaration, -Wempty-body (not sure about submitting this one), -Wunused-but-set-parameter and -Wignored-qualifiers. With the above fixed, we can enable -Wextra after disabling -Wtype-limits (though I fixed the files that had many occurrences of that), -Wno-unused-parameter, -Wsign-compare and and -Wmissing-field-initializers, all of which should stay in W=1 level. Arnd
On Tuesday, June 07, 2016 07:10:17 PM Viresh Kumar wrote: > On 7 June 2016 at 17:00, Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > Fix the use of 0 instead of NULL to clk_get() call. This stops the > > following warning: > > > > drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer > > > > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> > > --- > > Cc: Jason Cooper <jason@lakedaemon.net> > > Cc: Andrew Lunn <andrew@lunn.ch> > > Cc: Gregory Clement <gregory.clement@free-electrons.com> > > Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > > Cc: Viresh Kumar <viresh.kumar@linaro.org> > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-pm@vger.kernel.org > > Cc: linux-kernel@lists.codethink.co.uk > > --- > > drivers/cpufreq/mvebu-cpufreq.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Applied, thanks!
diff --git a/drivers/cpufreq/mvebu-cpufreq.c b/drivers/cpufreq/mvebu-cpufreq.c index e920889..ed915ee 100644 --- a/drivers/cpufreq/mvebu-cpufreq.c +++ b/drivers/cpufreq/mvebu-cpufreq.c @@ -70,7 +70,7 @@ static int __init armada_xp_pmsu_cpufreq_init(void) continue; } - clk = clk_get(cpu_dev, 0); + clk = clk_get(cpu_dev, NULL); if (IS_ERR(clk)) { pr_err("Cannot get clock for CPU %d\n", cpu); return PTR_ERR(clk);
Fix the use of 0 instead of NULL to clk_get() call. This stops the following warning: drivers/cpufreq/mvebu-cpufreq.c:73:40: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> --- Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-pm@vger.kernel.org Cc: linux-kernel@lists.codethink.co.uk --- drivers/cpufreq/mvebu-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)