[PATCH] cpufreq: mvebu: fix integer to pointer cast

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[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 <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 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(-)

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);
-- 
2.8.1

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Viresh Kumar]

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 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(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Rafael J. Wysocki]

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 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(-)
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Applied, thanks!

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Mason]

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.

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Ben Dooks]

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 Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Arnd Bergmann]

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

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Mason]

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.

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Ben Dooks]

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



-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

[PATCH] cpufreq: mvebu: fix integer to pointer cast

[Arnd Bergmann]

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