On Wed, 23 Mar 2011, Luben Tuikov wrote: > --- On Wed, 3/23/11, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > Reverting the original patch for now is fine with me. > > You mean my patch? This commit: 24d720b726c1a85f1962831ac30ad4d2ef8276b1. Yes, that is what I mean by "the original patch". > > As for the next > > merge window, let me submit a more bullet-proof version of > > the second > > patch. > > How can you submit a "more bullet-proof" version of the second patch without the "first", which would be my topic patch I assume? This > one: 24d720b726c1a85f1962831ac30ad4d2ef8276b1. > > Does this mean you'll resubmit my topic patch as your own and roll your minor patch with it? No. It means I'll submit a new version of the $SUBJECT patch (which in fact I have already done), and leave it up to James to decide the best way to merge it with your original patch. 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). > > 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. Alan Stern -- 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
