RE: [PATCH net-next] hyperv: Fix a compiler warning in netvsc_send()

2013-04-29 Thread Haiyang Zhang


> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Monday, April 29, 2013 2:10 PM
> To: Haiyang Zhang
> Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> jasow...@redhat.com; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org
> Subject: Re: [PATCH net-next] hyperv: Fix a compiler warning in
> netvsc_send()
> 
> From: Haiyang Zhang 
> Date: Fri, 26 Apr 2013 11:25:55 -0700
> 
> > Fixed: warning: cast from pointer to integer of different size
> >
> > The Hyper-V hosts always use 64 bit request id. The guests can have 32
> > or 64 bit pointers which equal to the ulong type size. So we cast it to 
> > ulong
> type.
> > And, assigning 32bit integer to 64 bit variable works fine.
> >
> > The VMBus returns the same id in the completion packet. But the value
> > has no effect on the host side.
> >
> > Reported-by: kbuild test robot 
> > Signed-off-by: Haiyang Zhang 
> > Reviewed-by: K. Y. Srinivasan 
> 
> Applied, but:
> 
> > -   req_id = (u64)packet;
> > +   req_id = (ulong)packet;
> 
> I really do not like these shorthands for fundamental C types, we generally
> do not use "ulong", "uint" etc.  Please expand them out explicitly to
> "unsigned long", "unsigned int", etc.

Thanks for applying it. 

Going forward, I will use the long format, like "unsigned long", instead of 
"ulong", etc.

Thanks,
- Haiyang

--
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 net-next] hyperv: Fix a compiler warning in netvsc_send()

2013-04-29 Thread David Miller
From: Haiyang Zhang 
Date: Fri, 26 Apr 2013 11:25:55 -0700

> Fixed: warning: cast from pointer to integer of different size
> 
> The Hyper-V hosts always use 64 bit request id. The guests can have 32 or 64
> bit pointers which equal to the ulong type size. So we cast it to ulong type.
> And, assigning 32bit integer to 64 bit variable works fine.
> 
> The VMBus returns the same id in the completion packet. But the value has no
> effect on the host side.
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Haiyang Zhang 
> Reviewed-by: K. Y. Srinivasan 

Applied, but:

> - req_id = (u64)packet;
> + req_id = (ulong)packet;

I really do not like these shorthands for fundamental C types, we
generally do not use "ulong", "uint" etc.  Please expand them out
explicitly to "unsigned long", "unsigned int", etc.
--
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 net-next] hyperv: Fix a compiler warning in netvsc_send()

2013-04-26 Thread Haiyang Zhang
Fixed: warning: cast from pointer to integer of different size

The Hyper-V hosts always use 64 bit request id. The guests can have 32 or 64
bit pointers which equal to the ulong type size. So we cast it to ulong type.
And, assigning 32bit integer to 64 bit variable works fine.

The VMBus returns the same id in the completion packet. But the value has no
effect on the host side.

Reported-by: kbuild test robot 
Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
---
 drivers/net/hyperv/netvsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index f5f0f09..2b04804 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -522,7 +522,7 @@ int netvsc_send(struct hv_device *device,
sendMessage.msg.v1_msg.send_rndis_pkt.send_buf_section_size = 0;
 
if (packet->completion.send.send_completion)
-   req_id = (u64)packet;
+   req_id = (ulong)packet;
else
req_id = 0;
 
-- 
1.7.4.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/