Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

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?

[PATCH 5.6 014/126] iommu/amd: Fix over-read of ACPI UID from IVRS table

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

[PATCH 5.4 012/111] iommu/amd: Fix over-read of ACPI UID from IVRS table

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

[PATCH 4.19 12/81] iommu/amd: Fix over-read of ACPI UID from IVRS table

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

[PATCH 4.14 10/59] iommu/amd: Fix over-read of ACPI UID from IVRS table

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

[PATCH 4.9 09/64] iommu/amd: Fix over-read of ACPI UID from IVRS table

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

Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets

On Wed, May 20, 2020 at 09:50:36AM -0400, Jim Quinlan wrote: > On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman > wrote: > > > > On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote: > > > diff --git a/include/linux/device.h b/include/linux/device.h > > &

Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets

On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote: > diff --git a/include/linux/device.h b/include/linux/device.h > index ac8e37cd716a..6cd916860b5f 100644 > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -493,6 +493,8 @@ struct dev_links_info { > * @bus_dma_limit:

[PATCH] drivers/iommu: properly export iommu_group_get_for_dev

John Garry Fixes: a7ba5c3d008d ("drivers/iommu: Export core IOMMU API symbols to permit modular drivers") Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.

Re: [PATCH 3/4] dma-mapping: add a dma_ops_bypass flag to struct device

mon solution. > > Signed-off-by: Christoph Hellwig > --- > include/linux/device.h | 6 > kernel/dma/mapping.c | 70 +- > 2 files changed, 55 insertions(+), 21 deletions(-) Reviewed-by: Greg Kroah-Hartman ___

Re: [PATCH v4 05/16] iommu: Rename struct iommu_param to dev_iommu

On Thu, Mar 26, 2020 at 04:08:30PM +0100, Joerg Roedel wrote: > From: Joerg Roedel > > The term dev_iommu aligns better with other existing structures and > their accessor functions. > > Cc: Greg Kroah-Hartman > Tested-by: Will Deacon # arm-smmu > Reviewed-by: Jean-Ph

Re: [PATCH v4 06/16] iommu: Move iommu_fwspec to struct dev_iommu

On Thu, Mar 26, 2020 at 04:08:31PM +0100, Joerg Roedel wrote: > From: Joerg Roedel > > Move the iommu_fwspec pointer in struct device into struct dev_iommu. > This is a step in the effort to reduce the iommu related pointers in > struct device to one. > > Cc: Greg Kr

Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device

ons(+), 21 deletions(-) Reviewed-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: drivers/iommu/qcom_iommu.c:348 qcom_iommu_domain_free+0x5c/0x70

On Tue, Feb 18, 2020 at 06:31:51PM +, Robin Murphy wrote: > On 18/02/2020 6:23 pm, Greg Kroah-Hartman wrote: > [...] > > Can you bisect to find the offending commit? > > This particular presentation appears to be down to the DRM driver starting > to call of_platform_d

Re: drivers/iommu/qcom_iommu.c:348 qcom_iommu_domain_free+0x5c/0x70

On Tue, Feb 18, 2020 at 04:13:57PM +0530, Naresh Kamboju wrote: > We have noticed these kernel warnings on APQ 8016 SBC (dragonboard > 410c ) running stable rc 5.5, 5.4 branches and linux mainline and > linux-next master branches. > > This warning started happening from linux mainline 5.3

Re: [PATCH v12 2/4] uacce: add uacce driver

On Thu, Feb 13, 2020 at 05:15:10PM +0800, Herbert Xu wrote: > On Mon, Feb 10, 2020 at 03:37:11PM -0800, Greg Kroah-Hartman wrote: > > > > Looks much saner now, thanks for all of the work on this: > > > > Reviewed-by: Greg Kroah-Hartman > > > > Or am I supp

Re: [PATCH v12 2/4] uacce: add uacce driver

> Signed-off-by: Zaibo Xu > Signed-off-by: Zhou Wang > Signed-off-by: Jean-Philippe Brucker > Signed-off-by: Zhangfei Gao Looks much saner now, thanks for all of the work on this: Reviewed-by: Greg Kroah-Hartman Or am I supposed to take this in my tree? If so, I can, but I need

Re: [PATCH v11 2/4] uacce: add uacce driver

On Wed, Jan 15, 2020 at 07:18:34PM +0800, zhangfei wrote: > Hi, Greg > > On 2020/1/14 下午10:59, Greg Kroah-Hartman wrote: > > On Mon, Jan 13, 2020 at 11:34:55AM +0800, zhangfei wrote: > > > Hi, Greg > > > > > > Thanks for the review. > > >

Re: [PATCH v11 2/4] uacce: add uacce driver

On Mon, Jan 13, 2020 at 11:34:55AM +0800, zhangfei wrote: > Hi, Greg > > Thanks for the review. > > On 2020/1/12 上午3:40, Greg Kroah-Hartman wrote: > > On Sat, Jan 11, 2020 at 10:48:37AM +0800, Zhangfei Gao wrote: > > > +static int uacce_fops_open(struct in

Re: [PATCH v11 2/4] uacce: add uacce driver

On Sat, Jan 11, 2020 at 10:48:37AM +0800, Zhangfei Gao wrote: > +static int uacce_fops_open(struct inode *inode, struct file *filep) > +{ > + struct uacce_mm *uacce_mm = NULL; > + struct uacce_device *uacce; > + struct uacce_queue *q; > + int ret = 0; > + > + uacce =

Re: [PATCH v4 05/16] drivers/iommu: Take a ref to the IOMMU driver prior to ->add_device()

On Thu, Jan 09, 2020 at 02:16:03PM +, Will Deacon wrote: > Hi Greg, > > On Thu, Dec 19, 2019 at 03:44:37PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Dec 19, 2019 at 12:03:41PM +, Will Deacon wrote: > > > diff --git a/include/linux/iommu.h b/include/l

Re: dma-direct: don't check swiotlb=force in dma_direct_map_resource

On Tue, Jan 07, 2020 at 06:18:28PM +, Robin Murphy wrote: > On 07/01/2020 5:38 pm, Naresh Kamboju wrote: > > Following build error on stable-rc 5.4.9-rc1 for arm architecture. > > > > dma/direct.c: In function 'dma_direct_possible': > > dma/direct.c:329:3: error: too many arguments to

[PATCH 5.4 368/434] iommu: set group default domain before creating direct mappings

Add API to request DMA domain for device") Signed-off-by: Jerry Snitselaar Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/iommu.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/iommu/iommu.c +++ b/drivers/

[PATCH 5.4 371/434] iommu/vt-d: Allocate reserved region for ISA with correct permission

Baolu Cc: iommu@lists.linux-foundation.org Cc: sta...@vger.kernel.org # v5.3+ Fixes: d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") Signed-off-by: Jerry Snitselaar Acked-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kro

Re: [PATCH v4 00/16] iommu: Permit modular builds of ARM SMMU[v3] drivers

> I tested this on AMD Seattle by loading arm-smmu-mod.ko from the initrd. All look good to me! Reviewed-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 05/16] drivers/iommu: Take a ref to the IOMMU driver prior to ->add_device()

On Thu, Dec 19, 2019 at 12:03:41PM +, Will Deacon wrote: > To avoid accidental removal of an active IOMMU driver module, take a > reference to the driver module in 'iommu_probe_device()' immediately > prior to invoking the '->add_device()' callback and hold it until the > after the device has

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

On Wed, Oct 30, 2019 at 08:45:32PM +0100, Christoph Hellwig wrote: > On Wed, Oct 30, 2019 at 08:26:40PM +0100, Greg Kroah-Hartman wrote: > > Looks good! You can apply patch 2/2 as well if you want to take that > > through your tree too. > > I can do that, I'll just need

Re: [PATCH v4 2/2] usb: core: Remove redundant vmap checks

changed, 1 insertion(+), 7 deletions(-) Acked-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

On Wed, Oct 30, 2019 at 07:09:21PM +0100, Christoph Hellwig wrote: > On Wed, Oct 30, 2019 at 10:18:49AM +0100, Greg Kroah-Hartman wrote: > > On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote: > > > As we've seen from USB and other areas[1], we need to always do runtime &g

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote: > As we've seen from USB and other areas[1], we need to always do runtime > checks for DMA operating on memory regions that might be remapped. This > adds vmap checks (similar to those already in USB but missing in other > places) into

Re: [PATCH v3 1/2] dma-mapping: Add vmap checks to dma_map_single()

On Thu, Oct 10, 2019 at 03:28:28PM -0700, Kees Cook wrote: > As we've seen from USB and other areas[1], we need to always do runtime > checks for DMA operating on memory regions that might be remapped. This > adds vmap checks (similar to those already in USB but missing in other > places) into

Re: [PATCH v2] dma-mapping: Move vmap address checks into dma_map_single()

On Fri, Oct 04, 2019 at 02:28:16PM -0700, Kees Cook wrote: > As we've seen from USB and other areas, we need to always do runtime > checks for DMA operating on memory regions that might be remapped. This > moves the existing checks from USB into dma_map_single(), but leaves > the slightly heavier

Re: next take at setting up a dma mask by default for platform devices v2

On Fri, Aug 16, 2019 at 08:24:29AM +0200, Christoph Hellwig wrote: > Hi all, > > this is another attempt to make sure the dma_mask pointer is always > initialized for platform devices. Not doing so lead to lots of > boilerplate code, and makes platform devices different from all our > major

Re: next take at setting up a dma mask by default for platform devices

On Thu, Aug 15, 2019 at 03:25:31PM +0200, Christoph Hellwig wrote: > On Thu, Aug 15, 2019 at 03:23:18PM +0200, Greg Kroah-Hartman wrote: > > I've taken the first 2 patches for 5.3-final. Given that patch 3 needs > > to be fixed, I'll wait for a respin of these before considering th

Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device

On Thu, Aug 15, 2019 at 03:38:12PM +0200, Christoph Hellwig wrote: > On Thu, Aug 15, 2019 at 03:03:25PM +0200, Greg Kroah-Hartman wrote: > > > --- a/include/linux/platform_device.h > > > +++ b/include/linux/platform_device.h > > > @@ -24,6 +24,7 @@ struct

Re: next take at setting up a dma mask by default for platform devices

On Sun, Aug 11, 2019 at 10:05:14AM +0200, Christoph Hellwig wrote: > Hi all, > > this is another attempt to make sure the dma_mask pointer is always > initialized for platform devices. Not doing so lead to lots of > boilerplate code, and makes platform devices different from all our > major

Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device

On Sun, Aug 11, 2019 at 10:05:20AM +0200, Christoph Hellwig wrote: > We still treat devices without a DMA mask as defaulting to 32-bits for > both mask, but a few releases ago we've started warning about such > cases, as they require special cases to work around this sloppyness. > Add a dma_mask

[PATCH 5.2 085/144] iommu/vt-d: Check if domain->pgd was allocated

[ Upstream commit 3ee9eca760e7d0b68c55813243de66bbb499dc3b ] There is a couple of places where on domain_init() failure domain_exit() is called. While currently domain_init() can fail only if alloc_pgtable_page() has failed. Make domain_exit() check if domain->pgd present, before calling

[PATCH 4.19 17/32] iommu/vt-d: Dont queue_iova() if there is no flush queue

shing") Signed-off-by: Dmitry Safonov Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel [v4.14-port notes: o minor conflict with untrusted IOMMU devices check under if-condition] Signed-off-by: Dmitry Safonov Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/intel-iommu.c |2 +- drivers/io

[PATCH 4.14 17/25] iommu/vt-d: Dont queue_iova() if there is no flush queue

shing") Signed-off-by: Dmitry Safonov Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel [v4.14-port notes: o minor conflict with untrusted IOMMU devices check under if-condition o setup_timer() near one chunk is timer_setup() in v5.3] Signed-off-by: Dmitry Safonov Signed-off-by: Greg Kro

Re: [PATCH-4.19-stable 0/2] iommu/vt-d: queue_iova() boot crash backport

On Wed, Jul 31, 2019 at 05:22:18PM +0100, Dmitry Safonov wrote: > Backport commits from master that fix boot failure on some intel > machines. > > Cc: David Woodhouse > Cc: Joerg Roedel > Cc: Joerg Roedel > Cc: Lu Baolu Thanks for the backports, 4.19.y and 4.14.y patches now queued up. greg

[PATCH 5.2 202/215] iommu/vt-d: Dont queue_iova() if there is no flush queue

shing") Signed-off-by: Dmitry Safonov Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/intel-iommu.c |3 ++- drivers/iommu/iova.c| 18 ++ include/linux/iova.h|6 ++ 3 files changed, 22 insert

Re: [PATCH] omap-iommu: no need to check return value of debugfs_create functions

On Thu, Jul 04, 2019 at 05:35:52PM +0200, Joerg Roedel wrote: > On Thu, Jul 04, 2019 at 04:36:49PM +0200, Greg Kroah-Hartman wrote: > > When calling debugfs functions, there is no need to ever check the > > return value. The function can work or not, but the code logic shou

[PATCH] omap-iommu: no need to check return value of debugfs_create functions

When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Joerg Roedel Cc: iommu@lists.linux-foundation.org Signed-off-by: Greg Kroah-Hartman --- Warning, not even

Re: [PATCH v2] driver: core: Allow subsystems to continue deferring probe

On Fri, Jun 14, 2019 at 12:10:10PM +0200, Rafael J. Wysocki wrote: > On Fri, Jun 14, 2019 at 11:39 AM Thierry Reding > wrote: > > > > On Fri, Jun 14, 2019 at 11:10:58AM +0200, Greg Kroah-Hartman wrote: > > > On Thu, Jun 13, 2019 at 07:00:11PM +0200, Thierry Reding w

Re: [PATCH v2] driver: core: Allow subsystems to continue deferring probe

On Thu, Jun 13, 2019 at 07:00:11PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Some subsystems, such as pinctrl, allow continuing to defer probe > indefinitely. This is useful for devices that depend on resources > provided by devices that are only probed after the init stage. > >

[PATCH] swiotlb: no need to check return value of debugfs_create functions

-foundation.org Signed-off-by: Greg Kroah-Hartman --- kernel/dma/swiotlb.c | 25 - 1 file changed, 4 insertions(+), 21 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 13f0cb080a4d..62fa5a82a065 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma

Re: [PATCH] driver: core: Allow subsystems to continue deferring probe

On Wed, Jun 05, 2019 at 04:23:12PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Some subsystems, such as pinctrl, allow continuing to defer probe > indefinitely. This is useful for devices that depend on resources > provided by devices that are only probed after the init stage. > >

Re: [PATCH/RFC] driver core: Postpone DMA tear-down until after devres release

On Thu, Mar 07, 2019 at 02:52:55PM +, Robin Murphy wrote: > Hi John, > > On 07/03/2019 14:45, John Garry wrote: > [...] > > Hi guys, > > > > Any idea what happened to this fix? > > It's been in -next for a while (commit 376991db4b64) - I assume it will land > shortly and hit stable

Re: [PATCH 07/12] dma-mapping: move CONFIG_DMA_CMA to kernel/dma/Kconfig

dma/Kconfig | 77 > 2 files changed, 77 insertions(+), 77 deletions(-) Much nicer, thanks! Reviewed-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 09/12] dma-mapping: remove the DMA_MEMORY_EXCLUSIVE flag

-sm501.c | 3 +-- > drivers/usb/host/ohci-tmio.c | 2 +- > include/linux/dma-mapping.h | 7 ++ > kernel/dma/coherent.c | 25 ++- > 14 files changed, 29 ins

Re: [PATCH 02/12] device.h: dma_mem is only needed for HAVE_GENERIC_DMA_COHERENT

On Mon, Feb 11, 2019 at 02:35:44PM +0100, Christoph Hellwig wrote: > No need to carry an unused field around. > > Signed-off-by: Christoph Hellwig > --- > include/linux/device.h | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by:

Re: [PATCH] dma: debug: no need to check return value of debugfs_create functions

On Fri, Feb 01, 2019 at 10:04:02AM +0100, Christoph Hellwig wrote: > On Tue, Jan 22, 2019 at 07:48:47PM +0100, Greg Kroah-Hartman wrote: > > > Does this actually need to be at file scope, or could it be punted to a > > > local in dma_debug_fs_init() while we're here? >

Re: [RFC PATCH 2/5] drivers/base: add a function to test peer to peer capability

On Tue, Jan 29, 2019 at 12:47:25PM -0500, jgli...@redhat.com wrote: > From: Jérôme Glisse > > device_test_p2p() return true if two devices can peer to peer to > each other. We add a generic function as different inter-connect > can support peer to peer and we want to genericaly test this no >

Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability

On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote: > > > On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote: > > +bool pci_test_p2p(struct device *devA, struct device *devB) > > +{ > > + struct pci_dev *pciA, *pciB; > > + bool ret; > > + int tmp; > > + > > + /* > > +*

Re: [PATCH] dma: debug: no need to check return value of debugfs_create functions

On Tue, Jan 22, 2019 at 06:44:38PM +, Robin Murphy wrote: > Hi Greg, > > On 22/01/2019 15:21, Greg Kroah-Hartman wrote: > > When calling debugfs functions, there is no need to ever check the > > return value. The function can work or not, but the code logic should &

[PATCH] dma: debug: no need to check return value of debugfs_create functions

they are created. Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: iommu@lists.linux-foundation.org Signed-off-by: Greg Kroah-Hartman --- kernel/dma/debug.c | 81 ++ 1 file changed, 10 insertions(+), 71 deletions(-) diff --git a/kernel/dma

Re: [PATCH 1/6] driver core: Introduce device_iommu_mapped() function

check, as the pointer will > be moved to 'struct dev_iommu_data'. This way to make the > check is also not very readable. > > Introduce an explicit function to perform this check. > > Cc: Greg Kroah-Hartman > Acked-by: Greg Kroah-Hartman No need to have a cc: line if I h

Re: [PATCH 1/5] driver core: Introduce device_iommu_mapped() function

check, as the pointer will > be moved to 'struct dev_iommu_data'. This way to make the > check is also not very readable. > > Introduce an explicit function to perform this check. > > Cc: Greg Kroah-Hartman > Signed-off-by: Joerg Roedel > --- > include/linux/device.h | 10 +

[PATCH 4.18 33/34] x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels

ux-foundation.org Cc: sta...@vger.kernel.org Link: https://lkml.kernel.org/r/20181014075208.2715-1-...@lst.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/pci-swiotlb.c |2 -- 1 file changed, 2 deletions(-) --- a/arch/x86/kernel/pci-swiotlb.c +++ b/arch/x86/

[PATCH 4.18 156/168] iommu/amd: Clear memory encryption mask from physical address

-by: Boris Ostrovsky Cc: Tom Lendacky Cc: Joerg Roedel Cc: Cc: Borislav Petkov Cc: Paolo Bonzini Cc: Radim Krčmář Cc: k...@vger.kernel.org Cc: Boris Ostrovsky Cc: # 4.14+ Signed-off-by: Brijesh Singh Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/a

[PATCH 4.14 84/94] iommu/amd: Clear memory encryption mask from physical address

-by: Boris Ostrovsky Cc: Tom Lendacky Cc: Joerg Roedel Cc: Cc: Borislav Petkov Cc: Paolo Bonzini Cc: Radim Krčmář Cc: k...@vger.kernel.org Cc: Boris Ostrovsky Cc: # 4.14+ Signed-off-by: Brijesh Singh Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/a

Re: [git pull] IOMMU Fixes for Linux v4.19-rc6

On Fri, Oct 05, 2018 at 10:30:09AM +0200, Joerg Roedel wrote: > Hi Greg, > > The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: > > Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) > > are available in the git repository at: > >

Re: [GIT PULL] dma mapping fix for 4.19-rc6

On Fri, Sep 28, 2018 at 05:54:47PM -0700, Christoph Hellwig wrote: > The following changes since commit bfb0e9b490bc15f243009359745a9d8a94089dc4: > > Merge tag 'usb-4.19-rc6' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb (2018-09-25 17:54:55 > +0200) > > are available in the

Re: Linux 4.19-rc5: Missing iommu fix

On Mon, Sep 24, 2018 at 11:33:39AM +0200, Sedat Dilek wrote: > Hi Greg, > > thanks and congrats for this release. > > Me and several other people have an issue with "intel_iommu=on" (see > [1]) and a patch is pending in [2]. > Unfortunately, it is not in linux-iommu Git. > Hope this will soon

Re: [git pull] IOMMU Fixes for Linux v4.19-rc5

On Wed, Sep 26, 2018 at 11:36:49AM +0200, Joerg Roedel wrote: > Hi Greg, > > The following changes since commit 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84: > > Linux 4.19-rc5 (2018-09-23 19:15:18 +0200) > > are available in the git repository at: > >

Re: [PATCH 2/5] dma-mapping: move the dma_coherent flag to struct device

On Tue, Sep 11, 2018 at 08:46:36AM +0200, Christoph Hellwig wrote: > On Mon, Sep 10, 2018 at 06:13:50PM +0200, Greg Kroah-Hartman wrote: > > > +#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \ > > > +defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) ||

Re: [PATCH 2/5] dma-mapping: move the dma_coherent flag to struct device

On Mon, Sep 10, 2018 at 08:05:30AM +0200, Christoph Hellwig wrote: > diff --git a/include/linux/device.h b/include/linux/device.h > index 8f882549edee..983506789402 100644 > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -927,6 +927,8 @@ struct dev_links_info { > * @offline:

Re: [PATCH 1/7] core, dma-direct: add a flag 32-bit dma limits

For the patch, no objection from me: Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 11/22] driver core: add per device iommu param

ommu_param as a parent pointer such that all device IOMMU > data can be consolidated here. The idea was suggested here by Greg KH > and Joerg. The name iommu_param is chosen here since iommu_data has been used. > > Suggested-by: Greg Kroah-Hartman <gre...@linuxfoundati

Re: [PATCH v4 11/22] driver core: add per device iommu param

ommu_param as a parent pointer such that all device IOMMU > data can be consolidated here. The idea was suggested here by Greg KH > and Joerg. The name iommu_param is chosen here since iommu_data has been used. > > Suggested-by: Greg Kroah-Hartman <gre...@linuxfoundati

Re: [PATCH v2 21/21] usb: Remove depends on HAS_DMA in case of platform dependency

t; > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Reviewed-by: Mark Brown <broo...@kernel.org> > Acked-by: Robin Murphy <robin.mur...@arm.com> > Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com>

Re: [PATCH v2 3/5] usb: gadget: Add NO_DMA dummies for DMA mapping API

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Reviewed-by: Mark Brown <broo...@kernel.org> > Acked-by: Robin Murphy <robin.mur...@arm.com> > Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation

Re: [PATCH v2 18/21] serial: Remove depends on HAS_DMA in case of platform dependency

t; > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Reviewed-by: Mark Brown <broo...@kernel.org> > Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> _

Re: [PATCH v2 20/21] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency

t; > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Reviewed-by: Mark Brown <broo...@kernel.org> > Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> _

Re: [PATCH v3 09/16] driver core: add iommu device fault reporting data

ommu_param as a parent pointer such that all device IOMMU > data can be consolidated here. The idea was suggested here by Greg KH > and Joerg. The name iommu_param is chosen here since iommu_data has been used. > > Suggested-by: Greg Kroah-Hartman <gre...@linuxfoundati

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

On Fri, Oct 06, 2017 at 12:11:45AM -0700, Christoph Hellwig wrote: > On Thu, Oct 05, 2017 at 04:03:37PM -0700, Jacob Pan wrote: > > DMA faults can be detected by IOMMU at device level. Adding a pointer > > to struct device allows IOMMU subsystem to report relevant faults > > back to the device

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

r user space drivers), guest OS holds > responsibility to handle and respond per device IOMMU fault. > Therefore we need fault reporting mechanism to propagate faults beyond > IOMMU subsystem. > > Signed-off-by: Jacob Pan <jacob.jun....@linux.intel.com> Acked-by: Greg Kroah-Ha

[PATCH 4.9 044/103] x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0

linux-foundation.org Cc: Jon Mason <jdma...@kudzu.us> Cc: Muli Ben-Yehuda <mu...@mulix.org> Link: http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkov...@suse.cz Signed-off-by: Thomas Gleixner <t...@linutronix.de> Signed-off-by: Greg Kroah-Hartm

[PATCH 3.18 12/39] x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0

iommu@lists.linux-foundation.org Cc: Jon Mason <jdma...@kudzu.us> Cc: Muli Ben-Yehuda <mu...@mulix.org> Link: http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkov...@suse.cz Signed-off-by: Thomas Gleixner <t...@linutronix.de> Signed-off-by: Greg Kroah-Har

[PATCH 4.10 042/167] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

gt; Cc: Ashok Raj <ashok@intel.com> Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support") Signed-off-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Ashok Raj <ashok@intel.com> Tested-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Joerg Roede

[PATCH 4.10 043/167] iommu/vt-d: Tylersburg isoch identity map check is done too late.

in init_dmars()") Signed-off-by: Ashok Raj <ashok@intel.com> Reported-by: Yunhong Jiang <yunhong.ji...@intel.com> Signed-off-by: Joerg Roedel <jroe...@suse.de> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/iommu/intel-iommu

[PATCH 4.9 040/153] iommu/vt-d: Tylersburg isoch identity map check is done too late.

in init_dmars()") Signed-off-by: Ashok Raj <ashok@intel.com> Reported-by: Yunhong Jiang <yunhong.ji...@intel.com> Signed-off-by: Joerg Roedel <jroe...@suse.de> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/iommu/intel-iommu.c |3 ++- 1 f

[PATCH 4.9 039/153] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

gt; Cc: Ashok Raj <ashok@intel.com> Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support") Signed-off-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Ashok Raj <ashok@intel.com> Tested-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Joerg Roede

[PATCH 4.4 26/91] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

gt; Cc: Ashok Raj <ashok@intel.com> Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support") Signed-off-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Ashok Raj <ashok@intel.com> Tested-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Joerg Roede

[PATCH 4.4 27/91] iommu/vt-d: Tylersburg isoch identity map check is done too late.

in init_dmars()") Signed-off-by: Ashok Raj <ashok@intel.com> Reported-by: Yunhong Jiang <yunhong.ji...@intel.com> Signed-off-by: Joerg Roedel <jroe...@suse.de> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/iommu/intel-iommu.c |3 ++- 1 f

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote: > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to > transfer data between memory and PCIe adapter. Because of performance > reasons it is important that the CPU cache is not flushed when such > drivers transfer

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

ers transfer data. Make this possible by allowing these drivers to > override the dma_map_ops pointer. Additionally, introduce the function > set_dma_ops() that will be used by a later patch in this series. > > Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>

Re: [PATCH 2/2] driver core: Silence device links sphinx warning

ki <raf...@kernel.org> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Cc: Jonathan Corbet <cor...@lwn.net> > Cc: Silvio Fricke <silvio.fri...@gmail.com> > Signed-off-by: Lukas Wunner <lu...@wunner.de> > --- > drivers/base/core.c| 4 ++-- &

Re: [PATCH V5 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On Sun, Sep 27, 2015 at 03:48:24PM +0200, Rafael J. Wysocki wrote: > On Sun, Sep 27, 2015 at 12:04 AM, Viresh Kumar > wrote: > > global_lock is defined as an unsigned long and accessing only its lower > > 32 bits from sysfs is incorrect, as we need to consider other 32

Re: [RFC/PATCH 6/9] drivers: platform: Configure dma operations at probe time

+ drivers/of/platform.c | 7 +++ 2 files changed, 12 insertions(+), 4 deletions(-) Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo

Re: [PATCH 0/2] iommu/vt-d: Keep RMRR mappings around on driver unbind

. Please review. I have no objection to these, do you want me to take them through my tree? Or if they are going through some other one feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org To the first patch. thanks, greg k-h

Re: [PATCH 04/29] drivers: base: add notifier for failed driver bind

On Tue, Aug 05, 2014 at 12:47:32PM +0200, Marek Szyprowski wrote: This patch adds support for getting a notify for failed device driver bind, so all the items done in BUS_NOTIFY_BIND_DRIVER event can be cleaned if the driver fails to bind. But doesn't the bus know if the driver fails to bind,

Re: 3.16rc3 multiplatform, Armada 370 and IOMMU: unbootable kernel

On Mon, Jul 07, 2014 at 07:58:18AM -0300, Ezequiel Garcia wrote: On 05 Jul 01:59 PM, Greg Kroah-Hartman wrote: On Sat, Jul 05, 2014 at 12:03:08PM -0300, Ezequiel Garcia wrote: After following Gregory's stacktrace (also reproduced here): [c02451f8] (iommu_bus_notifier) from [c00512e8

Re: 3.16rc3 multiplatform, Armada 370 and IOMMU: unbootable kernel

On Sat, Jul 05, 2014 at 12:03:08PM -0300, Ezequiel Garcia wrote: After following Gregory's stacktrace (also reproduced here): [c02451f8] (iommu_bus_notifier) from [c00512e8] (notifier_call_chain+0x64/0x9c) [c00512e8] (notifier_call_chain) from [c00514cc]

Re: [PATCH v2] iommu: Constify struct iommu_ops

-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3.14 78/78] [stable PATCH] iommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap()

3.14-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse dw...@infradead.org Based on commit ea8ea460c9ace60bbb5ac6e5521d637d5c15293d upstream This missing IOTLB flush was added as a minor, inconsequential bug-fix in commit ea8ea460c

Re: [PATCH 1/2] debugfs: Allow debugfs_create_dir() to take data

On Wed, Aug 15, 2012 at 08:40:08AM +0300, Hiroshi Doyu wrote: On Thu, 9 Aug 2012 14:56:24 +0200 Hiroshi Doyu hd...@nvidia.com wrote: Hi Greg, Felipe, On Wed, 8 Aug 2012 15:34:27 +0200 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Wed, Aug 08, 2012 at 09:24:32AM +0300

Re: [PATCH 1/2] debugfs: Allow debugfs_create_dir() to take data

On Wed, Aug 08, 2012 at 09:24:32AM +0300, Hiroshi Doyu wrote: Add __debugfs_create_dir(), which takes data passed from caller. Why? Signed-off-by: Hiroshi Doyu hd...@nvidia.com --- fs/debugfs/inode.c |7 --- include/linux/debugfs.h |9 - 2 files changed, 12

<    1   2