lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <722266ba-1572-2c2b-87d6-dc4f8ec9a274@os.amperecomputing.com>
Date: Mon, 28 Oct 2024 20:27:27 -0700 (PDT)
From: Ilkka Koskinen <ilkka@...amperecomputing.com>
To: Will Deacon <will@...nel.org>
cc: Ilkka Koskinen <ilkka@...amperecomputing.com>, 
    Shuai Xue <xueshuai@...ux.alibaba.com>, 
    Jing Zhang <renyu.zj@...ux.alibaba.com>, 
    Mark Rutland <mark.rutland@....com>, linux-arm-kernel@...ts.infradead.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] perf/dwc_pcie: Load DesignWare PCIe PMU driver
 automatically on Ampere SoCs


On Mon, 28 Oct 2024, Will Deacon wrote:
> On Thu, Oct 24, 2024 at 03:19:17PM -0700, Ilkka Koskinen wrote:
>>
>> Hi Will,
>>
>> On Thu, 24 Oct 2024, Will Deacon wrote:
>>> On Tue, Oct 08, 2024 at 11:18:23PM +0000, Ilkka Koskinen wrote:
>>>> Load DesignWare PCIe PMU driver automatically if the system has a PCI
>>>> bridge by Ampere.
>>>>
>>>> Signed-off-by: Ilkka Koskinen <ilkka@...amperecomputing.com>
>>>> ---
>>>>  drivers/perf/dwc_pcie_pmu.c | 10 ++++++++++
>>>>  1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/drivers/perf/dwc_pcie_pmu.c b/drivers/perf/dwc_pcie_pmu.c
>>>> index 3581d916d851..d752168733cf 100644
>>>> --- a/drivers/perf/dwc_pcie_pmu.c
>>>> +++ b/drivers/perf/dwc_pcie_pmu.c
>>>> @@ -782,6 +782,16 @@ static void __exit dwc_pcie_pmu_exit(void)
>>>>  module_init(dwc_pcie_pmu_init);
>>>>  module_exit(dwc_pcie_pmu_exit);
>>>>
>>>> +static const struct pci_device_id dwc_pcie_pmu_table[] = {
>>>> +	{
>>>> +		PCI_DEVICE(PCI_VENDOR_ID_AMPERE, PCI_ANY_ID),
>>>> +		.class		= PCI_CLASS_BRIDGE_PCI_NORMAL,
>>>> +		.class_mask	= ~0,
>>>> +	},
>>>> +	{ }
>>>> +};
>>>> +MODULE_DEVICE_TABLE(pci, dwc_pcie_pmu_table);
>>>
>>> Hmm, won't this only work if the driver is modular? Should we be calling
>>> pci_register_driver() for the builtin case?
>>
>> That would be the normal case indeed. However, this driver is quite
>> different: dwc_pcie_pmu_init() goes through all the pci devices looking for
>> root ports with the pmu capabilities. Moreover, the probe function isn't
>> bound to any specific vendor/class/device IDs. This patch simply makes sure
>> the driver is loaded and the init function gets called, if the driver was
>> built as module and ran on Ampere system.
>
> Ok, but that seems like the wrong approach, no? We end up with a weird
> list of vendors who want the thing to probe on their SoCs and, by
> omission, everybody not on the list doesn't want that behaviour.

Ideally, dwc pmu driver would claim the supported root ports but I think 
the PCIe driver is doing that. How about if we simply drop the auto 
loading patch and let users to manually load the driver as they have been 
doing so far?

Cheers, Ilkka

>
> Will
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