On Fri, Nov 01, 2013 at 03:25:23PM +0100, Johan Hovold wrote: > On Fri, Nov 01, 2013 at 02:47:27PM +0100, Frank Schäfer wrote: > > Am 01.11.2013 14:29, schrieb Johan Hovold: > > > On Fri, Nov 01, 2013 at 01:03:24PM +0100, Frank Schäfer wrote: > > >> Am 01.11.2013 12:15, schrieb Johan Hovold: > > >>> On Fri, Nov 01, 2013 at 11:44:33AM +0100, Frank Schäfer wrote: > > >>>> Am 01.11.2013 11:22, schrieb Johan Hovold: > > >>>>> I think that adding support for odd baud rates (and the improved device > > >>>>> detection) can be implemented in a cleaner way and want to have a chance > > >>>>> to discuss that with you. > > >>>> Ok, between the lines I can read that you just don't trust this patch > > >>>> series. ;) > > >>>> I'm looking forward to your suggestions for a cleaner way to implement > > >>>> this. :) > > >>> You have done a great job here in reverse-engineering the chip and > > >>> documenting the quirks. It's not an easy job at all with all the > > >>> different chips out there, including pirate ones. > > >>> > > >>> I just think we should take the safe way here and hold off the changes > > >>> another cycle. Get some more people to do more testing (which chip types > > >>> do we have among us at the moment?). This would also allow us to come up > > >>> with a series which abstracts the differences in a cleaner way rather > > >>> than spreading this information all over the driver. I'm aware that it > > >>> has grown to that state incrementally, but at this point I think it's > > >>> clear that some abstraction is needed. > > >> You're the maintainer, the decission is of course up to you. > > >> I have generally no problem with reverting patches. If something isn't > > >> ready or plain crap, it should of course be reverted. > > >> But AFAICS, the problem here isn't the patch series itself. It's just > > >> that this series unveils another long standing bug. > > > As I said in my last mail, the important thing is to fix the regression > > > so we don't break any currently working systems. > > > > Johan, I totally agree with you. > > But we have _two_ possibilities to fix this regression. > > 1) revert the whole buncg of patches > > Yes, and this is the way we do it this time. > > I'm afraid that the patches did not get enough review (and I blame > myself for not finding the time to do it sooner) and could still be > improved. No, it's my fault as well, don't blame yourself. I'll go revert all of these for now and send it to Linus for 3.12-final, and then we can start "fresh" in resolving this issue. thanks, greg k-h -- 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
