[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161129091258.GA19534@gmail.com>
Date: Tue, 29 Nov 2016 10:12:58 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Baolin Wang <baolin.wang@...aro.org>
Cc: John Stultz <john.stultz@...aro.org>,
lkml <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Prarit Bhargava <prarit@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 4/7] time: alarmtimer: Add the tracepoints for alarmtimer
* Baolin Wang <baolin.wang@...aro.org> wrote:
> On 29 November 2016 at 15:23, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > * John Stultz <john.stultz@...aro.org> wrote:
> >
> >> From: Baolin Wang <baolin.wang@...aro.org>
> >>
> >> For system debugging, we sometimes want to know who sets one
> >> alarm timer, the time of the timer, when the timer started and
> >> fired and so on. Thus adding tracepoints can help us trace the
> >> alarmtimer information.
> >
> > s/one alarm timer/an alarm timer
> >
> >> For example, when we debug the system supend/resume, if the
> >> system is always resumed by RTC alarm, we can find out which
> >> process set the alarm timer to resume system by below trace log:
> >
> > s/when we debug the system/when we debug system
> > s/supend/suspend
> > s/resume system/resume the system
> > s/by below trace log/by the trace log below
> >
> >> From the trace log, we can find out the 'Binder:3292_2' process
> >> set one alarm timer which resumes the system.
> >
> > s/set one alarm timer/set an alarm timer
> >
> >> Changes since v4:
> >> - Initialize 'type' to -1 and rename it in alarmtimer_suspend().
> >> - Fix typo in subject line.
> >>
> >> Changes since v3:
> >> - Remove the "ALARM_" prefix in the string.
> >> - Add the ACK by Steven Rostedt.
> >>
> >> Changes since v2:
> >> - Save time as s64 type.
> >> - Remove 'process_name' parameter and add 'now' parameter.
> >> - Rename the trace event name.
> >> - Remove restart trace event.
> >> - Other optimization.
> >
> > I find it really sad that a patch that has gone through 4 iterations still has so
> > many typos and grammar errors in its changelog :-(
>
> Really sorry for these elementary errors, I will fix these errors in
> new patch. Sorry for troubles again.
No problem - the code looks fine to me, so we can fix this when applying the
patches.
Thanks,
Ingo
Powered by blists - more mailing lists