From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Shuai Xue <xueshuai@linux.alibaba.com>
Cc: Yicong Yang <yangyicong@huawei.com>, <chengyou@linux.alibaba.com>,
<kaishen@linux.alibaba.com>, <helgaas@kernel.org>,
<will@kernel.org>, <baolin.wang@linux.alibaba.com>,
<robin.murphy@arm.com>, <yangyicong@hisilicon.com>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-pci@vger.kernel.org>, <rdunlap@infradead.org>,
<mark.rutland@arm.com>, <zhuo.song@linux.alibaba.com>
Subject: Re: [PATCH v6 3/4] drivers/perf: add DesignWare PCIe PMU driver
Date: Fri, 28 Jul 2023 16:20:30 +0100 [thread overview]
Message-ID: <20230728162030.00005e60@Huawei.com> (raw)
In-Reply-To: <12958abe-4bdb-8532-bf67-8e772ed2a9dd@linux.alibaba.com>
...
> >>> +
> >>> +static int dwc_pcie_pmu_online_cpu(unsigned int cpu, struct hlist_node *cpuhp_node)
> >>> +{
> >>> + struct dwc_pcie_pmu *pcie_pmu;
> >>> + struct pci_dev *pdev;
> >>> + int node;
> >>> +
> >>> + pcie_pmu = hlist_entry_safe(cpuhp_node, struct dwc_pcie_pmu, cpuhp_node);
> >>> + pdev = pcie_pmu->pdev;
> >>> + node = dev_to_node(&pdev->dev);
> >>> +
> >>> + if (node != NUMA_NO_NODE && cpu_to_node(pcie_pmu->oncpu) != node &&
> >
> > Perhaps worth a comment on when you might see node == NUMA_NO_NODE?
> > Beyond NUMA being entirely disabled, I'd hope that never happens and for that you
> > might be able to use a compile time check.
> >
> > I wonder if this can be simplified by a flag that says if we are already in the
> > right node? Might be easier to follow than having similar dance in online and offline
> > to figure that out.
>
> Ok, I will add a comment for NUMA_NO_NODE. If no numa support, I think
> any CPU is fine to bind.
Agreed. I would add a comment on that being the intent.
>
> pcie_pmu->on_cpu may be a good choise to be used as a flag, right? pcie_pmu->on_cpu
> will be set as -1 when pcie_pmu is allocated and then check in
> dwc_pcie_pmu_online_cpu() first.
I think you still want to know whether it's in the right node - as maybe
there are no local CPUs available at startup.
>
> Then, the code will be:
>
> static int dwc_pcie_pmu_online_cpu(unsigned int cpu, struct hlist_node *cpuhp_node)
> {
> struct dwc_pcie_pmu *pcie_pmu;
> struct pci_dev *pdev;
> int node;
>
> pcie_pmu = hlist_entry_safe(cpuhp_node, struct dwc_pcie_pmu, cpuhp_node);
> /* If another CPU is already managing this PMU, simply return. */
> if (pcie_pmu->on_cpu != -1)
> return 0;
>
> pdev = pcie_pmu->pdev;
> node = dev_to_node(&pdev->dev);
>
> /* Select the first CPU if no numa support. */
> if (node == NUMA_NO_NODE)
> pcie_pmu->on_cpu = cpu;
> else if (cpu_to_node(pcie_pmu->on_cpu) != node &&
> cpu_to_node(cpu) == node)
> dwc_pcie_pmu_migrate(pcie_pmu, cpu);
>
> return 0;
> }
> >
> >>> +static int __init dwc_pcie_pmu_init(void)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
> >>> + "perf/dwc_pcie_pmu:online",
> >>> + dwc_pcie_pmu_online_cpu,
> >>> + dwc_pcie_pmu_offline_cpu);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + dwc_pcie_pmu_hp_state = ret;
> >>> +
> >>> + ret = platform_driver_register(&dwc_pcie_pmu_driver);
> >>> + if (ret) {
> >>> + cpuhp_remove_multi_state(dwc_pcie_pmu_hp_state);
> >>> + return ret;
> >>> + }
> >>> +
> >>> + dwc_pcie_pmu_dev = platform_device_register_simple(
> >>> + "dwc_pcie_pmu", PLATFORM_DEVID_NONE, NULL, 0);
> >>> + if (IS_ERR(dwc_pcie_pmu_dev)) {
> >>> + platform_driver_unregister(&dwc_pcie_pmu_driver);
> >>
> >> On failure we also need to remove cpuhp state as well.
> >
> > I'd suggest using gotos and a single error handling block. That
> > makes it both harder to forget things like this and easier to
> > compare that block with what happens in exit() - so slightly
> > easier to review!
>
> Given that we have a appropriate way to tear down the PMUs via devm_add_action_or_reset(),
> I am going to remove the redundant probe/remove framework via platform_driver_{un}register().
> for_each probe process in __dwc_pcie_pmu_probe() will be move into dwc_pcie_pmu_init().
> Is it a better way?
I think I'd prefer to see a standard driver creation / probe flow even if you could in theory
avoid it.
Jonathan
>
> Thank you very much for your valuable comments.
>
> Best Regards,
> Shuai
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-07-28 15:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 7:49 [PATCH v6 0/4] drivers/perf: add Synopsys DesignWare PCIe PMU driver support Shuai Xue
2023-06-06 7:49 ` [PATCH v6 1/4] docs: perf: Add description for Synopsys DesignWare PCIe PMU driver Shuai Xue
2023-07-27 8:57 ` Jonathan Cameron
2023-07-27 12:52 ` Shuai Xue
2023-07-28 10:18 ` Jonathan Cameron
2023-06-06 7:49 ` [PATCH v6 2/4] PCI: Add Alibaba Vendor ID to linux/pci_ids.h Shuai Xue
2023-06-06 15:31 ` Bjorn Helgaas
2023-06-07 0:42 ` Shuai Xue
2023-06-06 7:49 ` [PATCH v6 3/4] drivers/perf: add DesignWare PCIe PMU driver Shuai Xue
2023-06-06 15:14 ` Yicong Yang
2023-07-27 9:39 ` Jonathan Cameron
2023-07-28 12:41 ` Shuai Xue
2023-07-28 15:20 ` Jonathan Cameron [this message]
2023-08-01 11:46 ` Yicong Yang
2023-08-04 1:39 ` Shuai Xue
2023-08-04 2:28 ` Yicong Yang
2023-08-04 3:09 ` Shuai Xue
2023-10-09 13:08 ` Shuai Xue
2023-10-10 7:35 ` Yicong Yang
2023-10-10 7:45 ` Shuai Xue
2023-07-28 1:31 ` Shuai Xue
2023-06-06 7:49 ` [PATCH v6 4/4] MAINTAINERS: add maintainers for " Shuai Xue
2023-06-16 8:39 ` [PATCH v6 0/4] drivers/perf: add Synopsys DesignWare PCIe PMU driver support Shuai Xue
2023-07-10 12:04 ` Shuai Xue
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=20230728162030.00005e60@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=chengyou@linux.alibaba.com \
--cc=helgaas@kernel.org \
--cc=kaishen@linux.alibaba.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rdunlap@infradead.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=xueshuai@linux.alibaba.com \
--cc=yangyicong@hisilicon.com \
--cc=yangyicong@huawei.com \
--cc=zhuo.song@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;
as well as URLs for NNTP newsgroup(s).