* linux-next: build failure after merge of the bitmap tree
@ 2025-11-25 7:24 Stephen Rothwell
2025-11-25 8:05 ` Geert Uytterhoeven
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2025-11-25 7:24 UTC (permalink / raw)
To: Yury Norov, Miquel Raynal, Boris Brezillon
Cc: Richard Genoud, Geert Uytterhoeven, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 5040 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/mtd/nand/raw/sunxi_nand.c:33:9: error: "field_get" redefined [-Werror]
33 | #define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
| ^~~~~~~~~
In file included from include/linux/fortify-string.h:5,
from include/linux/string.h:386,
from include/linux/bitmap.h:13,
from include/linux/cpumask.h:11,
from arch/x86/include/asm/paravirt.h:21,
from arch/x86/include/asm/cpuid/api.h:57,
from arch/x86/include/asm/processor.h:19,
from include/linux/sched.h:13,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from include/linux/dma-mapping.h:5,
from drivers/mtd/nand/raw/sunxi_nand.c:16:
include/linux/bitfield.h:298:9: note: this is the location of the previous definition
298 | #define field_get(mask, reg) \
| ^~~~~~~~~
drivers/mtd/nand/raw/sunxi_nand.c:34:9: error: "field_prep" redefined [-Werror]
34 | #define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
| ^~~~~~~~~~
include/linux/bitfield.h:278:9: note: this is the location of the previous definition
278 | #define field_prep(mask, val) \
| ^~~~~~~~~~
cc1: all warnings being treated as errors
Caused by commit
c1c6ab80b25c ("bitfield: Add non-constant field_{prep,get}() helpers")
interacting with commits
d21b4338159f ("mtd: rawnand: sunxi: introduce ecc_mode_mask in sunxi_nfc_caps")
6fc2619af1eb ("mtd: rawnand: sunxi: rework pattern found registers")
from the nand tree.
I have applied the following hack for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 25 Nov 2025 17:47:46 +1100
Subject: [PATCH] fix up for "bitfield: Add non-constant field_{prep,get}()
helpers"
interacting with commits
d21b4338159f ("mtd: rawnand: sunxi: introduce ecc_mode_mask in sunxi_nfc_caps")
6fc2619af1eb ("mtd: rawnand: sunxi: rework pattern found registers")
from the nand tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/mtd/nand/raw/sunxi_nand.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
index 031ab651c5a8..b940eb5cf79a 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -30,8 +30,8 @@
#include <linux/reset.h>
/* non compile-time field get/prep */
-#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
-#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
+#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
+#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
#define NFC_REG_CTL 0x0000
#define NFC_REG_ST 0x0004
@@ -185,7 +185,7 @@
#define NFC_RANDOM_EN(nfc) (nfc->caps->random_en_mask)
#define NFC_RANDOM_DIRECTION(nfc) (nfc->caps->random_dir_mask)
#define NFC_ECC_MODE_MSK(nfc) (nfc->caps->ecc_mode_mask)
-#define NFC_ECC_MODE(nfc, x) field_prep(NFC_ECC_MODE_MSK(nfc), (x))
+#define NFC_ECC_MODE(nfc, x) sunxi_field_prep(NFC_ECC_MODE_MSK(nfc), (x))
/* RANDOM_PAGE_SIZE: 0: ECC block size 1: page size */
#define NFC_A23_RANDOM_PAGE_SIZE BIT(11)
#define NFC_H6_RANDOM_PAGE_SIZE BIT(7)
@@ -879,7 +879,7 @@ static void sunxi_nfc_set_user_data_len(struct sunxi_nfc *nfc,
val = readl(nfc->regs + NFC_REG_USER_DATA_LEN(nfc, step));
val &= ~NFC_USER_DATA_LEN_MSK(step);
- val |= field_prep(NFC_USER_DATA_LEN_MSK(step), i);
+ val |= sunxi_field_prep(NFC_USER_DATA_LEN_MSK(step), i);
writel(val, nfc->regs + NFC_REG_USER_DATA_LEN(nfc, step));
}
@@ -992,7 +992,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct nand_chip *nand,
*cur_off = oob_off + ecc->bytes + USER_DATA_SZ;
pattern_found = readl(nfc->regs + nfc->caps->reg_pat_found);
- pattern_found = field_get(NFC_ECC_PAT_FOUND_MSK(nfc), pattern_found);
+ pattern_found = sunxi_field_get(NFC_ECC_PAT_FOUND_MSK(nfc), pattern_found);
ret = sunxi_nfc_hw_ecc_correct(nand, data, oob_required ? oob : NULL, 0,
readl(nfc->regs + NFC_REG_ECC_ST),
@@ -1121,7 +1121,7 @@ static int sunxi_nfc_hw_ecc_read_chunks_dma(struct nand_chip *nand, uint8_t *buf
status = readl(nfc->regs + NFC_REG_ECC_ST);
pattern_found = readl(nfc->regs + nfc->caps->reg_pat_found);
- pattern_found = field_get(NFC_ECC_PAT_FOUND_MSK(nfc), pattern_found);
+ pattern_found = sunxi_field_get(NFC_ECC_PAT_FOUND_MSK(nfc), pattern_found);
for (i = 0; i < nchunks; i++) {
int data_off = i * ecc->size;
--
2.52.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-11-25 7:24 linux-next: build failure after merge of the bitmap tree Stephen Rothwell
@ 2025-11-25 8:05 ` Geert Uytterhoeven
2025-11-25 8:31 ` Miquel Raynal
2025-11-28 8:17 ` Miquel Raynal
0 siblings, 2 replies; 38+ messages in thread
From: Geert Uytterhoeven @ 2025-11-25 8:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Yury Norov, Miquel Raynal, Boris Brezillon, Richard Genoud,
Geert Uytterhoeven, Linux Kernel Mailing List,
Linux Next Mailing List
Hi Stephen,
On Tue, 25 Nov 2025 at 08:24, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the bitmap tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/mtd/nand/raw/sunxi_nand.c:33:9: error: "field_get" redefined [-Werror]
> 33 | #define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> | ^~~~~~~~~
> In file included from include/linux/fortify-string.h:5,
> from include/linux/string.h:386,
> from include/linux/bitmap.h:13,
> from include/linux/cpumask.h:11,
> from arch/x86/include/asm/paravirt.h:21,
> from arch/x86/include/asm/cpuid/api.h:57,
> from arch/x86/include/asm/processor.h:19,
> from include/linux/sched.h:13,
> from include/linux/ratelimit.h:6,
> from include/linux/dev_printk.h:16,
> from include/linux/device.h:15,
> from include/linux/dma-mapping.h:5,
> from drivers/mtd/nand/raw/sunxi_nand.c:16:
> include/linux/bitfield.h:298:9: note: this is the location of the previous definition
> 298 | #define field_get(mask, reg) \
> | ^~~~~~~~~
> drivers/mtd/nand/raw/sunxi_nand.c:34:9: error: "field_prep" redefined [-Werror]
> 34 | #define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> | ^~~~~~~~~~
> include/linux/bitfield.h:278:9: note: this is the location of the previous definition
> 278 | #define field_prep(mask, val) \
> | ^~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Caused by commit
>
> c1c6ab80b25c ("bitfield: Add non-constant field_{prep,get}() helpers")
>
> interacting with commits
>
> d21b4338159f ("mtd: rawnand: sunxi: introduce ecc_mode_mask in sunxi_nfc_caps")
> 6fc2619af1eb ("mtd: rawnand: sunxi: rework pattern found registers")
>
> from the nand tree.
>
> I have applied the following hack for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 25 Nov 2025 17:47:46 +1100
> Subject: [PATCH] fix up for "bitfield: Add non-constant field_{prep,get}()
> helpers"
>
> interacting with commits
>
> d21b4338159f ("mtd: rawnand: sunxi: introduce ecc_mode_mask in sunxi_nfc_caps")
> 6fc2619af1eb ("mtd: rawnand: sunxi: rework pattern found registers")
>
> from the nand tree.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/mtd/nand/raw/sunxi_nand.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
> index 031ab651c5a8..b940eb5cf79a 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> @@ -30,8 +30,8 @@
> #include <linux/reset.h>
>
> /* non compile-time field get/prep */
> -#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> -#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> +#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> +#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
See "[PATCH -next v6 11/26] mtd: rawnand: sunxi: #undef
field_{get,prep}() before local definition"[1] and follow-up
"[PATCH -next v6 24/26] mtd: rawnand: sunxi: Convert to common
field_{get,prep}() helpers"[2].
The former unfortunately didn't make it into the nand tree yet...
[1] https://lore.kernel.org/all/703d7eec56074148daed4ea45b637f8a83f15305.1762435376.git.geert+renesas@glider.be
[2] https://lore.kernel.org/all/e1c879967328d8c1098aaa014845c2f11874d7c7.1762435376.git.geert+renesas@glider.be/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-11-25 8:05 ` Geert Uytterhoeven
@ 2025-11-25 8:31 ` Miquel Raynal
2025-11-25 8:37 ` Geert Uytterhoeven
2025-11-25 8:53 ` Miquel Raynal
2025-11-28 8:17 ` Miquel Raynal
1 sibling, 2 replies; 38+ messages in thread
From: Miquel Raynal @ 2025-11-25 8:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Yury Norov, Boris Brezillon, Richard Genoud,
Geert Uytterhoeven, Linux Kernel Mailing List,
Linux Next Mailing List
Hello Geert,
>> /* non compile-time field get/prep */
>> -#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>> -#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>> +#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>> +#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>
> See "[PATCH -next v6 11/26] mtd: rawnand: sunxi: #undef
> field_{get,prep}() before local definition"[1] and follow-up
> "[PATCH -next v6 24/26] mtd: rawnand: sunxi: Convert to common
> field_{get,prep}() helpers"[2].
> The former unfortunately didn't make it into the nand tree yet...
>
> [1] https://lore.kernel.org/all/703d7eec56074148daed4ea45b637f8a83f15305.1762435376.git.geert+renesas@glider.be
> [2] https://lore.kernel.org/all/e1c879967328d8c1098aaa014845c2f11874d7c7.1762435376.git.geert+renesas@glider.be/
It wasn't clear to me when/if I could effectively pull these, nor if
they would make it for this release. Were you (or someone else) supposed
to carry these on your own? Or, can I just apply these two now?
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-11-25 8:31 ` Miquel Raynal
@ 2025-11-25 8:37 ` Geert Uytterhoeven
2025-11-25 14:44 ` Yury Norov
2025-11-25 8:53 ` Miquel Raynal
1 sibling, 1 reply; 38+ messages in thread
From: Geert Uytterhoeven @ 2025-11-25 8:37 UTC (permalink / raw)
To: Miquel Raynal
Cc: Stephen Rothwell, Yury Norov, Boris Brezillon, Richard Genoud,
Linux Kernel Mailing List, Linux Next Mailing List
Hi Miquel,
On Tue, 25 Nov 2025 at 09:31, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >> /* non compile-time field get/prep */
> >> -#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> >> -#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> >> +#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> >> +#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> >
> > See "[PATCH -next v6 11/26] mtd: rawnand: sunxi: #undef
> > field_{get,prep}() before local definition"[1] and follow-up
> > "[PATCH -next v6 24/26] mtd: rawnand: sunxi: Convert to common
> > field_{get,prep}() helpers"[2].
> > The former unfortunately didn't make it into the nand tree yet...
> >
> > [1] https://lore.kernel.org/all/703d7eec56074148daed4ea45b637f8a83f15305.1762435376.git.geert+renesas@glider.be
> > [2] https://lore.kernel.org/all/e1c879967328d8c1098aaa014845c2f11874d7c7.1762435376.git.geert+renesas@glider.be/
>
> It wasn't clear to me when/if I could effectively pull these, nor if
> they would make it for this release. Were you (or someone else) supposed
> to carry these on your own? Or, can I just apply these two now?
The first one you can apply now, to fix the build issue.
The second one has to wait until the changes to <linux/bitfield.h>
are in your tree.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-11-25 8:37 ` Geert Uytterhoeven
@ 2025-11-25 14:44 ` Yury Norov
2025-11-25 14:55 ` Miquel Raynal
0 siblings, 1 reply; 38+ messages in thread
From: Yury Norov @ 2025-11-25 14:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Miquel Raynal, Stephen Rothwell, Boris Brezillon, Richard Genoud,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Nov 25, 2025 at 09:37:25AM +0100, Geert Uytterhoeven wrote:
> Hi Miquel,
>
> On Tue, 25 Nov 2025 at 09:31, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >> /* non compile-time field get/prep */
> > >> -#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> > >> -#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> > >> +#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> > >> +#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> > >
> > > See "[PATCH -next v6 11/26] mtd: rawnand: sunxi: #undef
> > > field_{get,prep}() before local definition"[1] and follow-up
> > > "[PATCH -next v6 24/26] mtd: rawnand: sunxi: Convert to common
> > > field_{get,prep}() helpers"[2].
> > > The former unfortunately didn't make it into the nand tree yet...
> > >
> > > [1] https://lore.kernel.org/all/703d7eec56074148daed4ea45b637f8a83f15305.1762435376.git.geert+renesas@glider.be
> > > [2] https://lore.kernel.org/all/e1c879967328d8c1098aaa014845c2f11874d7c7.1762435376.git.geert+renesas@glider.be/
> >
> > It wasn't clear to me when/if I could effectively pull these, nor if
> > they would make it for this release. Were you (or someone else) supposed
> > to carry these on your own? Or, can I just apply these two now?
>
> The first one you can apply now, to fix the build issue.
> The second one has to wait until the changes to <linux/bitfield.h>
> are in your tree.
Is anything expected on my side? Should I drop the trouble patch, or
just wait, or something else?
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-11-25 14:44 ` Yury Norov
@ 2025-11-25 14:55 ` Miquel Raynal
0 siblings, 0 replies; 38+ messages in thread
From: Miquel Raynal @ 2025-11-25 14:55 UTC (permalink / raw)
To: Yury Norov
Cc: Geert Uytterhoeven, Stephen Rothwell, Boris Brezillon,
Richard Genoud, Linux Kernel Mailing List,
Linux Next Mailing List
Hello Yury,
On 25/11/2025 at 09:44:27 -05, Yury Norov <yury.norov@gmail.com> wrote:
> On Tue, Nov 25, 2025 at 09:37:25AM +0100, Geert Uytterhoeven wrote:
>> Hi Miquel,
>>
>> On Tue, 25 Nov 2025 at 09:31, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>> > >> /* non compile-time field get/prep */
>> > >> -#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>> > >> -#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>> > >> +#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>> > >> +#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>> > >
>> > > See "[PATCH -next v6 11/26] mtd: rawnand: sunxi: #undef
>> > > field_{get,prep}() before local definition"[1] and follow-up
>> > > "[PATCH -next v6 24/26] mtd: rawnand: sunxi: Convert to common
>> > > field_{get,prep}() helpers"[2].
>> > > The former unfortunately didn't make it into the nand tree yet...
>> > >
>> > > [1] https://lore.kernel.org/all/703d7eec56074148daed4ea45b637f8a83f15305.1762435376.git.geert+renesas@glider.be
>> > > [2] https://lore.kernel.org/all/e1c879967328d8c1098aaa014845c2f11874d7c7.1762435376.git.geert+renesas@glider.be/
>> >
>> > It wasn't clear to me when/if I could effectively pull these, nor if
>> > they would make it for this release. Were you (or someone else) supposed
>> > to carry these on your own? Or, can I just apply these two now?
>>
>> The first one you can apply now, to fix the build issue.
>> The second one has to wait until the changes to <linux/bitfield.h>
>> are in your tree.
>
> Is anything expected on my side? Should I drop the trouble patch, or
> just wait, or something else?
Don't drop it, it's on my side to apply the "undef" fix now.
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: linux-next: build failure after merge of the bitmap tree
2025-11-25 8:31 ` Miquel Raynal
2025-11-25 8:37 ` Geert Uytterhoeven
@ 2025-11-25 8:53 ` Miquel Raynal
1 sibling, 0 replies; 38+ messages in thread
From: Miquel Raynal @ 2025-11-25 8:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Yury Norov, Boris Brezillon, Richard Genoud,
Geert Uytterhoeven, Linux Kernel Mailing List,
Linux Next Mailing List
>On 25/11/2025 at 09:31:48 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Hello Geert,
>
>>> /* non compile-time field get/prep */
>>> -#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>>> -#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>>> +#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>>> +#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>>
>> See "[PATCH -next v6 11/26] mtd: rawnand: sunxi: #undef
>> field_{get,prep}() before local definition"[1] and follow-up
>> "[PATCH -next v6 24/26] mtd: rawnand: sunxi: Convert to common
>> field_{get,prep}() helpers"[2].
>> The former unfortunately didn't make it into the nand tree yet...
>>
>> [1] https://lore.kernel.org/all/703d7eec56074148daed4ea45b637f8a83f15305.1762435376.git.geert+renesas@glider.be
>> [2] https://lore.kernel.org/all/e1c879967328d8c1098aaa014845c2f11874d7c7.1762435376.git.geert+renesas@glider.be/
>
> It wasn't clear to me when/if I could effectively pull these, nor if
> they would make it for this release. Were you (or someone else) supposed
> to carry these on your own? Or, can I just apply these two now?
Actually it's entirely my fault, I put that series aside given the
bikeshedding that happened on patch 12. I am sorry for not being more
pushy on my side, this is great job I should have encouraged with more
engagement, but I tend to loose all kind of motivation when it comes to
arguing with perfectionists.
So as hinted in the cover letter, I'll take patch 11 now and apply the
other patch (which I blindly acked already) on top of -rc1. Don't
hesitate to ping me or resend if I don't.
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: linux-next: build failure after merge of the bitmap tree
2025-11-25 8:05 ` Geert Uytterhoeven
2025-11-25 8:31 ` Miquel Raynal
@ 2025-11-28 8:17 ` Miquel Raynal
1 sibling, 0 replies; 38+ messages in thread
From: Miquel Raynal @ 2025-11-28 8:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Yury Norov, Boris Brezillon, Richard Genoud,
Geert Uytterhoeven, Linux Kernel Mailing List,
Linux Next Mailing List
Hello,
>> Caused by commit
>>
>> c1c6ab80b25c ("bitfield: Add non-constant field_{prep,get}() helpers")
>>
>> interacting with commits
>>
>> d21b4338159f ("mtd: rawnand: sunxi: introduce ecc_mode_mask in sunxi_nfc_caps")
>> 6fc2619af1eb ("mtd: rawnand: sunxi: rework pattern found registers")
>>
>> from the nand tree.
>>
>> I have applied the following hack for today.
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 25 Nov 2025 17:47:46 +1100
>> Subject: [PATCH] fix up for "bitfield: Add non-constant field_{prep,get}()
>> helpers"
>>
>> interacting with commits
>>
>> d21b4338159f ("mtd: rawnand: sunxi: introduce ecc_mode_mask in sunxi_nfc_caps")
>> 6fc2619af1eb ("mtd: rawnand: sunxi: rework pattern found registers")
>>
>> from the nand tree.
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> drivers/mtd/nand/raw/sunxi_nand.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
>> index 031ab651c5a8..b940eb5cf79a 100644
>> --- a/drivers/mtd/nand/raw/sunxi_nand.c
>> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
>> @@ -30,8 +30,8 @@
>> #include <linux/reset.h>
>>
>> /* non compile-time field get/prep */
>> -#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>> -#define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>> +#define sunxi_field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
>> +#define sunxi_field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>
> See "[PATCH -next v6 11/26] mtd: rawnand: sunxi: #undef
> field_{get,prep}() before local definition"[1] and follow-up
> "[PATCH -next v6 24/26] mtd: rawnand: sunxi: Convert to common
> field_{get,prep}() helpers"[2].
> The former unfortunately didn't make it into the nand tree yet...
>
> [1]
> https://lore.kernel.org/all/703d7eec56074148daed4ea45b637f8a83f15305.1762435376.git.geert+renesas@glider.be
I've had some issues since a distribution update, but I've taken the patch
locally and prepared my branch for the merge window, I cannot push to
the MTD repository right now but it will be done tonight.
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 38+ messages in thread
* linux-next: build failure after merge of the bitmap tree
@ 2025-02-18 5:07 Stephen Rothwell
2025-02-18 10:35 ` Beata Michalska
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2025-02-18 5:07 UTC (permalink / raw)
To: Yury Norov, Catalin Marinas, Will Deacon
Cc: Beata Michalska, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (arm64 defconfig)
failed like this:
arch/arm64/kernel/topology.c: In function 'arch_freq_get_on_cpu':
arch/arm64/kernel/topology.c:270:43: error: too many arguments to function 'cpumask_next_wrap'
270 | ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus,
| ^~~~~~~~~~~~~~~~~
In file included from arch/arm64/include/asm/cpufeature.h:27,
from arch/arm64/include/asm/ptrace.h:11,
from arch/arm64/include/asm/irqflags.h:9,
from include/linux/irqflags.h:18,
from include/linux/spinlock.h:59,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:7,
from include/linux/slab.h:16,
from include/linux/resource_ext.h:11,
from include/linux/acpi.h:13,
from arch/arm64/kernel/topology.c:14:
include/linux/cpumask.h:317:14: note: declared here
317 | unsigned int cpumask_next_wrap(int n, const struct cpumask *src)
| ^~~~~~~~~~~~~~~~~
Caused by commits
46ac1bec179d ("cpumask: deprecate cpumask_next_wrap()")
43f7f920e14e ("cpumask: re-introduce cpumask_next{,_and}_wrap()")
65b98ea8b278 ("cpumask: drop cpumask_next_wrap_old()")
interacting with commit
dd871ac1237f ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
from the arm64 tree.
I have applied the following patch for today (which may not be correct).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 Feb 2025 15:44:06 +1100
Subject: [PATCH] fixup for "cpumask: drop cpumask_next_wrap_old()"
interacting with commit
dd871ac1237f ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
from the arm64 tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm64/kernel/topology.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 6f0cab8e746b..70db234c41a2 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -231,7 +231,6 @@ void arch_cpu_idle_enter(void)
int arch_freq_get_on_cpu(int cpu)
{
struct amu_cntr_sample *amu_sample;
- unsigned int start_cpu = cpu;
unsigned long last_update;
unsigned int freq = 0;
u64 scale;
@@ -267,8 +266,7 @@ int arch_freq_get_on_cpu(int cpu)
do {
- ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus,
- start_cpu, false);
+ ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus);
} while (ref_cpu < nr_cpu_ids && idle_cpu(ref_cpu));
--
2.45.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-02-18 5:07 Stephen Rothwell
@ 2025-02-18 10:35 ` Beata Michalska
2025-02-18 13:49 ` Stephen Rothwell
0 siblings, 1 reply; 38+ messages in thread
From: Beata Michalska @ 2025-02-18 10:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Yury Norov, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Linux Next Mailing List
Hi,
On Tue, Feb 18, 2025 at 04:07:42PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bitmap tree, today's linux-next build (arm64 defconfig)
> failed like this:
>
> arch/arm64/kernel/topology.c: In function 'arch_freq_get_on_cpu':
> arch/arm64/kernel/topology.c:270:43: error: too many arguments to function 'cpumask_next_wrap'
> 270 | ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus,
> | ^~~~~~~~~~~~~~~~~
> In file included from arch/arm64/include/asm/cpufeature.h:27,
> from arch/arm64/include/asm/ptrace.h:11,
> from arch/arm64/include/asm/irqflags.h:9,
> from include/linux/irqflags.h:18,
> from include/linux/spinlock.h:59,
> from include/linux/mmzone.h:8,
> from include/linux/gfp.h:7,
> from include/linux/slab.h:16,
> from include/linux/resource_ext.h:11,
> from include/linux/acpi.h:13,
> from arch/arm64/kernel/topology.c:14:
> include/linux/cpumask.h:317:14: note: declared here
> 317 | unsigned int cpumask_next_wrap(int n, const struct cpumask *src)
> | ^~~~~~~~~~~~~~~~~
>
> Caused by commits
>
> 46ac1bec179d ("cpumask: deprecate cpumask_next_wrap()")
> 43f7f920e14e ("cpumask: re-introduce cpumask_next{,_and}_wrap()")
> 65b98ea8b278 ("cpumask: drop cpumask_next_wrap_old()")
>
> interacting with commit
>
> dd871ac1237f ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
>
> from the arm64 tree.
>
> I have applied the following patch for today (which may not be correct).
Thank you for that.
I'm currently testing a proper fix for that one.
Should I just send it over as a diff to apply or rather a proper 'fixes' patch?
---
BR
Beata
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 18 Feb 2025 15:44:06 +1100
> Subject: [PATCH] fixup for "cpumask: drop cpumask_next_wrap_old()"
>
> interacting with commit
>
> dd871ac1237f ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
>
> from the arm64 tree.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/arm64/kernel/topology.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 6f0cab8e746b..70db234c41a2 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -231,7 +231,6 @@ void arch_cpu_idle_enter(void)
> int arch_freq_get_on_cpu(int cpu)
> {
> struct amu_cntr_sample *amu_sample;
> - unsigned int start_cpu = cpu;
> unsigned long last_update;
> unsigned int freq = 0;
> u64 scale;
> @@ -267,8 +266,7 @@ int arch_freq_get_on_cpu(int cpu)
>
>
> do {
> - ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus,
> - start_cpu, false);
> + ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus);
>
> } while (ref_cpu < nr_cpu_ids && idle_cpu(ref_cpu));
>
> --
> 2.45.2
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-02-18 10:35 ` Beata Michalska
@ 2025-02-18 13:49 ` Stephen Rothwell
2025-02-18 14:10 ` Catalin Marinas
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2025-02-18 13:49 UTC (permalink / raw)
To: Beata Michalska
Cc: Yury Norov, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Hi Beata,
On Tue, 18 Feb 2025 11:35:02 +0100 Beata Michalska <beata.michalska@arm.com> wrote:
>
> I'm currently testing a proper fix for that one.
> Should I just send it over as a diff to apply or rather a proper 'fixes' patch?
Maybe a proper 'fixes' patch, please, if easy - otherwise a diff is
fine.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: linux-next: build failure after merge of the bitmap tree
2025-02-18 13:49 ` Stephen Rothwell
@ 2025-02-18 14:10 ` Catalin Marinas
2025-02-18 14:16 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: Catalin Marinas @ 2025-02-18 14:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Beata Michalska, Yury Norov, Will Deacon,
Linux Kernel Mailing List, Linux Next Mailing List
Hi Stephen,
On Wed, Feb 19, 2025 at 12:49:34AM +1100, Stephen Rothwell wrote:
> On Tue, 18 Feb 2025 11:35:02 +0100 Beata Michalska <beata.michalska@arm.com> wrote:
> > I'm currently testing a proper fix for that one.
> > Should I just send it over as a diff to apply or rather a proper 'fixes' patch?
>
> Maybe a proper 'fixes' patch, please, if easy - otherwise a diff is
> fine.
I just talked to Beata off-list. I think she'll try to use the current
for_each_cpu_wrap() API and avoid conflicts with the cpumask_next_wrap()
API change.
If that doesn't work, you either carry a patch in -next until both
branches end up upstream or I merge a stable bitmap branch from Yury
with a fix on top.
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: linux-next: build failure after merge of the bitmap tree
2025-02-18 14:10 ` Catalin Marinas
@ 2025-02-18 14:16 ` Yury Norov
2025-02-18 18:23 ` Catalin Marinas
0 siblings, 1 reply; 38+ messages in thread
From: Yury Norov @ 2025-02-18 14:16 UTC (permalink / raw)
To: Catalin Marinas
Cc: Stephen Rothwell, Beata Michalska, Will Deacon,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Feb 18, 2025 at 02:10:25PM +0000, Catalin Marinas wrote:
> Hi Stephen,
>
> On Wed, Feb 19, 2025 at 12:49:34AM +1100, Stephen Rothwell wrote:
> > On Tue, 18 Feb 2025 11:35:02 +0100 Beata Michalska <beata.michalska@arm.com> wrote:
> > > I'm currently testing a proper fix for that one.
> > > Should I just send it over as a diff to apply or rather a proper 'fixes' patch?
> >
> > Maybe a proper 'fixes' patch, please, if easy - otherwise a diff is
> > fine.
>
> I just talked to Beata off-list. I think she'll try to use the current
> for_each_cpu_wrap() API and avoid conflicts with the cpumask_next_wrap()
> API change.
Hi,
Yes, for_each() loops are always preferable over opencoded iterating.
Please feel free to CC me in case I can help.
Thanks,
Yury
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: linux-next: build failure after merge of the bitmap tree
2025-02-18 14:16 ` Yury Norov
@ 2025-02-18 18:23 ` Catalin Marinas
2025-02-18 19:28 ` Beata Michalska
0 siblings, 1 reply; 38+ messages in thread
From: Catalin Marinas @ 2025-02-18 18:23 UTC (permalink / raw)
To: Yury Norov
Cc: Stephen Rothwell, Beata Michalska, Will Deacon,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Feb 18, 2025 at 09:16:34AM -0500, Yury Norov wrote:
> On Tue, Feb 18, 2025 at 02:10:25PM +0000, Catalin Marinas wrote:
> > Hi Stephen,
> >
> > On Wed, Feb 19, 2025 at 12:49:34AM +1100, Stephen Rothwell wrote:
> > > On Tue, 18 Feb 2025 11:35:02 +0100 Beata Michalska <beata.michalska@arm.com> wrote:
> > > > I'm currently testing a proper fix for that one.
> > > > Should I just send it over as a diff to apply or rather a proper 'fixes' patch?
> > >
> > > Maybe a proper 'fixes' patch, please, if easy - otherwise a diff is
> > > fine.
> >
> > I just talked to Beata off-list. I think she'll try to use the current
> > for_each_cpu_wrap() API and avoid conflicts with the cpumask_next_wrap()
> > API change.
>
> Hi,
>
> Yes, for_each() loops are always preferable over opencoded iterating.
> Please feel free to CC me in case I can help.
Beata is going to post the official fix but in the meantime, to avoid
breaking next, I'll add my temporary fix:
--------8<--------------------------------
From 1b12139107798128c183838c5f4a3f7ffcea1e44 Mon Sep 17 00:00:00 2001
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Tue, 18 Feb 2025 18:20:46 +0000
Subject: [PATCH] arm64: Do not use the deprecated cpumask_next_wrap() in
arch_freq_get_on_cpu()
cpumask_next_wrap() will soon disappear in its current form. Use
for_each_cpu_wrap() instead.
Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/topology.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index a09b0551ec59..1544d3648554 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -254,7 +254,7 @@ int arch_freq_get_on_cpu(int cpu)
if (!housekeeping_cpu(cpu, HK_TYPE_TICK) ||
time_is_before_jiffies(last_update + msecs_to_jiffies(AMU_SAMPLE_EXP_MS))) {
struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
- int ref_cpu = cpu;
+ int ref_cpu;
if (!policy)
return -EINVAL;
@@ -265,11 +265,10 @@ int arch_freq_get_on_cpu(int cpu)
return -EOPNOTSUPP;
}
- do {
- ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus,
- start_cpu, true);
-
- } while (ref_cpu < nr_cpu_ids && idle_cpu(ref_cpu));
+ for_each_cpu_wrap(ref_cpu, policy->cpus, start_cpu) {
+ if (!idle_cpu(ref_cpu))
+ break;
+ }
cpufreq_cpu_put(policy);
^ permalink raw reply related [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-02-18 18:23 ` Catalin Marinas
@ 2025-02-18 19:28 ` Beata Michalska
2025-02-18 19:44 ` Catalin Marinas
0 siblings, 1 reply; 38+ messages in thread
From: Beata Michalska @ 2025-02-18 19:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: Yury Norov, Stephen Rothwell, Will Deacon,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Feb 18, 2025 at 06:23:29PM +0000, Catalin Marinas wrote:
> On Tue, Feb 18, 2025 at 09:16:34AM -0500, Yury Norov wrote:
> > On Tue, Feb 18, 2025 at 02:10:25PM +0000, Catalin Marinas wrote:
> > > Hi Stephen,
> > >
> > > On Wed, Feb 19, 2025 at 12:49:34AM +1100, Stephen Rothwell wrote:
> > > > On Tue, 18 Feb 2025 11:35:02 +0100 Beata Michalska <beata.michalska@arm.com> wrote:
> > > > > I'm currently testing a proper fix for that one.
> > > > > Should I just send it over as a diff to apply or rather a proper 'fixes' patch?
> > > >
> > > > Maybe a proper 'fixes' patch, please, if easy - otherwise a diff is
> > > > fine.
> > >
> > > I just talked to Beata off-list. I think she'll try to use the current
> > > for_each_cpu_wrap() API and avoid conflicts with the cpumask_next_wrap()
> > > API change.
> >
> > Hi,
> >
> > Yes, for_each() loops are always preferable over opencoded iterating.
> > Please feel free to CC me in case I can help.
>
> Beata is going to post the official fix but in the meantime, to avoid
> breaking next, I'll add my temporary fix:
>
Just posted the fix [1].
Thank you all.
---
[1] https://lore.kernel.org/linux-next/20250218192412.2072619-1-beata.michalska@arm.com/T/#u
---
BR
Beata
> --------8<--------------------------------
> From 1b12139107798128c183838c5f4a3f7ffcea1e44 Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Tue, 18 Feb 2025 18:20:46 +0000
> Subject: [PATCH] arm64: Do not use the deprecated cpumask_next_wrap() in
> arch_freq_get_on_cpu()
>
> cpumask_next_wrap() will soon disappear in its current form. Use
> for_each_cpu_wrap() instead.
>
> Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/kernel/topology.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index a09b0551ec59..1544d3648554 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -254,7 +254,7 @@ int arch_freq_get_on_cpu(int cpu)
> if (!housekeeping_cpu(cpu, HK_TYPE_TICK) ||
> time_is_before_jiffies(last_update + msecs_to_jiffies(AMU_SAMPLE_EXP_MS))) {
> struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> - int ref_cpu = cpu;
> + int ref_cpu;
>
> if (!policy)
> return -EINVAL;
> @@ -265,11 +265,10 @@ int arch_freq_get_on_cpu(int cpu)
> return -EOPNOTSUPP;
> }
>
> - do {
> - ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus,
> - start_cpu, true);
> -
> - } while (ref_cpu < nr_cpu_ids && idle_cpu(ref_cpu));
> + for_each_cpu_wrap(ref_cpu, policy->cpus, start_cpu) {
> + if (!idle_cpu(ref_cpu))
> + break;
> + }
>
> cpufreq_cpu_put(policy);
>
>
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2025-02-18 19:28 ` Beata Michalska
@ 2025-02-18 19:44 ` Catalin Marinas
0 siblings, 0 replies; 38+ messages in thread
From: Catalin Marinas @ 2025-02-18 19:44 UTC (permalink / raw)
To: Beata Michalska
Cc: Yury Norov, Stephen Rothwell, Will Deacon,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Feb 18, 2025 at 08:28:56PM +0100, Beata Michalska wrote:
> On Tue, Feb 18, 2025 at 06:23:29PM +0000, Catalin Marinas wrote:
> > On Tue, Feb 18, 2025 at 09:16:34AM -0500, Yury Norov wrote:
> > > On Tue, Feb 18, 2025 at 02:10:25PM +0000, Catalin Marinas wrote:
> > > > Hi Stephen,
> > > >
> > > > On Wed, Feb 19, 2025 at 12:49:34AM +1100, Stephen Rothwell wrote:
> > > > > On Tue, 18 Feb 2025 11:35:02 +0100 Beata Michalska <beata.michalska@arm.com> wrote:
> > > > > > I'm currently testing a proper fix for that one.
> > > > > > Should I just send it over as a diff to apply or rather a proper 'fixes' patch?
> > > > >
> > > > > Maybe a proper 'fixes' patch, please, if easy - otherwise a diff is
> > > > > fine.
> > > >
> > > > I just talked to Beata off-list. I think she'll try to use the current
> > > > for_each_cpu_wrap() API and avoid conflicts with the cpumask_next_wrap()
> > > > API change.
> > >
> > > Hi,
> > >
> > > Yes, for_each() loops are always preferable over opencoded iterating.
> > > Please feel free to CC me in case I can help.
> >
> > Beata is going to post the official fix but in the meantime, to avoid
> > breaking next, I'll add my temporary fix:
> >
> Just posted the fix [1].
> Thank you all.
>
> ---
> [1] https://lore.kernel.org/linux-next/20250218192412.2072619-1-beata.michalska@arm.com/T/#u
Great, thanks. I'll queue it tomorrow.
--
Catalin
^ permalink raw reply [flat|nested] 38+ messages in thread
* linux-next: build failure after merge of the bitmap tree
@ 2024-05-08 6:27 Stephen Rothwell
2024-05-08 13:24 ` Kuan-Wei Chiu
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2024-05-08 6:27 UTC (permalink / raw)
To: Yury Norov
Cc: Kuan-Wei Chiu, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
lib/test_bitops.c: In function 'test_fns':
lib/test_bitops.c:56:9: error: cleanup argument not a function
56 | unsigned long *buf __free(kfree) = NULL;
| ^~~~~~~~
lib/test_bitops.c:60:15: error: implicit declaration of function 'kmalloc_array' [-Werror=implicit-function-declaration]
60 | buf = kmalloc_array(10000, sizeof(unsigned long), GFP_KERNEL);
| ^~~~~~~~~~~~~
lib/test_bitops.c:60:13: error: assignment to 'long unsigned int *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
60 | buf = kmalloc_array(10000, sizeof(unsigned long), GFP_KERNEL);
| ^
cc1: all warnings being treated as errors
Caused by commit
777c893e12fa ("lib/test_bitops: Add benchmark test for fns()")
I have used the bitmap tree from next-20240507 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2024-05-08 6:27 Stephen Rothwell
@ 2024-05-08 13:24 ` Kuan-Wei Chiu
2024-05-08 22:18 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: Kuan-Wei Chiu @ 2024-05-08 13:24 UTC (permalink / raw)
To: Yury Norov
Cc: Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, May 08, 2024 at 04:27:55PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bitmap tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> lib/test_bitops.c: In function 'test_fns':
> lib/test_bitops.c:56:9: error: cleanup argument not a function
> 56 | unsigned long *buf __free(kfree) = NULL;
> | ^~~~~~~~
> lib/test_bitops.c:60:15: error: implicit declaration of function 'kmalloc_array' [-Werror=implicit-function-declaration]
> 60 | buf = kmalloc_array(10000, sizeof(unsigned long), GFP_KERNEL);
> | ^~~~~~~~~~~~~
> lib/test_bitops.c:60:13: error: assignment to 'long unsigned int *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> 60 | buf = kmalloc_array(10000, sizeof(unsigned long), GFP_KERNEL);
> | ^
> cc1: all warnings being treated as errors
>
> Caused by commit
>
> 777c893e12fa ("lib/test_bitops: Add benchmark test for fns()")
>
> I have used the bitmap tree from next-20240507 for today.
>
> --
> Cheers,
> Stephen Rothwell
Hi Yury,
I believe the following patch can resolve this issue. If you agree that
this patch is correct, could you help me fold it into the commit that
caused the error mentioned above?
Regards,
Kuan-Wei
From e028ad2415fc1b9cf7f59faa298ac7d6c2723b4a Mon Sep 17 00:00:00 2001
From: Kuan-Wei Chiu <visitorckw@gmail.com>
Date: Wed, 8 May 2024 21:16:50 +0800
Subject: [PATCH] lib/test_bitops: Fix compilation error on ppc64_defconfig
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
lib/test_bitops.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/test_bitops.c b/lib/test_bitops.c
index ee4759ced0f6..564bc486b599 100644
--- a/lib/test_bitops.c
+++ b/lib/test_bitops.c
@@ -8,6 +8,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/printk.h>
+#include <linux/slab.h>
/* a tiny module only meant to test
*
--
2.34.1
^ permalink raw reply related [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2024-05-08 13:24 ` Kuan-Wei Chiu
@ 2024-05-08 22:18 ` Yury Norov
0 siblings, 0 replies; 38+ messages in thread
From: Yury Norov @ 2024-05-08 22:18 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, May 08, 2024 at 09:24:41PM +0800, Kuan-Wei Chiu wrote:
> On Wed, May 08, 2024 at 04:27:55PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the bitmap tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > lib/test_bitops.c: In function 'test_fns':
> > lib/test_bitops.c:56:9: error: cleanup argument not a function
> > 56 | unsigned long *buf __free(kfree) = NULL;
> > | ^~~~~~~~
> > lib/test_bitops.c:60:15: error: implicit declaration of function 'kmalloc_array' [-Werror=implicit-function-declaration]
> > 60 | buf = kmalloc_array(10000, sizeof(unsigned long), GFP_KERNEL);
> > | ^~~~~~~~~~~~~
> > lib/test_bitops.c:60:13: error: assignment to 'long unsigned int *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> > 60 | buf = kmalloc_array(10000, sizeof(unsigned long), GFP_KERNEL);
> > | ^
> > cc1: all warnings being treated as errors
> >
> > Caused by commit
> >
> > 777c893e12fa ("lib/test_bitops: Add benchmark test for fns()")
> >
> > I have used the bitmap tree from next-20240507 for today.
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
> Hi Yury,
>
> I believe the following patch can resolve this issue. If you agree that
> this patch is correct, could you help me fold it into the commit that
> caused the error mentioned above?
>
> Regards,
> Kuan-Wei
Updated, thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* linux-next: build failure after merge of the bitmap tree
@ 2023-10-20 4:49 Stephen Rothwell
0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2023-10-20 4:49 UTC (permalink / raw)
To: Yury Norov
Cc: Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (native perf)
failed like this:
util/probe-finder.c: In function 'convert_variable_type':
util/probe-finder.c:336:51: error: format '%zd' expects argument of type 'signed size_t', but argument 6 has type 'int' [-Werror=format=]
336 | ret = snprintf(buf, 16, "b%d@%d/%zd", bsize, boffs,
| ~~^
| |
| long int
| %d
cc1: all warnings being treated as errors
Caused by commit
f14eba432b67 ("bitops: make BYTES_TO_BITS() treewide-available")
I have used the bitmap tree from next-20231018 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* linux-next: build failure after merge of the bitmap tree
@ 2023-10-19 6:01 Stephen Rothwell
2023-10-19 15:58 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2023-10-19 6:01 UTC (permalink / raw)
To: Yury Norov
Cc: Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (native perf)
failed like this:
In file included from /home/sfr/next/next/tools/perf/util/header.h:10,
from /home/sfr/next/perf/pmu-events/pmu-events.c:3:
/home/sfr/next/next/tools/include/linux/bitmap.h:5:10: fatal error: linux/align.h: No such file or directory
5 | #include <linux/align.h>
| ^~~~~~~~~~~~~~~
Caused by commit
ed46ac8199f0 ("bitmap: introduce generic optimized bitmap_size()")
I have used the bitmap tree from next-20231018 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2023-10-19 6:01 Stephen Rothwell
@ 2023-10-19 15:58 ` Yury Norov
2023-10-20 4:24 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: Yury Norov @ 2023-10-19 15:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
On Thu, Oct 19, 2023 at 05:01:06PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bitmap tree, today's linux-next build (native perf)
> failed like this:
>
> In file included from /home/sfr/next/next/tools/perf/util/header.h:10,
> from /home/sfr/next/perf/pmu-events/pmu-events.c:3:
> /home/sfr/next/next/tools/include/linux/bitmap.h:5:10: fatal error: linux/align.h: No such file or directory
> 5 | #include <linux/align.h>
> | ^~~~~~~~~~~~~~~
>
> Caused by commit
>
> ed46ac8199f0 ("bitmap: introduce generic optimized bitmap_size()")
>
> I have used the bitmap tree from next-20231018 for today.
Thanks, Stephen. I'll take a look and let you know when it's resolved.
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2023-10-19 15:58 ` Yury Norov
@ 2023-10-20 4:24 ` Yury Norov
2023-10-20 4:51 ` Stephen Rothwell
0 siblings, 1 reply; 38+ messages in thread
From: Yury Norov @ 2023-10-20 4:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
On Thu, Oct 19, 2023 at 08:58:24AM -0700, Yury Norov wrote:
> On Thu, Oct 19, 2023 at 05:01:06PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the bitmap tree, today's linux-next build (native perf)
> > failed like this:
> >
> > In file included from /home/sfr/next/next/tools/perf/util/header.h:10,
> > from /home/sfr/next/perf/pmu-events/pmu-events.c:3:
> > /home/sfr/next/next/tools/include/linux/bitmap.h:5:10: fatal error: linux/align.h: No such file or directory
> > 5 | #include <linux/align.h>
> > | ^~~~~~~~~~~~~~~
> >
> > Caused by commit
> >
> > ed46ac8199f0 ("bitmap: introduce generic optimized bitmap_size()")
> >
> > I have used the bitmap tree from next-20231018 for today.
>
> Thanks, Stephen. I'll take a look and let you know when it's resolved.
Hi Stephen,
So the problem is that the patch "bitmap: introduce generic optimized
bitmap_size()" adds reference to the linux/align.h, which doesn't exist
in tools.
I removed tools part of the patch entirely, and now tools/perf, for
example, builds OK for me natively. The tree doesn't touch tools at
all now, except for moving BYTES_TO_BITS() from a source file to a
header, which looks safe.
Can you please try the latest bitmap-for-next?
Alexander, when you touch tools, it's can you build something from
it as part of your testing? I usually build tools/perf.
Thanks,
Yury
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2023-10-20 4:24 ` Yury Norov
@ 2023-10-20 4:51 ` Stephen Rothwell
2023-10-20 12:33 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2023-10-20 4:51 UTC (permalink / raw)
To: Yury Norov
Cc: Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]
Hi Yury,
On Thu, 19 Oct 2023 21:24:49 -0700 Yury Norov <yury.norov@gmail.com> wrote:
>
> On Thu, Oct 19, 2023 at 08:58:24AM -0700, Yury Norov wrote:
> > On Thu, Oct 19, 2023 at 05:01:06PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the bitmap tree, today's linux-next build (native perf)
> > > failed like this:
> > >
> > > In file included from /home/sfr/next/next/tools/perf/util/header.h:10,
> > > from /home/sfr/next/perf/pmu-events/pmu-events.c:3:
> > > /home/sfr/next/next/tools/include/linux/bitmap.h:5:10: fatal error: linux/align.h: No such file or directory
> > > 5 | #include <linux/align.h>
> > > | ^~~~~~~~~~~~~~~
> > >
> > > Caused by commit
> > >
> > > ed46ac8199f0 ("bitmap: introduce generic optimized bitmap_size()")
> > >
> > > I have used the bitmap tree from next-20231018 for today.
> >
> > Thanks, Stephen. I'll take a look and let you know when it's resolved.
>
> So the problem is that the patch "bitmap: introduce generic optimized
> bitmap_size()" adds reference to the linux/align.h, which doesn't exist
> in tools.
>
> I removed tools part of the patch entirely, and now tools/perf, for
> example, builds OK for me natively. The tree doesn't touch tools at
> all now, except for moving BYTES_TO_BITS() from a source file to a
> header, which looks safe.
Almost - see my other email.
> Can you please try the latest bitmap-for-next?
See above.
My "native" is PowerPC 64 LE.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2023-10-20 4:51 ` Stephen Rothwell
@ 2023-10-20 12:33 ` Yury Norov
2023-11-02 11:41 ` Alexander Lobakin
0 siblings, 1 reply; 38+ messages in thread
From: Yury Norov @ 2023-10-20 12:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
On Fri, Oct 20, 2023 at 03:51:13PM +1100, Stephen Rothwell wrote:
> Hi Yury,
>
> On Thu, 19 Oct 2023 21:24:49 -0700 Yury Norov <yury.norov@gmail.com> wrote:
> >
> > On Thu, Oct 19, 2023 at 08:58:24AM -0700, Yury Norov wrote:
> > > On Thu, Oct 19, 2023 at 05:01:06PM +1100, Stephen Rothwell wrote:
> > > >
> > > > After merging the bitmap tree, today's linux-next build (native perf)
> > > > failed like this:
> > > >
> > > > In file included from /home/sfr/next/next/tools/perf/util/header.h:10,
> > > > from /home/sfr/next/perf/pmu-events/pmu-events.c:3:
> > > > /home/sfr/next/next/tools/include/linux/bitmap.h:5:10: fatal error: linux/align.h: No such file or directory
> > > > 5 | #include <linux/align.h>
> > > > | ^~~~~~~~~~~~~~~
> > > >
> > > > Caused by commit
> > > >
> > > > ed46ac8199f0 ("bitmap: introduce generic optimized bitmap_size()")
> > > >
> > > > I have used the bitmap tree from next-20231018 for today.
> > >
> > > Thanks, Stephen. I'll take a look and let you know when it's resolved.
> >
> > So the problem is that the patch "bitmap: introduce generic optimized
> > bitmap_size()" adds reference to the linux/align.h, which doesn't exist
> > in tools.
> >
> > I removed tools part of the patch entirely, and now tools/perf, for
> > example, builds OK for me natively. The tree doesn't touch tools at
> > all now, except for moving BYTES_TO_BITS() from a source file to a
> > header, which looks safe.
>
> Almost - see my other email.
>
> > Can you please try the latest bitmap-for-next?
>
> See above.
>
> My "native" is PowerPC 64 LE.
I tried arm64. Anyways, it's clear that the series is not ready yet.
I'll drop it from bitmap_for_next. Sorry for this mess.
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2023-10-20 12:33 ` Yury Norov
@ 2023-11-02 11:41 ` Alexander Lobakin
0 siblings, 0 replies; 38+ messages in thread
From: Alexander Lobakin @ 2023-11-02 11:41 UTC (permalink / raw)
To: Yury Norov, Stephen Rothwell
Cc: Linux Kernel Mailing List, Linux Next Mailing List
From: Yury Norov <yury.norov@gmail.com>
Date: Fri, 20 Oct 2023 05:33:15 -0700
Sorry, was on long vacation :z
> On Fri, Oct 20, 2023 at 03:51:13PM +1100, Stephen Rothwell wrote:
>> Hi Yury,
>>
>> On Thu, 19 Oct 2023 21:24:49 -0700 Yury Norov <yury.norov@gmail.com> wrote:
>>>
>>> On Thu, Oct 19, 2023 at 08:58:24AM -0700, Yury Norov wrote:
>>>> On Thu, Oct 19, 2023 at 05:01:06PM +1100, Stephen Rothwell wrote:
>>>>>
>>>>> After merging the bitmap tree, today's linux-next build (native perf)
>>>>> failed like this:
>>>>>
>>>>> In file included from /home/sfr/next/next/tools/perf/util/header.h:10,
>>>>> from /home/sfr/next/perf/pmu-events/pmu-events.c:3:
>>>>> /home/sfr/next/next/tools/include/linux/bitmap.h:5:10: fatal error: linux/align.h: No such file or directory
>>>>> 5 | #include <linux/align.h>
>>>>> | ^~~~~~~~~~~~~~~
>>>>>
>>>>> Caused by commit
>>>>>
>>>>> ed46ac8199f0 ("bitmap: introduce generic optimized bitmap_size()")
>>>>>
>>>>> I have used the bitmap tree from next-20231018 for today.
>>>>
>>>> Thanks, Stephen. I'll take a look and let you know when it's resolved.
>>>
>>> So the problem is that the patch "bitmap: introduce generic optimized
>>> bitmap_size()" adds reference to the linux/align.h, which doesn't exist
>>> in tools.
>>>
>>> I removed tools part of the patch entirely, and now tools/perf, for
>>> example, builds OK for me natively. The tree doesn't touch tools at
>>> all now, except for moving BYTES_TO_BITS() from a source file to a
>>> header, which looks safe.
>>
>> Almost - see my other email.
>>
>>> Can you please try the latest bitmap-for-next?
>>
>> See above.
>>
>> My "native" is PowerPC 64 LE.
>
> I tried arm64. Anyways, it's clear that the series is not ready yet.
> I'll drop it from bitmap_for_next. Sorry for this mess.
Sorry for that, it was working for me. I'll resubmit once the window opens.
Thanks,
Olek
^ permalink raw reply [flat|nested] 38+ messages in thread
* linux-next: build failure after merge of the bitmap tree
@ 2022-09-26 23:53 broonie
2022-09-27 0:37 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: broonie @ 2022-09-26 23:53 UTC (permalink / raw)
To: Yury Norov; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
Hi all,
After merging the bitmap tree, today's linux-next build (x86
allmodconfig) failed like this:
In file included from /tmp/next/build/include/linux/printk.h:573,
from /tmp/next/build/include/linux/kernel.h:29,
from /tmp/next/build/arch/x86/include/asm/percpu.h:27,
from /tmp/next/build/arch/x86/include/asm/nospec-branch.h:14,
from /tmp/next/build/arch/x86/include/asm/paravirt_types.h:40,
from /tmp/next/build/arch/x86/include/asm/ptrace.h:97,
from /tmp/next/build/arch/x86/include/asm/math_emu.h:5,
from /tmp/next/build/arch/x86/include/asm/processor.h:13,
from /tmp/next/build/arch/x86/include/asm/timex.h:5,
from /tmp/next/build/include/linux/timex.h:67,
from /tmp/next/build/include/linux/time32.h:13,
from /tmp/next/build/include/linux/time.h:60,
from /tmp/next/build/include/linux/stat.h:19,
from /tmp/next/build/include/linux/module.h:13,
from /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:9:
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c: In function 'rvu_npc_exact_alloc_mem_table_entry':
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:454:20: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format=]
454 | dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%lu\n", __func__,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/dynamic_debug.h:223:15: note: in definition of macro '__dynamic_func_call_cls'
223 | func(&id, ##__VA_ARGS__); \
| ^~~~~~~~~~~
/tmp/next/build/include/linux/dynamic_debug.h:249:2: note: in expansion of macro '_dynamic_func_call_cls'
249 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/dynamic_debug.h:272:2: note: in expansion of macro '_dynamic_func_call'
272 | _dynamic_func_call(fmt, __dynamic_dev_dbg, \
| ^~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/dev_printk.h:155:2: note: in expansion of macro 'dynamic_dev_dbg'
155 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~
/tmp/next/build/include/linux/dev_printk.h:155:23: note: in expansion of macro 'dev_fmt'
155 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:454:2: note: in expansion of macro 'dev_dbg'
454 | dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%lu\n", __func__,
| ^~~~~~~
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:454:63: note: format string is defined here
454 | dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%lu\n", __func__,
| ~~^
| |
| long unsigned int
| %u
In file included from /tmp/next/build/include/linux/device.h:15,
from /tmp/next/build/include/linux/pci.h:37,
from /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:10:
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c: In function 'rvu_npc_exact_alloc_id':
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:21: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format=]
492 | dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/dev_printk.h:110:16: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
/tmp/next/build/include/linux/dev_printk.h:144:49: note: in expansion of macro 'dev_fmt'
144 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:3: note: in expansion of macro 'dev_err'
492 | dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
| ^~~~~~~
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:51: note: format string is defined here
492 | dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
| ~~^
| |
| long unsigned int
| %u
In file included from /tmp/next/build/include/linux/device.h:15,
from /tmp/next/build/include/linux/pci.h:37,
from /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:10:
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c: In function 'rvu_npc_exact_alloc_cam_table_entry':
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:525:22: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format=]
525 | dev_info(rvu->dev, "%s: No space in exact cam table, weight=%lu\n", __func__,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/dev_printk.h:110:16: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
/tmp/next/build/include/linux/dev_printk.h:150:51: note: in expansion of macro 'dev_fmt'
150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:525:3: note: in expansion of macro 'dev_info'
525 | dev_info(rvu->dev, "%s: No space in exact cam table, weight=%lu\n", __func__,
| ^~~~~~~~
/tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:525:65: note: format string is defined here
525 | dev_info(rvu->dev, "%s: No space in exact cam table, weight=%lu\n", __func__,
| ~~^
| |
| long unsigned int
| %u
cc1: all warnings being treated as errors
make[8]: *** [/tmp/next/build/scripts/Makefile.build:249: drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.o] Error 1
make[7]: *** [/tmp/next/build/scripts/Makefile.build:440: drivers/net/ethernet/marvell/octeontx2/af] Error 2
make[6]: *** [/tmp/next/build/scripts/Makefile.build:440: drivers/net/ethernet/marvell/octeontx2] Error 2
make[5]: *** [/tmp/next/build/scripts/Makefile.build:440: drivers/net/ethernet/marvell] Error 2
make[5]: *** Waiting for unfinished jobs....
/tmp/next/build/drivers/gpu/drm/i915/gt/intel_sseu.c: In function 'intel_sseu_print_ss_info':
/tmp/next/build/drivers/gpu/drm/i915/gt/intel_sseu.c:867:39: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format=]
867 | seq_printf(m, " %s Geometry DSS: %lu\n", type,
| ~~^
| |
| long unsigned int
| %u
868 | bitmap_weight(sseu->geometry_subslice_mask.xehp,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
869 | XEHP_BITMAP_BITS(sseu->geometry_subslice_mask)));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/gpu/drm/i915/gt/intel_sseu.c:870:38: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format=]
870 | seq_printf(m, " %s Compute DSS: %lu\n", type,
| ~~^
| |
| long unsigned int
| %u
871 | bitmap_weight(sseu->compute_subslice_mask.xehp,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
872 | XEHP_BITMAP_BITS(sseu->compute_subslice_mask)));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
These look like they have probably been there for a while but I've used
a slightly different compiler version to Stephen so they're showing up
now once the bitmap tree is merged. I will have a proper look tomorrow
hopefully but for now I've dropped the bitmap tree as it's getting very
late and it is likely I'll not finish the -next run today at all.
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2022-09-26 23:53 broonie
@ 2022-09-27 0:37 ` Yury Norov
2022-09-27 18:56 ` Mark Brown
0 siblings, 1 reply; 38+ messages in thread
From: Yury Norov @ 2022-09-27 0:37 UTC (permalink / raw)
To: broonie; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Sep 27, 2022 at 12:53:48AM +0100, broonie@kernel.org wrote:
> Hi all,
>
> After merging the bitmap tree, today's linux-next build (x86
> allmodconfig) failed like this:
Hmm, this weird. I checked the next-20220923, and the drivers' code
mentioned in the log differs from what I see, and looks correct.
bitmap_weight() definition hasn't been changed in bitmap-for-next
patches.
Allmodconfig build looks good to me.
Check what I see in next-20220923 below.
Thanks,
Yury
> /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:3: note: in expansion of macro 'dev_err'
> 492 | dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
> | ^~~~~~~
> /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:51: note: format string is defined here
> 492 | dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
> | ~~^
> | |
> | long unsigned int
> | %u
dev_err(rvu->dev, "%s: No space in id bitmap (%d)\n",
__func__, bitmap_weight(table->id_bmap, table->tot_ids));
> /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:525:22: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format=]
> 525 | dev_info(rvu->dev, "%s: No space in exact cam table, weight=%lu\n", __func__,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dev_info(rvu->dev, "%s: No space in exact cam table, weight=%u\n", __func__,
bitmap_weight(table->cam_table.bmap, table->cam_table.depth));jj
> /tmp/next/build/drivers/gpu/drm/i915/gt/intel_sseu.c:867:39: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format=]
> 867 | seq_printf(m, " %s Geometry DSS: %lu\n", type,
> | ~~^
> | |
> | long unsigned int
> | %u
> 868 | bitmap_weight(sseu->geometry_subslice_mask.xehp,
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | |
> | unsigned int
> 869 | XEHP_BITMAP_BITS(sseu->geometry_subslice_mask)));
seq_printf(m, " %s Geometry DSS: %u\n", type,
bitmap_weight(sseu->geometry_subslice_mask.xehp,
XEHP_BITMAP_BITS(sseu->geometry_subslice_mask)));
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/gpu/drm/i915/gt/intel_sseu.c:870:38: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format=]
> 870 | seq_printf(m, " %s Compute DSS: %lu\n", type,
> | ~~^
> | |
> | long unsigned int
> | %u
> 871 | bitmap_weight(sseu->compute_subslice_mask.xehp,
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | |
> | unsigned int
> 872 | XEHP_BITMAP_BITS(sseu->compute_subslice_mask)));
bitmap_weight(sseu->compute_subslice_mask.xehp,
XEHP_BITMAP_BITS(sseu->compute_subslice_mask)));
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> These look like they have probably been there for a while but I've used
> a slightly different compiler version to Stephen so they're showing up
> now once the bitmap tree is merged. I will have a proper look tomorrow
> hopefully but for now I've dropped the bitmap tree as it's getting very
> late and it is likely I'll not finish the -next run today at all.
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2022-09-27 0:37 ` Yury Norov
@ 2022-09-27 18:56 ` Mark Brown
0 siblings, 0 replies; 38+ messages in thread
From: Mark Brown @ 2022-09-27 18:56 UTC (permalink / raw)
To: Yury Norov; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On Mon, Sep 26, 2022 at 05:37:46PM -0700, Yury Norov wrote:
> On Tue, Sep 27, 2022 at 12:53:48AM +0100, broonie@kernel.org wrote:
> > After merging the bitmap tree, today's linux-next build (x86
> > allmodconfig) failed like this:
> Hmm, this weird. I checked the next-20220923, and the drivers' code
> mentioned in the log differs from what I see, and looks correct.
> bitmap_weight() definition hasn't been changed in bitmap-for-next
> patches.
> Allmodconfig build looks good to me.
> Check what I see in next-20220923 below.
I'm seeing the same issue again today, the driver hasn't changed here -
the
> > /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:3: note: in expansion of macro 'dev_err'
> > 492 | dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
> > | ^~~~~~~
> > /tmp/next/build/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:51: note: format string is defined here
> > 492 | dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
> > | ~~^
> > | |
> > | long unsigned int
> > | %u
> dev_err(rvu->dev, "%s: No space in id bitmap (%d)\n",
> __func__, bitmap_weight(table->id_bmap, table->tot_ids));
This is coming from a patch Stephen had in his tree "fix up for
bitmap_weight return value changing" which had been in -next, apparently
fixing some other issue which had been in your tree. With that removed
things seem fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* linux-next: build failure after merge of the bitmap tree
@ 2022-09-20 8:08 Stephen Rothwell
2022-09-20 14:49 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2022-09-20 8:08 UTC (permalink / raw)
To: Yury Norov; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (powerpc
allyesconfig) failed like this:
ld: arch/powerpc/kernel/head_64.o: in function `generic_secondary_common_init':
(.text+0x545e): undefined reference to `nr_cpu_ids'
Caused by commit
c90c5bd9f2d6 ("lib/cpumask: add FORCE_NR_CPUS config option")
This build has CONFIG_FORCE_NR_CPUS set but the (assembler) code expects
nr_cpu_ids to be a variable ...
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2022-09-20 8:08 Stephen Rothwell
@ 2022-09-20 14:49 ` Yury Norov
0 siblings, 0 replies; 38+ messages in thread
From: Yury Norov @ 2022-09-20 14:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Sep 20, 2022 at 06:08:39PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bitmap tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> ld: arch/powerpc/kernel/head_64.o: in function `generic_secondary_common_init':
> (.text+0x545e): undefined reference to `nr_cpu_ids'
>
> Caused by commit
>
> c90c5bd9f2d6 ("lib/cpumask: add FORCE_NR_CPUS config option")
>
> This build has CONFIG_FORCE_NR_CPUS set but the (assembler) code expects
> nr_cpu_ids to be a variable ...
>
> I have reverted that commit for today.
Thanks for report, Stephen.
I did PPC build for bitmap-for-next, and it was OK on top of
v6-rc4. On today's -next I can reproduce the failure. It's weird
because the code in trouble was added at 2011 in 768d18ad6d5e6
("powerpc: Don't search for paca in freed memory").
Anyways, the fix is straightforward. I updated the bitmap-for-next
with it, and will send it for review shortly.
--
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index cf2c08902c05..7cb97881635e 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -400,7 +400,11 @@ generic_secondary_common_init:
#else
LOAD_REG_ADDR(r8, paca_ptrs) /* Load paca_ptrs pointe */
ld r8,0(r8) /* Get base vaddr of array */
+#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
+ LOAD_REG_IMMEDIATE(r7, NR_CPUS)
+#else
LOAD_REG_ADDR(r7, nr_cpu_ids) /* Load nr_cpu_ids address */
+#endif
lwz r7,0(r7) /* also the max paca allocated */
li r5,0 /* logical cpu id */
1:
^ permalink raw reply related [flat|nested] 38+ messages in thread
* linux-next: build failure after merge of the bitmap tree
@ 2022-07-27 10:29 Stephen Rothwell
0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2022-07-27 10:29 UTC (permalink / raw)
To: Yury Norov
Cc: Michael Ellerman, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: modpost: ".arch_get_random_seed_longs" [arch/powerpc/kvm/kvm-hv.ko] undefined!
Caused by commit
c3aaaf9e2ada ("powerpc: drop dependency on <asm/machdep.h> in archrandom.h")
It seems that the EXPORT was needed. I applied the following for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 27 Jul 2022 20:21:53 +1000
Subject: [PATCH] fixup for "powerpc: drop dependency on <asm/machdep.h> in
archrandom.h"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/setup-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 91f8982c61a0..463072ed40e8 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -177,6 +177,7 @@ size_t arch_get_random_seed_longs(unsigned long *v, size_t max_longs)
return 1;
return 0;
}
+EXPORT_SYMBOL_GPL(arch_get_random_seed_longs);
void machine_halt(void)
{
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 38+ messages in thread* linux-next: build failure after merge of the bitmap tree
@ 2022-07-22 9:16 Stephen Rothwell
2022-07-22 19:29 ` Yury Norov
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2022-07-22 9:16 UTC (permalink / raw)
To: Yury Norov; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 14825 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/cred.h:16,
from include/linux/seq_file.h:13,
from arch/powerpc/include/asm/machdep.h:6,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/sched.h:1203:9: error: unknown type name 'nodemask_t'
1203 | nodemask_t mems_allowed;
| ^~~~~~~~~~
In file included from include/linux/gfp.h:7,
from include/linux/percpu_counter.h:16,
from include/linux/sched/user.h:7,
from include/linux/cred.h:17,
from include/linux/seq_file.h:13,
from arch/powerpc/include/asm/machdep.h:6,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/mmzone.h:1166:41: error: unknown type name 'nodemask_t'
1166 | nodemask_t *nodes);
| ^~~~~~~~~~
In file included from include/linux/gfp.h:7,
from include/linux/percpu_counter.h:16,
from include/linux/sched/user.h:7,
from include/linux/cred.h:17,
from include/linux/seq_file.h:13,
from arch/powerpc/include/asm/machdep.h:6,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/mmzone.h:1185:41: error: unknown type name 'nodemask_t'
1185 | nodemask_t *nodes)
| ^~~~~~~~~~
include/linux/mmzone.h:1211:41: error: unknown type name 'nodemask_t'
1211 | nodemask_t *nodes)
| ^~~~~~~~~~
include/linux/mmzone.h:1254:39: error: unknown type name 'nodemask_t'
1254 | static inline bool movable_only_nodes(nodemask_t *nodes)
| ^~~~~~~~~~
In file included from include/linux/percpu_counter.h:16,
from include/linux/sched/user.h:7,
from include/linux/cred.h:17,
from include/linux/seq_file.h:13,
from arch/powerpc/include/asm/machdep.h:6,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/gfp.h:198:17: error: unknown type name 'nodemask_t'
198 | nodemask_t *nodemask);
| ^~~~~~~~~~
include/linux/gfp.h:200:17: error: unknown type name 'nodemask_t'
200 | nodemask_t *nodemask);
| ^~~~~~~~~~
include/linux/gfp.h:203:33: error: unknown type name 'nodemask_t'
203 | nodemask_t *nodemask, int nr_pages,
| ^~~~~~~~~~
include/linux/gfp.h: In function 'alloc_pages_bulk_list':
include/linux/gfp.h:215:16: error: implicit declaration of function '__alloc_pages_bulk'; did you mean 'alloc_pages_bulk_list'? [-Werror=implicit-function-declaration]
215 | return __alloc_pages_bulk(gfp, numa_mem_id(), NULL, nr_pages, list, NULL);
| ^~~~~~~~~~~~~~~~~~
| alloc_pages_bulk_list
In file included from include/linux/container_of.h:5,
from include/linux/list.h:5,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:55,
from include/linux/ipc.h:5,
from include/uapi/linux/sem.h:5,
from include/linux/sem.h:5,
from include/linux/compat.h:14,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/gfp.h: In function '__alloc_pages_node':
include/linux/gfp.h:241:52: error: implicit declaration of function 'node_online'; did you mean 'node_zonelist'? [-Werror=implicit-function-declaration]
241 | VM_WARN_ON((gfp_mask & __GFP_THISNODE) && !node_online(nid));
| ^~~~~~~~~~~
include/linux/build_bug.h:30:63: note: in definition of macro 'BUILD_BUG_ON_INVALID'
30 | #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
| ^
include/linux/gfp.h:241:9: note: in expansion of macro 'VM_WARN_ON'
241 | VM_WARN_ON((gfp_mask & __GFP_THISNODE) && !node_online(nid));
| ^~~~~~~~~~
In file included from include/linux/percpu_counter.h:16,
from include/linux/sched/user.h:7,
from include/linux/cred.h:17,
from include/linux/seq_file.h:13,
from arch/powerpc/include/asm/machdep.h:6,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/gfp.h:243:16: error: implicit declaration of function '__alloc_pages'; did you mean '__add_pages'? [-Werror=implicit-function-declaration]
243 | return __alloc_pages(gfp_mask, order, nid, NULL);
| ^~~~~~~~~~~~~
| __add_pages
include/linux/gfp.h:243:16: warning: returning 'int' from a function with return type 'struct page *' makes pointer from integer without a cast [-Wint-conversion]
243 | return __alloc_pages(gfp_mask, order, nid, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/gfp.h: In function '__folio_alloc_node':
include/linux/gfp.h:252:16: error: implicit declaration of function '__folio_alloc'; did you mean '__folio_alloc_node'? [-Werror=implicit-function-declaration]
252 | return __folio_alloc(gfp, order, nid, NULL);
| ^~~~~~~~~~~~~
| __folio_alloc_node
include/linux/gfp.h:252:16: warning: returning 'int' from a function with return type 'struct folio *' makes pointer from integer without a cast [-Wint-conversion]
252 | return __folio_alloc(gfp, order, nid, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/gfp.h: At top level:
include/linux/gfp.h:366:49: error: unknown type name 'nodemask_t'
366 | int nid, nodemask_t *nodemask);
| ^~~~~~~~~~
In file included from include/linux/mm.h:703,
from include/linux/scatterlist.h:8,
from include/linux/dma-mapping.h:10,
from arch/powerpc/include/asm/machdep.h:8,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/huge_mm.h: In function '__transparent_hugepage_enabled':
include/linux/huge_mm.h:166:13: error: implicit declaration of function 'vma_is_dax' [-Werror=implicit-function-declaration]
166 | if (vma_is_dax(vma))
| ^~~~~~~~~~
include/linux/huge_mm.h: In function 'file_thp_enabled':
include/linux/huge_mm.h:183:29: error: invalid use of undefined type 'struct file'
183 | inode = vma->vm_file->f_inode;
| ^~
include/linux/huge_mm.h:187:17: error: implicit declaration of function 'inode_is_open_for_write' [-Werror=implicit-function-declaration]
187 | !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/stat.h:7,
from include/linux/compat.h:12,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/huge_mm.h:187:64: error: invalid use of undefined type 'struct inode'
187 | !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
| ^~
include/uapi/linux/stat.h:22:28: note: in definition of macro 'S_ISREG'
22 | #define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
| ^
In file included from include/linux/scatterlist.h:8,
from include/linux/dma-mapping.h:10,
from arch/powerpc/include/asm/machdep.h:8,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/mm.h: At top level:
include/linux/mm.h:1833:49: error: unknown type name 'nodemask_t'
1833 | extern void show_free_areas(unsigned int flags, nodemask_t *nodemask);
| ^~~~~~~~~~
include/linux/mm.h: In function 'get_num_physpages':
include/linux/mm.h:2518:9: error: implicit declaration of function 'for_each_online_node'; did you mean 'for_each_online_pgdat'? [-Werror=implicit-function-declaration]
2518 | for_each_online_node(nid)
| ^~~~~~~~~~~~~~~~~~~~
| for_each_online_pgdat
include/linux/mm.h:2518:34: error: expected ';' before 'phys_pages'
2518 | for_each_online_node(nid)
| ^
| ;
2519 | phys_pages += node_present_pages(nid);
| ~~~~~~~~~~
include/linux/mm.h: At top level:
include/linux/mm.h:2569:42: error: unknown type name 'nodemask_t'
2569 | extern void show_mem(unsigned int flags, nodemask_t *nodemask);
| ^~~~~~~~~~
include/linux/mm.h:2578:33: error: unknown type name 'nodemask_t'
2578 | void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...);
| ^~~~~~~~~~
include/linux/mm.h: In function 'seal_check_future_write':
include/linux/mm.h:3411:21: error: 'F_SEAL_FUTURE_WRITE' undeclared (first use in this function)
3411 | if (seals & F_SEAL_FUTURE_WRITE) {
| ^~~~~~~~~~~~~~~~~~~
include/linux/mm.h:3411:21: note: each undeclared identifier is reported only once for each function it appears in
In file included from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/fs.h: At top level:
include/linux/fs.h:2977:20: error: conflicting types for 'inode_is_open_for_write'; have 'bool(const struct inode *)' {aka '_Bool(const struct inode *)'}
2977 | static inline bool inode_is_open_for_write(const struct inode *inode)
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/mm.h:703,
from include/linux/scatterlist.h:8,
from include/linux/dma-mapping.h:10,
from arch/powerpc/include/asm/machdep.h:8,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/huge_mm.h:187:17: note: previous implicit declaration of 'inode_is_open_for_write' with type 'int()'
187 | !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/fs.h:3364:20: error: conflicting types for 'vma_is_dax'; have 'bool(const struct vm_area_struct *)' {aka '_Bool(const struct vm_area_struct *)'}
3364 | static inline bool vma_is_dax(const struct vm_area_struct *vma)
| ^~~~~~~~~~
In file included from include/linux/mm.h:703,
from include/linux/scatterlist.h:8,
from include/linux/dma-mapping.h:10,
from arch/powerpc/include/asm/machdep.h:8,
from arch/powerpc/include/asm/archrandom.h:5,
from include/linux/random.h:109,
from include/linux/nodemask.h:97,
from include/linux/list_lru.h:12,
from include/linux/fs.h:13,
from include/linux/compat.h:17,
from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/huge_mm.h:166:13: note: previous implicit declaration of 'vma_is_dax' with type 'int()'
166 | if (vma_is_dax(vma))
| ^~~~~~~~~~
I am not sure which commit caused this. Though I suspect
bbe8fb1a3c53 ("lib/nodemask: inline next_node_in() and node_random()")
which added the include of random.h to nodemask.h
I have used the bitmap tree from next-20220721 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: linux-next: build failure after merge of the bitmap tree
2022-07-22 9:16 Stephen Rothwell
@ 2022-07-22 19:29 ` Yury Norov
0 siblings, 0 replies; 38+ messages in thread
From: Yury Norov @ 2022-07-22 19:29 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Fri, Jul 22, 2022 at 07:16:57PM +1000, Stephen Rothwell wrote:
> Hi all,
...
> I am not sure which commit caused this. Though I suspect
>
> bbe8fb1a3c53 ("lib/nodemask: inline next_node_in() and node_random()")
>
> which added the include of random.h to nodemask.h
>
> I have used the bitmap tree from next-20220721 for today.
Hi Stephen,
You're right. The problem in the last patch of the series. I've got
the fix already, and testing it now.
I'll drop the bbe8fb1a3c53 and submit it separately together with
header fix.
Thanks,
Yury
^ permalink raw reply [flat|nested] 38+ messages in thread
* linux-next: build failure after merge of the bitmap tree
@ 2022-07-15 10:29 Stephen Rothwell
0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2022-07-15 10:29 UTC (permalink / raw)
To: Yury Norov, Dave Airlie, David Miller
Cc: Networking, DRI, Matt Roper, Jakub Kicinski, Ratheesh Kannoth,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 11939 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/gt/intel_sseu.c: In function 'intel_sseu_print_ss_info':
drivers/gpu/drm/i915/gt/intel_sseu.c:868:52: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format=]
868 | seq_printf(m, " %s Geometry DSS: %u\n", type,
| ~^
| |
| unsigned int
| %lu
869 | bitmap_weight(sseu->geometry_subslice_mask.xehp,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| long unsigned int
870 | XEHP_BITMAP_BITS(sseu->geometry_subslice_mask)));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/gt/intel_sseu.c:871:51: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format=]
871 | seq_printf(m, " %s Compute DSS: %u\n", type,
| ~^
| |
| unsigned int
| %lu
872 | bitmap_weight(sseu->compute_subslice_mask.xehp,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| long unsigned int
873 | XEHP_BITMAP_BITS(sseu->compute_subslice_mask)));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
In file included from include/linux/printk.h:573,
from include/linux/kernel.h:29,
from arch/x86/include/asm/percpu.h:27,
from arch/x86/include/asm/nospec-branch.h:14,
from arch/x86/include/asm/paravirt_types.h:40,
from arch/x86/include/asm/ptrace.h:97,
from arch/x86/include/asm/math_emu.h:5,
from arch/x86/include/asm/processor.h:13,
from arch/x86/include/asm/timex.h:5,
from include/linux/timex.h:67,
from include/linux/time32.h:13,
from include/linux/time.h:60,
from include/linux/stat.h:19,
from include/linux/module.h:13,
from drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:9:
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c: In function 'rvu_npc_exact_alloc_mem_table_entry':
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:454:27: error: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Werror=format=]
454 | dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%u\n", __func__,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:134:29: note: in definition of macro '__dynamic_func_call'
134 | func(&id, ##__VA_ARGS__); \
| ^~~~~~~~~~~
include/linux/dynamic_debug.h:166:9: note: in expansion of macro '_dynamic_func_call'
166 | _dynamic_func_call(fmt,__dynamic_dev_dbg, \
| ^~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:155:9: note: in expansion of macro 'dynamic_dev_dbg'
155 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/dev_printk.h:155:30: note: in expansion of macro 'dev_fmt'
155 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:454:9: note: in expansion of macro 'dev_dbg'
454 | dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%u\n", __func__,
| ^~~~~~~
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:454:69: note: format string is defined here
454 | dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%u\n", __func__,
| ~^
| |
| unsigned int
| %lu
In file included from include/linux/device.h:15,
from include/linux/pci.h:37,
from drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:10:
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c: In function 'rvu_npc_exact_alloc_id':
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:35: error: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Werror=format=]
492 | dev_err(rvu->dev, "%s: No space in id bitmap (%d)\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:144:56: note: in expansion of macro 'dev_fmt'
144 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:17: note: in expansion of macro 'dev_err'
492 | dev_err(rvu->dev, "%s: No space in id bitmap (%d)\n",
| ^~~~~~~
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:492:64: note: format string is defined here
492 | dev_err(rvu->dev, "%s: No space in id bitmap (%d)\n",
| ~^
| |
| int
| %ld
In file included from include/linux/device.h:15,
from include/linux/pci.h:37,
from drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:10:
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c: In function 'rvu_npc_exact_alloc_cam_table_entry':
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:525:36: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format=]
525 | dev_info(rvu->dev, "%s: No space in exact cam table, weight=%u\n", __func__,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:150:58: note: in expansion of macro 'dev_fmt'
150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:525:17: note: in expansion of macro 'dev_info'
525 | dev_info(rvu->dev, "%s: No space in exact cam table, weight=%u\n", __func__,
| ^~~~~~~~
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c:525:78: note: format string is defined here
525 | dev_info(rvu->dev, "%s: No space in exact cam table, weight=%u\n", __func__,
| ~^
| |
| unsigned int
| %lu
cc1: all warnings being treated as errors
Caused by commit
31563fb891aa ("lib/bitmap: change type of bitmap_weight to unsigned long")
interacting with commits
b87d39019651 ("drm/i915/sseu: Disassociate internal subslice mask representation from uapi")
from the drm tree and
b747923afff8 ("octeontx2-af: Exact match support")
from the net-next tree.
I have applied the following merge resolution patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Jul 2022 20:20:15 +1000
Subject: [PATCH] fix up for bitmap_weight return value changing
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 4 ++--
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c b/drivers/gpu/drm/i915/gt/intel_sseu.c
index c6d3050604c8..79fa564785b6 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -865,10 +865,10 @@ void intel_sseu_print_ss_info(const char *type,
int s;
if (sseu->has_xehp_dss) {
- seq_printf(m, " %s Geometry DSS: %u\n", type,
+ seq_printf(m, " %s Geometry DSS: %lu\n", type,
bitmap_weight(sseu->geometry_subslice_mask.xehp,
XEHP_BITMAP_BITS(sseu->geometry_subslice_mask)));
- seq_printf(m, " %s Compute DSS: %u\n", type,
+ seq_printf(m, " %s Compute DSS: %lu\n", type,
bitmap_weight(sseu->compute_subslice_mask.xehp,
XEHP_BITMAP_BITS(sseu->compute_subslice_mask)));
} else {
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c
index 1195b690f483..2f4ce41df83c 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c
@@ -451,7 +451,7 @@ static int rvu_npc_exact_alloc_mem_table_entry(struct rvu *rvu, u8 *way,
}
mutex_unlock(&table->lock);
- dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%u\n", __func__,
+ dev_dbg(rvu->dev, "%s: No space in 4 way exact way, weight=%lu\n", __func__,
bitmap_weight(table->mem_table.bmap, table->mem_table.depth));
return -ENOSPC;
}
@@ -489,7 +489,7 @@ static bool rvu_npc_exact_alloc_id(struct rvu *rvu, u32 *seq_id)
idx = find_first_zero_bit(table->id_bmap, table->tot_ids);
if (idx == table->tot_ids) {
mutex_unlock(&table->lock);
- dev_err(rvu->dev, "%s: No space in id bitmap (%d)\n",
+ dev_err(rvu->dev, "%s: No space in id bitmap (%lu)\n",
__func__, bitmap_weight(table->id_bmap, table->tot_ids));
return false;
@@ -522,7 +522,7 @@ static int rvu_npc_exact_alloc_cam_table_entry(struct rvu *rvu, int *index)
idx = find_first_zero_bit(table->cam_table.bmap, table->cam_table.depth);
if (idx == table->cam_table.depth) {
mutex_unlock(&table->lock);
- dev_info(rvu->dev, "%s: No space in exact cam table, weight=%u\n", __func__,
+ dev_info(rvu->dev, "%s: No space in exact cam table, weight=%lu\n", __func__,
bitmap_weight(table->cam_table.bmap, table->cam_table.depth));
return -ENOSPC;
}
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 38+ messages in thread* linux-next: build failure after merge of the bitmap tree
@ 2022-07-08 7:47 Stephen Rothwell
0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2022-07-08 7:47 UTC (permalink / raw)
To: Yury Norov
Cc: Paul Menzel, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
lib/bitmap.c:351:6: error: conflicting types for '__bitmap_set'; have 'void(long unsigned int *, unsigned int, unsigned int)'
351 | void __bitmap_set(unsigned long *map, unsigned int start, unsigned int len)
| ^~~~~~~~~~~~
In file included from lib/bitmap.c:7:
include/linux/bitmap.h:167:6: note: previous declaration of '__bitmap_set' with type 'void(long unsigned int *, unsigned int, int)'
167 | void __bitmap_set(unsigned long *map, unsigned int start, int len);
| ^~~~~~~~~~~~
In file included from include/linux/linkage.h:7,
from include/linux/printk.h:8,
from include/asm-generic/bug.h:22,
from arch/powerpc/include/asm/bug.h:158,
from include/linux/bug.h:5,
from lib/bitmap.c:9:
lib/bitmap.c:370:15: error: conflicting types for '__bitmap_set'; have 'void(long unsigned int *, unsigned int, unsigned int)'
370 | EXPORT_SYMBOL(__bitmap_set);
| ^~~~~~~~~~~~
include/linux/export.h:87:28: note: in definition of macro '___EXPORT_SYMBOL'
87 | extern typeof(sym) sym; \
| ^~~
include/linux/export.h:147:41: note: in expansion of macro '__EXPORT_SYMBOL'
147 | #define _EXPORT_SYMBOL(sym, sec) __EXPORT_SYMBOL(sym, sec, "")
| ^~~~~~~~~~~~~~~
include/linux/export.h:150:41: note: in expansion of macro '_EXPORT_SYMBOL'
150 | #define EXPORT_SYMBOL(sym) _EXPORT_SYMBOL(sym, "")
| ^~~~~~~~~~~~~~
lib/bitmap.c:370:1: note: in expansion of macro 'EXPORT_SYMBOL'
370 | EXPORT_SYMBOL(__bitmap_set);
| ^~~~~~~~~~~~~
In file included from lib/bitmap.c:7:
include/linux/bitmap.h:167:6: note: previous declaration of '__bitmap_set' with type 'void(long unsigned int *, unsigned int, int)'
167 | void __bitmap_set(unsigned long *map, unsigned int start, int len);
| ^~~~~~~~~~~~
Caused by commit
aaa4ab5ec044 ("lib/bitmap: Make length parameter `len` unsigned")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* linux-next: build failure after merge of the bitmap tree
@ 2022-05-02 8:15 Stephen Rothwell
0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2022-05-02 8:15 UTC (permalink / raw)
To: Yury Norov; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (native perf)
failed like this:
../lib/bitmap.c:21:5: error: conflicting types for '__bitmap_weight_cmp'; have 'int(const long unsigned int *, unsigned int, int)'
21 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits, int num)
| ^~~~~~~~~~~~~~~~~~~
In file included from ../lib/bitmap.c:6:
tools/include/linux/bitmap.h:15:5: note: previous declaration of '__bitmap_weight_cmp' with type 'int(const long unsigned int *, unsigned int, unsigned int)'
15 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits,
| ^~~~~~~~~~~~~~~~~~~
../lib/bitmap.c: In function '__bitmap_weight_cmp':
../lib/bitmap.c:26:50: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
26 | if (w + bits - k * BITS_PER_LONG < num)
| ^
../lib/bitmap.c:31:23: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
31 | if (w > num)
| ^
cc1: all warnings being treated as errors
tools/perf/../lib/bitmap.c:21:5: error: conflicting types for '__bitmap_weight_cmp'; have 'int(const long unsigned int *, unsigned int, int)'
21 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits, int num)
| ^~~~~~~~~~~~~~~~~~~
In file included from tools/perf/../lib/bitmap.c:6:
tools/include/linux/bitmap.h:15:5: note: previous declaration of '__bitmap_weight_cmp' with type 'int(const long unsigned int *, unsigned int, unsigned int)'
15 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits,
| ^~~~~~~~~~~~~~~~~~~
tools/perf/../lib/bitmap.c: In function '__bitmap_weight_cmp':
tools/perf/../lib/bitmap.c:26:50: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
26 | if (w + bits - k * BITS_PER_LONG < num)
| ^
tools/perf/../lib/bitmap.c:31:23: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
31 | if (w > num)
| ^
cc1: all warnings being treated as errors
Probably caused by commit
4252f3915e02 ("tools: bitmap: sync bitmap_weight")
I have used the bitmap tree from next-20220429 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* linux-next: build failure after merge of the bitmap tree
@ 2022-04-19 4:29 Stephen Rothwell
0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2022-04-19 4:29 UTC (permalink / raw)
To: Yury Norov; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]
Hi all,
After merging the bitmap tree, today's linux-next build (native powerpcle
perf) failed like this:
../lib/bitmap.c:21:5: error: conflicting types for '__bitmap_weight_cmp'; have 'int(const long unsigned int *, unsigned int, int)'
21 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits, int num)
| ^~~~~~~~~~~~~~~~~~~
In file included from ../lib/bitmap.c:6:
tools/include/linux/bitmap.h:15:5: note: previous declaration of '__bitmap_weight_cmp' with type 'int(const long unsigned int *, unsigned int, unsigned int)'
15 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits,
| ^~~~~~~~~~~~~~~~~~~
../lib/bitmap.c: In function '__bitmap_weight_cmp':
../lib/bitmap.c:26:50: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
26 | if (w + bits - k * BITS_PER_LONG < num)
| ^
../lib/bitmap.c:31:23: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
31 | if (w > num)
| ^
cc1: all warnings being treated as errors
tools/perf/../lib/bitmap.c:21:5: error: conflicting types for '__bitmap_weight_cmp'; have 'int(const long unsigned int *, unsigned int, int)'
21 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits, int num)
| ^~~~~~~~~~~~~~~~~~~
In file included from tools/perf/../lib/bitmap.c:6:
tools/include/linux/bitmap.h:15:5: note: previous declaration of '__bitmap_weight_cmp' with type 'int(const long unsigned int *, unsigned int, unsigned int)'
15 | int __bitmap_weight_cmp(const unsigned long *bitmap, unsigned int bits,
| ^~~~~~~~~~~~~~~~~~~
tools/perf/../lib/bitmap.c: In function '__bitmap_weight_cmp':
tools/perf/../lib/bitmap.c:26:50: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
26 | if (w + bits - k * BITS_PER_LONG < num)
| ^
tools/perf/../lib/bitmap.c:31:23: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
31 | if (w > num)
| ^
cc1: all warnings being treated as errors
Caused by commit
bf04367e90b2 ("tools: bitmap: sync bitmap_weight")
I have dropped the bitmap tree for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2025-11-28 8:17 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-25 7:24 linux-next: build failure after merge of the bitmap tree Stephen Rothwell
2025-11-25 8:05 ` Geert Uytterhoeven
2025-11-25 8:31 ` Miquel Raynal
2025-11-25 8:37 ` Geert Uytterhoeven
2025-11-25 14:44 ` Yury Norov
2025-11-25 14:55 ` Miquel Raynal
2025-11-25 8:53 ` Miquel Raynal
2025-11-28 8:17 ` Miquel Raynal
-- strict thread matches above, loose matches on Subject: below --
2025-02-18 5:07 Stephen Rothwell
2025-02-18 10:35 ` Beata Michalska
2025-02-18 13:49 ` Stephen Rothwell
2025-02-18 14:10 ` Catalin Marinas
2025-02-18 14:16 ` Yury Norov
2025-02-18 18:23 ` Catalin Marinas
2025-02-18 19:28 ` Beata Michalska
2025-02-18 19:44 ` Catalin Marinas
2024-05-08 6:27 Stephen Rothwell
2024-05-08 13:24 ` Kuan-Wei Chiu
2024-05-08 22:18 ` Yury Norov
2023-10-20 4:49 Stephen Rothwell
2023-10-19 6:01 Stephen Rothwell
2023-10-19 15:58 ` Yury Norov
2023-10-20 4:24 ` Yury Norov
2023-10-20 4:51 ` Stephen Rothwell
2023-10-20 12:33 ` Yury Norov
2023-11-02 11:41 ` Alexander Lobakin
2022-09-26 23:53 broonie
2022-09-27 0:37 ` Yury Norov
2022-09-27 18:56 ` Mark Brown
2022-09-20 8:08 Stephen Rothwell
2022-09-20 14:49 ` Yury Norov
2022-07-27 10:29 Stephen Rothwell
2022-07-22 9:16 Stephen Rothwell
2022-07-22 19:29 ` Yury Norov
2022-07-15 10:29 Stephen Rothwell
2022-07-08 7:47 Stephen Rothwell
2022-05-02 8:15 Stephen Rothwell
2022-04-19 4:29 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).