[no subject]

[Alfred Cheuk Yu Chow]

Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central,
Hong Kong. I have a business proposal of $ 38,980,369.00.

All confirmable documents to back up the claims will be made available
to you prior to your acceptance and as soon as I receive your return
mail.

Best Regards,
Alfred Chow.





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

Re: [PATCH 41/80] staging: lustre: lmv: separate master object with master stripe

[James Simmons]

> > +static inline bool
> > +lsm_md_eq(const struct lmv_stripe_md *lsm1, const struct lmv_stripe_md 
> > *lsm2)
> > +{
> > +   int idx;
> > +
> > +   if (lsm1->lsm_md_magic != lsm2->lsm_md_magic ||
> > +   lsm1->lsm_md_stripe_count != lsm2->lsm_md_stripe_count ||
> > +   lsm1->lsm_md_master_mdt_index != lsm2->lsm_md_master_mdt_index ||
> > +   lsm1->lsm_md_hash_type != lsm2->lsm_md_hash_type ||
> > +   lsm1->lsm_md_layout_version != lsm2->lsm_md_layout_version ||
> > +   !strcmp(lsm1->lsm_md_pool_name, lsm2->lsm_md_pool_name))
> > +   return false;
> 
> Hi James and all,
>  This patch (8f18c8a48b736c2f in linux) is different from the
>  corresponding patch in lustre-release (60e07b972114df).
> 
> In that patch, the last clause in the 'if' condition is
> 
> +   strcmp(lsm1->lsm_md_pool_name,
> + lsm2->lsm_md_pool_name) != 0)
> 
> Whoever converted it to "!strcmp()" inverted the condition.  This is a
> perfect example of why I absolutely *loathe* the "!strcmp()" construct!!
> 
> This causes many tests in the 'sanity' test suite to return
> -ENOMEM (that had me puzzled for a while!!).
> This seems to suggest that no-one has been testing the mainline linux
> lustre.
> It also seems to suggest that there is a good chance that there
> are other bugs that have crept in while no-one has really been caring.
> Given that the sanity test suite doesn't complete for me, but just
> hangs (in test_27z I think), that seems particularly likely.
> 
> 
> So my real question - to anyone interested in lustre for mainline linux
> - is: can we actually trust this code at all?
> I'm seriously tempted to suggest that we just
>   rm -r drivers/staging/lustre
> 
> drivers/staging is great for letting the community work on code that has
> been "thrown over the wall" and is not openly developed elsewhere, but
> that is not the case for lustre.  lustre has (or seems to have) an open
> development process.  Having on-going development happen both there and
> in drivers/staging seems a waste of resources.
> 
> Might it make sense to instead start cleaning up the code in
> lustre-release so as to make it meet the upstream kernel standards.
> Then when the time is right, the kernel code can be moved *out* of
> lustre-release and *in* to linux.  Then development can continue in
> Linux (just like it does with other Linux filesystems).
> 
> An added bonus of this is that there is an obvious path to getting
> server support in mainline Linux.  The current situation of client-only
> support seems weird given how interdependent the two are.
> 
> What do others think?  Is there any chance that the current lustre in
> Linux will ever be more than a poor second-cousin to the external
> lustre-release.  If there isn't, should we just discard it now and move
> on?

If you think that the OpenSFS/Intel branch (lustre-release) is the land
of milk and honey you are very wrong. Take for example the UAPI header
cleanup I push to the linux client several months ago. That work took
5 years to complete. I had to complete that work in the Intel branch
since it impacted our tools. This isn't the only example. I worked along
side Intel for increasing striping of a file to more then the 160 stripe
limit Lustre use to have. That work took 3 years to complete. If the
patch is more than one line it will normally take 1 to 2 months to land.
It is common to have patches 6 months or more in age.

