Jeff Garzik wrote: > Tejun Heo wrote: >> Jeff Garzik wrote: >>> Tejun Heo wrote: >>>> Implement and use DMA mask configuration helper. >>>> >>>> Signed-off-by: Tejun Heo <htejun@xxxxxxxxx> >>>> --- >>>> This function probably belongs to pci layer. Put it in libata with >>>> pci_test_bits() for the time being. >>> AFAIK the default DMA mask is always 32-bit. Code (often written by me) >>> that sets it to a 32-bit mask was just paranoia, and not really needed. >>> >>> Hence, the pci_go_64() function I added, found in #upstream. >> >> It isn't in #upstream yet. Also, at the second thought, there is a >> problem with pci_go_64(). DMA masks are not reset after driver is >> detached. Even if the device starts with 32bit DMA masks, after a 64bit >> enabled driver is attached and detached, the device's DMA masks are >> 64bit. I'm refreshing new-init-model patchset and keeping >> pci_configure_dma_masks() for now. > > That "problem" has existed since day one, and nobody seems to care :) > > I can't think of a single 64-bit-capable driver that restores the masks, > and can't think of a single bug report that resulted from it. Jeff, there are further problems with doing pci_go_64() only on devices which support 64bit. pci_set_dma_mask() is the only place where the PCI code can test whether DMA is usable or not, so if we don't configure DMA mask on 32bit controllers, there's no way to tell whether DMA is allowed on the controller/bus or not. We end up blindly enabling bus mastering without consulting the PCI bus. I think it's just cleaner to do pci_configure_dma_masks() on all cases with proper DMA mask. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
