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

2016-12-05 Thread Greg Kroah-Hartman
On Sun, Dec 04, 2016 at 01:10:04PM +0100, Lukas Wunner wrote: > Silence this warning emitted by sphinx: > include/linux/device.h:938: warning: No description found for parameter > 'links' > > While at it, fix typos in comments of device links code. > > Cc: Rafa

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

2017-01-10 Thread Greg Kroah-Hartman
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 > Cc: Greg Kroah-Hartman > Cc: Au

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

2017-01-10 Thread Greg Kroah-Hartman
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 da

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

2017-03-10 Thread Greg Kroah-Hartman
ng Signed-off-by: Ashok Raj Tested-by: CQ Tang Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman --- include/linux/intel-iommu.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/include/linux/intel-iommu.h +++ b/include/linux/intel-iommu.h @@ -15

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

2017-03-10 Thread Greg Kroah-Hartman
ned-off-by: Greg Kroah-Hartman --- drivers/iommu/intel-iommu.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -3238,13 +3238,14 @@ static int __init init_dmars(void) iommu_identity_mapping |= IDENTMAP_GF

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

2017-03-10 Thread Greg Kroah-Hartman
ng Signed-off-by: Ashok Raj Tested-by: CQ Tang Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman --- include/linux/intel-iommu.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/include/linux/intel-iommu.h +++ b/include/linux/intel-iommu.h @@ -15

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

2017-03-10 Thread Greg Kroah-Hartman
ned-off-by: Greg Kroah-Hartman --- drivers/iommu/intel-iommu.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -3325,13 +3325,14 @@ static int __init init_dmars(void) iommu_identity_mapping |= IDENTMAP_GF

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

2017-03-10 Thread Greg Kroah-Hartman
ng Signed-off-by: Ashok Raj Tested-by: CQ Tang Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman --- include/linux/intel-iommu.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/include/linux/intel-iommu.h +++ b/include/linux/intel-iommu.h @@ -15

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

2017-03-10 Thread Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/intel-iommu.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -3325,13 +3325,14 @@ static int __init init_dmars(void) iommu_identity_mapping |= IDENTMAP_GF

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

2017-05-11 Thread Greg Kroah-Hartman
-Yehuda Link: http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkov...@suse.cz Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/pci-calgary_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kerne

[PATCH 4.10 060/129] x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0

2017-05-11 Thread Greg Kroah-Hartman
-Yehuda Link: http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkov...@suse.cz Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/pci-calgary_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kerne

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

2017-05-11 Thread Greg Kroah-Hartman
-Yehuda Link: http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkov...@suse.cz Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/pci-calgary_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/pc

[PATCH 4.4 17/60] x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0

2017-05-11 Thread Greg Kroah-Hartman
-Yehuda Link: http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkov...@suse.cz Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/pci-calgary_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/pc

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

2014-06-09 Thread Greg Kroah-Hartman
3.14-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse Based on commit ea8ea460c9ace60bbb5ac6e5521d637d5c15293d upstream This missing IOTLB flush was added as a minor, inconsequential bug-fix in commit ea8ea460c ("iommu/vt-d: Clean

Re: [PATCH v2] iommu: Constify struct iommu_ops

2014-06-27 Thread Greg Kroah-Hartman
On Fri, Jun 27, 2014 at 09:03:12AM +0200, Thierry Reding wrote: > From: Thierry Reding > > This structure is read-only data and should never be modified. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - add missing hunk from include/device.h > Signed

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

2014-07-05 Thread Greg Kroah-Hartman
On Sat, Jul 05, 2014 at 12:03:08PM -0300, Ezequiel Garcia wrote: > After following Gregory's stacktrace (also reproduced here): > > [] (iommu_bus_notifier) from [] > (notifier_call_chain+0x64/0x9c) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x40/0x58) > [] (__blocking_n

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

2014-07-07 Thread Greg Kroah-Hartman
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): > > > &g

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

2014-07-07 Thread Greg Kroah-Hartman
On Mon, Jul 07, 2014 at 08:37:58PM -0300, Ezequiel Garcia wrote: > On 07 Jul 11:30 AM, Greg Kroah-Hartman wrote: > > On Mon, Jul 07, 2014 at 07:58:18AM -0300, Ezequiel Garcia wrote: > [..] > > > > > > I guess I snipped the thread and lost most of the info

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

2018-11-08 Thread Greg Kroah-Hartman
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/

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

2018-12-06 Thread Greg Kroah-Hartman
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

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

2018-12-12 Thread Greg Kroah-Hartman
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 ha

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

2019-01-22 Thread Greg Kroah-Hartman
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] dma: debug: no need to check return value of debugfs_create functions

2019-01-22 Thread Greg Kroah-Hartman
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 &

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

