devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).