Am 01.11.2013 14:47, schrieb Frank Schäfer: > 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 > 2) remove the calculation and reproting of the actually set baud rate > with a follow-up patch Just to be clear: 2) isn't yet another change, it's in fact a partial revert. Frank > If we can find out how to fix the workaround for the hardware bug, this > would of course replace 2) and be the best solution, but we are running > out of time. > >>> 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. > The two possibilities are no quick hacks and they are known to work. > > Concerning the experimental patches: > Yes they are _experimental_ and not yet ready, That's why I do _not_ > want to see them applied. I necer said anything else. > What we're trying to do is to fix the workaround for the hardware bug, > which we have to do in any case. > > Regards, > Frank > >> 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
