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@xxxxxxxxxxx> > --- > .../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@xxxxxxxxxxx> > + > +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
