[PATCH 00/32] Add parents to struct pmu -> dev

[PATCH 00/32] Add parents to struct pmu -> dev

[Jonathan Cameron]

These are the low hanging fruit following GregKH's feedback that
all the devices registered via perf_pmu_register() should have parents.

Note that this causes potential ABI breakage.

It may fall in the category of it isn't breakage if no one notices
but I can't be certain of that.  Whilst it is arguable that
no one should be been accessing PMUs except via the event_source
bus, there was documentation suggesting /sys/devices/ for particular
PMUs (because it was a shorter path?)

The first patch is pulled out of the series:
https://lore.kernel.org/linux-cxl/20230327170247.6968-1-Jonathan.Cameron@huawei.com/
[PATCH v3 0/5] CXL 3.0 Performance Monitoring Unit support

In that particular case it is very useful to be able to figure out which
CXL device the PMU device is associated with and looking at it's parents
in the device model as shown with ls -lh /sys/bus/event_sources/devices/
is a very easy way to do this (once it is correctly parented).

Addressing all the other instances of struct pmu not covered by this series
is likely to be a more complex discussion but unlikely to have an affect
on what is proposed here.

Documentation updates deliberately 'fixed' in separate patches before
changing the path to highlight that using /sys/bus/event_source/devices
path is unchanged by this series and that is presumed to be the
most common way these files are accessed.

Jonathan Cameron (32):
  perf: Allow a PMU to have a parent
  perf/hisi-pcie: Assign parent for event_source device
  Documentation: hisi-pmu: Drop reference to /sys/devices path
  perf/hisi-uncore: Assign parents for event_source devices
  Documentation: hns-pmu: Use /sys/bus/event_source/devices paths
  perf/hisi-hns3: Assign parents for event_source device
  perf/amlogic: Assign parents for event_source devices
  perf/arm_cspmu: Assign parents for event_source devices
  Documentation: xgene-pmu: Use /sys/bus/event_source/devices paths
  perf/xgene: Assign parents for event_source devices
  Documentation: thunderx2-pmu:  Use /sys/bus/event_source/devices paths
  perf/thunderx2: Assign parents for event_source devices
  perf/riscv: Assign parents for event_source devices
  Documentation: qcom-pmu: Use /sys/bus/event_source/devices paths
  perf/qcom: Assign parents for event_source devices
  perf/imx_ddr: Assign parents for event_source devices
  perf/arm_pmu: Assign parents for event_source devices
  perf/alibaba_uncore: Assign parents for event_source device
  perf/arm-cci: Assign parents for event_source device
  perf/arm-ccn: Assign parents for event_source device
  perf/arm-cmn: Assign parents for event_source device
  perf/arm-dmc620: Assign parents for event_source device
  perf/arm-dsu: Assign parents for event_source device
  perf/arm-smmuv3: Assign parents for event_source device
  perf/arm-spe: Assign parents for event_source device
  arc: Assign parents for event_source devices
  ARM: imx: Assign parents for mmdc event_source devices
  dmaengine: idxd: Assign parent for event_source device
  fpga: dfl: Assign parent for event_source device
  drivers/nvdimm: Assign parent for event_source device
  Documentation: ABI + trace: hisi_ptt: update paths to bus/event_source
  hwtracing: hisi_ptt: Assign parent for event_source device

 ...i_ptt => sysfs-bus-event_source-devices-hisi_ptt} | 12 ++++++------
 Documentation/admin-guide/perf/hisi-pmu.rst          |  1 -
 Documentation/admin-guide/perf/hns3-pmu.rst          |  8 ++++----
 Documentation/admin-guide/perf/qcom_l2_pmu.rst       |  2 +-
 Documentation/admin-guide/perf/qcom_l3_pmu.rst       |  2 +-
 Documentation/admin-guide/perf/thunderx2-pmu.rst     |  2 +-
 Documentation/admin-guide/perf/xgene-pmu.rst         |  2 +-
 Documentation/trace/hisi-ptt.rst                     |  4 ++--
 MAINTAINERS                                          |  2 +-
 arch/arc/kernel/perf_event.c                         |  1 +
 arch/arm/mach-imx/mmdc.c                             |  1 +
 drivers/dma/idxd/perfmon.c                           |  1 +
 drivers/fpga/dfl-fme-perf.c                          |  1 +
 drivers/hwtracing/ptt/hisi_ptt.c                     |  1 +
 drivers/nvdimm/nd_perf.c                             |  1 +
 drivers/perf/alibaba_uncore_drw_pmu.c                |  1 +
 drivers/perf/amlogic/meson_ddr_pmu_core.c            |  1 +
 drivers/perf/arm-cci.c                               |  1 +
 drivers/perf/arm-ccn.c                               |  1 +
 drivers/perf/arm-cmn.c                               |  1 +
 drivers/perf/arm_cspmu/arm_cspmu.c                   |  1 +
 drivers/perf/arm_dmc620_pmu.c                        |  1 +
 drivers/perf/arm_dsu_pmu.c                           |  1 +
 drivers/perf/arm_pmu_platform.c                      |  1 +
 drivers/perf/arm_smmuv3_pmu.c                        |  1 +
 drivers/perf/arm_spe_pmu.c                           |  1 +
 drivers/perf/fsl_imx8_ddr_perf.c                     |  1 +
 drivers/perf/hisilicon/hisi_pcie_pmu.c               |  1 +
 drivers/perf/hisilicon/hisi_uncore_pmu.c             |  1 +
 drivers/perf/hisilicon/hns3_pmu.c                    |  1 +
 drivers/perf/qcom_l2_pmu.c                           |  1 +
 drivers/perf/qcom_l3_pmu.c                           |  1 +
 drivers/perf/riscv_pmu_legacy.c                      |  1 +
 drivers/perf/riscv_pmu_sbi.c                         |  1 +
 drivers/perf/thunderx2_pmu.c                         |  1 +
 drivers/perf/xgene_pmu.c                             |  1 +
 include/linux/perf_event.h                           |  1 +
 kernel/events/core.c                                 |  1 +
 38 files changed, 46 insertions(+), 18 deletions(-)
 rename Documentation/ABI/testing/{sysfs-devices-hisi_ptt => sysfs-bus-event_source-devices-hisi_ptt} (83%)

-- 
2.37.2

[PATCH 01/32] perf: Allow a PMU to have a parent

[Jonathan Cameron]

Some PMUs have well defined parents such as PCI devices.
As the device_initialize() and device_add() are all within
pmu_dev_alloc() which is called from perf_pmu_register()
there is no opportunity to set the parent from within a driver.

Add a struct device *parent field to struct pmu and use that
to set the parent.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>

---
Previously posted in CPMU series hence the change log.
v3: No change
---
 include/linux/perf_event.h | 1 +
 kernel/events/core.c       | 1 +
 2 files changed, 2 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index d5628a7b5eaa..b99db1eda72c 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -303,6 +303,7 @@ struct pmu {
 
 	struct module			*module;
 	struct device			*dev;
+	struct device			*parent;
 	const struct attribute_group	**attr_groups;
 	const struct attribute_group	**attr_update;
 	const char			*name;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index fb3e436bcd4a..a84c282221f2 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11367,6 +11367,7 @@ static int pmu_dev_alloc(struct pmu *pmu)
 
 	dev_set_drvdata(pmu->dev, pmu);
 	pmu->dev->bus = &pmu_bus;
+	pmu->dev->parent = pmu->parent;
 	pmu->dev->release = pmu_dev_release;
 
 	ret = dev_set_name(pmu->dev, "%s", pmu->name);
-- 
2.37.2

[PATCH 02/32] perf/hisi-pcie: Assign parent for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the PCI device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/hisilicon/hisi_pcie_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/hisilicon/hisi_pcie_pmu.c b/drivers/perf/hisilicon/hisi_pcie_pmu.c
index 6fee0b6e163b..2cc88d75b895 100644
--- a/drivers/perf/hisilicon/hisi_pcie_pmu.c
+++ b/drivers/perf/hisilicon/hisi_pcie_pmu.c
@@ -793,6 +793,7 @@ static int hisi_pcie_alloc_pmu(struct pci_dev *pdev, struct hisi_pcie_pmu *pcie_
 	pcie_pmu->pmu = (struct pmu) {
 		.name		= name,
 		.module		= THIS_MODULE,
+		.parent		= &pdev->dev,
 		.event_init	= hisi_pcie_pmu_event_init,
 		.pmu_enable	= hisi_pcie_pmu_enable,
 		.pmu_disable	= hisi_pcie_pmu_disable,
-- 
2.37.2

[PATCH 03/32] Documentation: hisi-pmu: Drop reference to /sys/devices path

[Jonathan Cameron]

Having assigned a parent to the device, the suggested path is
no longer valid.  As /sys/bus/event_sources based path is also
provided, simply drop mention of alternative.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 Documentation/admin-guide/perf/hisi-pmu.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/admin-guide/perf/hisi-pmu.rst b/Documentation/admin-guide/perf/hisi-pmu.rst
index 546979360513..1ddab80769d3 100644
--- a/Documentation/admin-guide/perf/hisi-pmu.rst
+++ b/Documentation/admin-guide/perf/hisi-pmu.rst
@@ -20,7 +20,6 @@ interrupt, and the PMU driver shall register perf PMU drivers like L3C,
 HHA and DDRC etc. The available events and configuration options shall
 be described in the sysfs, see:
 
-/sys/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>/, or
 /sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>.
 The "perf list" command shall list the available events from sysfs.
 
-- 
2.37.2

[PATCH 04/32] perf/hisi-uncore: Assign parents for event_source devices

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pmu.c
index f1b0f5e1a28f..b4350e5dc3fc 100644
--- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
@@ -538,6 +538,7 @@ void hisi_pmu_init(struct hisi_pmu *hisi_pmu, const char *name,
 
 	pmu->name               = name;
 	pmu->module             = module;
+	pmu->parent		= hisi_pmu->dev;
 	pmu->task_ctx_nr        = perf_invalid_context;
 	pmu->event_init         = hisi_uncore_pmu_event_init;
 	pmu->pmu_enable         = hisi_uncore_pmu_enable;
-- 
2.37.2

[PATCH 05/32] Documentation: hns-pmu: Use /sys/bus/event_source/devices paths

[Jonathan Cameron]

To allow setting an appropriate parent for the struct pmu device
remove existing references to /sys/devices/ path.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 Documentation/admin-guide/perf/hns3-pmu.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/perf/hns3-pmu.rst b/Documentation/admin-guide/perf/hns3-pmu.rst
index 75a40846d47f..1195e570f2d6 100644
--- a/Documentation/admin-guide/perf/hns3-pmu.rst
+++ b/Documentation/admin-guide/perf/hns3-pmu.rst
@@ -16,7 +16,7 @@ HNS3 PMU driver
 
 The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
 
-  /sys/devices/hns3_pmu_sicl_<sicl_id>
+  /sys/bus/event_source/devices/hns3_pmu_sicl_<sicl_id>
 
 PMU driver provides description of available events, filter modes, format,
 identifier and cpumask in sysfs.
@@ -40,9 +40,9 @@ device.
 
 Example usage of checking event code and subevent code::
 
-  $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
+  $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
   config=0x00204
-  $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
+  $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
   config=0x10204
 
 Each performance statistic has a pair of events to get two values to
@@ -60,7 +60,7 @@ computation to calculate real performance data is:::
 
 Example usage of checking supported filter mode::
 
-  $# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
+  $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
   filter mode supported: global/port/port-tc/func/func-queue/
 
 Example usage of perf::
-- 
2.37.2

[PATCH 06/32] perf/hisi-hns3: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the PCI device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/hisilicon/hns3_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/hisilicon/hns3_pmu.c b/drivers/perf/hisilicon/hns3_pmu.c
index e0457d84af6b..8ddffd8cc1f1 100644
--- a/drivers/perf/hisilicon/hns3_pmu.c
+++ b/drivers/perf/hisilicon/hns3_pmu.c
@@ -1419,6 +1419,7 @@ static int hns3_pmu_alloc_pmu(struct pci_dev *pdev, struct hns3_pmu *hns3_pmu)
 	hns3_pmu->pmu = (struct pmu) {
 		.name		= name,
 		.module		= THIS_MODULE,
+		.parent		= &pdev->dev,
 		.event_init	= hns3_pmu_event_init,
 		.pmu_enable	= hns3_pmu_enable,
 		.pmu_disable	= hns3_pmu_disable,
-- 
2.37.2

[PATCH 07/32] perf/amlogic: Assign parents for event_source devices

[Jonathan Cameron]

Currently all these devices appear directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parents to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Jiucheng Xu <jiucheng.xu@amlogic.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/amlogic/meson_ddr_pmu_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/amlogic/meson_ddr_pmu_core.c b/drivers/perf/amlogic/meson_ddr_pmu_core.c
index b84346dbac2c..e0d3e87457e0 100644
--- a/drivers/perf/amlogic/meson_ddr_pmu_core.c
+++ b/drivers/perf/amlogic/meson_ddr_pmu_core.c
@@ -490,6 +490,7 @@ int meson_ddr_pmu_create(struct platform_device *pdev)
 	*pmu = (struct ddr_pmu) {
 		.pmu = {
 			.module		= THIS_MODULE,
+			.parent		= &pdev->dev,
 			.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
 			.task_ctx_nr	= perf_invalid_context,
 			.attr_groups	= attr_groups,
-- 
2.37.2

[PATCH 08/32] perf/arm_cspmu: Assign parents for event_source devices

[Jonathan Cameron]

Currently all these devices appear directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parents to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index e31302ab7e37..4390e4fb1e95 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -1155,6 +1155,7 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
 	cspmu->pmu = (struct pmu){
 		.task_ctx_nr	= perf_invalid_context,
 		.module		= THIS_MODULE,
+		.parent		= cspmu->dev,
 		.pmu_enable	= arm_cspmu_enable,
 		.pmu_disable	= arm_cspmu_disable,
 		.event_init	= arm_cspmu_event_init,
-- 
2.37.2

[PATCH 09/32] Documentation: xgene-pmu: Use /sys/bus/event_source/devices paths

[Jonathan Cameron]

To allow setting an appropriate parent for the struct pmu device
remove existing references to /sys/devices/ path.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 Documentation/admin-guide/perf/xgene-pmu.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/perf/xgene-pmu.rst b/Documentation/admin-guide/perf/xgene-pmu.rst
index 644f8ed89152..98ccb8e777c4 100644
--- a/Documentation/admin-guide/perf/xgene-pmu.rst
+++ b/Documentation/admin-guide/perf/xgene-pmu.rst
@@ -13,7 +13,7 @@ PMU (perf) driver
 
 The xgene-pmu driver registers several perf PMU drivers. Each of the perf
 driver provides description of its available events and configuration options
-in sysfs, see /sys/devices/<l3cX/iobX/mcbX/mcX>/.
+in sysfs, see /sys/bus/event_source/devices/<l3cX/iobX/mcbX/mcX>/.
 
 The "format" directory describes format of the config (event ID),
 config1 (agent ID) fields of the perf_event_attr structure. The "events"
-- 
2.37.2

[PATCH 10/32] perf/xgene: Assign parents for event_source devices

[Jonathan Cameron]

Currently all these devices appear directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parents to be the hardware related struct device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Khuong Dinh <khuong@os.amperecomputing.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/xgene_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index 0c32dffc7ede..451c01dbc1d6 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -1104,6 +1104,7 @@ static int xgene_init_perf(struct xgene_pmu_dev *pmu_dev, char *name)
 
 	/* Perf driver registration */
 	pmu_dev->pmu = (struct pmu) {
+		.parent		= pmu_dev->parent->dev,
 		.attr_groups	= pmu_dev->attr_groups,
 		.task_ctx_nr	= perf_invalid_context,
 		.pmu_enable	= xgene_perf_pmu_enable,
-- 
2.37.2

[PATCH 11/32] Documentation: thunderx2-pmu: Use /sys/bus/event_source/devices paths

[Jonathan Cameron]

To allow setting an appropriate parent for the struct pmu device
remove existing references to /sys/devices/ path.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 Documentation/admin-guide/perf/thunderx2-pmu.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/perf/thunderx2-pmu.rst b/Documentation/admin-guide/perf/thunderx2-pmu.rst
index 01f158238ae1..9255f7bf9452 100644
--- a/Documentation/admin-guide/perf/thunderx2-pmu.rst
+++ b/Documentation/admin-guide/perf/thunderx2-pmu.rst
@@ -22,7 +22,7 @@ The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and
 L3C devices.  Each PMU can be used to count up to 4 (DMC/L3C) or up to 8
 (CCPI2) events simultaneously. The PMUs provide a description of their
 available events and configuration options under sysfs, see
-/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
+/sys/bus/event_source/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
 
 The driver does not support sampling, therefore "perf record" will not
 work. Per-task perf sessions are also not supported.
-- 
2.37.2

[PATCH 12/32] perf/thunderx2: Assign parents for event_source devices

[Jonathan Cameron]

Currently all these devices appear directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parents to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Robert Richter <rric@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/thunderx2_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index 1edb9c03704f..e58a3523ac8d 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -729,6 +729,7 @@ static int tx2_uncore_pmu_register(
 	/* Perf event registration */
 	tx2_pmu->pmu = (struct pmu) {
 		.module         = THIS_MODULE,
+		.parent		= tx2_pmu->dev,
 		.attr_groups	= tx2_pmu->attr_groups,
 		.task_ctx_nr	= perf_invalid_context,
 		.event_init	= tx2_uncore_event_init,
-- 
2.37.2

[PATCH 13/32] perf/riscv: Assign parents for event_source devices

[Jonathan Cameron]

Currently all these devices appear directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parents to be the appropriate platform devices.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Atish Patra <atishp@atishpatra.org>
CC: Anup Patel <anup@brainfault.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

---

Untested.

This is minimal change, but could be made more elegant either by
making one of the existing initialization functions take a struct device *
or by embedding one in struct riscv_pmu
---
 drivers/perf/riscv_pmu_legacy.c | 1 +
 drivers/perf/riscv_pmu_sbi.c    | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/perf/riscv_pmu_legacy.c b/drivers/perf/riscv_pmu_legacy.c
index ca9e20bfc7ac..8c4a0d915dc7 100644
--- a/drivers/perf/riscv_pmu_legacy.c
+++ b/drivers/perf/riscv_pmu_legacy.c
@@ -102,6 +102,7 @@ static int pmu_legacy_device_probe(struct platform_device *pdev)
 	pmu = riscv_pmu_alloc();
 	if (!pmu)
 		return -ENOMEM;
+	pmu->pmu.parent = &pdev->dev;
 	pmu_legacy_init(pmu);
 
 	return 0;
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 70cb50fd41c2..f138fbc00a66 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -880,6 +880,7 @@ static int pmu_sbi_device_probe(struct platform_device *pdev)
 	}
 
 	pmu->pmu.attr_groups = riscv_pmu_attr_groups;
+	pmu->pmu.parent = &pdev->dev;
 	pmu->cmask = cmask;
 	pmu->ctr_start = pmu_sbi_ctr_start;
 	pmu->ctr_stop = pmu_sbi_ctr_stop;
-- 
2.37.2

[PATCH 14/32] Documentation: qcom-pmu: Use /sys/bus/event_source/devices paths

[Jonathan Cameron]

To allow setting an appropriate parent for the struct pmu device
remove existing references to /sys/devices/ path.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 Documentation/admin-guide/perf/qcom_l2_pmu.rst | 2 +-
 Documentation/admin-guide/perf/qcom_l3_pmu.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/perf/qcom_l2_pmu.rst b/Documentation/admin-guide/perf/qcom_l2_pmu.rst
index c130178a4a55..c37c6be9b8d8 100644
--- a/Documentation/admin-guide/perf/qcom_l2_pmu.rst
+++ b/Documentation/admin-guide/perf/qcom_l2_pmu.rst
@@ -10,7 +10,7 @@ There is one logical L2 PMU exposed, which aggregates the results from
 the physical PMUs.
 
 The driver provides a description of its available events and configuration
-options in sysfs, see /sys/devices/l2cache_0.
+options in sysfs, see /sys/bus/event_source/devices/l2cache_0.
 
 The "format" directory describes the format of the events.
 
diff --git a/Documentation/admin-guide/perf/qcom_l3_pmu.rst b/Documentation/admin-guide/perf/qcom_l3_pmu.rst
index a3d014a46bfd..a66556b7e985 100644
--- a/Documentation/admin-guide/perf/qcom_l3_pmu.rst
+++ b/Documentation/admin-guide/perf/qcom_l3_pmu.rst
@@ -9,7 +9,7 @@ PMU with device name l3cache_<socket>_<instance>. User space is responsible
 for aggregating across slices.
 
 The driver provides a description of its available events and configuration
-options in sysfs, see /sys/devices/l3cache*. Given that these are uncore PMUs
+options in sysfs, see /sys/bus/event_source/devices/l3cache*. Given that these are uncore PMUs
 the driver also exposes a "cpumask" sysfs attribute which contains a mask
 consisting of one CPU per socket which will be used to handle all the PMU
 events on that socket.
-- 
2.37.2

[PATCH 15/32] perf/qcom: Assign parents for event_source devices

[Jonathan Cameron]

Currently all these devices appear directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parents to be the platform devices.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/qcom_l2_pmu.c | 1 +
 drivers/perf/qcom_l3_pmu.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/perf/qcom_l2_pmu.c b/drivers/perf/qcom_l2_pmu.c
index aaca6db7d8f6..b047282cdda8 100644
--- a/drivers/perf/qcom_l2_pmu.c
+++ b/drivers/perf/qcom_l2_pmu.c
@@ -904,6 +904,7 @@ static int l2_cache_pmu_probe(struct platform_device *pdev)
 	l2cache_pmu->pmu = (struct pmu) {
 		/* suffix is instance id for future use with multiple sockets */
 		.name		= "l2cache_0",
+		.parent		= &pdev->dev,
 		.task_ctx_nr    = perf_invalid_context,
 		.pmu_enable	= l2_cache_pmu_enable,
 		.pmu_disable	= l2_cache_pmu_disable,
diff --git a/drivers/perf/qcom_l3_pmu.c b/drivers/perf/qcom_l3_pmu.c
index 346311a05460..f693a6d9e7e1 100644
--- a/drivers/perf/qcom_l3_pmu.c
+++ b/drivers/perf/qcom_l3_pmu.c
@@ -748,6 +748,7 @@ static int qcom_l3_cache_pmu_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	l3pmu->pmu = (struct pmu) {
+		.parent		= &pdev->dev,
 		.task_ctx_nr	= perf_invalid_context,
 
 		.pmu_enable	= qcom_l3_cache__pmu_enable,
-- 
2.37.2

[PATCH 16/32] perf/imx_ddr: Assign parents for event_source devices

[Jonathan Cameron]

Currently all this device appear directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Frank Li <Frank.li@nxp.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/fsl_imx8_ddr_perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 5222ba1e79d0..e73b83487bb0 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -592,6 +592,7 @@ static int ddr_perf_init(struct ddr_pmu *pmu, void __iomem *base,
 	*pmu = (struct ddr_pmu) {
 		.pmu = (struct pmu) {
 			.module	      = THIS_MODULE,
+			.parent      = dev,
 			.capabilities = PERF_PMU_CAP_NO_EXCLUDE,
 			.task_ctx_nr = perf_invalid_context,
 			.attr_groups = attr_groups,
-- 
2.37.2

[PATCH 17/32] perf/arm_pmu: Assign parents for event_source devices

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

---
Note that the ACPI path for this driver has no obvious 'parent' to
use so I've left that for now. See armv8_pmu_driver_init() in
arch/arm64/kernel/perf_event.c Suggestions welcome!
---
 drivers/perf/arm_pmu_platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm_pmu_platform.c b/drivers/perf/arm_pmu_platform.c
index 933b96e243b8..705ed45402ff 100644
--- a/drivers/perf/arm_pmu_platform.c
+++ b/drivers/perf/arm_pmu_platform.c
@@ -197,6 +197,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 	if (!pmu)
 		return -ENOMEM;
 
+	pmu->pmu.parent = &pdev->dev;
 	pmu->plat_device = pdev;
 
 	ret = pmu_parse_irqs(pmu);
-- 
2.37.2

[PATCH 18/32] perf/alibaba_uncore: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/alibaba_uncore_drw_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
index a7689fecb49d..0d129acf3f84 100644
--- a/drivers/perf/alibaba_uncore_drw_pmu.c
+++ b/drivers/perf/alibaba_uncore_drw_pmu.c
@@ -683,6 +683,7 @@ static int ali_drw_pmu_probe(struct platform_device *pdev)
 
 	drw_pmu->pmu = (struct pmu) {
 		.module		= THIS_MODULE,
+		.parent		= &pdev->dev,
 		.task_ctx_nr	= perf_invalid_context,
 		.event_init	= ali_drw_pmu_event_init,
 		.add		= ali_drw_pmu_add,
-- 
2.37.2

[PATCH 19/32] perf/arm-cci: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm-cci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 03b1309875ae..502581ba7d15 100644
--- a/drivers/perf/arm-cci.c
+++ b/drivers/perf/arm-cci.c
@@ -1412,6 +1412,7 @@ static int cci_pmu_init(struct cci_pmu *cci_pmu, struct platform_device *pdev)
 
 	cci_pmu->pmu = (struct pmu) {
 		.module		= THIS_MODULE,
+		.parent		= &pdev->dev,
 		.name		= cci_pmu->model->name,
 		.task_ctx_nr	= perf_invalid_context,
 		.pmu_enable	= cci_pmu_enable,
-- 
2.37.2

[PATCH 20/32] perf/arm-ccn: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm-ccn.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm-ccn.c b/drivers/perf/arm-ccn.c
index 728d13d8e98a..dc8b0dcb436e 100644
--- a/drivers/perf/arm-ccn.c
+++ b/drivers/perf/arm-ccn.c
@@ -1265,6 +1265,7 @@ static int arm_ccn_pmu_init(struct arm_ccn *ccn)
 	/* Perf driver registration */
 	ccn->dt.pmu = (struct pmu) {
 		.module = THIS_MODULE,
+		.parent = ccn->dev,
 		.attr_groups = arm_ccn_pmu_attr_groups,
 		.task_ctx_nr = perf_invalid_context,
 		.event_init = arm_ccn_pmu_event_init,
-- 
2.37.2

[PATCH 21/32] perf/arm-cmn: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm-cmn.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index c9689861be3f..7731eb0e2a4a 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -2284,6 +2284,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
 	cmn->cpu = cpumask_local_spread(0, dev_to_node(cmn->dev));
 	cmn->pmu = (struct pmu) {
 		.module = THIS_MODULE,
+		.parent = &pdev->dev,
 		.attr_groups = arm_cmn_attr_groups,
 		.capabilities = PERF_PMU_CAP_NO_EXCLUDE,
 		.task_ctx_nr = perf_invalid_context,
-- 
2.37.2

[PATCH 22/32] perf/arm-dmc620: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm_dmc620_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm_dmc620_pmu.c b/drivers/perf/arm_dmc620_pmu.c
index 54aa4658fb36..c99360cc8f6d 100644
--- a/drivers/perf/arm_dmc620_pmu.c
+++ b/drivers/perf/arm_dmc620_pmu.c
@@ -644,6 +644,7 @@ static int dmc620_pmu_device_probe(struct platform_device *pdev)
 
 	dmc620_pmu->pmu = (struct pmu) {
 		.module = THIS_MODULE,
+		.parent		= &pdev->dev,
 		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
 		.task_ctx_nr	= perf_invalid_context,
 		.event_init	= dmc620_pmu_event_init,
-- 
2.37.2

[PATCH 23/32] perf/arm-dsu: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm_dsu_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
index fe2abb412c00..de75c00cb456 100644
--- a/drivers/perf/arm_dsu_pmu.c
+++ b/drivers/perf/arm_dsu_pmu.c
@@ -751,6 +751,7 @@ static int dsu_pmu_device_probe(struct platform_device *pdev)
 
 	dsu_pmu->pmu = (struct pmu) {
 		.task_ctx_nr	= perf_invalid_context,
+		.parent		= &pdev->dev,
 		.module		= THIS_MODULE,
 		.pmu_enable	= dsu_pmu_enable,
 		.pmu_disable	= dsu_pmu_disable,
-- 
2.37.2

[PATCH 24/32] perf/arm-smmuv3: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm_smmuv3_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 25a269d431e4..7b3edccae535 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -826,6 +826,7 @@ static int smmu_pmu_probe(struct platform_device *pdev)
 
 	smmu_pmu->pmu = (struct pmu) {
 		.module		= THIS_MODULE,
+		.parent		= &pdev->dev,
 		.task_ctx_nr    = perf_invalid_context,
 		.pmu_enable	= smmu_pmu_enable,
 		.pmu_disable	= smmu_pmu_disable,
-- 
2.37.2

[PATCH 25/32] perf/arm-spe: Assign parents for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/perf/arm_spe_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index b9ba4c4fe5a2..a98ef633fa00 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -955,6 +955,7 @@ static int arm_spe_pmu_perf_init(struct arm_spe_pmu *spe_pmu)
 
 	spe_pmu->pmu = (struct pmu) {
 		.module = THIS_MODULE,
+		.parent		= &spe_pmu->pdev->dev,
 		.capabilities	= PERF_PMU_CAP_EXCLUSIVE | PERF_PMU_CAP_ITRACE,
 		.attr_groups	= arm_spe_pmu_attr_groups,
 		/*
-- 
2.37.2

[PATCH 26/32] arc: Assign parents for event_source devices

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Vineet Gupta <vgupta@kernel.org>002
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 arch/arc/kernel/perf_event.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
index adff957962da..bd4c2c110afe 100644
--- a/arch/arc/kernel/perf_event.c
+++ b/arch/arc/kernel/perf_event.c
@@ -788,6 +788,7 @@ static int arc_pmu_device_probe(struct platform_device *pdev)
 	arc_pmu->attr_groups[ARCPMU_ATTR_GR_FORMATS] = &arc_pmu_format_attr_gr;
 
 	arc_pmu->pmu = (struct pmu) {
+		.parent		= &pdev->dev,
 		.pmu_enable	= arc_pmu_enable,
 		.pmu_disable	= arc_pmu_disable,
 		.event_init	= arc_pmu_event_init,
-- 
2.37.2

[PATCH 27/32] ARM: imx: Assign parents for mmdc event_source devices

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 arch/arm/mach-imx/mmdc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index b9efe9da06e0..a015e0ea915d 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm/mach-imx/mmdc.c
@@ -436,6 +436,7 @@ static int mmdc_pmu_init(struct mmdc_pmu *pmu_mmdc,
 {
 	*pmu_mmdc = (struct mmdc_pmu) {
 		.pmu = (struct pmu) {
+			.parent		= dev,
 			.task_ctx_nr    = perf_invalid_context,
 			.attr_groups    = attr_groups,
 			.event_init     = mmdc_pmu_event_init,
-- 
2.37.2

[PATCH 28/32] dmaengine: idxd: Assign parent for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the iDXD PCI Device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/dma/idxd/perfmon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/idxd/perfmon.c b/drivers/dma/idxd/perfmon.c
index d73004f47cf4..4d61334a814a 100644
--- a/drivers/dma/idxd/perfmon.c
+++ b/drivers/dma/idxd/perfmon.c
@@ -478,6 +478,7 @@ static void idxd_pmu_init(struct idxd_pmu *idxd_pmu)
 	}
 
 	idxd_pmu->pmu.name		= idxd_pmu->name;
+	idxd_pmu->pmu.parent		= &idxd_pmu->idxd->pdev->dev;
 	idxd_pmu->pmu.attr_groups	= perfmon_attr_groups;
 	idxd_pmu->pmu.task_ctx_nr	= perf_invalid_context;
 	idxd_pmu->pmu.event_init	= perfmon_pmu_event_init;
-- 
2.37.2

[PATCH 29/32] fpga: dfl: Assign parent for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the Platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Wu Hao <hao.wu@intel.com>
Cc: Tom Rix <trix@redhat.com>
Cc: linux-fpga@vger.kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/fpga/dfl-fme-perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
index 7422d2bc6f37..2d59f1c620b1 100644
--- a/drivers/fpga/dfl-fme-perf.c
+++ b/drivers/fpga/dfl-fme-perf.c
@@ -912,6 +912,7 @@ static int fme_perf_pmu_register(struct platform_device *pdev,
 
 	fme_perf_setup_hardware(priv);
 
+	pmu->parent =		&pdev->dev;
 	pmu->task_ctx_nr =	perf_invalid_context;
 	pmu->attr_groups =	fme_perf_groups;
 	pmu->attr_update =	fme_perf_events_groups;
-- 
2.37.2

[PATCH 30/32] drivers/nvdimm: Assign parent for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the platform device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: nvdimm@lists.linux.dev
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/nvdimm/nd_perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvdimm/nd_perf.c b/drivers/nvdimm/nd_perf.c
index 433bbb68ae64..67de6069edfb 100644
--- a/drivers/nvdimm/nd_perf.c
+++ b/drivers/nvdimm/nd_perf.c
@@ -292,6 +292,7 @@ int register_nvdimm_pmu(struct nvdimm_pmu *nd_pmu, struct platform_device *pdev)
 	 * device data in events functions.
 	 */
 	nd_pmu->dev = &pdev->dev;
+	nd_pmu->pmu.parent = &pdev->dev;
 
 	/* Fill attribute groups for the nvdimm pmu device */
 	nd_pmu->pmu.attr_groups[NVDIMM_PMU_FORMAT_ATTR] = &nvdimm_pmu_format_group;
-- 
2.37.2

[PATCH 31/32] Documentation: ABI + trace: hisi_ptt: update paths to bus/event_source

[Jonathan Cameron]

To allow for assigning a suitable parent to the struct pmu device
update the documentation to describe the device via the event_source
bus where it will remain accessible.

For the ABI documention file also rename the file as it is named
after the path.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 ...i_ptt => sysfs-bus-event_source-devices-hisi_ptt} | 12 ++++++------
 Documentation/trace/hisi-ptt.rst                     |  4 ++--
 MAINTAINERS                                          |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-devices-hisi_ptt b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
similarity index 83%
rename from Documentation/ABI/testing/sysfs-devices-hisi_ptt
rename to Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
index 82de6d710266..f2f48f7ce887 100644
--- a/Documentation/ABI/testing/sysfs-devices-hisi_ptt
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
@@ -1,4 +1,4 @@
-What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune
+What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune
 Date:		October 2022
 KernelVersion:	6.1
 Contact:	Yicong Yang <yangyicong@hisilicon.com>
@@ -8,7 +8,7 @@ Description:	This directory contains files for tuning the PCIe link
 
 		See Documentation/trace/hisi-ptt.rst for more information.
 
-What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
+What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
 Date:		October 2022
 KernelVersion:	6.1
 Contact:	Yicong Yang <yangyicong@hisilicon.com>
@@ -18,7 +18,7 @@ Description:	(RW) Controls the weight of Tx completion TLPs, which influence
 		will return an error, and out of range values will be converted
 		to 2. The value indicates a probable level of the event.
 
-What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
+What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
 Date:		October 2022
 KernelVersion:	6.1
 Contact:	Yicong Yang <yangyicong@hisilicon.com>
@@ -28,7 +28,7 @@ Description:	(RW) Controls the weight of Tx non-posted TLPs, which influence
 		will return an error, and out of range values will be converted
 		to 2. The value indicates a probable level of the event.
 
-What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
+What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
 Date:		October 2022
 KernelVersion:	6.1
 Contact:	Yicong Yang <yangyicong@hisilicon.com>
@@ -38,7 +38,7 @@ Description:	(RW) Controls the weight of Tx posted TLPs, which influence the
 		will return an error, and out of range values will be converted
 		to 2. The value indicates a probable level of the event.
 
-What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
+What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
 Date:		October 2022
 KernelVersion:	6.1
 Contact:	Yicong Yang <yangyicong@hisilicon.com>
@@ -49,7 +49,7 @@ Description:	(RW) Control the allocated buffer watermark for inbound packets.
 		will return an error, and out of range values will be converted
 		to 2. The value indicates a probable level of the event.
 
-What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
+What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
 Date:		October 2022
 KernelVersion:	6.1
 Contact:	Yicong Yang <yangyicong@hisilicon.com>
diff --git a/Documentation/trace/hisi-ptt.rst b/Documentation/trace/hisi-ptt.rst
index 4f87d8e21065..d923e09fcbaa 100644
--- a/Documentation/trace/hisi-ptt.rst
+++ b/Documentation/trace/hisi-ptt.rst
@@ -40,7 +40,7 @@ IO dies (SICL, Super I/O Cluster), where there's one PCIe Root
 Complex for each SICL.
 ::
 
-    /sys/devices/hisi_ptt<sicl_id>_<core_id>
+    /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>
 
 Tune
 ====
@@ -53,7 +53,7 @@ Each event is presented as a file under $(PTT PMU dir)/tune, and
 a simple open/read/write/close cycle will be used to tune the event.
 ::
 
-    $ cd /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune
+    $ cd /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune
     $ ls
     qos_tx_cpl    qos_tx_np    qos_tx_p
     tx_path_rx_req_alloc_buf_level
diff --git a/MAINTAINERS b/MAINTAINERS
index d8ebab595b2a..75019f62b1df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9266,7 +9266,7 @@ M:	Yicong Yang <yangyicong@hisilicon.com>
 M:	Jonathan Cameron <jonathan.cameron@huawei.com>
 L:	linux-kernel@vger.kernel.org
 S:	Maintained
-F:	Documentation/ABI/testing/sysfs-devices-hisi_ptt
+F:	Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
 F:	Documentation/trace/hisi-ptt.rst
 F:	drivers/hwtracing/ptt/
 F:	tools/perf/arch/arm64/util/hisi-ptt.c
-- 
2.37.2

[PATCH 32/32] hwtracing: hisi_ptt: Assign parent for event_source device

[Jonathan Cameron]

Currently the PMU device appears directly under /sys/devices/
Only root busses should appear there, so instead assign the pmu->dev
parent to be the PCI device.

Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/hwtracing/ptt/hisi_ptt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwtracing/ptt/hisi_ptt.c b/drivers/hwtracing/ptt/hisi_ptt.c
index 30f1525639b5..3868d43e9e3c 100644
--- a/drivers/hwtracing/ptt/hisi_ptt.c
+++ b/drivers/hwtracing/ptt/hisi_ptt.c
@@ -871,6 +871,7 @@ static int hisi_ptt_register_pmu(struct hisi_ptt *hisi_ptt)
 
 	hisi_ptt->hisi_ptt_pmu = (struct pmu) {
 		.module		= THIS_MODULE,
+		.parent		= &hisi_ptt->pdev->dev,
 		.capabilities	= PERF_PMU_CAP_EXCLUSIVE | PERF_PMU_CAP_ITRACE,
 		.task_ctx_nr	= perf_sw_context,
 		.attr_groups	= hisi_ptt_pmu_groups,
-- 
2.37.2

Re: [PATCH 00/32] Add parents to struct pmu -> dev

[Greg KH]

On Tue, Apr 04, 2023 at 02:41:53PM +0100, Jonathan Cameron wrote:
> These are the low hanging fruit following GregKH's feedback that
> all the devices registered via perf_pmu_register() should have parents.
> 
> Note that this causes potential ABI breakage.
> 
> It may fall in the category of it isn't breakage if no one notices
> but I can't be certain of that.  Whilst it is arguable that
> no one should be been accessing PMUs except via the event_source
> bus, there was documentation suggesting /sys/devices/ for particular
> PMUs (because it was a shorter path?)

devices can always move around /sys/devices/ as there is not a guarantee
that they will ever be in the same place.  That's what /sys/class/ is
used to find (and /sys/bus/ in some cases.)

And even then, the naming scheme is variable, and can and will change
(i.e. bus ids), so that too is not required to stay the same.

thanks for doing this work, I'll add it to my review queue...

greg k-h

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Greg KH]

On Tue, Apr 04, 2023 at 02:41:54PM +0100, Jonathan Cameron wrote:
> Some PMUs have well defined parents such as PCI devices.
> As the device_initialize() and device_add() are all within
> pmu_dev_alloc() which is called from perf_pmu_register()
> there is no opportunity to set the parent from within a driver.
> 
> Add a struct device *parent field to struct pmu and use that
> to set the parent.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> 

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 02/32] perf/hisi-pcie: Assign parent for event_source device

[Greg KH]

On Tue, Apr 04, 2023 at 02:41:55PM +0100, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the PCI device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>  drivers/perf/hisilicon/hisi_pcie_pmu.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 03/32] Documentation: hisi-pmu: Drop reference to /sys/devices path

[Greg KH]

On Tue, Apr 04, 2023 at 02:41:56PM +0100, Jonathan Cameron wrote:
> Having assigned a parent to the device, the suggested path is
> no longer valid.  As /sys/bus/event_sources based path is also
> provided, simply drop mention of alternative.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 04/32] perf/hisi-uncore: Assign parents for event_source devices

[Greg KH]

On Tue, Apr 04, 2023 at 02:41:57PM +0100, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 05/32] Documentation: hns-pmu: Use /sys/bus/event_source/devices paths

[Greg KH]

On Tue, Apr 04, 2023 at 02:41:58PM +0100, Jonathan Cameron wrote:
> To allow setting an appropriate parent for the struct pmu device
> remove existing references to /sys/devices/ path.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 00/32] Add parents to struct pmu -> dev

[Greg KH]

On Tue, Apr 04, 2023 at 02:41:53PM +0100, Jonathan Cameron wrote:
> These are the low hanging fruit following GregKH's feedback that
> all the devices registered via perf_pmu_register() should have parents.
> 
> Note that this causes potential ABI breakage.
> 
> It may fall in the category of it isn't breakage if no one notices
> but I can't be certain of that.  Whilst it is arguable that
> no one should be been accessing PMUs except via the event_source
> bus, there was documentation suggesting /sys/devices/ for particular
> PMUs (because it was a shorter path?)
> 
> The first patch is pulled out of the series:
> https://lore.kernel.org/linux-cxl/20230327170247.6968-1-Jonathan.Cameron@huawei.com/
> [PATCH v3 0/5] CXL 3.0 Performance Monitoring Unit support
> 
> In that particular case it is very useful to be able to figure out which
> CXL device the PMU device is associated with and looking at it's parents
> in the device model as shown with ls -lh /sys/bus/event_sources/devices/
> is a very easy way to do this (once it is correctly parented).
> 
> Addressing all the other instances of struct pmu not covered by this series
> is likely to be a more complex discussion but unlikely to have an affect
> on what is proposed here.
> 
> Documentation updates deliberately 'fixed' in separate patches before
> changing the path to highlight that using /sys/bus/event_source/devices
> path is unchanged by this series and that is presumed to be the
> most common way these files are accessed.

For the whole series, looks good:

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 19/32] perf/arm-cci: Assign parents for event_source device

[Suzuki K Poulose]

On 04/04/2023 14:42, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>


> ---
>   drivers/perf/arm-cci.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
> index 03b1309875ae..502581ba7d15 100644
> --- a/drivers/perf/arm-cci.c
> +++ b/drivers/perf/arm-cci.c
> @@ -1412,6 +1412,7 @@ static int cci_pmu_init(struct cci_pmu *cci_pmu, struct platform_device *pdev)
>   
>   	cci_pmu->pmu = (struct pmu) {
>   		.module		= THIS_MODULE,
> +		.parent		= &pdev->dev,
>   		.name		= cci_pmu->model->name,
>   		.task_ctx_nr	= perf_invalid_context,
>   		.pmu_enable	= cci_pmu_enable,

Re: [PATCH 08/32] perf/arm_cspmu: Assign parents for event_source devices

[Suzuki K Poulose]

On 04/04/2023 14:42, Jonathan Cameron wrote:
> Currently all these devices appear directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parents to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>   drivers/perf/arm_cspmu/arm_cspmu.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index e31302ab7e37..4390e4fb1e95 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -1155,6 +1155,7 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
>   	cspmu->pmu = (struct pmu){
>   		.task_ctx_nr	= perf_invalid_context,
>   		.module		= THIS_MODULE,
> +		.parent		= cspmu->dev,
>   		.pmu_enable	= arm_cspmu_enable,
>   		.pmu_disable	= arm_cspmu_disable,
>   		.event_init	= arm_cspmu_event_init,

Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Re: [PATCH 23/32] perf/arm-dsu: Assign parents for event_source device

[Suzuki K Poulose]

On 04/04/2023 14:42, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>   drivers/perf/arm_dsu_pmu.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
> index fe2abb412c00..de75c00cb456 100644
> --- a/drivers/perf/arm_dsu_pmu.c
> +++ b/drivers/perf/arm_dsu_pmu.c
> @@ -751,6 +751,7 @@ static int dsu_pmu_device_probe(struct platform_device *pdev)
>   
>   	dsu_pmu->pmu = (struct pmu) {
>   		.task_ctx_nr	= perf_invalid_context,
> +		.parent		= &pdev->dev,
>   		.module		= THIS_MODULE,
>   		.pmu_enable	= dsu_pmu_enable,
>   		.pmu_disable	= dsu_pmu_disable,

Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Re: [PATCH 18/32] perf/alibaba_uncore: Assign parents for event_source device

[Shuai Xue]

On 2023/4/4 PM9:42, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Cc: Shuai Xue <xueshuai@linux.alibaba.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>  drivers/perf/alibaba_uncore_drw_pmu.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
> index a7689fecb49d..0d129acf3f84 100644
> --- a/drivers/perf/alibaba_uncore_drw_pmu.c
> +++ b/drivers/perf/alibaba_uncore_drw_pmu.c
> @@ -683,6 +683,7 @@ static int ali_drw_pmu_probe(struct platform_device *pdev)
>  
>  	drw_pmu->pmu = (struct pmu) {
>  		.module		= THIS_MODULE,
> +		.parent		= &pdev->dev,
>  		.task_ctx_nr	= perf_invalid_context,
>  		.event_init	= ali_drw_pmu_event_init,
>  		.add		= ali_drw_pmu_add,


Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>

Thank you.

Best Regards,
Shuai

RE: [PATCH 30/32] drivers/nvdimm: Assign parent for event_source device

[Dan Williams]

Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: nvdimm@lists.linux.dev
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Dan Williams <dan.j.williams@intel.com>

Re: [PATCH 31/32] Documentation: ABI + trace: hisi_ptt: update paths to bus/event_source

[Yicong Yang]

On 2023/4/4 21:42, Jonathan Cameron wrote:
> To allow for assigning a suitable parent to the struct pmu device
> update the documentation to describe the device via the event_source
> bus where it will remain accessible.
> 
> For the ABI documention file also rename the file as it is named
> after the path.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>

> ---
>  ...i_ptt => sysfs-bus-event_source-devices-hisi_ptt} | 12 ++++++------
>  Documentation/trace/hisi-ptt.rst                     |  4 ++--
>  MAINTAINERS                                          |  2 +-
>  3 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-devices-hisi_ptt b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
> similarity index 83%
> rename from Documentation/ABI/testing/sysfs-devices-hisi_ptt
> rename to Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
> index 82de6d710266..f2f48f7ce887 100644
> --- a/Documentation/ABI/testing/sysfs-devices-hisi_ptt
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
> @@ -1,4 +1,4 @@
> -What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune
> +What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune
>  Date:		October 2022
>  KernelVersion:	6.1
>  Contact:	Yicong Yang <yangyicong@hisilicon.com>
> @@ -8,7 +8,7 @@ Description:	This directory contains files for tuning the PCIe link
>  
>  		See Documentation/trace/hisi-ptt.rst for more information.
>  
> -What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
> +What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
>  Date:		October 2022
>  KernelVersion:	6.1
>  Contact:	Yicong Yang <yangyicong@hisilicon.com>
> @@ -18,7 +18,7 @@ Description:	(RW) Controls the weight of Tx completion TLPs, which influence
>  		will return an error, and out of range values will be converted
>  		to 2. The value indicates a probable level of the event.
>  
> -What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
> +What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
>  Date:		October 2022
>  KernelVersion:	6.1
>  Contact:	Yicong Yang <yangyicong@hisilicon.com>
> @@ -28,7 +28,7 @@ Description:	(RW) Controls the weight of Tx non-posted TLPs, which influence
>  		will return an error, and out of range values will be converted
>  		to 2. The value indicates a probable level of the event.
>  
> -What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
> +What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
>  Date:		October 2022
>  KernelVersion:	6.1
>  Contact:	Yicong Yang <yangyicong@hisilicon.com>
> @@ -38,7 +38,7 @@ Description:	(RW) Controls the weight of Tx posted TLPs, which influence the
>  		will return an error, and out of range values will be converted
>  		to 2. The value indicates a probable level of the event.
>  
> -What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
> +What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
>  Date:		October 2022
>  KernelVersion:	6.1
>  Contact:	Yicong Yang <yangyicong@hisilicon.com>
> @@ -49,7 +49,7 @@ Description:	(RW) Control the allocated buffer watermark for inbound packets.
>  		will return an error, and out of range values will be converted
>  		to 2. The value indicates a probable level of the event.
>  
> -What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
> +What:		/sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
>  Date:		October 2022
>  KernelVersion:	6.1
>  Contact:	Yicong Yang <yangyicong@hisilicon.com>
> diff --git a/Documentation/trace/hisi-ptt.rst b/Documentation/trace/hisi-ptt.rst
> index 4f87d8e21065..d923e09fcbaa 100644
> --- a/Documentation/trace/hisi-ptt.rst
> +++ b/Documentation/trace/hisi-ptt.rst
> @@ -40,7 +40,7 @@ IO dies (SICL, Super I/O Cluster), where there's one PCIe Root
>  Complex for each SICL.
>  ::
>  
> -    /sys/devices/hisi_ptt<sicl_id>_<core_id>
> +    /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>
>  
>  Tune
>  ====
> @@ -53,7 +53,7 @@ Each event is presented as a file under $(PTT PMU dir)/tune, and
>  a simple open/read/write/close cycle will be used to tune the event.
>  ::
>  
> -    $ cd /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune
> +    $ cd /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune
>      $ ls
>      qos_tx_cpl    qos_tx_np    qos_tx_p
>      tx_path_rx_req_alloc_buf_level
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d8ebab595b2a..75019f62b1df 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9266,7 +9266,7 @@ M:	Yicong Yang <yangyicong@hisilicon.com>
>  M:	Jonathan Cameron <jonathan.cameron@huawei.com>
>  L:	linux-kernel@vger.kernel.org
>  S:	Maintained
> -F:	Documentation/ABI/testing/sysfs-devices-hisi_ptt
> +F:	Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
>  F:	Documentation/trace/hisi-ptt.rst
>  F:	drivers/hwtracing/ptt/
>  F:	tools/perf/arch/arm64/util/hisi-ptt.c
> 

Re: [PATCH 32/32] hwtracing: hisi_ptt: Assign parent for event_source device

[Yicong Yang]

On 2023/4/4 21:42, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the PCI device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Cc: Yicong Yang <yangyicong@hisilicon.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>

> ---
>  drivers/hwtracing/ptt/hisi_ptt.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/hwtracing/ptt/hisi_ptt.c b/drivers/hwtracing/ptt/hisi_ptt.c
> index 30f1525639b5..3868d43e9e3c 100644
> --- a/drivers/hwtracing/ptt/hisi_ptt.c
> +++ b/drivers/hwtracing/ptt/hisi_ptt.c
> @@ -871,6 +871,7 @@ static int hisi_ptt_register_pmu(struct hisi_ptt *hisi_ptt)
>  
>  	hisi_ptt->hisi_ptt_pmu = (struct pmu) {
>  		.module		= THIS_MODULE,
> +		.parent		= &hisi_ptt->pdev->dev,
>  		.capabilities	= PERF_PMU_CAP_EXCLUSIVE | PERF_PMU_CAP_ITRACE,
>  		.task_ctx_nr	= perf_sw_context,
>  		.attr_groups	= hisi_ptt_pmu_groups,
> 

Re: [PATCH 02/32] perf/hisi-pcie: Assign parent for event_source device

[Yicong Yang]

On 2023/4/4 21:41, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the PCI device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>

> ---
>  drivers/perf/hisilicon/hisi_pcie_pmu.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/hisilicon/hisi_pcie_pmu.c b/drivers/perf/hisilicon/hisi_pcie_pmu.c
> index 6fee0b6e163b..2cc88d75b895 100644
> --- a/drivers/perf/hisilicon/hisi_pcie_pmu.c
> +++ b/drivers/perf/hisilicon/hisi_pcie_pmu.c
> @@ -793,6 +793,7 @@ static int hisi_pcie_alloc_pmu(struct pci_dev *pdev, struct hisi_pcie_pmu *pcie_
>  	pcie_pmu->pmu = (struct pmu) {
>  		.name		= name,
>  		.module		= THIS_MODULE,
> +		.parent		= &pdev->dev,
>  		.event_init	= hisi_pcie_pmu_event_init,
>  		.pmu_enable	= hisi_pcie_pmu_enable,
>  		.pmu_disable	= hisi_pcie_pmu_disable,
> 

Re: [PATCH 03/32] Documentation: hisi-pmu: Drop reference to /sys/devices path

[Yicong Yang]

On 2023/4/4 21:41, Jonathan Cameron wrote:
> Having assigned a parent to the device, the suggested path is
> no longer valid.  As /sys/bus/event_sources based path is also
> provided, simply drop mention of alternative.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>

> ---
>  Documentation/admin-guide/perf/hisi-pmu.rst | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/perf/hisi-pmu.rst b/Documentation/admin-guide/perf/hisi-pmu.rst
> index 546979360513..1ddab80769d3 100644
> --- a/Documentation/admin-guide/perf/hisi-pmu.rst
> +++ b/Documentation/admin-guide/perf/hisi-pmu.rst
> @@ -20,7 +20,6 @@ interrupt, and the PMU driver shall register perf PMU drivers like L3C,
>  HHA and DDRC etc. The available events and configuration options shall
>  be described in the sysfs, see:
>  
> -/sys/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>/, or
>  /sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>.
>  The "perf list" command shall list the available events from sysfs.
>  
> 

Re: [PATCH 04/32] perf/hisi-uncore: Assign parents for event_source devices

[Yicong Yang]

On 2023/4/4 21:41, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>

> ---
>  drivers/perf/hisilicon/hisi_uncore_pmu.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pmu.c
> index f1b0f5e1a28f..b4350e5dc3fc 100644
> --- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
> +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
> @@ -538,6 +538,7 @@ void hisi_pmu_init(struct hisi_pmu *hisi_pmu, const char *name,
>  
>  	pmu->name               = name;
>  	pmu->module             = module;
> +	pmu->parent		= hisi_pmu->dev;
>  	pmu->task_ctx_nr        = perf_invalid_context;
>  	pmu->event_init         = hisi_uncore_pmu_event_init;
>  	pmu->pmu_enable         = hisi_uncore_pmu_enable;
> 

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Yicong Yang]

On 2023/4/4 21:41, Jonathan Cameron wrote:
> Some PMUs have well defined parents such as PCI devices.
> As the device_initialize() and device_add() are all within
> pmu_dev_alloc() which is called from perf_pmu_register()
> there is no opportunity to set the parent from within a driver.
> 
> Add a struct device *parent field to struct pmu and use that
> to set the parent.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> 
> ---
> Previously posted in CPMU series hence the change log.
> v3: No change
> ---
>  include/linux/perf_event.h | 1 +
>  kernel/events/core.c       | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index d5628a7b5eaa..b99db1eda72c 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -303,6 +303,7 @@ struct pmu {
>  
>  	struct module			*module;
>  	struct device			*dev;
> +	struct device			*parent;
>  	const struct attribute_group	**attr_groups;
>  	const struct attribute_group	**attr_update;
>  	const char			*name;
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index fb3e436bcd4a..a84c282221f2 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -11367,6 +11367,7 @@ static int pmu_dev_alloc(struct pmu *pmu)
>  
>  	dev_set_drvdata(pmu->dev, pmu);
>  	pmu->dev->bus = &pmu_bus;
> +	pmu->dev->parent = pmu->parent;

If there's no parent assigned, is it ok to add some check here? Then we can find it earlier
maybe at develop stage.

Thanks.

>  	pmu->dev->release = pmu_dev_release;
>  
>  	ret = dev_set_name(pmu->dev, "%s", pmu->name);
> 

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Jonathan Cameron]

On Thu, 6 Apr 2023 12:03:27 +0800
Yicong Yang <yangyicong@huawei.com> wrote:

> On 2023/4/4 21:41, Jonathan Cameron wrote:
> > Some PMUs have well defined parents such as PCI devices.
> > As the device_initialize() and device_add() are all within
> > pmu_dev_alloc() which is called from perf_pmu_register()
> > there is no opportunity to set the parent from within a driver.
> > 
> > Add a struct device *parent field to struct pmu and use that
> > to set the parent.
> > 
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > 
> > ---
> > Previously posted in CPMU series hence the change log.
> > v3: No change
> > ---
> >  include/linux/perf_event.h | 1 +
> >  kernel/events/core.c       | 1 +
> >  2 files changed, 2 insertions(+)
> > 
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index d5628a7b5eaa..b99db1eda72c 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -303,6 +303,7 @@ struct pmu {
> >  
> >  	struct module			*module;
> >  	struct device			*dev;
> > +	struct device			*parent;
> >  	const struct attribute_group	**attr_groups;
> >  	const struct attribute_group	**attr_update;
> >  	const char			*name;
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index fb3e436bcd4a..a84c282221f2 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -11367,6 +11367,7 @@ static int pmu_dev_alloc(struct pmu *pmu)
> >  
> >  	dev_set_drvdata(pmu->dev, pmu);
> >  	pmu->dev->bus = &pmu_bus;
> > +	pmu->dev->parent = pmu->parent;  
> 
> If there's no parent assigned, is it ok to add some check here? Then we can find it earlier
> maybe at develop stage.

In the long run I agree it would be good.  Short term there are more instances of
struct pmu that don't have parents than those that do (even after this series).
We need to figure out what to do about those before adding checks on it being
set.

Jonathan

> 
> Thanks.
> 
> >  	pmu->dev->release = pmu_dev_release;
> >  
> >  	ret = dev_set_name(pmu->dev, "%s", pmu->name);
> >   

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Peter Zijlstra]

On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:

> In the long run I agree it would be good.  Short term there are more instances of
> struct pmu that don't have parents than those that do (even after this series).
> We need to figure out what to do about those before adding checks on it being
> set.

Right, I don't think you've touched *any* of the x86 PMUs for example,
and getting everybody that boots an x86 kernel a warning isn't going to
go over well :-)

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Jonathan Cameron]

On Thu, 6 Apr 2023 14:40:40 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> 
> > In the long run I agree it would be good.  Short term there are more instances of
> > struct pmu that don't have parents than those that do (even after this series).
> > We need to figure out what to do about those before adding checks on it being
> > set.  
> 
> Right, I don't think you've touched *any* of the x86 PMUs for example,
> and getting everybody that boots an x86 kernel a warning isn't going to
> go over well :-)
> 

It was tempting :) "Warning: Parentless PMU: try a different architecture."

I'd love some inputs on what the x86 PMU devices parents should be?
CPU counters in general tend to just spin out of deep in the architecture code.

My overall favorite is an l2 cache related PMU that is spun up in
arch/arm/kernel/irq.c init_IRQ()

I'm just not going to try and figure out why...

Jonathan

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Greg KH]

On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote:
> On Thu, 6 Apr 2023 14:40:40 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> > 
> > > In the long run I agree it would be good.  Short term there are more instances of
> > > struct pmu that don't have parents than those that do (even after this series).
> > > We need to figure out what to do about those before adding checks on it being
> > > set.  
> > 
> > Right, I don't think you've touched *any* of the x86 PMUs for example,
> > and getting everybody that boots an x86 kernel a warning isn't going to
> > go over well :-)
> > 
> 
> It was tempting :) "Warning: Parentless PMU: try a different architecture."
> 
> I'd love some inputs on what the x86 PMU devices parents should be?
> CPU counters in general tend to just spin out of deep in the architecture code.
> 
> My overall favorite is an l2 cache related PMU that is spun up in
> arch/arm/kernel/irq.c init_IRQ()
> 
> I'm just not going to try and figure out why...

Why not change the api to force a parent to be passed in?  And if one
isn't, we make it a "virtual" device and throw it in the class for them?

thanks,

greg k-h

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Peter Zijlstra]

On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote:
> On Thu, 6 Apr 2023 14:40:40 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> > 
> > > In the long run I agree it would be good.  Short term there are more instances of
> > > struct pmu that don't have parents than those that do (even after this series).
> > > We need to figure out what to do about those before adding checks on it being
> > > set.  
> > 
> > Right, I don't think you've touched *any* of the x86 PMUs for example,
> > and getting everybody that boots an x86 kernel a warning isn't going to
> > go over well :-)
> > 
> 
> It was tempting :) "Warning: Parentless PMU: try a different architecture."

Haha!

> I'd love some inputs on what the x86 PMU devices parents should be?
> CPU counters in general tend to just spin out of deep in the architecture code.

For the 'simple' ones I suppose we can use the CPU device.

> My overall favorite is an l2 cache related PMU that is spun up in
> arch/arm/kernel/irq.c init_IRQ()

Yeah, we're going to have a ton of them as well. Some of them are PCI
devices and have a clear parent, others, not so much :/

Re: [PATCH 29/32] fpga: dfl: Assign parent for event_source device

[Xu Yilun]

On 2023-04-04 at 14:42:22 +0100, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the Platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Cc: Wu Hao <hao.wu@intel.com>
> Cc: Tom Rix <trix@redhat.com>
> Cc: linux-fpga@vger.kernel.org
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Reviewed-by: Xu Yilun <yilun.xu@intel.com>

> ---
>  drivers/fpga/dfl-fme-perf.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> index 7422d2bc6f37..2d59f1c620b1 100644
> --- a/drivers/fpga/dfl-fme-perf.c
> +++ b/drivers/fpga/dfl-fme-perf.c
> @@ -912,6 +912,7 @@ static int fme_perf_pmu_register(struct platform_device *pdev,
>  
>  	fme_perf_setup_hardware(priv);
>  
> +	pmu->parent =		&pdev->dev;
>  	pmu->task_ctx_nr =	perf_invalid_context;
>  	pmu->attr_groups =	fme_perf_groups;
>  	pmu->attr_update =	fme_perf_events_groups;
> -- 
> 2.37.2
> 

Re: [PATCH 07/32] perf/amlogic: Assign parents for event_source devices

[Jiucheng Xu]

On 2023/4/4 21:42, Jonathan Cameron wrote:
> [ EXTERNAL EMAIL ]
>
> Currently all these devices appear directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parents to be the platform device.
>
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Cc: Jiucheng Xu <jiucheng.xu@amlogic.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>   drivers/perf/amlogic/meson_ddr_pmu_core.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/perf/amlogic/meson_ddr_pmu_core.c b/drivers/perf/amlogic/meson_ddr_pmu_core.c
> index b84346dbac2c..e0d3e87457e0 100644
> --- a/drivers/perf/amlogic/meson_ddr_pmu_core.c
> +++ b/drivers/perf/amlogic/meson_ddr_pmu_core.c
> @@ -490,6 +490,7 @@ int meson_ddr_pmu_create(struct platform_device *pdev)
>   	*pmu = (struct ddr_pmu) {
>   		.pmu = {
>   			.module		= THIS_MODULE,
> +			.parent		= &pdev->dev,
Reviewed-by: Jiucheng Xu <jiucheng.xu@amlogic.com
>   			.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
>   			.task_ctx_nr	= perf_invalid_context,
>   			.attr_groups	= attr_groups,

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Jonathan Cameron]

On Thu, 6 Apr 2023 19:08:45 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote:
> > On Thu, 6 Apr 2023 14:40:40 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >   
> > > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> > >   
> > > > In the long run I agree it would be good.  Short term there are more instances of
> > > > struct pmu that don't have parents than those that do (even after this series).
> > > > We need to figure out what to do about those before adding checks on it being
> > > > set.    
> > > 
> > > Right, I don't think you've touched *any* of the x86 PMUs for example,
> > > and getting everybody that boots an x86 kernel a warning isn't going to
> > > go over well :-)
> > >   
> > 
> > It was tempting :) "Warning: Parentless PMU: try a different architecture."
> > 
> > I'd love some inputs on what the x86 PMU devices parents should be?
> > CPU counters in general tend to just spin out of deep in the architecture code.
> > 
> > My overall favorite is an l2 cache related PMU that is spun up in
> > arch/arm/kernel/irq.c init_IRQ()
> > 
> > I'm just not going to try and figure out why...  
> 
> Why not change the api to force a parent to be passed in?  And if one
> isn't, we make it a "virtual" device and throw it in the class for them?

Longer term I'd be fine doing that, but I'd like to identify the right parents
rather than end up sweeping it under the carpet.  Anything we either get completely
stuck on (or decide we don't care about) could indeed fall back to a virtual
device.

Jonathan


> 
> thanks,
> 
> greg k-h

Re: [PATCH 21/32] perf/arm-cmn: Assign parents for event_source device

[Robin Murphy]

On 2023-04-04 14:42, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.

Oh, fab! Just the other week I wrote up a patch doing this after the 
fact with device_move() on the grounds of making the PMU instances 
easier to identify (and with an equivalent cleanup of 
Documentation/admin-guide/perf), which I was close to getting round to 
sending as an RFC. Thus I thoroughly approve :D

Acked-by: Robin Murphy <robin.murphy@arm.com>

> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>   drivers/perf/arm-cmn.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> index c9689861be3f..7731eb0e2a4a 100644
> --- a/drivers/perf/arm-cmn.c
> +++ b/drivers/perf/arm-cmn.c
> @@ -2284,6 +2284,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
>   	cmn->cpu = cpumask_local_spread(0, dev_to_node(cmn->dev));
>   	cmn->pmu = (struct pmu) {
>   		.module = THIS_MODULE,
> +		.parent = &pdev->dev,
>   		.attr_groups = arm_cmn_attr_groups,
>   		.capabilities = PERF_PMU_CAP_NO_EXCLUDE,
>   		.task_ctx_nr = perf_invalid_context,

Re: [PATCH 25/32] perf/arm-spe: Assign parents for event_source device

[Suzuki K Poulose]

On 04/04/2023 14:42, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>   drivers/perf/arm_spe_pmu.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
> index b9ba4c4fe5a2..a98ef633fa00 100644
> --- a/drivers/perf/arm_spe_pmu.c
> +++ b/drivers/perf/arm_spe_pmu.c
> @@ -955,6 +955,7 @@ static int arm_spe_pmu_perf_init(struct arm_spe_pmu *spe_pmu)
>   
>   	spe_pmu->pmu = (struct pmu) {
>   		.module = THIS_MODULE,
> +		.parent		= &spe_pmu->pdev->dev,
>   		.capabilities	= PERF_PMU_CAP_EXCLUSIVE | PERF_PMU_CAP_ITRACE,
>   		.attr_groups	= arm_spe_pmu_attr_groups,
>   		/*

Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Re: [PATCH 20/32] perf/arm-ccn: Assign parents for event_source device

[Suzuki K Poulose]

On 04/04/2023 14:42, Jonathan Cameron wrote:
> Currently the PMU device appears directly under /sys/devices/
> Only root busses should appear there, so instead assign the pmu->dev
> parent to be the platform device.
> 
> Link: https://lore.kernel.org/linux-cxl/ZCLI9A40PJsyqAmq@kroah.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>   drivers/perf/arm-ccn.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/perf/arm-ccn.c b/drivers/perf/arm-ccn.c
> index 728d13d8e98a..dc8b0dcb436e 100644
> --- a/drivers/perf/arm-ccn.c
> +++ b/drivers/perf/arm-ccn.c
> @@ -1265,6 +1265,7 @@ static int arm_ccn_pmu_init(struct arm_ccn *ccn)
>   	/* Perf driver registration */
>   	ccn->dt.pmu = (struct pmu) {
>   		.module = THIS_MODULE,
> +		.parent = ccn->dev,
>   		.attr_groups = arm_ccn_pmu_attr_groups,
>   		.task_ctx_nr = perf_invalid_context,
>   		.event_init = arm_ccn_pmu_event_init,


Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Robin Murphy]

On 2023-04-06 17:44, Jonathan Cameron wrote:
> On Thu, 6 Apr 2023 14:40:40 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
>> On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
>>
>>> In the long run I agree it would be good.  Short term there are more instances of
>>> struct pmu that don't have parents than those that do (even after this series).
>>> We need to figure out what to do about those before adding checks on it being
>>> set.
>>
>> Right, I don't think you've touched *any* of the x86 PMUs for example,
>> and getting everybody that boots an x86 kernel a warning isn't going to
>> go over well :-)
>>
> 
> It was tempting :) "Warning: Parentless PMU: try a different architecture."
> 
> I'd love some inputs on what the x86 PMU devices parents should be?
> CPU counters in general tend to just spin out of deep in the architecture code.
> 
> My overall favorite is an l2 cache related PMU that is spun up in
> arch/arm/kernel/irq.c init_IRQ()
> 
> I'm just not going to try and figure out why...

I think that's simply because the PMU support was hung off the existing 
PL310 configuration code, which still supports non-DT boardfiles. The 
PMU shouldn't strictly need to be registered that early, it would just 
be a bunch more work to ensure that a platform device is available for 
it to bind to as a regular driver model driver, which wasn't justifiable 
at the time.

Thanks,
Robin.

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Mark Rutland]

On Thu, Apr 06, 2023 at 09:49:38PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote:
> > On Thu, 6 Apr 2023 14:40:40 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> > > 
> > > > In the long run I agree it would be good.  Short term there are more instances of
> > > > struct pmu that don't have parents than those that do (even after this series).
> > > > We need to figure out what to do about those before adding checks on it being
> > > > set.  
> > > 
> > > Right, I don't think you've touched *any* of the x86 PMUs for example,
> > > and getting everybody that boots an x86 kernel a warning isn't going to
> > > go over well :-)
> > > 
> > 
> > It was tempting :) "Warning: Parentless PMU: try a different architecture."
> 
> Haha!
> 
> > I'd love some inputs on what the x86 PMU devices parents should be?
> > CPU counters in general tend to just spin out of deep in the architecture code.
> 
> For the 'simple' ones I suppose we can use the CPU device.

Uh, *which* CPU device? Do we have a container device for all CPUs?

> > My overall favorite is an l2 cache related PMU that is spun up in
> > arch/arm/kernel/irq.c init_IRQ()

That's an artifact of the L2 cache controller driver getting initialized there;
ideally we'd have a device for the L2 cache itself (which presumably should
hang off an aggregate CPU device).

> Yeah, we're going to have a ton of them as well. Some of them are PCI
> devices and have a clear parent, others, not so much :/

In a number of places the only thing we have is the PMU driver, and we don't
have a driver (or device) for the HW block it's a part of. Largely that's
interconnect PMUs; we could create container devices there.

Mark.

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Peter Zijlstra]

On Tue, Jun 06, 2023 at 02:06:24PM +0100, Mark Rutland wrote:
> On Thu, Apr 06, 2023 at 09:49:38PM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote:
> > > On Thu, 6 Apr 2023 14:40:40 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> > > > 
> > > > > In the long run I agree it would be good.  Short term there are more instances of
> > > > > struct pmu that don't have parents than those that do (even after this series).
> > > > > We need to figure out what to do about those before adding checks on it being
> > > > > set.  
> > > > 
> > > > Right, I don't think you've touched *any* of the x86 PMUs for example,
> > > > and getting everybody that boots an x86 kernel a warning isn't going to
> > > > go over well :-)
> > > > 
> > > 
> > > It was tempting :) "Warning: Parentless PMU: try a different architecture."
> > 
> > Haha!
> > 
> > > I'd love some inputs on what the x86 PMU devices parents should be?
> > > CPU counters in general tend to just spin out of deep in the architecture code.
> > 
> > For the 'simple' ones I suppose we can use the CPU device.
> 
> Uh, *which* CPU device? Do we have a container device for all CPUs?

drivers/base/cpu.c:per_cpu(cpu_sys_devices, cpu) for whatever the core
pmu is for that cpu ?

> > > My overall favorite is an l2 cache related PMU that is spun up in
> > > arch/arm/kernel/irq.c init_IRQ()
> 
> That's an artifact of the L2 cache controller driver getting initialized there;
> ideally we'd have a device for the L2 cache itself (which presumably should
> hang off an aggregate CPU device).

/sys/devices/system/cpu/cpuN/cache/indexM

has a struct device somewhere in
drivers/base/cacheinfo.c:ci_index_dev or somesuch.

> > Yeah, we're going to have a ton of them as well. Some of them are PCI
> > devices and have a clear parent, others, not so much :/
> 
> In a number of places the only thing we have is the PMU driver, and we don't
> have a driver (or device) for the HW block it's a part of. Largely that's
> interconnect PMUs; we could create container devices there.

Dont they have a PCI device? But yeah, some are going to be a wee bit
challenging.

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Mark Rutland]

On Tue, Jun 06, 2023 at 03:18:59PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2023 at 02:06:24PM +0100, Mark Rutland wrote:
> > On Thu, Apr 06, 2023 at 09:49:38PM +0200, Peter Zijlstra wrote:
> > > On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote:
> > > > On Thu, 6 Apr 2023 14:40:40 +0200
> > > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > > 
> > > > > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> > > > > 
> > > > > > In the long run I agree it would be good.  Short term there are more instances of
> > > > > > struct pmu that don't have parents than those that do (even after this series).
> > > > > > We need to figure out what to do about those before adding checks on it being
> > > > > > set.  
> > > > > 
> > > > > Right, I don't think you've touched *any* of the x86 PMUs for example,
> > > > > and getting everybody that boots an x86 kernel a warning isn't going to
> > > > > go over well :-)
> > > > > 
> > > > 
> > > > It was tempting :) "Warning: Parentless PMU: try a different architecture."
> > > 
> > > Haha!
> > > 
> > > > I'd love some inputs on what the x86 PMU devices parents should be?
> > > > CPU counters in general tend to just spin out of deep in the architecture code.
> > > 
> > > For the 'simple' ones I suppose we can use the CPU device.
> > 
> > Uh, *which* CPU device? Do we have a container device for all CPUs?
> 
> drivers/base/cpu.c:per_cpu(cpu_sys_devices, cpu) for whatever the core
> pmu is for that cpu ?

... but the struct pmu covers several CPUs, so I don't have a single 'cpu', no?

If I have a system where cpu{0,1,2} are Cortex-A53 and cpu{3,4} are Cortex-A57,
I have two struct pmu instances, each associated with several CPUs. When I
probe each of those I determine a cpumask for each.

> > > > My overall favorite is an l2 cache related PMU that is spun up in
> > > > arch/arm/kernel/irq.c init_IRQ()
> > 
> > That's an artifact of the L2 cache controller driver getting initialized there;
> > ideally we'd have a device for the L2 cache itself (which presumably should
> > hang off an aggregate CPU device).
> 
> /sys/devices/system/cpu/cpuN/cache/indexM
> 
> has a struct device somewhere in
> drivers/base/cacheinfo.c:ci_index_dev or somesuch.

I guess, but I don't think the L2 cache controller (the PL310) is actually tied
to that today.

> > > Yeah, we're going to have a ton of them as well. Some of them are PCI
> > > devices and have a clear parent, others, not so much :/
> > 
> > In a number of places the only thing we have is the PMU driver, and we don't
> > have a driver (or device) for the HW block it's a part of. Largely that's
> > interconnect PMUs; we could create container devices there.
> 
> Dont they have a PCI device? But yeah, some are going to be a wee bit
> challenging.

The system might not even have PCI, so it's arguable that they should just hang
off an MMIO bus (which is effectively what the platofrm bus is).

Thanks,
Mark.

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Peter Zijlstra]

