Re: [PATCH -next] drm/amdgpu: fix error return code in amdgpu_amdkfd_gpuvm_create_process_vm()

On Wed, Mar 28, 2018 at 4:20 PM, Wei Yongjun wrote: > Fix to return error code -ENOMEM from the eviction fence create fail > error handling case instead of 0, as done elsewhere in this function. > > Fixes: a46a2cd103a8 ("drm/amdgpu: Add GPUVM memory management functions

Re: [PATCH -next] drm/amdgpu: fix error return code in amdgpu_amdkfd_gpuvm_create_process_vm()

On Wed, Mar 28, 2018 at 4:20 PM, Wei Yongjun wrote: > Fix to return error code -ENOMEM from the eviction fence create fail > error handling case instead of 0, as done elsewhere in this function. > > Fixes: a46a2cd103a8 ("drm/amdgpu: Add GPUVM memory management functions for > KFD") >

Re: [PATCH] drm/amdkfd: fix uninitialized variable use

On Thu, Mar 15, 2018 at 6:49 PM, Arnd Bergmann wrote: > When CONFIG_ACPI is disabled, we never initialize the acpi_table > structure in kfd_create_crat_image_virtual: > > drivers/gpu/drm/amd/amdkfd/kfd_crat.c: In function > 'kfd_create_crat_image_virtual': >

Re: [PATCH] drm/amdkfd: fix uninitialized variable use

On Thu, Mar 15, 2018 at 6:49 PM, Arnd Bergmann wrote: > When CONFIG_ACPI is disabled, we never initialize the acpi_table > structure in kfd_create_crat_image_virtual: > > drivers/gpu/drm/amd/amdkfd/kfd_crat.c: In function > 'kfd_create_crat_image_virtual': >

Re: [PATCH] drm/amdkfd: Delete an error message for a failed memory allocation in kfd_topology_init()

On Thu, Feb 8, 2018 at 11:33 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 8 Feb 2018 22:23:57 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using

Re: [PATCH] drm/amdkfd: Delete an error message for a failed memory allocation in kfd_topology_init()

On Thu, Feb 8, 2018 at 11:33 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 8 Feb 2018 22:23:57 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring >

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Hi Gustavo, The patch is queued for the merge window of kernel 4.17 (opens in about 7 weeks from now). Oded On Wed, Feb 14, 2018 at 11:30 PM, Gustavo A. R. Silva wrote: > Hi all, > > I was just wondering about the status of this patch. > > Thanks > -- > Gustavo > > > On

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Hi Gustavo, The patch is queued for the merge window of kernel 4.17 (opens in about 7 weeks from now). Oded On Wed, Feb 14, 2018 at 11:30 PM, Gustavo A. R. Silva wrote: > Hi all, > > I was just wondering about the status of this patch. > > Thanks > -- > Gustavo > > > On 01/19/2018 04:18 PM,

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

On Sat, Jan 20, 2018 at 12:30 AM, Gustavo A. R. Silva wrote: > > Quoting Felix Kuehling : > >> Looks good. This change is Reviewed-by: Felix Kuehling >> >> > > Thanks Felix. > -- > Gustavo > Applied to -next Oded > > > >

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

On Sat, Jan 20, 2018 at 12:30 AM, Gustavo A. R. Silva wrote: > > Quoting Felix Kuehling : > >> Looks good. This change is Reviewed-by: Felix Kuehling >> >> > > Thanks Felix. > -- > Gustavo > Applied to -next Oded > > > >

Re: [PATCH v2] drm/amdkfd: Fix potential NULL pointer dereferences

ct kfd_dev > *dev) > mutex_lock(>mutex); > pdd = kfd_get_process_device_data(dev, p); > > + if (WARN_ON(!pdd)) { > + mutex_unlock(>mutex); > + continue; > + } > + >

Re: [PATCH v2] drm/amdkfd: Fix potential NULL pointer dereferences

gt; pdd = kfd_get_process_device_data(dev, p); > > + if (WARN_ON(!pdd)) { > + mutex_unlock(>mutex); > + continue; > + } > + > if (pdd->bound == PDD_BOUND) > pdd->bound = PDD_BOUND_SUSPENDED; > mutex_unlock(>mutex); > -- > 2.7.4 > This patch is: Reviewed-by: Oded Gabbay

