CoreSight December 2023

coresight@lists.linaro.org

10 participants
30 discussions

[PATCH v3 0/4] coresight: Make current W=1 warnings default

by James Clark

Changes since v2: * Split code and Makefile changes * Add a fix for a comment warning in etm3x * Add some sparse checker fixes in coresight-cfg-afdo.c * Fix the 0 instead of NULL warnings reported by kernel test robot James Clark (4): coresight: Fix uninitialized struct warnings coresight: etm3x: Fix build warning coresight: Fix undeclared variable warnings from sparse checker coresight: Make current W=1 warnings default drivers/hwtracing/coresight/Makefile | 20 +++++++++++++++++++ .../hwtracing/coresight/coresight-cfg-afdo.c | 1 + .../hwtracing/coresight/coresight-cti-core.c | 2 +- drivers/hwtracing/coresight/coresight-etb10.c | 2 +- .../coresight/coresight-etm3x-core.c | 4 ++-- .../coresight/coresight-etm4x-core.c | 2 +- .../hwtracing/coresight/coresight-funnel.c | 4 ++-- .../coresight/coresight-replicator.c | 2 +- drivers/hwtracing/coresight/coresight-stm.c | 2 +- .../hwtracing/coresight/coresight-tmc-core.c | 2 +- drivers/hwtracing/coresight/coresight-tpda.c | 2 +- drivers/hwtracing/coresight/coresight-tpdm.c | 2 +- drivers/hwtracing/coresight/coresight-tpiu.c | 2 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 2 +- 14 files changed, 35 insertions(+), 14 deletions(-) -- 2.34.1

9 months

[PATCH 0/8] coresight: Separate sysfs and Perf usage and some other cleanups

by James Clark

I've been finding it quite difficult to reason about some of the state and functions in coresight-core.c because they have generic names when they are actually only relevant to the sysfs usage of Coresight rather than usage through Perf. This is probably because sysfs came first and Perf was added later. This has caused a couple of issues where these things have been used in the wrong context, for example the first commit is a fixup. To fix this I've mainly just moved all of the sysfs stuff to the sysfs file and removed the 'enable' state, which was just for sysfs. While doing the refactor it became obvious that refcnt didn't need to be atomic either, so that can be simplified along with some other comment clarifications and simplifications. Hopefully it's also a step towards to removing all of the duplicate refcnt and mode tracking code from the individual devices. That tracking pretty much always results in a one-shot enable/disable and fixes the mode to either sysfs or Perf, and there is no reason that can't exist in the core layer outside of the devices. I tried to finish that in this set, but there turned out to be some complexities, so I cut it short at a point where I can be sure that there are no behavioral changes. James Clark (8): coresight: Fix issue where a source device's helpers aren't disabled coresight: Make language around "activated" sinks consistent coresight: Remove ops callback checks coresight: Move mode to struct coresight_device coresight: Remove the 'enable' field. coresight: Move all sysfs code to sysfs file coresight: Remove atomic type from refcnt coresight: Remove unused stubs drivers/hwtracing/coresight/coresight-core.c | 494 +----------------- drivers/hwtracing/coresight/coresight-etb10.c | 29 +- .../hwtracing/coresight/coresight-etm-perf.c | 2 +- drivers/hwtracing/coresight/coresight-etm.h | 2 - .../coresight/coresight-etm3x-core.c | 17 +- .../coresight/coresight-etm3x-sysfs.c | 4 +- .../coresight/coresight-etm4x-core.c | 4 +- drivers/hwtracing/coresight/coresight-priv.h | 9 +- drivers/hwtracing/coresight/coresight-stm.c | 24 +- drivers/hwtracing/coresight/coresight-sysfs.c | 391 ++++++++++++++ .../hwtracing/coresight/coresight-tmc-core.c | 2 +- .../hwtracing/coresight/coresight-tmc-etf.c | 46 +- .../hwtracing/coresight/coresight-tmc-etr.c | 33 +- drivers/hwtracing/coresight/coresight-tmc.h | 2 - drivers/hwtracing/coresight/coresight-tpda.c | 13 +- drivers/hwtracing/coresight/coresight-tpiu.c | 14 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 22 +- drivers/hwtracing/coresight/ultrasoc-smb.h | 2 - include/linux/coresight.h | 114 +--- 19 files changed, 561 insertions(+), 663 deletions(-) -- 2.34.1

