Am 01.11.2013 11:22, schrieb Johan Hovold: >>> Greg, what do you say about this? Is reverting for 3.12 the correct way >>> to deal with this, and make sure these fairly invasive patches get some >>> more testing before being reapplied? >>> >>> Reverting would mean reverting a whole bunch of commits though, as they >>> appear to depend quite heavily on each other: >>> >>> 7d26a78 USB: pl2303: distinguish between original and cloned HX chips >>> 034d152 pl2303: improve the chip type detection/distinction >>> a77a8c2 pl2303: improve the chip type information output on startup >>> 73b583a pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup() >>> c23bda3 usb: pl2303: add two comments concerning the supported baud rates with HX chips >>> 61fa8d6 usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips >>> b5c16c6 usb: pl2303: increase the allowed baud rate range for the divisor based encoding method >>> e917ba0 usb: pl2303: move the two baud rate encoding methods to separate functions >>> b9208c7 usb: pl2303: remove 500000 baud from the list of standard baud rates >>> 75417d9 usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method >>> 57ce61a usb: pl2303: fix+improve the divsor based baud rate encoding method >>> b8bdad6 USB: pl2303: restrict the divisor based baud rate encoding method to the "HX" chip type >> No need to revert all these patches, removing the calculation of the >> resulting baud rateat the end of fcn pl2303_baudrate_encode_divisor() >> should fix this issue. > It could, if the problem I identified above is the only issue here. Well, unless you don't find another regression, I see no reason to revert. ;) > However, we have a clear regression and 3.12 is coming out very, very > soon. Indeed, but fortunately we are also close to a solution/decision. > >> The remaining question is, does the HXD work with the improved divisor >> method or do we have to reintroduce the old method ? > This is exactly the kind of issues we can discuss and investigate after > reverting the changes. Let's not break any systems meanwhile. Well, Mika and you have have such a device, so you can test it. Alternatively, we can apply the patch I've sent that restores the old behavior (of course without the calculation of the resulting baud rate). > 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. :) Regards, Frank > > 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
