API compliance scanning with coccinelle flagged:
./drivers/net/wan/cosa.c:520:2-18: WARNING:
timeout (30) seems HZ dependent
Numeric constants passed to schedule_timeout() make the effective
timeout HZ dependent which makes little sense in a device probe.
Fixed up by converting the constant to jiffies with msecs_to_jiffies()
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
As the actually intended timeout is not documented and msecs_to_jiffies
timeouts can be a factor 10 different from the current effective timeout
As the original driver predates variable HZ (2.2.26 drivers/net/cosa.c
also is using schedule_timeout(30)) this is probably assuming HZ=100
and thus the timeout would need to be 300, this needs to be checked by
someone who knows the details of this driver.
In any case it should be passed in a HZ independent manner.
Patch was compile tested with i386_defconfig + CONFIG_WAN=y
CONFIG_ISA=y, CONFIG_HDLC=m, CONFIG_COSA=m
Patch is against 4.1-rc6 (localversion-next is -next-20150605)
drivers/net/wan/cosa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index bcfa01a..4cce63c 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -517,7 +517,7 @@ static int cosa_probe(int base, int irq, int dma)
*/
set_current_state(TASK_INTERRUPTIBLE);
cosa_putstatus(cosa, SR_TX_INT_ENA);
- schedule_timeout(30);
+ schedule_timeout(msecs_to_jiffies(300));
irq = probe_irq_off(irqs);
/* Disable all IRQs from the card */
cosa_putstatus(cosa, 0);
--
1.7.10.4
From: Nicholas Mc Guire <[email protected]>
Date: Sat, 6 Jun 2015 09:51:51 +0200
> @@ -517,7 +517,7 @@ static int cosa_probe(int base, int irq, int dma)
> */
> set_current_state(TASK_INTERRUPTIBLE);
> cosa_putstatus(cosa, SR_TX_INT_ENA);
> - schedule_timeout(30);
> + schedule_timeout(msecs_to_jiffies(300));
> irq = probe_irq_off(irqs);
> /* Disable all IRQs from the card */
> cosa_putstatus(cosa, 0);
You are making these transformations completely inconsistently.
You're converting it to msecs in some patches and here you are doing
something else.
Please do _all_ of these transformations consistently and in a way
that minimizes the chances of breaking things.
And the only way to do that is to strictly convert these cases to
whatever it works out to when HZ=100 since that is strictly the
environment all of this old code was written in.
Thank you.
On Sun, 07 Jun 2015, David Miller wrote:
> From: Nicholas Mc Guire <[email protected]>
> Date: Sat, 6 Jun 2015 09:51:51 +0200
>
> > @@ -517,7 +517,7 @@ static int cosa_probe(int base, int irq, int dma)
> > */
> > set_current_state(TASK_INTERRUPTIBLE);
> > cosa_putstatus(cosa, SR_TX_INT_ENA);
> > - schedule_timeout(30);
> > + schedule_timeout(msecs_to_jiffies(300));
> > irq = probe_irq_off(irqs);
> > /* Disable all IRQs from the card */
> > cosa_putstatus(cosa, 0);
>
> You are making these transformations completely inconsistently.
>
> You're converting it to msecs in some patches and here you are doing
> something else.
>
As noted in the cosa case the code predated configurable HZ so the
30 was definitely assuming HZ=100 and therefor it should probably be 300
now - I do not think that is inconsisten and it was explained in the
patch. I only can make the HZ=100 assumption if the code predates
configurable HZ otherwise I leave it at the nominal value and put a note
in that it may be a significant change and needs review.
What alternative would you suggest ?
> Please do _all_ of these transformations consistently and in a way
> that minimizes the chances of breaking things.
>
> And the only way to do that is to strictly convert these cases to
> whatever it works out to when HZ=100 since that is strictly the
> environment all of this old code was written in.
>
for the dscc4 case Im not sure - that seems to have gone in in 2.4
and that had HZ configurable. The cosa case was checked
again 2.2.26 (no config HZ) and the timeout there was 30 -> 300ms.
I think that this is consistent with respect to the limited available
information of the timeout unit in the code.
thx!
hofrat
From: Nicholas Mc Guire <[email protected]>
Date: Sun, 7 Jun 2015 10:25:58 +0200
> for the dscc4 case Im not sure - that seems to have gone in in 2.4
> and that had HZ configurable. The cosa case was checked
> again 2.2.26 (no config HZ) and the timeout there was 30 -> 300ms.
>
> I think that this is consistent with respect to the limited available
> information of the timeout unit in the code.
Ok, applied.