On 01/23/2015 03:12 PM, Christoph Hellwig wrote: > On Fri, Jan 23, 2015 at 01:05:30PM +0100, Bart Van Assche wrote: >> There is some confusion in the SCSI core and in SCSI LLDs around the >> meaning of sc_data_direction and whether or not this member can have the >> value DMA_BIDIRECTIONAL. Clear up this confusion. The patches in this >> series are: > > I wonder if we should change the code to set DMA_BIDIRECTIONAL for > bidi commands. That seems a lot more logical than the current > version. > You cannot do this. Because a Bidi Command is actually two commands one for the WRITE side (DMA_TO_DEVICE) which is this one, and another command for the READ side (DMA_FROM_DEVICE). The DMA_XXX_ enum must not to be confused with the t10-scsi Bidi commands. In DMA world the enum means: What are the allowed access on the memory buffer, is Device allowed to read-from-memory-only or write-to-memory-only or both simultaneously "on the same buffer". It is a flag to the IO-mmu on the direction of its mappings. A t10-scsi bidi command is "two buffers". The command caries two distinct buffers one is only-written-to 2nd only-read-from. But these are two distinct buffers each his proper direction. If you ask me you need to remove sc_data_direction all together and just go directly to the READ/WRITE flag at request level. SCSI has no business duplicating the same information in another member another way. In any way t10-scsi has no use in the entire of its STD of the DMA_BIDIRECTIONAL sense. ie. same buffer, two directional access. So DMA_BIDIRECTIONAL is just dead code for sc_data_direction. It could be imagined but t10-scsi does not have a use for it. Again Not to be confused with one-command two buffers, which is exactly the opposite. > Also I don't think all the debug checks for bidi commands that you > change should stay at all - driver need to set the QUEUE_FLAG_BIDI to > ever see a bidi command. > Exactly just remove the all checks. > It would also nice to add a host template flag for bidi support instead > of having to poke into the block layer request_queue while we're at it. Cheers Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html