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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D3F6C433EF for ; Wed, 18 May 2022 16:54:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240542AbiERQy1 (ORCPT ); Wed, 18 May 2022 12:54:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240464AbiERQyZ (ORCPT ); Wed, 18 May 2022 12:54:25 -0400 Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F2DC201339; Wed, 18 May 2022 09:54:24 -0700 (PDT) Received: by mail-oo1-f45.google.com with SMTP id q73-20020a4a334c000000b0035eb110dd0dso516595ooq.10; Wed, 18 May 2022 09:54:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LtkWw6fSMloB5/PDUQGj9Fdz71VUuBNVm04fOD0zRWU=; b=xe+cpXTDIB/gVIQhZlok/rYgQg8PjyTp/BewG14AMf1EoVX+t3dL2fBC9MfNeKqYm/ lZItObf+r686lf4JSbKQhTtlY+Y4Cc2YbU2VEI2wiy2OB5Luf4GzpKsE2kziUx1mjSU3 5bvBDe/OXTQLAiKlHn9nQ+oNZvgFFoMVSK3ASPq/JUETfue6NsFBsjz5mkEy4OzYpkAg T21JK+sttSTAVxHSmyBl6Luc8upg6IQwOUbqk5W+/QA8yEnpSdroYeNH4TK9xXgK9+bH 5h8+kCFl8WYzqJ6NrtsKotnMYmmXQO24Wd281UIXG2imS78b5IfIaJSwZihPjGjbk6XP J5uA== X-Gm-Message-State: AOAM533WFvZpcci9S4nrEvwEMpIwY2OKFuS5HP7X5MnCLB30newKYJBh WOWA2V2lDCWkcfDmc07aig== X-Google-Smtp-Source: ABdhPJywLKeAaJqcZXkFmnZxmhvPb8KJmZF/4AP/8kXOBXaQ9XEpghDsect82HnXuwtczswZegMMkQ== X-Received: by 2002:a4a:a50d:0:b0:35e:d7d1:c7dc with SMTP id v13-20020a4aa50d000000b0035ed7d1c7dcmr252191ook.27.1652892863324; Wed, 18 May 2022 09:54:23 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id o82-20020aca4155000000b00326e2284976sm950613oia.15.2022.05.18.09.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 09:54:22 -0700 (PDT) Received: (nullmailer pid 3489723 invoked by uid 1000); Wed, 18 May 2022 16:54:21 -0000 Date: Wed, 18 May 2022 11:54:21 -0500 From: Rob Herring To: Peter Maydell Cc: Andre Przywara , Frank Rowand , devicetree@vger.kernel.org, linux-arm-kernel , "linux-kernel@vger.kernel.org" , Ross Burton , Ard Biesheuvel , Catalin Marinas , Will Deacon , Russell King Subject: Re: [PATCH] of/fdt: Ignore disabled memory nodes Message-ID: <20220518165421.GF3302100-robh@kernel.org> References: <20220517101410.3493781-1-andre.przywara@arm.com> <20220517153444.GA1057027-robh@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 17, 2022 at 08:19:47PM +0100, Peter Maydell wrote: > On Tue, 17 May 2022 at 18:48, Rob Herring wrote: > > > > On Tue, May 17, 2022 at 11:54 AM Peter Maydell wrote: > > > > > > On Tue, 17 May 2022 at 16:34, Rob Herring wrote: > > > > > > > > On Tue, May 17, 2022 at 11:14:10AM +0100, Andre Przywara wrote: > > > > > When we boot a machine using a devicetree, the generic DT code goes > > > > > through all nodes with a 'device_type = "memory"' property, and collects > > > > > all memory banks mentioned there. However it does not check for the > > > > > status property, so any nodes which are explicitly "disabled" will still > > > > > be added as a memblock. > > > > > This ends up badly for QEMU, when booting with secure firmware on > > > > > arm/arm64 machines, because QEMU adds a node describing secure-only > > > > > memory: > > > > > =================== > > > > > secram@e000000 { > > > > > > > > BTW, 'memory' is the correct node name. > > > > > > We already have a 'memory' node, which is for the NS > > > memory. This one's for the secure-only RAM block, > > > which is why I gave it a name that hopefully helps in > > > spotting that when a human is reading the DT. > > > > You can do: secram: memory@e000000 { > > > > Where 'secram' is only a source level label until overlays come into > > the picture. > > We generate the DTB with libfdt, so source-only information > isn't something we can put in, I think. (The quoted DT fragment > in this patch's commit message is the result of decompiling > the runtime generated DT binary blob with dtc.) Given the runtime aspect with overlays, it's conceivable that libfdt could support setting labels some day and then dts output maintaining them. We could also consider a standard node name such as 'secure-memory'. It's a whole can of worms though on how secure vs. non-secure memory (and other things) are represented. > > > I'm not really sure to what extent node names in device trees are > > > "this is just an identifying textual label" and to what extent > > > they are "this is really ABI and you need to follow the standard", > > > though -- nothing in practice seems to care what they are, > > > suggesting the "textual label" theory, but some bits of tooling > > > complain if you do things like forget the address value or use the > > > same address for two different nodes, suggesting the "really ABI" > > > theory. > > > > Node names are supposed to follow the class of device and there's a > > list of established names in the spec. > > > > Sometimes it's ABI and sometimes not. Much of it is just good hygiene. > > memory nodes are also special because 'device_type' is used to > > identify them, but device_type is generally deprecated for FDT as its > > meaning in OpenFirmware doesn't apply (it defines what callable > > methods exist). We could use the nodename (without unit address) > > instead, but that would fail in some cases as other names have been > > used. > > This seems kind of odd to me as a design, compared to Design? I wish. Evolution. > "have the node have a property that says what it is > and let the name of the node just be, well, its name" > (especially since 'device_type' and 'compatible' look an > awful lot like "this is the property that tells you what this > node actually is".) > Are we just stuck with what we have for historical reasons ? Yes. If we were designing this, we'd probably have 'compatible = "memory"'. We're likely just stuck with things how they are. Mostly node names haven't been an ABI and we're just trying to be consistent in naming and use of unit-addresses. Rob 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6A2C7C433F5 for ; Wed, 18 May 2022 16:55:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GMfgLF+TDfgjsteSsWO3D8f8w+b7txPCQb7gglJ8KZk=; b=OoaomM69yUv8nP ndPEftkQawSpGQho9RodsYvuFADfECrzbrjdx4Mal1u1ncurnr/kZG/haAVKvGc3H6OdBP38m6Xlb jaAXOAnKiiYtjKZvvzBDaAecliWZmQMVlrMTJyOu1dN+RlXkKF7evbQ0cWn+NyptGmtjEX86QlGV0 c2ariveo9/rECxT0k2G+EgC+Zko/jl9rO+BuTR3yDDEarrfssiccAXXbHM8eaXDLArN1pFnCtUTu5 7jCmFoMFn36MJcbn93XzBi6RXmUmt5K24+JYqgasEUjX8BUBj5ZQ0X7BzR2716BN+k6t4JODRnHw2 57hfSvqGapa7nw2BLnbQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrMwO-0038KC-Uh; Wed, 18 May 2022 16:54:29 +0000 Received: from mail-oo1-f54.google.com ([209.85.161.54]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrMwL-0038IR-HA for linux-arm-kernel@lists.infradead.org; Wed, 18 May 2022 16:54:27 +0000 Received: by mail-oo1-f54.google.com with SMTP id a23-20020a4ad5d7000000b0035ee70da7a9so522785oot.1 for ; Wed, 18 May 2022 09:54:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LtkWw6fSMloB5/PDUQGj9Fdz71VUuBNVm04fOD0zRWU=; b=dNO1ZUZCzIS+V+1xtCP+rtUANZfTU3uYWAn2XrPe6u2iL8Fh7b3DOBVWwlXN0wT/7O y3o7O7q/QR/fpWi8hm3fNRgBbh1v9k7UBVPRzFXYATYkvg8tLaMXO9QyNuWNNDcWX0WG GvwRvryvDhY3mkNhcFvz1K7F+3NeMfxSUURyvJqXrQ/WbCAPUYDbB8Zs1BS+GbnJwVfG gE9w00CJaFnFajpogbm+VXIa5Z8KKvb9uteEjN4ZdqJ9zdb8Z/tvwXlqVBI4sg6tIyyG XLyA4TRjkbIKIOU6OAne0SG6zTOqMfq8jCVWhO1zoIshw0e2bfPWqco2QvORNU6tEWkD ovVw== X-Gm-Message-State: AOAM531+QhQjaUFsZPMyvFKftj3TE7po8nolOTZFtWqA1lZOTA8X4FjU K/pgcET5QsHIPVjG1hi52Q== X-Google-Smtp-Source: ABdhPJywLKeAaJqcZXkFmnZxmhvPb8KJmZF/4AP/8kXOBXaQ9XEpghDsect82HnXuwtczswZegMMkQ== X-Received: by 2002:a4a:a50d:0:b0:35e:d7d1:c7dc with SMTP id v13-20020a4aa50d000000b0035ed7d1c7dcmr252191ook.27.1652892863324; Wed, 18 May 2022 09:54:23 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id o82-20020aca4155000000b00326e2284976sm950613oia.15.2022.05.18.09.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 09:54:22 -0700 (PDT) Received: (nullmailer pid 3489723 invoked by uid 1000); Wed, 18 May 2022 16:54:21 -0000 Date: Wed, 18 May 2022 11:54:21 -0500 From: Rob Herring To: Peter Maydell Cc: Andre Przywara , Frank Rowand , devicetree@vger.kernel.org, linux-arm-kernel , "linux-kernel@vger.kernel.org" , Ross Burton , Ard Biesheuvel , Catalin Marinas , Will Deacon , Russell King Subject: Re: [PATCH] of/fdt: Ignore disabled memory nodes Message-ID: <20220518165421.GF3302100-robh@kernel.org> References: <20220517101410.3493781-1-andre.przywara@arm.com> <20220517153444.GA1057027-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220518_095425_621894_AF1CBA03 X-CRM114-Status: GOOD ( 37.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 17, 2022 at 08:19:47PM +0100, Peter Maydell wrote: > On Tue, 17 May 2022 at 18:48, Rob Herring wrote: > > > > On Tue, May 17, 2022 at 11:54 AM Peter Maydell wrote: > > > > > > On Tue, 17 May 2022 at 16:34, Rob Herring wrote: > > > > > > > > On Tue, May 17, 2022 at 11:14:10AM +0100, Andre Przywara wrote: > > > > > When we boot a machine using a devicetree, the generic DT code goes > > > > > through all nodes with a 'device_type = "memory"' property, and collects > > > > > all memory banks mentioned there. However it does not check for the > > > > > status property, so any nodes which are explicitly "disabled" will still > > > > > be added as a memblock. > > > > > This ends up badly for QEMU, when booting with secure firmware on > > > > > arm/arm64 machines, because QEMU adds a node describing secure-only > > > > > memory: > > > > > =================== > > > > > secram@e000000 { > > > > > > > > BTW, 'memory' is the correct node name. > > > > > > We already have a 'memory' node, which is for the NS > > > memory. This one's for the secure-only RAM block, > > > which is why I gave it a name that hopefully helps in > > > spotting that when a human is reading the DT. > > > > You can do: secram: memory@e000000 { > > > > Where 'secram' is only a source level label until overlays come into > > the picture. > > We generate the DTB with libfdt, so source-only information > isn't something we can put in, I think. (The quoted DT fragment > in this patch's commit message is the result of decompiling > the runtime generated DT binary blob with dtc.) Given the runtime aspect with overlays, it's conceivable that libfdt could support setting labels some day and then dts output maintaining them. We could also consider a standard node name such as 'secure-memory'. It's a whole can of worms though on how secure vs. non-secure memory (and other things) are represented. > > > I'm not really sure to what extent node names in device trees are > > > "this is just an identifying textual label" and to what extent > > > they are "this is really ABI and you need to follow the standard", > > > though -- nothing in practice seems to care what they are, > > > suggesting the "textual label" theory, but some bits of tooling > > > complain if you do things like forget the address value or use the > > > same address for two different nodes, suggesting the "really ABI" > > > theory. > > > > Node names are supposed to follow the class of device and there's a > > list of established names in the spec. > > > > Sometimes it's ABI and sometimes not. Much of it is just good hygiene. > > memory nodes are also special because 'device_type' is used to > > identify them, but device_type is generally deprecated for FDT as its > > meaning in OpenFirmware doesn't apply (it defines what callable > > methods exist). We could use the nodename (without unit address) > > instead, but that would fail in some cases as other names have been > > used. > > This seems kind of odd to me as a design, compared to Design? I wish. Evolution. > "have the node have a property that says what it is > and let the name of the node just be, well, its name" > (especially since 'device_type' and 'compatible' look an > awful lot like "this is the property that tells you what this > node actually is".) > Are we just stuck with what we have for historical reasons ? Yes. If we were designing this, we'd probably have 'compatible = "memory"'. We're likely just stuck with things how they are. Mostly node names haven't been an ABI and we're just trying to be consistent in naming and use of unit-addresses. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel