From: Greg KH <gregkh@linuxfoundation.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Liang, Kan" <kan.liang@linux.intel.com>,
linux-cxl@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com, acme@kernel.org, mark.rutland@arm.com,
will@kernel.org, dan.j.williams@intel.com, linuxarm@huawei.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Davidlohr Bueso <dave@stgolabs.net>,
Dave Jiang <dave.jiang@intel.com>
Subject: Re: [PATCH v2 2/5] perf: Allow a PMU to have a parent.
Date: Tue, 28 Mar 2023 13:01:08 +0200 [thread overview]
Message-ID: <ZCLI9A40PJsyqAmq@kroah.com> (raw)
In-Reply-To: <20230328115444.000036ea@Huawei.com>
On Tue, Mar 28, 2023 at 11:54:44AM +0100, Jonathan Cameron wrote:
> On Mon, 27 Mar 2023 13:04:08 -0400
> "Liang, Kan" <kan.liang@linux.intel.com> wrote:
>
> > On 2023-03-24 1:13 p.m., 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.
> >
> > Why we want a PMU parent? Maybe I missed it. I don't see that the parent
> > is used anywhere.
>
> This allows you to identify the association between PMU and the hardware related
> device that is providing it by looking at the directory structure in sysfs rather
> than putting them directly under /sys/devices.
>
> ls -l /sys/bus/event_sources/devices/
>
> ... armv8_pmuv3_0 -> ../../../devices/arm8_pmuv3_0
> ... breakpoint -> ../../../devices/breakpoint
> ... cpmu0 -> ../../../devices/pci0000:0c/0000:0c:00.0/0000:0d:00.0/cpmu0/cpmu0
> etc
>
> (the first cpmu0 is the parent registered as a child of the PCI EP and used for
> driver binding). So it's of use to userspace rather than in the kernel driver
> itself.
>
> Note that almost nothing is normally in the top level /sys/devices other than
> event_sources - because nearly all other struct device instances created by
> subsystems have parents assigned.
>
> On my system
>
> ls /sys/devices
>
> armv8_pmuv3_0 LNXSYSTEM:00 pci0000:0c pnp0 system uprobe
> breakpoint pci0000:00 platform software tracepoint virtual
>
> +CC Greg KH for input on whether / why this make sense.
That doesn't make sense, nothing should be in /sys/devices/ EXCEPT the
root device of busses. Everything else is wrong and should have their
code fixed up (i.e. "breakpoint", "software", etc.)
thanks,
greg k-h
next prev parent reply other threads:[~2023-03-28 11:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 17:13 [PATCH v2 0/5] CXL 3.0 Performance Monitoring Unit support Jonathan Cameron
2023-03-24 17:13 ` [PATCH v2 1/5] cxl: Add function to count regblocks of a given type Jonathan Cameron
2023-03-24 17:13 ` [PATCH v2 2/5] perf: Allow a PMU to have a parent Jonathan Cameron
2023-03-27 17:04 ` Liang, Kan
2023-03-28 10:54 ` Jonathan Cameron
2023-03-28 11:01 ` Greg KH [this message]
2023-03-29 8:55 ` Jonathan Cameron
2023-03-29 9:03 ` Greg KH
2023-03-24 17:13 ` [PATCH v2 3/5] cxl/pci: Find and register CXL PMU devices Jonathan Cameron
2023-03-24 21:01 ` kernel test robot
2023-03-27 15:50 ` Jonathan Cameron
2023-03-24 17:13 ` [PATCH v2 4/5] cxl: CXL Performance Monitoring Unit driver Jonathan Cameron
2023-03-24 21:12 ` kernel test robot
2023-03-27 15:50 ` Jonathan Cameron
2023-03-24 21:42 ` kernel test robot
2023-03-24 22:03 ` kernel test robot
2023-03-24 22:03 ` kernel test robot
2023-03-27 17:07 ` Liang, Kan
2023-03-29 13:11 ` Jonathan Cameron
2023-03-24 17:13 ` [PATCH v2 5/5] docs: perf: Minimal introduction the the CXL PMU device and driver Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZCLI9A40PJsyqAmq@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=acme@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=kan.liang@linux.intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox