On Fri, Apr 14, 2017 at 11:30:14AM -0600, Logan Gunthorpe wrote: > On 14/04/17 05:37 AM, Benjamin Herrenschmidt wrote: > > I object to designing a subsystem that by design cannot work on whole > > categories of architectures out there. > > Hardly. That's extreme. We'd design a subsystem that works for the easy > cases and needs more work to support the offset cases. It would not be > designed in such a way that it could _never_ support those > architectures. It would simply be such that it only permits use by the > cases that are known to work. Then those cases could be expanded as time > goes on and people work on adding more support. I'm a little hesitant about excluding offset support, so I'd like to hear more about this. Is the issue related to PCI BARs that are not completely addressable by the CPU? If so, that sounds like a first-class issue that should be resolved up front because I don't think the PCI core in general would deal well with that. If all the PCI memory of interest is in fact addressable by the CPU, I would think it would be pretty straightforward to support offsets -- everywhere you currently use a PCI bus address, you just use the corresponding CPU physical address instead. > There's tons of stuff that needs to be done to get this upstream. I'd > rather not require it to work for every possible architecture from the > start. The testing alone would be impossible. Many subsystems start by > working for x86 first and then adding support in other architectures > later. (Often with that work done by the people who care about those > systems and actually have the hardware to test with.) I don't think exhaustive testing is that big a deal. PCI offset support is generic, so you shouldn't need any arch-specific code to deal with it. I'd rather have consistent support across the board, even though some arches might not be tested. I think that's simpler and better than adding checks to disable functionality on some arches merely on the grounds that it hasn't been tested there. Bjorn
