Re: [PATCH v2] Remove sparse warnings in mdc_request.c

[Greg KH]

On Mon, Apr 03, 2017 at 10:25:37PM -0700, skanda.kash...@gmail.com wrote:
> From: Skanda Guruanand 
> 
> Signed-off-by: Skanda Guruanand 
> 
> I have modified  struct lu_dirpage as suggested in lustre_idl.h file
> 
> CHECK   drivers/staging/lustre/lustre/mdc/mdc_request.c
> drivers/staging/lustre/lustre/mdc/mdc_request.c:958:42: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:959:42: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:962:42: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:963:42: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:985:50: warning: cast
> to restricted __le32
> drivers/staging/lustre/lustre/mdc/mdc_request.c:1193:24: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:1328:25: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:1329:23: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:1332:25: warning: cast
> to restricted __le64
> drivers/staging/lustre/lustre/mdc/mdc_request.c:1333:23: warning: cast
> to restricted __le64
> 
> ---
>  drivers/staging/lustre/lustre/include/lustre/lustre_idl.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

What changed from v1?

Always put that here below the --- line.

v3?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] Remove sparse warnings in mdc_request.c

[skanda . kashyap]

From: Skanda Guruanand 

Signed-off-by: Skanda Guruanand 

I have modified  struct lu_dirpage as suggested in lustre_idl.h file

CHECK   drivers/staging/lustre/lustre/mdc/mdc_request.c
drivers/staging/lustre/lustre/mdc/mdc_request.c:958:42: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:959:42: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:962:42: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:963:42: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:985:50: warning: cast
to restricted __le32
drivers/staging/lustre/lustre/mdc/mdc_request.c:1193:24: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:1328:25: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:1329:23: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:1332:25: warning: cast
to restricted __le64
drivers/staging/lustre/lustre/mdc/mdc_request.c:1333:23: warning: cast
to restricted __le64

---
 drivers/staging/lustre/lustre/include/lustre/lustre_idl.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 60b827e..df48b8d 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -846,10 +846,10 @@ struct luda_type {
 #endif
 
 struct lu_dirpage {
-   __u64   ldp_hash_start;
-   __u64   ldp_hash_end;
-   __u32   ldp_flags;
-   __u32   ldp_pad0;
+   __le64  ldp_hash_start;
+   __le64  ldp_hash_end;
+   __le32  ldp_flags;
+   __le32  ldp_pad0;
struct lu_dirent ldp_entries[0];
 };
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] remove custom Michael MIC implementation

[Tobin C. Harding]

On Mon, Apr 03, 2017 at 12:15:15PM +0200, Arend Van Spriel wrote:
> seems we are missing out again?

Sorry, I don't understand what this comment means?

> On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote:
> > "Tobin C. Harding"  writes:
> > 
> >> Except one: do you know off the top of your head of a canonical
> >> implementation of a softmac wi-fi driver.
> > 
> > I'll suggest taking a look at the ath9k driver :)
> 
> Looking at ks7010 driver it looks like it has 802.11 stack in firmware
> and not sure if Renesas is actively supporting this effort to come up
> with mac80211-friendly firmware or provide detailed chip info.

Thanks for taking a look. If the ks7010 driver has 802.11 stack in
firmware does that mean it is not compatible with using the kernel
mac80211 stack with the current firmware? I do not have my hopes up
about getting any chip information out of Renesas, all I think we have
to go in is the current WEXT driver.

This is an exercise in learning for me, but I do not want to take any
ones time up with a project that is not that useful. Is getting the
ks7010 driver out of staging something that is of use to the kernel
community or are there other wi-fi tasks that our time is better spent
on?

thanks,
Tobin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: lustre cleanup macros in libcfs_private.h

[Craig Inches]

This resolves a checkpatch warning that "Single statement macros should
not use a do {} while (0) loop" by removing the loop and adjusting line
length accordingly.

Signed-off-by: Craig Inches 
---
 .../lustre/include/linux/libcfs/libcfs_private.h   | 51 +++---
 1 file changed, 15 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
index 2dae857..150454f 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
@@ -87,12 +87,9 @@ do { 
\
 #define LIBCFS_VMALLOC_SIZE(2 << PAGE_SHIFT) /* 2 pages */
 #endif
 
-#define LIBCFS_ALLOC_PRE(size, mask)   \
-do {   \
-   LASSERT(!in_interrupt() ||  \
-   ((size) <= LIBCFS_VMALLOC_SIZE &&   \
-!gfpflags_allow_blocking(mask)));  \
-} while (0)
+#define LIBCFS_ALLOC_PRE(size, mask)   \
+   LASSERT(!in_interrupt() || ((size) <= LIBCFS_VMALLOC_SIZE   \
+   && !gfpflags_allow_blocking(mask)))
 
 #define LIBCFS_ALLOC_POST(ptr, size)   \
 do {   \
@@ -187,46 +184,28 @@ void  cfs_array_free(void *vars);
 #if LASSERT_ATOMIC_ENABLED
 
 /** assert value of @a is equal to @v */
-#define LASSERT_ATOMIC_EQ(a, v) \
-do {   \
-   LASSERTF(atomic_read(a) == v,  \
-"value: %d\n", atomic_read((a)));\
-} while (0)
+#define LASSERT_ATOMIC_EQ(a, v) LASSERTF(atomic_read(a) == v,  \
+"value: %d\n", atomic_read((a)))
 
 /** assert value of @a is unequal to @v */
-#define LASSERT_ATOMIC_NE(a, v) \
-do {   \
-   LASSERTF(atomic_read(a) != v,  \
-"value: %d\n", atomic_read((a)));\
-} while (0)
+#define LASSERT_ATOMIC_NE(a, v) LASSERTF(atomic_read(a) != v,  \
+"value: %d\n", atomic_read((a)))
 
 /** assert value of @a is little than @v */
-#define LASSERT_ATOMIC_LT(a, v) \
-do {   \
-   LASSERTF(atomic_read(a) < v,\
-"value: %d\n", atomic_read((a)));\
-} while (0)
+#define LASSERT_ATOMIC_LT(a, v) LASSERTF(atomic_read(a) < v,   \
+"value: %d\n", atomic_read((a)))
 
 /** assert value of @a is little/equal to @v */
-#define LASSERT_ATOMIC_LE(a, v) \
-do {   \
-   LASSERTF(atomic_read(a) <= v,  \
-"value: %d\n", atomic_read((a)));\
-} while (0)
+#define LASSERT_ATOMIC_LE(a, v) LASSERTF(atomic_read(a) <= v,  \
+"value: %d\n", atomic_read((a)))
 
 /** assert value of @a is great than @v */
-#define LASSERT_ATOMIC_GT(a, v) \
-do {   \
-   LASSERTF(atomic_read(a) > v,\
-"value: %d\n", atomic_read((a)));\
-} while (0)
+#define LASSERT_ATOMIC_GT(a, v) LASSERTF(atomic_read(a) > v,   \
+"value: %d\n", atomic_read((a)))
 
 /** assert value of @a is great/equal to @v */
-#define LASSERT_ATOMIC_GE(a, v) \
-do {   \
-   LASSERTF(atomic_read(a) >= v,  \
-"value: %d\n", atomic_read((a)));\
-} while (0)
+#define LASSERT_ATOMIC_GE(a, v) LASSERTF(atomic_read(a) >= v,  \
+"value: %d\n", atomic_read((a)))
 
 /** assert value of @a is great than @v1 and little than @v2 */
 #define LASSERT_ATOMIC_GT_LT(a, v1, v2) \
-- 
2.10.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 22/22] staging/android: Update Ion TODO list

[Laura Abbott]

Most of the items have been taken care of by a clean up series. Remove
the completed items and add a few new ones.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/TODO | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 8f3ac37..5f14247 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -7,23 +7,10 @@ TODO:
 
 
 ion/
- - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel internal
-   interface on top of dma-buf. flush_for_device needs to be added to dma-buf
-   first.
- - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some
-   vendor trees. Should be replaced with an ioctl on the dma-buf to expose the
-   begin/end_cpu_access hooks to userspace.
- - Clarify the tricks ion plays with explicitly managing coherency behind the
-   dma api's back (this is absolutely needed for high-perf gpu drivers): Add an
-   explicit coherency management mode to flush_for_device to be used by drivers
-   which want to manage caches themselves and which indicates whether cpu 
caches
-   need flushing.
- - With those removed there's probably no use for ION_IOC_IMPORT anymore either
-   since ion would just be the central allocator for shared buffers.
- - Add dt-binding to expose cma regions as ion heaps, with the rule that any
-   such cma regions must already be used by some device for dma. I.e. ion only
-   exposes existing cma regions and doesn't reserve unecessarily memory when
-   booting a system which doesn't use ion.
+ - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
+   involve putting appropriate bindings in a memory node for Ion to find.
+ - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
+ - Better test framework (integration with VGEM was suggested)
 
 Please send patches to Greg Kroah-Hartman  and Cc:
 Arve Hjønnevåg  and Riley Andrews 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 21/22] staging: android: ion: Set query return value

[Laura Abbott]

This never got set in the ioctl. Properly set a return value of 0 on
success.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 9eeb06f..d6fd350 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -498,6 +498,7 @@ int ion_query_heaps(struct ion_heap_query *query)
}
 
query->cnt = cnt;
+   ret = 0;
 out:
up_read(>lock);
return ret;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 19/22] staging: android: ion: Drop ion_map_kernel interface

[Laura Abbott]

Nobody uses this interface externally. Drop it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 59 ---
 1 file changed, 59 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 7d40233..5a82bea 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -424,22 +424,6 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
return vaddr;
 }
 
-static void *ion_handle_kmap_get(struct ion_handle *handle)
-{
-   struct ion_buffer *buffer = handle->buffer;
-   void *vaddr;
-
-   if (handle->kmap_cnt) {
-   handle->kmap_cnt++;
-   return buffer->vaddr;
-   }
-   vaddr = ion_buffer_kmap_get(buffer);
-   if (IS_ERR(vaddr))
-   return vaddr;
-   handle->kmap_cnt++;
-   return vaddr;
-}
-
 static void ion_buffer_kmap_put(struct ion_buffer *buffer)
 {
buffer->kmap_cnt--;
@@ -462,49 +446,6 @@ static void ion_handle_kmap_put(struct ion_handle *handle)
ion_buffer_kmap_put(buffer);
 }
 
-void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-   void *vaddr;
-
-   mutex_lock(>lock);
-   if (!ion_handle_validate(client, handle)) {
-   pr_err("%s: invalid handle passed to map_kernel.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-EINVAL);
-   }
-
-   buffer = handle->buffer;
-
-   if (!handle->buffer->heap->ops->map_kernel) {
-   pr_err("%s: map_kernel is not implemented by this heap.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-ENODEV);
-   }
-
-   mutex_lock(>lock);
-   vaddr = ion_handle_kmap_get(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-   return vaddr;
-}
-EXPORT_SYMBOL(ion_map_kernel);
-
-void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-
-   mutex_lock(>lock);
-   buffer = handle->buffer;
-   mutex_lock(>lock);
-   ion_handle_kmap_put(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-}
-EXPORT_SYMBOL(ion_unmap_kernel);
-
 static struct mutex debugfs_mutex;
 static struct rb_root *ion_root_client;
 static int is_client_alive(struct ion_client *client)
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 17/22] staging: android: ion: Collapse internal header files

[Laura Abbott]

Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c |   1 -
 drivers/staging/android/ion/ion.c   |   1 -
 drivers/staging/android/ion/ion.h   | 481 
 drivers/staging/android/ion/ion_carveout_heap.c |   1 -
 drivers/staging/android/ion/ion_chunk_heap.c|   1 -
 drivers/staging/android/ion/ion_cma_heap.c  |   1 -
 drivers/staging/android/ion/ion_heap.c  |   1 -
 drivers/staging/android/ion/ion_page_pool.c |   3 +-
 drivers/staging/android/ion/ion_priv.h  | 453 --
 drivers/staging/android/ion/ion_system_heap.c   |   1 -
 10 files changed, 403 insertions(+), 541 deletions(-)
 delete mode 100644 drivers/staging/android/ion/ion_priv.h

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 91b5c2b..4e7bf16 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -19,7 +19,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 union ion_ioctl_arg {
struct ion_fd_data fd;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index fbab1e3..e1fb865 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -39,7 +39,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index e8a6ffe..67fcb73 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -1,5 +1,5 @@
 /*
- * drivers/staging/android/ion/ion.h
+ * drivers/staging/android/ion/ion_priv.h
  *
  * Copyright (C) 2011 Google, Inc.
  *
@@ -14,24 +14,26 @@
  *
  */
 
-#ifndef _LINUX_ION_H
-#define _LINUX_ION_H
+#ifndef _ION_PRIV_H
+#define _ION_PRIV_H
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 #include "../uapi/ion.h"
 
-struct ion_handle;
-struct ion_device;
-struct ion_heap;
-struct ion_mapper;
-struct ion_client;
-struct ion_buffer;
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
- * @id:unique identifier for heap.  When allocating higher 
numbers
+ * @id:unique identifier for heap.  When allocating higher 
numb ers
  * will be allocated from first.  At allocation these are passed
  * as a bit mask and therefore can not exceed ION_NUM_HEAP_IDS.
  * @name:  used for debug purposes
@@ -52,114 +54,433 @@ struct ion_platform_heap {
 };
 
 /**
- * struct ion_platform_data - array of platform heaps passed from board file
- * @nr:number of structures in the array
- * @heaps: array of platform_heap structions
+ * struct ion_buffer - metadata for a particular buffer
+ * @ref:   reference count
+ * @node:  node in the ion_device buffers tree
+ * @dev:   back pointer to the ion_device
+ * @heap:  back pointer to the heap the buffer came from
+ * @flags: buffer specific flags
+ * @private_flags: internal buffer specific flags
+ * @size:  size of the buffer
+ * @priv_virt: private data to the buffer representable as
+ * a void *
+ * @lock:  protects the buffers cnt fields
+ * @kmap_cnt:  number of times the buffer is mapped to the kernel
+ * @vaddr: the kernel mapping if kmap_cnt is not zero
+ * @sg_table:  the sg table for the buffer if dmap_cnt is not zero
+ * @pages: flat array of pages in the buffer -- used by fault
+ * handler and only valid for buffers that are faulted in
+ * @vmas:  list of vma's mapping this buffer
+ * @handle_count:  count of handles referencing this buffer
+ * @task_comm: taskcomm of last client to reference this buffer in a
+ * handle, used for debugging
+ * @pid:   pid of last client to reference this buffer in a
+ * handle, used for debugging
+ */
+struct ion_buffer {
+   struct kref ref;
+   union {
+   struct rb_node node;
+   struct list_head list;
+   };
+   struct ion_device *dev;
+   struct ion_heap *heap;
+   unsigned long flags;
+   unsigned long private_flags;
+   size_t size;
+   void *priv_virt;
+   struct mutex lock;
+   int kmap_cnt;
+   void *vaddr;
+   struct sg_table *sg_table;
+   struct page **pages;
+   struct list_head vmas;
+   struct list_head attachments;
+   

[PATCHv3 20/22] staging: android: ion: Remove ion_handle and ion_client

[Laura Abbott]

ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_client is also now only used internally. We have enough
mechanisms for race conditions and leaks already so just drop ion_handle
and ion_client. This also includes ripping out most of the debugfs
infrastructure since much of that was tied to clients and handles.
The debugfs infrastructure was prone to give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c |  53 +--
 drivers/staging/android/ion/ion.c   | 701 ++--
 drivers/staging/android/ion/ion.h   |  77 +---
 drivers/staging/android/uapi/ion.h  |  25 +-
 4 files changed, 51 insertions(+), 805 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 4e7bf16..76427e4 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -21,9 +21,7 @@
 #include "ion.h"
 
 union ion_ioctl_arg {
-   struct ion_fd_data fd;
struct ion_allocation_data allocation;
-   struct ion_handle_data handle;
struct ion_heap_query query;
 };
 
@@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_FREE:
-   return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
}
@@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
-   struct ion_client *client = filp->private_data;
-   struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
union ion_ioctl_arg data;
@@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
switch (cmd) {
case ION_IOC_ALLOC:
{
-   struct ion_handle *handle;
+   int fd;
 
-   handle = ion_alloc(client, data.allocation.len,
+   fd = ion_alloc(data.allocation.len,
data.allocation.heap_id_mask,
data.allocation.flags);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
+   if (fd < 0)
+   return fd;
 
-   data.allocation.handle = handle->id;
+   data.allocation.fd = fd;
 
-   cleanup_handle = handle;
-   break;
-   }
-   case ION_IOC_FREE:
-   {
-   struct ion_handle *handle;
-
-   mutex_lock(>lock);
-   handle = ion_handle_get_by_id_nolock(client,
-data.handle.handle);
-   if (IS_ERR(handle)) {
-   mutex_unlock(>lock);
-   return PTR_ERR(handle);
-   }
-   ion_free_nolock(client, handle);
-   ion_handle_put_nolock(handle);
-   mutex_unlock(>lock);
-   break;
-   }
-   case ION_IOC_SHARE:
-   {
-   struct ion_handle *handle;
-
-   handle = ion_handle_get_by_id(client, data.handle.handle);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
-   data.fd.fd = ion_share_dma_buf_fd(client, handle);
-   ion_handle_put(handle);
-   if (data.fd.fd < 0)
-   ret = data.fd.fd;
break;
}
case ION_IOC_HEAP_QUERY:
-   ret = ion_query_heaps(client, );
+   ret = ion_query_heaps();
break;
default:
return -ENOTTY;
}
 
if (dir & _IOC_READ) {
-   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd))) {
-   if (cleanup_handle)
-   ion_free(client, cleanup_handle);
+   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
return -EFAULT;
-   }
}
return ret;
 }
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 5a82bea..9eeb06f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -90,7 +90,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 
buffer->heap = heap;
buffer->flags = flags;
-   kref_init(>ref);
 
ret = heap->ops->allocate(heap, buffer, len, flags);
 
@@ -140,9 +139,8 @@ 

[PATCHv3 16/22] staging: android: ion: Get rid of ion_phys_addr_t

[Laura Abbott]

Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.h   | 12 ++--
 drivers/staging/android/ion/ion_carveout_heap.c | 10 +-
 drivers/staging/android/ion/ion_chunk_heap.c|  6 +++---
 drivers/staging/android/ion/ion_heap.c  |  4 ++--
 4 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 3b4bff5..e8a6ffe 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -28,14 +28,6 @@ struct ion_mapper;
 struct ion_client;
 struct ion_buffer;
 
-/*
- * This should be removed some day when phys_addr_t's are fully
- * plumbed in the kernel, and all instances of ion_phys_addr_t should
- * be converted to phys_addr_t.  For the time being many kernel interfaces
- * do not accept phys_addr_t's that would have to
- */
-#define ion_phys_addr_t unsigned long
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
@@ -53,9 +45,9 @@ struct ion_platform_heap {
enum ion_heap_type type;
unsigned int id;
const char *name;
-   ion_phys_addr_t base;
+   phys_addr_t base;
size_t size;
-   ion_phys_addr_t align;
+   phys_addr_t align;
void *priv;
 };
 
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index e0e360f..1419a89 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -30,10 +30,10 @@
 struct ion_carveout_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
 };
 
-static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
+static phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
 unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -46,7 +46,7 @@ static ion_phys_addr_t ion_carveout_allocate(struct ion_heap 
*heap,
return offset;
 }
 
-static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
+static void ion_carveout_free(struct ion_heap *heap, phys_addr_t addr,
  unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -63,7 +63,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
  unsigned long flags)
 {
struct sg_table *table;
-   ion_phys_addr_t paddr;
+   phys_addr_t paddr;
int ret;
 
table = kmalloc(sizeof(*table), GFP_KERNEL);
@@ -96,7 +96,7 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
struct ion_heap *heap = buffer->heap;
struct sg_table *table = buffer->sg_table;
struct page *page = sg_page(table->sgl);
-   ion_phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
+   phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
 
ion_heap_buffer_zero(buffer);
 
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 46e13f6..606f25f 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -27,7 +27,7 @@
 struct ion_chunk_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
unsigned long chunk_size;
unsigned long size;
unsigned long allocated;
@@ -151,8 +151,8 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
chunk_heap->heap.ops = _heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-   pr_debug("%s: base %lu size %zu \n", __func__,
-chunk_heap->base, heap_data->size);
+   pr_debug("%s: base %pa size %zu \n", __func__,
+_heap->base, heap_data->size);
 
return _heap->heap;
 
diff --git a/drivers/staging/android/ion/ion_heap.c 
b/drivers/staging/android/ion/ion_heap.c
index c69d0bd..03b554f 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -343,9 +343,9 @@ struct ion_heap *ion_heap_create(struct ion_platform_heap 
*heap_data)
}
 
if (IS_ERR_OR_NULL(heap)) {
-   pr_err("%s: error creating heap %s type %d base %lu size %zu\n",
+   pr_err("%s: error creating heap %s type %d base %pa size %zu\n",
   __func__, heap_data->name, heap_data->type,
-  heap_data->base, heap_data->size);
+  _data->base, heap_data->size);
   

[PATCHv3 18/22] staging: android: ion: Rework heap registration/enumeration

[Laura Abbott]

The current model of Ion heap registration  is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/Kconfig | 25 +
 drivers/staging/android/ion/Makefile|  7 +--
 drivers/staging/android/ion/ion.c   | 28 +--
 drivers/staging/android/ion/ion.h   | 40 +--
 drivers/staging/android/ion/ion_carveout_heap.c | 10 
 drivers/staging/android/ion/ion_chunk_heap.c|  9 
 drivers/staging/android/ion/ion_cma_heap.c  | 24 +++--
 drivers/staging/android/ion/ion_heap.c  | 67 -
 drivers/staging/android/ion/ion_system_heap.c   | 38 --
 9 files changed, 85 insertions(+), 163 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 15108c4..a517b2d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,31 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
+config ION_SYSTEM_HEAP
+   bool "Ion system heap"
+   depends on ION
+   help
+ Choose this option to enable the Ion system heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config ION_CARVEOUT_HEAP
+   bool "Ion carveout heap support"
+   depends on ION
+   help
+ Choose this option to enable carveout heaps with Ion. Carveout heaps
+ are backed by memory reserved from the system. Allocation times are
+ typically faster at the cost of memory not being used. Unless you
+ know your system has these regions, you should say N here.
+
+config ION_CHUNK_HEAP
+   bool "Ion chunk heap support"
+   depends on ION
+   help
+  Choose this option to enable chunk heaps with Ion. This heap is
+ similar in function the carveout heap but memory is broken down
+ into smaller chunk sizes, typically corresponding to a TLB size.
+ Unless you know your system has these regions, you should say N here.
+
 config ION_CMA_HEAP
bool "Ion CMA heap support"
depends on ION && CMA
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index a892afa..eb7eeed 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,5 @@
-obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o \
-   ion_page_pool.o ion_system_heap.o \
-   ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
+obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
+obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
 obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e1fb865..7d40233 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,9 @@
 
 #include "ion.h"
 
+static struct ion_device *internal_dev;
+static int heap_id = 0;
+
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
@@ -1198,9 +1201,10 @@ static int debug_shrink_get(void *data, u64 *val)
 DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
 
-void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
+void ion_device_add_heap(struct ion_heap *heap)
 {
struct dentry *debug_file;
+   struct ion_device *dev = internal_dev;
 
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -1217,6 +1221,7 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 
heap->dev = dev;
down_write(>lock);
+   heap->id = heap_id++;
/*
 * use negative heap->id to reverse the priority -- when traversing
 * the list later attempt higher id numbers first
@@ -1256,14 +1261,14 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 }
 EXPORT_SYMBOL(ion_device_add_heap);
 
-struct ion_device *ion_device_create(void)
+int ion_device_create(void)
 {
struct ion_device *idev;
int ret;
 
idev = kzalloc(sizeof(*idev), GFP_KERNEL);
if (!idev)
-   

[PATCHv3 15/22] staging: android: ion: Break the ABI in the name of forward progress

[Laura Abbott]

Several of the Ion ioctls were designed in such a way that they
necessitate compat ioctls. We're breaking a bunch of other ABIs and
cleaning stuff up anyway so let's follow the ioctl guidelines and clean
things up while everyone is busy converting things over anyway. As part
of this, also remove the useless alignment field from the allocation
structure.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/Makefile |   3 -
 drivers/staging/android/ion/compat_ion.c | 152 ---
 drivers/staging/android/ion/compat_ion.h |  29 --
 drivers/staging/android/ion/ion-ioctl.c  |   1 -
 drivers/staging/android/ion/ion.c|   5 +-
 drivers/staging/android/uapi/ion.h   |  19 ++--
 6 files changed, 11 insertions(+), 198 deletions(-)
 delete mode 100644 drivers/staging/android/ion/compat_ion.c
 delete mode 100644 drivers/staging/android/ion/compat_ion.h

diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 66d0c4a..a892afa 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -2,6 +2,3 @@ obj-$(CONFIG_ION) +=ion.o ion-ioctl.o ion_heap.o \
ion_page_pool.o ion_system_heap.o \
ion_carveout_heap.o ion_chunk_heap.o
 obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
-ifdef CONFIG_COMPAT
-obj-$(CONFIG_ION) += compat_ion.o
-endif
diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
deleted file mode 100644
index 5037ddd..000
--- a/drivers/staging/android/ion/compat_ion.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- * drivers/staging/android/ion/compat_ion.c
- *
- * Copyright (C) 2013 Google, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include 
-#include 
-#include 
-
-#include "ion.h"
-#include "compat_ion.h"
-
-/* See drivers/staging/android/uapi/ion.h for the definition of these structs 
*/
-struct compat_ion_allocation_data {
-   compat_size_t len;
-   compat_size_t align;
-   compat_uint_t heap_id_mask;
-   compat_uint_t flags;
-   compat_int_t handle;
-};
-
-struct compat_ion_handle_data {
-   compat_int_t handle;
-};
-
-#define COMPAT_ION_IOC_ALLOC   _IOWR(ION_IOC_MAGIC, 0, \
- struct compat_ion_allocation_data)
-#define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
- struct compat_ion_handle_data)
-
-static int compat_get_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err = get_user(s, >len);
-   err |= put_user(s, >len);
-   err |= get_user(s, >align);
-   err |= put_user(s, >align);
-   err |= get_user(u, >heap_id_mask);
-   err |= put_user(u, >heap_id_mask);
-   err |= get_user(u, >flags);
-   err |= put_user(u, >flags);
-   err |= get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_get_ion_handle_data(
-   struct compat_ion_handle_data __user *data32,
-   struct ion_handle_data __user *data)
-{
-   compat_int_t i;
-   int err;
-
-   err = get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_put_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err = get_user(s, >len);
-   err |= put_user(s, >len);
-   err |= get_user(s, >align);
-   err |= put_user(s, >align);
-   err |= get_user(u, >heap_id_mask);
-   err |= put_user(u, >heap_id_mask);
-   err |= get_user(u, >flags);
-   err |= put_user(u, >flags);
-   err |= get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
-{
-   long ret;
-
-   if (!filp->f_op->unlocked_ioctl)
-   return -ENOTTY;
-
-   switch (cmd) {
-   case COMPAT_ION_IOC_ALLOC:
-   {
-   struct compat_ion_allocation_data __user *data32;
-   struct ion_allocation_data __user *data;
-   int err;
-
-   data32 = 

[PATCHv3 14/22] staging: android: ion: Stop butchering the DMA address

[Laura Abbott]

Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 3d979ef5..65638f5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -81,8 +81,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 {
struct ion_buffer *buffer;
struct sg_table *table;
-   struct scatterlist *sg;
-   int i, ret;
+   int ret;
 
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
@@ -119,20 +118,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
INIT_LIST_HEAD(>vmas);
INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
-   /*
-* this will set up dma addresses for the sglist -- it is not
-* technically correct as per the dma api -- a specific
-* device isn't really taking ownership here.  However, in practice on
-* our systems the only dma_address space is physical addresses.
-* Additionally, we can't afford the overhead of invalidating every
-* allocation via dma_map_sg. The implicit contract here is that
-* memory coming from the heaps is ready for dma, ie if it has a
-* cached mapping that mapping has been invalidated
-*/
-   for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
-   sg_dma_address(sg) = sg_phys(sg);
-   sg_dma_len(sg) = sg->length;
-   }
mutex_lock(>buffer_lock);
ion_buffer_add(dev, buffer);
mutex_unlock(>buffer_lock);
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 02/22] cma: Introduce cma_for_each_area

[Laura Abbott]

Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.

Signed-off-by: Laura Abbott 
---
 include/linux/cma.h |  2 ++
 mm/cma.c| 14 ++
 2 files changed, 16 insertions(+)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index d41d1f8..3e8fbf5 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -34,4 +34,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
align,
  gfp_t gfp_mask);
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned 
int count);
+
+extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void 
*data);
 #endif
diff --git a/mm/cma.c b/mm/cma.c
index 43c1b2c..978b4a1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -504,3 +504,17 @@ bool cma_release(struct cma *cma, const struct page 
*pages, unsigned int count)
 
return true;
 }
+
+int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
+{
+   int i;
+
+   for (i = 0; i < cma_area_count; i++) {
+   int ret = it(_areas[i], data);
+
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 04/22] staging: android: ion: Remove alignment from allocation field

[Laura Abbott]

The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c |  1 -
 drivers/staging/android/ion/ion.c   | 14 ++
 drivers/staging/android/ion/ion.h   |  5 +
 drivers/staging/android/ion/ion_carveout_heap.c | 10 +++---
 drivers/staging/android/ion/ion_chunk_heap.c|  9 +++--
 drivers/staging/android/ion/ion_cma_heap.c  |  5 +
 drivers/staging/android/ion/ion_priv.h  |  2 +-
 drivers/staging/android/ion/ion_system_heap.c   |  9 +
 8 files changed, 16 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 9ff815a..5b2e93f 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
struct ion_handle *handle;
 
handle = ion_alloc(client, data.allocation.len,
-   data.allocation.align,
data.allocation.heap_id_mask,
data.allocation.flags);
if (IS_ERR(handle))
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index f45115f..c2adfe1 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -103,7 +103,6 @@ static void ion_buffer_add(struct ion_device *dev,
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
-   unsigned long align,
unsigned long flags)
 {
struct ion_buffer *buffer;
@@ -119,15 +118,14 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->flags = flags;
kref_init(>ref);
 
-   ret = heap->ops->allocate(heap, buffer, len, align, flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
 
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
 
ion_heap_freelist_drain(heap, 0);
-   ret = heap->ops->allocate(heap, buffer, len, align,
- flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret)
goto err2;
}
@@ -401,7 +399,7 @@ static int ion_handle_add(struct ion_client *client, struct 
ion_handle *handle)
 }
 
 struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
-size_t align, unsigned int heap_id_mask,
+unsigned int heap_id_mask,
 unsigned int flags)
 {
struct ion_handle *handle;
@@ -410,8 +408,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
struct ion_heap *heap;
int ret;
 
-   pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
-len, align, heap_id_mask, flags);
+   pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+len, heap_id_mask, flags);
/*
 * traverse the list of heaps available in this system in priority
 * order.  If the heap type is supported by the client, and matches the
@@ -428,7 +426,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
-   buffer = ion_buffer_create(heap, dev, len, align, flags);
+   buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 93dafb4..3b4bff5 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -45,7 +45,6 @@ struct ion_buffer;
  * @name:  used for debug purposes
  * @base:  base address of heap in physical memory if applicable
  * @size:  size of the heap in bytes if applicable
- * @align: required alignment in physical memory if applicable
  * @priv:  private info passed from the board file
  *
  * Provided by the board file.
@@ -93,8 +92,6 @@ void ion_client_destroy(struct ion_client *client);
  * ion_alloc - allocate ion memory
  * @client:the client
  * @len:   size of the 

[PATCHv3 08/22] staging: android: ion: Remove crufty cache support

[Laura Abbott]

Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/compat_ion.c|  1 -
 drivers/staging/android/ion/ion-ioctl.c |  6 
 drivers/staging/android/ion/ion.c   | 40 -
 drivers/staging/android/ion/ion_carveout_heap.c |  6 
 drivers/staging/android/ion/ion_chunk_heap.c|  6 
 drivers/staging/android/ion/ion_page_pool.c |  3 --
 drivers/staging/android/ion/ion_priv.h  | 13 
 drivers/staging/android/ion/ion_system_heap.c   |  5 
 drivers/staging/android/uapi/ion.h  | 10 ---
 9 files changed, 90 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 9a978d2..b892d3a 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -186,7 +186,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
-   case ION_IOC_SYNC:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..e096bcd 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -51,7 +51,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_SYNC:
case ION_IOC_FREE:
case ION_IOC_CUSTOM:
return _IOC_WRITE;
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_SYNC:
-   {
-   ret = ion_sync_for_device(client, data.fd.fd);
-   break;
-   }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 226ea1f..8757164 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -863,22 +863,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
 }
 
-void ion_pages_sync_for_device(struct device *dev, struct page *page,
-  size_t size, enum dma_data_direction dir)
-{
-   struct scatterlist sg;
-
-   sg_init_table(, 1);
-   sg_set_page(, page, size, 0);
-   /*
-* This is not correct - sg_dma_address needs a dma_addr_t that is valid
-* for the targeted device, but this works on the currently targeted
-* hardware.
-*/
-   sg_dma_address() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -1097,30 +1081,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct 
ion_client *client, int fd)
 }
 EXPORT_SYMBOL(ion_import_dma_buf_fd);
 
-int ion_sync_for_device(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_buffer *buffer;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return PTR_ERR(dmabuf);
-
-   /* if this memory came from ion */
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not sync dmabuf from another exporter\n",
-  __func__);
-   dma_buf_put(dmabuf);
-   return -EINVAL;
-   }
-   buffer = dmabuf->priv;
-
-   dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
-  buffer->sg_table->nents, DMA_BIDIRECTIONAL);
-   dma_buf_put(dmabuf);
-   return 0;
-}
-
 int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
 {
struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index 9bf8e98..e0e360f 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer 
*buffer)
 
ion_heap_buffer_zero(buffer);
 
-   if (ion_buffer_cached(buffer))
-   dma_sync_sg_for_device(NULL, table->sgl, table->nents,
-  DMA_BIDIRECTIONAL);
-
ion_carveout_free(heap, paddr, buffer->size);
 

[PATCHv3 06/22] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laura Abbott]

Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c  | 151 ++---
 drivers/staging/android/ion/ion_priv.h |   1 +
 2 files changed, 103 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 7dcb8a9..6aac935 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -162,6 +162,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(>vmas);
+   INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
/*
 * this will set up dma addresses for the sglist -- it is not
@@ -796,10 +797,6 @@ void ion_client_destroy(struct ion_client *client)
 }
 EXPORT_SYMBOL(ion_client_destroy);
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-  struct device *dev,
-  enum dma_data_direction direction);
-
 static struct sg_table *dup_sg_table(struct sg_table *table)
 {
struct sg_table *new_table;
@@ -826,22 +823,89 @@ static struct sg_table *dup_sg_table(struct sg_table 
*table)
return new_table;
 }
 
+static void free_duped_table(struct sg_table *table)
+{
+   sg_free_table(table);
+   kfree(table);
+}
+
+struct ion_dma_buf_attachment {
+   struct device *dev;
+   struct sg_table *table;
+   struct list_head list;
+};
+
+static int ion_dma_buf_attach(struct dma_buf *dmabuf, struct device *dev,
+   struct dma_buf_attachment *attachment)
+{
+   struct ion_dma_buf_attachment *a;
+   struct sg_table *table;
+   struct ion_buffer *buffer = dmabuf->priv;
+
+   a = kzalloc(sizeof(*a), GFP_KERNEL);
+   if (!a)
+   return -ENOMEM;
+
+   table = dup_sg_table(buffer->sg_table);
+   if (IS_ERR(table)) {
+   kfree(a);
+   return -ENOMEM;
+   }
+
+   a->table = table;
+   a->dev = dev;
+   INIT_LIST_HEAD(>list);
+
+   attachment->priv = a;
+
+   mutex_lock(>lock);
+   list_add(>list, >attachments);
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
+   struct dma_buf_attachment *attachment)
+{
+   struct ion_dma_buf_attachment *a = attachment->priv;
+   struct ion_buffer *buffer = dmabuf->priv;
+
+   free_duped_table(a->table);
+   mutex_lock(>lock);
+   list_del(>list);
+   mutex_unlock(>lock);
+
+   kfree(a);
+}
+
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
-   struct dma_buf *dmabuf = attachment->dmabuf;
-   struct ion_buffer *buffer = dmabuf->priv;
+   struct ion_dma_buf_attachment *a = attachment->priv;
+   struct sg_table *table;
+   int ret;
+
+   table = a->table;
 
-   ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-   return dup_sg_table(buffer->sg_table);
+   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+   direction)){
+   ret = -ENOMEM;
+   goto err;
+   }
+   return table;
+
+err:
+   free_duped_table(table);
+   return ERR_PTR(ret);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
-   sg_free_table(table);
-   kfree(table);
+   dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
@@ -865,38 +929,6 @@ struct ion_vma_list {
struct vm_area_struct *vma;
 };
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-  struct device *dev,
-  enum dma_data_direction dir)
-{
-   struct ion_vma_list *vma_list;
-   int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-   int i;
-
-   pr_debug("%s: syncing for device %s\n", __func__,
-dev ? dev_name(dev) : "null");
-
-   if (!ion_buffer_fault_user_mappings(buffer))
-   return;
-
-   mutex_lock(>lock);
-   for (i = 0; i < pages; i++) {
-   struct page *page = buffer->pages[i];
-
-   if (ion_buffer_page_is_dirty(page))
-   ion_pages_sync_for_device(dev, ion_buffer_page(page),
- PAGE_SIZE, dir);
-
-

[PATCHv3 13/22] staging: android: ion: Use CMA APIs directly

[Laura Abbott]

When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also mitigates some of
the caching problems (e.g. dma_alloc_coherent only returning uncached
memory).

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/Kconfig|  7 +++
 drivers/staging/android/ion/Makefile   |  3 +-
 drivers/staging/android/ion/ion_cma_heap.c | 97 --
 3 files changed, 35 insertions(+), 72 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 206c4de..15108c4 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,3 +10,10 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
+config ION_CMA_HEAP
+   bool "Ion CMA heap support"
+   depends on ION && CMA
+   help
+ Choose this option to enable CMA heaps with Ion. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 26672a0..66d0c4a 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o \
ion_page_pool.o ion_system_heap.o \
-   ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
+   ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..f3e0f59 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include "ion.h"
 #include "ion_priv.h"
 
 struct ion_cma_heap {
struct ion_heap heap;
-   struct device *dev;
+   struct cma *cma;
 };
 
 #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
 
-struct ion_cma_buffer_info {
-   void *cpu_addr;
-   dma_addr_t handle;
-   struct sg_table *table;
-};
-
 
 /* ION CMA heap operations functions */
 static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
unsigned long flags)
 {
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
-   struct device *dev = cma_heap->dev;
-   struct ion_cma_buffer_info *info;
-
-   dev_dbg(dev, "Request buffer allocation len %ld\n", len);
-
-   if (buffer->flags & ION_FLAG_CACHED)
-   return -EINVAL;
+   struct sg_table *table;
+   struct page *pages;
+   int ret;
 
-   info = kzalloc(sizeof(*info), GFP_KERNEL);
-   if (!info)
+   pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
+   if (!pages)
return -ENOMEM;
 
-   info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
-   GFP_HIGHUSER | __GFP_ZERO);
-
-   if (!info->cpu_addr) {
-   dev_err(dev, "Fail to allocate buffer\n");
+   table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+   if (!table)
goto err;
-   }
 
-   info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
-   if (!info->table)
+   ret = sg_alloc_table(table, 1, GFP_KERNEL);
+   if (ret)
goto free_mem;
 
-   if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
-   len))
-   goto free_table;
-   /* keep this for memory release */
-   buffer->priv_virt = info;
-   buffer->sg_table = info->table;
-   dev_dbg(dev, "Allocate buffer %p\n", buffer);
+   sg_set_page(table->sgl, pages, len, 0);
+
+   buffer->priv_virt = pages;
+   buffer->sg_table = table;
return 0;
 
-free_table:
-   kfree(info->table);
 free_mem:
-   dma_free_coherent(dev, len, info->cpu_addr, info->handle);
+   kfree(table);
 err:
-   kfree(info);
+   cma_release(cma_heap->cma, pages, buffer->size);
return -ENOMEM;
 }
 
 static void ion_cma_free(struct ion_buffer *buffer)
 {
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
-   struct device *dev = cma_heap->dev;
-   struct ion_cma_buffer_info *info = buffer->priv_virt;
+   struct page *pages 

[PATCHv3 12/22] staging: android: ion: Remove old platform support

[Laura Abbott]

Device specific platform support has been haphazard for Ion. There have
been several independent attempts and there are still objections to
what bindings exist right now. Just remove everything for a fresh start.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/Kconfig|  42 ---
 drivers/staging/android/ion/Makefile   |   7 -
 drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
 drivers/staging/android/ion/hisilicon/Makefile |   1 -
 drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 
 drivers/staging/android/ion/ion_dummy_driver.c | 155 ---
 drivers/staging/android/ion/ion_of.c   | 184 -
 drivers/staging/android/ion/ion_of.h   |  37 ---
 drivers/staging/android/ion/ion_test.c | 305 -
 drivers/staging/android/ion/tegra/Makefile |   1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
 drivers/staging/android/uapi/ion_test.h|  69 -
 12 files changed, 999 deletions(-)
 delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
 delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
 delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
 delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
 delete mode 100644 drivers/staging/android/ion/ion_of.c
 delete mode 100644 drivers/staging/android/ion/ion_of.h
 delete mode 100644 drivers/staging/android/ion/ion_test.c
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
 delete mode 100644 drivers/staging/android/uapi/ion_test.h

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index c8fb413..206c4de 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,45 +10,3 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
-config ION_TEST
-   tristate "Ion Test Device"
-   depends on ION
-   help
- Choose this option to create a device that can be used to test the
- kernel and device side ION functions.
-
-config ION_DUMMY
-   bool "Dummy Ion driver"
-   depends on ION
-   help
- Provides a dummy ION driver that registers the
- /dev/ion device and some basic heaps. This can
- be used for testing the ION infrastructure if
- one doesn't have access to hardware drivers that
- use ION.
-
-config ION_TEGRA
-   tristate "Ion for Tegra"
-   depends on ARCH_TEGRA && ION
-   help
- Choose this option if you wish to use ion on an nVidia Tegra.
-
-config ION_HISI
-   tristate "Ion for Hisilicon"
-   depends on ARCH_HISI && ION
-   select ION_OF
-   help
- Choose this option if you wish to use ion on Hisilicon Platform.
-
-source "drivers/staging/android/ion/hisilicon/Kconfig"
-
-config ION_OF
-   bool "Devicetree support for Ion"
-   depends on ION && OF_ADDRESS
-   help
- Provides base support for defining Ion heaps in devicetree
- and setting them up. Also includes functions for platforms
- to parse the devicetree and expand for their own custom
- extensions
-
- If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 5d630a0..26672a0 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,13 +1,6 @@
 obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o \
ion_page_pool.o ion_system_heap.o \
ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
-obj-$(CONFIG_ION_TEST) += ion_test.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
-
-obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
-obj-$(CONFIG_ION_TEGRA) += tegra/
-obj-$(CONFIG_ION_HISI) += hisilicon/
-obj-$(CONFIG_ION_OF) += ion_of.o
-
diff --git a/drivers/staging/android/ion/hisilicon/Kconfig 
b/drivers/staging/android/ion/hisilicon/Kconfig
deleted file mode 100644
index 2b4bd07..000
--- a/drivers/staging/android/ion/hisilicon/Kconfig
+++ /dev/null
@@ -1,5 +0,0 @@
-config HI6220_ION
-bool "Hi6220 ION Driver"
-depends on ARCH_HISI && ION
-help
-  Build the Hisilicon Hi6220 ion driver.
diff --git a/drivers/staging/android/ion/hisilicon/Makefile 
b/drivers/staging/android/ion/hisilicon/Makefile
deleted file mode 100644
index 2a89414..000
--- a/drivers/staging/android/ion/hisilicon/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_HI6220_ION) += hi6220_ion.o
diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c 
b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
deleted file mode 100644
index 0de7897..000
--- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
+++ 

[PATCHv3 10/22] staging: android: ion: Remove import interface

[Laura Abbott]

With the expansion of dma-buf and the move for Ion to be come just an
allocator, the import mechanism is mostly useless. There isn't a kernel
component to Ion anymore and handles are private to Ion. Remove this
interface.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/compat_ion.c |  1 -
 drivers/staging/android/ion/ion-ioctl.c  | 11 -
 drivers/staging/android/ion/ion.c| 76 
 drivers/staging/android/uapi/ion.h   |  9 
 4 files changed, 97 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 5b192ea..ae1ffc3 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -145,7 +145,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
}
case ION_IOC_SHARE:
case ION_IOC_MAP:
-   case ION_IOC_IMPORT:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 2b475bf..7b54eea 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -131,17 +131,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
ret = data.fd.fd;
break;
}
-   case ION_IOC_IMPORT:
-   {
-   struct ion_handle *handle;
-
-   handle = ion_import_dma_buf_fd(client, data.fd.fd);
-   if (IS_ERR(handle))
-   ret = PTR_ERR(handle);
-   else
-   data.handle.handle = handle->id;
-   break;
-   }
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(client, );
break;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 125c537..3d979ef5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,24 +274,6 @@ int ion_handle_put(struct ion_handle *handle)
return ret;
 }
 
-static struct ion_handle *ion_handle_lookup(struct ion_client *client,
-   struct ion_buffer *buffer)
-{
-   struct rb_node *n = client->handles.rb_node;
-
-   while (n) {
-   struct ion_handle *entry = rb_entry(n, struct ion_handle, node);
-
-   if (buffer < entry->buffer)
-   n = n->rb_left;
-   else if (buffer > entry->buffer)
-   n = n->rb_right;
-   else
-   return entry;
-   }
-   return ERR_PTR(-EINVAL);
-}
-
 struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client *client,
   int id)
 {
@@ -1023,64 +1005,6 @@ int ion_share_dma_buf_fd(struct ion_client *client, 
struct ion_handle *handle)
 }
 EXPORT_SYMBOL(ion_share_dma_buf_fd);
 
-struct ion_handle *ion_import_dma_buf(struct ion_client *client,
- struct dma_buf *dmabuf)
-{
-   struct ion_buffer *buffer;
-   struct ion_handle *handle;
-   int ret;
-
-   /* if this memory came from ion */
-
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not import dmabuf from another exporter\n",
-  __func__);
-   return ERR_PTR(-EINVAL);
-   }
-   buffer = dmabuf->priv;
-
-   mutex_lock(>lock);
-   /* if a handle exists for this buffer just take a reference to it */
-   handle = ion_handle_lookup(client, buffer);
-   if (!IS_ERR(handle)) {
-   ion_handle_get(handle);
-   mutex_unlock(>lock);
-   goto end;
-   }
-
-   handle = ion_handle_create(client, buffer);
-   if (IS_ERR(handle)) {
-   mutex_unlock(>lock);
-   goto end;
-   }
-
-   ret = ion_handle_add(client, handle);
-   mutex_unlock(>lock);
-   if (ret) {
-   ion_handle_put(handle);
-   handle = ERR_PTR(ret);
-   }
-
-end:
-   return handle;
-}
-EXPORT_SYMBOL(ion_import_dma_buf);
-
-struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_handle *handle;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return ERR_CAST(dmabuf);
-
-   handle = ion_import_dma_buf(client, dmabuf);
-   dma_buf_put(dmabuf);
-   return handle;
-}
-EXPORT_SYMBOL(ion_import_dma_buf_fd);
-
 int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
 {
struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 8ff471d..3a59044 100644
--- 

[PATCHv3 11/22] staging: android: ion: Remove duplicate ION_IOC_MAP

[Laura Abbott]

ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two
identical interfaces. Remove it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/compat_ion.c |  1 -
 drivers/staging/android/ion/ion-ioctl.c  |  1 -
 drivers/staging/android/uapi/ion.h   | 10 --
 3 files changed, 12 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index ae1ffc3..5037ddd 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -144,7 +144,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
(unsigned long)data);
}
case ION_IOC_SHARE:
-   case ION_IOC_MAP:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 7b54eea..a361724 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -118,7 +118,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
break;
}
case ION_IOC_SHARE:
-   case ION_IOC_MAP:
{
struct ion_handle *handle;
 
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 3a59044..abd72fd 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -164,16 +164,6 @@ struct ion_heap_query {
 #define ION_IOC_FREE   _IOWR(ION_IOC_MAGIC, 1, struct ion_handle_data)
 
 /**
- * DOC: ION_IOC_MAP - get a file descriptor to mmap
- *
- * Takes an ion_fd_data struct with the handle field populated with a valid
- * opaque handle.  Returns the struct with the fd field set to a file
- * descriptor open in the current address space.  This file descriptor
- * can then be used as an argument to mmap.
- */
-#define ION_IOC_MAP_IOWR(ION_IOC_MAGIC, 2, struct ion_fd_data)
-
-/**
  * DOC: ION_IOC_SHARE - creates a file descriptor to use to share an allocation
  *
  * Takes an ion_fd_data struct with the handle field populated with a valid
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 07/22] staging: android: ion: Remove page faulting support

[Laura Abbott]

The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 117 --
 1 file changed, 117 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 6aac935..226ea1f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -42,37 +42,11 @@
 #include "ion_priv.h"
 #include "compat_ion.h"
 
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
-   return (buffer->flags & ION_FLAG_CACHED) &&
-   !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
 }
 
-static inline struct page *ion_buffer_page(struct page *page)
-{
-   return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
-   return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
 /* this function should only be called while dev->lock is held */
 static void ion_buffer_add(struct ion_device *dev,
   struct ion_buffer *buffer)
@@ -140,25 +114,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->dev = dev;
buffer->size = len;
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-   struct scatterlist *sg;
-   int i, j, k = 0;
-
-   buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
-   if (!buffer->pages) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   for_each_sg(table->sgl, sg, table->nents, i) {
-   struct page *page = sg_page(sg);
-
-   for (j = 0; j < sg->length / PAGE_SIZE; j++)
-   buffer->pages[k++] = page++;
-   }
-   }
-
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(>vmas);
@@ -924,69 +879,6 @@ void ion_pages_sync_for_device(struct device *dev, struct 
page *page,
dma_sync_sg_for_device(dev, , 1, dir);
 }
 
-struct ion_vma_list {
-   struct list_head list;
-   struct vm_area_struct *vma;
-};
-
-static int ion_vm_fault(struct vm_fault *vmf)
-{
-   struct ion_buffer *buffer = vmf->vma->vm_private_data;
-   unsigned long pfn;
-   int ret;
-
-   mutex_lock(>lock);
-   ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
-   BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
-   pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
-   ret = vm_insert_pfn(vmf->vma, vmf->address, pfn);
-   mutex_unlock(>lock);
-   if (ret)
-   return VM_FAULT_ERROR;
-
-   return VM_FAULT_NOPAGE;
-}
-
-static void ion_vm_open(struct vm_area_struct *vma)
-{
-   struct ion_buffer *buffer = vma->vm_private_data;
-   struct ion_vma_list *vma_list;
-
-   vma_list = kmalloc(sizeof(*vma_list), GFP_KERNEL);
-   if (!vma_list)
-   return;
-   vma_list->vma = vma;
-   mutex_lock(>lock);
-   list_add(_list->list, >vmas);
-   mutex_unlock(>lock);
-   pr_debug("%s: adding %p\n", __func__, vma);
-}
-
-static void ion_vm_close(struct vm_area_struct *vma)
-{
-   struct ion_buffer *buffer = vma->vm_private_data;
-   struct ion_vma_list *vma_list, *tmp;
-
-   pr_debug("%s\n", __func__);
-   mutex_lock(>lock);
-   list_for_each_entry_safe(vma_list, tmp, >vmas, list) {
-   if (vma_list->vma != vma)
-   continue;
-   list_del(_list->list);
-   kfree(vma_list);
-   pr_debug("%s: deleting %p\n", __func__, vma);
-   break;
-   }
-   mutex_unlock(>lock);
-}
-
-static const struct vm_operations_struct ion_vma_ops = {
-   .open = ion_vm_open,
-   .close = ion_vm_close,
-   .fault = ion_vm_fault,
-};
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -998,15 +890,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
-   VM_DONTDUMP;
-   vma->vm_private_data = buffer;
-   vma->vm_ops = _vma_ops;
-   

[PATCHv3 09/22] staging: android: ion: Remove custom ioctl interface

[Laura Abbott]

Ion is now moving towards a unified interfact. This makes the custom
ioctl interface unneeded. Remove it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/compat_ion.c   | 40 --
 drivers/staging/android/ion/ion-ioctl.c| 11 ---
 drivers/staging/android/ion/ion.c  |  6 +---
 drivers/staging/android/ion/ion_dummy_driver.c |  2 +-
 drivers/staging/android/ion/ion_priv.h |  8 +-
 drivers/staging/android/uapi/ion.h | 21 --
 6 files changed, 3 insertions(+), 85 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index b892d3a..5b192ea 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -30,11 +30,6 @@ struct compat_ion_allocation_data {
compat_int_t handle;
 };
 
-struct compat_ion_custom_data {
-   compat_uint_t cmd;
-   compat_ulong_t arg;
-};
-
 struct compat_ion_handle_data {
compat_int_t handle;
 };
@@ -43,8 +38,6 @@ struct compat_ion_handle_data {
  struct compat_ion_allocation_data)
 #define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
  struct compat_ion_handle_data)
-#define COMPAT_ION_IOC_CUSTOM  _IOWR(ION_IOC_MAGIC, 6, \
- struct compat_ion_custom_data)
 
 static int compat_get_ion_allocation_data(
struct compat_ion_allocation_data __user *data32,
@@ -105,22 +98,6 @@ static int compat_put_ion_allocation_data(
return err;
 }
 
-static int compat_get_ion_custom_data(
-   struct compat_ion_custom_data __user *data32,
-   struct ion_custom_data __user *data)
-{
-   compat_uint_t cmd;
-   compat_ulong_t arg;
-   int err;
-
-   err = get_user(cmd, >cmd);
-   err |= put_user(cmd, >cmd);
-   err |= get_user(arg, >arg);
-   err |= put_user(arg, >arg);
-
-   return err;
-};
-
 long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
long ret;
@@ -166,23 +143,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
return filp->f_op->unlocked_ioctl(filp, ION_IOC_FREE,
(unsigned long)data);
}
-   case COMPAT_ION_IOC_CUSTOM: {
-   struct compat_ion_custom_data __user *data32;
-   struct ion_custom_data __user *data;
-   int err;
-
-   data32 = compat_ptr(arg);
-   data = compat_alloc_user_space(sizeof(*data));
-   if (!data)
-   return -EFAULT;
-
-   err = compat_get_ion_custom_data(data32, data);
-   if (err)
-   return err;
-
-   return filp->f_op->unlocked_ioctl(filp, ION_IOC_CUSTOM,
-   (unsigned long)data);
-   }
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index e096bcd..2b475bf 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -26,7 +26,6 @@ union ion_ioctl_arg {
struct ion_fd_data fd;
struct ion_allocation_data allocation;
struct ion_handle_data handle;
-   struct ion_custom_data custom;
struct ion_heap_query query;
 };
 
@@ -52,7 +51,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
case ION_IOC_FREE:
-   case ION_IOC_CUSTOM:
return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
@@ -62,7 +60,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
struct ion_client *client = filp->private_data;
-   struct ion_device *dev = client->dev;
struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
@@ -145,14 +142,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_CUSTOM:
-   {
-   if (!dev->custom_ioctl)
-   return -ENOTTY;
-   ret = dev->custom_ioctl(client, data.custom.cmd,
-   data.custom.arg);
-   break;
-   }
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(client, );
break;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 8757164..125c537 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1347,10 +1347,7 @@ void 

[PATCHv3 01/22] cma: Store a name in the cma structure

[Laura Abbott]

Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.

Signed-off-by: Laura Abbott 
---
v3: Added default name suggestion per Sumit. Fixup powerpc call site.
---
 arch/powerpc/kvm/book3s_hv_builtin.c |  3 ++-
 drivers/base/dma-contiguous.c|  5 +++--
 include/linux/cma.h  |  4 +++-
 mm/cma.c | 17 +++--
 mm/cma.h |  1 +
 mm/cma_debug.c   |  2 +-
 6 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 4d6c64b..b739ff8 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -100,7 +100,8 @@ void __init kvm_cma_reserve(void)
 (unsigned long)selected_size / SZ_1M);
align_size = HPT_ALIGN_PAGES << PAGE_SHIFT;
cma_declare_contiguous(0, selected_size, 0, align_size,
-   KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, _cma);
+   KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, "kvm_cma",
+   _cma);
}
 }
 
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index b55804c..ea9726e 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -165,7 +165,8 @@ int __init dma_contiguous_reserve_area(phys_addr_t size, 
phys_addr_t base,
 {
int ret;
 
-   ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed, res_cma);
+   ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed,
+   "reserved", res_cma);
if (ret)
return ret;
 
@@ -258,7 +259,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EINVAL;
}
 
-   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, );
+   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name, 
);
if (err) {
pr_err("Reserved memory: unable to setup CMA region\n");
return err;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 03f32d0..d41d1f8 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -21,13 +21,15 @@ struct cma;
 extern unsigned long totalcma_pages;
 extern phys_addr_t cma_get_base(const struct cma *cma);
 extern unsigned long cma_get_size(const struct cma *cma);
+extern const char *cma_get_name(const struct cma *cma);
 
 extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
-   bool fixed, struct cma **res_cma);
+   bool fixed, const char *name, struct cma **res_cma);
 extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
unsigned int order_per_bit,
+   const char *name,
struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
align,
  gfp_t gfp_mask);
diff --git a/mm/cma.c b/mm/cma.c
index a6033e3..43c1b2c 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -53,6 +53,11 @@ unsigned long cma_get_size(const struct cma *cma)
return cma->count << PAGE_SHIFT;
 }
 
+const char *cma_get_name(const struct cma *cma)
+{
+   return cma->name ? cma->name : "(undefined)";
+}
+
 static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
 int align_order)
 {
@@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
  */
 int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 unsigned int order_per_bit,
+const char *name,
 struct cma **res_cma)
 {
struct cma *cma;
@@ -198,6 +204,13 @@ int __init cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 * subsystems (like slab allocator) are available.
 */
cma = _areas[cma_area_count];
+   if (name) {
+   cma->name = name;
+   } else {
+   cma->name = kasprintf(GFP_KERNEL, "cma%d\n", cma_area_count);
+   if (!cma->name)
+   return -ENOMEM;
+   }
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
@@ -229,7 +242,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
-   bool fixed, struct 

[PATCHv3 03/22] staging: android: ion: Remove dmap_cnt

[Laura Abbott]

The reference counting of dma_map calls was removed. Remove the
associated counter field as well.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion_priv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_priv.h 
b/drivers/staging/android/ion/ion_priv.h
index 5b3059c..46d3ff5 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -44,7 +44,6 @@
  * @lock:  protects the buffers cnt fields
  * @kmap_cnt:  number of times the buffer is mapped to the kernel
  * @vaddr: the kernel mapping if kmap_cnt is not zero
- * @dmap_cnt:  number of times the buffer is mapped for dma
  * @sg_table:  the sg table for the buffer if dmap_cnt is not zero
  * @pages: flat array of pages in the buffer -- used by fault
  * handler and only valid for buffers that are faulted in
@@ -70,7 +69,6 @@ struct ion_buffer {
struct mutex lock;
int kmap_cnt;
void *vaddr;
-   int dmap_cnt;
struct sg_table *sg_table;
struct page **pages;
struct list_head vmas;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Laura Abbott]

Hi,

This is v3 of the series to do some serious Ion cleanup in preparation for
moving out of staging. I didn't hear much on v2 so I'm going to assume
people are okay with the series as is. I know there were still some open
questions about moving away from /dev/ion but in the interest of small
steps I'd like to go ahead and merge this series assuming there are no more
major objections. More work can happen on top of this.

Changes from v2:
- Dropped the RFC tag
- Minor bisectability fixes
- Sumit's comment about CMA naming
- Updated the TODO list

Thanks,
Laura

Laura Abbott (22):
  cma: Store a name in the cma structure
  cma: Introduce cma_for_each_area
  staging: android: ion: Remove dmap_cnt
  staging: android: ion: Remove alignment from allocation field
  staging: android: ion: Duplicate sg_table
  staging: android: ion: Call dma_map_sg for syncing and mapping
  staging: android: ion: Remove page faulting support
  staging: android: ion: Remove crufty cache support
  staging: android: ion: Remove custom ioctl interface
  staging: android: ion: Remove import interface
  staging: android: ion: Remove duplicate ION_IOC_MAP
  staging: android: ion: Remove old platform support
  staging: android: ion: Use CMA APIs directly
  staging: android: ion: Stop butchering the DMA address
  staging: android: ion: Break the ABI in the name of forward progress
  staging: android: ion: Get rid of ion_phys_addr_t
  staging: android: ion: Collapse internal header files
  staging: android: ion: Rework heap registration/enumeration
  staging: android: ion: Drop ion_map_kernel interface
  staging: android: ion: Remove ion_handle and ion_client
  staging: android: ion: Set query return value
  staging/android: Update Ion TODO list

 arch/powerpc/kvm/book3s_hv_builtin.c   |3 +-
 drivers/base/dma-contiguous.c  |5 +-
 drivers/staging/android/TODO   |   21 +-
 drivers/staging/android/ion/Kconfig|   56 +-
 drivers/staging/android/ion/Makefile   |   18 +-
 drivers/staging/android/ion/compat_ion.c   |  195 
 drivers/staging/android/ion/compat_ion.h   |   29 -
 drivers/staging/android/ion/hisilicon/Kconfig  |5 -
 drivers/staging/android/ion/hisilicon/Makefile |1 -
 drivers/staging/android/ion/hisilicon/hi6220_ion.c |  113 --
 drivers/staging/android/ion/ion-ioctl.c|   85 +-
 drivers/staging/android/ion/ion.c  | 1168 +++-
 drivers/staging/android/ion/ion.h  |  389 +--
 drivers/staging/android/ion/ion_carveout_heap.c|   37 +-
 drivers/staging/android/ion/ion_chunk_heap.c   |   27 +-
 drivers/staging/android/ion/ion_cma_heap.c |  125 +--
 drivers/staging/android/ion/ion_dummy_driver.c |  155 ---
 drivers/staging/android/ion/ion_heap.c |   68 --
 drivers/staging/android/ion/ion_of.c   |  184 ---
 drivers/staging/android/ion/ion_of.h   |   37 -
 drivers/staging/android/ion/ion_page_pool.c|6 +-
 drivers/staging/android/ion/ion_priv.h |  473 
 drivers/staging/android/ion/ion_system_heap.c  |   53 +-
 drivers/staging/android/ion/ion_test.c |  305 -
 drivers/staging/android/ion/tegra/Makefile |1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |   80 --
 drivers/staging/android/uapi/ion.h |   86 +-
 drivers/staging/android/uapi/ion_test.h|   69 --
 include/linux/cma.h|6 +-
 mm/cma.c   |   31 +-
 mm/cma.h   |1 +
 mm/cma_debug.c |2 +-
 32 files changed, 620 insertions(+), 3214 deletions(-)
 delete mode 100644 drivers/staging/android/ion/compat_ion.c
 delete mode 100644 drivers/staging/android/ion/compat_ion.h
 delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
 delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
 delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
 delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
 delete mode 100644 drivers/staging/android/ion/ion_of.c
 delete mode 100644 drivers/staging/android/ion/ion_of.h
 delete mode 100644 drivers/staging/android/ion/ion_priv.h
 delete mode 100644 drivers/staging/android/ion/ion_test.c
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
 delete mode 100644 drivers/staging/android/uapi/ion_test.h

-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: bcm2835-audio: remove unnecessary log messages

[Aishwarya Pant]

Remove unnecessary log messages in the driver which are just tracking
function entry and exits.

Signed-off-by: Aishwarya Pant 
---
Changes in v2:
Patch v1 introduced a compile error; remove it by deleting the log
continuation.

 .../vc04_services/bcm2835-audio/bcm2835-ctl.c  |  2 --
 .../vc04_services/bcm2835-audio/bcm2835-pcm.c  | 19 ---
 .../vc04_services/bcm2835-audio/bcm2835-vchiq.c| 38 --
 3 files changed, 59 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index 1fae169..f484bb0 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -41,7 +41,6 @@
 static int snd_bcm2835_ctl_info(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
 {
-   audio_info(" ... IN\n");
if (kcontrol->private_value == PCM_PLAYBACK_VOLUME) {
uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->count = 1;
@@ -58,7 +57,6 @@ static int snd_bcm2835_ctl_info(struct snd_kcontrol *kcontrol,
uinfo->value.integer.min = 0;
uinfo->value.integer.max = AUDIO_DEST_MAX - 1;
}
-   audio_info(" ... OUT\n");
return 0;
 }
 
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
index 8bd69b9..e8cf0b9 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
@@ -65,7 +65,6 @@ void bcm2835_playback_fifo(struct bcm2835_alsa_stream 
*alsa_stream)
unsigned int consumed = 0;
int new_period = 0;
 
-   audio_info(" .. IN\n");
 
audio_info("alsa_stream=%p substream=%p\n", alsa_stream,
alsa_stream ? alsa_stream->substream : 0);
@@ -100,7 +99,6 @@ void bcm2835_playback_fifo(struct bcm2835_alsa_stream 
*alsa_stream)
} else {
audio_warning(" unexpected NULL substream\n");
}
-   audio_info(" .. OUT\n");
 }
 
 /* open callback */
@@ -113,7 +111,6 @@ static int snd_bcm2835_playback_open_generic(
int idx;
int err;
 
-   audio_info(" .. IN (%d)\n", substream->number);
 
if (mutex_lock_interruptible(>audio_mutex)) {
audio_error("Interrupted whilst waiting for lock\n");
@@ -187,7 +184,6 @@ static int snd_bcm2835_playback_open_generic(
 out:
mutex_unlock(>audio_mutex);
 
-   audio_info(" .. OUT =%d\n", err);
 
return err;
 }
@@ -211,7 +207,6 @@ static int snd_bcm2835_playback_close(struct 
snd_pcm_substream *substream)
struct snd_pcm_runtime *runtime;
struct bcm2835_alsa_stream *alsa_stream;
 
-   audio_info(" .. IN\n");
 
chip = snd_pcm_substream_chip(substream);
if (mutex_lock_interruptible(>audio_mutex)) {
@@ -252,7 +247,6 @@ static int snd_bcm2835_playback_close(struct 
snd_pcm_substream *substream)
chip->opened &= ~(1 << substream->number);
 
mutex_unlock(>audio_mutex);
-   audio_info(" .. OUT\n");
 
return 0;
 }
@@ -265,7 +259,6 @@ static int snd_bcm2835_pcm_hw_params(struct 
snd_pcm_substream *substream,
struct bcm2835_alsa_stream *alsa_stream = runtime->private_data;
int err;
 
-   audio_info(" .. IN\n");
 
err = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params));
if (err < 0) {
@@ -277,7 +270,6 @@ static int snd_bcm2835_pcm_hw_params(struct 
snd_pcm_substream *substream,
alsa_stream->channels = params_channels(params);
alsa_stream->params_rate = params_rate(params);
alsa_stream->pcm_format_width = 
snd_pcm_format_width(params_format(params));
-   audio_info(" .. OUT\n");
 
return err;
 }
@@ -285,7 +277,6 @@ static int snd_bcm2835_pcm_hw_params(struct 
snd_pcm_substream *substream,
 /* hw_free callback */
 static int snd_bcm2835_pcm_hw_free(struct snd_pcm_substream *substream)
 {
-   audio_info(" .. IN\n");
return snd_pcm_lib_free_pages(substream);
 }
 
@@ -298,7 +289,6 @@ static int snd_bcm2835_pcm_prepare(struct snd_pcm_substream 
*substream)
int channels;
int err;
 
-   audio_info(" .. IN\n");
 
if (mutex_lock_interruptible(>audio_mutex))
return -EINTR;
@@ -339,7 +329,6 @@ static int snd_bcm2835_pcm_prepare(struct snd_pcm_substream 
*substream)
alsa_stream->pos, runtime->frame_bits);
 
mutex_unlock(>audio_mutex);
-   audio_info(" .. OUT\n");
return 0;
 }
 
@@ -376,7 +365,6 @@ static int snd_bcm2835_pcm_trigger(struct snd_pcm_substream 
*substream, int cmd)
struct bcm2835_alsa_stream *alsa_stream = runtime->private_data;
int err = 0;
 
-   audio_info(" .. IN\n");
 
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -419,7 

Re: [RFC PATCH] binder: Don't require the binder lock when killed in binder_thread_read()

[Doug Anderson]

Hi,

On Mon, Apr 3, 2017 at 6:25 AM, Greg KH  wrote:
> On Sat, Apr 01, 2017 at 07:34:53PM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Fri, Mar 31, 2017 at 11:48 PM, Greg KH  wrote:
>> > On Fri, Mar 31, 2017 at 02:00:13PM -0700, Doug Anderson wrote:
>> >> On Fri, Mar 31, 2017 at 12:29 PM, Greg KH  
>> >> wrote:
>> >> BTW: I presume that nobody has decided that it would be a wise idea to
>> >> pick the OOM reaper code back to any stable trees?  It seemed a bit
>> >> too scary to me, so I wrote a dumber (but easier to backport) solution
>> >> that avoided the deadlocks I was seeing.  http://crosreview.com/465189
>> >> and the 3 patches above it in case anyone else stumbles on this thread
>> >> and is curious.
>> >
>> > What specific upstream OOM patches are you referring to?  I'm always
>> > glad to review patches for stable kernels, just email
>> > sta...@vger.kernel.org the git commit ids and we can take it from there.
>>
>> +stable
>>
>> I was wondering about the concept of porting the OOM Reaper back to
>> older kernels.  The OOM reaper was originally introduced in:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/oom_kill.c?id=aac453635549699c13a84ea1456d5b0e574ef855
>>
>> Basically the problem described in that patch exists in many older
>> kernels and I've certainly seen crashes related to this in 3.10, but I
>> believe older kernels see the same problems too.
>>
>> Personally I wouldn't know exactly which patches were important to
>> backport and how far to go.  One could arbitrarily try to backport up
>> to 4.6.7 (since 4.6 was the first kernel to really have the OOM
>> reaper) and ignore all the reaper fixes that landed since then.  This
>> would probably be doable for kernel 4.4, though if anyone was trying
>> to support older kernels it might get harder.
>
> Well, I would need someone to give me a list of commits, and actually
> test it to see if it is something that people use/want before I can
> queue anything up for a stable release...
>
> {hint}

Here's a list of the patches between 4.5 and 4.6.7 that touch the oom_killer:

af8e15cc85a2 oom, oom_reaper: do not enqueue task if it is on the
oom_reaper_list head
bb29902a7515 oom, oom_reaper: protect oom_reaper_list using simpler way
e26796066fdf oom: make oom_reaper freezable
29c696e1c6ec oom: make oom_reaper_list single linked
855b01832573 oom, oom_reaper: disable oom_reaper for oom_kill_allocating_task
03049269de43 mm, oom_reaper: implement OOM victims queuing
bc448e897b6d mm, oom_reaper: report success/failure
36324a990cf5 oom: clear TIF_MEMDIE after oom_reaper managed to unmap
the address space
aac453635549 mm, oom: introduce oom reaper
6a618957ad17 mm: oom_kill: don't ignore oom score on exiting tasks
6afcf2895e6f mm,oom: make oom_killer_disable() killable

69b27baf00fa sched: add schedule_timeout_idle()


A few of those are code cleanups or are fixing OOM killer bugs
unrelated to the problem at hand (OOM killer getting stuck forever
because a task won't die), but it may still make sense to take them
just to get the oom killer into a consistent / known state (AKA
4.6.7).


The problem (and the reason I was so hesitant to provide a list of
patches) is that I personally am not a expert on mm.  Thus:

1. I don't know if there are any subtle dependencies on other "mm"
patches.  I can pick the patches above to a 4.4 kernel with only minor
conflicts (plus a fix not to look at MM_SHMEMPAGES, which didn't exist
in 4.4) and they seem to work OK, but with "mm" I always am worried
about minor changes in some other bit of mm code that might be needed
to make all the corner cases work right.

2. There are plenty of other fixes to the OOM reaper in 4.7+.  For
instance this patch:

e2fe14564d33 oom_reaper: close race with exiting task

References a "Fixes" for the original patch that introduced the OOM
reaper, but there are 11 other patches between 4.6 and 4.7 that also
sound like they fix some important bugs and I just don't know if they
are important things to bring back to linux stable or not...  Then
another 13 patches between 4.7 and 4.8.

Maybe +Michal Hocko would have some opinions of which OOM Reaper
patches would be good for picking into linux stable?


-Doug
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

[gre...@linuxfoundation.org]

Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Mon, Apr 03, 2017 at 05:57:11PM +, Long Li wrote:
> I think we need both going forward. They addressed different problems.

I have no idea what this means or what to do...

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

[Long Li]

I think we need both going forward. They addressed different problems.

> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Cathy Avery
> Sent: Thursday, March 30, 2017 6:52 AM
> To: driverdev-devel@linuxdriverproject.org; Stephen Hemminger
> ; gre...@linuxfoundation.org
> Subject: Re: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1]
> scsi: storvsc: properly set residual data length on errors
> 
> Hi,
> 
> So which commit is moving forward and which one is not?
> 
> f1c635b439a5c01776fe3a25b1e2dc546ea82e6f or
> 40630f462824ee24bc00d692865c86c3828094e0?
> 
> We have backported 40630f462824ee24bc00d692865c86c3828094e0 and I am
> unclear if this is a regression and must be removed or it is a regression but 
> is
> fixed by f1c635b439a5c01776fe3a25b1e2dc546ea82e6f and can remain.
> 
> Thanks,
> 
> Cathy
> 
> On 03/28/2017 12:14 PM, Stephen Hemminger wrote:
> > I decided not to send it to stable since problem was only observed on
> > 4.11 but it is probably endemic to all GEN2 VM's
> >
> > -Original Message-
> > From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com]
> > Sent: Tuesday, March 28, 2017 7:29 AM
> > To: Stephen Hemminger ; Long Li
> > 
> > Cc: KY Srinivasan ; Martin K. Petersen
> > ; Haiyang Zhang
> ;
> > j...@linux.vnet.ibm.com; de...@linuxdriverproject.org; linux-scsi
> > ; LKML ;
> > sta...@vger.kernel.org; Greg KH 
> > Subject: Re:
> > [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1]
> > scsi: storvsc: properly set residual data length on errors
> >
> > On 03/27/2017 06:14 PM, Stephen Hemminger wrote:
> >> Are you sure the real problem is not the one fixed by this commit?
> >>
> >> commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f
> >> Author: Stephen Hemminger 
> >> Date:   Tue Mar 7 09:15:53 2017 -0800
> >>
> >>  scsi: storvsc: Workaround for virtual DVD SCSI version
> >>
> >>  Hyper-V host emulation of SCSI for virtual DVD device reports SCSI
> >>  version 0 (UNKNOWN) but is still capable of supporting REPORTLUN.
> >>
> >>  Without this patch, a GEN2 Linux guest on Hyper-V will not boot 4.11
> >>  successfully with virtual DVD ROM device. What happens is that the
> SCSI
> >>  scan process falls back to doing sequential probing by INQUIRY.  But 
> >> the
> >>  storvsc driver has a previous workaround that masks/blocks all errors
> >>  reports from INQUIRY (or MODE_SENSE) commands.  This workaround
> causes
> >>  the scan to then populate a full set of bogus LUN's on the target and
> >>  then sends kernel spinning off into a death spiral doing block reads 
> >> on
> >>  the non-existent LUNs.
> >>
> >>  By setting the correct blacklist flags, the target with the DVD device
> >>  is scanned with REPORTLUN and that works correctly.
> >>
> >>  Patch needs to go in current 4.11, it is safe but not necessary in 
> >> older
> >>  kernels.
> >>
> >>  Signed-off-by: Stephen Hemminger 
> >>  Reviewed-by: K. Y. Srinivasan 
> >>  Reviewed-by: Christoph Hellwig 
> >>  Signed-off-by: Martin K. Petersen 
> >>
> >> -Original Message-
> >> From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com]
> >> Sent: Monday, March 27, 2017 1:22 PM
> >> To: Long Li 
> >> Cc: KY Srinivasan ; Martin K. Petersen
> >> ; Haiyang Zhang
> ;
> >> Stephen Hemminger ;
> j...@linux.vnet.ibm.com;
> >> de...@linuxdriverproject.org; linux-scsi
> >> ; LKML ;
> >> sta...@vger.kernel.org; Greg KH 
> >> Subject:
> >> [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1]
> >> scsi: storvsc: properly set residual data length on errors
> >>
> >> Hi Long Li,
> >>
> >> A kernel bug report was opened against Ubuntu [0].  After a kernel
> >> bisect, it was found that reverting the following commit resolved this bug:
> >>
> >> commit 40630f462824ee24bc00d692865c86c3828094e0
> >> Author: Long Li 
> >> Date:   Wed Dec 14 18:46:03 2016 -0800
> >>
> >>  scsi: storvsc: properly set residual data length on errors
> >>
> >>
> >> The regression was introduced in mainline as of v4.11-rc1.  It was
> >> also cc'd to stable and has landed in v3.12.y, v4.4.y, v4.9.y and v4.10.y.
> >>
> >>
> >> This regression seems pretty severe since it's preventing virtual
> >> machines from booting.  It's affecting a couple of users so far.  I
> >> was hoping to get your feedback, since you are the patch 

