* [PATCH] Describe "fail" status for /cpus/cpu* nodes
@ 2021-09-16 14:10 Matthias Schiffer
2021-10-08 10:31 ` Matthias Schiffer
[not found] ` <20210916141028.32058-1-matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
0 siblings, 2 replies; 6+ messages in thread
From: Matthias Schiffer @ 2021-09-16 14:10 UTC (permalink / raw)
To: devicetree-spec-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Frank Rowand, Matthias Schiffer
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
Suggested-by: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Matthias Schiffer <matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
---
source/chapter3-devicenodes.rst | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 1cea148..9d8ef6e 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -614,8 +614,8 @@ standard properties with specific applicable detail.
CPU. This property shall be present for nodes
representing CPUs in a symmetric
multiprocessing (SMP) configuration. For a CPU
- node the meaning of the ``"okay"`` and
- ``"disabled"`` values are as follows:
+ node the meaning of the ``"okay"``, ``"disabled"``
+ and ``"fail"`` values are as follows:
``"okay"`` :
The CPU is running.
@@ -623,6 +623,9 @@ standard properties with specific applicable detail.
``"disabled"`` :
The CPU is in a quiescent state.
+ ``"fail"`` :
+ The CPU is not operational or does not exist.
+
A quiescent CPU is in a state where it cannot
interfere with the normal operation of other
CPUs, nor can its state be affected by the
@@ -639,6 +642,11 @@ standard properties with specific applicable detail.
loop, held in reset, and electrically isolated
from the system bus or in another
implementation dependent state.
+
+ A CPU with ``"fail"`` status does not affect the
+ system in any way.
+ The status is assigned to nodes for which no
+ corresponding CPU exists.
``enable-method`` | SD | ``<stringlist>`` Describes the method by which a CPU in a
disabled state is enabled. This property is
required for CPUs with a status property with
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] Describe "fail" status for /cpus/cpu* nodes
[not found] ` <20210916141028.32058-1-matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
@ 2021-10-08 10:31 ` Matthias Schiffer
0 siblings, 0 replies; 6+ messages in thread
From: Matthias Schiffer @ 2021-10-08 10:31 UTC (permalink / raw)
To: devicetree-spec; +Cc: Rob Herring, Frank Rowand, devicetree
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?
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.
>
> Suggested-by: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> ---
> source/chapter3-devicenodes.rst | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
> index 1cea148..9d8ef6e 100644
> --- a/source/chapter3-devicenodes.rst
> +++ b/source/chapter3-devicenodes.rst
> @@ -614,8 +614,8 @@ standard properties with specific applicable detail.
> CPU. This property shall be present for nodes
> representing CPUs in a symmetric
> multiprocessing (SMP) configuration. For a CPU
> - node the meaning of the ``"okay"`` and
> - ``"disabled"`` values are as follows:
> + node the meaning of the ``"okay"``, ``"disabled"``
> + and ``"fail"`` values are as follows:
>
> ``"okay"`` :
> The CPU is running.
> @@ -623,6 +623,9 @@ standard properties with specific applicable detail.
> ``"disabled"`` :
> The CPU is in a quiescent state.
>
> + ``"fail"`` :
> + The CPU is not operational or does not exist.
> +
> A quiescent CPU is in a state where it cannot
> interfere with the normal operation of other
> CPUs, nor can its state be affected by the
> @@ -639,6 +642,11 @@ standard properties with specific applicable detail.
> loop, held in reset, and electrically isolated
> from the system bus or in another
> implementation dependent state.
> +
> + A CPU with ``"fail"`` status does not affect the
> + system in any way.
> + The status is assigned to nodes for which no
> + corresponding CPU exists.
> ``enable-method`` | SD | ``<stringlist>`` Describes the method by which a CPU in a
> disabled state is enabled. This property is
> required for CPUs with a status property with
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Describe "fail" status for /cpus/cpu* nodes
@ 2021-10-08 10:31 ` Matthias Schiffer
0 siblings, 0 replies; 6+ messages in thread
From: Matthias Schiffer @ 2021-10-08 10:31 UTC (permalink / raw)
To: devicetree-spec-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA
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?
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.
>
> Suggested-by: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matthias Schiffer <matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
> ---
> source/chapter3-devicenodes.rst | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
> index 1cea148..9d8ef6e 100644
> --- a/source/chapter3-devicenodes.rst
> +++ b/source/chapter3-devicenodes.rst
> @@ -614,8 +614,8 @@ standard properties with specific applicable detail.
> CPU. This property shall be present for nodes
> representing CPUs in a symmetric
> multiprocessing (SMP) configuration. For a CPU
> - node the meaning of the ``"okay"`` and
> - ``"disabled"`` values are as follows:
> + node the meaning of the ``"okay"``, ``"disabled"``
> + and ``"fail"`` values are as follows:
>
> ``"okay"`` :
> The CPU is running.
> @@ -623,6 +623,9 @@ standard properties with specific applicable detail.
> ``"disabled"`` :
> The CPU is in a quiescent state.
>
> + ``"fail"`` :
> + The CPU is not operational or does not exist.
> +
> A quiescent CPU is in a state where it cannot
> interfere with the normal operation of other
> CPUs, nor can its state be affected by the
> @@ -639,6 +642,11 @@ standard properties with specific applicable detail.
> loop, held in reset, and electrically isolated
> from the system bus or in another
> implementation dependent state.
> +
> + A CPU with ``"fail"`` status does not affect the
> + system in any way.
> + The status is assigned to nodes for which no
> + corresponding CPU exists.
> ``enable-method`` | SD | ``<stringlist>`` Describes the method by which a CPU in a
> disabled state is enabled. This property is
> required for CPUs with a status property with
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Describe "fail" status for /cpus/cpu* nodes
@ 2021-10-08 13:19 ` Rob Herring
0 siblings, 0 replies; 6+ messages in thread
From: Rob Herring @ 2021-10-08 13:19 UTC (permalink / raw)
To: Matthias Schiffer; +Cc: Mailing List, Frank Rowand, devicetree
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Describe "fail" status for /cpus/cpu* nodes
@ 2021-10-08 13:19 ` Rob Herring
0 siblings, 0 replies; 6+ messages in thread
From: Rob Herring @ 2021-10-08 13:19 UTC (permalink / raw)
To: Matthias Schiffer
Cc: Mailing List, Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA
On Fri, Oct 8, 2021 at 5:31 AM Matthias Schiffer
<matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Describe "fail" status for /cpus/cpu* nodes
[not found] ` <20210916141028.32058-1-matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
@ 2021-11-30 17:01 ` Rob Herring
0 siblings, 0 replies; 6+ messages in thread
From: Rob Herring @ 2021-11-30 17:01 UTC (permalink / raw)
To: Matthias Schiffer; +Cc: Mailing List, Frank Rowand
On Thu, Sep 16, 2021 at 9:10 AM Matthias Schiffer
<matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org> 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
>
> Suggested-by: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matthias Schiffer <matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
> ---
> source/chapter3-devicenodes.rst | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
Applied, thanks.
Rob
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-11-30 17:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-16 14:10 [PATCH] Describe "fail" status for /cpus/cpu* nodes Matthias Schiffer
2021-10-08 10:31 ` Matthias Schiffer
2021-10-08 10:31 ` Matthias Schiffer
2021-10-08 13:19 ` Rob Herring
2021-10-08 13:19 ` Rob Herring
[not found] ` <20210916141028.32058-1-matthias.schiffer-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
2021-11-30 17:01 ` Rob Herring
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.