On 3/31/2020 10:24 AM, Greg KH wrote:
On Tue, Mar 31, 2020 at 10:07:07AM -0700, Dave Jiang wrote:
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@xxxxxxxxx>
---
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.
Please do not. Also, that's not what you are doing here from what I can
tell.
If you feel this should be PCI exclusive, should we make the ioremap
routines for this memory type pci specific as well?
Why wouldn't it be? Is this needed anywhere else?
Ok I'll make this pci specific.
thanks,
greg k-h