Re: [PATCH] drm: fix amdkfd use-after-free GP fault

It was sent to Dave Airle (drm maintainer) to be included in 4.15-rc2 or 4.15-rc3 (depends when Dave will send his drm fixes). Oded On Wed, Nov 29, 2017 at 12:41 AM, Randy Dunlap <rdun...@infradead.org> wrote: > On 11/13/2017 08:09 AM, Oded Gabbay wrote: >> On Sat, Nov 11, 2017 at

Re: [PATCH] drm: fix amdkfd use-after-free GP fault

It was sent to Dave Airle (drm maintainer) to be included in 4.15-rc2 or 4.15-rc3 (depends when Dave will send his drm fixes). Oded On Wed, Nov 29, 2017 at 12:41 AM, Randy Dunlap wrote: > On 11/13/2017 08:09 AM, Oded Gabbay wrote: >> On Sat, Nov 11, 2017 at 8:16 AM, Randy Dunl

Re: [PATCH] pci: add class codes for processing accelerators

On Thu, Nov 23, 2017 at 4:11 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Thu, Nov 23, 2017 at 04:04:22PM +0200, Oded Gabbay wrote: >> Add PCI codes to include/linux/pci_ids.h for Processing Accelerators. There >> are new ASICs (now in development) for Deep Learn

Re: [PATCH] pci: add class codes for processing accelerators

On Thu, Nov 23, 2017 at 4:11 PM, Greg KH wrote: > On Thu, Nov 23, 2017 at 04:04:22PM +0200, Oded Gabbay wrote: >> Add PCI codes to include/linux/pci_ids.h for Processing Accelerators. There >> are new ASICs (now in development) for Deep Learning that will utilize this >> bas

[PATCH] pci: add class codes for processing accelerators

Add PCI codes to include/linux/pci_ids.h for Processing Accelerators. There are new ASICs (now in development) for Deep Learning that will utilize this base class. Signed-off-by: Oded Gabbay <oded.gab...@gmail.com> --- include/linux/pci_ids.h | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH] pci: add class codes for processing accelerators

Add PCI codes to include/linux/pci_ids.h for Processing Accelerators. There are new ASICs (now in development) for Deep Learning that will utilize this base class. Signed-off-by: Oded Gabbay --- include/linux/pci_ids.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux

Re: [PATCH] uapi: fix linux/kfd_ioctl.h userspace compilation errors

On Mon, Nov 13, 2017 at 2:35 AM, Dmitry V. Levin wrote: > Consistently use types provided by via > to fix the following linux/kfd_ioctl.h userspace compilation errors: > > /usr/include/linux/kfd_ioctl.h:236:2: error: unknown type name 'uint64_t' > uint64_t va_addr; /* to

Re: [PATCH] uapi: fix linux/kfd_ioctl.h userspace compilation errors

On Mon, Nov 13, 2017 at 2:35 AM, Dmitry V. Levin wrote: > Consistently use types provided by via > to fix the following linux/kfd_ioctl.h userspace compilation errors: > > /usr/include/linux/kfd_ioctl.h:236:2: error: unknown type name 'uint64_t' > uint64_t va_addr; /* to KFD */ >

Re: [PATCH] drm: fix amdkfd use-after-free GP fault

50 4d 85 c0 74 2b 48 8b 86 88 00 00 00 48 85 c0 74 25 <48> > 8b 08 0f be 7b 01 48 c7 c2 96 0a aa 97 31 c0 83 ef 30 e8 7f > [ 947.650339] RIP: __dev_printk+0x29/0x90 RSP: a51e409c7e48 > [ 947.650388] ---[ end trace c41965e147ae98ae ]--- > > Signed-off-by: Randy Dunlap <rdun

Re: [PATCH] drm: fix amdkfd use-after-free GP fault

000202 R12: > 7fff8740efc0 > [ 947.650314] R13: R14: 006231c0 R15: > 00623010 > [ 947.650316] Code: 00 00 55 49 89 d1 48 89 e5 53 48 89 fb 48 83 ec 18 48 85 > f6 74 5f 4c 8b 46 50 4d 85 c0 74 2b 48 8b 86 88 00 00 00 48 85 c0 74 25 <48

[PATCH] microblaze: add missing include to mmu_context_mm.h

of linux/sched.h to mmu_context_mm.h to avoid such errors. Signed-off-by: Oded Gabbay <oded.gab...@gmail.com> --- arch/microblaze/include/asm/mmu_context_mm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/microblaze/include/asm/mmu_context_mm.h b/arch/microblaze/inclu

[PATCH] microblaze: add missing include to mmu_context_mm.h

of linux/sched.h to mmu_context_mm.h to avoid such errors. Signed-off-by: Oded Gabbay --- arch/microblaze/include/asm/mmu_context_mm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/microblaze/include/asm/mmu_context_mm.h b/arch/microblaze/include/asm/mmu_context_mm.h index

Re: [PATCH] sparc64: mmu_context: Add missing include files

34315e1f0ed 100644 > --- a/arch/sparc/include/asm/mmu_context_64.h > +++ b/arch/sparc/include/asm/mmu_context_64.h > @@ -7,9 +7,11 @@ > > #include > #include > +#include > > #include > #include > +#include > > static inline void enter_lazy_tlb(struct mm_str

Re: [PATCH] sparc64: mmu_context: Add missing include files

ontext_64.h > +++ b/arch/sparc/include/asm/mmu_context_64.h > @@ -7,9 +7,11 @@ > > #include > #include > +#include > > #include > #include > +#include > > static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct > *tsk) > {

Re: [PATCH] drm/amdkfd: check for null dev to avoid a null pointer dereference

On Fri, Sep 8, 2017 at 5:13 PM, Colin King wrote: > From: Colin Ian King > > The call to kfd_device_by_id can potentially return null, so check that > dev is null and return with -EINVAL to avoid a null pointer dereference. > > Detected by

Re: [PATCH] drm/amdkfd: check for null dev to avoid a null pointer dereference

On Fri, Sep 8, 2017 at 5:13 PM, Colin King wrote: > From: Colin Ian King > > The call to kfd_device_by_id can potentially return null, so check that > dev is null and return with -EINVAL to avoid a null pointer dereference. > > Detected by CoverityScan CID#1454629 ("Dereference null return

Re: [PATCH] drm/amdkfd: remove memset before memcpy

On Tue, Aug 29, 2017 at 10:03 PM, Himanshu Jha wrote: > calling memcpy immediately after memset with the same region of memory > makes memset redundant. > > Signed-off-by: Himanshu Jha > --- >

Re: [PATCH] drm/amdkfd: remove memset before memcpy

On Tue, Aug 29, 2017 at 10:03 PM, Himanshu Jha wrote: > calling memcpy immediately after memset with the same region of memory > makes memset redundant. > > Signed-off-by: Himanshu Jha > --- > drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 1 - > 1 file changed, 1 deletion(-) > > diff

Re: [PATCH v06 36/36] uapi linux/kfd_ioctl.h: use __u32 and __u64 instead of uint32_t and uint64_t

ixes user space compilation errors like: >> >> linux/kfd_ioctl.h:33:2: error: unknown type name ‘uint32_t’ >> uint32_t major_version; /* from KFD */ >> ^~~~ >> >> Signed-off-by: Mikko Rapeli <mikko.rap...@iki.fi> >> Cc: Yair Shachar <yair.shac

Re: [PATCH v06 36/36] uapi linux/kfd_ioctl.h: use __u32 and __u64 instead of uint32_t and uint64_t

>> linux/kfd_ioctl.h:33:2: error: unknown type name ‘uint32_t’ >> uint32_t major_version; /* from KFD */ >> ^~~~ >> >> Signed-off-by: Mikko Rapeli >> Cc: Yair Shachar >> Cc: Oded Gabbay >> Cc: Andrew Lewycky > > Looks good to me, > > Acked-by: Arnd Bergmann Thanks! Applied to amdkfd -next tree Oded

Re: [PATCH trivial] drm/amdkfd: Spelling s/apreture/aperture/

On Thu, Jun 1, 2017 at 1:28 PM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH trivial] drm/amdkfd: Spelling s/apreture/aperture/

On Thu, Jun 1, 2017 at 1:28 PM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c >

Re: [PATCH] amdkfd: fix spelling mistake in kfd_ioctl_dbg_unrgesiter

On Sat, Nov 12, 2016 at 7:33 PM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake, rename kfd_ioctl_dbg_unrgesiter > to kfd_ioctl_dbg_unregister > > Signed-off-by: Colin Ian King > --- >

Re: [PATCH] amdkfd: fix spelling mistake in kfd_ioctl_dbg_unrgesiter

On Sat, Nov 12, 2016 at 7:33 PM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake, rename kfd_ioctl_dbg_unrgesiter > to kfd_ioctl_dbg_unregister > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 6 +++--- > 1 file changed, 3

Re: [PATCH] drm/amdkfd: print doorbell offset as a hex value

On Wed, Jul 13, 2016 at 10:36 AM, Colin King wrote: > From: Colin Ian King > > The doorbell offset is formatted with a 0x prefix to suggest it is > a hexadecimal value, when in fact %d is being used and this is confusing. > Use %X instead to

Re: [PATCH] drm/amdkfd: print doorbell offset as a hex value

On Wed, Jul 13, 2016 at 10:36 AM, Colin King wrote: > From: Colin Ian King > > The doorbell offset is formatted with a 0x prefix to suggest it is > a hexadecimal value, when in fact %d is being used and this is confusing. > Use %X instead to match the proceeding 0x prefix. > > Signed-off-by:

Re: [RFT v3] drm: use late_initcall() for amdkfd and radeon

On Tue, May 31, 2016 at 8:15 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > On Sun, May 29, 2016 at 05:49:17PM +0300, Oded Gabbay wrote: >> On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: >> > diff --git a/drivers/gpu/drm/radeon/ra

Re: [RFT v3] drm: use late_initcall() for amdkfd and radeon

On Tue, May 31, 2016 at 8:15 PM, Luis R. Rodriguez wrote: > On Sun, May 29, 2016 at 05:49:17PM +0300, Oded Gabbay wrote: >> On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez wrote: >> > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c >> > b/drivers/gpu/drm/rad

Re: [PATCH v3] gpu: drm: amd: amdkfd: Remove create_workqueue()

On Sun, May 29, 2016 at 6:44 PM, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > create_workqueue has been replaced with alloc_workqueue with max_active > as 0 since there is no need for throttling the number of active work items.

Re: [PATCH v3] gpu: drm: amd: amdkfd: Remove create_workqueue()

On Sun, May 29, 2016 at 6:44 PM, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > create_workqueue has been replaced with alloc_workqueue with max_active > as 0 since there is no need for throttling the number of active work items. > > WQ_MEM_RECLAIM has

