[PATCH 1/1] driver/net: remove unused code in cosa module

[PATCH 1/1] driver/net: remove unused code in cosa module

[Li, Zhen-Hua]

From: "Li, Zhen-Hua" <zhen-hual@hp.com>

For the cosa module, CONFIG_COSA can only be checked as 'm',
and cosa module can only be compiled as a module.

So remove unused code in cosa.c

Signed-off-by: Li, Zhen-Hua <zhen-hual@hp.com>
---
 drivers/net/wan/cosa.c |    4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index 84734a8..83c39e2 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -1521,11 +1521,7 @@ static int cosa_reset_and_read_id(struct cosa_data *cosa, char *idstring)
 	cosa_putstatus(cosa, 0);
 	cosa_getdata8(cosa);
 	cosa_putstatus(cosa, SR_RST);
-#ifdef MODULE
 	msleep(500);
-#else
-	udelay(5*100000);
-#endif
 	/* Disable all IRQs from the card */
 	cosa_putstatus(cosa, 0);
 
-- 
1.7.10.4

Re: [PATCH 1/1] driver/net: remove unused code in cosa module

[David Miller]

From: "Li, Zhen-Hua" <zhen-hual@hp.com>
Date: Mon, 14 Apr 2014 18:08:36 +0800

> For the cosa module, CONFIG_COSA can only be checked as 'm',
> and cosa module can only be compiled as a module.

That's not true, it's "tristate" in drivers/net/wan/Kconfig so it
could be set to 'y' too.

But there is another reason to make this change, because for such
large timeout values only msleep() makes sense, udelay() could
overflow it's internal precision.

Please resubmit this with the proper reasoning and commit message.

Re: [PATCH 1/1] driver/net: remove unused code in cosa module

[Li, ZhenHua]

Thanks for your correction. I will send again with proper reason.

On 04/15/2014 01:31 AM, David Miller wrote:
> From: "Li, Zhen-Hua" <zhen-hual@hp.com>
> Date: Mon, 14 Apr 2014 18:08:36 +0800
>
>> For the cosa module, CONFIG_COSA can only be checked as 'm',
>> and cosa module can only be compiled as a module.
> That's not true, it's "tristate" in drivers/net/wan/Kconfig so it
> could be set to 'y' too.
>
> But there is another reason to make this change, because for such
> large timeout values only msleep() makes sense, udelay() could
> overflow it's internal precision.
>
> Please resubmit this with the proper reasoning and commit message.