This series adds support for the trace performance monitoring and
diagnostics hardware (TPDM and TPDA). It is composed of two major
elements.
a) Changes for original coresight framework to support for TPDM and TPDA.
b) Add driver code for TPDM and TPDA.
Introduction of changes for original coresight framework
Support TPDM as new coresight source.
Since only STM and ETM are supported as coresight source originally.
TPDM is a newly added coresight source. We need to change
the original way of saving coresight path to support more types source
for coresight driver.
The following patch is to add support more coresight sources.
coresight: core: Use IDR for non-cpu bound sources' paths.
Introduction of TPDM and TPDA
TPDM - The trace performance monitoring and diagnostics monitor or TPDM in
short serves as data collection component for various dataset types
specified in the QPMDA(Qualcomm performance monitoring and diagnostics
architecture) spec. The primary use case of the TPDM is to collect data
from different data sources and send it to a TPDA for packetization,
timestamping and funneling.
Coresight: Add coresight TPDM source driver
dt-bindings: arm: Adds CoreSight TPDM hardware definitions
coresight-tpdm: Add DSB dataset support
coresight-tpdm: Add integration test support
docs: sysfs: coresight: Add sysfs ABI documentation for TPDM
TPDA - The trace performance monitoring and diagnostics aggregator or
TPDA in short serves as an arbitration and packetization engine for the
performance monitoring and diagnostics network as specified in the QPMDA
(Qualcomm performance monitoring and diagnostics architecture)
specification. The primary use case of the TPDA is to provide
packetization, funneling and timestamping of Monitor data as specified
in the QPMDA specification.
The following patch is to add driver for TPDA.
Coresight: Add TPDA link driver
dt-bindings: arm: Adds CoreSight TPDA hardware definitions
The last patch of this series is a device tree modification, which add
the TPDM and TPDA configuration to device tree for validating.
ARM: dts: msm: Add coresight components for SM8250
ARM: dts: msm: Add tpdm mm/prng for sm8250
Once this series patches are applied properly, the tpdm and tpda nodes
should be observed at the coresight path /sys/bus/coresight/devices
e.g.
/sys/bus/coresight/devices # ls -l | grep tpd
tpda0 -> ../../../devices/platform/soc(a)0/6004000.tpda/tpda0
tpdm0 -> ../../../devices/platform/soc(a)0/6c08000.mm.tpdm/tpdm0
We can use the commands are similar to the below to validate TPDMs.
Enable coresight sink first.
echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source
echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test
echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test
The test data will be collected in the coresight sink which is enabled.
If rwp register of the sink is keeping updating when do
integration_test (by cat tmc_etf0/mgmt/rwp), it means there is data
generated from TPDM to sink.
There must be a tpda between tpdm and the sink. When there are some
other trace event hw components in the same HW block with tpdm, tpdm
and these hw components will connect to the coresight funnel. When
there is only tpdm trace hw in the HW block, tpdm will connect to
tpda directly.
+---------------+ +-------------+
| tpdm@6c08000 | |tpdm@684C000 |
+-------|-------+ +------|------+
| |
+-------|-------+ |
| funnel@6c0b000| |
+-------|-------+ |
| |
+-------|-------+ |
|funnel@6c2d000 | |
+-------|-------+ |
| |
| +---------------+ |
+----- tpda@6004000 -----------+
+-------|-------+
|
+-------|-------+
|funnel@6005000 |
+---------------+
This patch series depends on patch series
"coresight: Add new API to allocate trace source ID values".
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20220308205000.…
Changes from V10:
1. Change dev_info to dev_dbg in TPDM/TPDA drivers. -- Suzuki K Poulose <suzuki.poulose(a)arm.com>
2. Merge sysfs API change of integration_test to integration_test driver
change. -- -- Suzuki K Poulose <suzuki.poulose(a)arm.com>
Mao Jinlong (9):
coresight: core: Use IDR for non-cpu bound sources' paths.
Coresight: Add coresight TPDM source driver
dt-bindings: arm: Adds CoreSight TPDM hardware definitions
coresight-tpdm: Add DSB dataset support
coresight-tpdm: Add integration test support
Coresight: Add TPDA link driver
dt-bindings: arm: Adds CoreSight TPDA hardware definitions
arm64: dts: qcom: sm8250: Add coresight components
arm64: dts: qcom: sm8250: Add tpdm mm/prng
.../testing/sysfs-bus-coresight-devices-tpdm | 13 +
.../bindings/arm/qcom,coresight-tpda.yaml | 111 +++
.../bindings/arm/qcom,coresight-tpdm.yaml | 93 +++
MAINTAINERS | 2 +
arch/arm64/boot/dts/qcom/sm8250.dtsi | 671 ++++++++++++++++++
drivers/hwtracing/coresight/Kconfig | 23 +
drivers/hwtracing/coresight/Makefile | 2 +
drivers/hwtracing/coresight/coresight-core.c | 42 +-
drivers/hwtracing/coresight/coresight-tpda.c | 206 ++++++
drivers/hwtracing/coresight/coresight-tpda.h | 35 +
drivers/hwtracing/coresight/coresight-tpdm.c | 259 +++++++
drivers/hwtracing/coresight/coresight-tpdm.h | 62 ++
include/linux/coresight.h | 1 +
13 files changed, 1508 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
create mode 100644 drivers/hwtracing/coresight/coresight-tpda.c
create mode 100644 drivers/hwtracing/coresight/coresight-tpda.h
create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.c
create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.h
--
2.17.1
On Thu, Jun 30, 2022 at 05:13:17PM +0700, Bagas Sanjaya wrote:
> Stephen Rothwell reported htmldocs warning:
>
> Documentation/trace/coresight/coresight.rst:133: WARNING: Inline emphasis start-string without end-string.
>
> The warning above is due to unescaped wildcard asterisk (*) on CoreSight
> devicetree binding filename, which confuses Sphinx as emphasis instead.
>
> Escape the wildcard to fix the warning.
>
> Link: https://lore.kernel.org/linux-next/20220630173801.41bf22a2@canb.auug.org.au/
> Fixes: 3c15fddf312120 ("dt-bindings: arm: Convert CoreSight bindings to DT schema")
> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
> 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: Jonathan Corbet <corbet(a)lwn.net>
> Cc: Rob Herring <robh(a)kernel.org>
> Cc: coresight(a)lists.linaro.org
> Cc: linux-arm-kernel(a)lists.infradead.org
> Cc: linux-next(a)vger.kernel.org
> Cc: linux-kernel(a)vger.kernel.org
> Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
> Signed-off-by: Bagas Sanjaya <bagasdotme(a)gmail.com>
> ---
> Documentation/trace/coresight/coresight.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied.
Thanks,
Mathieu
> diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst
> index 529b7c80e6f353..1644a0244ad10a 100644
> --- a/Documentation/trace/coresight/coresight.rst
> +++ b/Documentation/trace/coresight/coresight.rst
> @@ -130,7 +130,7 @@ Misc:
> Device Tree Bindings
> --------------------
>
> -See Documentation/devicetree/bindings/arm/arm,coresight-*.yaml for details.
> +See Documentation/devicetree/bindings/arm/arm,coresight-\*.yaml for details.
>
> As of this writing drivers for ITM, STMs and CTIs are not provided but are
> expected to be added as the solution matures.
>
> base-commit: 6cc11d2a1759275b856e464265823d94aabd5eaf
> --
> An old man doll... just what I always wanted! - Clara
>
Issues with lockdep possible deadlock scenarios have been reported when using the
coresight configfs interface handling complex configuration, when unloading modules.
These are due to holding the main configuration mutex during configfs register, but
taking it later when accessing configfs files.
The patches improve the clean up of configurations and update load and unload of
configurations and initialisation of configfs to fix the locking mechanisms.
Applies to coresight/next (5.19-rc2)
Tested on DB410c (with patch [0] also applied to fix separate console boot issue).
Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules")
Reported-by: Suzuki Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
[0] https://lkml.kernel.org/r/20220614124618.2830569-1-suzuki.poulose@arm.com
Changes since v4:
No functional change - fixed comment in patch header 1/2 and error string format to
remove checkpatch warning as requested by Mathieu.
Changes since v3:
Addressed minor issues raised by Suzuki.
Changes since v2:
Added additional work to fix load and unload ops after issue recurred
due to file access.
Mike Leach (2):
coresight: configfs: Fix unload of configurations on module exit
coresight: syscfg: Update load and unload operations
.../hwtracing/coresight/coresight-config.h | 2 +
.../hwtracing/coresight/coresight-syscfg.c | 298 +++++++++++++++---
.../hwtracing/coresight/coresight-syscfg.h | 13 +
3 files changed, 261 insertions(+), 52 deletions(-)
--
2.17.1
Issues with lockdep possible deadlock scenarios have been reported when using the
coresight configfs interface handling complex configuration, when unloading modules.
These are due to holding the main configuration mutex during configfs register, but
taking it later when accessing configfs files.
The patches improve the clean up of configurations and update load and unload of
configurations and initialisation of configfs to fix the locking mechanisms.
Applies to coresight/next (5.19-rc2)
Tested on DB410c (with patch [0] also applied to fix separate console boot issue).
Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules")
Reported-by: Suzuki Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
[0] https://lkml.kernel.org/r/20220614124618.2830569-1-suzuki.poulose@arm.com
Changes since v3:
Addressed minor issues raised by Suzuki.
Changes since v2:
Added additional work to fix load and unload ops after issue recurred
due to file access.
Mike Leach (2):
coresight: configfs: Fix unload of configurations on module exit
coresight: syscfg: Update load and unload operations
.../hwtracing/coresight/coresight-config.h | 2 +
.../hwtracing/coresight/coresight-syscfg.c | 299 +++++++++++++++---
.../hwtracing/coresight/coresight-syscfg.h | 13 +
3 files changed, 262 insertions(+), 52 deletions(-)
--
2.17.1
Hi Nick,
Thanks for the rework.
On 23/06/2022 18:41, Nick Desaulniers wrote:
> When the following configs are enabled:
> * CORESIGHT
> * CORESIGHT_SOURCE_ETM4X
> * UBSAN
> * UBSAN_TRAP
>
> Clang fails assemble the kernel with the error:
> <instantiation>:1:7: error: expected constant expression in '.inst' directive
> .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
> ^
> drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in
> macro instantiation
> etm4x_relaxed_read32(csa, TRCCNTVRn(i));
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from
> macro 'etm4x_relaxed_read32'
> read_etm4x_sysreg_offset((offset), false)))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded
> from macro 'read_etm4x_sysreg_offset'
> __val = read_etm4x_sysreg_const_offset((offset)); \
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from
> macro 'read_etm4x_sysreg_const_offset'
> READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from
> macro 'READ_ETM4x_REG'
> read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
> ^
> arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro
> 'read_sysreg_s'
> asm volatile(__mrs_s("%0", r) : "=r" (__val)); \
> ^
> arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
> " mrs_s " v ", " __stringify(r) "\n" \
> ^
>
> Consider the definitions of TRCSSCSRn and TRCCNTVRn:
> drivers/hwtracing/coresight/coresight-etm4x.h:56
> #define TRCCNTVRn(n) (0x160 + (n * 4))
> drivers/hwtracing/coresight/coresight-etm4x.h:81
> #define TRCSSCSRn(n) (0x2A0 + (n * 4))
>
> Where the macro parameter is expanded to i; a loop induction variable
> from etm4_disable_hw.
>
> When any compiler can determine that loops may be unrolled, then the
> __builtin_constant_p check in read_etm4x_sysreg_offset() defined in
> drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This
> can lead to the expression `(0x160 + (i * 4))` being passed to
> read_etm4x_sysreg_const_offset. Via the trace above, this is passed
> through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it
> is string-ified and used directly in inline asm.
>
> Regardless of which compiler or compiler options determine whether a
> loop can or can't be unrolled, which determines whether
> __builtin_constant_p evaluates to true when passed an expression using a
> loop induction variable, it is NEVER safe to allow the preprocessor to
> construct inline asm like:
> asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val));
> ^ expected constant expression
>
> Replace unsafe uses of calls to etm4x_relaxed_read32 with
> csdev_access_relaxed_read32 when the parameter is an expression that
> would be invalid inline asm so that it does not depend on the ability of
> the compiler to optimize __builtin_constant_p of the expression to true.
> Only when the second parameter of etm4x_relaxed_read32 expands to an
> expression dependent on a loop induction variable do we need to fix
> this.
>
> For such cases where the induction variable is used in an expression,
> perform the following function call replacements:
> * etm4x_relaxed_write32 -> csdev_access_relaxed_write32
> * etm4x_relaxed_write64 -> csdev_access_relaxed_write64
> * etm4x_relaxed_read32 -> csdev_access_relaxed_read32
> * etm4x_read32 -> csdev_access_read32
> * etm4x_read64 -> csdev_access_read64
>
> This is not a bug in clang; it's a potentially unsafe use of the macro
> arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1310
> Reported-by: Arnd Bergmann <arnd(a)kernel.org>
> Suggested-by: Arnd Bergmann <arnd(a)kernel.org>
> Suggested-by: Tao Zhang <quic_taozha(a)quicinc.com>
> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Hi Nick
Thanks for resending the patch. Unfortunately, this one still doesn't
address my comments in the v3 [0].
On 14/06/2022 23:02, Nick Desaulniers wrote:
> When the following configs are enabled:
> * CORESIGHT
> * CORESIGHT_SOURCE_ETM4X
> * UBSAN
> * UBSAN_TRAP
>
> Clang fails assemble the kernel with the error:
> <instantiation>:1:7: error: expected constant expression in '.inst' directive
> .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
> ^
> drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation
> etm4x_relaxed_read32(csa, TRCCNTVRn(i));
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32'
> read_etm4x_sysreg_offset((offset), false)))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset'
> __val = read_etm4x_sysreg_const_offset((offset)); \
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset'
> READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
> ^
> drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG'
> read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
> ^
> arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s'
> asm volatile(__mrs_s("%0", r) : "=r" (__val)); \
> ^
> arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
> " mrs_s " v ", " __stringify(r) "\n" \
> ^
>
> Consider the definitions of TRCSSCSRn and TRCCNTVRn:
> drivers/hwtracing/coresight/coresight-etm4x.h:56
> #define TRCCNTVRn(n) (0x160 + (n * 4))
> drivers/hwtracing/coresight/coresight-etm4x.h:81
> #define TRCSSCSRn(n) (0x2A0 + (n * 4))
>
> Where the macro parameter is expanded to i; a loop induction variable
> from etm4_disable_hw.
>
> When any compiler can determine that loops may be unrolled, then the
> __builtin_constant_p check in read_etm4x_sysreg_offset() defined in
> drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This
> can lead to the expression `(0x160 + (i * 4))` being passed to
> read_etm4x_sysreg_const_offset. Via the trace above, this is passed
> through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it
> is string-ified and used directly in inline asm.
>
> Regardless of compiler or compiler options determine whether a loop can
> or can't be unrolled, which determines whether __builtin_constant_p
> evaluates to true when passed an expression using a loop induction
> variable, it is NEVER safe to allow the preprocessor to construction
> inline asm like:
> asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val));
> ^ expected constant expression
>
> Replace unsafe uses of calls to etm4x_relaxed_read32 with
> csdev_access_read32 when the parameter is an expression that would be
> invalid inline asm so that it does not depend on the ability of the
> compiler to optimize __builtin_constant_p of the expression to true.
> Only when the second parameter of etm4x_relaxed_read32 expands to an
> expression dependent on a loop induction variable do we need to fix
> this.
>
> This is not a bug in clang; it's a potentially unsafe use of the macro
> arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1310
> Suggested-by: Arnd Bergmann <arnd(a)kernel.org>
> Suggested-by: Tao Zhang <quic_taozha(a)quicinc.com>
> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
> ---
> V1 (Arnd):
> https://lore.kernel.org/lkml/20210225094324.3542511-1-arnd@kernel.org/
>
> V2 (Arnd):
> https://lore.kernel.org/lkml/20210429145752.3218324-1-arnd@kernel.org/
>
> V3 (Tao):
> https://lore.kernel.org/lkml/1632652550-26048-1-git-send-email-quic_taozha@…
Even with this patch applied, we have many more instances left
to convert. Please could you update the patch to convert all of these ?
$ grep "(i)" coresight-etm4x* | grep -v csdev_
coresight-etm4x-core.c: * Check if TRCSSPCICRn(i) is implemented for a
given instance.
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->seq_ctrl[i], TRCSEQEVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->cntrldvr[i], TRCCNTRLDVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->cntr_ctrl[i], TRCCNTCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->cntr_val[i], TRCCNTVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->res_ctrl[i], TRCRSCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->ss_ctrl[i], TRCSSCCRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->ss_status[i], TRCSSCSRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
config->ss_pe_cmp[i], TRCSSPCICRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->addr_val[i], TRCACVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->addr_acc[i], TRCACATRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->ctxid_pid[i], TRCCIDCVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
config->vmid_val[i], TRCVMIDCVRn(i));
coresight-etm4x-core.c: state->trcseqevr[i] = etm4x_read32(csa,
TRCSEQEVRn(i));
coresight-etm4x-core.c: state->trccntrldvr[i] =
etm4x_read32(csa, TRCCNTRLDVRn(i));
coresight-etm4x-core.c: state->trccntctlr[i] = etm4x_read32(csa,
TRCCNTCTLRn(i));
coresight-etm4x-core.c: state->trccntvr[i] = etm4x_read32(csa,
TRCCNTVRn(i));
coresight-etm4x-core.c: state->trcrsctlr[i] = etm4x_read32(csa,
TRCRSCTLRn(i));
coresight-etm4x-core.c: state->trcssccr[i] = etm4x_read32(csa,
TRCSSCCRn(i));
coresight-etm4x-core.c: state->trcsscsr[i] = etm4x_read32(csa,
TRCSSCSRn(i));
coresight-etm4x-core.c: state->trcsspcicr[i] =
etm4x_read32(csa, TRCSSPCICRn(i));
coresight-etm4x-core.c: state->trcacvr[i] = etm4x_read64(csa,
TRCACVRn(i));
coresight-etm4x-core.c: state->trcacatr[i] = etm4x_read64(csa,
TRCACATRn(i));
coresight-etm4x-core.c: state->trccidcvr[i] = etm4x_read64(csa,
TRCCIDCVRn(i));
coresight-etm4x-core.c: state->trcvmidcvr[i] = etm4x_read64(csa,
TRCVMIDCVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcseqevr[i], TRCSEQEVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trccntrldvr[i], TRCCNTRLDVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trccntctlr[i], TRCCNTCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trccntvr[i], TRCCNTVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcrsctlr[i], TRCRSCTLRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcssccr[i], TRCSSCCRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcsscsr[i], TRCSSCSRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write32(csa,
state->trcsspcicr[i], TRCSSPCICRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trcacvr[i], TRCACVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trcacatr[i], TRCACATRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trccidcvr[i], TRCCIDCVRn(i));
coresight-etm4x-core.c: etm4x_relaxed_write64(csa,
state->trcvmidcvr[i], TRCVMIDCVRn(i));
[0]
https://lore.kernel.org/lkml/48162555-2a67-60bc-ea4b-8720e7b98a22@arm.com/
Kind regards
Suzuki
>
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 87299e99dabb..7c6bd85e36d4 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -836,13 +836,13 @@ static void etm4_disable_hw(void *info)
> /* read the status of the single shot comparators */
> for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> config->ss_status[i] =
> - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> + csdev_access_read32(csa, TRCSSCSRn(i));
> }
>
> /* read back the current counter values */
> for (i = 0; i < drvdata->nr_cntr; i++) {
> config->cntr_val[i] =
> - etm4x_relaxed_read32(csa, TRCCNTVRn(i));
> + csdev_access_read32(csa, TRCCNTVRn(i));
> }
>
> coresight_disclaim_device_unlocked(csdev);
> @@ -1177,7 +1177,7 @@ static void etm4_init_arch_data(void *info)
> drvdata->nr_ss_cmp = FIELD_GET(TRCIDR4_NUMSSCC_MASK, etmidr4);
> for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> drvdata->config.ss_status[i] =
> - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> + csdev_access_read32(csa, TRCSSCSRn(i));
> }
> /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> drvdata->numcidc = FIELD_GET(TRCIDR4_NUMCIDC_MASK, etmidr4);
Issues with lockdep possible deadlock scenarios have been reported when using the
coresight configfs interface handling complex configuration, when unloading modules.
These are due to holding the main configuration mutex during configfs register, but
taking it later when accessing configfs files.
The patches improve the clean up of configurations and update load and unload of
configurations and initialisation of configfs to fix the locking mechanisms.
Applies to coresight/next (5.19-rc2)
Tested on DB410c (with patch [0] also applied to fix separate console boot issue).
Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules")
Reported-by: Suzuki Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
[0] https://lkml.kernel.org/r/20220614124618.2830569-1-suzuki.poulose@arm.com
Changes since v2:
Added additional work to fix load and unload ops after issue recurred
due to file access.
Mike Leach (2):
coresight: configfs: Fix unload of configurations on module exit
coresight: syscfg: Update load and unload operations
.../hwtracing/coresight/coresight-config.h | 2 +
.../hwtracing/coresight/coresight-syscfg.c | 297 +++++++++++++++---
.../hwtracing/coresight/coresight-syscfg.h | 13 +
3 files changed, 263 insertions(+), 49 deletions(-)
--
2.17.1
coresight devices track their connections (output connections) and
hold a reference to the fwnode. When a device goes away, we walk through
the devices on the coresight bus and make sure that the references
are dropped. This happens both ways:
a) For all output connections from the device, drop the reference to
the target device via coresight_release_platform_data()
b) Iterate over all the devices on the coresight bus and drop the
reference to fwnode if *this* device is the target of the output
connection, via coresight_remove_conns()->coresight_remove_match().
However, the coresight_remove_match() doesn't clear the fwnode field,
after dropping the reference, this causes use-after-free and
additional refcount drops on the fwnode.
e.g., if we have two devices, A and B, with a connection, A -> B.
If we remove B first, B would clear the reference on B, from A
via coresight_remove_match(). But when A is removed, it still has
a connection with fwnode still pointing to B. Thus it tries to drops
the reference in coresight_release_platform_data(), raising the bells
like :
[ 91.990153] ------------[ cut here ]------------
[ 91.990163] refcount_t: addition on 0; use-after-free.
[ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144
[ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-)
crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug]
[ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53
[ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019
[ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 91.990454] pc : refcount_warn_saturate+0xa0/0x144
[ 91.990476] lr : refcount_warn_saturate+0xa0/0x144
[ 91.990496] sp : ffff80000c843640
[ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8
[ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8
[ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2
[ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40
[ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0
[ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375
[ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28
[ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572
[ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027
[ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00
[ 91.991000] Call trace:
[ 91.991012] refcount_warn_saturate+0xa0/0x144
[ 91.991034] kobject_get+0xac/0xb0
[ 91.991055] of_node_get+0x2c/0x40
[ 91.991076] of_fwnode_get+0x40/0x60
[ 91.991094] fwnode_handle_get+0x3c/0x60
[ 91.991116] fwnode_get_nth_parent+0xf4/0x110
[ 91.991137] fwnode_full_name_string+0x48/0xc0
[ 91.991158] device_node_string+0x41c/0x530
[ 91.991178] pointer+0x320/0x3ec
[ 91.991198] vsnprintf+0x23c/0x750
[ 91.991217] vprintk_store+0x104/0x4b0
[ 91.991238] vprintk_emit+0x8c/0x360
[ 91.991257] vprintk_default+0x44/0x50
[ 91.991276] vprintk+0xcc/0xf0
[ 91.991295] _printk+0x68/0x90
[ 91.991315] of_node_release+0x13c/0x14c
[ 91.991334] kobject_put+0x98/0x114
[ 91.991354] of_node_put+0x24/0x34
[ 91.991372] of_fwnode_put+0x40/0x5c
[ 91.991390] fwnode_handle_put+0x38/0x50
[ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight]
[ 91.991472] coresight_unregister+0x64/0xcc [coresight]
[ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x]
[ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x]
[ 91.991598] amba_remove+0x3c/0x19c
Reproducible by: (Build all coresight components as modules):
#!/bin/sh
while true
do
for m in tmc stm cpu_debug etm4x replicator funnel
do
modprobe coresight_${m}
done
for m in tmc stm cpu_debug etm4x replicator funnel
do
rmmode coresight_${m}
done
done
Cc: stable(a)vger.kernel.org
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Mike Leach <mike.leach(a)linaro.org>
Cc: Leo Yan <leo.yan(a)linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index ee6ce92ab4c3..1edfec1e9d18 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1424,6 +1424,7 @@ static int coresight_remove_match(struct device *dev, void *data)
* platform data.
*/
fwnode_handle_put(conn->child_fwnode);
+ conn->child_fwnode = NULL;
/* No need to continue */
break;
}
--
2.35.3