On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote:
> Remove SMMU shutdown callback since it seems to cause more
> problems than benefits. With this callback, we need to make
> sure that all clients/consumers of SMMU do not perform any
> DMA activity once the SMMU is shutdown and tr
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of 128
KiB on a 256 MiB system).
Fix this by correcting the calculation of the number of GiBs of RAM in
the system.
Fixes: 1d659236fb43c4d2 ("dma-pool: scale the de
Hi Will,
On 2020-06-08 13:48, Will Deacon wrote:
On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote:
Remove SMMU shutdown callback since it seems to cause more
problems than benefits. With this callback, we need to make
sure that all clients/consumers of SMMU do not perform any
On 2020-06-08 10:13, Sai Prakash Ranjan wrote:
Hi Will,
On 2020-06-08 13:48, Will Deacon wrote:
On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote:
Remove SMMU shutdown callback since it seems to cause more
problems than benefits. With this callback, we need to make
sure that a
On Mon, Jun 08, 2020 at 02:43:03PM +0530, Sai Prakash Ranjan wrote:
> On 2020-06-08 13:48, Will Deacon wrote:
> > On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote:
> > > Remove SMMU shutdown callback since it seems to cause more
> > > problems than benefits. With this callback, we
On 2020-06-08 09:52, Geert Uytterhoeven wrote:
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of 128
KiB on a 256 MiB system).
Fix this by correcting the calculation of the number of GiBs of RAM in
the system.
Hi Robin,
On Mon, Jun 8, 2020 at 2:04 PM Robin Murphy wrote:
> On 2020-06-08 09:52, Geert Uytterhoeven wrote:
> > On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
> > memory pools are much larger than intended (e.g. 2 MiB instead of 128
> > KiB on a 256 MiB system).
> >
> > F
On 2020-06-08 13:25, Geert Uytterhoeven wrote:
Hi Robin,
On Mon, Jun 8, 2020 at 2:04 PM Robin Murphy wrote:
On 2020-06-08 09:52, Geert Uytterhoeven wrote:
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of 12
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of 128
KiB on a 256 MiB system).
Fix this by correcting the calculation of the number of GiBs of RAM in
the system. Invert the order of the min/max operations, to k
Hi Robin,
On 2020-06-08 16:56, Robin Murphy wrote:
On 2020-06-08 10:13, Sai Prakash Ranjan wrote:
Hi Will,
On 2020-06-08 13:48, Will Deacon wrote:
On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote:
Remove SMMU shutdown callback since it seems to cause more
problems than bene
Hi Will,
On 2020-06-08 17:08, Will Deacon wrote:
On Mon, Jun 08, 2020 at 02:43:03PM +0530, Sai Prakash Ranjan wrote:
On 2020-06-08 13:48, Will Deacon wrote:
> On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote:
> > Remove SMMU shutdown callback since it seems to cause more
> > p
On Thu, Jun 04, 2020 at 02:39:04PM -0600, Jordan Crouse wrote:
> When CONFIG_OF=n of_match_device() gets pre-processed out of existence
> leaving qcom-smmu_client_of_match unused. Mark it as possibly unused to
> keep the compiler from warning in that case.
>
> Fixes: 0e764a01015d ("iommu/arm-smmu:
Hi Andy,
On Sun, Jun 7, 2020 at 12:500f9bfe0fb8840b268af1bbcc51f1cd440514e PM
Andy Shevchenko wrote:
>
> On Fri, Jun 05, 2020 at 05:26:48PM -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of single or multiple pfn offsets between
Hi Linus,
The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162:
Linux 5.7 (2020-05-31 16:49:15 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-updates-v5.8
for you to fetch changes up to 431275af
On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:
> On 2020/6/6 上午7:19, Bjorn Helgaas wrote:
> > On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:
> > > On 2020/6/2 上午1:41, Bjorn Helgaas wrote:
> > > > On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:
> > > > > O
The pull request you sent on Mon, 8 Jun 2020 18:05:07 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-updates-v5.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4e3a16ee9148e966678bbc713579235422271a63
Thank you!
--
Deet-doot-dot
On Mon, 8 Jun 2020, Geert Uytterhoeven wrote:
> On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
> memory pools are much larger than intended (e.g. 2 MiB instead of 128
> KiB on a 256 MiB system).
>
> Fix this by correcting the calculation of the number of GiBs of RAM in
> th
From: Alexander Monakov
[ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ]
IVRS parsing code always tries to read 255 bytes from memory when
retrieving ACPI device path, and makes an assumption that firmware
provides a zero-terminated string. Both of those are bugs: the entry
is likely
From: Raul E Rangel
[ Upstream commit ea90228c7b2ae6646bb6381385229aabb6f14cd2 ]
acpi_dev_hid_uid_match() expects a null pointer for UID if it doesn't
exist. The acpihid_map_entry contains a char buffer for holding the
UID. If no UID was provided in the IVRS table, this buffer will be
zeroed. If
From: Joerg Roedel
[ Upstream commit bd421264ed307dd296eab036851221b225071a32 ]
The IOMMU core code has support for deferring the attachment of a domain
to a device. This is needed in kdump kernels where the new domain must
not be attached to a device before the device driver takes it over.
Whe
From: Joerg Roedel
[ Upstream commit f44a4d7e4f1cdef73c90b1dc749c4d8a7372a8eb ]
The update_domain() function is expected to also inform the hardware
about domain changes. This needs a COMPLETION_WAIT command to be sent
to all IOMMUs which use the domain.
Signed-off-by: Joerg Roedel
Tested-by:
From: Joerg Roedel
[ Upstream commit 5b8a9a047b6cad361405c7900c1e1cdd378c4589 ]
When increase_address_space() fails to allocate memory, alloc_pte()
will call it again until it succeeds. Do not loop forever while trying
to increase the address space and just return an error instead.
Signed-off-b
PCI ACS is disabled if Intel IOMMU is off by default or intel_iommu=off
is used in command line. Unfortunately, Intel IOMMU will be forced on if
there're devices sitting on an external facing PCI port that is marked
as untrusted (for example, thunderbolt peripherals). That means, PCI ACS
is disable
Hi, Bjorn
On 2020/6/9 上午12:41, Bjorn Helgaas wrote:
On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:
On 2020/6/6 上午7:19, Bjorn Helgaas wrote:
On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:
On 2020/6/2 上午1:41, Bjorn Helgaas wrote:
On Thu, May 28, 2020 at 09:33:44AM
The Scalable-mode Page-walk Coherency (SMPWC) field in the VT-d extended
capability register indicates the hardware coherency behavior on paging
structures accessed through the pasid table entry. This is ignored in
current code and using ECAP.C instead which is only valid in legacy mode.
Fix this s
25 matches
Mail list logo