On Tue, Jun 06, 2023 at 02:30:52PM +0100, Mark Rutland wrote:

> > > Uh, *which* CPU device? Do we have a container device for all CPUs?
> > 
> > drivers/base/cpu.c:per_cpu(cpu_sys_devices, cpu) for whatever the core
> > pmu is for that cpu ?
> 
> ... but the struct pmu covers several CPUs, so I don't have a single 'cpu', no?
> 
> If I have a system where cpu{0,1,2} are Cortex-A53 and cpu{3,4} are Cortex-A57,
> I have two struct pmu instances, each associated with several CPUs. When I
> probe each of those I determine a cpumask for each.

Bah :/ Clearly I overlooked the disparity there.

> > > > > My overall favorite is an l2 cache related PMU that is spun up in
> > > > > arch/arm/kernel/irq.c init_IRQ()
> > > 
> > > That's an artifact of the L2 cache controller driver getting initialized there;
> > > ideally we'd have a device for the L2 cache itself (which presumably should
> > > hang off an aggregate CPU device).
> > 
> > /sys/devices/system/cpu/cpuN/cache/indexM
> > 
> > has a struct device somewhere in
> > drivers/base/cacheinfo.c:ci_index_dev or somesuch.
> 
> I guess, but I don't think the L2 cache controller (the PL310) is actually tied
> to that today.