2019-01-29 Thread Greg Kroah-Hartman
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; > > + > > + /* > > +* Fo

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

2019-01-29 Thread Greg Kroah-Hartman
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 > mat

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

2019-02-01 Thread Greg Kroah-Hartman
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: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability

2019-02-11 Thread Greg Kroah-Hartman
users. Also rename the Kconfig option to describe the feature better. > > Signed-off-by: Christoph Hellwig Reviewed-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2019-02-11 Thread Greg Kroah-Hartman
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 09/12] dma-mapping: remove the DMA_MEMORY_EXCLUSIVE flag

2019-02-11 Thread Greg Kroah-Hartman
-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 07/12] dma-mapping: move CONFIG_DMA_CMA to kernel/dma/Kconfig

2019-02-11 Thread Greg Kroah-Hartman
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/RFC] driver core: Postpone DMA tear-down until after devres release

2019-03-07 Thread Greg Kroah-Hartman
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 thereafte

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

2020-02-18 Thread Greg Kroah-Hartman
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 onwards

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

2020-02-18 Thread Greg Kroah-Hartman
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: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device

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

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

2020-03-26 Thread Greg Kroah-Hartman
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 Kroah

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

2020-03-26 Thread Greg Kroah-Hartman
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 3/4] dma-mapping: add a dma_ops_bypass flag to struct device

2020-04-14 Thread Greg Kroah-Hartman
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 ___

[PATCH] drivers/iommu: properly export iommu_group_get_for_dev

2020-04-30 Thread Greg Kroah-Hartman
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 09/15] device core: Add ability to handle multiple dma offsets

2020-05-19 Thread Greg Kroah-Hartman
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: Lim

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

2020-05-20 Thread Greg Kroah-Hartman
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 > > &

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

2020-05-26 Thread Greg Kroah-Hartman
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

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

2020-05-26 Thread Greg Kroah-Hartman
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

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

2020-05-26 Thread Greg Kroah-Hartman
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

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

2020-05-26 Thread Greg Kroah-Hartman
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

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

2020-05-26 Thread Greg Kroah-Hartman
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

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Greg Kroah-Hartman
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? than

Re: [PATCH 2/2] iommu: calling pci_fixup_iommu in iommu_fwspec_init

2020-05-27 Thread Greg Kroah-Hartman
On Tue, May 26, 2020 at 07:49:09PM +0800, Zhangfei Gao wrote: > Calling pci_fixup_iommu in iommu_fwspec_init, which alloc > iommu_fwnode. Some platform devices appear as PCI but are > actually on the AMBA bus, and they need fixup in > drivers/pci/quirks.c handling iommu_fwnode. > So calling pci_fix

Re: [PATCH 1/2] PCI: Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Greg Kroah-Hartman
On Tue, May 26, 2020 at 11:09:57PM +0800, Zhangfei Gao wrote: > Hi, Christoph > > On 2020/5/26 下午10:46, Christoph Hellwig wrote: > > On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote: > > > Some platform devices appear as PCI but are actually on the AMBA bus, > > > and they need fixup i

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-15 Thread Greg Kroah-Hartman
On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain wrote: > This is needed to allow the userspace to determine when an untrusted > device has been added, and thus allowing it to bind the driver manually > to it, if it so wishes. This is being done as part of the approach > discussed at https://lk

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-17 Thread Greg Kroah-Hartman
On Wed, Jun 17, 2020 at 12:53:03PM -0700, Rajat Jain wrote: > Hi Greg, Christoph, > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote: > > > > On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote: > > > Need clarification. The flag "untrusted" is currently a part of > > > pci_dev s

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig > > wrote: > > ... > > > (and likely call it "external" instead of "untrusted". > > Which is not okay. 'External' to wha

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 12:14:41PM +0300, Andy Shevchenko wrote: > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > >

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

2012-08-08 Thread Greg Kroah-Hartman
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 > --- > fs/debugfs/inode.c |7 --- > include/linux/debugfs.h |9 - > 2 files changed, 12 insertions(+), 4

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

2012-08-15 Thread Greg Kroah-Hartman
On Wed, Aug 15, 2012 at 08:40:08AM +0300, Hiroshi Doyu wrote: > On Thu, 9 Aug 2012 14:56:24 +0200 > Hiroshi Doyu wrote: > > > Hi Greg, Felipe, > > > > On Wed, 8 Aug 2012 15:34:27 +0200 > > Greg Kroah-Hartman wrote: > > > > > On Wed, Aug

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

2014-08-25 Thread Greg Kroah-Hartman
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: [PATCH 0/2] iommu/vt-d: Keep RMRR mappings around on driver unbind

2014-10-01 Thread Greg Kroah-Hartman
stroyed > when the device is actually removed from the system. > > 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

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

2019-08-22 Thread Greg Kroah-Hartman
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 busse

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

2019-10-05 Thread Greg Kroah-Hartman
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 c

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

2019-10-10 Thread Greg Kroah-Hartman
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 dma_

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

2019-10-30 Thread Greg Kroah-Hartman
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 dma_

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

2019-10-30 Thread Greg Kroah-Hartman
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 runti

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

2019-10-30 Thread Greg Kroah-Hartman
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()

2019-10-30 Thread Greg Kroah-Hartman
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

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

2019-12-19 Thread Greg Kroah-Hartman
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 b

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

2019-12-19 Thread Greg Kroah-Hartman
> 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

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

2019-12-29 Thread Greg Kroah-Hartman
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

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

2019-12-29 Thread Greg Kroah-Hartman
d 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/

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

2020-01-07 Thread Greg Kroah-Hartman
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 function

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

2020-01-09 Thread Greg Kroah-Hartman
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: [PATCH v11 2/4] uacce: add uacce driver

2020-01-11 Thread Greg Kroah-Hartman
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 = xa_load(&ua

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

2020-01-14 Thread Greg Kroah-Hartman
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

2020-01-15 Thread Greg Kroah-Hartman
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 v12 2/4] uacce: add uacce driver

2020-02-10 Thread Greg Kroah-Hartman
ned-off-by: Kenneth Lee > 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?

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

2020-02-13 Thread Greg Kroah-Hartman
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 v2 09/16] driver core: add iommu device fault reporting data

2017-10-05 Thread Greg Kroah-Hartman
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 Acked-by: Greg Kroah-Hartman __

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

2017-10-06 Thread Greg Kroah-Hartman
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 driv

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

2017-12-18 Thread Greg Kroah-Hartman
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 > Signed-off-by: Jacob Pan > Li

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

2018-03-16 Thread Greg Kroah-Hartman
. > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Mark Brown > Acked-by: Robin Murphy Acked-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-03-16 Thread Greg Kroah-Hartman
. > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Mark Brown > Acked-by: Robin Murphy Acked-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-03-16 Thread Greg Kroah-Hartman
igned-off-by: Geert Uytterhoeven > Reviewed-by: Mark Brown > Acked-by: Robin Murphy > Acked-by: Felipe Balbi Acked-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-03-16 Thread Greg Kroah-Hartman
. > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Mark Brown > Acked-by: Robin Murphy > Acked-by: Felipe Balbi [drivers/usb/gadget/] Acked-by: Greg Kroah-Hartman ___ 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

2018-03-23 Thread Greg Kroah-Hartman
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 > Signed-off-by: Jacob Pan > Sig

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

2019-06-05 Thread Greg Kroah-Hartman
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. > > On

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

2019-06-12 Thread Greg Kroah-Hartman
-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 v2] driver: core: Allow subsystems to continue deferring probe

2019-06-14 Thread Greg Kroah-Hartman
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. > > On

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

2019-06-14 Thread Greg Kroah-Hartman
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

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

2019-07-04 Thread Greg Kroah-Hartman
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] omap-iommu: no need to check return value of debugfs_create functions

2019-07-04 Thread Greg Kroah-Hartman
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 5.2 202/215] iommu/vt-d: Dont queue_iova() if there is no flush queue

2019-07-29 Thread Greg Kroah-Hartman
va deferred flushing") 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 cha

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

2019-07-31 Thread Greg Kroah-Hartman
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 4.14 17/25] iommu/vt-d: Dont queue_iova() if there is no flush queue

2019-08-02 Thread Greg Kroah-Hartman
va deferred flushing") 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-o

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

2019-08-02 Thread Greg Kroah-Hartman
va deferred flushing") 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

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

2019-08-14 Thread Greg Kroah-Hartman
[ 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 domain_u

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

2019-08-15 Thread Greg Kroah-Hartman
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 fi

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

2019-08-15 Thread Greg Kroah-Hartman
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 busse

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

2019-08-15 Thread Greg Kroah-Hartman
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

2019-08-15 Thread Greg Kroah-Hartman
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 cons

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote: > Hello, > > On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko > wrote: > > > > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > > wrote: > > > > > > On Thu, Jun 18, 2020 at 11:12:5

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 10:23:38AM -0700, Rajat Jain wrote: > Thanks Greg and Andy for your continued inputs, and thanks Ashok for chiming > in. > > On Thu, Jun 18, 2020 at 9:23 AM Raj, Ashok wrote: > > > > Hi Greg, > > > > > > On Thu, Jun 18, 2020 at

Re: [PATCH 2/2] pci: Add parameter to disable attaching untrusted devices

2020-06-25 Thread Greg Kroah-Hartman
On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote: > Introduce a PCI parameter that disables the automatic attachment of > untrusted devices to their drivers. You didn't document this new api anywhere :( ___ iommu mailing list iommu@lists.linux-

  1   2   3   >