Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp1209722rwi; Thu, 3 Nov 2022 02:28:17 -0700 (PDT) X-Google-Smtp-Source: AMsMyM54n4/rdmQyZNtXy/3En/WKH2agyR6L+LLMPeSt3dZoM9c60+rwcS4ATatn0TfbHek/7YKi X-Received: by 2002:a05:6a00:1810:b0:56b:f29d:cc8e with SMTP id y16-20020a056a00181000b0056bf29dcc8emr28937992pfa.33.1667467696998; Thu, 03 Nov 2022 02:28:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667467696; cv=none; d=google.com; s=arc-20160816; b=pC9Iei9lLH+aZxeCe//SrRLGxlSK8LA12SRdsPAH4VVrcGNPT4zCy8dt4/ZX6TGxnn q0rq0uEiF7T0wFFnP877Y7JtTB0qrZrzY0s+2A7S3R3M/lNHM7SnWy1vZwrzh3Xiel38 aP1SXsMrUG/f72rPz/1eiBOmmcYNJplPTh2cTPLbNWjVgpYwE8SPn0AXLAOY6eOyJDqY JsRDEWYctrlGVvjD4zPU68SzL8V1GMtsBE9YWZ5t90nLn5e04oVX19KBMlqy1Qksdq9R XVZmwDRhgBmBzVfxmT0voUhVAjS+N8PKR/JSBiredi3PjYxd/NtO6wLH/Hi6kWQGMNbu iwmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=DRziaAI4jAVyQiwlHi+270n8gvjWGj93mCgZnk1wbCI=; b=KqBBughOOvLiDBJsWcLQePuwrslK/5+4pD9FlYmfE4GFNtkmTwb9uFG5jC6vXrE2Yr omi4JGKt40twqtlsgvhw2wqDt8XMSShfUmAeEqOgI0MYSdHJ1qDqr1Il2AthsFgdokUp m/IA5ILpOl1YXCTPQDnihEEhrBGJXCOt7251sZrDV2jR6Ta0mjGcQNwMpfZbXLValqFd cahhr72muWfD/m98Gjo5iiDuBYlJVbTg7lHT3ykysXhFC+Eb/lQSO/2XFBua0tBtwDJO MekqZvDyilt0ecjBt6LKWa3RIlFqOlTK/RVSpfESEQF1CxyS6EI+7pWiPXVxNjZQ38c9 m1WA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=EeZejlVQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hk11-20020a17090b224b00b00213a3a2a09csi6004364pjb.159.2022.11.03.02.28.04; Thu, 03 Nov 2022 02:28:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=EeZejlVQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230521AbiKCJTy (ORCPT + 97 others); Thu, 3 Nov 2022 05:19:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230075AbiKCJTZ (ORCPT ); Thu, 3 Nov 2022 05:19:25 -0400 Received: from msg-2.mailo.com (msg-2.mailo.com [213.182.54.12]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46F94DF68 for ; Thu, 3 Nov 2022 02:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1667467121; bh=1FFyeCB1hsvWSZFVl4Cqf8cr/xeMPMTwxPelch+HVkI=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=EeZejlVQ/tZqrGfYydi+VCs7I1D4NSzQRoumLgidzbI2cgsVeO7/PKStGXl6eCgfa c30K5t4HuvvqAW+06jcpqOliI5EnwlGIjSBwbpaZl/T3Zh459MBN/XCTcHhbhnQ1lT o5sMCt3OmN8D9q86F15gVi/XOZ2KWKJPIzTXpG/8= Received: by b-1.in.mailobj.net [192.168.90.11] with ESMTP via [213.182.55.206] Thu, 3 Nov 2022 10:18:41 +0100 (CET) X-EA-Auth: lRmrKz4m7pPIlT6G9wgNSAXAl/QL4q8IeqYV3yT3ly6KzkRBk4KKck/th0wDBHggEFJP7QaLRArA0ckubZhz+ziq/dVwzlM2 Date: Thu, 3 Nov 2022 14:48:35 +0530 From: Deepak R Varma To: Dan Carpenter Cc: David Laight , "outreachy@lists.linux.dev" , Greg Kroah-Hartman , "linux-staging@lists.linux.dev" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] staging: rtl8192e: Use min_t/max_t macros for variable comparison Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 03, 2022 at 11:53:45AM +0300, Dan Carpenter wrote: > On Thu, Nov 03, 2022 at 08:24:15AM +0000, David Laight wrote: > > > --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c > > > +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c > > > @@ -587,17 +587,12 @@ void HTOnAssocRsp(struct rtllib_device *ieee) > > > else > > > pHTInfo->CurrentAMPDUFactor = HT_AGG_SIZE_64K; > > > } else { > > > - if (pPeerHTCap->MaxRxAMPDUFactor < HT_AGG_SIZE_32K) > > > - pHTInfo->CurrentAMPDUFactor = > > > - pPeerHTCap->MaxRxAMPDUFactor; > > > - else > > > - pHTInfo->CurrentAMPDUFactor = HT_AGG_SIZE_32K; > > > + pHTInfo->CurrentAMPDUFactor = min_t(u32, pPeerHTCap->MaxRxAMPDUFactor, > > > + HT_AGG_SIZE_32K); > > > > For min() to fail there must be a signed v unsigned mismatch. > > Maybe that ought to be fixed. > > > > u32 is the right choice here. > > I'm having a hard time understanding your email. You might be saying > we could declare HT_AGG_SIZE_32K as a u32 so then we could use min() > instead of min_t()? HT_AGG_SIZE_32K is an enum. > > pPeerHTCap->MaxRxAMPDUFactor is a bitfield. > > u8 MaxRxAMPDUFactor:2; > > We will never be able to use min(). I think we could do min((u32)a, (u32)b), but it is just unwrapped min_t if I understand David's comment. > > > > } > > > } > > > - if (pHTInfo->MPDU_Density > pPeerHTCap->MPDUDensity) > > > - pHTInfo->current_mpdu_density = pHTInfo->MPDU_Density; > > > - else > > > - pHTInfo->current_mpdu_density = pPeerHTCap->MPDUDensity; > > > + pHTInfo->current_mpdu_density = max_t(u8, pHTInfo->MPDU_Density, > > > + pPeerHTCap->MPDUDensity); > > > > Using u8 with max_t() really doesn't make any sense. > > Using u8 looks wrong because you would worry that one of the types is > larger than U8_MAX. But it's actually fine. The types are u8 vs another > bitfield. I would probably have gone with u32 here as well. I will take your advise and upgrade the type to u32 as a revision. > > > The value will get promoted to signed int prior to the comparison. > > > > That's sort of true-ish but I don't understand what you are saying? > #confused Yes, I too did not understand David's comment. I tried to dig dipper into max_t but it gets very complex. Can you please elaborate how you determined the promotion to signed int? > > regards, > dan carpenter > >