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. > Please also consider that the patch I've sent 5 minutes ago should also > needs to be applied to stable. > We have the same issue there and it's not restricted to the divisor > based baud rate encoding method. > The same can happen with the direct encoding method... I'm aware of that, but I'm not going to accept a quick hack which might or might not fix the problem (you have already submitted three "experimental" fixes), and which could cause other problems as well. It's too late in the cycle for this. > So IMHO, going a step forward and fixing this bug is the better solution. Let's revert, and then fix the general baudrate-switching problem during 3.13-rc. After some abstractions are in place and we have a chance to discuss which baudrate-setting method should be used when, we can easily add back the refined device detection and improved divisor algorithm you implemented. Thanks, Johan -- 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
