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