1. 30 8月, 2022 2 次提交
  2. 28 7月, 2022 2 次提交
  3. 08 7月, 2022 1 次提交
  4. 27 6月, 2022 1 次提交
  5. 10 6月, 2022 3 次提交
  6. 20 5月, 2022 1 次提交
  7. 06 5月, 2022 1 次提交
  8. 22 4月, 2022 1 次提交
  9. 15 4月, 2022 2 次提交
  10. 03 3月, 2022 1 次提交
    • J
      serial: make uart_console_write->putchar()'s character an unsigned char · 3f8bab17
      Jiri Slaby 提交于
      Currently, uart_console_write->putchar's second parameter (the
      character) is of type int. It makes little sense, provided uart_console_write()
      accepts the input string as "const char *s" and passes its content -- the
      characters -- to putchar(). So switch the character's type to unsigned
      char.
      
      We don't use char as that is signed on some platforms. That would cause
      troubles for drivers which (implicitly) cast the char to u16 when
      writing to the device. Sign extension would happen in that case and the
      value written would be completely different to the provided char. DZ is
      an example of such a driver -- on MIPS, it uses u16 for dz_out in
      dz_console_putchar().
      
      Note we do the char -> uchar conversion implicitly in
      uart_console_write(). Provided we do not change size of the data type,
      sign extension does not happen there, so the problem is void.
      
      This makes the types consistent and unified with the rest of the uart
      layer, which uses unsigned char in most places already. One exception is
      xmit_buf, but that is going to be converted later.
      
      Cc: Paul Cercueil <paul@crapouillou.net>
      Cc: Tobias Klauser <tklauser@distanz.ch>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Vineet Gupta <vgupta@kernel.org>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: bcm-kernel-feedback-list@broadcom.com
      Cc: Alexander Shiyan <shc_work@mail.ru>
      Cc: Baruch Siach <baruch@tkos.co.il>
      Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: NXP Linux Team <linux-imx@nxp.com>
      Cc: Karol Gugala <kgugala@antmicro.com>
      Cc: Mateusz Holenko <mholenko@antmicro.com>
      Cc: Vladimir Zapolskiy <vz@mleia.com>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Taichi Sugaya <sugaya.taichi@socionext.com>
      Cc: Takao Orito <orito.takao@socionext.com>
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: "Andreas Färber" <afaerber@suse.de>
      Cc: Manivannan Sadhasivam <mani@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Andy Gross <agross@kernel.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Cc: Orson Zhai <orsonzhai@gmail.com>
      Cc: Baolin Wang <baolin.wang7@gmail.com>
      Cc: Chunyan Zhang <zhang.lyra@gmail.com>
      Cc: Patrice Chotard <patrice.chotard@foss.st.com>
      Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
      Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Peter Korsgaard <peter@korsgaard.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Acked-by: Richard Genoud <richard.genoud@gmail.com> [atmel_serial]
      Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: NPaul Cercueil <paul@crapouillou.net>
      Acked-by: Neil Armstrong <narmstrong@baylibre.com> # meson_serial
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Link: https://lore.kernel.org/r/20220303080831.21783-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f8bab17
  11. 26 1月, 2022 1 次提交
  12. 18 12月, 2021 1 次提交
  13. 03 12月, 2021 1 次提交
  14. 26 11月, 2021 1 次提交
  15. 26 8月, 2021 3 次提交
  16. 18 8月, 2021 1 次提交
  17. 29 7月, 2021 1 次提交
  18. 13 5月, 2021 10 次提交
  19. 21 1月, 2021 1 次提交
  20. 28 10月, 2020 1 次提交
    • V
      tty: serial: fsl_lpuart: LS1021A has a FIFO size of 16 words, like LS1028A · c97f2a6f
      Vladimir Oltean 提交于
      Prior to the commit that this one fixes, the FIFO size was derived from
      the read-only register LPUARTx_FIFO[TXFIFOSIZE] using the following
      formula:
      
      TX FIFO size = 2 ^ (LPUARTx_FIFO[TXFIFOSIZE] - 1)
      
      The documentation for LS1021A is a mess. Under chapter 26.1.3 LS1021A
      LPUART module special consideration, it mentions TXFIFO_SZ and RXFIFO_SZ
      being equal to 4, and in the register description for LPUARTx_FIFO, it
      shows the out-of-reset value of TXFIFOSIZE and RXFIFOSIZE fields as "011",
      even though these registers read as "101" in reality.
      
      And when LPUART on LS1021A was working, the "101" value did correspond
      to "16 datawords", by applying the formula above, even though the
      documentation is wrong again (!!!!) and says that "101" means 64 datawords
      (hint: it doesn't).
      
      So the "new" formula created by commit f77ebb24 has all the premises
      of being wrong for LS1021A, because it relied only on false data and no
      actual experimentation.
      
      Interestingly, in commit c2f448cf ("tty: serial: fsl_lpuart: add
      LS1028A support"), Michael Walle applied a workaround to this by manually
      setting the FIFO widths for LS1028A. It looks like the same values are
      used by LS1021A as well, in fact.
      
      When the driver thinks that it has a deeper FIFO than it really has,
      getty (user space) output gets truncated.
      
      Many thanks to Michael for pointing out where to look.
      
      Fixes: f77ebb24 ("tty: serial: fsl_lpuart: correct the FIFO depth size")
      Suggested-by: NMichael Walle <michael@walle.cc>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Link: https://lore.kernel.org/r/20201023013429.3551026-1-vladimir.oltean@nxp.com
      Reviewed-by:Fugang Duan <fugang.duan@nxp.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c97f2a6f
  21. 05 10月, 2020 1 次提交
  22. 30 9月, 2020 2 次提交
  23. 28 8月, 2020 1 次提交