<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/perf, branch v6.1.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-04-10T14:28:30+00:00</updated>
<entry>
<title>drivers/perf: riscv: Disable PERF_SAMPLE_BRANCH_* while not supported</title>
<updated>2024-04-10T14:28:30+00:00</updated>
<author>
<name>Pu Lehui</name>
<email>pulehui@huawei.com</email>
</author>
<published>2024-03-12T01:20:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=81f7c9da2bed3df06fd4c6a1ae8034001b1ed959'/>
<id>urn:sha1:81f7c9da2bed3df06fd4c6a1ae8034001b1ed959</id>
<content type='text'>
[ Upstream commit ea6873118493019474abbf57d5a800da365734df ]

RISC-V perf driver does not yet support branch sampling. Although the
specification is in the works [0], it is best to disable such events
until support is available, otherwise we will get unexpected results.
Due to this reason, two riscv bpf testcases get_branch_snapshot and
perf_branches/perf_branches_hw fail.

Link: https://github.com/riscv/riscv-control-transfer-records [0]
Fixes: f5bfa23f576f ("RISC-V: Add a perf core library for pmu drivers")
Signed-off-by: Pu Lehui &lt;pulehui@huawei.com&gt;
Reviewed-by: Atish Patra &lt;atishp@rivosinc.com&gt;
Reviewed-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Link: https://lore.kernel.org/r/20240312012053.1178140-1-pulehui@huaweicloud.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/arm-cmn: Workaround AmpereOneX errata AC04_MESH_1 (incorrect child count)</title>
<updated>2024-03-26T22:20:24+00:00</updated>
<author>
<name>Ilkka Koskinen</name>
<email>ilkka@os.amperecomputing.com</email>
</author>
<published>2024-02-09T17:11:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d23425dab9975e3abff49fd416856c020dd90dd1'/>
<id>urn:sha1:d23425dab9975e3abff49fd416856c020dd90dd1</id>
<content type='text'>
[ Upstream commit 50572064ec7109b00eef8880e905f55861c8b3de ]

AmpereOneX mesh implementation has a bug in HN-P nodes that makes them
report incorrect child count. The failing crosspoints report 8 children
while they only have two.

When the driver tries to access the inexistent child nodes, it believes it
has reached an invalid node type and probing fails. The workaround is to
ignore those incorrect child nodes and continue normally.

Signed-off-by: Ilkka Koskinen &lt;ilkka@os.amperecomputing.com&gt;
[ rm: rewrote simpler generalised version ]
Tested-by: Ilkka Koskinen &lt;ilkka@os.amperecomputing.com&gt;
Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Link: https://lore.kernel.org/r/ce4b1442135fe03d0de41859b04b268c88c854a3.1707498577.git.robin.murphy@arm.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf: hisi: Fix use-after-free when register pmu fails</title>
<updated>2023-11-20T10:52:01+00:00</updated>
<author>
<name>Junhao He</name>
<email>hejunhao3@huawei.com</email>
</author>
<published>2023-10-24T11:36:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b660420f449d094b1fabfa504889810b3a63cdd5'/>
<id>urn:sha1:b660420f449d094b1fabfa504889810b3a63cdd5</id>
<content type='text'>
[ Upstream commit b805cafc604bfdb671fae7347a57f51154afa735 ]

When we fail to register the uncore pmu, the pmu context may not been
allocated. The error handing will call cpuhp_state_remove_instance()
to call uncore pmu offline callback, which migrate the pmu context.
Since that's liable to lead to some kind of use-after-free.

Use cpuhp_state_remove_instance_nocalls() instead of
cpuhp_state_remove_instance() so that the notifiers don't execute after
the PMU device has been failed to register.

Fixes: a0ab25cd82ee ("drivers/perf: hisi: Add support for HiSilicon PA PMU driver")
FIxes: 3bf30882c3c7 ("drivers/perf: hisi: Add support for HiSilicon SLLC PMU driver")
Signed-off-by: Junhao He &lt;hejunhao3@huawei.com&gt;
Link: https://lore.kernel.org/r/20231024113630.13472-1-hejunhao3@huawei.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drivers/perf: hisi_pcie: Check the type first in pmu::event_init()</title>
<updated>2023-11-20T10:52:01+00:00</updated>
<author>
<name>Yicong Yang</name>
<email>yangyicong@hisilicon.com</email>
</author>
<published>2023-10-24T09:29:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=104fa6426a8fe9c38113bb58fd1cd526bf4d39d6'/>
<id>urn:sha1:104fa6426a8fe9c38113bb58fd1cd526bf4d39d6</id>
<content type='text'>
[ Upstream commit 6d7d51e88e21c0af1ca96a3617afef334bfeffcf ]

Check whether the event type matches the PMU type firstly in
pmu::event_init() before touching the event. Otherwise we'll
change the events of others and lead to incorrect results.
Since in perf_init_event() we may call every pmu's event_init()
in a certain case, we should not modify the event if it's not
ours.

Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
Signed-off-by: Yicong Yang &lt;yangyicong@hisilicon.com&gt;
Link: https://lore.kernel.org/r/20231024092954.42297-2-yangyicong@huawei.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/arm-cmn: Fix DTC domain detection</title>
<updated>2023-11-20T10:52:01+00:00</updated>
<author>
<name>Robin Murphy</name>
<email>robin.murphy@arm.com</email>
</author>
<published>2023-10-20T17:51:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c6e00bc30ea105e4958709d7510384441556559c'/>
<id>urn:sha1:c6e00bc30ea105e4958709d7510384441556559c</id>
<content type='text'>
[ Upstream commit e3e73f511c49c741f6309862c2248958ad77bbaa ]

It transpires that dtm_unit_info is another register which got shuffled
in CMN-700 without me noticing. Fix that in a way which also proactively
fixes the fragile laziness of its consumer, just in case any further
fields ever get added alongside dtc_domain.

Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support")
Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Reviewed-by: Ilkka Koskinen &lt;ilkka@os.amperecomputing.com&gt;
Link: https://lore.kernel.org/r/3076ee83d0554f6939fbb6ee49ab2bdb28d8c7ee.1697824215.git.robin.murphy@arm.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/arm-cmn: Revamp model detection</title>
<updated>2023-11-20T10:52:01+00:00</updated>
<author>
<name>Robin Murphy</name>
<email>robin.murphy@arm.com</email>
</author>
<published>2023-06-12T17:16:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=28fa550a49e818d6445e787f584759b1bf21d9d4'/>
<id>urn:sha1:28fa550a49e818d6445e787f584759b1bf21d9d4</id>
<content type='text'>
[ Upstream commit 7819e05a0dceac20c5ff78ec9b252faf3b76b824 ]

CMN implements a set of CoreSight-format peripheral ID registers which
in principle we should be able to use to identify the hardware. However
so far we have avoided trying to use the part number field since the
TRMs have all described it as "configuration dependent". It turns out,
though, that this is a quirk of the documentation generation process,
and in fact the part number should always be a stable well-defined field
which we can trust.

To that end, revamp our model detection to rely less on ACPI/DT, and
pave the way towards further using the hardware information as an
identifier for userspace jevent metrics. This includes renaming the
revision constants to maximise readability.

Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Reviewed-and-tested-by: Ilkka Koskinen &lt;ilkka@os.amperecomputing.com&gt;
Link: https://lore.kernel.org/r/3c791eaae814b0126f9adbd5419bfb4a600dade7.1686588640.git.robin.murphy@arm.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Stable-dep-of: e3e73f511c49 ("perf/arm-cmn: Fix DTC domain detection")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process</title>
<updated>2023-11-20T10:52:01+00:00</updated>
<author>
<name>Hao Chen</name>
<email>chenhao418@huawei.com</email>
</author>
<published>2023-10-19T09:13:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4589403a343bb0c72a6faf5898386ff964d4e01a'/>
<id>urn:sha1:4589403a343bb0c72a6faf5898386ff964d4e01a</id>
<content type='text'>
[ Upstream commit 50b560783f7f71790bcf70e9e9855155fb0af8c1 ]

When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug
callbacks after the device has been unregistered, leading to fireworks
when we try to execute empty function callbacks within the driver:

  | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
  | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G        W  O      5.12.0-rc4+ #1
  | Hardware name:  , BIOS KpxxxFPGA 1P B600 V143 04/22/2021
  | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
  | pc : perf_pmu_migrate_context+0x98/0x38c
  | lr : perf_pmu_migrate_context+0x94/0x38c
  |
  | Call trace:
  |  perf_pmu_migrate_context+0x98/0x38c
  |  hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]

