1. 23 4月, 2018 3 次提交
    • D
      earlycon: Use a pointer table to fix __earlycon_table stride · dd709e72
      Daniel Kurtz 提交于
      Commit 99492c39 ("earlycon: Fix __earlycon_table stride") tried to fix
      __earlycon_table stride by forcing the earlycon_id struct alignment to 32
      and asking the linker to 32-byte align the __earlycon_table symbol.  This
      fix was based on commit 07fca0e5 ("tracing: Properly align linker
      defined symbols") which tried a similar fix for the tracing subsystem.
      
      However, this fix doesn't quite work because there is no guarantee that
      gcc will place structures packed into an array format.  In fact, gcc 4.9
      chooses to 64-byte align these structs by inserting additional padding
      between the entries because it has no clue that they are supposed to be in
      an array.  If we are unlucky, the linker will assign symbol
      "__earlycon_table" to a 32-byte aligned address which does not correspond
      to the 64-byte aligned contents of section "__earlycon_table".
      
      To address this same problem, the fix to the tracing system was
      subsequently re-implemented using a more robust table of pointers approach
      by commits:
       3d56e331 ("tracing: Replace syscall_meta_data struct array with pointer array")
       65498646 ("tracepoints: Fix section alignment using pointer array")
       e4a9ea5e ("tracing: Replace trace_event struct array with pointer array")
      
      Let's use this same "array of pointers to structs" approach for
      EARLYCON_TABLE.
      
      Fixes: 99492c39 ("earlycon: Fix __earlycon_table stride")
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Suggested-by: NAaron Durbin <adurbin@chromium.org>
      Reviewed-by: NRob Herring <robh@kernel.org>
      Tested-by: NGuenter Roeck <groeck@chromium.org>
      Reviewed-by: NGuenter Roeck <groeck@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd709e72
    • S
      serial: imx: fix cached UCR2 read on software reset · 0aa821d8
      Stefan Agner 提交于
      To reset the UART the SRST needs be cleared (low active). According
      to the documentation the bit will remain active for 4 module clocks
      until it is cleared (set to 1).
      
      Hence the real register need to be read in case the cached register
      indicates that the SRST bit is zero.
      
      This bug lead to wrong baudrate because the baud rate register got
      restored before reset completed in imx_flush_buffer.
      
      Fixes: 3a0ab62f ("serial: imx: implement shadow registers for UCRx and UFCR")
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
      Reviewed-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0aa821d8
    • S
      serial: imx: warn user when using unsupported configuration · 6d215f83
      Stefan Agner 提交于
      When using half-duplex mode (which disables receiver during txing)
      the RTS signal cannot be driven low during transmission when using
      i.MX UART RTS/CTS control. This seems to be a limitation of the
      i.MX UART IP: The RTS (CTS_B) signal is controlled by the receiver.
      When the receiver is disabled, the signal stays in UART logic idle
      state which is high...
      
      If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
      transmission. Since this is the default state of the RTS (CTS_B)
      signal when the receiver is off, half-duplex mode in this
      configuration works fine.
      
      However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
      cannot be generated when the receiver is turned off.
      
      Print an error if the user selects this unsupported configuration
      (both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
      configure the closest working configuration (set the
      SER_RS485_RX_DURING_TX flag).
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d215f83
  2. 22 4月, 2018 3 次提交
    • M
      serial: mvebu-uart: Fix local flags handling on termios update · 46c6975a
      Marc Zyngier 提交于
      Commit 68a0db1d reworked the baud rate selection, but also added
      a (not so) subtle change in the way the local flags (c_lflag in the
      termios structure) are handled, forcing the new flags to always be the
      same as the old ones.
      
      The reason for that particular change is both obscure and undocumented.
      It also completely breaks userspace. Something as trivial as getty is
      unusable:
      
      <example>
      	Debian GNU/Linux 9 sy-borg ttyMV0
      
      	sy-borg login: root
      	root
      	[timeout]
      
      	Debian GNU/Linux 9 sy-borg ttyMV0
      </example>
      
      which is quite obvious in retrospect: getty cannot get in control of
      the echo mode, is stuck in canonical mode, and times out without ever
      seeing anything valid. It also begs the question of how this change was
      ever tested.
      
      The fix is pretty obvious: stop messing with c_lflag, and the world
      will be a happier place.
      
      Cc: stable@vger.kernel.org # 4.15+
      Fixes: 68a0db1d ("serial: mvebu-uart: add function to change baudrate")
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46c6975a
    • T
      tty: n_gsm: Fix DLCI handling for ADM mode if debug & 2 is not set · b2d89ad9
      Tony Lindgren 提交于
      At least on droid 4 with control channel in ADM mode, there is no response
      to Modem Status Command (MSC). Currently gsmtty_modem_update() expects to
      have data in dlci->modem_rx unless debug & 2 is set. This means that on
      droid 4, things only work if debug & 2 is set.
      
      Let's fix the issue by ignoring empty dlci->modem_rx for ADM mode. In
      the AMD mode, CMD_MSC will never respond and gsm_process_modem() won't
      get called to set dlci->modem_rx.
      
      And according to ts_127010v140000p.pdf, MSC is only relevant if basic
      option is chosen, so let's test for that too.
      
      Fixes: ea3d8465 ("tty: n_gsm: Allow ADM response in addition to UA for control dlci")
      Cc: linux-serial@vger.kernel.org
      Cc: Alan Cox <alan@llwyncelyn.cymru>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Marcel Partap <mpartap@gmx.net>
      Cc: Merlijn Wajer <merlijn@wizzup.org>
      Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
      Cc: Michael Scott <michael.scott@linaro.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Russ Gorby <russ.gorby@intel.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Sebastian Reichel <sre@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2d89ad9
    • T
      tty: n_gsm: Fix long delays with control frame timeouts in ADM mode · e9ec2254
      Tony Lindgren 提交于
      Commit ea3d8465 ("tty: n_gsm: Allow ADM response in addition to UA for
      control dlci") added support for DLCI to stay in Asynchronous Disconnected
      Mode (ADM). But we still get long delays waiting for commands to other
      DLCI to complete:
      
      --> 5) C: SABM(P)
      Q>  0) C: UIH(F)
      Q>  0) C: UIH(F)
      Q>  0) C: UIH(F)
      ...
      
      This happens because gsm_control_send() sets cretries timer to T2 that is
      by default set to 34. This will cause resend for T2 times for the control
      frame. In ADM mode, we will never get a response so the control frame, so
      retries are just delaying all the commands.
      
      Let's fix the issue by setting DLCI_MODE_ADM flag after detecting the ADM
      mode for the control DLCI. Then we can use that in gsm_control_send() to
      set retries to 1. This means the control frame will be sent once allowing
      the other end at an opportunity to switch from ADM to ABM mode.
      
      Note that retries will be decremented in gsm_control_retransmit() so
      we don't want to set it to 0 here.
      
      Fixes: ea3d8465 ("tty: n_gsm: Allow ADM response in addition to UA for control dlci")
      Cc: linux-serial@vger.kernel.org
      Cc: Alan Cox <alan@llwyncelyn.cymru>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Marcel Partap <mpartap@gmx.net>
      Cc: Merlijn Wajer <merlijn@wizzup.org>
      Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
      Cc: Michael Scott <michael.scott@linaro.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Russ Gorby <russ.gorby@intel.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Sebastian Reichel <sre@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9ec2254
  3. 13 4月, 2018 8 次提交
  4. 12 4月, 2018 26 次提交
新手
引导
客服 返回
顶部