RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

[Dexuan Cui]

> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, May 19, 2016 12:13
> To: Dexuan Cui 
> Cc: KY Srinivasan ; o...@aepfle.de;
> gre...@linuxfoundation.org; jasow...@redhat.com; linux-
> ker...@vger.kernel.org; j...@perches.com; net...@vger.kernel.org;
> a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang
> 
> Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
> 
> 
> I'm travelling and very busy with the merge window.  So sorry I won't be able
> to think about this for some time.

David, 
Sure, I understand.

Please let me recap my last mail:

1)  I'll replace my statically-allocated per-connection "send/recv bufs" with
dynamically ones, so no buf is used when there is no traffic.

2) Another kind of bufs i.e., the  multi-page "VMBus send/recv ringbuffer", is
a must IMO due to the host side's design of the feature: every connection needs
its own ringbuffer, which takes several pages (2~3 pages at least. And, 5 pages
should suffice for good performance). The ringbuffer can be accessed by the
host at any time, so IMO the pages can't be swappable.

I understand net-next is closed now. I'm going to post the next version
after 4.7-rc1 is out in several weeks.

If you could give me some suggestions, I would be definitely happy to take.

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

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

[David Miller]

I'm travelling and very busy with the merge window.  So sorry I won't be able
to think about this for some time.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] ION: Sys_heap: Add cached pool to spead up cached buffer alloc

[Chen Feng]

Add ion cached pool in system heap. This patch add a cached pool
in system heap. It has a great improvement of alloc for cached
buffer.

With memory pressue alloc test 800MB in userspace used iontest.
The result avg is 577ms. Without patch it's avg is about 883ms.

v1: Makes the cached buffer zeroed before going to pool
v2: Add cached param in pool to distinguish wheather need to flush
cache at a fresh alloc.
Rework the shrink function.

Signed-off-by: Chen Feng 
Signed-off-by: Xia  Qing 
Reviewed-by: Fu Jun 
---
 drivers/staging/android/ion/ion_page_pool.c   |  10 +-
 drivers/staging/android/ion/ion_priv.h|   5 +-
 drivers/staging/android/ion/ion_system_heap.c | 183 +-
 3 files changed, 133 insertions(+), 65 deletions(-)

diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c
index 1fe8016..2c5e5c5 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -30,8 +30,9 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool 
*pool)
 
if (!page)
return NULL;
-   ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
-   DMA_BIDIRECTIONAL);
+   if (!pool->cached)
+   ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
+ DMA_BIDIRECTIONAL);
return page;
 }
 
@@ -147,7 +148,8 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t 
gfp_mask,
return freed;
 }
 
-struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order)
+struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order,
+  bool cached)
 {
struct ion_page_pool *pool = kmalloc(sizeof(*pool), GFP_KERNEL);
 
@@ -161,6 +163,8 @@ struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, 
unsigned int order)
pool->order = order;
mutex_init(>mutex);
plist_node_init(>list, order);
+   if (cached)
+   pool->cached = true;
 
return pool;
 }
diff --git a/drivers/staging/android/ion/ion_priv.h 
b/drivers/staging/android/ion/ion_priv.h
index 0239883..f3cb8b4 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -360,6 +360,7 @@ void ion_carveout_free(struct ion_heap *heap, 
ion_phys_addr_t addr,
  * @gfp_mask:  gfp_mask to use from alloc
  * @order: order of pages in the pool
  * @list:  plist node for list of pools
+ * @cached:it's cached pool or not
  *
  * Allows you to keep a pool of pre allocated pages to use from your heap.
  * Keeping a pool of pages that is ready for dma, ie any cached mapping have
@@ -369,6 +370,7 @@ void ion_carveout_free(struct ion_heap *heap, 
ion_phys_addr_t addr,
 struct ion_page_pool {
int high_count;
int low_count;
+   bool cached;
struct list_head high_items;
struct list_head low_items;
struct mutex mutex;
@@ -377,7 +379,8 @@ struct ion_page_pool {
struct plist_node list;
 };
 
-struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order);
+struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order,
+  bool cached);
 void ion_page_pool_destroy(struct ion_page_pool *);
 struct page *ion_page_pool_alloc(struct ion_page_pool *);
 void ion_page_pool_free(struct ion_page_pool *, struct page *);
diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index b69dfc7..32a0ebf 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -26,16 +26,18 @@
 #include "ion.h"
 #include "ion_priv.h"
 
+#define NUM_ORDERS ARRAY_SIZE(orders)
+
 static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN |
 __GFP_NORETRY) & ~__GFP_RECLAIM;
 static gfp_t low_order_gfp_flags  = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
 static const unsigned int orders[] = {8, 4, 0};
-static const int num_orders = ARRAY_SIZE(orders);
+
 static int order_to_index(unsigned int order)
 {
int i;
 
-   for (i = 0; i < num_orders; i++)
+   for (i = 0; i < NUM_ORDERS; i++)
if (order == orders[i])
return i;
BUG();
@@ -49,47 +51,55 @@ static inline unsigned int order_to_size(int order)
 
 struct ion_system_heap {
struct ion_heap heap;
-   struct ion_page_pool *pools[0];
+   struct ion_page_pool *uncached_pools[NUM_ORDERS];
+   struct ion_page_pool *cached_pools[NUM_ORDERS];
 };
 
+/**
+ * The page from page-pool are all zeroed before. We need do cache
+ * clean for cached buffer. The uncached buffer 

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

[gre...@linuxfoundation.org]

On Thu, May 19, 2016 at 12:59:09AM +, Dexuan Cui wrote:
> > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On 
> > Behalf
> > Of Dexuan Cui
> > Sent: Tuesday, May 17, 2016 10:46
> > To: David Miller 
> > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com;
> > linux-ker...@vger.kernel.org; j...@perches.com; net...@vger.kernel.org;
> > a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang
> > 
> > Subject: RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
> > 
> > > From: David Miller [mailto:da...@davemloft.net]
> > > Sent: Monday, May 16, 2016 1:16
> > > To: Dexuan Cui 
> > > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > > a...@canonical.com; jasow...@redhat.com; cav...@redhat.com; KY
> > > Srinivasan ; Haiyang Zhang ;
> > > j...@perches.com; vkuzn...@redhat.com
> > > Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM 
> > > Sockets(hv_sock)
> > >
> > > From: Dexuan Cui 
> > > Date: Sun, 15 May 2016 09:52:42 -0700
> > >
> > > > Changes since v10
> > > >
> > > > 1) add module params: send_ring_page, recv_ring_page. They can be used
> > to
> > > > enlarge the ringbuffer size to get better performance, e.g.,
> > > > # modprobe hv_sock  recv_ring_page=16 send_ring_page=16
> > > > By default, recv_ring_page is 3 and send_ring_page is 2.
> > > >
> > > > 2) add module param max_socket_number (the default is 1024).
> > > > A user can enlarge the number to create more than 1024 hv_sock sockets.
> > > > By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes.
> > > > (Here 1+1 means 1 page for send/recv buffers per connection, 
> > > > respectively.)
> > >
> > > This is papering around my objections, and create module parameters which
> > > I am fundamentally against.
> > >
> > > You're making the facility unusable by default, just to work around my
> > > memory consumption concerns.
> > >
> > > What will end up happening is that everyone will simply increase the
> > > values.
> > >
> > > You're not really addressing the core issue, and I will be ignoring you
> > > future submissions of this change until you do.
> > 
> > David,
> > I am sorry I came across as ignoring your feedback; that was not my 
> > intention.
> > The current host side design for this feature is such that each socket 
> > connection
> > needs its own channel, which consists of
> > 
> > 1.A ring buffer for host to guest communication
> > 2.A ring buffer for guest to host communication
> > 
> > The memory for the ring buffers has to be pinned down as this will be 
> > accessed
> > both from interrupt level in Linux guest and from the host OS at any time.
> > 
> > To address your concerns, I am planning to re-implement both the receive 
> > path
> > and the send path so that no additional pinned memory will be needed.
> > 
> > Receive Path:
> > When the application does a read on the socket, we will dynamically allocate
> > the buffer and perform the read operation on the incoming ring buffer. Since
> > we will be in the process context, we can sleep here and will set the
> > "GFP_KERNEL | __GFP_NOFAIL" flags. This buffer will be freed once the
> > application consumes all the data.
> > 
> > Send Path:
> > On the send side, we will construct the payload to be sent directly on the
> > outgoing ringbuffer.
> > 
> > So, with these changes, the only memory that will be pinned down will be the
> > memory for the ring buffers on a per-connection basis and this memory will 
> > be
> > pinned down until the connection is torn down.
> > 
> > Please let me know if this addresses your concerns.
> > 
> > -- Dexuan
> 
> Hi David,
> Ping. Really appreciate your comment.

Don't wait for people to respond to random design questions, go work on
the code and figure out if it is workable or not yourself.  Then post
patches.  We aren't responsible for your work, you are.

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

RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

[Dexuan Cui]

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of Dexuan Cui
> Sent: Tuesday, May 17, 2016 10:46
> To: David Miller 
> Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com;
> linux-ker...@vger.kernel.org; j...@perches.com; net...@vger.kernel.org;
> a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang
> 
> Subject: RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
> 
> > From: David Miller [mailto:da...@davemloft.net]
> > Sent: Monday, May 16, 2016 1:16
> > To: Dexuan Cui 
> > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com; cav...@redhat.com; KY
> > Srinivasan ; Haiyang Zhang ;
> > j...@perches.com; vkuzn...@redhat.com
> > Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
> >
> > From: Dexuan Cui 
> > Date: Sun, 15 May 2016 09:52:42 -0700
> >
> > > Changes since v10
> > >
> > > 1) add module params: send_ring_page, recv_ring_page. They can be used
> to
> > > enlarge the ringbuffer size to get better performance, e.g.,
> > > # modprobe hv_sock  recv_ring_page=16 send_ring_page=16
> > > By default, recv_ring_page is 3 and send_ring_page is 2.
> > >
> > > 2) add module param max_socket_number (the default is 1024).
> > > A user can enlarge the number to create more than 1024 hv_sock sockets.
> > > By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes.
> > > (Here 1+1 means 1 page for send/recv buffers per connection, 
> > > respectively.)
> >
> > This is papering around my objections, and create module parameters which
> > I am fundamentally against.
> >
> > You're making the facility unusable by default, just to work around my
> > memory consumption concerns.
> >
> > What will end up happening is that everyone will simply increase the
> > values.
> >
> > You're not really addressing the core issue, and I will be ignoring you
> > future submissions of this change until you do.
> 
> David,
> I am sorry I came across as ignoring your feedback; that was not my intention.
> The current host side design for this feature is such that each socket 
> connection
> needs its own channel, which consists of
> 
> 1.A ring buffer for host to guest communication
> 2.A ring buffer for guest to host communication
> 
> The memory for the ring buffers has to be pinned down as this will be accessed
> both from interrupt level in Linux guest and from the host OS at any time.
> 
> To address your concerns, I am planning to re-implement both the receive path
> and the send path so that no additional pinned memory will be needed.
> 
> Receive Path:
> When the application does a read on the socket, we will dynamically allocate
> the buffer and perform the read operation on the incoming ring buffer. Since
> we will be in the process context, we can sleep here and will set the
> "GFP_KERNEL | __GFP_NOFAIL" flags. This buffer will be freed once the
> application consumes all the data.
> 
> Send Path:
> On the send side, we will construct the payload to be sent directly on the
> outgoing ringbuffer.
> 
> So, with these changes, the only memory that will be pinned down will be the
> memory for the ring buffers on a per-connection basis and this memory will be
> pinned down until the connection is torn down.
> 
> Please let me know if this addresses your concerns.
> 
> -- Dexuan

Hi David,
Ping. Really appreciate your comment.

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

Hello

[Deniz Mutluer]

My name is Deniz Mutluer,I am the secretary to Toma Mihaly an executive with 
the Rusd Investment bank,He says he has business proposal that would be of 
great benefits to both of you.

Kindly contact him via his personal email :  mih9...@gmail.com

Thanks,
Deniz.











Bu e-posta mesajı kişisel olup, içeriğinden mesajı atan kullanıcı doğrudan 
sorumludur. Bu mesajın içeriği ve/veya ekleri hiçbir şekilde izinsiz 
kullanılamaz, saklanamaz ve/veya kopyalanamaz. Mesaj yanlışlıkla size 
gönderilmişse ya da mesajın muhatabının siz olmadığını düşünüyorsanız, lütfen 
tüm ekleriyle birlikte siliniz ve göndereni uyarınız.

This is a personal e-mail message the user of which is directly responsible for 
the content of the message. Under no circumstances the content and/or annexes 
of the message can be used, hold and/or reproduced without permission. If the 
message has been sent to you by mistake or if you think you are not the 
intended recipient, please with all the annexes, delete the message and notify 
the sender

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

RE: [PATCH v2 06/14] staging: comedi: daqboard2000: rename register offset macros

[Hartley Sweeten]

On Wednesday, May 18, 2016 5:37 AM, Ian Abbott wrote:
> Rename the macros defining register offsets to avoid CamelCase, and to
> use namespace associated with the driver.
>
> Signed-off-by: Ian Abbott 
> Reviewed-by: H Hartley Sweeten 
> ---
> Other CamelCase issues in this patch will be dealt with by later
> patches in the series.
>
> v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.
> ---
>  drivers/staging/comedi/drivers/daqboard2000.c | 112 
> ++
>  1 file changed, 61 insertions(+), 51 deletions(-)

[snip]

+#define DB2K_REG_DIO_P2_EXP_IO_16_BIT(x)   (0xc0 + (x) * 2) /* s16 */

You slipped an extra space in here:
WARNING: please, no space before tabs
#184: FILE: drivers/staging/comedi/drivers/daqboard2000.c:184:
+#define DB2K_REG_DIO_P2_EXP_IO_16_BIT(x) ^I(0xc0 + (x) * 2) /* s16 */$

Regards,
Hartley

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

RE: [PATCH v2 12/14] staging: comedi: daqboard2000: rename reference DACs register macros

[Hartley Sweeten]

On Wednesday, May 18, 2016 5:37 AM, Ian Abbott wrote:
> Rename the macros that define values for the reference DACs register to
> avoid CamelCase, and to make it clearer which register they are
> associated with.  Add a macro `DAQBOARD2000_REF_DACS_SET` for the value
> `0x80` that triggers setting one of the references.

[snip]

+#define DB2K_REF_DACS_SET  0x0080

Minor issue... Typo in the commit. Not sure if it's worth a v3.

Regards,
Hartley

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

RE: new driver for drivers/virt/?

[Sell, Timothy C]

> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, May 18, 2016 6:12 PM
> To: Sell, Timothy C
> Cc: mi...@kernel.org; dave.han...@linux.intel.com;
> ti...@freescale.com; ga...@kernel.crashing.org; Kershner, David A;
> cor...@lwn.net; mi...@redhat.com; h...@zytor.com; Arfvidson, Erik;
> hof...@osadl.org; dzic...@redhat.com; Curtin, Alexander Paul;
> janani.rvchn...@gmail.com; sudipm.mukher...@gmail.com;
> pra...@redhat.com; Binder, David Anthony; nhor...@redhat.com;
> dan.j.willi...@intel.com; linux-ker...@vger.kernel.org; linux-
> d...@vger.kernel.org; driverdev-devel@linuxdriverproject.org; *S-Par-
> Maintainer; Greg KH; Jes Sorensen
> Subject: Re: new driver for drivers/virt/?
> 
> On Wed, 18 May 2016, Sell, Timothy C wrote:
> > We have a bus driver currently in drivers/staging/unisys/visorbus/ that
> > we are trying to get out of staging and into the kernel proper.  Since
> > "visorbus" is a driver to host a virtual bus presented to a Linux guest
> > in a hypervisor environment (refer to
> > drivers/staging/unisys/Documentation/overview.txt for more details),
> > Greg KH and Jes Sorensen have suggested the possibility that drivers/virt/
> > might be a good place for visorbus.  But right now, we see that the only
> > driver under drivers/virt/ is the Freescale hypervisor environment, which
> > made us wonder whether this was really the correct place.
> >
> > Would you have any guidance for us?
> > Our intent is to push our visorbus out of staging immediately following
> > the current merge window.
> 
> What's the problem with Gregs and Jes suggestion? I don't see any.
> 

That's good; glad you agree with them.  We just wanted to double-check
with those of you listed as maintainers of drivers/virt/.  Thanks.

> There is bigger fish to fry than the final place of this driver. I had just a
> peek at the staging code and there is enough stuff which wants to be
> cleaned
> up before moving anywhere. I don't have time to do a proper review now,
> but
> here are a few hints upfront:
> 
> 1) Locking:
> 
>visordriver_callback_lock:
> 
>   That should be a mutex, not a semaphore
> 
>periodic_work->lock:
> 
>   Why is this a rw_lock if it's only locked with write_lock? And what's
>   the purpose of this lock at all?
> 
> 2) Memory barriers:
> 
>Completely undocumented wmb()s without corresponding rmb()s to do
> obscure
>protection of that periodic work stuff.
> 
> 3) periodic_work:
> 
>That set of functions is obscure. Especially visor_periodic_work_stop()
>makes me shudder. See also #2.
> 
>That work->lock does not inspire my confidence further.
> 
> 4) Exports:
> 
>A gazillion of exports which are just wrappers around another set of
>exports
> 
> 5) Function comments:
> 
>Try to mimic kerneldoc comments, i.e. start with: /**
>but do not implement any of the kerneldoc requirements.
> 

We'll take a look at these.  Thanks.

Tim Sell

> I'll try do find a time slot for a proper review of that thing, but don't
> expect that to happen in the next days.
> 
> Thanks,
> 
>   tglx
> 

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

Re: new driver for drivers/virt/?

[Greg KH]

On Thu, May 19, 2016 at 12:11:46AM +0200, Thomas Gleixner wrote:
> On Wed, 18 May 2016, Sell, Timothy C wrote:
> > We have a bus driver currently in drivers/staging/unisys/visorbus/ that
> > we are trying to get out of staging and into the kernel proper.  Since
> > "visorbus" is a driver to host a virtual bus presented to a Linux guest
> > in a hypervisor environment (refer to 
> > drivers/staging/unisys/Documentation/overview.txt for more details),
> > Greg KH and Jes Sorensen have suggested the possibility that drivers/virt/
> > might be a good place for visorbus.  But right now, we see that the only
> > driver under drivers/virt/ is the Freescale hypervisor environment, which
> > made us wonder whether this was really the correct place.
> > 
> > Would you have any guidance for us?
> > Our intent is to push our visorbus out of staging immediately following
> > the current merge window.
> 
> What's the problem with Gregs and Jes suggestion? I don't see any.

Neither do I, odd that they wanted a third opinion :(

> There is bigger fish to fry than the final place of this driver. I had just a
> peek at the staging code and there is enough stuff which wants to be cleaned
> up before moving anywhere. I don't have time to do a proper review now, but
> here are a few hints upfront:



I don't think anyone has given a good review of the code yet, I know
it's been a long time for me.  It's on my todo list, but that's not
going to happen until way after 4.7-rc1 is out.  Thanks for this initial
list.

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

Re: new driver for drivers/virt/?

[Thomas Gleixner]

On Wed, 18 May 2016, Sell, Timothy C wrote:
> We have a bus driver currently in drivers/staging/unisys/visorbus/ that
> we are trying to get out of staging and into the kernel proper.  Since
> "visorbus" is a driver to host a virtual bus presented to a Linux guest
> in a hypervisor environment (refer to 
> drivers/staging/unisys/Documentation/overview.txt for more details),
> Greg KH and Jes Sorensen have suggested the possibility that drivers/virt/
> might be a good place for visorbus.  But right now, we see that the only
> driver under drivers/virt/ is the Freescale hypervisor environment, which
> made us wonder whether this was really the correct place.
> 
> Would you have any guidance for us?
> Our intent is to push our visorbus out of staging immediately following
> the current merge window.

What's the problem with Gregs and Jes suggestion? I don't see any.

There is bigger fish to fry than the final place of this driver. I had just a
peek at the staging code and there is enough stuff which wants to be cleaned
up before moving anywhere. I don't have time to do a proper review now, but
here are a few hints upfront:

1) Locking:

   visordriver_callback_lock: 

  That should be a mutex, not a semaphore

   periodic_work->lock: 

  Why is this a rw_lock if it's only locked with write_lock? And what's
  the purpose of this lock at all?

2) Memory barriers:

   Completely undocumented wmb()s without corresponding rmb()s to do obscure
   protection of that periodic work stuff.

3) periodic_work:

   That set of functions is obscure. Especially visor_periodic_work_stop()
   makes me shudder. See also #2. 

   That work->lock does not inspire my confidence further.

4) Exports:

   A gazillion of exports which are just wrappers around another set of
   exports

5) Function comments:

   Try to mimic kerneldoc comments, i.e. start with: /**
   but do not implement any of the kerneldoc requirements.

I'll try do find a time slot for a proper review of that thing, but don't
expect that to happen in the next days.

Thanks,

tglx

   





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

new driver for drivers/virt/?

[Sell, Timothy C]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, May 18, 2016 1:27 PM
> To: Jes Sorensen
> Cc: Kershner, David A; cor...@lwn.net; t...@linutronix.de;
> mi...@redhat.com; h...@zytor.com; Arfvidson, Erik; Sell, Timothy C;
> hof...@osadl.org; dzic...@redhat.com; Curtin, Alexander Paul;
> janani.rvchn...@gmail.com; sudipm.mukher...@gmail.com;
> pra...@redhat.com; Binder, David Anthony; nhor...@redhat.com;
> dan.j.willi...@intel.com; linux-ker...@vger.kernel.org; linux-
> d...@vger.kernel.org; driverdev-devel@linuxdriverproject.org; *S-Par-
> Maintainer
> Subject: Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized
> devices to arch/x86
> 
> On Wed, May 18, 2016 at 12:03:58PM -0400, Jes Sorensen wrote:
> > Greg KH  writes:
> > > On Tue, May 17, 2016 at 07:49:53PM -0400, Jes Sorensen wrote:
> > >> > Ok, but still no need to put it under arch/ anything, it should go in
> > >> > drivers/ like all other drivers and busses are, no matter what the arch
> > >> > it happens to run on is.
> > >>
> > >> I don't think thats obvious. arch/x86/kvm is an example of this, Sparc
> > >> and PPC also have their stuff under arch/.
> > >
> > > For some things, yes, but let's not make the same mistakes as others :)
> > >
> > > Look at drivers/hv/ for an example of a very x86-only bus and driver
> > > subsystem living in drivers/  Please don't burry driver stuff in arch/
> > > the ARM developers are trying to fix their mistakes of the past and move
> > > all of their cruft out of arch/ for that reason.
> >
> > Works for me.
> >
> > So should they put it in drivers/visorbus or drivers/bus/visorbus?
> 
> drivers/visorbus please.  drivers/bus/ is an "odd" thing :(
> 
> > What about drivers/virt? Would you suggest hv and xen gets moved in
> > there?
> 
> Ah, yeah, that would be great, never noticed it before, despite being
> there since 2011...
> 
> thanks,
> 
> greg k-h

tglx, Ingo, Dave, Timur, Kumar:

We have a bus driver currently in drivers/staging/unisys/visorbus/ that
we are trying to get out of staging and into the kernel proper.  Since
"visorbus" is a driver to host a virtual bus presented to a Linux guest
in a hypervisor environment (refer to 
drivers/staging/unisys/Documentation/overview.txt for more details),
Greg KH and Jes Sorensen have suggested the possibility that drivers/virt/
might be a good place for visorbus.  But right now, we see that the only
driver under drivers/virt/ is the Freescale hypervisor environment, which
made us wonder whether this was really the correct place.

Would you have any guidance for us?
Our intent is to push our visorbus out of staging immediately following
the current merge window.

Thanks.

Tim Sell

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

Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized devices to arch/x86

[Greg KH]

On Wed, May 18, 2016 at 12:03:58PM -0400, Jes Sorensen wrote:
> Greg KH  writes:
> > On Tue, May 17, 2016 at 07:49:53PM -0400, Jes Sorensen wrote:
> >> > Ok, but still no need to put it under arch/ anything, it should go in
> >> > drivers/ like all other drivers and busses are, no matter what the arch
> >> > it happens to run on is.
> >> 
> >> I don't think thats obvious. arch/x86/kvm is an example of this, Sparc
> >> and PPC also have their stuff under arch/.
> >
> > For some things, yes, but let's not make the same mistakes as others :)
> >
> > Look at drivers/hv/ for an example of a very x86-only bus and driver
> > subsystem living in drivers/  Please don't burry driver stuff in arch/
> > the ARM developers are trying to fix their mistakes of the past and move
> > all of their cruft out of arch/ for that reason.
> 
> Works for me.
> 
> So should they put it in drivers/visorbus or drivers/bus/visorbus?

drivers/visorbus please.  drivers/bus/ is an "odd" thing :(

> What about drivers/virt? Would you suggest hv and xen gets moved in
> there?

Ah, yeah, that would be great, never noticed it before, despite being
there since 2011...

thanks,

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

Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized devices to arch/x86

[Jes Sorensen]

Greg KH  writes:
> On Tue, May 17, 2016 at 07:49:53PM -0400, Jes Sorensen wrote:
>> > Ok, but still no need to put it under arch/ anything, it should go in
>> > drivers/ like all other drivers and busses are, no matter what the arch
>> > it happens to run on is.
>> 
>> I don't think thats obvious. arch/x86/kvm is an example of this, Sparc
>> and PPC also have their stuff under arch/.
>
> For some things, yes, but let's not make the same mistakes as others :)
>
> Look at drivers/hv/ for an example of a very x86-only bus and driver
> subsystem living in drivers/  Please don't burry driver stuff in arch/
> the ARM developers are trying to fix their mistakes of the past and move
> all of their cruft out of arch/ for that reason.

Works for me.

So should they put it in drivers/visorbus or drivers/bus/visorbus?  What
about drivers/virt? Would you suggest hv and xen gets moved in there?

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

[PATCH v2 09/14] staging: comedi: daqboard2000: redo DAC control register macros

[Ian Abbott]

Rename the macros used to define values for the DAC control register to
avoid CamelCase and to make it clearer which register they are
associated with.  Refactor the macros used to define values to enable or
disable DAC channels to use the channel number as a parameter.  None of
these macros are currently used by the driver.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 271ad83..aea40ee 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -225,20 +225,13 @@ static const struct comedi_lrange range_daqboard2000_ai = 
{
 #define DAQBOARD2000_Dac3Busy0x0080
 
 /* DAC control */
-#define DAQBOARD2000_Dac0Enable  0x0021
-#define DAQBOARD2000_Dac1Enable  0x0031
-#define DAQBOARD2000_Dac2Enable  0x0041
-#define DAQBOARD2000_Dac3Enable  0x0051
-#define DAQBOARD2000_DacEnableBit0x0001
-#define DAQBOARD2000_Dac0Disable 0x0020
-#define DAQBOARD2000_Dac1Disable 0x0030
-#define DAQBOARD2000_Dac2Disable 0x0040
-#define DAQBOARD2000_Dac3Disable 0x0050
-#define DAQBOARD2000_DacResetFifo0x0004
-#define DAQBOARD2000_DacPatternDisable   0x0060
-#define DAQBOARD2000_DacPatternEnable0x0061
-#define DAQBOARD2000_DacSelectSignedData 0x0002
-#define DAQBOARD2000_DacSelectUnsignedData   0x
+#define DB2K_DAC_CONTROL_ENABLE_BIT0x0001
+#define DB2K_DAC_CONTROL_DATA_IS_SIGNED0x0002
+#define DB2K_DAC_CONTROL_RESET_FIFO0x0004
+#define DB2K_DAC_CONTROL_DAC_DISABLE(x)(0x0020 + ((x) 
<< 4))
+#define DB2K_DAC_CONTROL_DAC_ENABLE(x) (0x0021 + ((x) << 4))
+#define DB2K_DAC_CONTROL_PATTERN_DISABLE   0x0060
+#define DB2K_DAC_CONTROL_PATTERN_ENABLE0x0061
 
 /* Trigger Control */
 #define DAQBOARD2000_TrigAnalog  0x
-- 
2.8.1

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

[PATCH v2 11/14] staging: comedi: daqboard2000: rename trigger control register macros

[Ian Abbott]

