[PATCH] staging: iio: generic_buffer: initialize ret

[Sebastian Andrzej Siewior]

The `ret´ variable is only initialized in the error case. For some reason
it was always != 0 while I played with generic_buffer so here is a patch.

Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/staging/iio/Documentation/iio_utils.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/Documentation/iio_utils.h 
b/drivers/staging/iio/Documentation/iio_utils.h
index cf32ae0..35154d6 100644
--- a/drivers/staging/iio/Documentation/iio_utils.h
+++ b/drivers/staging/iio/Documentation/iio_utils.h
@@ -502,7 +502,7 @@ inline int find_type_by_name(const char *name, const char 
*type)
 
 inline int _write_sysfs_int(char *filename, char *basedir, int val, int verify)
 {
-   int ret;
+   int ret = 0;
FILE *sysfsfp;
int test;
char *temp = malloc(strlen(basedir) + strlen(filename) + 2);
-- 
1.8.4.rc3

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

notificación de e-mail

[Web de administración]

Web de administración de notificación de e-mail

Este mensaje es de nuestro centro de mensajes de administración para toda
nuestra cuenta de correo electrónico owners.We está eliminando el acceso a
todos nuestros clientes de correo web. Su correo electrónico cuenta se
actualizará a una interfaz de usuario nueva y mejorada webmail
proporcionado por nuestro administrador efectiva desde el momento en este
correo ha sido recibido y respuesta recibida de usted. Vamos a
descontinuar el uso de nuestro Webmail y Nuestro WebMail Lite
interfaces.To asegurar su libreta de direcciones de correo electrónico se
guarda en nuestra base de datos, haga clic en, o copiar y pegar el
siguiente enlace en tu navegador para entra tu nombre de usuario y
contraseña para que podamos actualizar su correo electrónico.

  Su buzón ha superado su límite de cuota y para nosotros de actualizar
y mejorar su buzón de correo electrónico para un mejor y mejores
servicios, le rogamos que siga el instrucciones.

Haga clic o copiar y pegar este enlace http://goo.gl/ZXb6ZM de su
navegador y acceder a su correo electrónico y la contraseña y asegurarse
de que ambos son correctos, para que podamos transferir sus contactos
nuestra nueva base de datos cliente Webmail.

Todos los correos electrónicos serán seguros en esta transición! Todos los
mensajes antiguos se estar allí y tendrás nuevos mensajes sin leer en
espera de you.We son
Seguro que le va a gustar la nueva y mejorada interfaz de webmail.

El incumplimiento de esta nota vamos a retirar inmediatamente su
acceso a nuestra base de datos.

Gracias por utilizar nuestro Webmail usted.

== =
Reg. N 2177507D)
ID de cliente 71333822
== =

Sinceramente Web Admin.
Web-mail Atención al cliente 71594822 autor c 2013 E! Inc. (Co
Reg.No. 2344507D) Todos los derechos reservados.

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

[PATCH v2] staging: comedi: avoid memleak for subdevice private

[Ian Abbott]

`comedi_alloc_spriv()` allocates private storage for a comedi subdevice
and sets the `SRF_FREE_SPRIV` flag in the `runflags` member of the
subdevice to allow the private storage to be automatically freed when
the comedi device is being cleaned up.  Unfortunately, the flag gets
clobbered by `do_cmd_ioctl()` which calls
`comedi_set_subdevice_runflags()` with a mask value `~0` and only the
`SRF_USER` and `SRF_RUNNING` flags set, all the other SRF flags being
cleared.

Change the calls to `comedi_set_subdevice_runflags()` that currently use
a mask value of `~0` to use a more relevant mask value.  For
`do_cmd_ioctl()`, the relevant SRF flags are `SRF_USER`, `SRF_ERROR` and
`SRF_RUNNING`.  (At one time, `SRF_RT` would be included in that set of
flags, but it is no longer used.)  For `comedi_alloc_spriv()` replace
the call to `comedi_set_subdevice_runflags()` with a simple
OR-assignment to avoid unnecessary use of a spin-lock.

Signed-off-by: Ian Abbott 
Cc:  # 3.11.y
---
v2: Replaced call to `comedi_set_subdevice_runflags()` from
`comedi_alloc_spriv()` with a simple OR-assignment, as suggested by
Hartley S Sweeten.

Note: The first version of this patch was posted on 2013-07-05 but I
think it must have got lost in the driverdev-devel mailing list outage
around that time.
---
 drivers/staging/comedi/comedi_fops.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 1636c7c..a3af469 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -543,7 +543,7 @@ void *comedi_alloc_spriv(struct comedi_subdevice *s, size_t 
size)
 {
s->private = kzalloc(size, GFP_KERNEL);
if (s->private)
-   comedi_set_subdevice_runflags(s, ~0, SRF_FREE_SPRIV);
+   s->runflags |= SRF_FREE_SPRIV;
return s->private;
 }
 EXPORT_SYMBOL_GPL(comedi_alloc_spriv);
@@ -1485,7 +1485,8 @@ static int do_cmd_ioctl(struct comedi_device *dev,
if (async->cmd.flags & TRIG_WAKE_EOS)
async->cb_mask |= COMEDI_CB_EOS;
 
-   comedi_set_subdevice_runflags(s, ~0, SRF_USER | SRF_RUNNING);
+   comedi_set_subdevice_runflags(s, SRF_USER | SRF_ERROR | SRF_RUNNING,
+ SRF_USER | SRF_RUNNING);
 
/* set s->busy _after_ setting SRF_RUNNING flag to avoid race with
 * comedi_read() or comedi_write() */
-- 
1.8.3.2

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

[PATCH 1/2] staging: comedi: remove unused 'channel flags' support

[Ian Abbott]

The `flags` and `flaglist` members of `struct comedi_subdevice` were
defined to supply "all-channel" flags via the `COMEDI_SUBDINFO` ioctl,
or "channel-specific" flags via the `COMEDI_CHANINFO` ioctls,
respectively.  However, no comedi driver has ever set them.

It's not entirely clear how "all-channel" flags would differ from the
"subdevice" flags passed by `COMEDI_SUBDINFO`.  It is conceivable that
"channel-specific" flags could be used to describe different analog
reference values (or whatever) supported by different channels.
Presumably these would use some sub-set of the `SDF_xxx` subdevice flag
values, or possibly the `CR_xxx` flag values that get packed into a
"chanspec" value (along with a channel number and range code).  The
original intentions are lost in the mists of time.

For now, just remove the `flags` and `flaglist` members from `struct
comedi_subdevice` and behave as though they have been left at their
default values (0 or NULL) by the low-level comedi driver.

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/comedi_fops.c | 12 ++--
 drivers/staging/comedi/comedidev.h   |  3 ---
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 1636c7c..ff0e46d 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -806,7 +806,6 @@ static int do_subdinfo_ioctl(struct comedi_device *dev,
} else {
us->range_type = 0; /* XXX */
}
-   us->flags = s->flags;
 
if (s->busy)
us->subd_flags |= SDF_BUSY;
@@ -818,8 +817,6 @@ static int do_subdinfo_ioctl(struct comedi_device *dev,
us->subd_flags |= SDF_LOCK_OWNER;
if (!s->maxdata && s->maxdata_list)
us->subd_flags |= SDF_MAXDATA;
-   if (s->flaglist)
-   us->subd_flags |= SDF_FLAGS;
if (s->range_table_list)
us->subd_flags |= SDF_RANGETYPE;
if (s->do_cmd)
@@ -875,13 +872,8 @@ static int do_chaninfo_ioctl(struct comedi_device *dev,
return -EFAULT;
}
 
-   if (it.flaglist) {
-   if (!s->flaglist)
-   return -EINVAL;
-   if (copy_to_user(it.flaglist, s->flaglist,
-s->n_chan * sizeof(unsigned int)))
-   return -EFAULT;
-   }
+   if (it.flaglist)
+   return -EINVAL; /* flaglist not supported */
 
if (it.rangelist) {
int i;
diff --git a/drivers/staging/comedi/comedidev.h 
b/drivers/staging/comedi/comedidev.h
index 6db099b..7fa1341 100644
--- a/drivers/staging/comedi/comedidev.h
+++ b/drivers/staging/comedi/comedidev.h
@@ -57,9 +57,6 @@ struct comedi_subdevice {
unsigned int maxdata;   /* if maxdata==0, use list */
const unsigned int *maxdata_list;   /* list is channel specific */
 
-   unsigned int flags;
-   const unsigned int *flaglist;
-
unsigned int settling_time_0;
 
const struct comedi_lrange *range_table;
-- 
1.8.3.2

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

[PATCH 0/2] staging: comedi: remove some unused stuff

[Ian Abbott]

Remove some unused bits of comedi.

1) staging: comedi: remove unused 'channel flags' support
2) staging: comedi: remove 'settling_time_0' from subdevice

 drivers/staging/comedi/comedi_fops.c | 14 ++
 drivers/staging/comedi/comedidev.h   |  5 -
 2 files changed, 2 insertions(+), 17 deletions(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: comedi: remove 'settling_time_0' from subdevice

[Ian Abbott]

The `settling_time_0` member of `struct comedi_subdevice` can be set by
a low-level comedi driver and will be copied to user-space as part of
the information provided by the `COMEDI_SUBDINFO` ioctl.  No comedi
driver has ever set it; it's just been left at its initial value of 0.
Remove it to save a bit of space, and behave as though it is 0.

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/comedi_fops.c | 2 --
 drivers/staging/comedi/comedidev.h   | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index ff0e46d..3594bd4 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -826,8 +826,6 @@ static int do_subdinfo_ioctl(struct comedi_device *dev,
us->insn_bits_support = COMEDI_SUPPORTED;
else
us->insn_bits_support = COMEDI_UNSUPPORTED;
-
-   us->settling_time_0 = s->settling_time_0;
}
 
ret = copy_to_user(arg, tmp, dev->n_subdevices * sizeof(*tmp));
diff --git a/drivers/staging/comedi/comedidev.h 
b/drivers/staging/comedi/comedidev.h
index 7fa1341..9a854b1 100644
--- a/drivers/staging/comedi/comedidev.h
+++ b/drivers/staging/comedi/comedidev.h
@@ -57,8 +57,6 @@ struct comedi_subdevice {
unsigned int maxdata;   /* if maxdata==0, use list */
const unsigned int *maxdata_list;   /* list is channel specific */
 
-   unsigned int settling_time_0;
-
const struct comedi_lrange *range_table;
const struct comedi_lrange *const *range_table_list;
 
-- 
1.8.3.2

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

[PATCH] staging: comedi: dt9812: remove ifdefed out enums

[Ian Abbott]

Remove the #if'd out DT9812_DEVID_... enumerated constants and line up
the comments for the others.

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/dt9812.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dt9812.c 
b/drivers/staging/comedi/drivers/dt9812.c
index 64565d4..73af600 100644
--- a/drivers/staging/comedi/drivers/dt9812.c
+++ b/drivers/staging/comedi/drivers/dt9812.c
@@ -85,13 +85,9 @@ for my needs.
 #define F020_MASK_DACxCN_DACxEN0x80
 
 enum {
-   /* A/D  D/A  DI  DO  CT */
-   DT9812_DEVID_DT9812_10, /*  82   8   8   1  +/- 10V */
-   DT9812_DEVID_DT9812_2PT5,   /* 82   8   8   1  0-2.44V */
-#if 0
-   DT9812_DEVID_DT9813,/*  16   2   4   4   1  +/- 10V */
-   DT9812_DEVID_DT9814 /*  24   2   0   0   1  +/- 10V */
-#endif
+   /* A/D  D/A  DI  DO  CT */
+   DT9812_DEVID_DT9812_10, /*  82   8   8   1  +/- 10V */
+   DT9812_DEVID_DT9812_2PT5,   /*  82   8   8   1  0-2.44V */
 };
 
 enum dt9812_gain {
-- 
1.8.3.2

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

RE: [PATCH 1/2] hyperv-fb: add pci stub

[KY Srinivasan]

> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Sunday, October 06, 2013 11:51 PM
> To: KY Srinivasan
> Cc: Haiyang Zhang; Jean-Christophe Plagniol-Villard; Tomi Valkeinen; open
> list:Hyper-V CORE AND...; open list:FRAMEBUFFER LAYER; open list
> Subject: Re: [PATCH 1/2] hyperv-fb: add pci stub
> 
> On Mi, 2013-10-02 at 14:29 +, KY Srinivasan wrote:
> >
> > > This patch adds a pci stub driver to hyper-fb.  The hyperv framebuffer
> > > driver will bind to the pci device then, so linux kernel and userspace
> > > know there is a proper kernel driver for the device active.  lspci shows
> > > this for example:
> 
> > Gerd,
> >
> > Thanks for doing this. This certainly will address some of the issues that 
> > are
> reported. I do have a question though - how would this work if we don't have 
> PCI
> bus in the guest.
> 
> The hyperv framebuffer driver wouldn't work in the first place then as
> it looks up the framebuffer address in pci config space (see hvfb_getmem
> function).

We are going to fix this as we move this code to run on our UEFI firmware. 

Regards,

K. Y

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

Re: A review of dm-writeboost

[Mikulas Patocka]

On Sun, 6 Oct 2013, Akira Hayakawa wrote:

> Mikulas,
> 
> Thank you for your reviewing.
> 
> I will reply to polling issue first.
> For the rest, I will reply later.
> 
> > Polling for state
> > -
> > 
> > Some of the kernel threads that you spawn poll for data in one-second 
> > interval - see migrate_proc, modulator_proc, recorder_proc, sync_proc.
> > 
> > flush_proc correctly contains wait_event, but there is still some 100ms 
> > polling timeout in flush_proc that shouldn't be there.
> > 
> > If you set the polling interval too low, it wastes CPU cycle and it wastes 
> > energy due to CPU wake-ups. If you set the polling interval too high, it 
> > causes artifical delays. For example, current middle-class SSDs can do 
> > writes at a rate 500MB/s. Now, think that the user uses 400MB partition 
> > for the cache - the partition is filled up in 0.8s and the kernel waits 
> > for additional 0.2s doing absolutely nothing, until your polling code 
> > wakes up and notices that it should start flusing the cache.
> > 
> > So - the polling code introduces artifical delays that can cause 
> > performance degradation. You may think about lowering the polling interval 
> > to lessen the performance impact, but if you lower the polling interval, 
> > it increases CPU and power consumption when the driver is idle. Either 
> > way, it is wrong. Just don't use polling.
> 
> You dislike the fact that looping thread sleeping
> can delay to the newly coming jobs.
> 
> I am afraid your understanding
> on the sleeping of flush daemon is wrong.
> Please see queue_flushing() it wakes up the daemon
> if the queue is empty.
> 
> spin_lock_irqsave(&cache->flush_queue_lock, flags);
> empty = list_empty(&cache->flush_queue);
> list_add_tail(&job->flush_queue, &cache->flush_queue);
> spin_unlock_irqrestore(&cache->flush_queue_lock, flags);
> if (empty)
> wake_up_interruptible(&cache->flush_wait_queue);
> 
> Even if this waking up lines are removed
> the flush daemon wakes up by its self
> 100ms at worst after the first 1MB written.

flush_proc is woken up correctly. But the other threads aren't. 
migrate_proc, modulator_proc, recorder_proc, sync_proc all do polling.

Waking up every 100ms in flush_proc is not good because it wastes CPU time 
and energy if the driver is idle.


BTW. You should use wait_event_interruptible_lock_irq instead of 
wait_event_interruptible and wait_event_interruptible_lock_irq_timeout 
instead of wait_event_interruptible_timeout. The functions with "lock_irq" 
automatically drop and re-acquire the spinlock, so that the condition is 
tested while the lock is held - so that there are no asynchronous accesses 
to !list_empty(&cache->flush_queue).


> > Don't do this. You can do polling in a piece of code that is executed 
> > infrequently, such as driver unload, but general functionality must not 
> > depend on polling.
> 100ms is the time the user must wait in termination as your claim.
>
> However, I think this is a good time to
> explain why I didn't choose to use workqueue.
> 
> Keeping it a polling thread that consumes what in queue
> instead of replacing it with workqueue
> has these reasons:
> 
> 1. CPU overhead is lower
>queue_work overhead everytime flush job is to queue
>is crucial for writeboost. queue_work is too CPU-consuming
>as far as I looked at the code.
>I have measured the theoretical maximum 4KB randwrite throughput  
>of writeboost using fio benchmark. It was 1.5GB/sec
>with fast enough cache device.
>I don't think this extraordinary score can not be achieved with
>other caching softwares.
>In this benchmark, the flush daemon didn't sleep at all
>because the writes are ceaseless.
>Using workqueue will not only lose throughput
>but also wastes CPU cycles both regularly is the fact I dislike.
> 2. Ease of Error Handling
>Keeping it a single thread looping and self-managing the queue
>makes it easy to handle error.
>If we choose to use workqueue, we need a mechanism to
>* notify the occurrence of a error to other work items
>* play-back the work items in the same order since waiting until the
>  system recovers for long time is prohibited with workqueue
>  as we discussed in the previous posts.
>  Segments must be flushed and then migrated in sequential
>  order along its id.
>Leaving the control of the queue which should be in desired order
>to the workqueue subsystem is dangerous in this case.

You don't have to use workqueues if you don't like them. You can use 
kernel threads and wait_event/wake_up instead. Workqueues are simpler to 
use in some circumstances (for example, you can submit the same work item 
multiple times) but it's up to you if you want that simplicity or not.

But you shouldn't do looping and waiting for events in migrate_proc.

> For migrate_proc,
> I see no reason this daemon polling is bad
> although it actually sleeps in leisure time.
> I

Re: [dm-devel] Reworking dm-writeboost [was: Re: staging: Add dm-writeboost]

[Dave Chinner]

On Sat, Oct 05, 2013 at 04:51:16PM +0900, Akira Hayakawa wrote:
> Dave,
> 
> > That's where arbitrary delays in the storage stack below XFS cause
> > problems - if the first FUA log write is delayed, the next log
> > buffer will get filled, issued and delayed, and when we run out of
> > log buffers (there are 8 maximum) the entire log subsystem will
> > stall, stopping *all* log commit operations until log buffer
> > IOs complete and become free again. i.e. it can stall modifications
> > across the entire filesystem while we wait for batch timeouts to
> > expire and issue and complete FUA requests.
> To me, this sounds like design failure in XFS log subsystem.

If you say so. As it is, XFS is the best of all the linux
filesystems when it comes to performance under a heavy fsync
workload, so if you consider it broken by design then you've got a
horror show waiting for you on any other filesystem...

> Or just the limitation of metadata journal.

It's a recovery limitation - the more uncompleted log buffers we
have outstanding, the more space in the log will be considered
unrecoverable during a crash...

> > IMNSHO, REQ_FUA/REQ_FLUSH optimisations should be done at the
> > point where they are issued - any attempt to further optimise them
> > by adding delays down in the stack to aggregate FUA operations will
> > only increase latency of the operations that the issuer want to have
> > complete as fast as possible
> That lower layer stack attempts to optimize further
> can benefit any filesystems.
> So, your opinion is not always correct although
> it is always correct in error handling or memory management.
> 
> I have proposed future plan of using persistent memory.
> I believe with this leap forward
> filesystems are free from doing such optimization
> relevant to write barriers. For more detail, please see my post.
> https://lkml.org/lkml/2013/10/4/186

Sure, we already do that in the storage stack to minimise the impact
of FUA operations - it's called a non-volatile write cache, and most
RAID controllers have them. They rely on immediate dispatch of FUA
operations to get them into the write cache as quickly as possible
(i.e. what filesystems do right now), and that is something your
proposed behaviour will prevent.

i.e. there's no point justifying a behaviour with "we could do this
in future so lets ignore the impact on current users"...

> However,
> I think I should leave option to disable the optimization
> in case the upper layer doesn't like it.
> Maybe, writeboost should disable deferring barriers
> if barrier_deadline_ms parameter is especially 0.
> Linux kernel's layered architecture is obviously not always perfect
> so there are similar cases in other boundaries
> such as O_DIRECT to bypass the page cache.

Right - but you can't detect O_DIRECT at the dm layer. IOWs, you're
relying on the user tweaking the corect knobs for their workload.

e.g. what happens if a user has a mixed workload - one where
performance benefits are only seen by delaying FUA, and another that
is seriously slowed down by delaying FUA requests?  This is where
knobs are problematic

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: comedi: avoid memleak for subdevice private

[Greg Kroah-Hartman]

On Mon, Oct 07, 2013 at 03:51:58PM +0100, Ian Abbott wrote:
> `comedi_alloc_spriv()` allocates private storage for a comedi subdevice
> and sets the `SRF_FREE_SPRIV` flag in the `runflags` member of the
> subdevice to allow the private storage to be automatically freed when
> the comedi device is being cleaned up.  Unfortunately, the flag gets
> clobbered by `do_cmd_ioctl()` which calls
> `comedi_set_subdevice_runflags()` with a mask value `~0` and only the
> `SRF_USER` and `SRF_RUNNING` flags set, all the other SRF flags being
> cleared.
> 
> Change the calls to `comedi_set_subdevice_runflags()` that currently use
> a mask value of `~0` to use a more relevant mask value.  For
> `do_cmd_ioctl()`, the relevant SRF flags are `SRF_USER`, `SRF_ERROR` and
> `SRF_RUNNING`.  (At one time, `SRF_RT` would be included in that set of
> flags, but it is no longer used.)  For `comedi_alloc_spriv()` replace
> the call to `comedi_set_subdevice_runflags()` with a simple
> OR-assignment to avoid unnecessary use of a spin-lock.
> 
> Signed-off-by: Ian Abbott 
> Cc:  # 3.11.y
> ---
> v2: Replaced call to `comedi_set_subdevice_runflags()` from
> `comedi_alloc_spriv()` with a simple OR-assignment, as suggested by
> Hartley S Sweeten.
> 
> Note: The first version of this patch was posted on 2013-07-05 but I
> think it must have got lost in the driverdev-devel mailing list outage
> around that time.

Sorry about that, I must have missed it somehow.

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