On Mon, 2007-09-10 at 10:03 -0700, Matthew Dharm wrote: > On Mon, Sep 10, 2007 at 05:11:23PM +0300, Boaz Harrosh wrote: > > > > In motivation to abstract scsi_cmnd members and insulate > > drivers/transports from scsi_cmnd internals. The last > > place left was the REQUEST_SENSE sequence when done > > synchronous, by drivers. > > This probably isn't serious, but I noticed one thing (beyond what Alan's > analysis noted)... > > I've always assumed that the scatterlist structs passed to an HCD were, > themselves, allocated from DMA-able memory. That is, not just the transfer > buffers themselves, but the struct scatterlist also. They are, but this is an artifact of the command allocation. Commands (as in the 6, 10 12 or 16 bytes of command sequence) are designed to be DMAable, meaning that everything that makes up a struct scsi_cmnd is automatically DMAable. However, the design is for the dma_mapped scatterlist to be converted to a form the underlying HBA can use. I don't currently know of any HBA whose descriptor format matches those of struct scatterlist, so I don't think there'll be any impact to putting the scatterlist in memory that might not be DMAable by the HBA. > In this implementation, the struct scatterlist used for the single-element > transfer of the request sense buffer is part of the > struct scsi_eh_save_cmnd_info, which is allocated on the stack (for at > least usb-storage). And, stack isn't DMA-able on all arches. > > It is not a problem for usb-storage, since the struct scatterlists are > processed in code into a series of URBs, so nobody actually does DMA the > scatterlist structures. However, I don't know enough about the other HCDs > to be certain about them. James - 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