This is one of the major reasons I'm involved in the upstream client
work. If lustre remains a tiny under manned community it is doomed to
remain a niche file system. For years I have tried to recruit new
developers to help out and even gave talks at lustre conferences on
internals. That effort was meet with little success. This is not the
case with the linux lustre client. We do have people contributing
including you. So the reality is that if we removed the lustre client
it would be at least 3+ years before the code would be ready to merged
back in. It would be another 3+ years before it left staging. Many
cleanups in the linux client which impact many lines of code have not
been ported to the Intel branch. It would take forever to get those in.
Honestly I gave up some time ago for those types of cleanups. The cleanups
done in the upstream client would have to be redone. What we really
need is to expand the community. Recently a lot of work has gone into
supporting Ubuntu for our utilities. I hope this helps to get Canonical
involved with the upstream lustre client.

The upstream client is not as bad as you think. A year ago no one in
their right mind would touch the upstream client but their are actually
sites using it today. Its not perfect but it is usable and it is improving
all the time. Yes we have quite a few bugs to squash that show up in
our test suite but the barrier to leaving staging is much much smaller
than it used to be. Once the number of bugs reported in test suite
becomes reasonable we can start 

[PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling

[Michael Kelley]

Fix bugs in signaling the Hyper-V host when freeing space in the
host->guest ring buffer:

1. The interrupt_mask must not be used to determine whether to signal
   on the host->guest ring buffer
2. The ring buffer write_index must be read (via hv_get_bytes_to_write)
   *after* pending_send_sz is read in order to avoid a race condition
3. Comparisons with pending_send_sz must treat the "equals" case as
   not-enough-space
4. Don't signal if the pending_send_sz feature is not present. Older
   versions of Hyper-V that don't implement this feature will poll.

Fixes: 03bad714a161 ("vmbus: more host signalling avoidance")
Signed-off-by: Michael Kelley 
---
 drivers/hv/ring_buffer.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 50e0714..b64be18 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -423,7 +423,11 @@ struct vmpacket_descriptor *
 void hv_pkt_iter_close(struct vmbus_channel *channel)
 {
struct hv_ring_buffer_info *rbi = >inbound;
-   u32 orig_write_sz = hv_get_bytes_to_write(rbi);
+   u32 curr_write_sz;
+   u32 delta = rbi->ring_buffer->read_index < rbi->priv_read_index ?
+   (rbi->priv_read_index - rbi->ring_buffer->read_index) :
+   (rbi->ring_datasize - rbi->ring_buffer->read_index +
+   rbi->priv_read_index);
 
/*
 * Make sure all reads are done before we update the read index since
@@ -446,27 +450,31 @@ void hv_pkt_iter_close(struct vmbus_channel *channel)
 */
virt_mb();
 
-   /* If host has disabled notifications then skip */
-   if (rbi->ring_buffer->interrupt_mask)
-   return;
-
if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
u32 pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
 
/*
+* Ensure the read of write_index in hv_get_bytes_to_write()
+* happens after the read of pending_send_sz.
+*/
+   virt_rmb();
+   curr_write_sz = hv_get_bytes_to_write(rbi);
+
+   /*
 * If there was space before we began iteration,
 * then host was not blocked. Also handles case where
 * pending_sz is zero then host has nothing pending
 * and does not need to be signaled.
 */
-   if (orig_write_sz > pending_sz)
+   if (curr_write_sz - delta > pending_sz)
return;
 
/* If pending write will not fit, don't give false hope. */
-   if (hv_get_bytes_to_write(rbi) < pending_sz)
+   if (curr_write_sz <= pending_sz)
return;
+
+   vmbus_setevent(channel);
}
 
-   vmbus_setevent(channel);
 }
 EXPORT_SYMBOL_GPL(hv_pkt_iter_close);
-- 
1.8.3.1

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

Re: [lustre-devel] [PATCH 41/80] staging: lustre: lmv: separate master object with master stripe

[James Simmons]

> > On Feb 8, 2018, at 10:10 PM, NeilBrown  wrote:
> > 
> > On Thu, Feb 08 2018, Oleg Drokin wrote:
> > 
> >>> On Feb 8, 2018, at 8:39 PM, NeilBrown  wrote:
> >>> 
> >>> On Tue, Aug 16 2016, James Simmons wrote:
> >> 
> >> my that’s an old patch
> >> 
> >>> 
> > ...
> >>> 
> >>> Whoever converted it to "!strcmp()" inverted the condition.  This is a
> >>> perfect example of why I absolutely *loathe* the "!strcmp()" construct!!
> >>> 
> >>> This causes many tests in the 'sanity' test suite to return
> >>> -ENOMEM (that had me puzzled for a while!!).
> >> 
> >> huh? I am not seeing anything of the sort and I was running sanity
> >> all the time until a recent pause (but going to resume).
> > 
> > That does surprised me - I reproduce it every time.
> > I have two VMs running a SLE12-SP2 kernel with patches from
> > lustre-release applied.  These are servers. They have 2 3G virtual disks
> > each.
> > I have two over VMs running current mainline.  These are clients.
> > 
> > I guess your 'recent pause' included between v4.15-rc1 (8e55b6fd0660)
> > and v4.15-rc6 (a93639090a27) - a full month when lustre wouldn't work at
> > all :-(
> 
> More than that, but I am pretty sure James Simmons is running tests all the 
> time too
> (he has a different config, I only have tcp).

Yes I have been testing and haven't encountered this problem. Let me try 
the fix you pointed out. 
 
> > Do you have a list of requested cleanups?  I would find that to be
> > useful.
> 
> As Greg would tell you, “if you don’t know what needs to be done,
> let’s just remove the whole thing from staging now”.
> 
> I assume you saw drivers/staging/lustre/TODO already, it’s only partially 
> done.

Actually the complete list is at :

https://jira.hpdd.intel.com/browse/LU-9679

I need to move that to our TODO list. Sorry I have been short on cycles.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: vc04_services: merge vchiq_kern_lib.c into vchiq_arm.c

[Stefan Wahren]

> Arnd Bergmann  hat am 2. Februar 2018 um 16:01 geschrieben:
> 
> 
> There are two incompatible definitions of 'vchiq_instance_struct', so
> passing them through vchiq_initialise(), vchiq_connect() or another
> such interface is broken, as shown by building the driver with link-time
> optimizations:
> 
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h:129:0: error: 
> type of 'vchiq_initialise' does not match original declaration 
> [-Werror=lto-type-mismatch]
>  extern VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *pinstance);
> 
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c:68:0: 
> note: 'vchiq_initialise' was previously declared here
>  VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
> 
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c:68:0: 
> note: code may be misoptimized unless -fno-strict-aliasing is used
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h:131:0: error: 
> type of 'vchiq_connect' does not match original declaration 
> [-Werror=lto-type-mismatch]
>  extern VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance);
> 
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c:168:0: 
> note: 'vchiq_connect' was previously declared here
>  VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
> 
> It's possible that only one of the two sides actually access the members,
> but it's clear that they need to agree on the layout. The easiest way
> to achieve this appears to be to merge the two files into one. I tried
> moving the structure definition into a shared header first, but ended
> up running into too many interdependencies that way.
> 
> Signed-off-by: Arnd Bergmann 

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

[PATCH] staging: vt6656: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning

[Dileep Sankhla]

Signed-off-by: Dileep Sankhla 
---
 drivers/staging/vt6656/usbpipe.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index 273176386a51..5bbc56f8779e 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -194,9 +194,6 @@ static void vnt_submit_rx_urb_complete(struct urb *urb)
if (vnt_rx_data(priv, rcb, urb->actual_length)) {
rcb->skb = dev_alloc_skb(priv->rx_buf_sz);
if (!rcb->skb) {
-   dev_dbg(>usb->dev,
-   "Failed to re-alloc rx skb\n");
-
rcb->in_use = false;
return;
}
-- 
2.15.1

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

Re: [PATCH v6] Staging: iio: ade7758: Expand buf_lock to cover both buffer and state protection

[Jonathan Cameron]

On Tue,  6 Feb 2018 22:31:57 +0530
Shreeya Patel  wrote:

> iio_dev->mlock is to be used only by the IIO core for protecting
> device mode changes between INDIO_DIRECT and INDIO_BUFFER.
> 
> This patch replaces the use of mlock with the already established
> buf_lock mutex.
> 
> Introducing 'unlocked' forms of read and write registers. The
> read/write frequency functions now require buf_lock to be held.
> That's not obvious so avoid this but moving the locking inside
> the functions where it is then clear that they are taking the
> unlocked forms of the register read/write.
> 
> It isn't readily apparent that write frequency function requires
> the locks to be taken, so move it inside the function to where it
> is required to protect.
> 
> Also, the read raw does not require iio_dev->mlock for
> reads. It can run concurrently as resource protection is handled
> by buf_lock in read register.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git.
Pushed out as testing for the autobuilders at 0day.org an
others to check we didn't get anything wrong.

I'll push out as a non rebasing tree next weekend as I'm offline
most of this week so won't be able to do it before then.

Jonathan

> ---
> 
> Changes in v2
>   -Add static keyword to newly introduced functions and remove some
> added comments which are not required.
> 
> Changes in v3
>   -Remove some useless mlocks and send it as another patch.
> Also make the necessary change in the current patch associated with 
> the new patch with commit id 88eba33. Make commit message more 
> appropriate.
> 
> Changes in v4
>   -Write frequency function do not require lock so move it inside
> the function to where it is required to protect.
> 
> Changes in v5
>   -Remove goto statement and make the code to return -EINVAL there
> itself.
> 
> Changes in v6
>   -Merge patch with commit id 88eba33 with this patch. Also make
> the changed function definition same as before.
>  
>  drivers/staging/iio/meter/ade7758.h  |  2 +-
>  drivers/staging/iio/meter/ade7758_core.c | 52 
> +++-
>  2 files changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/staging/iio/meter/ade7758.h 
> b/drivers/staging/iio/meter/ade7758.h
> index 6ae78d8..2de81b5 100644
> --- a/drivers/staging/iio/meter/ade7758.h
> +++ b/drivers/staging/iio/meter/ade7758.h
> @@ -111,7 +111,7 @@
>   * @trig:data ready trigger registered with iio
>   * @tx:  transmit buffer
>   * @rx:  receive buffer
> - * @buf_lock:mutex to protect tx and rx
> + * @buf_lock:mutex to protect tx, rx, read and write 
> frequency
>   **/
>  struct ade7758_state {
>   struct spi_device   *us;
> diff --git a/drivers/staging/iio/meter/ade7758_core.c 
> b/drivers/staging/iio/meter/ade7758_core.c
> index 7b7ffe5..4e0dbf5 100644
> --- a/drivers/staging/iio/meter/ade7758_core.c
> +++ b/drivers/staging/iio/meter/ade7758_core.c
> @@ -24,17 +24,25 @@
>  #include "meter.h"
>  #include "ade7758.h"
>  
> -int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val)
> +static int __ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 
> val)
>  {
> - int ret;
>   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>   struct ade7758_state *st = iio_priv(indio_dev);
>  
> - mutex_lock(>buf_lock);
>   st->tx[0] = ADE7758_WRITE_REG(reg_address);
>   st->tx[1] = val;
>  
> - ret = spi_write(st->us, st->tx, 2);
> + return spi_write(st->us, st->tx, 2);
> +}
> +
> +int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val)
> +{
> + int ret;
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ade7758_state *st = iio_priv(indio_dev);
> +
> + mutex_lock(>buf_lock);
> + ret = __ade7758_spi_write_reg_8(dev, reg_address, val);
>   mutex_unlock(>buf_lock);
>  
>   return ret;
> @@ -91,7 +99,7 @@ static int ade7758_spi_write_reg_24(struct device *dev, u8 
> reg_address,
>   return ret;
>  }
>  
> -int ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 *val)
> +static int __ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 
> *val)
>  {
>   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>   struct ade7758_state *st = iio_priv(indio_dev);
> @@ -111,7 +119,6 @@ int ade7758_spi_read_reg_8(struct device *dev, u8 
> reg_address, u8 *val)
>   },
>   };
>  
> - mutex_lock(>buf_lock);
>   st->tx[0] = ADE7758_READ_REG(reg_address);
>   st->tx[1] = 0;
>  
> @@ -124,7 +131,19 @@ int ade7758_spi_read_reg_8(struct device *dev, u8 
> reg_address, u8 *val)
>   *val = st->rx[0];
>  
>  error_ret:
> + return ret;
> +}
> +
> +int ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 *val)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ade7758_state *st = 

[PATCH] staging: android: ion: Add requested allocation alignment

[Alexey Skidanov]

Current ion defined allocation ioctl doesn't allow to specify the requested
allocation alignment. CMA heap allocates buffers aligned on buffer size
page order.

Sometimes, the alignment requirement is less restrictive. In such cases,
providing specific alignment may reduce the external memory fragmentation
and in some cases it may avoid the allocation request failure.

To fix this, we add an alignment parameter to the allocation ioctl.

Signed-off-by: Alexey Skidanov 
---
 drivers/staging/android/ion/ion-ioctl.c |  3 ++-
 drivers/staging/android/ion/ion.c   | 14 +-
 drivers/staging/android/ion/ion.h   |  9 ++---
 drivers/staging/android/ion/ion_carveout_heap.c |  3 ++-
 drivers/staging/android/ion/ion_chunk_heap.c|  3 ++-
 drivers/staging/android/ion/ion_cma_heap.c  | 18 --
 drivers/staging/android/ion/ion_system_heap.c   |  6 --
 drivers/staging/android/uapi/ion.h  |  7 +++
 8 files changed, 40 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index c789893..9fe022b 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -83,7 +83,8 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
 
fd = ion_alloc(data.allocation.len,
   data.allocation.heap_id_mask,
-  data.allocation.flags);
+  data.allocation.flags,
+  data.allocation.align);
if (fd < 0)
return fd;
 
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index f480885..35ddc7a 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -78,7 +78,8 @@ static void ion_buffer_add(struct ion_device *dev,
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
-   unsigned long flags)
+   unsigned long flags,
+   unsigned int align)
 {
struct ion_buffer *buffer;
int ret;
@@ -90,14 +91,14 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
buffer->heap = heap;
buffer->flags = flags;
 
-   ret = heap->ops->allocate(heap, buffer, len, flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags, align);
 
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
 
ion_heap_freelist_drain(heap, 0);
-   ret = heap->ops->allocate(heap, buffer, len, flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags, align);
if (ret)
goto err2;
}
@@ -390,7 +391,10 @@ static const struct dma_buf_ops dma_buf_ops = {
.unmap = ion_dma_buf_kunmap,
 };
 
-int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
+int ion_alloc(size_t len,
+ unsigned int heap_id_mask,
+ unsigned int flags,
+ unsigned int align)
 {
struct ion_device *dev = internal_dev;
struct ion_buffer *buffer = NULL;
@@ -417,7 +421,7 @@ int ion_alloc(size_t len, unsigned int heap_id_mask, 
unsigned int flags)
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
-   buffer = ion_buffer_create(heap, dev, len, flags);
+   buffer = ion_buffer_create(heap, dev, len, flags, align);
if (!IS_ERR(buffer))
break;
}
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index f5f9cd6..0c161d2 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -123,8 +123,10 @@ struct ion_device {
  */
 struct ion_heap_ops {
int (*allocate)(struct ion_heap *heap,
-   struct ion_buffer *buffer, unsigned long len,
-   unsigned long flags);
+   struct ion_buffer *buffer,
+   unsigned long len,
+   unsigned long flags,
+   unsigned int align);
void (*free)(struct ion_buffer *buffer);
void * (*map_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
void (*unmap_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
@@ -228,7 +230,8 @@ int ion_heap_pages_zero(struct page *page, size_t size, 
pgprot_t pgprot);
 
 int ion_alloc(size_t len,
  unsigned int heap_id_mask,
- unsigned int flags);
+   

ion kernel mapping implementation

[Alexey Skidanov]

Hi,

Current ion kernel mapping implementation uses vmap() to map previously
allocated buffers into kernel virtual address space. On 32 bit
platforms, vmap() might fail on large enough buffers due to the limited
available vmalloc space.

dma_buf_kmap() should guarantee that only one page is mapped at a time.
So, probably it's better to implement dma_buf_kmap() by kmap() and not
by vmap()?

Thanks,
Alexey

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