From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Mukesh Ojha <quic_mojha@quicinc.com>,
keescook@chromium.org, gpiccoli@igalia.com, corbet@lwn.net,
tony.luck@intel.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org
Cc: linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: reserved-memory: ramoops: Update the binding
Date: Fri, 13 Jan 2023 13:04:59 +0100 [thread overview]
Message-ID: <7cb96551-094c-1a68-cc3f-31e4e2e94518@linaro.org> (raw)
In-Reply-To: <1673611126-13803-1-git-send-email-quic_mojha@quicinc.com>
Subject: drop second/last, redundant "binding". The "dt-bindings" prefix
is already stating that these are bindings.
Your subject says nothing. Everything is "update".
On 13/01/2023 12:58, Mukesh Ojha wrote:
> Update the ramoops region binding document with details
> like region can also be reserved dynamically apart from
> reserving it statically.
So what exactly can be here reserved dynamically? And what does it mean
'dynamically'? By whom? How is this property of hardware (not OS)?
>
> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
> ---
> Change in v2:
> - Added this patch as per changes going to be done in patch 3/3
>
> .../bindings/reserved-memory/ramoops.yaml | 34 ++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml
> index 0391871..54e46e8 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml
> +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml
> @@ -10,7 +10,8 @@ description: |
> ramoops provides persistent RAM storage for oops and panics, so they can be
> recovered after a reboot. This is a child-node of "/reserved-memory", and
> is named "ramoops" after the backend, rather than "pstore" which is the
> - subsystem.
> + subsystem. This region can be reserved both statically or dynamically by
> + using appropriate property in device tree.
>
> Parts of this storage may be set aside for other persistent log buffers, such
> as kernel log messages, or for optional ECC error-correction data. The total
> @@ -112,7 +113,13 @@ unevaluatedProperties: false
>
> required:
> - compatible
> - - reg
> +
> +oneOf:
> + - required:
> + - reg
> +
> + - required:
> + - size
There is no such property. You cannot require it.
>
> anyOf:
> - required: [record-size]
> @@ -142,3 +149,26 @@ examples:
> };
> };
> };
> +
> + - |
> + / {
> + compatible = "foo";
> + model = "foo";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + ramoops: ramoops_region {
Node names should be generic, no underscores in node names.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
Any reason in naming it differently then existing one? You have there
example.
> + compatible = "ramoops";
> + alloc-ranges = <0x0 0x00000000 0xffffffff 0xffffffff>;
> + size = <0x0 0x10000>; /* 64kB */
> + console-size = <0x8000>; /* 32kB */
> + record-size = <0x400>; /* 1kB */
> + ecc-size = <16>;
> + };
> + };
> + };
Best regards,
Krzysztof
next prev parent reply other threads:[~2023-01-13 12:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 11:58 Mukesh Ojha
2023-01-13 11:58 ` [PATCH v2 2/3] Documentation: admin-guide: ramoops.rst: Update the ramoops document Mukesh Ojha
2023-01-13 13:24 ` Mukesh Ojha
2023-01-13 11:58 ` [PATCH v3 3/3] pstore/ram: Rework logic for detecting ramoops Mukesh Ojha
2023-01-13 12:04 ` Krzysztof Kozlowski [this message]
2023-01-13 13:22 ` [PATCH v2 1/3] dt-bindings: reserved-memory: ramoops: Update the binding Mukesh Ojha
2023-01-27 12:29 ` Mukesh Ojha
2023-01-27 12:52 ` Krzysztof Kozlowski
2023-01-13 15:26 ` Rob Herring
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=7cb96551-094c-1a68-cc3f-31e4e2e94518@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=gpiccoli@igalia.com \
--cc=keescook@chromium.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_mojha@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=tony.luck@intel.com \
/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
all inboxes | Powered by JetHome®