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 24641C433FE for ; Thu, 21 Apr 2022 10:02:32 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 503CE83894; Thu, 21 Apr 2022 12:02:29 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 933D9834BC; Thu, 21 Apr 2022 12:02:27 +0200 (CEST) Received: from sibelius.xs4all.nl (80-61-163-207.fixed.kpn.net [80.61.163.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id B886C834BC for ; Thu, 21 Apr 2022 12:02:24 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 40cc8080; Thu, 21 Apr 2022 12:02:23 +0200 (CEST) Date: Thu, 21 Apr 2022 12:02:23 +0200 (CEST) From: Mark Kettenis To: Francesco Dolcini Cc: francesco.dolcini@toradex.com, trini@konsulko.com, u-boot@lists.denx.de, sjg@chromium.org, robh@kernel.org In-Reply-To: <20220421083434.GA229346@francesco-nb.int.toradex.com> (message from Francesco Dolcini on Thu, 21 Apr 2022 10:34:34 +0200) Subject: Re: RFC: Adding U-Boot version in FDT chosen node References: <20220411181755.GB20890@francesco-nb.int.toradex.com> <20220420170143.GA208136@francesco-nb.int.toradex.com> <20220421083434.GA229346@francesco-nb.int.toradex.com> Message-ID: 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.5 at phobos.denx.de X-Virus-Status: Clean > Date: Thu, 21 Apr 2022 10:34:34 +0200 > From: Francesco Dolcini > > Hello Mark > > On Wed, Apr 20, 2022 at 11:51:44PM +0200, Mark Kettenis wrote: > > > Date: Wed, 20 Apr 2022 19:01:43 +0200 > > > From: Francesco Dolcini > > > > > > +Tom > > > > > > On Mon, Apr 11, 2022 at 08:17:55PM +0200, Francesco Dolcini wrote: > > > > Hello all, > > > > I have a need to pass the u-boot version string to the operating > > > > system and I'm thinking at adding `u-boot,version` property storing > > > > `version_string` in it in the FDT `chosen` node. > > > > > > > > Is this something that would be generally useful? Would be a patch like > > > > that acceptable in upstream u-boot? Is there any other obvious way to > > > > achieve something like that already implemented (using the cmdline would > > > > work without any code change, but probably not the nicest solution). > > > > > > Any concern on this Tom? I'm asking you directly since you recently > > > acknowledged another change [0] related to the chosen node. > > > > > > [0] https://lore.kernel.org/all/20220412201444.GN14282@bill-the-cat/ > > > > To be honest, putting this in the "chosen" node feels odd. > > Traditionally device trees have a node dedicated to the firmware. For > > example Sun OpenFirmware systems had a "openprom" node with a > > "version" property. And OpenPOWER systems have an > > "ibm,firmware-versions" node. > > I would personally not mind the parent node of this property, however > from my partial understanding on the recent device tree architecture > decisions we do want only the description of the hardware and real > devices into it. Well, if that were true, device trees for virtualized platforms (e.g. QEMU with virtio devices) wouldn't work. And things like PSCI on arm64 wouldn't be discoverable. The boundary between "real hardware" and "firmware" is somewhat vague anyway. The hardware may be an integrated microcontroller running a firmware, where the firmware is what actually defines the programming interface. > No software artifact nor software configuration should be part of it, > with the only exception of the chosen node [0]. The device tree specification itself uses slightly different text: "The /chosen node does not represent a real device in the system but describes parameters chosen or specified by the system firmware at run time. It shall be a child of the root node." I wouldn't call the U-Boot version number a "paramater chosen or specified by the system firmware at run time". On the other hand, U-Boot doesn't provide some sort of U-Boot specific firmware interface to the OS. The firmware interfaces it does provide are industry standard interfaces such as UEFI, SMBIOS and PSCI. And what you're trying to do is just provide some static information about the U-Boot version that is providing those interfaces. Note U-Boot already provides its version number is provided through the UEFI and SMBIOS interfaces. But of course not all "boards" enable those interfaces. Anyway, I'm just pointing out here that I think "/chosen" isn't necessarily the "obvious" place to provide this information, and that there is a precedent for providing this information in a separate top-level node. > Rob in cc can comment if I understood this wrong. > > [0] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt