Hi Alex On Fri, May 2, 2014 at 12:27 AM, Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > The existing quirk for these devices doesn't really solve the problem, > re-implement it using the DMA alias iterator. We'll come back later > and remove the existing quirk and dma_source interface. > > Signed-off-by: Alex Williamson <alex.williamson@xxxxxxxxxx> > --- > drivers/pci/quirks.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index e729206..a458c6b 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3333,6 +3333,22 @@ int pci_dev_specific_reset(struct pci_dev *dev, int probe) > return -ENOTTY; > } > > +static void quirk_dma_func0_alias(struct pci_dev *dev) > +{ > + if (PCI_SLOT(dev->devfn) != 0) > + dev->dma_func_alias |= (1 << 0); > +} > + > +/* > + * https://bugzilla.redhat.com/show_bug.cgi?id=605888 > + * > + * Some Ricoh devices use function 0 as the PCIe requester ID for DMA. > + */ > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe822, quirk_dma_func0_alias); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe230, quirk_dma_func0_alias); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias); 0xe832 is listed twice. Previously only 0xe832 needed the dma alias on my thinkpad T410, which has all three devices. > + > static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev) > { > if (!PCI_FUNC(dev->devfn)) > Unfortunately, this quirk doesn't work for me. I tried it without modification, as well as with each alias individually. I get: Set context mapping for 0d:00.3 firewire_ohci 0000:0d:00.3: added OHCI v1.10 device as card 0, 4 IR + 4 IT contexts, quirks 0x11 dmar: DRHD: handling fault status reg 2 dmar: DMAR:[DMA Read] Request device [0d:00.0] fault addr fffff000 DMAR:[fault reason 02] Present bit in context entry is clear I think I need to see Set context mapping for 0d:00.0 before Set context mapping for 0d:00.3 in the log, but it's not there. I'd love to look into this and understand it properly, but I don't have time for the next four weeks. The devices are attached as follows: BDF, device ID 0d:00.0, e822 0d:00.1, e230 0d:00.3, e832 The kernel log is attached. Regards, a.