[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <11ca366c-7788-41d0-bf47-4f31c1ee2626@kernel.org>
Date: Wed, 21 Aug 2024 08:48:00 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Konrad Dybcio <konradybcio@...nel.org>,
Melody Olvera <quic_molvera@...cinc.com>,
Trilok Soni <quic_tsoni@...cinc.com>,
Souradeep Chowdhury <quic_schowdhu@...cinc.com>,
Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Satya Durga Srinivasu Prabhala <quic_satyap@...cinc.com>,
Elson Serrao <quic_eserrao@...cinc.com>
Cc: cros-qcom-dts-watchers@...omium.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org
Subject: Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible
strings for eud
On 20/08/2024 21:19, Konrad Dybcio wrote:
> On 20.08.2024 8:21 PM, Melody Olvera wrote:
>>
>>
>> On 8/14/2024 3:09 PM, Trilok Soni wrote:
>>> On 8/14/2024 1:25 PM, Konrad Dybcio wrote:
>>>>> Unfortunately, no. We considered several options, but none guarantee that we will avoid
>>>>> a crash if we try non-securely. The secure call also won't give a specific error if it fails either
>>>>> (for security reasons) so we can't know if a secure access failed because it's supposed to be
>>>>> accessed non-securely or for another reason; hence this approach. If there's
>>>>> another way to achieve this functionality that might be better, I'm all ears.
>>>> Can we read some fuse values and decide based on that?
>>> In most of the cases, these fuse values are not allowed to be read
>>> from the Linux, so that will be another problem. Melody can check
>>> if there is any fuse values around here and possible to read them
>>> through Linux.
>>>
>>
>> I double-checked, but there really isn't any kind of fuse or anything we can read to determine
>> how we need to access these registers. I remembered checking before authoring these patches,
>> but I wanted to just make sure before responding here.
>
> Well in that case I suppose a new compatible / property (please voice
> your opinion Krzysztof) is necessary after all.. Thanks for making sure
You mean the "secure" part? Sure, I don't object that, although
(repeating as usual) I am not in favor of it in the first place, be
cause you should use only SoC compatibles.
The objection here was for dropping specific front compatible, without
any relevant explanation.
Best regards,
Krzysztof
Powered by blists - more mailing lists