Re: [PATCH 5/6] staging: wilc1000: fix initialize warning issue.

[Dan Carpenter <dan.carpenter@oracle.com>]

On Tue, Jun 30, 2015 at 05:34:37PM +0900, Dean Lee wrote:
> modify it
> 
> Signed-off-by: Dean Lee <dean.lee@atmel.com>

This patch description is useless.  What is the warning?

> ---
>  drivers/staging/wilc1000/host_interface.c | 3 ++-
>  drivers/staging/wilc1000/linux_wlan.c     | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
> index 1e40dca..a2e9b6d 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -7162,7 +7162,7 @@ s32 host_int_add_beacon(void *hWFIDrv, u32 u32Interval,
>  	s32 s32Error = WILC_SUCCESS;
>  	tstrWILC_WFIDrv *pstrWFIDrv = (tstrWILC_WFIDrv *)hWFIDrv;
>  	tstrHostIFmsg strHostIFmsg;
> -	tstrHostIFSetBeacon *pstrSetBeaconParam = &strHostIFmsg.uniHostIFmsgBody.strHostIFSetBeacon;
> +	tstrHostIFSetBeacon *pstrSetBeaconParam = NULL;

The NULL pointer is not going to be used so do not initialize
pstrSetBeaconParam.

>  
>  	if (hWFIDrv == NULL) {
>  		WILC_ERRORREPORT(s32Error, WILC_INVALID_ARGUMENT);
> @@ -7172,6 +7172,7 @@ s32 host_int_add_beacon(void *hWFIDrv, u32 u32Interval,
>  
>  	PRINT_D(HOSTINF_DBG, "Setting adding beacon message queue params\n");
>  
> +	pstrSetBeaconParam = &strHostIFmsg.uniHostIFmsgBody.strHostIFSetBeacon;
>  
>  	/* prepare the WiphyParams Message */
>  	strHostIFmsg.u16MsgId = HOST_IF_MSG_ADD_BEACON;
> diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
> index 659b70a..1b8991a 100644
> --- a/drivers/staging/wilc1000/linux_wlan.c
> +++ b/drivers/staging/wilc1000/linux_wlan.c
> @@ -2463,7 +2463,7 @@ void frmw_to_linux(uint8_t *buff, uint32_t size, uint32_t pkt_offset)
>  			return;
>  		}
>  
> -		skb_reserve(skb, (unsigned int)skb->data & 0x3);
> +		skb_reserve(skb, (uintptr_t)skb->data & 0x3);

Neither the original nor the new code make sense.  skb->data is a
properly aligned pointer so we are doing skb_reserve(skb, 0);

This change is not described in the patch description.

regards,
dan carpenter