Re: A review of dm-writeboost

2013-10-09 Thread Akira Hayakawa 
Mikulas,

> Next, you need to design some locking - which variables are protected by 
> which locks. If you use shared variables without locks, you need to use 
> memory barriers (it is harder to design code using memory barriers than 
> locks).

First I will explain the locking and the shared variables.
writeboost doesn't have many variables shared among asynchronous threads.

1. We have HashTable for cache lookup and RAM buffer for write data transiently.
   These data structures are locked by a mutex io_lock.
   barrier_ios is a queue to push bio flagged with REQ_FUA or REQ_FLUSH.
   This queue is also locked by io_lock.
   These bios are chained to flush job inside io_lock.
   queue_flushing is a routine that makes a flush job and queues it in
   flush_queue which is protected by a spinlock flush_queue_lock.
   This foreground (.map) is a producer of flush jobs to flush daemon.
2. flush daemon loops flush_proc in single thread.
   It pops and consumes one flush job from flush_queue (writing to the cache 
device).
   Therefore, foreground should keep that the flush job is
   completely initialized before queues it.
   After completing the writing, it sets(actually increments) the 
last_flush_segment_id.
   This daemon is the only to update this shared variable.
3. migrate daemon loops migrate_proc also running in the single thread.
   It first calculates how many (nr_mig) segments from 
   last_migrated_segment_id + 1 to + nr_mig by referring
   last_flushed_segment_id and last_migrate_segment_id.
   The former is the head of the dirty log and the latter
   is the tail. Note that the head doesn't have to be synchronized
   since the last_flush_segment_id linearly increases.
   last_flush_segment_id not synced only results in less number of migration 
than actual.
   It doesn't collapse anything at all.
   After migrate all the nr_mig dirty segments, it increments
   last_migrated_segment_id by nr_mig.
   This daemon is the only to update this last_migrate_segment_id.
   
Other daemons don't share such variables.

> Think of this piece of code:
> nr_mig_candidates = cache->last_flushed_segment_id -
> cache->last_migrated_segment_id;
> ...
> nr_mig = min(nr_mig_candidates,
>  cache->nr_cur_batched_migration);
> ...
> for (i = 1; i <= nr_mig; i++) {
>   seg = get_segment_header_by_id(
> cache,
> cache->last_migrated_segment_id + i);
> list_add_tail(&seg->migrate_list, &cache->migrate_list);
> }
> 
> The processor may reorder all memory accesses - for example it may read 
> the data accessed in the "for" cycle before reading the variables 
> "cache->last_flushed_segment_id" and "cache->last_migrated_segment_id". If 
> this happens, the code may work with invalid data.

True?
My understanding is that reordering does not happen
for these three blocks of code because there are sequential data dependencies.
That the last block is while loop is the point?

But, I sorted our other two points we need to insert memory barriers.

First is in queue_flushing.
We can't deny that incomplete flush job is queued and
flush_proc goes bad.
I am thinking of inserting smp_wmb before queuing and
smp_rmb after popping a job in flush_proc.

Second is in migrate_proc.
We can't deny that migrate_proc goes into migrate_linked_segments
before cache->migrate_list is properly initialized.
I am thinking of inserting smp_wmb before migrate_linked_segments.

I don't understand memory barrier well.
So, please fix if I am going the wrong way.

> Nonatomic 64-bit variables
> --
> 
> Note that 64-bit variables are not atomic on 32-bit architectures.
> 
> Linux assumes that 32-bit variables are atomic on 32-bit architectures and 
> 64-bit or 32-bit variables are atomic on 64-bit architectures. That is, 
> variables having the "long" or "int" type are atomic. Atomicity means that 
> if you read and modify the variable at the same time, you read either the 
> old value or the new values.
> 
> 64-bit variables on 32-bit architectures are usually read and written in 
> two steps, and thus the atomicity requirement isn't true.
> 
> For example, suppose that you change cache->last_flushed_segment_id from 
> 0x to 0x0001. Now, the function migrate_proc 
> that asynchronously reads cache->last_flushed_segment_id can read 
> 0x or 0x0001 (if it reads one of these values, 
> it behaves correctly), but it can also read 0x or 
> 0x0001 - if migrate_proc reads one of these two values, it 
> goes wild, migrating segments that weren't ever supposed to be migrated, 
> and likely causes a crash or data corruption.
> 
> I found this bug in migrate_proc and update_superblock_record (but it may 
> be also in other parts of the code).
> 
> You can use atomic64_t type for atomic 64-bit variables (plus memory 
> barriers as explained in the previous section). Or

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

2013-10-09 Thread Tomi Valkeinen 
On 02/10/13 14:55, Gerd Hoffmann 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:
> 
> [root@dhcp231 ~]# lspci -vs8
> 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
> VGA (prog-if 00 [VGA controller])
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f800 (32-bit, non-prefetchable) [size=64M]
> Expansion ROM at  [disabled]
> Kernel driver in use: hyperv_fb
> 
> Another effect is that the xorg vesa driver will not attach to the
> device and thus the Xorg server will automatically use the fbdev
> driver instead.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/video/hyperv_fb.c | 40 +++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 

Thanks, queuing the series for 3.13.

 Tomi




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

[PATCH 06/10] staging: lustre: Do not use 0 for NULL pointer in console.c

2013-10-09 Thread Sachin Kamat 
Do not use 0 for NULL pointer.

Signed-off-by: Sachin Kamat 
---
 drivers/staging/lustre/lnet/selftest/console.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/selftest/console.c 
b/drivers/staging/lustre/lnet/selftest/console.c
index 09e4700..f1152e4 100644
--- a/drivers/staging/lustre/lnet/selftest/console.c
+++ b/drivers/staging/lustre/lnet/selftest/console.c
@@ -797,7 +797,7 @@ lstcon_group_info(char *name, lstcon_ndlist_ent_t *gents_p,
return rc;
}
 
-   if (dents_up != 0) {
+   if (dents_up) {
/* verbose query */
rc = lstcon_nodes_getent(&grp->grp_ndl_list,
 index_p, count_p, dents_up);
-- 
1.7.9.5

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

[PATCH 02/10] staging: dgap: dgap_fep5: Remove braces around return

2013-10-09 Thread Sachin Kamat 
Braces are not needed around return values.

Signed-off-by: Sachin Kamat 
Cc: Lidza Louina 
---
 drivers/staging/dgap/dgap_fep5.c |   38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/dgap/dgap_fep5.c b/drivers/staging/dgap/dgap_fep5.c
index 5ebfcac..86e9aa6 100644
--- a/drivers/staging/dgap/dgap_fep5.c
+++ b/drivers/staging/dgap/dgap_fep5.c
@@ -134,7 +134,7 @@ int dgap_after_config_loaded(void)
dgap_Board[i]->flipflagbuf = dgap_driver_kzmalloc(MYFLIPLEN, 
GFP_ATOMIC);
}
 
-   return (rc);
+   return rc;
 }
 
 
@@ -150,14 +150,14 @@ static int dgap_usertoboard(struct board_t *brd, char 
*to_addr, char __user *fro
int n = U2BSIZE;
 
if (!brd || brd->magic != DGAP_BOARD_MAGIC)
-   return(-EFAULT);
+   return -EFAULT;
 
while (len) {
if (n > len)
n = len;
 
if (copy_from_user((char *) &buf, from_addr, n) == -1 ) {
-   return(-EFAULT);
+   return -EFAULT;
}
 
/* Copy data from buffer to card memory */
@@ -169,7 +169,7 @@ static int dgap_usertoboard(struct board_t *brd, char 
*to_addr, char __user *fro
from_addr += n;   
n = U2BSIZE;
 }
-   return(0);
+   return 0;
 }
 
 
@@ -1155,20 +1155,20 @@ uint dgap_get_custom_baud(struct channel_t *ch)
uint value = 0;
 
if (!ch || ch->magic != DGAP_CHANNEL_MAGIC) {
-   return (0);
+   return 0;
}
 
if (!ch->ch_bd || ch->ch_bd->magic != DGAP_BOARD_MAGIC) {
-   return (0);
+   return 0;
}
 
if (!(ch->ch_bd->bd_flags & BD_FEP5PLUS))
-   return (0);
+   return 0;
 
vaddr = ch->ch_bd->re_map_membase;
 
if (!vaddr)
-   return (0);
+   return 0;
 
/*
 * Go get from fep mem, what the fep
@@ -1178,7 +1178,7 @@ uint dgap_get_custom_baud(struct channel_t *ch)
(ch->ch_portnum * 0x28) + LINE_SPEED));
 
value = readw(vaddr + offset);
-   return (value);
+   return value;
 }
 
 
@@ -1230,23 +1230,23 @@ int dgap_param(struct tty_struct *tty)
uchar   hflow;
 
if (!tty || tty->magic != TTY_MAGIC)
-   return (-ENXIO);
+   return -ENXIO;
 
un = (struct un_t *) tty->driver_data;
if (!un || un->magic != DGAP_UNIT_MAGIC)
-   return (-ENXIO);
+   return -ENXIO;
 
ch = un->un_ch;
if (!ch || ch->magic != DGAP_CHANNEL_MAGIC)
-   return (-ENXIO);
+   return -ENXIO;
 
bd = ch->ch_bd;
if (!bd || bd->magic != DGAP_BOARD_MAGIC)
-   return (-ENXIO);
+   return -ENXIO;
 
 bs = ch->ch_bs;
if (bs == 0)
-   return (-ENXIO);
+   return -ENXIO;
 
DPR_PARAM(("param start: tdev: %x cflags: %x oflags: %x iflags: %x\n",
ch->ch_tun.un_dev, ch->ch_c_cflag, ch->ch_c_oflag, 
ch->ch_c_iflag));
@@ -1553,7 +1553,7 @@ int dgap_param(struct tty_struct *tty)
 
DPR_PARAM(("param finish\n"));
 
-   return (0);
+   return 0;
 }
 
 
@@ -1670,7 +1670,7 @@ static int dgap_event(struct board_t *bd)
int b1;
 
if (!bd || bd->magic != DGAP_BOARD_MAGIC)
-   return (-ENXIO);
+   return -ENXIO;
 
DGAP_LOCK(bd->bd_lock, lock_flags);
 
@@ -1678,7 +1678,7 @@ static int dgap_event(struct board_t *bd)
 
if (!vaddr) {
DGAP_UNLOCK(bd->bd_lock, lock_flags);
-   return (-ENXIO);
+   return -ENXIO;
}
 
eaddr = (struct ev_t *) (vaddr + EVBUF);
@@ -1696,7 +1696,7 @@ static int dgap_event(struct board_t *bd)
DPR_EVENT(("should be calling xxfail %d\n", __LINE__));
/* Let go of board lock */
DGAP_UNLOCK(bd->bd_lock, lock_flags);
-   return (-ENXIO);
+   return -ENXIO;
}
 
/*
@@ -1944,5 +1944,5 @@ next:
writew(tail, &(eaddr->ev_tail));
DGAP_UNLOCK(bd->bd_lock, lock_flags);
 
-   return (0);
+   return 0;
 }   
-- 
1.7.9.5

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

[PATCH 05/10] staging: line6: midi: Use NULL instead of 0 for pointers

2013-10-09 Thread Sachin Kamat 
Use NULL instead of 0 for pointers.

Signed-off-by: Sachin Kamat 
---
 drivers/staging/line6/midi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/line6/midi.c b/drivers/staging/line6/midi.c
index e3f9a53..52da4d9 100644
--- a/drivers/staging/line6/midi.c
+++ b/drivers/staging/line6/midi.c
@@ -205,7 +205,7 @@ static void line6_midi_input_trigger(struct 
snd_rawmidi_substream *substream,
if (up)
line6->line6midi->substream_receive = substream;
else
-   line6->line6midi->substream_receive = 0;
+   line6->line6midi->substream_receive = NULL;
 }
 
 static struct snd_rawmidi_ops line6_midi_output_ops = {
-- 
1.7.9.5

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

[PATCH 03/10] staging: dgap: dgap_fep5: Do not use 0 for NULL pointer

2013-10-09 Thread Sachin Kamat 
Do not compare NULL pointer with 0.

Signed-off-by: Sachin Kamat 
Cc: Lidza Louina 
---
 drivers/staging/dgap/dgap_fep5.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/dgap/dgap_fep5.c b/drivers/staging/dgap/dgap_fep5.c
index 86e9aa6..794cf9d 100644
--- a/drivers/staging/dgap/dgap_fep5.c
+++ b/drivers/staging/dgap/dgap_fep5.c
@@ -1245,7 +1245,7 @@ int dgap_param(struct tty_struct *tty)
return -ENXIO;
 
 bs = ch->ch_bs;
-   if (bs == 0)
+   if (!bs)
return -ENXIO;
 
DPR_PARAM(("param start: tdev: %x cflags: %x oflags: %x iflags: %x\n",
-- 
1.7.9.5

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

[PATCH 07/10] staging: dgnc: dgnc_tty: Do not use 0 for NULL pointer

2013-10-09 Thread Sachin Kamat 
Do not use 0 for NULL pointer.

Signed-off-by: Sachin Kamat 
Cc: Lidza Louina 
---
 drivers/staging/dgnc/dgnc_tty.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index c6fee11..a6c6aba 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -520,7 +520,7 @@ void dgnc_sniff_nowait_nolock(struct channel_t *ch, uchar 
*text, uchar *buf, int
/*
 *  Loop while data remains.
 */
-   while (nbuf > 0 && ch->ch_sniff_buf != 0) {
+   while (nbuf > 0 && ch->ch_sniff_buf) {
/*
 *  Determine the amount of available space left in the
 *  buffer.  If there's none, wait until some appears.
-- 
1.7.9.5

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

[PATCH 04/10] staging: dgap: dgap_tty: Do not use 0 for pointers

2013-10-09 Thread Sachin Kamat 
0 should not be used instead of NULL for pointers.

Signed-off-by: Sachin Kamat 
Cc: Lidza Louina 
---
 drivers/staging/dgap/dgap_tty.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dgap/dgap_tty.c b/drivers/staging/dgap/dgap_tty.c
index 924e2bf..2a7a372 100644
--- a/drivers/staging/dgap/dgap_tty.c
+++ b/drivers/staging/dgap/dgap_tty.c
@@ -595,7 +595,7 @@ static void dgap_sniff_nowait_nolock(struct channel_t *ch, 
uchar *text, uchar *b
/*
 *  Loop while data remains.
 */
-   while (nbuf > 0 && ch->ch_sniff_buf != 0) {
+   while (nbuf > 0 && ch->ch_sniff_buf) {
/*
 *  Determine the amount of available space left in the
 *  buffer.  If there's none, wait until some appears.
@@ -1107,9 +1107,10 @@ static int dgap_tty_open(struct tty_struct *tty, struct 
file *file)
MAJOR(tty_devnum(tty)), MINOR(tty_devnum(tty)), un, brd->name));
 
/*
-* Error if channel info pointer is 0.
+* Error if channel info pointer is NULL.
 */
-   if ((bs = ch->ch_bs) == 0) {
+   bs = ch->ch_bs;
+   if (!bs) {
DGAP_UNLOCK(ch->ch_lock, lock_flags2);
DGAP_UNLOCK(brd->bd_lock, lock_flags);
DPR_OPEN(("%d BS is 0!\n", __LINE__));
-- 
1.7.9.5

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

[PATCH 09/10] staging: rtl8192u: Use NULL instead of 0

2013-10-09 Thread Sachin Kamat 
Use NULL instead of 0 for pointer.

Signed-off-by: Sachin Kamat 
---
 drivers/staging/rtl8192u/r8192U_core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index cd0946d..c383e64 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2009,7 +2009,7 @@ void rtl8192_usb_deleteendpoints(struct net_device *dev)
priv->oldaddr = NULL;
if (priv->pp_rxskb) {
kfree(priv->pp_rxskb);
-   priv->pp_rxskb = 0;
+   priv->pp_rxskb = NULL;
}
 }
 #else
-- 
1.7.9.5

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

[PATCH 01/10] staging: dgap: dgap_fep5: Remove braces around single line statements

2013-10-09 Thread Sachin Kamat 
Single line statements do not require braces.

Signed-off-by: Sachin Kamat 
Cc: Lidza Louina 
---
 drivers/staging/dgap/dgap_fep5.c |   15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/dgap/dgap_fep5.c b/drivers/staging/dgap/dgap_fep5.c
index 4464f02..5ebfcac 100644
--- a/drivers/staging/dgap/dgap_fep5.c
+++ b/drivers/staging/dgap/dgap_fep5.c
@@ -1229,29 +1229,24 @@ int dgap_param(struct tty_struct *tty)
uchar   mval;
uchar   hflow;
 
-   if (!tty || tty->magic != TTY_MAGIC) {
+   if (!tty || tty->magic != TTY_MAGIC)
return (-ENXIO);
-   }
 
un = (struct un_t *) tty->driver_data;
-   if (!un || un->magic != DGAP_UNIT_MAGIC) {
+   if (!un || un->magic != DGAP_UNIT_MAGIC)
return (-ENXIO);
-   }
 
ch = un->un_ch;
-   if (!ch || ch->magic != DGAP_CHANNEL_MAGIC) {
+   if (!ch || ch->magic != DGAP_CHANNEL_MAGIC)
return (-ENXIO);
-   }
 
bd = ch->ch_bd;
-   if (!bd || bd->magic != DGAP_BOARD_MAGIC) {
+   if (!bd || bd->magic != DGAP_BOARD_MAGIC)
return (-ENXIO);
-   }
 
 bs = ch->ch_bs;
-   if (bs == 0) {
+   if (bs == 0)
return (-ENXIO);
-   }
 
DPR_PARAM(("param start: tdev: %x cflags: %x oflags: %x iflags: %x\n",
ch->ch_tun.un_dev, ch->ch_c_cflag, ch->ch_c_oflag, 
ch->ch_c_iflag));
-- 
1.7.9.5

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

[PATCH 10/10] staging: vt6655: Use NULL instead of 0

2013-10-09 Thread Sachin Kamat 
Use NULL instead of 0 for pointer.

Signed-off-by: Sachin Kamat 
Cc: Forest Bond 
---
 drivers/staging/vt6655/wroute.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/wroute.c b/drivers/staging/vt6655/wroute.c
index b61328f..85302c5 100644
--- a/drivers/staging/vt6655/wroute.c
+++ b/drivers/staging/vt6655/wroute.c
@@ -179,7 +179,7 @@ bool ROUTEbRelay(PSDevice pDevice, unsigned char 
*pbySkbData, unsigned int uData
pHeadTD = pHeadTD->next;
}
 
-   pLastTD->pTDInfo->skb = 0;
+   pLastTD->pTDInfo->skb = NULL;
pLastTD->pTDInfo->byFlags = 0;
 
pDevice->apCurrTD[TYPE_AC0DMA] = pHeadTD;
-- 
1.7.9.5

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

[PATCH 08/10] staging: lirc: Do not use 0 for NULL pointer

2013-10-09 Thread Sachin Kamat 
Do not use 0 for NULL pointer.

Signed-off-by: Sachin Kamat 
Cc: Jarod Wilson 
---
 drivers/staging/media/lirc/lirc_bt829.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_bt829.c 
b/drivers/staging/media/lirc/lirc_bt829.c
index fa31ee7..fbbdce4 100644
--- a/drivers/staging/media/lirc/lirc_bt829.c
+++ b/drivers/staging/media/lirc/lirc_bt829.c
@@ -132,7 +132,7 @@ int init_module(void)
atir_driver.minor   = -1;
atir_driver.code_length = 8;
atir_driver.sample_rate = 10;
-   atir_driver.data= 0;
+   atir_driver.data= NULL;
atir_driver.add_to_buf  = atir_add_to_buf;
atir_driver.set_use_inc = atir_set_use_inc;
atir_driver.set_use_dec = atir_set_use_dec;
@@ -159,7 +159,7 @@ void cleanup_module(void)
 static int atir_init_start(void)
 {
pci_addr_lin = ioremap(pci_addr_phys + DATA_PCI_OFF, 0x400);
-   if (pci_addr_lin == 0) {
+   if (!pci_addr_lin) {
pr_info("pci mem must be mapped\n");
return 0;
}
-- 
1.7.9.5

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

[PATCH 1/1] staging: mt29f_spinand: Use module_spi_driver

2013-10-09 Thread Sachin Kamat 
module_spi_driver removes the boilerplate code and simplifies it.

Signed-off-by: Sachin Kamat 
Cc: Henry Pan 
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c |   18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 8e95a57..5647079 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -939,23 +939,7 @@ static struct spi_driver spinand_driver = {
.remove = spinand_remove,
 };
 
-/*
- * Device driver registration
- */
-static int __init spinand_init(void)
-{
-   return spi_register_driver(&spinand_driver);
-}
-
-/*
- * unregister Device driver.
- */
-static void __exit spinand_exit(void)
-{
-   spi_unregister_driver(&spinand_driver);
-}
-module_init(spinand_init);
-module_exit(spinand_exit);
+module_spi_driver(spinand_driver);
 
 MODULE_DESCRIPTION("SPI NAND driver for Micron");
 MODULE_AUTHOR("Henry Pan , Kamlakant Patel 
");
-- 
1.7.9.5

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

[BUG] imx-drm: lockdep circular locking dependency

2013-10-09 Thread Russell King - ARM Linux 
A suggestion to IMX developers: please run your test kernels with
PROVE_LOCKING enabled (and preferably other debugging options too.)
Thanks.

==
[ INFO: possible circular locking dependency detected ]
3.12.0-rc3+ #43 Not tainted
---
swapper/0/1 is trying to acquire lock:
 (&imx_drm_device->mutex){+.+.+.}, at: [] 
imx_drm_encoder_get_mux_id+0x28/0x98

but task is already holding lock:
 (&crtc->mutex){+.+...}, at: [] drm_modeset_lock_all+0x44/0x58

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&crtc->mutex){+.+...}:
   [] __lock_acquire+0x15a8/0x1e1c
   [] lock_acquire+0x68/0x7c
   [] _mutex_lock_nest_lock+0x58/0x388
   [] drm_crtc_init+0x48/0xb0
   [] imx_drm_add_crtc+0xe4/0x148
   [] ipu_drm_probe+0x138/0x20c
   [] platform_drv_probe+0x20/0x24
   [] driver_probe_device+0x9c/0x234
   [] __driver_attach+0x9c/0xa0
   [] bus_for_each_dev+0x70/0x94
   [] driver_attach+0x24/0x28
   [] bus_add_driver+0x1d8/0x26c
   [] driver_register+0x80/0xfc
   [] __platform_driver_register+0x50/0x64
   [] ipu_drm_driver_init+0x18/0x20
   [] do_one_initcall+0x38/0x168
   [] kernel_init_freeable+0x104/0x1cc
   [] kernel_init+0x10/0xec
   [] ret_from_fork+0x14/0x2c

-> #1 (&dev->mode_config.mutex){+.+.+.}:
   [] __lock_acquire+0x15a8/0x1e1c
   [] lock_acquire+0x68/0x7c
   [] mutex_lock_nested+0x5c/0x38c
   [] drm_modeset_lock_all+0x20/0x58
   [] drm_encoder_init+0x20/0x84
   [] imx_drm_add_encoder+0x8c/0xe0
   [] imx_ldb_probe+0x2bc/0x50c
   [] platform_drv_probe+0x20/0x24
   [] driver_probe_device+0x9c/0x234
   [] __driver_attach+0x9c/0xa0
   [] bus_for_each_dev+0x70/0x94
   [] driver_attach+0x24/0x28
   [] bus_add_driver+0x1d8/0x26c
   [] driver_register+0x80/0xfc
   [] __platform_driver_register+0x50/0x64
   [] imx_ldb_driver_init+0x18/0x20
   [] do_one_initcall+0x38/0x168
   [] kernel_init_freeable+0x104/0x1cc
   [] kernel_init+0x10/0xec
   [] ret_from_fork+0x14/0x2c

-> #0 (&imx_drm_device->mutex){+.+.+.}:
   [] print_circular_bug+0x74/0x2fc
   [] __lock_acquire+0x1770/0x1e1c
   [] lock_acquire+0x68/0x7c
   [] mutex_lock_nested+0x5c/0x38c
   [] imx_drm_encoder_get_mux_id+0x28/0x98
   [] imx_ldb_encoder_prepare+0x3c/0x12c
   [] drm_crtc_helper_set_mode+0x1f8/0x4b0
   [] drm_crtc_helper_set_config+0x7b4/0x9dc
   [] drm_mode_set_config_internal+0x68/0xf0
   [] drm_fb_helper_set_par+0x54/0xb0
   [] fbcon_init+0x4c8/0x520
   [] visual_init+0xac/0xf8
   [] do_bind_con_driver+0x16c/0x388
   [] do_take_over_console+0xa4/0x1b4
   [] do_fbcon_takeover+0x70/0xd4
   [] fbcon_event_notify+0x7e0/0x830
   [] notifier_call_chain+0x4c/0x8c
   [] __blocking_notifier_call_chain+0x50/0x68
   [] blocking_notifier_call_chain+0x20/0x28
   [] fb_notifier_call_chain+0x20/0x24
   [] register_framebuffer+0x1ac/0x268
   [] drm_fb_helper_initial_config+0x408/0x574
   [] drm_fbdev_cma_init+0x7c/0xe8
   [] imx_fb_helper_init+0x58/0x90
   [] do_one_initcall+0x38/0x168
   [] kernel_init_freeable+0x104/0x1cc
   [] kernel_init+0x10/0xec
   [] ret_from_fork+0x14/0x2c

other info that might help us debug this:

Chain exists of:
  &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(&crtc->mutex);
   lock(&dev->mode_config.mutex);
   lock(&crtc->mutex);
  lock(&imx_drm_device->mutex);

 *** DEADLOCK ***


6 locks held by swapper/0/1:
 #0:  (registration_lock){+.+.+.}, at: [] 
register_framebuffer+0x20/0x268
 #1:  (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x20/0x44
 #2:  (console_lock){+.+.+.}, at: [] register_framebuffer+0x19c/0x268
 #3:  ((fb_notifier_list).rwsem){.+.+.+}, at: [] 
__blocking_notifier_call_chain+0x34/0x68
 #4:  (&dev->mode_config.mutex){+.+.+.}, at: [] 
drm_modeset_lock_all+0x20/0x58
 #5:  (&crtc->mutex){+.+...}, at: [] drm_modeset_lock_all+0x44/0x58

stack backtrace:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-rc3+ #43
Backtrace: 
[] (dump_backtrace+0x0/0x10c) from [] (show_stack+0x18/0x1c)
 r6:c097dba8 r5:c097e318 r4: r3:
[] (show_stack+0x0/0x1c) from [] (dump_stack+0x70/0x90)
[] (dump_stack+0x0/0x90) from [] 
(print_circular_bug+0x1d0/0x2fc)
 r4:c097ddc8 r3:df87
[] (print_circular_bug+0x0/0x2fc) from [] 
(__lock_acquire+0x1770/0x1e1c)
[] (__lock_acquire+0x0/0x1e1c) from [] 
(lock_acquire+0x68/0x7c)
[] (lock_acquire+0x0/0x7c) from [] 
(mutex_lock_nested+0x5c/0x38c)
 r7:df86c000 r6:c088904c r5:c046eaa8 r4:dfb6c4a0
[] (mutex_lock_nested+0x0/0x38c) from [] 
(imx_drm_encoder_get_mux_id+0x28/0x98)
[] (imx_drm_e

RE: [PATCH 01/28] staging: comedi: s626: tidy the header file a bit

2013-10-09 Thread Hartley Sweeten 
On Tuesday, October 08, 2013 11:06 AM, Ian Abbott wrote:
> Tidy up the "s626.h" header file a bit, cleaning up the whitespace and
> fixing overlength lines.  Add multiple inclusion protection (even though
> it's only included once and only by "s626.c").  Remove unnecessary
> driver comment near the start of the file as it is more or less the same
> as the one in "s626.c".  Remove obviously unused/useless stuff.
>
> I'm not sure what to do about the INTEL/MOTOROLA platform selection in
> the file.  I've left it alone (set to INTEL) for now.
>
> Signed-off-by: Ian Abbott 
> ---
>  drivers/staging/comedi/drivers/s626.h | 925 
> --
>  1 file changed, 436 insertions(+), 489 deletions(-)

Ian,

I'm still reviewing this series but I had a comment on the s626.h file.

Since the s626 driver is the only user of this header it would be nicer
if this head just went away. Any objections to just merging its contents
directly info to s626.c file? This could be done as a single patch after
this series is applied.

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

Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor

2013-10-09 Thread H. Peter Anvin 
On 09/27/2013 08:35 AM, KY Srinivasan wrote:
> 
> Thanks Olaf. Could you submit the patch.
> 

Haven't heard anything from Olaf... could you fold in the fix and resumbit?

-hpa


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

[PATCH] imx-drm: imx-drm-core: Fix circular locking dependency

2013-10-09 Thread Fabio Estevam 
From: Fabio Estevam 

Booting a mx6 with CONFIG_PROVE_LOCKING we get:

==
[ INFO: possible circular locking dependency detected ]
3.12.0-rc4-next-20131009+ #34 Not tainted
---
swapper/0/1 is trying to acquire lock:
 (&imx_drm_device->mutex){+.+.+.}, at: [<804575a8>] 
imx_drm_encoder_get_mux_id+0x28/0x98

but task is already holding lock:
 (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&crtc->mutex){+.+...}:
   [<800777d0>] __lock_acquire+0x18d4/0x1c24
   [<80077fec>] lock_acquire+0x68/0x7c
   [<805ead5c>] _mutex_lock_nest_lock+0x58/0x3a8
   [<802fec50>] drm_crtc_init+0x48/0xa8
   [<80457c88>] imx_drm_add_crtc+0xd4/0x144
   [<8045e2e8>] ipu_drm_probe+0x114/0x1fc
   [<80312278>] platform_drv_probe+0x20/0x50
   [<80310c68>] driver_probe_device+0x110/0x22c
   [<80310e20>] __driver_attach+0x9c/0xa0
   [<8030f218>] bus_for_each_dev+0x5c/0x90
   [<80310750>] driver_attach+0x20/0x28
   [<8031034c>] bus_add_driver+0xdc/0x1dc
   [<803114d8>] driver_register+0x80/0xfc
   [<80312198>] __platform_driver_register+0x50/0x64
   [<808172fc>] ipu_drm_driver_init+0x18/0x20
   [<800088c0>] do_one_initcall+0xfc/0x160
   [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
   [<805e2930>] kernel_init+0x10/0xec
   [<8000ea68>] ret_from_fork+0x14/0x2c

-> #1 (&dev->mode_config.mutex){+.+.+.}:
   [<800777d0>] __lock_acquire+0x18d4/0x1c24
   [<80077fec>] lock_acquire+0x68/0x7c
   [<805eb100>] mutex_lock_nested+0x54/0x3a4
   [<802fe758>] drm_modeset_lock_all+0x20/0x54
   [<802fead4>] drm_encoder_init+0x20/0x7c
   [<80457ae4>] imx_drm_add_encoder+0x88/0xec
   [<80459838>] imx_ldb_probe+0x344/0x4fc
   [<80312278>] platform_drv_probe+0x20/0x50
   [<80310c68>] driver_probe_device+0x110/0x22c
   [<80310e20>] __driver_attach+0x9c/0xa0
   [<8030f218>] bus_for_each_dev+0x5c/0x90
   [<80310750>] driver_attach+0x20/0x28
   [<8031034c>] bus_add_driver+0xdc/0x1dc
   [<803114d8>] driver_register+0x80/0xfc
   [<80312198>] __platform_driver_register+0x50/0x64
   [<8081722c>] imx_ldb_driver_init+0x18/0x20
   [<800088c0>] do_one_initcall+0xfc/0x160
   [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
   [<805e2930>] kernel_init+0x10/0xec
   [<8000ea68>] ret_from_fork+0x14/0x2c

-> #0 (&imx_drm_device->mutex){+.+.+.}:
   [<805e510c>] print_circular_bug+0x74/0x2e0
   [<80077ad0>] __lock_acquire+0x1bd4/0x1c24
   [<80077fec>] lock_acquire+0x68/0x7c
   [<805eb100>] mutex_lock_nested+0x54/0x3a4
   [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98
   [<80459a98>] imx_ldb_encoder_prepare+0x34/0x114
   [<802ef724>] drm_crtc_helper_set_mode+0x1f0/0x4c0
   [<802f0344>] drm_crtc_helper_set_config+0x828/0x99c
   [<802ff270>] drm_mode_set_config_internal+0x5c/0xdc
   [<802eebe0>] drm_fb_helper_set_par+0x50/0xb4
   [<802af580>] fbcon_init+0x490/0x500
   [<802dd104>] visual_init+0xa8/0xf8
   [<802df414>] do_bind_con_driver+0x140/0x37c
   [<802df764>] do_take_over_console+0x114/0x1c4
   [<802af65c>] do_fbcon_takeover+0x6c/0xd4
   [<802b2b30>] fbcon_event_notify+0x7c8/0x818
   [<80049954>] notifier_call_chain+0x4c/0x8c
   [<80049cd8>] __blocking_notifier_call_chain+0x50/0x68
   [<80049d10>] blocking_notifier_call_chain+0x20/0x28
   [<802a75f0>] fb_notifier_call_chain+0x1c/0x24
   [<802a9224>] register_framebuffer+0x188/0x268
   [<802ee994>] drm_fb_helper_initial_config+0x2bc/0x4b8
   [<802f118c>] drm_fbdev_cma_init+0x7c/0xec
   [<80817288>] imx_fb_helper_init+0x54/0x90
   [<800088c0>] do_one_initcall+0xfc/0x160
   [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
   [<805e2930>] kernel_init+0x10/0xec
   [<8000ea68>] ret_from_fork+0x14/0x2c

other info that might help us debug this:

Chain exists of:
  &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(&crtc->mutex);
   lock(&dev->mode_config.mutex);
   lock(&crtc->mutex);
  lock(&imx_drm_device->mutex);

 *** DEADLOCK ***

6 locks held by swapp

Re: [PATCH] imx-drm: imx-drm-core: Fix circular locking dependency

2013-10-09 Thread Russell King - ARM Linux 
On Wed, Oct 09, 2013 at 08:07:12PM -0300, Fabio Estevam wrote:
> In order to avoid this lockdep warning, remove the locking from 
> imx_drm_encoder_get_mux_id() and imx_drm_crtc_panel_format_pins().
> 
> Tested on a mx6sabrelite and mx53qsb.
> 
> Reported-by: Russell King 
> Signed-off-by: Fabio Estevam 

Confirmed that it avoids the warning.

Tested-by: Russell King 

(Please change the reported-to to this address as well please, thanks.)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] imx-drm: imx-drm-core: Fix circular locking dependency

2013-10-09 Thread Fabio Estevam 
From: Fabio Estevam 

Booting a mx6 with CONFIG_PROVE_LOCKING we get:

==
[ INFO: possible circular locking dependency detected ]
3.12.0-rc4-next-20131009+ #34 Not tainted
---
swapper/0/1 is trying to acquire lock:
 (&imx_drm_device->mutex){+.+.+.}, at: [<804575a8>] 
imx_drm_encoder_get_mux_id+0x28/0x98

but task is already holding lock:
 (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&crtc->mutex){+.+...}:
   [<800777d0>] __lock_acquire+0x18d4/0x1c24
   [<80077fec>] lock_acquire+0x68/0x7c
   [<805ead5c>] _mutex_lock_nest_lock+0x58/0x3a8
   [<802fec50>] drm_crtc_init+0x48/0xa8
   [<80457c88>] imx_drm_add_crtc+0xd4/0x144
   [<8045e2e8>] ipu_drm_probe+0x114/0x1fc
   [<80312278>] platform_drv_probe+0x20/0x50
   [<80310c68>] driver_probe_device+0x110/0x22c
   [<80310e20>] __driver_attach+0x9c/0xa0
   [<8030f218>] bus_for_each_dev+0x5c/0x90
   [<80310750>] driver_attach+0x20/0x28
   [<8031034c>] bus_add_driver+0xdc/0x1dc
   [<803114d8>] driver_register+0x80/0xfc
   [<80312198>] __platform_driver_register+0x50/0x64
   [<808172fc>] ipu_drm_driver_init+0x18/0x20
   [<800088c0>] do_one_initcall+0xfc/0x160
   [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
   [<805e2930>] kernel_init+0x10/0xec
   [<8000ea68>] ret_from_fork+0x14/0x2c

-> #1 (&dev->mode_config.mutex){+.+.+.}:
   [<800777d0>] __lock_acquire+0x18d4/0x1c24
   [<80077fec>] lock_acquire+0x68/0x7c
   [<805eb100>] mutex_lock_nested+0x54/0x3a4
   [<802fe758>] drm_modeset_lock_all+0x20/0x54
   [<802fead4>] drm_encoder_init+0x20/0x7c
   [<80457ae4>] imx_drm_add_encoder+0x88/0xec
   [<80459838>] imx_ldb_probe+0x344/0x4fc
   [<80312278>] platform_drv_probe+0x20/0x50
   [<80310c68>] driver_probe_device+0x110/0x22c
   [<80310e20>] __driver_attach+0x9c/0xa0
   [<8030f218>] bus_for_each_dev+0x5c/0x90
   [<80310750>] driver_attach+0x20/0x28
   [<8031034c>] bus_add_driver+0xdc/0x1dc
   [<803114d8>] driver_register+0x80/0xfc
   [<80312198>] __platform_driver_register+0x50/0x64
   [<8081722c>] imx_ldb_driver_init+0x18/0x20
   [<800088c0>] do_one_initcall+0xfc/0x160
   [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
   [<805e2930>] kernel_init+0x10/0xec
   [<8000ea68>] ret_from_fork+0x14/0x2c

-> #0 (&imx_drm_device->mutex){+.+.+.}:
   [<805e510c>] print_circular_bug+0x74/0x2e0
   [<80077ad0>] __lock_acquire+0x1bd4/0x1c24
   [<80077fec>] lock_acquire+0x68/0x7c
   [<805eb100>] mutex_lock_nested+0x54/0x3a4
   [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98
   [<80459a98>] imx_ldb_encoder_prepare+0x34/0x114
   [<802ef724>] drm_crtc_helper_set_mode+0x1f0/0x4c0
   [<802f0344>] drm_crtc_helper_set_config+0x828/0x99c
   [<802ff270>] drm_mode_set_config_internal+0x5c/0xdc
   [<802eebe0>] drm_fb_helper_set_par+0x50/0xb4
   [<802af580>] fbcon_init+0x490/0x500
   [<802dd104>] visual_init+0xa8/0xf8
   [<802df414>] do_bind_con_driver+0x140/0x37c
   [<802df764>] do_take_over_console+0x114/0x1c4
   [<802af65c>] do_fbcon_takeover+0x6c/0xd4
   [<802b2b30>] fbcon_event_notify+0x7c8/0x818
   [<80049954>] notifier_call_chain+0x4c/0x8c
   [<80049cd8>] __blocking_notifier_call_chain+0x50/0x68
   [<80049d10>] blocking_notifier_call_chain+0x20/0x28
   [<802a75f0>] fb_notifier_call_chain+0x1c/0x24
   [<802a9224>] register_framebuffer+0x188/0x268
   [<802ee994>] drm_fb_helper_initial_config+0x2bc/0x4b8
   [<802f118c>] drm_fbdev_cma_init+0x7c/0xec
   [<80817288>] imx_fb_helper_init+0x54/0x90
   [<800088c0>] do_one_initcall+0xfc/0x160
   [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
   [<805e2930>] kernel_init+0x10/0xec
   [<8000ea68>] ret_from_fork+0x14/0x2c

other info that might help us debug this:

Chain exists of:
  &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(&crtc->mutex);
   lock(&dev->mode_config.mutex);
   lock(&crtc->mutex);
  lock(&imx_drm_device->mutex);

 *** DEADLOCK ***

6 locks held by swapp

RE: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor

2013-10-09 Thread KY Srinivasan 


> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Wednesday, October 09, 2013 3:50 PM
> To: KY Srinivasan
> Cc: Olaf Hering; x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; a...@canonical.com;
> jasow...@redhat.com; t...@linutronix.de; jbeul...@suse.com; b...@alien8.de
> Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency
> from the hypervisor
> 
> On 09/27/2013 08:35 AM, KY Srinivasan wrote:
> >
> > Thanks Olaf. Could you submit the patch.
> >
> 
> Haven't heard anything from Olaf... could you fold in the fix and resumbit?

I think Olaf sent the updated patch out; I will dig up the email and resend it.

Regards,

K. Y
> 
>   -hpa
> 

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

RE: [PATCH 00/28] staging: comedi: s626: tidy up

2013-10-09 Thread Hartley Sweeten 
On Tuesday, October 08, 2013 11:06 AM, Ian Abbott wrote:
>
> Tidy up the s626 comedi driver a bit.

This driver is mind numbingly hard to follow... All the subtracted bit shifting
and masking is still a mess. Probably why the code is so comment happy.

But, your cleanup does help so...

Reviewed-by: H Hartley Sweeten 

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

My friendly greetings

2013-10-09 Thread Anetta 
My Boss has instructed me to contact you with regards to a transaction worth 
22.4million pounds to discuss with you. Reply to his private email mark-
jcar...@hotmail.co.uk  for more information.

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

[PATCH 1/1] staging: xillybus: Use module_platform_driver

2013-10-09 Thread Sachin Kamat 
module_platform_driver simplifies the code by removing the boilerplate.

Signed-off-by: Sachin Kamat 
---
 drivers/staging/xillybus/xillybus_of.c |   13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/staging/xillybus/xillybus_of.c 
b/drivers/staging/xillybus/xillybus_of.c
index 92c2931..2ae045e 100644
--- a/drivers/staging/xillybus/xillybus_of.c
+++ b/drivers/staging/xillybus/xillybus_of.c
@@ -198,15 +198,4 @@ static struct platform_driver xillybus_platform_driver = {
},
 };
 
-static int __init xillybus_of_init(void)
-{
-   return platform_driver_register(&xillybus_platform_driver);
-}
-
-static void __exit xillybus_of_exit(void)
-{
-   platform_driver_unregister(&xillybus_platform_driver);
-}
-
-module_init(xillybus_of_init);
-module_exit(xillybus_of_exit);
+module_platform_driver(xillybus_platform_driver);
-- 
1.7.9.5

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