| Message ID | 1445599779-11733-1-git-send-email-pingbo.wen@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Friday 23 October 2015 19:29:39 WEN Pingbo wrote: > 1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no need to handle sec and usec separately > > 2. hp_sdc.rtv is only used for time diff, monotonic time is better here > > Signed-off-by: WEN Pingbo <pingbo.wen@linaro.org> > --- > > Version 2: > Using ktime_t instead of struct timespec64 > Version 3: > Commit msg adjustment, and using ktime_to_ns to extract nsecs > The patch looks good now, but the changelog still needs a tiny bit of work. First of all, your line wrapping is off, please start a new line after around 70 characters as you do in an email. Also, we don't normally have enumerated lists in a changelog, just use normal text. The best changelogs typically have three paragraphs: The first paragraph describes what the driver currently does. For really obvious cases, this can be combined with the second paragraph. The second paragraph explains why that is bad. This is where you can mention the monotonic time vs real time issue and say whether we just want the timeval removed to fix the kernel in general or whether this particular driver is broken. The third paragraph explains what the patch does to resolve the issue described in the second one. This is also where you can list other approaches that would have solved the problem, and why you picked on over the others. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 在 2015年10月23日，19:45，Arnd Bergmann <arnd@arndb.de> 写道： > > On Friday 23 October 2015 19:29:39 WEN Pingbo wrote: >> 1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no need to handle sec and usec separately >> >> > > The patch looks good now, but the changelog still needs a tiny bit of > work. First of all, your line wrapping is off, please start a new line > after around 70 characters as you do in an email. > Well, little fault:) Will be fixed in next version. > Also, we don't normally have enumerated lists in a changelog, just use > normal text. The best changelogs typically have three paragraphs: > > The first paragraph describes what the driver currently does. For really > obvious cases, this can be combined with the second paragraph. > > The second paragraph explains why that is bad. This is where you can > mention the monotonic time vs real time issue and say whether we > just want the timeval removed to fix the kernel in general or whether > this particular driver is broken. > > The third paragraph explains what the patch does to resolve the issue > described in the second one. This is also where you can list other > approaches that would have solved the problem, and why you picked on > over the others. Do we really need this in ChangeLog? Commit msg already states this. I think the purpose of ChangeLog is let people know the main difference of two version patch at a glance, and the ‘what’ and ‘why’ should be placed in commit msg. Pingbo-- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 October 2015 20:19:46 Pingbo Wen wrote: > > > Also, we don't normally have enumerated lists in a changelog, just use > > normal text. The best changelogs typically have three paragraphs: > > > > The first paragraph describes what the driver currently does. For really > > obvious cases, this can be combined with the second paragraph. > > > > The second paragraph explains why that is bad. This is where you can > > mention the monotonic time vs real time issue and say whether we > > just want the timeval removed to fix the kernel in general or whether > > this particular driver is broken. > > > > The third paragraph explains what the patch does to resolve the issue > > described in the second one. This is also where you can list other > > approaches that would have solved the problem, and why you picked on > > over the others. > > Do we really need this in ChangeLog? Commit msg already states this. I think > the purpose of ChangeLog is let people know the main difference of two > version patch at a glance, and the ‘what’ and ‘why’ should be placed in > commit msg. > I was using the terms changelog and commit message interchangeably, sorry for being unclear. I meant the part above the --- line. The revision history you have below the --- line looks good here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/input/serio/hp_sdc.c b/drivers/input/serio/hp_sdc.c index 852858e..17e3725 100644 --- a/drivers/input/serio/hp_sdc.c +++ b/drivers/input/serio/hp_sdc.c @@ -193,7 +193,7 @@ static void hp_sdc_take(int irq, void *dev_id, uint8_t status, uint8_t data) curr->seq[curr->idx++] = status; curr->seq[curr->idx++] = data; hp_sdc.rqty -= 2; - do_gettimeofday(&hp_sdc.rtv); + hp_sdc.rtv = ktime_get(); if (hp_sdc.rqty <= 0) { /* All data has been gathered. */ @@ -306,13 +306,9 @@ static void hp_sdc_tasklet(unsigned long foo) write_lock_irq(&hp_sdc.rtq_lock); if (hp_sdc.rcurr >= 0) { - struct timeval tv; + ktime_t time_diff = ktime_sub(ktime_get(), hp_sdc.rtv); - do_gettimeofday(&tv); - if (tv.tv_sec > hp_sdc.rtv.tv_sec) - tv.tv_usec += USEC_PER_SEC; - - if (tv.tv_usec - hp_sdc.rtv.tv_usec > HP_SDC_MAX_REG_DELAY) { + if (ktime_to_ns(time_diff) > HP_SDC_MAX_REG_DELAY) { hp_sdc_transaction *curr; uint8_t tmp; @@ -321,8 +317,8 @@ static void hp_sdc_tasklet(unsigned long foo) * we'll need to figure out a way to communicate * it back to the application. and be less verbose. */ - printk(KERN_WARNING PREFIX "read timeout (%ius)!\n", - (int)(tv.tv_usec - hp_sdc.rtv.tv_usec)); + printk(KERN_WARNING PREFIX "read timeout (%llins)!\n", + ktime_to_ns(time_diff)); curr->idx += hp_sdc.rqty; hp_sdc.rqty = 0; tmp = curr->seq[curr->actidx]; @@ -551,7 +547,7 @@ unsigned long hp_sdc_put(void) /* Start a new read */ hp_sdc.rqty = curr->seq[curr->idx]; - do_gettimeofday(&hp_sdc.rtv); + hp_sdc.rtv = ktime_get(); curr->idx++; /* Still need to lock here in case of spurious irq. */ write_lock_irq(&hp_sdc.rtq_lock); diff --git a/include/linux/hp_sdc.h b/include/linux/hp_sdc.h index d392975..348a9b5 100644 --- a/include/linux/hp_sdc.h +++ b/include/linux/hp_sdc.h @@ -47,9 +47,9 @@ #endif -/* No 4X status reads take longer than this (in usec). +/* No 4X status reads take longer than this (in nsec). */ -#define HP_SDC_MAX_REG_DELAY 20000 +#define HP_SDC_MAX_REG_DELAY 20000000 typedef void (hp_sdc_irqhook) (int irq, void *dev_id, uint8_t status, uint8_t data); @@ -281,7 +281,7 @@ typedef struct { hp_sdc_transaction *tq[HP_SDC_QUEUE_LEN]; /* All pending read/writes */ int rcurr, rqty; /* Current read transact in process */ - struct timeval rtv; /* Time when current read started */ + ktime_t rtv; /* Time when current read started */ int wcurr; /* Current write transact in process */ int dev_err; /* carries status from registration */
1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no need to handle sec and usec separately 2. hp_sdc.rtv is only used for time diff, monotonic time is better here Signed-off-by: WEN Pingbo <pingbo.wen@linaro.org> --- Version 2: Using ktime_t instead of struct timespec64 Version 3: Commit msg adjustment, and using ktime_to_ns to extract nsecs drivers/input/serio/hp_sdc.c | 16 ++++++---------- include/linux/hp_sdc.h | 6 +++--- 2 files changed, 9 insertions(+), 13 deletions(-)