9 months, 3 weeks

[PATCH 0/3] perf scripts python: arm-cs-trace-disasm.py:

by Ruidong Tian

Now the instruction flow disasmed by arm-cs-trace-disasm.py is ambiguous and uncorrect, fix them in one patch set. Please refer to each patch for details. Ruidong Tian (3): perf scripts python: arm-cs-trace-disasm.py: print dso base address perf scripts python: arm-cs-trace-disasm.py: set start vm addr of exectable file to 0 perf scripts python: arm-cs-trace-disasm.py: do not ignore disam first sample .../scripts/python/arm-cs-trace-disasm.py | 28 +++++++++++-------- 1 file changed, 16 insertions(+), 12 deletions(-) -- 2.33.1

10 months

[PATCH v3 0/8] Add support to configure TPDM CMB subunit

by Tao Zhang

Introduction of TPDM CMB(Continuous Multi Bit) subunit CMB subunit is responsible for creating a dataset element, and is also optionally responsible for packing it to fit multiple elements on a single ATB transfer if possible in the configuration. The TPDM Core Datapath requests timestamps be stored by the TPDA and then delivering ATB sized data (depending on ATB width and element size, this could be smaller or larger than a dataset element) to the ATB Mast FSM. The CMB makes trace elements in two modes. In �continuous� mode, every valid data cycle creates an element. In �trace on change� mode, when valid data changes on the bus, a trace element is created. In continuous mode, all cycles where this condition is true create trace elements. In trace on change mode, a data element is only when the previously sampled input is different from the current sampled input. The CMB subunit must be configured prior to enablement. This series adds support for TPDM to configure the configure CMB subunit. Once this series patches are applied properly, the new tpdm nodes for should be observed at the tpdm path /sys/bus/coresight/devices/tpdm* which supports CMB subunit. e.g. root@qemuarm64:/sys/devices/platform/soc@0/684c000.tpdm/tpdm0# ls -l -rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_mode drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_msr drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_patt drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_trig_patt -rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_trig_ts -rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_ts_all drwxr-xr-x 2 root root 0 Jan 1 00:00 connections drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_edge drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_msr drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_patt drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_trig_patt -rw-r--r-- 1 root root 4096 Jan 1 00:00 enable_source --w------- 1 root root 4096 Jan 1 00:00 integration_test drwxr-xr-x 2 root root 0 Ja? 1 00:00 power --w------- 1 root root 4096 Jan 1 00:00 reset_dataset lrwxrwxrwx 1 root root 0 Apr 5 2021 subsystem -> ../../../../../bus/coresight -rw-r--r-- 1 root root 4096 Apr 5 2021 uevent -r--r--r-- 1 root root 4096 Jan 1 00:00 waiting_for_supplier We can use the commands are similar to the below to configure the TPDMs which support CMB subunit. Enable coresight sink first. echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/tpdm0/reset_dataset echo 1 > /sys/bus/coresight/devices/tpdm0/cmb_mode echo 1 > /sys/bus/coresight/devices/tpdm0/cmb_patt/enable_ts echo 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/cmb_patt/tpmr0 echo 0 > /sys/bus/coresight/devices/tpdm0/cmb_trig_ts echo 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/cmb_trig_patt/xpr1 echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source codelinaro link: https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/tpdm-cmb-v3 Changes in V3: 1. Add 8-bit support to the description in the TPDM devicetree document. -- Rob Herring 2. Change how the result is produced in "tpdm_read_element_size". -- James Clark 3. Calling "tpdm_clear_element_size" at the beginning of "tpda_enable_port". -- James Clark 4. Use "dsb_esize" and "cmb_esize" to determine whether multiple TPDMs are detected on a TPDA input port in "tpda_get_element_size". -- James Clark 5. Modify the judgment logic in "tpda_enable_port". -- James Clark 6. Add more description of "cmb_mode" to TPDM SysFS document. -- James Clark Changes in V2: 1. Optimizate and modify this patch series based on the patch series "Add support to configure TPDM CMB subunit". 2. Modify the functions that read the element size of DSB/CMB in TPDA driver. Tao Zhang (8): dt-bindings: arm: Add support for CMB element size coresight-tpda: Add support to configure CMB element coresight-tpdm: Add CMB dataset support coresight-tpdm: Add support to configure CMB coresight-tpdm: Add pattern registers support for CMB coresight-tpdm: Add timestamp control register support for the CMB dt-bindings: arm: Add support for TPDM CMB MSR register coresight-tpdm: Add msr register support for CMB .../testing/sysfs-bus-coresight-devices-tpdm | 87 ++++ .../bindings/arm/qcom,coresight-tpdm.yaml | 38 ++ drivers/hwtracing/coresight/coresight-tpda.c | 117 +++--- drivers/hwtracing/coresight/coresight-tpda.h | 6 + drivers/hwtracing/coresight/coresight-tpdm.c | 390 +++++++++++++++++- drivers/hwtracing/coresight/coresight-tpdm.h | 87 ++++ 6 files changed, 673 insertions(+), 52 deletions(-) -- 2.17.1

10 months

[PATCH] coresight: Add coresight name support

by Mao Jinlong

Add coresight name support for custom names which will be easy to identify the device by the name. Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> --- .../hwtracing/coresight/coresight-cti-core.c | 20 ++++++++------ drivers/hwtracing/coresight/coresight-dummy.c | 10 ++++--- .../hwtracing/coresight/coresight-platform.c | 27 +++++++++++++++++++ drivers/hwtracing/coresight/coresight-tpdm.c | 10 ++++--- include/linux/coresight.h | 1 + 5 files changed, 53 insertions(+), 15 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c index 3999d0a2cb60..60a1e76064a9 100644 --- a/drivers/hwtracing/coresight/coresight-cti-core.c +++ b/drivers/hwtracing/coresight/coresight-cti-core.c @@ -902,14 +902,18 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id) /* default to powered - could change on PM notifications */ drvdata->config.hw_powered = true; - /* set up device name - will depend if cpu bound or otherwise */ - if (drvdata->ctidev.cpu >= 0) - cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d", - drvdata->ctidev.cpu); - else - cti_desc.name = coresight_alloc_device_name(&cti_sys_devs, dev); - if (!cti_desc.name) - return -ENOMEM; + cti_desc.name = coresight_get_device_name(dev); + if (!cti_desc.name) { + /* set up device name - will depend if cpu bound or otherwise */ + if (drvdata->ctidev.cpu >= 0) + cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d", + drvdata->ctidev.cpu); + else { + cti_desc.name = coresight_alloc_device_name(&cti_sys_devs, dev); + if (!cti_desc.name) + return -ENOMEM; + } + } /* setup CPU power management handling for CPU bound CTI devices. */ ret = cti_pm_setup(drvdata); diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c index e4deafae7bc2..b19cd400df79 100644 --- a/drivers/hwtracing/coresight/coresight-dummy.c +++ b/drivers/hwtracing/coresight/coresight-dummy.c @@ -76,10 +76,12 @@ static int dummy_probe(struct platform_device *pdev) struct coresight_desc desc = { 0 }; if (of_device_is_compatible(node, "arm,coresight-dummy-source")) { - - desc.name = coresight_alloc_device_name(&source_devs, dev); - if (!desc.name) - return -ENOMEM; + desc.name = coresight_get_device_name(dev); + if (!desc.name) { + desc.name = coresight_alloc_device_name(&source_devs, dev); + if (!desc.name) + return -ENOMEM; + } desc.type = CORESIGHT_DEV_TYPE_SOURCE; desc.subtype.source_subtype = diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c index 9d550f5697fa..284aa22a06b7 100644 --- a/drivers/hwtracing/coresight/coresight-platform.c +++ b/drivers/hwtracing/coresight/coresight-platform.c @@ -183,6 +183,18 @@ static int of_coresight_get_cpu(struct device *dev) return cpu; } +static const char *of_coresight_get_device_name(struct device *dev) +{ + const char *name = NULL; + + if (!dev->of_node) + return NULL; + + of_property_read_string(dev->of_node, "coresight-name", &name); + + return name; +} + /* * of_coresight_parse_endpoint : Parse the given output endpoint @ep * and fill the connection information in @pdata->out_conns @@ -315,6 +327,12 @@ static inline int of_coresight_get_cpu(struct device *dev) { return -ENODEV; } + +static inline const char *of_coresight_get_device_name(struct device *dev) +{ + return NULL; +} + #endif #ifdef CONFIG_ACPI @@ -794,6 +812,15 @@ int coresight_get_cpu(struct device *dev) } EXPORT_SYMBOL_GPL(coresight_get_cpu); +const char *coresight_get_device_name(struct device *dev) +{ + if (is_of_node(dev->fwnode)) + return of_coresight_get_device_name(dev); + else + return NULL; +} +EXPORT_SYMBOL_GPL(coresight_get_device_name); + struct coresight_platform_data * coresight_get_platform_data(struct device *dev) { diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c index f4854af0431e..7735ff18c48e 100644 --- a/drivers/hwtracing/coresight/coresight-tpdm.c +++ b/drivers/hwtracing/coresight/coresight-tpdm.c @@ -201,9 +201,13 @@ static int tpdm_probe(struct amba_device *adev, const struct amba_id *id) drvdata->base = base; /* Set up coresight component description */ - desc.name = coresight_alloc_device_name(&tpdm_devs, dev); - if (!desc.name) - return -ENOMEM; + desc.name = coresight_get_device_name(dev); + if (!desc.name) { + desc.name = coresight_alloc_device_name(&tpdm_devs, dev); + if (!desc.name) + return -ENOMEM; + } + desc.type = CORESIGHT_DEV_TYPE_SOURCE; desc.subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS; desc.ops = &tpdm_cs_ops; diff --git a/include/linux/coresight.h b/include/linux/coresight.h index a269fffaf991..caa17c8af865 100644 --- a/include/linux/coresight.h +++ b/include/linux/coresight.h @@ -675,6 +675,7 @@ static inline void coresight_write64(struct coresight_device *csdev, u64 val, u3 #endif /* IS_ENABLED(CONFIG_CORESIGHT) */ extern int coresight_get_cpu(struct device *dev); +extern const char *coresight_get_device_name(struct device *dev); struct coresight_platform_data *coresight_get_platform_data(struct device *dev); struct coresight_connection * -- 2.41.0

10 months, 1 week

Re: [PATCH v1 1/2] dt-bindings: arm: coresight: Update the pattern of ete node name

by James Clark

On 26/12/2023 09:36, Krzysztof Kozlowski wrote: > On 26/12/2023 02:50, Jinlong Mao wrote: >> >> >> On 12/21/2023 4:44 PM, Krzysztof Kozlowski wrote: >>> On 21/12/2023 09:36, Jinlong Mao wrote: >>>> >>>> >>>> On 12/21/2023 4:17 PM, Krzysztof Kozlowski wrote: >>>>> On 21/12/2023 09:15, Jinlong Mao wrote: >>>>>> >>>>>> >>>>>> On 12/21/2023 4:12 PM, Krzysztof Kozlowski wrote: >>>>>>> On 21/12/2023 04:28, Jinlong Mao wrote: >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>>>>>> index f725e6940993..cbf583d34029 100644 >>>>>>>>>> --- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>>>>>> @@ -23,7 +23,7 @@ description: | >>>>>>>>>> >>>>>>>>>> properties: >>>>>>>>>> $nodename: >>>>>>>>>> - pattern: "^ete([0-9a-f]+)$" >>>>>>>>>> + pattern: "^ete-([0-9a-f]+)$" >>>>>>>>> >>>>>>>>> My concerns are not resolved. Why is it here in the first place? >>>>>>>> >>>>>>>> Hi Krzysztof, >>>>>>>> >>>>>>>> ETE is acronym of embedded trace extension. The number of the name is >>>>>>>> the same as the number of the CPU it belongs to. >>>>>>> >>>>>>> This is obvious and was not my question. > > You already said it here... > >>>>>> >>>>>> Do you mean why the pattern match of the node name is added here ? >>>>> >>>>> Yes, especially that it is requiring a non-generic name. >>>>> >>>>>> >>>>>> This node should not have the node name match, right ? >>>>> >>>>> Usually. For sure shouldn't be for non-generic names. >>>>> >>>> Hi Suzuki, >>>> >>>> Can we remove the pattern match of the node name and use a generic name >>>> "ete" for the ete DT nodes ? >>> >>> "ete" is not a generic name. What is generic here? It's an acronym of >>> some specific device name. >>> >> >> The device full name is embedded trace extension. So use ETE as the name >> here. > > That's obvious and my comment was not about it. Second time... This is > my unlucky day... I said, why do you even want to enforce name which is > not generic, since the names should be generic? > I think we can just drop the enforced name if it's getting in the way. It doesn't really do anything and other Coresight bindings don't have it anyway. > I assume you read the DT specification: > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetr… > > > Best regards, > Krzysztof > I couldn't find anything in that list that would be a good fit for a name, and it seems like all of the Coresight devices have already been added with non generic names (like funnel and replicator etc), so it might be a bit late now. But if we drop the enforced name then it's probably fine. James

10 months, 2 weeks

Re: [PATCH v1 1/2] dt-bindings: arm: coresight: Update the pattern of ete node name

by Jinlong Mao

On 12/21/2023 4:44 PM, Krzysztof Kozlowski wrote: > On 21/12/2023 09:36, Jinlong Mao wrote: >> >> >> On 12/21/2023 4:17 PM, Krzysztof Kozlowski wrote: >>> On 21/12/2023 09:15, Jinlong Mao wrote: >>>> >>>> >>>> On 12/21/2023 4:12 PM, Krzysztof Kozlowski wrote: >>>>> On 21/12/2023 04:28, Jinlong Mao wrote: >>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>>>> index f725e6940993..cbf583d34029 100644 >>>>>>>> --- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>>>> @@ -23,7 +23,7 @@ description: | >>>>>>>> >>>>>>>> properties: >>>>>>>> $nodename: >>>>>>>> - pattern: "^ete([0-9a-f]+)$" >>>>>>>> + pattern: "^ete-([0-9a-f]+)$" >>>>>>> >>>>>>> My concerns are not resolved. Why is it here in the first place? >>>>>> >>>>>> Hi Krzysztof, >>>>>> >>>>>> ETE is acronym of embedded trace extension. The number of the name is >>>>>> the same as the number of the CPU it belongs to. >>>>> >>>>> This is obvious and was not my question. >>>> >>>> Do you mean why the pattern match of the node name is added here ? >>> >>> Yes, especially that it is requiring a non-generic name. >>> >>>> >>>> This node should not have the node name match, right ? >>> >>> Usually. For sure shouldn't be for non-generic names. >>> >> Hi Suzuki, >> >> Can we remove the pattern match of the node name and use a generic name >> "ete" for the ete DT nodes ? > > "ete" is not a generic name. What is generic here? It's an acronym of > some specific device name. > The device full name is embedded trace extension. So use ETE as the name here. Thanks Jinlong Mao >

10 months, 3 weeks

Re: [PATCH RFC V2 1/4] perf/core: Add aux_pause, aux_resume, aux_start_paused

by James Clark

On 20/12/2023 16:16, Adrian Hunter wrote: > On 20/12/23 17:54, James Clark wrote: >> >> >> On 08/12/2023 17:24, Adrian Hunter wrote: >>> Hardware traces, such as instruction traces, can produce a vast amount of >>> trace data, so being able to reduce tracing to more specific circumstances >>> can be useful. >>> >>> The ability to pause or resume tracing when another event happens, can do >>> that. >>> >>> Add ability for an event to "pause" or "resume" AUX area tracing. >>> >>> Add aux_pause bit to perf_event_attr to indicate that, if the event >>> happens, the associated AUX area tracing should be paused. Ditto >>> aux_resume. Do not allow aux_pause and aux_resume to be set together. >>> >>> Add aux_start_paused bit to perf_event_attr to indicate to an AUX area >>> event that it should start in a "paused" state. >>> >>> Add aux_paused to struct perf_event for AUX area events to keep track of >>> the "paused" state. aux_paused is initialized to aux_start_paused. >>> >>> Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start() >>> callbacks. Call as needed, during __perf_event_output(). Add >>> aux_in_pause_resume to struct perf_buffer to prevent races with the NMI >>> handler. Pause/resume in NMI context will miss out if it coincides with >>> another pause/resume. >>> >>> To use aux_pause or aux_resume, an event must be in a group with the AUX >>> area event as the group leader. >>> >>> Example (requires Intel PT and tools patches also): >>> >>> $ perf record --kcore -e '{intel_pt/aux-start-paused/k,syscalls:sys_enter_newuname/aux-resume/,syscalls:sys_exit_newuname/aux-pause/}' uname >> >> I think it might be useful to have an aux-toggle option as well, and >> then you could do sampling if you put it on a PMU counter with an >> interval. Unless you can make two events for the same counter with >> different intervals, and one does resume and the other does pause? I'm >> not sure if that would work? > > There is already ->snapshot_aux() for sampling. Is that what you mean? > I suppose that mostly handles that use case yes. Although there are some slight differences. It looks like for SAMPLE_AUX, the buffer size for each sample is fixed and limited to 16 bits in size, whereas between pause and resume you could potentially have multiple buffers delivered to userspace of any size. And it looks like SAMPLE_AUX would leave the trace running even when no samples were being collected. I suppose you might not want to consume the memory bandwidth and turn the trace off between samples, which pause/resume does. Especially if you intend to have long periods between the samples. I think if it did turn out to be useful the toggle function can easily be added later, so I don't intend this comment to be a blocking one. >> >> Other than that it looks ok. I got Coresight working with a couple of >> changes to what you posted on here, but that can always be done more >> thoroughly later if we leave PERF_PMU_CAP_AUX_PAUSE off Coresight for now. > > Thanks a lot for looking at this! >

10 months, 3 weeks

Re: [PATCH v1 1/2] dt-bindings: arm: coresight: Update the pattern of ete node name

by Jinlong Mao

On 12/21/2023 4:17 PM, Krzysztof Kozlowski wrote: > On 21/12/2023 09:15, Jinlong Mao wrote: >> >> >> On 12/21/2023 4:12 PM, Krzysztof Kozlowski wrote: >>> On 21/12/2023 04:28, Jinlong Mao wrote: >>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>> index f725e6940993..cbf583d34029 100644 >>>>>> --- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>>>> @@ -23,7 +23,7 @@ description: | >>>>>> >>>>>> properties: >>>>>> $nodename: >>>>>> - pattern: "^ete([0-9a-f]+)$" >>>>>> + pattern: "^ete-([0-9a-f]+)$" >>>>> >>>>> My concerns are not resolved. Why is it here in the first place? >>>> >>>> Hi Krzysztof, >>>> >>>> ETE is acronym of embedded trace extension. The number of the name is >>>> the same as the number of the CPU it belongs to. >>> >>> This is obvious and was not my question. >> >> Do you mean why the pattern match of the node name is added here ? > > Yes, especially that it is requiring a non-generic name. > >> >> This node should not have the node name match, right ? > > Usually. For sure shouldn't be for non-generic names. > Hi Suzuki, Can we remove the pattern match of the node name and use a generic name "ete" for the ete DT nodes ? Thanks Jinlong Mao > Best regards, > Krzysztof >

10 months, 3 weeks

Re: [PATCH v1 1/2] dt-bindings: arm: coresight: Update the pattern of ete node name

by Jinlong Mao

On 12/21/2023 4:12 PM, Krzysztof Kozlowski wrote: > On 21/12/2023 04:28, Jinlong Mao wrote: >>>> diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>> index f725e6940993..cbf583d34029 100644 >>>> --- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml >>>> @@ -23,7 +23,7 @@ description: | >>>> >>>> properties: >>>> $nodename: >>>> - pattern: "^ete([0-9a-f]+)$" >>>> + pattern: "^ete-([0-9a-f]+)$" >>> >>> My concerns are not resolved. Why is it here in the first place? >> >> Hi Krzysztof, >> >> ETE is acronym of embedded trace extension. The number of the name is >> the same as the number of the CPU it belongs to. > > This is obvious and was not my question. Do you mean why the pattern match of the node name is added here ? This node should not have the node name match, right ? Thanks Jinlong Mao > > Best regards, > Krzysztof >

10 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight December 2023