<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/tty, branch v6.6.132</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-25T10:06:04+00:00</updated>
<entry>
<title>serial: uartlite: fix PM runtime usage count underflow on probe</title>
<updated>2026-03-25T10:06:04+00:00</updated>
<author>
<name>Maciej Andrzejewski ICEYE</name>
<email>maciej.andrzejewski@m-works.net</email>
</author>
<published>2026-03-05T12:37:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=447f2c6ef11c0798d65ddd788903fc3d730b39ff'/>
<id>urn:sha1:447f2c6ef11c0798d65ddd788903fc3d730b39ff</id>
<content type='text'>
commit d54801cd509515f674a5aac1d3ea1401d2a05863 upstream.

ulite_probe() calls pm_runtime_put_autosuspend() at the end of probe
without holding a corresponding PM runtime reference for non-console
ports.

During ulite_assign(), uart_add_one_port() triggers uart_configure_port()
which calls ulite_pm() via uart_change_pm(). For non-console ports, the
UART core performs a balanced get/put cycle:

  uart_change_pm(ON)  -&gt; ulite_pm() -&gt; pm_runtime_get_sync()        +1
  uart_change_pm(OFF) -&gt; ulite_pm() -&gt; pm_runtime_put_autosuspend() -1

This leaves no spare reference for the pm_runtime_put_autosuspend() at
the end of probe. The PM runtime core prevents the count from actually
going below zero, and instead triggers a
"Runtime PM usage count underflow!" warning.

For console ports the bug is masked: the UART core skips the
uart_change_pm(OFF) call, so the UART core's unbalanced get happens to
pair with probe's trailing put.

Add pm_runtime_get_noresume() before pm_runtime_enable() to take an
explicit probe-owned reference that the trailing
pm_runtime_put_autosuspend() can release. This ensures a correct usage
count regardless of whether the port is a console.

Fixes: 5bbe10a6942d ("tty: serial: uartlite: Add runtime pm support")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Maciej Andrzejewski ICEYE &lt;maciej.andrzejewski@m-works.net&gt;
Link: https://patch.msgid.link/20260305123746.4152800-1-maciej.andrzejewski@m-works.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY</title>
<updated>2026-03-25T10:06:04+00:00</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2026-02-03T17:10:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=59e13f1c9a8c8c338970bc1020aa12a4959a01a6'/>
<id>urn:sha1:59e13f1c9a8c8c338970bc1020aa12a4959a01a6</id>
<content type='text'>
commit e0a368ae79531ff92105a2692f10d83052055856 upstream.

When DW UART is !uart_16550_compatible, it can indicate BUSY at any
point (when under constant Rx pressure) unless a complex sequence of
steps is performed. Any LCR write can run a foul with the condition
that prevents writing LCR while the UART is BUSY, which triggers
BUSY_DETECT interrupt that seems unmaskable using IER bits.

Normal flow is that dw8250_handle_irq() handles BUSY_DETECT condition
by reading USR register. This BUSY feature, however, breaks the
assumptions made in serial8250_do_shutdown(), which runs
synchronize_irq() after clearing IER and assumes no interrupts can
occur after that point but then proceeds to update LCR, which on DW
UART can trigger an interrupt.

If serial8250_do_shutdown() releases the interrupt handler before the
handler has run and processed the BUSY_DETECT condition by read the USR
register, the IRQ is not deasserted resulting in interrupt storm that
triggers "irq x: nobody cared" warning leading to disabling the IRQ.

Add late synchronize_irq() into serial8250_do_shutdown() to ensure
BUSY_DETECT from DW UART is handled before port's interrupt handler is
released. Alternative would be to add DW UART specific shutdown
function but it would mostly duplicate the generic code and the extra
synchronize_irq() seems pretty harmless in serial8250_do_shutdown().

Fixes: 7d4008ebb1c9 ("tty: add a DesignWare 8250 driver")
Cc: stable &lt;stable@kernel.org&gt;
Reported-by: Bandal, Shankar &lt;shankar.bandal@intel.com&gt;
Tested-by: Bandal, Shankar &lt;shankar.bandal@intel.com&gt;
Tested-by: Murthy, Shanth &lt;shanth.murthy@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://patch.msgid.link/20260203171049.4353-7-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: Fix TX deadlock when using DMA</title>
<updated>2026-03-25T10:06:04+00:00</updated>
<author>
<name>Raul E Rangel</name>
<email>rrangel@chromium.org</email>
</author>
<published>2026-02-09T20:58:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d2719a0a9c3439abf67843a5504b7afccd9ded93'/>
<id>urn:sha1:d2719a0a9c3439abf67843a5504b7afccd9ded93</id>
<content type='text'>
commit a424a34b8faddf97b5af41689087e7a230f79ba7 upstream.

`dmaengine_terminate_async` does not guarantee that the
`__dma_tx_complete` callback will run. The callback is currently the
only place where `dma-&gt;tx_running` gets cleared. If the transaction is
canceled and the callback never runs, then `dma-&gt;tx_running` will never
get cleared and we will never schedule new TX DMA transactions again.

This change makes it so we clear `dma-&gt;tx_running` after we terminate
the DMA transaction. This is "safe" because `serial8250_tx_dma_flush`
is holding the UART port lock. The first thing the callback does is also
grab the UART port lock, so access to `dma-&gt;tx_running` is serialized.

Fixes: 9e512eaaf8f4 ("serial: 8250: Fix fifo underflow on flush")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Raul E Rangel &lt;rrangel@google.com&gt;
Link: https://patch.msgid.link/20260209135815.1.I16366ecb0f62f3c96fe3dd5763fcf6f3c2b4d8cd@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250_pci: add support for the AX99100</title>
<updated>2026-03-25T10:06:04+00:00</updated>
<author>
<name>Martin Roukala (né Peres)</name>
<email>martin.roukala@mupuf.org</email>
</author>
<published>2026-03-09T13:53:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=092cb022a4544f0c520aef4c69117dcaddda4b2b'/>
<id>urn:sha1:092cb022a4544f0c520aef4c69117dcaddda4b2b</id>
<content type='text'>
commit 9c0072bc33d349c83d223e64be30794e11938a6b upstream.

This is found in popular brands such as StarTech.com or Delock, and has
been a source of frustration to quite a few people, if I can trust
Amazon comments complaining about Linux support via the official
out-of-the-tree driver.

Signed-off-by: Martin Roukala (né Peres) &lt;martin.roukala@mupuf.org&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://patch.msgid.link/20260309-8250_pci_ax99100-v1-1-3328bdfd8e94@mupuf.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done</title>
<updated>2026-03-04T12:20:54+00:00</updated>
<author>
<name>Moteen Shah</name>
<email>m-shah@ti.com</email>
</author>
<published>2026-01-12T08:18:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4ff5ab3e71414e27cd7603fdc4ee52362e29393f'/>
<id>urn:sha1:4ff5ab3e71414e27cd7603fdc4ee52362e29393f</id>
<content type='text'>
[ Upstream commit a5fd8945a478ff9be14812693891d7c9b4185a50 ]

Clear rx_running flag only after DMA teardown polling completes. In the
previous implementation the flag was being cleared while hardware teardown
was still in progress, creating a mismatch between software state
(flag = 0, "ready") and hardware state (still terminating).

Signed-off-by: Moteen Shah &lt;m-shah@ti.com&gt;
Link: https://patch.msgid.link/20260112081829.63049-3-m-shah@ti.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_dw: handle clock enable errors in runtime_resume</title>
<updated>2026-03-04T12:20:53+00:00</updated>
<author>
<name>Artem Shimko</name>
<email>a.shimko.dev@gmail.com</email>
</author>
<published>2025-11-04T14:54:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32ccda4895ba69c48e70c1808235933ebe707fa0'/>
<id>urn:sha1:32ccda4895ba69c48e70c1808235933ebe707fa0</id>
<content type='text'>
[ Upstream commit d31228143a489ba6ba797896a07541ce06828c09 ]

Add error checking for clk_prepare_enable() calls in
dw8250_runtime_resume(). Currently if either clock fails to enable,
the function returns success while leaving clocks in inconsistent state.

This change implements comprehensive error handling by checking the return
values of both clk_prepare_enable() calls. If the second clock enable
operation fails after the first clock has already been successfully
enabled, the code now properly cleans up by disabling and unpreparing
the first clock before returning. The error code is then propagated to
the caller, ensuring that clock enable failures are properly reported
rather than being silently ignored.