Rename the macros that define values for the trigger control register to
avoid CamelCase, and to make it clearer which register they are
associated with.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 37aa3a4..9bf831b 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -232,16 +232,16 @@ static const struct comedi_lrange range_daqboard2000_ai = 
{
 #define DB2K_DAC_CONTROL_PATTERN_ENABLE0x0061
 
 /* Trigger Control */
-#define DAQBOARD2000_TrigAnalog  0x
-#define DAQBOARD2000_TrigTTL 0x0010
-#define DAQBOARD2000_TrigTransHiLo   0x0004
-#define DAQBOARD2000_TrigTransLoHi   0x
-#define DAQBOARD2000_TrigAbove   0x
-#define DAQBOARD2000_TrigBelow   0x0004
-#define DAQBOARD2000_TrigLevelSense  0x0002
-#define DAQBOARD2000_TrigEdgeSense   0x
-#define DAQBOARD2000_TrigEnable  0x0001
-#define DAQBOARD2000_TrigDisable 0x
+#define DB2K_TRIG_CONTROL_TYPE_ANALOG  0x
+#define DB2K_TRIG_CONTROL_TYPE_TTL 0x0010
+#define DB2K_TRIG_CONTROL_EDGE_HI_LO   0x0004
+#define DB2K_TRIG_CONTROL_EDGE_LO_HI   0x
+#define DB2K_TRIG_CONTROL_LEVEL_ABOVE  0x
+#define DB2K_TRIG_CONTROL_LEVEL_BELOW  0x0004
+#define DB2K_TRIG_CONTROL_SENSE_LEVEL  0x0002
+#define DB2K_TRIG_CONTROL_SENSE_EDGE   0x
+#define DB2K_TRIG_CONTROL_ENABLE   0x0001
+#define DB2K_TRIG_CONTROL_DISABLE  0x
 
 /* Reference Dac Selection */
 #define DAQBOARD2000_PosRefDacSelect 0x0100
@@ -543,10 +543,10 @@ static void daqboard2000_adcDisarm(struct comedi_device 
*dev)
 {
/* Disable hardware triggers */
udelay(2);
-   writew(DAQBOARD2000_TrigAnalog | DAQBOARD2000_TrigDisable,
+   writew(DB2K_TRIG_CONTROL_TYPE_ANALOG | DB2K_TRIG_CONTROL_DISABLE,
   dev->mmio + DB2K_REG_TRIG_CONTROL);
udelay(2);
-   writew(DAQBOARD2000_TrigTTL | DAQBOARD2000_TrigDisable,
+   writew(DB2K_TRIG_CONTROL_TYPE_TTL | DB2K_TRIG_CONTROL_DISABLE,
   dev->mmio + DB2K_REG_TRIG_CONTROL);
 
/* Stop the scan list FIFO from loading the configuration pipe */
-- 
2.8.1

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

[PATCH v2 08/14] staging: comedi: daqboard2000: rename acq status register macros

[Ian Abbott]

Rename the macros associated with the acquisition status register to
avoid CamelCase and to make it clear which register they are associated
with.

Add a macro to define the offset of the read-only acquisition status
register.  It's the same offset as the acquisition control register,
which is write-only.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 39 ++-
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index e77a65a..271ad83 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -151,7 +151,8 @@ static const struct comedi_lrange range_daqboard2000_ai = {
 /*
  * Register Memory Map
  */
-#define DB2K_REG_ACQ_CONTROL   0x00/* u16 */
+#define DB2K_REG_ACQ_CONTROL   0x00/* u16 (w) */
+#define DB2K_REG_ACQ_STATUS0x00/* u16 (r) */
 #define DB2K_REG_ACQ_SCAN_LIST_FIFO0x02/* u16 */
 #define DB2K_REG_ACQ_PACER_CLOCK_DIV_LOW   0x04/* u32 */
 #define DB2K_REG_ACQ_SCAN_COUNTER  0x08/* u16 */
@@ -190,19 +191,6 @@ static const struct comedi_lrange range_daqboard2000_ai = {
 #define DB2K_ACQ_CONTROL_RESET_RESULTS_FIFO0x0002
 #define DB2K_ACQ_CONTROL_RESET_CONFIG_PIPE 0x0001
 
-/* Acqusition status bits */
-#define DAQBOARD2000_AcqResultsFIFOMore1Sample   0x0001
-#define DAQBOARD2000_AcqResultsFIFOHasValidData  0x0002
-#define DAQBOARD2000_AcqResultsFIFOOverrun   0x0004
-#define DAQBOARD2000_AcqLogicScanning0x0008
-#define DAQBOARD2000_AcqConfigPipeFull   0x0010
-#define DAQBOARD2000_AcqScanListFIFOEmpty0x0020
-#define DAQBOARD2000_AcqAdcNotReady  0x0040
-#define DAQBOARD2000_ArbitrationFailure  0x0080
-#define DAQBOARD2000_AcqPacerOverrun 0x0100
-#define DAQBOARD2000_DacPacerOverrun 0x0200
-#define DAQBOARD2000_AcqHardwareError0x01c0
-
 /* Pacer Clock Control */
 #define DB2K_ACQ_CONTROL_ADC_PACER_INTERNAL0x0030
 #define DB2K_ACQ_CONTROL_ADC_PACER_EXTERNAL0x0032
@@ -214,6 +202,18 @@ static const struct comedi_lrange range_daqboard2000_ai = {
 #define DB2K_ACQ_CONTROL_ADC_PACER_INTERNAL_OUT_ENABLE 0x0008
 #define DB2K_ACQ_CONTROL_ADC_PACER_EXTERNAL_RISING 0x0100
 
+/* Acquisition status bits */
+#define DB2K_ACQ_STATUS_RESULTS_FIFO_MORE_1_SAMPLE 0x0001
+#define DB2K_ACQ_STATUS_RESULTS_FIFO_HAS_DATA  0x0002
+#define DB2K_ACQ_STATUS_RESULTS_FIFO_OVERRUN   0x0004
+#define DB2K_ACQ_STATUS_LOGIC_SCANNING 0x0008
+#define DB2K_ACQ_STATUS_CONFIG_PIPE_FULL   0x0010
+#define DB2K_ACQ_STATUS_SCAN_LIST_FIFO_EMPTY   0x0020
+#define DB2K_ACQ_STATUS_ADC_NOT_READY  0x0040
+#define DB2K_ACQ_STATUS_ARBITRATION_FAILURE0x0080
+#define DB2K_ACQ_STATUS_ADC_PACER_OVERRUN  0x0100
+#define DB2K_ACQ_STATUS_DAC_PACER_OVERRUN  0x0200
+
 /* DAC status */
 #define DAQBOARD2000_DacFull 0x0001
 #define DAQBOARD2000_RefBusy 0x0002
@@ -327,7 +327,7 @@ static int daqboard2000_ai_status(struct comedi_device *dev,
 {
unsigned int status;
 
-   status = readw(dev->mmio + DB2K_REG_ACQ_CONTROL);
+   status = readw(dev->mmio + DB2K_REG_ACQ_STATUS);
if (status & context)
return 0;
return -EBUSY;
@@ -371,7 +371,7 @@ static int daqboard2000_ai_insn_read(struct comedi_device 
*dev,
   dev->mmio + DB2K_REG_ACQ_CONTROL);
 
ret = comedi_timeout(dev, s, insn, daqboard2000_ai_status,
-DAQBOARD2000_AcqConfigPipeFull);
+DB2K_ACQ_STATUS_CONFIG_PIPE_FULL);
if (ret)
return ret;
 
@@ -379,12 +379,13 @@ static int daqboard2000_ai_insn_read(struct comedi_device 
*dev,
   dev->mmio + DB2K_REG_ACQ_CONTROL);
 
ret = comedi_timeout(dev, s, insn, daqboard2000_ai_status,
-DAQBOARD2000_AcqLogicScanning);
+DB2K_ACQ_STATUS_LOGIC_SCANNING);
if (ret)
return ret;
 
-   ret = comedi_timeout(dev, s, insn, daqboard2000_ai_status,
-DAQBOARD2000_AcqResultsFIFOHasValidData);
+   ret =
+   comedi_timeout(dev, s, insn, daqboard2000_ai_status,
+  DB2K_ACQ_STATUS_RESULTS_FIFO_HAS_DATA);
if (ret)
return ret;
 
-- 
2.8.1

[PATCH v2 12/14] staging: comedi: daqboard2000: rename reference DACs register macros

[Ian Abbott]

Rename the macros that define values for the reference DACs register to
avoid CamelCase, and to make it clearer which register they are
associated with.  Add a macro `DAQBOARD2000_REF_DACS_SET` for the value
`0x80` that triggers setting one of the references.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 9bf831b..4c6c881 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -244,8 +244,9 @@ static const struct comedi_lrange range_daqboard2000_ai = {
 #define DB2K_TRIG_CONTROL_DISABLE  0x
 
 /* Reference Dac Selection */
-#define DAQBOARD2000_PosRefDacSelect 0x0100
-#define DAQBOARD2000_NegRefDacSelect 0x
+#define DB2K_REF_DACS_SET  0x0080
+#define DB2K_REF_DACS_SELECT_POS_REF   0x0100
+#define DB2K_REF_DACS_SELECT_NEG_REF   0x
 
 struct daq200_boardtype {
const char *name;
@@ -569,7 +570,7 @@ static void daqboard2000_activateReferenceDacs(struct 
comedi_device *dev)
int timeout;
 
/*  Set the + reference dac value in the FPGA */
-   writew(0x80 | DAQBOARD2000_PosRefDacSelect,
+   writew(DB2K_REF_DACS_SET | DB2K_REF_DACS_SELECT_POS_REF,
   dev->mmio + DB2K_REG_REF_DACS);
for (timeout = 0; timeout < 20; timeout++) {
val = readw(dev->mmio + DB2K_REG_DAC_STATUS);
@@ -579,7 +580,7 @@ static void daqboard2000_activateReferenceDacs(struct 
comedi_device *dev)
}
 
/*  Set the - reference dac value in the FPGA */
-   writew(0x80 | DAQBOARD2000_NegRefDacSelect,
+   writew(DB2K_REF_DACS_SET | DB2K_REF_DACS_SELECT_NEG_REF,
   dev->mmio + DB2K_REG_REF_DACS);
for (timeout = 0; timeout < 20; timeout++) {
val = readw(dev->mmio + DB2K_REG_DAC_STATUS);
-- 
2.8.1

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

[PATCH v2 10/14] staging: comedi: daqboard2000: redo DAC status macros and fix busy

[Ian Abbott]

Rename the macros defining values for the DAC status register to avoid
CamelCase, and to make it clear which register they are associated with.
Refactor the macros defining the regular DAC channel "busy" bits into a
single macro that takes the DAC channel number as a parameter.

Add a macro to define the offset of the read-only DAC status register.
It is the same offset as the DAC control register, which is write-only.

The code in `daqboard2000_ao_eoc()` that checks the status for
completion of the DAC conversion looks wrong.  The register has a "busy"
bit for each channel, but the existing code only works for channels 0
and 1.  The driver only supports two DAC channels at the moment, so the
bug is currently harmless, but fix it so we can support four DAC
channels on some board models.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.

squash! staging: comedi: daqboard2000: redo DAC status macros and fix busy
---
 drivers/staging/comedi/drivers/daqboard2000.c | 28 +--
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index aea40ee..37aa3a4 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -162,7 +162,8 @@ static const struct comedi_lrange range_daqboard2000_ai = {
 #define DB2K_REG_ACQ_RESULTS_SHADOW0x14/* u16 */
 #define DB2K_REG_ACQ_ADC_RESULT0x18/* u16 
*/
 #define DB2K_REG_DAC_SCAN_COUNTER  0x1c/* u16 */
-#define DB2K_REG_DAC_CONTROL   0x20/* u16 */
+#define DB2K_REG_DAC_CONTROL   0x20/* u16 (w) */
+#define DB2K_REG_DAC_STATUS0x20/* u16 (r) */
 #define DB2K_REG_DAC_FIFO  0x24/* s16 */
 #define DB2K_REG_DAC_PACER_CLOCK_DIV   0x2a/* u16 */
 #define DB2K_REG_REF_DACS  0x2c/* u16 */
@@ -215,14 +216,11 @@ static const struct comedi_lrange range_daqboard2000_ai = 
{
 #define DB2K_ACQ_STATUS_DAC_PACER_OVERRUN  0x0200
 
 /* DAC status */
-#define DAQBOARD2000_DacFull 0x0001
-#define DAQBOARD2000_RefBusy 0x0002
-#define DAQBOARD2000_TrgBusy 0x0004
-#define DAQBOARD2000_CalBusy 0x0008
-#define DAQBOARD2000_Dac0Busy0x0010
-#define DAQBOARD2000_Dac1Busy0x0020
-#define DAQBOARD2000_Dac2Busy0x0040
-#define DAQBOARD2000_Dac3Busy0x0080
+#define DB2K_DAC_STATUS_DAC_FULL   0x0001
+#define DB2K_DAC_STATUS_REF_BUSY   0x0002
+#define DB2K_DAC_STATUS_TRIG_BUSY  0x0004
+#define DB2K_DAC_STATUS_CAL_BUSY   0x0008
+#define DB2K_DAC_STATUS_DAC_BUSY(x)(0x0010 << (x))
 
 /* DAC control */
 #define DB2K_DAC_CONTROL_ENABLE_BIT0x0001
@@ -400,8 +398,8 @@ static int daqboard2000_ao_eoc(struct comedi_device *dev,
unsigned int chan = CR_CHAN(insn->chanspec);
unsigned int status;
 
-   status = readw(dev->mmio + DB2K_REG_DAC_CONTROL);
-   if ((status & ((chan + 1) * 0x0010)) == 0)
+   status = readw(dev->mmio + DB2K_REG_DAC_STATUS);
+   if ((status & DB2K_DAC_STATUS_DAC_BUSY(chan)) == 0)
return 0;
return -EBUSY;
 }
@@ -574,8 +572,8 @@ static void daqboard2000_activateReferenceDacs(struct 
comedi_device *dev)
writew(0x80 | DAQBOARD2000_PosRefDacSelect,
   dev->mmio + DB2K_REG_REF_DACS);
for (timeout = 0; timeout < 20; timeout++) {
-   val = readw(dev->mmio + DB2K_REG_DAC_CONTROL);
-   if ((val & DAQBOARD2000_RefBusy) == 0)
+   val = readw(dev->mmio + DB2K_REG_DAC_STATUS);
+   if ((val & DB2K_DAC_STATUS_REF_BUSY) == 0)
break;
udelay(2);
}
@@ -584,8 +582,8 @@ static void daqboard2000_activateReferenceDacs(struct 
comedi_device *dev)
writew(0x80 | DAQBOARD2000_NegRefDacSelect,
   dev->mmio + DB2K_REG_REF_DACS);
for (timeout = 0; timeout < 20; timeout++) {
-   val = readw(dev->mmio + DB2K_REG_DAC_CONTROL);
-   if ((val & DAQBOARD2000_RefBusy) == 0)
+   val = readw(dev->mmio + DB2K_REG_DAC_STATUS);
+   if ((val & DB2K_DAC_STATUS_REF_BUSY) == 0)
break;
udelay(2);
}
-- 
2.8.1

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

[PATCH v2 13/14] staging: comedi: daqboard2000: rename CamelCase functions

[Ian Abbott]

Rename functions to avoid CamelCase warnings from checkpatch, and to use
namespace associated with the driver.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: No change, except to some diff context lines from previous patches.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 80 ++-
 1 file changed, 41 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 4c6c881..856ed1cb 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -265,14 +265,16 @@ struct daqboard2000_private {
void __iomem *plx;
 };
 
-static void writeAcqScanListEntry(struct comedi_device *dev, u16 entry)
+static void daqboard2000_write_acq_scan_list_entry(struct comedi_device *dev,
+  u16 entry)
 {
writew(entry & 0x00ff, dev->mmio + DB2K_REG_ACQ_SCAN_LIST_FIFO);
writew((entry >> 8) & 0x00ff,
   dev->mmio + DB2K_REG_ACQ_SCAN_LIST_FIFO);
 }
 
-static void setup_sampling(struct comedi_device *dev, int chan, int gain)
+static void daqboard2000_setup_sampling(struct comedi_device *dev, int chan,
+   int gain)
 {
u16 word0, word1, word2, word3;
 
@@ -306,10 +308,10 @@ static void setup_sampling(struct comedi_device *dev, int 
chan, int gain)
/* These should be read from EEPROM */
word2 |= 0x0800;/* offset */
word3 |= 0xc000;/* gain */
-   writeAcqScanListEntry(dev, word0);
-   writeAcqScanListEntry(dev, word1);
-   writeAcqScanListEntry(dev, word2);
-   writeAcqScanListEntry(dev, word3);
+   daqboard2000_write_acq_scan_list_entry(dev, word0);
+   daqboard2000_write_acq_scan_list_entry(dev, word1);
+   daqboard2000_write_acq_scan_list_entry(dev, word2);
+   daqboard2000_write_acq_scan_list_entry(dev, word3);
 }
 
 static int daqboard2000_ai_status(struct comedi_device *dev,
@@ -357,7 +359,7 @@ static int daqboard2000_ai_insn_read(struct comedi_device 
*dev,
 * forced to fix it.  --ds
 */
for (i = 0; i < insn->n; i++) {
-   setup_sampling(dev, chan, gain);
+   daqboard2000_setup_sampling(dev, chan, gain);
/* Enable reading from the scanlist FIFO */
writew(DB2K_ACQ_CONTROL_SEQ_START_SCAN_LIST,
   dev->mmio + DB2K_REG_ACQ_CONTROL);
@@ -429,7 +431,7 @@ static int daqboard2000_ao_insn_write(struct comedi_device 
*dev,
return insn->n;
 }
 
-static void daqboard2000_resetLocalBus(struct comedi_device *dev)
+static void daqboard2000_reset_local_bus(struct comedi_device *dev)
 {
struct daqboard2000_private *devpriv = dev->private;
 
@@ -439,7 +441,7 @@ static void daqboard2000_resetLocalBus(struct comedi_device 
*dev)
mdelay(10);
 }
 
-static void daqboard2000_reloadPLX(struct comedi_device *dev)
+static void daqboard2000_reload_plx(struct comedi_device *dev)
 {
struct daqboard2000_private *devpriv = dev->private;
 
@@ -451,7 +453,7 @@ static void daqboard2000_reloadPLX(struct comedi_device 
*dev)
mdelay(10);
 }
 
-static void daqboard2000_pulseProgPin(struct comedi_device *dev)
+static void daqboard2000_pulse_prog_pin(struct comedi_device *dev)
 {
struct daqboard2000_private *devpriv = dev->private;
 
@@ -461,7 +463,7 @@ static void daqboard2000_pulseProgPin(struct comedi_device 
*dev)
mdelay(10); /* Not in the original code, but I like symmetry... */
 }
 
-static int daqboard2000_pollCPLD(struct comedi_device *dev, int mask)
+static int daqboard2000_poll_cpld(struct comedi_device *dev, int mask)
 {
int result = 0;
int i;
@@ -480,7 +482,7 @@ static int daqboard2000_pollCPLD(struct comedi_device *dev, 
int mask)
return result;
 }
 
-static int daqboard2000_writeCPLD(struct comedi_device *dev, int data)
+static int daqboard2000_write_cpld(struct comedi_device *dev, int data)
 {
int result = 0;
 
@@ -493,9 +495,9 @@ static int daqboard2000_writeCPLD(struct comedi_device 
*dev, int data)
return result;
 }
 
-static int initialize_daqboard2000(struct comedi_device *dev,
-  const u8 *cpld_array, size_t len,
-  unsigned long context)
+static int daqboard2000_load_firmware(struct comedi_device *dev,
+ const u8 *cpld_array, size_t len,
+ unsigned long context)
 {
struct daqboard2000_private *devpriv = dev->private;
int result = -EIO;
@@ -510,10 +512,10 @@ static int initialize_daqboard2000(struct comedi_device 
*dev,
return -EIO;
 
for (retry = 0; retry < 3; retry++) {
-   daqboard2000_resetLocalBus(dev);
-   

[PATCH v2 14/14] staging: comedi: daqboard2000: prefer usleep_range()

[Ian Abbott]

The checkpatch.pl warns about two `udelay(x)` calls, one of 100
microseconds, and one of 10 microseconds.  The 100 microseconds one is
used when waiting for FPGA to become ready to accept firmware, and is
not that critical, so replace it with a call to `usleep_range(100,
1000)`.  The 10 microseconds one is called as each 16-bit word of
firmware data is written.  Replace it with a fairly tight
`usleep_range(10, 20)` to avoid slowing down firmware loading too much.
The firmware is fairly short, so this would only slow it down firmware
loading by about 20 milliseconds or so.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Replaced the 10 microsecond udelay with a fairly tight usleep_range,
as suggested by Hartley.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 856ed1cb..fa41799 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -476,7 +476,7 @@ static int daqboard2000_poll_cpld(struct comedi_device 
*dev, int mask)
result = 1;
break;
}
-   udelay(100);
+   usleep_range(100, 1000);
}
udelay(5);
return result;
@@ -486,7 +486,7 @@ static int daqboard2000_write_cpld(struct comedi_device 
*dev, int data)
 {
int result = 0;
 
-   udelay(10);
+   usleep_range(10, 20);
writew(data, dev->mmio + 0x1000);
if ((readw(dev->mmio + 0x1000) & DAQBOARD2000_CPLD_INIT) ==
DAQBOARD2000_CPLD_INIT) {
-- 
2.8.1

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

[PATCH v2 05/14] staging: comedi: daqboard2000: rename serial EEPROM register macros

[Ian Abbott]

Rename the macros defining values for the Serial EEPROM Control Register
to avoid CamelCase.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index cbbeb50..ceb910d 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -116,12 +116,12 @@
 #define DAQBOARD2000_SUBSYSTEM_IDS40x0004  /* Daqboard/2000 - 4 Dacs */
 
 /* Initialization bits for the Serial EEPROM Control Register */
-#define DAQBOARD2000_SECRProgPinHi  0x8001767e
-#define DAQBOARD2000_SECRProgPinLo  0x8000767e
-#define DAQBOARD2000_SECRLocalBusHi 0xc000767e
-#define DAQBOARD2000_SECRLocalBusLo 0x8000767e
-#define DAQBOARD2000_SECRReloadHi   0xa000767e
-#define DAQBOARD2000_SECRReloadLo   0x8000767e
+#define DB2K_SECR_PROG_PIN_HI  0x8001767e
+#define DB2K_SECR_PROG_PIN_LO  0x8000767e
+#define DB2K_SECR_LOCAL_BUS_HI 0xc000767e
+#define DB2K_SECR_LOCAL_BUS_LO 0x8000767e
+#define DB2K_SECR_RELOAD_HI0xa000767e
+#define DB2K_SECR_RELOAD_LO0x8000767e
 
 /* SECR status bits */
 #define DAQBOARD2000_EEPROM_PRESENT 0x1000
@@ -438,9 +438,9 @@ static void daqboard2000_resetLocalBus(struct comedi_device 
*dev)
 {
struct daqboard2000_private *devpriv = dev->private;
 
-   writel(DAQBOARD2000_SECRLocalBusHi, devpriv->plx + 0x6c);
+   writel(DB2K_SECR_LOCAL_BUS_HI, devpriv->plx + 0x6c);
mdelay(10);
-   writel(DAQBOARD2000_SECRLocalBusLo, devpriv->plx + 0x6c);
+   writel(DB2K_SECR_LOCAL_BUS_LO, devpriv->plx + 0x6c);
mdelay(10);
 }
 
@@ -448,11 +448,11 @@ static void daqboard2000_reloadPLX(struct comedi_device 
*dev)
 {
struct daqboard2000_private *devpriv = dev->private;
 
-   writel(DAQBOARD2000_SECRReloadLo, devpriv->plx + 0x6c);
+   writel(DB2K_SECR_RELOAD_LO, devpriv->plx + 0x6c);
mdelay(10);
-   writel(DAQBOARD2000_SECRReloadHi, devpriv->plx + 0x6c);
+   writel(DB2K_SECR_RELOAD_HI, devpriv->plx + 0x6c);
mdelay(10);
-   writel(DAQBOARD2000_SECRReloadLo, devpriv->plx + 0x6c);
+   writel(DB2K_SECR_RELOAD_LO, devpriv->plx + 0x6c);
mdelay(10);
 }
 
@@ -460,9 +460,9 @@ static void daqboard2000_pulseProgPin(struct comedi_device 
*dev)
 {
struct daqboard2000_private *devpriv = dev->private;
 
-   writel(DAQBOARD2000_SECRProgPinHi, devpriv->plx + 0x6c);
+   writel(DB2K_SECR_PROG_PIN_HI, devpriv->plx + 0x6c);
mdelay(10);
-   writel(DAQBOARD2000_SECRProgPinLo, devpriv->plx + 0x6c);
+   writel(DB2K_SECR_PROG_PIN_LO, devpriv->plx + 0x6c);
mdelay(10); /* Not in the original code, but I like symmetry... */
 }
 
-- 
2.8.1

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

[PATCH v2 02/14] staging: comedi: daqboard2000: use usual block comment style

[Ian Abbott]

Reformat one of the block comments to conform to the usual style (it's
the only one that doesn't).

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: No change.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 63d68fd..905b005 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -359,10 +359,12 @@ static int daqboard2000_ai_insn_read(struct comedi_device 
*dev,
gain = CR_RANGE(insn->chanspec);
chan = CR_CHAN(insn->chanspec);
 
-   /* This doesn't look efficient.  I decided to take the conservative
+   /*
+* This doesn't look efficient.  I decided to take the conservative
 * approach when I did the insn conversion.  Perhaps it would be
 * better to have broken it completely, then someone would have been
-* forced to fix it.  --ds */
+* forced to fix it.  --ds
+*/
for (i = 0; i < insn->n; i++) {
setup_sampling(dev, chan, gain);
/* Enable reading from the scanlist FIFO */
-- 
2.8.1

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

[PATCH v2 03/14] staging: comedi: daqboard2000: CHECK: spaces preferred around that '*'

[Ian Abbott]

Fix checkpatch issues of the form "CHECK: spaces preferred around that
'*' (ctx:VxV)".

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
CamelCase issues in this patch will be dealt with by later patches.

v2: No change.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 905b005..904de95 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -169,17 +169,17 @@ static const struct comedi_lrange range_daqboard2000_ai = 
{
 #define dioP3hsioData  0x32/* s16 */
 #define dioP3Control   0x34/* u16 */
 #define calEepromControl   0x36/* u16 */
-#define dacSetting(x)  (0x38 + (x)*2)  /* s16 */
+#define dacSetting(x)  (0x38 + (x) * 2) /* s16 */
 #define dioP2ExpansionIO8Bit   0x40/* s16 */
 #define ctrTmrControl  0x80/* u16 */
-#define ctrInput(x)(0x88 + (x)*2)  /* s16 */
-#define timerDivisor(x)(0xa0 + (x)*2)  /* u16 */
+#define ctrInput(x)(0x88 + (x) * 2) /* s16 */
+#define timerDivisor(x)(0xa0 + (x) * 2) /* u16 */
 #define dmaControl 0xb0/* u16 */
 #define trigControl0xb2/* u16 */
 #define calEeprom  0xb8/* u16 */
 #define acqDigitalMark 0xba/* u16 */
 #define trigDacs   0xbc/* u16 */
-#define dioP2ExpansionIO16Bit(x)   (0xc0 + (x)*2)  /* s16 */
+#define dioP2ExpansionIO16Bit(x)   (0xc0 + (x) * 2) /* s16 */
 
 /* Scan Sequencer programming */
 #define DAQBOARD2000_SeqStartScanList0x0011
-- 
2.8.1

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

[PATCH v2 01/14] staging: comedi: daqboard2000: remove commented out code

[Ian Abbott]

Remove some commented out code.  Some of it uses constructs that don't
exist in the driver, and probably come from the source code for the MS
Windows driver.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: added comments to offset and gain values that should be read from
EEPROM, as suggested by Hartley.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 57ab668..63d68fd 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -278,9 +278,7 @@ struct daqboard2000_private {
 
 static void writeAcqScanListEntry(struct comedi_device *dev, u16 entry)
 {
-   /* udelay(4); */
writew(entry & 0x00ff, dev->mmio + acqScanListFIFO);
-   /* udelay(4); */
writew((entry >> 8) & 0x00ff, dev->mmio + acqScanListFIFO);
 }
 
@@ -315,13 +313,9 @@ static void setup_sampling(struct comedi_device *dev, int 
chan, int gain)
word3 = 0;
break;
}
-/*
-  dev->eeprom.correctionDACSE[i][j][k].offset = 0x800;
-  dev->eeprom.correctionDACSE[i][j][k].gain = 0xc00;
-*/
/* These should be read from EEPROM */
-   word2 |= 0x0800;
-   word3 |= 0xc000;
+   word2 |= 0x0800;/* offset */
+   word3 |= 0xc000;/* gain */
writeAcqScanListEntry(dev, word0);
writeAcqScanListEntry(dev, word1);
writeAcqScanListEntry(dev, word2);
-- 
2.8.1

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

[PATCH v2 06/14] staging: comedi: daqboard2000: rename register offset macros

[Ian Abbott]

Rename the macros defining register offsets to avoid CamelCase, and to
use namespace associated with the driver.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
Other CamelCase issues in this patch will be dealt with by later
patches in the series.

v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 112 ++
 1 file changed, 61 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index ceb910d..b068746 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -151,35 +151,35 @@ static const struct comedi_lrange range_daqboard2000_ai = 
{
 /*
  * Register Memory Map
  */
-#define acqControl 0x00/* u16 */
-#define acqScanListFIFO0x02/* u16 */
-#define acqPacerClockDivLow0x04/* u32 */
-#define acqScanCounter 0x08/* u16 */
-#define acqPacerClockDivHigh   0x0a/* u16 */
-#define acqTriggerCount0x0c/* u16 */
-#define acqResultsFIFO 0x10/* u16 */
-#define acqResultsShadow   0x14/* u16 */
-#define acqAdcResult   0x18/* u16 */
-#define dacScanCounter 0x1c/* u16 */
-#define dacControl 0x20/* u16 */
-#define dacFIFO0x24/* s16 */
-#define dacPacerClockDiv   0x2a/* u16 */
-#define refDacs0x2c/* u16 */
-#define dioControl 0x30/* u16 */
-#define dioP3hsioData  0x32/* s16 */
-#define dioP3Control   0x34/* u16 */
-#define calEepromControl   0x36/* u16 */
-#define dacSetting(x)  (0x38 + (x) * 2) /* s16 */
-#define dioP2ExpansionIO8Bit   0x40/* s16 */
-#define ctrTmrControl  0x80/* u16 */
-#define ctrInput(x)(0x88 + (x) * 2) /* s16 */
-#define timerDivisor(x)(0xa0 + (x) * 2) /* u16 */
-#define dmaControl 0xb0/* u16 */
-#define trigControl0xb2/* u16 */
-#define calEeprom  0xb8/* u16 */
-#define acqDigitalMark 0xba/* u16 */
-#define trigDacs   0xbc/* u16 */
-#define dioP2ExpansionIO16Bit(x)   (0xc0 + (x) * 2) /* s16 */
+#define DB2K_REG_ACQ_CONTROL   0x00/* u16 */
+#define DB2K_REG_ACQ_SCAN_LIST_FIFO0x02/* u16 */
+#define DB2K_REG_ACQ_PACER_CLOCK_DIV_LOW   0x04/* u32 */
+#define DB2K_REG_ACQ_SCAN_COUNTER  0x08/* u16 */
+#define DB2K_REG_ACQ_PACER_CLOCK_DIV_HIGH  0x0a/* u16 */
+#define DB2K_REG_ACQ_TRIGGER_COUNT 0x0c/* u16 */
+#define DB2K_REG_ACQ_RESULTS_FIFO  0x10/* u16 */
+#define DB2K_REG_ACQ_RESULTS_SHADOW0x14/* u16 */
+#define DB2K_REG_ACQ_ADC_RESULT0x18/* u16 
*/
+#define DB2K_REG_DAC_SCAN_COUNTER  0x1c/* u16 */
+#define DB2K_REG_DAC_CONTROL   0x20/* u16 */
+#define DB2K_REG_DAC_FIFO  0x24/* s16 */
+#define DB2K_REG_DAC_PACER_CLOCK_DIV   0x2a/* u16 */
+#define DB2K_REG_REF_DACS  0x2c/* u16 */
+#define DB2K_REG_DIO_CONTROL   0x30/* u16 */
+#define DB2K_REG_P3_HSIO_DATA  0x32/* s16 */
+#define DB2K_REG_P3_CONTROL0x34/* u16 */
+#define DB2K_REG_CAL_EEPROM_CONTROL0x36/* u16 */
+#define DB2K_REG_DAC_SETTING(x)(0x38 + (x) * 2) /* s16 
*/
+#define DB2K_REG_DIO_P2_EXP_IO_8_BIT   0x40/* s16 */
+#define DB2K_REG_COUNTER_TIMER_CONTROL 0x80/* u16 */
+#define DB2K_REG_COUNTER_INPUT(x)  (0x88 + (x) * 2) /* s16 */
+#define DB2K_REG_TIMER_DIV(x)  (0xa0 + (x) * 2) /* u16 */
+#define DB2K_REG_DMA_CONTROL   0xb0/* u16 */
+#define DB2K_REG_TRIG_CONTROL  0xb2/* u16 */
+#define DB2K_REG_CAL_EEPROM0xb8/* u16 */
+#define DB2K_REG_ACQ_DIGITAL_MARK  0xba/* u16 */
+#define DB2K_REG_TRIG_DACS 0xbc/* u16 */
+#define DB2K_REG_DIO_P2_EXP_IO_16_BIT(x)   (0xc0 + (x) * 2) /* s16 */
 
 /* 

[PATCH v2 04/14] staging: comedi: daqboard2000: add blank line after struct declaration

[Ian Abbott]

Fix checkpatch issue: "CHECK: Please use a blank line after
function/struct/union/enum declarations".

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
---
v2: Fixed typo in patch description: `black line` --> `blank line`.
---
 drivers/staging/comedi/drivers/daqboard2000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 904de95..cbbeb50 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -264,6 +264,7 @@ struct daq200_boardtype {
const char *name;
int id;
 };
+
 static const struct daq200_boardtype boardtypes[] = {
{"ids2", DAQBOARD2000_SUBSYSTEM_IDS2},
{"ids4", DAQBOARD2000_SUBSYSTEM_IDS4},
-- 
2.8.1

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

Re: [PATCH 06/14] staging: comedi: daqboard2000: rename register offset macros

[Ian Abbott]

On 17/05/16 18:27, Hartley Sweeten wrote:

On Tuesday, May 17, 2016 2:53 AM, Ian Abbott wrote:

Rename the macros defining register offsets to avoid CamelCase, and to
use namespace associated with the driver.

Signed-off-by: Ian Abbott 
---
Other CamelCase issues in this patch will be dealt with by later
patches in the series.
---
  drivers/staging/comedi/drivers/daqboard2000.c | 112 ++
  1 file changed, 61 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index b3b68e8..92ff8f4 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -151,35 +151,35 @@ static const struct comedi_lrange range_daqboard2000_ai = 
{
  /*
   * Register Memory Map
   */
-#define acqControl 0x00/* u16 */
-#define acqScanListFIFO0x02/* u16 */
-#define acqPacerClockDivLow0x04/* u32 */
-#define acqScanCounter 0x08/* u16 */
-#define acqPacerClockDivHigh   0x0a/* u16 */
-#define acqTriggerCount0x0c/* u16 */
-#define acqResultsFIFO 0x10/* u16 */
-#define acqResultsShadow   0x14/* u16 */
-#define acqAdcResult   0x18/* u16 */
-#define dacScanCounter 0x1c/* u16 */
-#define dacControl 0x20/* u16 */
-#define dacFIFO0x24/* s16 */
-#define dacPacerClockDiv   0x2a/* u16 */
-#define refDacs0x2c/* u16 */
-#define dioControl 0x30/* u16 */
-#define dioP3hsioData  0x32/* s16 */
-#define dioP3Control   0x34/* u16 */
-#define calEepromControl   0x36/* u16 */
-#define dacSetting(x)  (0x38 + (x) * 2) /* s16 */
-#define dioP2ExpansionIO8Bit   0x40/* s16 */
-#define ctrTmrControl  0x80/* u16 */
-#define ctrInput(x)(0x88 + (x) * 2) /* s16 */
-#define timerDivisor(x)(0xa0 + (x) * 2) /* u16 */
-#define dmaControl 0xb0/* u16 */
-#define trigControl0xb2/* u16 */
-#define calEeprom  0xb8/* u16 */
-#define acqDigitalMark 0xba/* u16 */
-#define trigDacs   0xbc/* u16 */
-#define dioP2ExpansionIO16Bit(x)   (0xc0 + (x) * 2) /* s16 */
+#define DAQBOARD2000_REG_ACQ_CONTROL   0x00 /* u16 */
+#define DAQBOARD2000_REG_ACQ_SCAN_LIST_FIFO0x02 /* u16 */
+#define DAQBOARD2000_REG_ACQ_PACER_CLOCK_DIV_LOW   0x04 /* u32 */
+#define DAQBOARD2000_REG_ACQ_SCAN_COUNTER  0x08 /* u16 */
+#define DAQBOARD2000_REG_ACQ_PACER_CLOCK_DIV_HIGH  0x0a /* u16 */
+#define DAQBOARD2000_REG_ACQ_TRIGGER_COUNT 0x0c /* u16 */
+#define DAQBOARD2000_REG_ACQ_RESULTS_FIFO  0x10 /* u16 */
+#define DAQBOARD2000_REG_ACQ_RESULTS_SHADOW0x14 /* u16 */
+#define DAQBOARD2000_REG_ACQ_ADC_RESULT0x18 /* u16 */
+#define DAQBOARD2000_REG_DAC_SCAN_COUNTER  0x1c /* u16 */
+#define DAQBOARD2000_REG_DAC_CONTROL   0x20 /* u16 */
+#define DAQBOARD2000_REG_DAC_FIFO  0x24 /* s16 */
+#define DAQBOARD2000_REG_DAC_PACER_CLOCK_DIV   0x2a /* u16 */
+#define DAQBOARD2000_REG_REF_DACS  0x2c /* u16 */
+#define DAQBOARD2000_REG_DIO_CONTROL   0x30 /* u16 */
+#define DAQBOARD2000_REG_P3_HSIO_DATA  0x32 /* s16 */
+#define DAQBOARD2000_REG_P3_CONTROL0x34 /* u16 */
+#define DAQBOARD2000_REG_CAL_EEPROM_CONTROL0x36 /* u16 */
+#define DAQBOARD2000_REG_DAC_SETTING(x)(0x38 + (x) * 2) /* s16 
*/
+#define DAQBOARD2000_REG_DIO_P2_EXP_IO_8_BIT   0x40 /* s16 */
+#define DAQBOARD2000_REG_COUNTER_TIMER_CONTROL 0x80 /* u16 */
+#define DAQBOARD2000_REG_COUNTER_INPUT(x)  (0x88 + (x) * 2) /* s16 */
+#define DAQBOARD2000_REG_TIMER_DIV(x)  (0xa0 + (x) * 2) /* u16 */
+#define DAQBOARD2000_REG_DMA_CONTROL   0xb0 /* u16 */
+#define DAQBOARD2000_REG_TRIG_CONTROL  0xb2 /* u16 */
+#define DAQBOARD2000_REG_CAL_EEPROM0xb8 /* u16 */
+#define DAQBOARD2000_REG_ACQ_DIGITAL_MARK  0xba /* u16 */
+#define DAQBOARD2000_REG_TRIG_DACS 0xbc /* u16 */
+#define DAQBOARD2000_REG_DIO_P2_EXP_IO_16_BIT(x) (0xc0 + (x) * 2) /* s16 */


Any chance we can shorten the namespace prefix? It's not a big deal but
the DAQBOARD2000_ is 

Re: [PATCH 14/14] staging: comedi: daqboard2000: prefer usleep_range()

[Ian Abbott]

On 17/05/16 18:42, Hartley Sweeten wrote:

On Tuesday, May 17, 2016 2:53 AM, Ian Abbott wrote:

The checkpatch.pl warns about two `udelay(x)` calls, one of 100
microseconds, and one of 10 microseconds.  The 100 microseconds one is
used when waiting for FPGA to become ready to accept firmware, and is
not that critical, so replace it with a call to `usleep_range(100,
1000)`.  The 10 microseconds one is called as each 16-bit word of
firmware data is written.  A longer sleep would slow down firmware
loading, so leave it alone.


The firmware blob in comedi-nonfree-firmware/daqboard2000 is
41236 bytes or 20618 words. With the 10 microsecond delay for
each word to total delay time is only 0.0206 seconds. I don't think a
small usleep_range() would slow down the firmware loading by much.
How about usleep_range(10, 20)?

Regards,
Hartley


Okay.

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 05/14] staging: comedi: daqboard2000: rename serial EEPROM register macros

[Ian Abbott]

On 17/05/16 18:22, Hartley Sweeten wrote:

On Tuesday, May 17, 2016 2:53 AM, Ian Abbott wrote:

Rename the macros defining values for the Serial EEPROM Control Register
to avoid CamelCase.

Signed-off-by: Ian Abbott 
---
  drivers/staging/comedi/drivers/daqboard2000.c | 26 +-
  1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index fde0924..b3b68e8 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -116,12 +116,12 @@
  #define DAQBOARD2000_SUBSYSTEM_IDS4   0x0004  /* Daqboard/2000 - 4 Dacs */


Ian,

This board uses a PLX-9080 chip for the PCI interface.

If would be better to include  and use the register/bit defines
to remove the magic numbers.


I was planning to do that, but want to massage plx9080.h a bit first.



The only PLX register used is PLX_CONTROL_REG (0x6c).


  /* Initialization bits for the Serial EEPROM Control Register */
-#define DAQBOARD2000_SECRProgPinHi  0x8001767e
-#define DAQBOARD2000_SECRProgPinLo  0x8000767e
-#define DAQBOARD2000_SECRLocalBusHi 0xc000767e
-#define DAQBOARD2000_SECRLocalBusLo 0x8000767e
-#define DAQBOARD2000_SECRReloadHi   0xa000767e
-#define DAQBOARD2000_SECRReloadLo   0x8000767e
+#define DAQBOARD2000_SECR_PROG_PIN_HI  0x8001767e
+#define DAQBOARD2000_SECR_PROG_PIN_LO  0x8000767e
+#define DAQBOARD2000_SECR_LOCAL_BUS_HI 0xc000767e
+#define DAQBOARD2000_SECR_LOCAL_BUS_LO 0x8000767e
+#define DAQBOARD2000_SECR_RELOAD_HI0xa000767e
+#define DAQBOARD2000_SECR_RELOAD_LO0x8000767e


These "Initialization bits" are just various combinations of the
PLX_CONTROL_REG bit defines (CTL_*) to toggle the various
EEPROM bits.


Yes, it would be better to read the control register and only change the 
bits of interest.


I plan to do some more work on this driver.  This series is mainly to 
get the checkpatch warnings (well, most of them) out of the way first.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 01/14] staging: comedi: daqboard2000: remove commented out code

[Ian Abbott]

On 17/05/16 18:14, Hartley Sweeten wrote:

On Tuesday, May 17, 2016 2:53 AM, Ian Abbott wrote:

Remove some commented out code.  Some of it uses constructs that don't
exist in the driver, and probably come from the source code for the MS
Windows driver.

Signed-off-by: Ian Abbott 
---
  drivers/staging/comedi/drivers/daqboard2000.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c 
b/drivers/staging/comedi/drivers/daqboard2000.c
index 57ab668..8c9a024 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c

[snip]

@@ -315,10 +313,6 @@ static void setup_sampling(struct comedi_device *dev, int 
chan, int gain)
word3 = 0;
break;
}
-/*
-  dev->eeprom.correctionDACSE[i][j][k].offset = 0x800;
-  dev->eeprom.correctionDACSE[i][j][k].gain = 0xc00;
-*/
/* These should be read from EEPROM */
word2 |= 0x0800;
word3 |= 0xc000;


It might be a good idea to add a comment about the magic 0x0800 and 0xc000 
values:


word2 |= 0x0800;/* offset */
word3 |= 0xc000;/* gain */


Fair enough.


Wish I could find a register map for this board. I sent an email to Measurement 
Computing
to see if one is available.


I think the board was made by IOTech and added to Measurement 
Computing's catalog, and the Windows driver appears to have been done by 
IOTech too.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] Staging: comedi: fix CHECK: Prefer using the BIT macro issues in pcmmio.c

[Ian Abbott]

On 18/05/16 05:57, Ravishankar Karkala Mallikarjunayya wrote:

This patch Replace all occurences of (1<
---
  drivers/staging/comedi/drivers/pcmmio.c | 40 -
  1 file changed, 20 insertions(+), 20 deletions(-)



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] Staging: comedi: fix type issue in s626.c

[Ian Abbott]

On 17/05/16 11:13, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the s626.c file that fixes up a type issues
found by the checkpatch.pl tool.

i.e Prefer kernel type 'u8' over 'uint8_t'
 Prefer kernel type 'u16' over 'uint16_t'
 Prefer kernel type 'u32' over 'uint32_t'
 Prefer kernel type 's16' over 'int16_t'
 Prefer kernel type 's32' over 'int32_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/s626.c | 152 +-
  1 file changed, 76 insertions(+), 76 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 0e1f535..c91ed53 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -75,7 +75,7 @@ struct s626_buffer_dma {
  };

  struct s626_private {
-   uint8_t ai_cmd_running; /* ai_cmd is running */
+   u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /*
 * time between samples in
 * units of the timer
@@ -85,11 +85,11 @@ struct s626_private {
 * time between conversion in
 * units of the timer
 */
-   uint16_t counter_int_enabs; /*
+   u16 counter_int_enabs;  /*
 * counter interrupt enable mask
 * for MISC2 register
 */
-   uint8_t adc_items;  /* number of items in ADC poll list */
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /*
 * DMA buffer used to hold ADC (RPS1)
 * program
@@ -98,13 +98,13 @@ struct s626_private {
 * DMA buffer used to receive ADC data
 * and hold DAC data
 */
-   uint32_t *dac_wbuf; /*
+   u32 *dac_wbuf;  /*
 * pointer to logical adrs of DMA buffer
 * used to hold DAC data
 */
-   uint16_t dacpol;/* image of DAC polarity register */
-   uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /*
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /*
 * I2C device address for onboard EEPROM
 * (board rev dependent)
 */


This part of the patch fails to apply after your "[PATCH 1/2] Staging: 
comedi: Fix WARNING issue in s626.c" patch, because that patch already 
changed some of the types of the structure members.


At this point, it's probably best if you start again, and repost an 
updated, and self-consistent, version 2 of your original series of 4 
patches, tagged as "[PATCH v2 1/4]" etc.  At the moment, everything is 
too messed up.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] Staging: comedi: Fix WARNING issue in s626.c

[Ian Abbott]

On 17/05/16 11:13, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the s626.c file that fixes up a Block comments
issues found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/s626.c | 60 +++
  1 file changed, 40 insertions(+), 20 deletions(-)




I guess this is patch is a replacement for your earlier
"[PATCH 1/4] Staging: comedi: Fix WARNING issue in s626.c". The usual 
practice is to keep the same patch numbering and to add a "v2" like 
this: "[PATCH v2 1/4] Staging: comedi: Fix WARNING issue in s626.c". 
Then add a comment below the "---" line describing what has changed in 
version 2 of the patch. Remember that Greg and the other higher up 
maintainers have to sift through hundreds (or at least a large number) 
of patches a day, so the easier you make it for them, the better.



diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index c5e0863..0e1f535 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -76,24 +76,38 @@ struct s626_buffer_dma {

  struct s626_private {
uint8_t ai_cmd_running; /* ai_cmd is running */
-   unsigned int ai_sample_timer;   /* time between samples in
-* units of the timer */
+   unsigned int ai_sample_timer;   /*
+* time between samples in
+* units of the timer
+*/
int ai_convert_count;   /* conversion counter */
-   unsigned int ai_convert_timer;  /* time between conversion in
-* units of the timer */
-   uint16_t counter_int_enabs; /* counter interrupt enable mask
-* for MISC2 register */
+   unsigned int ai_convert_timer;  /*
+* time between conversion in
+* units of the timer
+*/
+   u16 counter_int_enabs;  /*
+* counter interrupt enable mask
+* for MISC2 register
+*/
uint8_t adc_items;  /* number of items in ADC poll list */
-   struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
-* program */
-   struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
-* and hold DAC data */
-   uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
-* used to hold DAC data */
+   struct s626_buffer_dma rps_buf; /*
+* DMA buffer used to hold ADC (RPS1)
+* program
+*/
+   struct s626_buffer_dma ana_buf; /*
+* DMA buffer used to receive ADC data
+* and hold DAC data
+*/
+   u32 *dac_wbuf;  /*
+* pointer to logical adrs of DMA buffer
+* used to hold DAC data
+*/
uint16_t dacpol;/* image of DAC polarity register */
uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
-* (board rev dependent) */
+   u32 i2c_adrs;   /*
+* I2C device address for onboard EEPROM
+* (board rev dependent)
+*/
  };


There's something weird going on above.  In addition to reformatting the 
comments, it's also replacing the type descriptors of some of the 
members (using `u32` instead of `uint32_t` etc.).  It looks like bits of 
the patches from your earlier series have crept into this one.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: Fix a unsigned warning issue

[Ian Abbott]

On 17/05/16 17:53, Amit Ghadge wrote:

This is a patch to the quatech_daqp_cs.c file that fixes by using
unsigned int instead of unsigned, following warning found by checkpatch.
* WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Amit Ghadge 
---
  drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c 
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index e9e4313..802f51e 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -643,7 +643,7 @@ static int daqp_ao_insn_write(struct comedi_device *dev,
outb(0, dev->iobase + DAQP_AUX_REG);

for (i = 0; i > insn->n; i++) {
-   unsigned val = data[i];
+   unsigned int val = data[i];
int ret;

/* D/A transfer rate is about 8ms */



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] Staging: comedi: Fix WARNING issue in dt2801.c

[Ian Abbott]

On 17/05/16 11:13, Ravishankar Karkala Mallikarjunayya wrote:

This is a patch to the dt2801.c file that fixes up a Block comments
issues found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
  drivers/staging/comedi/drivers/dt2801.c | 95 +
  1 file changed, 50 insertions(+), 45 deletions(-)


Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel