linux-kernel - Re: [PATCH v4 4/8] dt-bindings: firmware: arm,scmi: Add atomic-threshold-us optional property

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

Message-ID: <20220215092023.GA21915@e120937-lin>
Date:   Tue, 15 Feb 2022 09:20:37 +0000
From:   Cristian Marussi <cristian.marussi@....com>
To:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        robh+dt@...nel.org
Cc:     sudeep.holla@....com, james.quinlan@...adcom.com,
        Jonathan.Cameron@...wei.com, f.fainelli@...il.com,
        etienne.carriere@...aro.org, vincent.guittot@...aro.org,
        souvik.chakravarty@....com, peter.hilber@...nsynergy.com,
        igor.skalkin@...nsynergy.com, Rob Herring <robh+dt@...nel.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v4 4/8] dt-bindings: firmware: arm,scmi: Add
 atomic-threshold-us optional property

On Sun, Feb 13, 2022 at 07:58:28PM +0000, Cristian Marussi wrote:
> SCMI protocols in the platform can optionally signal to the OSPM agent
> the expected execution latency for a specific resource/operation pair.
> 
> Introduce an SCMI system wide optional property to describe a global time
> threshold which can be configured on a per-platform base to determine the
> opportunity, or not, for an SCMI command advertised to have a higher
> latency than the threshold, to be considered for atomic operations:
> high-latency SCMI synchronous commands should be preferably issued in the
> usual non-atomic mode.
> 
> Cc: Rob Herring <robh+dt@...nel.org>
> Cc: devicetree@...r.kernel.org
> Signed-off-by: Cristian Marussi <cristian.marussi@....com>
> ---
> v3 --> v4
> - renamed property to atomic-threshold-us
> v1 --> v2
> - rephrased the property description
> ---
>  .../devicetree/bindings/firmware/arm,scmi.yaml        | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index eae15df36eef..3ffa669b91af 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -81,6 +81,15 @@ properties:
>    '#size-cells':
>      const: 0
>  

Hi Rob,

gentle ping ... any feedback on this SCMI DT addition ?

(beside the brain-dead error of mine down below in the example still
to be fixed...my bad)

> +  atomic-threshold-us:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      An optional time value, expressed in microseconds, representing, on this
> +      platform, the threshold above which any SCMI command, advertised to have
> +      an higher-than-threshold execution latency, should not be considered for
> +      atomic mode of operation, even if requested.
> +      If left unconfigured defaults to zero.
> +
>    arm,smc-id:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      description:
> @@ -264,6 +273,8 @@ examples:
>              #address-cells = <1>;
>              #size-cells = <0>;
>  
> +            atomic_threshold = <10000>;
> +

...this example clearly still needs to be renamed to 'atomic-threshold-us'

Thanks,
Cristian