CoreSight

coresight@lists.linaro.org

5 participants
2506 discussions

[PATCH v2] coresight: etm4x: Fix PID tracing when perf is run in an init PID namespace

by Julien Meunier

The previous implementation limited the tracing capabilities when perf was run in the init PID namespace, making it impossible to trace applications in non-init PID namespaces. This update improves the tracing process by verifying the event owner. This allows us to determine whether the user has the necessary permissions to trace the application. Cc: stable(a)vger.kernel.org Fixes: aab473867fed ("coresight: etm4x: Don't trace PID for non-root PID namespace") Signed-off-by: Julien Meunier <julien.meunier(a)nokia.com> --- Changes in v2: * Update comments --- drivers/hwtracing/coresight/coresight-etm4x-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 66d44a404ad0..cf41c42399e1 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -693,9 +693,9 @@ static int etm4_parse_event_config(struct coresight_device *csdev, config->cfg |= TRCCONFIGR_TS; } - /* Only trace contextID when runs in root PID namespace */ + /* Only trace contextID when the event owner is in root PID namespace */ if ((attr->config & BIT(ETM_OPT_CTXTID)) && - task_is_in_init_pid_ns(current)) + task_is_in_init_pid_ns(event->owner)) /* bit[6], Context ID tracing bit */ config->cfg |= TRCCONFIGR_CID; @@ -709,8 +709,8 @@ static int etm4_parse_event_config(struct coresight_device *csdev, ret = -EINVAL; goto out; } - /* Only trace virtual contextID when runs in root PID namespace */ - if (task_is_in_init_pid_ns(current)) + /* Only trace virtual contextID when the event owner is in root PID namespace */ + if (task_is_in_init_pid_ns(event->owner)) config->cfg |= TRCCONFIGR_VMID | TRCCONFIGR_VMIDOPT; } -- 2.34.1

12 months

OpenCSD v1.5.5 release

by Mike Leach

Version v1.5.5 is now released. Update:- Add build support for MacOS Bugfix:- Fix object cleanup in decode tree. -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

12 months

Re: [PATCH v4 0/2] coresight: core: Add device name support

by Mike Leach

Hi Jinlong I was suggesting using the label property - see p44, table 4.3 of the devicetree specification. e.g. node_name@node_address { label = "text description of this device instance"; } Then use the normal of_xxxx functions to extract the string value from "label". Regards Mike On Fri, 18 Oct 2024 at 09:42, Jinlong Mao <quic_jinlmao(a)quicinc.com> wrote: > > > > On 2024/7/31 23:15, Mike Leach wrote: > > Hi, > > > > 1) As per Krzysztof comment - use the standard "label" property > > > > 2) Do not use the label string as the node name - there is no > > guarantee of uniqueness which will cause issues. Please add the label > > as a sysfs file to the standard node. > > This uses the existing standard names, allowing any scripting based on > > this to continue to work, and will not cause issues with uniqueness > > > > e.g. > > This will allow : > > > > cat cti_cpu0/label > > > > to extract the additional hardware context information that you need. > > > > Thanks > > > > Mike > > Hi Mike, > > I tried to get the label in the driver code. But I don't find any > function for it. Do you know the function to get the label of the device > tree node ? > > label: node_name@node_address > > Thanks > Jinlong Mao > > > > > > > On Wed, 3 Jul 2024 at 13:24, Mao Jinlong <quic_jinlmao(a)quicinc.com> wrote: > >> > >> With current design, the name of the non-cpu bounded coresight > >> component is the device type with the number. And with 'ls' command > >> we can get the register address of the component. But from these > >> information, we can't know what the HW or system the component belongs > >> to. Add device-name in DT to support it. > >> > >> cti_sys0 -> ../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0 > >> cti_sys1 -> ../../../devices/platform/soc(a)0/13900000.cti/cti_sys1 > >> tpdm0 -> ../../../devices/platform/soc(a)0/10b0d000.tpdm/tpdm0 > >> tpdm1 -> ../../../devices/platform/soc(a)0/10c28000.tpdm/tpdm1 > >> tpdm2 -> ../../../devices/platform/soc(a)0/10c29000.tpdm/tpdm2 > >> > >> Change since V3: > >> 1. Change device-name to arm,cs-dev-name. > >> 2. Add arm,cs-dev-name to only CTI and sources' dt-binding. > >> > >> Change since V2: > >> 1. Fix the error in coresight core. > >> drivers/hwtracing/coresight/coresight-core.c:1775:7: error: assigning to 'char *' from 'const char *' discards qualifiers > >> > >> 2. Fix the warning when run dtbinding check. > >> Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml: device-name: missing type definition > >> > >> Change since V1: > >> 1. Change coresight-name to device name. > >> 2. Add the device-name in coresight dt bindings. > >> > >> > >> Mao Jinlong (2): > >> coresight: core: Add device name support > >> dt-bindings: arm: Add device-name in the coresight components > >> > >> .../bindings/arm/arm,coresight-catu.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-cpu-debug.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-cti.yaml | 6 +++ > >> .../arm/arm,coresight-dummy-sink.yaml | 6 +++ > >> .../arm/arm,coresight-dummy-source.yaml | 6 +++ > >> .../arm/arm,coresight-dynamic-funnel.yaml | 6 +++ > >> .../arm/arm,coresight-dynamic-replicator.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-etb10.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-etm.yaml | 6 +++ > >> .../arm/arm,coresight-static-funnel.yaml | 6 +++ > >> .../arm/arm,coresight-static-replicator.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-stm.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-tmc.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-tpiu.yaml | 6 +++ > >> .../bindings/arm/qcom,coresight-tpda.yaml | 6 +++ > >> .../bindings/arm/qcom,coresight-tpdm.yaml | 6 +++ > >> drivers/hwtracing/coresight/coresight-core.c | 37 ++++++++++--------- > >> .../hwtracing/coresight/coresight-platform.c | 31 ++++++++++++++++ > >> include/linux/coresight.h | 3 +- > >> 19 files changed, 149 insertions(+), 18 deletions(-) > >> > >> Mao Jinlong (2): > >> dt-bindings: arm: Add device-name in the coresight components > >> coresight: core: Add device name support > >> > >> .../bindings/arm/arm,coresight-cti.yaml | 6 +++ > >> .../arm/arm,coresight-dummy-source.yaml | 6 +++ > >> .../bindings/arm/arm,coresight-stm.yaml | 6 +++ > >> .../bindings/arm/qcom,coresight-tpdm.yaml | 6 +++ > >> drivers/hwtracing/coresight/coresight-core.c | 37 ++++++++++--------- > >> .../hwtracing/coresight/coresight-platform.c | 30 +++++++++++++++ > >> include/linux/coresight.h | 3 +- > >> 7 files changed, 76 insertions(+), 18 deletions(-) > >> > >> -- > >> 2.41.0 > >> > > > > > > -- > > Mike Leach > > Principal Engineer, ARM Ltd. > > Manchester Design Centre. UK > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

