Am 31.10.2013 21:56, schrieb Johan Hovold:
> On Thu, Oct 31, 2013 at 09:26:06PM +0100, Johan Hovold wrote:
>> On Thu, Oct 31, 2013 at 7:45 PM, Frank Schäfer wrote:
>>> Am 31.10.2013 13:30, schrieb Mika Westerberg:
>>>> On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote:
>>>>> 2) comment out the following line at the end of
>>>>> pl2303_baudrate_encode_divisor_HXD():
>>>>>
>>>>> baud = 12000000 * 32 / ((1 << buf[1]) * buf[0]);
>>>> This seems to fix the problem :)
>>>>
>>>> Once the line is commented out, the serial console works fine with the
>>>> speeds I've been testing (115200, 230400 and 460800).
>>> Urgh... so it seems getty gets confused if the actually set baud rate is
>>> reported back.
>>> The kernel still reports the standard baud rate (e.g. B230400), it only
>>> sets the exact value in the c_ispeed and c_ospeed fields of the termios
>>> struct.
>>> So even if getty doesn't support non-standard baud rates, everything
>>> should be fine.
>>> I'll have to take a closer look at this issue later.
> I think I know what's going on. The pl2303 is known to loose bytes when
> changing the termios settings (see commit bf5e5834b ("pl2303: Fix mode
> switching regression")).
>
> Your commit 57ce61aad ("usb: pl2303: fix+improve the divisor based baud
> rate encoding method") introduced a regression when it started reporting
> back the baudrates determined by the divisor algorithm.
>
> Since that commit, tty_termios_hw_change(&tty->termios, old_termios)
> will always return true -- even when userspace isn't requesting a
> different baudrate.
Hmm... so there is a bug in tty_termios_hw_change() ?>>> Ok, so now let's see if the fixed/improved divisor based method also >>> works for the HXD chip if we don't report the actually set baud rate. >>> Try commenting out the line >>> >>> baud = 12000000 * 32 / ((1 << A) * B); >>> >>> at the end of pl2303_baudrate_encode_divisor() of a clean 3.12-rc kernel. >>> It's unlikely that this makes baud rates < 115200 working, but testing >>> both cases doesn't harm. ;) > I can trigger the problem here with my HXD/EA/RA/SA-device as well, and > I've verified that not returning the calculated baudrate makes this > particular issue *seem* to go away. > > This obviously has to be fixed or reverted quickly. Indeed. > 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. The remaining question is, does the HXD work with the improved divisor method or do we have to reintroduce the old method ? Regards, Frank > Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
