mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shuai Xue <xueshuai@linux.alibaba.com>
To: Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>,
	Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Yicong Yang <yangyicong@huawei.com>
Cc: chengyou@linux.alibaba.com, kaishen@linux.alibaba.com,
	baolin.wang@linux.alibaba.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, renyu.zj@linux.alibaba.com
Subject: Re: [PATCH v9 3/4] drivers/perf: add DesignWare PCIe PMU driver
Date: Mon, 30 Oct 2023 11:53:01 +0800	[thread overview]
Message-ID: <889576c1-4761-4329-9f3b-63a2930c391d@linux.alibaba.com> (raw)
In-Reply-To: <6790b6ea-4874-4a8c-a8fd-d9ab6caaf1d4@arm.com>



On 2023/10/27 02:06, Robin Murphy wrote:
...
>>>>      return ret;
>>>>
>>> [...]
>>>>> +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)
>>>>> +        goto platform_driver_register_err;
>>>>> +
>>>>> +    dwc_pcie_pmu_dev = platform_device_register_simple(
>>>>> +                "dwc_pcie_pmu", PLATFORM_DEVID_NONE, NULL, 0);
>>>>> +    if (IS_ERR(dwc_pcie_pmu_dev)) {
>>>>> +        ret = PTR_ERR(dwc_pcie_pmu_dev);
>>>>> +        goto platform_device_register_error;
>>>>> +    }
>>>>
>>>> I'm a bit confused as to why you're having to create a platform device
>>>> for a PCI device -- is this because the main designware driver has already
>>>> bound to it? A comment here explaining why you need to do this would be
>>>> very helpful. In particular, is there any dependency on another driver
>>>> to make sure that e.g. config space accesses work properly? If so, we
>>>> probably need to enforce module load ordering or something like that.
>>>
>>> AFAICS the platform device/driver serve no purpose other than being a hilariously roundabout way to run the for_each_pci_dev() loop in dwc_pcie_pmu_probe() upon module init, and to save explicitly freeing the PMU name/data. Furthermore the devres action for dwc_pcie_pmu_remove_cpuhp_instance() is apparently going for even more style points at module exit by not even relying on the corresponding .remove callback of the tenuous platform driver to undo what its .probe did, but (ab)using the device's devres list to avoid having to keep track of an explicit list of PMU instances at all.
>>
>> You are right.
>>
>>>
>>> Frankly I think it would be a lot more straightforward to just maintain that explicit list of PMU instances, do the PMU creation directly in dwc_pcie_pmu_init(), then unregister and free them in dwc_pcie_pmu_exit(). Not every driver has to contain a literal struct device_driver.
>>
>> Agreed, it might be more straightforward. But personally speaking, I prefer
>> current implementation.
>>
>>      - standard driver creation / probe flow is more normal
> 
> It's really not, though. We have a weird singleton platform device appearing out of nowhere which effectively represents the module being loaded, rather than anything about the actual underlying hardware. If you want this to look like "normal" driver model usage, then create a separate platform device for each physical PCI PMU instance you discover (potentially via both a one-time scan at module_init and an ADD_DEVICE hotplug notifier later), then have the platform driver just register the corresponding PMU device in .probe and unregister it in .remove, without confusing devres action tricks.
> 

Got it. If IIUC, I should register a platform device for each matched pci
device in module_init() or when BUS_NOTIFY_ADD_DEVICE event triggered, and
unwind it in module exit() and when BUS_NOTIFY_DEL_DEVICE event triggered.

Thank you for valuable comments.

Best Regards,
Shuai

  reply	other threads:[~2023-10-30  3:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 13:42 [PATCH v9 0/4] drivers/perf: add Synopsys DesignWare PCIe PMU driver support Shuai Xue
2023-10-20 13:42 ` [PATCH v9 1/4] docs: perf: Add description for Synopsys DesignWare PCIe PMU driver Shuai Xue
2023-10-20 13:42 ` [PATCH v9 2/4] PCI: Add Alibaba Vendor ID to linux/pci_ids.h Shuai Xue
2023-10-20 13:42 ` [PATCH v9 3/4] drivers/perf: add DesignWare PCIe PMU driver Shuai Xue
2023-10-20 16:49   ` Jonathan Cameron
2023-10-22  7:27     ` Shuai Xue
2023-10-22  7:47   ` Shuai Xue
2023-10-23  2:05     ` Baolin Wang
2023-10-23  9:39       ` Shuai Xue
2023-10-23  9:13   ` Yicong Yang
2023-10-23 12:26     ` Shuai Xue
2023-10-23 12:32   ` Will Deacon
2023-10-23 18:51     ` Robin Murphy
2023-10-24  9:29       ` Shuai Xue
2023-10-26 13:44         ` Jonathan Cameron
2023-10-26 16:52           ` Robin Murphy
2023-10-27 12:25             ` Shuai Xue
2023-10-30 19:22               ` Jonathan Cameron
2023-10-26 18:06         ` Robin Murphy
2023-10-30  3:53           ` Shuai Xue [this message]
2023-10-24  8:27     ` Shuai Xue
2023-10-30  4:54       ` Shuai Xue
2023-10-30  6:28   ` Krishna Chaitanya Chundru
2023-10-30 10:29     ` Shuai Xue
2023-10-20 13:42 ` [PATCH v9 4/4] MAINTAINERS: add maintainers for " 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=889576c1-4761-4329-9f3b-63a2930c391d@linux.alibaba.com \
    --to=xueshuai@linux.alibaba.com \
    --cc=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=renyu.zj@linux.alibaba.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --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

all inboxes | Powered by JetHome®