From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752315AbbFZQd4 (ORCPT ); Fri, 26 Jun 2015 12:33:56 -0400 Received: from mail-qc0-f173.google.com ([209.85.216.173]:36617 "EHLO mail-qc0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751814AbbFZQdr (ORCPT ); Fri, 26 Jun 2015 12:33:47 -0400 Date: Fri, 26 Jun 2015 13:36:14 -0300 From: Gaston Gonzalez To: Arnd Bergmann Cc: gregkh@linuxfoundation.org, paul.gortmaker@windriver.com, dilekuzulmez@gmail.com, gdonald@gmail.com, cristina.opriceana@gmail.com, hamohammed.sa@gmail.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging: rtl8192u: ieee80211_rx: Fix incorrect type in assignments Message-ID: <20150626163614.GA18241@debsktop1> References: <1434924729-21086-1-git-send-email-gascoar@gmail.com> <1775494.ZyQRebyBWF@wuerfel> <20150624163458.GA1613@debsktop1> <13543765.eFokhJjyZi@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13543765.eFokhJjyZi@wuerfel> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 25, 2015 at 02:06:44PM +0200, Arnd Bergmann wrote: > On Wednesday 24 June 2015 13:34:58 Gaston Gonzalez wrote: > > On Tue, Jun 23, 2015 at 12:13:47PM +0200, Arnd Bergmann wrote: > > > On Sunday 21 June 2015 19:12:09 Gaston Gonzalez wrote: > > > > /* WMM spec P.11: The minimum value for AIFSN shall be 2 */ > > > > qos_param->aifs[aci] = (qos_param->aifs[aci] < 2) ? 2:qos_param->aifs[aci]; > > > > > > > > - qos_param->cw_min[aci] = ac_params->ecw_min_max & 0x0F; > > > > + qos_param->cw_min[aci] = > > > > + cpu_to_le16(ac_params->ecw_min_max & 0x0F); > > > > > > > > - qos_param->cw_max[aci] = (ac_params->ecw_min_max & 0xF0) >> 4; > > > > + qos_param->cw_max[aci] = > > > > + cpu_to_le16((ac_params->ecw_min_max & 0xF0) >> 4); > > > > > > > > qos_param->flag[aci] = > > > > (ac_params->aci_aifsn & 0x10) ? 0x01 : 0x00; > > > > - qos_param->tx_op_limit[aci] = le16_to_cpu(ac_params->tx_op_limit); > > > > + qos_param->tx_op_limit[aci] = ac_params->tx_op_limit; > > > > } > > > > return 0; > > > > > > This certainly needs a more thorough description of how you determined that > > > the byte swaps that you add are in fact required. Did you test it on > > > a big-endian machine? > > > > > > Arnd > > > > Hello Arnd, > > > > Thank you for reviewing this. > > After your email and reviwing this again I'm getting a bit suspicious > > myself, but this is what I saw: > > > > -- First warning: > > > > qos_param->cw_min[aci] is defined as __le16() in ieee80211.h > > (ieee80211_qos_parameters structure) > > > > ac_params-> ecw_min_max is defined as u8 in ieee80211.h > > (ieee80211_qos_ac_parameter structure) > > > > So the assignment is: __le16 = u8 & 0x0F; > > > > -- Second warning: > > > > qos_param->cw_max[aci] is __le16() > > ac_params-> ecw_min_max is u8 > > > > The assignment is: __le16 = (u8 & 0xF0) >> 4; > > > > Thus, for the warning 1 and 2, I understand that the result won't be the > > same if the machine is big-endian or little-endian, and that's why we > > need a cpu_to_le16. Am I missing something? > > I think your analysis is right, as long as the __le16 annotation is > actually correct. It usually helps to look at the git history to > see what the intent of the patch was that introduced the assignment > and the patch that introduced the __le16 type. Presumably one of them > was incorrect, and it would be good to figure out where it went wrong, > and to add a 'Fixes:' tag in your patch description that pinpoints > the exact mistake. > Ok, will do. > > -- Third warning: > > > > In this case both sides of the assignment are already defined as __le16: > > > > qos_param->tx_op_limit[aci] (ieee80211_qos_parameters structure defined > > in ieee80211.h)) > > > > ac_params->tx_op_limit (ieee80211_qos_ac_parameter structure defined in > > ieee80211.h) > > > > So the assignment is: __le16() = le16_to_cpu(__le16) > > > > Im getting suspicious now, but it sounded wrong to me. > > In the case the right part is correct, I guess the left part should be > > u16 type? > > Again, your logic sounds good: there is clearly something wrong here, but > it's not obvious to conclude whether it is an incorrect annotation or > an extraneous byte swap. Besides looking at the git history, it also > helps to look at all other uses of the two sides of the assignment: > > See if qos_param->tx_op_limit is in fact used as a little-endian > value (e.g. by copying to memory or a register), and if the value that > got written to ac_params->tx_op_limit was byte-swapped already at > the time of assignment. > Ok, I'll do it too. > > Regarding the test: I tested it on my machine, but is of course little- > > endian :( I could built a qemu virtual machine to test it on a > > big-endian emulated platform. Should that work? > > Yes, that would work: you can assign the USB device to the qemu machine > and run a kernel in there. The easiest emulation to try is probably > a PowerPC PAPR machine with a file system from > https://people.debian.org/~aurel32/qemu/powerpc/. > MIPS should work as well. > Ok, thanks a lot for all the pointers. Gaston > Arnd