linux-kernel - Re: [PATCH v3 5/6] arm64: dts: qcom: sm6150: Add gpu and rgmu nodes

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] [day] [month] [year] [list]

Message-ID: <7e1b7b46-f4d6-4028-8518-80e954dbb7cf@oss.qualcomm.com>
Date: Wed, 17 Dec 2025 13:31:22 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Akhil P Oommen <akhilpo@....qualcomm.com>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Rob Clark <robin.clark@....qualcomm.com>, Sean Paul <sean@...rly.run>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Dmitry Baryshkov <lumag@...nel.org>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Jessica Zhang <jesszhan0024@...il.com>,
        Dan Carpenter <dan.carpenter@...aro.org>,
        linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Jie Zhang <quic_jiezh@...cinc.com>
Subject: Re: [PATCH v3 5/6] arm64: dts: qcom: sm6150: Add gpu and rgmu nodes

On 12/5/25 3:05 PM, Akhil P Oommen wrote:
> On 12/5/2025 7:22 PM, Konrad Dybcio wrote:
>> On 12/5/25 2:41 PM, Akhil P Oommen wrote:
>>> On 12/4/2025 7:01 PM, Konrad Dybcio wrote:
>>>> On 12/4/25 11:13 AM, Akhil P Oommen wrote:
>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>> From: Jie Zhang <quic_jiezh@...cinc.com>
>>>>>>>>
>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>
>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@...cinc.com>
>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@....qualcomm.com>
>>>>>>>> ---
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> +			gpu_opp_table: opp-table {
>>>>>>>> +				compatible = "operating-points-v2";
>>>>>>>> +
>>>>>>>> +				opp-845000000 {
>>>>>>>> +					opp-hz = /bits/ 64 <845000000>;
>>>>>>>> +					required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>> +					opp-peak-kBps = <7050000>;
>>>>>>>> +				};
>>>>>>>
>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>> or mobile parts specifically?
>>>>>>
>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>> here.
>>>>>
>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>> except the 290Mhz corner. We can remove that one.
>>>>>
>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>> speedbins from the mobile variant until that is supported.
>>>>
>>>> Writing this reply took probably only slightly less time than fixing
>>>> the issue.. I really see no point in kicking the can down the road
>>>
>>> We don't know the speedbin fuse register and the values applicable for
>>> this IoT chipset. Currently, there is only a single variant and no SKUs
>>> for this chipset. We can add them when those decisions are taken by the
>>> relevant folks from Product team.
>>
>> If there's only a single variant right now, could you simply read back
>> the value and report it where necessary to make sure the internal teams
>> are aware?
>>
>> There's surely *some* value fused into the cell..
> 
> We don't know which register to read at the moment. It could be the hard
> fuse register or some soft fuse register at an arbitrary location.
> 
> It is better to leave it as it is for now. Who knows, maybe there won't
> any SKUs at all.

Please don't take it the wrong way, but who else would know that? :/

Konrad