linux-next: build failure after merge of the arm tree

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

Hi Russell,

After merging the arm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/linux/bitops.h:36:0,
                 from include/linux/bitmap.h:7,
                 from drivers/dma/sun4i-dma.c:11:
drivers/dma/sun4i-dma.c: In function 'find_and_use_pchan':
include/linux/bitops.h:56:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
  for ((bit) = find_next_zero_bit((addr), (size), (bit)); \
                                  ^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
 #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
                                                             ^
drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
  for_each_clear_bit_from(i, &priv->pchans_used, max) {
  ^
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
 extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
            ^
include/linux/bitops.h:58:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
       (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
                                  ^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
 #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
                                                             ^
drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
  for_each_clear_bit_from(i, &priv->pchans_used, max) {
  ^
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
 extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
            ^

Caused (or exposed) by commit

  c4f8ff16b46b ("ARM: 8669/1: bitops: Align prototypes to generic API")

I have used the arm tree from next-20170420 for today.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the arm tree

[Mason]

On 21/04/2017 00:40, Stephen Rothwell wrote:

> After merging the arm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/linux/bitops.h:36:0,
>                  from include/linux/bitmap.h:7,
>                  from drivers/dma/sun4i-dma.c:11:
> drivers/dma/sun4i-dma.c: In function 'find_and_use_pchan':
> include/linux/bitops.h:56:34: error:
> passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
>   for ((bit) = find_next_zero_bit((addr), (size), (bit)); \
>                                   ^
> arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
>  #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
>                                                              ^
> drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
>   for_each_clear_bit_from(i, &priv->pchans_used, max) {
>   ^
> arch/arm/include/asm/bitops.h:163:12: note:
> expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
>  extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
>             ^
> [...]
> 
> Caused (or exposed) by commit
> 
>   c4f8ff16b46b ("ARM: 8669/1: bitops: Align prototypes to generic API")
> 
> I have used the arm tree from next-20170420 for today.

Weird that I didn't catch this when I ran make allyesconfig.
https://www.spinics.net/lists/arm-kernel/msg573736.html

Anyway, the fix is trivial.

The "pchans_used" field is an unsigned long array.
for_each_clear_bit_from() expects an unsigned long pointer,
not an array address.

I'll send a patch to the drivers/dma maintainers.

$ make C=2 drivers/dma/sun4i-dma.o
  CHECK   drivers/dma/sun4i-dma.c
  CC      drivers/dma/sun4i-dma.o

Regards.

[PATCH] dmaengine: sun4i: fix invalid argument

[Mason]

The "pchans_used" field is an unsigned long array.

for_each_clear_bit_from() expects an unsigned long pointer,
not an array address.

$ make C=2 drivers/dma/sun4i-dma.o
  CHECK   drivers/dma/sun4i-dma.c
drivers/dma/sun4i-dma.c:241:9: warning: incorrect type in argument 1 (different base types)
drivers/dma/sun4i-dma.c:241:9:    expected unsigned long const *p
drivers/dma/sun4i-dma.c:241:9:    got unsigned long ( *<noident> )[1]

Signed-off-by: Mason <slash.tmp@free.fr>
---
 drivers/dma/sun4i-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c
index 57aa227bfadb..f4ed3f17607c 100644
--- a/drivers/dma/sun4i-dma.c
+++ b/drivers/dma/sun4i-dma.c
@@ -238,7 +238,7 @@ static struct sun4i_dma_pchan *find_and_use_pchan(struct sun4i_dma_dev *priv,
 	}
 
 	spin_lock_irqsave(&priv->lock, flags);
-	for_each_clear_bit_from(i, &priv->pchans_used, max) {
+	for_each_clear_bit_from(i, priv->pchans_used, max) {
 		pchan = &pchans[i];
 		pchan->vchan = vchan;
 		set_bit(i, priv->pchans_used);
-- 
3.14159

Re: [PATCH] dmaengine: sun4i: fix invalid argument

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Fri, Apr 21, 2017 at 10:06:10AM +0200, Mason wrote:
> The "pchans_used" field is an unsigned long array.
> 
> for_each_clear_bit_from() expects an unsigned long pointer,
> not an array address.
> 
> $ make C=2 drivers/dma/sun4i-dma.o
>   CHECK   drivers/dma/sun4i-dma.c
> drivers/dma/sun4i-dma.c:241:9: warning: incorrect type in argument 1 (different base types)
> drivers/dma/sun4i-dma.c:241:9:    expected unsigned long const *p
> drivers/dma/sun4i-dma.c:241:9:    got unsigned long ( *<noident> )[1]

The patch looks good...

> Signed-off-by: Mason <slash.tmp@free.fr>

However this doesn't.

See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[PATCH v2] dmaengine: sun4i: fix invalid argument

[Mason]

From: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>

The "pchans_used" field is an unsigned long array.

for_each_clear_bit_from() expects an unsigned long pointer,
not an array address.

$ make C=2 drivers/dma/sun4i-dma.o
  CHECK   drivers/dma/sun4i-dma.c
drivers/dma/sun4i-dma.c:241:9: warning: incorrect type in argument 1 (different base types)
drivers/dma/sun4i-dma.c:241:9:    expected unsigned long const *p
drivers/dma/sun4i-dma.c:241:9:    got unsigned long ( *<noident> )[1]

Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
---
 drivers/dma/sun4i-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c
index 57aa227bfadb..f4ed3f17607c 100644
--- a/drivers/dma/sun4i-dma.c
+++ b/drivers/dma/sun4i-dma.c
@@ -238,7 +238,7 @@ static struct sun4i_dma_pchan *find_and_use_pchan(struct sun4i_dma_dev *priv,
 	}
 
 	spin_lock_irqsave(&priv->lock, flags);
-	for_each_clear_bit_from(i, &priv->pchans_used, max) {
+	for_each_clear_bit_from(i, priv->pchans_used, max) {
 		pchan = &pchans[i];
 		pchan->vchan = vchan;
 		set_bit(i, priv->pchans_used);
-- 
3.14159

Re: [PATCH v2] dmaengine: sun4i: fix invalid argument

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Fri, Apr 21, 2017 at 10:43:20AM +0200, Mason wrote:
> From: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> 
> The "pchans_used" field is an unsigned long array.
> 
> for_each_clear_bit_from() expects an unsigned long pointer,
> not an array address.
> 
> $ make C=2 drivers/dma/sun4i-dma.o
>   CHECK   drivers/dma/sun4i-dma.c
> drivers/dma/sun4i-dma.c:241:9: warning: incorrect type in argument 1 (different base types)
> drivers/dma/sun4i-dma.c:241:9:    expected unsigned long const *p
> drivers/dma/sun4i-dma.c:241:9:    got unsigned long ( *<noident> )[1]
> 
> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

Hi Mason,

On Fri, 21 Apr 2017 09:58:58 +0200 Mason <slash.tmp@free.fr> wrote:
>
> Anyway, the fix is trivial.
> 
> The "pchans_used" field is an unsigned long array.
> for_each_clear_bit_from() expects an unsigned long pointer,
> not an array address.
> 
> I'll send a patch to the drivers/dma maintainers.

The fix really needs to go into the arm tree (as well?) since that is
the tree that has the patch that causes the build to break (even if the
actual bug was preexisting).

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the arm tree

[Mason]

On 21/04/2017 10:12, Stephen Rothwell wrote:

> Mason wrote:
>
>> Anyway, the fix is trivial.
>>
>> The "pchans_used" field is an unsigned long array.
>> for_each_clear_bit_from() expects an unsigned long pointer,
>> not an array address.
>>
>> I'll send a patch to the drivers/dma maintainers.
> 
> The fix really needs to go into the arm tree (as well?) since that is
> the tree that has the patch that causes the build to break (even if the
> actual bug was preexisting).

Hello Stephen,

Since it's a trivial patch, and since Vinod is on vacation
until Monday, I suppose Russell could push the patch through
his own tree? (Maybe after an ACK from a sunxi maintainer.)

I am currently building an allyesconfig next-20170420 kernel.
Considering the speed of this system, this will take a while.

Regards.

Re: linux-next: build failure after merge of the arm tree

[Russell King - ARM Linux]

On Fri, Apr 21, 2017 at 06:12:30PM +1000, Stephen Rothwell wrote:
> Hi Mason,
> 
> On Fri, 21 Apr 2017 09:58:58 +0200 Mason <slash.tmp@free.fr> wrote:
> >
> > Anyway, the fix is trivial.
> > 
> > The "pchans_used" field is an unsigned long array.
> > for_each_clear_bit_from() expects an unsigned long pointer,
> > not an array address.
> > 
> > I'll send a patch to the drivers/dma maintainers.
> 
> The fix really needs to go into the arm tree (as well?) since that is
> the tree that has the patch that causes the build to break (even if the
> actual bug was preexisting).

Or I drop the offending patch (done) and we get the DMA subsystem fixed
first.  Given how long it's been this way, I doubt there's any hurry to
get this change in for the next merge window.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: linux-next: build failure after merge of the arm tree

[Mason]

On 22/04/2017 01:43, Russell King - ARM Linux wrote:

> Or I drop the offending patch (done) and we get the DMA subsystem fixed
> first.  Given how long it's been this way, I doubt there's any hurry to
> get this change in for the next merge window.

Your solution makes sense.

Vinod, could you apply [PATCH v2] dmaengine: sun4i: fix invalid argument
to your tree when you have the time?

Regards.

Re: linux-next: build failure after merge of the arm tree

[Vinod Koul]

On Sat, Apr 22, 2017 at 10:41:37AM +0200, Mason wrote:
> On 22/04/2017 01:43, Russell King - ARM Linux wrote:
> 
> > Or I drop the offending patch (done) and we get the DMA subsystem fixed
> > first.  Given how long it's been this way, I doubt there's any hurry to
> > get this change in for the next merge window.
> 
> Your solution makes sense.
> 
> Vinod, could you apply [PATCH v2] dmaengine: sun4i: fix invalid argument
> to your tree when you have the time?

Done now..

-- 
~Vinod

[PATCH v2] arm: bitops: Align prototypes to generic API

[Mason]

From: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>

include/asm-generic/bitops/find.h declares:

extern unsigned long
find_first_zero_bit(const unsigned long *addr, unsigned long size);

while arch/arm/include/asm/bitops.h declares:

#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
extern int _find_first_zero_bit_le(const void * p, unsigned size);

Align the arm prototypes to the generic API, to have gcc report
inadequate arguments, such as pointer to u32.

Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
---
The patch fixing drivers/dma/sun4i-dma.c
("dmaengine: sun4i: fix invalid argument")
has landed on linux-next (thanks Vinod)
as 57192245bc074710ea1a128d39ecc429455ac815
---
 arch/arm/include/asm/bitops.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index e943e6cee254..f308c8c40cb9 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -159,16 +159,16 @@ extern int _test_and_change_bit(int nr, volatile unsigned long * p);
 /*
  * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
  */
-extern int _find_first_zero_bit_le(const void * p, unsigned size);
-extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_zero_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
 extern int _find_first_bit_le(const unsigned long *p, unsigned size);
 extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
 
 /*
  * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
  */
-extern int _find_first_zero_bit_be(const void * p, unsigned size);
-extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_zero_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_zero_bit_be(const unsigned long *p, int size, int offset);
 extern int _find_first_bit_be(const unsigned long *p, unsigned size);
 extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
 
-- 
2.11.0

Re: linux-next: build failure after merge of the arm tree

[Mason]

On 22/04/2017 01:43, Russell King - ARM Linux wrote:
> On Fri, Apr 21, 2017 at 06:12:30PM +1000, Stephen Rothwell wrote:
>> Hi Mason,
>>
>> On Fri, 21 Apr 2017 09:58:58 +0200 Mason <slash.tmp@free.fr> wrote:
>>>
>>> Anyway, the fix is trivial.
>>>
>>> The "pchans_used" field is an unsigned long array.
>>> for_each_clear_bit_from() expects an unsigned long pointer,
>>> not an array address.
>>>
>>> I'll send a patch to the drivers/dma maintainers.
>>
>> The fix really needs to go into the arm tree (as well?) since that is
>> the tree that has the patch that causes the build to break (even if the
>> actual bug was preexisting).
> 
> Or I drop the offending patch (done) and we get the DMA subsystem fixed
> first.  Given how long it's been this way, I doubt there's any hurry to
> get this change in for the next merge window.

Hello Russell,

Is it safe to apply the patch now?
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8679/1

Regards.

Re: linux-next: build failure after merge of the arm tree

[Mason]

On 21/04/2017 09:58, Mason wrote:

> Weird that I didn't catch this when I ran make allyesconfig.

Doh! make allyesconfig builds for BE systems.

CONFIG_CPU_BIG_ENDIAN=y
CONFIG_CPU_ENDIAN_BE8=y

But the patch I originally tested with only updated the LE bitops.

With the complete patch, I didn't see any build issues, other than
drivers/dma/sun4i-dma.c

Regards.

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

Hi all,

After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/clk/clkdev.c: In function 'vclkdev_alloc':
drivers/clk/clkdev.c:195:16: error: assignment to '__va_list_tag (*)[1]' from incompatible pointer type '__va_list_tag **' [-Werror=incompatible-pointer-types]
  195 |         fmt.va = ≈
      |                ^
cc1: all warnings being treated as errors

Caused by commit

  5d998425e37b ("clkdev: report over-sized strings when creating clkdev entries")

I have used the arm tree from next-20240502 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the arm tree

[Russell King (Oracle)]

On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/clk/clkdev.c: In function 'vclkdev_alloc':
> drivers/clk/clkdev.c:195:16: error: assignment to '__va_list_tag (*)[1]' from incompatible pointer type '__va_list_tag **' [-Werror=incompatible-pointer-types]
>   195 |         fmt.va = ≈
>       |                ^
> cc1: all warnings being treated as errors

This builds perfectly fine for me - this is on debian stable with
arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110:

  CC      drivers/clk/clkdev.o
  AR      drivers/clk/built-in.a
  AR      drivers/built-in.a
  AR      built-in.a
  AR      vmlinux.a
  LD      vmlinux.o
  OBJCOPY modules.builtin.modinfo
  GEN     modules.builtin
  MODPOST Module.symvers
  UPD     include/generated/utsversion.h
  CC      init/version-timestamp.o
  LD      .tmp_vmlinux.kallsyms1
  NM      .tmp_vmlinux.kallsyms1.syms
  KSYMS   .tmp_vmlinux.kallsyms1.S
  AS      .tmp_vmlinux.kallsyms1.S
  LD      .tmp_vmlinux.kallsyms2
  NM      .tmp_vmlinux.kallsyms2.syms
  KSYMS   .tmp_vmlinux.kallsyms2.S
  AS      .tmp_vmlinux.kallsyms2.S
  LD      vmlinux
  NM      System.map

No warnings, no errors.

va_format is defined as:

struct va_format {
        const char *fmt;
        va_list *va;
};

and what we have here is a "va_list ap".

Therefore, the assignment:

        fmt.va = ≈

is correct.

What certainly won't work is:

	fmt.va = ap;

and there aren't any other reasonable alternatives.

My conclusion: your compiler is being stupid.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: linux-next: build failure after merge of the arm tree

[Russell King (Oracle)]

On Fri, May 03, 2024 at 09:18:01AM +0100, Russell King (Oracle) wrote:
> On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/clk/clkdev.c: In function 'vclkdev_alloc':
> > drivers/clk/clkdev.c:195:16: error: assignment to '__va_list_tag (*)[1]' from incompatible pointer type '__va_list_tag **' [-Werror=incompatible-pointer-types]
> >   195 |         fmt.va = ≈
> >       |                ^
> > cc1: all warnings being treated as errors
> 
> This builds perfectly fine for me - this is on debian stable with
> arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110:
> 
>   CC      drivers/clk/clkdev.o
>   AR      drivers/clk/built-in.a
>   AR      drivers/built-in.a
>   AR      built-in.a
>   AR      vmlinux.a
>   LD      vmlinux.o
>   OBJCOPY modules.builtin.modinfo
>   GEN     modules.builtin
>   MODPOST Module.symvers
>   UPD     include/generated/utsversion.h
>   CC      init/version-timestamp.o
>   LD      .tmp_vmlinux.kallsyms1
>   NM      .tmp_vmlinux.kallsyms1.syms
>   KSYMS   .tmp_vmlinux.kallsyms1.S
>   AS      .tmp_vmlinux.kallsyms1.S
>   LD      .tmp_vmlinux.kallsyms2
>   NM      .tmp_vmlinux.kallsyms2.syms
>   KSYMS   .tmp_vmlinux.kallsyms2.S
>   AS      .tmp_vmlinux.kallsyms2.S
>   LD      vmlinux
>   NM      System.map
> 
> No warnings, no errors.
> 
> va_format is defined as:
> 
> struct va_format {
>         const char *fmt;
>         va_list *va;
> };
> 
> and what we have here is a "va_list ap".
> 
> Therefore, the assignment:
> 
>         fmt.va = ≈
> 
> is correct.
> 
> What certainly won't work is:
> 
> 	fmt.va = ap;
> 
> and there aren't any other reasonable alternatives.
> 
> My conclusion: your compiler is being stupid.

... and even more evidence that your error is strange:

void __ext4_error(struct super_block *sb, const char *function,
                  unsigned int line, bool force_ro, int error, __u64 block,
                  const char *fmt, ...)
{
        struct va_format vaf;
        va_list args;

                vaf.fmt = fmt;
                vaf.va = &args;

Now, looking at __ext4_error(), it seems that va_start()..va_end()
need to be around this - but why this oddity? None of the other printing
functions like vsnprintf() require it? Why do we have this pitfall?
Why isn't this oddity documented anywhere?

However, I don't see that lack of va_start() etc would cause a type
error.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

Hi Russell,

On Fri, 3 May 2024 09:18:00 +0100 "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
>
> On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> > 
> > After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/clk/clkdev.c: In function 'vclkdev_alloc':
> > drivers/clk/clkdev.c:195:16: error: assignment to '__va_list_tag (*)[1]' from incompatible pointer type '__va_list_tag **' [-Werror=incompatible-pointer-types]
> >   195 |         fmt.va = &ap;
> >       |                ^
> > cc1: all warnings being treated as errors  
> 
> This builds perfectly fine for me - this is on debian stable with
> arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110:
> 
> No warnings, no errors.
> 
> va_format is defined as:
> 
> struct va_format {
>         const char *fmt;
>         va_list *va;
> };
> 
> and what we have here is a "va_list ap".
> 
> Therefore, the assignment:
> 
>         fmt.va = &ap;
> 
> is correct.
> 
> What certainly won't work is:
> 
> 	fmt.va = ap;
> 
> and there aren't any other reasonable alternatives.
> 
> My conclusion: your compiler is being stupid.

Definitely possible.  My build is an x86_64 allmodconfig cross build
hosted on PowerPC64LE.

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 13.2.0-7) 13.2.0

It still fails for me even just building your tree.  :-(

And if I revert commit 5d998425e37b it does not fail (of course).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the arm tree

[Russell King (Oracle)]

On Fri, May 03, 2024 at 10:08:26PM +1000, Stephen Rothwell wrote:
> Hi Russell,
> 
> On Fri, 3 May 2024 09:18:00 +0100 "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> >
> > On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > drivers/clk/clkdev.c: In function 'vclkdev_alloc':
> > > drivers/clk/clkdev.c:195:16: error: assignment to '__va_list_tag (*)[1]' from incompatible pointer type '__va_list_tag **' [-Werror=incompatible-pointer-types]
> > >   195 |         fmt.va = &ap;
> > >       |                ^
> > > cc1: all warnings being treated as errors  
> > 
> > This builds perfectly fine for me - this is on debian stable with
> > arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110:
> > 
> > No warnings, no errors.
> > 
> > va_format is defined as:
> > 
> > struct va_format {
> >         const char *fmt;
> >         va_list *va;
> > };
> > 
> > and what we have here is a "va_list ap".
> > 
> > Therefore, the assignment:
> > 
> >         fmt.va = &ap;
> > 
> > is correct.
> > 
> > What certainly won't work is:
> > 
> > 	fmt.va = ap;
> > 
> > and there aren't any other reasonable alternatives.
> > 
> > My conclusion: your compiler is being stupid.
> 
> Definitely possible.  My build is an x86_64 allmodconfig cross build
> hosted on PowerPC64LE.
> 
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 13.2.0-7) 13.2.0
> 
> It still fails for me even just building your tree.  :-(
> 
> And if I revert commit 5d998425e37b it does not fail (of course).

So I think the questions are...

1) why does this fail with this compiler?

2) why does this instance fail, when we have plenty of other instances
in the kernel doing the same thing? (grep vaf fs/)

I'm wrong about the va_start()/va_end() - those are done in the
caller, e.g. clkdev_create() does the va_start..va_end before
passing the va_list to vclkdev_create() which then passes it down
to vclkdev_alloc(). So it would be wrong to add another va_start()
in vclkdev_alloc().

The only thing I can think of doing is something like:

#ifdef CONFIg_X86_64
	pr_error("%s:%s ID is greater than %zu\n",
		 "[compiler error - unreportable device]",
        	 con_id, failure, max_size);
#else
	{
		struct va_format fmt;
	        fmt.fmt = dev_fmt;
	        fmt.va = &ap;
	        pr_err("%pV:%s: %s ID is greater than %zu\n",
        	       &fmt, con_id, failure, max_size);
	}
#endif
	kfree(cla);
	return NULL;

which would be better than nothing... but really we shouldn't be
working around what looks to me like a compiler bug like this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Hi all,

After merging the arm tree, today's linux-next build (quite a few
including arm allnoconfig clang-16, arm allnoconfig gcc-10) failed
like this:

ld.lld: error: undefined symbol: phys_initrd_start
   or
init.c:(.init.text+0xd4): undefined reference to `phys_initrd_start'

Caused by commit

  b35b2736b43d ("ARM: 9230/1: Support initrd with address in boot alias region")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the arm tree

[Matija Glavinic Pecotic]

Hi,

On 31.08.2022 11:10, Stephen Rothwell wrote:
> After merging the arm tree, today's linux-next build (quite a few
> including arm allnoconfig clang-16, arm allnoconfig gcc-10) failed
> like this:
> 
> ld.lld: error: undefined symbol: phys_initrd_start
>    or
> init.c:(.init.text+0xd4): undefined reference to `phys_initrd_start'
> 
> Caused by commit
> 
>   b35b2736b43d ("ARM: 9230/1: Support initrd with address in boot alias region")

my apologies for that, I missed to test with CONFIG_BLK_DEV_INITRD=n

I've seen Russell dropping patch already, hopefully update will
soon follow.

Regards,

Matija

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

Hi all,

After merging the arm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from <command-line>:
arch/arm/mm/mmu.c: In function 'early_fixmap_init':
include/linux/compiler_types.h:328:38: error: call to '__compiletime_assert_295' declared with attribute error: BUILD_BUG_ON failed: (__fix_to_virt(__end_of_fixmap_region) >> PMD_SHIFT) != FIXADDR_TOP >> PMD_SHIFT
  328 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |                                      ^
include/linux/compiler_types.h:309:4: note: in definition of macro '__compiletime_assert'
  309 |    prefix ## suffix();    \
      |    ^~~~~~
include/linux/compiler_types.h:328:2: note: in expansion of macro '_compiletime_assert'
  328 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |  ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
      |                                     ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
   50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
      |  ^~~~~~~~~~~~~~~~
arch/arm/mm/mmu.c:372:2: note: in expansion of macro 'BUILD_BUG_ON'
  372 |  BUILD_BUG_ON((__fix_to_virt(__end_of_fixmap_region) >> PMD_SHIFT)
      |  ^~~~~~~~~~~~

Exposed by commit

  9b89a073e1ca ("ARM: 9149/1: add BUILD_BUG_ON to check if fixmap range spans multiple pmds")

I have no idea why that BUILD_BUG_ON hits, so I have just reverted that
commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

Hi all,

After merging the arm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:


Caused by commit

  e3a0e1427dcb ("ARM: 8953/1: decompressor: simplify libfdt builds")

My arm builds are ppc64le hosted cross compiles using Debian's cross
gcc package.

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

Hi all,

On Mon, 20 Jan 2020 08:24:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the arm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:

In file included from scripts/dtc/libfdt/libfdt_env.h:12,
                 from arch/arm/boot/compressed/fdt_rw.c:6:
/usr/lib/gcc-cross/arm-linux-gnueabi/9/include/stdint.h:9:26: error: no include path in which to search for stdint.h
    9 | # include_next <stdint.h>
      |                          ^
In file included from arch/arm/boot/compressed/fdt_rw.c:6:
scripts/dtc/libfdt/libfdt_env.h:13:10: fatal error: stdlib.h: No such file or directory
   13 | #include <stdlib.h>
      |          ^~~~~~~~~~
compilation terminated.
In file included from scripts/dtc/libfdt/libfdt_env.h:12,
                 from arch/arm/boot/compressed/fdt_ro.c:6:
/usr/lib/gcc-cross/arm-linux-gnueabi/9/include/stdint.h:9:26: error: no include path in which to search for stdint.h
    9 | # include_next <stdint.h>
      |                          ^
In file included from arch/arm/boot/compressed/fdt_ro.c:6:
scripts/dtc/libfdt/libfdt_env.h:13:10: fatal error: stdlib.h: No such file or directory
   13 | #include <stdlib.h>
      |          ^~~~~~~~~~

> Caused by commit
> 
>   e3a0e1427dcb ("ARM: 8953/1: decompressor: simplify libfdt builds")
> 
> My arm builds are ppc64le hosted cross compiles using Debian's cross
> gcc package.
> 
> I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the arm tree

[Russell King - ARM Linux admin]

Hi Stephen,

Patch dropped.

I think this needs to wait until it's been properly tested before I
apply the next version.

On Mon, Jan 20, 2020 at 08:24:47AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the arm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> 
> Caused by commit
> 
>   e3a0e1427dcb ("ARM: 8953/1: decompressor: simplify libfdt builds")
> 
> My arm builds are ppc64le hosted cross compiles using Debian's cross
> gcc package.
> 
> I have reverted that commit for today.
> -- 
> Cheers,
> Stephen Rothwell



-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

Hi Russell,

After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/built-in.o: In function `__sp804_clocksource_and_sched_clock_init':
(.init.text+0x1a0e7): undefined reference to `sched_clock_register'

Presumably caused by commit 5261ef2ea836 ("ARM: 8366/1: move Dual-Timer
SP804 driver to drivers/clocksource").

I have used the arm tree from next-20150528 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

Hi Russell,

After merging the arm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

arch/arm/kernel/iwmmxt.S: Assembler messages:
arch/arm/kernel/iwmmxt.S:68: Error: bad instruction `inc_preempt_count r10,r3'
arch/arm/kernel/iwmmxt.S:176: Error: bad instruction `dec_preempt_count r10,r3'

Caused by commit c9133fdf69c4 ("ARM: 8019/1: Disable preemption in
iwmmxt_task_enable()").

I have used the arm tree from next-20140409 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: build failure after merge of the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

Hi Russell,

After merging the final tree, the linux-next 20110228 build (lots of arm
configs) failed like this:

stat: cannot stat `arch/arm/boot/compressed/../Image': No such file or directory
gcc-4.4.0-nolibc/arm-linux/bin/arm-linux-ld:--defsym _image_size=: syntax error

Presumably caused by commit d239b1dc093d551046a909920b5310c1d1e308c1
("ARM: 6746/1: remove the 4x expansion presumption while decompressing
the kernel").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: build failure after merge of the arm tree

[Nicolas Pitre]

On Thu, 3 Mar 2011, Stephen Rothwell wrote:

> Hi Russell,
> 
> After merging the final tree, the linux-next 20110228 build (lots of arm
> configs) failed like this:
> 
> stat: cannot stat `arch/arm/boot/compressed/../Image': No such file or directory
> gcc-4.4.0-nolibc/arm-linux/bin/arm-linux-ld:--defsym _image_size=: syntax error
> 
> Presumably caused by commit d239b1dc093d551046a909920b5310c1d1e308c1
> ("ARM: 6746/1: remove the 4x expansion presumption while decompressing
> the kernel").

The fix would be this:

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 9d328be..3c0c68f 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -84,7 +84,7 @@ EXTRA_CFLAGS  := -fpic -fno-builtin
 EXTRA_AFLAGS  := -Wa,-march=all
 
 # Provide size of uncompressed kernel to the decompressor via a linker symbol.
-LDFLAGS_vmlinux := --defsym _image_size=$(shell stat -c "%s" $(obj)/../Image)
+LDFLAGS_vmlinux = --defsym _image_size=$(shell stat -c "%s" $(obj)/../Image)
 # Supply ZRELADDR to the decompressor via a linker symbol.
 ifneq ($(CONFIG_AUTO_ZRELADDR),y)
 LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)

Russell: can you fold this fix in the original patch, or do you prefer I 
send you this fix separately?


Nicolas