From: Rob Herring <robh+dt@kernel.org>
To: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc: Mailing List <devicetree-spec@vger.kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
devicetree@vger.kernel.org
Subject: Re: [PATCH] Describe "fail" status for /cpus/cpu* nodes
Date: Fri, 8 Oct 2021 08:19:04 -0500 [thread overview]
Message-ID: <CAL_Jsq+b2oiBwWzHP3398GGTh0Od1wgQRhf99EB82edi5Rg=gA@mail.gmail.com> (raw)
In-Reply-To: <9bd436c8c61052ec65e1f9e830c10cd783320822.camel@ew.tq-group.com>
On Fri, Oct 8, 2021 at 5:31 AM Matthias Schiffer
<matthias.schiffer@ew.tq-group.com> wrote:
>
> On Thu, 2021-09-16 at 16:10 +0200, Matthias Schiffer wrote:
> > There are situations where it is desirable to use the same base Device
> > Tree for devices with a different number of CPUs: There may be CPU
> > variants with different numbers of cores that can be used interchangably
> > on the same mainboard, or there are multiple CPU sockets. Not needing to
> > explicitly build a device tree for each such variant can make
> > maintenance significantly easier.
> >
> > For this to work, a system firmware / bootloader needs to adjust the
> > Device Tree by removing or disabling the excess CPU nodes. However, this
> > is currently not easily possible due to the special meaning of the
> > "disabled" status for CPU nodes:
> >
> > - A "disabled" CPU node is interpreted as inactive, but existent. The
> > Linux kernel will attempt to enable such CPUs on boot, which will
> > obviously fail for non-existent CPUs
> > - Removing the CPU node altogether from a Device Tree is much more
> > complex than setting a single property, as it may leave dangling
> > phandle references, often requiring specific knowledge of other nodes'
> > structure to deal with them.
> >
> > In the discussion [1] it was suggested to introduce a new status value
> > for CPUs that should really not be used at all. Rob proposed to use the
> > value "fail", which already exists in the generic definitions of the
> > status property.
> >
> > [1] https://www.lkml.org/lkml/2020/8/26/1237
>
> Hi,
> I haven't received any feedback regarding this spec update yet. Should
> I also send a kernel patch that actually implements this behaviour?
Looks fine to me, just hadn't gotten around to applying.
> Do properties described in the spec also need to be documented in the
> kernel's Documentation/devicetree/bindings? It seems that there is no
> generic "cpu" binding documentation at the moment, only arch-specific
> variants.
https://github.com/devicetree-org/dt-schema/blob/main/schemas/cpus.yaml
Rob
prev parent reply other threads:[~2021-10-08 13:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210916141028.32058-1-matthias.schiffer@ew.tq-group.com>
2021-10-08 10:31 ` [PATCH] Describe "fail" status for /cpus/cpu* nodes Matthias Schiffer
2021-10-08 13:19 ` Rob Herring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL_Jsq+b2oiBwWzHP3398GGTh0Od1wgQRhf99EB82edi5Rg=gA@mail.gmail.com' \
--to=robh+dt@kernel.org \
--cc=devicetree-spec@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=matthias.schiffer@ew.tq-group.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).