Am 01.11.2013 11:06, schrieb Frank Schäfer:
> 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() ?
Ahh... no... I see what's going on.
I assume we have to compare the resulting encoded baud rates to check if
the settings changed.
But that's something for the next kernel...
Frank
>
>>>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
