1. 23 4月, 2018 1 次提交
    • 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
  2. 16 3月, 2018 1 次提交
  3. 07 2月, 2018 1 次提交
  4. 09 1月, 2018 1 次提交
  5. 28 11月, 2017 1 次提交
    • L
      serial: Make retrieval of rs485 properties platform-agnostic · 743f93f8
      Lukas Wunner 提交于
      Commit ef838a81 ("serial: Add common rs485 device tree parsing
      function") consolidated retrieval of rs485 OF properties in a common
      helper function but did not #ifdef it to CONFIG_OF.  The function is
      therefore included on ACPI platforms as well even though it's not used.
      
      On the other hand ACPI platforms with rs485 do exist (e.g. Siemens
      IOT2040) and they may leverage _DSD to store rs485 properties.  Likewise,
      UART platform devices instantiated from an MFD should be able to specify
      rs485 properties.  In fact, the tty subsystem maintainer had asked for
      a "generic" function during review of commit ef838a81:
      https://marc.info/?l=linux-serial&m=150143441725194&w=4
      
      Thus, instead of constraining the helper to OF platforms, make it
      platform-agnostic by converting it to device_property_*() functions
      and renaming it accordingly.
      
      In imx.c, move the invocation of uart_get_rs485_mode() from
      serial_imx_probe_dt() to serial_imx_probe() so that it also gets called
      for non-OF devices.
      
      In omap-serial.c, move its invocation further up within
      serial_omap_probe_rs485() so that the RTS polarity can be overridden
      with the driver-specific "rs485-rts-active-high" property once we
      introduce a generic "rs485-rts-active-low" property.
      
      Cc: Jan Kiszka <jan.kiszka@siemens.com>
      Cc: Richard Genoud <richard.genoud@gmail.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      743f93f8
  6. 19 9月, 2017 1 次提交
  7. 29 8月, 2017 1 次提交
  8. 30 7月, 2017 1 次提交
  9. 18 5月, 2017 1 次提交
  10. 09 4月, 2017 1 次提交
  11. 31 3月, 2017 1 次提交
  12. 12 1月, 2017 1 次提交
  13. 16 12月, 2016 1 次提交
  14. 16 11月, 2016 1 次提交
  15. 28 9月, 2016 1 次提交
  16. 15 9月, 2016 1 次提交
  17. 02 9月, 2016 1 次提交
  18. 26 6月, 2016 1 次提交
  19. 01 5月, 2016 2 次提交
  20. 07 2月, 2016 5 次提交
  21. 14 12月, 2015 2 次提交
  22. 07 5月, 2015 1 次提交
  23. 10 4月, 2015 1 次提交
  24. 27 3月, 2015 2 次提交
  25. 26 3月, 2015 1 次提交
  26. 07 3月, 2015 3 次提交
  27. 03 2月, 2015 1 次提交
    • P
      serial: core: Rework hw-assisted flow control support · 391f93f2
      Peter Hurley 提交于
      hw-assisted flow control support was added to the serial core
      in v3.8 with commits,
      dba05832 ("SERIAL: core: add hardware assisted h/w flow control support")
      2cbacafd ("SERIAL: core: add hardware assisted s/w flow control support")
      9aba8d5b ("SERIAL: core: add throttle/unthrottle callbacks for hardware
                      assisted flow control")
      Since then, additional requirements for serial core support have arisen.
      Specifically,
      1. Separate tx and rx flow control settings for UARTs which only support
         tx flow control (ie., autoCTS).
      2. Disable sw-assisted CTS flow control in autoCTS mode
      3. Support for RTS flow control by serial core and userspace in autoRTS mode
      
      Distinguish mode from capability; introduce UPSTAT_AUTORTS, UPSTAT_AUTOCTS
      and UPSTAT_AUTOXOFF which, when set by the uart driver, enable serial core
      support for hw-assisted rx, hw-assisted tx and hw-assisted in-band/IXOFF
      rx flow control, respectively. [Note: hw-assisted in-band/IXON tx flow
      control does not require serial core support/intervention and can be
      enabled by the uart driver when required.]
      
      These modes must be set/reset in the driver's set_termios() method, based
      on termios settings, and thus can be safely queried in any context in which
      one of the port lock, port mutex or termios rwsem are held. Set these modes
      in the 2 in-tree drivers, omap-serial and 8250_omap, which currently
      use UPF_HARD_FLOW/UPF_SOFT_FLOW support.
      
      Retain UPF_HARD_FLOW and UPF_SOFT_FLOW as capabilities; re-define
      UPF_HARD_FLOW as both UPF_AUTO_RTS and UPF_AUTO_CTS to allow for distinct
      and separate rx and tx flow control capabilities.
      
      Disable sw-assisted CTS flow control when UPSTAT_AUTOCTS is enabled.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      391f93f2
  28. 10 1月, 2015 1 次提交
    • P
      serial: omap_8250: Fix RTS handling · 4bf4ea9d
      Peter Hurley 提交于
      The OMAP3 UART ignores MCR[1] (ie., UART_MCR_RTS) when in autoRTS
      mode (UPF_HARD_FLOW + CRTSCTS). This makes it impossible for either
      the serial core or userspace to manually flow control the sender.
      
      Disable autoRTS mode when RTS is lowered and restore the previous
      mode when RTS is raised.
      
      Note that the OMAP3 UART provides no mechanism for switching from
      autoRTS mode without corrupting incoming data; to access the
      necessary register, the line control settings must be set to 8-e-2
      and thus any data received during that time will be interpreted with
      those settings. This corruption has been observed in practice.
      
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bf4ea9d
  29. 26 11月, 2014 1 次提交
  30. 07 11月, 2014 2 次提交