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. > 2) remove the calculation and reproting of the actually set baud rate > with a follow-up patch You call this is a partial revert in a follow up mail, and this could possibly fix the problem we're seeing. However, I think reverting the whole series and fixing the general problem is the way to go at this point in time. This way the other changes will get some more review and testing too, which I think is needed. I'd be happy to help with the HX-device I have and hopefully we can gather enough testers to cover the other types as well. > 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. Yes, so this will have to wait a bit. > >> 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. Your first RFC/RFT was a hack, and apparently didn't even fix the problem according to Mika. I did not look much closer at the other two you marked "experimental". > 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. I just wanted to make clear that no fix for the general problem you would come up with today would be enough to to change my mind given that 3.12 likely is to be released on Sunday and that the reverts need to go to Linus today. [ And any fix for the general problem obviously needs to be thought through and properly tested first. ] Sorry, 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
