sym2: remove unkown data direction handling
RFC PATCH 1/1 sym2: remove unkown data direction handling
since 2.3 the LLDD gets the data direction passed down, so we don't need to kludge around an unknown data direction anymore. I've added a BUG when we get an unkown data direction neverless, and it seems to survive so far under low load.
drivers/scsi/sym53c8xx_2/sym_fw.c +0 -6
@@ -70,9 +70,6 @@ };static struct sym_fwb_ofs sym_fw1b_ofs = { SYM_GEN_FW_B(struct SYM_FWB_SCR) -#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN - SYM_GEN_B(struct SYM_FWB_SCR, data_io) -#endif };static struct sym_fwz_ofs sym_fw1z_ofs = { SYM_GEN_FW_Z(struct SYM_FWZ_SCR)
@@ -98,9 +95,6 @@ };static struct sym_fwb_ofs sym_fw2b_ofs = { SYM_GEN_FW_B(struct SYM_FWB_SCR) -#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN - SYM_GEN_B(struct SYM_FWB_SCR, data_io) -#endif SYM_GEN_B(struct SYM_FWB_SCR, start64) SYM_GEN_B(struct SYM_FWB_SCR, pm_handle) };
===== drivers/scsi/sym53c8xx_2/sym_fw.h 1.3 vs edited =====
drivers/scsi/sym53c8xx_2/sym_fw.h +0 -6
@@ -92,9 +92,6 @@ };struct sym_fwb_ofs {SYM_GEN_FW_B (u_short) -#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN - SYM_GEN_B(u_short, data_io) -#endif SYM_GEN_B(u_short, start64) SYM_GEN_B(u_short, pm_handle) };
@@ -111,9 +108,6 @@ };struct sym_fwb_ba {SYM_GEN_FW_B (u32) -#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN - SYM_GEN_B(u32, data_io) -#endif SYM_GEN_B(u32 ,start64 ); SYM_GEN_B(u32, pm_handle); };
===== drivers/scsi/sym53c8xx_2/sym_fw1.h 1.6 vs edited =====
drivers/scsi/sym53c8xx_2/sym_fw1.h +0 -48
60 lines not on this page · raw message
===== drivers/scsi/sym53c8xx_2/sym_fw2.h 1.6 vs edited =====
drivers/scsi/sym53c8xx_2/sym_fw2.h +0 -52
64 lines not on this page · raw message
===== drivers/scsi/sym53c8xx_2/sym_glue.h 1.23 vs edited =====
drivers/scsi/sym53c8xx_2/sym_glue.h +0 -1
@@ -74,7 +74,6 @@*/ #define SYM_CONF_TIMER_INTERVAL ((HZ+1)/2) -#define SYM_OPT_HANDLE_DIR_UNKNOWN #define SYM_OPT_HANDLE_DEVICE_QUEUEING #define SYM_OPT_LIMIT_COMMAND_REORDERING #define SYM_OPT_ANNOUNCE_TRANSFER_RATE
===== drivers/scsi/sym53c8xx_2/sym_hipd.h 1.8 vs edited =====
drivers/scsi/sym53c8xx_2/sym_hipd.h +4 -41
100 lines not on this page · raw message
Quoted 4 lines · Christoph Hellwig
since 2.3 the LLDD gets the data direction passed down, so we don't need to kludge around an unknown data direction anymore. I've added a BUG when we get an unkown data direction neverless, and it seems to survive so far under low load.
I thought we could get an unknown data direction from certain ioctls?
Signature · 6 lines
"Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain
Quoted 7 lines · Matthew Wilcox
Quoted 4 lines · Christoph Hellwig
since 2.3 the LLDD gets the data direction passed down, so we don't need to kludge around an unknown data direction anymore. I've added a BUG when we get an unkown data direction neverless, and it seems to survive so far under low load.
I thought we could get an unknown data direction from certain ioctls?
Not anymore. We could get the wrong direction from some older ioctls, when not used as document but not an unkown one.
Quoted 1 line
Quoted 1 line
I thought we could get an unknown data direction from certain
ioctls?
Quoted 3 lines
Not anymore. We could get the wrong direction from some older ioctls, when not used as document but not an unkown one.
Isn't it still possible for a userspace program to specify SG_DXFER_UNKNOWN when sending a command via /dev/sg* (not that it's a good idea, but...)
http://gear.torque.net/sg/p/sg_v3_ho.html#AEN166
If you want to BUG() on an unknown data direction, then sg should return an error to userspace when it sees SG_DXFER_UNKNOWN to avoid the BUG().
Anthony J. Battersby
Cybernetics