On Thu, 2010-02-18 at 11:24 -0500, Alan Stern wrote: > On Thu, 18 Feb 2010, James Bottomley wrote: > > > On Thu, 2010-02-18 at 14:16 +0530, Ramya Desai wrote: > > > On Wed, Feb 17, 2010 at 8:32 PM, James Bottomley > > > <James.Bottomley@xxxxxxx> wrote: > > > > > > > I have no idea what the MS driver is, so it's impossible to answer > > > > specifically. > > > > > > MS means mass storage driver only. > > > > OK, still don't know what that is ... but Randy decoded this for me; he > > said you mean a driver under drivers/usb/storage? > > Yes, Ramya is talking about usb-storage. > > > 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). James -- 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
