From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76725C54EE9 for ; Tue, 20 Sep 2022 10:15:25 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B449484C5A; Tue, 20 Sep 2022 12:15:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="QcP/RiHm"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3AAF084C5E; Tue, 20 Sep 2022 12:15:21 +0200 (CEST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E129A84C3C for ; Tue, 20 Sep 2022 12:15:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pbrobinson@gmail.com Received: by mail-lj1-x235.google.com with SMTP id x29so2409760ljq.2 for ; Tue, 20 Sep 2022 03:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=oZtvZ43mWRAMn8+ljJ6PuB+5z5XcOylX4eeXC3yrT1A=; b=QcP/RiHmiR5ACc798CksBgm+DDaFfQm0GZTm6cqh+WYIDY113RbGq1STrQTOsUf2VN vISi0K5PX4COP7slnTKiAQwM8g9LsDmzTKDpPE1Ekl+Er42JL1IqCwrJb+WTmiUuFTCw 5YCehpe6zGYvBydZVM9KVK9C1pV1OYonS07zAbD/c/opd6wJAQHm459FWnbtOqXgVM/u YyMS7onUCsXnI9+9i39fgUjj+pA0wveLb2LrENWCyJuhMWzugVcRranax7zqYeafMTM0 wExVOU45DYkM3M8neeL7ucebt6AiW5LuSo0dAH8YwOWvqLwHxkbmaqtd6kbb2VLkUwI7 ++2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=oZtvZ43mWRAMn8+ljJ6PuB+5z5XcOylX4eeXC3yrT1A=; b=Iw7EN6o8voQ1wmGwbXuAH73bmjijdXUpyL56nQqzJpw1sdscMKOUSlYERwYMtrTaLr eE9tNojkVtJ7jR7WNPy1oeo9jkKQf4M2XDmazqvuYyfIH2gE3oOIi4A8yahngnIBbMUc +IgaY915Z3djoqj8Vi1L38x+XOHmObLLBV5qupTEQYCFuvIThoPQWk+4kqjIe8yJEtX2 cyn4sV2eZZHerMjl6/3x7Swr10BrdPbVBYrQZFmkVw7ILe4yHYX5wi5b3DXxY0FLiFXF 9jusjVIiAWHkEuKFpepWIhCMx8ygMBAFu/eMJUFlzjkDwiw7pfFAhCAUtnuQ92VM3m1o 69RA== X-Gm-Message-State: ACrzQf1BEEgIl2UGc4OmCJ9RciO3IBWTGgIGJpIYjVrH/enN9BTUqEgI 2Amatr+zDOmeELdLrJ+qeDF4s6JYOnCX3n6aq/U= X-Google-Smtp-Source: AMsMyM6FKB5nSxamxtmzt+gyAZP9xhtxD9Mrezt3HHBnfKNijOnp8GYrxtCvSKgnXhaDaY7aEFHTu3EBVxE801fA6sQ= X-Received: by 2002:a2e:8957:0:b0:261:d3c7:4d92 with SMTP id b23-20020a2e8957000000b00261d3c74d92mr6361695ljk.23.1663668917064; Tue, 20 Sep 2022 03:15:17 -0700 (PDT) MIME-Version: 1.0 References: <20220906134426.53748-1-ilias.apalodimas@linaro.org> In-Reply-To: From: Peter Robinson Date: Tue, 20 Sep 2022 11:15:04 +0100 Message-ID: Subject: Re: [PATCH 1/2] smbios: Simplify reporting of unknown values To: Simon Glass Cc: Ilias Apalodimas , U-Boot Mailing List , Tom Rini , Heinrich Schuchardt , Rob Herring Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Simon, Adding Rob for information around putting things in device tree. > > If a value is not valid during the DT or SYSINFO parsing, we explicitly > > set that to "Unknown Product" and "Unknown" for the product and > > manufacturer respectively. It's cleaner if we move the checks insisde > > smbios_add_string() and always report "Unknown" regardless of the missing > > field. > > > > pre-patch dmidecode > > > > Handle 0x0001, DMI type 1, 27 bytes > > System Information > > Manufacturer: Unknown > > Product Name: Unknown Product > > Version: Not Specified > > Serial Number: Not Specified > > UUID: Not Settable > > Wake-up Type: Reserved > > SKU Number: Not Specified > > Family: Not Specified > > > > Handle 0x0002, DMI type 2, 14 bytes > > Base Board Information > > Manufacturer: Unknown > > Product Name: Unknown Product > > Version: Not Specified > > Serial Number: Not Specified > > Asset Tag: Not Specified > > Features: > > Board is a hosting board > > Location In Chassis: Not Specified > > Type: Motherboard > > > > > > post-patch dmidecode: > > > > Handle 0x0001, DMI type 1, 27 bytes > > System Information > > Manufacturer: Unknown > > Product Name: Unknown > > Version: Unknown > > Serial Number: Unknown > > UUID: Not Settable > > Wake-up Type: Reserved > > SKU Number: Unknown > > Family: Unknown > > > > Handle 0x0002, DMI type 2, 14 bytes > > Base Board Information > > Manufacturer: Unknown > > Product Name: Unknown > > Version: Unknown > > Serial Number: Not Specified > > Asset Tag: Unknown > > Features: > > Board is a hosting board > > Location In Chassis: Not Specified > > Chassis Handle: 0x0000 > > Type: Motherboard > > > > Signed-off-by: Ilias Apalodimas > > --- > > lib/smbios.c | 17 +++-------------- > > 1 file changed, 3 insertions(+), 14 deletions(-) > > Perhaps a better fix is to drop the smbios info? > > What upstream projects use this information to show things to the > user? You showed a screenshot of some sort of system-info app. We > could teach it about falling back to the device tree. That way we are > not adding fake information to SMBIOS. Lots of things use it, particularly for enterprise support platforms. The system-info apps you mention above are the GNOME about dialog box and a tool called neofetch (which I personally don't particularly care for but people like it for some reason). There's general tools like dmidecode that use the information, but there's a LOT of open source tools that use the SMBIOS information, most of the Desktop UX About or HW tools, a lot of support tools like sosreport (https://github.com/sosreport/sos), and server management tools like cockpit (https://cockpit-project.org/) and uncountable proprietary tools. The problem with putting these things into Device Tree is that they're not really describing the hardware explicitly and it's U-Boot specific and Rob has mentioned in the past we absolutely shouldn't be making things up that don't belong in Device Tree. > Also, SMBIOS is a legacy thing and a PITA to work with. How about we > use the device tree binding for the same info: You say it's legacy, yet it released a new 3.6.0 version in June this year and is used extensively across x86 and is required for some of the Arm SystemReady standards. Doesn't appear particularly legacy to me. While I don't particularly like SMBIOS either it's the standard and widely used, I don't see it going anywhere soon. The advantage of it from someone who had to deal with end to end I feel it's better to support this because patching all the various projects to support other things and getting them deployed and enterprises and third parties to upgrade and integrate into their platforms and processes. Which from experience takes an extremely long time! > smbios { > compatible = "u-boot,sysinfo-smbios"; > > smbios { > system { > manufacturer = "pine64"; > product = "rock64_rk3328"; > }; > > baseboard { > manufacturer = "pine64"; > product = "rock64_rk3328"; > }; > > chassis { > manufacturer = "pine64"; > product = "rock64_rk3328"; > }; > }; > }; > > This is easy to parse and gets us away from all this legacy junk that > we don't need. I don't see this is any more pretty or any better than getting the information from Device Tree, moving forward I think it would also be useful to populate things like serial numbers from the fuse/otp blocks which we often already display either on the console during boot for via various commands. Overall I think we need to be practical, this is a standard that is widely used now, it's much more straight forward for the overall ecosystem to continue to use a widely adopted standard rather than trying to update all the open and proprietary tools out there to some new "standard" that is only useful for device tree platforms. I'll reference XKCD here for that: https://xkcd.com/927/ Peter