linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mukesh Ojha <quic_mojha@quicinc.com>
To: <corbet@lwn.net>, <agross@kernel.org>, <andersson@kernel.org>,
	<konrad.dybcio@linaro.org>, <robh+dt@kernel.org>,
	<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
	<keescook@chromium.org>, <tony.luck@intel.com>,
	<gpiccoli@igalia.com>, <mathieu.poirier@linaro.org>,
	<catalin.marinas@arm.com>, <will@kernel.org>,
	<linus.walleij@linaro.org>, <andy.shevchenko@gmail.com>
Cc: <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-hardening@vger.kernel.org>,
	<linux-remoteproc@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-gpio@vger.kernel.org>,
	"Mukesh Ojha" <quic_mojha@quicinc.com>
Subject: [PATCH v4 08/21] dt-bindings: reserved-memory: Add qcom,ramoops binding
Date: Wed, 28 Jun 2023 18:04:35 +0530	[thread overview]
Message-ID: <1687955688-20809-9-git-send-email-quic_mojha@quicinc.com> (raw)
In-Reply-To: <1687955688-20809-1-git-send-email-quic_mojha@quicinc.com>

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".
+
+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


  parent reply	other threads:[~2023-06-28 12:37 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 12:34 [PATCH v4 00/21] Add Qualcomm Minidump kernel driver related support Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 01/21] docs: qcom: Add qualcomm minidump guide Mukesh Ojha
