<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/tty, branch v6.1.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-04-13T11:05:23+00:00</updated>
<entry>
<title>tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc</title>
<updated>2024-04-13T11:05:23+00:00</updated>
<author>
<name>Thadeu Lima de Souza Cascardo</name>
<email>cascardo@canonical.com</email>
</author>
<published>2023-07-31T18:59:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b85977977cbd120591b23c2450e90a5806a7167'/>
<id>urn:sha1:2b85977977cbd120591b23c2450e90a5806a7167</id>
<content type='text'>
commit 67c37756898a5a6b2941a13ae7260c89b54e0d88 upstream.

Any unprivileged user can attach N_GSM0710 ldisc, but it requires
CAP_NET_ADMIN to create a GSM network anyway.

Require initial namespace CAP_NET_ADMIN to do that.

Signed-off-by: Thadeu Lima de Souza Cascardo &lt;cascardo@canonical.com&gt;
Link: https://lore.kernel.org/r/20230731185942.279611-1-cascardo@canonical.com
Cc: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: serial: imx: Fix broken RS485</title>
<updated>2024-04-03T13:19:46+00:00</updated>
<author>
<name>Rickard x Andersson</name>
<email>rickaran@axis.com</email>
</author>
<published>2024-02-21T11:53:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4f2debd9c6801065196960d2967de4668ed025a8'/>
<id>urn:sha1:4f2debd9c6801065196960d2967de4668ed025a8</id>
<content type='text'>
commit 672448ccf9b6a676f96f9352cbf91f4d35f4084a upstream.

When about to transmit the function imx_uart_start_tx is called and in
some RS485 configurations this function will call imx_uart_stop_rx. The
problem is that imx_uart_stop_rx will enable loopback in order to
release the RS485 bus, but when loopback is enabled transmitted data
will just be looped to RX.

This patch fixes the above problem by not enabling loopback when about
to transmit.

This driver now works well when used for RS485 half duplex master
configurations.

Fixes: 79d0224f6bf2 ("tty: serial: imx: Handle RS485 DE signal active high")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Rickard x Andersson &lt;rickaran@axis.com&gt;
Tested-by: Christoph Niedermaier &lt;cniedermaier@dh-electronics.com&gt;
Link: https://lore.kernel.org/r/20240221115304.509811-1-rickaran@axis.com
Signed-off-by: Christoph Niedermaier &lt;cniedermaier@dh-electronics.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vt: fix unicode buffer corruption when deleting characters</title>
<updated>2024-04-03T13:19:42+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nico@fluxnic.net</email>
</author>
<published>2024-02-29T22:15:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=994a1e583c0c206c8ca7d03334a65b79f4d8bc51'/>
<id>urn:sha1:994a1e583c0c206c8ca7d03334a65b79f4d8bc51</id>
<content type='text'>
commit 1581dafaf0d34bc9c428a794a22110d7046d186d upstream.

This is the same issue that was fixed for the VGA text buffer in commit
39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
buffer"). The cure is also the same i.e. replace memcpy() with memmove()
due to the overlaping buffers.

Signed-off-by: Nicolas Pitre &lt;nico@fluxnic.net&gt;
Fixes: 81732c3b2fed ("tty vt: Fix line garbage in virtual console on command line edition")
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/sn184on2-3p0q-0qrq-0218-895349s4753o@syhkavp.arg
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: serial: fsl_lpuart: avoid idle preamble pending if CTS is enabled</title>
<updated>2024-04-03T13:19:41+00:00</updated>
<author>
<name>Sherry Sun</name>
<email>sherry.sun@nxp.com</email>
</author>
<published>2024-03-05T01:57:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d40ab69217481d938b3434f5218032f59a58b935'/>
<id>urn:sha1:d40ab69217481d938b3434f5218032f59a58b935</id>
<content type='text'>
commit 74cb7e0355fae9641f825afa389d3fba3b617714 upstream.

If the remote uart device is not connected or not enabled after booting
up, the CTS line is high by default. At this time, if we enable the flow
control when opening the device(for example, using “stty -F /dev/ttyLP4
crtscts” command), there will be a pending idle preamble(first writing 0
and then writing 1 to UARTCTRL_TE will queue an idle preamble) that
cannot be sent out, resulting in the uart port fail to close(waiting for
TX empty), so the user space stty will have to wait for a long time or
forever.