All it would do is make fancy links in sysfs I think, who cares ;-)

> > > > Yeah, we're going to have a ton of them as well. Some of them are PCI
> > > > devices and have a clear parent, others, not so much :/
> > > 
> > > In a number of places the only thing we have is the PMU driver, and we don't
> > > have a driver (or device) for the HW block it's a part of. Largely that's
> > > interconnect PMUs; we could create container devices there.
> > 
> > Dont they have a PCI device? But yeah, some are going to be a wee bit
> > challenging.
> 
> The system might not even have PCI, so it's arguable that they should just hang
> off an MMIO bus (which is effectively what the platofrm bus is).

You and your dodgy platforms :-)

Re: [PATCH 01/32] perf: Allow a PMU to have a parent

[Robin Murphy]

On 2023-06-06 14:48, Peter Zijlstra wrote:
> On Tue, Jun 06, 2023 at 02:30:52PM +0100, Mark Rutland wrote:
> 
>>>> Uh, *which* CPU device? Do we have a container device for all CPUs?
>>>
>>> drivers/base/cpu.c:per_cpu(cpu_sys_devices, cpu) for whatever the core
>>> pmu is for that cpu ?
>>
>> ... but the struct pmu covers several CPUs, so I don't have a single 'cpu', no?
>>
>> If I have a system where cpu{0,1,2} are Cortex-A53 and cpu{3,4} are Cortex-A57,
>> I have two struct pmu instances, each associated with several CPUs. When I
>> probe each of those I determine a cpumask for each.
> 
> Bah :/ Clearly I overlooked the disparity there.
> 
>>>>>> My overall favorite is an l2 cache related PMU that is spun up in
>>>>>> arch/arm/kernel/irq.c init_IRQ()
>>>>
>>>> That's an artifact of the L2 cache controller driver getting initialized there;
>>>> ideally we'd have a device for the L2 cache itself (which presumably should
>>>> hang off an aggregate CPU device).
>>>
>>> /sys/devices/system/cpu/cpuN/cache/indexM
>>>
>>> has a struct device somewhere in
>>> drivers/base/cacheinfo.c:ci_index_dev or somesuch.
>>
>> I guess, but I don't think the L2 cache controller (the PL310) is actually tied
>> to that today.
> 
> All it would do is make fancy links in sysfs I think, who cares ;-)
> 
>>>>> Yeah, we're going to have a ton of them as well. Some of them are PCI
>>>>> devices and have a clear parent, others, not so much :/
>>>>
>>>> In a number of places the only thing we have is the PMU driver, and we don't
>>>> have a driver (or device) for the HW block it's a part of. Largely that's
>>>> interconnect PMUs; we could create container devices there.
>>>
>>> Dont they have a PCI device? But yeah, some are going to be a wee bit
>>> challenging.
>>
>> The system might not even have PCI, so it's arguable that they should just hang
>> off an MMIO bus (which is effectively what the platofrm bus is).
> 
> You and your dodgy platforms :-)

For system PMUs we'll pretty much always have a platform device 
corresponding to a DT/ACPI entry used to describe MMIO registers and/or 
interrupts. In many cases the PMU is going to be the only part of the 
underlying device that is meaningful to Linux anyway, so I don't see any 
issue with just hanging the PMU device off its corresponding platform 
device - it still gives the user a way to map a PMU instance back to 
some understandable system topology (i.e. ACPI/DT) to disambiguate, and 
that's the most important thing.

Thanks,
Robin.