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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.