linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhangfei Gao <zhangfei.gao@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joerg Roedel <joro@8bytes.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	jean-philippe <jean-philippe@linaro.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	kenneth-lee-2012@foxmail.com, Wangzhou <wangzhou1@hisilicon.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-pci <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Wed, 27 May 2020 21:51:13 +0800	[thread overview]
Message-ID: <ec994862-ac1c-bb6e-4fe6-ce5bf74f614a@linaro.org> (raw)
In-Reply-To: <CAK8P3a35fjXt1F2hJygup5gWfjPHZTuU+VD69K5uzrNhhgu0Pw@mail.gmail.com>



On 2020/5/27 下午5:53, Arnd Bergmann wrote:
> On Wed, May 27, 2020 at 11:00 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
>>> Some platform devices appear as PCI but are actually on the AMBA bus,
>> Why would these devices not just show up on the AMBA bus and use all of
>> that logic instead of being a PCI device and having to go through odd
>> fixes like this?
> There is a general move to having hardware be discoverable even with
> ARM processors. Having on-chip devices be discoverable using PCI config
> space is how x86 SoCs usually do it, and that is generally a good thing
> as it means we don't need to describe them in DT
>
> I guess as the hardware designers are still learning about it, this is not
> always done correctly. In general, we can also describe PCI devices on
> DT and do fixups during the probing there, but I suspect that won't work
> as easily using ACPI probing, so the fixup is keyed off the hardware ID,
> again as is common for x86 on-chip devices.
>
>   
Yes, thanks Arnd :)

In order to use pasid, io page fault has to be supported,
either by PCI PRI feature (from pci device) or stall mode from smmu 
(platform device).
Here is letting system know the platform device can support smmu stall 
mode, as a result support pasid.
While stall is not a pci capability, so we use a fixup here.

Thanks


  reply	other threads:[~2020-05-27 13:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 11:49 [PATCH 0/2] Introduce PCI_FIXUP_IOMMU Zhangfei Gao
2020-05-26 11:49 ` [PATCH 1/2] PCI: " Zhangfei Gao
2020-05-26 14:46   ` Christoph Hellwig
2020-05-26 15:09     ` Zhangfei Gao
2020-05-27  9:01       ` Greg Kroah-Hartman
2020-05-26 11:49 ` [PATCH 2/2] iommu: calling pci_fixup_iommu in iommu_fwspec_init Zhangfei Gao
2020-05-27  9:01   ` Greg Kroah-Hartman
2020-05-28  6:53     ` Zhangfei Gao
2020-05-27  9:00 ` [PATCH 0/2] Introduce PCI_FIXUP_IOMMU Greg Kroah-Hartman
2020-05-27  9:53   ` Arnd Bergmann
2020-05-27 13:51     ` Zhangfei Gao [this message]
2020-05-27 18:18 ` Bjorn Helgaas
2020-05-28  6:46   ` Zhangfei Gao
2020-05-28  7:33   ` Joerg Roedel
2020-06-01 17:41     ` Bjorn Helgaas
2020-06-04 13:33       ` Zhangfei Gao
2020-06-05 23:19         ` Bjorn Helgaas
2020-06-08  2:54           ` Zhangfei Gao
2020-06-08 16:41             ` Bjorn Helgaas
2020-06-09  4:01               ` Zhangfei Gao
2020-06-09  9:15                 ` Arnd Bergmann
2020-06-09 16:49                   ` Bjorn Helgaas
2020-06-11  2:54                     ` Zhangfei Gao
2020-06-11 13:44                       ` Bjorn Helgaas
2020-06-13 14:30                         ` Zhangfei Gao
2020-06-15 23:52                           ` Bjorn Helgaas
2020-06-19  2:26                             ` Zhangfei Gao
2020-06-23 15:04                               ` Bjorn Helgaas
2020-12-16 11:24                                 ` Zhou Wang
2020-12-17 20:38                                   ` Bjorn Helgaas
2020-06-22 11:55         ` Joerg Roedel
2020-06-23  7:48           ` Zhangfei Gao
2020-06-22 11:53       ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec994862-ac1c-bb6e-4fe6-ce5bf74f614a@linaro.org \
    --to=zhangfei.gao@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kenneth-lee-2012@foxmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=wangzhou1@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).