Re: [PATCH 3/6] pci: add PCI quirk cmdmem fixup for Intel DSA device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 01, 2020 at 07:20:59PM -0700, Dan Williams wrote:
> On Wed, Apr 1, 2020 at 12:19 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> >
> > On Mon, Mar 30, 2020 at 02:27:06PM -0700, Dave Jiang wrote:
> > > Since there is no standard way that defines a PCI device that receives
> > > descriptors or commands with synchronous write operations, add quirk to set
> > > cmdmem for the Intel accelerator device that supports it.
> >
> > Why do we need a quirk for this?  Even assuming a flag is needed in
> > struct pci_dev (and I don't really understand why that is needed to
> > start with), it could be set in ->probe.
> 
> The consideration in my mind is whether this new memory type and
> instruction combination warrants a new __attribute__((noderef,
> address_space(X))) separate from __iomem. If it stays a single device
> concept layered on __iomem then yes, I agree it can all live locally
> in the driver. However, when / if this facility becomes wider spread,
> as the PCI ECR in question is trending, it might warrant general
> annotation.
> 
> The enqcmds instruction does not operate on typical x86 mmio
> addresses, only these special device portals offer the ability to have
> non-posted writes with immediate results in the cpu condition code
> flags.

But that is not what this series does at all.  And I think it makes
sense to wait until it gains adoption to think about a different address
space.  In this series we could just trivially kill patches 2-4 and make
it much easier to understand.



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux