<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/tty/serial/uartlite.c, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-25T10:08:49+00:00</updated>
<entry>
<title>serial: uartlite: fix PM runtime usage count underflow on probe</title>
<updated>2026-03-25T10:08:49+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=04d57b332e37ba0052c5062b3f86e871fee6e436'/>
<id>urn:sha1:04d57b332e37ba0052c5062b3f86e871fee6e436</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>tty: serial: uartlite: register uart driver in init</title>
<updated>2025-07-06T09:01:35+00:00</updated>
<author>
<name>Jakub Lewalski</name>
<email>jakub.lewalski@nokia.com</email>
</author>
<published>2025-03-31T16:06:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=685d29f2c5057b32c7b1b46f2a7d303b926c8f72'/>
<id>urn:sha1:685d29f2c5057b32c7b1b46f2a7d303b926c8f72</id>
<content type='text'>
[ Upstream commit 6bd697b5fc39fd24e2aa418c7b7d14469f550a93 ]

When two instances of uart devices are probing, a concurrency race can
occur. If one thread calls uart_register_driver function, which first
allocates and assigns memory to 'uart_state' member of uart_driver
structure, the other instance can bypass uart driver registration and
call ulite_assign. This calls uart_add_one_port, which expects the uart
driver to be fully initialized. This leads to a kernel panic due to a
null pointer dereference:

[    8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8
[    8.156982] #PF: supervisor write access in kernel mode
[    8.156984] #PF: error_code(0x0002) - not-present page
[    8.156986] PGD 0 P4D 0
...
[    8.180668] RIP: 0010:mutex_lock+0x19/0x30
[    8.188624] Call Trace:
[    8.188629]  ? __die_body.cold+0x1a/0x1f
[    8.195260]  ? page_fault_oops+0x15c/0x290
[    8.209183]  ? __irq_resolve_mapping+0x47/0x80
[    8.209187]  ? exc_page_fault+0x64/0x140
[    8.209190]  ? asm_exc_page_fault+0x22/0x30
[    8.209196]  ? mutex_lock+0x19/0x30
[    8.223116]  uart_add_one_port+0x60/0x440
[    8.223122]  ? proc_tty_register_driver+0x43/0x50
[    8.223126]  ? tty_register_driver+0x1ca/0x1e0
[    8.246250]  ulite_probe+0x357/0x4b0 [uartlite]

To prevent it, move uart driver registration in to init function. This
will ensure that uart_driver is always registered when probe function
is called.

Signed-off-by: Jakub Lewalski &lt;jakub.lewalski@nokia.com&gt;
Signed-off-by: Elodie Decerle &lt;elodie.decerle@nokia.com&gt;
Link: https://lore.kernel.org/r/20250331160732.2042-1-elodie.decerle@nokia.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: switch from circ_buf to kfifo</title>
<updated>2024-04-09T13:28:03+00:00</updated>
<author>
<name>Jiri Slaby (SUSE)</name>
<email>jirislaby@kernel.org</email>
</author>
<published>2024-04-05T06:08:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1788cf6a91d9fa9aa61fc2917afe192c23d67f6a'/>
<id>urn:sha1:1788cf6a91d9fa9aa61fc2917afe192c23d67f6a</id>
<content type='text'>
Switch from struct circ_buf to proper kfifo. kfifo provides much better
API, esp. when wrap-around of the buffer needs to be taken into account.
Look at pl011_dma_tx_refill() or cpm_uart_tx_pump() changes for example.

Kfifo API can also fill in scatter-gather DMA structures, so it easier
for that use case too. Look at lpuart_dma_tx() for example. Note that
not all drivers can be converted to that (like atmel_serial), they
handle DMA specially.

Note that usb-serial uses kfifo for TX for ages.

omap needed a bit more care as it needs to put a char into FIFO to start
the DMA transfer when OMAP_DMA_TX_KICK is set. In that case, we have to
do kfifo_dma_out_prepare twice: once to find out the tx_size (to find
out if it is worths to do DMA at all -- size &gt;= 4), the second time for
the actual transfer.

All traces of circ_buf are removed from serial_core.h (and its struct
uart_state).

Signed-off-by: Jiri Slaby (SUSE) &lt;jirislaby@kernel.org&gt;
Cc: Al Cooper &lt;alcooperx@gmail.com&gt;
Cc: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Cc: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Cc: Kumaravel Thiagarajan &lt;kumaravel.thiagarajan@microchip.com&gt;
Cc: Tharun Kumar P &lt;tharunkumar.pasumarthi@microchip.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Vineet Gupta &lt;vgupta@kernel.org&gt;
Cc: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Cc: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Cc: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: Claudiu Beznea &lt;claudiu.beznea@tuxon.dev&gt;
Cc: Alexander Shiyan &lt;shc_work@mail.ru&gt;
Cc: Baruch Siach &lt;baruch@tkos.co.il&gt;
Cc: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Cc: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Cc: Kevin Hilman &lt;khilman@baylibre.com&gt;
Cc: Jerome Brunet &lt;jbrunet@baylibre.com&gt;
Cc: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Cc: Taichi Sugaya &lt;sugaya.taichi@socionext.com&gt;
Cc: Takao Orito &lt;orito.takao@socionext.com&gt;
Cc: Bjorn Andersson &lt;andersson@kernel.org&gt;
Cc: Konrad Dybcio &lt;konrad.dybcio@linaro.org&gt;
Cc: Pali Rohár &lt;pali@kernel.org&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Cc: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Cc: Aneesh Kumar K.V &lt;aneesh.kumar@kernel.org&gt;
Cc: Naveen N. Rao &lt;naveen.n.rao@linux.ibm.com&gt;
Cc: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Cc: Krzysztof Kozlowski &lt;krzysztof.kozlowski@linaro.org&gt;
Cc: Alim Akhtar &lt;alim.akhtar@samsung.com&gt;
Cc: Laxman Dewangan &lt;ldewangan@nvidia.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Cc: Jonathan Hunter &lt;jonathanh@nvidia.com&gt;
Cc: Orson Zhai &lt;orsonzhai@gmail.com&gt;
Cc: Baolin Wang &lt;baolin.wang@linux.alibaba.com&gt;
Cc: Chunyan Zhang &lt;zhang.lyra@gmail.com&gt;
Cc: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt;
Cc: Maxime Coquelin &lt;mcoquelin.stm32@gmail.com&gt;
Cc: Alexandre Torgue &lt;alexandre.torgue@foss.st.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Hammer Hsieh &lt;hammerh0314@gmail.com&gt;
Cc: Peter Korsgaard &lt;jacmet@sunsite.dk&gt;
Cc: Timur Tabi &lt;timur@kernel.org&gt;
Cc: Michal Simek &lt;michal.simek@amd.com&gt;
Cc: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Link: https://lore.kernel.org/r/20240405060826.2521-13-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: uartlite: Use dynamic allocation for major number when uart ports &gt; 4</title>
<updated>2023-11-25T07:23:16+00:00</updated>
<author>
<name>Manikanta Guntupalli</name>
<email>manikanta.guntupalli@amd.com</email>
</author>
<published>2023-11-16T13:40:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=01c33b813864ca15a9dec22045ce1a5bb09d5e74'/>
<id>urn:sha1:01c33b813864ca15a9dec22045ce1a5bb09d5e74</id>
<content type='text'>
Device number 204 has a range of minors on major number.
uart_register_driver is failing due to lack of minor numbers
when more number of uart ports used. So, to avoid minor number
limitation on 204 major number use dynamic major allocation
when more than 4 uart ports used otherwise use static major
allocation.

https://docs.kernel.org/arch/arm/sa1100/serial_uart.html

Signed-off-by: Manikanta Guntupalli &lt;manikanta.guntupalli@amd.com&gt;
Link: https://lore.kernel.org/r/20231116134003.3762725-3-manikanta.guntupalli@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: serial: uartlite: Document uartlite_data in kernel-doc style</title>
<updated>2023-11-23T19:22:07+00:00</updated>
<author>
<name>Sean Anderson</name>
<email>sean.anderson@seco.com</email>
</author>
<published>2023-11-06T15:24:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dd6ffc9c57f69c2708f7c14dd7da5901b7d24b98'/>
<id>urn:sha1:dd6ffc9c57f69c2708f7c14dd7da5901b7d24b98</id>
<content type='text'>
Use @ and - to conform with kernel-doc style.

Reported-by: kernel test robot &lt;yujie.liu@intel.com&gt;
Signed-off-by: Sean Anderson &lt;sean.anderson@seco.com&gt;
Reviewed-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reviewed-by: Shubhrajyoti Datta &lt;shubhrajyoti.datta@amd.com&gt;
Link: https://lore.kernel.org/r/20231106152428.3641883-1-sean.anderson@seco.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: uartlite: Convert to platform remove callback returning void</title>
<updated>2023-11-23T19:12:35+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2023-11-10T15:30:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a0e8be950b9f945e526c600f9e6f4d265752497'/>
<id>urn:sha1:2a0e8be950b9f945e526c600f9e6f4d265752497</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20231110152927.70601-51-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: uartlite: Use port lock wrappers</title>
<updated>2023-09-18T09:18:16+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2023-09-14T18:38:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=de71068b6a06788dd179136f43d2d873e6fd14a9'/>
<id>urn:sha1:de71068b6a06788dd179136f43d2d873e6fd14a9</id>
<content type='text'>
When a serial port is used for kernel console output, then all
modifications to the UART registers which are done from other contexts,
e.g. getty, termios, are interference points for the kernel console.

So far this has been ignored and the printk output is based on the
principle of hope. The rework of the console infrastructure which aims to
support threaded and atomic consoles, requires to mark sections which
modify the UART registers as unsafe. This allows the atomic write function
to make informed decisions and eventually to restore operational state. It
also allows to prevent the regular UART code from modifying UART registers
while printk output is in progress.

All modifications of UART registers are guarded by the UART port lock,
which provides an obvious synchronization point with the console
infrastructure.

To avoid adding this functionality to all UART drivers, wrap the
spin_[un]lock*() invocations for uart_port::lock into helper functions
which just contain the spin_[un]lock*() invocations for now. In a
subsequent step these helpers will gain the console synchronization
mechanisms.

Converted with coccinelle. No functional change.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Ogness &lt;john.ogness@linutronix.de&gt;
Link: https://lore.kernel.org/r/20230914183831.587273-72-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: Explicitly include correct DT includes</title>
<updated>2023-07-25T18:19:05+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2023-07-24T20:54:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29e5c442e553cea180682d54ac0e2e95250fa668'/>
<id>urn:sha1:29e5c442e553cea180682d54ac0e2e95250fa668</id>
<content type='text'>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt; # for imx
Link: https://lore.kernel.org/r/20230724205440.767071-1-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: Make uart_remove_one_port() return void</title>
<updated>2023-05-13T10:48:16+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2023-05-12T17:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d5b3d02d0b107345f2a6ecb5b06f98356f5c97ab'/>
<id>urn:sha1:d5b3d02d0b107345f2a6ecb5b06f98356f5c97ab</id>
<content type='text'>
The return value is only ever used as a return value for remove callbacks
of platform drivers. This return value is ignored by the driver core.
(The only effect is an error message, but uart_remove_one_port() already
emitted one in this case.)

So the return value isn't used at all and uart_remove_one_port() can be
changed to return void without any loss. Also this better matches the
Linux device model as remove functions are not supposed to fail.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20230512173810.131447-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: uartlite: Use uart_xmit_advance()</title>
<updated>2022-11-03T02:35:43+00:00</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2022-10-19T09:11:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=852322ff4f2be566b0165a1f9c2adfcc0a86f8b6'/>
<id>urn:sha1:852322ff4f2be566b0165a1f9c2adfcc0a86f8b6</id>
<content type='text'>
Take advantage of the new uart_xmit_advance() helper.

Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20221019091151.6692-42-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
