[RFC PATCHv2 20/21] 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   | 697 ++--
 drivers/staging/android/ion/ion.h   |  73 +---
 drivers/staging/android/uapi/ion.h  |  25 +-
 4 files changed, 49 insertions(+), 799 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..64c652b 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 @@ 

[RFC PATCHv2 21/21] 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 64c652b..8bd90ce 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

[RFC PATCHv2 11/21] 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

[RFC PATCHv2 17/21] 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;
+  

[RFC PATCHv2 19/21] 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

[RFC PATCHv2 10/21] 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
--- 

[RFC PATCHv2 18/21] 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)
-  

[RFC PATCHv2 08/21] 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);

[RFC PATCHv2 16/21] 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);
  

[RFC PATCHv2 15/21] staging: android: ion: Break the ABI in the name of forward progress

[Laura Abbott]

To: Sumit Semwal 
To: Riley Andrews 
Cc: rom...@google.com
To: a...@android.com
To: Riley Andrews 
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Greg Kroah-Hartman 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: Brian Starkey 
Cc: Daniel Vetter 
Cc: Mark Brown 
Cc: Benjamin Gaignard 
Cc: linux...@kvack.org
Cc: Laurent Pinchart 


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, 

[RFC PATCHv2 07/21] 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;
-   

[RFC PATCHv2 12/21] 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 | 156 ---
 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, 1000 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
+++ 

[RFC PATCHv2 14/21] 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

[RFC PATCHv2 13/21] 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 

[RFC PATCHv2 09/21] 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_priv.h   |  8 +--
 drivers/staging/android/uapi/ion.h   | 21 -
 5 files changed, 2 insertions(+), 84 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 ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 }
 

[RFC PATCHv2 06/21] 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);
-
-   

[RFC PATCHv2 05/21] staging: android: ion: Duplicate sg_table

[Laura Abbott]

Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.

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

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index c2adfe1..7dcb8a9 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -800,6 +800,32 @@ 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;
+   int ret, i;
+   struct scatterlist *sg, *new_sg;
+
+   new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+   if (!new_table)
+   return ERR_PTR(-ENOMEM);
+
+   ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+   if (ret) {
+   kfree(new_table);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   new_sg = new_table->sgl;
+   for_each_sg(table->sgl, sg, table->nents, i) {
+   memcpy(new_sg, sg, sizeof(*sg));
+   sg->dma_address = 0;
+   new_sg = sg_next(new_sg);
+   }
+
+   return new_table;
+}
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
@@ -807,13 +833,15 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
 
ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-   return buffer->sg_table;
+   return dup_sg_table(buffer->sg_table);
 }
 
 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);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
-- 
2.7.4

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

[RFC PATCHv2 03/21] 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

[RFC PATCHv2 01/21] 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 
---
 drivers/base/dma-contiguous.c |  5 +++--
 include/linux/cma.h   |  4 +++-
 mm/cma.c  | 11 +--
 mm/cma.h  |  1 +
 mm/cma_debug.c|  2 +-
 5 files changed, 17 insertions(+), 6 deletions(-)

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..0d187b1 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;
@@ -201,6 +207,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
+   cma->name = name;
*res_cma = cma;
cma_area_count++;
totalcma_pages += (size / PAGE_SIZE);
@@ -229,7 +236,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 cma **res_cma)
+   bool fixed, const char *name, struct cma **res_cma)
 {
phys_addr_t memblock_end = memblock_end_of_DRAM();
phys_addr_t highmem_start;
@@ -335,7 +342,7 @@ int __init cma_declare_contiguous(phys_addr_t base,
base = addr;
}
 
-   ret = cma_init_reserved_mem(base, size, order_per_bit, res_cma);
+   ret = cma_init_reserved_mem(base, size, order_per_bit, name, res_cma);
if (ret)
goto err;
 
diff --git a/mm/cma.h b/mm/cma.h
index 17c75a4..4986128 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -11,6 +11,7 @@ struct cma {
struct hlist_head mem_head;
spinlock_t mem_head_lock;
 #endif
+   const char *name;
 };
 
 extern struct cma cma_areas[MAX_CMA_AREAS];
diff --git a/mm/cma_debug.c b/mm/cma_debug.c
index ffc0c3d..595b757 100644
--- a/mm/cma_debug.c
+++ b/mm/cma_debug.c
@@ -167,7 +167,7 @@ static void cma_debugfs_add_one(struct cma *cma, int idx)
char name[16];
int u32s;
 
-   

[RFC PATCHv2 04/21] 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 

[RFC PATCHv2 02/21] 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 0d187b1..9a040e1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -498,3 +498,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

[RFC PATCHv2 00/21] Ion clean in preparation for moving out of staging

[Laura Abbott]

Hi,

This is v2 of the series to do some serious Ion clean up in preparation for
moving out of staging. I got good feedback last time so this series mostly
attempts to address that feedback and do more still more cleanup. Highlights:

- All calls to DMA APIs should now be with a real actual proper device
  structure
- Patch to stop setting sg_dma_address manually now included
- Fix for a bug in the query interface
- Removal of custom ioctl interface
- Removal of import interface
- Removal of any notion of using Ion as an in kernel interface.
- Cleanup of ABI so compat interface is no longer needed
- Deletion of a bit more platform code
- Combined heap enumeration and heap registration code up so there are fewer
  layers of abstraction
- Some general cleanup and header reduction.
- Removal of both the ion_client and ion_handle structures since these mostly
  become redundant. As a result, Ion only returns a dma_buf fd. The overall
  result is that the only Ion interfaces are the query ioctl and the alloc
  ioctl.

The following are still TODOs/open problems:
- Sumit's comments about the CMA naming.
- Bindings/platform for chunk and carveout heap
- There was some discussion about making the sg_table duplication generic. I
  got bogged down in handling some of the edge cases for generic handling
  so I put this aside. Making it generic is still something that should happen.
- More fine-grained support for restricting heap access. There are good
  arguments to be made for having a way for having good integration with
  selinux and other policy mechanisms.
- While not on the original list, there is still no good good test standalone
  test framework. I noticed that the existing ion_test was fairly generic so I
  proposed moving it to dma_buf. Daniel Vetter suggested just using the VGEM
  module instead. Ideally, the tests can live as part of some other existing
  test set (drm tests maybe?)

Feedback appreciated as always.

Thanks,
Laura

Laura Abbott (21):
  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

 drivers/base/dma-contiguous.c  |5 +-
 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  | 1164 +++-
 drivers/staging/android/ion/ion.h  |  393 +--
 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 |  156 ---
 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   |   25 +-
 mm/cma.h   |1 +
 mm/cma_debug.c |2 +-
 30 

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Eric Anholt]

Mauro Carvalho Chehab  writes:

> Em Wed, 15 Mar 2017 18:46:24 -0700
> Michael Zoran  escreveu:
>
>> On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:
>> 
>> > No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
>> > Perhaps I'm missing some other patch. I'm compiling it from
>> > the Greg's staging tree (branch staging-next):
>> >https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.
>> > git/log/?h=staging-next
>> > 
>> > Btw, as I'm running Raspbian, and didn't want to use compat32 bits, 
>> > I'm compiling the Kernel as an arm32 bits Kernel.
>> > 
>> > I did a small trick to build the DTB on arm32:
>> > 
>> >ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
>> > arch/arm/boot/dts/bcm2837-rpi-3-b.dts
>> >ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
>> > arch/arm/boot/dts/bcm2837.dtsi
>> >git checkout arch/arm/boot/dts/Makefile
>> >sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb bcm2837-rpi-3-
>> > b.dtb," a && mv a arch/arm/boot/dts/Makefile
>> >   
>> 
>> Two other hacks are currently needed to get the camera to work:
>> 
>> 1. Add this to config.txt(This required to get the firmware to detect
>> the camera)
>> 
>> start_x=1
>> gpu_mem=128
>
> I had this already.
>
>> 
>> 2. VC4 is incompatible with the firmware at this time, so you need 
>> to presently munge the build configuration. What you do is leave
>> simplefb in the build config(I'm assuming you already have that), but
>> you will need to remove VC4 from the config.
>> 
>> The firmware currently adds a node for a simplefb for debugging
>> purposes to show the boot log.  Surprisingly, this is still good enough
>> for basic usage and testing.  
>
> That solved the issue. Thanks! It would be good to add a notice
> about that at the TODO, not let it build if DRM_VC4.
>
> Please consider applying the enclosed path.

The VC4 incompatibility (camera firmware's AWB ends up briefly using the
GPU, without coordinating with the Linux driver) is supposed to be fixed
in current firmware
(https://github.com/raspberrypi/firmware/issues/760#issuecomment-287391025)


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

[PATCH] vmbus: fix missed ring events on boot

[Stephen Hemminger]

During initialization, the channel initialization code schedules the
tasklet to scan the VMBUS receive event page (i.e. simulates an
interrupt). The problem was that it invokes the tasklet on a different
CPU from where it normally runs and therefore if an event is present,
it will clear the bit but not find the associated channel.

This can lead to missed events, typically stuck tasks, during bootup
when sub channels are being initialized. Typically seen as stuck
boot with 8 or more CPU's.

This patch is not necessary for upstream (4.11 and later) since
commit 631e63a9f346 ("vmbus: change to per channel tasklet").
This changed vmbus code to get rid of common tasklet which
caused the problem.

Cc: sta...@vger.kernel.org
Signed-off-by: Stephen Hemminger 
---
 drivers/hv/channel.c  | 10 +-
 drivers/hv/channel_mgmt.c | 26 +++---
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index be34547cdb68..a8790498ba2b 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -609,7 +609,15 @@ static int vmbus_close_internal(struct vmbus_channel 
*channel)
get_order(channel->ringbuffer_pagecount * PAGE_SIZE));
 
 out:
-   hv_event_tasklet_enable(channel);
+   if (channel->target_cpu != get_cpu()) {
+   smp_call_function_single(channel->target_cpu,
+
(smp_call_func_t)hv_event_tasklet_enable,
+channel, true);
+   put_cpu();
+   } else {
+   put_cpu();
+   hv_event_tasklet_enable(channel);
+   }
 
return ret;
 }
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 0af7e39006c8..021f6da1968d 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -321,12 +321,24 @@ static void free_channel(struct vmbus_channel *channel)
kfree(channel);
 }
 
-static void percpu_channel_enq(void *arg)
+static void percpu_channel_enable(void *arg)
 {
struct vmbus_channel *channel = arg;
int cpu = smp_processor_id();
+   struct tasklet_struct *tasklet
+   = hv_context.event_dpc[cpu];
+
+   /*
+* This state is used to indicate a successful open
+* so that when we do close the channel normally, we
+* can cleanup properly
+*/
+   channel->state = CHANNEL_OPEN_STATE;
 
list_add_tail(>percpu_list, _context.percpu_list[cpu]);
+
+   tasklet_enable(tasklet);
+   tasklet_schedule(tasklet);
 }
 
 static void percpu_channel_deq(void *arg)
@@ -480,20 +492,12 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
if (newchannel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(newchannel->target_cpu,
-percpu_channel_enq,
+percpu_channel_enable,
 newchannel, true);
} else {
-   percpu_channel_enq(newchannel);
+   percpu_channel_enable(newchannel);
put_cpu();
}
-   hv_event_tasklet_enable(newchannel);
-
-   /*
-* This state is used to indicate a successful open
-* so that when we do close the channel normally, we
-* can cleanup properly
-*/
-   newchannel->state = CHANNEL_OPEN_STATE;
 
if (!fnew) {
if (channel->sc_creation_callback != NULL)
-- 
2.11.0

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

Re: [PATCH] vmbus: remove hv_event_tasklet_disable/enable

[Stephen Hemminger]

On Thu, 2 Mar 2017 12:32:55 +
Dexuan Cui  wrote:

> With the recent introduction of per-channel tasklet, we need to update
> the way we handle the 3 concurrency issues:
> 
> 1. hv_process_channel_removal -> percpu_channel_deq vs.
>vmbus_chan_sched -> list_for_each_entry(..., percpu_list);
> 
> 2. vmbus_process_offer -> percpu_channel_enq/deq vs. vmbus_chan_sched.
> 
> 3. vmbus_close_internal vs. the per-channel tasklet vmbus_on_event;
> 
> The first 2 issues can be handled by Stephen's recent patch
> "vmbus: use rcu for per-cpu channel list", and the third issue
> can be handled by calling tasklet_disable in vmbus_close_internal here.
> 
> We don't need the original hv_event_tasklet_disable/enable since we
> now use per-channel tasklet instead of the previous per-CPU tasklet,
> and actually we must remove them due to the side effect now:
> vmbus_process_offer -> hv_event_tasklet_enable -> tasklet_schedule will
> start the per-channel callback prematurely, cauing NULL dereferencing
> (the channel may haven't been properly configured to run the callback yet).
> 
> Fixes: 631e63a9f346 ("vmbus: change to per channel tasklet")
> 
> Signed-off-by: Dexuan Cui 
> Cc: "K. Y. Srinivasan" 
> Cc: Haiyang Zhang 
> Cc: Stephen Hemminger 

It also fixes a number of missed interrupts causing stuck tasks on boot.
Please put it in 4.11

Reviewed-by: Stephen Hemminger 

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

[PATCH 5/5] staging: bcm2835-camera: Remove 2 completed issues from TODO list

[Michael Zoran]

The TODO list has port the camera to ARM64.  That's done.

The list also mentions the error where the camera module won't
load if the camera isn't connected yet.  vchiq already has
a mechanism to deal with calling back into consumer when vchiq
connects, so instead of adding more code hook into that
mechanism.

That completes another TODO item.

Signed-off-by: Michael Zoran 
---
 drivers/staging/vc04_services/bcm2835-camera/TODO | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-camera/TODO 
b/drivers/staging/vc04_services/bcm2835-camera/TODO
index 61a509992b9a..713291bf0fdf 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/TODO
+++ b/drivers/staging/vc04_services/bcm2835-camera/TODO
@@ -16,23 +16,7 @@ hardware can do.  If we exposed the native padding 
requirements
 through the V4L2 "multiplanar" formats, the firmware would have one
 less copy it needed to do.
 
-3) Port to ARM64
-
-The bulk_receive() does some manual cache flushing that are 32-bit ARM
-only, which we should convert to proper cross-platform APIs.
-
-4) Convert to be a platform driver.
-
-Right now when the module probes, it tries to initialize VCHI and
-errors out if it wasn't ready yet.  If bcm2835-v4l2 was built in, then
-VCHI generally isn't ready because it depends on both the firmware and
-mailbox drivers having already loaded.
-
-We should have VCHI create a platform device once it's initialized,
-and have this driver bind to it, so that we automatically load the
-v4l2 module after VCHI loads.
-
-5) Drop the gstreamer workaround.
+3) Drop the gstreamer workaround.
 
 This was a temporary workaround for a bug that was fixed mid-2014, and
 we should remove it before stabilizing the driver.
-- 
2.11.0

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

[PATCH 1/5] bcm2835-camera: Correct port_parameter_get return value

[Michael Zoran]

From: Dave Stevenson 

The API for port_parameter_get() requires that the
filled length is returned, or if insufficient space
that the required space is returned.

Signed-off-by: Dave Stevenson 

Changed path:
From: drivers/media/platform/bcm2835/mmal-vchiq.c
To:   drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c

Signed-off-by: Michael Zoran 
---
 .../vc04_services/bcm2835-camera/mmal-vchiq.c| 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c 
b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
index fc1076db0f82..4f4499dfe0c3 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -1422,6 +1422,7 @@ static int port_parameter_get(struct vchiq_mmal_instance 
*instance,
struct mmal_msg m;
struct mmal_msg *rmsg;
VCHI_HELD_MSG_T rmsg_handle;
+   u32 reply_size;
 
m.h.type = MMAL_MSG_TYPE_PORT_PARAMETER_GET;
 
@@ -1445,19 +1446,30 @@ static int port_parameter_get(struct 
vchiq_mmal_instance *instance,
}
 
ret = -rmsg->u.port_parameter_get_reply.status;
-   if (ret || (rmsg->u.port_parameter_get_reply.size > *value_size)) {
+   /*
+* port_parameter_get_reply.size includes the header,
+* whilst *value_size doesn't.
+*/
+   reply_size = rmsg->u.port_parameter_get_reply.size - (2 * sizeof(u32));
+
+   if (ret || (reply_size > *value_size)) {
/* Copy only as much as we have space for
 * but report true size of parameter
 */
memcpy(value, >u.port_parameter_get_reply.value,
   *value_size);
-   *value_size = rmsg->u.port_parameter_get_reply.size;
} else
memcpy(value, >u.port_parameter_get_reply.value,
-  rmsg->u.port_parameter_get_reply.size);
+  reply_size);
+
+   /*
+* Return amount of data copied if big enough,
+* or wanted if not big enough.
+*/
+   *value_size = reply_size;
 
pr_debug("%s:result:%d component:0x%x port:%d parameter:%d\n", __func__,
-ret, port->component->handle, port->handle, parameter_id);
+   ret, port->component->handle, port->handle, parameter_id);
 
 release_msg:
vchi_held_msg_release(_handle);
-- 
2.11.0

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

[PATCH 4/5] staging: bcm2835-camera: Fix TODO issue #4 where camera doesn't start if vchiq isn't connected.

[Michael Zoran]

The camera currently doesn't start if vchiq hasn't connected yet.
Vchiq does have a mechanism to receive a callback when vchiq is
connected. So instead of connecting to the camera immedialy,
wait for the callback.

This fixed TODO issue #4

Signed-off-by: Michael Zoran 
---
 .../vc04_services/bcm2835-camera/bcm2835-camera.c  | 40 +++---
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c 
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index 86bbd6e899a8..714f2bd2366b 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#include "interface/vchiq_arm/vchiq_connected.h"
 #include "mmal-common.h"
 #include "mmal-encodings.h"
 #include "mmal-vchiq.h"
@@ -1586,7 +1587,7 @@ static int set_camera_parameters(struct 
vchiq_mmal_instance *instance,
 #define MAX_SUPPORTED_ENCODINGS 20
 
 /* MMAL instance and component init */
-static int __init mmal_init(struct bm2835_mmal_dev *dev)
+static int mmal_init(struct bm2835_mmal_dev *dev)
 {
int ret;
struct mmal_es_format_local *format;
@@ -1890,7 +1891,7 @@ static struct v4l2_format default_v4l2_format = {
.fmt.pix.sizeimage = 1024 * 768,
 };
 
-static int __init bm2835_mmal_init(void)
+static int bcm2835_mmal_init(void)
 {
int ret;
struct bm2835_mmal_dev *dev;
@@ -2010,7 +2011,7 @@ static int __init bm2835_mmal_init(void)
return ret;
 }
 
-static void __exit bm2835_mmal_exit(void)
+static void bcm2835_mmal_exit(void)
 {
int camera;
struct vchiq_mmal_instance *instance = gdev[0]->instance;
@@ -2022,5 +2023,34 @@ static void __exit bm2835_mmal_exit(void)
vchiq_mmal_finalise(instance);
 }
 
-module_init(bm2835_mmal_init);
-module_exit(bm2835_mmal_exit);
+static bool connected;
+
+static void bcm2835_connected(void)
+{
+   int ret;
+
+   ret = bcm2835_mmal_init();
+   if (!ret)
+   return;
+
+   connected = true;
+}
+
+static int __init bcm2835_camera_init(void)
+{
+   vchiq_add_connected_callback(bcm2835_connected);
+   return 0;
+}
+
+static void __exit bcm2835_camera_exit(void)
+{
+   vchiq_remove_connected_callback(bcm2835_connected);
+
+   if (!connected)
+   return;
+
+   bcm2835_mmal_exit();
+}
+
+module_init(bcm2835_camera_init);
+module_exit(bcm2835_camera_exit);
-- 
2.11.0

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

[PATCH 2/5] staging: bcm2835-camera: Fix integer underrun in port_parameter_get

[Michael Zoran]

Fix port_paremeter_get function blindly subtracts 8 from a reply
size without checking that the size is at lest 8 bytes. This can
casue a large buffer to be copied since the size is unsigned.

Add a WARN_ON, and also add min and max conditions to the size
of the data that is copied.

Signed-off-by: Michael Zoran 
---
 .../vc04_services/bcm2835-camera/mmal-vchiq.c  | 27 +++---
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c 
b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
index 4f4499dfe0c3..a8768358c557 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -1450,23 +1450,24 @@ static int port_parameter_get(struct 
vchiq_mmal_instance *instance,
 * port_parameter_get_reply.size includes the header,
 * whilst *value_size doesn't.
 */
-   reply_size = rmsg->u.port_parameter_get_reply.size - (2 * sizeof(u32));
 
-   if (ret || (reply_size > *value_size)) {
-   /* Copy only as much as we have space for
-* but report true size of parameter
-*/
-   memcpy(value, >u.port_parameter_get_reply.value,
-  *value_size);
-   } else
-   memcpy(value, >u.port_parameter_get_reply.value,
-  reply_size);
+   if (WARN_ON(rmsg->u.port_parameter_get_reply.size < 8))
+   reply_size = 0;
+   else
+   reply_size = rmsg->u.port_parameter_get_reply.size - 8;
 
/*
-* Return amount of data copied if big enough,
-* or wanted if not big enough.
+* The API for port_parameter_get() requires that the
+* filled length is returned, or if insufficient space
+* that the required space is returned.
+*
+* See Commit: 95452744c5ebcaa0f5d4eaff7313b2b4cd51bd9f
+* https://github.com/raspberrypi/linux
 */
-   *value_size = reply_size;
+
+   memcpy(value, >u.port_parameter_get_reply.value,
+  min(*value_size, reply_size));
+   *value_size = max(reply_size, *value_size);
 
pr_debug("%s:result:%d component:0x%x port:%d parameter:%d\n", __func__,
ret, port->component->handle, port->handle, parameter_id);
-- 
2.11.0

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

[PATCH 3/5] staging: vchiq_arm: Add vchiq_remove_connected_callback

[Michael Zoran]

The connected callback mechanism of vchiq is missing the ability
to remove a connected callback, such as when a module unloads.

So add the vchiq_remove_connected_callback to support unloading
modules that hook into vchiq.

Signed-off-by: Michael Zoran 
---
 .../interface/vchiq_arm/vchiq_connected.c  | 23 --
 .../interface/vchiq_arm/vchiq_connected.h  |  1 +
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git 
a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
index 7ea29665bd0c..6de7e1237467 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
@@ -94,6 +94,21 @@ void vchiq_add_connected_callback(VCHIQ_CONNECTED_CALLBACK_T 
callback)
mutex_unlock(_connected_mutex);
 }
 
+void vchiq_remove_connected_callback(VCHIQ_CONNECTED_CALLBACK_T callback)
+{
+   int i;
+
+   connected_init();
+
+   mutex_lock(_connected_mutex);
+
+   for (i = 0; i <  g_num_deferred_callbacks; i++)
+   if (g_deferred_callback[i] == callback)
+   g_deferred_callback[i] = NULL;
+
+   mutex_unlock(_connected_mutex);
+}
+
 /
 *
 * This function is called by the vchiq stack once it has been connected to
@@ -110,8 +125,12 @@ void vchiq_call_connected_callbacks(void)
if (mutex_lock_killable(_connected_mutex) != 0)
return;
 
-   for (i = 0; i <  g_num_deferred_callbacks; i++)
-   g_deferred_callback[i]();
+   for (i = 0; i <  g_num_deferred_callbacks; i++) {
+   if (g_deferred_callback[i])
+   g_deferred_callback[i]();
+
+   g_deferred_callback[i] = NULL;
+   }
 
g_num_deferred_callbacks = 0;
g_connected = 1;
diff --git 
a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.h 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.h
index 863b3e335c1a..b2e9b045677a 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.h
@@ -45,6 +45,7 @@ typedef void (*VCHIQ_CONNECTED_CALLBACK_T)(void);
 /*  Function Prototypes -- */
 
 void vchiq_add_connected_callback(VCHIQ_CONNECTED_CALLBACK_T callback);
+void vchiq_remove_connected_callback(VCHIQ_CONNECTED_CALLBACK_T callback);
 void vchiq_call_connected_callbacks(void);
 
 #endif /* VCHIQ_CONNECTED_H */
-- 
2.11.0

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

[PATCH 0/5] staging: vc04_services: camera driver maintance

[Michael Zoran]

This series imports a improved version of the port_paramter_get function
for the camera from the github tree.  The patch does not pass
checkpatch.pl but I thought it's better the change gets in.

I improved upon that patch by fixing a possible integer underrun.

I finished the TODO item of the race condition if the vchiq driver
is not connected when the camera module initializes.  To do this
required improving upon the callback based mechanism of vchiq
to be able to remove the callback in the case the module is unloaded.

Finally, I removed 2 issues from the camera TODO list as ARM64 port
of the camera is complete and the start race condition is fixed.

Dave Stevenson (1):
  bcm2835-camera: Correct port_parameter_get return value

Michael Zoran (4):
  staging: bcm2835-camera: Fix integer underrun in port_parameter_get
  staging: vchiq_arm: Add vchiq_remove_connected_callback
  staging: bcm2835-camera: Fix TODO issue #4 where camera doesn't start
if vchiq isn't connected.
  staging: bcm2835-camera: Remove 2 completed issues from TODO list

 drivers/staging/vc04_services/bcm2835-camera/TODO  | 18 +-
 .../vc04_services/bcm2835-camera/bcm2835-camera.c  | 40 +++---
 .../vc04_services/bcm2835-camera/mmal-vchiq.c  | 35 +--
 .../interface/vchiq_arm/vchiq_connected.c  | 23 +++--
 .../interface/vchiq_arm/vchiq_connected.h  |  1 +
 5 files changed, 82 insertions(+), 35 deletions(-)

-- 
2.11.0

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

[PATCH] Staging: atomisp: fix an uninitialized variable bug

[Dan Carpenter]

There are some error paths in atomisp_css_frame_allocate() which don't
initialize "res" so it could lead us to try release random memory.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index d9a5c24633cb..0f01047cdf8e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -4733,7 +4733,7 @@ static int
 atomisp_v4l2_framebuffer_to_css_frame(const struct v4l2_framebuffer *arg,
 struct atomisp_css_frame **result)
 {
-   struct atomisp_css_frame *res;
+   struct atomisp_css_frame *res = NULL;
unsigned int padded_width;
enum atomisp_css_frame_format sh_format;
char *tmp_buf = NULL;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: atomisp: fix locking in alloc_user_pages()

[Dan Carpenter]

We call this function with the lock held and should also return with the
lock held as well.  This one error path is not-consistent because we
should return without the lock held.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
index fd3bd5c48672..d1a609d25f18 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
@@ -1012,6 +1012,7 @@ static int alloc_user_pages(struct hmm_buffer_object *bo,
dev_err(atomisp_dev, "find_vma failed\n");
atomisp_kernel_free(bo->page_obj);
atomisp_kernel_free(pages);
+   mutex_lock(>mutex);
return -EFAULT;
}
mutex_lock(>mutex);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3] Staging: most: use __func__ instead of the function name

[Chandra Annamaneni]

Change video.c to use %s, __func__ instead of function names.
Warnings flagged by checkpatch.pl

Signed-off-by: Chandra Annamaneni 

diff --git a/drivers/staging/most/aim-v4l2/video.c 
b/drivers/staging/most/aim-v4l2/video.c
index e074841..59e861e 100644
--- a/drivers/staging/most/aim-v4l2/video.c
+++ b/drivers/staging/most/aim-v4l2/video.c
@@ -79,7 +79,7 @@ static int aim_vdev_open(struct file *filp)
struct most_video_dev *mdev = video_drvdata(filp);
struct aim_fh *fh;

-   v4l2_info(>v4l2_dev, "aim_vdev_open()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

switch (vdev->vfl_type) {
case VFL_TYPE_GRABBER:
@@ -128,7 +128,7 @@ static int aim_vdev_close(struct file *filp)
struct most_video_dev *mdev = fh->mdev;
struct mbo *mbo, *tmp;

-   v4l2_info(>v4l2_dev, "aim_vdev_close()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

/*
 * We need to put MBOs back before we call most_stop_channel()
@@ -324,7 +324,7 @@ static int vidioc_g_std(struct file *file, void *priv, 
v4l2_std_id *norm)
struct aim_fh *fh = priv;
struct most_video_dev *mdev = fh->mdev;

-   v4l2_info(>v4l2_dev, "vidioc_g_std()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

*norm = V4L2_STD_UNKNOWN;
return 0;
@@ -361,7 +361,7 @@ static int vidioc_s_input(struct file *file, void *priv, 
unsigned int index)
struct aim_fh *fh = priv;
struct most_video_dev *mdev = fh->mdev;

-   v4l2_info(>v4l2_dev, "vidioc_s_input(%d)\n", index);
+   v4l2_info(>v4l2_dev, "%s(%d)\n", __func__, index);

if (index >= V4L2_AIM_MAX_INPUT)
return -EINVAL;
@@ -441,7 +441,7 @@ static int aim_register_videodev(struct most_video_dev 
*mdev)
 {
int ret;

-   v4l2_info(>v4l2_dev, "aim_register_videodev()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

init_waitqueue_head(>wait_data);

@@ -471,7 +471,7 @@ static int aim_register_videodev(struct most_video_dev 
*mdev)

 static void aim_unregister_videodev(struct most_video_dev *mdev)
 {
-   v4l2_info(>v4l2_dev, "aim_unregister_videodev()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

video_unregister_device(mdev->vdev);
 }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 08/12] cma: Store a name in the cma structure

[Laura Abbott]

On 03/10/2017 12:53 AM, Sumit Semwal wrote:
> Hi Laura,
> 
> Thanks for the patch.
> 
> On 3 March 2017 at 03:14, Laura Abbott  wrote:
>>
>> 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 
>> ---
>>  drivers/base/dma-contiguous.c |  5 +++--
>>  include/linux/cma.h   |  4 +++-
>>  mm/cma.c  | 11 +--
>>  mm/cma.h  |  1 +
>>  mm/cma_debug.c|  2 +-
>>  5 files changed, 17 insertions(+), 6 deletions(-)
>>
> 
>> +const char *cma_get_name(const struct cma *cma)
>> +{
>> +   return cma->name ? cma->name : "(undefined)";
>> +}
>> +
> Would it make sense to perhaps have the idx stored as the name,
> instead of 'undefined'? That would make sure that the various cma
> names are still unique.
> 

Good suggestion. I'll see about cleaning that up.

>>  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)
>>  {
> 
> Best regards,
> Sumit.
> 

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

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Mauro Carvalho Chehab]

Em Fri, 17 Mar 2017 12:16:08 +
Russell King - ARM Linux  escreveu:

> On Fri, Mar 17, 2017 at 01:02:07PM +0100, Philipp Zabel wrote:
> > I think most of the simple, fixed pipeline use cases could be handled by
> > libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that
> > function internally would set up the media links to the
> > nearest /dev/video interface, propagate format, resolution and frame
> > intervals if necessary, and return an fd to the video device, there'd be
> > no additional complexity for the users beyond selecting the v4l2_subdev
> > instead of the video device.  
> 
> ... which would then require gstreamer to be modified too. The gstreamer
> v4l2 plugin looks for /dev/video* or /dev/v4l2/video* devices and monitors
> these for changes, so gstreamer applications know which capture devices
> are available:
> 
>   const gchar *paths[] = { "/dev", "/dev/v4l2", NULL };
>   const gchar *names[] = { "video", NULL };
> 
>   /* Add some depedency, so the dynamic features get updated upon changes in
>* /dev/video* */
>   gst_plugin_add_dependency (plugin,
>   NULL, paths, names, GST_PLUGIN_DEPENDENCY_FLAG_FILE_NAME_IS_PREFIX);
> 
> I haven't checked yet whether sys/v4l2/gstv4l2deviceprovider.c knows
> anything about the v4l2 subdevs.

Not only gstreamer do that, but all simple V4L2 applications, although
on most of them, you can either pass a command line argument or setup
the patch via GUI.

Btw, I've no idea from where gstreamer took /dev/v4l2 :-)
I'm yet to find a distribution using it.

On the other hand, /dev/v4l/by-patch and /dev/v4l/by-id are usual directories
where V4L2 devices can be found, and should provide persistent names. So, IMHO,
gst should prefer those names, when they exist:

$ tree /dev/v4l
/dev/v4l
├── by-id
│   ├── usb-046d_HD_Pro_Webcam_C920_55DA1CCF-video-index0 -> ../../video1
│   └── usb-Sunplus_mMobile_Inc_USB_Web-CAM-video-index0 -> ../../video0
└── by-path
├── platform-3f98.usb-usb-0:1.2:1.0-video-index0 -> ../../video1
└── platform-3f98.usb-usb-0:1.5:1.0-video-index0 -> ../../video0




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

Re: [PATCH 0/6] staging: bcm2835-firmware-gpio: Initial staging commit

[Michael Zoran]

On Fri, 2017-03-17 at 18:24 +0100, Stefan Wahren wrote:
> Hi Michael,
> 
> > Michael Zoran  hat am 17. März 2017 um 17:48
> > geschrieben:
> > 
> > 
> > On Fri, 2017-03-17 at 17:31 +0100, Stefan Wahren wrote:
> > > Hi Michael,
> > > 
> > > 
> > > Am 17.03.2017 um 16:22 schrieb Michael Zoran:
> > > > The firmware now has a mailbox API for performing generalized
> > > > gpio
> > > > through
> > > > the firmware.  This driver builds upon a driver written by Dave
> > > > Stevenson
> > > > that was written specifically for the expander on the RPI 3,
> > > > but I
> > > > have
> > > > generalized for generic GPIO through the firmware.
> > > > 
> > > > With this change I was able to test VC4 on a RPI 3 running in
> > > > arm64
> > > > with
> > > > a pure mainline tree from the staging branch.
> > > > 
> > > > The firmware gpio numbers are currently documented at:
> > > > https://github.com/raspberrypi/firmware/blob/master/extra/dt-bl
> > > > ob.d
> > > > ts
> > > > 
> > > > 
> > > 
> > > could you please explain why this driver should go to staging?
> > 
> > I can think of a few reasons:
> > 
> > 1. The mailbox API is still very new and a work in progress. I'm
> > sure
> > it's probably going to change some.
> > 
> > 2. It fits in with the VideoCore subsystem idea in that it doesn't
> > talk
> > directly to hardware. Submitting it to staging would allow us to
> > get
> > VC4 working sooner to unblock proper testing on a RPI 3.
> > 
> > 3. I have some ideas for this driver for future work that I'm still
> > thinking about but I'm not ready yet to submit any changes.
> > 
> 
> before running into the wrong direction i suggest to send at least 1
> RFC series to the GPIO and the DT mailing list.
> 
> If you interested i can send you my comments to this series.
> 
> Stefan

Sure I'm interested in comments, but keep in mind I generalized the
driver really, really fast.  We probably need to change the name of the
driver and the comment block at the top.  I also noticed when the
driver loads it's complaining about no GPIO parent so it certainly
needs work.  I was hoping people would be happy that we have some way
to get some VC4 support on mainline.

I still think this belongs with VideoCore rather then the general
kernel tree.  And for now VideoCore is in staging.



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

Re: [PATCH 0/6] staging: bcm2835-firmware-gpio: Initial staging commit

[Stefan Wahren]

Hi Michael,

> Michael Zoran  hat am 17. März 2017 um 17:48 geschrieben:
> 
> 
> On Fri, 2017-03-17 at 17:31 +0100, Stefan Wahren wrote:
> > Hi Michael,
> > 
> > 
> > Am 17.03.2017 um 16:22 schrieb Michael Zoran:
> > > The firmware now has a mailbox API for performing generalized gpio
> > > through
> > > the firmware.  This driver builds upon a driver written by Dave
> > > Stevenson
> > > that was written specifically for the expander on the RPI 3, but I
> > > have
> > > generalized for generic GPIO through the firmware.
> > > 
> > > With this change I was able to test VC4 on a RPI 3 running in arm64
> > > with
> > > a pure mainline tree from the staging branch.
> > > 
> > > The firmware gpio numbers are currently documented at:
> > > https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.d
> > > ts
> > > 
> > > 
> > 
> > could you please explain why this driver should go to staging?
> 
> I can think of a few reasons:
> 
> 1. The mailbox API is still very new and a work in progress. I'm sure
> it's probably going to change some.
> 
> 2. It fits in with the VideoCore subsystem idea in that it doesn't talk
> directly to hardware. Submitting it to staging would allow us to get
> VC4 working sooner to unblock proper testing on a RPI 3.
> 
> 3. I have some ideas for this driver for future work that I'm still
> thinking about but I'm not ready yet to submit any changes.
> 

before running into the wrong direction i suggest to send at least 1 RFC series 
to the GPIO and the DT mailing list.

If you interested i can send you my comments to this series.

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

Re: outreachy

[Julia Lawall]

On Fri, 17 Mar 2017, Pavel Machek wrote:

> Hi!
>
> >
> > Hah!  That's the joy of being a maintainer of a driver in staging.  Even
> > if you filter out outreachy, you are going to get a lot of "basic
> > mistakes" and other type patches cc:ed to you.
> >
> > I strongly suggest, that if you all don't like this type of stuff,
> > either:
> > - work to get the code out of staging as soon as possible (i.e.
> >   send me coding style fixes for everything right now, and then
> >   fix up the rest of the stuff.)
> > - take yourself off the maintainer list for this code.
> >
> > It's your choice, outreachy right now is a lot of patches, but again,
> > it's not going to keep you from getting the "basic" stuff sent to you
> > in ways that is totally wrong.
>
> Could we get these trivial patches off the lkml? Yes, lkml already has
> a lot of traffic, but no, this is not useful :-(.

The outreachy instructions say to use the -nol argument to
get_maintainers, which would prevent them from being sent to any mailing
list.  However others thought that all patches should be sent to mailing
lists, and so I haven't enforced anything for people who have omitted
-nol.  However I have tried to remove bcm maintainers from CC lists on
replies and reminded people not to send you patches,

julia


>
>   Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/6] staging: bcm2835-firmware-gpio: Initial staging commit

[Michael Zoran]

On Fri, 2017-03-17 at 17:31 +0100, Stefan Wahren wrote:
> Hi Michael,
> 
> 
> Am 17.03.2017 um 16:22 schrieb Michael Zoran:
> > The firmware now has a mailbox API for performing generalized gpio
> > through
> > the firmware.  This driver builds upon a driver written by Dave
> > Stevenson
> > that was written specifically for the expander on the RPI 3, but I
> > have
> > generalized for generic GPIO through the firmware.
> > 
> > With this change I was able to test VC4 on a RPI 3 running in arm64
> > with
> > a pure mainline tree from the staging branch.
> > 
> > The firmware gpio numbers are currently documented at:
> > https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.d
> > ts
> > 
> > 
> 
> could you please explain why this driver should go to staging?

I can think of a few reasons:

1. The mailbox API is still very new and a work in progress. I'm sure
it's probably going to change some.

2. It fits in with the VideoCore subsystem idea in that it doesn't talk
directly to hardware. Submitting it to staging would allow us to get
VC4 working sooner to unblock proper testing on a RPI 3.

3. I have some ideas for this driver for future work that I'm still
thinking about but I'm not ready yet to submit any changes.


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

Re: [PATCH 0/6] staging: bcm2835-firmware-gpio: Initial staging commit

[Stefan Wahren]

Hi Michael,


Am 17.03.2017 um 16:22 schrieb Michael Zoran:

The firmware now has a mailbox API for performing generalized gpio through
the firmware.  This driver builds upon a driver written by Dave Stevenson
that was written specifically for the expander on the RPI 3, but I have
generalized for generic GPIO through the firmware.

With this change I was able to test VC4 on a RPI 3 running in arm64 with
a pure mainline tree from the staging branch.

The firmware gpio numbers are currently documented at:
https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts




could you please explain why this driver should go to staging?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] HV: properly delay KVP packets when negotiation is in progress

[Vitaly Kuznetsov]

Long Li  writes:

> The host may send multiple KVP packets before the negotiation with daemon
> is finished. We need to keep those packets in ring buffer until the daemon
> is negotiated and connected.

The patch looks OK but previously we always presumed that this can't
happen for util drivers and host will never send a new request before we
answer to the previous one. If this is not true we may have more issues
which need fixing as all three drivers we have are written in a
'transaction' fashion.

So my question would be: can the host send multiple (KVP) packets
_after_ the negotiation with daemon is finished?


>
> This patch is based on the work of Nick Meier 
>
> Signed-off-by: Long Li 
> ---
>  drivers/hv/hv_kvp.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> index de26371..b9f928d 100644
> --- a/drivers/hv/hv_kvp.c
> +++ b/drivers/hv/hv_kvp.c
> @@ -628,16 +628,17 @@ void hv_kvp_onchannelcallback(void *context)
>NEGO_IN_PROGRESS,
>NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
>
> - if (host_negotiatied == NEGO_NOT_STARTED &&
> - kvp_transaction.state < HVUTIL_READY) {
> + if (kvp_transaction.state < HVUTIL_READY) {
>   /*
>* If userspace daemon is not connected and host is asking
>* us to negotiate we need to delay to not lose messages.
>* This is important for Failover IP setting.
>*/
> - host_negotiatied = NEGO_IN_PROGRESS;
> - schedule_delayed_work(_host_handshake_work,
> + if (host_negotiatied == NEGO_NOT_STARTED) {
> + host_negotiatied = NEGO_IN_PROGRESS;
> + schedule_delayed_work(_host_handshake_work,
> HV_UTIL_NEGO_TIMEOUT * HZ);
> + }
>   return;
>   }
>   if (kvp_transaction.state > HVUTIL_READY)

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

[PATCH 23/36] staging: unisys: include: remove irrelevant comments

[David Kershner]

From: Jon Frisch 

This patch removes comments that are no longer relevant
in channel.h.

Signed-off-by: Jon Frisch 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 048ef16..741a1ef 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -20,16 +20,6 @@
 #include 
 #include 
 
-/*
- * Whenever this file is changed a corresponding change must be made in
- * the Console/ServicePart/visordiag_early/supervisor_channel.h file
- * which is needed for Linux kernel compiles. These two files must be
- * in sync.
- */
-
-/* define the following to prevent include nesting in kernel header
- * files of similar abbreviated content
- */
 #define __SUPERVISOR_CHANNEL_H__
 
 #define SIGNATURE_16(A, B) ((A) | ((B) << 8))
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 03/36] staging: unisys: visorbus: removed unused structure pci_id

[David Kershner]

From: Sameer Wadgaonkar 

Removed unused structure pci_id from controlvmchannel.h

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/controlvmchannel.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/staging/unisys/visorbus/controlvmchannel.h
index 8593452..79f77ad 100644
--- a/drivers/staging/unisys/visorbus/controlvmchannel.h
+++ b/drivers/staging/unisys/visorbus/controlvmchannel.h
@@ -147,14 +147,6 @@ struct irq_info {
u8 reserved[3]; /* Natural alignment purposes */
 };
 
-struct pci_id {
-   u16 domain;
-   u8 bus;
-   u8 slot;
-   u8 func;
-   u8 reserved[3]; /* Natural alignment purposes */
-};
-
 struct efi_spar_indication  {
u64 boot_to_fw_ui:1;/* Bit 0: Stop in uefi ui */
u64 clear_nvram:1;  /* Bit 1: Clear NVRAM */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 11/36] staging: unisys: include: Remove unused visorchannel #defines

[David Kershner]

From: David Binder 

Removes unused #defines pertaining to visorchannel UUIDs.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 36dbe21..d3c1dac 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -381,17 +381,4 @@ static const uuid_le spar_vnic_channel_protocol_uuid =
0x85, 0x30, 0x44, 0x45, 0x53, 0x54, 0x42, 0x00)
 static const uuid_le spar_siovm_uuid = SPAR_SIOVM_UUID;
 
-/* {5b52c5ac-e5f5-4d42-8dff-429eaecd221f} */
-#define SPAR_CONTROLDIRECTOR_CHANNEL_PROTOCOL_UUID  \
-   UUID_LE(0x5b52c5ac, 0xe5f5, 0x4d42, \
-   0x8d, 0xff, 0x42, 0x9e, 0xae, 0xcd, 0x22, 0x1f)
-
-static const uuid_le spar_controldirector_channel_protocol_uuid =
-   SPAR_CONTROLDIRECTOR_CHANNEL_PROTOCOL_UUID;
-
-/* {b4e79625-aede-4eAA-9e11-D3eddcd4504c} */
-#define SPAR_DIAG_POOL_CHANNEL_PROTOCOL_UUID   \
-   UUID_LE(0xb4e79625, 0xaede, 0x4eaa, \
-   0x9e, 0x11, 0xd3, 0xed, 0xdc, 0xd4, 0x50, 0x4c)
-
 #endif
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 14/36] staging: unisys: include: Change out-of-date references

[David Kershner]

From: David Binder 

Replace references to virtpci to visornic in iochannel.h.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 41e5b4e..53fed6d 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -92,11 +92,11 @@ enum net_types {
 */
/* visornic -> uisnic */
NET_RCV,/* incoming packet received */
-   /* uisnic -> virtpci */
+   /* uisnic -> visornic */
NET_XMIT,   /* for outgoing net packets */
/* visornic -> uisnic */
NET_XMIT_DONE,  /* outgoing packet xmitted */
-   /* uisnic -> virtpci */
+   /* uisnic -> visornic */
NET_RCV_ENBDIS, /* enable/disable packet reception */
/* visornic -> uisnic */
NET_RCV_ENBDIS_ACK, /* acknowledge enable/disable packet */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 30/36] staging: unisys: visorbus: vbuschannel.h: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/vbuschannel.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/vbuschannel.h 
b/drivers/staging/unisys/visorbus/vbuschannel.h
index 408bb3a..447fef2 100644
--- a/drivers/staging/unisys/visorbus/vbuschannel.h
+++ b/drivers/staging/unisys/visorbus/vbuschannel.h
@@ -28,8 +28,8 @@
 
 /* {193b331b-c58f-11da-95a9-00e08161165f} */
 #define SPAR_VBUS_CHANNEL_PROTOCOL_UUID \
-   UUID_LE(0x193b331b, 0xc58f, 0x11da, \
-   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
+   UUID_LE(0x193b331b, 0xc58f, 0x11da, \
+   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
 static const uuid_le spar_vbus_channel_protocol_uuid =
SPAR_VBUS_CHANNEL_PROTOCOL_UUID;
 
@@ -43,13 +43,13 @@ static const uuid_le spar_vbus_channel_protocol_uuid =
  */
 #define SPAR_VBUS_CHANNEL_PROTOCOL_VERSIONID 1
 
-#define SPAR_VBUS_CHANNEL_OK_CLIENT(ch)   \
-   spar_check_channel_client(ch,   \
-  spar_vbus_channel_protocol_uuid, \
-  "vbus",  \
-  sizeof(struct spar_vbus_channel_protocol),\
-  SPAR_VBUS_CHANNEL_PROTOCOL_VERSIONID, \
-  SPAR_VBUS_CHANNEL_PROTOCOL_SIGNATURE)
+#define SPAR_VBUS_CHANNEL_OK_CLIENT(ch) \
+   spar_check_channel_client(ch, \
+ spar_vbus_channel_protocol_uuid, \
+ "vbus", \
+ sizeof(struct spar_vbus_channel_protocol), \
+ SPAR_VBUS_CHANNEL_PROTOCOL_VERSIONID, \
+ SPAR_VBUS_CHANNEL_PROTOCOL_SIGNATURE)
 
 /*
  * An array of this struct is present in the channel area for each vbus.
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 15/36] staging: unisys: visornic: Move function to appropriate location

[David Kershner]

From: David Binder 

Move function add_physinfo_entries() to visornic_main.c, which is the
only function where it is used.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/iochannel.h  | 37 +--
 drivers/staging/unisys/visornic/visornic_main.c | 37 ++-
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 53fed6d..0b61fd7 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -551,41 +551,4 @@ struct spar_io_channel_protocol {
 #define PI_PAGE_SIZE  0x1000
 #define PI_PAGE_MASK  0x0FFF
 
-/* Returns next non-zero index on success or 0 on failure (i.e. out of room). 
*/
-static inline u16
-add_physinfo_entries(u64 inp_pfn, u16 inp_off, u32 inp_len, u16 index,
-u16 max_pi_arr_entries, struct phys_info pi_arr[])
-{
-   u32 len;
-   u16 i, firstlen;
-
-   firstlen = PI_PAGE_SIZE - inp_off;
-   if (inp_len <= firstlen) {
-   /* The input entry spans only one page - add as is. */
-   if (index >= max_pi_arr_entries)
-   return 0;
-   pi_arr[index].pi_pfn = inp_pfn;
-   pi_arr[index].pi_off = (u16)inp_off;
-   pi_arr[index].pi_len = (u16)inp_len;
-   return index + 1;
-   }
-
-   /* This entry spans multiple pages. */
-   for (len = inp_len, i = 0; len;
-   len -= pi_arr[index + i].pi_len, i++) {
-   if (index + i >= max_pi_arr_entries)
-   return 0;
-   pi_arr[index + i].pi_pfn = inp_pfn + i;
-   if (i == 0) {
-   pi_arr[index].pi_off = inp_off;
-   pi_arr[index].pi_len = firstlen;
-   } else {
-   pi_arr[index + i].pi_off = 0;
-   pi_arr[index + i].pi_len =
-   (u16)MINNUM(len, (u32)PI_PAGE_SIZE);
-   }
-   }
-   return index + i;
-}
-
 #endif /* __IOCHANNEL_H__ */
diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index b961d7e..89de87f 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -141,6 +141,43 @@ struct visornic_devdata {
struct uiscmdrsp cmdrsp[SIZEOF_CMDRSP];
 };
 
+/* Returns next non-zero index on success or 0 on failure (i.e. out of room). 
*/
+static inline u16
+add_physinfo_entries(u64 inp_pfn, u16 inp_off, u32 inp_len, u16 index,
+u16 max_pi_arr_entries, struct phys_info pi_arr[])
+{
+   u32 len;
+   u16 i, firstlen;
+
+   firstlen = PI_PAGE_SIZE - inp_off;
+   if (inp_len <= firstlen) {
+   /* The input entry spans only one page - add as is. */
+   if (index >= max_pi_arr_entries)
+   return 0;
+   pi_arr[index].pi_pfn = inp_pfn;
+   pi_arr[index].pi_off = (u16)inp_off;
+   pi_arr[index].pi_len = (u16)inp_len;
+   return index + 1;
+   }
+
+   /* This entry spans multiple pages. */
+   for (len = inp_len, i = 0; len;
+   len -= pi_arr[index + i].pi_len, i++) {
+   if (index + i >= max_pi_arr_entries)
+   return 0;
+   pi_arr[index + i].pi_pfn = inp_pfn + i;
+   if (i == 0) {
+   pi_arr[index].pi_off = inp_off;
+   pi_arr[index].pi_len = firstlen;
+   } else {
+   pi_arr[index + i].pi_off = 0;
+   pi_arr[index + i].pi_len =
+   (u16)MINNUM(len, (u32)PI_PAGE_SIZE);
+   }
+   }
+   return index + i;
+}
+
 /*
  * visor_copy_fragsinfo_from_skb(
  * @skb_in: skbuff that we are pulling the frags from
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 35/36] staging: unisys: include: visorbus.h: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/visorbus.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 0bb7903..6582939 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -209,7 +209,7 @@ int visorchannel_signalinsert(struct visorchannel *channel, 
u32 queue,
 bool visorchannel_signalempty(struct visorchannel *channel, u32 queue);
 uuid_le visorchannel_get_uuid(struct visorchannel *channel);
 
-#define BUS_ROOT_DEVICEUINT_MAX
+#define BUS_ROOT_DEVICE UINT_MAX
 struct visor_device *visorbus_get_device_by_id(u32 bus_no, u32 dev_no,
   struct visor_device *from);
 #endif
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 32/36] staging: unisys: visorinput: visorinput.c: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorinput/visorinput.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorinput/visorinput.c 
b/drivers/staging/unisys/visorinput/visorinput.c
index 3fc7d9e..cdd3543 100644
--- a/drivers/staging/unisys/visorinput/visorinput.c
+++ b/drivers/staging/unisys/visorinput/visorinput.c
@@ -33,21 +33,21 @@
 #include "ultrainputreport.h"
 
 /* Keyboard channel {c73416d0-b0b8-44af-b304-9d2ae99f1b3d} */
-#define SPAR_KEYBOARD_CHANNEL_PROTOCOL_UUID\
-   UUID_LE(0xc73416d0, 0xb0b8, 0x44af, \
+#define SPAR_KEYBOARD_CHANNEL_PROTOCOL_UUID \
+   UUID_LE(0xc73416d0, 0xb0b8, 0x44af, \
0xb3, 0x4, 0x9d, 0x2a, 0xe9, 0x9f, 0x1b, 0x3d)
 #define SPAR_KEYBOARD_CHANNEL_PROTOCOL_UUID_STR 
"c73416d0-b0b8-44af-b304-9d2ae99f1b3d"
 
 /* Mouse channel {addf07d4-94a9-46e2-81c3-61abcdbdbd87} */
-#define SPAR_MOUSE_CHANNEL_PROTOCOL_UUID  \
+#define SPAR_MOUSE_CHANNEL_PROTOCOL_UUID \
UUID_LE(0xaddf07d4, 0x94a9, 0x46e2, \
0x81, 0xc3, 0x61, 0xab, 0xcd, 0xbd, 0xbd, 0x87)
 #define SPAR_MOUSE_CHANNEL_PROTOCOL_UUID_STR \
"addf07d4-94a9-46e2-81c3-61abcdbdbd87"
 
-#define PIXELS_ACROSS_DEFAULT  800
-#define PIXELS_DOWN_DEFAULT600
-#define KEYCODE_TABLE_BYTES256
+#define PIXELS_ACROSS_DEFAULT 800
+#define PIXELS_DOWN_DEFAULT   600
+#define KEYCODE_TABLE_BYTES   256
 
 enum visorinput_device_type {
visorinput_keyboard,
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 36/36] staging: unisys: include: channel.h: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/channel.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 741a1ef..71defbd 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -29,10 +29,10 @@
(SIGNATURE_32(A, B, C, D) | ((u64)(SIGNATURE_32(E, F, G, H)) << 32))
 
 #ifndef COVER
-#define COVER(v, d)   ((d) * DIV_ROUND_UP(v, d))
+#define COVER(v, d) ((d) * DIV_ROUND_UP(v, d))
 #endif
 
-#define ULTRA_CHANNEL_PROTOCOL_SIGNATURE  SIGNATURE_32('E', 'C', 'N', 'L')
+#define ULTRA_CHANNEL_PROTOCOL_SIGNATURE SIGNATURE_32('E', 'C', 'N', 'L')
 
 enum channel_serverstate {
CHANNELSRV_UNINITIALIZED = 0,   /* channel is in an undefined state */
@@ -62,7 +62,7 @@ enum channel_clientstate {
 #define SPAR_CHANNEL_SERVER_READY(ch) \
(readl(&(ch)->srv_state) == CHANNELSRV_READY)
 
-#define ULTRA_VALID_CHANNELCLI_TRANSITION(o, n)
\
+#define ULTRA_VALID_CHANNELCLI_TRANSITION(o, n) \
(o) == CHANNELCLI_DETACHED) && ((n) == CHANNELCLI_DISABLED)) || \
  (((o) == CHANNELCLI_ATTACHING) && ((n) == CHANNELCLI_DISABLED)) || \
  (((o) == CHANNELCLI_ATTACHED) && ((n) == CHANNELCLI_DISABLED)) || \
@@ -84,7 +84,7 @@ enum channel_clientstate {
 /* throttling invalid boot channel statetransition error due to client
  * disabled
  */
-#define ULTRA_CLIERRORBOOT_THROTTLEMSG_DISABLED0x01
+#define ULTRA_CLIERRORBOOT_THROTTLEMSG_DISABLED 0x01
 
 /* throttling invalid boot channel statetransition error due to client
  * not attached
@@ -92,7 +92,7 @@ enum channel_clientstate {
 #define ULTRA_CLIERRORBOOT_THROTTLEMSG_NOTATTACHED 0x02
 
 /* throttling invalid boot channel statetransition error due to busy channel */
-#define ULTRA_CLIERRORBOOT_THROTTLEMSG_BUSY0x04
+#define ULTRA_CLIERRORBOOT_THROTTLEMSG_BUSY 0x04
 
 /* Values for ULTRA_CHANNEL_PROTOCOL.Features: This define exists so
  * that windows guest can look at the FeatureFlags in the io channel,
@@ -255,8 +255,8 @@ spar_check_channel_client(struct channel_header *ch,
 
 /* {414815ed-c58c-11da-95a9-00e08161165f} */
 #define SPAR_VHBA_CHANNEL_PROTOCOL_UUID \
-   UUID_LE(0x414815ed, 0xc58c, 0x11da, \
-   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
+   UUID_LE(0x414815ed, 0xc58c, 0x11da, \
+   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
 static const uuid_le spar_vhba_channel_protocol_uuid =
SPAR_VHBA_CHANNEL_PROTOCOL_UUID;
 #define SPAR_VHBA_CHANNEL_PROTOCOL_UUID_STR \
@@ -264,8 +264,8 @@ static const uuid_le spar_vhba_channel_protocol_uuid =
 
 /* {8cd5994d-c58e-11da-95a9-00e08161165f} */
 #define SPAR_VNIC_CHANNEL_PROTOCOL_UUID \
-   UUID_LE(0x8cd5994d, 0xc58e, 0x11da, \
-   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
+   UUID_LE(0x8cd5994d, 0xc58e, 0x11da, \
+   0x95, 0xa9, 0x0, 0xe0, 0x81, 0x61, 0x16, 0x5f)
 static const uuid_le spar_vnic_channel_protocol_uuid =
SPAR_VNIC_CHANNEL_PROTOCOL_UUID;
 #define SPAR_VNIC_CHANNEL_PROTOCOL_UUID_STR \
@@ -273,8 +273,8 @@ static const uuid_le spar_vnic_channel_protocol_uuid =
 
 /* {72120008-4AAB-11DC-8530-444553544200} */
 #define SPAR_SIOVM_UUID \
-   UUID_LE(0x72120008, 0x4AAB, 0x11DC, \
-   0x85, 0x30, 0x44, 0x45, 0x53, 0x54, 0x42, 0x00)
+   UUID_LE(0x72120008, 0x4AAB, 0x11DC, \
+   0x85, 0x30, 0x44, 0x45, 0x53, 0x54, 0x42, 0x00)
 static const uuid_le spar_siovm_uuid = SPAR_SIOVM_UUID;
 
 #endif
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 34/36] staging: unisys: include: iochannel.h: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/iochannel.h | 24 +++
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/unisys/include/iochannel.h 
b/drivers/staging/unisys/include/iochannel.h
index 0b61fd7..5d8a500 100644
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@ -50,13 +50,13 @@
 #define ULTRA_VNIC_CHANNEL_PROTOCOL_VERSIONID 2
 #define ULTRA_VSWITCH_CHANNEL_PROTOCOL_VERSIONID 1
 
-#define SPAR_VHBA_CHANNEL_OK_CLIENT(ch)\
+#define SPAR_VHBA_CHANNEL_OK_CLIENT(ch) \
(spar_check_channel_client(ch, spar_vhba_channel_protocol_uuid, \
   "vhba", MIN_IO_CHANNEL_SIZE, \
   ULTRA_VHBA_CHANNEL_PROTOCOL_VERSIONID, \
   ULTRA_VHBA_CHANNEL_PROTOCOL_SIGNATURE))
 
-#define SPAR_VNIC_CHANNEL_OK_CLIENT(ch)\
+#define SPAR_VNIC_CHANNEL_OK_CLIENT(ch) \
(spar_check_channel_client(ch, spar_vnic_channel_protocol_uuid, \
   "vnic", MIN_IO_CHANNEL_SIZE, \
   ULTRA_VNIC_CHANNEL_PROTOCOL_VERSIONID, \
@@ -200,7 +200,7 @@ struct uiscmdrsp_scsi {
int linuxstat;  /* original Linux status used by Linux vdisk */
u8 scsistat;/* the scsi status */
u8 addlstat;/* non-scsi status */
-#define ADDL_SEL_TIMEOUT   4
+#define ADDL_SEL_TIMEOUT 4
 
/* The following fields are need to determine the result of command. */
 u8 sensebuf[MAX_SENSE_SIZE];   /* sense info in case cmd failed; */
@@ -340,7 +340,7 @@ struct net_pkt_xmtdone {
 #define RCVPOST_BUF_SIZE 4032
 #define MAX_NET_RCV_CHAIN \
((VISOR_ETH_MAX_MTU + ETH_HLEN + RCVPOST_BUF_SIZE - 1) \
-   / RCVPOST_BUF_SIZE)
+/ RCVPOST_BUF_SIZE)
 
 /*
  * rcv buf size must be large enough to include ethernet data len + ethernet
@@ -441,7 +441,7 @@ struct uiscmdrsp_scsitaskmgmt {
/* Result of taskmgmt command - set by IOPart - values are: */
char result;
 
-#define TASK_MGMT_FAILED  0
+#define TASK_MGMT_FAILED 0
 } __packed;
 
 /* Used by uissd to send disk add/remove notifications to Guest. */
@@ -496,11 +496,11 @@ struct uiscmdrsp {
char cmdtype;
 
 /* Describes what type of information is in the struct */
-#define CMD_SCSI_TYPE  1
-#define CMD_NET_TYPE   2
-#define CMD_SCSITASKMGMT_TYPE  3
-#define CMD_NOTIFYGUEST_TYPE   4
-#define CMD_VDISKMGMT_TYPE 5
+#define CMD_SCSI_TYPE1
+#define CMD_NET_TYPE 2
+#define CMD_SCSITASKMGMT_TYPE 3
+#define CMD_NOTIFYGUEST_TYPE  4
+#define CMD_VDISKMGMT_TYPE5
union {
struct uiscmdrsp_scsi scsi;
struct uiscmdrsp_net net;
@@ -548,7 +548,7 @@ struct spar_io_channel_protocol {
 #define SIZEOF_CMDRSP (COVER(sizeof(struct uiscmdrsp), 64))
 
 /* Use 4K page sizes when passing page info between Guest and IOPartition. */
-#define PI_PAGE_SIZE  0x1000
-#define PI_PAGE_MASK  0x0FFF
+#define PI_PAGE_SIZE 0x1000
+#define PI_PAGE_MASK 0x0FFF
 
 #endif /* __IOCHANNEL_H__ */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 31/36] staging: unisys: visorbus: vmcallinterface.h: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/vmcallinterface.h | 26 
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/vmcallinterface.h 
b/drivers/staging/unisys/visorbus/vmcallinterface.h
index 3ba1ed7..06bd300 100644
--- a/drivers/staging/unisys/visorbus/vmcallinterface.h
+++ b/drivers/staging/unisys/visorbus/vmcallinterface.h
@@ -59,7 +59,7 @@ __unisys_extended_vmcall_gnuc(unsigned long long tuple,
 #endif /*  */
 
 /* define subsystem number for AppOS, used in uislib driver  */
-#define MDS_APPOS 0x4000L  /* subsystem = 62 - AppOS */
+#define MDS_APPOS 0x4000L /* subsystem = 62 - AppOS */
 enum vmcall_monitor_interface_method_tuple { /* VMCALL identification tuples  
*/
/* Note: when a new VMCALL is added:
 * - the 1st 2 hex digits correspond to one of the
@@ -83,14 +83,14 @@ enum vmcall_monitor_interface_method_tuple { /* VMCALL 
identification tuples  */
 };
 
 #define VMCALL_SUCCESS 0
-#define VMCALL_SUCCESSFUL(result)  (result == 0)
+#define VMCALL_SUCCESSFUL(result) (result == 0)
 
 #define unisys_vmcall(tuple, reg_ebx, reg_ecx) \
__unisys_vmcall_gnuc(tuple, reg_ebx, reg_ecx)
 #define unisys_extended_vmcall(tuple, reg_ebx, reg_ecx, reg_edx) \
__unisys_extended_vmcall_gnuc(tuple, reg_ebx, reg_ecx, reg_edx)
 #define ISSUE_IO_VMCALL(method, param, result) \
-   (result = unisys_vmcall(method, (param) & 0x,   \
+   (result = unisys_vmcall(method, (param) & 0x, \
(param) >> 32))
 
 /* Structures for IO VMCALLs */
@@ -162,16 +162,16 @@ enum event_pc {   /* POSTCODE event 
identifier tuples */
  * entered/exited from.
  */
 
-#define POSTCODE_LINUX(EVENT_PC, pc16bit1, pc16bit2, severity) \
-do {   \
-   unsigned long long post_code_temp;  \
-   post_code_temp = (((u64)CURRENT_FILE_PC) << 56) |   \
-   (((u64)EVENT_PC) << 44) |   \
-   u64)__LINE__) & 0xFFF) << 32) | \
-   u64)pc16bit1) & 0x) << 16) |\
-   (((u64)pc16bit2) & 0x); \
-   unisys_extended_vmcall(VMCALL_POST_CODE_LOGEVENT, severity, \
-  MDS_APPOS, post_code_temp);  \
+#define POSTCODE_LINUX(EVENT_PC, pc16bit1, pc16bit2, severity) \
+do { \
+   unsigned long long post_code_temp; \
+   post_code_temp = (((u64)CURRENT_FILE_PC) << 56) | \
+   (((u64)EVENT_PC) << 44) | \
+   u64)__LINE__) & 0xFFF) << 32) | \
+   u64)pc16bit1) & 0x) << 16) | \
+   (((u64)pc16bit2) & 0x); \
+   unisys_extended_vmcall(VMCALL_POST_CODE_LOGEVENT, severity, \
+  MDS_APPOS, post_code_temp); \
 } while (0)
 
 #endif /* __VMCALLINTERFACE_H__ */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 21/36] staging: unisys: include: remove macro lengthof

[David Kershner]

From: Jon Frisch 

This patch removes the unused macro lengthof.

Signed-off-by: Jon Frisch 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 8c6a7ad..e5e3698 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -38,9 +38,6 @@
 #define SIGNATURE_64(A, B, C, D, E, F, G, H) \
(SIGNATURE_32(A, B, C, D) | ((u64)(SIGNATURE_32(E, F, G, H)) << 32))
 
-#ifndef lengthof
-#define lengthof(TYPE, MEMBER) (sizeof(((TYPE *)0)->MEMBER))
-#endif
 #ifndef COVER
 #define COVER(v, d)   ((d) * DIV_ROUND_UP(v, d))
 #endif
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 24/36] staging: unisys: visornic: remove inline functions

[David Kershner]

From: Jon Frisch 

This patch removes inline functions in visornic_main.c.

Signed-off-by: Jon Frisch 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 89de87f..ac8ed04 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -409,7 +409,7 @@ alloc_rcv_buf(struct net_device *netdev)
  * Send the skb to the IO Partition.
  * Returns void
  */
-static inline void
+static void
 post_skb(struct uiscmdrsp *cmdrsp,
 struct visornic_devdata *devdata, struct sk_buff *skb)
 {
@@ -760,8 +760,8 @@ static unsigned long devdata_xmits_outstanding(struct 
visornic_devdata *devdata)
  *  Returns true iff the number of unacked xmits sent to
  *  the IO partition is >= high_watermark.
  */
-static inline bool vnic_hit_high_watermark(struct visornic_devdata *devdata,
-  ulong high_watermark)
+static bool vnic_hit_high_watermark(struct visornic_devdata *devdata,
+   ulong high_watermark)
 {
return (devdata_xmits_outstanding(devdata) >= high_watermark);
 }
@@ -776,8 +776,8 @@ static inline bool vnic_hit_high_watermark(struct 
visornic_devdata *devdata,
  *  Returns true iff the number of unacked xmits sent to
  *  the IO partition is <= low_watermark.
  */
-static inline bool vnic_hit_low_watermark(struct visornic_devdata *devdata,
- ulong low_watermark)
+static bool vnic_hit_low_watermark(struct visornic_devdata *devdata,
+  ulong low_watermark)
 {
return (devdata_xmits_outstanding(devdata) <= low_watermark);
 }
@@ -1067,7 +1067,7 @@ visornic_xmit_timeout(struct net_device *netdev)
  * we are finished with them.
  * Returns 0 for success, -1 for error.
  */
-static inline int
+static int
 repost_return(struct uiscmdrsp *cmdrsp, struct visornic_devdata *devdata,
  struct sk_buff *skb, struct net_device *netdev)
 {
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 33/36] staging: unisys: visorhba: visorhba_main.c: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 3df9c0e..d372115 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -28,9 +28,9 @@
 
 /* The Send and Receive Buffers of the IO Queue may both be full */
 
-#define IOS_ERROR_THRESHOLD1000
-#define MAX_PENDING_REQUESTS   (MIN_NUMSIGNALS * 2)
-#define VISORHBA_ERROR_COUNT   30
+#define IOS_ERROR_THRESHOLD  1000
+#define MAX_PENDING_REQUESTS (MIN_NUMSIGNALS * 2)
+#define VISORHBA_ERROR_COUNT 30
 
 static struct dentry *visorhba_debugfs_dir;
 
@@ -101,10 +101,10 @@ struct visorhba_devices_open {
struct visorhba_devdata *devdata;
 };
 
-#define for_each_vdisk_match(iter, list, match)  \
+#define for_each_vdisk_match(iter, list, match) \
for (iter = >head; iter->next; iter = iter->next) \
-   if ((iter->channel == match->channel) &&  \
-   (iter->id == match->id) &&\
+   if ((iter->channel == match->channel) && \
+   (iter->id == match->id) && \
(iter->lun == match->lun))
 
 /*
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 25/36] staging: unisys: visorbus: remove #pragma directive

[David Kershner]

From: Jon Frisch 

This patch removes the #pragma directive from visorchannel.h
and adds the __packed keyword to all structs to suppress structure
padding.

Signed-off-by: Jon Frisch 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/vbuschannel.h | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/vbuschannel.h 
b/drivers/staging/unisys/visorbus/vbuschannel.h
index 5dbf6c5..408bb3a 100644
--- a/drivers/staging/unisys/visorbus/vbuschannel.h
+++ b/drivers/staging/unisys/visorbus/vbuschannel.h
@@ -51,8 +51,6 @@ static const uuid_le spar_vbus_channel_protocol_uuid =
   SPAR_VBUS_CHANNEL_PROTOCOL_VERSIONID, \
   SPAR_VBUS_CHANNEL_PROTOCOL_SIGNATURE)
 
-#pragma pack(push, 1)  /* both GCC and VC now allow this pragma */
-
 /*
  * An array of this struct is present in the channel area for each vbus.
  * (See vbuschannel.h.)
@@ -64,7 +62,7 @@ struct ultra_vbus_deviceinfo {
u8 drvname[16]; /* driver .sys file name */
u8 infostrs[96];/* kernel version */
u8 reserved[128];   /* pad size to 256 bytes */
-};
+} __packed;
 
 /*
  * vbuschannel_print_devinfo() - format a struct ultra_vbus_deviceinfo
@@ -113,7 +111,7 @@ struct spar_vbus_headerinfo {
u32 dev_info_offset;/* byte offset from beginning of this struct */
/* to the DevInfo array (below) */
u8 reserved[104];
-};
+} __packed;
 
 struct spar_vbus_channel_protocol {
struct channel_header channel_header;   /* initialized by server */
@@ -125,8 +123,6 @@ struct spar_vbus_channel_protocol {
/* describes client bus device and driver */
struct ultra_vbus_deviceinfo dev_info[0];
/* describes client device and driver for each device on the bus */
-};
-
-#pragma pack(pop)
+} __packed;
 
 #endif
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 19/36] staging: unisys: include: simplify spar_check_channel_client

