Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp36849imm; Mon, 4 Jun 2018 12:33:46 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLWI7CmyWulN19MIElbjqMjtrbSQEHlUKTCX0ZrtU0j7RvEWWo+Hc8HJQaGy7tm3LtFSyBJ X-Received: by 2002:a63:7208:: with SMTP id n8-v6mr18077694pgc.420.1528140826251; Mon, 04 Jun 2018 12:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528140826; cv=none; d=google.com; s=arc-20160816; b=dYnVrrOwIC+eW3pdclZKL/2+/W1YL3qVqi93AQx0SKvUdVIcxEIT7zohqYyrptBM2n KexoJB/ivfocbzDoCccmm6OkOSouS9y7bhyjj5XX38XHrQwa0AvY1qSzJ1NBVhOfVZh0 nNI9kAxmz7Q9rGIy8HIWUP/q37gf5qSpdMDY7FmMPBDInxNZy2bYw4MQKmKs2Kjb8Oqj pVpK1vli+hU1AkMsiAVWa2g/FqfgpPXe9h7Ib2KIkK5Wyc+AnK88cJTq8/w5ghD+VewS wZ3LMASMcHFt8auSvKAhAxcBIdHzZ3w+ecxnJgHk/R82MEzFOP5xHAYFAw6nr1QlMz8L Eygg== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=A2nAEw2lZ6cNi+EEFiSNmr+qBcM32Ewi+F2BR7/y+Mg=; b=FS3rnRu4spO+BEW03aa8ev2Ze9x/IFDLMbd0J+kCWp5xBlSBqKyaP8kL8Vi2ijZ8wK 32yHImIMJGU0xb9HfTkdcy7NBUwz19Bzh+KORe/218QaUKPmrgYPlFbVizzx72oTJM8z uS3I3w2abv5csDGrDcMIgEme4duPqrDyjRnvWO1Dmm78l6SPvS/RrBCYVUBhS3muOL08 tvqz400cp9R1gz7LjHqbxqEIewENBSRg8+OFN0nxxPcfXg6txJ/twrkg2focP7oRLd7/ DvIE+hxN2y8fRtZBL6EkhWyPpDvBIVCN7ziJPbOv/PFtbQG+ROeWWt3XrFw7AVdItf3F G8/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=flzNj0mw; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w16-v6si47286241plq.141.2018.06.04.12.33.31; Mon, 04 Jun 2018 12:33:46 -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=@gmail.com header.s=20161025 header.b=flzNj0mw; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751297AbeFDTc4 (ORCPT + 99 others); Mon, 4 Jun 2018 15:32:56 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:55404 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879AbeFDTcy (ORCPT ); Mon, 4 Jun 2018 15:32:54 -0400 Received: by mail-wm0-f66.google.com with SMTP id v16-v6so416662wmh.5; Mon, 04 Jun 2018 12:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=A2nAEw2lZ6cNi+EEFiSNmr+qBcM32Ewi+F2BR7/y+Mg=; b=flzNj0mwBXbMVsBtSs7nClpxlyxlTT4ABQ6MGX/cXHqWkw8rKMrHKRiW+Ia+/lBHvi uj2eLFAu8X2krXaly8vD49ptR4pcfW7I5g2LaWxQPH5XGOmWCUcuz/lEaCXSX+4lpfOo GGjzk5cdSW2Q6lOWYIqNhI+PMSuVeYZQ/aWU27TYEnxGV6qOUV2c4dZeL73faihD4Ogt yzvtUeLZ6jHl38VP5a5wg0Qb+xUN9zFeBBNuRNBknX8ZLmKztf2V2PB2WHz+zbHLqryT 0W9uxR0trjof36aXCSlFzFetVlz2rqKPaHjfJLyOwUVdSS5Pu9MvqWUG6G2GtVVX785B afjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=A2nAEw2lZ6cNi+EEFiSNmr+qBcM32Ewi+F2BR7/y+Mg=; b=QWbw4XAozWI9mXGf+tevJPCCYuKVxPfqHNDJe+ihLH4pO9DVuG/SegYWVE7U4tnO9W 0Oiaukouw7TkhlP0AB8WCFJSpW+DlGsKJCXZYSxJboHgjP94ovLxiNW4hMZFsuoUVyG8 FcAcQDQMy3CMmx5gto9yrpePOC7a+B2iV0Nwy24SLiVVi6LFSOjGh1vqDBhgcxH62o42 5Y3d4jwD72JJ0K0E/cHdjL2AczgGwUaFgmD0/HPbudScsP8m4WjZJ9UYXKLhLAQm2qOi QD/GfuyJI3MAJRyYdSGSX0MKfv+FgVv/J/T8pZHBdz34F3hUgVUz2bgV8L203EvgzjTF bSww== X-Gm-Message-State: APt69E00Jmc8Db0tUB9by7nfLwojcMKnUpd8cwwsmlx6IU5pRmpNtdM8 LzFzBR8nHCz6qaBKD3715W4= X-Received: by 2002:a1c:c342:: with SMTP id t63-v6mr2217668wmf.123.1528140772890; Mon, 04 Jun 2018 12:32:52 -0700 (PDT) Received: from L80496 (abo-39-222-68.trs.modulonet.fr. [85.68.222.39]) by smtp.gmail.com with ESMTPSA id t14-v6sm41916966wrm.82.2018.06.04.12.32.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Jun 2018 12:32:51 -0700 (PDT) Date: Mon, 4 Jun 2018 21:32:50 +0200 From: Thibaut Robert To: Dan Carpenter 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: <20180604193250.GB32753@L80496> References: <20180529191143.13081-1-thibaut.robert@gmail.com> <20180530111725.gmigyddsp2i6mgzw@mwanda> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180530111725.gmigyddsp2i6mgzw@mwanda> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le mercredi 30 mai 2018 ? 14:17:25 (+0300), Dan Carpenter a ?crit : > 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... buff comes from the network but we are looking at single byte here. ieee80211_is_action expects an le16, so we I added this to extend an u8 to an le16. Is this incorrect ? Or maybe we the buff has the second byte ? but that I can't tell. > > > 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