CoreSight

coresight@lists.linaro.org

6 participants
2352 discussions

Re: [PATCH v2] coresight: etm4x: Fix crash observed on Qcom ETM parts with 'Low power override'

by Leo Yan

Hi Bhupesh, On Thu, Aug 25, 2022 at 10:52:32AM +0530, Bhupesh Sharma wrote: > Some Qualcomm ETM implementations require skipping powering up > the trace unit, as the ETMs are in the same power domain as > their CPU cores. > > Via commit 5214b563588e ("coresight: etm4x: Add support for > sysreg only devices"), the setting of 'skip_power_up' flag was > moved after the 'etm4_init_arch_data' function is called, whereas > the flag value is itself used inside the function. This causes > a crash when ETM mode 'Low-power state behavior override' is set > on some Qualcomm parts. > > Fix the same. > > Fixes: 5214b563588e ("coresight: etm4x: Add support for sysreg only devices") > Cc: Mike Leach <mike.leach(a)linaro.org> > Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma(a)linaro.org> > --- > - v1 can be seen here: https://lore.kernel.org/lkml/20220803191236.3037591-1-bhupesh.sharma@linaro… > - Addressed the review comments from Suzuki. > - Rebased on linux-next. > > drivers/hwtracing/coresight/coresight-etm4x-core.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index d39660a3e50c..14c1c7869795 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -977,6 +977,16 @@ static bool etm4_init_sysreg_access(struct etmv4_drvdata *drvdata, > if (!cpu_supports_sysreg_trace()) > return false; > > + /* > + * Some Qualcomm implementations require skipping powering up the trace unit, > + * as the ETMs are in the same power domain as their CPU cores. > + * > + * Since the 'skip_power_up' flag is used inside 'etm4_init_arch_data' function, > + * initialize it before the function is called. > + */ > + if (fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up")) > + drvdata->skip_power_up = true; > + I personally think this sentence should be placed in the function etm4_probe(), you need to move it just before smp call etm4_init_arch_data(), this can allow DT property "qcom,skip-power-up" to be respected. > /* > * ETMs implementing sysreg access must implement TRCDEVARCH. > */ > @@ -1951,8 +1961,7 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) > return -EINVAL; > > /* TRCPDCR is not accessible with system instructions. */ > - if (!desc.access.io_mem || > - fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up")) > + if (!desc.access.io_mem) > drvdata->skip_power_up = true; I prefer to move the condition checking for "desc.access.io_mem" to etm4_init_sysreg_access(), this can make sure the flag skip_power_up is set correctly based on property of system register access. A side topic, in the mainline kernel I found the value "desc.access.io_mem" is always zero (see the initialized value in etm4_probe() and etm4_init_sysreg_access()). Should we initialize desc.access.io_mem to true in etm4_probe()? diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index d39660a3e50c..cf2555c50abb 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -1939,6 +1939,7 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) if (drvdata->cpu < 0) return drvdata->cpu; + desc.access.io_mem = true; init_arg.drvdata = drvdata; init_arg.csa = &desc.access; init_arg.pid = etm_pid; Thanks, Leo > major = ETM_ARCH_MAJOR_VERSION(drvdata->arch); > -- > 2.35.3 >

2 years, 6 months

[PATCH v11 0/2] Add support for UltraSoc System Memory Buffer

by Junhao He

Add support for UltraSoc System Memory Buffer. Change since v10: - Rebase onto v6.1-rc4, included similar sysfs register accessors (as same as James's patch) - Link: https://lore.kernel.org/lkml/20221022115929.7503-1-hejunhao3@huawei.com/ Change since v9: - Update the Contact tag in SMB document. - Replace the spinlock with mutex. - Do some clean-ups in "smb_enable()" and "smb_release()". - Use classic memory mapped interface. - Link: https://lore.kernel.org/linux-arm-kernel/20220818132231.28240-1-hejunhao3@h… Change since v8: - Insert a blank line at the end of the config tag in Kconfig to Randy's comment. - Link: https://lore.kernel.org/linux-arm-kernel/20220816131634.38195-1-hejunhao3@h… Change since v7: - Use the macros for register bit flags and numbers of resource. - Cleanup punctuation. - Update the Date tag and the KernelVersion tag in the document. - Link: https://lore.kernel.org/lkml/20220712091353.34540-1-hejunhao3@huawei.com/ Change since v6: - Modify the code style and driver description according to Suzuki's comment. - Modify configuration of "drvdata->reading", to void problems in open/read concurrency scenario. - Rename the macro of "SMB_FLOW_MASK". - Use the "handle->head" to determine the page number and offset. - Link: https://lore.kernel.org/linux-arm-kernel/20220606130223.57354-1-liuqi115@hu… Change since v5: - Address the comments from Suzuki, add some comments in SMB document, and modify configuration of "drvdata->reading", to void problems in multi-core concurrency scenario - Link: https://lore.kernel.org/linux-arm-kernel/20220416083953.52610-1-liuqi115@hu… Change since v4: - Add a simple document of SMB driver according to Suzuki's comment. - Address the comments from Suzuki. - Link: https://lore.kernel.org/linux-arm-kernel/20220128061755.31909-1-liuqi115@hu… Change since v3: - Modify the file header according to community specifications. - Address the comments from Mathieu. - Link: https://lore.kernel.org/linux-arm-kernel/20211118110016.40398-1-liuqi115@hu… Change since v2: - Move ultrasoc driver to drivers/hwtracing/coresight by Mathieu's comment. - Link: https://lists.linaro.org/pipermail/coresight/2021-November/007310.html Change since v1: - Drop the document of UltraSoc according to Mathieu's comment. - Add comments to explain some private hardware settings. - Address the comments from Mathieu. - Link: https://lists.linaro.org/pipermail/coresight/2021-August/006842.html Change since RFC: - Move driver to drivers/hwtracing/coresight/ultrasoc. - Remove ultrasoc-axi-com.c, as AXI-COM doesn't need to be configured in basic tracing function. - Remove ultrasoc.c as SMB does not need to register with the ultrasoc core. - Address the comments from Mathieu and Suzuki. - Link: https://lists.linaro.org/pipermail/coresight/2021-June/006535.html Qi Liu (2): drivers/coresight: Add UltraSoc System Memory Buffer driver Documentation: Add document for UltraSoc SMB drivers .../sysfs-bus-coresight-devices-ultra_smb | 31 + .../trace/coresight/ultrasoc-smb.rst | 80 +++ drivers/hwtracing/coresight/Kconfig | 11 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/ultrasoc-smb.c | 631 ++++++++++++++++++ drivers/hwtracing/coresight/ultrasoc-smb.h | 113 ++++ 6 files changed, 867 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb create mode 100644 Documentation/trace/coresight/ultrasoc-smb.rst create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.c create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.h -- 2.33.0

2 years, 6 months

Re: [PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by Suzuki K Poulose

Hi Greg, On 07/11/2022 10:24, Greg Kroah-Hartman wrote: > On Mon, Nov 07, 2022 at 09:59:24AM +0000, Suzuki K Poulose wrote: >> On 07/11/2022 09:52, Greg Kroah-Hartman wrote: >>> On Mon, Nov 07, 2022 at 09:23:26AM +0000, Suzuki K Poulose wrote: >>>> On 07/11/2022 09:11, Greg Kroah-Hartman wrote: >>>>> On Wed, Nov 02, 2022 at 11:20:03AM +0000, James Clark wrote: >>>>>> commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. >>>>> >>>>> Isn't this commit 665c157e0204176023860b51a46528ba0ba62c33 instead? >>>> >>>> This was reverted in commit d76308f03ee1 and pushed in later >>>> with fixups as 6746eae4bbadd. >>> >>> So which should be applied? >> >> Sorry, this particular post is a backport for v5.10 stable branch. >> >>> >>> confused, >> >> Now I am too. What is expected here ? My understanding is, we >> should stick the "upstream" commit that is getting backported >> at the beginning of the commit description. In that sense, >> the commit id in this patch looks correct to me. Please let >> me know if this is not the case. >> >> As such, this is only for 5.10.x branch. The rest are taken >> care of. >> >> Please let us know if we are something missing. > > We already have commit 665c157e0204176023860b51a46528ba0ba62c33 queued > up in the 5.10 stable queue. Is that not correct? It has the same We pushed the fix as part of the coresight fixes for 6.1 [0], as commit: 6746eae4bbad "coresight: cti: Fix hang in cti_disable_hw()" But, the version in there, produced a build warning with "unused variable" (with CONFIG_WERROR) [1] and thus was reverted in [2], commit: d76308f03ee1: Revert "coresight: cti: Fix hang in cti_disable_hw()" Later, we sent you the corrected fix separately [3], which was queued as commit "6746eae4bbadd". 6746eae4bbad coresight: cti: Fix hang in cti_disable_hw() So, in effect, here is what we have in the tree : $ git log --oneline | grep "cti: Fix" 6746eae4bbad coresight: cti: Fix hang in cti_disable_hw() d76308f03ee1 Revert "coresight: cti: Fix hang in cti_disable_hw()" 665c157e0204 coresight: cti: Fix hang in cti_disable_hw() > subject line as this one. I understand the "same" subject line has caused this confusion. Will modify it in the future avoid this confusion. So, kindly drop "665c157e0204" from the queue for 5.10, it would fail to apply there anyway so does the correct "6746eae4bbad". This backport is appropriate for 5.10 branch, with the correct version. I have double checked the versions pulled into 6.0.x [4] and 5.15.x [5] branches and they all have the correct one (6746eae4bbad) applied. [0] https://lkml.kernel.org/r/16664341837810@kroah.com [1] https://lkml.kernel.org/r/20221024135752.2b83af97@canb.auug.org.au [2] https://lkml.kernel.org/r/166659326494120@kroah.com [3] https://lkml.kernel.org/r/1666717705115206@kroah.com [4] https://lkml.kernel.org/r/166719866563237@kroah.com [5] https://lkml.kernel.org/r/16671983698786@kroah.com Hope this helps. Suzuki > > Still confused. > > thanks, > > greg k-h

2 years, 6 months

Re: [PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by Suzuki K Poulose

On 07/11/2022 09:52, Greg Kroah-Hartman wrote: > On Mon, Nov 07, 2022 at 09:23:26AM +0000, Suzuki K Poulose wrote: >> On 07/11/2022 09:11, Greg Kroah-Hartman wrote: >>> On Wed, Nov 02, 2022 at 11:20:03AM +0000, James Clark wrote: >>>> commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. >>> >>> Isn't this commit 665c157e0204176023860b51a46528ba0ba62c33 instead? >> >> This was reverted in commit d76308f03ee1 and pushed in later >> with fixups as 6746eae4bbadd. > > So which should be applied? Sorry, this particular post is a backport for v5.10 stable branch. > > confused, Now I am too. What is expected here ? My understanding is, we should stick the "upstream" commit that is getting backported at the beginning of the commit description. In that sense, the commit id in this patch looks correct to me. Please let me know if this is not the case. As such, this is only for 5.10.x branch. The rest are taken care of. Please let us know if we are something missing. Suzuki > > greg k-h

2 years, 6 months

Re: [PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by Suzuki K Poulose

On 07/11/2022 09:11, Greg Kroah-Hartman wrote: > On Wed, Nov 02, 2022 at 11:20:03AM +0000, James Clark wrote: >> commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. > > Isn't this commit 665c157e0204176023860b51a46528ba0ba62c33 instead? This was reverted in commit d76308f03ee1 and pushed in later with fixups as 6746eae4bbadd. Cheers Suzuki > > confused, > > greg k-h

2 years, 6 months

[PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by James Clark

commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware. This can cause a hang when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace. Fixes: 835d722ba10a ("coresight: cti: Initial CoreSight CTI Driver") Cc: stable <stable(a)kernel.org> # 5.10.x Reported-by: Aishwarya TCV <Aishwarya.TCV(a)arm.com> Reported-by: Cristian Marussi <Cristian.Marussi(a)arm.com> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Reviewed-by: Mike Leach <mike.leach(a)linaro.org> Tested-by: Mike Leach <mike.leach(a)linaro.org> [ Fix build warnings ] Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Link: https://lore.kernel.org/r/20221025131032.1149459-1-suzuki.poulose@arm.com Signed-off-by: James Clark <james.clark(a)arm.com> --- drivers/hwtracing/coresight/coresight-cti-core.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c index 0276700c246d..90270696206c 100644 --- a/drivers/hwtracing/coresight/coresight-cti-core.c +++ b/drivers/hwtracing/coresight/coresight-cti-core.c @@ -90,11 +90,9 @@ void cti_write_all_hw_regs(struct cti_drvdata *drvdata) static int cti_enable_hw(struct cti_drvdata *drvdata) { struct cti_config *config = &drvdata->config; - struct device *dev = &drvdata->csdev->dev; unsigned long flags; int rc = 0; - pm_runtime_get_sync(dev->parent); spin_lock_irqsave(&drvdata->spinlock, flags); /* no need to do anything if enabled or unpowered*/ @@ -119,7 +117,6 @@ static int cti_enable_hw(struct cti_drvdata *drvdata) /* cannot enable due to error */ cti_err_not_enabled: spin_unlock_irqrestore(&drvdata->spinlock, flags); - pm_runtime_put(dev->parent); return rc; } @@ -153,7 +150,6 @@ static void cti_cpuhp_enable_hw(struct cti_drvdata *drvdata) static int cti_disable_hw(struct cti_drvdata *drvdata) { struct cti_config *config = &drvdata->config; - struct device *dev = &drvdata->csdev->dev; spin_lock(&drvdata->spinlock); @@ -174,7 +170,6 @@ static int cti_disable_hw(struct cti_drvdata *drvdata) coresight_disclaim_device_unlocked(drvdata->base); CS_LOCK(drvdata->base); spin_unlock(&drvdata->spinlock); - pm_runtime_put(dev->parent); return 0; /* not disabled this call */ -- 2.25.1

2 years, 6 months

OpenCSD version 1.3.3

by Mike Leach

Version 1.3.3 of OpenCSD is now released. Fixes problems where bad input data to the CoreSight frame demuxer was not being correctly handled, resulting in buffer misalignment and possible read beyond the end of the buffers. (Github issues #49, #50, #51) Adds a test program to validate these fixes and other error checking which has been improved / corrected. Also fixed and issue in PTM decode which failed to extract the address of a waypoint marker correctly under certain circumstances.(github issue #48) Adds build env for VS2022. Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

2 years, 6 months

[PATCH 0/9] Add support to configure TPDM DSB subunit

by Tao Zhang

Introduction of TPDM DSB subunit DSB subunit is responsible for creating a dataset element, and is also optionally responsible for packing it to fit multiple elements on a single ATB transfer if possible in the configuration. The TPDM Core Datapath requests timestamps be stored by the TPDA and then delivering ATB sized data (depending on ATB width and element size, this could be smaller or larger than a dataset element) to the ATB Mast FSM. The DSB subunit must be configured prior to enablement. This series adds support for TPDM to configure the configure DSB subunit. Once this series patches are applied properly, the new tpdm nodes for should be observed at the tpdm path /sys/bus/coresight/devices/tpdm* which supports DSB subunit. e.g. /sys/devices/platform/soc(a)0/69d0000.tpdm/tpdm0#ls -l | grep dsb -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_edge_ctrl -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_edge_ctrl_mask -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_mode -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_mask -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_ts -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_type -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_val -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_patt_mask -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_patt_val -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_ts -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_type We can use the commands are similar to the below to configure the TPDMs which support DSB subunit. Enable coresight sink first. echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/tpdm0/reset echo 0x3 0x3 0x1 > /sys/bus/coresight/devices/tpdm0/dsb_edge_ctrl_mask echo 0x6d 0x6d 0 > /sys/bus/coresight/devices/tpdm0/dsb_edge_ctrl echo 1 > /sys/bus/coresight/devices/tpdm0/dsb_patt_ts echo 1 > /sys/bus/coresight/devices/tpdm0/dsb_patt_type echo 0 > /sys/bus/coresight/devices/tpdm0/dsb_trig_ts echo 0 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/dsb_patt_mask echo 0 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/dsb_trig_patt_val This series applies to coresight/next https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git?h=next This patch series depends on patch series "[v12,0/9] Coresight: Add support for TPDM and TPDA" https://patchwork.kernel.org/project/linux-arm-kernel/cover/20220905065357.… Tao Zhang (9): dt-bindings: arm: Add support for DSB element coresight-tpda: Add DSB dataset support coresight-tpdm: Initialize DSB subunit configuration coresight-tpdm: Add reset node to TPDM node coresight-tpdm: Add nodes to set trigger timestamp and type coresight-tpdm: Add node to set dsb programming mode coresight-tpdm: Add nodes for dsb element creation coresight-tpdm: Add nodes to configure pattern match output coresight-tpdm: Add nodes for timestamp request .../bindings/arm/qcom,coresight-tpda.yaml | 9 + drivers/hwtracing/coresight/coresight-tpda.c | 62 ++ drivers/hwtracing/coresight/coresight-tpda.h | 4 + drivers/hwtracing/coresight/coresight-tpdm.c | 625 ++++++++++++++++++++- drivers/hwtracing/coresight/coresight-tpdm.h | 60 ++ 5 files changed, 756 insertions(+), 4 deletions(-) -- 2.7.4

2 years, 6 months

[PATCH] coresight: cti: Fix hang in cti_disable_hw()

by Suzuki K Poulose

From: James Clark <james.clark(a)arm.com> cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware. Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock management to the SCMI power domain""), this causes a hang on Juno when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls This was also missed until the revert commit because pm_runtime_put() was called with the wrong device until commit 692c9a499b28 ("coresight: cti: Correct the parameter for pm_runtime_put") With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace. Fixes: 835d722ba10a ("coresight: cti: Initial CoreSight CTI Driver") Reported-by: Aishwarya TCV <Aishwarya.TCV(a)arm.com> Reported-by: Cristian Marussi <Cristian.Marussi(a)arm.com> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: James Clark <james.clark(a)arm.com> Reviewed-by: Mike Leach <mike.leach(a)linaro.org> Tested-by: Mike Leach <mike.leach(a)linaro.org> [ Fix build warnings ] Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> --- Greg, Please could you apply this patch to your tree. Thanks Suzuki Changes since previous posting: - Fix build warnings with 'unused variable' --- drivers/hwtracing/coresight/coresight-cti-core.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c index 1be92342b5b9..c6e8c6542f24 100644 --- a/drivers/hwtracing/coresight/coresight-cti-core.c +++ b/drivers/hwtracing/coresight/coresight-cti-core.c @@ -90,11 +90,9 @@ void cti_write_all_hw_regs(struct cti_drvdata *drvdata) static int cti_enable_hw(struct cti_drvdata *drvdata) { struct cti_config *config = &drvdata->config; - struct device *dev = &drvdata->csdev->dev; unsigned long flags; int rc = 0; - pm_runtime_get_sync(dev->parent); spin_lock_irqsave(&drvdata->spinlock, flags); /* no need to do anything if enabled or unpowered*/ @@ -119,7 +117,6 @@ static int cti_enable_hw(struct cti_drvdata *drvdata) /* cannot enable due to error */ cti_err_not_enabled: spin_unlock_irqrestore(&drvdata->spinlock, flags); - pm_runtime_put(dev->parent); return rc; } @@ -153,7 +150,6 @@ static void cti_cpuhp_enable_hw(struct cti_drvdata *drvdata) static int cti_disable_hw(struct cti_drvdata *drvdata) { struct cti_config *config = &drvdata->config; - struct device *dev = &drvdata->csdev->dev; struct coresight_device *csdev = drvdata->csdev; spin_lock(&drvdata->spinlock); @@ -175,7 +171,6 @@ static int cti_disable_hw(struct cti_drvdata *drvdata) coresight_disclaim_device_unlocked(csdev); CS_LOCK(drvdata->base); spin_unlock(&drvdata->spinlock); - pm_runtime_put(dev->parent); return 0; /* not disabled this call */ -- 2.37.3

2 years, 6 months

Re: [PATCH] coresight: cti: Remove unused variables in cti_{dis,en}able_hw()

by Suzuki K Poulose

Hi Nathan On 24/10/2022 16:12, Nathan Chancellor wrote: > Clean up the following warnings, as the variables are no longer used. > > drivers/hwtracing/coresight/coresight-cti-core.c:93:17: warning: unused variable 'dev' [-Wunused-variable] > struct device *dev = &drvdata->csdev->dev; > ^ > drivers/hwtracing/coresight/coresight-cti-core.c:154:17: warning: unused variable 'dev' [-Wunused-variable] > struct device *dev = &drvdata->csdev->dev; > ^ > 2 warnings generated. > > Fixes: 665c157e0204 ("coresight: cti: Fix hang in cti_disable_hw()") > Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> Thanks for your patch, this is now reverted upstream. I have queued a patch locally to sqaush the changes and plan to push it once the revert lands upstream. Thanks Suzuki

2 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight