linux-kernel - Re: [PATCH] coresight: Add coresight name support

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] [day] [month] [year] [list]
Message-ID: <1ae3c5a4-97d9-415e-8dd5-520e00c5e94f@quicinc.com>
Date: Thu, 11 Jan 2024 14:08:19 +0800
From: Jinlong Mao <quic_jinlmao@...cinc.com>
To: Rob Herring <robh@...nel.org>, Mike Leach <mike.leach@...aro.org>
CC: James Clark <james.clark@....com>,
        Suzuki K Poulose
	<suzuki.poulose@....com>,
        <coresight@...ts.linaro.org>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        Tingwei Zhang <quic_tingweiz@...cinc.com>,
        Yuanfang Zhang <quic_yuanfang@...cinc.com>,
        Tao Zhang
	<quic_taozha@...cinc.com>, Leo Yan <leo.yan@...aro.org>,
        Alexander Shishkin
	<alexander.shishkin@...ux.intel.com>
Subject: Re: [PATCH] coresight: Add coresight name support



On 1/3/2024 11:32 PM, Rob Herring wrote:
> On Tue, Jan 2, 2024 at 5:05 AM Mike Leach <mike.leach@...aro.org> wrote:
>>
>> As James mentions this is clearly a V2 of a previous patch - please
>> mark as such in future.
>>
>> Adding to what James has already said:-
>>
>> 1) Mapping between the canonical names used in the drivers and the
>> information as to the precise device is as easy as running 'ls' on
>> /sys/bus/coresight/devices:-
>>
>> root@...aro-developer:/home/linaro/cs-mods# ls -al /sys/bus/coresight/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Jan  2 11:27 .
>> drwxr-xr-x 4 root root 0 Jan  2 11:27 ..
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_cpu0 ->
>> ../../../devices/platform/soc@...58000.cti/cti_cpu0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_cpu1 ->
>> ../../../devices/platform/soc@...59000.cti/cti_cpu1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_cpu2 ->
>> ../../../devices/platform/soc@...5a000.cti/cti_cpu2
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_cpu3 ->
>> ../../../devices/platform/soc@...5b000.cti/cti_cpu3
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_sys0 ->
>> ../../../devices/platform/soc@...10000.cti/cti_sys0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_sys1 ->
>> ../../../devices/platform/soc@...11000.cti/cti_sys1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm0 ->
>> ../../../devices/platform/soc@...5c000.etm/etm0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm1 ->
>> ../../../devices/platform/soc@...5d000.etm/etm1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm2 ->
>> ../../../devices/platform/soc@...5e000.etm/etm2
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm3 ->
>> ../../../devices/platform/soc@...5f000.etm/etm3
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 funnel0 ->
>> ../../../devices/platform/soc@...21000.funnel/funnel0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 funnel1 ->
>> ../../../devices/platform/soc@...41000.funnel/funnel1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 replicator0 ->
>> ../../../devices/platform/soc@...24000.replicator/replicator0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 tmc_etf0 ->
>> ../../../devices/platform/soc@...25000.etf/tmc_etf0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 tmc_etr0 ->
>> ../../../devices/platform/soc@...26000.etr/tmc_etr0
>>
>>
>> 2) The patch set must contain the usage and specification in the .yaml
>>   file(s) of the property used.
> 
> For the record, I don't like "coresight-name". I don't have another
> suggestion because "easy" is not sufficient reasoning for why this is
> needed.

For example, if we want to configure the trigger and HW events for 
modem, we can't know which cti or TPDM is for modem from current names.

lrwxrwxrwx    1 root     0                0 Jan  1 00:01 cti_sys0 -> 
./../../devices/platform/soc@...38f0000.cti/cti_sys0
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 cti_sys1 -> 
./../../devices/platform/soc@...3900000.cti/cti_sys1
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 tpdm0 -> 
./../../devices/platform/soc@...0b0d000.tpdm/tpdm0
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 tpdm1 -> 
./../../devices/platform/soc@...0c28000.tpdm/tpdm1
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 tpdm2 -> 
./../../devices/platform/soc@...0c29000.tpdm/tpdm2

Thanks
Jinlong Mao
> 
>> However, there was a standard property called 'name' which is
>> deprecated - see
>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html
>> section 2.3.11. I do not believe that adding another 'name' property
>> would be accepted by the DT maintainers.
> 
> "name" is just the node name for anything in the last 15 years. They
> used to be separate, but would still mostly be the same. The only case
> I found with them different was old PowerPC Macs.
> 
>> 3) the 'device_node' structure has a 'name' field that contains the
>> node name in the DT approved "node-name@...t-address" format.
> 
> Actually, it is without the unit-address. full_name is with the unit-address.
> 
>> This
>> contains whatever node names you used in the dt.  Why not use this if
>> a change has to be made and find some conditional to activate it.
> 
> Don't go accessing "name" or "full_name" directly. I intend to get rid
> of "name" and generate it from full_name. So use the accessors and
> printk specifiers if you need node names.
> 
> Rob