linux-kernel - Re: [PATCH 2/6] device/pci: add cmdmem cap to pci

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: <00d8e780-105e-f552-daf0-9854f2e99a91@intel.com>
Date:   Tue, 31 Mar 2020 10:07:07 -0700
From:   Dave Jiang <dave.jiang@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     vkoul@...nel.org, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, hpa@...or.com, bhelgaas@...gle.com, arnd@...db.de,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        dmaengine@...r.kernel.org, dan.j.williams@...el.com,
        ashok.raj@...el.com, fenghua.yu@...el.com,
        linux-pci@...r.kernel.org, tony.luck@...el.com, jing.lin@...el.com,
        sanjay.k.kumar@...el.com
Subject: Re: [PATCH 2/6] device/pci: add cmdmem cap to pci_dev


On 3/31/2020 3:04 AM, Greg KH wrote:
> On Mon, Mar 30, 2020 at 02:27:00PM -0700, Dave Jiang wrote:
>> Since the current accelerator devices do not have standard PCIe capability
>> enumeration for accepting ENQCMDS yet, for now an attribute of pdev->cmdmem has
>> been added to struct pci_dev.  Currently a PCI quirk must be used for the
>> devices that have such cap until the PCI cap is standardized. Add a helper
>> function to provide the check if a device supports the cmdmem capability.
>>
>> Such capability is expected to be added to PCIe device cap enumeration in
>> the future.
>>
>> Signed-off-by: Dave Jiang <dave.jiang@...el.com>
>> ---
>>   drivers/base/core.c    |   13 +++++++++++++
>>   include/linux/device.h |    2 ++
>>   include/linux/pci.h    |    1 +
>>   3 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index dbb0f9130f42..cd9f5b040ed4 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -27,6 +27,7 @@
>>   #include <linux/netdevice.h>
>>   #include <linux/sched/signal.h>
>>   #include <linux/sysfs.h>
>> +#include <linux/pci.h>
>>   
>>   #include "base.h"
>>   #include "power/power.h"
>> @@ -3790,3 +3791,15 @@ int device_match_any(struct device *dev, const void *unused)
>>   	return 1;
>>   }
>>   EXPORT_SYMBOL_GPL(device_match_any);
>> +
>> +bool device_supports_cmdmem(struct device *dev)
>> +{
>> +	struct pci_dev *pdev;
>> +
>> +	if (!dev_is_pci(dev))
>> +		return false;
>> +
>> +	pdev = to_pci_dev(dev);
>> +	return pdev->cmdmem;
>> +}
>> +EXPORT_SYMBOL_GPL(device_supports_cmdmem);
> Why would a pci-specific function like this be ok to have in the driver
> core?  Please keep it in the pci core code instead.

The original thought was to introduce a new arch level memory mapping 
semantic. If you feel this should be PCI exclusive, should we make the 
ioremap routines for this memory type pci specific as well?


>
> thanks,
>
> greg k-h