Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2693180ybt; Mon, 22 Jun 2020 04:54:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwoe/sr61FbzyIHsmPmtpDAgH93nYrPCGVGjfKrtQEiNHVC3MWttqSOAUYoF5x269hTlDpq X-Received: by 2002:a50:d9cb:: with SMTP id x11mr2082935edj.93.1592826885404; Mon, 22 Jun 2020 04:54:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592826885; cv=none; d=google.com; s=arc-20160816; b=knZ928rjuxveoj8qy9c+jcyxSIsrrRhx90LzQqc3LK+13LGGL2nqadbX+1th5cys5G lUb6tce5MOtAChCHlYjYxX1gnHjvGkjDA+xkpm1haT83gHBVEMSw3l2hjWwIohTIYyt7 W01pcUvxZbnsnVLCLTVRRbwyc63RMzs0F3WqXRGQDAXoTSt0ffJ/1sTU6tMaass2ZDya nlPTkhblmV63gMS1/wehkxup94n/6gj5fHUkzjcUA+cl1/pgNIa/eoDPwS2f0PWiIfAV YEEON/3swHvhI7+h9sqa8o6POrYukswKdJKEqehnP8g2ET343ge/Lp/d+O4KEtK2pb6X 4Dvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=mgWWxp198BCkQfkL/241xyHLi6SeAW0A2v41xuHmFZ8=; b=SKpeNSTShIJ2uLDUE8D9Nquh7sqsk+VPPR/TAfj+7RMeeYSQrd9JreZZ01zIi51D35 6t/wR99lTaJsv0UzsKJ2DipIn7MMl+PBgCMMH+HcXWUDcWK6H3uppgqA1LqIHEWJVAOH H5lFUtVTK5rPbdow4iYm9Xb6NO7B2o2hl59Aas23g6/SFvrqketEfPi0TNiyOPaUqfOt ktxLdV2nZ4OxYVQpDGOvAA9e7fEoiycS9t0UKEmDF33DJNmue0mhK83ZtdiS5Ybobmdh sHNg19EHH0E/lByWkBHDhoX2jmy+xqKUddew5CfVnUU2A8elkuBkXFUOsW498xYFmj25 3Opw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r12si1473363ejs.370.2020.06.22.04.54.12; Mon, 22 Jun 2020 04:54:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728101AbgFVLxz (ORCPT + 99 others); Mon, 22 Jun 2020 07:53:55 -0400 Received: from 8bytes.org ([81.169.241.247]:48348 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727048AbgFVLxz (ORCPT ); Mon, 22 Jun 2020 07:53:55 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id AA30A36B; Mon, 22 Jun 2020 13:53:49 +0200 (CEST) Date: Mon, 22 Jun 2020 13:53:48 +0200 From: Joerg Roedel To: Bjorn Helgaas Cc: Zhangfei Gao , Bjorn Helgaas , Arnd Bergmann , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , jean-philippe , Greg Kroah-Hartman , Herbert Xu , kenneth-lee-2012@foxmail.com, Wangzhou , linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU Message-ID: <20200622115347.GG3701@8bytes.org> References: <20200528073344.GO5221@8bytes.org> <20200601174104.GA734973@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200601174104.GA734973@bjorn-Precision-5520> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Jun 01, 2020 at 12:41:04PM -0500, Bjorn Helgaas wrote: > I found this [1] from Paul Menzel, which was a slowdown caused by > quirk_usb_early_handoff(). I think the real problem is individual > quirks that take a long time. > > The PCI_FIXUP_IOMMU things we're talking about should be fast, and of > course, they're only run for matching devices anyway. So I'd rather > keep them as PCI_FIXUP_FINAL than add a whole new phase. Okay, so if it is not a performance problem, then I am fine with using PCI_FIXUP_FINAL. But I dislike calling the fixups from IOMMU code, there must be a better solution. Regards, Joerg > [1] https://lore.kernel.org/linux-pci/b1533fd5-1fae-7256-9597-36d3d5de9d2a@molgen.mpg.de/