linux-kernel - Re: [PATCH] dt-bindings: firmware: Add documentation for qcom,platform-parts-info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <359ba91d-866b-45e4-83fe-598ed791f877@quicinc.com>
Date:   Mon, 4 Sep 2023 14:08:00 +0530
From:   Naman Jain <quic_namajain@...cinc.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>
CC:     <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_pkondeti@...cinc.com>,
        <quic_kaushalk@...cinc.com>, <quic_rohiagar@...cinc.com>,
        <kernel@...cinc.com>
Subject: Re: [PATCH] dt-bindings: firmware: Add documentation for
 qcom,platform-parts-info

On 9/1/2023 12:52 PM, Krzysztof Kozlowski wrote:
> On 01/09/2023 08:02, Naman Jain wrote:
>> Add documentation to describe device tree bindings for QCOM's
>> platform-parts-info node. Firmware populates these nodes to pass the
>> information to kernel regarding the subset of hardware blocks
>> and features like Camera, Modem, Display present in a product.
>>
>> This is to support that the same software image runs seamlessly on
>> different platforms where one or more HW blocks are not supported or
>> if some sub parts for a particular block are not supported.
>>
>> Purpose of these definitions is to allow clients to know about this,
>> and thus, handle these cases gracefully.
> Whether camera is or is not supported, is defined by presence of camera
> node or by its status field.
>
> Existing firmware (e.g. U-Boot) is also doing this - patching DTS when
> needed.
>
> I do not think introducing some parallel way makes any sense, so no,
> that's not the way to do it.
>
> Best regards,
> Krzysztof

Thanks Krzysztof for reviewing the patch. I think for telling whether 
the Camera HW block is not
supported / not present, firmware can either remove the device tree 
node, or change its status
to disabled, so that is fine.
With this patch, I was trying to address the use case, where Camera is 
supported but certain features
of that particular Camera are not supported, due to dependent HW blocks 
not present, or due to
product decision to not support it. We wanted to avoid the firmware to 
have this overhead of knowing
what these individual bits mean and thus, disable few of the HW blocks 
that are supposed to be
disabled. And this is applicable for each of these HW blocks.

For example, we can know from 32 bits provided for modem, if 3G/4G/5G is 
supported or not on a
platform. That is decided based on presence/absence of certain HW 
blocks, but it may or may not be as
simple as disabling a particular DT node.
Basically we wanted to defer it to the subsystem drivers, to do whatever 
they like with this
information on sub-parts that are available.

Will rephrase my commit message to make it clearer, but would like to 
hear your thoughts on this first.

Thanks,

Naman Jain

>