Re: [PATCH 2/2] staging: sm750fb: removed line continuations in quoted strings

[Greg KH]

On Mon, Apr 03, 2017 at 10:03:34PM +0530, Prasant Jalan wrote:
> On Sat, Apr 1, 2017 at 12:40 AM, Prasant Jalan  
> wrote:



> A gentle reminder for my patches.
> Any comments or updates will be helpful!

2 days, over a weekend, for a coding style change is pretty fast, don't
you agree?  I will get to these eventually, usually every other week I
flush them all out.

Please be patient, don't worry, the patch is not lost.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: sm750fb: removed line continuations in quoted strings

[Prasant Jalan]

On Sat, Apr 1, 2017 at 12:40 AM, Prasant Jalan  wrote:
> checkpatch gives WARNING: Avoid line continuations in quoted strings.
>
> Trivial fix by removing line continuations and adding another quote at
> the start of next line.
>
> Signed-off-by: Prasant Jalan 
> ---
>  drivers/staging/sm750fb/sm750.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 445c68d..386d4ad 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -837,15 +837,15 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int 
> index)
>
> /* some member of info->var had been set by fb_find_mode */
>
> -   pr_info("Member of info->var is :\n\
> -   xres=%d\n\
> -   yres=%d\n\
> -   xres_virtual=%d\n\
> -   yres_virtual=%d\n\
> -   xoffset=%d\n\
> -   yoffset=%d\n\
> -   bits_per_pixel=%d\n \
> -   ...\n",
> +   pr_info("Member of info->var is :\n"
> +   "xres=%d\n"
> +   "yres=%d\n"
> +   "xres_virtual=%d\n"
> +   "yres_virtual=%d\n"
> +   "xoffset=%d\n"
> +   "yoffset=%d\n"
> +   "bits_per_pixel=%d\n"
> +   " ...\n",
> var->xres,
> var->yres,
> var->xres_virtual,
> --
> 2.7.4
>

Hi All,


A gentle reminder for my patches.
Any comments or updates will be helpful!


Regards, Prasant
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

[Russell King - ARM Linux]

On Mon, Apr 03, 2017 at 09:07:43AM -0500, Rob Herring wrote:
> On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote:
> > I assume if there's another binding doc in progress, it means
> > someone is working on another Synopsys DW CSI-2 subdevice driver.
> 
> Yes. see http://patchwork.ozlabs.org/patch/736177/
> 
> > Unfortunately I don't have the time to contribute and switch to
> > this other subdevice, and do test/debug.
> 
> >From a DT perspective, I'm not asking that you share the subdevice 
> driver, only the binding. Simply put, there's 1 h/w block here, so there 
> should only be 1 binding. The binding is an ABI, so you can't just merge 
> it and change it later.

I think it would be nice to have some kind of standard base binding
for CSI2 interfaces, but beyond the standard compatible/reg/interrupts
and graph properties, I'm not sure what it would look like.

As far as those properties go, the iMX6 version does better than the
DW version, because we specify the full graph, whereas the DW version
only specifies the downstream link.  Once that's done, there's some
properties (like those specifying the output configuration) which
probably ought to be moved to the graph links instead, once they exist.

So, if anything, I think it's the DW version needs to be augmented with
fuller information, and some of the properties moved.

Also, as I've mentioned in my other reply, while they may both appear
to be called "Synopsys DW CSI-2" devices, they appear to be quite
different from the hardware perspective.

The rest 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

[Russell King - ARM Linux]

On Mon, Apr 03, 2017 at 09:11:35AM -0500, Rob Herring wrote:
> On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> > > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam  
> > > wrote:
> > > > Add bindings documentation for the i.MX media driver.
> > > >
> > > > Signed-off-by: Steve Longerbeam 
> > > > ---
> > > >  Documentation/devicetree/bindings/media/imx.txt | 74 
> > > > +
> > > >  1 file changed, 74 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/media/imx.txt 
> > > > b/Documentation/devicetree/bindings/media/imx.txt
> > > > new file mode 100644
> > > > index 000..3059c06
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/imx.txt
> > > > @@ -0,0 +1,74 @@
> > > > +Freescale i.MX Media Video Device
> > > > +=
> > > > +
> > > > +Video Media Controller node
> > > > +---
> > > > +
> > > > +This is the media controller node for video capture support. It is a
> > > > +virtual device that lists the camera serial interface nodes that the
> > > > +media device will control.
> > > > +
> > > > +Required properties:
> > > > +- compatible : "fsl,imx-capture-subsystem";
> > > > +- ports  : Should contain a list of phandles pointing to camera
> > > > +   sensor interface ports of IPU devices
> > > > +
> > > > +example:
> > > > +
> > > > +capture-subsystem {
> > > > +   compatible = "fsl,imx-capture-subsystem";
> > > > +   ports = <_csi0>, <_csi1>;
> > > > +};
> > > > +
> > > > +fim child node
> > > > +--
> > > > +
> > > > +This is an optional child node of the ipu_csi port nodes. If present 
> > > > and
> > > > +available, it enables the Frame Interval Monitor. Its properties can be
> > > > +used to modify the method in which the FIM measures frame intervals.
> > > > +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> > > > +Frame Interval Monitor.
> > > > +
> > > > +Optional properties:
> > > > +- fsl,input-capture-channel: an input capture channel and channel 
> > > > flags,
> > > > +specified as . The channel 
> > > > number
> > > > +must be 0 or 1. The flags can be
> > > > +IRQ_TYPE_EDGE_RISING, 
> > > > IRQ_TYPE_EDGE_FALLING, or
> > > > +IRQ_TYPE_EDGE_BOTH, and specify which input
> > > > +capture signal edge will trigger the input
> > > > +capture event. If an input capture channel 
> > > > is
> > > > +specified, the FIM will use this method to
> > > > +measure frame intervals instead of via the 
> > > > EOF
> > > > +interrupt. The input capture method is much
> > > > +preferred over EOF as it is not subject to
> > > > +interrupt latency errors. However it 
> > > > requires
> > > > +routing the VSYNC or FIELD output signals 
> > > > of
> > > > +the camera sensor to one of the i.MX input
> > > > +capture pads (SD1_DAT0, SD1_DAT1), which 
> > > > also
> > > > +gives up support for SD1.
> > > > +
> > > > +
> > > > +mipi_csi2 node
> > > > +--
> > > > +
> > > > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > > > +CSI-2 sensors.
> > > > +
> > > > +Required properties:
> > > > +- compatible   : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> > > 
> > > As I mentioned in v5, there's a DW CSI2 binding in progress. This
> > > needs to be based on that.
> > 
> > Maybe someone can provide some kind of reference to it, and it's
> > associated driver?
> 
> Let me Google that for you (TM). The reference is in my comments on v5. 
> Here's a reference to it [1].

Looking at the actual driver, it seems to at least have a different
register layout:

registerimx6dw
version 0x000   0x000
n_lanes 0x004   0x004
phy_shutdownz   0x008   -
dphy_resetz 0x00c   -
resetn  0x010   0x008
phy_state   0x014   -
data_ids_1  0x018   0x010
data_ids_2  0x01c   0x014
err10x020   -
err20x024   -
msk10x028   -
msk20x02c   -
phy_tst_ctrl0   0x030   -
phy_tst_ctrl1   0x034   -
sft_reset   0xf00   -   (not part of CSI2, but a IMX6 specific
CSI2 to IPU gasket layer, but lives in
CSI2's register region)

The DW version has many more registers than are documented by the iMX6
version.  Only the first two registers appear to be common 

Re: [PATCH v6 03/39] [media] dt/bindings: Add bindings for OV5640

[Rob Herring]

On Mon, Mar 27, 2017 at 05:40:20PM -0700, Steve Longerbeam wrote:
> Add device tree binding documentation for the OV5640 camera sensor.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  .../devicetree/bindings/media/i2c/ov5640.txt   | 45 
> ++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt

I already acked this. Please add acks when posting new versions.

Rob
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 01/39] [media] dt-bindings: Add bindings for video-multiplexer device

[Rob Herring]

On Mon, Mar 27, 2017 at 05:40:18PM -0700, Steve Longerbeam wrote:
> From: Philipp Zabel 
> 
> Add bindings documentation for the video multiplexer device.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Steve Longerbeam 
> ---
>  .../bindings/media/video-multiplexer.txt   | 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/video-multiplexer.txt

Acked-by: Rob Herring 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

[Rob Herring]

On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote:
> On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam  
> > wrote:
> > > Add bindings documentation for the i.MX media driver.
> > >
> > > Signed-off-by: Steve Longerbeam 
> > > ---
> > >  Documentation/devicetree/bindings/media/imx.txt | 74 
> > > +
> > >  1 file changed, 74 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/imx.txt 
> > > b/Documentation/devicetree/bindings/media/imx.txt
> > > new file mode 100644
> > > index 000..3059c06
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/imx.txt
> > > @@ -0,0 +1,74 @@
> > > +Freescale i.MX Media Video Device
> > > +=
> > > +
> > > +Video Media Controller node
> > > +---
> > > +
> > > +This is the media controller node for video capture support. It is a
> > > +virtual device that lists the camera serial interface nodes that the
> > > +media device will control.
> > > +
> > > +Required properties:
> > > +- compatible : "fsl,imx-capture-subsystem";
> > > +- ports  : Should contain a list of phandles pointing to camera
> > > +   sensor interface ports of IPU devices
> > > +
> > > +example:
> > > +
> > > +capture-subsystem {
> > > +   compatible = "fsl,imx-capture-subsystem";
> > > +   ports = <_csi0>, <_csi1>;
> > > +};
> > > +
> > > +fim child node
> > > +--
> > > +
> > > +This is an optional child node of the ipu_csi port nodes. If present and
> > > +available, it enables the Frame Interval Monitor. Its properties can be
> > > +used to modify the method in which the FIM measures frame intervals.
> > > +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> > > +Frame Interval Monitor.
> > > +
> > > +Optional properties:
> > > +- fsl,input-capture-channel: an input capture channel and channel flags,
> > > +specified as . The channel number
> > > +must be 0 or 1. The flags can be
> > > +IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, 
> > > or
> > > +IRQ_TYPE_EDGE_BOTH, and specify which input
> > > +capture signal edge will trigger the input
> > > +capture event. If an input capture channel is
> > > +specified, the FIM will use this method to
> > > +measure frame intervals instead of via the 
> > > EOF
> > > +interrupt. The input capture method is much
> > > +preferred over EOF as it is not subject to
> > > +interrupt latency errors. However it requires
> > > +routing the VSYNC or FIELD output signals of
> > > +the camera sensor to one of the i.MX input
> > > +capture pads (SD1_DAT0, SD1_DAT1), which also
> > > +gives up support for SD1.
> > > +
> > > +
> > > +mipi_csi2 node
> > > +--
> > > +
> > > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > > +CSI-2 sensors.
> > > +
> > > +Required properties:
> > > +- compatible   : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> > 
> > As I mentioned in v5, there's a DW CSI2 binding in progress. This
> > needs to be based on that.
> 
> Maybe someone can provide some kind of reference to it, and it's
> associated driver?

Let me Google that for you (TM). The reference is in my comments on v5. 
Here's a reference to it [1].

[1] https://lkml.org/lkml/2017/3/20/524

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

[Rob Herring]

On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote:
> 
> 
> On 03/28/2017 05:21 PM, Rob Herring wrote:
> > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam  
> > wrote:
> > > Add bindings documentation for the i.MX media driver.
> > > 
> > > 
> > > +
> > > +mipi_csi2 node
> > > +--
> > > +
> > > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > > +CSI-2 sensors.
> > > +
> > > +Required properties:
> > > +- compatible   : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> > 
> > As I mentioned in v5, there's a DW CSI2 binding in progress. This
> > needs to be based on that.
> 
> Hi Rob, I'm not sure what you are asking me to do.
> 
> I assume if there's another binding doc in progress, it means
> someone is working on another Synopsys DW CSI-2 subdevice driver.

Yes. see http://patchwork.ozlabs.org/patch/736177/

> Unfortunately I don't have the time to contribute and switch to
> this other subdevice, and do test/debug.

>From a DT perspective, I'm not asking that you share the subdevice 
driver, only the binding. Simply put, there's 1 h/w block here, so there 
should only be 1 binding. The binding is an ABI, so you can't just merge 
it and change it later.

The driver side is a decision for the V4L2 maintainers.

> For now I would prefer if this patchset is merged as is, and
> then contribute/switch to another CSI-2 subdev later. It is
> also getting very difficult managing all these patches (39 as
> of this version), and I'd prefer not to spam the lists with
> such large patchsets for too much longer.

Then maybe you should figure out how to split up the series. I've not 
looked at it to provide suggestions.

Rob
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH] binder: Don't require the binder lock when killed in binder_thread_read()

[peter enderborg]

On 03/31/2017 07:53 PM, Douglas Anderson wrote:
> Sometimes when we're out of memory the OOM killer decides to kill a
> process that's in binder_thread_read().  If we happen to be waiting
> for work we'll get the kill signal and wake up.  That's good.  ...but
> then we try to grab the binder lock before we return.  That's bad.
>
> The problem is that someone else might be holding the one true global
> binder lock.  If that one other process is blocked then we can't
> finish exiting.  In the worst case, the other process might be blocked
> waiting for memory.  In that case we'll have a really hard time
> exiting.
>
> On older kernels that don't have the OOM reaper (or something
> similar), like kernel 4.4, this is a really big problem and we end up
> with a simple deadlock because:
> * Once we pick a process to OOM kill we won't pick another--we first
>   wait for the process we picked to die.  The reasoning is that we've
>   given the doomed process access to special memory pools so it can
>   quit quickly and we don't have special pool memory to go around.
> * We don't have any type of "special access donation" that would give
>   the mutex holder our special access.
>
> On kernel 4.4 w/ binder patches, we easily see this happen:
>
> We just attempted this OOM kill:
>   Killed process 4132 (Binder_1) total-vm:949904kB, anon-rss:4kB, file-rss:0kB
>
> The doomed task:
>   Stack traceback for pid 4132
>4132 3380  00   D  Binder_1
>   Call trace:
>__switch_to+0x9c/0xa8
>__schedule+0x504/0x740
>schedule+0x88/0xa8
>schedule_preempt_disabled+0x28/0x44
>__mutex_lock_slowpath+0xf8/0x1a4
>mutex_lock+0x4c/0x68
>binder_thread_read+0x68c/0x11bc
>binder_ioctl_write_read.constprop.46+0x1e8/0x318
>binder_ioctl+0x370/0x778
>compat_SyS_ioctl+0x134/0x10ac
>el0_svc_naked+0x24/0x28
>
> The binder lock holder:
>4001 3380  04   RBinder_7
>   Call trace:
>__switch_to+0x9c/0xa8
>__schedule+0x504/0x740
>preempt_schedule_common+0x28/0x48
>preempt_schedule+0x24/0x2c
>_raw_spin_unlock+0x44/0x50
>list_lru_count_one+0x40/0x50
>super_cache_count+0x68/0xa0
>shrink_slab.part.54+0xfc/0x4a4
>shrink_zone+0xa8/0x198
>try_to_free_pages+0x408/0x590
>__alloc_pages_nodemask+0x60c/0x95c
>__read_swap_cache_async+0x98/0x214
>read_swap_cache_async+0x48/0x7c
>swapin_readahead+0x188/0x1b8
>handle_mm_fault+0xbf8/0x1050
>do_page_fault+0x140/0x2dc
>do_mem_abort+0x64/0xd8
>   Exception stack: < ... cut ... >
>el1_da+0x18/0x78
>binder_ioctl+0x370/0x778
>compat_SyS_ioctl+0x134/0x10ac
>el0_svc_naked+0x24/0x28
>
> There's really not a lot of reason to grab the binder lock when we're
> just going to exit anyway.  Add a little bit of complexity to the code
> to allow binder_thread_read() to sometimes return without the lock
> held.
>
> NOTE: to do this safely we need to make sure that we can safely do
> these things _without_ the global binder lock:
> * Muck with proc->ready_threads
> * Clear a bitfield in thread->looper
>
> It appears that those two operations don't need to be done together
> and it's OK to have different locking solutions for the two.  Thus:
>
> 1. We change thread->looper to atomic_t and use atomic ops to muck
>with it.  This means we're not clobbering someone else's work with
>our read/modify/write.
>
>Note that I haven't confirmed that every modify of "thread->looper"
>can be done without the binder mutex or without some
>coarser-grained lock.  ...but clearing the
>BINDER_LOOPER_STATE_WAITING bit should be fine.  The only place
>looking at it is binder_deferred_flush().  Also: while erroring out
>we also may clear BINDER_LOOPER_STATE_NEED_RETURN.  This looks to
>be OK, though the code isn't trivial to follow.
>
> 2. We add a new fine-grained mutex (per "proc" structure) to guard all
>of the "_threads" counters.  Technically the only value we're
>modifying is "proc->ready_threads" and we're just decrementing it
>(so maybe we could use atomic_t here, too?).  ...but it appears
>that all of the "_threads" work together so protecting them
>together seems to make the most sense.
>
>Note that to avoid deadlock:
>* We never first grab the fine grained mutex and _then_ the binder
>  mutex.
>* We always grab the fine grained mutex for short periods and never
>  do anything blocking while holding it.
>
> To sum it all up:
>
> 1. This patch does improve the chances that we will be able to kill a
>task quickly when we want to.  That means this patch has some
>merit.
> 2. Though this patch has merit, it isn't isn't actually all that
>critical because:
>2a) On newer kernels the OOM reaper should keep us from getting
>deadlocked.
>2b) Even on old kernels there are other deadlock cases we hit even
>if we fix binder in this way.
>
> Signed-off-by: Douglas Anderson 

