From: Brian Norris <briannorris@chromium.org>
To: "kernel test robot" <lkp@intel.com>,
"Nícolas F. R. A. Prado" <nfraprado@collabora.com>
Cc: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
"Tzung-Bi Shih" <tzungbi@kernel.org>,
llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
kernel@collabora.com,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Julius Werner" <jwerner@chromium.org>,
chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] firmware: google: cbmem: Add to module device table
Date: Tue, 16 Jan 2024 09:40:55 -0800 [thread overview]
Message-ID: <Zaa_pwuPOMCQV4GD@google.com> (raw)
In-Reply-To: <202401151013.Xioj5wZo-lkp@intel.com>
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
next prev parent reply other threads:[~2024-01-16 17:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 15:11 [PATCH 0/4] Allow coreboot modules to autoload and enable cbmem in the arm64 defconfig Nícolas F. R. A. Prado
2024-01-11 15:11 ` Nícolas F. R. A. Prado
2024-01-11 15:11 ` [PATCH 1/4] firmware: coreboot: Generate modalias uevent for devices Nícolas F. R. A. Prado
2024-01-12 0:37 ` Brian Norris
2024-01-12 12:24 ` Nícolas F. R. A. Prado
2024-01-11 15:11 ` [PATCH 2/4] firmware: coreboot: Generate aliases for coreboot modules Nícolas F. R. A. Prado
2024-01-14 17:08 ` Andy Shevchenko
2024-01-17 12:53 ` Nícolas F. R. A. Prado
2024-01-21 12:41 ` Andy Shevchenko
2024-01-22 18:24 ` Nícolas F. R. A. Prado
2024-01-11 15:11 ` [PATCH 3/4] firmware: google: cbmem: Add to module device table Nícolas F. R. A. Prado
2024-01-12 0:38 ` Brian Norris
2024-01-12 12:26 ` Nícolas F. R. A. Prado
2024-01-15 2:53 ` kernel test robot
2024-01-16 17:40 ` Brian Norris [this message]
2024-01-11 15:11 ` [PATCH 4/4] arm64: defconfig: Enable support for cbmem entries in the coreboot table Nícolas F. R. A. Prado
2024-01-11 15:11 ` Nícolas F. R. A. Prado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zaa_pwuPOMCQV4GD@google.com \
--to=briannorris@chromium.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chrome-platform@lists.linux.dev \
--cc=jwerner@chromium.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=nfraprado@collabora.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=tzungbi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.