[PATCH] staging: ks7010: fix wait_for_completion_interruptible_timeout return handling

[PATCH] staging: ks7010: fix wait_for_completion_interruptible_timeout return handling

[Nicholas Mc Guire]

wait_for_completion_interruptible_timeout return 0 on timeout and 
-ERESTARTSYS if interrupted. The check for 
!wait_for_completion_interruptible_timeout() would report an interrupt
as timeout. Further, while HZ/50 will work most of the time it could 
fail for HZ < 50, so this is switched to msecs_to_jiffies(20).

Fixes: 13a9930d15b4 ("staging: ks7010: add driver from Nanonote extra-repository")

Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---

API non-compliance was located by coccinelle

Note: build showed some sparse warnings
CHECK   drivers/staging/ks7010/ks_hostif.c                                      
drivers/staging/ks7010/ks_hostif.c:72:6: warning: symbol
'ks_wlan_hw_wakeup_task' was not declared. Should it be static?
drivers/staging/ks7010/ks_hostif.c:1512:6: warning: symbol
'hostif_infrastructure_set2_request' was not declared. Should it be static?

Compile tested with: x86_64_defconfig + CONFIG_STAGING=y
CONFIG_MMC=m, CONFIG_KS7010=m

Patch is against 4.7-rc7 (localversion-next -next-20160725)

 drivers/staging/ks7010/ks_hostif.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c b/drivers/staging/ks7010/ks_hostif.c
index a8822fe..4d32c98 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -74,11 +74,15 @@ void ks_wlan_hw_wakeup_task(struct work_struct *work)
 	struct ks_wlan_private *priv =
 	    container_of(work, struct ks_wlan_private, ks_wlan_wakeup_task);
 	int ps_status = atomic_read(&priv->psstatus.status);
+	long time_left;
 
 	if (ps_status == PS_SNOOZE) {
 		ks_wlan_hw_wakeup_request(priv);
-		if (!wait_for_completion_interruptible_timeout(&priv->psstatus.wakeup_wait, HZ / 50)) {	/* 20ms timeout */
-			DPRINTK(1, "wake up timeout !!!\n");
+		time_left = wait_for_completion_interruptible_timeout(
+				&priv->psstatus.wakeup_wait,
+				msecs_to_jiffies(20));
+		if (time_left <= 0) {
+			DPRINTK(1, "wake up timeout or interrupted !!!\n");
 			schedule_work(&priv->ks_wlan_wakeup_task);
 			return;
 		}
-- 
2.1.4

Re: [PATCH] staging: ks7010: fix wait_for_completion_interruptible_timeout return handling

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Mon, Jul 25, 2016 at 09:21:50PM +0200, Nicholas Mc Guire wrote:
> wait_for_completion_interruptible_timeout return 0 on timeout and 
> -ERESTARTSYS if interrupted. The check for 
> !wait_for_completion_interruptible_timeout() would report an interrupt
> as timeout. Further, while HZ/50 will work most of the time it could 

Wouldn't it interpret -ERESTARTSYS as *no timeout*?

Anyway, the plain !0 comparison for me clearly shows that
'interruptible' was more copy&pasted then really planned or supported.
If it was, it would need to cancel something. Also, 20ms is pretty hard
to cancel for a user ;) Given all that and the troubles we had with
'interruptible' in the I2C subsystem, I'd much vote for dropping
interruptible here.

> fail for HZ < 50, so this is switched to msecs_to_jiffies(20).

Rest looks good, thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] staging: ks7010: fix wait_for_completion_interruptible_timeout return handling

[Nicholas Mc Guire]

On Mon, Jul 25, 2016 at 10:54:03PM +0200, Wolfram Sang wrote:
> On Mon, Jul 25, 2016 at 09:21:50PM +0200, Nicholas Mc Guire wrote:
> > wait_for_completion_interruptible_timeout return 0 on timeout and 
> > -ERESTARTSYS if interrupted. The check for 
> > !wait_for_completion_interruptible_timeout() would report an interrupt
> > as timeout. Further, while HZ/50 will work most of the time it could 
> 
> Wouldn't it interpret -ERESTARTSYS as *no timeout*?
>

yup - actually the current code just treats the -ERESTARTSYS 
case as success.
 
> Anyway, the plain !0 comparison for me clearly shows that
> 'interruptible' was more copy&pasted then really planned or supported.
> If it was, it would need to cancel something. Also, 20ms is pretty hard
> to cancel for a user ;) Given all that and the troubles we had with
> 'interruptible' in the I2C subsystem, I'd much vote for dropping
> interruptible here.
> 
> > fail for HZ < 50, so this is switched to msecs_to_jiffies(20).
> 
> Rest looks good, thanks!
> 

thx!
hofrat