From: Will Deacon <will@kernel.org>
To: yunhui cui <cuiyunhui@bytedance.com>
Cc: Shuai Xue <xueshuai@linux.alibaba.com>,
renyu.zj@linux.alibaba.com, mark.rutland@arm.com,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [PATCH] perf/dwc_pcie: fix duplicate pci_dev devices
Date: Mon, 27 Jan 2025 16:51:57 +0000 [thread overview]
Message-ID: <20250127165156.GE25757@willie-the-truck> (raw)
In-Reply-To: <CAEEQ3wnTMfWSZRhTax3N60W=m3a=zxnJF6dOfiGnqJzBQs8WEg@mail.gmail.com>
On Sun, Jan 26, 2025 at 09:54:35AM +0800, yunhui cui wrote:
> Hi Will,
>
> On Fri, Jan 24, 2025 at 8:30 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Fri, Jan 24, 2025 at 05:11:05PM +0800, yunhui cui wrote:
> > > > >>> vsec = dwc_pcie_des_cap(pdev);
> > > > >>> if (!vsec)
> > > > >>> return -ENODEV;
> > > > >>>
> > > > >>> sbdf = plat_dev->id;
> > > > >>> - name = devm_kasprintf(&plat_dev->dev, GFP_KERNEL, "dwc_rootport_%x", sbdf);
> > > > >>> + name = devm_kasprintf(&plat_dev->dev, GFP_KERNEL, "dwc_rootport_%d_pmu", sbdf);
> > > > >>
> > > > >> A new name will break previous user tools.
> > > > > This name isn't suitable. It can't clearly show which is the PMU
> > > > > device. Userspace tools don't have binding relationships, like perf.
> > > > > Tools must traverse PMU devices before use.
> > > >
> > > > The device is under /sys/bus/event_source/ which indates it is PMU device.
> > > > As far as I know, most of PMU devices do not endup with a '_pmu' prefix.
> > >
> > > The point is the name "dwc_rootport_" is misleading, suggesting an
> > > extra PCIE RP in the system. Best to change the name to intuitive
> > > "xx_pmu".
> >
> > As pointed out above, changing the name will break userspace. So it's
> > simply not an option, sorry.
>
> Could you specify what in the userspace is broken and give an example?
Can't I just take the documented example from dwc_pcie_pmu.rst:
$# perf stat -a -e dwc_rootport_13018/Rx_PCIe_TLP_Data_Payload/
If I have a script that uses that command on a machine today, then
applying your kernel patch will break the script, no?
Will
next prev parent reply other threads:[~2025-01-27 16:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 7:48 [PATCH] perf/dwc_pcie: fix duplicate pci_dev devices Yunhui Cui
2025-01-23 9:49 ` Shuai Xue
2025-01-24 2:56 ` [External] " yunhui cui
2025-01-24 6:48 ` Shuai Xue
2025-01-24 9:11 ` yunhui cui
2025-01-24 12:29 ` Will Deacon
2025-01-26 1:54 ` yunhui cui
2025-01-27 16:51 ` Will Deacon [this message]
2025-02-01 9:51 ` yunhui cui
2025-02-04 12:31 ` Will Deacon
2025-02-05 1:45 ` yunhui cui
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=20250127165156.GE25757@willie-the-truck \
--to=will@kernel.org \
--cc=cuiyunhui@bytedance.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=renyu.zj@linux.alibaba.com \
--cc=xueshuai@linux.alibaba.com \
/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