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
>
>
WARNING: multiple messages have this Message-ID (diff)
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:20 UTC|newest]
Thread overview: 58+ 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 ` Shuai Xue
2023-06-06 7:49 ` [PATCH v6 1/4] docs: perf: Add description for Synopsys DesignWare PCIe PMU driver Shuai Xue
2023-06-06 7:49 ` Shuai Xue
2023-07-27 8:57 ` Jonathan Cameron
2023-07-27 8:57 ` Jonathan Cameron
2023-07-27 12:52 ` Shuai Xue
2023-07-27 12:52 ` Shuai Xue
2023-07-28 10:18 ` Jonathan Cameron
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 7:49 ` Shuai Xue
2023-06-06 15:31 ` Bjorn Helgaas
2023-06-06 15:31 ` Bjorn Helgaas
2023-06-07 0:42 ` Shuai Xue
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 7:49 ` Shuai Xue
2023-06-06 15:14 ` Yicong Yang
2023-06-06 15:14 ` Yicong Yang
2023-07-27 9:39 ` Jonathan Cameron
2023-07-27 9:39 ` Jonathan Cameron
2023-07-28 12:41 ` Shuai Xue
2023-07-28 12:41 ` Shuai Xue
2023-07-28 15:20 ` Jonathan Cameron [this message]
2023-07-28 15:20 ` Jonathan Cameron
2023-08-01 11:46 ` Yicong Yang
2023-08-01 11:46 ` Yicong Yang
2023-08-04 1:39 ` Shuai Xue
2023-08-04 1:39 ` Shuai Xue
2023-08-04 2:28 ` Yicong Yang
2023-08-04 2:28 ` Yicong Yang
2023-08-04 3:09 ` Shuai Xue
2023-08-04 3:09 ` Shuai Xue
2023-10-09 13:08 ` Shuai Xue
2023-10-09 13:08 ` Shuai Xue
2023-10-10 7:35 ` Yicong Yang
2023-10-10 7:35 ` Yicong Yang
2023-10-10 7:45 ` Shuai Xue
2023-10-10 7:45 ` Shuai Xue
2023-07-28 1:31 ` 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-06 7:49 ` Shuai Xue
2023-06-16 8:39 ` [PATCH v6 0/4] drivers/perf: add Synopsys DesignWare PCIe PMU driver support Shuai Xue
2023-06-16 8:39 ` Shuai Xue
2023-07-10 12:04 ` Shuai Xue
2023-07-10 12:04 ` Shuai Xue
2023-07-24 2:34 ` Shuai Xue
2023-07-24 9:18 ` Jonathan Cameron
2023-07-24 12:13 ` Shuai Xue
2023-07-25 20:59 ` Bjorn Helgaas
2023-07-27 3:45 ` Shuai Xue
2023-07-27 3:45 ` Shuai Xue
2023-07-28 13:39 ` Will Deacon
2023-07-28 13:39 ` Will Deacon
2023-07-31 7:30 ` Shuai Xue
2023-07-31 7:30 ` 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 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.