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

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

[Stephen Rothwell]

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

Hi all,

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

drivers/nvmem/nvmem_stm32_romem: struct of_device_id is 200 bytes.  The last of 3 is:
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x74 0x2c 0x73 0x74 0x6d 0x33 0x32 0x6d 0x70 0x31 0x33 0x2d 0x62 0x73 0x65 0x63 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
FATAL: modpost: drivers/nvmem/nvmem_stm32_romem: struct of_device_id is not terminated with a NULL entry!

Caused by commit

  55ca3192d007 ("nvmem: stm32: add OP-TEE support for STM32MP13x")

I have used the nvmem tree from next-20221031 for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Srinivas Kandagatla]

Thanks Stephen,



On 01/11/2022 03:21, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the nvmem tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/nvmem/nvmem_stm32_romem: struct of_device_id is 200 bytes.  The last of 3 is:
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x74 0x2c 0x73 0x74 0x6d 0x33 0x32 0x6d 0x70 0x31 0x33 0x2d 0x62 0x73 0x65 0x63 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> FATAL: modpost: drivers/nvmem/nvmem_stm32_romem: struct of_device_id is not terminated with a NULL entry!
> 
> Caused by commit

As there are some other comments on the patch, removing this until those 
are fixed.

--srini
> 
>    55ca3192d007 ("nvmem: stm32: add OP-TEE support for STM32MP13x")
> 
> I have used the nvmem tree from next-20221031 for today.
> 

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

[Stephen Rothwell]

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

Hi all,

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

drivers/nvmem/sec-qfprom.c: In function 'sec_qfprom_probe':
drivers/nvmem/sec-qfprom.c:59:13: error: unused variable 'ret' [-Werror=unused-variable]
   59 |         int ret;
      |             ^~~
cc1: all warnings being treated as errors

Caused by commit

  9c7f2bce8a0e ("nvmem: sec-qfprom: Add Qualcomm secure QFPROM support")

I have used the nvmem tree from next-20230809 for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Tue, 15 Aug 2023 20:25:08 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> After merging the nvmem tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/nvmem/sec-qfprom.c: In function 'sec_qfprom_probe':
> drivers/nvmem/sec-qfprom.c:59:13: error: unused variable 'ret' [-Werror=unused-variable]
>    59 |         int ret;
>       |             ^~~
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   9c7f2bce8a0e ("nvmem: sec-qfprom: Add Qualcomm secure QFPROM support")
> 
> I have used the nvmem tree from next-20230809 for today.

Ping?

-- 
Cheers,
Stephen Rothwell

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

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

[Komal Bajaj]

On 8/21/2023 5:18 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 15 Aug 2023 20:25:08 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> After merging the nvmem tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvmem/sec-qfprom.c: In function 'sec_qfprom_probe':
>> drivers/nvmem/sec-qfprom.c:59:13: error: unused variable 'ret' [-Werror=unused-variable]
>>     59 |         int ret;
>>        |             ^~~
>> cc1: all warnings being treated as errors
>>
>> Caused by commit
>>
>>    9c7f2bce8a0e ("nvmem: sec-qfprom: Add Qualcomm secure QFPROM support")
>>
>> I have used the nvmem tree from next-20230809 for today.
> Ping?
>

Hi Stephen,
Had already submitted a change for this -
https://lore.kernel.org/all/20230816130057.28717-1-quic_kbajaj@quicinc.com/

Thanks
Komal

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

[Stephen Rothwell]

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

Hi all,

After merging the nvmem tree, today's linux-next build (i386 defconfig)
failed like this:

/home/sfr/next/next/drivers/nvmem/core.c: In function 'nvmem_cell_put':
/home/sfr/next/next/drivers/nvmem/core.c:1603:9: error: implicit declaration of function 'nvmem_layout_module_put' [-Werror=implicit-function-declaration]
 1603 |         nvmem_layout_module_put(nvmem);
      |         ^~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  ed7778e43271 ("nvmem: core: Rework layouts to become regular devices")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Dec 2023 16:34:34 +1100
Subject: [PATCH] fix up for "nvmem: core: Rework layouts to become regular devices"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/nvmem/core.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 9fc452e8ada8..784b61eb4d8e 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1491,6 +1491,11 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np, const char *id)
 	return cell;
 }
 EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
