From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 777DFEE4993 for ; Wed, 23 Aug 2023 14:15:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236185AbjHWOPe (ORCPT ); Wed, 23 Aug 2023 10:15:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236188AbjHWOPc (ORCPT ); Wed, 23 Aug 2023 10:15:32 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 461CAE57; Wed, 23 Aug 2023 07:15:30 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1692800128; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tC3legbKEgh6GaaSn5yn0aimdQy2CL6olThV+is3i/s=; b=sRRyH1OEK1xpWU6ptY+xbUO0aV2vsPkBsmcJa6O4urXCbLGekvw7terr9WvATbiptHdkYf xt5yWFn6vPnZq61Oavlx5zIoX5KaSiqyIs6Trxn8rgn92dCTQRxKggCCP/J5flumSc2Mlf UBG6H4x1lwJMdidZ3o46qeqI6iHDlkPUG2F8TiH024VrILCJaBrQ1XMOVfK7x0uX7tDNHD DAbWJ5FL7R4vsisj4BwPYbO2yHkCPoofEKtxnx8fl5ZX9u4xtulo5QrAy4g9ofv6dFyKzE XkcWxyh5s22ZANx57zn1FadqYzi85hQRjRHxU9vHQV/l37T3PmTAvD9bkf5TBA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1692800128; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tC3legbKEgh6GaaSn5yn0aimdQy2CL6olThV+is3i/s=; b=MavnPf9nYe9evfczAehjxfX9HzO8oe/uGl9hyapHj2jdVIqagf2I/DQx6+MNEOJdt5Fmw2 eVxr+alc9JcjDhDw== To: =?utf-8?B?6buE5bCR5rOi?= , Bjorn Helgaas , "Ahmed S. Darwish" , Jason Gunthorpe , Kevin Tian , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: =?utf-8?B?5p2O6auY6bmP?= , =?utf-8?B?5qKB5Lyf?= =?utf-8?B?6bmP?= , =?utf-8?B?57+B6YeR6aOe?= , =?utf-8?B?54aK5Lqu?= Subject: Re: Subject: [PATCH] pci/msi: remove redundant calculation in msi_setup_msi_desc In-Reply-To: <3ebf5d8032ad418da4f24516cd23406e@xiaomi.com> References: <3ebf5d8032ad418da4f24516cd23406e@xiaomi.com> Date: Wed, 23 Aug 2023 16:15:27 +0200 Message-ID: <87bkexetfk.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 18 2023 at 07:26, =E9=BB=84=E5=B0=91=E6=B3=A2 wrote: Your patch is corrupt: Applying: Subject: [PATCH] pci/msi: remove redundant calculation in msi_se= tup_msi_desc error: corrupt patch at line 12 It's DOS mangled and whitespace damaged. > Whether to support 64-bit address status has been calculated before, > and the calculation result can be used directly afterwards, so use > msi_attrib.is_64 to avoid double calculation. I'm not seeing what this solves: > - if (control & PCI_MSI_FLAGS_64BIT) > + if (desc.pci.msi_attrib.is_64) Both variants resolve to a test of a bit and a conditional instruction on the result. It's exactly zero difference in terms of "calculation". So all this does is change the memory location to test. Not more not less. It does not generate better code and does not save anything. Thanks, tglx