This is an LPUART IP bug(idle preamble has higher priority than CTS),
here add a workaround patch to enable TX CTS after enabling UARTCTRL_TE,
so that the idle preamble does not get stuck due to CTS is deasserted.

Fixes: 380c966c093e ("tty: serial: fsl_lpuart: add 32-bit register interface support")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Sherry Sun &lt;sherry.sun@nxp.com&gt;
Reviewed-by: Alexander Sverdlin &lt;alexander.sverdlin@siemens.com&gt;
Link: https://lore.kernel.org/r/20240305015706.1050769-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: Lock console when calling into driver before registration</title>
<updated>2024-04-03T13:19:31+00:00</updated>
<author>
<name>Peter Collingbourne</name>
<email>pcc@google.com</email>
</author>
<published>2024-03-04T21:43:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b8073c069a843f556469aab45254b099a4d969de'/>
<id>urn:sha1:b8073c069a843f556469aab45254b099a4d969de</id>
<content type='text'>
[ Upstream commit 801410b26a0e8b8a16f7915b2b55c9528b69ca87 ]

During the handoff from earlycon to the real console driver, we have
two separate drivers operating on the same device concurrently. In the
case of the 8250 driver these concurrent accesses cause problems due
to the driver's use of banked registers, controlled by LCR.DLAB. It is
possible for the setup(), config_port(), pm() and set_mctrl() callbacks
to set DLAB, which can cause the earlycon code that intends to access
TX to instead access DLL, leading to missed output and corruption on
the serial line due to unintended modifications to the baud rate.

In particular, for setup() we have:

univ8250_console_setup()
-&gt; serial8250_console_setup()
-&gt; uart_set_options()
-&gt; serial8250_set_termios()
-&gt; serial8250_do_set_termios()
-&gt; serial8250_do_set_divisor()

For config_port() we have:

serial8250_config_port()
-&gt; autoconfig()

For pm() we have:

serial8250_pm()
-&gt; serial8250_do_pm()
-&gt; serial8250_set_sleep()

For set_mctrl() we have (for some devices):

serial8250_set_mctrl()
-&gt; omap8250_set_mctrl()
-&gt; __omap8250_set_mctrl()

To avoid such problems, let's make it so that the console is locked
during pre-registration calls to these callbacks, which will prevent
the earlycon driver from running concurrently.

Remove the partial solution to this problem in the 8250 driver
that locked the console only during autoconfig_irq(), as this would
result in a deadlock with the new approach. The console continues
to be locked during autoconfig_irq() because it can only be called
through uart_configure_port().

Although this patch introduces more locking than strictly necessary
(and in particular it also locks during the call to rs485_config()
which is not affected by this issue as far as I can tell), it follows
the principle that it is the responsibility of the generic console
code to manage the earlycon handoff by ensuring that earlycon and real
console driver code cannot run concurrently, and not the individual
drivers.

Signed-off-by: Peter Collingbourne &lt;pcc@google.com&gt;
Reviewed-by: John Ogness &lt;john.ogness@linutronix.de&gt;
Link: https://linux-review.googlesource.com/id/I7cf8124dcebf8618e6b2ee543fa5b25532de55d8
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240304214350.501253-1-pcc@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: max310x: fix NULL pointer dereference in I2C instantiation</title>
<updated>2024-04-03T13:19:24+00:00</updated>
<author>
<name>Hugo Villeneuve</name>
<email>hvilleneuve@dimonoff.com</email>
</author>
<published>2024-01-18T15:21:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=12609c76b755dbeb1645c0aacc0f0f4743b2eff3'/>
<id>urn:sha1:12609c76b755dbeb1645c0aacc0f0f4743b2eff3</id>
<content type='text'>
[ Upstream commit 0d27056c24efd3d63a03f3edfbcfc4827086b110 ]

When trying to instantiate a max14830 device from userspace:

    echo max14830 0x60 &gt; /sys/bus/i2c/devices/i2c-2/new_device

we get the following error:

    Unable to handle kernel NULL pointer dereference at virtual address...
    ...
    Call trace:
        max310x_i2c_probe+0x48/0x170 [max310x]
        i2c_device_probe+0x150/0x2a0
    ...

Add check for validity of devtype to prevent the error, and abort probe
with a meaningful error message.

