Skip to contentSkip to conversation

cpufreq: mvebu: fix integer to pointer cast

PATCH New Ben Dooks 5 participants 9 messages Jun 7, 2016 – Jun 14, 2016

Subsystems (2)
CPU frequency scaling framework Arm/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SoC support
lore
Share & tools
lore

Ben Dooks

author
#0 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

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 <[email protected]>

---
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Gregory Clement <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pm at vger.kernel.org
Cc: linux-kernel at lists.codethink.co.uk

---
 drivers/cpufreq/mvebu-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/cpufreq/mvebu-cpufreq.c +1 -1
index e920889..ed915ee 100644
@@ -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);
Signature · 1 line
2.8.1
maintainer
#1 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

Quoted 16 lines · Ben Dooks

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 <[email protected]>

---
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Gregory Clement <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pm at vger.kernel.org
Cc: linux-kernel at lists.codethink.co.uk

Quoted 3 lines
---
 drivers/cpufreq/mvebu-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by Viresh Kumar <[email protected]>
Applied
#2 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

Quoted 21 lines · Viresh Kumar
Quoted 16 lines · Ben Dooks

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 <[email protected]>

---
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Gregory Clement <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]

Quoted 3 lines
---
 drivers/cpufreq/mvebu-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Quoted 1 line
Acked-by Viresh Kumar <[email protected]>

Applied, thanks!

#3 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

In reply to Ben Dooks
Quoted 4 lines · Ben Dooks

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?

drivers/cpufreq/mvebu-cpufreq.c static int __init armada_xp_pmsu_cpufreq_init(void) · line 73

Quoted 2 lines
drivers/cpufreq/mvebu-cpufreq.c +1 -1
-		clk = clk_get(cpu_dev, 0);
+		clk = clk_get(cpu_dev, NULL);

Quoting C99 6.3.2.3 Pointers clause 3

Quoted 4 lines

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.

author
#4 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

Quoted 8 lines · Mason
Quoted 4 lines · Ben Dooks

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
Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#5 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

Quoted 6 lines · CEST Ben Dooks
Quoted 5 lines · Mason
Quoted 3 lines · Ben Dooks

Fix the use of 0 instead of NULL to clk_get() call. This stops the following warning:

Quoted 9 lines
Quoted 3 lines
Quoted 1 line

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

#6 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

Quoted 7 lines · Arnd Bergmann
Quoted 6 lines · CEST Ben Dooks
Quoted 5 lines · Mason
Quoted 3 lines · Ben Dooks

Fix the use of 0 instead of NULL to clk_get() call. This stops the following warning:

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 2 lines

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.

author
#7 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

In reply to Arnd Bergmann
Quoted 13 lines · Arnd Bergmann
Quoted 12 lines · CEST Ben Dooks
Quoted 8 lines · Mason
Quoted 4 lines · Ben Dooks

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

Quoted 8 lines
Quoted 3 lines
$ 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?

Quoted 6 lines

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

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#8 lore raw

PATCH 1/1 cpufreq: mvebu: fix integer to pointer cast

Quoted 23 lines · CEST Ben Dooks
Quoted 13 lines · Arnd Bergmann
Quoted 12 lines · CEST Ben Dooks
Quoted 8 lines · Mason
Quoted 4 lines · Ben Dooks

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

Quoted 8 lines
Quoted 3 lines
$ 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.

Quoted 5 lines

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