2023-06-28 23:21   ` Rob Herring
2023-06-28 12:34 ` [PATCH v4 02/21] kallsyms: Export kallsyms_lookup_name Mukesh Ojha
2023-06-28 13:24   ` Andy Shevchenko
2023-06-28 15:04     ` Mukesh Ojha
2023-06-28 13:53   ` Pavan Kondeti
2023-06-28 15:22     ` Mukesh Ojha
2023-06-28 15:32       ` Will Deacon
2023-06-28 15:43         ` Greg KH
2023-06-28 12:34 ` [PATCH v4 03/21] soc: qcom: Add qcom_minidump_smem module Mukesh Ojha
2023-06-28 13:31   ` Andy Shevchenko
2023-06-28 15:47   ` Greg KH
2023-06-28 12:34 ` [PATCH v4 04/21] soc: qcom: Add Qualcomm APSS minidump (frontend) feature support Mukesh Ojha
2023-06-28 13:43   ` Andy Shevchenko
2023-06-29  2:33   ` Pavan Kondeti
2023-06-30  7:15     ` Mukesh Ojha
2023-06-30  8:38       ` Pavan Kondeti
2023-06-28 12:34 ` [PATCH v4 05/21] soc: qcom: Add linux minidump smem backend driver support Mukesh Ojha
2023-06-28 13:51   ` Andy Shevchenko
2023-06-28 12:34 ` [PATCH v4 06/21] soc: qcom: minidump: Add pending region registration support Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 07/21] soc: qcom: minidump: Add update region support Mukesh Ojha
2023-06-29  2:49   ` Pavan Kondeti
2023-06-28 12:34 ` Mukesh Ojha [this message]
2023-06-28 14:10   ` [PATCH v4 08/21] dt-bindings: reserved-memory: Add qcom,ramoops binding Pavan Kondeti
2023-06-28 23:17     ` Rob Herring
2023-06-29  1:45       ` Pavan Kondeti
2023-06-28 14:47   ` Rob Herring
2023-06-28 15:01     ` Mukesh Ojha
2023-07-02  8:12       ` Krzysztof Kozlowski
2023-07-03  6:21         ` Mukesh Ojha
2023-07-03  7:20           ` Krzysztof Kozlowski
2023-07-03 15:55             ` Mukesh Ojha
2023-07-04  5:57               ` Krzysztof Kozlowski
2023-07-19 10:29                 ` Luca Stefani
2023-06-28 12:34 ` [PATCH v4 09/21] pstore/ram : Export ramoops_parse_dt() symbol Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 10/21] soc: qcom: Add qcom's pstore minidump driver support Mukesh Ojha
2023-06-28 22:57   ` Rob Herring
2023-06-29  9:16     ` Mukesh Ojha
2023-07-05 23:27       ` Rob Herring
2023-06-28 12:34 ` [PATCH v4 11/21] soc: qcom: Register pstore frontend region with minidump Mukesh Ojha
2023-06-30  4:55   ` Pavan Kondeti
2023-06-30  9:25     ` Andy Shevchenko
2023-06-28 12:34 ` [PATCH v4 12/21] remoteproc: qcom: Expand MD_* as MINIDUMP_* Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 13/21] remoterproc: qcom: refactor to leverage exported minidump symbol Mukesh Ojha
2023-06-28 15:51   ` Pavan Kondeti
2023-06-29  9:20     ` Mukesh Ojha
2023-06-30  3:41       ` Pavan Kondeti
2023-06-28 12:34 ` [PATCH v4 14/21] MAINTAINERS: Add entry for minidump driver related support Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 15/21] arm64: defconfig: Enable Qualcomm Minidump related drivers Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 16/21] arm64: dts: qcom: sm8450: Add Qualcomm ramoops minidump node Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 17/21] firmware: qcom_scm: provide a read-modify-write function Mukesh Ojha
2023-06-30  5:01   ` Pavan Kondeti
2023-06-28 12:34 ` [PATCH v4 18/21] pinctrl: qcom: Use qcom_scm_io_update_field() Mukesh Ojha
2023-06-28 13:44   ` Andy Shevchenko
2023-06-30 14:58     ` Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 19/21] firmware: scm: Modify only the download bits in TCSR register Mukesh Ojha
2023-06-28 15:20   ` Konrad Dybcio
2023-06-30 14:57     ` Mukesh Ojha
2023-06-28 12:34 ` [PATCH v4 20/21] firmware: qcom_scm: Refactor code to support multiple download mode Mukesh Ojha
2023-06-30  5:25   ` Pavan Kondeti
2023-06-30  9:28     ` Andy Shevchenko
2023-06-28 12:34 ` [PATCH v4 21/21] firmware: qcom_scm: Add multiple download mode support Mukesh Ojha
2023-06-28 15:45 ` [PATCH v4 00/21] Add Qualcomm Minidump kernel driver related support Greg KH
2023-06-28 16:20   ` Mukesh Ojha
2023-06-28 16:53     ` Greg KH
2023-06-28 23:12   ` Rob Herring
2023-06-30 16:04     ` Mukesh Ojha
2023-07-02  8:29       ` Krzysztof Kozlowski
2023-07-03 21:05         ` Trilok Soni
2023-07-06 17:20           ` Mathieu Poirier
2023-07-18 15:03             ` Mukesh Ojha
2023-08-07 13:46               ` Mukesh Ojha
2023-07-06 17:40           ` Rob Herring
2023-07-06 18:07             ` Trilok Soni
2023-08-10 16:47             ` Mukesh Ojha
2023-07-04  9:27     ` Linus Walleij
2023-07-05 17:29       ` Trilok Soni
2023-07-14 23:45         ` Trilok Soni
2023-07-18  5:47           ` Mukesh Ojha
2023-07-18 13:35             ` Greg KH
2023-07-18 13:55               ` Mukesh Ojha
2023-07-18 14:41                 ` Greg KH
2023-07-18 16:22                   ` Trilok Soni
2023-07-02  8:08 ` Krzysztof Kozlowski
2023-07-13  4:39 ` Kathiravan T
2023-07-14 15:25   ` Mukesh Ojha

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=1687955688-20809-9-git-send-email-quic_mojha@quicinc.com \
    --to=quic_mojha@quicinc.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gpiccoli@igalia.com \
    --cc=keescook@chromium.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).