Re: [PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

On Thu, May 26, 2016 at 10:37 PM, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > create_workqueue has been replaced with alloc_workqueue with max_active > as 0 since there is no need for throttling the number of active work

Re: [PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

On Thu, May 26, 2016 at 10:37 PM, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > create_workqueue has been replaced with alloc_workqueue with max_active > as 0 since there is no need for throttling the number of active work items. > > WQ_MEM_RECLAIM has

Re: [RFT v3] drm: use late_initcall() for amdkfd and radeon

On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez wrote: > To get KFD support in radeon we need the following > initialization to happen in this order, their > respective driver file that has its init routine > listed next to it: > > 0. AMD IOMMUv1:

Re: [RFT v3] drm: use late_initcall() for amdkfd and radeon

On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez wrote: > To get KFD support in radeon we need the following > initialization to happen in this order, their > respective driver file that has its init routine > listed next to it: > > 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c > 1. AMD IOMMUv2:

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Mon, Apr 18, 2016 at 9:55 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > > On Apr 18, 2016 7:48 AM, "Oded Gabbay" <oded.gab...@gmail.com> wrote: >> >> On Wed, Apr 13, 2016 at 1:07 AM, Luis R. Rodriguez <mcg...@kernel.org> >> wrote: >

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Mon, Apr 18, 2016 at 9:55 AM, Luis R. Rodriguez wrote: > > On Apr 18, 2016 7:48 AM, "Oded Gabbay" wrote: >> >> On Wed, Apr 13, 2016 at 1:07 AM, Luis R. Rodriguez >> wrote: >> > On Mon, Apr 11, 2016 at 03:52:43PM +0200, Christian König wrote: >&

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Wed, Apr 13, 2016 at 1:07 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > On Mon, Apr 11, 2016 at 03:52:43PM +0200, Christian König wrote: >> Am 11.04.2016 um 15:39 schrieb Oded Gabbay: >> >On Mon, Apr 11, 2016 at 4:28 PM, Christian König >> ><chri

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Wed, Apr 13, 2016 at 1:07 AM, Luis R. Rodriguez wrote: > On Mon, Apr 11, 2016 at 03:52:43PM +0200, Christian König wrote: >> Am 11.04.2016 um 15:39 schrieb Oded Gabbay: >> >On Mon, Apr 11, 2016 at 4:28 PM, Christian König >> > wrote: >> >>Am 09.04.

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

gt; This reverts the old work around implemented through commit >>> 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in Makefile"), >>> instead of making the dependency implicit by linker order this >>> makes the ordering requirement explicit through p

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

ough commit >>> 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in Makefile"), >>> instead of making the dependency implicit by linker order this >>> makes the ordering requirement explicit through proper kernel >>> APIs. >>> >>>

Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown()

On Thu, Mar 17, 2016 at 4:37 PM, Jerome Glisse wrote: > On Wed, Mar 16, 2016 at 05:10:34PM +, Olu Ogunbowale wrote: >> From: Olujide Ogunbowale >> >> Export the memory management functions, unmapped_area() & >> unmapped_area_topdown(), as GPL

Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown()

On Thu, Mar 17, 2016 at 4:37 PM, Jerome Glisse wrote: > On Wed, Mar 16, 2016 at 05:10:34PM +, Olu Ogunbowale wrote: >> From: Olujide Ogunbowale >> >> Export the memory management functions, unmapped_area() & >> unmapped_area_topdown(), as GPL symbols; this allows the kernel to >> better

Re: [RFT] iommu/amd: use subsys_initcall() on amdv2 iommu

On Wed, Mar 16, 2016 at 12:14 PM, Joerg Roedel <j...@8bytes.org> wrote: > On Wed, Mar 16, 2016 at 09:02:43AM +0200, Oded Gabbay wrote: >> fwiw, we currently have this covered by the ugly hack of putting iommu >> subsystem in front of gpu subsystem in the main

Re: [RFT] iommu/amd: use subsys_initcall() on amdv2 iommu

On Wed, Mar 16, 2016 at 12:14 PM, Joerg Roedel wrote: > On Wed, Mar 16, 2016 at 09:02:43AM +0200, Oded Gabbay wrote: >> fwiw, we currently have this covered by the ugly hack of putting iommu >> subsystem in front of gpu subsystem in the main driver

Re: [RFT] iommu/amd: use subsys_initcall() on amdv2 iommu

On Wed, Mar 16, 2016 at 12:12 AM, Luis R. Rodriguez wrote: > We need to ensure amd iommu v2 initializes before > driver uses such as drivers/gpu/drm/amd/amdkfd/kfd_module.c, > to do this make its init routine a subsys_initcall() which > ensures its load init is called first

Re: [RFT] iommu/amd: use subsys_initcall() on amdv2 iommu

On Wed, Mar 16, 2016 at 12:12 AM, Luis R. Rodriguez wrote: > We need to ensure amd iommu v2 initializes before > driver uses such as drivers/gpu/drm/amd/amdkfd/kfd_module.c, > to do this make its init routine a subsys_initcall() which > ensures its load init is called first than modules when >

Re: [RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use

On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes wrote: > Passing overlapping source and destination buffers to snprintf > formally has undefined behaviour and is rather fragile. While the > rather special case of passing the output buffer as the argument >

Re: [RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use

On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes wrote: > Passing overlapping source and destination buffers to snprintf > formally has undefined behaviour and is rather fragile. While the > rather special case of passing the output buffer as the argument > corresponding to a leading "%s" in the

Re: [patch] drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers()

On Fri, Mar 11, 2016 at 9:51 AM, Dan Carpenter wrote: > At the end of the function we expect "status" to be zero, but it's > either -EINVAL or unitialized. > > Fixes: 788bf83db301 ('drm/amdkfd: Add wave control operation to debugger') > Signed-off-by: Dan Carpenter

Re: [patch] drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers()

On Fri, Mar 11, 2016 at 9:51 AM, Dan Carpenter wrote: > At the end of the function we expect "status" to be zero, but it's > either -EINVAL or unitialized. > > Fixes: 788bf83db301 ('drm/amdkfd: Add wave control operation to debugger') > Signed-off-by: Dan Carpenter > > diff --git

Re: [PATCH] gpu: drm: amd: amdkfd: Remove unnecessary cast in kfree

On Mon, Jan 25, 2016 at 7:33 PM, Amitoj Kaur Chawla wrote: > Remove an unnecassary cast in the argument to kfree. > > Found using Coccinelle. The semantic patch used to find this is as follows: > > // > @@ > type T; > expression *f; > @@ > > - kfree((T *)(f)); > + kfree(f); > // > >

Re: [PATCH] drm/amdgpu: fix non-ANSI declaration of amdgpu_amdkfd_gfx_*_get_functions()

On Fri, Jan 22, 2016 at 7:35 PM, Colin King wrote: > From: Colin Ian King > > amdgpu_amdkfd_gfx_7_get_functions and amdgpu_amdkfd_gfx_8_0_get_functions > have no parameters, so use the normal void parameter convention to make > them match their prototypes in the header file >

Re: [PATCH] gpu: drm: amd: amdkfd: Remove unnecessary cast in kfree

On Mon, Jan 25, 2016 at 7:33 PM, Amitoj Kaur Chawla wrote: > Remove an unnecassary cast in the argument to kfree. > > Found using Coccinelle. The semantic patch used to find this is as follows: > > // > @@ > type T; > expression *f; > @@ > > - kfree((T *)(f)); > + kfree(f);

Re: [PATCH] drm/amdgpu: fix non-ANSI declaration of amdgpu_amdkfd_gfx_*_get_functions()

On Fri, Jan 22, 2016 at 7:35 PM, Colin King wrote: > From: Colin Ian King > > amdgpu_amdkfd_gfx_7_get_functions and amdgpu_amdkfd_gfx_8_0_get_functions > have no parameters, so use the normal void parameter convention to make > them match

Re: [PATCH 0/4 v2] Implement access checks in iommu page fault paths

On Tue, Nov 17, 2015 at 5:11 PM, Joerg Roedel wrote: > Hi, > > here is the second version of the patch-set to implement > proper access checks into the io-page-fault handlers of the > AMD IOMMU and Intel VT-d drivers. > > Two additional patches clean up the AMD part a bit further. > Since I can't

Re: [PATCH 0/4 v2] Implement access checks in iommu page fault paths

On Tue, Nov 17, 2015 at 5:11 PM, Joerg Roedel wrote: > Hi, > > here is the second version of the patch-set to implement > proper access checks into the io-page-fault handlers of the > AMD IOMMU and Intel VT-d drivers. > > Two additional patches clean up the AMD part a bit

Re: [PATCH 3/9] amdkfd: use instead of

On Fri, Aug 28, 2015 at 10:27 AM, Christoph Hellwig wrote: > > The latter is a default version of and not for driver use. > > Signed-off-by: Christoph Hellwig > --- > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 2 +- > 2 files changed,

Re: [PATCH 3/9] amdkfd: use linux/mman.h instead of uapi/asm-generic/mman-common.h

On Fri, Aug 28, 2015 at 10:27 AM, Christoph Hellwig h...@lst.de wrote: The latter is a default version of asm/mman.h and not for driver use. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c |

Re: [PATCH 0/5] AMD IOMMU Fixes for v4.2-rc4

+-- > 3 files changed, 45 insertions(+), 80 deletions(-) > > -- > 1.9.1 > > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu This series, with the additional patch, is: Tested-by: &q

Re: [PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

s.qdep; > iommu = amd_iommu_rlookup_table[dev_data->devid]; > -- > 1.9.1 > This series, with the additional patch is: Tested-by: "Oded Gabbay " -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

Joerg, Why amdkfd's devices are considered a non-IOMMUv2 capable devices ? After all, they contain the IOMMUv2 H/W and use it constantly for HSA. ODed On Thu, Jul 30, 2015 at 1:05 PM, Joerg Roedel wrote: > From: Joerg Roedel > > With the grouping of multi-function devices a non-ATS > capable

Re: [PATCH 0/5] AMD IOMMU Fixes for v4.2-rc4

Hi Joerg, I tested your patches on Kaveri, and while they do fix the initial setup between amdkfd and IOMMU, the kernel crashes when an HSA process tries to do any simple action that involves the kernel, such as to create a compute queue. So while I suppose the above patches should be included,

Re: [PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

Joerg, Why amdkfd's devices are considered a non-IOMMUv2 capable devices ? After all, they contain the IOMMUv2 H/W and use it constantly for HSA. ODed On Thu, Jul 30, 2015 at 1:05 PM, Joerg Roedel j...@8bytes.org wrote: From: Joerg Roedel jroe...@suse.de With the grouping of multi-function

Re: [PATCH 0/5] AMD IOMMU Fixes for v4.2-rc4

___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu This series, with the additional patch, is: Tested-by: Oded Gabbay oded.gab...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

This series, with the additional patch is: Tested-by: Oded Gabbay oded.gab...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: [PATCH 0/5] AMD IOMMU Fixes for v4.2-rc4

Hi Joerg, I tested your patches on Kaveri, and while they do fix the initial setup between amdkfd and IOMMU, the kernel crashes when an HSA process tries to do any simple action that involves the kernel, such as to create a compute queue. So while I suppose the above patches should be included,

Re: [PATCH v2] drm/amdkfd: validate pdd where it acquired first

On Thu, Jul 9, 2015 at 12:11 PM, Maninder Singh wrote: > Currently pdd is validate after dereferencing it, which is > not correct, Thus validate pdd before its first use. > > Signed-off-by: Maninder Singh > --- > v1: remove validation of pdd after its usage > v2: do validation at first place

Re: [RFC][PATCH 1/1] drm/amdkfd: Remove redundant pdd validation

On Mon, Jun 29, 2015 at 7:33 AM, Maninder Singh wrote: > > pdd is already dereferenced before this check. > So it is redundtant to validate pdd here. > > Signed-off-by: Maninder Singh > --- > drivers/gpu/drm/amd/amdkfd/kfd_process.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) >

Re: [RFC][PATCH 1/1] drm/amdkfd: Remove redundant pdd validation

On Mon, Jun 29, 2015 at 7:33 AM, Maninder Singh maninder...@samsung.com wrote: pdd is already dereferenced before this check. So it is redundtant to validate pdd here. Signed-off-by: Maninder Singh maninder...@samsung.com --- drivers/gpu/drm/amd/amdkfd/kfd_process.c |3 +-- 1 file

Re: [PATCH v2] drm/amdkfd: validate pdd where it acquired first

On Thu, Jul 9, 2015 at 12:11 PM, Maninder Singh maninder...@samsung.com wrote: Currently pdd is validate after dereferencing it, which is not correct, Thus validate pdd before its first use. Signed-off-by: Maninder Singh maninder...@samsung.com --- v1: remove validation of pdd after its

Re: [patch] drm/amdkfd: fix some range checks in address watch ioctl

On Thu, Jun 11, 2015 at 6:19 PM, Dan Carpenter wrote: > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > index 96c904b..54a608a 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c > @@

Re: [patch] drm/amdkfd: fix some range checks in address watch ioctl

On Thu, Jun 11, 2015 at 6:19 PM, Dan Carpenter dan.carpen...@oracle.com wrote: diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c index 96c904b..54a608a 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +++

Re: [patch] drm/amdkfd: fix some range checks in address watch ioctl

On Thu, Jun 11, 2015 at 6:19 PM, Dan Carpenter wrote: > #include "kfd_dbgmgr.h" > +#include "../../radeon/cik_reg.h" > > static long kfd_ioctl(struct file *, unsigned int, unsigned long); We can't include radeon files in kfd_chardev.c, because amdkfd works with two device drivers - radeon and

Re: [patch] drm/amdkfd: fix some range checks in address watch ioctl

On Thu, Jun 11, 2015 at 6:19 PM, Dan Carpenter dan.carpen...@oracle.com wrote: #include kfd_dbgmgr.h +#include ../../radeon/cik_reg.h static long kfd_ioctl(struct file *, unsigned int, unsigned long); We can't include radeon files in kfd_chardev.c, because amdkfd works with two device

Re: [PATCH] drm/amdkfd: avoid CONFIG_ prefix for non-Kconfig symbols

On Fri, Jun 5, 2015 at 11:27 AM, Valentin Rothberg wrote: > The CONFIG_ prefix is reserved for Kconfig options in Make and CPP > syntax. Various static analysis tools rely on this naming convention > and check if CONFIG_ prefixed symbols are defined Kconfig. Hence add > yet another prefix AMD_

Re: [PATCH] drm/amdkfd: avoid CONFIG_ prefix for non-Kconfig symbols

On Fri, Jun 5, 2015 at 11:27 AM, Valentin Rothberg valentinrothb...@gmail.com wrote: The CONFIG_ prefix is reserved for Kconfig options in Make and CPP syntax. Various static analysis tools rely on this naming convention and check if CONFIG_ prefixed symbols are defined Kconfig. Hence add

Re: [PATCH 03/12] drm/amdkfd: Use DECLARE_BITMAP

On Wed, May 20, 2015 at 4:37 AM, Joe Perches wrote: > Use the generic mechanism to declare a bitmap instead of unsigned long. > > It seems that "struct kfd_process.allocated_queue_bitmap" is unused. > Maybe it could be deleted instead. > > Signed-off-by: Joe Perches > --- >

Re: linux-next: build failure after merge of the drm tree

On Wed, May 20, 2015 at 8:31 AM, Stephen Rothwell wrote: > Hi Dave, > > On Wed, 20 May 2015 15:25:38 +1000 Stephen Rothwell > wrote: >> >> On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie >> wrote: >> > >> > > After merging the drm tree, today's linux-next build (powerpc >> > >

Re: [PATCH 03/12] drm/amdkfd: Use DECLARE_BITMAP

On Wed, May 20, 2015 at 4:37 AM, Joe Perches j...@perches.com wrote: Use the generic mechanism to declare a bitmap instead of unsigned long. It seems that struct kfd_process.allocated_queue_bitmap is unused. Maybe it could be deleted instead. Signed-off-by: Joe Perches j...@perches.com ---

Re: linux-next: build failure after merge of the drm tree

On Wed, May 20, 2015 at 8:31 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Dave, On Wed, 20 May 2015 15:25:38 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie airl...@linux.ie wrote: After merging the drm tree, today's

[PATCH] drm/amdkfd: Don't report local memory size

cal memory for HSA, we need this patch. Cc: sta...@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/

[PATCH] drm/amdkfd: Don't report local memory size

for HSA, we need this patch. Cc: sta...@vger.kernel.org Reviewed-by: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Oded Gabbay oded.gab...@gmail.com --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd

[PATCH] MAINTAINERS: update amdkfd Oded's email address

Leaving AMD soon so need to update my email address to @gmail.com Signed-off-by: Oded Gabbay --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 781e099..d68df93 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -631,7 +631,7 @@ F

[PATCH] MAINTAINERS: update amdkfd Oded's email address

Leaving AMD soon so need to update my email address to @gmail.com Signed-off-by: Oded Gabbay oded.gab...@gmail.com --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 781e099..d68df93 100644 --- a/MAINTAINERS +++ b/MAINTAINERS

Re: [git pull] IOMMU Updates for Linux v4.1

On Tue, May 5, 2015 at 9:22 PM, Josh Boyer wrote: > On Sun, May 3, 2015 at 2:18 AM, Oded Gabbay wrote: >> >> >> On 05/03/2015 01:14 AM, Joerg Roedel wrote: >>> >>> Hi Oded, >>> >>> On Sat, May 02, 2015 at 07:59:39PM +0300, Oded Gabbay w

Re: [git pull] IOMMU Updates for Linux v4.1

On Tue, May 5, 2015 at 9:22 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Sun, May 3, 2015 at 2:18 AM, Oded Gabbay oded.gab...@amd.com wrote: On 05/03/2015 01:14 AM, Joerg Roedel wrote: Hi Oded, On Sat, May 02, 2015 at 07:59:39PM +0300, Oded Gabbay wrote: However, Joerg

Re: [git pull] IOMMU Updates for Linux v4.1

On 05/03/2015 01:14 AM, Joerg Roedel wrote: Hi Oded, On Sat, May 02, 2015 at 07:59:39PM +0300, Oded Gabbay wrote: However, Joerg is not answering my emails for some reason (vacation/sick?) Sorry, I was travelling for the last 3 weeks and had bad internet access. But I am back and will take

Re: [git pull] IOMMU Updates for Linux v4.1

On 05/03/2015 01:14 AM, Joerg Roedel wrote: Hi Oded, On Sat, May 02, 2015 at 07:59:39PM +0300, Oded Gabbay wrote: However, Joerg is not answering my emails for some reason (vacation/sick?) Sorry, I was travelling for the last 3 weeks and had bad internet access. But I am back and will take

<    5   6   7   8   9   10   11   12   13   14   >