+
+#else /* IS_ENABLED(CONFIG_OF) */
+
+static inline void nvmem_layout_module_put(struct nvmem_device *nvmem) { }
+
 #endif
 
 /**
-- 
2.40.1

-- 
Cheers,
Stephen Rothwell

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

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

[Srinivas Kandagatla]

Thankyou Stephen for the patch.

On 11/12/2023 05:49, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the nvmem tree, today's linux-next build (i386 defconfig)
> failed like this:
> 
> /home/sfr/next/next/drivers/nvmem/core.c: In function 'nvmem_cell_put':
> /home/sfr/next/next/drivers/nvmem/core.c:1603:9: error: implicit declaration of function 'nvmem_layout_module_put' [-Werror=implicit-function-declaration]
>   1603 |         nvmem_layout_module_put(nvmem);
>        |         ^~~~~~~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>    ed7778e43271 ("nvmem: core: Rework layouts to become regular devices")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 11 Dec 2023 16:34:34 +1100
> Subject: [PATCH] fix up for "nvmem: core: Rework layouts to become regular devices"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>   drivers/nvmem/core.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 9fc452e8ada8..784b61eb4d8e 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -1491,6 +1491,11 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np, const char *id)
>   	return cell;
>   }
>   EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
> +
> +#else /* IS_ENABLED(CONFIG_OF) */
> +
> +static inline void nvmem_layout_module_put(struct nvmem_device *nvmem) { }
> +

I see no reason why nvmem_layout_module_put() should be even under 
IS_ENABLED(CONFIG_OF).

Updated the patch with this fixed.


--srini

>   #endif
>   
>   /**

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

[Miquel Raynal]

Hi Srinivas,

srinivas.kandagatla@linaro.org wrote on Mon, 11 Dec 2023 10:23:40 +0000:

> Thankyou Stephen for the patch.
> 
> On 11/12/2023 05:49, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the nvmem tree, today's linux-next build (i386 defconfig)
> > failed like this:
> > 
> > /home/sfr/next/next/drivers/nvmem/core.c: In function 'nvmem_cell_put':
> > /home/sfr/next/next/drivers/nvmem/core.c:1603:9: error: implicit declaration of function 'nvmem_layout_module_put' [-Werror=implicit-function-declaration]
> >   1603 |         nvmem_layout_module_put(nvmem);
> >        |         ^~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >    ed7778e43271 ("nvmem: core: Rework layouts to become regular devices")
> > 
> > I have applied the following patch for today.
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 11 Dec 2023 16:34:34 +1100
> > Subject: [PATCH] fix up for "nvmem: core: Rework layouts to become regular devices"
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >   drivers/nvmem/core.c | 5 +++++
> >   1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > index 9fc452e8ada8..784b61eb4d8e 100644
> > --- a/drivers/nvmem/core.c
> > +++ b/drivers/nvmem/core.c
> > @@ -1491,6 +1491,11 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np, const char *id)
> >   	return cell;
> >   }
> >   EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
> > +
> > +#else /* IS_ENABLED(CONFIG_OF) */
> > +
> > +static inline void nvmem_layout_module_put(struct nvmem_device *nvmem) { }
> > +  
> 
> I see no reason why nvmem_layout_module_put() should be even under IS_ENABLED(CONFIG_OF).
> 
> Updated the patch with this fixed.

Ok, works for me. I will send a fixup with the doc change (see the
other kernel test robot report) so you can squash it as well with the
original patch.

I am surprised we get these now, I actually pushed the branch on my
Github 0-day repository and got no negative report within 3 days.
Anyway, I guess they have to prioritize the requests.

Thanks,
Miquèl

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

[Srinivas Kandagatla]

Hi Miquel,

On 11/12/2023 10:30, Miquel Raynal wrote:
> Hi Srinivas,
> 
> srinivas.kandagatla@linaro.org wrote on Mon, 11 Dec 2023 10:23:40 +0000:
> 
>> Thankyou Stephen for the patch.
>>
>> On 11/12/2023 05:49, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the nvmem tree, today's linux-next build (i386 defconfig)
>>> failed like this:
>>>
>>> /home/sfr/next/next/drivers/nvmem/core.c: In function 'nvmem_cell_put':
>>> /home/sfr/next/next/drivers/nvmem/core.c:1603:9: error: implicit declaration of function 'nvmem_layout_module_put' [-Werror=implicit-function-declaration]
>>>    1603 |         nvmem_layout_module_put(nvmem);
>>>         |         ^~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Caused by commit
>>>
>>>     ed7778e43271 ("nvmem: core: Rework layouts to become regular devices")
>>>
>>> I have applied the following patch for today.
>>>
>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Date: Mon, 11 Dec 2023 16:34:34 +1100
>>> Subject: [PATCH] fix up for "nvmem: core: Rework layouts to become regular devices"
>>>
>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>> ---
>>>    drivers/nvmem/core.c | 5 +++++
>>>    1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
>>> index 9fc452e8ada8..784b61eb4d8e 100644
>>> --- a/drivers/nvmem/core.c
>>> +++ b/drivers/nvmem/core.c
>>> @@ -1491,6 +1491,11 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np, const char *id)
>>>    	return cell;
>>>    }
>>>    EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
>>> +
>>> +#else /* IS_ENABLED(CONFIG_OF) */
>>> +
>>> +static inline void nvmem_layout_module_put(struct nvmem_device *nvmem) { }
>>> +
>>
>> I see no reason why nvmem_layout_module_put() should be even under IS_ENABLED(CONFIG_OF).
>>
>> Updated the patch with this fixed.
> 
> Ok, works for me. I will send a fixup with the doc change (see the
> other kernel test robot report) so you can squash it as well with the
> original patch.
> 
if you have fix up ready, can you send it.

--srini

> I am surprised we get these now, I actually pushed the branch on my
> Github 0-day repository and got no negative report within 3 days.
> Anyway, I guess they have to prioritize the requests.
> 
> Thanks,
> Miquèl

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

[Miquel Raynal]

Hi Srinivas,

srinivas.kandagatla@linaro.org wrote on Mon, 11 Dec 2023 11:10:19 +0000:

> Hi Miquel,
> 
> On 11/12/2023 10:30, Miquel Raynal wrote:
> > Hi Srinivas,
> > 
> > srinivas.kandagatla@linaro.org wrote on Mon, 11 Dec 2023 10:23:40 +0000:
> >   
> >> Thankyou Stephen for the patch.
> >>
> >> On 11/12/2023 05:49, Stephen Rothwell wrote:  
> >>> Hi all,
> >>>
> >>> After merging the nvmem tree, today's linux-next build (i386 defconfig)
> >>> failed like this:
> >>>
> >>> /home/sfr/next/next/drivers/nvmem/core.c: In function 'nvmem_cell_put':
> >>> /home/sfr/next/next/drivers/nvmem/core.c:1603:9: error: implicit declaration of function 'nvmem_layout_module_put' [-Werror=implicit-function-declaration]
> >>>    1603 |         nvmem_layout_module_put(nvmem);
> >>>         |         ^~~~~~~~~~~~~~~~~~~~~~~
> >>>
> >>> Caused by commit
> >>>
> >>>     ed7778e43271 ("nvmem: core: Rework layouts to become regular devices")
> >>>
> >>> I have applied the following patch for today.
> >>>
> >>> From: Stephen Rothwell <sfr@canb.auug.org.au>
> >>> Date: Mon, 11 Dec 2023 16:34:34 +1100
> >>> Subject: [PATCH] fix up for "nvmem: core: Rework layouts to become regular devices"
> >>>
> >>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >>> ---
> >>>    drivers/nvmem/core.c | 5 +++++
> >>>    1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> >>> index 9fc452e8ada8..784b61eb4d8e 100644
> >>> --- a/drivers/nvmem/core.c
> >>> +++ b/drivers/nvmem/core.c
> >>> @@ -1491,6 +1491,11 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np, const char *id)
> >>>    	return cell;
> >>>    }
> >>>    EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
> >>> +
> >>> +#else /* IS_ENABLED(CONFIG_OF) */
> >>> +
> >>> +static inline void nvmem_layout_module_put(struct nvmem_device *nvmem) { }
> >>> +  
> >>
> >> I see no reason why nvmem_layout_module_put() should be even under IS_ENABLED(CONFIG_OF).
> >>
> >> Updated the patch with this fixed.  
> > 
> > Ok, works for me. I will send a fixup with the doc change (see the
> > other kernel test robot report) so you can squash it as well with the
> > original patch.
> >   
> if you have fix up ready, can you send it.

Actually I mixed up two e-mails, I think this is all what is needed on
your branch. I don't have anything else. I thought there was a kernel
doc warning but I cannot find it anymore, so I believe I read my
e-mail too quickly.
 
Thanks,
Miquèl

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

[Stephen Rothwell]

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

Hi all,

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

In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
   13 |         u32 baud_rate;
      |         ^~~
include/linux/mfd/qnap-mcu.h:17:9: error: unknown type name 'bool'
   17 |         bool usb_led;
      |         ^~~~
include/linux/mfd/qnap-mcu.h:1:1: note: 'bool' is defined in header '<stdbool.h>'; this is probably fixable by adding '#include <stdbool.h>'
  +++ |+#include <stdbool.h>
    1 | /* SPDX-License-Identifier: GPL-2.0+ */
include/linux/mfd/qnap-mcu.h:21:25: error: unknown type name 'u8'
   21 |                   const u8 *cmd_data, size_t cmd_data_size,
      |                         ^~
include/linux/mfd/qnap-mcu.h:21:39: error: unknown type name 'size_t'
   21 |                   const u8 *cmd_data, size_t cmd_data_size,
      |                                       ^~~~~~
include/linux/mfd/qnap-mcu.h:1:1: note: 'size_t' is defined in header '<stddef.h>'; this is probably fixable by adding '#include <stddef.h>'
  +++ |+#include <stddef.h>
    1 | /* SPDX-License-Identifier: GPL-2.0+ */
include/linux/mfd/qnap-mcu.h:22:19: error: unknown type name 'u8'
   22 |                   u8 *reply_data, size_t reply_data_size);
      |                   ^~
include/linux/mfd/qnap-mcu.h:22:35: error: unknown type name 'size_t'
   22 |                   u8 *reply_data, size_t reply_data_size);
      |                                   ^~~~~~
include/linux/mfd/qnap-mcu.h:22:35: note: 'size_t' is defined in header '<stddef.h>'; this is probably fixable by adding '#include <stddef.h>'
include/linux/mfd/qnap-mcu.h:24:34: error: unknown type name 'u8'
   24 |                            const u8 *cmd_data, size_t cmd_data_size);
      |                                  ^~
include/linux/mfd/qnap-mcu.h:24:48: error: unknown type name 'size_t'
   24 |                            const u8 *cmd_data, size_t cmd_data_size);
      |                                                ^~~~~~
include/linux/mfd/qnap-mcu.h:24:48: note: 'size_t' is defined in header '<stddef.h>'; this is probably fixable by adding '#include <stddef.h>'
drivers/nvmem/qnap-mcu-eeprom.c: In function 'qnap_mcu_eeprom_read_block':
drivers/nvmem/qnap-mcu-eeprom.c:32:15: error: implicit declaration of function 'qnap_mcu_exec' [-Wimplicit-function-declaration]
   32 |         ret = qnap_mcu_exec(mcu, cmd, sizeof(cmd), reply, bytes + sizeof(cmd));
      |               ^~~~~~~~~~~~~

Caused by commit

  117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")

I have used the nvmem tree from next-20250818 for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Heiko Stübner]

Hi,

Am Dienstag, 19. August 2025, 05:40:39 Mitteleuropäische Sommerzeit schrieb Stephen Rothwell:
> After merging the nvmem tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
> include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
>    13 |         u32 baud_rate;
>       |         ^~~

[...]

> 
> Caused by commit
> 
>   117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")
> 
> I have used the nvmem tree from next-20250818 for today.

bah, sorry about messing this up.

While I encountered this, and fixed that with the pending
  https://lore.kernel.org/all/20250804130726.3180806-2-heiko@sntech.de/

I completely missed that the nvmem driver applied alone would break
without that change :-( .

I've send
  https://lore.kernel.org/all/20250819111044.2714855-1-heiko@sntech.de/

as a fix that removes the issue for the nvmem driver.


Heiko

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

[Srinivas Kandagatla]

On 8/19/25 12:14 PM, Heiko Stübner wrote:
> Hi,
> 
> Am Dienstag, 19. August 2025, 05:40:39 Mitteleuropäische Sommerzeit schrieb Stephen Rothwell:
>> After merging the nvmem tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
>> include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
>>    13 |         u32 baud_rate;
>>       |         ^~~
> 
> [...]
> 
>>
>> Caused by commit
>>
>>   117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")
>>
>> I have used the nvmem tree from next-20250818 for today.
> 
> bah, sorry about messing this up.
> 
> While I encountered this, and fixed that with the pending
>   https://lore.kernel.org/all/20250804130726.3180806-2-heiko@sntech.de/
> 
> I completely missed that the nvmem driver applied alone would break
> without that change :-( .

I have now reverted this change, @Heiko Please let me know if you want
to take this to mfd tree or vice-versa.

--srini
> 
> I've send
>   https://lore.kernel.org/all/20250819111044.2714855-1-heiko@sntech.de/
> 
> as a fix that removes the issue for the nvmem driver.
> 
> 
> Heiko
> 
> 

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

[Heiko Stübner]

Am Dienstag, 19. August 2025, 13:22:04 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
> On 8/19/25 12:14 PM, Heiko Stübner wrote:
> > Hi,
> > 
> > Am Dienstag, 19. August 2025, 05:40:39 Mitteleuropäische Sommerzeit schrieb Stephen Rothwell:
> >> After merging the nvmem tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
> >> include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
> >>    13 |         u32 baud_rate;
> >>       |         ^~~
> > 
> > [...]
> > 
> >>
> >> Caused by commit
> >>
> >>   117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")
> >>
> >> I have used the nvmem tree from next-20250818 for today.
> > 
> > bah, sorry about messing this up.
> > 
> > While I encountered this, and fixed that with the pending
> >   https://lore.kernel.org/all/20250804130726.3180806-2-heiko@sntech.de/
> > 
> > I completely missed that the nvmem driver applied alone would break
> > without that change :-( .
> 
> I have now reverted this change, @Heiko Please let me know if you want
> to take this to mfd tree or vice-versa.

ok, no worries :-) .

I guess for now, I'll just make sure the header patch gets somewhere.
And I guess I'll re-try the nvmem driver once that has happened,
probably for the next cycle.

Creating dependencies between trees somehow does sound like
more hassle so I'll just wait for a stable base, to not cause more
breakage :-)


Heiko

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

[Srinivas Kandagatla]

On 8/19/25 2:54 PM, Heiko Stübner wrote:
> Am Dienstag, 19. August 2025, 13:22:04 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
>> On 8/19/25 12:14 PM, Heiko Stübner wrote:
>>> Hi,
>>>
>>> Am Dienstag, 19. August 2025, 05:40:39 Mitteleuropäische Sommerzeit schrieb Stephen Rothwell:
>>>> After merging the nvmem tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
>>>> include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
>>>>    13 |         u32 baud_rate;
>>>>       |         ^~~
>>>
>>> [...]
>>>
>>>>
>>>> Caused by commit
>>>>
>>>>   117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")
>>>>
>>>> I have used the nvmem tree from next-20250818 for today.
>>>
>>> bah, sorry about messing this up.
>>>
>>> While I encountered this, and fixed that with the pending
>>>   https://lore.kernel.org/all/20250804130726.3180806-2-heiko@sntech.de/
>>>
>>> I completely missed that the nvmem driver applied alone would break
>>> without that change :-( .
>>
>> I have now reverted this change, @Heiko Please let me know if you want
>> to take this to mfd tree or vice-versa.
> 
> ok, no worries :-) .
> 
> I guess for now, I'll just make sure the header patch gets somewhere.
> And I guess I'll re-try the nvmem driver once that has happened,
> probably for the next cycle.

I don't think we need to wait till next cycle, Lee can pick up this
patch via mfd tree if header change is going via mfd tree.


--srini

> 
> Creating dependencies between trees somehow does sound like
> more hassle so I'll just wait for a stable base, to not cause more
> breakage :-)
> 
> 
> Heiko
> 
> 

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

[Heiko Stübner]

Am Dienstag, 19. August 2025, 15:58:32 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
> 
> On 8/19/25 2:54 PM, Heiko Stübner wrote:
> > Am Dienstag, 19. August 2025, 13:22:04 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
> >> On 8/19/25 12:14 PM, Heiko Stübner wrote:
> >>> Hi,
> >>>
> >>> Am Dienstag, 19. August 2025, 05:40:39 Mitteleuropäische Sommerzeit schrieb Stephen Rothwell:
> >>>> After merging the nvmem tree, today's linux-next build (x86_64
> >>>> allmodconfig) failed like this:
> >>>>
> >>>> In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
> >>>> include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
> >>>>    13 |         u32 baud_rate;
> >>>>       |         ^~~
> >>>
> >>> [...]
> >>>
> >>>>
> >>>> Caused by commit
> >>>>
> >>>>   117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")
> >>>>
> >>>> I have used the nvmem tree from next-20250818 for today.
> >>>
> >>> bah, sorry about messing this up.
> >>>
> >>> While I encountered this, and fixed that with the pending
> >>>   https://lore.kernel.org/all/20250804130726.3180806-2-heiko@sntech.de/
> >>>
> >>> I completely missed that the nvmem driver applied alone would break
> >>> without that change :-( .
> >>
> >> I have now reverted this change, @Heiko Please let me know if you want
> >> to take this to mfd tree or vice-versa.
> > 
> > ok, no worries :-) .
> > 
> > I guess for now, I'll just make sure the header patch gets somewhere.
> > And I guess I'll re-try the nvmem driver once that has happened,
> > probably for the next cycle.
> 
> I don't think we need to wait till next cycle, Lee can pick up this
> patch via mfd tree if header change is going via mfd tree.

Okay ... if that is fine with you then great.

I guess for less confusion, I'll re-submit the driver, reference the header
patch it needs and you can Ack it to go via the mfd tree.

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

[Lee Jones]

On Tue, 19 Aug 2025, Heiko Stübner wrote:

> Am Dienstag, 19. August 2025, 15:58:32 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
> > 
> > On 8/19/25 2:54 PM, Heiko Stübner wrote:
> > > Am Dienstag, 19. August 2025, 13:22:04 Mitteleuropäische Sommerzeit schrieb Srinivas Kandagatla:
> > >> On 8/19/25 12:14 PM, Heiko Stübner wrote:
> > >>> Hi,
> > >>>
> > >>> Am Dienstag, 19. August 2025, 05:40:39 Mitteleuropäische Sommerzeit schrieb Stephen Rothwell:
> > >>>> After merging the nvmem tree, today's linux-next build (x86_64
> > >>>> allmodconfig) failed like this:
> > >>>>
> > >>>> In file included from drivers/nvmem/qnap-mcu-eeprom.c:12:
> > >>>> include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name 'u32'
> > >>>>    13 |         u32 baud_rate;
> > >>>>       |         ^~~
> > >>>
> > >>> [...]
> > >>>
> > >>>>
> > >>>> Caused by commit
> > >>>>
> > >>>>   117c3f3014a9 ("nvmem: add driver for the eeprom in qnap-mcu controllers")
> > >>>>
> > >>>> I have used the nvmem tree from next-20250818 for today.
> > >>>
> > >>> bah, sorry about messing this up.
> > >>>
> > >>> While I encountered this, and fixed that with the pending
> > >>>   https://lore.kernel.org/all/20250804130726.3180806-2-heiko@sntech.de/
> > >>>
> > >>> I completely missed that the nvmem driver applied alone would break
> > >>> without that change :-( .
> > >>
> > >> I have now reverted this change, @Heiko Please let me know if you want
> > >> to take this to mfd tree or vice-versa.
> > > 
> > > ok, no worries :-) .
> > > 
> > > I guess for now, I'll just make sure the header patch gets somewhere.
> > > And I guess I'll re-try the nvmem driver once that has happened,
> > > probably for the next cycle.
> > 
> > I don't think we need to wait till next cycle, Lee can pick up this
> > patch via mfd tree if header change is going via mfd tree.
> 
> Okay ... if that is fine with you then great.
> 
> I guess for less confusion, I'll re-submit the driver, reference the header
> patch it needs and you can Ack it to go via the mfd tree.

Sounds fine.

-- 
Lee Jones [李琼斯]