On Tue, Mar 31, 2020 at 10:07:07AM -0700, Dave Jiang wrote:
On 3/31/2020 3:04 AM, Greg KH wrote:Please do not. Also, that's not what you are doing here from what I can
On Mon, Mar 30, 2020 at 02:27:00PM -0700, Dave Jiang wrote:The original thought was to introduce a new arch level memory mapping
Since the current accelerator devices do not have standard PCIe capabilityWhy would a pci-specific function like this be ok to have in the driver
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);
core? Please keep it in the pci core code instead.
semantic.
tell.
If you feel this should be PCI exclusive, should we make the ioremapWhy wouldn't it be? Is this needed anywhere else?
routines for this memory type pci specific as well?
thanks,
greg k-h