From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757306AbdELIIz (ORCPT ); Fri, 12 May 2017 04:08:55 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:37551 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922AbdELIIu (ORCPT ); Fri, 12 May 2017 04:08:50 -0400 X-ME-Sender: X-Sasl-enc: uAtzovfaVcloz4NWKjVjJ26bnUBwb3Jq0DeThi2V3b2e 1494576524 Date: Fri, 12 May 2017 10:08:35 +0200 From: Greg Kroah-Hartman To: Guillaume Brogi Cc: Bhumika Goyal , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging: rtl8192u: Convert __le16 to cpu before casting to u32 Message-ID: <20170512080835.GB15405@kroah.com> References: <20170325232414.bqqgsm74wjvkcky4@nexon> <20170408103125.GA19569@kroah.com> <20170408183236.2zgiedzu3jjffdb5@nexon> <20170507125636.nsmrgob5s4ctf3i7@nexon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170507125636.nsmrgob5s4ctf3i7@nexon> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 07, 2017 at 02:56:36PM +0200, Guillaume Brogi wrote: > On Sat, Apr 08, 2017 at 08:32:36PM +0200, Guillaume Brogi wrote: > > On Sat, Apr 08, 2017 at 12:31:25PM +0200, Greg Kroah-Hartman wrote: > > > On Sun, Mar 26, 2017 at 12:24:14AM +0100, Guillaume Brogi wrote: > > > > > > > > This patch fixes the following sparse warnings: > > > > drivers/staging/rtl8192u/r8192U_dm.c:2307:49: warning: cast from restricted __le16 > > > > drivers/staging/rtl8192u/r8192U_dm.c:2308:44: warning: cast from restricted __le16 > > > > drivers/staging/rtl8192u/r8192U_dm.c:2309:44: warning: cast from restricted __le16 > > > > > > > > Those three members of qos_parameters are indeed __le16 so they should > > > > be converted to the cpu's endianness before being cast to u32. > > > > > > > > The lines are over the 80 character limit. They already were, and, for > > > > the sake of readability, I don't think they should be split. > > > > > > Please fix up your subject: line to match other patches for this driver, > > > I almost missed it :( > > > > > Sorry about that. I realised my mistake after sending the email. > > > > > > > > > > Signed-off-by: Guillaume Brogi > > > > --- > > > > drivers/staging/rtl8192u/r8192U_dm.c | 6 +++--- > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/drivers/staging/rtl8192u/r8192U_dm.c b/drivers/staging/rtl8192u/r8192U_dm.c > > > > index 9209aad0515e..5946c1f8d37d 100644 > > > > --- a/drivers/staging/rtl8192u/r8192U_dm.c > > > > +++ b/drivers/staging/rtl8192u/r8192U_dm.c > > > > @@ -2304,9 +2304,9 @@ static void dm_check_edca_turbo( > > > > /* For Each time updating EDCA parameter, reset EDCA turbo mode status. */ > > > > dm_init_edca_turbo(dev); > > > > u1bAIFS = qos_parameters->aifs[0] * ((mode&(IEEE_G|IEEE_N_24G)) ? 9 : 20) + aSifsTime; > > > > - u4bAcParam = (((u32)(qos_parameters->tx_op_limit[0])) << AC_PARAM_TXOP_LIMIT_OFFSET)| > > > > - (((u32)(qos_parameters->cw_max[0])) << AC_PARAM_ECW_MAX_OFFSET)| > > > > - (((u32)(qos_parameters->cw_min[0])) << AC_PARAM_ECW_MIN_OFFSET)| > > > > + u4bAcParam = (((u32)le16_to_cpu(qos_parameters->tx_op_limit[0])) << AC_PARAM_TXOP_LIMIT_OFFSET) | > > > > + (((u32)le16_to_cpu(qos_parameters->cw_max[0])) << AC_PARAM_ECW_MAX_OFFSET) | > > > > + (((u32)le16_to_cpu(qos_parameters->cw_min[0])) << AC_PARAM_ECW_MIN_OFFSET) | > > > > ((u32)u1bAIFS << AC_PARAM_AIFS_OFFSET); > > > > /*write_nic_dword(dev, WDCAPARA_ADD[i], u4bAcParam);*/ > > > > write_nic_dword(dev, EDCAPARA_BE, u4bAcParam); > > > > > > How are you sure that this change is correct? How did you verify it? > > > > > Sadly, I don't have the hardware to test that. I only checked the code > > and compiled it. > > > > > thanks, > > > > > Cheers, > > > Hello again, > > Since there was no news for a while, I figured I'd ask what's the status > of this patch. I hope that's OK. Has it simply been forgotten or is > there something blocking/unacceptable? I don't see it in my queue, sorry. If you can't test this, or verify that it is correct some other way, I don't want to take endian fixes, sorry. thanks, greg k-h