Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1943690pxv; Fri, 2 Jul 2021 17:04:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCiZh8dUc31I4uaHZoC1y7ibHWH6ou6qr7hxlOx8qrx0PUxWjpWBeklExOUgu2HhjAANMn X-Received: by 2002:a6b:8f4b:: with SMTP id r72mr1833360iod.183.1625270658875; Fri, 02 Jul 2021 17:04:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625270658; cv=none; d=google.com; s=arc-20160816; b=QLlZWkaGz9fjYVQQb0jx9RMLVfQbzcEkmWoXhTbkzJ3Ip89s9QjpMvuGD+f37AifzN smOu4bhGpXg+a17/li9HD4N7l09GtVX9FSGtdrbEvObHAQPT3YFImpbgRxckG5r8y//V Synto3AIywMGYiwuSd98a6MduX3rtVISS4mUUj1pyTF2RTcuCBCDRKJ+No9Zzh7XNYEL ofzMyK1UDkc92bZaRGADI1rcERE39/GNAX0ZZ/9pg2xSCsANwA5CYjEispYSFyouGguy GDznhVs1ighMC9w1sNnOCA7SpJwus64UoLwUKw2jO6JMi0W1LYLz6BD6gCY0xzKhBqKa 6a+w== 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:date:from:dkim-signature; bh=zLdbz+KNKw9C/s+UQg9D2c39mkDMgDODryRHEG/G82M=; b=tmjVayWXT+AEFW2wCf89fh1GSmczQQZBHF5VNI5HOOKfIZ0EnEP0Qo8lyvPzNs17tg 9Edv9FNKS6Jw9EfJmmmK/hsdepOFeos0p3Lf1H09ouscr3S9VCt0ubNSNCcGtVq8oa84 ZLpqv4MhmYQcU6+Xdd/AMS1SMWXNgsZPcAul3dBYcJAAdOlw8xnpXXpe1Z7vvxyGcFvx o4oAItiGqrdn78PCJ+D8sc2m0CvZvXG/bVU8X7H56fX2z76dwk8wXee9JMTiqka2Tzfy 48KnQ1toW8NlDse9PKxq6/t/YLGzX7e9/tXO44/VTE4J9hM2I13oJYygo8qjR3HPvpM4 GmUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LwIRYO0P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id z4si4595251ilo.41.2021.07.02.17.04.06; Fri, 02 Jul 2021 17:04:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LwIRYO0P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S230127AbhGCAC7 (ORCPT + 99 others); Fri, 2 Jul 2021 20:02:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230017AbhGCAC6 (ORCPT ); Fri, 2 Jul 2021 20:02:58 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4866DC061762; Fri, 2 Jul 2021 17:00:26 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id d12so11430416pgd.9; Fri, 02 Jul 2021 17:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zLdbz+KNKw9C/s+UQg9D2c39mkDMgDODryRHEG/G82M=; b=LwIRYO0PPgUIWAquYY8ces1Lo5AOOwxoJysiMqJ+rjZyGg7w7Ao+0dMA8KSfoZfGc5 6Oo5YcN7fF0sVh6fupTmApnNdpAGn0YuYpHa3RdeQ9HLQtFmhKFA3f737hiIjh27Ij9W owDAfDx429O+hOGvZlaLFR5Gkd4rsw2ghLWiFb4HPFKGswr0TqZDMdTWh+D6pXzBIzC7 TJ9RTXC3Xzp9hMEp4/8lV4iOgbNyczTGxqFceZe6SCY88tHvesGZii0SoTh/P5FCHODa F2OjEMox6EmIGtzQ+Ffmxx62uJ3YQeVAGZmu5Hho5VHRcvFY4uTXVB2IrttX3BrbRW5b 2TKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zLdbz+KNKw9C/s+UQg9D2c39mkDMgDODryRHEG/G82M=; b=AA6yxv0EfJVuS8nt5BGcYAlqDXQ4QaEIuuCMAVQHS5GsiqrxSAMpTJIXmEbHAsirq4 LjQb9+KgkVd6/WBm47vQx7WMPWuIzNO+7XJPTFF3GdP8Hjai4Rk2RGbf4DXiAP3rfydf JxI+KxpNqXQ4++bTDudbBM3YjhJKOlQZvzSHxjgc8hwJu4UQG4uLazxpJCUEED8h6LOQ HrgutMBctc3KfCuMo/Jr1uXSapnIfWZGokHSFtW7HCeWHduypVWglpVbsJQX8S67U/zm ct2hG9wwrcANaKMRG4xRBLzmvhCh5RbBgIQQkf3JaCs1JMAB+WGqOHdSW6TF47MS+u5M vHQQ== X-Gm-Message-State: AOAM532f4UcYYlq6Lsp+4duYpPbWQ+ApVKV5HlHWDTbVIHW8mKpLBfN+ ktAgR7roFBIKSh97IY9gHQc= X-Received: by 2002:a63:7d5:: with SMTP id 204mr2416568pgh.309.1625270425816; Fri, 02 Jul 2021 17:00:25 -0700 (PDT) Received: from localhost ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id 20sm3597615pfu.5.2021.07.02.17.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jul 2021 17:00:24 -0700 (PDT) From: Coiby Xu X-Google-Original-From: Coiby Xu Date: Sat, 3 Jul 2021 07:56:29 +0800 To: Joe Perches Cc: Dan Carpenter , linux-staging@lists.linux.dev, netdev@vger.kernel.org, Benjamin Poirier , Shung-Hsi Yu , Manish Chopra , "supporter:QLOGIC QLGE 10Gb ETHERNET DRIVER" , Greg Kroah-Hartman , open list Subject: Re: [RFC 13/19] staging: qlge: rewrite do while loop as for loop in qlge_sem_spinlock Message-ID: <20210702235629.k2k2q7b2lxzw4kzd@Rk> References: <20210621134902.83587-1-coiby.xu@gmail.com> <20210621134902.83587-14-coiby.xu@gmail.com> <20210622072036.GK1861@kadam> <20210624112245.zgvkcxyu7hzrzc23@Rk> <20210630233338.2l34shhrm3bdd4gx@Rk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 30, 2021 at 09:35:31PM -0700, Joe Perches wrote: >On Thu, 2021-07-01 at 07:33 +0800, Coiby Xu wrote: >> On Wed, Jun 30, 2021 at 03:58:06AM -0700, Joe Perches wrote: >> > On Thu, 2021-06-24 at 19:22 +0800, Coiby Xu wrote: >> > > On Tue, Jun 22, 2021 at 10:20:36AM +0300, Dan Carpenter wrote: >> > > > On Mon, Jun 21, 2021 at 09:48:56PM +0800, Coiby Xu wrote: >> > > > > Since wait_count=30 > 0, the for loop is equivalent to do while >> > > > > loop. This commit also replaces 100 with UDELAY_DELAY. >> > [] >> > > > > diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c >> > [] >> > I also think using UDELAY_DELAY is silly and essentially misleading >> > as it's also used as an argument value for mdelay >> > >> > $ git grep -w UDELAY_DELAY >> > drivers/staging/qlge/qlge.h:#define UDELAY_DELAY 100 >> > drivers/staging/qlge/qlge_main.c: udelay(UDELAY_DELAY); >> > drivers/staging/qlge/qlge_main.c: udelay(UDELAY_DELAY); >> > drivers/staging/qlge/qlge_mpi.c: mdelay(UDELAY_DELAY); >> > drivers/staging/qlge/qlge_mpi.c: mdelay(UDELAY_DELAY); >> > drivers/staging/qlge/qlge_mpi.c: mdelay(UDELAY_DELAY); /* 100ms */ >> >> Thanks for spotting this issue! How about "#define MDELAY_DELAY 100" for >> mdelay? > >I think the define is pointless and it'd be more readable >to just use 100 in all the cases. > >IMO: There really aren't enough cases to justify using defines. I thought magic number should be avoided if possible. This case is new to me. Thanks for the explanation! > > -- Best regards, Coiby