[PATCH v1 0/3] Add compatibles for different eud access modes

[PATCH v1 0/3] Add compatibles for different eud access modes

[Melody Olvera]

When enabling eud on some devices, a crash can happen when trying to
access mode manager registers, since some devices require that these
be accessed securely. To support this usecase, update the compatible
strings and add driver functionality to distinguish between secure
and non-secure euds and avert these kinds of crashes.

Melody Olvera (3):
  dt-bindings: soc: qcom: eud: Update compatible strings for eud
  usb: misc: qcom_eud: Access mode manager through secure calls
  arm64: dts: qcom: sc7280: Update eud compatible string

 .../bindings/soc/qcom/qcom,eud.yaml           |  6 +--
 arch/arm64/boot/dts/qcom/sc7280.dtsi          |  2 +-
 drivers/usb/misc/qcom_eud.c                   | 53 ++++++++++++++++---
 3 files changed, 51 insertions(+), 10 deletions(-)


base-commit: eec5d86d5bac6b3e972eb9c1898af3c08303c52d
-- 
2.45.2

[PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Melody Olvera]

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
 
   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>;
 
-- 
2.45.2

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Krzysztof Kozlowski]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Melody Olvera]

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
>

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Krzysztof Kozlowski]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Konrad Dybcio]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Melody Olvera]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Konrad Dybcio]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Trilok Soni]

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. 

-- 
---Trilok Soni

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Melody Olvera]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Konrad Dybcio]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Krzysztof Kozlowski]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Konrad Dybcio]

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

Re: [PATCH v1 1/3] dt-bindings: soc: qcom: eud: Update compatible strings for eud

[Melody Olvera]

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

[PATCH v1 2/3] usb: misc: qcom_eud: Access mode manager through secure calls

[Melody Olvera]

On many SoCs, the EUD mode manager needs to be accessed through
calls to the secure monitor, so add a compatible string and a config
to assess how the mode manager must be accessed and change behavior
accordingly.

Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
---
 drivers/usb/misc/qcom_eud.c | 53 ++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/misc/qcom_eud.c b/drivers/usb/misc/qcom_eud.c
index 19906301a4eb..77ef089a3ebf 100644
--- a/drivers/usb/misc/qcom_eud.c
+++ b/drivers/usb/misc/qcom_eud.c
@@ -5,6 +5,7 @@
 
 #include <linux/bitops.h>
 #include <linux/err.h>
+#include <linux/firmware/qcom/qcom_scm.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/iopoll.h>
@@ -35,18 +36,31 @@ struct eud_chip {
 	struct usb_role_switch		*role_sw;
 	void __iomem			*base;
 	void __iomem			*mode_mgr;
+	phys_addr_t			mode_mgr_phys;
 	unsigned int			int_status;
 	int				irq;
 	bool				enabled;
 	bool				usb_attached;
 };
 
+struct eud_cfg {
+	bool secure_eud_en;
+};
+
 static int enable_eud(struct eud_chip *priv)
 {
+	int ret;
+
 	writel(EUD_ENABLE, priv->base + EUD_REG_CSR_EUD_EN);
 	writel(EUD_INT_VBUS | EUD_INT_SAFE_MODE,
 			priv->base + EUD_REG_INT1_EN_MASK);
-	writel(1, priv->mode_mgr + EUD_REG_EUD_EN2);
+	if (priv->mode_mgr_phys && !priv->mode_mgr) {
+		ret = qcom_scm_io_writel(priv->mode_mgr_phys + EUD_REG_EUD_EN2, 1);
+		if (ret)
+			return ret;
+	} else {
+		writel(1, priv->mode_mgr + EUD_REG_EUD_EN2);
+	}
 
 	return usb_role_switch_set_role(priv->role_sw, USB_ROLE_DEVICE);
 }
@@ -54,7 +68,10 @@ static int enable_eud(struct eud_chip *priv)
 static void disable_eud(struct eud_chip *priv)
 {
 	writel(0, priv->base + EUD_REG_CSR_EUD_EN);
-	writel(0, priv->mode_mgr + EUD_REG_EUD_EN2);
+	if (priv->mode_mgr_phys && !priv->mode_mgr)
+		qcom_scm_io_writel(priv->mode_mgr_phys + EUD_REG_EUD_EN2, 0);
+	else
+		writel(0, priv->mode_mgr + EUD_REG_EUD_EN2);
 }
 
 static ssize_t enable_show(struct device *dev,
@@ -178,6 +195,8 @@ static void eud_role_switch_release(void *data)
 static int eud_probe(struct platform_device *pdev)
 {
 	struct eud_chip *chip;
+	struct resource *res;
+	const struct eud_cfg *cfg;
 	int ret;
 
 	chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
@@ -200,9 +219,22 @@ static int eud_probe(struct platform_device *pdev)
 	if (IS_ERR(chip->base))
 		return PTR_ERR(chip->base);
 
-	chip->mode_mgr = devm_platform_ioremap_resource(pdev, 1);
-	if (IS_ERR(chip->mode_mgr))
-		return PTR_ERR(chip->mode_mgr);
+	cfg = of_device_get_match_data(&pdev->dev);
+	if (!cfg)
+		return -EINVAL;
+
+	if (cfg->secure_eud_en) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		if (!res)
+			return -ENODEV;
+		chip->mode_mgr_phys = res->start;
+		chip->mode_mgr = NULL;
+	} else {
+		chip->mode_mgr = devm_platform_ioremap_resource(pdev, 1);
+		if (IS_ERR(chip->mode_mgr))
+			return PTR_ERR(chip->mode_mgr);
+		chip->mode_mgr_phys = 0;
+	}
 
 	chip->irq = platform_get_irq(pdev, 0);
 	if (chip->irq < 0)
@@ -231,8 +263,17 @@ static void eud_remove(struct platform_device *pdev)
 	disable_irq_wake(chip->irq);
 }
 
+static const struct eud_cfg nonsecure_eud = {
+	.secure_eud_en = false,
+};
+
+static const struct eud_cfg secure_eud = {
+	.secure_eud_en = true,
+};
+
 static const struct of_device_id eud_dt_match[] = {
-	{ .compatible = "qcom,eud" },
+	{ .compatible = "qcom,eud", .data = &nonsecure_eud },
+	{ .compatible = "qcom,secure-eud", .data = &secure_eud },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, eud_dt_match);
-- 
2.45.2

[PATCH v1 3/3] arm64: dts: qcom: sc7280: Update eud compatible string

[Melody Olvera]

Update eud compatible string to reflect use of non-secure eud.

Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 3d8410683402..f4b120043036 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -4018,7 +4018,7 @@ system-cache-controller@9200000 {
 		};
 
 		eud: eud@88e0000 {
-			compatible = "qcom,sc7280-eud", "qcom,eud";
+			compatible = "qcom,eud";
 			reg = <0 0x88e0000 0 0x2000>,
 			      <0 0x88e2000 0 0x1000>;
 			interrupts-extended = <&pdc 11 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.45.2

Re: [PATCH v1 3/3] arm64: dts: qcom: sc7280: Update eud compatible string

[Krzysztof Kozlowski]

On 07/08/2024 20:32, Melody Olvera wrote:
> Update eud compatible string to reflect use of non-secure eud.

This does not match diff at all. You say here something but do something
entirely else. Sorry, that's a NAK.

Best regards,
Krzysztof

Re: [PATCH v1 3/3] arm64: dts: qcom: sc7280: Update eud compatible string

[Melody Olvera]

On 8/8/2024 4:03 AM, Krzysztof Kozlowski wrote:
> On 07/08/2024 20:32, Melody Olvera wrote:
>> Update eud compatible string to reflect use of non-secure eud.
> This does not match diff at all. You say here something but do something
> entirely else. Sorry, that's a NAK.

Will drop this patch.

> Best regards,
> Krzysztof
>