rq_data_dir() returns either READ or WRITE (0 == READ, 1 == WRITE), not a boolean value. Now, admittedly the "!= 0" doesn't really change the value (0 stays as zero, 1 stays as one), but it's not only redundant, it confuses gcc, and causes gcc to warn about the construct switch (rq_data_dir(req)) { case READ: ... case WRITE: ... that we have in a few drivers. Now, the gcc warning is silly and stupid (it seems to warn not about the switch value having a different type from the case statements, but about _any_ boolean switch value), but in this case the code itself is silly and stupid too, so let's just change it, and get rid of warnings like this: drivers/block/hd.c: In function ‘hd_request’: drivers/block/hd.c:630:11: warning: switch condition has boolean value [-Wswitch-bool] switch (rq_data_dir(req)) { The odd '!= 0' came in when "cmd_flags" got turned into a "u64" in commit 5953316dbf90 ("block: make rq->cmd_flags be 64-bit") and is presumably because the old code (that just did a logical 'and' with 1) would then end up making the type of rq_data_dir() be u64 too. But if we want to retain the old regular integer type, let's just cast the result to 'int' rather than use that rather odd '!= 0'.
Unified · Split
| @@ -584,7 +584,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q) · 583 unmodified lines | ||
| 584 | 584 | |
| 585 | 585 | #define list_entry_rq(ptr) list_entry((ptr), struct request, queuelist) |
| 586 | 586 | |
| 587 | −#define rq_data_dir(rq) (((rq)->cmd_flags & 1) != 0) | |
| 587 | +#define rq_data_dir(rq) ((int)((rq)->cmd_flags & 1)) | |
| 588 | 588 | |
| 589 | 589 | /* |
| 590 | 590 | * Driver can handle struct request, if it either has an old style |