--- On Wed, 3/23/11, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > No. It means I'll submit a new version of the > $SUBJECT patch (which in > fact I have already done), I just saw it and acked it. > and leave it up to James to > decide the best > way to merge it with your original patch. Yes, I'm curious to see what Bottomley does too, now that he's (apparently?) decided to revert my topic patch, on top of which yours applies. > Even though the merge window is now nearly over, my revised > patch could > still be sent on to Linus as a bug fix for 2.6.39-rc2 (and > also queued > for 2.6.38.1 or .2, of course). Yes, that'd be the smart thing to do. > > > It's possible that some wierd USB device will > report that > > > more than 192 > > > bytes of mode-sense data is available and then > fail when > > > the host asks > > > for the reported amount. You'd think no device > could > > > be that stupid, > > > > If by "fail" you mean "crash", then yes, that's bad. > However, the device may return less data. The while loop of > my patch, 24d720b726c1a85f1962831ac30ad4d2ef8276b1, will > correctly parse the returned > > less data. > > True; my patches catch that case. They prevent a > second MODE SENSE > command from being sent if it would ask for less data than > the first > command has already asked for. By "that" case you mean asking for less data than already asked for. You don't mean "parsing the MOSE SENSE data for any len correctly". Indeed, there is no point in asking for _less_ data than already asked for, as the loop I included in my topic patch, 24d720b726c1a85f1962831ac30ad4d2ef8276b1, will parse that data correctly. Luben -- 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
