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 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
