CoreSight August 2024

coresight@lists.linaro.org

9 participants
48 discussions

Re: [PATCH] perf scripts python arm-cs-trace-disasm.py: Skip disasm if address continuity is broken

by James Clark

On 23/08/2024 10:57 am, Ganapatrao Kulkarni wrote: > > Hi James/Mike, > > On 23-08-2024 02:33 pm, James Clark wrote: >> >> >> On 19/08/2024 11:59 am, Mike Leach wrote: >>> Hi, >>> >>> A new branch of OpenCSD is available - ocsd-consistency-checks-1.5.4-rc1 >>> >>> Testing I managed to do confirms the N atom on unconditional branches >>> appear to work. I do not have a test case for the range >>> discontinuities. >>> >>> The checks are enabled using operation flags on decoder creation. See >>> the docs for details. >>> >>> Mike >>> >> >> Hi Mike, >> >> I tested the new OpenCSD and I don't see the error anymore in the >> disassembly script. I'm not sure if we need to go any further and add >> the backwards check, it looks like just a later symptom and the checks >> that you've added already prevent it. >> >> If you release a new version I can send the perf patch. I was going to >> use these flags if that looks right to you? As far as I know that's the >> set that can be always on and won't fail on bad hardware? >> >> I also assumed that ETM4_OPFLG_PKTDEC_AA64_OPCODE_CHK can be given even >> for etmv3 and it's just a nop? >> >> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >> index e917985bbbe6..90967fd807e6 100644 >> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >> @@ -685,9 +685,14 @@ cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params, >> return 0; >> >> if (d_params->operation == CS_ETM_OPERATION_DECODE) { >> + int decode_flags = OCSD_CREATE_FLG_FULL_DECODER; >> +#ifdef OCSD_OPFLG_N_UNCOND_DIR_BR_CHK >> + decode_flags |= OCSD_OPFLG_N_UNCOND_DIR_BR_CHK | OCSD_OPFLG_CHK_RANGE_CONTINUE | >> + ETM4_OPFLG_PKTDEC_AA64_OPCODE_CHK; >> +#endif >> if (ocsd_dt_create_decoder(decoder->dcd_tree, >> decoder->decoder_name, >> - OCSD_CREATE_FLG_FULL_DECODER, >> + decode_flags, >> trace_config, &csid)) >> return -1; >> > > I tried Mike's branch with above James's patch and still the segfault is happening to us. > Did you update OpenCSD as well?

3 weeks, 5 days

Re: [PATCH v3 1/2] dt-bindings: arm: Add qcom,qmi-id for remote etm

by Jinlong Mao

On 2024/8/23 15:39, Krzysztof Kozlowski wrote: > On Fri, Aug 23, 2024 at 03:16:07PM +0800, Jinlong Mao wrote: >> >> >> On 2024/8/22 15:41, Krzysztof Kozlowski wrote: >>> On Wed, Aug 21, 2024 at 11:41:18PM -0700, Mao Jinlong wrote: >>>> qcom,qmi-id is the instance id used by qmi API to communicate with >>>> remote processor. >>>> >>>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >>>> --- >>>> .../bindings/arm/qcom,coresight-remote-etm.yaml | 10 ++++++++++ >>>> 1 file changed, 10 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >>>> index 4fd5752978cd..27e5f18bfedf 100644 >>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >>>> @@ -20,6 +20,13 @@ properties: >>>> compatible: >>>> const: qcom,coresight-remote-etm >>>> + qcom,qmi-id: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + This id is used by qmi API to communicate with remote processor for >>>> + enabling and disabling remote etm. Each processor has its unique instance >>>> + id. >>>> + >>>> out-ports: >>>> $ref: /schemas/graph.yaml#/properties/ports >>>> additionalProperties: false >>>> @@ -31,6 +38,7 @@ properties: >>>> required: >>>> - compatible >>>> + - qcom,qmi-id >>> >>> That's an ABI break. >>> >>> Best regards, >>> Krzysztof >> Hi Krzysztof, >> >> Sorry, I didn't get your point. >> Could you please share more details ? > > Adding new required properties is an ABI break. Nothing in commit msg > explained why this is okay or even needed. > > Best regards, > Krzysztof Thank you. I will update in the commit msg. >

3 weeks, 5 days

Re: [PATCH v3 1/2] dt-bindings: arm: Add qcom,qmi-id for remote etm

by Jinlong Mao

On 2024/8/22 15:41, Krzysztof Kozlowski wrote: > On Wed, Aug 21, 2024 at 11:41:18PM -0700, Mao Jinlong wrote: >> qcom,qmi-id is the instance id used by qmi API to communicate with >> remote processor. >> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- >> .../bindings/arm/qcom,coresight-remote-etm.yaml | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> index 4fd5752978cd..27e5f18bfedf 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> @@ -20,6 +20,13 @@ properties: >> compatible: >> const: qcom,coresight-remote-etm >> >> + qcom,qmi-id: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + This id is used by qmi API to communicate with remote processor for >> + enabling and disabling remote etm. Each processor has its unique instance >> + id. >> + >> out-ports: >> $ref: /schemas/graph.yaml#/properties/ports >> additionalProperties: false >> @@ -31,6 +38,7 @@ properties: >> >> required: >> - compatible >> + - qcom,qmi-id > > That's an ABI break. > > Best regards, > Krzysztof Hi Krzysztof, Sorry, I didn't get your point. Could you please share more details ? Thanks Jinlong Mao > >

3 weeks, 5 days

[PATCH v3 0/3] source filtering for multi-port output

by Tao Zhang

In our hardware design, by combining a funnel and a replicator, it implement a hardware device with one-to-one correspondence between output ports and input ports. The programming usage on this device is the same as funnel. The software uses a funnel and a static replicator to implement the driver of this device. Since original funnels only support a single output connection and original replicator only support a single input connection, the code needs to be modified to support this new feature. The following is a typical topology diagram of multi-port output mechanism. |----------| |---------| |----------| |---------| | TPDM 0 | | Source0 | | Source 1 | | TPDM 1 | |----------| |---------| |----------| |---------| | | | | | | | | | --------- | | | | | | | | | | | | | | | \-------------/ ---------------------- | \ Funnel 0 / | | ----------- | ------------------------------ | | | | | | \------------------/ \ Funnel 1 / ----| \--------------/ | | |----> Combine a funnel and a | | static replicator /-----------------\ | / replicator 0 \ ----| /---------------------\ | | | | | |-----------| | |---------| | | |TPDM0 |TPDM1 | \-----------------/ | \ TPDA 0 / | \-------------/ | | | | |Source0/1 | \-------------------------------/ \ Funnel 2 / \---------------------------/ Changes in V3: 1. Rename the function "coresight_source_filter" to "coresight_block_source". And refine this function. -- Suzuki K Poulose 2. Rename the parameters of the function "coresight_find_out_connection" to avoid confusion. -- Suzuki K Poulose 3. Get the source of path in "coresight_enable_path" and "coresight_disable_path". -- Suzuki K Poulose 4. Fix filter source device before skip the port in "coresight_orphan_match". -- Suzuki K Poulose 5. Make sure the device still orphan if whter is a filter source firmware node but the filter source device is null. -- Suzuki K Poulose 6. Walk through the entire coresight bus and fixup the "filter_src_dev" if the source is being removed. -- Suzuki K Poulose 7. Refine the commit description of patch#2. -- Suzuki K Poulose 8. Call "fwnode_handle_put" to "drop" the refcount for the device firmware node. -- Suzuki K Poulose 9. Fix the warning reported by kernel test robot. -- kernel test robot. 10. Use the source device directly if the port has a hardcoded filter in "tpda_get_element_size". -- Suzuki K Poulose Changes in V2: 1. Change the reference for endpoint property in dt-binding. -- Krzysztof Kozlowski 2. Change the property name "filter_src" to "filter-src". -- Krzysztof Kozlowski 3. Fix the errors in running 'make dt_binding_check'. -- Rob Herring 4. Pass in the source parameter instead of path. -- Suzuki K Poulose 5. Reset the "filter_src_dev" if the "src" csdev is being removed. -- Suzuki K Poulose 6. Add a warning if the "filter_src_dev" is of not the type DEV_TYPE_SOURCE. -- Suzuki K Poulose 7. Optimize the procedure for handling all possible cases. -- Suzuki K Poulose Changes in V1: 1. Add a static replicator connect to a funnel to implement the correspondence between the output ports and the input ports on funnels. -- Suzuki K Poulose 2. Add filter_src_dev and filter_src_dev phandle to "coresight_connection" struct, and populate them if there is one. -- Suzuki K Poulose 3. To look at the phandle and then fixup/remove the filter_src device in fixup/remove connections. -- Suzuki K Poulose 4. When TPDA reads DSB/CMB element size, it is implemented by looking up filter src device in the connections. -- Suzuki K Poulose Tao Zhang (3): dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering coresight: Add support for trace filtering by source coresight-tpda: Optimize the function of reading element size .../arm/arm,coresight-static-replicator.yaml | 19 ++- drivers/hwtracing/coresight/coresight-core.c | 136 +++++++++++++++--- .../hwtracing/coresight/coresight-platform.c | 18 +++ drivers/hwtracing/coresight/coresight-tpda.c | 11 +- include/linux/coresight.h | 5 + 5 files changed, 164 insertions(+), 25 deletions(-) -- 2.17.1

3 weeks, 6 days

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

by Suzuki K Poulose

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. Happy to proceed with anything that seems acceptable for you folks. Suzuki > > Best regards, > Krzysztof >

3 weeks, 6 days

Re: [PATCH v3 3/5] dt-bindings: arm: Add Coresight TMC Control Unit hardware

by Suzuki K Poulose

On 22/08/2024 10:55, Krzysztof Kozlowski wrote: > On 20/08/2024 08:36, JieGan wrote: >> On Mon, Aug 19, 2024 at 11:51:41AM +0200, Krzysztof Kozlowski wrote: >>> On 19/08/2024 10:51, JieGan wrote: >>>> On Mon, Aug 19, 2024 at 08:25:33AM +0200, Krzysztof Kozlowski wrote: >>>>> On 19/08/2024 03:49, JieGan wrote: >>>>>> On Sun, Aug 18, 2024 at 08:28:34AM -0600, Rob Herring wrote: >>>>>>> On Mon, Aug 12, 2024 at 10:41:39AM +0800, Jie Gan wrote: >>>>>>>> Add binding file to specify how to define a Coresight TMC >>>>>>>> Control Unit device in device tree. >>>>>>>> >>>>>>>> It is responsible for controlling the data filter function >>>>>>>> based on the source device's Trace ID for TMC ETR device. >>>>>>>> The trace data with that Trace id can get into ETR's buffer >>>>>>>> while other trace data gets ignored. >>>>>>>> >>>>>>>> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> >>>>>>>> --- >>>>>>>> .../bindings/arm/qcom,coresight-ctcu.yaml | 79 +++++++++++++++++++ >>>>>>>> 1 file changed, 79 insertions(+) >>>>>>>> create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>>>> >>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>>>> new file mode 100644 >>>>>>>> index 000000000000..7a9580007942 >>>>>>>> --- /dev/null >>>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>>>> @@ -0,0 +1,79 @@ >>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>>>>> +%YAML 1.2 >>>>>>>> +--- >>>>>>>> +$id: http://devicetree.org/schemas/arm/qcom,coresight-ctcu.yaml# >>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>>>>> + >>>>>>>> +title: CoreSight TMC Control Unit >>>>>>>> + >>>>>>>> +maintainers: >>>>>>>> + - Yuanfang Zhang <quic_yuanfang(a)quicinc.com> >>>>>>>> + - Mao Jinlong <quic_jinlmao(a)quicinc.com> >>>>>>>> + - Jie Gan <quic_jiegan(a)quicinc.com> >>>>>>>> + >>>>>>>> +description: >>>>>>>> + The Coresight TMC Control unit controls various Coresight behaviors. >>>>>>>> + It works as a helper device when connected to TMC ETR device. >>>>>>>> + It is responsible for controlling the data filter function based on >>>>>>>> + the source device's Trace ID for TMC ETR device. The trace data with >>>>>>>> + that Trace id can get into ETR's buffer while other trace data gets >>>>>>>> + ignored. >>>>>>> >>>>>>> Nowhere is TMC defined. >>>>>> The Coresight TMC control unit(CTCU) connected to Coresight TMC device via replicator and >>>>>> works as a helper device to TMC device. >>>>> >>>>> Did you understand the feedback or just responding with whatever to get >>>>> rid of reviewers? >>>> >>>> Sorry for the insufficient clarity in my response, I am just misunderstood the feedback and try >>>> to explain the relationship between TMC and CTCU device. >>>> >>>> I will add the TMC description to explain what TMC is as shown below: >>>> The Trace Memory Controller(TMC) is used for Embedded Trace Buffer(ETB), Embedded Trace FIFO(ETF) >>>> and Embedded Trace Router(ETR) configurations. The configuration mode (ETB, ETF, ETR) is >>>> discovered at boot time when the device is probed. >>> >>> Thanks. >>> >>>> >>>>> >>>>>> >>>>>> The in-ports listed below illustrate their connection to TMC devices. >>>>>> >>>>>>> >>>>>>>> + >>>>>>>> +properties: >>>>>>>> + compatible: >>>>>>>> + enum: >>>>>>>> + - qcom,sa8775p-ctcu >>>>>>>> + >>>>>>>> + reg: >>>>>>>> + maxItems: 1 >>>>>>>> + >>>>>>>> + clocks: >>>>>>>> + maxItems: 1 >>>>>>>> + >>>>>>>> + clock-names: >>>>>>>> + items: >>>>>>>> + - const: apb >>>>>>>> + >>>>>>>> + in-ports: >>>>>>> >>>>>>> Use 'ports' unless you have both in and out ports. >>>>>> The ‘in-ports’ and ‘out-ports’ properties will be parsed by ‘of_coresight_get_port_parent’ >>>>>> and their relationships to other devices will be stored in the coresight_platform_data structure. >>>>>> >>>>>> for example: >>>>>> struct coresight_platform_data { >>>>>> int nr_inconns; >>>>>> int nr_outconns; >>>>>> struct coresight_connection **out_conns; >>>>>> struct coresight_connection **in_conns; >>>>>> }; >>>>>> >>>>>> https://elixir.bootlin.com/linux/v6.11-rc4/source/drivers/hwtracing/coresig… >>>>> >>>>> and? If you respond with some unrelated argument, we will respond with >>>>> the same: Use 'ports' unless you have both in and out ports. >>>> >>>> Sorry for the insufficient response. >>>> >>>> The Coresight driver prefers using ‘in-ports’ and ‘out-ports’ instead of the ‘ports’ property, as each >>>> Coresight component needs to specify its input and output directions. >>>> >>>> The Coresight system operates by integrating all Coresight components and construting its data flow path >>>> based on the defined directions. >>>> >>>> Consequently, the data flow direction cannot be determined when utilizing the ‘ports’ property in the >>>> Coresight system. >>> >>> It can be determined. Driver knows that there are only in-ports, so you >>> cannot have here other direction. Maybe the drivers have somehow this >>> hard-coded? But that's a bit annoying limitation. >>> >> In Coresight platform driver, the of_coresight_get_port_parent function is used to retrieve the parent of the 'ports' node. >> The function is specifically hard-coded to recognize 'in-ports' and 'out-ports'. I think that's the limitation for >> 'ports' property. >> >> https://elixir.bootlin.com/linux/v6.11-rc4/source/drivers/hwtracing/coresig… > > That's a limitation of coresight platform driver, not bindings. Fix your > drivers. A bit more of context and history. We have a generic platform parsing code for parsing the firmware tables (DT and ACPI) in CoreSight. This will parse most generic bits (read, the graph connections) to avoid duplicating the code. Most of the components have both in and out connections (except trace sources and other helper devices like this TMC CU). Also, the "previous" (now legacy) DT graph bindings for CoreSight relied on using standard "ports" with a property to indicate whether a given port is "input". The platform driver still supports this for any legacy platform that hasn't moved over (of course with a complaint of using obsolete bindings in the dmesg). Now the above proposal is going to conflict with the legacy binding handling, where "ports" indicate output ports by default, without the obsolete property and the driver can't differentiate this from a legacy binding vs modern binding with individual driver to decide the direction of the port. Nothing unfixable, but I don't understand what is wrong in calling "input ports" in-ports. But if that is definitely a no go area, we would need to add "fixup" logic in individual drivers to "correct" the type of a port (i.e, all output ports in the parsed data to input ports) and live with it. Kind regards Suzuki > > Best regards, > Krzysztof >

3 weeks, 6 days

[PATCH v3 0/2] coresight: Add remote etm support

by Mao Jinlong

The system on chip (SoC) consists of main APSS(Applications processor subsytem) and additional processors like modem, lpass. There is coresight-etm driver for etm trace of APSS. Coresight remote etm driver is for enabling and disabling the etm trace of remote processors. It uses QMI interface to communicate with remote processors' software and uses coresight framework to configure the connection from remote etm source to TMC sinks. Example to capture the remote etm trace: Enable source: echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/remote_etm0/enable_source Capture the trace: cat /dev/tmc_etf0 > /data/remote_etm.bin Disable source: echo 0 > /sys/bus/coresight/devices/remote_etm0/enable_source Change since V2: 1. Change qcom,inst-id to qcom,qmi-id 2. Fix the error in code for type of remote_etm_remove 3. Depend on QMI helper in Kconfig Changes since V1: 1. Remove unused content 2. Use CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS as remote etm source type. 3. Use enabled instead of enable in driver data. 4. Validate instance id value where it's read from the DT. Mao Jinlong (2): dt-bindings: arm: Add qcom,qmi-id for remote etm coresight: Add remote etm support .../arm/qcom,coresight-remote-etm.yaml | 10 + drivers/hwtracing/coresight/Kconfig | 13 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-qmi.h | 89 +++++ .../coresight/coresight-remote-etm.c | 307 ++++++++++++++++++ 5 files changed, 420 insertions(+) create mode 100644 drivers/hwtracing/coresight/coresight-qmi.h create mode 100644 drivers/hwtracing/coresight/coresight-remote-etm.c -- 2.41.0

3 weeks, 6 days

[PATCH v4 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 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,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 | 26 ++++++++ .../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++---- .../hwtracing/coresight/coresight-trace-id.h | 9 +++ include/linux/coresight.h | 1 + 7 files changed, 140 insertions(+), 14 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source -- 2.41.0

4 weeks

[PATCH] coresight: tmc: sg: Do not leak sg_table

by Suzuki K Poulose

Running perf with cs_etm on Juno triggers the following kmemleak warning ! :~# cat /sys/kernel/debug/kmemleak unreferenced object 0xffffff8806b6d720 (size 96): comm "perf", pid 562, jiffies 4297810960 hex dump (first 32 bytes): 38 d8 13 07 88 ff ff ff 00 d0 9e 85 c0 ff ff ff 8............... 00 10 00 88 c0 ff ff ff 00 f0 ff f7 ff 00 00 00 ................ backtrace (crc 1dbf6e00): [<ffffffc08107381c>] kmemleak_alloc+0xbc/0xd8 [<ffffffc0802f9798>] kmalloc_trace_noprof+0x220/0x2e8 [<ffffffc07bb71948>] tmc_alloc_sg_table+0x48/0x208 [coresight_tmc] [<ffffffc07bb71cbc>] tmc_etr_alloc_sg_buf+0xac/0x240 [coresight_tmc] [<ffffffc07bb72538>] tmc_alloc_etr_buf.constprop.0+0x1f0/0x260 [coresight_tmc] [<ffffffc07bb7280c>] alloc_etr_buf.constprop.0.isra.0+0x74/0xa8 [coresight_tmc] [<ffffffc07bb72950>] tmc_alloc_etr_buffer+0x110/0x260 [coresight_tmc] [<ffffffc07bb38afc>] etm_setup_aux+0x204/0x3b0 [coresight] [<ffffffc08025837c>] rb_alloc_aux+0x20c/0x318 [<ffffffc08024dd84>] perf_mmap+0x2e4/0x7a0 [<ffffffc0802cceb0>] mmap_region+0x3b0/0xa08 [<ffffffc0802cd8a8>] do_mmap+0x3a0/0x500 [<ffffffc080295328>] vm_mmap_pgoff+0x100/0x1d0 [<ffffffc0802cadf8>] ksys_mmap_pgoff+0xb8/0x110 [<ffffffc080020688>] __arm64_sys_mmap+0x38/0x58 [<ffffffc080028fc0>] invoke_syscall.constprop.0+0x58/0x100 This due to the fact that we do not free the "sg_table" itself while freeing up the SG table and data pages. Fix this by freeing the sg_table in tmc_free_sg_table(). Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Cc: Mike Leach <mike.leach(a)linaro.org> Cc: James Clark <james.clark(a)arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> --- drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c index e75428fa1592..610ad51cda65 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c @@ -261,6 +261,7 @@ void tmc_free_sg_table(struct tmc_sg_table *sg_table) { tmc_free_table_pages(sg_table); tmc_free_data_pages(sg_table); + kfree(sg_table); } EXPORT_SYMBOL_GPL(tmc_free_sg_table); @@ -342,7 +343,6 @@ struct tmc_sg_table *tmc_alloc_sg_table(struct device *dev, rc = tmc_alloc_table_pages(sg_table); if (rc) { tmc_free_sg_table(sg_table); - kfree(sg_table); return ERR_PTR(rc); } -- 2.34.1

4 weeks, 1 day

Re: [PATCH v2 RESEND] Coresight: Set correct cs_mode for TPDM to fix disable issue

by Suzuki K Poulose

On Mon, 12 Aug 2024 12:30:43 +0800, Jie Gan wrote: > The coresight_disable_source_sysfs function should verify the > mode of the coresight device before disabling the source. > > However, the mode for the TPDM device is always set to > CS_MODE_DISABLED, resulting in the check consistently failing. > As a result, TPDM cannot be properly disabled. > > [...] Applied, thanks! [1/1] Coresight: Set correct cs_mode for TPDM to fix disable issue https://git.kernel.org/coresight/c/14f5fa9b5fcbe2b3d5098893aba6ad62254d2ef6 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight August 2024