Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4360417imm; Wed, 30 May 2018 04:19:04 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIa0iPKVcs2RWVA+ysaSO8shUdsBA7jAJnjeB6pr9UvC5y+oT7JAjUK09awav1Fm2X47ui8 X-Received: by 2002:a17:902:7406:: with SMTP id g6-v6mr2419670pll.90.1527679144004; Wed, 30 May 2018 04:19:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527679143; cv=none; d=google.com; s=arc-20160816; b=enSf66OoutdymRUu2BHAVKAApVc3lNggYz8c9areEd3/gpVGIa1Ld1+eqxLZSwuNgM wiTSzkRWRYVYhyeUflRkj6YrDL2UhsO9nGOiJfE+WIWmj78OqT8PIXdxjau7VVh/yiNn EXOg/RMGGZ4y45LA9/t4xp2FWsmsfWmg872/qOwyY1t6kUEB6jstF5U871XhKHH7gE9K 2o4vd7/glxmuMCJoV4kN8e1MLsa/5mS2lDPzz5SlZfmOjFjmfK6LazWkCjJLlwXFmfZL WYCd3/3n9mPcKkJzkkN1eYs0iPaj67Lh6p2LCwuw1vY0GiIajkdeTB+7kfeRexAjdSIW m+6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=yw1UvowisrtsAhQAtaRa74WASFhuEWrCnsCiT/wWQtA=; b=LXSa4GTuLpgueA1ihgCI0UEyYjU4GkMxEx9bFIwbP0xLCnuBvQ0VL8+qJzHZHcs3vR +SRpA7wNUDxmt7oVfUEad4XwhHrrN9JSpXhtLsYfa0XpmB5uO3Sv5TWh4cA0lGV6wzXn So6wFqLlzENGWrkHk2q2oXCzP8mF1wrLjQ6r/fgGFSGVqBWMxfYyBxBq4+Ym/jHuBQXN Liaz4GeT8XAP5xb33Rg3nJFy2bfsEJYpqFcj+uipR7r+YAVSw8OgNPUwkI1+8Nsf21P/ EB+x3DPoWsHlNjdYT1KokB8qhpjT636UMh2SWHNHMJx08mZFAvu10QtYp/Bsbs29E9vs jr0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=sG+eh2Vh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p66-v6si34259308pfg.329.2018.05.30.04.18.49; Wed, 30 May 2018 04:19:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=sG+eh2Vh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752972AbeE3LSD (ORCPT + 99 others); Wed, 30 May 2018 07:18:03 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:46752 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752517AbeE3LRr (ORCPT ); Wed, 30 May 2018 07:17:47 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4UBG9aX088724; Wed, 30 May 2018 11:17:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2017-10-26; bh=yw1UvowisrtsAhQAtaRa74WASFhuEWrCnsCiT/wWQtA=; b=sG+eh2VhJ038gJuTiNF5eTEyTof7CTFp0EAnAIsiX7POVnei52zAw5RAgHi6N+B34qnV EbAG5I7Wxl49rcBsftmCF+tWjEJcrglcQUJS/M8C4+s4JPNcY6yEbMokk/8qlKOVq3B/ ku7Ik1+qgJO/xTZ3bRBrJ14oJZHPWXiPCFClLcXpF4SAhZHIUFekvPzp+ZA0dZdzc/DM QSRnQ/B+jMTD5FPXshKaqpjVsWfpD36V2nage+pLgpX1AyU291tFge8pEya75E6V1X0m mx85srSXqzzGLEe3nbSxJmgQ0JO3vLpyV9eZwBSAhksvbulTMxCJ1EltBiKgpJ8NOZPq 8A== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2j9ev89wj7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 11:17:35 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4UBHZTu028392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 11:17:35 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4UBHYiK017125; Wed, 30 May 2018 11:17:34 GMT Received: from mwanda (/197.157.0.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 May 2018 04:17:33 -0700 Date: Wed, 30 May 2018 14:17:25 +0300 From: Dan Carpenter To: Thibaut Robert Cc: Aditya Shankar , Ganesh Krishna , Greg Kroah-Hartman , devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] staging: wilc1000: fix some endianness sparse warnings Message-ID: <20180530111725.gmigyddsp2i6mgzw@mwanda> References: <20180529191143.13081-1-thibaut.robert@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180529191143.13081-1-thibaut.robert@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8908 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805300130 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 29, 2018 at 09:11:43PM +0200, Thibaut Robert wrote: > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c > index e248702ee519..745bf5ca2622 100644 > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c > @@ -1431,7 +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device *dev, u8 *buff, u32 size) > > freq = ieee80211_channel_to_frequency(curr_channel, NL80211_BAND_2GHZ); > > - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) { > + if (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) { "buff" comes from the network, it's going to be little endian, not cpu endian. The rest of the function treats it as CPU endian but I'm pretty sure it's wrong... > cfg80211_rx_mgmt(priv->wdev, freq, 0, buff, size, 0); > return; > } > diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c > index 28c93f3f846e..a5ac1d26590b 100644 > --- a/drivers/staging/wilc1000/wilc_wlan.c > +++ b/drivers/staging/wilc1000/wilc_wlan.c > @@ -560,7 +560,8 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count) > int ret = 0; > int counter; > int timeout; > - u32 vmm_table[WILC_VMM_TBL_SIZE]; > + __le32 vmm_table[WILC_VMM_TBL_SIZE]; > + u32 table_entry; > struct wilc_vif *vif; > struct wilc *wilc; > const struct wilc_hif_func *func; > @@ -598,10 +599,10 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count) > if ((sum + vmm_sz) > LINUX_TX_SIZE) > break; > > - vmm_table[i] = vmm_sz / 4; > + table_entry = vmm_sz / 4; > if (tqe->type == WILC_CFG_PKT) > - vmm_table[i] |= BIT(10); > - vmm_table[i] = cpu_to_le32(vmm_table[i]); > + table_entry |= BIT(10); > + vmm_table[i] = cpu_to_le32(table_entry); > > i++; > sum += vmm_sz; > @@ -704,8 +705,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count) > if (vmm_table[i] == 0) > break; > > - vmm_table[i] = cpu_to_le32(vmm_table[i]); > - vmm_sz = (vmm_table[i] & 0x3ff); > + vmm_sz = (le32_to_cpu(vmm_table[i]) & 0x3ff); > vmm_sz *= 4; > header = (tqe->type << 31) | > (tqe->buffer_size << 15) | > @@ -715,8 +715,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count) > else > header &= ~BIT(30); > > - header = cpu_to_le32(header); > - memcpy(&txb[offset], &header, 4); > + *((__le32 *)&txb[offset]) = cpu_to_le32(header); I worry about alignment issues here. That might be the reason for the memcpy(). (I'm reading as fast as I can and don't the code so I may be wrong). > if (tqe->type == WILC_CFG_PKT) { > buffer_offset = ETH_CONFIG_PKT_HDR_OFFSET; > } else if (tqe->type == WILC_NET_PKT) { > @@ -770,8 +769,7 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc, u8 *buffer, int size) > > do { > buff_ptr = buffer + offset; > - memcpy(&header, buff_ptr, 4); > - header = cpu_to_le32(header); > + header = le32_to_cpup((__le32 *)buff_ptr); Maybe the same, whenever you see a memcpy(). > > is_cfg_packet = (header >> 31) & 0x1; > pkt_offset = (header >> 22) & 0x1ff; > @@ -942,6 +940,7 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const u8 *buffer, > u32 offset; > u32 addr, size, size2, blksz; > u8 *dma_buffer; > + const __le32 *header; > int ret = 0; > > blksz = BIT(12); > @@ -952,10 +951,9 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const u8 *buffer, > > offset = 0; > do { > - memcpy(&addr, &buffer[offset], 4); > - memcpy(&size, &buffer[offset + 4], 4); > - addr = cpu_to_le32(addr); > - size = cpu_to_le32(size); > + header = (__le32 *)buffer + offset; > + addr = le32_to_cpu(header[0]); > + size = le32_to_cpu(header[1]); > acquire_bus(wilc, ACQUIRE_ONLY); > offset += 8; > while (((int)size) && (offset < buffer_size)) { > diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c b/drivers/staging/wilc1000/wilc_wlan_cfg.c > index c0b9b700f4d7..4a914d8572aa 100644 > --- a/drivers/staging/wilc1000/wilc_wlan_cfg.c > +++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c > @@ -275,14 +275,14 @@ static int wilc_wlan_cfg_set_bin(u8 *frame, u32 offset, u16 id, u8 *b, u32 size) > > static void wilc_wlan_parse_response_frame(u8 *info, int size) > { > - u32 wid, len = 0, i = 0; > + u32 wid; > + int len = 0, i = 0; Why did we make these int now? > > while (size > 0) { > i = 0; > - wid = info[0] | (info[1] << 8); > - wid = cpu_to_le32(wid); > + wid = le16_to_cpup((__le16 *)info); > > - switch ((wid >> 12) & 0x7) { > + switch (info[1] >> 4) { Why do we not need to mask by 0x7? Anyway, I feel like this isn't beautiful. We should be using a macro and "wid" instead of magically poking into info[1]. switch(SOME_MACRO(wid)) { regards, dan carpenter