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: <db728b45-473a-e088-7296-160d93d79e0b@quicinc.com>
Date:   Tue, 16 May 2023 14:58:51 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH V6 1/3] dt-bindings: sram: qcom,imem: Add Boot Stat region
 within IMEM
Content-Language: en-US
To:     Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>
CC:     Souradeep Chowdhury <quic_schowdhu@quicinc.com>,
        Andy Gross <agross@kernel.org>,
        Konrad Dybcio <konrad.dybcio@somainline.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
        <devicetree@vger.kernel.org>, Sibi Sankar <quic_sibis@quicinc.com>,
        Rajendra Nayak <quic_rjendra@quicinc.com>
References: <cover.1683628357.git.quic_schowdhu@quicinc.com>
 <343182748e12b6a4ac57d336405c50e36fc5520c.1683628357.git.quic_schowdhu@quicinc.com>
 <CAA8EJpp2x2OEB2sg+caKmjkDYJp_NJ9mXo85FxTZr-9zRXHNhw@mail.gmail.com>
 <7d397e67-5d56-4975-98af-1ac9746c07f4@app.fastmail.com>
 <CAA8EJpoMGyAJBTw1-=+NT=ysy+cpc4EpJSv1SABJVh2BscdJ+g@mail.gmail.com>
From:   Trilok Soni <quic_tsoni@quicinc.com>
In-Reply-To: <CAA8EJpoMGyAJBTw1-=+NT=ysy+cpc4EpJSv1SABJVh2BscdJ+g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/16/2023 12:17 PM, Dmitry Baryshkov wrote:
> On Tue, 16 May 2023 at 11:16, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, May 9, 2023, at 13:35, Dmitry Baryshkov wrote:
>>> On Tue, 9 May 2023 at 13:53, Souradeep Chowdhury
>>> <quic_schowdhu@quicinc.com> wrote:
>>>>
>>>> All Qualcomm bootloaders log useful timestamp information related
>>>> to bootloader stats in the IMEM region. Add the child node within
>>>> IMEM for the boot stat region containing register address and
>>>> compatible string.
>>>
>>> I might have a minor vote here. Is there any reason why you have to
>>> instantiate the device from DT?
>>> It looks like a software interface. Ideally software should not be
>>> described in DT (e.g. this can be instantiated from imem
>>> driver-to-be).
>>
>> There is nothing wrong with describing firmware in DT, if that
>> firmware is part of the platform, we do that for a lot of
>> other bits of firmware.
>>
>> However, in this specific case, many things are wrong with the
>> implementation, and neither the DT binding nor the driver
>> makes sense to me in its current state.
>>
>>>> +  "^stats@[0-9a-f]+$":
>>>> +    type: object
>>>> +    description:
>>>> +      Imem region dedicated for storing timestamps related
>>>> +      information regarding bootstats.
>>>> +
>>>> +    additionalProperties: false
>>>> +
>>>> +    properties:
>>>> +      compatible:
>>>> +        items:
>>>> +          - enum:
>>>> +              - qcom,sm8450-bootstats
>>>> +          - const: qcom,imem-bootstats
>>>> +
>>>> +      reg:
>>>> +        maxItems: 1
>>
>> If I understand this right, this "qcom,imem-bootstats"
>> device serves as an indirection to store additional
>> properties of the system in a memory area, but the description
>> of that area is more complex than its contents, which
>> makes no sense to me.
>>
>> Just create a binding for a firmware node in the devicetree
>> itself, and put the values in properties of that. The first
>> stage firmware can still use the same interface, but the
>> actual loader that assembles the DT can get it out of that
>> and store it in the properties. With that done, there is also
>> no need for a kernel driver, as userspace can just get the
>> values from /sys/firmware/devicetree/ directly.
> 
> This sounds good, except the always-present issue of the devices which
> have already been released. Usually we can not expect a bootloader
> update for these devices.

Valid point. I don't expect current SOCs supported at upstream to update 
with the newer bootloader having this feature done through bootloader.

---Trilok Soni