linux-kernel - Re: [PATCH v3 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6e408062-9a74-4a2a-8b67-b83244c4ca95@quicinc.com>
Date: Thu, 17 Oct 2024 15:23:12 +0800
From: Tao Zhang <quic_taozha@...cinc.com>
To: Suzuki K Poulose <suzuki.poulose@....com>,
        Krzysztof Kozlowski
	<krzk@...nel.org>
CC: Mike Leach <mike.leach@...aro.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Leo Yan <leo.yan@...ux.dev>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        <coresight@...ts.linaro.org>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] dt-bindings: arm:
 qcom,coresight-static-replicator: Add property for source filtering


On 10/9/2024 6:52 PM, Suzuki K Poulose wrote:
> Krzysztof
>
> On 22/08/2024 12:50, Suzuki K Poulose wrote:
>> On 22/08/2024 11:34, Suzuki K Poulose wrote:
>>> On 22/08/2024 08:08, Krzysztof Kozlowski wrote:
>>>> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote:
>>>>> On 21/08/2024 04:13, Tao Zhang wrote:
>>>>>> The is some "magic" hard coded filtering in the replicators,
>>>>>> which only passes through trace from a particular "source". Add
>>>>>> a new property "filter-src" to label a phandle to the coresight
>>>>>> trace source device matching the hard coded filtering for the port.
>>>>>
>>>>> Minor nit: Please do not use abbreviate "source" in the bindings.
>>>>> I am not an expert on other changes below and will leave it to
>>>>> Rob/Krzysztof to comment.
>>>>>
>>>>> Rob, Krzysztof,
>>>>>
>>>>> We need someway to "link" (add a phandle) from a "port". The patch 
>>>>> below
>>>>> is extending "standard" port to add a phandle. Please let us know if
>>>>> there is a better way.
>>>>>
>>>>> e.g.:
>>>>>
>>>>> filters = list of tuples of port, phandle. ?
>>>>>
>>>>> e.g.:
>>>>>
>>>>> filters = < 0, <&tpdm_video>,
>>>>>              1, <&tpdm_mdss>
>>>>>        >
>>>>>
>>>>
>>>> Current solution feels like band-aid - what if next time you need some
>>>> second filter? Or "wall"? Or whatever? Next property?
>>>
>>>
>>>
>>>>
>>>> Isn't filter just one endpoint in the graph?
>>>>
>>>> A <--> filter <--> B
>>>
>>> To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a
>>> multi output ports).
>>>
>>> For clearer example:
>>>
>>> A0 <--> .. <--> ..\                  p0  / --> Filtered for (A1) 
>>> <--> B1
>>> A1 <--> .. <--> .. - < L(filters>    p1  - --> Filtered for (A2) 
>>> <--> B2
>>> A2 <--> .. <--> ../                  p2  \ --> Unfiltered        
>>> <--> B0
>>>
>>>
>>>
>>>> Instead of
>>>>
>>>> A <----through-filter----> B?
>>>
>>> The problem is we need to know the components in the path from A0 to X
>>> through, (Not just A0 and L). And also we need to know "which port 
>>> (p0 vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out 
>>> of the
>>> link "L".
>>>
>>> So ideally, we need a way to tie p0 -> A1, p1 -> A2.
>>>
>>> would we need something else in the future ? I don't know for sure.
>>> People could design their own things ;-). But this was the first time
>>> ever in the last 12yrs since we supported coresight in the kernel.
>>> (there is always a first time).
>>>
>>> Fundamentally, the "ports" cannot have additional properties today.
>>> Not sure if there are other usecases (I don't see why). So, we have
>>> to manually extend like above, which I think is not nice.
>>
>> Replying to the other thread [0], made me realize that the above is not
>> true. Indeed it is possible to add properties for endpoints, e.g:
>>
>> e.g.: media/video-interfaces.yaml
>>
>> So extending the endpoint node is indeed acceptable (unlike I thought).
>> May be the we it is achieved in this patch is making it look otherwise.
>>
>> Suzuki
>> [0] 
>> https://lkml.kernel.org/r/4b51d5a9-3706-4630-83c1-01b01354d9a4@arm.com
>
> Please could you let us know if it is acceptable to extend "endpoint"
> node to have an optional property ?

Hi Krzysztof,


Kindly reminder, could you help comment on this?


Best,

Tao

>
> Suzuki
>
>
>>
>>
>>
>>>
>>> Happy to proceed with anything that seems acceptable for you folks.
>>>
>>> Suzuki
>>>
>>>
>>>
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>
>
> _______________________________________________
> CoreSight mailing list -- coresight@...ts.linaro.org
> To unsubscribe send an email to coresight-leave@...ts.linaro.org