On Tue, 28 Feb 2017, Sebastian Ott wrote: > On Mon, 27 Feb 2017, Bart Van Assche wrote: > > On Mon, 2017-02-27 at 21:17 +0100, Sebastian Ott wrote: > > > commit 99db94940 "IB/core: Remove ib_device.dma_device" > > > breaks infiniband on s390 (and I think also other archs that do something > > > like to_pci_dev(dev) in one of their dma_ops callbacks). > > > > > > With this commit you use the dma_ops of the device that called > > > ib_register_device but you call e.g. dma_map with ib_device->dev > > > as an argument. > > > > > > S390's (pci specific) dma_map uses to_pci_dev(dev) to look into the > > > pci device (and its arch specific data) and oopses. > > > > > > Calling dma_map with ib_device->dev.parent would work but then it > > > wouldn't make sense to copy dma_ops and mask from ib_device->dev.parent > > > to ib_device->dev.. > > > > How about something like the untested patch below? > > It works but it doesn't feel right (why should all pci devices have this > duplicated data). > > Frankly I don't get the usecase of infiniband (sometimes) using > device->dev.dma_ops instead of parent->dma_ops. Ok, some drivers in drivers/infiniband/sw/ set dma_ops to &dma_virt_ops . So instead of copying the dma_ops you could do if (!device->dev.dma_ops) /*or use some new flag for ib_register_device*/ device->dma_device = parent; else device->dma_device = &device->dev; Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
