| Message ID | 20240807183205.803847-2-quic_molvera@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add compatibles for different eud access modes | expand |
On 07/08/2024 20:32, Melody Olvera wrote: > The EUD can more accurately be divided into two types; a secure type > which requires that certain registers be updated via scm call and a > nonsecure type which must access registers nonsecurely. Thus, change > the compatible strings to reflect secure and nonsecure eud usage. > > Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> > --- > Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml > index f2c5ec7e6437..476f92768610 100644 > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml > @@ -17,8 +17,8 @@ properties: > compatible: > items: > - enum: > - - qcom,sc7280-eud > - - const: qcom,eud > + - qcom,secure-eud > + - qcom,eud Commit msg did not explain me why DT bindings rules are avoided here and you drop existing SoC specific compatible. This really does not look like having any sense at all, I cannot come up with logic behind dropping existing users. You could deprecate it, but then why exactly this device should have exception from generic bindings rule? Best regards, Krzysztof
On 8/8/2024 4:00 AM, Krzysztof Kozlowski wrote: > On 07/08/2024 20:32, Melody Olvera wrote: >> The EUD can more accurately be divided into two types; a secure type >> which requires that certain registers be updated via scm call and a >> nonsecure type which must access registers nonsecurely. Thus, change >> the compatible strings to reflect secure and nonsecure eud usage. >> >> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >> --- >> Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >> index f2c5ec7e6437..476f92768610 100644 >> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >> @@ -17,8 +17,8 @@ properties: >> compatible: >> items: >> - enum: >> - - qcom,sc7280-eud >> - - const: qcom,eud >> + - qcom,secure-eud >> + - qcom,eud > Commit msg did not explain me why DT bindings rules are avoided here and > you drop existing SoC specific compatible. > > This really does not look like having any sense at all, I cannot come up > with logic behind dropping existing users. You could deprecate it, but > then why exactly this device should have exception from generic bindings > rule? Understood. I won't drop this compatible string. Is alright to add the additional compatible as is? Thanks, Melody > > Best regards, > Krzysztof >
On 13/08/2024 22:03, Melody Olvera wrote: > > > On 8/8/2024 4:00 AM, Krzysztof Kozlowski wrote: >> On 07/08/2024 20:32, Melody Olvera wrote: >>> The EUD can more accurately be divided into two types; a secure type >>> which requires that certain registers be updated via scm call and a >>> nonsecure type which must access registers nonsecurely. Thus, change >>> the compatible strings to reflect secure and nonsecure eud usage. >>> >>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>> --- >>> Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>> index f2c5ec7e6437..476f92768610 100644 >>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>> @@ -17,8 +17,8 @@ properties: >>> compatible: >>> items: >>> - enum: >>> - - qcom,sc7280-eud >>> - - const: qcom,eud >>> + - qcom,secure-eud >>> + - qcom,eud >> Commit msg did not explain me why DT bindings rules are avoided here and >> you drop existing SoC specific compatible. >> >> This really does not look like having any sense at all, I cannot come up >> with logic behind dropping existing users. You could deprecate it, but >> then why exactly this device should have exception from generic bindings >> rule? > > Understood. I won't drop this compatible string. Is alright to add the > additional compatible as is? You always need SoC specific compatible. Best regards, Krzysztof
On 14.08.2024 8:15 AM, Krzysztof Kozlowski wrote: > On 13/08/2024 22:03, Melody Olvera wrote: >> >> >> On 8/8/2024 4:00 AM, Krzysztof Kozlowski wrote: >>> On 07/08/2024 20:32, Melody Olvera wrote: >>>> The EUD can more accurately be divided into two types; a secure type >>>> which requires that certain registers be updated via scm call and a >>>> nonsecure type which must access registers nonsecurely. Thus, change >>>> the compatible strings to reflect secure and nonsecure eud usage. >>>> >>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>>> --- >>>> Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>> index f2c5ec7e6437..476f92768610 100644 >>>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>> @@ -17,8 +17,8 @@ properties: >>>> compatible: >>>> items: >>>> - enum: >>>> - - qcom,sc7280-eud >>>> - - const: qcom,eud >>>> + - qcom,secure-eud >>>> + - qcom,eud >>> Commit msg did not explain me why DT bindings rules are avoided here and >>> you drop existing SoC specific compatible. >>> >>> This really does not look like having any sense at all, I cannot come up >>> with logic behind dropping existing users. You could deprecate it, but >>> then why exactly this device should have exception from generic bindings >>> rule? >> >> Understood. I won't drop this compatible string. Is alright to add the >> additional compatible as is? > > You always need SoC specific compatible. Melody, is there any way to discover (that won't crash the board if we guess wrong) whether secure accessors are needed? Konrad
On 8/13/2024 11:15 PM, Krzysztof Kozlowski wrote: > On 13/08/2024 22:03, Melody Olvera wrote: >> >> On 8/8/2024 4:00 AM, Krzysztof Kozlowski wrote: >>> On 07/08/2024 20:32, Melody Olvera wrote: >>>> The EUD can more accurately be divided into two types; a secure type >>>> which requires that certain registers be updated via scm call and a >>>> nonsecure type which must access registers nonsecurely. Thus, change >>>> the compatible strings to reflect secure and nonsecure eud usage. >>>> >>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>>> --- >>>> Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>> index f2c5ec7e6437..476f92768610 100644 >>>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>> @@ -17,8 +17,8 @@ properties: >>>> compatible: >>>> items: >>>> - enum: >>>> - - qcom,sc7280-eud >>>> - - const: qcom,eud >>>> + - qcom,secure-eud >>>> + - qcom,eud >>> Commit msg did not explain me why DT bindings rules are avoided here and >>> you drop existing SoC specific compatible. >>> >>> This really does not look like having any sense at all, I cannot come up >>> with logic behind dropping existing users. You could deprecate it, but >>> then why exactly this device should have exception from generic bindings >>> rule? >> Understood. I won't drop this compatible string. Is alright to add the >> additional compatible as is? > You always need SoC specific compatible. Got it. Will change to SoC specific then. Thanks, Melody
On 8/14/2024 3:30 AM, Konrad Dybcio wrote: > On 14.08.2024 8:15 AM, Krzysztof Kozlowski wrote: >> On 13/08/2024 22:03, Melody Olvera wrote: >>> >>> On 8/8/2024 4:00 AM, Krzysztof Kozlowski wrote: >>>> On 07/08/2024 20:32, Melody Olvera wrote: >>>>> The EUD can more accurately be divided into two types; a secure type >>>>> which requires that certain registers be updated via scm call and a >>>>> nonsecure type which must access registers nonsecurely. Thus, change >>>>> the compatible strings to reflect secure and nonsecure eud usage. >>>>> >>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>>>> --- >>>>> Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>>> index f2c5ec7e6437..476f92768610 100644 >>>>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>>> @@ -17,8 +17,8 @@ properties: >>>>> compatible: >>>>> items: >>>>> - enum: >>>>> - - qcom,sc7280-eud >>>>> - - const: qcom,eud >>>>> + - qcom,secure-eud >>>>> + - qcom,eud >>>> Commit msg did not explain me why DT bindings rules are avoided here and >>>> you drop existing SoC specific compatible. >>>> >>>> This really does not look like having any sense at all, I cannot come up >>>> with logic behind dropping existing users. You could deprecate it, but >>>> then why exactly this device should have exception from generic bindings >>>> rule? >>> Understood. I won't drop this compatible string. Is alright to add the >>> additional compatible as is? >> You always need SoC specific compatible. > Melody, is there any way to discover (that won't crash the board if we > guess wrong) whether secure accessors are needed? > 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. Thanks, Melody
On 14.08.2024 7:33 PM, Melody Olvera wrote: > > > On 8/14/2024 3:30 AM, Konrad Dybcio wrote: >> On 14.08.2024 8:15 AM, Krzysztof Kozlowski wrote: >>> On 13/08/2024 22:03, Melody Olvera wrote: >>>> >>>> On 8/8/2024 4:00 AM, Krzysztof Kozlowski wrote: >>>>> On 07/08/2024 20:32, Melody Olvera wrote: >>>>>> The EUD can more accurately be divided into two types; a secure type >>>>>> which requires that certain registers be updated via scm call and a >>>>>> nonsecure type which must access registers nonsecurely. Thus, change >>>>>> the compatible strings to reflect secure and nonsecure eud usage. >>>>>> >>>>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>>>>> --- >>>>>> Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- >>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>>>> index f2c5ec7e6437..476f92768610 100644 >>>>>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>>>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml >>>>>> @@ -17,8 +17,8 @@ properties: >>>>>> compatible: >>>>>> items: >>>>>> - enum: >>>>>> - - qcom,sc7280-eud >>>>>> - - const: qcom,eud >>>>>> + - qcom,secure-eud >>>>>> + - qcom,eud >>>>> Commit msg did not explain me why DT bindings rules are avoided here and >>>>> you drop existing SoC specific compatible. >>>>> >>>>> This really does not look like having any sense at all, I cannot come up >>>>> with logic behind dropping existing users. You could deprecate it, but >>>>> then why exactly this device should have exception from generic bindings >>>>> rule? >>>> Understood. I won't drop this compatible string. Is alright to add the >>>> additional compatible as is? >>> You always need SoC specific compatible. >> Melody, is there any way to discover (that won't crash the board if we >> guess wrong) whether secure accessors are needed? >> > > 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? Konrad
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.
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. Thanks, Melody
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 Konrad
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
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
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml index f2c5ec7e6437..476f92768610 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml @@ -17,8 +17,8 @@ properties: compatible: items: - enum: - - qcom,sc7280-eud - - const: qcom,eud + - qcom,secure-eud + - qcom,eud reg: items: @@ -55,7 +55,7 @@ additionalProperties: false examples: - | eud@88e0000 { - compatible = "qcom,sc7280-eud", "qcom,eud"; + compatible = "qcom,eud"; reg = <0x88e0000 0x2000>, <0x88e2000 0x1000>;
The EUD can more accurately be divided into two types; a secure type which requires that certain registers be updated via scm call and a nonsecure type which must access registers nonsecurely. Thus, change the compatible strings to reflect secure and nonsecure eud usage. Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> --- Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)