Message ID | 20240111151226.842603-4-nfraprado@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-23777-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp1523185dyi; Thu, 11 Jan 2024 07:25:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IFF7NvaqP3QQsxDTi9ATITd5valj2NePCUnAD9JO1RgEibjpV62K6Uen+O6M3wESCc3UMrK X-Received: by 2002:a17:90a:6b85:b0:28c:e6c4:2af2 with SMTP id w5-20020a17090a6b8500b0028ce6c42af2mr1088115pjj.59.1704986717630; Thu, 11 Jan 2024 07:25:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704986717; cv=none; d=google.com; s=arc-20160816; b=D4wQV8MYrw+5EoifvjCI8E9YZ8iivyq0jbHvVLkvDfByczuMj8BcGJUakzpMGcGHxo uGL8QYTlMq2sALHYgf4/QzqtNBi4BR6cjDfFXyl0HZXzhuT92FQMq/4ZKX2Tn8lX+tux aG+bNnroShLeaZzQ+C+O7uXCXdOhxBaZqDxFtgcLFXJZJskuffxdWbnWA5rPm17KYAT1 DEY4ldxEi1LTI0M+sngs5BhexbEF+aTyjrzTCizKPTv39aAuQSy//WYRsGOAfY7YsknL X1T/NsUqhnxywWrhOH9iswfhFxCGQ6lAAUh+Oj1m5LOZ2FCemQ6+c8nM0bazpRJ/dvhy 8ARQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=BeaFX8z25B6QjEo7ZQK5LOtOf31INAGe31lgagAgrKA=; fh=H0kbwUruoBXq1bqKu/NFiE7mK9MAh4+V9Tzc3DeEtw4=; b=BWnGcy1ReSEROwS19haX4qhHTkia3CLJF0LZKfuFnSrqkCYxkhF4mHev/m0TosDk4Y rUR0aMWDydOUk9nV/M6fV07raLHeclnyrDfEeCgIxWb6RlDXONz/S0KS6yF7CK07RQGL JJKDcMPi89teJa18SYnNLon7vgA8SWFEpIRV5RxgAUDhzF92eBRWAAcW1Mjww1YpUV7n xE+rzqC+T6Pif2I3KU2zul2RoxjMaSaFcDuJjeaydEQnfjfUQAO0Kl6JpvmYlvSoXp6d /3kmKYT78JYX0SZlfO935BrbzJvKig02yVgA80o687O5gOiT6A6Nx6D6ZKLwC8EI4ma7 y9bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=VFxLYHDq; spf=pass (google.com: domain of linux-kernel+bounces-23777-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23777-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id x13-20020a17090aca0d00b0028d65897b16si1340240pjt.55.2024.01.11.07.25.17 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 07:25:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-23777-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=VFxLYHDq; spf=pass (google.com: domain of linux-kernel+bounces-23777-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23777-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D3374289FC0 for <ouuuleilei@gmail.com>; Thu, 11 Jan 2024 15:15:52 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6BA9D4CB41; Thu, 11 Jan 2024 15:14:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="VFxLYHDq" Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 85FC84F213 for <linux-kernel@vger.kernel.org>; Thu, 11 Jan 2024 15:14:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1704986091; bh=CHvr4PScujipymb+OTlox6s6i63JQHd4PBTYty5wiek=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VFxLYHDq8htIlCQPt2uLpfyJxCn40rH/SW4OZM4tonLsrFfzfgA/l85xIRUD9OfQp eJwDTAP0JAxdSIhq7CbAL4lQQURW9WCvW75P9434gUTV1NVDwBzsMmkk8NkKSWlsPC HOuB03bhDe7rdLPT4C1kc0oMCAcZuCKkoQMZpU+7yAPeEkODkdRb5tbP6cnbRun/Oy e65p1QuPFCjkh7pOWWeBCCqmf9Mv+Y+WoCtZ2FcXKX8C4SQjaKIEvOKwUY9nTqUBWK gjmmTRX+JXaSwFsAp7SH3T/fTFh6JOcDfQtT06IngFPgMsGoZcOmuokelAC8sxGSW8 NN1iuq9uehaSw== Received: from localhost.localdomain (zone.collabora.co.uk [167.235.23.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nfraprado) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 4A7113781F80; Thu, 11 Jan 2024 15:14:47 +0000 (UTC) From: =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com> To: Tzung-Bi Shih <tzungbi@kernel.org> Cc: kernel@collabora.com, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com>, Brian Norris <briannorris@chromium.org>, Julius Werner <jwerner@chromium.org>, chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 3/4] firmware: google: cbmem: Add to module device table Date: Thu, 11 Jan 2024 12:11:48 -0300 Message-ID: <20240111151226.842603-4-nfraprado@collabora.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240111151226.842603-1-nfraprado@collabora.com> References: <20240111151226.842603-1-nfraprado@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787808152361272748 X-GMAIL-MSGID: 1787808152361272748 |
Series |
Allow coreboot modules to autoload and enable cbmem in the arm64 defconfig
|
|
Commit Message
Nícolas F. R. A. Prado
Jan. 11, 2024, 3:11 p.m. UTC
Create an id table and add it to the module device table to allow the
cbmem driver to be automatically loaded when a matching device is found.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
drivers/firmware/google/cbmem.c | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On Thu, Jan 11, 2024 at 12:11:48PM -0300, Nícolas F. R. A. Prado wrote: > Create an id table and add it to the module device table to allow the > cbmem driver to be automatically loaded when a matching device is found. > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Might as well also patch framebuffer-coreboot.c and memconsole-coreboot.c while you're at it? But for this one: Acked-by: Brian Norris <briannorris@chromium.org>
On Thu, Jan 11, 2024 at 04:38:44PM -0800, Brian Norris wrote: > On Thu, Jan 11, 2024 at 12:11:48PM -0300, Nícolas F. R. A. Prado wrote: > > Create an id table and add it to the module device table to allow the > > cbmem driver to be automatically loaded when a matching device is found. > > > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > > Might as well also patch framebuffer-coreboot.c and > memconsole-coreboot.c while you're at it? Yeah, no reason not to. Will do in v2. Thanks, Nícolas
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
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
diff --git a/drivers/firmware/google/cbmem.c b/drivers/firmware/google/cbmem.c index 88e587ba1e0d..ceb89b4cdbe0 100644 --- a/drivers/firmware/google/cbmem.c +++ b/drivers/firmware/google/cbmem.c @@ -13,6 +13,7 @@ #include <linux/kernel.h> #include <linux/kobject.h> #include <linux/module.h> +#include <linux/mod_devicetable.h> #include <linux/platform_device.h> #include <linux/slab.h> #include <linux/sysfs.h> @@ -114,6 +115,12 @@ static int cbmem_entry_probe(struct coreboot_device *dev) return 0; } +static const struct coreboot_device_id cbmem_ids[] = { + { .tag = LB_TAG_CBMEM_ENTRY }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(coreboot, cbmem_ids); + static struct coreboot_driver cbmem_entry_driver = { .probe = cbmem_entry_probe, .drv = {