Re: [RFC PATCH] binder: Don't require the binder lock when killed in binder_thread_read()

[Greg KH]

On Sat, Apr 01, 2017 at 07:34:53PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Mar 31, 2017 at 11:48 PM, Greg KH  wrote:
> > On Fri, Mar 31, 2017 at 02:00:13PM -0700, Doug Anderson wrote:
> >> On Fri, Mar 31, 2017 at 12:29 PM, Greg KH  
> >> wrote:
> >> BTW: I presume that nobody has decided that it would be a wise idea to
> >> pick the OOM reaper code back to any stable trees?  It seemed a bit
> >> too scary to me, so I wrote a dumber (but easier to backport) solution
> >> that avoided the deadlocks I was seeing.  http://crosreview.com/465189
> >> and the 3 patches above it in case anyone else stumbles on this thread
> >> and is curious.
> >
> > What specific upstream OOM patches are you referring to?  I'm always
> > glad to review patches for stable kernels, just email
> > sta...@vger.kernel.org the git commit ids and we can take it from there.
> 
> +stable
> 
> I was wondering about the concept of porting the OOM Reaper back to
> older kernels.  The OOM reaper was originally introduced in:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/oom_kill.c?id=aac453635549699c13a84ea1456d5b0e574ef855
> 
> Basically the problem described in that patch exists in many older
> kernels and I've certainly seen crashes related to this in 3.10, but I
> believe older kernels see the same problems too.
> 
> Personally I wouldn't know exactly which patches were important to
> backport and how far to go.  One could arbitrarily try to backport up
> to 4.6.7 (since 4.6 was the first kernel to really have the OOM
> reaper) and ignore all the reaper fixes that landed since then.  This
> would probably be doable for kernel 4.4, though if anyone was trying
> to support older kernels it might get harder.

Well, I would need someone to give me a list of commits, and actually
test it to see if it is something that people use/want before I can
queue anything up for a stable release...

{hint}

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] scsi: storvsc: Add support for FC rport.

[Cathy Avery]

On 04/03/2017 08:17 AM, Christoph Hellwig wrote:

