On Sun Jan 05 20, jimyan wrote:
On a system with an Intel PCIe port configured as a nvme host device, iommu
initialization fails with
DMAR: Device scope type does not match for :80:00.0
This is because the DMAR table reports this device as having scope 2
(ACPI_DMAR_SCOPE_TYPE_BRIDGE):
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 Mon, Dec 16, 2019 at 09:37:50AM -0700, Jordan Crouse wrote:
> Refactor how address space initialization works. Instead of having the
> address space function create the MMU object (and thus require separate but
> equal functions for gpummu and iommu) use a single function and pass the
> MMU
On Tue, Dec 24, 2019 at 08:27:28AM +0530, smase...@codeaurora.org wrote:
> On 2019-12-16 22:07, Jordan Crouse wrote:
> >Attempt to enable split pagetables if the arm-smmu driver supports it.
> >This will move the default address space from the default region to
> >the address range assigned to
On Sun, 5 Jan 2020 18:45:05 +0800, Chao Hao wrote:
> This patch adds description for MT6779 IOMMU.
>
> MT6779 has two iommus, they are MM_IOMMU and APU_IOMMU which
> use ARM Short-Descriptor translation format.
>
> The MT6779 IOMMU hardware diagram is as below, it is only a brief
> diagram about
> On Jan 6, 2020, at 1:19 PM, Robin Murphy wrote:
>
> Fair enough... I guess this is a W=1 thing?
Yes.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 06/01/2020 3:27 pm, Qian Cai wrote:
The commit c18647900ec8 ("iommu/dma: Relax locking in
iommu_dma_prepare_msi()") introduced a compliation warning,
drivers/iommu/dma-iommu.c: In function 'iommu_dma_prepare_msi':
drivers/iommu/dma-iommu.c:1206:27: warning: variable 'cookie' set but
not used
On 01/01/2020 1:54 am, David Rientjes via iommu wrote:
Christoph, Thomas, is something like this (without the diagnosic
information included in this patch) acceptable for these allocations?
Adding expansion support when the pool is half depleted wouldn't be *that*
hard.
Or are there
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
Hello people,
since the introduction of the bounce buffer, a regression with TB3 devices has
been introduced.
USB devices attached to TB3 refuse to work since. Removing the commits that
introduced the bounce buffer, fixes the issue.
Commits:
3b53034c268d550d9e8522e613a14ab53b8840d8
The commit c18647900ec8 ("iommu/dma: Relax locking in
iommu_dma_prepare_msi()") introduced a compliation warning,
drivers/iommu/dma-iommu.c: In function 'iommu_dma_prepare_msi':
drivers/iommu/dma-iommu.c:1206:27: warning: variable 'cookie' set but
not used [-Wunused-but-set-variable]
struct
On 04/01/2020 12:20 am, Brian Masney wrote:
When attempting to load the qcom-iommu driver, and an -EPROBE_DEFER
error occurs, the following attempted NULL pointer deference occurs:
Unable to handle kernel NULL pointer dereference at virtual address
0014
pgd = (ptrval)
On Fri, Dec 20, 2019 at 05:13:13PM +0100, Joerg Roedel wrote:
> On Thu, Dec 19, 2019 at 12:03:36PM +, Will Deacon wrote:
> > Ard Biesheuvel (1):
> > iommu/arm-smmu: Support SMMU module probing from the IORT
> >
> > Greg Kroah-Hartman (1):
> > PCI/ATS: Restore EXPORT_SYMBOL_GPL() for
> On Dec 20, 2019, at 10:13, Kai-Heng Feng wrote:
>
>
>
>> On Dec 20, 2019, at 03:15, Deucher, Alexander
>> wrote:
>>
>>> -Original Message-
>>> From: Kai-Heng Feng
>>> Sent: Wednesday, December 18, 2019 12:45 PM
>>> To: Joerg Roedel
>>> Cc: Christoph Hellwig ; Deucher,
16 matches
Mail list logo
