Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <58a26b9e-a48d-d567-c310-193a2c52521e@linaro.org>
Date:   Sun, 2 Jul 2023 10:12:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: [PATCH v4 08/21] dt-bindings: reserved-memory: Add qcom,ramoops
 binding
To:     Mukesh Ojha <quic_mojha@quicinc.com>,
        Rob Herring <robh+dt@kernel.org>
Cc:     corbet@lwn.net, agross@kernel.org, andersson@kernel.org,
        konrad.dybcio@linaro.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, 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
References: <1687955688-20809-1-git-send-email-quic_mojha@quicinc.com>
 <1687955688-20809-9-git-send-email-quic_mojha@quicinc.com>
 <CAL_JsqJ_TTnGjjB2d8_FKHpWBRG5GHLoWnabCKjsdeZ4QFdNEg@mail.gmail.com>
 <cacbbb02-732e-076e-50bf-292d20a4d722@quicinc.com>
Content-Language: en-US
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <cacbbb02-732e-076e-50bf-292d20a4d722@quicinc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

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