[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15cfd153-314a-4eeb-8de9-97a888905bff@kadam.mountain>
Date: Fri, 4 Aug 2023 19:02:46 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: oe-kbuild@...ts.linux.dev,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
lkp@...el.com, oe-kbuild-all@...ts.linux.dev,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Robert Marko <robert.marko@...tura.hr>,
Luka Perkov <luka.perkov@...tura.hr>,
Michael Walle <michael@...le.cc>, linux-kernel@...r.kernel.org,
Randy Dunlap <rdunlap@...radead.org>,
Chen-Yu Tsai <wenst@...omium.org>,
Daniel Golle <daniel@...rotopia.org>,
Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH v7 5/7] nvmem: core: Rework layouts to become platform
devices
On Fri, Aug 04, 2023 at 05:39:03PM +0200, Miquel Raynal wrote:
> Hi Dan,
>
> dan.carpenter@...aro.org wrote on Thu, 3 Aug 2023 13:13:04 +0300:
>
> > Hi Miquel,
> >
> > kernel test robot noticed the following build warnings:
> >
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >
> > url: https://github.com/intel-lab-lkp/linux/commits/Miquel-Raynal/nvmem-core-Create-all-cells-before-adding-the-nvmem-device/20230802-022331
> > base: char-misc/char-misc-testing
> > patch link: https://lore.kernel.org/r/20230801182132.1058707-6-miquel.raynal%40bootlin.com
> > patch subject: [PATCH v7 5/7] nvmem: core: Rework layouts to become platform devices
> > config: x86_64-randconfig-m001-20230730 (https://download.01.org/0day-ci/archive/20230803/202308030002.DnSFOrMB-lkp@intel.com/config)
> > compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> > reproduce: (https://download.01.org/0day-ci/archive/20230803/202308030002.DnSFOrMB-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit
> > (i.e. not just a new version of the same patch/commit),
>
> (Nice addition, a lot of newcomers would always add these tags
> otherwise.)
The Intel kbuild devs add this stuff, I just look it over and hit
forward.
>
> > kindly add following tags
> > | Reported-by: kernel test robot <lkp@...el.com>
> > | Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> > | Closes: https://lore.kernel.org/r/202308030002.DnSFOrMB-lkp@intel.com/
> >
> > New smatch warnings:
> > drivers/nvmem/core.c:1003 nvmem_register() warn: 'layout_np' is an error pointer or valid
> > drivers/nvmem/core.c:2130 nvmem_try_loading_layout_driver() warn: 'layout_np' is an error pointer or valid
> >
> > Old smatch warnings:
> > drivers/nvmem/core.c:761 nvmem_add_cells_from_fixed_layout() warn: 'layout_np' is an error pointer or valid
> > drivers/nvmem/core.c:802 nvmem_layout_get() warn: 'layout_np' is an error pointer or valid
> >
> > vim +/layout_np +1003 drivers/nvmem/core.c
> >
> > 266570f496b90d Michael Walle 2023-04-04 1000
> > 00d059fd6702f0 Miquel Raynal 2023-08-01 1001 /* Populate layouts as devices */
> > 00d059fd6702f0 Miquel Raynal 2023-08-01 1002 layout_np = of_nvmem_layout_get_container(nvmem);
> > 00d059fd6702f0 Miquel Raynal 2023-08-01 @1003 if (layout_np) {
> >
> > So, ugh, of_nvmem_layout_get_container() return NULL on error or error
> > pointer if either CONFIG_NVMEM or CONFIG_OF is turned off. I feel like
> > that's a mistake. Normally when a function returns both error pointers
> > and NULL then the NULL means the feature is disabled and the error
> > pointers mean there was an error. Here it is the opposite.
> >
> > I have written a blog about this:
> > https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/
>
> Nice (besides the huge spider which stared at me unexpectedly :-) )
Those are a species of jumping spiders. They are shiny and golden in
real life, but it never shows up properly in photos. :)
>
> > At first I thought that this was to do with CONFIG_COMPILE_TEST but
> > actually that is disabled. The issue here is that CONFIG_OF is turned
> > off. So this is a genuine bug, we're compiling a module which will
> > always crash.
> >
> > So I guess the fix is easy that this should return NULL if either
> > CONFIG_NVMEM or CONFIG_OF is turned off. That was a long explanation
> > which is no longer required now that it's not a COMPILE_TEST issue. :P
>
> I wanted to disable CONFIG_OF to make the test, I totally forget, I'll
> handle this case and return NULL when this happens.
>
> However I don't understand why you mention CONFIG_NVMEM, because if it
> is not defined, this file will not compile at all?
Yeah. You're right. I wrote this email thinking it was a
CONFIG_COMPILE_TEST issue and didn't edit it properly in the end.
regards,
dan carpenter
Powered by blists - more mailing lists