Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread Arnd Bergmann
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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread Pingbo Wen

> 在 2015年10月23日,19:45,Arnd Bergmann  写道:
> 
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread Arnd Bergmann
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 
> ---
> 
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread WEN Pingbo
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 
---

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(-)

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(_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(_sdc.rtq_lock);
 
if (hp_sdc.rcurr >= 0) {
-   struct timeval tv;
+   ktime_t time_diff = ktime_sub(ktime_get(), hp_sdc.rtv);
 
-   do_gettimeofday();
-   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(_sdc.rtv);
+   hp_sdc.rtv = ktime_get();
curr->idx++;
/* Still need to lock here in case of spurious irq. */
write_lock_irq(_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 2
+#define HP_SDC_MAX_REG_DELAY 2000
 
 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.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread Arnd Bergmann
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 
> ---
> 
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread WEN Pingbo
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 
---

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(-)

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(_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(_sdc.rtq_lock);
 
if (hp_sdc.rcurr >= 0) {
-   struct timeval tv;
+   ktime_t time_diff = ktime_sub(ktime_get(), hp_sdc.rtv);
 
-   do_gettimeofday();
-   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(_sdc.rtv);
+   hp_sdc.rtv = ktime_get();
curr->idx++;
/* Still need to lock here in case of spurious irq. */
write_lock_irq(_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 2
+#define HP_SDC_MAX_REG_DELAY 2000
 
 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.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread Arnd Bergmann
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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread Pingbo Wen

> 在 2015年10月23日,19:45,Arnd Bergmann  写道:
> 
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/