Signed-off-by: Artem Shimko &lt;a.shimko.dev@gmail.com&gt;
Link: https://patch.msgid.link/20251104145433.2316165-2-a.shimko.dev@gmail.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: SH_SCI: improve "DMA support" prompt</title>
<updated>2026-03-04T12:20:09+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2026-01-10T23:26:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=24ec8015beca758dde972950a4fc337c58d41fd8'/>
<id>urn:sha1:24ec8015beca758dde972950a4fc337c58d41fd8</id>
<content type='text'>
[ Upstream commit 93bb95a11238d66a4c9aa6eabf9774b073a5895c ]

Having a prompt of "DMA support" suddenly appear during a
"make oldconfig" can be confusing. Add a little helpful text to
the prompt message.

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Link: https://patch.msgid.link/20260110232643.3533351-5-rdunlap@infradead.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: imx: change SERIAL_IMX_CONSOLE to bool</title>
<updated>2026-03-04T12:20:09+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2026-01-10T23:26:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c233e1e818731c2eb06bfd35a870865eb5316f32'/>
<id>urn:sha1:c233e1e818731c2eb06bfd35a870865eb5316f32</id>
<content type='text'>
[ Upstream commit 79527d86ba91c2d9354832d19fd12b3baa66bd10 ]

SERIAL_IMX_CONSOLE is a build option for the imx driver (SERIAL_IMX).
It does not build a separate console driver file, so it can't be built
as a module since it isn't built at all.

Change the Kconfig symbol from tristate to bool and update the help
text accordingly.

Fixes: 0db4f9b91c86 ("tty: serial: imx: enable imx serial console port as module")
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Link: https://patch.msgid.link/20260110232643.3533351-2-rdunlap@infradead.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: 8250_pci: Fix broken RS485 for F81504/508/512</title>
<updated>2026-01-30T09:27:34+00:00</updated>
<author>
<name>Marnix Rijnart</name>
<email>marnix.rijnart@iwell.eu</email>
</author>
<published>2026-01-12T00:08:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dce0865a5828a09caa48d6daf109d47a3b965296'/>
<id>urn:sha1:dce0865a5828a09caa48d6daf109d47a3b965296</id>
<content type='text'>
commit 27aff0a56b3c77ea1a73641c9b3c4172a8f7238f upstream.

Fintek F81504/508/512 can support both RTS_ON_SEND and RTS_AFTER_SEND,
but pci_fintek_rs485_supported only announces the former.

This makes it impossible to unset SER_RS485_RTS_ON_SEND from
userspace because of uart_sanitize_serial_rs485(). Some devices
with these chips need RTS low on TX, so they are effectively broken.

Fix this by announcing the support for SER_RS485_RTS_AFTER_SEND,
similar to commit 068d35a7be65 ("serial: sc16is7xx: announce support
for SER_RS485_RTS_ON_SEND").

Fixes: 4afeced55baa ("serial: core: fix sanitizing check for RTS settings")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Marnix Rijnart &lt;marnix.rijnart@iwell.eu&gt;
Link: https://patch.msgid.link/20260112000931.61703-1-marnix.rijnart@iwell.eu
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: fix tty_port_tty_*hangup() kernel-doc</title>
<updated>2026-01-11T14:22:33+00:00</updated>
<author>
<name>Jiri Slaby (SUSE)</name>
<email>jirislaby@kernel.org</email>
</author>
<published>2025-06-24T08:06:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=21e82354cdd7c954dbcf3e06d8536b40d2813c16'/>
<id>urn:sha1:21e82354cdd7c954dbcf3e06d8536b40d2813c16</id>
<content type='text'>
commit 6241b49540a65a6d5274fa938fd3eb4cbfe2e076 upstream.

The commit below added a new helper, but omitted to move (and add) the
corressponding kernel-doc. Do it now.

Signed-off-by: "Jiri Slaby (SUSE)" &lt;jirislaby@kernel.org&gt;
Fixes: 2b5eac0f8c6e ("tty: introduce and use tty_port_tty_vhangup() helper")
Link: https://lore.kernel.org/all/b23d566c-09dc-7374-cc87-0ad4660e8b2e@linux.intel.com/
Reported-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: linux-doc@vger.kernel.org
Link: https://lore.kernel.org/r/20250624080641.509959-6-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
