From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D3C65361644 for ; Sun, 15 Mar 2026 15:14:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773587690; cv=none; b=prJQ1DSp1raTK6NXi3zvdx0F82AstRnzA2Ip4+0DmkJt+1JjuRQqG/NKusTQ607IIG4ejKNvt81q/UNUku4g26avukSMQ9mmt0oV/EHx/EijmPnLo2GC7Lhtr/zSNxGEQ0MlrzBkeSbxPDmKTNL/hpVunjCxEtj30yq2mwPosuA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773587690; c=relaxed/simple; bh=24FFGUEMRvnj5hQcbpHSraIj0B5nMSP2gH23l6X9cVE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZYajY7HUgiwxwlLsbsI9prbUYvFHsY4xmwQgcZLfgOT0iiHmQmThA1BlNY0XKJoeb3A+tyVCxzMpNwAPe4zceTFVPzTI2VYc8gAn/aENCUq2ktCSjgvP588o2sZ0+MOlQbveKge4igDVsoUuF5v8ULv3P2jQrstpHfp2NuzbG+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qbvFQ16b; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qbvFQ16b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21BB6C4CEF7; Sun, 15 Mar 2026 15:14:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773587690; bh=24FFGUEMRvnj5hQcbpHSraIj0B5nMSP2gH23l6X9cVE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qbvFQ16b0D4EPbWsckE3XYnwEfQlnjhK44soLwtVRvAmPHCVtWZ5J6ewvIwcXF/6j eRiv5Z05zk+HX/KiI/nbicjDfDuaOd9YEAtf6DRHF8876FHmHNJtuZ8lP8+fs+b0R7 H1Omhw5zLREv2XJPBvFkk2dh7cALmqa4brg3buQLWF9nRTQxg0UCPdiZKdkP3tA/IV M8bHqF/bsuH6rYmgUS4MUaXqUO/RzPlsWiHTd+IjHetDnwHsD8QnmH2xQiKfndv0AV vDBYKNhKJqsjLcAhM+JRVQYCax/VPT2AfaG/khcfAEWAoCB8B+YZLaE+FH8fRgiKJ3 Pw/wJMbC6qG+w== Message-ID: Date: Sun, 15 Mar 2026 10:14:48 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 5/5] x86/CPU/AMD: Print AGESA string from DMI additional information entry To: Borislav Petkov Cc: Yazen Ghannam , Jean Delvare , linux-kernel@vger.kernel.org References: <20260123213056.861317-1-superm1@kernel.org> <20260123213056.861317-6-superm1@kernel.org> <20260315131416.GVabawqKuPkYKShXpn@fat_crate.local> Content-Language: en-US From: Mario Limonciello In-Reply-To: <20260315131416.GVabawqKuPkYKShXpn@fat_crate.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/15/26 8:14 AM, Borislav Petkov wrote: > On Fri, Jan 23, 2026 at 03:30:56PM -0600, Mario Limonciello (AMD) wrote: >> From: Yazen Ghannam >> >> Type 40 entries (Additional Information) are summarized in section 7.41 >> as part of the SMBIOS specification. Generally, these entries aren't >> interesting to save. >> >> However on some AMD Zen systems, the AGESA version is stored here. This >> is useful to save to the kernel message logs for debugging. It can be >> used to cross-reference issues. >> >> Implement an iterator for the Additional Information entries. Use this >> to find and print the AGESA string. Do so in AMD code, since the use >> case is AMD-specific. > > Look what I said the last time: FYI - you're replying to the v5 not the v6 [1]. Link: https://lore.kernel.org/all/20260307141024.819807-1-superm1@kernel.org/ [1] > > https://lore.kernel.org/r/20260126130755.GIaXdnK65MTIiXqg-l@fat_crate.local > > I'll have to teach AI to give feedback for commit messages explaining the > diff. Sorry about that one, I missed it even in v6. > >> Signed-off-by: Yazen Ghannam >> Co-developed-by: "Mario Limonciello (AMD)" >> Signed-off-by: "Mario Limonciello (AMD)" >> --- >> v5: >> * Return "" in !CONFIG_DMI case (LKP robot, Yazen) >> v4: >> * New patch (based upon older versions though) >> --- >> arch/x86/kernel/cpu/amd.c | 53 +++++++++++++++++++++++++++++++++++++ >> drivers/firmware/dmi_scan.c | 3 ++- >> include/linux/dmi.h | 18 +++++++++++++ >> 3 files changed, 73 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c >> index bc94ff1e250ad..aa04a27aeb107 100644 >> --- a/arch/x86/kernel/cpu/amd.c >> +++ b/arch/x86/kernel/cpu/amd.c >> @@ -1,6 +1,7 @@ >> // SPDX-License-Identifier: GPL-2.0-only >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -1404,3 +1405,55 @@ static __init int print_s5_reset_status_mmio(void) >> return 0; >> } >> late_initcall(print_s5_reset_status_mmio); >> + >> +static void __init amd_dmi_scan_additional(const struct dmi_header *d, void *p) >> +{ >> + struct dmi_a_info *info = (struct dmi_a_info *)d; >> + void *next, *end; >> + >> + /* >> + * DMI Additional Info table has a 'count' field. But it's not very >> + * helpful since the entries are variable length. So don't use it. >> + */ >> + if (info->header.type != DMI_ENTRY_ADDITIONAL || >> + info->header.length < DMI_A_INFO_MIN_SIZE) >> + return; >> + >> + /* >> + * Get the first entry. >> + * The minimum table size guarantees at least one entry is present. >> + */ >> + next = (void *)(info + 1); >> + end = (void *)info + info->header.length; > > From last time: > > "This end needs to be corrected to some sane upper limit because we don't trust > firmware one bit." > I did add a check for info->count < 1, but that's not what you were actually looking for. Do you have a suggestion for an upper limit to bound things? I was thinking something like this: #define DMI_LIMIT 10 int limit = info -> count > DMI_LIMIT ? DMI_LIMIT : info->count; end = (void *)info + limit * info->header.length;