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 41E66ECAAA1 for ; Sat, 17 Sep 2022 16:55:57 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8765084A03; Sat, 17 Sep 2022 18:55:54 +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="NJOMvvjG"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 04A4B84A7E; Sat, 17 Sep 2022 18:55:53 +0200 (CEST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 16866849F1 for ; Sat, 17 Sep 2022 18:55:50 +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=seanga2@gmail.com Received: by mail-qt1-x82a.google.com with SMTP id h21so18075983qta.3 for ; Sat, 17 Sep 2022 09:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date; bh=3pDgS/jgsdi4HQaC3CaIpfu1FIgvaDWfCbgEX1y4RGs=; b=NJOMvvjG0hDJ5umomaXKQZATM4vGVEuyMcwXud0Ihz/zPxrLbR3yDFfC4orcULKe63 pqwUex2WRN72T4HEv8PKqTRv3CkAKfIKyxyX/olvhWLePT6wKHO+lroHENSHrB7E6r2t dsSksLad+pIasLYkb1J2Ew62c5fDsX5+9zwNuBScY6hzE4ltPAu4vq7Zp32b9SjzVUiX WGtBgaZWV5aYfQjGmhwkMDoJBI9CKKEWogDdBomo2TehZlEMRzhugjFp5FkL/h5sV2oX h/6vWXcNSqmKzIRsK4BiUxnOIHJaEcCXIRhGRHi/FHJ/Vqyb95Tvr7kmsSx567dBXvTD 17Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=3pDgS/jgsdi4HQaC3CaIpfu1FIgvaDWfCbgEX1y4RGs=; b=PSc+TjX5QDdXFJ3mLjXJFeLzqcX964nOZ+ousYRH5bVG40qiwFsRnzCsK3+3kmM/B+ +6ec4NI5DjdBvJ+WFbwplXmqyil8/JSutA+gUWRKauH3WNilKdJFSRmrucDLd7oCHqZK 5lbFjIZWRRUuwmlKvQFd1q5RYHnQNIKpVw3s4SODCVT6DDFyKY40Uwrt/xgwS+U3xKpv qmtTU9KTutrYXisZWcFj1HggMrng9nQzblk0Xm3jrsRvIJ5kF7VEUQCUHzvSwTgWhtLa 3n6zwG2Qu0Ofb8kzLNqe0nGlvKpdTCg6zzPLOA5dM/ZU78qk8qJ/g5j5MrsbfpE8y6Z3 wTLg== X-Gm-Message-State: ACrzQf1vZZgHzZXZJSR6Qwjhwil3cQK6gD5hg+B6199cqqgw+xV7HJ9d hnsqb9aOLchUPCitypQ2rrg= X-Google-Smtp-Source: AMsMyM7aA5A7d52x8LSKQ02mM/v3/apbnY3F63zRwLnfmOOH2nSRRNbQa6SRXDKzb2tKOS8WDtiPSA== X-Received: by 2002:a05:622a:1ba8:b0:35b:b64b:5c82 with SMTP id bp40-20020a05622a1ba800b0035bb64b5c82mr9010533qtb.95.1663433748724; Sat, 17 Sep 2022 09:55:48 -0700 (PDT) Received: from [192.168.1.201] (pool-173-73-95-180.washdc.fios.verizon.net. [173.73.95.180]) by smtp.gmail.com with ESMTPSA id l2-20020a37f902000000b006b9c355ed75sm8524364qkj.70.2022.09.17.09.55.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Sep 2022 09:55:48 -0700 (PDT) Message-ID: <0e250d37-de96-330b-4666-af07fd65e2e8@gmail.com> Date: Sat, 17 Sep 2022 12:55:47 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 From: Sean Anderson Subject: Re: [PATCH 1/2] smbios: Simplify reporting of unknown values To: Ilias Apalodimas , Simon Glass Cc: U-Boot Mailing List , Tom Rini , Heinrich Schuchardt , Peter Robinson References: <20220906134426.53748-1-ilias.apalodimas@linaro.org> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 9/16/22 16:30, Ilias Apalodimas wrote: > Hi Simon, > > [...] > >>> 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? > > Unfortunately there's a ton of userspace tools still using it. So I think > we still need it > >> >> 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. >> > > What's fake here? The model and compatible are taken directly from the DT > and that should be accurate. I'd rather fix the DT if that's problematic. > What would make sense for me to change is take the first token of the > compatible node instead of the entire string as it's format is expected to > be anyway. > Manufacturer: socionext,developer-box > Product Name: Socionext Developer Box Well, firstly, the manufacturer is "Socionext", not "socionext,developer-box". Compatibles are not suitable for user-visible identifiers. The product name should also be something like "Socionext Developerbox" or maybe "SynQuacer E-series", but this more of a "bug" in the devicetree model property. Second, these identifiers are not suitable for all structures you want to use it for. For example, the chassis is really a "INWIN industrial PC case: MicroATX mini-tower case IW-BK623/300-H E USB 3.0 Black with 300W SFX power supply" [1]. I would describe this as something like Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: INWIN Type: Mini Tower Lock: Not Present Version: Unknown Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 The exact values are not particularly important, but I would certainly classify a manufacturer of "socionext,developer-box" as fake. We might not even know what the chassis is; what's to stop a user from using a different case? [1] https://www.96boards.org/documentation/enterprise/developerbox/hardware-docs/MN04-00002-3E.pdf >> Also, SMBIOS is a legacy thing and a PITA to work with. How about we >> use the device tree binding for the same info: >> >> 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. > > That's the exact opposite of the patch description. Most of these info are > already included in the DT in it's standard properties. So if U-Boot ends > up with a DT without these we get a usable smbios table. For example a DT > handed over by the previous stage bootloader would not include these nodes. I agree. I think a better example would fill in these fields with descriptive values. > As far as sysinfo-smbios node is concerned, it's only present in 13 > boards, so it's not like it's used by the majority of boards. Yes we > could fix them, but imho we are better off re-using what's already there > and defined on the DT spec at least for the simplistic values. IMO SYS_VENDOR and SYS_BOARD are more descriptive than the devicetree values, but neither is good... How many boards do we have which actually use the SMBIOS tables? There are a lot of boards with EFI_LOADER enabled by default, but I suspect most never boot anything EFI. --Sean