[David Kershner]

The function spar_check_channel_client shouldn't need to do
readq's, it is referencing a local copy of the channel
header. Simplify it to just access the fields directly.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 37 -
 1 file changed, 13 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index d3c1dac..8c6a7ad 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -217,7 +217,7 @@ struct signal_queue_header {
  * is used to pass the EFI_DIAG_CAPTURE_PROTOCOL needed to log messages.
  */
 static inline int
-spar_check_channel_client(void __iomem *ch,
+spar_check_channel_client(struct channel_header *ch,
  uuid_le expected_uuid,
  char *chname,
  u64 expected_min_bytes,
@@ -225,48 +225,37 @@ spar_check_channel_client(void __iomem *ch,
  u64 expected_signature)
 {
if (uuid_le_cmp(expected_uuid, NULL_UUID_LE) != 0) {
-   uuid_le guid;
-
-   memcpy_fromio(,
- &((struct channel_header __iomem *)(ch))->chtype,
- sizeof(guid));
/* caller wants us to verify type GUID */
-   if (uuid_le_cmp(guid, expected_uuid) != 0) {
+   if (uuid_le_cmp(ch->chtype, expected_uuid) != 0) {
pr_err("Channel mismatch on channel=%s(%pUL) field=type 
expected=%pUL actual=%pUL\n",
   chname, _uuid,
-  _uuid, );
+  _uuid, >chtype);
return 0;
}
}
if (expected_min_bytes > 0) {   /* verify channel size */
-   unsigned long long bytes =
-   readq(&((struct channel_header __iomem *)
-   (ch))->size);
-   if (bytes < expected_min_bytes) {
+   if (ch->size < expected_min_bytes) {
pr_err("Channel mismatch on channel=%s(%pUL) field=size 
expected=0x%-8.8Lx actual=0x%-8.8Lx\n",
   chname, _uuid,
-  (unsigned long long)expected_min_bytes, bytes);
+  (unsigned long long)expected_min_bytes,
+  ch->size);
return 0;
}
}
if (expected_version > 0) { /* verify channel version */
-   unsigned long ver = readl(&((struct channel_header __iomem *)
-   (ch))->version_id);
-   if (ver != expected_version) {
-   pr_err("Channel mismatch on channel=%s(%pUL) 
field=version expected=0x%-8.8lx actual=0x%-8.8lx\n",
+   if (ch->version_id != expected_version) {
+   pr_err("Channel mismatch on channel=%s(%pUL) 
field=version expected=0x%-8.8lx actual=0x%-8.8x\n",
   chname, _uuid,
-  (unsigned long)expected_version, ver);
+  (unsigned long)expected_version,
+  ch->version_id);
return 0;
}
}
if (expected_signature > 0) {   /* verify channel signature */
-   unsigned long long sig =
-   readq(&((struct channel_header __iomem *)
-   (ch))->signature);
-   if (sig != expected_signature) {
-   pr_err("Channel mismatch on channel=%s(%pUL) 
field=signature expected=0x%-8.8llx actual=0x%-8.8llx\n",
+   if (ch->signature != expected_signature) {
+   pr_err("Channel mismatch on channel=%s(%pUL) 
field=signature expected=0x%-8.8Lx actual=0x%-8.8Lx\n",
   chname, _uuid,
-  expected_signature, sig);
+  expected_signature, ch->signature);
return 0;
}
}
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 13/36] staging: unisys: visorbus: Rename #define VMCALL_IO_CONTROLVM_ADDR

[David Kershner]

From: David Binder 

Rename #define VMCALL_IO_CONTROLVM_ADDR to VMCALL_CONTROLVM_ADDR, as this
vmcall can be used by any partition, not just the IO partition.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c| 2 +-
 drivers/staging/unisys/visorbus/vmcallinterface.h | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 184cf5f..c7b7cae 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1321,7 +1321,7 @@ issue_vmcall_io_controlvm_addr(u64 *control_addr, u32 
*control_bytes)
u64 physaddr;
 
physaddr = virt_to_phys();
-   ISSUE_IO_VMCALL(VMCALL_IO_CONTROLVM_ADDR, physaddr, result);
+   ISSUE_IO_VMCALL(VMCALL_CONTROLVM_ADDR, physaddr, result);
if (VMCALL_SUCCESSFUL(result)) {
*control_addr = params.address;
*control_bytes = params.channel_bytes;
diff --git a/drivers/staging/unisys/visorbus/vmcallinterface.h 
b/drivers/staging/unisys/visorbus/vmcallinterface.h
index d1d72c1..1a65336 100644
--- a/drivers/staging/unisys/visorbus/vmcallinterface.h
+++ b/drivers/staging/unisys/visorbus/vmcallinterface.h
@@ -54,8 +54,8 @@ __unisys_extended_vmcall_gnuc(unsigned long long tuple,
return result;
 }
 
-#ifdef VMCALL_IO_CONTROLVM_ADDR
-#undef VMCALL_IO_CONTROLVM_ADDR
+#ifdef VMCALL_CONTROLVM_ADDR
+#undef VMCALL_CONTROLVM_ADDR
 #endif /*  */
 
 /* define subsystem number for AppOS, used in uislib driver  */
@@ -72,7 +72,7 @@ enum vmcall_monitor_interface_method_tuple { /* VMCALL 
identification tuples  */
 *   type of VMCALL
 */
/* used by all Guests, not just IO */
-   VMCALL_IO_CONTROLVM_ADDR = 0x0501,
+   VMCALL_CONTROLVM_ADDR = 0x0501,
/* Allow caller to query virtual time offset */
VMCALL_QUERY_GUEST_VIRTUAL_TIME_OFFSET = 0x0708,
/* LOGEVENT Post Code (RDX) with specified subsystem mask */
@@ -95,7 +95,7 @@ enum vmcall_monitor_interface_method_tuple { /* VMCALL 
identification tuples  */
 
 /* Structures for IO VMCALLs */
 
-/* Parameters to VMCALL_IO_CONTROLVM_ADDR interface */
+/* Parameters to VMCALL_CONTROLVM_ADDR interface */
 struct vmcall_io_controlvm_addr_params {
/* The Guest-relative physical address of the ControlVm channel. */
/* This VMCall fills this in with the appropriate address. */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 29/36] staging: unisys: visorbus: visorchipset.c: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index c7b7cae..46c5a93 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -29,7 +29,7 @@
 
 #define CURRENT_FILE_PC VISOR_BUS_PC_visorchipset_c
 
-#define POLLJIFFIES_CONTROLVMCHANNEL_FAST   1
+#define POLLJIFFIES_CONTROLVMCHANNEL_FAST 1
 #define POLLJIFFIES_CONTROLVMCHANNEL_SLOW 100
 
 #define MAX_CONTROLVM_PAYLOAD_BYTES (1024 * 128)
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 27/36] staging: unisys: visorbus: visorbus_main.c: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index cdad654..fc841b1 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -31,7 +31,7 @@ static int visorbus_forcenomatch;
 #define LINESIZE 99
 
 #define CURRENT_FILE_PC VISOR_BUS_PC_visorbus_main_c
-#define POLLJIFFIES_NORMALCHANNEL 10
+#define POLLJIFFIES_NORMALCHANNEL 10
 
 static int busreg_rc = -ENODEV; /* stores the result from bus registration */
 static struct dentry *visorbus_debugfs_dir;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 12/36] staging: unisys: visorbus: Remove useless checks in visorbus_main.c

[David Kershner]

From: David Binder 

Removes checks that all visor_device instances have an associated
visorchannel. Due to the design of the s-Par drivers these checks are
unnecessary.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 22 --
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index e9c7d1a..cdad654 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -185,8 +185,6 @@ static ssize_t physaddr_show(struct device *dev, struct 
device_attribute *attr,
 {
struct visor_device *vdev = to_visor_device(dev);
 
-   if (!vdev->visorchannel)
-   return 0;
return sprintf(buf, "0x%llx\n",
   visorchannel_get_physaddr(vdev->visorchannel));
 }
@@ -197,8 +195,6 @@ static ssize_t nbytes_show(struct device *dev, struct 
device_attribute *attr,
 {
struct visor_device *vdev = to_visor_device(dev);
 
-   if (!vdev->visorchannel)
-   return 0;
return sprintf(buf, "0x%lx\n",
visorchannel_get_nbytes(vdev->visorchannel));
 }
@@ -209,8 +205,6 @@ static ssize_t clientpartition_show(struct device *dev,
 {
struct visor_device *vdev = to_visor_device(dev);
 
-   if (!vdev->visorchannel)
-   return 0;
return sprintf(buf, "0x%llx\n",
   visorchannel_get_clientpartition(vdev->visorchannel));
 }
@@ -222,8 +216,6 @@ static ssize_t typeguid_show(struct device *dev, struct 
device_attribute *attr,
struct visor_device *vdev = to_visor_device(dev);
char typeid[LINESIZE];
 
-   if (!vdev->visorchannel)
-   return 0;
return sprintf(buf, "%s\n",
   visorchannel_id(vdev->visorchannel, typeid));
 }
@@ -235,8 +227,6 @@ static ssize_t zoneguid_show(struct device *dev, struct 
device_attribute *attr,
struct visor_device *vdev = to_visor_device(dev);
char zoneid[LINESIZE];
 
-   if (!vdev->visorchannel)
-   return 0;
return sprintf(buf, "%s\n",
   visorchannel_zoneid(vdev->visorchannel, zoneid));
 }
@@ -245,13 +235,12 @@ static DEVICE_ATTR_RO(zoneguid);
 static ssize_t typename_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
-   struct visor_device *vdev = to_visor_device(dev);
int i = 0;
struct bus_type *xbus = dev->bus;
struct device_driver *xdrv = dev->driver;
struct visor_driver *drv = NULL;
 
-   if (!vdev->visorchannel || !xbus || !xdrv)
+   if (!xbus || !xdrv)
return 0;
i = xbus->match(dev, xdrv);
if (!i)
@@ -344,11 +333,10 @@ static ssize_t channel_id_show(struct device *dev,
struct visor_device *vdev = to_visor_device(dev);
int len = 0;
 
-   if (vdev->visorchannel) {
-   visorchannel_id(vdev->visorchannel, buf);
-   len = strlen(buf);
-   buf[len++] = '\n';
-   }
+   visorchannel_id(vdev->visorchannel, buf);
+   len = strlen(buf);
+   buf[len++] = '\n';
+
return len;
 }
 static DEVICE_ATTR_RO(channel_id);
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 28/36] staging: unisys: visorbus: controlvmchannel.h: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/controlvmchannel.h | 134 +++---
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/staging/unisys/visorbus/controlvmchannel.h
index 79f77ad..63f9e44 100644
--- a/drivers/staging/unisys/visorbus/controlvmchannel.h
+++ b/drivers/staging/unisys/visorbus/controlvmchannel.h
@@ -19,9 +19,9 @@
 #include "channel.h"
 
 /* {2B3C2D10-7EF5-4ad8-B966-3448B7386B3D} */
-#define SPAR_CONTROLVM_CHANNEL_PROTOCOL_UUID   \
-   UUID_LE(0x2b3c2d10, 0x7ef5, 0x4ad8, \
-   0xb9, 0x66, 0x34, 0x48, 0xb7, 0x38, 0x6b, 0x3d)
+#define SPAR_CONTROLVM_CHANNEL_PROTOCOL_UUID \
+   UUID_LE(0x2b3c2d10, 0x7ef5, 0x4ad8, \
+   0xb9, 0x66, 0x34, 0x48, 0xb7, 0x38, 0x6b, 0x3d)
 
 #define ULTRA_CONTROLVM_CHANNEL_PROTOCOL_SIGNATURE \
ULTRA_CHANNEL_PROTOCOL_SIGNATURE
@@ -33,24 +33,24 @@
  * software.  Note that you can usually add fields to the END of the
  * channel struct withOUT needing to increment this.
  */
-#define ULTRA_CONTROLVM_CHANNEL_PROTOCOL_VERSIONID  1
+#define ULTRA_CONTROLVM_CHANNEL_PROTOCOL_VERSIONID 1
 
-#define SPAR_CONTROLVM_CHANNEL_OK_CLIENT(ch)   \
-   spar_check_channel_client(ch, \
+#define SPAR_CONTROLVM_CHANNEL_OK_CLIENT(ch) \
+   (spar_check_channel_client(ch, \
SPAR_CONTROLVM_CHANNEL_PROTOCOL_UUID, \
"controlvm", \
sizeof(struct spar_controlvm_channel_protocol), \
ULTRA_CONTROLVM_CHANNEL_PROTOCOL_VERSIONID, \
-   ULTRA_CONTROLVM_CHANNEL_PROTOCOL_SIGNATURE)
+   ULTRA_CONTROLVM_CHANNEL_PROTOCOL_SIGNATURE))
 
 /* Defines for various channel queues */
-#define CONTROLVM_QUEUE_REQUEST0
-#define CONTROLVM_QUEUE_RESPONSE   1
-#define CONTROLVM_QUEUE_EVENT  2
-#define CONTROLVM_QUEUE_ACK3
+#define CONTROLVM_QUEUE_REQUEST 0
+#define CONTROLVM_QUEUE_RESPONSE 1
+#define CONTROLVM_QUEUE_EVENT   2
+#define CONTROLVM_QUEUE_ACK 3
 
 /* Max num of messages stored during IOVM creation to be reused after crash */
-#define CONTROLVM_CRASHMSG_MAX 2
+#define CONTROLVM_CRASHMSG_MAX 2
 
 struct spar_segment_state  {
/* Bit 0: May enter other states */
@@ -453,78 +453,78 @@ struct spar_controlvm_parameters_header {
 };
 
 /* General Errors--[0-99] 
*/
-#define CONTROLVM_RESP_SUCCESS  0
-#define CONTROLVM_RESP_ALREADY_DONE 1
-#define CONTROLVM_RESP_IOREMAP_FAILED   2
-#define CONTROLVM_RESP_KMALLOC_FAILED   3
-#define CONTROLVM_RESP_ID_UNKNOWN   4
-#define CONTROLVM_RESP_ID_INVALID_FOR_CLIENT5
+#define CONTROLVM_RESP_SUCCESS0
+#define CONTROLVM_RESP_ALREADY_DONE   1
+#define CONTROLVM_RESP_IOREMAP_FAILED 2
+#define CONTROLVM_RESP_KMALLOC_FAILED 3
+#define CONTROLVM_RESP_ID_UNKNOWN 4
+#define CONTROLVM_RESP_ID_INVALID_FOR_CLIENT  5
 
 /* CONTROLVM_INIT_CHIPSET---[100-199] 
*/
-#define CONTROLVM_RESP_CLIENT_SWITCHCOUNT_NONZERO   100
-#define CONTROLVM_RESP_EXPECTED_CHIPSET_INIT101
+#define CONTROLVM_RESP_CLIENT_SWITCHCOUNT_NONZERO  100
+#define CONTROLVM_RESP_EXPECTED_CHIPSET_INIT  101
 
 /* Maximum Limit[200-299] 
*/
-#define CONTROLVM_RESP_ERROR_MAX_BUSES 201 /* BUS_CREATE */
-#define CONTROLVM_RESP_ERROR_MAX_DEVICES202/* DEVICE_CREATE */
+#define CONTROLVM_RESP_ERROR_MAX_BUSES201 /* BUS_CREATE */
+#define CONTROLVM_RESP_ERROR_MAX_DEVICES  202 /* DEVICE_CREATE */
 /* Payload and Parameter Related[400-499] 
*/
-#define CONTROLVM_RESP_PAYLOAD_INVALID 400 /* SWITCH_ATTACHEXTPORT,
-* DEVICE_CONFIGURE
-*/
-#define CONTROLVM_RESP_INITIATOR_PARAMETER_INVALID 401  /* Multiple */
-#define CONTROLVM_RESP_TARGET_PARAMETER_INVALID402  /* DEVICE_CONFIGURE */
-#define 

[PATCH 22/36] staging: unisys: include: removed unused function declarations

[David Kershner]

From: Jon Frisch 

This patch removes the unused function declarations
in channel.h.

Signed-off-by: Jon Frisch 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 80 +-
 1 file changed, 80 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index e5e3698..048ef16 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -260,86 +260,6 @@ spar_check_channel_client(struct channel_header *ch,
 }
 
 /*
- * Routine Description:
- * Tries to insert the prebuilt signal pointed to by pSignal into the nth
- * Queue of the Channel pointed to by pChannel
- *
- * Parameters:
- * pChannel: (IN) points to the IO Channel
- * Queue: (IN) nth Queue of the IO Channel
- * pSignal: (IN) pointer to the signal
- *
- * Assumptions:
- * - pChannel, Queue and pSignal are valid.
- * - If insertion fails due to a full queue, the caller will determine the
- * retry policy (e.g. wait & try again, report an error, etc.).
- *
- * Return value: 1 if the insertion succeeds, 0 if the queue was
- * full.
- */
-
-unsigned char spar_signal_insert(struct channel_header __iomem *ch, u32 queue,
-void *sig);
-
-/*
- * Routine Description:
- * Removes one signal from Channel pChannel's nth Queue at the
- * time of the call and copies it into the memory pointed to by
- * pSignal.
- *
- * Parameters:
- * pChannel: (IN) points to the IO Channel
- * Queue: (IN) nth Queue of the IO Channel
- * pSignal: (IN) pointer to where the signals are to be copied
- *
- * Assumptions:
- * - pChannel and Queue are valid.
- * - pSignal points to a memory area large enough to hold queue's SignalSize
- *
- * Return value: 1 if the removal succeeds, 0 if the queue was
- * empty.
- */
-
-unsigned char spar_signal_remove(struct channel_header __iomem *ch, u32 queue,
-void *sig);
-
-/*
- * Routine Description:
- * Removes all signals present in Channel pChannel's nth Queue at the
- * time of the call and copies them into the memory pointed to by
- * pSignal.  Returns the # of signals copied as the value of the routine.
- *
- * Parameters:
- * pChannel: (IN) points to the IO Channel
- * Queue: (IN) nth Queue of the IO Channel
- * pSignal: (IN) pointer to where the signals are to be copied
- *
- * Assumptions:
- * - pChannel and Queue are valid.
- * - pSignal points to a memory area large enough to hold Queue's MaxSignals
- * # of signals, each of which is Queue's SignalSize.
- *
- * Return value:
- * # of signals copied.
- */
-unsigned int spar_signal_remove_all(struct channel_header *ch, u32 queue,
-   void *sig);
-
-/*
- * Routine Description:
- * Determine whether a signal queue is empty.
- *
- * Parameters:
- * pChannel: (IN) points to the IO Channel
- * Queue: (IN) nth Queue of the IO Channel
- *
- * Return value:
- * 1 if the signal queue is empty, 0 otherwise.
- */
-unsigned char spar_signalqueue_empty(struct channel_header __iomem *ch,
-u32 queue);
-
-/*
  * CHANNEL Guids
  */
 
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 26/36] staging: unisys: visorbus: visorchannel.c: Fix #define formatting

[David Kershner]

From: David Binder 

In an effort to create a more uniform coding style within the Unisys
s-Par driver set, this patch adjusts the formatting of all #define
directives within this source file to match the following template,
and thereby eliminate irregular usage of whitespace:
Reviewed-by: Tim Sell 

The amount of whitespace used between the  and the  is
dependent on what is needed to make the surrounding #define directives
as uniform as possible.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/visorchannel.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 1b1ef93..686137a 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -29,8 +29,9 @@
 #define MYDRVNAME "visorchannel"
 
 #define SPAR_CONSOLEVIDEO_CHANNEL_PROTOCOL_GUID \
-   UUID_LE(0x3cd6e705, 0xd6a2, 0x4aa5,   \
+   UUID_LE(0x3cd6e705, 0xd6a2, 0x4aa5, \
0xad, 0x5c, 0x7b, 0x8, 0x88, 0x9d, 0xff, 0xe2)
+
 static const uuid_le spar_video_guid = SPAR_CONSOLEVIDEO_CHANNEL_PROTOCOL_GUID;
 
 struct visorchannel {
@@ -173,17 +174,17 @@ visorchannel_get_header(struct visorchannel *channel)
  */
 #define SIG_DATA_OFFSET(chan_hdr, q, sig_hdr, slot) \
(SIG_QUEUE_OFFSET(chan_hdr, q) + (sig_hdr)->sig_base_offset + \
-   ((slot) * (sig_hdr)->signal_size))
+((slot) * (sig_hdr)->signal_size))
 
 /*
  * Write the contents of a specific field within a SIGNAL_QUEUE_HEADER back
  * into host memory
  */
-#define SIG_WRITE_FIELD(channel, queue, sig_hdr, FIELD)
 \
-   visorchannel_write(channel,  \
-  SIG_QUEUE_OFFSET(>chan_hdr, queue) +\
+#define SIG_WRITE_FIELD(channel, queue, sig_hdr, FIELD) \
+   visorchannel_write(channel, \
+  SIG_QUEUE_OFFSET(>chan_hdr, queue) + \
   offsetof(struct signal_queue_header, FIELD), \
-  &((sig_hdr)->FIELD),  \
+  &((sig_hdr)->FIELD), \
   sizeof((sig_hdr)->FIELD))
 
 static int
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 16/36] staging: unisys: visorbus: Rename what vmcallinterface.h #define

[David Kershner]

From: David Binder 

Renames __IOMONINTF_H__ to __VMCALLINTERFACE_H__, which more closely
reflects the naming conventions of the code.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/vmcallinterface.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/vmcallinterface.h 
b/drivers/staging/unisys/visorbus/vmcallinterface.h
index 1a65336..3ba1ed7 100644
--- a/drivers/staging/unisys/visorbus/vmcallinterface.h
+++ b/drivers/staging/unisys/visorbus/vmcallinterface.h
@@ -12,8 +12,8 @@
  * details.
  */
 
-#ifndef __IOMONINTF_H__
-#define __IOMONINTF_H__
+#ifndef __VMCALLINTERFACE_H__
+#define __VMCALLINTERFACE_H__
 
 /*
  * This file contains all structures needed to support the VMCALLs for IO
@@ -174,4 +174,4 @@ do {
\
   MDS_APPOS, post_code_temp);  \
 } while (0)
 
-#endif /* __IOMONINTF_H__ */
+#endif /* __VMCALLINTERFACE_H__ */
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 10/36] staging: unisys: include: Wrap macro argument in parenthesis

[David Kershner]

From: David Binder 

Addresses checkpatch check by wrapping macro argument in parenthesis.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index e202f5b..36dbe21 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -32,7 +32,7 @@
  */
 #define __SUPERVISOR_CHANNEL_H__
 
-#define SIGNATURE_16(A, B) ((A) | (B << 8))
+#define SIGNATURE_16(A, B) ((A) | ((B) << 8))
 #define SIGNATURE_32(A, B, C, D) \
(SIGNATURE_16(A, B) | (SIGNATURE_16(C, D) << 16))
 #define SIGNATURE_64(A, B, C, D, E, F, G, H) \
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 20/36] staging: unisys: visorbus: Remove pointer cast that causes sparse warning

[David Kershner]

From: David Binder 

Removes unnecessary cast of to __iomem of a non-io-mapped pointer, thereby
eliminating the following sparse warning:

visorchannel.c:159:17: warning: cast adds address space to expression ()

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_private.h | 2 +-
 drivers/staging/unisys/visorbus/visorchannel.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 49bec17..eb8b3ec 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -81,5 +81,5 @@ u64 visorchannel_get_clientpartition(struct visorchannel 
*channel);
 int visorchannel_set_clientpartition(struct visorchannel *channel,
 u64 partition_handle);
 char *visorchannel_uuid_id(uuid_le *guid, char *s);
-void __iomem *visorchannel_get_header(struct visorchannel *channel);
+void *visorchannel_get_header(struct visorchannel *channel);
 #endif
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 31cd37d..1b1ef93 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -153,10 +153,10 @@ visorchannel_write(struct visorchannel *channel, ulong 
offset,
return 0;
 }
 
-void __iomem  *
+void *
 visorchannel_get_header(struct visorchannel *channel)
 {
-   return (void __iomem *)>chan_hdr;
+   return >chan_hdr;
 }
 
 /*
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 18/36] staging: unisys: include: Add function definition argument identifier

[David Kershner]

From: David Binder 

Adds identifier to function definition arguments to satisfy checkpatch
warnings:

WARNING: function definition argument 'struct visor_driver *' should also
have an identifier name
WARNING: function definition argument 'struct visor_driver *' should also
have an identifier name

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 03d56f8..0bb7903 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -172,8 +172,8 @@ struct visor_device {
 
 #define to_visor_device(x) container_of(x, struct visor_device, device)
 
-int visorbus_register_visor_driver(struct visor_driver *);
-void visorbus_unregister_visor_driver(struct visor_driver *);
+int visorbus_register_visor_driver(struct visor_driver *drv);
+void visorbus_unregister_visor_driver(struct visor_driver *drv);
 int visorbus_read_channel(struct visor_device *dev,
  unsigned long offset, void *dest,
  unsigned long nbytes);
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 09/36] staging: unisys: visorbus: remove inline keyword in visorchannel.c

[David Kershner]

From: Sameer Wadgaonkar 

Removed inline keyword from functions sig_read_data and
sig_write_data in visorchannel.c

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchannel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 1e3dc58..31cd37d 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -199,7 +199,7 @@ sig_read_header(struct visorchannel *channel, u32 queue,
 sig_hdr, sizeof(struct signal_queue_header));
 }
 
-static inline int
+static int
 sig_read_data(struct visorchannel *channel, u32 queue,
  struct signal_queue_header *sig_hdr, u32 slot, void *data)
 {
@@ -210,7 +210,7 @@ sig_read_data(struct visorchannel *channel, u32 queue,
 data, sig_hdr->signal_size);
 }
 
-static inline int
+static int
 sig_write_data(struct visorchannel *channel, u32 queue,
   struct signal_queue_header *sig_hdr, u32 slot, void *data)
 {
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 07/36] staging: unisys: visorhba: remove inline keyword

[David Kershner]

From: Sameer Wadgaonkar 

Removed inline keyword from the function complete_taskmgmt_command
in visorhba_main.c

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 4018d5a..3df9c0e 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -686,8 +686,8 @@ static const struct file_operations info_debugfs_fops = {
  * command. Wake up anyone waiting for it.
  * Returns void
  */
-static inline void complete_taskmgmt_command
-(struct idr *idrtable, struct uiscmdrsp *cmdrsp, int result)
+static void complete_taskmgmt_command(struct idr *idrtable,
+ struct uiscmdrsp *cmdrsp, int result)
 {
wait_queue_head_t *wq =
idr_find(idrtable, cmdrsp->scsitaskmgmt.notify_handle);
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 05/36] staging: unisys: include: remove unused macro spar_signal_init

[David Kershner]

From: Sameer Wadgaonkar 

Removed unused macro spar_signal_init from channel.h

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 88fec81..e202f5b 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -211,20 +211,6 @@ struct signal_queue_header {
u8 filler[12];  /* Pad out to 64 byte cacheline */
 } __packed;
 
-#define spar_signal_init(chan, QHDRFLD, QDATAFLD, QDATATYPE, ver, typ) \
-   do {\
-   memset(>QHDRFLD, 0, sizeof(chan->QHDRFLD));   \
-   chan->QHDRFLD.version = ver;\
-   chan->QHDRFLD.chtype = typ; \
-   chan->QHDRFLD.size = sizeof(chan->QDATAFLD);\
-   chan->QHDRFLD.signal_size = sizeof(QDATATYPE);  \
-   chan->QHDRFLD.sig_base_offset = (u64)(chan->QDATAFLD) - \
-   (u64)(>QHDRFLD);  \
-   chan->QHDRFLD.max_slots =   \
-   sizeof(chan->QDATAFLD) / sizeof(QDATATYPE); \
-   chan->QHDRFLD.max_signals = chan->QHDRFLD.max_slots - 1;\
-   } while (0)
-
 /* Generic function useful for validating any type of channel when it is
  * received by the client that will be accessing the channel.
  * Note that  is only needed for callers in the EFI environment, and
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 02/36] staging: unisys: visorbus_main: removed revference to virtpci

[David Kershner]

From: Alexander Curtin 

The comment referencing virtpci was irrelevant.

Signed-off-by: Alexander Curtin 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index e7b04b6..e9c7d1a 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -823,10 +823,6 @@ fix_vbus_dev_info(struct visor_device *visordev)
bus_device_info_init(_info, chan_type_name, visordrv->name);
write_vbus_dev_info(bdev->visorchannel, hdr_info, _info, dev_no);
 
-   /*
-* Re-write bus+chipset info, because it is possible that this
-* was previously written by our evil counterpart, virtpci.
-*/
write_vbus_chp_info(bdev->visorchannel, hdr_info, _driverinfo);
write_vbus_bus_info(bdev->visorchannel, hdr_info,
_driverinfo);
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 17/36] staging: unisys: visorinput: Remove unnecessary usage of local variable

[David Kershner]

From: David Binder 

Remove local variable on stack by directly returning the value in the
array.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorinput/visorinput.c |  9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorinput/visorinput.c 
b/drivers/staging/unisys/visorinput/visorinput.c
index 949cce6..3fc7d9e 100644
--- a/drivers/staging/unisys/visorinput/visorinput.c
+++ b/drivers/staging/unisys/visorinput/visorinput.c
@@ -539,13 +539,10 @@ handle_locking_key(struct input_dev *visorinput_dev,
 static int
 scancode_to_keycode(int scancode)
 {
-   int keycode;
-
if (scancode > 0xff)
-   keycode = visorkbd_ext_keycode[(scancode >> 8) & 0xff];
-   else
-   keycode = visorkbd_keycode[scancode];
-   return keycode;
+   return visorkbd_ext_keycode[(scancode >> 8) & 0xff];
+
+   return  visorkbd_keycode[scancode];
 }
 
 static int
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 04/36] staging: unisys: include: remove unused function spar_check_channel_server

[David Kershner]

From: Sameer Wadgaonkar 

Removed unused function spar_check_channel_server from channel.h

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 8024529..88fec81 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -287,25 +287,6 @@ spar_check_channel_client(void __iomem *ch,
return 1;
 }
 
-/* Generic function useful for validating any type of channel when it is about
- * to be initialized by the server of the channel.
- * Note that  is only needed for callers in the EFI environment, and
- * is used to pass the EFI_DIAG_CAPTURE_PROTOCOL needed to log messages.
- */
-static inline int spar_check_channel_server(uuid_le typeuuid, char *name,
-   u64 expected_min_bytes,
-   u64 actual_bytes)
-{
-   if (expected_min_bytes > 0) /* verify channel size */
-   if (actual_bytes < expected_min_bytes) {
-   pr_err("Channel mismatch on channel=%s(%pUL) field=size 
expected=0x%-8.8llx actual=0x%-8.8llx\n",
-  name, , expected_min_bytes,
-  actual_bytes);
-   return 0;
-   }
-   return 1;
-}
-
 /*
  * Routine Description:
  * Tries to insert the prebuilt signal pointed to by pSignal into the nth
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 08/36] staging: unisys: visorbus: remove inline keyword from visorchipset

[David Kershner]

From: Sameer Wadgaonkar 

Removed inline keyword from the functions in visorchipset:
* issue_vmcall_io_controlvm_addr()

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 893bdb3..184cf5f 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1313,7 +1313,7 @@ chipset_notready_uevent(struct controlvm_message_header 
*msg_hdr)
return 0;
 }
 
-static inline unsigned int
+static unsigned int
 issue_vmcall_io_controlvm_addr(u64 *control_addr, u32 *control_bytes)
 {
struct vmcall_io_controlvm_addr_params params;
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 00/36] staging: unisys: additional code cleanups

[David Kershner]

This series cleans up several different checkpatch, sparse and other
miscellaneous code issues found throughout the Unisys s-Par driver stack.
It also cleans up the comments surrounding #defines.

Note: Acceptence of this patch series determines whether or not the team
will partake in a soft, sweet food made from a mixture of flour, shortening,
eggs, sugar and other ingredients, baked and often decorated. Though some
would suggest that it is a lie.

Alexander Curtin (2):
  staging: unisys: include: replaced COVERQ with DIV_ROUND_UP
  staging: unisys: visorbus_main: removed revference to virtpci

David Binder (21):
  staging: unisys: include: Wrap macro argument in parenthesis
  staging: unisys: include: Remove unused visorchannel #defines
  staging: unisys: visorbus: Remove useless checks in visorbus_main.c
  staging: unisys: visorbus: Rename #define VMCALL_IO_CONTROLVM_ADDR
  staging: unisys: include: Change out-of-date references
  staging: unisys: visornic: Move function to appropriate location
  staging: unisys: visorbus: Rename what vmcallinterface.h #define
  staging: unisys: visorinput: Remove unnecessary usage of local variable
  staging: unisys: include: Add function definition argument identifier
  staging: unisys: visorbus: Remove pointer cast that causes sparse warning
  staging: unisys: visorbus: visorchannel.c: Fix #define formatting
  staging: unisys: visorbus: visorbus_main.c: Fix #define formatting
  staging: unisys: visorbus: controlvmchannel.h: Fix #define formatting
  staging: unisys: visorbus: visorchipset.c: Fix #define formatting
  staging: unisys: visorbus: vbuschannel.h: Fix #define formatting
  staging: unisys: visorbus: vmcallinterface.h: Fix #define formatting
  staging: unisys: visorinput: visorinput.c: Fix #define formatting
  staging: unisys: visorhba: visorhba_main.c: Fix #define formatting
  staging: unisys: include: iochannel.h: Fix #define formatting
  staging: unisys: include: visorbus.h: Fix #define formatting
  staging: unisys: include: channel.h: Fix #define formatting

David Kershner (1):
  staging: unisys: include: simplify spar_check_channel_client

Jon Frisch (5):
  staging: unisys: include: remove macro lengthof
  staging: unisys: include: removed unused function declarations
  staging: unisys: include: remove irrelevant comments
  staging: unisys: visornic: remove inline functions
  staging: unisys: visorbus: remove #pragma directive

Sameer Wadgaonkar (7):
  staging: unisys: visorbus: removed unused structure pci_id
  staging: unisys: include: remove unused function spar_check_channel_server
  staging: unisys: include: remove unused macro spar_signal_init
  staging: unisys: visorbus: remove unused functions in visorchipset
  staging: unisys: visorhba: remove inline keyword
  staging: unisys: visorbus: remove inline keyword from visorchipset
  staging: unisys: visorbus: remove inline keyword in visorchannel.c

 drivers/staging/unisys/include/channel.h   | 203 +-
 drivers/staging/unisys/include/iochannel.h |  65 +
 drivers/staging/unisys/include/visorbus.h  |   6 +-
 drivers/staging/unisys/visorbus/controlvmchannel.h | 142 --
 drivers/staging/unisys/visorbus/vbuschannel.h  |  28 +--
 drivers/staging/unisys/visorbus/visorbus_main.c|  28 +--
 drivers/staging/unisys/visorbus/visorbus_private.h |   2 +-
 drivers/staging/unisys/visorbus/visorchannel.c |  21 +-
 drivers/staging/unisys/visorbus/visorchipset.c |  24 +--
 drivers/staging/unisys/visorbus/vmcallinterface.h  |  40 +--
 drivers/staging/unisys/visorhba/visorhba_main.c|  16 +-
 drivers/staging/unisys/visorinput/visorinput.c |  21 +-
 drivers/staging/unisys/visornic/visornic_main.c|  49 ++-
 13 files changed, 222 insertions(+), 423 deletions(-)

base-commit: 7bc49cb9b9b8bad32536c4b6d1aff1824c1adc6c
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 01/36] staging: unisys: include: replaced COVERQ with DIV_ROUND_UP

[David Kershner]

From: Alexander Curtin 

COVERQ is functionally equivalent to DIV_ROUND_UP and was only used
to define the COVER macro.

Signed-off-by: Alexander Curtin 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/channel.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/include/channel.h 
b/drivers/staging/unisys/include/channel.h
index 1c95302..8024529 100644
--- a/drivers/staging/unisys/include/channel.h
+++ b/drivers/staging/unisys/include/channel.h
@@ -41,11 +41,8 @@
 #ifndef lengthof
 #define lengthof(TYPE, MEMBER) (sizeof(((TYPE *)0)->MEMBER))
 #endif
-#ifndef COVERQ
-#define COVERQ(v, d)  (((v) + (d) - 1) / (d))
-#endif
 #ifndef COVER
-#define COVER(v, d)   ((d) * COVERQ(v, d))
+#define COVER(v, d)   ((d) * DIV_ROUND_UP(v, d))
 #endif
 
 #define ULTRA_CHANNEL_PROTOCOL_SIGNATURE  SIGNATURE_32('E', 'C', 'N', 'L')
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 06/36] staging: unisys: visorbus: remove unused functions in visorchipset

[David Kershner]

From: Sameer Wadgaonkar 

Removed unused functions issue_vmcall_update_physical_time() and
issue_vmcall_query_guest_virtual_time_offset() from visorchipset.c

Signed-off-by: Sameer Wadgaonkar 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index cce1974..893bdb3 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1495,24 +1495,6 @@ device_resume_response(struct visor_device *dev_info, 
int response)
dev_info->pending_msg_hdr = NULL;
 }
 
-static inline s64 issue_vmcall_query_guest_virtual_time_offset(void)
-{
-   u64 result = VMCALL_SUCCESS;
-   u64 physaddr = 0;
-
-   ISSUE_IO_VMCALL(VMCALL_QUERY_GUEST_VIRTUAL_TIME_OFFSET, physaddr,
-   result);
-   return result;
-}
-
-static inline int issue_vmcall_update_physical_time(u64 adjustment)
-{
-   int result = VMCALL_SUCCESS;
-
-   ISSUE_IO_VMCALL(VMCALL_UPDATE_PHYSICAL_TIME, adjustment, result);
-   return result;
-}
-
 static struct parser_context *
 parser_init_byte_stream(u64 addr, u32 bytes, bool local, bool *retry)
 {
-- 
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: outreachy

[Pavel Machek]

Hi!

> 
> Hah!  That's the joy of being a maintainer of a driver in staging.  Even
> if you filter out outreachy, you are going to get a lot of "basic
> mistakes" and other type patches cc:ed to you.
> 
> I strongly suggest, that if you all don't like this type of stuff,
> either:
>   - work to get the code out of staging as soon as possible (i.e.
> send me coding style fixes for everything right now, and then
> fix up the rest of the stuff.)
>   - take yourself off the maintainer list for this code.
> 
> It's your choice, outreachy right now is a lot of patches, but again,
> it's not going to keep you from getting the "basic" stuff sent to you
> in ways that is totally wrong.

Could we get these trivial patches off the lkml? Yes, lkml already has
a lot of traffic, but no, this is not useful :-(.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

[PATCH 3/6] staging: bcm2835-firmware-gpio: Expand DT options for driver

[Michael Zoran]

This change adds the following optional DT properties:

number-gpios: Number of GPIOs the device should expose
gpio-base: GPIO base that is registered with the kernel
firmware-gpio-base: GPIO bases as viewed by the firmware

The purpose of these DT nodes is to make the driver more
general.

Signed-off-by: Michael Zoran 
---
 .../bcm2835-firmware-gpio/gpio-bcm-exp.c   | 40 --
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c 
b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
index ba9750107957..f6719c84ed8b 100644
--- a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
+++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
@@ -23,12 +23,15 @@
 #include 
 
 #define MODULE_NAME "brcmexp-gpio"
-#define NUM_GPIO 8
+#define DEFAULT_NUM_GPIO 8
+#define DEFAULT_GPIO_BASE 128
+#define DEFAULT_FIRMWARE_GPIO_BASE 128
 
 struct brcmexp_gpio {
struct gpio_chip gc;
struct device *dev;
struct rpi_firmware *fw;
+   u32 firmware_gpio_base;
 };
 
 struct gpio_set_config {
@@ -58,7 +61,7 @@ static int brcmexp_gpio_get_polarity(struct gpio_chip *gc, 
unsigned int off)
 
gpio = container_of(gc, struct brcmexp_gpio, gc);
 
-   get.gpio = off + gpio->gc.base; /* GPIO to update */
+   get.gpio = off + gpio->firmware_gpio_base;
 
ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
, sizeof(get));
@@ -78,7 +81,7 @@ static int brcmexp_gpio_dir_in(struct gpio_chip *gc, unsigned 
int off)
 
gpio = container_of(gc, struct brcmexp_gpio, gc);
 
-   set_in.gpio = off + gpio->gc.base;  /* GPIO to update */
+   set_in.gpio = off + gpio->firmware_gpio_base;
set_in.direction = 0;   /* Input */
set_in.polarity = brcmexp_gpio_get_polarity(gc, off);
/* Retain existing setting */
@@ -105,7 +108,7 @@ static int brcmexp_gpio_dir_out(struct gpio_chip *gc, 
unsigned int off, int val)
 
gpio = container_of(gc, struct brcmexp_gpio, gc);
 
-   set_out.gpio = off + gpio->gc.base; /* GPIO to update */
+   set_out.gpio = off + gpio->firmware_gpio_base;
set_out.direction = 1;  /* Output */
set_out.polarity = brcmexp_gpio_get_polarity(gc, off);
/* Retain existing setting */
@@ -131,7 +134,7 @@ static int brcmexp_gpio_get_direction(struct gpio_chip *gc, 
unsigned int off)
 
gpio = container_of(gc, struct brcmexp_gpio, gc);
 
-   get.gpio = off + gpio->gc.base; /* GPIO to update */
+   get.gpio = off + gpio->firmware_gpio_base;
 
ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
, sizeof(get));
@@ -151,7 +154,7 @@ static int brcmexp_gpio_get(struct gpio_chip *gc, unsigned 
int off)
 
gpio = container_of(gc, struct brcmexp_gpio, gc);
 
-   get.gpio = off + gpio->gc.base; /* GPIO to update */
+   get.gpio = off + gpio->firmware_gpio_base;
get.state = 0;  /* storage for returned value */
 
ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_STATE,
@@ -172,9 +175,7 @@ static void brcmexp_gpio_set(struct gpio_chip *gc, unsigned 
int off, int val)
 
gpio = container_of(gc, struct brcmexp_gpio, gc);
 
-   off += gpio->gc.base;
-
-   set.gpio = off + gpio->gc.base; /* GPIO to update */
+   set.gpio = off + gpio->firmware_gpio_base;
set.state = val;/* Output state */
 
ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_STATE,
@@ -212,8 +213,8 @@ static int brcmexp_gpio_probe(struct platform_device *pdev)
ucb->gc.label = MODULE_NAME;
ucb->gc.owner = THIS_MODULE;
ucb->gc.of_node = np;
-   ucb->gc.base = 128;
-   ucb->gc.ngpio = NUM_GPIO;
+   ucb->gc.base = DEFAULT_GPIO_BASE;
+   ucb->gc.ngpio = DEFAULT_NUM_GPIO;
 
ucb->gc.direction_input = brcmexp_gpio_dir_in;
ucb->gc.direction_output = brcmexp_gpio_dir_out;
@@ -222,6 +223,23 @@ static int brcmexp_gpio_probe(struct platform_device *pdev)
ucb->gc.set = brcmexp_gpio_set;
ucb->gc.can_sleep = true;
 
+   ucb->firmware_gpio_base = DEFAULT_FIRMWARE_GPIO_BASE;
+
+   err = of_property_read_u16(dev->of_node, "number-gpios",
+  >gc.ngpio);
+   if (err)
+   dev_dbg(dev, "Failed to get DT property number-gpio");
+
+   err = of_property_read_u32(dev->of_node, "gpio-base",
+  >gc.base);
+   if (err)
+   dev_dbg(dev, "Failed to get DT property gpio-base");
+
+   err = of_property_read_u32(dev->of_node, "firmware-gpio-base",
+  >firmware_gpio_base);
+   if (err)
+   dev_dbg(dev, 

[PATCH 5/6] staging: bcm2835-firmware-gpio: Add a build system for the driver

[Michael Zoran]

This change adds the driver to the standard kernel build system.

Signed-off-by: Michael Zoran 
---
 drivers/staging/vc04_services/Kconfig| 2 ++
 drivers/staging/vc04_services/Makefile   | 1 +
 drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig  | 6 ++
 drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile | 5 +
 4 files changed, 14 insertions(+)
 create mode 100644 drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
 create mode 100644 drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile

diff --git a/drivers/staging/vc04_services/Kconfig 
b/drivers/staging/vc04_services/Kconfig
index b9f316603308..aebb622cff4a 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -34,5 +34,7 @@ source "drivers/staging/vc04_services/bcm2835-audio/Kconfig"
 
 source "drivers/staging/vc04_services/bcm2835-camera/Kconfig"
 
+source "drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig"
+
 endif
 
diff --git a/drivers/staging/vc04_services/Makefile 
b/drivers/staging/vc04_services/Makefile
index e9a8e1343cbb..54c75b732094 100644
--- a/drivers/staging/vc04_services/Makefile
+++ b/drivers/staging/vc04_services/Makefile
@@ -12,6 +12,7 @@ vchiq-objs := \
 
 obj-$(CONFIG_SND_BCM2835)  += bcm2835-audio/
 obj-$(CONFIG_VIDEO_BCM2835)+= bcm2835-camera/
+obj-$(CONFIG_FIRMWARE_GPIO_BCM2835) += bcm2835-firmware-gpio/
 
 ccflags-y += -DVCOS_VERIFY_BKPTS=1 -Idrivers/staging/vc04_services 
-DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400
 
diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig 
b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
new file mode 100644
index ..1c8cb579fad9
--- /dev/null
+++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
@@ -0,0 +1,6 @@
+config FIRMWARE_GPIO_BCM2835
+   tristate "BCM2835 Firmware GPIO"
+   depends on OF_GPIO && (ARCH_BCM2835 || COMPILE_TEST)
+   help
+ Turn on GPIO support for Broadcom chips using the firmware mailbox
+ to communicate with VideoCore on BCM283x chips.
diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile 
b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile
new file mode 100644
index ..afa642ab26f4
--- /dev/null
+++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_FIRMWARE_GPIO_BCM2835)+= gpio-bcm-exp.o
+
+
+
+
-- 
2.11.0

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

[PATCH 6/6] staging: vc04_services: Update makefile to use CONFIG_BCM_VIDEOCORE

[Michael Zoran]

The toplevel config for vc04_services is CONFIG_BCM2835_VCHIQ.

Since other drivers are being added that don't use vchiq,
change the toplevel Makefile to use CONFIG_BCM_VIDEOCORE.

Signed-off-by: Michael Zoran 
---
 drivers/staging/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 3671dc59579e..f5760ca7a8cf 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -39,5 +39,5 @@ obj-$(CONFIG_WILC1000)+= wilc1000/
 obj-$(CONFIG_MOST) += most/
 obj-$(CONFIG_KS7010)   += ks7010/
 obj-$(CONFIG_GREYBUS)  += greybus/
-obj-$(CONFIG_BCM2835_VCHIQ)+= vc04_services/
+obj-$(CONFIG_BCM_VIDEOCORE)+= vc04_services/
 
-- 
2.11.0

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

[PATCH 4/6] staging: bcm2835-firmware-gpio: Add brcm, bcm2835-firmware-gpio to compatible list

[Michael Zoran]

Since this driver is really a generalized mechanism for doing GPIO
through the firmware, add a new compatible id for
brcm,bcm2835-firmware-gpio.

Signed-off-by: Michael Zoran 
---
 drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c 
b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
index f6719c84ed8b..ce21f669ea35 100644
--- a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
+++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
@@ -259,6 +259,7 @@ static int brcmexp_gpio_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id __maybe_unused brcmexp_gpio_ids[] = {
+   { .compatible = "brcm,bcm2835-firmware-gpio" },
{ .compatible = "brcm,bcm2835-expgpio" },
{ }
 };
-- 
2.11.0

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

[PATCH 2/6] staging: bcm2835-firmware-gpio: Add needed mailbox defines to driver

[Michael Zoran]

The original change this driver is based on adds the needed mailbox
defines to include/soc/bcm2835/raspberrypi-firmware.h. That is not
appropriate at this time, so add the defines directly into the
driver source.

This change is based on:
https://github.com/raspberrypi/linux

Branch: rpi-4.11.y(commit efad03c3c86642dafccc03fcdd3ab84dd11e2ab7)

Signed-off-by: Michael Zoran 
---
 drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c 
b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
index 681a91492d4c..ba9750107957 100644
--- a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
+++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
@@ -43,6 +43,13 @@ struct gpio_get_set_state {
u32 gpio, state;
 };
 
+enum rpi_firmware_gpio_property_tag {
+   RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
+   RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
+   RPI_FIRMWARE_GET_GPIO_CONFIG =0x00030043,
+   RPI_FIRMWARE_SET_GPIO_CONFIG =0x00038043,
+};
+
 static int brcmexp_gpio_get_polarity(struct gpio_chip *gc, unsigned int off)
 {
struct brcmexp_gpio *gpio;
-- 
2.11.0

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

[PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

[Michael Zoran]

From: Dave Stevenson 

Pi3 and Compute Module 3 have a GPIO expander that the
VPU communicates with.
There is a mailbox service that now allows control of this
expander, so add a kernel driver that can make use of it.

Pwr_led node added to device-tree for Pi3.

Signed-off-by: Dave Stevenson 

Stripped off changes to Makefile and Kconfig
Also stripped off changes to raspberrypi-firmware.h
Moved to drivers/staging/vc04_services/bcm2835-firmware-gpio

Signed-off-by: Michael Zoran 
---
 .../bcm2835-firmware-gpio/gpio-bcm-exp.c   | 256 +
 1 file changed, 256 insertions(+)
 create mode 100644 
drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c

diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c 
b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
new file mode 100644
index ..681a91492d4c
--- /dev/null
+++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
@@ -0,0 +1,256 @@
+/*
+ *  Broadcom expander GPIO driver
+ *
+ *  Uses the firmware mailbox service to communicate with the
+ *  GPIO expander on the VPU.
+ *
+ *  Copyright (C) 2017 Raspberry Pi Trading Ltd.
+ *
+ *  Author: Dave Stevenson 
+ *  Based on gpio-bcm-virt.c by Dom Cobley 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MODULE_NAME "brcmexp-gpio"
+#define NUM_GPIO 8
+
+struct brcmexp_gpio {
+   struct gpio_chip gc;
+   struct device *dev;
+   struct rpi_firmware *fw;
+};
+
+struct gpio_set_config {
+   u32 gpio, direction, polarity, term_en, term_pull_up, state;
+};
+
+struct gpio_get_config {
+   u32 gpio, direction, polarity, term_en, term_pull_up;
+};
+
+struct gpio_get_set_state {
+   u32 gpio, state;
+};
+
+static int brcmexp_gpio_get_polarity(struct gpio_chip *gc, unsigned int off)
+{
+   struct brcmexp_gpio *gpio;
+   struct gpio_get_config get;
+   int ret;
+
+   gpio = container_of(gc, struct brcmexp_gpio, gc);
+
+   get.gpio = off + gpio->gc.base; /* GPIO to update */
+
+   ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
+   , sizeof(get));
+   if (ret) {
+   dev_err(gpio->dev,
+   "Failed to get GPIO %u config (%d)\n", off, ret);
+   return ret;
+   }
+   return get.polarity;
+}
+
+static int brcmexp_gpio_dir_in(struct gpio_chip *gc, unsigned int off)
+{
+   struct brcmexp_gpio *gpio;
+   struct gpio_set_config set_in;
+   int ret;
+
+   gpio = container_of(gc, struct brcmexp_gpio, gc);
+
+   set_in.gpio = off + gpio->gc.base;  /* GPIO to update */
+   set_in.direction = 0;   /* Input */
+   set_in.polarity = brcmexp_gpio_get_polarity(gc, off);
+   /* Retain existing setting */
+   set_in.term_en = 0; /* termination disabled */
+   set_in.term_pull_up = 0;/* n/a as termination disabled */
+   set_in.state = 0;   /* n/a as configured as an input */
+
+   ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_CONFIG,
+   _in, sizeof(set_in));
+   if (ret) {
+   dev_err(gpio->dev,
+   "Failed to set GPIO %u to input (%d)\n",
+   off, ret);
+   return ret;
+   }
+   return 0;
+}
+
+static int brcmexp_gpio_dir_out(struct gpio_chip *gc, unsigned int off, int 
val)
+{
+   struct brcmexp_gpio *gpio;
+   struct gpio_set_config set_out;
+   int ret;
+
+   gpio = container_of(gc, struct brcmexp_gpio, gc);
+
+   set_out.gpio = off + gpio->gc.base; /* GPIO to update */
+   set_out.direction = 1;  /* Output */
+   set_out.polarity = brcmexp_gpio_get_polarity(gc, off);
+   /* Retain existing setting */
+   set_out.term_en = 0;/* n/a as an output */
+   set_out.term_pull_up = 0;   /* n/a as termination disabled */
+   set_out.state = val;/* Output state */
+
+   ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_CONFIG,
+   _out, sizeof(set_out));
+   if (ret) {
+   dev_err(gpio->dev,
+   "Failed to set GPIO %u to output (%d)\n", off, ret);
+   return ret;
+   }
+   return 0;
+}
+
+static int brcmexp_gpio_get_direction(struct gpio_chip *gc, unsigned int off)
+{
+   struct brcmexp_gpio *gpio;
+   

[PATCH 0/6] staging: bcm2835-firmware-gpio: Initial staging commit

[Michael Zoran]

The firmware now has a mailbox API for performing generalized gpio through
the firmware.  This driver builds upon a driver written by Dave Stevenson
that was written specifically for the expander on the RPI 3, but I have 
generalized for generic GPIO through the firmware.

With this change I was able to test VC4 on a RPI 3 running in arm64 with
a pure mainline tree from the staging branch.   

The firmware gpio numbers are currently documented at:
https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts

My test dts for arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts:

/dts-v1/;
#include "bcm2837.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"

/ {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
model = "Raspberry Pi 3 Model B";

memory {
reg = <0 0x4000>;
};

leds {
act {
gpios = < 47 0>;
};
};

soc {
firmwaregpio: firmwaregpio {
compatible = "brcm,bcm2835-firmware-gpio";
number-gpios = <256>;
gpio-base = <128>;
firmware-gpio-base = <0>;
gpio-controller;
#gpio-cells = <2>;
firmware = <>;
};

hdmi {
hpd-gpios = < 132 GPIO_ACTIVE_LOW>;
};


};

};

 {
status = "okay";
};

Dave Stevenson (1):
  bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

Michael Zoran (5):
  staging: bcm2835-firmware-gpio: Add needed mailbox defines to driver
  staging: bcm2835-firmware-gpio: Expand DT options for driver
  staging: bcm2835-firmware-gpio: Add brcm,bcm2835-firmware-gpio to
compatible list
  staging: bcm2835-firmware-gpio: Add a build system for the driver
  staging: vc04_services: Update makefile to use CONFIG_BCM_VIDEOCORE

 drivers/staging/Makefile   |   2 +-
 drivers/staging/vc04_services/Kconfig  |   2 +
 drivers/staging/vc04_services/Makefile |   1 +
 .../vc04_services/bcm2835-firmware-gpio/Kconfig|   6 +
 .../vc04_services/bcm2835-firmware-gpio/Makefile   |   5 +
 .../bcm2835-firmware-gpio/gpio-bcm-exp.c   | 282 +
 6 files changed, 297 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
 create mode 100644 drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile
 create mode 100644 
drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c

-- 
2.11.0

___
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: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

[Tom Lendacky]

On 3/17/2017 9:32 AM, Tom Lendacky wrote:

On 3/16/2017 3:04 PM, Tom Lendacky wrote:

On 3/7/2017 8:59 AM, Borislav Petkov wrote:

On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote:

From: Tom Lendacky 

In order for memory pages to be properly mapped when SEV is active, we
need to use the PAGE_KERNEL protection attribute as the base
protection.
This will insure that memory mapping of, e.g. ACPI tables, receives the
proper mapping attributes.

Signed-off-by: Tom Lendacky 
---



diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index c400ab5..481c999 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -151,7 +151,15 @@ static void __iomem
*__ioremap_caller(resource_size_t phys_addr,
pcm = new_pcm;
}

+   /*
+* If the page being mapped is in memory and SEV is active then
+* make sure the memory encryption attribute is enabled in the
+* resulting mapping.
+*/
prot = PAGE_KERNEL_IO;
+   if (sev_active() && page_is_mem(pfn))


Hmm, a resource tree walk per ioremap call. This could get expensive for
ioremap-heavy workloads.

__ioremap_caller() gets called here during boot 55 times so not a whole
lot but I wouldn't be surprised if there were some nasty use cases which
ioremap a lot.

...


diff --git a/kernel/resource.c b/kernel/resource.c
index 9b5f044..db56ba3 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -518,6 +518,46 @@ int __weak page_is_ram(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(page_is_ram);

+/*
+ * This function returns true if the target memory is marked as
+ * IORESOURCE_MEM and IORESOUCE_BUSY and described as other than
+ * IORES_DESC_NONE (e.g. IORES_DESC_ACPI_TABLES).
+ */
+static int walk_mem_range(unsigned long start_pfn, unsigned long
nr_pages)
+{
+struct resource res;
+unsigned long pfn, end_pfn;
+u64 orig_end;
+int ret = -1;
+
+res.start = (u64) start_pfn << PAGE_SHIFT;
+res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
+res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+orig_end = res.end;
+while ((res.start < res.end) &&
+(find_next_iomem_res(, IORES_DESC_NONE, true) >= 0)) {
+pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
+end_pfn = (res.end + 1) >> PAGE_SHIFT;
+if (end_pfn > pfn)
+ret = (res.desc != IORES_DESC_NONE) ? 1 : 0;
+if (ret)
+break;
+res.start = res.end + 1;
+res.end = orig_end;
+}
+return ret;
+}


So the relevant difference between this one and walk_system_ram_range()
is this:

-ret = (*func)(pfn, end_pfn - pfn, arg);
+ret = (res.desc != IORES_DESC_NONE) ? 1 : 0;

so it seems to me you can have your own *func() pointer which does that
IORES_DESC_NONE comparison. And then you can define your own workhorse
__walk_memory_range() which gets called by both walk_mem_range() and
walk_system_ram_range() instead of almost duplicating them.

And looking at walk_system_ram_res(), that one looks similar too except
the pfn computation. But AFAICT the pfn/end_pfn things are computed from
res.start and res.end so it looks to me like all those three functions
are crying for unification...


I'll take a look at what it takes to consolidate these with a pre-patch.
Then I'll add the new support.


It looks pretty straight forward to combine walk_iomem_res_desc() and
walk_system_ram_res(). The walk_system_ram_range() function would fit
easily into this, also, except for the fact that the callback function
takes unsigned longs vs the u64s of the other functions.  Is it worth
modifying all of the callers of walk_system_ram_range() (which are only
about 8 locations) to change the callback functions to accept u64s in
order to consolidate the walk_system_ram_range() function, too?


The more I dig, the more I find that the changes keep expanding. I'll
leave walk_system_ram_range() out of the consolidation for now.

Thanks,
Tom



Thanks,
Tom



Thanks,
Tom




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

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

[Paolo Bonzini]

On 17/03/2017 12:33, Borislav Petkov wrote:
> On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote:
> 
>> If it is possible to do it in a fairly hypervisor-independent manner,
>> I'm all for it.  That is, only by looking at AMD-specified CPUID leaves
>> and at kernel ELF sections.
> 
> Not even that.
> 
> What that needs to be able to do is:
> 
>   kvm_map_percpu_hv_shared(st, sizeof(*st)))
> 
> where st is the percpu steal time ptr:
> 
>   struct kvm_steal_time *st = _cpu(steal_time, cpu);
> 
> Underneath, what it does basically is it clears the encryption mask from
> the pte, see patch 16/32.

Yes, and I'd like that to be done with a new data section rather than a
special KVM hook.

> And I keep talking about SEV-ES because this is going to expand on the
> need of having a shared memory region which the hypervisor and the guest
> needs to access, thus unencrypted. See
> 
> http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf
> 
> This is where you come in and say what would be the best approach there...

I have no idea.  SEV-ES seems to be very hard to set up at the beginning
of the kernel bootstrap.  There's all sorts of chicken and egg problems,
as well as complicated handshakes between the firmware and the guest,
and the way to do it also depends on the trust and threat models.

A much simpler way is to just boot under a trusted hypervisor, do
"modprobe sev-es" and save a snapshot of the guest.  Then you sign the
snapshot and pass it to your cloud provider.

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

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Fri, Mar 17, 2017 at 02:51:10PM +0100, Philipp Zabel wrote:
> On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
> [...]
> > The big question, waiting for an answer on the last 8 years is
> > who would do that? Such person would need to have several different
> > hardware from different vendors, in order to ensure that it has
> > a generic solution.
> > 
> > It is a way more feasible that the Kernel developers that already 
> > have a certain hardware on their hands to add support inside the
> > driver to forward the controls through the pipeline and to setup
> > a "default" pipeline that would cover the common use cases at
> > driver's probe.
> 
> Actually, would setting pipeline via libv4l2 plugin and letting drivers
> provide a sane enabled default pipeline configuration be mutually
> exclusive? Not sure about the control forwarding, but at least a simple
> link setup and format forwarding would also be possible in the kernel
> without hindering userspace from doing it themselves later.

I think this is the exact same problem as controls in ALSA.

When ALSA started off in life, the requirement was that all controls
shall default to minimum, and the user is expected to adjust controls
after the system is running.

After OSS, this gave quite a marked change in system behaviour, and
led to a lot of "why doesn't my sound work anymore" problems, because
people then had to figure out which combination of controls had to be
set to get sound out of their systems.

Now it seems to be much better, where install Linux on a platform, and
you have a working sound system (assuming that the drivers are all there
which is generally the case for x86.)

However, it's still possible to adjust all the controls from userspace.
All that's changed is the defaults.

Why am I mentioning this - because from what I understand Mauro saying,
it's no different from this situation.  Userspace will still have the
power to disable all links and setup its own.  The difference is that
there will be a default configuration that the kernel sets up at boot
time that will be functional, rather than the current default
configuration where the system is completely non-functional until
manually configured.

However, at the end of the day, I don't care _where_ the usability
problems are solved, only that there is some kind of solution.  It's not
the _where_ that's the real issue here, but the _how_, and discussion of
the _how_ is completely missing.

So, let's try kicking off a discussion about _how_ to do things.

_How_ do we setup a media controller system so that we end up with a
usable configuration - let's start with the obvious bit... which links
should be enabled.

I think the first pre-requisit is that we stop exposing capture devices
that can never be functional for the hardware that's present on the board,
so that there isn't this plentora of useless /dev/video* nodes and useless
subdevices.

One possible solution to finding a default path may be "find the shortest
path between the capture device and the sensor and enable intervening
links".

Then we need to try configuring that path with format/resolution
information.

However, what if something in the shortest path can't handle the format
that the sensor produces?  I think at that point, we'd need to drop that
subdev out of the path resolution, re-run the "find the shortest path"
algorithm, and try again.

Repeat until success or no path between the capture and sensor exists.

This works fine if you have just one sensor visible from a capture device,
but not if there's more than one (which I suspect is the case with the
Sabrelite board with its two cameras and video receiver.)  That breaks
the "find the shortest path" algorithm.

So, maybe it's a lot better to just let the board people provide via DT
a default setup for the connectivity of the modules somehow - certainly
one big step forward would be to disable in DT parts of the capture
system that can never be used (remembering that boards like the RPi /
Hummingboard may end up using DT overlays to describe this for different
cameras, so the capture setup may change after initial boot.)

-- 
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: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

[Tom Lendacky]

On 3/16/2017 3:04 PM, Tom Lendacky wrote:

On 3/7/2017 8:59 AM, Borislav Petkov wrote:

On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote:

From: Tom Lendacky 

In order for memory pages to be properly mapped when SEV is active, we
need to use the PAGE_KERNEL protection attribute as the base protection.
This will insure that memory mapping of, e.g. ACPI tables, receives the
proper mapping attributes.

Signed-off-by: Tom Lendacky 
---



diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index c400ab5..481c999 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -151,7 +151,15 @@ static void __iomem
*__ioremap_caller(resource_size_t phys_addr,
pcm = new_pcm;
}

+   /*
+* If the page being mapped is in memory and SEV is active then
+* make sure the memory encryption attribute is enabled in the
+* resulting mapping.
+*/
prot = PAGE_KERNEL_IO;
+   if (sev_active() && page_is_mem(pfn))


Hmm, a resource tree walk per ioremap call. This could get expensive for
ioremap-heavy workloads.

__ioremap_caller() gets called here during boot 55 times so not a whole
lot but I wouldn't be surprised if there were some nasty use cases which
ioremap a lot.

...


diff --git a/kernel/resource.c b/kernel/resource.c
index 9b5f044..db56ba3 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -518,6 +518,46 @@ int __weak page_is_ram(unsigned long pfn)
 }
 EXPORT_SYMBOL_GPL(page_is_ram);

+/*
+ * This function returns true if the target memory is marked as
+ * IORESOURCE_MEM and IORESOUCE_BUSY and described as other than
+ * IORES_DESC_NONE (e.g. IORES_DESC_ACPI_TABLES).
+ */
+static int walk_mem_range(unsigned long start_pfn, unsigned long
nr_pages)
+{
+struct resource res;
+unsigned long pfn, end_pfn;
+u64 orig_end;
+int ret = -1;
+
+res.start = (u64) start_pfn << PAGE_SHIFT;
+res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
+res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+orig_end = res.end;
+while ((res.start < res.end) &&
+(find_next_iomem_res(, IORES_DESC_NONE, true) >= 0)) {
+pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
+end_pfn = (res.end + 1) >> PAGE_SHIFT;
+if (end_pfn > pfn)
+ret = (res.desc != IORES_DESC_NONE) ? 1 : 0;
+if (ret)
+break;
+res.start = res.end + 1;
+res.end = orig_end;
+}
+return ret;
+}


So the relevant difference between this one and walk_system_ram_range()
is this:

-ret = (*func)(pfn, end_pfn - pfn, arg);
+ret = (res.desc != IORES_DESC_NONE) ? 1 : 0;

so it seems to me you can have your own *func() pointer which does that
IORES_DESC_NONE comparison. And then you can define your own workhorse
__walk_memory_range() which gets called by both walk_mem_range() and
walk_system_ram_range() instead of almost duplicating them.

And looking at walk_system_ram_res(), that one looks similar too except
the pfn computation. But AFAICT the pfn/end_pfn things are computed from
res.start and res.end so it looks to me like all those three functions
are crying for unification...


I'll take a look at what it takes to consolidate these with a pre-patch.
Then I'll add the new support.


It looks pretty straight forward to combine walk_iomem_res_desc() and
walk_system_ram_res(). The walk_system_ram_range() function would fit
easily into this, also, except for the fact that the callback function
takes unsigned longs vs the u64s of the other functions.  Is it worth
modifying all of the callers of walk_system_ram_range() (which are only
about 8 locations) to change the callback functions to accept u64s in
order to consolidate the walk_system_ram_range() function, too?

Thanks,
Tom



Thanks,
Tom




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

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Philipp Zabel]

On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
[...]
> The big question, waiting for an answer on the last 8 years is
> who would do that? Such person would need to have several different
> hardware from different vendors, in order to ensure that it has
> a generic solution.
> 
> It is a way more feasible that the Kernel developers that already 
> have a certain hardware on their hands to add support inside the
> driver to forward the controls through the pipeline and to setup
> a "default" pipeline that would cover the common use cases at
> driver's probe.

Actually, would setting pipeline via libv4l2 plugin and letting drivers
provide a sane enabled default pipeline configuration be mutually
exclusive? Not sure about the control forwarding, but at least a simple
link setup and format forwarding would also be possible in the kernel
without hindering userspace from doing it themselves later.

regards
Philipp

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

Re: [PATCH] Fix style warnings in drivers/staging/most/aim-v4l2

[Dan Carpenter]

Fix the patch prefix.  It should be:

[PATCH v2] Staging: most: use __func__ instead of the function name

On Fri, Mar 17, 2017 at 06:36:18AM -0700, Chandra Annamaneni wrote:
> 
> 
> Enclosed is a patch to the file video.c. It only fixes style warning
> flagged by checkpatch.pl.
> 
> Please let me know if anything else needs to be done.
> 
> Signed-off-by: Chandra Annamaneni on
> 
> Thanks.
> Chandra

This is an email but we want a patch description.  Look at other
messages to the list for how it's done.  Otherwise the patch looks OK.

regards,
dan carpenter


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

[PATCH] Fix style warnings in drivers/staging/most/aim-v4l2

[Chandra Annamaneni]

Enclosed is a patch to the file video.c. It only fixes style warning 
flagged by checkpatch.pl.


Please let me know if anything else needs to be done.

Signed-off-by: Chandra Annamaneni 

Thanks.
Chandra

diff --git a/drivers/staging/most/aim-v4l2/video.c 
b/drivers/staging/most/aim-v4l2/video.c
index e074841..59e861e 100644
--- a/drivers/staging/most/aim-v4l2/video.c
+++ b/drivers/staging/most/aim-v4l2/video.c
@@ -79,7 +79,7 @@ static int aim_vdev_open(struct file *filp)
struct most_video_dev *mdev = video_drvdata(filp);
struct aim_fh *fh;

-   v4l2_info(>v4l2_dev, "aim_vdev_open()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

switch (vdev->vfl_type) {
case VFL_TYPE_GRABBER:
@@ -128,7 +128,7 @@ static int aim_vdev_close(struct file *filp)
struct most_video_dev *mdev = fh->mdev;
struct mbo *mbo, *tmp;

-   v4l2_info(>v4l2_dev, "aim_vdev_close()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

/*
 * We need to put MBOs back before we call most_stop_channel()
@@ -324,7 +324,7 @@ static int vidioc_g_std(struct file *file, void *priv, 
v4l2_std_id *norm)
struct aim_fh *fh = priv;
struct most_video_dev *mdev = fh->mdev;

-   v4l2_info(>v4l2_dev, "vidioc_g_std()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

*norm = V4L2_STD_UNKNOWN;
return 0;
@@ -361,7 +361,7 @@ static int vidioc_s_input(struct file *file, void *priv, 
unsigned int index)
struct aim_fh *fh = priv;
struct most_video_dev *mdev = fh->mdev;

-   v4l2_info(>v4l2_dev, "vidioc_s_input(%d)\n", index);
+   v4l2_info(>v4l2_dev, "%s(%d)\n", __func__, index);

if (index >= V4L2_AIM_MAX_INPUT)
return -EINVAL;
@@ -441,7 +441,7 @@ static int aim_register_videodev(struct most_video_dev 
*mdev)
 {
int ret;

-   v4l2_info(>v4l2_dev, "aim_register_videodev()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

init_waitqueue_head(>wait_data);

@@ -471,7 +471,7 @@ static int aim_register_videodev(struct most_video_dev 
*mdev)

 static void aim_unregister_videodev(struct most_video_dev *mdev)
 {
-   v4l2_info(>v4l2_dev, "aim_unregister_videodev()\n");
+   v4l2_info(>v4l2_dev, "%s()\n", __func__);

video_unregister_device(mdev->vdev);
 }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Mauro Carvalho Chehab]

Em Fri, 17 Mar 2017 13:55:33 +0200
Sakari Ailus  escreveu:

> Hi Russell,
> 
> On 03/17/17 13:42, Russell King - ARM Linux wrote:
> > On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:  
> >> We're all very driver-development-driven, and userspace gets very little
> >> attention in general. So before just throwing in the towel we should take
> >> a good look at the reasons why there has been little or no development: is
> >> it because of fundamental design defects, or because nobody paid attention
> >> to it?
> >>
> >> I strongly suspect it is the latter.
> >>
> >> In addition, I suspect end-users of these complex devices don't really care
> >> about a plugin: they want full control and won't typically use generic
> >> applications. If they would need support for that, we'd have seen much more
> >> interest. The main reason for having a plugin is to simplify testing and
> >> if this is going to be used on cheap hobbyist devkits.  
> > 
> > I think you're looking at it with a programmers hat on, not a users hat.

I fully agree with you: whatever solution is provided, this should be fully
transparent for the end user, no matter what V4L2 application he's using.

> > 
> > Are you really telling me that requiring users to 'su' to root, and then
> > use media-ctl to manually configure the capture device is what most
> > users "want" ?  

The need of su can easily be fixed with a simple addition at the udev
rules.d, for it to consider media controller as part of the v4l stuff:

--- udev/rules.d/50-udev-default.rules  2017-02-01 19:45:35.0 -0200
+++ udev/rules.d/50-udev-default.rules  2015-08-29 07:54:16.033122614 -0300
@@ -30,6 +30,7 @@ SUBSYSTEM=="mem", KERNEL=="mem|kmem|port
 SUBSYSTEM=="input", GROUP="input"
 SUBSYSTEM=="input", KERNEL=="js[0-9]*", MODE="0664"
 
+SUBSYSTEM=="media", GROUP="video"
 SUBSYSTEM=="video4linux", GROUP="video"
 SUBSYSTEM=="graphics", GROUP="video"
 SUBSYSTEM=="drm", GROUP="video"

Ok, someone should base it on upstream and submit this to
udev maintainers[1].

[1] On a side note, it would also be possible to have an udev rule that
would be automatically setting the pipeline then the media device pops
up.

   I wrote something like that for remote controllers, with gets
   installed together with v4l-utils package: when a remote controller
   is detected, it checks the driver and the remote controller table
   that the driver wants and load it on userspace.

   It would be possible to do something like that for MC, but someone 
   would need to do such task. Of course, that would require to have
   a way for a generic application to detect the board type and be
   able to automatically setup the pipelines. So, we'll go back to
   the initial problem that nobody was able to do that so far.

> It depends on who the user is. I don't think anyone is suggesting a
> regular end user is the user of all these APIs: it is either an
> application tailored for that given device, a skilled user with his test
> scripts 

Test scripts are just test scripts, meant for development purposes.
We shouldn't even consider this seriously.

> Making use of the full potential of the hardware requires using a more
> expressive interface. 

That's the core of the problem: most users don't need "full potential
of the hardware". It is actually worse than that: several boards
don't allow "full potential" of the SoC capabilities.

Ok, when the user requires "full potential", they may need a complex
tailored application. But, on most cases, all it is needed is to
support a simple application that controls a video stream via
/dev/video0.

> That's what the kernel interface must provide. If
> we decide to limit ourselves to a small sub-set of that potential on the
> level of the kernel interface, we have made a wrong decision. It's as
> simple as that. This is why the functionality (and which requires taking
> a lot of policy decisions) belongs to the user space. We cannot have
> multiple drivers providing multiple kernel interfaces for the same hardware.

I strongly disagree. Looking only at the hardware capabilities without
having a solution to provide what the user wants is *wrong*.

The project decisions should be based on the common use cases, and, if
possible and not to expensive/complex, covering exotic cases.

The V4L2 API was designed to fulfill the user needs. Drivers should
take it in consideration when choosing policy decisions.

In order to give you some examples, before the V4L2 API, the bttv driver
used to have its own set of ioctls, meant to provide functionality based
on its hardware capabilities (like selecting other standards like PAL/M).
The end result is that applications written for bttv were not generic
enough[1]. The V4L2 API was designed to be generic enough to cover the
common use-cases.

[1] As the bttv board were very popular, most userspace apps didn't
work on other hardware. The big advantage of V4L2 API is that it

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Fri, Mar 17, 2017 at 01:02:07PM +0100, Philipp Zabel wrote:
> I think most of the simple, fixed pipeline use cases could be handled by
> libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that
> function internally would set up the media links to the
> nearest /dev/video interface, propagate format, resolution and frame
> intervals if necessary, and return an fd to the video device, there'd be
> no additional complexity for the users beyond selecting the v4l2_subdev
> instead of the video device.

... which would then require gstreamer to be modified too. The gstreamer
v4l2 plugin looks for /dev/video* or /dev/v4l2/video* devices and monitors
these for changes, so gstreamer applications know which capture devices
are available:

  const gchar *paths[] = { "/dev", "/dev/v4l2", NULL };
  const gchar *names[] = { "video", NULL };

  /* Add some depedency, so the dynamic features get updated upon changes in
   * /dev/video* */
  gst_plugin_add_dependency (plugin,
  NULL, paths, names, GST_PLUGIN_DEPENDENCY_FLAG_FILE_NAME_IS_PREFIX);

I haven't checked yet whether sys/v4l2/gstv4l2deviceprovider.c knows
anything about the v4l2 subdevs.

-- 
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 v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Philipp Zabel]

On Fri, 2017-03-17 at 11:42 +, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> > We're all very driver-development-driven, and userspace gets very little
> > attention in general. So before just throwing in the towel we should take
> > a good look at the reasons why there has been little or no development: is
> > it because of fundamental design defects, or because nobody paid attention
> > to it?
> > 
> > I strongly suspect it is the latter.
> > 
> > In addition, I suspect end-users of these complex devices don't really care
> > about a plugin: they want full control and won't typically use generic
> > applications. If they would need support for that, we'd have seen much more
> > interest. The main reason for having a plugin is to simplify testing and
> > if this is going to be used on cheap hobbyist devkits.
> 
> I think you're looking at it with a programmers hat on, not a users hat.
> 
> Are you really telling me that requiring users to 'su' to root, and then
> use media-ctl to manually configure the capture device is what most
> users "want" ?
> 
> Hasn't the way technology has moved towards graphical interfaces,
> particularly smart phones, taught us that the vast majority of users
> want is intuitive, easy to use interfaces, and not the command line
> with reams of documentation?
> 
> Why are smart phones soo popular - it's partly because they're flashy,
> but also because of the wealth of apps, and apps which follow the
> philosophy of "do one job, do it well" (otherwise they get bad reviews.)

> > An additional complication is simply that it is hard to find fully supported
> > MC hardware. omap3 boards are hard to find these days, renesas boards are 
> > not
> > easy to get, freescale isn't the most popular either. Allwinner, mediatek,
> > amlogic, broadcom and qualcomm all have closed source implementations or no
> > implementation at all.
> 
> Right, and that in itself tells us something - the problem that we're
> trying to solve is not one that commonly exists in the real world.
> 
> Yes, the hardware we have in front of us may be very complex, but if
> there's very few systems out there which are capable of making use of
> all that complexity, then we're trying to solve a problem that isn't
> the common case - and if it's going to take years to solve it (it
> already has taken years) then it's the wrong problem to be solved.
> 
> I bet most of the problem can be eliminated if, rather than exposing
> all this complexity, we instead expose a simpler capture system where
> the board designer gets to "wire up" the capture system.
> 
> I'll go back to my Bayer example, because that's the simplest.  As
> I've already said many times in these threads, there is only one
> possible path through the iMX6 device that such a source can be used
> with - it's a fixed path.  The actual path depends on the CSI2
> virtual channel that the camera has been _configured_ to use, but
> apart from that, it's effectively a well known set of blocks.  Such
> a configuration could be placed in DT.
> 
> For RGB connected to a single parallel CSI, things get a little more
> complex - capture through the CSI or through two other capture devices
> for de-interlacing or other features.  However, I'm not convinced that
> exposing multiple /dev/video* devices for different features for the
> same video source is a sane approach - I think that's a huge usability
> problem.  (The user is expected to select the capture device on iMX6
> depending on the features they want, and if they want to change features,
> they're expected to shut down their application and start it up on a
> different capture device.)  For the most part on iMX6, there's one
> path down to the CSI block, and then there's optional routing through
> the rest of the IPU depending on what features you want (such as
> de-interlacing.)
>
> The complex case is a CSI2 connected camera which produces multiple
> streams through differing virtual channels - and that's IMHO the only
> case where we need multiple different /dev/video* capture devices to
> be present.

I wanted to have the IC PRP outputs separate because the IC PRP should
support running both the VF and ENC tasks with different parameters from
the same input. That would allow to capture two different resolutions
(up to 1024x1024) at the same time.

I think most of the simple, fixed pipeline use cases could be handled by
libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that
function internally would set up the media links to the
nearest /dev/video interface, propagate format, resolution and frame
intervals if necessary, and return an fd to the video device, there'd be
no additional complexity for the users beyond selecting the v4l2_subdev
instead of the video device.

regards
Philipp

___
devel mailing list
de...@linuxdriverproject.org

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Sakari Ailus]

Hi Russell,

On 03/17/17 13:42, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
>> We're all very driver-development-driven, and userspace gets very little
>> attention in general. So before just throwing in the towel we should take
>> a good look at the reasons why there has been little or no development: is
>> it because of fundamental design defects, or because nobody paid attention
>> to it?
>>
>> I strongly suspect it is the latter.
>>
>> In addition, I suspect end-users of these complex devices don't really care
>> about a plugin: they want full control and won't typically use generic
>> applications. If they would need support for that, we'd have seen much more
>> interest. The main reason for having a plugin is to simplify testing and
>> if this is going to be used on cheap hobbyist devkits.
> 
> I think you're looking at it with a programmers hat on, not a users hat.
> 
> Are you really telling me that requiring users to 'su' to root, and then
> use media-ctl to manually configure the capture device is what most
> users "want" ?

It depends on who the user is. I don't think anyone is suggesting a
regular end user is the user of all these APIs: it is either an
application tailored for that given device, a skilled user with his test
scripts or as suggested previously, a libv4l plugin knowing the device
or a generic library geared towards providing best effort service. The
last one of this list does not exist yet and the second last item
requires help.

Typically this class of devices is simply not up to provide the level of
service you're requesting without additional user space control library
which is responsible for automatic white balance, exposure and focus.

Making use of the full potential of the hardware requires using a more
expressive interface. That's what the kernel interface must provide. If
we decide to limit ourselves to a small sub-set of that potential on the
level of the kernel interface, we have made a wrong decision. It's as
simple as that. This is why the functionality (and which requires taking
a lot of policy decisions) belongs to the user space. We cannot have
multiple drivers providing multiple kernel interfaces for the same hardware.

That said, I'm not trying to provide an excuse for not having libraries
available to help the user to configure and control the device more or
less automatically even in terms of best effort. It's something that
does require attention, a lot more of it than it has received in recent
few years.

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> We're all very driver-development-driven, and userspace gets very little
> attention in general. So before just throwing in the towel we should take
> a good look at the reasons why there has been little or no development: is
> it because of fundamental design defects, or because nobody paid attention
> to it?
> 
> I strongly suspect it is the latter.
> 
> In addition, I suspect end-users of these complex devices don't really care
> about a plugin: they want full control and won't typically use generic
> applications. If they would need support for that, we'd have seen much more
> interest. The main reason for having a plugin is to simplify testing and
> if this is going to be used on cheap hobbyist devkits.

I think you're looking at it with a programmers hat on, not a users hat.

Are you really telling me that requiring users to 'su' to root, and then
use media-ctl to manually configure the capture device is what most
users "want" ?

Hasn't the way technology has moved towards graphical interfaces,
particularly smart phones, taught us that the vast majority of users
want is intuitive, easy to use interfaces, and not the command line
with reams of documentation?

Why are smart phones soo popular - it's partly because they're flashy,
but also because of the wealth of apps, and apps which follow the
philosophy of "do one job, do it well" (otherwise they get bad reviews.)

> An additional complication is simply that it is hard to find fully supported
> MC hardware. omap3 boards are hard to find these days, renesas boards are not
> easy to get, freescale isn't the most popular either. Allwinner, mediatek,
> amlogic, broadcom and qualcomm all have closed source implementations or no
> implementation at all.

Right, and that in itself tells us something - the problem that we're
trying to solve is not one that commonly exists in the real world.

Yes, the hardware we have in front of us may be very complex, but if
there's very few systems out there which are capable of making use of
all that complexity, then we're trying to solve a problem that isn't
the common case - and if it's going to take years to solve it (it
already has taken years) then it's the wrong problem to be solved.

I bet most of the problem can be eliminated if, rather than exposing
all this complexity, we instead expose a simpler capture system where
the board designer gets to "wire up" the capture system.

I'll go back to my Bayer example, because that's the simplest.  As
I've already said many times in these threads, there is only one
possible path through the iMX6 device that such a source can be used
with - it's a fixed path.  The actual path depends on the CSI2
virtual channel that the camera has been _configured_ to use, but
apart from that, it's effectively a well known set of blocks.  Such
a configuration could be placed in DT.

For RGB connected to a single parallel CSI, things get a little more
complex - capture through the CSI or through two other capture devices
for de-interlacing or other features.  However, I'm not convinced that
exposing multiple /dev/video* devices for different features for the
same video source is a sane approach - I think that's a huge usability
problem.  (The user is expected to select the capture device on iMX6
depending on the features they want, and if they want to change features,
they're expected to shut down their application and start it up on a
different capture device.)  For the most part on iMX6, there's one
path down to the CSI block, and then there's optional routing through
the rest of the IPU depending on what features you want (such as
de-interlacing.)

The complex case is a CSI2 connected camera which produces multiple
streams through differing virtual channels - and that's IMHO the only
case where we need multiple different /dev/video* capture devices to
be present.

-- 
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