On 21.08.2024 8:48 AM, Krzysztof Kozlowski wrote: > 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. Is EUD-non-secure in use on both Chrome and LA firmwares on 7280? Konrad
