Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2694148ybt; Mon, 22 Jun 2020 04:56:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYr1Kcv+JXxYD/jOE+UInpzuN63FVgpyxpTDk4atXgoeNYz6E8C+SQNjDS2QtRf/ejBipF X-Received: by 2002:a17:906:9381:: with SMTP id l1mr15730392ejx.380.1592826975869; Mon, 22 Jun 2020 04:56:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592826975; cv=none; d=google.com; s=arc-20160816; b=0dAZNFUgqOvztlSGc88qxGWzaWq7eYaP3xInMH1V+ChqLa1auXhEp11FhGbRpTvm0i BQjuaYBHA6QwlGo0cR4t6DLLHaQiFGwpunRkXaIfT6nOUpPza981OyVATUOe+hKla1eN 0kVkwulwBWorVrcd8l6MNU6Okz8h7iLe8gf2gzgKsWH7RtRLNKZu7UVu+liDyjLQa3Cq Oh/fyYAmbB1/gt68ZJnm5yygBq5aSdvSS3IwntoqiN4IuUVtfLMnffMrCf28BoTlgGoA 7b40+deKXhPg+y/09p2OFQ05vx6MOVjbVLZqijwCKe1BURB+kI+7LIFoy3KN1D7zafq/ fkIQ== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=mbyFNWKcfavxhONCiungWtWY5T1ENWWoQdxyEHQia/s=; b=Vb5DvklqC0zWi3a9ayrqXwhHA8f3oFW4Vcmy2OvbhtJp3f5ZOf+Dqvq0xj2fCJZEH/ zm9JIMQhQrSMr6bKEK7PSdZYSiSgW+lt04MrYsvGqTxe/GWxl4QF2enTn8stCEtMTUPG ryuVZin1/khiohrwigtnup07QnxSWoqa7HVwg+q3fY6WJQw8AkApyCxPZInoajhmQ2Un KjGzTeCQAuKpgkGn1XWkCl+Em4aTgDtBg7tF9+JSG0ix2zEJ5JTfGvszoML+AhYa5nMZ dwmuAhRl4e/QrwLZOA7we6V9tBf3/LrAh8o39juSpaq/jiwG8HQ0SQXebwEBsklamQm2 yg1g== 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 cy5si1547244edb.554.2020.06.22.04.55.52; Mon, 22 Jun 2020 04:56:15 -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 S1727851AbgFVLzk (ORCPT + 99 others); Mon, 22 Jun 2020 07:55:40 -0400 Received: from 8bytes.org ([81.169.241.247]:48372 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727799AbgFVLzk (ORCPT ); Mon, 22 Jun 2020 07:55:40 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 746F636B; Mon, 22 Jun 2020 13:55:38 +0200 (CEST) Date: Mon, 22 Jun 2020 13:55:37 +0200 From: Joerg Roedel To: Zhangfei Gao Cc: Bjorn Helgaas , 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: <20200622115536.GH3701@8bytes.org> References: <20200601174104.GA734973@bjorn-Precision-5520> <779f4044-cf6a-b0d3-916f-0274450c07d3@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <779f4044-cf6a-b0d3-916f-0274450c07d3@linaro.org> 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 Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote: > +++ b/drivers/iommu/iommu.c > @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct > fwnode_handle *iommu_fwnode, > ??????? fwspec->iommu_fwnode = iommu_fwnode; > ??????? fwspec->ops = ops; > ??????? dev_iommu_fwspec_set(dev, fwspec); > + > +?????? if (dev_is_pci(dev)) > +?????????????? pci_fixup_device(pci_fixup_final, to_pci_dev(dev)); > + That's not going to fly, I don't think we should run the fixups twice, and they should not be run from IOMMU code. Is the only reason for this second pass that iommu_fwspec is not yet allocated when it runs the first time? I ask because it might be easier to just allocate the struct earlier then. Regards, Joerg