Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp5646891rwb; Wed, 9 Aug 2023 07:18:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE2OFx+/uIxXlgwFuAXz5YkYeM1JYVzs2wR0qzTxhXqPCAD4+jy/oK9asiL6dqOAcXhRxDS X-Received: by 2002:aa7:c542:0:b0:522:d6f4:c0e9 with SMTP id s2-20020aa7c542000000b00522d6f4c0e9mr2467556edr.38.1691590731856; Wed, 09 Aug 2023 07:18:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691590731; cv=none; d=google.com; s=arc-20160816; b=k3SX05SX6x6+pH9584yorr55SOubRMe6lbeM/BhMW9XrRVkqrlHkDxw6Td20TlXSiC A2WOSAsW/Pvv6PiucesCDRZ+imWO3phKCgSE6yQze5Ly0I2zH7pc7SsBK7BSR1+ia1qU U7e/6ZpkSnhGZ06VA4iIMaqt7ls/k3W3nmhWaeSa9VfyRq1ZJtrzMWtlAwKi73fwgKwz RsuG4/60X+u6Lu0p2OYh+sbHjcBEP/rajwd+YS6DFYmZox1LnMGBIEVIs7PuzJ3fXl7M 083NYj1pNzg12I5MwmH0iyxozk/TgExa36obk+oeN/dwX3y7DSwfBdaXrHS0wQxG3zQI MRgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=zy+x/SBeO8LkeYoDJLA84I+rEdcG+ek+MHSEVjjSAsc=; fh=/Dj2E+A0ygXa2hIEZGOCQ+TmuXwB36RPKrEHI4a9Kdw=; b=jUPEtDnD0Z2XxPTzTDY/ABoYRegjjWNraI2Am6UeXqfhHJNuD3f+sbDyL8zu/nIwjf INY5bRXjmEqlGI3CO/E1aL+RvXRHK1ddA5gR2vChKf1LjhQKEw2Ka0OpVhwdPr0juMQM JzRxKn3l71EzTNcxIssAkHfi2bLtVaxRTYCn7OSjJ+89PinweYGdMupn0X950AJuFplP 64tfkxMy+I0/msUjxEuDpg15S7i8fixxhYYaIoQEvsEv/gpc8kEbv6aEWDf/QAoq8kuz Q+WfK/gZLuXfIkA52ujCsWftXr4cMND1A1nrmSuyp5IIm2yjG6FdMSTr2yGjQdBzYWoQ Tj8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Qg0+2Nep; 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=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x20-20020aa7dad4000000b005232e465f74si5975801eds.595.2023.08.09.07.18.22; Wed, 09 Aug 2023 07:18:51 -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=pass header.i=@intel.com header.s=Intel header.b=Qg0+2Nep; 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=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232422AbjHINzo (ORCPT + 99 others); Wed, 9 Aug 2023 09:55:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231719AbjHINzk (ORCPT ); Wed, 9 Aug 2023 09:55:40 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 748A72109; Wed, 9 Aug 2023 06:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691589339; x=1723125339; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=gJzCp6ekx7CCevIM8uCATPGn/y4r8KOXNfeq4gNJ+QM=; b=Qg0+2Nep+LaeHsWEXoTUyECVQGp/Eyy1eQLr7qzNRBwX4iRVUngxLudL ICBnlAlAVPMuXrp0aBxFR8JAntGf5xxTJ9rZObs5ogZyl5hj/qNVZt+CR 90/H6M781soOAnKJHO4aindbjK1W6qm2daOEovl75Dhx48AB+9Lp739QB 0x4HFsFVLiROi3ieB3fqMqN/lnVP0w2J6LCGqHCNF5THGxyz6sEiRz3N0 Low51pM6/sFwSJSBFEEkNgnCsv3CmTfwC8hE2bzvxOACmoFu2rrIbzHoG x6imQVQingK30rZRBcy1NQPa330R16r+EfZ7Oj1BfPoGz7u8FCiNnsTCQ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="370029111" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="370029111" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 06:55:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="845966693" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="845966693" Received: from cvogler-mobl1.ger.corp.intel.com ([10.252.40.229]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 06:55:23 -0700 Date: Wed, 9 Aug 2023 16:55:20 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Sui Jingfeng cc: Bjorn Helgaas , Dave Airlie , Daniel Vetter , linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org, LKML , Sui Jingfeng Subject: Re: [PATCH v2 05/11] PCI/VGA: Move the new_state assignment out of the loop In-Reply-To: <20230808223412.1743176-6-sui.jingfeng@linux.dev> Message-ID: References: <20230808223412.1743176-1-sui.jingfeng@linux.dev> <20230808223412.1743176-6-sui.jingfeng@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,URIBL_BLOCKED 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 Wed, 9 Aug 2023, Sui Jingfeng wrote: > From: Sui Jingfeng > > In the vga_arbiter_notify_clients() function, the value of the 'new_state' > variable will be 'false' on systems that have more than one VGA device. > The value will be 'true' if there is only one VGA device or no VGA device > at all. Hence, its value is not relevant to the iteration of the loop. > > So move the assignment clause out of the loop. For a system with multiple > video cards, this patch saves unnecessary assignment. > > Signed-off-by: Sui Jingfeng > --- > drivers/pci/vgaarb.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c > index dc10a262fb5e..6883067a802a 100644 > --- a/drivers/pci/vgaarb.c > +++ b/drivers/pci/vgaarb.c > @@ -1468,22 +1468,20 @@ static void vga_arbiter_notify_clients(void) > { > struct vga_device *vgadev; > unsigned long flags; > - uint32_t new_decodes; > - bool new_state; > + bool state; > > if (!vga_arbiter_used) > return; > > + state = (vga_count > 1) ? false : true; > + Is it safe to move this outside of the lock? This would be enough (no need for ?: construct): state = vga_count <= 1; Or if you want to keep it as > 1: state = !(vga_count > 1); > spin_lock_irqsave(&vga_lock, flags); > list_for_each_entry(vgadev, &vga_list, list) { > - if (vga_count > 1) > - new_state = false; > - else > - new_state = true; > if (vgadev->set_decode) { > - new_decodes = vgadev->set_decode(vgadev->pdev, > - new_state); > - vga_update_device_decodes(vgadev, new_decodes); > + unsigned int decodes; > + > + decodes = vgadev->set_decode(vgadev->pdev, state); > + vga_update_device_decodes(vgadev, decodes); > } > } > spin_unlock_irqrestore(&vga_lock, flags); > -- i.