Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.124 2024-12-14T18:54:09+00:00 2024-12-14T18:54:09+00:00 Namhyung Kim namhyung@kernel.org 2024-11-21T00:13:34+00:00 urn:sha1:4dcaa86552dc253b752deac4473dcdf556ea6871 [ Upstream commit dfdf714fed559c09021df1d2a4bb64c0ad5f53bc ] The portid_bits and deviceid_bits were set only for XP type nodes in the arm_cmn_discover() and it confused other nodes to find XP nodes. Copy the both bits from the XP nodes directly when it sets up a new node. Fixes: e79634b53e39 ("perf/arm-cmn: Refactor node ID handling. Again.") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20241121001334.331334-1-namhyung@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-12-14T18:54:09+00:00 Chun-Tse Shao ctshao@google.com 2024-11-08T05:08:05+00:00 urn:sha1:ddce811ed3a466bd96fee9c3d00bc438b8dd0f31 [ Upstream commit 02a55f2743012a8089f09f6867220c3d57f16564 ] Same as https://lore.kernel.org/all/20240514180050.182454-1-namhyung@kernel.org/, we should skip `for_each_sibling_event()` for group leader since it doesn't have the ctx yet. Fixes: f3c0eba28704 ("perf: Add a few assertions") Reported-by: Greg Thelen <gthelen@google.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Tuan Phan <tuanphan@os.amperecomputing.com> Signed-off-by: Chun-Tse Shao <ctshao@google.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241108050806.3730811-1-ctshao@google.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-10-17T13:21:28+00:00 Robin Murphy robin.murphy@arm.com 2023-12-11T19:27:28+00:00 urn:sha1:85045e51c730e541d83b222d52659caaf43d23ff commit 1892fe103c3a20fced306c8dafa74f7f6d4ea0a3 upstream. Calling arm_cmn_event_clear() before all DTC indices are allocated is wrong, and can lead to arm_cmn_event_add() erroneously clearing live counters from full DTCs where allocation fails. Since the DTC counters are only updated by arm_cmn_init_counter() after all DTC and DTM allocations succeed, nothing actually needs cleaning up in this case anyway, and it should just return directly as it did before. Fixes: 7633ec2c262f ("perf/arm-cmn: Rework DTC counters (again)") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2024-10-17T13:20:40+00:00 Robin Murphy robin.murphy@arm.com 2024-09-02T17:51:59+00:00 urn:sha1:98a730f45551462a6d5b1cc091670a13ea0323a5 [ Upstream commit 359414b33e00bae91e4eabf3e4ef8e76024c7673 ] While CMN_MAX_DIMENSION was bumped to 12 for CMN-650, that only supports up to a 10x10 mesh, so bumping dtm_idx to 256 bits at the time worked out OK in practice. However CMN-700 did finally support up to 144 XPs, and thus needs a worst-case 288 bits of dtm_idx for an aggregated XP event on a maxed-out config. Oops. Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/e771b358526a0d7fc06efee2c3a2fdc0c9f51d44.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-10-17T13:20:40+00:00 Robin Murphy robin.murphy@arm.com 2024-09-02T17:51:57+00:00 urn:sha1:22deed5deab7dfa7cdf2ea7b53dd131f1f70ad61 [ Upstream commit e79634b53e398966c49f803c49701bc74dc3ccf8 ] The scope of the "extra device ports" configuration is not made clear by the CMN documentation - so far we've assumed it applies globally, based on the sole example which suggests as much. However it transpires that this is incorrect, and the format does in fact vary based on each individual XP's port configuration. As a consequence, we're currenly liable to decode the port/device indices from a node ID incorrectly, thus program the wrong event source in the DTM leading to bogus event counts, and also show device topology on the wrong ports in debugfs. To put this right, rework node IDs yet again to carry around the additional data necessary to decode them properly per-XP. At this point the notion of fully decomposing an ID becomes more impractical than it's worth, so unabstracting the XY mesh coordinates (where 2/3 users were just debug anyway) ends up leaving things a bit simpler overall. Fixes: 60d1504070c2 ("perf/arm-cmn: Support new IP features") Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/5195f990152fc37adba5fbf5929a6b11063d9f09.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-10-17T13:20:40+00:00 Robin Murphy robin.murphy@arm.com 2023-12-13T16:24:07+00:00 urn:sha1:3e66b8c3b2156d2ffc7fa83257b1b5c95a0ff9e4 [ Upstream commit a1083ee717e9bde012268782e084d343314490a4 ] The debugfs pretty-printer was written for the CMN-600 assumptions of a maximum 8x8 mesh, but CMN-700 now allows coordinates and ID values up to 12 and 128 respectively, which can overflow the format strings, mess up the alignment of the table and hurt overall readability. This table does prove useful for double-checking that the driver is picking up the topology of new systems correctly and for verifying user expectations, so tweak the formatting to stay nice and readable with wider values. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/1d1517eadd1bac5992fab679c9dc531b381944da.1702484646.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org> Stable-dep-of: e79634b53e39 ("perf/arm-cmn: Refactor node ID handling. Again.") Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-10-17T13:20:40+00:00 Robin Murphy robin.murphy@arm.com 2023-10-20T17:51:26+00:00 urn:sha1:7a638f9114727e1932234da0c147a33dcd115d87 [ Upstream commit 7633ec2c262fab3e7c5bf3cd3876b5748f584a57 ] The bitmap-based scheme for tracking DTC counter usage turns out to be a complete dead-end for its imagined purpose, since by the time we have to keep track of a per-DTC counter index anyway, we already have enough information to make the bitmap itself redundant. Revert the remains of it back to almost the original scheme, but now expanded to track per-DTC indices, in preparation for making use of them in anger. Note that since cycle count events always use a dedicated counter on a single DTC, we reuse the field to encode their DTC index directly. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/5f6ade76b47f033836d7a36c03555da896dfb4a3.1697824215.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org> Stable-dep-of: e79634b53e39 ("perf/arm-cmn: Refactor node ID handling. Again.") Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-10-17T13:20:38+00:00 Yicong Yang yangyicong@hisilicon.com 2024-08-29T09:03:30+00:00 urn:sha1:a1053b0a487c89ac36423079e44b84e1182430d3 [ Upstream commit daecd3373a16a039ad241086e30a1ec46fc9d61f ] Currently we set the period and record it as the initial value of the counter without checking it's set to the hardware successfully or not. However the counter maybe unwritable if the target event is unsupported by the device. In such case we will pass user a wrong count: [start counts when setting the period] hwc->prev_count = 0x8000000000000000 device.counter_value = 0 // the counter is not set as the period [when user reads the counter] event->count = device.counter_value - hwc->prev_count = 0x8000000000000000 // wrong. should be 0. Fix this by record the hardware counter counts correctly when setting the period. Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU") Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240829090332.28756-2-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-10-17T13:20:38+00:00 Jing Zhang renyu.zj@linux.alibaba.com 2024-08-22T03:33:31+00:00 urn:sha1:24f30b34ff76648d26872dd4eaa002f074225058 [ Upstream commit a3dd920977dccc453c550260c4b7605b280b79c3 ] The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it. Fixes: cf7b61073e45 ("drivers/perf: add DDR Sub-System Driveway PMU driver for Yitian 710 SoC") Signed-off-by: Jing Zhang <renyu.zj@linux.alibaba.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/1724297611-20686-1-git-send-email-renyu.zj@linux.alibaba.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-07-25T07:49:18+00:00 Samuel Holland samuel.holland@sifive.com 2024-06-28T07:51:42+00:00 urn:sha1:be3ba371437da22e6c6bab4a73824bf59cb68df5 [ Upstream commit 7dd646cf745c34d31e7ed2a52265e9ca8308f58f ] Currently, we stop all the counters while a new cpu is brought online. However, the hpmevent to counter mappings are not reset. The firmware may have some stale encoding in their mapping structure which may lead to undesirable results. We have not encountered such scenario though. Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20240628-misc_perf_fixes-v4-2-e01cfddcf035@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>