1. 26 11月, 2014 3 次提交
  2. 07 11月, 2014 4 次提交
  3. 06 11月, 2014 1 次提交
  4. 24 9月, 2014 1 次提交
  5. 10 7月, 2014 1 次提交
  6. 20 6月, 2014 1 次提交
    • P
      serial: Fix IGNBRK handling · ef8b9ddc
      Peter Hurley 提交于
      If IGNBRK is set without either BRKINT or PARMRK set, some uart
      drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the
      line discipline, when it should send either nothing or the TTYBREAK flag
      set. This happens because the read_status_mask masks out the BI
      condition, which uart_insert_char() then interprets as a normal 0x00 byte.
      
      SUS v3 is clear regarding the meaning of IGNBRK; Section 11.2.2, General
      Terminal Interface - Input Modes, states:
        "If IGNBRK is set, a break condition detected on input shall be ignored;
         that is, not put on the input queue and therefore not read by any
         process."
      
      Fix read_status_mask to include the BI bit if IGNBRK is set; the
      lsr status retains the BI bit if a BREAK is recv'd, which is
      subsequently ignored in uart_insert_char() when masked with the
      ignore_status_mask.
      
      Affected drivers:
      8250 - all
      serial_txx9
      mfd
      amba-pl010
      amba-pl011
      atmel_serial
      bfin_uart
      dz
      ip22zilog
      max310x
      mxs-auart
      netx-serial
      pnx8xxx_uart
      pxa
      sb1250-duart
      sccnxp
      serial_ks8695
      sirfsoc_uart
      st-asc
      vr41xx_siu
      zs
      sunzilog
      fsl_lpuart
      sunsab
      ucc_uart
      bcm63xx_uart
      sunsu
      efm32-uart
      pmac_zilog
      mpsc
      msm_serial
      m32r_sio
      
      Unaffected drivers:
      omap-serial
      rp2
      sa1100
      imx
      icom
      
      Annotated for fixes:
      altera_uart
      mcf
      
      Drivers without break detection:
      21285
      xilinx-uartps
      altera_jtaguart
      apbuart
      arc-uart
      clps711x
      max3100
      uartlite
      msm_serial_hs
      nwpserial
      lantiq
      vt8500_serial
      
      Unknown:
      samsung
      mpc52xx_uart
      bfin_sport_uart
      cpm_uart/core
      
      Fixes: Bugzilla #71651, '8250_core.c incorrectly handles IGNBRK flag'
      Reported-by: NIvan <athlon_@mail.ru>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef8b9ddc
  7. 18 4月, 2014 1 次提交
  8. 09 12月, 2013 1 次提交
  9. 06 10月, 2013 1 次提交
  10. 05 8月, 2013 2 次提交
  11. 27 7月, 2013 2 次提交
  12. 25 7月, 2013 1 次提交
  13. 23 4月, 2013 2 次提交
  14. 04 4月, 2013 1 次提交
  15. 16 1月, 2013 5 次提交
  16. 27 11月, 2012 2 次提交
  17. 22 11月, 2012 3 次提交
  18. 16 11月, 2012 2 次提交
  19. 12 9月, 2012 1 次提交
  20. 07 9月, 2012 2 次提交
  21. 06 9月, 2012 1 次提交
  22. 17 8月, 2012 1 次提交
    • H
      serial: mxs-auart: fix the wrong RTS hardware flow control · 00592021
      Huang Shijie 提交于
      Without checking if the auart supports the hardware flow control or not,
      the old mxs_auart_set_mctrl() asserted the RTS pin blindly.
      
      This will causes the auart receives wrong data in the following case:
         The far-end has already started the write operation, and wait for
      the auart asserts the RTS pin. Then the auart starts the read operation,
      but mxs_auart_set_mctrl() may be called before we set the RTSCTS in the
      mxs_auart_settermios(). So the RTS pin is asserted in a wrong situation,
      and we get the wrong data in the end.
      
      This bug has been catched when I connect the mx23(DTE) to the mx53(DCE).
      
      This patch also replaces the AUART_CTRL2_RTS with AUART_CTRL2_RTSEN.
      We should use the real the hardware flow control, not the software-controled
      hardware flow control.
      Signed-off-by: NHuang Shijie <b32955@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00592021
  23. 03 7月, 2012 1 次提交