[PATCH v9 0/4] arm64: arch_timer: Add workaround for hisilicon-161010101 erratum

[Daniel Lezcano]

On Mon, Jan 30, 2017 at 03:52:09PM +0000, Mark Rutland wrote:
> 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.

Ok, thanks for these clarifications.

> 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.

It is up to me to ensure the clockevent/clocksource drivers in general are
following the right direction. And this driver looks more and more opaque. I
will spend some times to do a review of the driver as soon as I have time.

So we finish the reviews of this series, you take the patches when I ack them up,
but from this point, any submission for this driver will have to stick to the
standard submission rules, that is to say: Thomas Gleixner and I have to be
recipients of the patches and go through our tree. Dependency issues with
other patchset must be solved before applying them in another tree.

Thanks.

  -- Daniel

-- 

 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog