On Tue, 30 Dec 2014, James Bottomley wrote: > > All right. How does this patch look? > > OK, I suppose. The transfer limits are a little on the low side, but > for usb-storage (i.e. non-UAS) performance devices, they should be OK. If you're referring to the 32-KB and 64-KB limits, we know from experience that some devices really do need them. If you're referring to the 32-MB limit... Well, that's what this whole thread is about, right? That limit could be restricted to apply only when a device is not connected over a SuperSpeed USB-3 link. But knowing the low quality of commodity USB hardware, I suspect it wouldn't work well. > For TYPE_TAPE, you still have no guarantee that the bridge won't screw > up ... and if the argument is that tapes are always connected to > sensible bridges, why aren't SATA devices? True, we have no guarantee. But tape drives do have special requirements because of the way they write blocks and gaps; this code was added by someone with a tape drive who did need the large limit. I guess there are a lot more bridges in the low-budget consumer world targeted to disk drives than to tape drives. That could explain a lot. > There's also a spelling mistake below. I'll fix it in the final patch submission. Thanks. Alan Stern PS: What's the current situation of my "SCSI: fix regression in scsi_send_eh_cmnd()" patch: http://marc.info/?l=linux-scsi&m=141658469207765&w=2 submitted on November 21? Since it was a bug-fix, I rather expected it to get merged before 3.18 was released. Since it didn't, I certainly hope it will get in before 3.19. -- 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
