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: <6a23eb7f-2fad-4a44-bf7c-ab7f01c342f3@arm.com>
Date: Mon, 8 Jul 2024 13:50:11 +0100
From: Suzuki K Poulose <suzuki.poulose@....com>
To: JieGan <quic_jiegan@...cinc.com>
Cc: Mathieu Poirier <mathieu.poirier@...aro.org>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Mike Leach <mike.leach@...aro.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 James Clark <james.clark@....com>, Jinlong Mao <quic_jinlmao@...cinc.com>,
 Leo Yan <leo.yan@...aro.org>, coresight@...ts.linaro.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, Tingwei Zhang <quic_tingweiz@...cinc.com>,
 Yuanfang Zhang <quic_yuanfang@...cinc.com>,
 Tao Zhang <quic_taozha@...cinc.com>, Trilok Soni <quic_tsoni@...cinc.com>,
 Song Chai <quic_songchai@...cinc.com>, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v2 2/4] dt-bindings: arm: Add binding document for
 Coresight Control Unit device.

On 08/07/2024 11:25, JieGan wrote:
> On Mon, Jul 08, 2024 at 06:10:28PM +0800, JieGan wrote:
>> On Mon, Jul 08, 2024 at 10:41:55AM +0100, Suzuki K Poulose wrote:
>>> On 05/07/2024 10:00, Jie Gan wrote:
>>>> Add binding document for Coresight Control Unit device.
>>>
>>> nit: This is again too generic ? corsight-tmc-control-unit ? After all
>>> thats what it is and not a *generic* coresight control unit ?
>>>
>> coresight-tmc-control-unit is much better. We will check it.
>>   
>>>>
>>>> Signed-off-by: Jie Gan <quic_jiegan@...cinc.com>
>>>> ---
>>>>    .../bindings/arm/qcom,coresight-ccu.yaml      | 87 +++++++++++++++++++
>>>>    1 file changed, 87 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml
>>>> new file mode 100644
>>>> index 000000000000..9bb8ced393a7
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml
>>>> @@ -0,0 +1,87 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/arm/qcom,coresight-ccu.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: CoreSight Control Unit
>>>> +
>>>> +maintainers:
>>>> +  - Yuanfang Zhang <quic_yuanfang@...cinc.com>
>>>> +  - Mao Jinlong <quic_jinlmao@...cinc.com>
>>>> +  - Jie Gan <quic_jiegan@...cinc.com>
>>>> +
>>>> +description:
>>>> +  The Coresight Control unit controls various Coresight behaviors.
>>>> +  Used to enable/disable ETR’s data filter function based on trace ID.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: qcom,coresight-ccu
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clocks:
>>>> +    maxItems: 1
>>>> +
>>>> +  clock-names:
>>>> +    items:
>>>> +      - const: apb_pclk
>>>> +
>>>> +  reg-names:
>>>> +    items:
>>>> +      - const: ccu-base
>>>> +
>>>> +  in-ports:
>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> +    unevaluatedProperties:
>>>> +      patternProperties:
>>>> +        '^port(@[0-7])?$':
>>>> +          description: Input connections from CoreSight Trace bus
>>>> +          $ref: /schemas/graph.yaml#/properties/port
>>>> +
>>>> +          properties:
>>>> +            qcom,ccu-atid-offset:
>>>
>>> Why do we need this atid offset ? Couldn't this be mapped to the "port"
>>> number ?
>>>
>>> e.g, input-port 0 on CCU => Offset x
>>>       input-port 1 on CCU => (Offset x + Size of 1 region)
>> If the first ATID offset remains constant, it appears to be feasible.
>> We will consider the possibility of this solution.
> We just checked the ATID offset varies across different hardware platforms.
> It defined as 0xf4 on some platforms, and some others defined as 0xf8.

What do you mean ? The offset where you apply the filter changes across
different platforms ? or different "tmc-control-unit" implementations ?
Is this discoverable from the device ? We could use different
compatibles for different "types" of the "devices". Simply adding
something in the DT is not the right way.

> 
> So I think it should be better to define it in device tree node.

No. See above.

Suzuki

> 
>>
>>>
>>> I believe I mentioned this in the previous posting too ?
>> Yes, you mentioned before. I moved it from TMC filed to CCU filed.
>>
>>>
>>> Suzuki
>>>
>>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