fix req->cmd == INT cases
Subsystems (3)
PATCH 1/1 fix req->cmd == INT cases
Quoted 1 line
From
6f4641911701cbdbe01516305b682012d8c6982aMon Sep 17 00:00:00 2001
Date: Tue, 19 Jun 2007 18:54:54 +0300
I have unearthed very old bugs in stale drivers that still used request->cmd as a READ|WRITE int.
This patch is maybe a proof that these drivers have not been used for a long time. Should they be removed completely?
If you are CCed it means your name was in one of these drivers source files, or in the MAINTAINERS file. Please acknowledge the possible removal of this old driver.
drivers/acorn/block/fd1772.c
Jens Axboe
Paul Bristow <[email protected]>
Dave Gilbert ([email protected])
drivers/acorn/block/mfmhd.c
TO: Russell King <[email protected]>
TO: Dave Alan Gilbert <[email protected]>
drivers/block/amiflop.c
Greg Harp
Joerg Dorchain
drivers/block/nbd.c
Paul Clements <[email protected]>
Pavel Machek <[email protected]>
Steven Whitehouse <[email protected]>
drivers/cdrom/aztcd.c
Eberhard Moenkeberg <[email protected]>
Werner Zimmermann([email protected])
drivers/cdrom/cm206.c
David van Leeuwen <[email protected]>
drivers/cdrom/gscd.c
Oliver Raupach <[email protected]>
drivers/cdrom/mcdx.c
Heiko Schlittermann <[email protected]>
drivers/cdrom/optcd.c
Leo Spiekman <[email protected]>
drivers/cdrom/sjcd.c
Vadim V. Model <[email protected]>
[email protected]
[email protected]
drivers/ide/legacy/hd.c
Linus Trovalds
--- drivers/acorn/block/fd1772.c | 2 +- drivers/acorn/block/mfmhd.c | 9 +++++---- drivers/block/amiflop.c | 2 +- drivers/block/nbd.c | 2 +- drivers/cdrom/aztcd.c | 2 +- drivers/cdrom/cm206.c | 2 +- drivers/cdrom/gscd.c | 2 +- drivers/cdrom/mcdx.c | 2 +- drivers/cdrom/optcd.c | 2 +- drivers/cdrom/sjcd.c | 2 +- drivers/ide/legacy/hd.c | 4 ++-- 11 files changed, 16 insertions(+), 15 deletions(-)
drivers/acorn/block/fd1772.c +1 -1
@@ -1246,7 +1246,7 @@ repeat:del_timer (&motor_off_timer); ReqCnt =0 ; - ReqCmd =CURRENT ->cmd; + ReqCmd =rq_data_dir (CURRENT ); ReqBlock =CURRENT ->sector; ReqBuffer =CURRENT ->buffer;setup_req_params (drive);
drivers/acorn/block/mfmhd.c +0 -0
@@ -439,7 +439,7 @@ static void mfm_rw_intr(void) a choice of command end or some data which is ready to be
collected */
/* I think we have to transfer data while the interrupt line is on
and its
not any other type of interrupt */
- if (CURRENT->cmd == WRITE) {
+ if (rq_data_dir(CURRENT) == WRITE) {
extern void hdc63463_writedma(void);
if ((hdc63463_dataleft <= 0) && (!(mfm_status & STAT_CED))) {
printk("mfm_rw_intr: Apparent DMA write request when no
more to DMA\n");
@@ -799,7 +799,7 @@ static void issue_request(unsigned int block,
unsigned int nsect,
raw_cmd.head = start_head;
raw_cmd.cylinder = track / p->heads;
raw_cmd.cmdtype = CURRENT->cmd;
- raw_cmd.cmdcode = CURRENT->cmd == WRITE ? CMD_WD : CMD_RD;
+ raw_cmd.cmdcode = rq_data_dir(CURRENT) == WRITE ? CMD_WD : CMD_RD;
raw_cmd.cmddata[0] = dev + 1; /* DAG: +1 to get US */
raw_cmd.cmddata[1] = raw_cmd.head;
raw_cmd.cmddata[2] = raw_cmd.cylinder >> 8;
@@ -830,7 +830,7 @@ static void issue_request(unsigned int block,
unsigned int nsect,
hdc63463_dataleft = nsect * 256; /* Better way? */
DBG("mfm%c: %sing: CHS=%d/%d/%d, sectors=%d, buffer=0x%08lx (%p)\n",
- raw_cmd.dev + 'a', (CURRENT->cmd == READ) ? "read" : "writ",
+ raw_cmd.dev + 'a', rq_data_dir(CURRENT) == READ ? "read" : "writ",
raw_cmd.cylinder,
raw_cmd.head,
raw_cmd.sector, nsect, (unsigned long) Copy_buffer, CURRENT);@@ -917,7 +917,8 @@ static void mfm_request(void)
DBG("mfm_request: block after offset=%d\n", block);- if (CURRENT->cmd != READ && CURRENT->cmd != WRITE) {
+ if (rq_data_dir(CURRENT) != READ &&
+ rq_data_dir(CURRENT) != WRITE) {
printk("unknown mfm-command %d\n", CURRENT->cmd);
end_request(CURRENT, 0);
Busy = 0;drivers/block/amiflop.c +1 -1
@@ -1363,7 +1363,7 @@ static void redo_fd_request(void)#ifdef DEBUG printk ("fd: sector %ld + %d requested for %s\n" ,CURRENT ->sector,cnt, - (CURRENT ->cmd==READ )?"read" :"write" ); + (rq_data_dir (CURRENT ) ==READ ) ?"read" :"write" );#endif block =CURRENT ->sector + cnt;if ((int )block > floppy->blocks) {
drivers/block/nbd.c +0 -0
@@ -416,7 +416,7 @@ static void nbd_clear_que(struct nbd_device *lo)/* * We always wait for result of write, for now. It would be nice to
make it optional
* in future
- * if ((req->cmd == WRITE) && (lo->flags & NBD_WRITE_NOCHK))
+ * if ((rq_data_dir(req) == WRITE) && (lo->flags & NBD_WRITE_NOCHK))
* { printk( "Warning: Ignoring result!\n"); nbd_end_request( req ); }
*/
drivers/cdrom/aztcd.c +1 -1
@@ -229,7 +229,7 @@ static struct request_queue *azt_queue;static int current_valid (void ) {return CURRENT && -CURRENT ->cmd ==READ && +rq_data_dir (CURRENT ) ==READ &&CURRENT ->sector !=-1 ; }
drivers/cdrom/cm206.c +1 -1
@@ -851,7 +851,7 @@ static void do_cm206_request(request_queue_t * q)if (!req)return ; -if (req->cmd !=READ ) { +if (rq_data_dir (req) !=READ ) {debug (("Non-read command %d on cdrom\n" , req->cmd));end_request (req,0 );continue ;
drivers/cdrom/gscd.c +1 -1
@@ -264,7 +264,7 @@ repeat:if (req->sector ==-1 ) goto out; -if (req->cmd !=READ ) { +if (rq_data_dir (req) !=READ ) {printk ("GSCD: bad cmd %u\n" ,rq_data_dir (req));end_request (req,0 ); goto repeat;
drivers/cdrom/mcdx.c +1 -1
@@ -596,7 +596,7 @@ static void do_mcdx_request(request_queue_t * q)xtrace (REQUEST ,"do_request() (%lu + %lu)\n" , req->sector, req->nr_sectors); -if (req->cmd !=READ ) { +if (rq_data_dir (req) !=READ ) {xwarn ("do_request(): non-read command to cd!!\n" );xtrace (REQUEST ,"end_request(0): write\n" );end_request (req,0 );
drivers/cdrom/optcd.c +1 -1
@@ -977,7 +977,7 @@ static int update_toc(void)static int current_valid (void ) {return CURRENT && -CURRENT ->cmd ==READ && +rq_data_dir (CURRENT ) ==READ &&CURRENT ->sector !=-1 ; }
drivers/cdrom/sjcd.c +1 -1
@@ -1064,7 +1064,7 @@ static void sjcd_invalidate_buffers(void)static int current_valid (void ) {return CURRENT && -CURRENT ->cmd ==READ && +rq_data_dir (CURRENT ) ==READ &&CURRENT ->sector !=-1 ; }
drivers/ide/legacy/hd.c +2 -2
@@ -622,8 +622,8 @@ repeat: head = track % disk->head; cyl = track / disk->head;#ifdef DEBUG -printk ("%s: %sing: CHS=%d/%d/%d, sectors=%d, buffer=%p\n" , - req->rq_disk->disk_name, (req->cmd ==READ )?"read" :"writ" , +printk ("%s: %s: CHS=%d/%d/%d, sectors=%d, buffer=%p\n" , + req->rq_disk->disk_name,dma_dir_to_string (rq_dma_dir (req)), cyl, head, sec, nsect, req->buffer);#endif if (blk_fs_request (req)) {
Signature · 1 line
1.5.0.4.402.g8035
Quoted 7 lines · Boaz Harrosh
From
6f4641911701cbdbe01516305b682012d8c6982aMon Sep 17 00:00:00 2001
Date: Tue, 19 Jun 2007 18:54:54 +0300I have unearthed very old bugs in stale drivers that still used
request->cmdas a READ|WRITE int.
This patch is maybe a proof that these drivers have not been used for a long time. Should they be removed completely?
If you look at most of the code, it's inside ifdef debug statements or comments most of them. So I don't think you can base any removal suggestion on that.
The patch itself looks fine though, if you send one that isn't mangled I'll apply it to the 2.6.23 branch.
Signature · 1 line
Jens Axboe
Quoted 8 lines · Jens Axboe
If you look at most of the code, it's inside ifdef debug statements or comments most of them. So I don't think you can base any removal suggestion on that.
The patch itself looks fine though, if you send one that isn't mangled I'll apply it to the 2.6.23 branch.
Sorry new Thunderbird Installation. I forgot it does that.
- I have unearthed very old bugs in stale drivers that still used request->cmd as a READ|WRITE int
- This patch is maybe a proof that these drivers have not been used for a long time. Should they be removed completely?
Drivers that currently do not work for sure:
drivers/acorn/block/fd1772.c
drivers/acorn/block/mfmhd.c
drivers/cdrom/aztcd.c
drivers/cdrom/cm206.c
drivers/cdrom/gscd.c
drivers/cdrom/mcdx.c
drivers/cdrom/optcd.c
drivers/cdrom/sjcd.c
Drivers with cosmetic fixes only:
drivers/block/amiflop.c
drivers/block/nbd.c
drivers/ide/legacy/hd.c
--- drivers/acorn/block/fd1772.c | 2 +- drivers/acorn/block/mfmhd.c | 13 +++---------- drivers/block/amiflop.c | 2 +- drivers/block/nbd.c | 2 +- drivers/cdrom/aztcd.c | 2 +- drivers/cdrom/cm206.c | 2 +- drivers/cdrom/gscd.c | 2 +- drivers/cdrom/mcdx.c | 2 +- drivers/cdrom/optcd.c | 2 +- drivers/cdrom/sjcd.c | 2 +- drivers/ide/legacy/hd.c | 3 ++- 11 files changed, 14 insertions(+), 20 deletions(-)
drivers/acorn/block/fd1772.c +1 -1
@@ -1246,7 +1246,7 @@ repeat:del_timer (&motor_off_timer); ReqCnt =0 ; - ReqCmd =CURRENT ->cmd; + ReqCmd =rq_data_dir (CURRENT ); ReqBlock =CURRENT ->sector; ReqBuffer =CURRENT ->buffer;setup_req_params (drive);
drivers/acorn/block/mfmhd.c +3 -10
@@ -439,7 +439,7 @@ static void mfm_rw_intr(void)a choice of command end or some data which is ready to be collected */ /* I think we have to transfer data while the interrupt line is on and its not any other type of interrupt */ -if (CURRENT ->cmd ==WRITE ) { +if (rq_data_dir (CURRENT ) ==WRITE ) {extern void hdc63463_writedma (void );if ((hdc63463_dataleft <=0 ) && (!(mfm_status &STAT_CED ))) {printk ("mfm_rw_intr: Apparent DMA write request when no more to DMA\n" );
@@ -799,7 +799,7 @@ static void issue_request(unsigned int block, unsigned int nsect, raw_cmd.head = start_head; raw_cmd.cylinder = track / p->heads; raw_cmd.cmdtype =CURRENT ->cmd; - raw_cmd.cmdcode =CURRENT ->cmd ==WRITE ?CMD_WD :CMD_RD ; + raw_cmd.cmdcode =rq_data_dir (CURRENT ) ==WRITE ?CMD_WD :CMD_RD ; raw_cmd.cmddata[0 ] = dev +1 ;/* DAG: +1 to get US */ raw_cmd.cmddata[1 ] = raw_cmd.head; raw_cmd.cmddata[2 ] = raw_cmd.cylinder >>8 ;
@@ -830,7 +830,7 @@ static void issue_request(unsigned int block, unsigned int nsect, hdc63463_dataleft = nsect *256 ;/* Better way? */ DBG ("mfm%c: %sing: CHS=%d/%d/%d, sectors=%d, buffer=0x%08lx (%p)\n" , - raw_cmd.dev +'a' , (CURRENT ->cmd ==READ ) ?"read" :"writ" , + raw_cmd.dev +'a' ,rq_data_dir (CURRENT ) ==READ ?"read" :"writ" , raw_cmd.cylinder, raw_cmd.head, raw_cmd.sector, nsect, (unsigned long ) Copy_buffer,CURRENT );
@@ -917,13 +917,6 @@ static void mfm_request(void)DBG ("mfm_request: block after offset=%d\n" , block); -if (CURRENT ->cmd !=READ &&CURRENT ->cmd !=WRITE ) { -printk ("unknown mfm-command %d\n" ,CURRENT ->cmd); -end_request (CURRENT ,0 ); - Busy =0 ; -printk ("mfm: continue 4\n" ); -continue ; - }issue_request (block, nsect,CURRENT );break ;
drivers/block/amiflop.c +1 -1
@@ -1363,7 +1363,7 @@ static void redo_fd_request(void)#ifdef DEBUG printk ("fd: sector %ld + %d requested for %s\n" ,CURRENT ->sector,cnt, - (CURRENT ->cmd==READ )?"read" :"write" ); + (rq_data_dir (CURRENT ) ==READ ) ?"read" :"write" );#endif block =CURRENT ->sector + cnt;if ((int )block > floppy->blocks) {
drivers/block/nbd.c +1 -1
@@ -416,7 +416,7 @@ static void nbd_clear_que(struct nbd_device *lo)/* * We always wait for result of write, for now. It would be nice to make it optional * in future -* if ((req->cmd == WRITE) && (lo->flags & NBD_WRITE_NOCHK)) +* if ((rq_data_dir(req) == WRITE) && (lo->flags & NBD_WRITE_NOCHK)) * { printk( "Warning: Ignoring result!\n"); nbd_end_request( req ); } */
drivers/cdrom/aztcd.c +1 -1
@@ -229,7 +229,7 @@ static struct request_queue *azt_queue;static int current_valid (void ) {return CURRENT && -CURRENT ->cmd ==READ && +rq_data_dir (CURRENT ) ==READ &&CURRENT ->sector !=-1 ; }
drivers/cdrom/cm206.c +1 -1
@@ -851,7 +851,7 @@ static void do_cm206_request(request_queue_t * q)if (!req)return ; -if (req->cmd !=READ ) { +if (rq_data_dir (req) !=READ ) {debug (("Non-read command %d on cdrom\n" , req->cmd));end_request (req,0 );continue ;
drivers/cdrom/gscd.c +1 -1
@@ -264,7 +264,7 @@ repeat:if (req->sector ==-1 ) goto out; -if (req->cmd !=READ ) { +if (rq_data_dir (req) !=READ ) {printk ("GSCD: bad cmd %u\n" ,rq_data_dir (req));end_request (req,0 ); goto repeat;
drivers/cdrom/mcdx.c +1 -1
@@ -596,7 +596,7 @@ static void do_mcdx_request(request_queue_t * q)xtrace (REQUEST ,"do_request() (%lu + %lu)\n" , req->sector, req->nr_sectors); -if (req->cmd !=READ ) { +if (rq_data_dir (req) !=READ ) {xwarn ("do_request(): non-read command to cd!!\n" );xtrace (REQUEST ,"end_request(0): write\n" );end_request (req,0 );
drivers/cdrom/optcd.c +1 -1
@@ -977,7 +977,7 @@ static int update_toc(void)static int current_valid (void ) {return CURRENT && -CURRENT ->cmd ==READ && +rq_data_dir (CURRENT ) ==READ &&CURRENT ->sector !=-1 ; }
drivers/cdrom/sjcd.c +1 -1
@@ -1064,7 +1064,7 @@ static void sjcd_invalidate_buffers(void)static int current_valid (void ) {return CURRENT && -CURRENT ->cmd ==READ && +rq_data_dir (CURRENT ) ==READ &&CURRENT ->sector !=-1 ; }
drivers/ide/legacy/hd.c +2 -1
@@ -623,7 +623,8 @@ repeat: cyl = track / disk->head;#ifdef DEBUG printk ("%s: %sing: CHS=%d/%d/%d, sectors=%d, buffer=%p\n" , - req->rq_disk->disk_name, (req->cmd ==READ )?"read" :"writ" , + req->rq_disk->disk_name, +req_data_dir (req) ==READ ?"read" :"writ" , cyl, head, sec, nsect, req->buffer);#endif if (blk_fs_request (req)) {
Signature · 1 line
1.5.0.4.402.g8035
Quoted 10 lines · Boaz Harrosh
Quoted 8 lines · Jens Axboe
If you look at most of the code, it's inside ifdef debug statements or comments most of them. So I don't think you can base any removal suggestion on that.
The patch itself looks fine though, if you send one that isn't mangled I'll apply it to the 2.6.23 branch.
Sorry new Thunderbird Installation. I forgot it does that.
The new patch applies cleanly, except on nbd where it fails. It suceeds with -l to ignore white space, so perhaps your mail setup isn't 100% up to standard yet :-)
Signature · 1 line
Jens Axboe
Quoted 6 lines · Jens Axboe
Quoted 5 lines · Boaz Harrosh
Quoted 4 lines · Jens Axboe
If you look at most of the code, it's inside ifdef debug statements or comments most of them. So I don't think you can base any removal suggestion on that.
Quoted 9 lines
Quoted 4 lines
Quoted 3 lines
The patch itself looks fine though, if you send one that isn't mangled I'll apply it to the 2.6.23 branch.
Sorry new Thunderbird Installation. I forgot it does that.
The new patch applies cleanly, except on nbd where it fails. It suceeds with -l to ignore white space, so perhaps your mail setup isn't 100% up to standard yet :-)
Thanks, you are right again, it was set to wrap text at 85 chars and when so, it will eat spaces at end of lines. Setting wrap to 0 fixes it.
Quoted 11 lines · Boaz Harrosh
Quoted 8 lines · Jens Axboe
If you look at most of the code, it's inside ifdef debug statements or comments most of them. So I don't think you can base any removal suggestion on that.
The patch itself looks fine though, if you send one that isn't mangled I'll apply it to the 2.6.23 branch.
Sorry new Thunderbird Installation. I forgot it does that.
Quoted 8 lines
- I have unearthed very old bugs in stale drivers that still used
request->cmdas a READ|WRITE int
- This patch is maybe a proof that these drivers have not been used for a long time. Should they be removed completely?Drivers that currently do not work for sure:
drivers/acorn/block/fd1772.c
drivers/acorn/block/mfmhd.c
Afaik these are old arm26 driver, and that port is dead and should probably be removed from the tree entirely.
Quoted 6 lines
drivers/cdrom/aztcd.c
drivers/cdrom/cm206.c
drivers/cdrom/gscd.c
drivers/cdrom/mcdx.c
drivers/cdrom/optcd.c
drivers/cdrom/sjcd.c
These are old cdrom drivers that are broken in various ways and probably should be killed off aswell.
Quoted 31 lines · Christoph Hellwig
Quoted 11 lines · Boaz Harrosh
Quoted 8 lines · Jens Axboe
If you look at most of the code, it's inside ifdef debug statements or comments most of them. So I don't think you can base any removal suggestion on that.
The patch itself looks fine though, if you send one that isn't mangled I'll apply it to the 2.6.23 branch.
Sorry new Thunderbird Installation. I forgot it does that.
Quoted 8 lines
- I have unearthed very old bugs in stale drivers that still used
request->cmdas a READ|WRITE int
- This patch is maybe a proof that these drivers have not been used for a long time. Should they be removed completely?Drivers that currently do not work for sure:
drivers/acorn/block/fd1772.c
drivers/acorn/block/mfmhd.cAfaik these are old arm26 driver, and that port is dead and should probably be removed from the tree entirely.
Quoted 6 lines
drivers/cdrom/aztcd.c
drivers/cdrom/cm206.c
drivers/cdrom/gscd.c
drivers/cdrom/mcdx.c
drivers/cdrom/optcd.c
drivers/cdrom/sjcd.c
Quoted 2 lines
These are old cdrom drivers that are broken in various ways and probably should be killed off aswell.
I agree (with both sentiments), would anyone mind if I just killed them off? mitsumi support is being reworked, that can get reintroduced once the driver is in a stable state.
Signature · 1 line
Jens Axboe
Quoted 6 lines · Jens Axboe
Quoted 2 lines
These are old cdrom drivers that are broken in various ways and probably should be killed off aswell.
I agree (with both sentiments), would anyone mind if I just killed them off? mitsumi support is being reworked, that can get reintroduced once the driver is in a stable state.
Yeah - the new mitsumi doesn't share anything with the old one anyway.
Quoted 10 lines · Jens Axboe
Quoted 9 lines · Christoph Hellwig
Quoted 7 lines · Boaz Harrosh
drivers/cdrom/aztcd.c
drivers/cdrom/cm206.c
drivers/cdrom/gscd.c
drivers/cdrom/mcdx.c
drivers/cdrom/optcd.c
drivers/cdrom/sjcd.c
Quoted 5 lines
Quoted 2 lines
These are old cdrom drivers that are broken in various ways and probably should be killed off aswell.
I agree (with both sentiments), would anyone mind if I just killed them off?
I wouldn't. As far as I'm concerned everything in drivers/cdrom except viocd.c and cdrom.c itself can go, assuming I'll be allowed to bring back support for the legacy cdrom types I'd still like to have supported -- in the first place mitsumi (mcdx), panasonic (sbpcd) and sony (cdu31a) and perhaps at some point other types if/when I happen across the hardware.
The old drivers serve as a source of hardware information but at least mcdx was broken in so many ways that it only did so at the source level. When I wanted to check throughput with the old driver I actually had to go back as far as 2.0.34 to find a working driver (the old mcd.c, already removed since 2.6.10). 2.0.34 sources are available from kernel.org, and 2.6.22 sources even from my local machine...
Quoted 2 lines
mitsumi support is being reworked, that can get reintroduced once the driver is in a stable state.
... which, by the way, is still waiting on comment from anyone with a clue as to why it makes the machine go boom (easily repeatable when using CFQ, not or not easily when using AS):
http://lkml.org/lkml/2007/6/4/50
Rene.
Quoted 15 lines · Rene Herman
Quoted 13 lines · Jens Axboe
Quoted 11 lines · Christoph Hellwig
Quoted 7 lines · Boaz Harrosh
drivers/cdrom/aztcd.cdrivers/cdrom/cm206.cdrivers/cdrom/gscd.cdrivers/cdrom/mcdx.cdrivers/cdrom/optcd.cdrivers/cdrom/sjcd.cThese are old cdrom drivers that are broken in various ways and probably should be killed off aswell.
Quoted 8 lines
Quoted 2 lines
I agree (with both sentiments), would anyone mind if I just killed them off?
I wouldn't. As far as I'm concerned everything in
drivers/cdromexceptviocd.candcdrom.citself can go, assuming I'll be allowed to bring back support for the legacy cdrom types I'd still like to have supported -- in the first place mitsumi (mcdx), panasonic (sbpcd) and sony (cdu31a) and perhaps at some point other types if/when I happen across the hardware.
Sure, a working clean driver would always be allowed in. I'll remove the legacy drivers in 2.6.23.
Quoted 6 lines
The old drivers serve as a source of hardware information but at least mcdx was broken in so many ways that it only did so at the source level. When I wanted to check throughput with the old driver I actually had to go back as far as 2.0.34 to find a working driver (the old
mcd.c, already removed since 2.6.10). 2.0.34 sources are available from kernel.org, and 2.6.22 sources even from my local machine...
Heh, that's pretty scary!
Quoted 8 lines
Quoted 2 lines
mitsumi support is being reworked, that can get reintroduced once the driver is in a stable state.
... which, by the way, is still waiting on comment from anyone with a clue as to why it makes the machine go boom (easily repeatable when using CFQ, not or not easily when using AS):
Yeah I know, I will get around to it eventually.
Signature · 1 line
Jens Axboe