Re: [PATCH] Re: cciss: warning: right shift count >= width of type

2007-08-12 Thread Rene Herman 

On 08/12/2007 10:32 PM, James Bottomley wrote:


On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:

On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:

@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
-   c->Request.CDB[2]= (start_blk >> 56) & 0xff;   //MSB
-   c->Request.CDB[3]= (start_blk >> 48) & 0xff;
-   c->Request.CDB[4]= (start_blk >> 40) & 0xff;
-   c->Request.CDB[5]= (start_blk >> 32) & 0xff;
-   c->Request.CDB[6]= (start_blk >> 24) & 0xff;
-   c->Request.CDB[7]= (start_blk >> 16) & 0xff;
-   c->Request.CDB[8]= (start_blk >>  8) & 0xff;
+   c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;  //MSB
+   c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+   c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+   c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+   c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+   c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+   c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;

put_unaligned(cpu_to_be64(start_blk), >Request.CDB[2]);

which is what's happening here anyway.


Well ... this was debated a while ago ad nauseam:

http://marc.info/?t=117699555300010

The main objection to what you propose is that it forces the u64
coercion even in the 32 bit start_blk case.  The preferred solution as a
result of that debate was simply to us a macro Andrew introduced:

upper_32_bits()

Which will silently replace zero in the non LBD case.  I actually
thought this had already been done.


I see. Will assume it's somewhere in the pipeline.

Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: cciss: warning: right shift count >= width of type

2007-08-12 Thread James Bottomley 
On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:
> On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
> > @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
> > } else {
> > c->Request.CDBLen = 16;
> > c->Request.CDB[1]= 0;
> > -   c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
> > -   c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> > -   c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> > -   c->Request.CDB[5]= (start_blk >> 32) & 0xff;
> > -   c->Request.CDB[6]= (start_blk >> 24) & 0xff;
> > -   c->Request.CDB[7]= (start_blk >> 16) & 0xff;
> > -   c->Request.CDB[8]= (start_blk >>  8) & 0xff;
> > +   c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;   
> > //MSB
> > +   c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
> > +   c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
> > +   c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
> > +   c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
> > +   c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
> > +   c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;
> 
>   put_unaligned(cpu_to_be64(start_blk), >Request.CDB[2]);
> 
> which is what's happening here anyway.

Well ... this was debated a while ago ad nauseam:

http://marc.info/?t=117699555300010

The main objection to what you propose is that it forces the u64
coercion even in the 32 bit start_blk case.  The preferred solution as a
result of that debate was simply to us a macro Andrew introduced:

upper_32_bits()

Which will silently replace zero in the non LBD case.  I actually
thought this had already been done.

James


James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: cciss: warning: right shift count >= width of type

2007-08-12 Thread Rene Herman 

On 08/12/2007 08:58 AM, Al Viro wrote:


On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:



+   c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;  //MSB
+   c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+   c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+   c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+   c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+   c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+   c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;


put_unaligned(cpu_to_be64(start_blk), >Request.CDB[2]);

which is what's happening here anyway.


Well, yes. There are a few more of these in the driver and this wants a 
maintainer (whom I can't reach @hp.com) comment.


Is that 16-bit one for CCISS_READ_10 really right? Either:

put_unaligned(cpu_to_be32(creq->nr_sectors), >Request.CDB[6]);

or possibly:

put_unaligned(cpu_to_be16(creq->nr_sectors), >Request.CDB[8]);

would look less surprising than the current 16-bit in 24-bit thing and the 
"sect >> 24" comment there seems to imply the first?


(the implcit downcasting in that case is fine, right?)

Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..9fb6b3c 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1711,10 +1712,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int 
ctlr, void *buff, size_
c->Request.Type.Direction = XFER_READ;
c->Request.Timeout = 0;
c->Request.CDB[0] = cmd;
-   c->Request.CDB[6] = (size >> 24) & 0xFF;//MSB
-   c->Request.CDB[7] = (size >> 16) & 0xFF;
-   c->Request.CDB[8] = (size >> 8) & 0xFF;
-   c->Request.CDB[9] = size & 0xFF;
+   put_unaligned(cpu_to_be32(size), >Request.CDB[6]);
break;
 
case CCISS_READ_CAPACITY:
@@ -1735,12 +1733,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int 
ctlr, void *buff, size_
c->Request.Timeout = 0;
c->Request.CDB[0] = cmd;
c->Request.CDB[1] = 0x10;
-   c->Request.CDB[10] = (size >> 24) & 0xFF;
-   c->Request.CDB[11] = (size >> 16) & 0xFF;
-   c->Request.CDB[12] = (size >> 8) & 0xFF;
-   c->Request.CDB[13] = size & 0xFF;
-   c->Request.Timeout = 0;
-   c->Request.CDB[0] = cmd;
+   put_unaligned(cpu_to_be32(size), >Request.CDB[10]);
break;
case CCISS_CACHE_FLUSH:
c->Request.CDBLen = 12;
@@ -2598,29 +2591,15 @@ static void do_cciss_request(request_queue_t *q)
if (likely(blk_fs_request(creq))) {
if(h->cciss_read == CCISS_READ_10) {
c->Request.CDB[1] = 0;
-   c->Request.CDB[2] = (start_blk >> 24) & 0xff;   //MSB
-   c->Request.CDB[3] = (start_blk >> 16) & 0xff;
-   c->Request.CDB[4] = (start_blk >> 8) & 0xff;
-   c->Request.CDB[5] = start_blk & 0xff;
-   c->Request.CDB[6] = 0;  // (sect >> 24) & 0xff; MSB
-   c->Request.CDB[7] = (creq->nr_sectors >> 8) & 0xff;
-   c->Request.CDB[8] = creq->nr_sectors & 0xff;
+   put_unaligned(cpu_to_be32(start_blk), 
>Request.CDB[2]);
+   c->Request.CDB[6] = 0;
+   put_unaligned(cpu_to_be16(creq->nr_sectors), 
>Request.CDB[7]);
c->Request.CDB[9] = c->Request.CDB[11] = 
c->Request.CDB[12] = 0;
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
-   c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
-   c->Request.CDB[3]= (start_blk >> 48) & 0xff;
-   c->Request.CDB[4]= (start_blk >> 40) & 0xff;
-   c->Request.CDB[5]= (start_blk >> 32) & 0xff;
-   c->Request.CDB[6]= (start_blk >> 24) & 0xff;
-   c->Request.CDB[7]= (start_blk >> 16) & 0xff;
-   c->Request.CDB[8]= (start_blk >>  8) & 0xff;
-   c->Request.CDB[9]= start_blk & 0xff;
-   c->Request.CDB[10]= (creq->nr_sectors >>  24) & 0xff;
-   c->Request.CDB[11]= (creq->nr_sectors >>  16) & 0xff;
-   c->Request.CDB[12]= (creq->nr_sectors >>  8) & 0xff;
-   c->Request.CDB[13]= creq->nr_sectors & 0xff;
+

Re: [PATCH] Re: cciss: warning: right shift count >= width of type

2007-08-12 Thread Al Viro 
On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
> @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
>   } else {
>   c->Request.CDBLen = 16;
>   c->Request.CDB[1]= 0;
> - c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
> - c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> - c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> - c->Request.CDB[5]= (start_blk >> 32) & 0xff;
> - c->Request.CDB[6]= (start_blk >> 24) & 0xff;
> - c->Request.CDB[7]= (start_blk >> 16) & 0xff;
> - c->Request.CDB[8]= (start_blk >>  8) & 0xff;
> + c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;   
> //MSB
> + c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
> + c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
> + c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
> + c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
> + c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
> + c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;

put_unaligned(cpu_to_be64(start_blk), >Request.CDB[2]);

which is what's happening here anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: cciss: warning: right shift count = width of type

2007-08-12 Thread Al Viro 
On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
 @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
   } else {
   c-Request.CDBLen = 16;
   c-Request.CDB[1]= 0;
 - c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
 - c-Request.CDB[3]= (start_blk  48)  0xff;
 - c-Request.CDB[4]= (start_blk  40)  0xff;
 - c-Request.CDB[5]= (start_blk  32)  0xff;
 - c-Request.CDB[6]= (start_blk  24)  0xff;
 - c-Request.CDB[7]= (start_blk  16)  0xff;
 - c-Request.CDB[8]= (start_blk   8)  0xff;
 + c-Request.CDB[2]= ((u64)start_blk  56)  0xff;   
 //MSB
 + c-Request.CDB[3]= ((u64)start_blk  48)  0xff;
 + c-Request.CDB[4]= ((u64)start_blk  40)  0xff;
 + c-Request.CDB[5]= ((u64)start_blk  32)  0xff;
 + c-Request.CDB[6]= ((u64)start_blk  24)  0xff;
 + c-Request.CDB[7]= ((u64)start_blk  16)  0xff;
 + c-Request.CDB[8]= ((u64)start_blk   8)  0xff;

put_unaligned(cpu_to_be64(start_blk), c-Request.CDB[2]);

which is what's happening here anyway.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: cciss: warning: right shift count = width of type

2007-08-12 Thread Rene Herman 

On 08/12/2007 08:58 AM, Al Viro wrote:


On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:



+   c-Request.CDB[2]= ((u64)start_blk  56)  0xff;  //MSB
+   c-Request.CDB[3]= ((u64)start_blk  48)  0xff;
+   c-Request.CDB[4]= ((u64)start_blk  40)  0xff;
+   c-Request.CDB[5]= ((u64)start_blk  32)  0xff;
+   c-Request.CDB[6]= ((u64)start_blk  24)  0xff;
+   c-Request.CDB[7]= ((u64)start_blk  16)  0xff;
+   c-Request.CDB[8]= ((u64)start_blk   8)  0xff;


put_unaligned(cpu_to_be64(start_blk), c-Request.CDB[2]);

which is what's happening here anyway.


Well, yes. There are a few more of these in the driver and this wants a 
maintainer (whom I can't reach @hp.com) comment.


Is that 16-bit one for CCISS_READ_10 really right? Either:

put_unaligned(cpu_to_be32(creq-nr_sectors), c-Request.CDB[6]);

or possibly:

put_unaligned(cpu_to_be16(creq-nr_sectors), c-Request.CDB[8]);

would look less surprising than the current 16-bit in 24-bit thing and the 
sect  24 comment there seems to imply the first?


(the implcit downcasting in that case is fine, right?)

Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..9fb6b3c 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -40,6 +40,7 @@
 #include linux/blktrace_api.h
 #include asm/uaccess.h
 #include asm/io.h
+#include asm/unaligned.h
 
 #include linux/dma-mapping.h
 #include linux/blkdev.h
@@ -1711,10 +1712,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int 
ctlr, void *buff, size_
c-Request.Type.Direction = XFER_READ;
c-Request.Timeout = 0;
c-Request.CDB[0] = cmd;
-   c-Request.CDB[6] = (size  24)  0xFF;//MSB
-   c-Request.CDB[7] = (size  16)  0xFF;
-   c-Request.CDB[8] = (size  8)  0xFF;
-   c-Request.CDB[9] = size  0xFF;
+   put_unaligned(cpu_to_be32(size), c-Request.CDB[6]);
break;
 
case CCISS_READ_CAPACITY:
@@ -1735,12 +1733,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int 
ctlr, void *buff, size_
c-Request.Timeout = 0;
c-Request.CDB[0] = cmd;
c-Request.CDB[1] = 0x10;
-   c-Request.CDB[10] = (size  24)  0xFF;
-   c-Request.CDB[11] = (size  16)  0xFF;
-   c-Request.CDB[12] = (size  8)  0xFF;
-   c-Request.CDB[13] = size  0xFF;
-   c-Request.Timeout = 0;
-   c-Request.CDB[0] = cmd;
+   put_unaligned(cpu_to_be32(size), c-Request.CDB[10]);
break;
case CCISS_CACHE_FLUSH:
c-Request.CDBLen = 12;
@@ -2598,29 +2591,15 @@ static void do_cciss_request(request_queue_t *q)
if (likely(blk_fs_request(creq))) {
if(h-cciss_read == CCISS_READ_10) {
c-Request.CDB[1] = 0;
-   c-Request.CDB[2] = (start_blk  24)  0xff;   //MSB
-   c-Request.CDB[3] = (start_blk  16)  0xff;
-   c-Request.CDB[4] = (start_blk  8)  0xff;
-   c-Request.CDB[5] = start_blk  0xff;
-   c-Request.CDB[6] = 0;  // (sect  24)  0xff; MSB
-   c-Request.CDB[7] = (creq-nr_sectors  8)  0xff;
-   c-Request.CDB[8] = creq-nr_sectors  0xff;
+   put_unaligned(cpu_to_be32(start_blk), 
c-Request.CDB[2]);
+   c-Request.CDB[6] = 0;
+   put_unaligned(cpu_to_be16(creq-nr_sectors), 
c-Request.CDB[7]);
c-Request.CDB[9] = c-Request.CDB[11] = 
c-Request.CDB[12] = 0;
} else {
c-Request.CDBLen = 16;
c-Request.CDB[1]= 0;
-   c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
-   c-Request.CDB[3]= (start_blk  48)  0xff;
-   c-Request.CDB[4]= (start_blk  40)  0xff;
-   c-Request.CDB[5]= (start_blk  32)  0xff;
-   c-Request.CDB[6]= (start_blk  24)  0xff;
-   c-Request.CDB[7]= (start_blk  16)  0xff;
-   c-Request.CDB[8]= (start_blk   8)  0xff;
-   c-Request.CDB[9]= start_blk  0xff;
-   c-Request.CDB[10]= (creq-nr_sectors   24)  0xff;
-   c-Request.CDB[11]= (creq-nr_sectors   16)  0xff;
-   c-Request.CDB[12]= (creq-nr_sectors   8)  0xff;
-   c-Request.CDB[13]= creq-nr_sectors  0xff;
+   put_unaligned(cpu_to_be64(start_blk), 
c-Request.CDB[2]);
+

Re: [PATCH] Re: cciss: warning: right shift count = width of type

2007-08-12 Thread James Bottomley 
On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:
 On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
  @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
  } else {
  c-Request.CDBLen = 16;
  c-Request.CDB[1]= 0;
  -   c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
  -   c-Request.CDB[3]= (start_blk  48)  0xff;
  -   c-Request.CDB[4]= (start_blk  40)  0xff;
  -   c-Request.CDB[5]= (start_blk  32)  0xff;
  -   c-Request.CDB[6]= (start_blk  24)  0xff;
  -   c-Request.CDB[7]= (start_blk  16)  0xff;
  -   c-Request.CDB[8]= (start_blk   8)  0xff;
  +   c-Request.CDB[2]= ((u64)start_blk  56)  0xff;   
  //MSB
  +   c-Request.CDB[3]= ((u64)start_blk  48)  0xff;
  +   c-Request.CDB[4]= ((u64)start_blk  40)  0xff;
  +   c-Request.CDB[5]= ((u64)start_blk  32)  0xff;
  +   c-Request.CDB[6]= ((u64)start_blk  24)  0xff;
  +   c-Request.CDB[7]= ((u64)start_blk  16)  0xff;
  +   c-Request.CDB[8]= ((u64)start_blk   8)  0xff;
 
   put_unaligned(cpu_to_be64(start_blk), c-Request.CDB[2]);
 
 which is what's happening here anyway.

Well ... this was debated a while ago ad nauseam:

http://marc.info/?t=117699555300010

The main objection to what you propose is that it forces the u64
coercion even in the 32 bit start_blk case.  The preferred solution as a
result of that debate was simply to us a macro Andrew introduced:

upper_32_bits()

Which will silently replace zero in the non LBD case.  I actually
thought this had already been done.

James


James


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: cciss: warning: right shift count = width of type

2007-08-12 Thread Rene Herman 

On 08/12/2007 10:32 PM, James Bottomley wrote:


On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:

On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:

@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c-Request.CDBLen = 16;
c-Request.CDB[1]= 0;
-   c-Request.CDB[2]= (start_blk  56)  0xff;   //MSB
-   c-Request.CDB[3]= (start_blk  48)  0xff;
-   c-Request.CDB[4]= (start_blk  40)  0xff;
-   c-Request.CDB[5]= (start_blk  32)  0xff;
-   c-Request.CDB[6]= (start_blk  24)  0xff;
-   c-Request.CDB[7]= (start_blk  16)  0xff;
-   c-Request.CDB[8]= (start_blk   8)  0xff;
+   c-Request.CDB[2]= ((u64)start_blk  56)  0xff;  //MSB
+   c-Request.CDB[3]= ((u64)start_blk  48)  0xff;
+   c-Request.CDB[4]= ((u64)start_blk  40)  0xff;
+   c-Request.CDB[5]= ((u64)start_blk  32)  0xff;
+   c-Request.CDB[6]= ((u64)start_blk  24)  0xff;
+   c-Request.CDB[7]= ((u64)start_blk  16)  0xff;
+   c-Request.CDB[8]= ((u64)start_blk   8)  0xff;

put_unaligned(cpu_to_be64(start_blk), c-Request.CDB[2]);

which is what's happening here anyway.


Well ... this was debated a while ago ad nauseam:

http://marc.info/?t=117699555300010

The main objection to what you propose is that it forces the u64
coercion even in the 32 bit start_blk case.  The preferred solution as a
result of that debate was simply to us a macro Andrew introduced:

upper_32_bits()

Which will silently replace zero in the non LBD case.  I actually
thought this had already been done.


I see. Will assume it's somewhere in the pipeline.

Rene.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: cciss: warning: right shift count >= width of type

2007-08-11 Thread Rene Herman 

On 08/12/2007 03:25 AM, Rene Herman wrote:


On 08/12/2007 02:56 AM, Jesper Juhl wrote:


(whoops, forgot to add maintainer to Cc - now added)


Ehm... too late...


Useless followup though -- hp.com rejects me as it feels the SPF neutral 
results gmail sends due to me not using the gmail SMTP server and/or web 
interface is something it wants to listen to.


I see you are @gmail as well, which depending on how you use it might mean 
your are also not able to reach @hp. If anyone can get HP to fix their mail 
setup, that'd be useful.


Rene.





On 12/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:

Hi,

I've been building some randconfig kernels lately and I've noticed
this in a few builds :

drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this :

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 
0xff;//MSB

c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 
bits wide.

Thus it seems gcc is absolutely right in complaining about those
56, 48 & 40 bit shifts, since they are indeed wider than the type
in the "!CONFIG_LBD on a 32bit arch" case.


I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, 
the proper fix is probably to cast start_blk to an actual (guaranteed) 
64-bit value. Untested, uncompiled, and someone else may disagree:


Rene.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Re: cciss: warning: right shift count >= width of type

2007-08-11 Thread Rene Herman 

On 08/12/2007 02:28 AM, Jesper Juhl wrote:

I've been building some randconfig kernels lately and I've noticed 
this in a few builds : 


drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this : 


static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h : 
...

#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those 
56, 48 & 40 bit shifts, since they are indeed wider than the type 
in the "!CONFIG_LBD on a 32bit arch" case.



I must admit that I have no idear what the proper way to deal with 
that is, so I'll just report it so hopefully someone else can fix it.


By the way; I'm building current Linus git tree, head at commit 
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, the 
proper fix is probably to cast start_blk to an actual (guaranteed) 64-bit 
value. Untested, uncompiled, and someone else may disagree:


Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
-   c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
-   c->Request.CDB[3]= (start_blk >> 48) & 0xff;
-   c->Request.CDB[4]= (start_blk >> 40) & 0xff;
-   c->Request.CDB[5]= (start_blk >> 32) & 0xff;
-   c->Request.CDB[6]= (start_blk >> 24) & 0xff;
-   c->Request.CDB[7]= (start_blk >> 16) & 0xff;
-   c->Request.CDB[8]= (start_blk >>  8) & 0xff;
+   c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;   
//MSB
+   c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+   c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+   c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+   c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+   c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+   c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;
c->Request.CDB[9]= start_blk & 0xff;
c->Request.CDB[10]= (creq->nr_sectors >>  24) & 0xff;
c->Request.CDB[11]= (creq->nr_sectors >>  16) & 0xff;

[PATCH] Re: cciss: warning: right shift count >= width of type

2007-08-11 Thread Rene Herman 

On 08/12/2007 02:56 AM, Jesper Juhl wrote:


(whoops, forgot to add maintainer to Cc - now added)


Ehm... too late...


On 12/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:

Hi,

I've been building some randconfig kernels lately and I've noticed
this in a few builds :

drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this :

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48 & 40 bit shifts, since they are indeed wider than the type
in the "!CONFIG_LBD on a 32bit arch" case.


I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, the 
proper fix is probably to cast start_blk to an actual (guaranteed) 64-bit 
value. Untested, uncompiled, and someone else may disagree:


Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
-   c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
-   c->Request.CDB[3]= (start_blk >> 48) & 0xff;
-   c->Request.CDB[4]= (start_blk >> 40) & 0xff;
-   c->Request.CDB[5]= (start_blk >> 32) & 0xff;
-   c->Request.CDB[6]= (start_blk >> 24) & 0xff;
-   c->Request.CDB[7]= (start_blk >> 16) & 0xff;
-   c->Request.CDB[8]= (start_blk >>  8) & 0xff;
+   c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;   
//MSB
+   c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+   c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+   c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+   c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+   c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+   c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;
c->Request.CDB[9]= start_blk & 0xff;
c->Request.CDB[10]= (creq->nr_sectors >>  24) & 0xff;
c->Request.CDB[11]= (creq->nr_sectors >>  16) & 0xff;

Re: cciss: warning: right shift count >= width of type

2007-08-11 Thread Jesper Juhl 
(whoops, forgot to add maintainer to Cc - now added)

On 12/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've been building some randconfig kernels lately and I've noticed
> this in a few builds :
>
> drivers/block/cciss.c:2614: warning: right shift count >= width of type
> drivers/block/cciss.c:2615: warning: right shift count >= width of type
> drivers/block/cciss.c:2616: warning: right shift count >= width of type
>
> The code in question is this :
>
> static void do_cciss_request(struct request_queue *q)
> {
> ...
> sector_t start_blk;
> ...
> c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
> c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> ...
> }
>
>
> The problem stems from these lines in include/linux/types.h :
> ...
> #ifdef CONFIG_LBD
> typedef u64 sector_t;
> #else
> typedef unsigned long sector_t;
> #endif
> ...
>
> So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
> Thus it seems gcc is absolutely right in complaining about those
> 56, 48 & 40 bit shifts, since they are indeed wider than the type
> in the "!CONFIG_LBD on a 32bit arch" case.
>
>
> I must admit that I have no idear what the proper way to deal with
> that is, so I'll just report it so hopefully someone else can fix it.
>
> By the way; I'm building current Linus git tree, head at commit
> ac07860264bd2b18834d3fa3be47032115524cea
>
>
> Kind regards,
>   Jesper Juhl
>
>
>


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

cciss: warning: right shift count >= width of type

2007-08-11 Thread Jesper Juhl 
Hi,

I've been building some randconfig kernels lately and I've noticed 
this in a few builds : 

drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this : 

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h : 
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those 
56, 48 & 40 bit shifts, since they are indeed wider than the type 
in the "!CONFIG_LBD on a 32bit arch" case.


I must admit that I have no idear what the proper way to deal with 
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit 
ac07860264bd2b18834d3fa3be47032115524cea


Kind regards,
  Jesper Juhl


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

cciss: warning: right shift count = width of type

2007-08-11 Thread Jesper Juhl 
Hi,

I've been building some randconfig kernels lately and I've noticed 
this in a few builds : 

drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type

The code in question is this : 

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
c-Request.CDB[3]= (start_blk  48)  0xff;
c-Request.CDB[4]= (start_blk  40)  0xff;
...
}


The problem stems from these lines in include/linux/types.h : 
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those 
56, 48  40 bit shifts, since they are indeed wider than the type 
in the !CONFIG_LBD on a 32bit arch case.


I must admit that I have no idear what the proper way to deal with 
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit 
ac07860264bd2b18834d3fa3be47032115524cea


Kind regards,
  Jesper Juhl


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cciss: warning: right shift count = width of type

2007-08-11 Thread Jesper Juhl 
(whoops, forgot to add maintainer to Cc - now added)

On 12/08/07, Jesper Juhl [EMAIL PROTECTED] wrote:
 Hi,

 I've been building some randconfig kernels lately and I've noticed
 this in a few builds :

 drivers/block/cciss.c:2614: warning: right shift count = width of type
 drivers/block/cciss.c:2615: warning: right shift count = width of type
 drivers/block/cciss.c:2616: warning: right shift count = width of type

 The code in question is this :

 static void do_cciss_request(struct request_queue *q)
 {
 ...
 sector_t start_blk;
 ...
 c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
 c-Request.CDB[3]= (start_blk  48)  0xff;
 c-Request.CDB[4]= (start_blk  40)  0xff;
 ...
 }


 The problem stems from these lines in include/linux/types.h :
 ...
 #ifdef CONFIG_LBD
 typedef u64 sector_t;
 #else
 typedef unsigned long sector_t;
 #endif
 ...

 So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
 Thus it seems gcc is absolutely right in complaining about those
 56, 48  40 bit shifts, since they are indeed wider than the type
 in the !CONFIG_LBD on a 32bit arch case.


 I must admit that I have no idear what the proper way to deal with
 that is, so I'll just report it so hopefully someone else can fix it.

 By the way; I'm building current Linus git tree, head at commit
 ac07860264bd2b18834d3fa3be47032115524cea


 Kind regards,
   Jesper Juhl





-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Re: cciss: warning: right shift count = width of type

2007-08-11 Thread Rene Herman 

On 08/12/2007 02:56 AM, Jesper Juhl wrote:


(whoops, forgot to add maintainer to Cc - now added)


Ehm... too late...


On 12/08/07, Jesper Juhl [EMAIL PROTECTED] wrote:

Hi,

I've been building some randconfig kernels lately and I've noticed
this in a few builds :

drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type

The code in question is this :

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
c-Request.CDB[3]= (start_blk  48)  0xff;
c-Request.CDB[4]= (start_blk  40)  0xff;
...
}


The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48  40 bit shifts, since they are indeed wider than the type
in the !CONFIG_LBD on a 32bit arch case.


I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, the 
proper fix is probably to cast start_blk to an actual (guaranteed) 64-bit 
value. Untested, uncompiled, and someone else may disagree:


Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c-Request.CDBLen = 16;
c-Request.CDB[1]= 0;
-   c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
-   c-Request.CDB[3]= (start_blk  48)  0xff;
-   c-Request.CDB[4]= (start_blk  40)  0xff;
-   c-Request.CDB[5]= (start_blk  32)  0xff;
-   c-Request.CDB[6]= (start_blk  24)  0xff;
-   c-Request.CDB[7]= (start_blk  16)  0xff;
-   c-Request.CDB[8]= (start_blk   8)  0xff;
+   c-Request.CDB[2]= ((u64)start_blk  56)  0xff;   
//MSB
+   c-Request.CDB[3]= ((u64)start_blk  48)  0xff;
+   c-Request.CDB[4]= ((u64)start_blk  40)  0xff;
+   c-Request.CDB[5]= ((u64)start_blk  32)  0xff;
+   c-Request.CDB[6]= ((u64)start_blk  24)  0xff;
+   c-Request.CDB[7]= ((u64)start_blk  16)  0xff;
+   c-Request.CDB[8]= ((u64)start_blk   8)  0xff;
c-Request.CDB[9]= start_blk  0xff;
c-Request.CDB[10]= (creq-nr_sectors   24)  0xff;
c-Request.CDB[11]= (creq-nr_sectors   16)  0xff;

[PATCH] Re: cciss: warning: right shift count = width of type

2007-08-11 Thread Rene Herman 

On 08/12/2007 02:28 AM, Jesper Juhl wrote:

I've been building some randconfig kernels lately and I've noticed 
this in a few builds : 


drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type

The code in question is this : 


static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
c-Request.CDB[3]= (start_blk  48)  0xff;
c-Request.CDB[4]= (start_blk  40)  0xff;
...
}


The problem stems from these lines in include/linux/types.h : 
...

#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those 
56, 48  40 bit shifts, since they are indeed wider than the type 
in the !CONFIG_LBD on a 32bit arch case.



I must admit that I have no idear what the proper way to deal with 
that is, so I'll just report it so hopefully someone else can fix it.


By the way; I'm building current Linus git tree, head at commit 
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, the 
proper fix is probably to cast start_blk to an actual (guaranteed) 64-bit 
value. Untested, uncompiled, and someone else may disagree:


Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c-Request.CDBLen = 16;
c-Request.CDB[1]= 0;
-   c-Request.CDB[2]= (start_blk  56)  0xff;//MSB
-   c-Request.CDB[3]= (start_blk  48)  0xff;
-   c-Request.CDB[4]= (start_blk  40)  0xff;
-   c-Request.CDB[5]= (start_blk  32)  0xff;
-   c-Request.CDB[6]= (start_blk  24)  0xff;
-   c-Request.CDB[7]= (start_blk  16)  0xff;
-   c-Request.CDB[8]= (start_blk   8)  0xff;
+   c-Request.CDB[2]= ((u64)start_blk  56)  0xff;   
//MSB
+   c-Request.CDB[3]= ((u64)start_blk  48)  0xff;
+   c-Request.CDB[4]= ((u64)start_blk  40)  0xff;
+   c-Request.CDB[5]= ((u64)start_blk  32)  0xff;
+   c-Request.CDB[6]= ((u64)start_blk  24)  0xff;
+   c-Request.CDB[7]= ((u64)start_blk  16)  0xff;
+   c-Request.CDB[8]= ((u64)start_blk   8)  0xff;
c-Request.CDB[9]= start_blk  0xff;
c-Request.CDB[10]= (creq-nr_sectors   24)  0xff;
c-Request.CDB[11]= (creq-nr_sectors   16)  0xff;

Re: [PATCH] Re: cciss: warning: right shift count = width of type

2007-08-11 Thread Rene Herman 

On 08/12/2007 03:25 AM, Rene Herman wrote:


On 08/12/2007 02:56 AM, Jesper Juhl wrote:


(whoops, forgot to add maintainer to Cc - now added)


Ehm... too late...


Useless followup though -- hp.com rejects me as it feels the SPF neutral 
results gmail sends due to me not using the gmail SMTP server and/or web 
interface is something it wants to listen to.


I see you are @gmail as well, which depending on how you use it might mean 
your are also not able to reach @hp. If anyone can get HP to fix their mail 
setup, that'd be useful.


Rene.





On 12/08/07, Jesper Juhl [EMAIL PROTECTED] wrote:

Hi,

I've been building some randconfig kernels lately and I've noticed
this in a few builds :

drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type

The code in question is this :

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk  56)  
0xff;//MSB

c-Request.CDB[3]= (start_blk  48)  0xff;
c-Request.CDB[4]= (start_blk  40)  0xff;
...
}


The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 
bits wide.

Thus it seems gcc is absolutely right in complaining about those
56, 48  40 bit shifts, since they are indeed wider than the type
in the !CONFIG_LBD on a 32bit arch case.


I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, 
the proper fix is probably to cast start_blk to an actual (guaranteed) 
64-bit value. Untested, uncompiled, and someone else may disagree:


Rene.



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/