* Re: [PATCH 3/4] firmware: google: cbmem: Add to module device table [not found] <20240111151226.842603-4-nfraprado@collabora.com> @ 2024-01-15 2:53 ` kernel test robot 2024-01-16 17:40 ` Brian Norris 0 siblings, 1 reply; 2+ messages in thread From: kernel test robot @ 2024-01-15 2:53 UTC (permalink / raw) To: Nícolas F. R. A. Prado, Tzung-Bi Shih Cc: llvm, oe-kbuild-all, kernel, AngeloGioacchino Del Regno, Nícolas F. R. A. Prado, Brian Norris, Julius Werner, chrome-platform, linux-kernel Hi Nícolas, kernel test robot noticed the following build warnings: [auto build test WARNING on next-20240111] [also build test WARNING on v6.7] [cannot apply to chrome-platform/for-next chrome-platform/for-firmware-next masahiroy-kbuild/for-next masahiroy-kbuild/fixes arm64/for-next/core linus/master v6.7 v6.7-rc8 v6.7-rc7] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/N-colas-F-R-A-Prado/firmware-coreboot-Generate-modalias-uevent-for-devices/20240111-231841 base: next-20240111 patch link: https://lore.kernel.org/r/20240111151226.842603-4-nfraprado%40collabora.com patch subject: [PATCH 3/4] firmware: google: cbmem: Add to module device table config: i386-randconfig-013-20240115 (https://download.01.org/0day-ci/archive/20240115/202401151013.Xioj5wZo-lkp@intel.com/config) compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240115/202401151013.Xioj5wZo-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), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202401151013.Xioj5wZo-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/firmware/google/cbmem.c:118:40: warning: unused variable 'cbmem_ids' [-Wunused-const-variable] 118 | static const struct coreboot_device_id cbmem_ids[] = { | ^~~~~~~~~ 1 warning generated. vim +/cbmem_ids +118 drivers/firmware/google/cbmem.c 117 > 118 static const struct coreboot_device_id cbmem_ids[] = { 119 { .tag = LB_TAG_CBMEM_ENTRY }, 120 { /* sentinel */ } 121 }; 122 MODULE_DEVICE_TABLE(coreboot, cbmem_ids); 123 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH 3/4] firmware: google: cbmem: Add to module device table 2024-01-15 2:53 ` [PATCH 3/4] firmware: google: cbmem: Add to module device table kernel test robot @ 2024-01-16 17:40 ` Brian Norris 0 siblings, 0 replies; 2+ messages in thread From: Brian Norris @ 2024-01-16 17:40 UTC (permalink / raw) To: kernel test robot, Nícolas F. R. A. Prado Cc: Nícolas F. R. A. Prado, Tzung-Bi Shih, llvm, oe-kbuild-all, kernel, AngeloGioacchino Del Regno, Julius Werner, chrome-platform, linux-kernel Hi Nicolas, On Mon, Jan 15, 2024 at 10:53:48AM +0800, kernel test robot wrote: > All warnings (new ones prefixed by >>): > > >> drivers/firmware/google/cbmem.c:118:40: warning: unused variable 'cbmem_ids' [-Wunused-const-variable] > 118 | static const struct coreboot_device_id cbmem_ids[] = { > | ^~~~~~~~~ > 1 warning generated. > > > vim +/cbmem_ids +118 drivers/firmware/google/cbmem.c > > 117 > > 118 static const struct coreboot_device_id cbmem_ids[] = { > 119 { .tag = LB_TAG_CBMEM_ENTRY }, > 120 { /* sentinel */ } > 121 }; > 122 MODULE_DEVICE_TABLE(coreboot, cbmem_ids); > 123 I was wondering why we have a seemingly unique "unused variable" failure mode in comparison to other similarly-structured device/bus drivers, and I realized that's because we're not relying on the same structure for both MODULE_DEVICE_TABLE (struct coreboot_device_id) and for the driver definition (struct coreboot_driver -> 'u32 tag'). Thus, this structure is only used for #define MODULE builds, and otherwise not used. Rather than wrapping these definitions in "#ifdef MODULE", perhaps we can settle on a single field, and replace `struct coreboot_driver::tag` with an instance of `struct coreboot_device_id`? That would normally be a breaking change that would require changing all drivers at the same time as the bus (or else some kind of intermediate transition state), but considering there are only 4 driver implementations and they all live under the same maintainer tree, that seems like it should still be OK (IMO). If it makes the series more readable/incremental, perhaps the switchover can be the last patch in the series, and there can remain some duplication (and potential -Wunused-const-variable issues) for the middle of the series. Brian ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-01-16 17:40 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20240111151226.842603-4-nfraprado@collabora.com>
2024-01-15 2:53 ` [PATCH 3/4] firmware: google: cbmem: Add to module device table kernel test robot
2024-01-16 17:40 ` Brian Norris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox