CoreSight

coresight@lists.linaro.org

9 participants
2378 discussions

Re: [PATCH V3 1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device()

by Anshuman Khandual

On 8/8/23 18:51, Will Deacon wrote: > On Mon, Aug 07, 2023 at 11:03:40AM +0530, Anshuman Khandual wrote: >> On 8/4/23 22:09, Will Deacon wrote: >>> On Thu, Aug 03, 2023 at 11:43:27AM +0530, Anshuman Khandual wrote: >>>> On 8/3/23 11:26, Anshuman Khandual wrote: >>>>> + /* >>>>> + * Sanity check all the GICC tables for the same interrupt >>>>> + * number. For now, only support homogeneous ACPI machines. >>>>> + */ >>>>> + for_each_possible_cpu(cpu) { >>>>> + struct acpi_madt_generic_interrupt *gicc; >>>>> + >>>>> + gicc = acpi_cpu_get_madt_gicc(cpu); >>>>> + if (gicc->header.length < len) >>>>> + return gsi ? -ENXIO : 0; >>>>> + >>>>> + this_gsi = parse_gsi(gicc); >>>>> + if (!this_gsi) >>>>> + return gsi ? -ENXIO : 0; >>>> >>>> Moved parse_gsi() return code checking to its original place just to >>>> make it similar in semantics to existing 'gicc->header.length check'. >>>> If 'gsi' is valid i.e atleast a single cpu has been probed, return >>>> -ENXIO indicating mismatch, otherwise just return 0. >>> >>> Wouldn't that still be the case without the check in this hunk? We'd run >>> into the homogeneous check and return -ENXIO from there, no? >> Although the return code will be the same i.e -ENXIO, but not for the same reason. >> >> this_gsi = parse_gsi(gicc); >> if (!this_gsi) >> return gsi ? -ENXIO : 0; >> >> This returns 0 when IRQ could not be parsed for the first cpu, but returns -ENXIO >> for subsequent cpus. Although return code -ENXIO here still indicates IRQ parsing >> to have failed. >> >> } else if (hetid != this_hetid || gsi != this_gsi) { >> pr_warn("ACPI: %s: must be homogeneous\n", pdev->name); >> return -ENXIO; >> } >> >> This returns -ENXIO when there is a IRQ mismatch. But if the above check is not >> there, -ENXIO return code here could not be classified into IRQ parse problem or >> mismatch without looking into the IRQ value. > > Sorry, but I don't understand your point here. If any of this fails, there's > going to be some debugging needed to look at the ACPI tables; the only > difference with my suggestion is that you'll get a message indicating that > the devices aren't homogeneous, which I think is helpful. I dont have strong opinion either way. Hence will move 'this_gsi' check inside the !gsi conditional check like you had suggested earlier.

1 year, 10 months

[PATCH] coresight: etm: Make cycle count threshold user configurable

by Anshuman Khandual

Cycle counting is enabled, when requested and supported but with a default threshold value ETM_CYC_THRESHOLD_DEFAULT i.e 0x100 getting into TRCCCCTLR, representing the minimum interval between cycle count trace packets. This makes cycle threshold user configurable, from the user space via perf event attributes. Although it falls back using ETM_CYC_THRESHOLD_DEFAULT, in case no explicit request. As expected it creates a sysfs file as well. /sys/bus/event_source/devices/cs_etm/format/cc_threshold New 'cc_threshold' uses 'event->attr.config3' as no more space is available in 'event->attr.config1' or 'event->attr.config2'. Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: James Clark <james.clark(a)arm.com> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-doc(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual(a)arm.com> --- Changes in V2: - s/treshhold/threshhold Changes in V1: https://lore.kernel.org/all/20230804044720.1478900-1-anshuman.khandual@arm.… Documentation/trace/coresight/coresight.rst | 2 ++ drivers/hwtracing/coresight/coresight-etm-perf.c | 2 ++ drivers/hwtracing/coresight/coresight-etm4x-core.c | 12 ++++++++++-- 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index 4a71ea6cb390..a698b07206b5 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -624,6 +624,8 @@ They are also listed in the folder /sys/bus/event_source/devices/cs_etm/format/ * - timestamp - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP <coresight-timestamp>` + * - cc_threshold + - Cycle count threshold value How to use the STM module ------------------------- diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c index 5ca6278baff4..09f75dffae60 100644 --- a/drivers/hwtracing/coresight/coresight-etm-perf.c +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c @@ -68,6 +68,7 @@ PMU_FORMAT_ATTR(preset, "config:0-3"); PMU_FORMAT_ATTR(sinkid, "config2:0-31"); /* config ID - set if a system configuration is selected */ PMU_FORMAT_ATTR(configid, "config2:32-63"); +PMU_FORMAT_ATTR(cc_threshold, "config3:0-11"); /* @@ -101,6 +102,7 @@ static struct attribute *etm_config_formats_attr[] = { &format_attr_preset.attr, &format_attr_configid.attr, &format_attr_branch_broadcast.attr, + &format_attr_cc_threshold.attr, NULL, }; diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 9d186af81ea0..a353c0784bab 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -644,7 +644,7 @@ static int etm4_parse_event_config(struct coresight_device *csdev, struct etmv4_config *config = &drvdata->config; struct perf_event_attr *attr = &event->attr; unsigned long cfg_hash; - int preset; + int preset, cc_threshold; /* Clear configuration from previous run */ memset(config, 0, sizeof(struct etmv4_config)); @@ -667,7 +667,15 @@ static int etm4_parse_event_config(struct coresight_device *csdev, if (attr->config & BIT(ETM_OPT_CYCACC)) { config->cfg |= TRCCONFIGR_CCI; /* TRM: Must program this for cycacc to work */ - config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT; + cc_threshold = attr->config3 & ETM_CYC_THRESHOLD_MASK; + if (cc_threshold) { + if (cc_threshold < drvdata->ccitmin) + config->ccctlr = drvdata->ccitmin; + else + config->ccctlr = cc_threshold; + } else { + config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT; + } } if (attr->config & BIT(ETM_OPT_TS)) { /* -- 2.25.1

1 year, 10 months

[PATCH v4 0/6] perf vendor events arm64: Update N2 and V2 metrics and events using Arm telemetry repo

by James Clark

This is a completely new approach from V3 [1], although the metrics and event descriptions are autogenerated, the topdown metrics have been manually edited to use #no_stall_errata. This removes the need to duplicate the whole set of JSONs when only the topdown metrics are different between N2 and V2. The CPU ID comparison function still needs to change so that the new literal can compare on versions, but now no change is needed to mapfile or the PMU event generation code because we still only support one set of JSONs per CPU. [1]: https://lore.kernel.org/lkml/20230711100218.1651995-1-james.clark@arm.com/ ------ Changes since v3: * Instead of duplicating all the metrics, add a new expression literal that can be used to share the same metrics between N2 and V2 * Move tests to arch/arm64/tests * Remove changes from jevents.py and mapfile.csv Changes since v2: * version -> variant in second commit message * Add a bit more detail about version matching in the second commit message * Update the comments in pmu-events/arch/arm64/mapfile.csv to say that variant and revision fields are now used * Increase the CC list Changes since v1: * Split last change into two so it doesn't hit the mailing list size limit James Clark (6): perf: cs-etm: Don't duplicate FIELD_GET() perf arm64: Allow version comparisons of CPU IDs perf test: Add a test for the new Arm CPU ID comparison behavior perf vendor events arm64: Update scale units and descriptions of common topdown metrics perf vendor events arm64: Update stall_slot workaround for N2 r0p3 perf vendor events arm64: Update N2 and V2 metrics and events using Arm telemetry repo tools/perf/arch/arm64/include/arch-tests.h | 3 + tools/perf/arch/arm64/tests/Build | 1 + tools/perf/arch/arm64/tests/arch-tests.c | 4 + tools/perf/arch/arm64/tests/cpuid-match.c | 38 ++ tools/perf/arch/arm64/util/header.c | 64 ++- tools/perf/arch/arm64/util/pmu.c | 21 + .../arch/arm64/arm/neoverse-n2-v2/branch.json | 8 - .../arch/arm64/arm/neoverse-n2-v2/bus.json | 18 +- .../arch/arm64/arm/neoverse-n2-v2/cache.json | 155 -------- .../arm64/arm/neoverse-n2-v2/exception.json | 45 ++- .../arm/neoverse-n2-v2/fp_operation.json | 22 ++ .../arm64/arm/neoverse-n2-v2/general.json | 10 + .../arm64/arm/neoverse-n2-v2/instruction.json | 143 ------- .../arm64/arm/neoverse-n2-v2/l1d_cache.json | 54 +++ .../arm64/arm/neoverse-n2-v2/l1i_cache.json | 14 + .../arm64/arm/neoverse-n2-v2/l2_cache.json | 50 +++ .../arm64/arm/neoverse-n2-v2/l3_cache.json | 22 ++ .../arm64/arm/neoverse-n2-v2/ll_cache.json | 10 + .../arch/arm64/arm/neoverse-n2-v2/memory.json | 39 +- .../arm64/arm/neoverse-n2-v2/metrics.json | 365 ++++++++++-------- .../arm64/arm/neoverse-n2-v2/pipeline.json | 23 -- .../arm64/arm/neoverse-n2-v2/retired.json | 30 ++ .../arch/arm64/arm/neoverse-n2-v2/spe.json | 12 +- .../arm/neoverse-n2-v2/spec_operation.json | 110 ++++++ .../arch/arm64/arm/neoverse-n2-v2/stall.json | 30 ++ .../arch/arm64/arm/neoverse-n2-v2/sve.json | 50 +++ .../arch/arm64/arm/neoverse-n2-v2/tlb.json | 66 ++++ .../arch/arm64/arm/neoverse-n2-v2/trace.json | 27 +- tools/perf/pmu-events/arch/arm64/sbsa.json | 24 +- tools/perf/util/cs-etm.c | 14 +- tools/perf/util/expr.c | 4 + tools/perf/util/pmu.c | 6 + tools/perf/util/pmu.h | 1 + 33 files changed, 894 insertions(+), 589 deletions(-) create mode 100644 tools/perf/arch/arm64/tests/cpuid-match.c delete mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/branch.json delete mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/cache.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/fp_operation.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/general.json delete mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/instruction.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/l1d_cache.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/l1i_cache.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/l2_cache.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/l3_cache.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/ll_cache.json delete mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/pipeline.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/retired.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/spec_operation.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/stall.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/sve.json create mode 100644 tools/perf/pmu-events/arch/arm64/arm/neoverse-n2-v2/tlb.json -- 2.34.1

1 year, 10 months

Re: [bug report] coresight: etm4x: Change etm4_platform_driver driver for MMIO devices

by Anshuman Khandual

Hello Dan, On 7/29/23 12:50, Dan Carpenter wrote: > Hello Anshuman Khandual, > > The patch 73d779a03a76: "coresight: etm4x: Change > etm4_platform_driver driver for MMIO devices" from Jul 10, 2023 > (linux-next), leads to the following Smatch static checker warning: > > drivers/hwtracing/coresight/coresight-etm4x-core.c:2272 etm4_remove_platform_dev() > error: we previously assumed 'drvdata' could be null (see line 2268) > > drivers/hwtracing/coresight/coresight-etm4x-core.c > 2264 static int __exit etm4_remove_platform_dev(struct platform_device *pdev) > 2265 { > 2266 struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev); > 2267 > 2268 if (drvdata) > > This check can probably be removed, right? etm4_remove_dev(drvdata) cannot be called if drvdata is NULL. But there might be an implicit assumption that 'drvdata' could never be NULL in this path. > > 2269 etm4_remove_dev(drvdata); > 2270 pm_runtime_disable(&pdev->dev); > 2271 > --> 2272 if (drvdata->pclk) > > Not checked here We could either have the following change which ensures that 'drvdata' is checked again before the clock is handled. diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 703b6fcbb6a5..9d186af81ea0 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -2267,11 +2267,13 @@ static int __exit etm4_remove_platform_dev(struct platform_device *pdev) if (drvdata) etm4_remove_dev(drvdata); - pm_runtime_disable(&pdev->dev); - if (drvdata->pclk) - clk_put(drvdata->pclk); + pm_runtime_disable(&pdev->dev); + if (drvdata) { + if (drvdata->pclk && !IS_ERR(drvdata->pclk)) + clk_put(drvdata->pclk); + } return 0; } OR remove the first drvdata check as suggested. diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 703b6fcbb6a5..6e1ffddbd4be 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -2265,11 +2265,9 @@ static int __exit etm4_remove_platform_dev(struct platform_device *pdev) { struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev); - if (drvdata) - etm4_remove_dev(drvdata); + etm4_remove_dev(drvdata); pm_runtime_disable(&pdev->dev); - - if (drvdata->pclk) + if (drvdata->pclk && !IS_ERR(drvdata->pclk) clk_put(drvdata->pclk); return 0; > > 2273 clk_put(drvdata->pclk); > 2274 > 2275 return 0; > 2276 } Also adding Suzuki and James for their input. - Anshuman

1 year, 10 months

[PATCH V3 0/4] coresight: trbe: Enable ACPI based devices

by Anshuman Khandual

This series enables detection of ACPI based TRBE devices via a stand alone purpose built representative platform device. But as a pre-requisite this changes coresight_platform_data structure assignment for the TRBE device. This series is based on v6.5-rc4 kernel, is also dependent on the following EDK2 changes posted earlier by Sami. https://edk2.groups.io/g/devel/message/107239 https://edk2.groups.io/g/devel/message/107241 Changes in V3: - Changed ARMV8_TRBE_PDEV_NAME from "arm-trbe-acpi" into "arm,trbe" - Dropped local variable 'matched' - Replaced 'matched' with 'valid gsi' as being already matched once - Moved find_acpi_cpu_topology_hetero_id() outside conditional check Changes in V2: https://lore.kernel.org/all/20230801094052.750416-1-anshuman.khandual@arm.c… - Refactored arm_spe_acpi_register_device() in a separate patch - Renamed trbe_acpi_resources as trbe_resources - Renamed trbe_acpi_dev as trbe_dev Changes in V1: https://lore.kernel.org/all/20230728112733.359620-1-anshuman.khandual@arm.c… Cc: Sami Mujawar <sami.mujawar(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: James Clark <james.clark(a)arm.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (4): arm_pmu: acpi: Refactor arm_spe_acpi_register_device() arm_pmu: acpi: Add a representative platform device for TRBE coresight: trbe: Add a representative coresight_platform_data for TRBE coresight: trbe: Enable ACPI based TRBE devices arch/arm64/include/asm/acpi.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 15 +- drivers/hwtracing/coresight/coresight-trbe.h | 1 + drivers/perf/arm_pmu_acpi.c | 142 +++++++++++++------ include/linux/perf/arm_pmu.h | 1 + 5 files changed, 119 insertions(+), 43 deletions(-) -- 2.25.1

1 year, 10 months

Re: [PATCH V3 1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device()

by Anshuman Khandual

On 8/4/23 22:09, Will Deacon wrote: > On Thu, Aug 03, 2023 at 11:43:27AM +0530, Anshuman Khandual wrote: >> >> >> On 8/3/23 11:26, Anshuman Khandual wrote: >>> + /* >>> + * Sanity check all the GICC tables for the same interrupt >>> + * number. For now, only support homogeneous ACPI machines. >>> + */ >>> + for_each_possible_cpu(cpu) { >>> + struct acpi_madt_generic_interrupt *gicc; >>> + >>> + gicc = acpi_cpu_get_madt_gicc(cpu); >>> + if (gicc->header.length < len) >>> + return gsi ? -ENXIO : 0; >>> + >>> + this_gsi = parse_gsi(gicc); >>> + if (!this_gsi) >>> + return gsi ? -ENXIO : 0; >> >> Hello Will, >> >> Moved parse_gsi() return code checking to its original place just to >> make it similar in semantics to existing 'gicc->header.length check'. >> If 'gsi' is valid i.e atleast a single cpu has been probed, return >> -ENXIO indicating mismatch, otherwise just return 0. > > Wouldn't that still be the case without the check in this hunk? We'd run > into the homogeneous check and return -ENXIO from there, no? Although the return code will be the same i.e -ENXIO, but not for the same reason. this_gsi = parse_gsi(gicc); if (!this_gsi) return gsi ? -ENXIO : 0; This returns 0 when IRQ could not be parsed for the first cpu, but returns -ENXIO for subsequent cpus. Although return code -ENXIO here still indicates IRQ parsing to have failed. } else if (hetid != this_hetid || gsi != this_gsi) { pr_warn("ACPI: %s: must be homogeneous\n", pdev->name); return -ENXIO; } This returns -ENXIO when there is a IRQ mismatch. But if the above check is not there, -ENXIO return code here could not be classified into IRQ parse problem or mismatch without looking into the IRQ value.

1 year, 10 months

Re: [RFC PATCH 0/3] coresight: Support exclude_guest with Feat_TRF and nVHE

by Suzuki K Poulose

Hi Marc On 04/08/2023 20:09, Marc Zyngier wrote: > On Fri, 04 Aug 2023 11:13:10 +0100, > James Clark <james.clark(a)arm.com> wrote: >> >> Hi, >> >> I'm looking for help in testing this and for feedback on whether it's >> useful to anyone. Testing it requires hardware that has Feat_TRF (v8.4) >> but no TRBE. This is because TRBE usage is disabled in nVHE guests. >> >> I don't currently have any access to any hardware, and the FVP model >> can only do self hosted trace using TRBE. >> >> Currently with nVHE you would always get trace from guests, and >> filtering out isn't possible without this patchset. In comparison, with >> VHE guests, they never generate guest trace without [1]. I think the >> existence of trace rather than lack of could suggest that this change is >> less useful than [1]. Also the restricted set of hardware that it works >> on supports that too. > > It'd be nice to have some sort of feature parity, but it seems like a > vanishingly small target of users having access to an ETM sink. > >> >> Apart from compilation and checking that the exclude guest settings >> are correctly programmed on guest switch, this is untested by me. > > I'll have a look at the series, but none of my HW fits in this > description (my ARMv8.4+ boxes don't have any form of tracing). While I have your attention, we have another series that manages the trace filtering for Guests on VHE, completely within the Coresight etm4x driver here [0]. I personally think, it is good to have the guest filtering for both nVHE and VHE under the KVM control, like we do in this series. I would like your opinion on this. [0] https://lkml.kernel.org/r/20230804085219.260790-1-james.clark@arm.com Suzuki > > Thanks, > > M. >

1 year, 10 months

[RFC PATCH 0/3] coresight: Support exclude_guest with Feat_TRF and nVHE

by James Clark

Hi, I'm looking for help in testing this and for feedback on whether it's useful to anyone. Testing it requires hardware that has Feat_TRF (v8.4) but no TRBE. This is because TRBE usage is disabled in nVHE guests. I don't currently have any access to any hardware, and the FVP model can only do self hosted trace using TRBE. Currently with nVHE you would always get trace from guests, and filtering out isn't possible without this patchset. In comparison, with VHE guests, they never generate guest trace without [1]. I think the existence of trace rather than lack of could suggest that this change is less useful than [1]. Also the restricted set of hardware that it works on supports that too. Apart from compilation and checking that the exclude guest settings are correctly programmed on guest switch, this is untested by me. Applies to kvmarm/next (3b4e3afb2032) [1]: https://lore.kernel.org/linux-arm-kernel/20230804085219.260790-3-james.clar… James Clark (3): arm64: KVM: Add support for exclude_guest and exclude_host for ETM arm64: KVM: Support exclude_guest for Coresight trace in nVHE coresight: Support exclude_guest with Feat_TRF and nVHE arch/arm64/include/asm/kvm_host.h | 10 +++- arch/arm64/kvm/Makefile | 1 + arch/arm64/kvm/arm.c | 1 + arch/arm64/kvm/debug.c | 7 +++ arch/arm64/kvm/etm.c | 48 ++++++++++++++++ arch/arm64/kvm/hyp/nvhe/debug-sr.c | 56 +++++++++++++++++-- .../hwtracing/coresight/coresight-etm-perf.c | 4 ++ include/kvm/etm.h | 43 ++++++++++++++ 8 files changed, 165 insertions(+), 5 deletions(-) create mode 100644 arch/arm64/kvm/etm.c create mode 100644 include/kvm/etm.h -- 2.34.1

1 year, 10 months

Re: [PATCH 1/2] arm64/sysreg: Move TRFCR definitions to sysreg

by James Clark

On 04/08/2023 13:10, Mark Brown wrote: > On Fri, Aug 04, 2023 at 09:52:16AM +0100, James Clark wrote: > >> TRFCR_EL2_CX needs to become TRFCR_ELx_CX to avoid unnecessary >> duplication and make the SysregFields block re-usable. > > That field is only present in the EL2 version. I would tend to leave > the registers split for that reason, there's some minor potential for > confusion if people refer to the sysreg file rather than the docs, or > potentially confuse some future automation. However that's not a super > strongly held opinion. > True, the potential for confusion is a good reason to not try to avoid duplication. Probably helps if it is ever auto generated or validated as well. I could update it on the next version. But do I leave all the existing _ELx usages in the code, or change them all to _EL1 (Except CX_EL2)? To leave them as _ELx sysreg would look like this, even though _EL1 would probably be more accurate: SysregFields TRFCR_EL2 Res0 63:7 UnsignedEnum 6:5 TS 0b0001 VIRTUAL 0b0010 GUEST_PHYSICAL 0b0011 PHYSICAL EndEnum Res0 4 Field 3 CX Res0 2 Field 1 E2TRE Field 0 E0TRE EndSysregFields SysregFields TRFCR_ELx Res0 63:7 UnsignedEnum 6:5 TS 0b0001 VIRTUAL 0b0010 GUEST_PHYSICAL 0b0011 PHYSICAL EndEnum Res0 4:2 Field 1 ExTRE Field 0 E0TRE EndSysregFields Sysreg TRFCR_EL1 3 0 1 2 1 Fields TRFCR_ELx EndSysreg Sysreg TRFCR_EL2 3 4 1 2 1 Fields TRFCR_EL2 EndSysreg Sysreg TRFCR_EL12 3 5 1 2 1 Fields TRFCR_ELx EndSysreg > Otherwise this checks out against DDI0601 2023-06: > > Reviewed-by: Mark Brown <broonie(a)kernel.org> Thanks for the review

1 year, 10 months

Re: [PATCH -next] coresight: dummy: simplify the code with module_platform_driver

by Suzuki K Poulose

On Fri, 4 Aug 2023 17:27:09 +0800, Yang Yingliang wrote: > The init/exit() of driver only calls platform_driver_register/unregister, > it can be simpilfied with module_platform_driver. > > Applied, thanks! [1/1] coresight: dummy: simplify the code with module_platform_driver https://git.kernel.org/coresight/c/28a03fae6e524d39fec14fea1ee67b86f4870658 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

1 year, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight