On Thu, 18 Feb 2010, James Bottomley wrote: > > > In that case, it looks like the helpers in protocol.c do use chaining > > > correctly (as long as the driver isn't doing direct dma), but there's a > > > clamp on the sg table size in scsiglue.c: > > > > > > .sg_tablesize = SG_ALL > > > > > > That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable > > > chaining. > > > > Is there any reason not to make this change in the standard kernel? I > > believe that the subdrivers which don't use the helpers in protocol.c > > also handle chaining correctly. > > As long as you're sure that's the case, it should be perfectly fine to > do this. On some platforms you'll see the transfer sg list length jump > from 128 to 2048 ... so any drivers not using the protocol.c helpers not > only have to be using chaining ... they also have to have enough > hardware slots (or manually tune sg_tablesize themselves) ... this was > the reason why we've been raising the limit individually in SCSI drivers > (a lot can't handle the large sg list table sizes). It shouldn't be much of a problem. The slots aren't stored in the hardware anyway; they are data structures set up in RAM and accessed via a coherent DMA mapping. The only limitations are available memory and latency. (In fact the memory issue is not always trivial. With one type of USB controller, the memory required for the transfer descriptors is half as large as the data buffers themselves! Luckily these controllers don't support high-speed operation, so they won't be used very often with large storage devices.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