12 months

CoreSight on Nvidia Jetson

by vincent.ernst＠web.de

Hi there, I have two Nvidia Jetson Developer Kits, one AGX Xavier and one Nano. I want to use CoreSight for self-hosted trace collection (i.e. without JTAG debug probe) on these boards. I built the kernel for CoreSight configuration, but the problem is that there are no CoreSight devices at /sys/bus/coresight/devices/. Does anyone have an idea how to fix this? Any help is highly appreciated! Best regards, Vincent

1 year

[PATCH v5 0/3] coresight: Add static trace id support

by Mao Jinlong

Some HW has static trace id which cannot be changed via software programming. For this case, configure the trace id in device tree with "arm,static-trace-id = <xxx>", and call coresight_trace_id_get_static_system_id with the trace id value in device probe function. The id will be reserved for the HW all the time if the device is probed. Changes since V4: 1. Use fwnode_property_read_u32 in fwnode_property_read_u32. 2. Update date and version in sysfs-bus-coresight-devices-dummy-source Changes since V3: 1. Adda new API function int coresight_trace_id_get_system_static_id(int trace_id). 2. Use the term "static trace id" for these devices where the hardware sets a non-programmable trace ID. Changes since V2: 1. Change "trace-id" to "arm,trace-id". 2. Add trace id flag for getting preferred id or ODD id. Changes since V1: 1. Add argument to coresight_trace_id_get_system_id for preferred id instead of adding new function coresight_trace_id_reserve_system_id. 2. Add constraint to trace-id in dt-binding file. Mao Jinlong (3): dt-bindings: arm: Add arm,static-trace-id for coresight dummy source coresight: Add support to get static id for system trace sources coresight: dummy: Add static trace id support for dummy source .../sysfs-bus-coresight-devices-dummy-source | 15 +++++ .../arm/arm,coresight-dummy-source.yaml | 6 ++ drivers/hwtracing/coresight/coresight-dummy.c | 59 +++++++++++++++++-- .../hwtracing/coresight/coresight-platform.c | 9 +++ .../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++---- .../hwtracing/coresight/coresight-trace-id.h | 9 +++ include/linux/coresight.h | 1 + 7 files changed, 123 insertions(+), 14 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source -- 2.17.1

1 year

Re: [PATCH 1/1] coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()

by Anshuman Khandual

