<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/tty, branch v6.4</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.4</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.4'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-06-13T10:31:45Z</updated>
<entry>
<title>tty: serial: fsl_lpuart: reduce RX watermark to 0 on LS1028A</title>
<updated>2023-06-13T10:31:45Z</updated>
<author>
<name>Robert Hodaszi</name>
<email>robert.hodaszi@digi.com</email>
</author>
<published>2023-06-09T12:13:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a82c3df955f8c1c726e4976527aa6ae924a67dd9'/>
<id>urn:sha1:a82c3df955f8c1c726e4976527aa6ae924a67dd9</id>
<content type='text'>
LS1028A is using DMA with LPUART. Having RX watermark set to 1, means
DMA transactions are started only after receiving the second character.

On other platforms with newer LPUART IP, Receiver Idle Empty function
initiates the DMA request after the receiver is idling for 4 characters.
But this feature is missing on LS1028A, which is causing a 1-character
delay in the RX direction on this platform.

Set RX watermark to 0 to initiate RX DMA after each character.

Link: https://lore.kernel.org/linux-serial/20230607103459.1222426-1-robert.hodaszi@digi.com/
Fixes: 9ad9df844754 ("tty: serial: fsl_lpuart: Fix the wrong RXWATER setting for rx dma case")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Robert Hodaszi &lt;robert.hodaszi@digi.com&gt;
Message-ID: &lt;20230609121334.1878626-1-robert.hodaszi@digi.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: lantiq: add missing interrupt ack</title>
<updated>2023-06-06T12:45:34Z</updated>
<author>
<name>Bernhard Seibold</name>
<email>mail@bernhard-seibold.de</email>
</author>
<published>2023-06-02T13:30:29Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=306320034e8fbe7ee1cc4f5269c55658b4612048'/>
<id>urn:sha1:306320034e8fbe7ee1cc4f5269c55658b4612048</id>
<content type='text'>
Currently, the error interrupt is never acknowledged, so once active it
will stay active indefinitely, causing the handler to be called in an
infinite loop.

Fixes: 2f0fc4159a6a ("SERIAL: Lantiq: Add driver for MIPS Lantiq SOCs.")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Bernhard Seibold &lt;mail@bernhard-seibold.de&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Message-ID: &lt;20230602133029.546-1-mail@bernhard-seibold.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: cpm_uart: Fix a COMPILE_TEST dependency</title>
<updated>2023-05-30T11:25:47Z</updated>
<author>
<name>Herve Codina</name>
<email>herve.codina@bootlin.com</email>
</author>
<published>2023-05-23T08:59:02Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7183c37fd53eee1e795206e625da12a5d7ec1e1a'/>
<id>urn:sha1:7183c37fd53eee1e795206e625da12a5d7ec1e1a</id>
<content type='text'>
In a COMPILE_TEST configuration, the cpm_uart driver uses symbols from
the cpm_uart_cpm2.c file. This file is compiled only when CONFIG_CPM2 is
set.

Without this dependency, the linker fails with some missing symbols for
COMPILE_TEST configuration that needs SERIAL_CPM without enabling CPM2.

This lead to:
  depends on CPM2 || CPM1 || (PPC32 &amp;&amp; CPM2 &amp;&amp; COMPILE_TEST)

This dependency does not make sense anymore and can be simplified
removing all the COMPILE_TEST part.

Signed-off-by: Herve Codina &lt;herve.codina@bootlin.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Link: https://lore.kernel.org/oe-kbuild-all/202305160221.9XgweObz-lkp@intel.com/
Fixes: e3e7b13bffae ("serial: allow COMPILE_TEST for some drivers")
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20230523085902.75837-3-herve.codina@bootlin.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: serial: fsl_lpuart: use UARTCTRL_TXINV to send break instead of UARTCTRL_SBK</title>
<updated>2023-05-30T11:24:27Z</updated>
<author>
<name>Sherry Sun</name>
<email>sherry.sun@nxp.com</email>
</author>
<published>2023-05-19T09:47:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2474e05467c00f7d51af3039b664de6886325257'/>
<id>urn:sha1:2474e05467c00f7d51af3039b664de6886325257</id>
<content type='text'>
LPUART IP now has two known bugs, one is that CTS has higher priority
than the break signal, which causes the break signal sending through
UARTCTRL_SBK may impacted by the CTS input if the HW flow control is
enabled. It exists on all platforms we support in this driver.
So we add a workaround patch for this issue: commit c4c81db5cf8b
("tty: serial: fsl_lpuart: disable the CTS when send break signal").

Another IP bug is i.MX8QM LPUART may have an additional break character
being sent after SBK was cleared. It may need to add some delay between
clearing SBK and re-enabling CTS to ensure that the SBK latch are
completely cleared.

But we found that during the delay period before CTS is enabled, there
is still a risk that Bluetooth data in TX FIFO may be sent out during
this period because of break off and CTS disabled(even if BT sets CTS
line deasserted, data is still sent to BT).

Due to this risk, we have to drop the CTS-disabling workaround for SBK
bugs, use TXINV seems to be a better way to replace SBK feature and
avoid above risk. Also need to disable the transmitter to prevent any
data from being sent out during break, then invert the TX line to send
break. Then disable the TXINV when turn off break and re-enable
transmitter.

Fixes: c4c81db5cf8b ("tty: serial: fsl_lpuart: disable the CTS when send break signal")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Sherry Sun &lt;sherry.sun@nxp.com&gt;
Link: https://lore.kernel.org/r/20230519094751.28948-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250_tegra: Fix an error handling path in tegra_uart_probe()</title>
<updated>2023-05-30T11:24:07Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2023-05-14T11:25:42Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=134f49dec0b6aca3259cd8259de4c572048bd207'/>
<id>urn:sha1:134f49dec0b6aca3259cd8259de4c572048bd207</id>
<content type='text'>
If an error occurs after reset_control_deassert(), it must be re-asserted,
as already done in the .remove() function.

Fixes: c6825c6395b7 ("serial: 8250_tegra: Create Tegra specific 8250 driver")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/f8130f35339cc80edc6b9aac4bb2a60b60a226bf.1684063511.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF</title>
<updated>2023-05-13T11:01:13Z</updated>
<author>
<name>George Kennedy</name>
<email>george.kennedy@oracle.com</email>
</author>
<published>2023-05-12T11:08:48Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8fb9ea65c9d1338b0d2bb0a9122dc942cdd32357'/>
<id>urn:sha1:8fb9ea65c9d1338b0d2bb0a9122dc942cdd32357</id>
<content type='text'>
After a call to console_unlock() in vcs_write() the vc_data struct can be
freed by vc_port_destruct(). Because of that, the struct vc_data pointer
must be reloaded in the while loop in vcs_write() after console_lock() to
avoid a UAF when vcs_size() is called.

Syzkaller reported a UAF in vcs_size().

BUG: KASAN: slab-use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
Read of size 4 at addr ffff8880beab89a8 by task repro_vcs_size/4119

Call Trace:
 &lt;TASK&gt;
__asan_report_load4_noabort (mm/kasan/report_generic.c:380)
vcs_size (drivers/tty/vt/vc_screen.c:215)
vcs_write (drivers/tty/vt/vc_screen.c:664)
vfs_write (fs/read_write.c:582 fs/read_write.c:564)
...
 &lt;TASK&gt;

Allocated by task 1213:
kmalloc_trace (mm/slab_common.c:1064)
vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680
    drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058)
con_install (drivers/tty/vt/vt.c:3334)
tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415
    drivers/tty/tty_io.c:1392)
tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128)
chrdev_open (fs/char_dev.c:415)
do_dentry_open (fs/open.c:921)
vfs_open (fs/open.c:1052)
...

Freed by task 4116:
kfree (mm/slab_common.c:1016)
vc_port_destruct (drivers/tty/vt/vt.c:1044)
tty_port_destructor (drivers/tty/tty_port.c:296)
tty_port_put (drivers/tty/tty_port.c:312)
vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))
vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)
tty_ioctl (drivers/tty/tty_io.c:2778)
...

The buggy address belongs to the object at ffff8880beab8800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 424 bytes inside of
 freed 1024-byte region [ffff8880beab8800, ffff8880beab8c00)

The buggy address belongs to the physical page:
page:00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000
    index:0x0 pfn:0xbeab8
head:00000000afc77580 order:3 entire_mapcount:0 nr_pages_mapped:0
    pincount:0
flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
page_type: 0xffffffff()
raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
&gt;ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
 ffff8880beab8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8880beab8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint

Fixes: ac751efa6a0d ("console: rename acquire/release_console_sem() to console_lock/unlock()")
Cc: stable &lt;stable@kernel.org&gt;
Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: George Kennedy &lt;george.kennedy@oracle.com&gt;
Reviewed-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://lore.kernel.org/r/1683889728-10411-1-git-send-email-george.kennedy@oracle.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: qcom-geni: fix enabling deactivated interrupt</title>
<updated>2023-05-13T11:00:54Z</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzysztof.kozlowski@linaro.org</email>
</author>
<published>2023-05-05T15:23:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5f949f140f73696f64acb89a1f16ff9153d017e0'/>
<id>urn:sha1:5f949f140f73696f64acb89a1f16ff9153d017e0</id>
<content type='text'>
The driver have a race, experienced only with PREEMPT_RT patchset:

CPU0                         | CPU1
==================================================================
qcom_geni_serial_probe       |
  uart_add_one_port          |
                             | serdev_drv_probe
                             |   qca_serdev_probe
                             |     serdev_device_open
                             |       uart_open
                             |         uart_startup
                             |           qcom_geni_serial_startup
                             |             enable_irq
                             |               __irq_startup
                             |                 WARN_ON()
                             |                 IRQ not activated
  request_threaded_irq       |
    irq_domain_activate_irq  |

The warning:

  894000.serial: ttyHS1 at MMIO 0x894000 (irq = 144, base_baud = 0) is a MSM
  serial serial0: tty port ttyHS1 registered
  WARNING: CPU: 7 PID: 107 at kernel/irq/chip.c:241 __irq_startup+0x78/0xd8
  ...
  qcom_geni_serial 894000.serial: serial engine reports 0 RX bytes in!

Adding UART port triggers probe of child serial devices - serdev and
eventually Qualcomm Bluetooth hci_qca driver.  This opens UART port
which enables the interrupt before it got activated in
request_threaded_irq().  The issue originates in commit f3974413cf02
("tty: serial: qcom_geni_serial: Wakeup IRQ cleanup") and discussion on
mailing list [1].  However the above commit does not explain why the
uart_add_one_port() is moved above requesting interrupt.

[1] https://lore.kernel.org/all/5d9f3dfa.1c69fb81.84c4b.30bf@mx.google.com/

Fixes: f3974413cf02 ("tty: serial: qcom_geni_serial: Wakeup IRQ cleanup")
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Stephen Boyd &lt;swboyd@chromium.org&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@linaro.org&gt;
Reviewed-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Link: https://lore.kernel.org/r/20230505152301.2181270-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250_bcm7271: fix leak in `brcmuart_probe`</title>
<updated>2023-05-13T10:56:01Z</updated>
<author>
<name>Doug Berger</name>
<email>opendmb@gmail.com</email>
</author>
<published>2023-04-27T18:19:16Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f264f2f6f4788dc031cef60a0cf2881902736709'/>
<id>urn:sha1:f264f2f6f4788dc031cef60a0cf2881902736709</id>
<content type='text'>
Smatch reports:
drivers/tty/serial/8250/8250_bcm7271.c:1120 brcmuart_probe() warn:
'baud_mux_clk' from clk_prepare_enable() not released on lines: 1032.

The issue is fixed by using a managed clock.

Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver")
Reported-by: XuDong Liu &lt;m202071377@hust.edu.cn&gt;
Link: https://lore.kernel.org/lkml/20230424125100.4783-1-m202071377@hust.edu.cn/
Signed-off-by: Doug Berger &lt;opendmb@gmail.com&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20230427181916.2983697-3-opendmb@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250_bcm7271: balance clk_enable calls</title>
<updated>2023-05-13T10:56:01Z</updated>
<author>
<name>Doug Berger</name>
<email>opendmb@gmail.com</email>
</author>
<published>2023-04-27T18:19:15Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8a3b5477256a54ae4a470dcebbcf8cdc18e4696d'/>
<id>urn:sha1:8a3b5477256a54ae4a470dcebbcf8cdc18e4696d</id>
<content type='text'>
The sw_baud clock must be disabled when the device driver is not
connected to the device. This now occurs when probe fails and
upon remove.

Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver")
Reported-by: XuDong Liu &lt;m202071377@hust.edu.cn&gt;
Link: https://lore.kernel.org/lkml/20230424125100.4783-1-m202071377@hust.edu.cn/
Signed-off-by: Doug Berger &lt;opendmb@gmail.com&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20230427181916.2983697-2-opendmb@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: arc_uart: fix of_iomap leak in `arc_serial_probe`</title>
<updated>2023-05-13T10:55:46Z</updated>
<author>
<name>Ke Zhang</name>
<email>m202171830@hust.edu.cn</email>
</author>
<published>2023-04-28T03:16:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8ab5fc55d7f65d58a3c3aeadf11bdf60267cd2bd'/>
<id>urn:sha1:8ab5fc55d7f65d58a3c3aeadf11bdf60267cd2bd</id>
<content type='text'>
Smatch reports:

drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn:
'port-&gt;membase' from of_iomap() not released on lines: 631.

In arc_serial_probe(), if uart_add_one_port() fails,
port-&gt;membase is not released, which would cause a resource leak.

To fix this, I replace of_iomap with devm_platform_ioremap_resource.

Fixes: 8dbe1d5e09a7 ("serial/arc: inline the probe helper")
Signed-off-by: Ke Zhang &lt;m202171830@hust.edu.cn&gt;
Reviewed-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Link: https://lore.kernel.org/r/20230428031636.44642-1-m202171830@hust.edu.cn
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
