CoreSight August 2024

coresight@lists.linaro.org

9 participants
48 discussions

[PATCH V2 0/5] arm-cs-trace-disasm.py/perf must accommodate non-zero DSO text offset

by Steve Clevenger

Changes in V2: - Updated mailing list distribution Fedora 37 distributed shared binary and executable mapped files show a zero text section offset. Starting with the Fedora 38 distribution, the shared binary and executable mapped files show a non-zero text section offset for some binaries. The text offset parameter is never passed into the arm-cs-trace-disasm.py script to allow the script to adjust the start/end address range passed to objdump. This adjustment is required to correctly offset into the dso text section. Not doing so results in an incorrect user instruction trace display for Fedora 38 (and later) user trace output. Steve Clevenger (5): Add dso__is_pie call to identify ELF PIE Add dso__is_pie prototype Force MAPPING_TYPE__IDENTIY for PIE Add map pgoff to python dictionary based on MAPPING_TYPE Adjust objdump start/end range per map pgoff parameter .../scripts/python/arm-cs-trace-disasm.py | 17 +++++- tools/perf/util/map.c | 5 +- .../scripting-engines/trace-event-python.c | 13 +++- tools/perf/util/symbol-elf.c | 60 +++++++++++++++++++ tools/perf/util/symbol.h | 1 + 5 files changed, 90 insertions(+), 6 deletions(-) -- 2.25.1

7 months, 3 weeks

[PATCH V2 1/5] Add dso__is_pie call to identify ELF PIE

by Steve Clevenger

Changes in V2: - Updated mailing list distribution - Decrease indentation, add null pointer checks per Leo Yan review Add dso__is_pie global to read the .dynamic section DT_FLAGS_1 entry for the DF_1_PIE flag. This identifies position executable code. Signed-off-by: Steve Clevenger <scclevenger(a)os.amperecomputing.com> --- tools/perf/util/symbol-elf.c | 60 ++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index e398abfd13a0..0e49c1345a67 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -662,6 +662,66 @@ static int dso__synthesize_plt_got_symbols(struct dso *dso, Elf *elf, return err; } +/* + * Check dynamic section DT_FLAGS_1 for a Position Independent + * Executable (PIE). + */ +bool dso__is_pie(struct dso *dso) +{ + Elf *elf = NULL; + Elf_Scn *scn = NULL; + GElf_Ehdr ehdr; + GElf_Shdr shdr; + bool is_pie = false; + char dso_path[PATH_MAX]; + int fd = -1; + + if (!dso || (elf_version(EV_CURRENT) == EV_NONE)) + goto exit; // false + + dso__build_id_filename(dso, dso_path, sizeof(dso_path), false); + + fd = open(dso_path, O_RDONLY); + + if (fd < 0) { + pr_debug("%s: cannot read cached %s.\n", __func__, dso_path); + goto exit; // false + } + + elf = elf_begin(fd, ELF_C_READ, NULL); + gelf_getehdr(elf, &ehdr); + + if (ehdr.e_type == ET_DYN) { + Elf_Data *data; + GElf_Dyn *entry; + int n_entries = shdr.sh_size / sizeof(GElf_Dyn); + + scn = elf_section_by_name(elf, &ehdr, &shdr, ".dynamic", NULL); + if (!scn) + goto exit; // false + + data = (Elf_Data *) elf_getdata(scn, NULL); + if (!data || !data->d_buf) + goto exit; // false + + // check DT_FLAGS_1 + for (int i = 0; i < n_entries; i++) { + entry = ((GElf_Dyn *) data->d_buf) + i; + if (entry->d_tag == DT_FLAGS_1) { + if ((entry->d_un.d_val & DF_1_PIE) != 0) { + is_pie = true; + break; + } + } + } // end for + } + + elf_end(elf); + close(fd); +exit: + return is_pie; +} + /* * We need to check if we have a .dynsym, so that we can handle the * .plt, synthesizing its symbols, that aren't on the symtabs (be it -- 2.25.1

7 months, 3 weeks

Re: [PATCH 1/5] Add dso__is_pie call to identify ELF PIE

by Steve Clevenger

On 8/26/2024 6:13 AM, Leo Yan wrote: > Hi Steve, > > On Tue, Aug 20, 2024 at 04:11:35PM -0600, Steve Clevenger wrote: >> From: "steve.c.clevenger.ampere" <scclevenger(a)os.amperecomputing.com> >> >> Add dso__is_pie global to read the .dynamic section DT_FLAGS_1 entry for >> the DF_1_PIE flag. This identifies position executable code. >> >> Signed-off-by: steve.c.clevenger.ampere <scclevenger(a)os.amperecomputing.com> >> --- >> tools/perf/util/symbol-elf.c | 55 ++++++++++++++++++++++++++++++++++++ >> 1 file changed, 55 insertions(+) >> >> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c >> index e398abfd13a0..1d4bd222b314 100644 >> --- a/tools/perf/util/symbol-elf.c >> +++ b/tools/perf/util/symbol-elf.c >> @@ -662,6 +662,61 @@ static int dso__synthesize_plt_got_symbols(struct dso *dso, Elf *elf, >> return err; >> } >> >> +/* >> + * Check dynamic section DT_FLAGS_1 for a Position Independent >> + * Executable (PIE). >> + */ >> +bool dso__is_pie(struct dso *dso) >> +{ >> + Elf *elf = NULL; >> + Elf_Scn *scn = NULL; >> + GElf_Ehdr ehdr; >> + GElf_Shdr shdr; >> + bool is_pie = false; >> + char dso_path[PATH_MAX]; >> + int fd = -1; >> + >> + if (!dso || (elf_version(EV_CURRENT) == EV_NONE)) >> + return is_pie; // false >> + >> + dso__build_id_filename(dso, dso_path, sizeof(dso_path), false); >> + >> + fd = open(dso_path, O_RDONLY); >> + >> + if (fd < 0) { >> + pr_debug("%s: cannot read cached %s.\n", __func__, dso_path); >> + return is_pie; // false >> + } >> + >> + elf = elf_begin(fd, ELF_C_READ, NULL); >> + gelf_getehdr(elf, &ehdr); >> + >> + if (ehdr.e_type == ET_DYN) { > > The code looks good to me, just several nitpicks. > > To avoid indentation, we can firstly check the failure case and directly > exit for it. > > if (ehdr.e_type != ET_DYN) > goto exit_elf_end; > >> + scn = elf_section_by_name(elf, &ehdr, &shdr, ".dynamic", NULL); > > Ditto. > > if (!scn) > goto exit_elf_end; > >> + if (scn) { // check DT_FLAGS_1 >> + Elf_Data *data; >> + GElf_Dyn *entry; >> + int n_entries = shdr.sh_size / sizeof(GElf_Dyn); >> + >> + data = (Elf_Data *) elf_getdata(scn, NULL); > > For a safe code, it is good to check if pointers (data and > data->d_buf) are valid before dereference them. > > if (!data || !data->d_buf) > goto exit_elf_end; > > With above changes: Thanks Leo. I understand your comment about excess indentation, but I don't believe there's an excess here. Valid points about NULL pointer checks. I've made changes based on your review. Please look for V2 of this patch series. Besides addressing your comments, V2 is mostly to update the mailing lists. Steve C. > > Reviewed-by: Leo Yan <leo.yan(a)arm.com> > >> + for (int i = 0; i < n_entries; i++) { >> + entry = ((GElf_Dyn *) data->d_buf) + i; >> + if (entry->d_tag == DT_FLAGS_1) { >> + if ((entry->d_un.d_val & DF_1_PIE) != 0) { >> + is_pie = true; >> + break; >> + } >> + } >> + } // end for >> + } >> + } >> + >> + elf_end(elf); >> + close(fd); >> + >> + return is_pie; >> +} >> + >> /* >> * We need to check if we have a .dynsym, so that we can handle the >> * .plt, synthesizing its symbols, that aren't on the symtabs (be it >> -- >> 2.25.1 >> >>

7 months, 3 weeks

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?

7 months, 3 weeks

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. >

7 months, 3 weeks

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 > >

7 months, 3 weeks

[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

7 months, 3 weeks

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 >

7 months, 3 weeks

[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

7 months, 3 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

7 months, 4 weeks

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight August 2024