| Message ID | 1687955688-20809-9-git-send-email-quic_mojha@quicinc.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [v4,01/21] docs: qcom: Add qualcomm minidump guide | expand |
On Wed, Jun 28, 2023 at 06:04:35PM +0530, Mukesh Ojha wrote: > Qualcomm ramoops minidump logger provide a means of storing > the ramoops data to some dynamically reserved memory instead > of traditionally implemented ramoops where the region should > be statically fixed ram region. Its device tree binding > would be exactly same as ramoops device tree binding and is > going to contain traditional ramoops frontend data and this > content will be collected via Qualcomm minidump infrastructure > provided from the boot firmware. > > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > --- > .../devicetree/bindings/soc/qcom/qcom,ramoops.yaml | 126 +++++++++++++++++++++ > 1 file changed, 126 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > new file mode 100644 > index 000000000000..b1fdcf3f8ad4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > @@ -0,0 +1,126 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/soc/qcom/qcom,ramoops.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Qualcomm Ramoops minidump logger > + > +description: | > + Qualcomm ramoops minidump logger provide a means of storing the ramoops > + data to some dynamically reserved memory instead of traditionally > + implemented ramoops where the region should be statically fixed ram > + region. Because of its similarity with ramoops it will also have same > + set of property what ramoops have it in its schema and is going to > + contain traditional ramoops frontend data and this region will be > + collected via Qualcomm minidump infrastructure provided from the > + boot firmware. > + > +maintainers: > + - Mukesh Ojha <quic_mojha@quicinc.com> > + > +properties: > + compatible: > + items: > + - enum: > + - qcom,sm8450-ramoops > + - const: qcom,ramoops > + > + memory-region: > + maxItems: 1 > + description: handle to memory reservation for qcom,ramoops region. > + > + ecc-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: enables ECC support and specifies ECC buffer size in bytes > + default: 0 # no ECC > + > + record-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: maximum size in bytes of each kmsg dump > + default: 0 > + > + console-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: size in bytes of log buffer reserved for kernel messages > + default: 0 > + > + ftrace-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: size in bytes of log buffer reserved for function tracing and profiling > + default: 0 > + > + pmsg-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: size in bytes of log buffer reserved for userspace messages > + default: 0 > + > + mem-type: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: if present, sets the type of mapping is to be used to map the reserved region. > + default: 0 > + oneOf: > + - const: 0 > + description: write-combined > + - const: 1 > + description: unbuffered > + - const: 2 > + description: cached > + > + max-reason: > + $ref: /schemas/types.yaml#/definitions/uint32 > + default: 2 # log oopses and panics > + maximum: 0x7fffffff > + description: | > + If present, sets maximum type of kmsg dump reasons to store. > + This can be set to INT_MAX to store all kmsg dumps. > + See include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump reason values. > + Setting this to 0 (KMSG_DUMP_UNDEF), means the reason filtering will be > + controlled by the printk.always_kmsg_dump boot param. > + If unset, it will be 2 (KMSG_DUMP_OOPS), otherwise 5 (KMSG_DUMP_MAX). > + > + flags: > + $ref: /schemas/types.yaml#/definitions/uint32 > + default: 0 > + description: | > + If present, pass ramoops behavioral flags > + (see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). > + > + no-dump-oops: > + deprecated: true > + type: boolean > + description: | > + Use max_reason instead. If present, and max_reason is not specified, > + it is equivalent to max_reason = 1 (KMSG_DUMP_PANIC). > + > + unbuffered: > + deprecated: true > + type: boolean > + description: | > + Use mem_type instead. If present, and mem_type is not specified, > + it is equivalent to mem_type = 1 and uses unbuffered mappings to map > + the reserved region (defaults to buffered mappings mem_type = 0). > + If both are specified -- "mem_type" overrides "unbuffered". > + Most of the properties you added here are already documented at Documentation/devicetree/bindings/reserved-memory/ramoops.yaml Can't we just reference them here? would something like work? max-reason: $ref: "../../reserved-memory/ramoops.yaml#/properties/max-reason > +unevaluatedProperties: false > + will there be any additional properties be added dynamically? if not, should not we use "additionalProperties: false" here? Thanks, Pavan
On Wed, Jun 28, 2023 at 6:36 AM Mukesh Ojha <quic_mojha@quicinc.com> wrote: > > Qualcomm ramoops minidump logger provide a means of storing > the ramoops data to some dynamically reserved memory instead > of traditionally implemented ramoops where the region should > be statically fixed ram region. Its device tree binding > would be exactly same as ramoops device tree binding and is > going to contain traditional ramoops frontend data and this > content will be collected via Qualcomm minidump infrastructure > provided from the boot firmware. The big difference is if firmware is not deciding where this log lives, then it doesn't need to be in DT. How does anything except the kernel that allocates the log find the logs? I'm pretty sure I already said all this before. > > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > --- > .../devicetree/bindings/soc/qcom/qcom,ramoops.yaml | 126 +++++++++++++++++++++ > 1 file changed, 126 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > new file mode 100644 > index 000000000000..b1fdcf3f8ad4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > @@ -0,0 +1,126 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/soc/qcom/qcom,ramoops.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Qualcomm Ramoops minidump logger > + > +description: | > + Qualcomm ramoops minidump logger provide a means of storing the ramoops > + data to some dynamically reserved memory instead of traditionally > + implemented ramoops where the region should be statically fixed ram > + region. Because of its similarity with ramoops it will also have same > + set of property what ramoops have it in its schema and is going to > + contain traditional ramoops frontend data and this region will be > + collected via Qualcomm minidump infrastructure provided from the > + boot firmware. > + > +maintainers: > + - Mukesh Ojha <quic_mojha@quicinc.com> > + > +properties: > + compatible: > + items: > + - enum: > + - qcom,sm8450-ramoops > + - const: qcom,ramoops > + > + memory-region: > + maxItems: 1 > + description: handle to memory reservation for qcom,ramoops region. > + > + ecc-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: enables ECC support and specifies ECC buffer size in bytes > + default: 0 # no ECC > + > + record-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: maximum size in bytes of each kmsg dump > + default: 0 > + > + console-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: size in bytes of log buffer reserved for kernel messages > + default: 0 > + > + ftrace-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: size in bytes of log buffer reserved for function tracing and profiling > + default: 0 > + > + pmsg-size: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: size in bytes of log buffer reserved for userspace messages > + default: 0 > + > + mem-type: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: if present, sets the type of mapping is to be used to map the reserved region. > + default: 0 > + oneOf: > + - const: 0 > + description: write-combined > + - const: 1 > + description: unbuffered > + - const: 2 > + description: cached > + > + max-reason: > + $ref: /schemas/types.yaml#/definitions/uint32 > + default: 2 # log oopses and panics > + maximum: 0x7fffffff > + description: | > + If present, sets maximum type of kmsg dump reasons to store. > + This can be set to INT_MAX to store all kmsg dumps. > + See include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump reason values. > + Setting this to 0 (KMSG_DUMP_UNDEF), means the reason filtering will be > + controlled by the printk.always_kmsg_dump boot param. > + If unset, it will be 2 (KMSG_DUMP_OOPS), otherwise 5 (KMSG_DUMP_MAX). > + > + flags: > + $ref: /schemas/types.yaml#/definitions/uint32 > + default: 0 > + description: | > + If present, pass ramoops behavioral flags > + (see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). > + > + no-dump-oops: > + deprecated: true Why would you define deprecated properties in a *new* binding? > + type: boolean > + description: | > + Use max_reason instead. If present, and max_reason is not specified, > + it is equivalent to max_reason = 1 (KMSG_DUMP_PANIC). > + > + unbuffered: > + deprecated: true > + type: boolean > + description: | > + Use mem_type instead. If present, and mem_type is not specified, > + it is equivalent to mem_type = 1 and uses unbuffered mappings to map > + the reserved region (defaults to buffered mappings mem_type = 0). > + If both are specified -- "mem_type" overrides "unbuffered". > + > +unevaluatedProperties: false > + > +required: > + - compatible > + - memory-region > + > +anyOf: > + - required: [record-size] > + - required: [console-size] > + - required: [ftrace-size] > + - required: [pmsg-size] > + > +examples: > + - | > + > + qcom_ramoops { > + compatible = "qcom,sm8450-ramoops", "qcom,ramoops"; > + memory-region = <&qcom_ramoops_region>; > + console-size = <0x8000>; /* 32kB */ > + record-size = <0x400>; /* 1kB */ > + ecc-size = <16>; > + }; > -- > 2.7.4 >
On 6/28/2023 8:17 PM, Rob Herring wrote: > On Wed, Jun 28, 2023 at 6:36 AM Mukesh Ojha <quic_mojha@quicinc.com> wrote: >> >> Qualcomm ramoops minidump logger provide a means of storing >> the ramoops data to some dynamically reserved memory instead >> of traditionally implemented ramoops where the region should >> be statically fixed ram region. Its device tree binding >> would be exactly same as ramoops device tree binding and is >> going to contain traditional ramoops frontend data and this >> content will be collected via Qualcomm minidump infrastructure >> provided from the boot firmware. > > The big difference is if firmware is not deciding where this log > lives, then it doesn't need to be in DT. How does anything except the > kernel that allocates the log find the logs? Yes, you are correct, firmware is not deciding where the logs lives instead here, Kernel has reserved the region where the ramoops region lives and later with the minidump registration where, physical address/size/virtual address(for parsing) are passed and that is how firmware is able to know and dump those region before triggering system reset. A part of this registration code you can find in 11/21 > I'm pretty sure I already said all this before. Yes, you said this before but that's the reason i came up with vendor ramoops instead of changing traditional ramoops binding. > >> >> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> >> --- >> .../devicetree/bindings/soc/qcom/qcom,ramoops.yaml | 126 +++++++++++++++++++++ >> 1 file changed, 126 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml >> >> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml >> new file mode 100644 >> index 000000000000..b1fdcf3f8ad4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml >> @@ -0,0 +1,126 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: "http://devicetree.org/schemas/soc/qcom/qcom,ramoops.yaml#" >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#" >> + >> +title: Qualcomm Ramoops minidump logger >> + >> +description: | >> + Qualcomm ramoops minidump logger provide a means of storing the ramoops >> + data to some dynamically reserved memory instead of traditionally >> + implemented ramoops where the region should be statically fixed ram >> + region. Because of its similarity with ramoops it will also have same >> + set of property what ramoops have it in its schema and is going to >> + contain traditional ramoops frontend data and this region will be >> + collected via Qualcomm minidump infrastructure provided from the >> + boot firmware. >> + >> +maintainers: >> + - Mukesh Ojha <quic_mojha@quicinc.com> >> + >> +properties: >> + compatible: >> + items: >> + - enum: >> + - qcom,sm8450-ramoops >> + - const: qcom,ramoops >> + >> + memory-region: >> + maxItems: 1 >> + description: handle to memory reservation for qcom,ramoops region. >> + >> + ecc-size: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: enables ECC support and specifies ECC buffer size in bytes >> + default: 0 # no ECC >> + >> + record-size: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: maximum size in bytes of each kmsg dump >> + default: 0 >> + >> + console-size: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: size in bytes of log buffer reserved for kernel messages >> + default: 0 >> + >> + ftrace-size: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: size in bytes of log buffer reserved for function tracing and profiling >> + default: 0 >> + >> + pmsg-size: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: size in bytes of log buffer reserved for userspace messages >> + default: 0 >> + >> + mem-type: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: if present, sets the type of mapping is to be used to map the reserved region. >> + default: 0 >> + oneOf: >> + - const: 0 >> + description: write-combined >> + - const: 1 >> + description: unbuffered >> + - const: 2 >> + description: cached >> + >> + max-reason: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + default: 2 # log oopses and panics >> + maximum: 0x7fffffff >> + description: | >> + If present, sets maximum type of kmsg dump reasons to store. >> + This can be set to INT_MAX to store all kmsg dumps. >> + See include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump reason values. >> + Setting this to 0 (KMSG_DUMP_UNDEF), means the reason filtering will be >> + controlled by the printk.always_kmsg_dump boot param. >> + If unset, it will be 2 (KMSG_DUMP_OOPS), otherwise 5 (KMSG_DUMP_MAX). >> + >> + flags: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + default: 0 >> + description: | >> + If present, pass ramoops behavioral flags >> + (see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). >> + >> + no-dump-oops: >> + deprecated: true > > Why would you define deprecated properties in a *new* binding? Since, it is exact copy of ramoops binding, that's the reason of mention. Will remove it. -Mukesh > >> + type: boolean >> + description: | >> + Use max_reason instead. If present, and max_reason is not specified, >> + it is equivalent to max_reason = 1 (KMSG_DUMP_PANIC). >> + >> + unbuffered: >> + deprecated: true >> + type: boolean >> + description: | >> + Use mem_type instead. If present, and mem_type is not specified, >> + it is equivalent to mem_type = 1 and uses unbuffered mappings to map >> + the reserved region (defaults to buffered mappings mem_type = 0). >> + If both are specified -- "mem_type" overrides "unbuffered". >> + >> +unevaluatedProperties: false >> + >> +required: >> + - compatible >> + - memory-region >> + >> +anyOf: >> + - required: [record-size] >> + - required: [console-size] >> + - required: [ftrace-size] >> + - required: [pmsg-size] >> + >> +examples: >> + - | >> + >> + qcom_ramoops { >> + compatible = "qcom,sm8450-ramoops", "qcom,ramoops"; >> + memory-region = <&qcom_ramoops_region>; >> + console-size = <0x8000>; /* 32kB */ >> + record-size = <0x400>; /* 1kB */ >> + ecc-size = <16>; >> + }; >> -- >> 2.7.4 >>
On Wed, Jun 28, 2023 at 8:11 AM Pavan Kondeti <quic_pkondeti@quicinc.com> wrote: > > On Wed, Jun 28, 2023 at 06:04:35PM +0530, Mukesh Ojha wrote: > > Qualcomm ramoops minidump logger provide a means of storing > > the ramoops data to some dynamically reserved memory instead > > of traditionally implemented ramoops where the region should > > be statically fixed ram region. Its device tree binding > > would be exactly same as ramoops device tree binding and is > > going to contain traditional ramoops frontend data and this > > content will be collected via Qualcomm minidump infrastructure > > provided from the boot firmware. > > > > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > > --- > > .../devicetree/bindings/soc/qcom/qcom,ramoops.yaml | 126 +++++++++++++++++++++ > > 1 file changed, 126 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > new file mode 100644 > > index 000000000000..b1fdcf3f8ad4 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > @@ -0,0 +1,126 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: "http://devicetree.org/schemas/soc/qcom/qcom,ramoops.yaml#" > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > > + > > +title: Qualcomm Ramoops minidump logger > > + > > +description: | > > + Qualcomm ramoops minidump logger provide a means of storing the ramoops > > + data to some dynamically reserved memory instead of traditionally > > + implemented ramoops where the region should be statically fixed ram > > + region. Because of its similarity with ramoops it will also have same > > + set of property what ramoops have it in its schema and is going to > > + contain traditional ramoops frontend data and this region will be > > + collected via Qualcomm minidump infrastructure provided from the > > + boot firmware. > > + > > +maintainers: > > + - Mukesh Ojha <quic_mojha@quicinc.com> > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - qcom,sm8450-ramoops > > + - const: qcom,ramoops > > + > > + memory-region: > > + maxItems: 1 > > + description: handle to memory reservation for qcom,ramoops region. > > + > > + ecc-size: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: enables ECC support and specifies ECC buffer size in bytes > > + default: 0 # no ECC > > + > > + record-size: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: maximum size in bytes of each kmsg dump > > + default: 0 > > + > > + console-size: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: size in bytes of log buffer reserved for kernel messages > > + default: 0 > > + > > + ftrace-size: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: size in bytes of log buffer reserved for function tracing and profiling > > + default: 0 > > + > > + pmsg-size: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: size in bytes of log buffer reserved for userspace messages > > + default: 0 > > + > > + mem-type: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: if present, sets the type of mapping is to be used to map the reserved region. > > + default: 0 > > + oneOf: > > + - const: 0 > > + description: write-combined > > + - const: 1 > > + description: unbuffered > > + - const: 2 > > + description: cached > > + > > + max-reason: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + default: 2 # log oopses and panics > > + maximum: 0x7fffffff > > + description: | > > + If present, sets maximum type of kmsg dump reasons to store. > > + This can be set to INT_MAX to store all kmsg dumps. > > + See include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump reason values. > > + Setting this to 0 (KMSG_DUMP_UNDEF), means the reason filtering will be > > + controlled by the printk.always_kmsg_dump boot param. > > + If unset, it will be 2 (KMSG_DUMP_OOPS), otherwise 5 (KMSG_DUMP_MAX). > > + > > + flags: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + default: 0 > > + description: | > > + If present, pass ramoops behavioral flags > > + (see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). > > + > > + no-dump-oops: > > + deprecated: true > > + type: boolean > > + description: | > > + Use max_reason instead. If present, and max_reason is not specified, > > + it is equivalent to max_reason = 1 (KMSG_DUMP_PANIC). > > + > > + unbuffered: > > + deprecated: true > > + type: boolean > > + description: | > > + Use mem_type instead. If present, and mem_type is not specified, > > + it is equivalent to mem_type = 1 and uses unbuffered mappings to map > > + the reserved region (defaults to buffered mappings mem_type = 0). > > + If both are specified -- "mem_type" overrides "unbuffered". > > + > > Most of the properties you added here are already documented at > Documentation/devicetree/bindings/reserved-memory/ramoops.yaml That is certainly a problem. Don't define the same property more than once. Not yet checked and enforced by the tools, but it will be. > Can't we just reference them here? would something like work? > > max-reason: > $ref: "../../reserved-memory/ramoops.yaml#/properties/max-reason Can work, but no. Common properties need to go into a schema of common properties which the device specific schemas reference. > > > +unevaluatedProperties: false > > + > > will there be any additional properties be added dynamically? if not, > should not we use "additionalProperties: false" here? I don't know what you mean by dynamically, but that's not the criteria for which to use. Rob
On Wed, Jun 28, 2023 at 05:17:13PM -0600, Rob Herring wrote: > On Wed, Jun 28, 2023 at 8:11 AM Pavan Kondeti <quic_pkondeti@quicinc.com> wrote: > > > > On Wed, Jun 28, 2023 at 06:04:35PM +0530, Mukesh Ojha wrote: > > > Qualcomm ramoops minidump logger provide a means of storing > > > the ramoops data to some dynamically reserved memory instead > > > of traditionally implemented ramoops where the region should > > > be statically fixed ram region. Its device tree binding > > > would be exactly same as ramoops device tree binding and is > > > going to contain traditional ramoops frontend data and this > > > content will be collected via Qualcomm minidump infrastructure > > > provided from the boot firmware. > > > > > > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > > > --- > > > .../devicetree/bindings/soc/qcom/qcom,ramoops.yaml | 126 +++++++++++++++++++++ > > > 1 file changed, 126 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > > new file mode 100644 > > > index 000000000000..b1fdcf3f8ad4 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml > > > @@ -0,0 +1,126 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: "http://devicetree.org/schemas/soc/qcom/qcom,ramoops.yaml#" > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > > > + > > > +title: Qualcomm Ramoops minidump logger > > > + > > > +description: | > > > + Qualcomm ramoops minidump logger provide a means of storing the ramoops > > > + data to some dynamically reserved memory instead of traditionally > > > + implemented ramoops where the region should be statically fixed ram > > > + region. Because of its similarity with ramoops it will also have same > > > + set of property what ramoops have it in its schema and is going to > > > + contain traditional ramoops frontend data and this region will be > > > + collected via Qualcomm minidump infrastructure provided from the > > > + boot firmware. > > > + > > > +maintainers: > > > + - Mukesh Ojha <quic_mojha@quicinc.com> > > > + > > > +properties: > > > + compatible: > > > + items: > > > + - enum: > > > + - qcom,sm8450-ramoops > > > + - const: qcom,ramoops > > > + > > > + memory-region: > > > + maxItems: 1 > > > + description: handle to memory reservation for qcom,ramoops region. > > > + > > > + ecc-size: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: enables ECC support and specifies ECC buffer size in bytes > > > + default: 0 # no ECC > > > + > > > + record-size: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: maximum size in bytes of each kmsg dump > > > + default: 0 > > > + > > > + console-size: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: size in bytes of log buffer reserved for kernel messages > > > + default: 0 > > > + > > > + ftrace-size: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: size in bytes of log buffer reserved for function tracing and profiling > > > + default: 0 > > > + > > > + pmsg-size: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: size in bytes of log buffer reserved for userspace messages > > > + default: 0 > > > + > > > + mem-type: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: if present, sets the type of mapping is to be used to map the reserved region. > > > + default: 0 > > > + oneOf: > > > + - const: 0 > > > + description: write-combined > > > + - const: 1 > > > + description: unbuffered > > > + - const: 2 > > > + description: cached > > > + > > > + max-reason: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + default: 2 # log oopses and panics > > > + maximum: 0x7fffffff > > > + description: | > > > + If present, sets maximum type of kmsg dump reasons to store. > > > + This can be set to INT_MAX to store all kmsg dumps. > > > + See include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump reason values. > > > + Setting this to 0 (KMSG_DUMP_UNDEF), means the reason filtering will be > > > + controlled by the printk.always_kmsg_dump boot param. > > > + If unset, it will be 2 (KMSG_DUMP_OOPS), otherwise 5 (KMSG_DUMP_MAX). > > > + > > > + flags: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + default: 0 > > > + description: | > > > + If present, pass ramoops behavioral flags > > > + (see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). > > > + > > > + no-dump-oops: > > > + deprecated: true > > > + type: boolean > > > + description: | > > > + Use max_reason instead. If present, and max_reason is not specified, > > > + it is equivalent to max_reason = 1 (KMSG_DUMP_PANIC). > > > + > > > + unbuffered: > > > + deprecated: true > > > + type: boolean > > > + description: | > > > + Use mem_type instead. If present, and mem_type is not specified, > > > + it is equivalent to mem_type = 1 and uses unbuffered mappings to map > > > + the reserved region (defaults to buffered mappings mem_type = 0). > > > + If both are specified -- "mem_type" overrides "unbuffered". > > > + > > > > Most of the properties you added here are already documented at > > Documentation/devicetree/bindings/reserved-memory/ramoops.yaml > > That is certainly a problem. Don't define the same property more than > once. Not yet checked and enforced by the tools, but it will be. > > > Can't we just reference them here? would something like work? > > > > max-reason: > > $ref: "../../reserved-memory/ramoops.yaml#/properties/max-reason > > Can work, but no. Common properties need to go into a schema of common > properties which the device specific schemas reference. > Thanks for the clarification. We need to define the common properties and make it available under /schemas/<>.yaml and add a reference to it in these bindings. Is my understanding correct? > > > > > +unevaluatedProperties: false > > > + > > > > will there be any additional properties be added dynamically? if not, > > should not we use "additionalProperties: false" here? > > I don't know what you mean by dynamically, but that's not the criteria > for which to use. > ok, I was wrong in saying dynamically. I should say "are there any other properties that will be included that are not documented here". is below my understanding correct? additionalProperties needs to be set to false if at all this binding defines all the possible properties (including child nodes) and not referring to any other schemas. If that is not the case and this binding references to other schemas, then unevaluatedProperties could be used since additionalProperties can't support combining schemas. Thanks, Pavan
On 28/06/2023 17:01, Mukesh Ojha wrote: > > > On 6/28/2023 8:17 PM, Rob Herring wrote: >> On Wed, Jun 28, 2023 at 6:36 AM Mukesh Ojha <quic_mojha@quicinc.com> wrote: >>> >>> Qualcomm ramoops minidump logger provide a means of storing >>> the ramoops data to some dynamically reserved memory instead >>> of traditionally implemented ramoops where the region should >>> be statically fixed ram region. Its device tree binding >>> would be exactly same as ramoops device tree binding and is >>> going to contain traditional ramoops frontend data and this >>> content will be collected via Qualcomm minidump infrastructure >>> provided from the boot firmware. >> >> The big difference is if firmware is not deciding where this log >> lives, then it doesn't need to be in DT. How does anything except the >> kernel that allocates the log find the logs? > > Yes, you are correct, firmware is not deciding where the logs lives > instead here, Kernel has reserved the region where the ramoops region > lives and later with the minidump registration where, physical > address/size/virtual address(for parsing) are passed and that is how > firmware is able to know and dump those region before triggering system > reset. Your explanation does not justify storing all this in DT. Kernel can allocate any memory it wishes, store there logs and pass the address to the firmware. That's it, no need for DT. > > A part of this registration code you can find in 11/21 > >> I'm pretty sure I already said all this before. > > Yes, you said this before but that's the reason i came up with vendor > ramoops instead of changing traditional ramoops binding. That's unexpected conclusion. Adding more bindings is not the answer to comment that it should not be in the DTS in the first place. Best regards, Krzysztof
On 7/2/2023 1:42 PM, Krzysztof Kozlowski wrote: > On 28/06/2023 17:01, Mukesh Ojha wrote: >> >> >> On 6/28/2023 8:17 PM, Rob Herring wrote: >>> On Wed, Jun 28, 2023 at 6:36 AM Mukesh Ojha <quic_mojha@quicinc.com> wrote: >>>> >>>> Qualcomm ramoops minidump logger provide a means of storing >>>> the ramoops data to some dynamically reserved memory instead >>>> of traditionally implemented ramoops where the region should >>>> be statically fixed ram region. Its device tree binding >>>> would be exactly same as ramoops device tree binding and is >>>> going to contain traditional ramoops frontend data and this >>>> content will be collected via Qualcomm minidump infrastructure >>>> provided from the boot firmware. >>> >>> The big difference is if firmware is not deciding where this log >>> lives, then it doesn't need to be in DT. How does anything except the >>> kernel that allocates the log find the logs? >> >> Yes, you are correct, firmware is not deciding where the logs lives >> instead here, Kernel has reserved the region where the ramoops region >> lives and later with the minidump registration where, physical >> address/size/virtual address(for parsing) are passed and that is how >> firmware is able to know and dump those region before triggering system >> reset. > > Your explanation does not justify storing all this in DT. Kernel can > allocate any memory it wishes, store there logs and pass the address to > the firmware. That's it, no need for DT. If you go through the driver, you will know that what it does, is just create platform device for actual ramoops driver to probe and to provide this it needs exact set of parameters of input what original ramoops DT provides, we need to keep it in DT as maintaining this in driver will not scale well with different size/parameter size requirement for different targets. > >> >> A part of this registration code you can find in 11/21 >> >>> I'm pretty sure I already said all this before. >> >> Yes, you said this before but that's the reason i came up with vendor >> ramoops instead of changing traditional ramoops binding. > > That's unexpected conclusion. Adding more bindings is not the answer to > comment that it should not be in the DTS in the first place. Please suggest, what is the other way being above text as requirement.. -- Mukesh > > Best regards, > Krzysztof >
On Mon, 3 Jul 2023 at 08:22, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > On 7/2/2023 1:42 PM, Krzysztof Kozlowski wrote: > >>> The big difference is if firmware is not deciding where this log > >>> lives, then it doesn't need to be in DT. How does anything except the > >>> kernel that allocates the log find the logs? > >> > >> Yes, you are correct, firmware is not deciding where the logs lives > >> instead here, Kernel has reserved the region where the ramoops region > >> lives and later with the minidump registration where, physical > >> address/size/virtual address(for parsing) are passed and that is how > >> firmware is able to know and dump those region before triggering system > >> reset. > > > > Your explanation does not justify storing all this in DT. Kernel can > > allocate any memory it wishes, store there logs and pass the address to > > the firmware. That's it, no need for DT. > > If you go through the driver, you will know that what it does, is We talk about bindings and I should not be forced to look at the driver to be able to understand them. Bindings should stand on their own. > just create platform device for actual ramoops driver to probe and to Not really justification for Devicetree anyway. Whatever your driver is doing, is driver's business, not bindings. > provide this it needs exact set of parameters of input what original > ramoops DT provides, we need to keep it in DT as maintaining this in > driver will not scale well with different size/parameter size > requirement for different targets. Really? Why? I don't see a problem in scaling. At all. > > > > >> > >> A part of this registration code you can find in 11/21 > >> > >>> I'm pretty sure I already said all this before. > >> > >> Yes, you said this before but that's the reason i came up with vendor > >> ramoops instead of changing traditional ramoops binding. > > > > That's unexpected conclusion. Adding more bindings is not the answer to > > comment that it should not be in the DTS in the first place. > > Please suggest, what is the other way being above text as requirement.. I do not see any requirement for us there. Forcing me to figure out how to add non-hardware property to DT is not the way to convince reviewers. But if you insist - we have ABI for this, called sysfs. If it is debugging feature, then debugfs. Best regards, Krzysztof
On 7/3/2023 12:50 PM, Krzysztof Kozlowski wrote: > On Mon, 3 Jul 2023 at 08:22, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >> On 7/2/2023 1:42 PM, Krzysztof Kozlowski wrote: >>>>> The big difference is if firmware is not deciding where this log >>>>> lives, then it doesn't need to be in DT. How does anything except the >>>>> kernel that allocates the log find the logs? >>>> >>>> Yes, you are correct, firmware is not deciding where the logs lives >>>> instead here, Kernel has reserved the region where the ramoops region >>>> lives and later with the minidump registration where, physical >>>> address/size/virtual address(for parsing) are passed and that is how >>>> firmware is able to know and dump those region before triggering system >>>> reset. >>> >>> Your explanation does not justify storing all this in DT. Kernel can >>> allocate any memory it wishes, store there logs and pass the address to >>> the firmware. That's it, no need for DT. >> >> If you go through the driver, you will know that what it does, is > > We talk about bindings and I should not be forced to look at the > driver to be able to understand them. Bindings should stand on their > own. Why can't ramoops binding have one more feature where it can add a flag *dynamic* to indicate the regions are dynamic and it is for platforms where there is another entity 'minidump' who is interested in these regions. > >> just create platform device for actual ramoops driver to probe and to > > Not really justification for Devicetree anyway. Whatever your driver > is doing, is driver's business, not bindings. > >> provide this it needs exact set of parameters of input what original >> ramoops DT provides, we need to keep it in DT as maintaining this in >> driver will not scale well with different size/parameter size >> requirement for different targets. > > Really? Why? I don't see a problem in scaling. At all. I had attempted it here, https://lore.kernel.org/lkml/1683133352-10046-10-git-send-email-quic_mojha@quicinc.com/ but got comments related to hard coding and some in favor of having the same set of properties what ramoops has/provides https://lore.kernel.org/lkml/e25723bf-be85-b458-a84c-1a45392683bb@gmail.com/ https://lore.kernel.org/lkml/202305161347.80204C1A0E@keescook/ > >> >>> >>>> >>>> A part of this registration code you can find in 11/21 >>>> >>>>> I'm pretty sure I already said all this before. >>>> >>>> Yes, you said this before but that's the reason i came up with vendor >>>> ramoops instead of changing traditional ramoops binding. >>> >>> That's unexpected conclusion. Adding more bindings is not the answer to >>> comment that it should not be in the DTS in the first place. >> >> Please suggest, what is the other way being above text as requirement.. > > I do not see any requirement for us there. Forcing me to figure out > how to add non-hardware property to DT is not the way to convince > reviewers. But if you insist - we have ABI for this, called sysfs. If > it is debugging feature, then debugfs. ramoops already support module params and a way to pass these parameters from bootargs but it also need to know the hard-codes addresses, so, doing something in sysfs will be again duplication with ramoops driver.. If this can be accommodated under ramoops, this will be very small change, like this https://lore.kernel.org/lkml/20230622005213.458236-1-isaacmanjarres@google.com/ -- Mukesh > > Best regards, > Krzysztof
On 03/07/2023 17:55, Mukesh Ojha wrote: > > > On 7/3/2023 12:50 PM, Krzysztof Kozlowski wrote: >> On Mon, 3 Jul 2023 at 08:22, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >>> On 7/2/2023 1:42 PM, Krzysztof Kozlowski wrote: >>>>>> The big difference is if firmware is not deciding where this log >>>>>> lives, then it doesn't need to be in DT. How does anything except the >>>>>> kernel that allocates the log find the logs? >>>>> >>>>> Yes, you are correct, firmware is not deciding where the logs lives >>>>> instead here, Kernel has reserved the region where the ramoops region >>>>> lives and later with the minidump registration where, physical >>>>> address/size/virtual address(for parsing) are passed and that is how >>>>> firmware is able to know and dump those region before triggering system >>>>> reset. >>>> >>>> Your explanation does not justify storing all this in DT. Kernel can >>>> allocate any memory it wishes, store there logs and pass the address to >>>> the firmware. That's it, no need for DT. >>> >>> If you go through the driver, you will know that what it does, is >> >> We talk about bindings and I should not be forced to look at the >> driver to be able to understand them. Bindings should stand on their >> own. > > Why can't ramoops binding have one more feature where it can add a flag > *dynamic* to indicate the regions are dynamic and it is for platforms > where there is another entity 'minidump' who is interested in these > regions. Because we do not define dynamic stuff in Devicetree. Dynamic means defined by SW or runtime configurable. It is against the entire idea of Devicetree which is for non-discoverable hardware. > >> >>> just create platform device for actual ramoops driver to probe and to >> >> Not really justification for Devicetree anyway. Whatever your driver >> is doing, is driver's business, not bindings. >> >>> provide this it needs exact set of parameters of input what original >>> ramoops DT provides, we need to keep it in DT as maintaining this in >>> driver will not scale well with different size/parameter size >>> requirement for different targets. >> >> Really? Why? I don't see a problem in scaling. At all. > > I had attempted it here, > > https://lore.kernel.org/lkml/1683133352-10046-10-git-send-email-quic_mojha@quicinc.com/ > > but got comments related to hard coding and some in favor of having > the same set of properties what ramoops has/provides > > https://lore.kernel.org/lkml/e25723bf-be85-b458-a84c-1a45392683bb@gmail.com/ > > https://lore.kernel.org/lkml/202305161347.80204C1A0E@keescook/ Then you were tricked. I don't get why someone else suggests that non-hardware property should be part of Devicetree, but anyway it's the call of Devicetree binding maintainers, not someone else. DT is not dumping ground for all the system configuration variables. >> >>> >>>> >>>>> >>>>> A part of this registration code you can find in 11/21 >>>>> >>>>>> I'm pretty sure I already said all this before. >>>>> >>>>> Yes, you said this before but that's the reason i came up with vendor >>>>> ramoops instead of changing traditional ramoops binding. >>>> >>>> That's unexpected conclusion. Adding more bindings is not the answer to >>>> comment that it should not be in the DTS in the first place. >>> >>> Please suggest, what is the other way being above text as requirement.. >> >> I do not see any requirement for us there. Forcing me to figure out >> how to add non-hardware property to DT is not the way to convince >> reviewers. But if you insist - we have ABI for this, called sysfs. If >> it is debugging feature, then debugfs. > > ramoops already support module params and a way to pass these parameters > from bootargs but it also need to know the hard-codes addresses, so, > doing something in sysfs will be again duplication with ramoops driver.. Why do you need hard-coded addresses? > > If this can be accommodated under ramoops, this will be very small > change, like this > > https://lore.kernel.org/lkml/20230622005213.458236-1-isaacmanjarres@google.com/ That's also funny patch - missing bindings updated, missing CC DT maintainers. Best regards, Krzysztof
On 04/07/23 07:57, Krzysztof Kozlowski wrote: > On 03/07/2023 17:55, Mukesh Ojha wrote: >> >> On 7/3/2023 12:50 PM, Krzysztof Kozlowski wrote: >>> On Mon, 3 Jul 2023 at 08:22, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >>>> On 7/2/2023 1:42 PM, Krzysztof Kozlowski wrote: >>>>>>> The big difference is if firmware is not deciding where this log >>>>>>> lives, then it doesn't need to be in DT. How does anything except the >>>>>>> kernel that allocates the log find the logs? >>>>>> Yes, you are correct, firmware is not deciding where the logs lives >>>>>> instead here, Kernel has reserved the region where the ramoops region >>>>>> lives and later with the minidump registration where, physical >>>>>> address/size/virtual address(for parsing) are passed and that is how >>>>>> firmware is able to know and dump those region before triggering system >>>>>> reset. >>>>> Your explanation does not justify storing all this in DT. Kernel can >>>>> allocate any memory it wishes, store there logs and pass the address to >>>>> the firmware. That's it, no need for DT. >>>> If you go through the driver, you will know that what it does, is >>> We talk about bindings and I should not be forced to look at the >>> driver to be able to understand them. Bindings should stand on their >>> own. >> Why can't ramoops binding have one more feature where it can add a flag >> *dynamic* to indicate the regions are dynamic and it is for platforms >> where there is another entity 'minidump' who is interested in these >> regions. > Because we do not define dynamic stuff in Devicetree. Dynamic means > defined by SW or runtime configurable. It is against the entire idea of > Devicetree which is for non-discoverable hardware. > >>>> just create platform device for actual ramoops driver to probe and to >>> Not really justification for Devicetree anyway. Whatever your driver >>> is doing, is driver's business, not bindings. >>> >>>> provide this it needs exact set of parameters of input what original >>>> ramoops DT provides, we need to keep it in DT as maintaining this in >>>> driver will not scale well with different size/parameter size >>>> requirement for different targets. >>> Really? Why? I don't see a problem in scaling. At all. >> I had attempted it here, >> >> https://lore.kernel.org/lkml/1683133352-10046-10-git-send-email-quic_mojha@quicinc.com/ >> >> but got comments related to hard coding and some in favor of having >> the same set of properties what ramoops has/provides >> >> https://lore.kernel.org/lkml/e25723bf-be85-b458-a84c-1a45392683bb@gmail.com/ >> >> https://lore.kernel.org/lkml/202305161347.80204C1A0E@keescook/ > Then you were tricked. I don't get why someone else suggests that > non-hardware property should be part of Devicetree, but anyway it's the > call of Devicetree binding maintainers, not someone else. DT is not > dumping ground for all the system configuration variables. Sorry for that, I assumed the interface should be as close as possible to pstore, but apparently that's not the case. Why does it have to be different from it? It provides the same functionality and is configurable even if it doesn't explicitly configure non discoverable hardware properties. Assuming we make the driver picks the values, how would it do that? Hardcoding a configuration could lead to a few problems, such as the allocated region being smaller than the driver defaults or driver defaults not fully utilizing the allocated region, possibly wasting more memory than it'll ever use. On top of that what happens if we want to configure it differently than the hardcoded default values? Via cmdline options? For example in the previous version it allocated the whole region for the console alone, while other entries, such as pmsg that could be useful on devices using minidump to store Android logs, was zero-sized. > >>>>>> A part of this registration code you can find in 11/21 >>>>>> >>>>>>> I'm pretty sure I already said all this before. >>>>>> Yes, you said this before but that's the reason i came up with vendor >>>>>> ramoops instead of changing traditional ramoops binding. >>>>> That's unexpected conclusion. Adding more bindings is not the answer to >>>>> comment that it should not be in the DTS in the first place. >>>> Please suggest, what is the other way being above text as requirement.. >>> I do not see any requirement for us there. Forcing me to figure out >>> how to add non-hardware property to DT is not the way to convince >>> reviewers. But if you insist - we have ABI for this, called sysfs. If >>> it is debugging feature, then debugfs. >> ramoops already support module params and a way to pass these parameters >> from bootargs but it also need to know the hard-codes addresses, so, >> doing something in sysfs will be again duplication with ramoops driver.. > Why do you need hard-coded addresses? > >> If this can be accommodated under ramoops, this will be very small >> change, like this >> >> https://lore.kernel.org/lkml/20230622005213.458236-1-isaacmanjarres@google.com/ > That's also funny patch - missing bindings updated, missing CC DT > maintainers. > > Best regards, > Krzysztof > > >
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml new file mode 100644 index 000000000000..b1fdcf3f8ad4 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/qcom/qcom,ramoops.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Ramoops minidump logger + +description: | + Qualcomm ramoops minidump logger provide a means of storing the ramoops + data to some dynamically reserved memory instead of traditionally + implemented ramoops where the region should be statically fixed ram + region. Because of its similarity with ramoops it will also have same + set of property what ramoops have it in its schema and is going to + contain traditional ramoops frontend data and this region will be + collected via Qualcomm minidump infrastructure provided from the + boot firmware. + +maintainers: + - Mukesh Ojha <quic_mojha@quicinc.com> + +properties: + compatible: + items: + - enum: + - qcom,sm8450-ramoops + - const: qcom,ramoops + + memory-region: + maxItems: 1 + description: handle to memory reservation for qcom,ramoops region. + + ecc-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: enables ECC support and specifies ECC buffer size in bytes + default: 0 # no ECC + + record-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: maximum size in bytes of each kmsg dump + default: 0 + + console-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: size in bytes of log buffer reserved for kernel messages + default: 0 + + ftrace-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: size in bytes of log buffer reserved for function tracing and profiling + default: 0 + + pmsg-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: size in bytes of log buffer reserved for userspace messages + default: 0 + + mem-type: + $ref: /schemas/types.yaml#/definitions/uint32 + description: if present, sets the type of mapping is to be used to map the reserved region. + default: 0 + oneOf: + - const: 0 + description: write-combined + - const: 1 + description: unbuffered + - const: 2 + description: cached + + max-reason: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 2 # log oopses and panics + maximum: 0x7fffffff + description: | + If present, sets maximum type of kmsg dump reasons to store. + This can be set to INT_MAX to store all kmsg dumps. + See include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump reason values. + Setting this to 0 (KMSG_DUMP_UNDEF), means the reason filtering will be + controlled by the printk.always_kmsg_dump boot param. + If unset, it will be 2 (KMSG_DUMP_OOPS), otherwise 5 (KMSG_DUMP_MAX). + + flags: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: | + If present, pass ramoops behavioral flags + (see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). + + no-dump-oops: + deprecated: true + type: boolean + description: | + Use max_reason instead. If present, and max_reason is not specified, + it is equivalent to max_reason = 1 (KMSG_DUMP_PANIC). + + unbuffered: + deprecated: true + type: boolean + description: | + Use mem_type instead. If present, and mem_type is not specified, + it is equivalent to mem_type = 1 and uses unbuffered mappings to map + the reserved region (defaults to buffered mappings mem_type = 0). + If both are specified -- "mem_type" overrides "unbuffered". + +unevaluatedProperties: false + +required: + - compatible + - memory-region + +anyOf: + - required: [record-size] + - required: [console-size] + - required: [ftrace-size] + - required: [pmsg-size] + +examples: + - | + + qcom_ramoops { + compatible = "qcom,sm8450-ramoops", "qcom,ramoops"; + memory-region = <&qcom_ramoops_region>; + console-size = <0x8000>; /* 32kB */ + record-size = <0x400>; /* 1kB */ + ecc-size = <16>; + };
Qualcomm ramoops minidump logger provide a means of storing the ramoops data to some dynamically reserved memory instead of traditionally implemented ramoops where the region should be statically fixed ram region. Its device tree binding would be exactly same as ramoops device tree binding and is going to contain traditional ramoops frontend data and this content will be collected via Qualcomm minidump infrastructure provided from the boot firmware. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> --- .../devicetree/bindings/soc/qcom/qcom,ramoops.yaml | 126 +++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ramoops.yaml