Fixes: 2e1f2d9a9bdb ("serial: max310x: implement I2C support")
Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Hugo Villeneuve &lt;hvilleneuve@dimonoff.com&gt;
Link: https://lore.kernel.org/r/20240118152213.2644269-2-hugo@hugovil.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250_exar: Don't remove GPIO device on suspend</title>
<updated>2024-03-26T22:20:58+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2024-02-19T15:04:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d2b48ecc760ae540b298bcf88a050c8bceef9662'/>
<id>urn:sha1:d2b48ecc760ae540b298bcf88a050c8bceef9662</id>
<content type='text'>
[ Upstream commit 73b5a5c00be39e23b194bad10e1ea8bb73eee176 ]

It seems a copy&amp;paste mistake that suspend callback removes the GPIO
device. There is no counterpart of this action, means once suspended
there is no more GPIO device available untile full unbind-bind cycle
is performed. Remove suspicious GPIO device removal in suspend.

Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci")
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240219150627.2101198-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tty: serial: samsung: fix tx_empty() to return TIOCSER_TEMT</title>
<updated>2024-03-26T22:20:57+00:00</updated>
<author>
<name>Tudor Ambarus</name>
<email>tudor.ambarus@linaro.org</email>
</author>
<published>2024-01-19T10:45:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad7362db2fd718f2c9d12eefa5cb50a0376fc328'/>
<id>urn:sha1:ad7362db2fd718f2c9d12eefa5cb50a0376fc328</id>
<content type='text'>
[ Upstream commit 314c2b399288f0058a8c5b6683292cbde5f1531b ]

The core expects for tx_empty() either TIOCSER_TEMT when the tx is
empty or 0 otherwise. s3c24xx_serial_txempty_nofifo() might return
0x4, and at least uart_get_lsr_info() tries to clear exactly
TIOCSER_TEMT (BIT(1)). Fix tx_empty() to return TIOCSER_TEMT.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Reviewed-by: Sam Protsenko &lt;semen.protsenko@linaro.org&gt;
Link: https://lore.kernel.org/r/20240119104526.1221243-2-tudor.ambarus@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: max310x: fix syntax error in IRQ error message</title>
<updated>2024-03-26T22:20:57+00:00</updated>
<author>
<name>Hugo Villeneuve</name>
<email>hvilleneuve@dimonoff.com</email>
</author>
<published>2024-01-18T15:22:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e955764b41676ebaba44b478f4e7e2afb43a0140'/>
<id>urn:sha1:e955764b41676ebaba44b478f4e7e2afb43a0140</id>
<content type='text'>
[ Upstream commit 8ede8c6f474255b2213cccd7997b993272a8e2f9 ]

Replace g with q.

Helpful when grepping thru source code or logs for
"request" keyword.

Fixes: f65444187a66 ("serial: New serial driver MAX310X")
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Hugo Villeneuve &lt;hvilleneuve@dimonoff.com&gt;
Link: https://lore.kernel.org/r/20240118152213.2644269-6-hugo@hugovil.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tty: vt: fix 20 vs 0x20 typo in EScsiignore</title>
<updated>2024-03-26T22:20:57+00:00</updated>
<author>
<name>Jiri Slaby (SUSE)</name>
<email>jirislaby@kernel.org</email>
</author>
<published>2024-01-22T11:03:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52af9897e787bdaffa839f5d6fb535448a3c559a'/>
<id>urn:sha1:52af9897e787bdaffa839f5d6fb535448a3c559a</id>
<content type='text'>
[ Upstream commit 0e6a92f67c8a94707f7bb27ac29e2bdf3e7c167d ]

The if (c &gt;= 20 &amp;&amp; c &lt;= 0x3f) test added in commit 7a99565f8732 is
wrong.  20 is DC4 in ascii and it makes no sense to consider that as the
bottom limit. Instead, it should be 0x20 as in the other test in
the commit above. This is supposed to NOT change anything as we handle
interesting 20-0x20 asciis far before this if.

So for sakeness, change to 0x20 (which is SPACE).

Signed-off-by: "Jiri Slaby (SUSE)" &lt;jirislaby@kernel.org&gt;
Fixes: 7a99565f8732 ("vt: ignore csi sequences with intermediate characters.")
Cc: Martin Hostettler &lt;textshell@uchuujin.de&gt;
Link: https://lore.kernel.org/all/ZaP45QY2WEsDqoxg@neutronstar.dyndns.org/
Tested-by: Helge Deller &lt;deller@gmx.de&gt; # parisc STI console
Link: https://lore.kernel.org/r/20240122110401.7289-4-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
