On Wed, Mar 13, 2013 at 09:18:15AM +0100, Thierry Reding wrote: > Mitch already answered this. The specification is now almost 15 years > old and it couldn't possibly have foreseen all of the future use-cases. > If the specification is too restrictive and Mitch gives his blessing to > remove some of the restrictions, I don't see any reason why we shouldn't > do so if it lets us represent the reality of hardware more accurately in > DT. I understand the spec is old, and I have no problem with making a Linux specific revision, but do *that* - don't bury some random deviation inside the bindings for a driver. I even suggested some language, but I feel more thought is needed to consider how to model the standardized ECAM mechanism.. > Furthermore we're not discussing radical changes. None of the changes > will be backwards-incompatible, but they will allow recent hardware to > be represented more correctly or conveniently. Sure, but it is still inconsistent, one MMIO config mechansim is in ranges, one is in regs. Plus I don't think tegra's case is a great starting point to design a spec update, it's config access mechanism is especially strange... Anyhow, I think this has been hashed to death, as long as your final binding has the 'device_type = pci' on the pcie-controller node I think it will be fine. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
