On 08/09/2012 04:19 PM, Alexander Graf wrote: > > On 09.08.2012, at 23:11, Scott Wood wrote: > >> On 08/09/2012 04:01 PM, Alexander Graf wrote: >>> >>> On 09.08.2012, at 22:58, Scott Wood wrote: >>>> Additionally, we should consider adding extra compatibles with the major >>>> QEMU version in them, so that QEMU-aware target code can work around >>>> QEMU limitations even if it's been fixed in a more recent QEMU. >>>> >>>> I think this is what you were getting at in the e500 platform >>>> discussion, when you pointed at the PC versioning, but it's not about >>>> documenting semantics so much as identifying the actual implementation. >>> >>> Yes, -M e500-1.2 should expose chrp,open-pic while -M e500 should expose >>> fsl,mpic. >> >> We could do that too if the chrp,open-pic version actually makes it into >> a release before we fix fsl,mpic (I don't know what the release schedule > > We are past soft freeze, hard feature freeze is coming up next week. > >> is), but what I meant was that the device tree should have something like >> compatible = "qemu,1.2-chrp-openpic", "chrp,open-pic" >> or >> compatible = "qemu,1.3-fsl-mpic", "fsl,mpic" >> >> ...so that we can run new kernels on old QEMUs, not just the other way >> around. > > Why would we bother?
Why not? It's much easier than the other way around -- it's just an extra string in the device tree. It's up to someone who cares to put relevant workarounds in the kernel. Compare it to real hardware, where we expect new kernels to run on old hardware but not the other way around, and where we expect to be able to identify the specific hardware we're running on (there are version registers in the MPIC for identifying real hardware version, but not QEMU implementation version). If we had this, we could have avoided needing to postpone fsl,mpic, because I think the Linux patch using large vectors hasn't been released yet, so we could have added a check for qemu,1.2-fsl-mpic and known that it didn't include large vectors. I guess it's still not too late... It would also be useful for overriding SVR checks in drivers (for errata and such), which can get particularly awkward if you mix some emulated devices with some directly assigned devices (no one SVR will be right for all of them, even if all the emulated devices faithfully emulate one SoC's behavior). -Scott
