Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp1078974ybs; Mon, 25 May 2020 06:43:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9+dfTMxf3EzZw7CfwRPUNuSmYUtLds3dwh5TE0hIwu5oykUQ8mnoNL8dSQu90EZ6NP7Id X-Received: by 2002:a50:c60c:: with SMTP id k12mr15026694edg.111.1590414238233; Mon, 25 May 2020 06:43:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590414238; cv=none; d=google.com; s=arc-20160816; b=u5QodNIPjR4tRNNzDd05oLwqOpgxapVyF2etkhY6vVLvqO4lxqatl8k45j3Lt03ekM CJo7C2ird7sDHoPvQlJasiZKiRP57eqYIuYLsF5qJJIAofbqMUx8WUtEueHktJNRIikS g1PmZffC+MHYWbFUU4mcFOt9w8URWXJjuA5N4Gpb8+Ydwvfsjy0i5qrdBzLGtF/V5dsO c+ts4sZBNKQHTKZjyJLs1k15eNgqaOyFa+6M4H3URDED6eu2zI4+eKs+JnLc24UyAkzn 4mx9WiZgDspgTJny8OxpKm+ui5qqi9+cgZQJ3rQHofQi3uLi9o6wMNCW7pOPLAQijZz8 zLYw== 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=77dbRbbLSN3c5eG823ZO64JgoNfpxn+G88ZUO66wNQI=; b=SWJ/pqiENJzDsQMaolf+1GA33o6Pbd4ykQ3PO43CkT9zubyNVwRFWL1LHOeX+7BTYB Q3m+9Bt+me+B2Yoqzw6eJ4PWqJnSitB4RA1MkCZhBumWgybRsf2e4GKUocqQHjAXlstx suZNl9OBCkT3hWGBTn4l0RL1OQbDdzgG7DqqcDEvqiJhSjjkpkQKiuX8Ee3PN7oZMNYU hfqScuV8w8wJzlo5liuvyqGVq9MrmvDd7aiuyfEH6i4UkavHYw8J9Q9dkdN5MOEAGveU bldm3b8YVTQFUeNKreORWjupQZ+THjXNBGdWB0G7oxsFVZmWwhmdZBHtDBRVfmeyvfrv 8hqA== 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 t10si9472689edq.435.2020.05.25.06.43.27; Mon, 25 May 2020 06:43:58 -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 S2390795AbgEYNnX (ORCPT + 99 others); Mon, 25 May 2020 09:43:23 -0400 Received: from 8bytes.org ([81.169.241.247]:44546 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388794AbgEYNnV (ORCPT ); Mon, 25 May 2020 09:43:21 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 9FEF7327; Mon, 25 May 2020 15:43:19 +0200 (CEST) Date: Mon, 25 May 2020 15:43:18 +0200 From: Joerg Roedel To: Zhangfei Gao Cc: 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 Subject: Re: [PATCH 0/2] Let pci_fixup_final access iommu_fwnode Message-ID: <20200525134318.GB5221@8bytes.org> References: <1589256511-12446-1-git-send-email-zhangfei.gao@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1589256511-12446-1-git-send-email-zhangfei.gao@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 Tue, May 12, 2020 at 12:08:29PM +0800, Zhangfei Gao wrote: > Some platform devices appear as PCI but are > actually on the AMBA bus, and they need fixup in > drivers/pci/quirks.c handling iommu_fwnode. > So calling pci_fixup_final after iommu_fwnode is allocated. > > For example: > Hisilicon platform device need fixup in > drivers/pci/quirks.c > > +static void quirk_huawei_pcie_sva(struct pci_dev *pdev) > +{ > + struct iommu_fwspec *fwspec; > + > + pdev->eetlp_prefix_path = 1; > + fwspec = dev_iommu_fwspec_get(&pdev->dev); > + if (fwspec) > + fwspec->can_stall = 1; > +} > + > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva); I don't think it is a great idea to hook this into PCI_FIXUP_FINAL. The fixup list needs to be processed for every device, which will slow down probing. So either we introduce something like PCI_FIXUP_IOMMU, if this is entirely PCI specific. If it needs to be generic we need some fixup infrastructure in the IOMMU code itself. Regards, Joerg