lkml.org 
[lkml]   [2020]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/6] device/pci: add cmdmem cap to pci_dev
From
Date

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@intel.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.
> 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

\
 
 \ /
  Last update: 2020-03-31 19:39    [W:0.051 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site