if (host->transportt == fc_transport_template) {
+   struct fc_rport_identifiers ids = {
+   .roles = FC_PORT_ROLE_FCP_TARGET,
+   };

I don't think storvsc ever acts as FCP target.


In order to implement the work around so that the scsi scan works 
indicating FC_PORT_ROLE_FCP_TARGET as a role was necessary due to its 
test in fc_scsi_scan_rport. The idea here is to avoid making any changes 
to the fc_transport driver which was of some concern.



Thanks,

Cathy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] scsi: storvsc: Add support for FC rport.

[Christoph Hellwig]

>   if (host->transportt == fc_transport_template) {
> + struct fc_rport_identifiers ids = {
> + .roles = FC_PORT_ROLE_FCP_TARGET,
> + };

I don't think storvsc ever acts as FCP target.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] remove custom Michael MIC implementation

[Greg Kroah-Hartman]

On Mon, Apr 03, 2017 at 07:03:59PM +1000, Tobin C. Harding wrote:
> On Mon, Apr 03, 2017 at 08:19:40AM +0300, Kalle Valo wrote:
> > + linux-wireless
> > 
> > "Tobin C. Harding"  writes:
> > 
> > > On Fri, Mar 31, 2017 at 09:58:51AM +0200, Wolfram Sang wrote:
> > >> 
> > >> > The code is untested, I have hardware in the mail.
> > >> 
> > >> Cool!
> > >
> > > The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
> > > a SDW-823 and should use the ks7010 driver. I am going to attempt to
> > > get it running on a Raspberry Pi B+. I ordered the wrong size break
> > > out board originally so waiting on the new one now.
> > >
> > >> 
> > >> > If any one is interested and has any comments I would really like to
> > >> > hear them. I am open to all suggestions (even down to trivial coding
> > >> > style issues).
> > >> 
> > >> I'll just repeat that the key move to get this driver out of staging is
> > >> to get away from the WEXT interface to CFG80211. Otherwise no chance
> > >> that wireless maintainers will even look at it. This is a huge change
> > >> but once it is done, features like Michael MIC come with it for free
> > >> (from what I recall, I am not a wireless expert myself).
> > >
> > > That would explain why I could not find more than the Orinoco driver
> > > using the Michael MIC module directly.
> > 
> > I think cfg80211 and mac80211 got mixed up. mac80211 (the full IEEE
> > 802.11 stack for "softmac" devices) provides Michael MIC implementation,
> > but cfg80211 (for "hardmac" devices) does not.
> 
> Cool, thanks for clarifying. Hilariously I was just sitting down
> trying to figure out what was up after a day spent trying to merge
> ideas from ath6kl (fullmac) and ks7010. I finally spent some time
> reading the cw1200 driver (softmac) for further inspiration.

As an example of a driver that has been moved from an internal wireless
stack to using the kernel stack is the vt6655 driver.  I think it's the
only driver that has done this type of transition, so look at the patch
history of it for an example of what to do.

good luck!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] scsi: storvsc: Add support for FC rport.

[Cathy Avery]

Included in the current storvsc driver for Hyper-V is the ability
to access luns on an FC fabric via a virtualized fiber channel
adapter exposed by the Hyper-V host. The driver also attaches to
the FC transport to allow host and port names to be published under
/sys/class/fc_host/hostX. Current customer tools running on the VM
require that these names be available in the well known standard
location under fc_host/hostX.

A problem arose when attaching to the FC transport. The scsi_scan
code attempts to call fc_user_scan which has basically become a no-op
due to the fact that the virtualized FC device does not expose rports.
At this point you cannot refresh the scsi bus after mapping or unmapping
luns on the SAN without a reboot of the VM.

This patch stubs in an rport per fc_host in storvsc so that the
requirement of a defined rport is now met within the fc_transport and
echo "- - -" > /sys/class/scsi_host/hostX/scan now works.

Signed-off-by: Cathy Avery 
---
Changes since v1:
- Fix fc_rport_identifiers init [Stephen Hemminger]
- Better error checking
---
 drivers/scsi/storvsc_drv.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 638e5f4..37646d1 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -478,6 +478,9 @@ struct storvsc_device {
 */
u64 node_name;
u64 port_name;
+#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
+   struct fc_rport *rport;
+#endif
 };
 
 struct hv_host_device {
@@ -1816,19 +1819,27 @@ static int storvsc_probe(struct hv_device *device,
target = (device->dev_instance.b[5] << 8 |
 device->dev_instance.b[4]);
ret = scsi_add_device(host, 0, target, 0);
-   if (ret) {
-   scsi_remove_host(host);
-   goto err_out2;
-   }
+   if (ret)
+   goto err_out3;
}
 #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
if (host->transportt == fc_transport_template) {
+   struct fc_rport_identifiers ids = {
+   .roles = FC_PORT_ROLE_FCP_TARGET,
+   };
+
fc_host_node_name(host) = stor_device->node_name;
fc_host_port_name(host) = stor_device->port_name;
+   stor_device->rport = fc_remote_port_add(host, 0, );
+   if (!stor_device->rport)
+   goto err_out3;
}
 #endif
return 0;
 
+err_out3:
+   scsi_remove_host(host);
+
 err_out2:
/*
 * Once we have connected with the host, we would need to
@@ -1854,8 +1865,10 @@ static int storvsc_remove(struct hv_device *dev)
struct Scsi_Host *host = stor_device->host;
 
 #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
-   if (host->transportt == fc_transport_template)
+   if (host->transportt == fc_transport_template) {
+   fc_remote_port_delete(stor_device->rport);
fc_remove_host(host);
+   }
 #endif
scsi_remove_host(host);
storvsc_dev_remove(dev);
-- 
2.5.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] remove custom Michael MIC implementation

[Arend Van Spriel]

seems we are missing out again?

On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote:
> "Tobin C. Harding"  writes:
> 
>> Except one: do you know off the top of your head of a canonical
>> implementation of a softmac wi-fi driver.
> 
> I'll suggest taking a look at the ath9k driver :)

Looking at ks7010 driver it looks like it has 802.11 stack in firmware
and not sure if Renesas is actively supporting this effort to come up
with mac80211-friendly firmware or provide detailed chip info.

Regards,
Arend

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] remove custom Michael MIC implementation

[Toke Høiland-Jørgensen]

"Tobin C. Harding"  writes:

> Except one: do you know off the top of your head of a canonical
> implementation of a softmac wi-fi driver.

I'll suggest taking a look at the ath9k driver :)

-Toke
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] remove custom Michael MIC implementation

[Kalle Valo]

"Tobin C. Harding"  writes:

>> >> But if you want a clean WEXT driver first, this is a step in the right
>> >> direction.
>> >
>> > Let's go for a CFG80211 driver and get out of staging :) So next step
>> > is I guess study the ath6kl driver, learn how CFG80211 is done and
>> > implement that interface in ks7010? Oh, and test that it works.
>> 
>> Please keep linux-wireless list in loop so that people on that list can
>> help.
>
> How newbie friendly is the linux-wireless list please?

I would claim quite friendly, but I'm finnish and our definition of
"friendly" seems to be very different from rest of the world ;)

> I am having trouble separating the data path code from the control
> path. I think I will spend a few more days on it though before asking
> any questions.

People do send questions to the list and most of the time they get
answered. So go for it.

There's also an irc channel which usually is helpful:

https://wireless.wiki.kernel.org/en/users/support#linux_wireless_user_irc_channel

> Except one: do you know off the top of your head of a canonical
> implementation of a softmac wi-fi driver.

You mean a mac80211 driver? mac80211_hwsim is the simplest one, but
that's not a real driver as it's a simulator. Just grep
ieee80211_register() to find all the drivers. Smaller drivers like
rtl8xxxu or wl1251 might be good starting points to get familiar with
the stack.

And I guess you already saw the documentation:

https://wireless.wiki.kernel.org/en/developers/documentation/mac80211

-- 
Kalle Valo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] remove custom Michael MIC implementation

[Tobin C. Harding]

On Mon, Apr 03, 2017 at 08:19:40AM +0300, Kalle Valo wrote:
> + linux-wireless
> 
> "Tobin C. Harding"  writes:
> 
> > On Fri, Mar 31, 2017 at 09:58:51AM +0200, Wolfram Sang wrote:
> >> 
> >> > The code is untested, I have hardware in the mail.
> >> 
> >> Cool!
> >
> > The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
> > a SDW-823 and should use the ks7010 driver. I am going to attempt to
> > get it running on a Raspberry Pi B+. I ordered the wrong size break
> > out board originally so waiting on the new one now.
> >
> >> 
> >> > If any one is interested and has any comments I would really like to
> >> > hear them. I am open to all suggestions (even down to trivial coding
> >> > style issues).
> >> 
> >> I'll just repeat that the key move to get this driver out of staging is
> >> to get away from the WEXT interface to CFG80211. Otherwise no chance
> >> that wireless maintainers will even look at it. This is a huge change
> >> but once it is done, features like Michael MIC come with it for free
> >> (from what I recall, I am not a wireless expert myself).
> >
> > That would explain why I could not find more than the Orinoco driver
> > using the Michael MIC module directly.
> 
> I think cfg80211 and mac80211 got mixed up. mac80211 (the full IEEE
> 802.11 stack for "softmac" devices) provides Michael MIC implementation,
> but cfg80211 (for "hardmac" devices) does not.

Cool, thanks for clarifying. Hilariously I was just sitting down
trying to figure out what was up after a day spent trying to merge
ideas from ath6kl (fullmac) and ks7010. I finally spent some time
reading the cw1200 driver (softmac) for further inspiration.

> >> Without the CFG80211 conversion, replacing the Michael custom
> >> implementation with the in-kernel one makes the driver a tad better and
> >> is good exercise. However, it will sadly not help to get the driver out
> >> of staging.
> >
> > I'll drop it then. Could you please tell me, is there any thing else
> > more I need to do to let LKML know that this RFC is dropped? Or is
> > this reply enough. I don't want to use any ones time unnecessarily.
> >
> >> 
> >> But if you want a clean WEXT driver first, this is a step in the right
> >> direction.
> >
> > Let's go for a CFG80211 driver and get out of staging :) So next step
> > is I guess study the ath6kl driver, learn how CFG80211 is done and
> > implement that interface in ks7010? Oh, and test that it works.
> 
> Please keep linux-wireless list in loop so that people on that list can
> help.

How newbie friendly is the linux-wireless list please? I am having
trouble separating the data path code from the control path. I think I
will spend a few more days on it though before asking any questions.

Except one: do you know off the top of your head of a canonical
implementation of a softmac wi-fi driver.

thanks,
Tobin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: rtl8712: fixed multiple line derefence issue

[Prasant Jalan]

Checkpatch emits WARNING: Avoid multiple line dereference.

Checkpatch warning is fixed by:
* Trivial indentation improvement and
* Using += instead of + helps shortening the statement.

Signed-off-by: Prasant Jalan 
---

  v2:
* Used += instead of + (pointed out by Joe Perches)
* Rebased to the latest next tree

 drivers/staging/rtl8712/rtl871x_xmit.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c 
b/drivers/staging/rtl8712/rtl871x_xmit.c
index de88819..eda2aee 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -213,8 +213,9 @@ sint r8712_update_attrib(struct _adapter *padapter, _pkt 
*pkt,
if (padapter->pwrctrlpriv.pwr_mode !=
padapter->registrypriv.power_mgnt) {
del_timer_sync(>dhcp_timer);
-   r8712_set_ps_mode(padapter, padapter->registrypriv.
-   power_mgnt, padapter->registrypriv.smart_ps);
+   r8712_set_ps_mode(padapter,
+ padapter->registrypriv.power_mgnt,
+ padapter->registrypriv.smart_ps);
}
}
 }
@@ -416,15 +417,13 @@ static sint xmitframe_addmic(struct _adapter *padapter,
   [10], 6);
}
if (pqospriv->qos_option == 1)
-   priority[0] = (u8)pxmitframe->
- attrib.priority;
+   priority[0] = (u8)pxmitframe->attrib.priority;
r8712_secmicappend(, [0], 4);
payload = pframe;
for (curfragnum = 0; curfragnum < pattrib->nr_frags;
 curfragnum++) {
payload = (u8 *)RND4((addr_t)(payload));
-   payload = payload + pattrib->
- hdrlen + pattrib->iv_len;
+   payload += pattrib->hdrlen + pattrib->iv_len;
if ((curfragnum + 1) == pattrib->nr_frags) {
length = pattrib->last_txcmdsz -
  pattrib->hdrlen -
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8712: fixed multiple line derefence issue

[Prasant Jalan]

On Mon, Apr 3, 2017 at 10:27 AM, Joe Perches  wrote:
> On Mon, 2017-04-03 at 09:43 +0530, Prasant Jalan wrote:
>> On Thu, Mar 30, 2017 at 12:03 AM, Prasant Jalan  
>> wrote:
>> > Checkpatch emits WARNING: Avoid multiple line dereference.
>> >
>> > Trivial indentation improvement helps fix the checkpatch warning.
> []
>> > diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c 
>> > b/drivers/staging/rtl8712/rtl871x_xmit.c
> []
>> > @@ -416,15 +417,14 @@ static sint xmitframe_addmic(struct _adapter 
>> > *padapter,
>> >[10], 6);
>> > }
>> > if (pqospriv->qos_option == 1)
>> > -   priority[0] = (u8)pxmitframe->
>> > - attrib.priority;
>> > +   priority[0] = 
>> > (u8)pxmitframe->attrib.priority;
>> > r8712_secmicappend(, [0], 4);
>> > payload = pframe;
>> > for (curfragnum = 0; curfragnum < 
>> > pattrib->nr_frags;
>> >  curfragnum++) {
>> > payload = (u8 *)RND4((addr_t)(payload));
>> > -   payload = payload + pattrib->
>> > - hdrlen + pattrib->iv_len;
>> > +   payload = payload + pattrib->hdrlen +
>> > + pattrib->iv_len;
>
> += would be shorter

Hi Joe,

Looks like back to school for me for overlooking such a trivial thing.

Thanks for the pointer, I will update the patch and resend.


Regards, Prasant
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel