On Thu, Jan 24, 2019 at 5:39 PM Daniel Lezcano
<daniel.lezc...@linaro.org> wrote:
>
> On 24/01/2019 09:56, Chen-Yu Tsai wrote:
> > On Thu, Jan 10, 2019 at 5:19 PM Daniel Lezcano
> > <daniel.lezc...@linaro.org> wrote:
> >>
> >> On 10/01/2019 07:22, Chen-Yu Tsai wrote:
> >>> If the clock tree is not fully populated when the timer-sun5i init code
> >>> is called, attempts to get the clock rate for the timer would fail and
> >>> return 0.
> >>>
> >>> Make the init code for both clock events and clocksource check the
> >>> returned clock rate and fail gracefully if the result is 0, instead of
> >>> causing a divide by 0 exception later on.
> >>>
> >>> Fixes: 4a59058f0b09 ("clocksource/drivers/sun5i: Refactor the current
> >>> code")
> >>> Signed-off-by: Chen-Yu Tsai <w...@csie.org>
> >>> ---
> >>
> >> Applied thanks.
> >
> > I'm not seeing this in linux-next, nor the patch
> >
> > arm64: arch_timer: Workaround for Allwinner A64 timer instability
> >
> > Any idea where these ended up?
>
> Yeah, I have a rough idea. They are now in linux-next via the
> clockevents/next branch.
Thanks, Daniel.
Stephen,
Looks like linux-next is not picking up the latest clockevents/next.
The merge log for linux-next-20190124 shows:
Merging clockevents/clockevents/next (bd2bcaa565a2 Merge branch
'clockevents/4.21' of
http://git.linaro.org/people/daniel.lezcano/linux into timers/core)
$ git merge clockevents/clockevents/next
The merged clockevents/next looks outdated compared to
http://git.linaro.org/people/daniel.lezcano/linux.git/log/?h=clockevents/next
Regards
ChenYu
