<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/tty/serial/8250/8250_port.c, branch master</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=master</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-12T14:34:29Z</updated>
<entry>
<title>serial: 8250_dw: Ensure BUSY is deasserted</title>
<updated>2026-03-12T14:34:29Z</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2026-02-03T17:10:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a7b9ce39fbe4ae2919fe4f7ac16c293cb6632d30'/>
<id>urn:sha1:a7b9ce39fbe4ae2919fe4f7ac16c293cb6632d30</id>
<content type='text'>
DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
Existance of BUSY depends on uart_16550_compatible, if UART HW is
configured with it those registers can always be written.

There currently is dw8250_force_idle() which attempts to achieve
non-BUSY state by disabling FIFO, however, the solution is unreliable
when Rx keeps getting more and more characters.

Create a sequence of operations that ensures UART cannot keep BUSY
asserted indefinitely. The new sequence relies on enabling loopback mode
temporarily to prevent incoming Rx characters keeping UART BUSY.

Ensure no Tx in ongoing while the UART is switches into the loopback
mode (requires exporting serial8250_fifo_wait_for_lsr_thre() and adding
DMA Tx pause/resume functions).

According to tests performed by Adriana Nicolae &lt;adriana@arista.com&gt;,
simply disabling FIFO or clearing FIFOs only once does not always
ensure BUSY is deasserted but up to two tries may be needed. This could
be related to ongoing Rx of a character (a guess, not known for sure).
Therefore, retry FIFO clearing a few times (retry limit 4 is arbitrary
number but using, e.g., p-&gt;fifosize seems overly large). Tests
performed by others did not exhibit similar challenge but it does not
seem harmful to leave the FIFO clearing loop in place for all DW UARTs
with BUSY functionality.

Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
writes. In case of plain LCR writes, opportunistically try to update
LCR first and only invoke dw8250_idle_enter() if the write did not
succeed (it has been observed that in practice most LCR writes do
succeed without complications).

This issue was first reported by qianfan Zhao who put lots of debugging
effort into understanding the solution space.

Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround")
Fixes: 7d4008ebb1c9 ("tty: add a DesignWare 8250 driver")
Cc: stable &lt;stable@kernel.org&gt;
Reported-by: qianfan Zhao &lt;qianfanguijin@163.com&gt;
Link: https://lore.kernel.org/linux-serial/289bb78a-7509-1c5c-2923-a04ed3b6487d@163.com/
Reported-by: Adriana Nicolae &lt;adriana@arista.com&gt;
Link: https://lore.kernel.org/linux-serial/20250819182322.3451959-1-adriana@arista.com/
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-8-ilpo.jarvinen@linux.intel.com
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-12T14:34:25Z</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2026-02-03T17:10:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e0a368ae79531ff92105a2692f10d83052055856'/>
<id>urn:sha1:e0a368ae79531ff92105a2692f10d83052055856</id>
<content type='text'>
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: Add serial8250_handle_irq_locked()</title>
<updated>2026-03-12T14:34:15Z</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2026-02-03T17:10:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8324a54f604da18f21070702a8ad82ab2062787b'/>
<id>urn:sha1:8324a54f604da18f21070702a8ad82ab2062787b</id>
<content type='text'>
8250_port exports serial8250_handle_irq() to HW specific 8250 drivers.
It takes port's lock within but a HW specific 8250 driver may want to
take port's lock itself, do something, and then call the generic
handler in 8250_port but to do that, the caller has to release port's
lock for no good reason.

Introduce serial8250_handle_irq_locked() which a HW specific driver can
call while already holding port's lock.

As this is new export, put it straight into a namespace (where all 8250
exports should eventually be moved).

Tested-by: Bandal, Shankar &lt;shankar.bandal@intel.com&gt;
Tested-by: Murthy, Shanth &lt;shanth.murthy@intel.com&gt;
Cc: stable &lt;stable@kernel.org&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-4-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: Protect LCR write in shutdown</title>
<updated>2026-03-12T14:34:07Z</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2026-02-03T17:10:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=59a33d83bbe6d73d2071d7ae21590b29faed0503'/>
<id>urn:sha1:59a33d83bbe6d73d2071d7ae21590b29faed0503</id>
<content type='text'>
The 8250_dw driver needs to potentially perform very complex operations
during LCR writes because its BUSY handling prevents updates to LCR
while UART is BUSY (which is not fully under our control without those
complex operations). Thus, LCR writes should occur under port's lock.

