From: Rob Herring <robh@kernel.org>
To: Alexander Graf <graf@amazon.com>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-mm@kvack.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org,
linux-doc@vger.kernel.org, x86@kernel.org,
Eric Biederman <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
James Gowans <jgowans@amazon.com>,
Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>,
arnd@arndb.de, pbonzini@redhat.com, madvenka@linux.microsoft.com,
Anthony Yznaga <anthony.yznaga@oracle.com>,
Usama Arif <usama.arif@bytedance.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
Date: Tue, 2 Jan 2024 08:20:23 -0700 [thread overview]
Message-ID: <20240102152023.GA2821956-robh@kernel.org> (raw)
In-Reply-To: <20231222195144.24532-12-graf@amazon.com>
On Fri, Dec 22, 2023 at 07:51:44PM +0000, Alexander Graf wrote:
> With ftrace in KHO, we are creating an ABI between old kernel and new
> kernel about the state that they transfer. To ensure that we document
> that state and catch any breaking change, let's add its schema to the
> common devicetree bindings. This way, we can quickly reason about the
> state that gets passed.
Why so much data in DT rather than putting all this information into
memory in your own data structure and DT just has a single property
pointing to that? That's what is done with every other blob of data
passed by kexec.
>
> Signed-off-by: Alexander Graf <graf@amazon.com>
> ---
> .../bindings/kho/ftrace/ftrace-array.yaml | 46 +++++++++++++++
> .../bindings/kho/ftrace/ftrace-cpu.yaml | 56 +++++++++++++++++++
> .../bindings/kho/ftrace/ftrace.yaml | 48 ++++++++++++++++
> 3 files changed, 150 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
>
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> new file mode 100644
> index 000000000000..9960fefc292d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace trace array
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,array-v1
> +
> + trace_flags:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Bitmap of all the trace flags that were enabled in the trace array at the
> + point of serialization.
> +
> +# Subnodes will be of type "ftrace,cpu-v1", one each per CPU
This can be expressed as a schema.
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - trace_flags
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> new file mode 100644
> index 000000000000..58c715e93f37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace per-CPU ring buffer contents
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,cpu-v1
> +
> + cpu:
> + $ref: /schemas/types.yaml#/definitions/uint32
'cpu' is already a defined property of type 'phandle'. While we can have
multiple types for a given property name, best practice is to avoid
that. The normal way to refer to a CPU would be a phandle to the CPU
node, but I can see that might not make sense here.
"CPU numbers" on arm64 are 64-bit values as well as they are the
CPU's MPIDR value.
> + description:
> + CPU number of the CPU that this ring buffer belonged to when it was
> + serialized.
> +
> + mem:
Too vague. Make the property name indicate what's in the memory.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u64 phys_addr, u64 len } elements that describe a list of ring
> + buffer pages. Each page consists of two elements. The first element
> + describes the location of the struct buffer_page that contains metadata
> + for a given ring buffer page, such as the ring's head indicator. The
> + second element points to the ring buffer data page which contains the raw
> + trace data.
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - cpu
> + - mem
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> new file mode 100644
> index 000000000000..b87a64843af3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace core data
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace-v1
> +
> + events:
Again, too vague.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u32 crc, u32 type } elements. Each element contains a unique
> + identifier for an event, followed by the identifier that this event had
> + in the previous kernel's trace buffers.
> +
> +# Other child nodes will be of type "ftrace,array-v1". Each of which describe
> +# a trace buffer
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - events
> +
> +examples:
> + - |
> + ftrace {
This should go under /chosen. Show that here. Start the example with
'/{' to do that and not add the usual boilerplate we add when extracting
the examples.
Also, we don't need 3 examples. Just do 1 complete example here.
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> --
> 2.40.1
>
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
>
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Alexander Graf <graf@amazon.com>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-mm@kvack.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org,
linux-doc@vger.kernel.org, x86@kernel.org,
Eric Biederman <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
James Gowans <jgowans@amazon.com>,
Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>,
arnd@arndb.de, pbonzini@redhat.com, madvenka@linux.microsoft.com,
Anthony Yznaga <anthony.yznaga@oracle.com>,
Usama Arif <usama.arif@bytedance.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
Date: Tue, 2 Jan 2024 08:20:23 -0700 [thread overview]
Message-ID: <20240102152023.GA2821956-robh@kernel.org> (raw)
In-Reply-To: <20231222195144.24532-12-graf@amazon.com>
On Fri, Dec 22, 2023 at 07:51:44PM +0000, Alexander Graf wrote:
> With ftrace in KHO, we are creating an ABI between old kernel and new
> kernel about the state that they transfer. To ensure that we document
> that state and catch any breaking change, let's add its schema to the
> common devicetree bindings. This way, we can quickly reason about the
> state that gets passed.
Why so much data in DT rather than putting all this information into
memory in your own data structure and DT just has a single property
pointing to that? That's what is done with every other blob of data
passed by kexec.
>
> Signed-off-by: Alexander Graf <graf@amazon.com>
> ---
> .../bindings/kho/ftrace/ftrace-array.yaml | 46 +++++++++++++++
> .../bindings/kho/ftrace/ftrace-cpu.yaml | 56 +++++++++++++++++++
> .../bindings/kho/ftrace/ftrace.yaml | 48 ++++++++++++++++
> 3 files changed, 150 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
>
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> new file mode 100644
> index 000000000000..9960fefc292d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace trace array
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,array-v1
> +
> + trace_flags:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Bitmap of all the trace flags that were enabled in the trace array at the
> + point of serialization.
> +
> +# Subnodes will be of type "ftrace,cpu-v1", one each per CPU
This can be expressed as a schema.
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - trace_flags
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> new file mode 100644
> index 000000000000..58c715e93f37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace per-CPU ring buffer contents
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,cpu-v1
> +
> + cpu:
> + $ref: /schemas/types.yaml#/definitions/uint32
'cpu' is already a defined property of type 'phandle'. While we can have
multiple types for a given property name, best practice is to avoid
that. The normal way to refer to a CPU would be a phandle to the CPU
node, but I can see that might not make sense here.
"CPU numbers" on arm64 are 64-bit values as well as they are the
CPU's MPIDR value.
> + description:
> + CPU number of the CPU that this ring buffer belonged to when it was
> + serialized.
> +
> + mem:
Too vague. Make the property name indicate what's in the memory.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u64 phys_addr, u64 len } elements that describe a list of ring
> + buffer pages. Each page consists of two elements. The first element
> + describes the location of the struct buffer_page that contains metadata
> + for a given ring buffer page, such as the ring's head indicator. The
> + second element points to the ring buffer data page which contains the raw
> + trace data.
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - cpu
> + - mem
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> new file mode 100644
> index 000000000000..b87a64843af3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace core data
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace-v1
> +
> + events:
Again, too vague.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u32 crc, u32 type } elements. Each element contains a unique
> + identifier for an event, followed by the identifier that this event had
> + in the previous kernel's trace buffers.
> +
> +# Other child nodes will be of type "ftrace,array-v1". Each of which describe
> +# a trace buffer
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - events
> +
> +examples:
> + - |
> + ftrace {
This should go under /chosen. Show that here. Start the example with
'/{' to do that and not add the usual boilerplate we add when extracting
the examples.
Also, we don't need 3 examples. Just do 1 complete example here.
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> --
> 2.40.1
>
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Alexander Graf <graf@amazon.com>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-mm@kvack.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org,
linux-doc@vger.kernel.org, x86@kernel.org,
Eric Biederman <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
James Gowans <jgowans@amazon.com>,
Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>,
arnd@arndb.de, pbonzini@redhat.com, madvenka@linux.microsoft.com,
Anthony Yznaga <anthony.yznaga@oracle.com>,
Usama Arif <usama.arif@bytedance.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
Date: Tue, 2 Jan 2024 08:20:23 -0700 [thread overview]
Message-ID: <20240102152023.GA2821956-robh@kernel.org> (raw)
In-Reply-To: <20231222195144.24532-12-graf@amazon.com>
On Fri, Dec 22, 2023 at 07:51:44PM +0000, Alexander Graf wrote:
> With ftrace in KHO, we are creating an ABI between old kernel and new
> kernel about the state that they transfer. To ensure that we document
> that state and catch any breaking change, let's add its schema to the
> common devicetree bindings. This way, we can quickly reason about the
> state that gets passed.
Why so much data in DT rather than putting all this information into
memory in your own data structure and DT just has a single property
pointing to that? That's what is done with every other blob of data
passed by kexec.
>
> Signed-off-by: Alexander Graf <graf@amazon.com>
> ---
> .../bindings/kho/ftrace/ftrace-array.yaml | 46 +++++++++++++++
> .../bindings/kho/ftrace/ftrace-cpu.yaml | 56 +++++++++++++++++++
> .../bindings/kho/ftrace/ftrace.yaml | 48 ++++++++++++++++
> 3 files changed, 150 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
>
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> new file mode 100644
> index 000000000000..9960fefc292d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace trace array
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,array-v1
> +
> + trace_flags:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Bitmap of all the trace flags that were enabled in the trace array at the
> + point of serialization.
> +
> +# Subnodes will be of type "ftrace,cpu-v1", one each per CPU
This can be expressed as a schema.
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - trace_flags
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> new file mode 100644
> index 000000000000..58c715e93f37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace per-CPU ring buffer contents
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,cpu-v1
> +
> + cpu:
> + $ref: /schemas/types.yaml#/definitions/uint32
'cpu' is already a defined property of type 'phandle'. While we can have
multiple types for a given property name, best practice is to avoid
that. The normal way to refer to a CPU would be a phandle to the CPU
node, but I can see that might not make sense here.
"CPU numbers" on arm64 are 64-bit values as well as they are the
CPU's MPIDR value.
> + description:
> + CPU number of the CPU that this ring buffer belonged to when it was
> + serialized.
> +
> + mem:
Too vague. Make the property name indicate what's in the memory.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u64 phys_addr, u64 len } elements that describe a list of ring
> + buffer pages. Each page consists of two elements. The first element
> + describes the location of the struct buffer_page that contains metadata
> + for a given ring buffer page, such as the ring's head indicator. The
> + second element points to the ring buffer data page which contains the raw
> + trace data.
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - cpu
> + - mem
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> new file mode 100644
> index 000000000000..b87a64843af3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace core data
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace-v1
> +
> + events:
Again, too vague.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u32 crc, u32 type } elements. Each element contains a unique
> + identifier for an event, followed by the identifier that this event had
> + in the previous kernel's trace buffers.
> +
> +# Other child nodes will be of type "ftrace,array-v1". Each of which describe
> +# a trace buffer
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - events
> +
> +examples:
> + - |
> + ftrace {
This should go under /chosen. Show that here. Start the example with
'/{' to do that and not add the usual boilerplate we add when extracting
the examples.
Also, we don't need 3 examples. Just do 1 complete example here.
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> --
> 2.40.1
>
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-02 15:20 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-22 19:35 [PATCH v2 00/17] kexec: Allow preservation of ftrace buffers Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 01/17] mm,memblock: Add support for scratch memory Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 02/17] memblock: Declare scratch memory as CMA Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2024-01-01 3:01 ` Stanislav Kinsburskii
2024-01-01 3:01 ` Stanislav Kinsburskii
2023-12-22 19:35 ` [PATCH v2 03/17] kexec: Add Kexec HandOver (KHO) generation helpers Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 04/17] kexec: Add KHO parsing support Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2024-01-01 3:33 ` Stanislav Kinsburskii
2024-01-01 3:33 ` Stanislav Kinsburskii
2024-01-01 3:33 ` Stanislav Kinsburskii
2024-01-15 13:27 ` Alexander Graf
2024-01-15 13:27 ` Alexander Graf
2024-01-15 13:27 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 05/17] kexec: Add KHO support to kexec file loads Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 06/17] kexec: Add config option for KHO Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 07/17] kexec: Add documentation " Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2024-01-01 3:55 ` Stanislav Kinsburskii
2024-01-01 3:55 ` Stanislav Kinsburskii
2024-01-01 3:55 ` Stanislav Kinsburskii
2023-12-22 19:35 ` [PATCH v2 08/17] arm64: Add KHO support Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 09/17] x86: " Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:35 ` Alexander Graf
2023-12-22 19:36 ` [PATCH v2 10/17] tracing: Initialize fields before registering Alexander Graf
2023-12-22 19:36 ` Alexander Graf
2023-12-22 19:36 ` Alexander Graf
2023-12-22 19:36 ` [PATCH v2 11/17] tracing: Introduce kho serialization Alexander Graf
2023-12-22 19:36 ` Alexander Graf
2023-12-22 19:36 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 06/17] kexec: Add config option for KHO Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 07/17] kexec: Add documentation " Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2024-01-03 18:48 ` Rob Herring
2024-01-03 18:48 ` Rob Herring
2024-01-03 18:48 ` Rob Herring
2024-01-17 14:01 ` Alexander Graf
2024-01-17 14:01 ` Alexander Graf
2024-01-17 14:01 ` Alexander Graf
2024-01-17 16:54 ` Rob Herring
2024-01-17 16:54 ` Rob Herring
2024-01-17 16:54 ` Rob Herring
2024-01-17 17:00 ` Alexander Graf
2024-01-17 17:00 ` Alexander Graf
2024-01-17 17:00 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 08/17] arm64: Add KHO support Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 09/17] x86: " Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 10/17] tracing: Initialize fields before registering Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 11/17] tracing: Introduce kho serialization Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 12/17] tracing: Add kho serialization of trace buffers Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 13/17] tracing: Recover trace buffers from kexec handover Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 14/17] tracing: Add kho serialization of trace events Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 15/17] tracing: Recover trace events from kexec handover Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 16/17] tracing: Add config option for " Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 19:51 ` Alexander Graf
2023-12-22 21:19 ` Rob Herring
2023-12-22 21:19 ` Rob Herring
2023-12-22 21:19 ` Rob Herring
2023-12-23 14:30 ` Krzysztof Kozlowski
2023-12-23 14:30 ` Krzysztof Kozlowski
2023-12-23 14:30 ` Krzysztof Kozlowski
2023-12-23 23:20 ` Alexander Graf
2023-12-23 23:20 ` Alexander Graf
2023-12-23 23:20 ` Alexander Graf
2023-12-24 8:58 ` Krzysztof Kozlowski
2023-12-24 8:58 ` Krzysztof Kozlowski
2023-12-24 8:58 ` Krzysztof Kozlowski
2024-01-02 14:53 ` Rob Herring
2024-01-02 14:53 ` Rob Herring
2024-01-02 14:53 ` Rob Herring
2024-01-02 15:20 ` Rob Herring [this message]
2024-01-02 15:20 ` Rob Herring
2024-01-02 15:20 ` Rob Herring
2024-01-17 13:56 ` Alexander Graf
2024-01-17 13:56 ` Alexander Graf
2024-01-17 13:56 ` Alexander Graf
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=20240102152023.GA2821956-robh@kernel.org \
--to=robh@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=ashish.kalra@amd.com \
--cc=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=ebiederm@xmission.com \
--cc=graf@amazon.com \
--cc=hpa@zytor.com \
--cc=jgowans@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mark.rutland@arm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=skinsburskii@linux.microsoft.com \
--cc=thomas.lendacky@amd.com \
--cc=usama.arif@bytedance.com \
--cc=x86@kernel.org \
/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 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.