Hi Daniel, On Tue, Jan 24, 2017 at 05:35:51PM +0100, Daniel Lezcano wrote: > That wasn't my point. The way the errata are handled in this patchset is > elegant and I have nothing against it. I'm worried about the accumulation of > fixes, hacks, workarounds in this driver. So my naive question is about not > using an identified bogus clocksource and use another one available on the > board, which is I believe often the case, instead of trying to deal with bogus > hardware. Apparently, that is not possible because 1) of KVM, 2) of duplication > and 3) of integration with the ARM64 code. > > Does it mean it is not possible to use another clocksource/clockevent than the > armv8-timer ? > > Can you elaborate these three points ? Practically speaking, these platforms have no other clocksource or clockevent device that I am aware of, which can be enumerated in a standard manner using ACPI. For point 1, KVM is intimately familiar with the architected timer (which is managed during VM context switch in hyp code, for example). KVM knows nothing of other clocksource or clockevent devices, and it is far from trivial to plumb these in either way. Since the architected timer is a mandatory part of ARMv8, guests may attempt to use it regardless. For point 3, arm64 currently requires the architected timer as this is mandatory per the ARMv8 architecture. It is non-trivial to add support for other devices to the vDSO, the delay loop, etc. Localising these quirks to the architected timer driver is by far the least worst option available. Marc and I are perfectly happy to manage that. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
