On Thu, Oct 17, 2019 at 07:36:51AM -0400, Qian Cai wrote:
>
>
> > On Oct 16, 2019, at 6:59 PM, Jerry Snitselaar wrote:
> >
> > I guess the mode level 6 check is really for other potential callers
> > increase_address_space, none exist at the moment, and the condition
> > of the while loop in
On Thu, Oct 17, 2019 at 10:39:13AM -0400, Qian Cai wrote:
> On Wed, 2019-10-16 at 17:44 +0200, Joerg Roedel wrote:
> > On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > > BTW, the previous x86 warning was from only reverted one patch "iommu:
> > > Add gfp
> > > parameter to
Did you get a chance to look at iommu_dma_alloc_remap() as well?
drivers/iommu/dma-iommu.c
584 static void *iommu_dma_alloc_remap(struct device *dev, size_t size,
585 dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
Hello,
I tried another script for the semantic patch language out.
This source code analysis approach points out that the implementation
of the function “exynos_iommu_add_device” contains still
an unchecked call of the function “device_link_add”.
Hello,
I tried another script for the semantic patch language out.
This source code analysis approach points out that the implementation
of the function “rk_iommu_add_device” contains still
an unchecked call of the function “device_link_add”.
On Fri Oct 18 19, Joerg Roedel wrote:
From: Joerg Roedel
A recent commit added a gfp parameter to amd_iommu_map() to make it
callable from atomic context, but forgot to pass it down to
iommu_map_page() and left GFP_KERNEL there. This caused
sleep-while-atomic warnings and needs to be fixed.
From: Joerg Roedel
A recent commit added a gfp parameter to amd_iommu_map() to make it
callable from atomic context, but forgot to pass it down to
iommu_map_page() and left GFP_KERNEL there. This caused
sleep-while-atomic warnings and needs to be fixed.
Reported-by: Qian Cai
Reported-by: Dan
As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is
possible for a device configured with 32 bit DMA addresses and a partial
DMA mapping located at the end of the address space to overflow. It
happens when a higher physical address, not DMAable, is translated to
it's DMA
sta2x11 is the only x86 device that depends custom DMA direct functions.
It turns out it can be made standard by carefully setting the device's
DMA masks and offset.
Originally only patch #2 was sent but I realised patch #1 is also
needed, which is a good addition as it's also a prerequisite to
On 2019-10-18 10:27 am, Dan Carpenter wrote:
Did you get a chance to look at iommu_dma_alloc_remap() as well?
drivers/iommu/dma-iommu.c
584 static void *iommu_dma_alloc_remap(struct device *dev, size_t size,
585 dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
On 17/10/2019 17:24, Christoph Hellwig wrote:
On Wed, Oct 16, 2019 at 06:07:36PM +0100, Robin Murphy wrote:
@@ -1180,7 +1179,7 @@ int iommu_dma_prepare_msi(struct msi_desc *desc,
phys_addr_t msi_addr)
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
struct
On Wed, Oct 16, 2019 at 01:50:24PM +0200, Thierry Reding wrote:
> From: Navneet Kumar
>
> Use PTB_ASID instead of SMMU_CONFIG to flush smmu.
> PTB_ASID can be accessed from non-secure mode, SMMU_CONFIG cannot be.
> Using SMMU_CONFIG could pose a problem when kernel doesn't have secure
> mode
On Fri Oct 18 19, Joerg Roedel wrote:
On Thu, Oct 17, 2019 at 07:36:51AM -0400, Qian Cai wrote:
> On Oct 16, 2019, at 6:59 PM, Jerry Snitselaar wrote:
>
> I guess the mode level 6 check is really for other potential callers
> increase_address_space, none exist at the moment, and the
* Suman Anna [191017 23:00]:
> Hi Tony,
>
> On 8/26/19 7:14 PM, Suman Anna wrote:
> > Hi Tony,
> >
> > The following 2 patches need to go along with the recent "iommu/omap: misc
> > fixes" series [1] that is currently staged [2] for a 5.4 merge and available
> > in linux-next. That series added
Hi Linus,
The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.4-rc3
for you to fetch changes up to
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile
Add Memory controller DT node on T194 and enable it.
This patch is a prerequisite for SMMU enable on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 4
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 6 ++
2 files changed, 10 insertions(+)
diff
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 100
drivers/iommu/arm-smmu.c| 11 -
drivers/iommu/arm-smmu.h|
Enable SMMU translations for SDHCI and EQOS transactions on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index
Remove const keyword for arm_smmu_flush_ops in arm_smmu_domain
and replace direct references to arm_smmu_tlb_sync* functions with
arm_smmu_flush_ops->tlb_sync().
This is necessary for vendor specific implementations that
need to override arm_smmu_flush_ops in part or full.
Signed-off-by: Krishna
Add DT node for T194 SMMU to enable SMMU support.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
Changes in v3:
Rebased on top of
https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/ next.
Resolved compile error seen with tegra194.dtsi changes after rebase.
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (7):
iommu/arm-smmu:
The pull request you sent on Fri, 18 Oct 2019 17:54:08 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.4-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/90105ae1eeef51987f40d8e2db4c9c79604fc4e4
Thank you!
--
Hi Robin,
Sorry for the late reply.
> This parameters are not changed after early boot.
> > By making them __ro_after_init will reduce any attack surface in the
> > kernel.
>
> At a glance, it looks like these are only referenced by a couple of
> __init functions, so couldn't they just be
25 matches
Mail list logo