Move LCR write under port's lock in serial8250_do_shutdown(). Also
split the LCR RMW so that the logic is on a separate line for clarity.

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;
Cc: stable &lt;stable@kernel.org&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-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: always disable IRQ during THRE test</title>
<updated>2026-03-12T14:30:30Z</updated>
<author>
<name>Peng Zhang</name>
<email>zhangpeng.00@bytedance.com</email>
</author>
<published>2026-02-24T12:16:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=24b98e8664e157aff0814a0f49895ee8223f382f'/>
<id>urn:sha1:24b98e8664e157aff0814a0f49895ee8223f382f</id>
<content type='text'>
commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq
has been set up") moved IRQ setup before the THRE test, in combination
with commit 205d300aea75 ("serial: 8250: change lock order in
serial8250_do_startup()") the interrupt handler can run during the
test and race with its IIR reads. This can produce wrong THRE test
results and cause spurious registration of the
serial8250_backup_timeout timer. Unconditionally disable the IRQ for
the short duration of the test and re-enable it afterwards to avoid
the race.

Fixes: 039d4926379b ("serial: 8250: Toggle IER bits on only after irq has been set up")
Depends-on: 205d300aea75 ("serial: 8250: change lock order in serial8250_do_startup()")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Peng Zhang &lt;zhangpeng.00@bytedance.com&gt;
Reviewed-by: Muchun Song &lt;songmuchun@bytedance.com&gt;
Signed-off-by: Alban Bedel &lt;alban.bedel@lht.dlh.de&gt;
Tested-by: Maximilian Lueer &lt;maximilian.lueer@lht.dlh.de&gt;
Link: https://patch.msgid.link/20260224121639.579404-1-alban.bedel@lht.dlh.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>treewide: Replace kmalloc with kmalloc_obj for non-scalar types</title>
<updated>2026-02-21T09:02:28Z</updated>
<author>
<name>Kees Cook</name>
<email>kees@kernel.org</email>
</author>
<published>2026-02-21T07:49:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=69050f8d6d075dc01af7a5f2f550a8067510366f'/>
<id>urn:sha1:69050f8d6d075dc01af7a5f2f550a8067510366f</id>
<content type='text'>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook &lt;kees@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: use guard()s</title>
<updated>2025-08-17T10:46:26Z</updated>
<author>
<name>Jiri Slaby (SUSE)</name>
<email>jirislaby@kernel.org</email>
</author>
<published>2025-08-14T07:24:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b339809edda15939e7d46b429c420c2bfe4ad946'/>
<id>urn:sha1:b339809edda15939e7d46b429c420c2bfe4ad946</id>
<content type='text'>
Having all the new guards, use them in the 8250 code. This improves
readability, makes error handling easier, and marks locked portions of
code explicit.

Signed-off-by: "Jiri Slaby (SUSE)" &lt;jirislaby@kernel.org&gt;
Link: https://lore.kernel.org/r/20250814072456.182853-10-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: introduce RPM guard()s</title>
<updated>2025-08-17T10:46:25Z</updated>
<author>
<name>Jiri Slaby (SUSE)</name>
<email>jirislaby@kernel.org</email>
</author>
<published>2025-08-14T07:24:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9f8da7b2f90cb5fb4c585d5e8aa89dfd724bd377'/>
<id>urn:sha1:9f8da7b2f90cb5fb4c585d5e8aa89dfd724bd377</id>
<content type='text'>
Having this, guards like these work:
  guard(serial8250_rpm)(up);
or
  scoped_guard(serial8250_rpm, up) {
    ...
  }

See e.g. "serial: 8250: use guard()s" later in this series.

And make them available to anyone (EXPORT + put in 8250.h) as drivers
open code this anyway.

The _tx ones are not defined as they would have no user.

Signed-off-by: "Jiri Slaby (SUSE)" &lt;jirislaby@kernel.org&gt;
Link: https://lore.kernel.org/r/20250814072456.182853-5-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: fix panic due to PSLVERR</title>
<updated>2025-07-24T09:40:41Z</updated>
<author>
<name>Yunhui Cui</name>
<email>cuiyunhui@bytedance.com</email>
</author>
<published>2025-07-23T02:33:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7f8fdd4dbffc05982b96caf586f77a014b2a9353'/>
<id>urn:sha1:7f8fdd4dbffc05982b96caf586f77a014b2a9353</id>
<content type='text'>
When the PSLVERR_RESP_EN parameter is set to 1, the device generates
an error response if an attempt is made to read an empty RBR (Receive
Buffer Register) while the FIFO is enabled.

In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,
UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes
dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter
function enables the FIFO via serial_out(p, UART_FCR, p-&gt;fcr).
Execution proceeds to the serial_port_in(port, UART_RX).
This satisfies the PSLVERR trigger condition.

When another CPU (e.g., using printk()) is accessing the UART (UART
is busy), the current CPU fails the check (value &amp; ~UART_LCR_SPAR) ==
(lcr &amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter
dw8250_force_idle().

Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-&gt;lock
to fix this issue.

Panic backtrace:
[    0.442336] Oops - unknown exception [#1]
[    0.442343] epc : dw8250_serial_in32+0x1e/0x4a
[    0.442351]  ra : serial8250_do_startup+0x2c8/0x88e
...
[    0.442416] console_on_rootfs+0x26/0x70

Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround")
Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/
Signed-off-by: Yunhui Cui &lt;cuiyunhui@bytedance.com&gt;
Reviewed-by: John Ogness &lt;john.ogness@linutronix.de&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: rename lsr_TEMT, iir_NOINT to lowercase</title>
<updated>2025-06-24T14:32:56Z</updated>
<author>
<name>Jiri Slaby (SUSE)</name>
<email>jirislaby@kernel.org</email>
</author>
<published>2025-06-24T08:06:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2721fc7adc923fb8d6ff55028e3e460ed93c1cb5'/>
<id>urn:sha1:2721fc7adc923fb8d6ff55028e3e460ed93c1cb5</id>
<content type='text'>
There are already variables like 'iir_noint1' and 'iir_noint2'. Follow
the preexisting lowercase naming of variables. So s/lsr_TEMT/lsr_temt/
and 'iir_NOINT' likewise.

Signed-off-by: "Jiri Slaby (SUSE)" &lt;jirislaby@kernel.org&gt;
Suggested-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20250624080641.509959-4-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
