Received-SPF: pass (google.com: domain of linux-kernel+bounces-23080-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <1ae3c5a4-97d9-415e-8dd5-520e00c5e94f@quicinc.com>
Date: Thu, 11 Jan 2024 14:08:19 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] coresight: Add coresight name support
Content-Language: en-US
To: Rob Herring <robh@kernel.org>, Mike Leach <mike.leach@linaro.org>
CC: James Clark <james.clark@arm.com>,
        Suzuki K Poulose
	<suzuki.poulose@arm.com>,
        <coresight@lists.linaro.org>, <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
        Tingwei Zhang <quic_tingweiz@quicinc.com>,
        Yuanfang Zhang <quic_yuanfang@quicinc.com>,
        Tao Zhang
	<quic_taozha@quicinc.com>, Leo Yan <leo.yan@linaro.org>,
        Alexander Shishkin
	<alexander.shishkin@linux.intel.com>
References: <20231228093321.5522-1-quic_jinlmao@quicinc.com>
 <12ce6e5d-6e4d-fb99-eb82-dece97423bfb@arm.com>
 <CAJ9a7Vgi=ELOhXNF97KrBtV5ef8khwWqzWKevrYW2RtBBtsppw@mail.gmail.com>
 <CAL_JsqKYuqKxokDzs3xVWqYZoFfyMwMrLd17DpfCO_x7CXvRZw@mail.gmail.com>
From: Jinlong Mao <quic_jinlmao@quicinc.com>
In-Reply-To: <CAL_JsqKYuqKxokDzs3xVWqYZoFfyMwMrLd17DpfCO_x7CXvRZw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 1/3/2024 11:32 PM, Rob Herring wrote:
> On Tue, Jan 2, 2024 at 5:05 AM Mike Leach <mike.leach@linaro.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@linaro-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@0/858000.cti/cti_cpu0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_cpu1 ->
>> ../../../devices/platform/soc@0/859000.cti/cti_cpu1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_cpu2 ->
>> ../../../devices/platform/soc@0/85a000.cti/cti_cpu2
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_cpu3 ->
>> ../../../devices/platform/soc@0/85b000.cti/cti_cpu3
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_sys0 ->
>> ../../../devices/platform/soc@0/810000.cti/cti_sys0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 cti_sys1 ->
>> ../../../devices/platform/soc@0/811000.cti/cti_sys1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm0 ->
>> ../../../devices/platform/soc@0/85c000.etm/etm0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm1 ->
>> ../../../devices/platform/soc@0/85d000.etm/etm1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm2 ->
>> ../../../devices/platform/soc@0/85e000.etm/etm2
>> lrwxrwxrwx 1 root root 0 Jan  2 11:27 etm3 ->
>> ../../../devices/platform/soc@0/85f000.etm/etm3
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 funnel0 ->
>> ../../../devices/platform/soc@0/821000.funnel/funnel0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 funnel1 ->
>> ../../../devices/platform/soc@0/841000.funnel/funnel1
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 replicator0 ->
>> ../../../devices/platform/soc@0/824000.replicator/replicator0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 tmc_etf0 ->
>> ../../../devices/platform/soc@0/825000.etf/tmc_etf0
>> lrwxrwxrwx 1 root root 0 Jan  2 11:42 tmc_etr0 ->
>> ../../../devices/platform/soc@0/826000.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@0/138f0000.cti/cti_sys0
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 cti_sys1 -> 
./../../devices/platform/soc@0/13900000.cti/cti_sys1
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 tpdm0 -> 
./../../devices/platform/soc@0/10b0d000.tpdm/tpdm0
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 tpdm1 -> 
./../../devices/platform/soc@0/10c28000.tpdm/tpdm1
lrwxrwxrwx    1 root     0                0 Jan  1 00:01 tpdm2 -> 
./../../devices/platform/soc@0/10c29000.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@unit-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