Use cpuhp_state_remove_instance_nocalls() instead of
cpuhp_state_remove_instance() so that the notifiers don't execute after
the PMU device has been unregistered.

Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU")
Signed-off-by: Hao Chen &lt;chenhao418@huawei.com&gt;
Signed-off-by: Jijie Shao &lt;shaojijie@huawei.com&gt;
Reviewed-by: Yicong Yang &lt;yangyicong@hisilicon.com&gt;
Link: https://lore.kernel.org/r/20231019091352.998964-1-shaojijie@huawei.com
[will: Rewrote commit message]
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7</title>
<updated>2023-10-19T21:08:50+00:00</updated>
<author>
<name>Jing Zhang</name>
<email>renyu.zj@linux.alibaba.com</email>
</author>
<published>2023-09-25T03:22:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1c8f6c7b837568e755cebe325d56c90759035b24'/>
<id>urn:sha1:1c8f6c7b837568e755cebe325d56c90759035b24</id>
<content type='text'>
[ Upstream commit 7f949f6f54ff593123ab95b6247bfa4542a65580 ]

The register por_dt_pmovsr Bits[7:0] indicates overflow from counters 7
to 0. But in arm_cmn_handle_irq(), only handled the overflow status of
Bits[3:0] which results in unhandled overflow status of counters 4 to 7.

So let the overflow status of DTC counters 4 to 7 to be handled.

Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
Signed-off-by: Jing Zhang &lt;renyu.zj@linux.alibaba.com&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Link: https://lore.kernel.org/r/1695612152-123633-1-git-send-email-renyu.zj@linux.alibaba.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/imx_ddr: speed up overflow frequency of cycle</title>
<updated>2023-09-23T09:11:00+00:00</updated>
<author>
<name>Xu Yang</name>
<email>xu.yang_2@nxp.com</email>
</author>
<published>2023-08-11T01:54:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d42d342d313206ef0d08d72311b5d86c72a1756e'/>
<id>urn:sha1:d42d342d313206ef0d08d72311b5d86c72a1756e</id>
<content type='text'>
[ Upstream commit e89ecd8368860bf05437eabd07d292c316221cfc ]

For i.MX8MP, we cannot ensure that cycle counter overflow occurs at least
4 times as often as other events. Due to byte counters will count for any
event configured, it will overflow more often. And if byte counters
overflow that related counters would stop since they share the
COUNTER_CNTL. We can speed up cycle counter overflow frequency by setting
counter parameter (CP) field of cycle counter. In this way, we can avoid
stop counting byte counters when interrupt didn't come and the byte
counters can be fetched or updated from each cycle counter overflow
interrupt.

Because we initialize CP filed to shorten counter0 overflow time, the cycle
counter will start couting from a fixed/base value each time. We need to
remove the base from the result too. Therefore, we could get precise result
from cycle counter.

Signed-off-by: Xu Yang &lt;xu.yang_2@nxp.com&gt;
Reviewed-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Link: https://lore.kernel.org/r/20230811015438.1999307-1-xu.yang_2@nxp.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/smmuv3: Enable HiSilicon Erratum 162001900 quirk for HIP08/09</title>
<updated>2023-09-23T09:11:00+00:00</updated>
<author>
<name>Yicong Yang</name>
<email>yangyicong@hisilicon.com</email>
</author>
<published>2023-08-14T12:40:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9d9b5cbc12f49fbdbbc454383981039005af8211'/>
<id>urn:sha1:9d9b5cbc12f49fbdbbc454383981039005af8211</id>
<content type='text'>
[ Upstream commit 0242737dc4eb9f6e9a5ea594b3f93efa0b12f28d ]

Some HiSilicon SMMU PMCG suffers the erratum 162001900 that the PMU
disable control sometimes fail to disable the counters. This will lead
to error or inaccurate data since before we enable the counters the
counter's still counting for the event used in last perf session.

This patch tries to fix this by hardening the global disable process.
Before disable the PMU, writing an invalid event type (0xffff) to
focibly stop the counters. Correspondingly restore each events on
pmu::pmu_enable().

Signed-off-by: Yicong Yang &lt;yangyicong@hisilicon.com&gt;
Link: https://lore.kernel.org/r/20230814124012.58013-1-yangyicong@huawei.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
