Hi Baolu,
> -邮件原件-
> 发件人: Lu Baolu [mailto:baolu...@linux.intel.com]
> 发送时间: 2020年1月9日 16:53
> 收件人: Christoph Hellwig
> 抄送: baolu...@linux.intel.com; Joerg Roedel ; Roland
> Dreier ; Jim,Yan ;
> iommu@lists.linux-foundation.org
> 主题: Re: [PATCH 22/22] iomm
On 1/9/20 3:06 PM, Christoph Hellwig wrote:
On Thu, Jan 09, 2020 at 07:28:41AM +0800, Lu Baolu wrote:
This patch has been replaced with this one.
https://lkml.org/lkml/2020/1/5/103
That still mentions a "nvme host device", which despite the different
spelling still doesn't make any sense.
On Thu, Jan 09, 2020 at 07:28:41AM +0800, Lu Baolu wrote:
> This patch has been replaced with this one.
>
> https://lkml.org/lkml/2020/1/5/103
That still mentions a "nvme host device", which despite the different
spelling still doesn't make any sense.
> Are you willing to add your reviewed-by for Jim's v2 patch? I will
> queue it for v5.6 if you both agree.
Sure:
Reviewed-by: Roland Dreier
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Christoph,
On 1/8/20 10:16 PM, Christoph Hellwig wrote:
+/*
+ * We expect devices with endpoint scope to have normal PCI
+ * headers, and devices with bridge scope to have bridge PCI
+ * headers. However some PCI devices may be listed in the
+ * DMAR table with bridge scope, even though
> +/*
> + * We expect devices with endpoint scope to have normal PCI
> + * headers, and devices with bridge scope to have bridge PCI
> + * headers. However some PCI devices may be listed in the
> + * DMAR table with bridge scope, even though they have a
> + * normal PCI header. We don't declare a
Hi,
On 1/7/20 9:30 AM, Jerry Snitselaar wrote:
On Tue Jan 07 20, Lu Baolu wrote:
Hi Jerry,
On 1/7/20 1:05 AM, Jerry Snitselaar wrote:
On Wed Jan 01 20, Roland Dreier via iommu wrote:
We saw more devices with the same mismatch quirk. So maintaining
them in
a quirk table will make it more
On Tue Jan 07 20, Lu Baolu wrote:
Hi Jerry,
On 1/7/20 1:05 AM, Jerry Snitselaar wrote:
On Wed Jan 01 20, Roland Dreier via iommu wrote:
We saw more devices with the same mismatch quirk. So maintaining them in
a quirk table will make it more readable and maintainable.
I guess I disagree
Hi Jerry,
On 1/7/20 1:05 AM, Jerry Snitselaar wrote:
On Wed Jan 01 20, Roland Dreier via iommu wrote:
We saw more devices with the same mismatch quirk. So maintaining them in
a quirk table will make it more readable and maintainable.
I guess I disagree about the maintainable part, given that
On Wed Jan 01 20, Roland Dreier via iommu wrote:
We saw more devices with the same mismatch quirk. So maintaining them in
a quirk table will make it more readable and maintainable.
I guess I disagree about the maintainable part, given that this patch
already regresses Broadwell NTB.
I'm not
Hi Jim,
On 1/5/20 12:52 AM, Roland Dreier wrote:
Jim proposed another solution.
https://lkml.org/lkml/2019/12/23/653
Does this work for you?
Yes, that's OK for the cases I've seen too. All the NTB devices I've
seen are PCI_CLASS_BRIDGE_OTHER with type 0 headers, so this patch
would not
> Jim proposed another solution.
>
> https://lkml.org/lkml/2019/12/23/653
>
> Does this work for you?
Yes, that's OK for the cases I've seen too. All the NTB devices I've
seen are PCI_CLASS_BRIDGE_OTHER with type 0 headers, so this patch
would not break anything. And I think the idea of
Hi Roland,
Jim proposed another solution.
https://lkml.org/lkml/2019/12/23/653
Does this work for you?
Best regards,
baolu
On 1/2/20 10:25 AM, Roland Dreier wrote:
We saw more devices with the same mismatch quirk. So maintaining them in
a quirk table will make it more readable and
Hi,
On 1/2/20 10:25 AM, Roland Dreier wrote:
We saw more devices with the same mismatch quirk. So maintaining them in
a quirk table will make it more readable and maintainable.
I guess I disagree about the maintainable part, given that this patch
already regresses Broadwell NTB.
I'm not even
> We saw more devices with the same mismatch quirk. So maintaining them in
> a quirk table will make it more readable and maintainable.
I guess I disagree about the maintainable part, given that this patch
already regresses Broadwell NTB.
I'm not even sure what the DMAR table says about NTB on
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2f0d, /* NTB devices */
> +quirk_dmar_scope_mismatch);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2020, /* NVME host */
> +quirk_dmar_scope_mismatch);
what's the motivation for changing
Hi,
On 1/2/20 10:11 AM, Roland Dreier wrote:
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2f0d, /* NTB devices */
+quirk_dmar_scope_mismatch);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2020, /* NVME host */
+
We expect devices with endpoint scope to have normal PCI headers,
and devices with bridge scope to have bridge PCI headers. However,
some PCI devices may be listed in the DMAR table with bridge scope,
even though they have a normal PCI header. Add a quirk flag for
those special devices.
Cc:
18 matches
Mail list logo
