On Tue, Jun 30, 2015 at 05:34:37PM +0900, Dean Lee wrote:
> modify it
> 
> Signed-off-by: Dean Lee <dean....@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

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to