On 10/18/24 19:38, Zhen Lei wrote: > Function devm_kzalloc() returns NULL instead of ERR_PTR() when it fails. Right, devm_kzalloc() calls devm_kmalloc() with additional __GFP_ZERO which returns NULL on error. > The IS_ERR() test in the return value check should be replaced with NULL > test. > > Fixes: 39744738a67d ("coresight: trbe: Allocate platform data per device") > Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Actually this problem is caused by the following commit which had replaced coresight_get_platform_data() with devm_kzalloc() for a dummy 'desc.pdata' allocation. Earlier IS_ERR() test for the return value, was correct for coresight_get_platform_data() which returns ERR_PTR() on error, but then it should have been changed for devm_kzalloc() into a NULL check instead. 4277f035d227 ("coresight: trbe: Add a representative coresight_platform_data for TRBE") Please add "Fixes:" tag for the above commit instead. > Signed-off-by: Zhen Lei <thunder.leizhen(a)huawei.com> > --- > drivers/hwtracing/coresight/coresight-trbe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c > index 96a32b213669940..93fe9860acf16bd 100644 > --- a/drivers/hwtracing/coresight/coresight-trbe.c > +++ b/drivers/hwtracing/coresight/coresight-trbe.c > @@ -1266,7 +1266,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp > * into the device for that purpose. > */ > desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL); > - if (IS_ERR(desc.pdata)) > + if (!desc.pdata) > goto cpu_clear; > > desc.type = CORESIGHT_DEV_TYPE_SINK; Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com>

1 year

Re: [PATCH 1/1] coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()

by James Clark

On 18/10/2024 3:08 pm, Zhen Lei wrote: > Function devm_kzalloc() returns NULL instead of ERR_PTR() when it fails. > The IS_ERR() test in the return value check should be replaced with NULL > test. > > Fixes: 39744738a67d ("coresight: trbe: Allocate platform data per device") > Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") I don't think the code that this patches exists in 3fbf7f011f24, but it looks ok for 39744738a67d. > Signed-off-by: Zhen Lei <thunder.leizhen(a)huawei.com> > --- > drivers/hwtracing/coresight/coresight-trbe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c > index 96a32b213669940..93fe9860acf16bd 100644 > --- a/drivers/hwtracing/coresight/coresight-trbe.c > +++ b/drivers/hwtracing/coresight/coresight-trbe.c > @@ -1266,7 +1266,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp > * into the device for that purpose. > */ > desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL); > - if (IS_ERR(desc.pdata)) > + if (!desc.pdata) > goto cpu_clear; > > desc.type = CORESIGHT_DEV_TYPE_SINK; Reviewed-by: James Clark <james.clark(a)linaro.org>

1 year

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

by Suzuki K Poulose

On 18/10/2024 11:31, Krzysztof Kozlowski wrote: > On 18/10/2024 12:08, Suzuki K Poulose wrote: >> On 18/10/2024 11:05, Krzysztof Kozlowski wrote: >>> On 17/10/2024 09:23, Tao Zhang wrote: >>>> >>>> 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? >>> >>> I don't have any smart ideas and with earlier explanation sounds ok. >> >> Just to confirm, are you OK with adding a property to the "endpoint" >> node that will indicate a phandle that the device allows on this >> endpoint ? > > You mean the filter property in endpoint? if so, then yes. Thanks for confirming ! Cheers Suzuki > > Best regards, > Krzysztof >

1 year

Re: [PATCH v4 1/2] dt-bindings: arm: Add device-name in the coresight components

by Suzuki K Poulose

On 24/07/2024 20:13, Krzysztof Kozlowski wrote: > On 03/07/2024 14:23, Mao Jinlong wrote: >> Current name of coresight component's folder consists of prefix of >> the device and the id in the device list. When run 'ls' command, >> we can get the register address of the device. Take CTI for example, >> if we want to set the config for modem CTI, but we can't know which >> CTI is modem CTI from all current information. >> >> cti_sys0 -> ../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0 >> cti_sys1 -> ../../../devices/platform/soc(a)0/13900000.cti/cti_sys1 >> >> Add device-name in device tree which can provide a better description >> of the coresight device. It can provide the info like the system or >> HW it belongs to. >> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- >> .../devicetree/bindings/arm/arm,coresight-cti.yaml | 6 ++++++ >> .../devicetree/bindings/arm/arm,coresight-dummy-source.yaml | 6 ++++++ >> .../devicetree/bindings/arm/arm,coresight-stm.yaml | 6 ++++++ >> .../devicetree/bindings/arm/qcom,coresight-tpdm.yaml | 6 ++++++ >> 4 files changed, 24 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml >> index 2d5545a2b49c..6a73eaa66a42 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml >> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml >> @@ -98,6 +98,12 @@ properties: >> power-domains: >> maxItems: 1 >> >> + arm,cs-dev-name: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + Define the name which can describe what kind of HW or system the >> + coresight device belongs to. > > Don't we use already label for such cases? Power domains, input, leds, > panels, IIO, hwmon and more. We do and if we can get hold of them, that would be ideal. but do we get them in the binary DT blob ? At least I couldn't see them on my Juno dtb. Cheers Suzuki > > Best regards, > Krzysztof >

1 year

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

by Suzuki K Poulose

On 18/10/2024 11:05, Krzysztof Kozlowski wrote: > On 17/10/2024 09:23, Tao Zhang wrote: >> >> 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? > > I don't have any smart ideas and with earlier explanation sounds ok. Just to confirm, are you OK with adding a property to the "endpoint" node that will indicate a phandle that the device allows on this endpoint ? Kind regards Suzuki > > Best regards, > Krzysztof >

1 year

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight