* [PATCH 37/37] PCI/MSI: Only check is_msi_managed in pcim_setup_msi_release()
From: Shawn Lin @ 2026-02-23 15:29 UTC (permalink / raw)
To: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc, Shawn Lin
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
The function pcim_enable_device() sets the is_managed flag, which
causes the device's IRQ vectors to be automatically managed and released
by the devres framework. If a driver subsequently calls
pci_free_irq_vectors() manually, it can lead to a double-free of the
interrupt resources.
Analysis reveals most PCI drivers call pci_free_irq_vectors()
while also using pcim_enable_device(), making them susceptible to this
double-free issue. In contrast, 35 drivers follow the pattern of
relying on devres to handle the cleanup.
To address this inconsistency and enforce explicit, driver-managed
control of IRQ vectors, this patch removes the pci_is_managed() check
from pcim_setup_msi_release() and let devres help cleanup if is_msi_managed
is true. This change ensures that interrupt vectors are not automatically
freed by the devres machinery when pcim_enable_device() is used, placing
the responsibility for their release squarely on the driver logic via
pci_free_irq_vectors(). If the driver need devres to help cleanup, newly added
pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() helpers could be used.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/pci/msi/msi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c
index 81d24a2..0727a0a 100644
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -70,7 +70,6 @@ static void pcim_msi_release(void *pcidev)
{
struct pci_dev *dev = pcidev;
- dev->is_msi_managed = false;
pci_free_irq_vectors(dev);
}
@@ -92,14 +91,13 @@ static int pcim_setup_msi_release(struct pci_dev *dev)
{
int ret;
- if (!pci_is_managed(dev) || dev->is_msi_managed)
+ if (!dev->is_msi_managed)
return 0;
ret = devm_add_action(&dev->dev, pcim_msi_release, dev);
if (ret)
return ret;
- dev->is_msi_managed = true;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 14/37] serial: 8250_mid: Replace pci_alloc_irq_vectors() with pcim_alloc_irq_vectors()
From: Shawn Lin @ 2026-02-23 15:49 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-serial, Bjorn Helgaas, Philipp Stanner, linux-pci,
Shawn Lin
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
pcim_enable_device() no longer automatically manages IRQ vectors via devres.
Drivers must now manually call pci_free_irq_vectors() for cleanup. Alternatively,
pcim_alloc_irq_vectors() should be used.
To: Andy Shevchenko <andy@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-serial@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: linux-pci@vger.kernel.org
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/tty/serial/8250/8250_mid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_mid.c b/drivers/tty/serial/8250/8250_mid.c
index 8ec0386..3ad9213 100644
--- a/drivers/tty/serial/8250/8250_mid.c
+++ b/drivers/tty/serial/8250/8250_mid.c
@@ -172,7 +172,7 @@ static int dnv_setup(struct mid8250 *mid, struct uart_port *p)
pci_set_master(pdev);
- ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
+ ret = pcim_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
if (ret < 0)
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Shawn Lin @ 2026-02-23 15:29 UTC (permalink / raw)
To: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc, Shawn Lin
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
pci device drivers which rely on the devres machinery to help cleanup the IRQ
vectors.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/pci/msi/api.c | 26 ++++++++++++++++++++++++++
include/linux/pci.h | 22 ++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c
index c18559b..2362fca 100644
--- a/drivers/pci/msi/api.c
+++ b/drivers/pci/msi/api.c
@@ -297,6 +297,32 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity);
/**
+ * pcim_alloc_irq_vectors() - devres managed pci_alloc_irq_vectors()
+ * Interrupt vectors are automatically freed by the devres machinery
+ */
+int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags)
+{
+ return pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, NULL);
+}
+EXPORT_SYMBOL(pcim_alloc_irq_vectors);
+
+/**
+ * pcim_alloc_irq_vectors_affinity() - devres managed pci_alloc_irq_vectors_affinity()
+ * Interrupt vectors are automatically freed by the devres machinery
+ */
+int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags,
+ struct irq_affinity *affd)
+{
+ dev->is_msi_managed = true;
+ return pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, affd);
+}
+EXPORT_SYMBOL(pcim_alloc_irq_vectors_affinity);
+
+/**
* pci_irq_vector() - Get Linux IRQ number of a device interrupt vector
* @dev: the PCI device to operate on
* @nr: device-relative interrupt vector index (0-based); has different
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d5ec0f8..ae58f70 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1764,6 +1764,12 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
unsigned int max_vecs, unsigned int flags,
struct irq_affinity *affd);
+int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags);
+int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags,
+ struct irq_affinity *affd);
+
bool pci_msix_can_alloc_dyn(struct pci_dev *dev);
struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,
const struct irq_affinity_desc *affdesc);
@@ -1806,6 +1812,22 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
flags, NULL);
}
+static inline int
+pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags,
+ struct irq_affinity *aff_desc)
+{
+ return pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, aff_desc);
+}
+static inline int
+pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags)
+{
+ return pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, NULL);
+}
+
static inline bool pci_msix_can_alloc_dyn(struct pci_dev *dev)
{ return false; }
static inline struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,
--
2.7.4
^ permalink raw reply related
* [PATCH] serial: 8250_fintek: Add support for F81214E
From: Ravindra Rama @ 2026-02-23 20:40 UTC (permalink / raw)
To: gregkh, jirislaby; +Cc: linux-serial, linux-kernel
The F81214E is a LPC/eSPI to 2 UART Super I/O chip.
Functionally, it is the same as the F81216E. The only difference
is that the F81216E has 4 UART ports, whereas the F81214E has 2
UART ports.
Signed-off-by: Ravi Rama <ravi.rama@nexthop.ai>
---
drivers/tty/serial/8250/8250_fintek.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_fintek.c
b/drivers/tty/serial/8250/8250_fintek.c
index b4461a89b8d0..976c5748905c 100644
--- a/drivers/tty/serial/8250/8250_fintek.c
+++ b/drivers/tty/serial/8250/8250_fintek.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Probe for F81216A LPC to 4 UART
+ * Probe for F81216A LPC to 4 UART and F81214E LPC/eSPI to 2 UART
*
* Copyright (C) 2014-2016 Ricardo Ribalda, Qtechnology A/S
*/
@@ -23,6 +23,7 @@
#define CHIP_ID_F81216AD 0x1602
#define CHIP_ID_F81216E 0x1617
#define CHIP_ID_F81216H 0x0501
+#define CHIP_ID_F81214E 0x1417
#define CHIP_ID_F81216 0x0802
#define VENDOR_ID1 0x23
#define VENDOR_ID1_VAL 0x19
@@ -161,6 +162,7 @@ static int fintek_8250_check_id(struct fintek_8250 *pdata)
case CHIP_ID_F81216AD:
case CHIP_ID_F81216E:
case CHIP_ID_F81216H:
+ case CHIP_ID_F81214E:
case CHIP_ID_F81216:
break;
default:
@@ -185,6 +187,7 @@ static int fintek_8250_get_ldn_range(struct
fintek_8250 *pdata, int *min,
case CHIP_ID_F81216AD:
case CHIP_ID_F81216E:
case CHIP_ID_F81216H:
+ case CHIP_ID_F81214E:
case CHIP_ID_F81216:
*min = F81216_LDN_LOW;
*max = F81216_LDN_HIGH;
@@ -255,6 +258,7 @@ static void fintek_8250_set_irq_mode(struct
fintek_8250 *pdata, bool is_level)
case CHIP_ID_F81216AD:
case CHIP_ID_F81216E:
case CHIP_ID_F81216H:
+ case CHIP_ID_F81214E:
case CHIP_ID_F81216:
sio_write_mask_reg(pdata, FINTEK_IRQ_MODE, IRQ_SHARE,
IRQ_SHARE);
@@ -269,6 +273,7 @@ static void fintek_8250_set_max_fifo(struct
fintek_8250 *pdata)
switch (pdata->pid) {
case CHIP_ID_F81216E: /* 128Bytes FIFO */
case CHIP_ID_F81216H:
+ case CHIP_ID_F81214E:
case CHIP_ID_F81966:
case CHIP_ID_F81866:
sio_write_mask_reg(pdata, FIFO_CTRL,
@@ -304,6 +309,7 @@ static void fintek_8250_set_termios(struct uart_port *port,
switch (pdata->pid) {
case CHIP_ID_F81216E:
case CHIP_ID_F81216H:
+ case CHIP_ID_F81214E:
reg = RS485;
break;
case CHIP_ID_F81966:
@@ -354,6 +360,7 @@ static void fintek_8250_set_termios_handler(struct
uart_8250_port *uart)
switch (pdata->pid) {
case CHIP_ID_F81216E:
case CHIP_ID_F81216H:
+ case CHIP_ID_F81214E:
case CHIP_ID_F81966:
case CHIP_ID_F81866:
uart->port.set_termios = fintek_8250_set_termios;
@@ -446,6 +453,7 @@ static void fintek_8250_set_rs485_handler(struct
uart_8250_port *uart)
break;
case CHIP_ID_F81216E: /* F81216E does not support RS485 delays */
+ case CHIP_ID_F81214E: /* F81214E does not support RS485 delays */
uart->port.rs485_config = fintek_8250_rs485_config;
uart->port.rs485_supported = fintek_8250_rs485_supported;
break;
--
2.50.1
^ permalink raw reply related
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Andy Shevchenko @ 2026-02-23 17:38 UTC (permalink / raw)
To: Shawn Lin
Cc: Andy Shevchenko, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Jan Dabros, linux-i2c, Daniel Mack,
Haojian Zhuang, linux-spi, Jonathan Derrick, linux-pci,
linux-gpio, Mauro Carvalho Chehab, linux-media, linux-mmc
In-Reply-To: <cb878741-7b61-b72c-5a72-6ed6d5091b1f@rock-chips.com>
On Tue, Feb 24, 2026 at 12:09:37AM +0800, Shawn Lin wrote:
> 在 2026/02/23 星期一 23:50, Andy Shevchenko 写道:
> > On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
> > >
> > > This patch series addresses a long-standing design issue in the PCI/MSI
> > > subsystem where the implicit, automatic management of IRQ vectors by
> > > the devres framework conflicts with explicit driver cleanup, creating
> > > ambiguity and potential resource management bugs.
> > >
> > > ==== The Problem: Implicit vs. Explicit Management ====
> > > Historically, `pcim_enable_device()` not only manages standard PCI resources
> > > (BARs) via devres but also implicitly triggers automatic IRQ vector management
> > > by setting a flag that registers `pcim_msi_release()` as a cleanup action.
> > >
> > > This creates an ambiguous ownership model. Many drivers follow a pattern of:
> > > 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
> > > 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
> > >
> > > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > > attempt to free the IRQ vectors a second time upon device release, leading to
> > > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > > while 35 other drivers correctly rely solely on the implicit cleanup.
> >
> > Is this confirmed? What I read from the cover letter, this series was
> > only compile-tested, so how can you prove the problem exists in the
> > first place?
>
> Yes, it's confirmed. My debug of a double free issue of a out-of-tree
> PCIe wifi driver which uses
> pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose
> it. And we did have a TODO to cleanup this hybrid usage, targeted in
> this cycle[1] suggested by Philipp:
Okay, fair enough. I think this bit was missing in the cover letter.
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi
> > > ==== The Solution: Making Management Explicit ====
> > > This series enforces a clear, predictable model:
> > > 1. New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
> > > pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
> > > vectors should use these functions, which set the is_msi_managed flag and
> > > ensure automatic cleanup.
> > > 2. Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
> > > pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
> > > make an explicit call to pcim_alloc_irq_vectors().
> > > 3. Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
> > > to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
> > > pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
> > > are now solely the driver's responsibility to free with pci_free_irq_vectors().
> > >
> > > With these changes, we clear ownership model: Explicit resource management eliminates
> > > ambiguity and follows the "principle of least surprise." New drivers choose one model and
> > > be consistent.
> > > - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
> > > - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
> >
> > Have you checked previous attempts? Why is your series better than those?
>
> There seems not previous attempts.
Maybe we are looking to the different projects...
https://lore.kernel.org/all/?q=pcim_alloc_irq_vectors
> > > ==== Testing And Review ====
> > > 1. This series is only compiled test with allmodconfig.
> > > 2. Given the substantial size of this patch series, I have structured the mailing
> > > to facilitate efficient review. The cover letter, the first patch and the last one will be sent
> > > to all relevant mailing lists and key maintainers to ensure broad visibility and
> > > initial feedback on the overall approach. The remaining subsystem-specific patches
> > > will be sent only to the respective subsystem maintainers and their associated
> > > mailing lists, reducing noise.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Shawn Lin @ 2026-02-23 16:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: shawn.lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc
In-Reply-To: <CAHp75VeWD5A0r7-Uayyte1ZXXxdhLixd+z_y0xNeki0N+Ro=jQ@mail.gmail.com>
Hi Andy
在 2026/02/23 星期一 23:50, Andy Shevchenko 写道:
> On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>
>> This patch series addresses a long-standing design issue in the PCI/MSI
>> subsystem where the implicit, automatic management of IRQ vectors by
>> the devres framework conflicts with explicit driver cleanup, creating
>> ambiguity and potential resource management bugs.
>>
>> ==== The Problem: Implicit vs. Explicit Management ====
>> Historically, `pcim_enable_device()` not only manages standard PCI resources
>> (BARs) via devres but also implicitly triggers automatic IRQ vector management
>> by setting a flag that registers `pcim_msi_release()` as a cleanup action.
>>
>> This creates an ambiguous ownership model. Many drivers follow a pattern of:
>> 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
>> 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
>>
>> When such a driver also uses `pcim_enable_device()`, the devres framework may
>> attempt to free the IRQ vectors a second time upon device release, leading to
>> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
>> while 35 other drivers correctly rely solely on the implicit cleanup.
>
> Is this confirmed? What I read from the cover letter, this series was
> only compile-tested, so how can you prove the problem exists in the
> first place?
Yes, it's confirmed. My debug of a double free issue of a out-of-tree
PCIe wifi driver which uses
pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose
it. And we did have a TODO to cleanup this hybrid usage, targeted in
this cycle[1] suggested by Philipp:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi
>
>> ==== The Solution: Making Management Explicit ====
>> This series enforces a clear, predictable model:
>> 1. New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
>> pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
>> vectors should use these functions, which set the is_msi_managed flag and
>> ensure automatic cleanup.
>> 2. Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
>> pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
>> make an explicit call to pcim_alloc_irq_vectors().
>> 3. Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
>> to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
>> pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
>> are now solely the driver's responsibility to free with pci_free_irq_vectors().
>>
>> With these changes, we clear ownership model: Explicit resource management eliminates
>> ambiguity and follows the "principle of least surprise." New drivers choose one model and
>> be consistent.
>> - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
>> - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
>
> Have you checked previous attempts? Why is your series better than those?
There seems not previous attempts.
>
>> ==== Testing And Review ====
>> 1. This series is only compiled test with allmodconfig.
>> 2. Given the substantial size of this patch series, I have structured the mailing
>> to facilitate efficient review. The cover letter, the first patch and the last one will be sent
>> to all relevant mailing lists and key maintainers to ensure broad visibility and
>> initial feedback on the overall approach. The remaining subsystem-specific patches
>> will be sent only to the respective subsystem maintainers and their associated
>> mailing lists, reducing noise.
>
^ permalink raw reply
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Andy Shevchenko @ 2026-02-23 15:50 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson, Arnd Bergmann, Benjamin Tissoires,
linux-input, linux-i3c, dmaengine, Philipp Stanner, netdev,
nic_swsd, linux-arm-msm, dri-devel, linux-usb, iommu, linux-riscv,
David Airlie, Simona Vetter, linux-cxl, linux-crypto,
platform-driver-x86, linux-serial, mhi, Andy Shevchenko,
Jan Dabros, linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
>
> This patch series addresses a long-standing design issue in the PCI/MSI
> subsystem where the implicit, automatic management of IRQ vectors by
> the devres framework conflicts with explicit driver cleanup, creating
> ambiguity and potential resource management bugs.
>
> ==== The Problem: Implicit vs. Explicit Management ====
> Historically, `pcim_enable_device()` not only manages standard PCI resources
> (BARs) via devres but also implicitly triggers automatic IRQ vector management
> by setting a flag that registers `pcim_msi_release()` as a cleanup action.
>
> This creates an ambiguous ownership model. Many drivers follow a pattern of:
> 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
> 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
>
> When such a driver also uses `pcim_enable_device()`, the devres framework may
> attempt to free the IRQ vectors a second time upon device release, leading to
> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> while 35 other drivers correctly rely solely on the implicit cleanup.
Is this confirmed? What I read from the cover letter, this series was
only compile-tested, so how can you prove the problem exists in the
first place?
> ==== The Solution: Making Management Explicit ====
> This series enforces a clear, predictable model:
> 1. New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
> pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
> vectors should use these functions, which set the is_msi_managed flag and
> ensure automatic cleanup.
> 2. Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
> pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
> make an explicit call to pcim_alloc_irq_vectors().
> 3. Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
> to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
> pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
> are now solely the driver's responsibility to free with pci_free_irq_vectors().
>
> With these changes, we clear ownership model: Explicit resource management eliminates
> ambiguity and follows the "principle of least surprise." New drivers choose one model and
> be consistent.
> - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
> - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
Have you checked previous attempts? Why is your series better than those?
> ==== Testing And Review ====
> 1. This series is only compiled test with allmodconfig.
> 2. Given the substantial size of this patch series, I have structured the mailing
> to facilitate efficient review. The cover letter, the first patch and the last one will be sent
> to all relevant mailing lists and key maintainers to ensure broad visibility and
> initial feedback on the overall approach. The remaining subsystem-specific patches
> will be sent only to the respective subsystem maintainers and their associated
> mailing lists, reducing noise.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 15/37] serial: 8250_exar: Replace pci_alloc_irq_vectors() with pcim_alloc_irq_vectors()
From: Shawn Lin @ 2026-02-23 15:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-serial, Bjorn Helgaas, Philipp Stanner, linux-pci,
Shawn Lin
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
pcim_enable_device() no longer automatically manages IRQ vectors via devres.
Drivers must now manually call pci_free_irq_vectors() for cleanup. Alternatively,
pcim_alloc_irq_vectors() should be used.
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-serial@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: linux-pci@vger.kernel.org
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/tty/serial/8250/8250_exar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index c682c0d..bde4d3a 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -1478,7 +1478,7 @@ exar_pci_probe(struct pci_dev *pcidev, const struct pci_device_id *ent)
pci_set_master(pcidev);
- rc = pci_alloc_irq_vectors(pcidev, 1, 1, PCI_IRQ_ALL_TYPES);
+ rc = pcim_alloc_irq_vectors(pcidev, 1, 1, PCI_IRQ_ALL_TYPES);
if (rc < 0)
return rc;
--
2.7.4
^ permalink raw reply related
* [PATCH] serial: pic32_uart: allow driver to be compiled on all architectures with COMPILE_TEST
From: Brian Masney @ 2026-02-22 23:29 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-kernel, linux-serial, Brian Masney
This driver currently only supports builds against a PIC32 target, or
with COMPILE_TEST on MIPS. Now that commit 24cad1a22848 ("serial:
pic32_uart: update include to use pic32.h from platform_data") is
merged, it's possible to compile this driver on other architectures.
To avoid future breakage of this driver in the future, let's update the
Kconfig so that it can be built with COMPILE_TEST enabled on all
architectures.
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
drivers/tty/serial/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index f86775cfdcc9eb2013006b28b630252bf7e947a2..69d9760da0efbd2388f28ebfa01050727b701140 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -803,7 +803,7 @@ config SERIAL_CPM_CONSOLE
config SERIAL_PIC32
tristate "Microchip PIC32 serial support"
- depends on MACH_PIC32 || (MIPS && COMPILE_TEST)
+ depends on MACH_PIC32 || COMPILE_TEST
select SERIAL_CORE
help
If you have a PIC32, this driver supports the serial ports.
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260222-serial-pic32-4bcd09d52983
Best regards,
--
Brian Masney <bmasney@redhat.com>
^ permalink raw reply related
* Re: [PATCH 00/19] printk cleanup - part 3
From: Marcos Paulo de Souza @ 2026-02-20 11:43 UTC (permalink / raw)
To: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Jiri Slaby, Breno Leitao, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Geert Uytterhoeven, Kees Cook, Tony Luck, Guilherme G. Piccoli,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Andreas Larsson, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Jacky Huang, Shan-Chun Hung,
Laurentiu Tudor
Cc: linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-0-21a291bcf197@suse.com>
On Sat, 2025-12-27 at 09:16 -0300, Marcos Paulo de Souza wrote:
> The parts 1 and 2 can be found here [1] and here[2].
>
> The changes proposed in this part 3 are mostly to clarify the usage
> of
> the interfaces for NBCON, and use the printk helpers more broadly.
> Besides it, it also introduces a new way to register consoles
> and drop thes the CON_ENABLED flag. It seems too much, but in reality
> the changes are not complex, and as the title says, it's basically a
> cleanup without changing the functional changes.
>
> This patchset includes a patch from part 2 that needed more work [3],
> as
> suggested by Petr Mladek.
>
> These changes were tested by reverting f79b163c4231
> ("Revert "serial: 8250: Switch to nbcon console""), and used qemu to
> test
> suspend/resume cycles, and everything worked as expected.
>
> PS: b4 --auto-to-cc added a bunch of people as CC, so I'm not sure if
> I should remove some or not, so I'm leaving the list as it is. If the
> patchset needs a v2, and you feel that you don't need to copied, just
> let me know.
>
> Thanks for checking the patches, and happy holidays!
>
> [1]:
> https://lore.kernel.org/lkml/20250226-printk-renaming-v1-0-0b878577f2e6@suse.com/#t
> [2]:
> https://lore.kernel.org/linux-serial/20251121-printk-cleanup-part2-v2-0-57b8b78647f4@suse.com/
> [3]:
> https://lore.kernel.org/linux-serial/aSgeqM3DWvR8-cMY@pathway.suse.cz/
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
> ---
> Marcos Paulo de Souza (19):
> printk/nbcon: Use an enum to specify the required callback in
> console_is_usable()
> printk: Introduce console_is_nbcon
> printk: Drop flags argument from console_is_usable
> printk: Reintroduce consoles_suspended global state
> printk: Add more context to suspend/resume functions
> printk: Introduce register_console_force
> drivers: netconsole: Migrate to register_console_force helper
> debug: debug_core: Migrate to register_console_force helper
> m68k: emu: nfcon.c: Migrate to register_console_force helper
> fs: pstore: platform: Migrate to register_console_force helper
> powerpc: kernel: udbg: Migrate to register_console_force helper
> sparc: kernel: btext: Migrate to register_console_force helper
> um: drivers: mconsole_kern.c: Migrate to register_console_force
> helper
> drivers: hwtracing: stm: console.c: Migrate to
> register_console_force helper
> drivers: tty: serial: mux.c: Migrate to register_console_force
> helper
> drivers: tty: serial: ma35d1_serial: Migrate to
> register_console_force helper
> drivers: tty: ehv_bytechan: Migrate to register_console_force
> helper
> drivers: braille: console: Drop CON_ENABLED console flag
> printk: Remove CON_ENABLED flag
>
> arch/m68k/emu/nfcon.c | 5 +-
> arch/powerpc/kernel/udbg.c | 4 +-
> arch/sparc/kernel/btext.c | 4 +-
> arch/um/drivers/mconsole_kern.c | 3 +-
> arch/um/kernel/kmsg_dump.c | 2 +-
> drivers/accessibility/braille/braille_console.c | 1 -
> drivers/hwtracing/stm/console.c | 4 +-
> drivers/net/netconsole.c | 13 +--
> drivers/tty/ehv_bytechan.c | 4 +-
> drivers/tty/serial/ma35d1_serial.c | 4 +-
> drivers/tty/serial/mux.c | 4 +-
> drivers/tty/tty_io.c | 6 +-
> fs/proc/consoles.c | 1 -
> fs/pstore/platform.c | 6 +-
> include/linux/console.h | 143
> +++++++++++++++++++-----
> kernel/debug/debug_core.c | 6 +-
> kernel/debug/kdb/kdb_io.c | 6 +-
> kernel/printk/nbcon.c | 17 +--
> kernel/printk/printk.c | 140 ++++++++++++--
> ---------
> 19 files changed, 230 insertions(+), 143 deletions(-)
This patchset, without the recent cleanup from Petr Mladek [1], has a
regression. I'll wait for it to be merged first before sending a new
version of this patchset. Thanks for all the reviews!
[1]:
https://lore.kernel.org/lkml/20260206165002.496724-1-pmladek@suse.com/
> ---
> base-commit: 93d65587479cfc97c0d7e41b5e8c6378ca681632
> change-id: 20251202-printk-cleanup-part3-ea116b11b3a6
>
> Best regards,
> --
> Marcos Paulo de Souza <mpdesouza@suse.com>
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: mediatek: add device-tree for Genio 720-EVK board
From: David Lechner @ 2026-02-20 0:09 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sean Wang
Cc: kernel, linux-kernel, linux-serial, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20251203-add-mediatek-genio-520-720-evk-v1-3-df794b2a30ae@collabora.com>
On 12/3/25 7:59 AM, Louis-Alexis Eyraud wrote:
> Add support for MediaTek MT8189 SoC and its variants, and a device-tree
> for the basic hardware enablement of the Genio 720-EVK board, based on
> MT8391 SoC.
>
> MT8391 SoC is a variant of MT8189 SoC with a difference for the Arm
> Cortex-A78 CPU core maximum frequency (2.6 Ghz for MT8391, 3 Ghz for
> MT8189). MT8391 hardware register maps are identical to MT8189.
>
> The Genio 720-EVK board has following features:
> - MT8391 SoC
> - MT6365 PMIC
Is MT6365 PMIC ...
> diff --git a/arch/arm64/boot/dts/mediatek/mt8391-genio-common.dtsi b/arch/arm64/boot/dts/mediatek/mt8391-genio-common.dtsi
> new file mode 100644
> index 0000000000000000000000000000000000000000..744641916952111a4b389cf6adbd27c429b6eff2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8391-genio-common.dtsi
> @@ -0,0 +1,555 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2025 Collabora Ltd.
> + * Author: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> + */
> +
> +#include "mt6359.dtsi"
... really 100% identical to MT6359 PMIC?
Asking because I'm working on this in U-Boot and would be helpful
to know that this is correct. Would probably be a good idea to mention
it in the commit message too to show this is intentional.
And I wonder if it would be a good idea to add a compatible with fallback
just to be sure.
&pmic {
compatible = "mediatek,mt6365", "mediatek,mt6359";
};
^ permalink raw reply
* Re: [PATCH 12/13] serial: linflexuart: Add DMA support
From: Dan Carpenter @ 2026-02-19 8:22 UTC (permalink / raw)
To: oe-kbuild, Larisa Grigore, gregkh, jirislaby, robh, krzk+dt,
conor+dt, sumit.semwal, christian.koenig, chester62515,
cosmin.stoica, adrian.nitu, stefan-gabriel.mirea,
Mihaela.Martinas
Cc: lkp, oe-kbuild-all, linux-kernel, linux-serial, devicetree,
linux-media, dri-devel, linaro-mm-sig, s32, imx, clizzi, aruizrui,
eballetb, echanude, jkangas, Larisa Grigore, Radu Pirea,
Phu Luu An, Js Ha, Ghennadi Procopciuc
In-Reply-To: <20260216150205.212318-13-larisa.grigore@oss.nxp.com>
Hi Larisa,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Larisa-Grigore/serial-linflexuart-Fix-locking-in-set_termios/20260216-231403
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
patch link: https://lore.kernel.org/r/20260216150205.212318-13-larisa.grigore%40oss.nxp.com
patch subject: [PATCH 12/13] serial: linflexuart: Add DMA support
config: i386-randconfig-141-20260217 (https://download.01.org/0day-ci/archive/20260217/202602171109.6YSFXcJ3-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
smatch version: v0.5.0-8994-gd50c5a4c
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202602171109.6YSFXcJ3-lkp@intel.com/
smatch warnings:
drivers/tty/serial/fsl_linflexuart.c:1441 linflex_probe() warn: missing unwind goto?
vim +1441 drivers/tty/serial/fsl_linflexuart.c
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1377 static int linflex_probe(struct platform_device *pdev)
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1378 {
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1379 struct device_node *np = pdev->dev.of_node;
1d3f5f07fafc71 Radu Pirea 2026-02-16 1380 struct linflex_port *lfport;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1381 struct uart_port *sport;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1382 struct resource *res;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1383 int ret;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1384
1d3f5f07fafc71 Radu Pirea 2026-02-16 1385 lfport = devm_kzalloc(&pdev->dev, sizeof(*lfport), GFP_KERNEL);
1d3f5f07fafc71 Radu Pirea 2026-02-16 1386 if (!lfport)
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1387 return -ENOMEM;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1388
1d3f5f07fafc71 Radu Pirea 2026-02-16 1389 sport = &lfport->port;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1390 sport->dev = &pdev->dev;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1391
0b34325c5f79f1 Larisa Grigore 2026-02-16 1392 lfport->dma_tx_chan = dma_request_chan(sport->dev, "tx");
0b34325c5f79f1 Larisa Grigore 2026-02-16 1393 if (IS_ERR(lfport->dma_tx_chan)) {
0b34325c5f79f1 Larisa Grigore 2026-02-16 1394 ret = PTR_ERR(lfport->dma_tx_chan);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1395 if (ret == -EPROBE_DEFER)
0b34325c5f79f1 Larisa Grigore 2026-02-16 1396 return ret;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1397
0b34325c5f79f1 Larisa Grigore 2026-02-16 1398 dev_info(sport->dev,
0b34325c5f79f1 Larisa Grigore 2026-02-16 1399 "DMA tx channel request failed, operating without tx DMA %ld\n",
0b34325c5f79f1 Larisa Grigore 2026-02-16 1400 PTR_ERR(lfport->dma_tx_chan));
0b34325c5f79f1 Larisa Grigore 2026-02-16 1401 lfport->dma_tx_chan = NULL;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1402 }
0b34325c5f79f1 Larisa Grigore 2026-02-16 1403
0b34325c5f79f1 Larisa Grigore 2026-02-16 1404 lfport->dma_rx_chan = dma_request_chan(sport->dev, "rx");
0b34325c5f79f1 Larisa Grigore 2026-02-16 1405 if (IS_ERR(lfport->dma_rx_chan)) {
0b34325c5f79f1 Larisa Grigore 2026-02-16 1406 ret = PTR_ERR(lfport->dma_rx_chan);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1407 if (ret == -EPROBE_DEFER) {
0b34325c5f79f1 Larisa Grigore 2026-02-16 1408 dma_release_channel(lfport->dma_tx_chan);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1409 return ret;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1410 }
0b34325c5f79f1 Larisa Grigore 2026-02-16 1411
0b34325c5f79f1 Larisa Grigore 2026-02-16 1412 dev_info(sport->dev,
0b34325c5f79f1 Larisa Grigore 2026-02-16 1413 "DMA rx channel request failed, operating without rx DMA %ld\n",
0b34325c5f79f1 Larisa Grigore 2026-02-16 1414 PTR_ERR(lfport->dma_rx_chan));
0b34325c5f79f1 Larisa Grigore 2026-02-16 1415 lfport->dma_rx_chan = NULL;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1416 }
1d3f5f07fafc71 Radu Pirea 2026-02-16 1417
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1418 ret = of_alias_get_id(np, "serial");
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1419 if (ret < 0) {
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1420 dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1421 goto linflex_probe_free_dma;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1422 }
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1423 if (ret >= UART_NR) {
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1424 dev_err(&pdev->dev, "driver limited to %d serial ports\n",
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1425 UART_NR);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1426 ret = -ENOMEM;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1427 goto linflex_probe_free_dma;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1428 }
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1429
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1430 sport->line = ret;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1431
8c6d7e5fd50b45 Yangtao Li 2023-07-12 1432 sport->membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1433 if (IS_ERR(sport->membase)) {
0b34325c5f79f1 Larisa Grigore 2026-02-16 1434 ret = PTR_ERR(sport->membase);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1435 goto linflex_probe_free_dma;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1436 }
8c6d7e5fd50b45 Yangtao Li 2023-07-12 1437 sport->mapbase = res->start;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1438
4e8da86fc1f767 Zhang Shurong 2023-08-26 1439 ret = platform_get_irq(pdev, 0);
4e8da86fc1f767 Zhang Shurong 2023-08-26 1440 if (ret < 0)
4e8da86fc1f767 Zhang Shurong 2023-08-26 @1441 return ret;
No clean up?
4e8da86fc1f767 Zhang Shurong 2023-08-26 1442
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1443 sport->iotype = UPIO_MEM;
4e8da86fc1f767 Zhang Shurong 2023-08-26 1444 sport->irq = ret;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1445 sport->ops = &linflex_pops;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1446 sport->flags = UPF_BOOT_AUTOCONF;
4151bbed79f98b Dmitry Safonov 2019-12-13 1447 sport->has_sysrq = IS_ENABLED(CONFIG_SERIAL_FSL_LINFLEXUART_CONSOLE);
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1448
1d3f5f07fafc71 Radu Pirea 2026-02-16 1449 ret = linflex_init_clk(lfport);
1d3f5f07fafc71 Radu Pirea 2026-02-16 1450 if (ret)
0b34325c5f79f1 Larisa Grigore 2026-02-16 1451 goto linflex_probe_free_dma;
1d3f5f07fafc71 Radu Pirea 2026-02-16 1452
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1453 linflex_ports[sport->line] = sport;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1454
1d3f5f07fafc71 Radu Pirea 2026-02-16 1455 platform_set_drvdata(pdev, lfport);
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1456
1d3f5f07fafc71 Radu Pirea 2026-02-16 1457 ret = uart_add_one_port(&linflex_reg, sport);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1458 if (ret) {
1d3f5f07fafc71 Radu Pirea 2026-02-16 1459 clk_bulk_disable_unprepare(LINFLEX_CLK_NUM, lfport->clks);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1460 goto linflex_probe_free_dma;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1461 }
0b34325c5f79f1 Larisa Grigore 2026-02-16 1462
0b34325c5f79f1 Larisa Grigore 2026-02-16 1463 return 0;
0b34325c5f79f1 Larisa Grigore 2026-02-16 1464
0b34325c5f79f1 Larisa Grigore 2026-02-16 1465 linflex_probe_free_dma:
0b34325c5f79f1 Larisa Grigore 2026-02-16 1466 if (lfport->dma_tx_chan)
0b34325c5f79f1 Larisa Grigore 2026-02-16 1467 dma_release_channel(lfport->dma_tx_chan);
0b34325c5f79f1 Larisa Grigore 2026-02-16 1468 if (lfport->dma_rx_chan)
0b34325c5f79f1 Larisa Grigore 2026-02-16 1469 dma_release_channel(lfport->dma_rx_chan);
1d3f5f07fafc71 Radu Pirea 2026-02-16 1470
1d3f5f07fafc71 Radu Pirea 2026-02-16 1471 return ret;
09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1472 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH AUTOSEL 6.19-5.10] serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done
From: Sasha Levin @ 2026-02-19 2:04 UTC (permalink / raw)
To: patches, stable
Cc: Moteen Shah, Greg Kroah-Hartman, Sasha Levin, jirislaby,
linux-kernel, linux-serial
In-Reply-To: <20260219020422.1539798-1-sashal@kernel.org>
From: Moteen Shah <m-shah@ti.com>
[ 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 <m-shah@ti.com>
Link: https://patch.msgid.link/20260112081829.63049-3-m-shah@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## 3. Classification
This is a **bug fix** — specifically a **state synchronization/race
condition fix** between software state and hardware state. The
`rx_running` flag was being cleared prematurely, before DMA hardware
teardown completed, creating a window where software and hardware states
were inconsistent.
## 4. Scope and Risk Assessment
- **Lines changed**: 2 lines — one line removed, one line added (just
moving `dma->rx_running = 0;`)
- **Files touched**: 1 file (drivers/tty/serial/8250/8250_omap.c)
- **Complexity**: Minimal — a single line is moved to a later position
in the same function
- **Risk**: Very low. The change only affects the timing of when
`rx_running` is cleared. The core logic is unchanged.
- **Potential concern**: The `count == 0` early return path (`goto out`)
now skips clearing `rx_running`, which could theoretically leave the
flag set. However, this is a minor edge case that likely doesn't occur
in practice (DMA completion with zero data transfer).
## 5. User Impact
- **Who is affected**: Users of OMAP SoC serial ports with DMA (TI
AM335x, AM437x, AM65x, etc.) — widely used in embedded/industrial
systems
- **Severity if triggered**: The state mismatch could cause:
- A new DMA being started while old hardware teardown is still in
progress
- Potential data corruption or missed serial data
- Possible DMA engine errors or hangs
- **Likelihood**: Moderate — this would occur when DMA teardown takes
time (in-flight bytes scenario) and another DMA operation is attempted
during the teardown window
## 6. Stability Indicators
- Author is from TI (SoC vendor) — deep knowledge of the hardware
- Reviewed by another TI engineer (Kumar, Udit)
- Accepted by Greg Kroah-Hartman (serial subsystem maintainer)
- Small, obviously correct fix with clear rationale
- Self-contained — no dependencies on other patches in the series
## 7. Stable Kernel Criteria Assessment
| Criterion | Met? |
|-----------|------|
| Obviously correct and tested | Yes — simple line movement, accepted by
maintainer |
| Fixes a real bug | Yes — software/hardware state mismatch |
| Fixes important issue | Yes — potential data corruption/DMA errors |
| Small and contained | Yes — 2 lines in 1 file |
| No new features | Correct — pure bug fix |
| No new APIs | Correct |
## Verification
- **Code analysis**: Read `__dma_rx_do_complete()` at lines 916-971 to
understand the full function flow and confirm the bug mechanism
(premature flag clearing before teardown polling)
- **Caller analysis**: Verified `__dma_rx_do_complete` is called from
`__dma_rx_complete` (line 991, DMA completion callback) and
`omap_8250_rx_dma_flush` (line 1022, flush path)
- **Lock analysis**: Verified that `__dma_rx_complete` does NOT hold
`rx_dma_lock` (only port lock at line 981), while
`omap_8250_rx_dma_flush` does hold `rx_dma_lock` (line 1009). This
confirms a real synchronization gap.
- **Race window**: After `__dma_rx_complete` calls
`__dma_rx_do_complete`, it calls `omap_8250_rx_dma(p)` at line 998,
which checks `rx_running`. With old code, `rx_running==0` was visible
during teardown polling.
- **Self-contained**: Verified patch 2/3 (623b07b370e99) modifies
different functions (`am654_8250_handle_rx_dma`,
`am654_8250_handle_uart_errors`) and does not conflict with or depend
on this patch
- **File history**: `8250_omap.c` DMA-RX callback added in commit
0e31c8d173ab1 (2014-09-29), present in all active stable trees
- **Mailing list**: Found the patch on lore.kernel.org, reviewed by
Kumar, Udit (TI), accepted by Greg KH
- **count==0 edge case**: Identified that with the patch, the `goto out`
for `count==0` skips clearing `rx_running`. This is a minor concern
but the count==0 case after DMA completion is unusual. This was NOT
verified to be problematic in practice (unverified edge case concern).
## Conclusion
This is a small, surgical, obviously correct fix for a real state
synchronization bug in the OMAP 8250 serial DMA path. The `rx_running`
flag was cleared too early, before hardware DMA teardown completed,
creating a window where software and hardware state were inconsistent.
This could lead to DMA conflicts, data corruption, or hangs on OMAP/AM
series SoCs which are widely used in embedded systems.
The fix is minimal (moving one line), self-contained, has no
dependencies, was written by the SoC vendor (TI), reviewed by another TI
engineer, and accepted by the serial subsystem maintainer. It meets all
stable kernel criteria.
**YES**
drivers/tty/serial/8250/8250_omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index e26bae0a6488f..272bc07c9a6b5 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -931,7 +931,6 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
goto out;
cookie = dma->rx_cookie;
- dma->rx_running = 0;
/* Re-enable RX FIFO interrupt now that transfer is complete */
if (priv->habit & UART_HAS_RHR_IT_DIS) {
@@ -965,6 +964,7 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
goto out;
ret = tty_insert_flip_string(tty_port, dma->rx_buf, count);
+ dma->rx_running = 0;
p->port.icount.rx += ret;
p->port.icount.buf_overrun += count - ret;
out:
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.12] serial: 8250: 8250_omap.c: Add support for handling UART error conditions
From: Sasha Levin @ 2026-02-19 2:03 UTC (permalink / raw)
To: patches, stable
Cc: Moteen Shah, Greg Kroah-Hartman, Sasha Levin, jirislaby,
linux-kernel, linux-serial
In-Reply-To: <20260219020422.1539798-1-sashal@kernel.org>
From: Moteen Shah <m-shah@ti.com>
[ Upstream commit 623b07b370e9963122d167e04fdc1dc713ebfbaf ]
The DMA IRQ handler does not accounts for the overrun(OE) or any other
errors being reported by the IP before triggering a DMA transaction which
leads to the interrupts not being handled resulting into an IRQ storm.
The way to handle OE is to:
1. Reset the RX FIFO.
2. Read the UART_RESUME register, which clears the internal flag
Earlier, the driver issued DMA transations even in case of OE which shouldn't
be done according to the OE handling mechanism mentioned above, as we are
resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During
Receive" [0].
[0] https://www.ti.com/lit/pdf/spruiu1
Signed-off-by: Moteen Shah <m-shah@ti.com>
Link: https://patch.msgid.link/20260112081829.63049-2-m-shah@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Detailed Analysis
### 1. What the commit fixes
The commit fixes an **IRQ storm** on TI K3/AM654 SoCs when a UART
overrun error (OE) occurs during DMA-based UART communication. The
existing `am654_8250_handle_rx_dma()` function did not handle UART error
conditions at all:
- When an overrun occurs, the UART sets `UART_LSR_OE` in the line status
register
- The existing code would try to start a DMA transaction despite the
overrun condition
- Without reading the UART_OMAP_RESUME register and resetting the FIFO,
the error interrupt flag stays set
- This causes an **interrupt storm** — the interrupt fires repeatedly
because it was never properly acknowledged/cleared
This is a known hardware behavior documented in the TI reference manual
section "12.1.6.4.8.1.3.6 Overrun During Receive."
### 2. Does it meet stable kernel rules?
**Obviously correct**: Yes. The fix follows the TI reference manual's
prescribed overrun handling: reset RX FIFO, then read the RESUME
register. The additional error handling for FE/PE/BI follows standard
UART error clearing practices.
**Fixes a real bug**: Yes. An IRQ storm is a serious hardware-triggered
bug that can lock up the system or make it unresponsive. This has been a
known class of problems on K3 SoCs (see prior commits `b67e830d38fa9`
and `c128a1b0523b6` that fixed similar IRQ storms from different
causes).
**Important issue**: Yes. IRQ storms can cause:
- 100% CPU consumption in interrupt context
- System hangs or unresponsiveness
- Potential soft lockups / hard lockups
**Small and contained**: The change adds ~15 lines of new error handling
code, modifies 2-3 lines in the existing function, and adds one register
define. All changes are confined to a single file and a single driver.
**No new features**: Despite the subject saying "Add support", this is
really fixing missing error handling in an existing IRQ handler. It
doesn't add new functionality; it properly handles error conditions that
were being ignored.
### 3. Risk vs Benefit
**Risk**: LOW
- Changes are confined to the AM654/K3 DMA RX path only (guarded by
`UART_HAS_EFR2` habit flag)
- The fix follows documented hardware procedures from TI's reference
manual
- The new `am654_8250_handle_uart_errors()` function is straightforward:
it clears error conditions by reading appropriate registers
- The condition `!(status & UART_LSR_OE)` prevents DMA on overrun, which
is the correct behavior per the hardware documentation
**Benefit**: HIGH
- Prevents IRQ storms on K3/AM654 SoCs when UART overrun or other error
conditions occur during DMA
- IRQ storms can make systems unusable
- This is particularly important for embedded/industrial use cases of
AM654 SoCs
### 4. Dependencies
- Patch 2/2 in a series, but patch 1 ("Clear DMA RX running status only
after DMA termination is done") appears independent
- The code depends on `serial8250_clear_and_reinit_fifos()` which has
existed since early 8250 driver code
- The `am654_8250_handle_rx_dma()` function exists since commit
`c26389f998a865` (v5.7 era), so it's present in all current stable
trees
- The `UART_OMAP_RESUME` register define is new but it's just a constant
(0x0B) — trivial
### 5. Concerns
The patch needs `UART_OMAP_RESUME` define which is added by this same
commit. This should apply cleanly as long as the define section hasn't
changed significantly. There may also be minor context conflicts due to
intermediate patches, but nothing fundamental.
The commit title "Add support for handling..." sounds like a feature
addition, but analysis shows it's a bug fix for missing error handling
that causes IRQ storms.
## Verification
- **git blame** confirmed `am654_8250_handle_rx_dma()` was introduced in
commit `c26389f998a865` (2020, v5.7 era) — present in all current
stable trees
- **git show `b67e830d38fa9`** confirmed prior IRQ storm fix on same K3
SoCs (2021), demonstrating this is a known class of bugs
- **git show `c128a1b0523b6`** confirmed another IRQ storm fix related
to Errata i2310 (2024), showing ongoing attention to this problem area
- **lore.kernel.org** confirmed this is patch 2/2, independent of patch
1 (cover letter describes separate issues)
- **Grep** confirmed `serial8250_clear_and_reinit_fifos` is declared in
`drivers/tty/serial/8250/8250.h` (available to the driver)
- **Grep** confirmed `UART_OMAP_RESUME` is not in the current codebase —
it's introduced by this patch as a new define (0x0B register offset)
- **Read** of current `am654_8250_handle_rx_dma()` confirmed there is no
error handling for OE/FE/PE/BI conditions — the bug exists
- **Unverified**: Whether stable trees 6.6.y or 6.1.y have any context
conflicts that would prevent clean backport (likely minor if any)
- Greg Kroah-Hartman signed off on the commit, confirming it went
through normal review
## Conclusion
This commit fixes a real, documented hardware bug (IRQ storm from
unhandled UART error conditions) on TI K3/AM654 SoCs. The fix is small,
contained, follows the hardware vendor's documented error handling
procedure, and addresses a serious issue (IRQ storms can make systems
unusable). The affected code (`am654_8250_handle_rx_dma`) has been in
stable trees since v5.7. This is consistent with the pattern of previous
IRQ storm fixes for this same hardware family (`b67e830d38fa9`,
`c128a1b0523b6`) that were both marked for stable backport.
**YES**
drivers/tty/serial/8250/8250_omap.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 9e49ef48b851b..e26bae0a6488f 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -100,6 +100,9 @@
#define OMAP_UART_REV_52 0x0502
#define OMAP_UART_REV_63 0x0603
+/* Resume register */
+#define UART_OMAP_RESUME 0x0B
+
/* Interrupt Enable Register 2 */
#define UART_OMAP_IER2 0x1B
#define UART_OMAP_IER2_RHR_IT_DIS BIT(2)
@@ -119,7 +122,6 @@
/* Timeout low and High */
#define UART_OMAP_TO_L 0x26
#define UART_OMAP_TO_H 0x27
-
struct omap8250_priv {
void __iomem *membase;
int line;
@@ -1256,6 +1258,20 @@ static u16 omap_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir, u16 status
return status;
}
+static void am654_8250_handle_uart_errors(struct uart_8250_port *up, u8 iir, u16 status)
+{
+ if (status & UART_LSR_OE) {
+ serial8250_clear_and_reinit_fifos(up);
+ serial_in(up, UART_LSR);
+ serial_in(up, UART_OMAP_RESUME);
+ } else {
+ if (status & (UART_LSR_FE | UART_LSR_PE | UART_LSR_BI))
+ serial_in(up, UART_RX);
+ if (iir & UART_IIR_XOFF)
+ serial_in(up, UART_IIR);
+ }
+}
+
static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
u16 status)
{
@@ -1266,7 +1282,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
* Queue a new transfer if FIFO has data.
*/
if ((status & (UART_LSR_DR | UART_LSR_BI)) &&
- (up->ier & UART_IER_RDI)) {
+ (up->ier & UART_IER_RDI) && !(status & UART_LSR_OE)) {
+ am654_8250_handle_uart_errors(up, iir, status);
omap_8250_rx_dma(up);
serial_out(up, UART_OMAP_EFR2, UART_OMAP_EFR2_TIMEOUT_BEHAVE);
} else if ((iir & 0x3f) == UART_IIR_RX_TIMEOUT) {
@@ -1282,6 +1299,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
serial_out(up, UART_OMAP_EFR2, 0x0);
up->ier |= UART_IER_RLSI | UART_IER_RDI;
serial_out(up, UART_IER, up->ier);
+ } else {
+ am654_8250_handle_uart_errors(up, iir, status);
}
}
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19] serial: rsci: Add set_rtrg() callback
From: Sasha Levin @ 2026-02-19 2:03 UTC (permalink / raw)
To: patches, stable
Cc: Biju Das, Lad Prabhakar, Greg Kroah-Hartman, Sasha Levin,
jirislaby, linux-kernel, linux-serial
In-Reply-To: <20260219020422.1539798-1-sashal@kernel.org>
From: Biju Das <biju.das.jz@bp.renesas.com>
[ Upstream commit b346e5d7dbf6696176417923c49838a1beb1d785 ]
The rtrg variable is populated in sci_init_single() for RZ/T2H. Add
set_rtrg() callback for setting the rtrg value.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/20251129164325.209213-4-biju.das.jz@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
`fifosize = 16`, so `fifosize > 1` is true, meaning the
`rx_fifo_trigger` sysfs attribute is also created. Both sysfs paths are
reachable and will cause NULL pointer dereferences without the
`set_rtrg` callback.
### Summary of Analysis
**What the commit does:** Adds a `set_rtrg()` callback to the RSCI
serial driver that programs the receive FIFO trigger level into the
hardware.
**What bug it fixes:** Without this callback, the `set_rtrg` function
pointer in `rsci_port_ops` is NULL. The shared SCI framework code in
`sh-sci.c` calls `s->ops->set_rtrg()` **without NULL checks** from
multiple paths:
1. **sysfs `rx_fifo_trigger` write** (line 1347): Created for RSCI
because `fifosize=16 > 1`. Writing to it calls NULL `set_rtrg` →
**kernel crash/panic**
2. **sysfs `rx_fifo_timeout` write** (line 1392): Explicitly created for
`SCI_PORT_RSCI` at line 3921-3922. Writing a non-zero value calls
NULL `set_rtrg` → **kernel crash/panic**
3. **Timer callback `rx_fifo_timer_fn`** (line 1322): Once a user writes
to `rx_fifo_timeout`, the timer is set up and will fire, calling NULL
`set_rtrg` → **kernel crash/panic**
4. **Interrupt handler path** (lines 1980-1982): If `rx_trigger > 1`
(it's 15 for RSCI) and `rx_fifo_timeout > 0`, the interrupt handler
calls NULL `rtrg_enabled` first → **kernel crash/panic**
The `rx_trigger` for RSCI is initialized to 15 (line 3333), and both
sysfs attributes are created, making these paths reachable from
userspace.
**Risk assessment:** LOW risk. The change adds a simple function that
reads a register, clamps a value, and writes it back. It only affects
the RSCI port type. The callback is registered in the existing ops
structure. No behavioral changes for any other port type.
**Scope:** Small - one new function (~15 lines) and one ops structure
entry.
**Stable criteria check:**
- Fixes a real bug: YES - NULL pointer dereference (kernel crash)
reachable from sysfs
- Obviously correct: YES - straightforward register read/modify/write
- Small and contained: YES - ~15 lines of new code, 1 file
- No new features: The function itself enables correct operation of
existing sysfs interfaces; the commit message frames it as "adding a
callback" but it's actually fixing a NULL pointer dereference
- Tested: YES - has "Tested-by:" tag
**Note:** The commit is also missing a `rtrg_enabled` callback, which is
also called without NULL check at line 1981. This commit only adds
`set_rtrg`, not `rtrg_enabled`. However, `set_rtrg` alone fixes the most
immediate crash paths (sysfs writes and timer). The `rtrg_enabled` path
at line 1981 would still be a problem but only if both `rx_trigger > 1`
AND `rx_fifo_timeout > 0`, which requires explicit user action to set
the timeout.
### Verification
- **Verified** that `SCI_PORT_RSCI` sets `rx_trigger = 15` at sh-
sci.c:3332-3333
- **Verified** that `rx_fifo_timeout` sysfs attribute is created for
`SCI_PORT_RSCI` at sh-sci.c:3921-3922
- **Verified** that `rx_fifo_trigger` sysfs attribute is created when
`fifosize > 1` at sh-sci.c:3916-3919 (RSCI fifosize=16 per rsci.c:420)
- **Verified** that `set_rtrg` is called without NULL checks at sh-sci.c
lines 1322, 1347, 1349, 1392, 1517, 1955, 1982, 2661, 2666, 2668
- **Verified** that `rtrg_enabled` is called without NULL check at sh-
sci.c:1981
- **Verified** that the RSCI `rsci_set_termios` at rsci.c:154-169 does
NOT call the shared `sci_set_termios` (lines 2673+) so the set_termios
path at lines 2659-2668 is not directly triggered for RSCI
- **Verified** that `rsci_port_ops` before this commit has no `set_rtrg`
callback (it was not listed in the pre-patch ops structure)
- **Could NOT verify** whether a separate commit adds `rtrg_enabled` for
RSCI (this commit only adds `set_rtrg`)
**YES**
drivers/tty/serial/rsci.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/tty/serial/rsci.c b/drivers/tty/serial/rsci.c
index b3c48dc1e07db..0533a4bb1d03c 100644
--- a/drivers/tty/serial/rsci.c
+++ b/drivers/tty/serial/rsci.c
@@ -151,6 +151,22 @@ static void rsci_start_rx(struct uart_port *port)
rsci_serial_out(port, CCR0, ctrl);
}
+static int rsci_scif_set_rtrg(struct uart_port *port, int rx_trig)
+{
+ u32 fcr = rsci_serial_in(port, FCR);
+
+ if (rx_trig >= port->fifosize)
+ rx_trig = port->fifosize - 1;
+ else if (rx_trig < 1)
+ rx_trig = 0;
+
+ fcr &= ~FCR_RTRG4_0;
+ fcr |= field_prep(FCR_RTRG4_0, rx_trig);
+ rsci_serial_out(port, FCR, fcr);
+
+ return rx_trig;
+}
+
static void rsci_set_termios(struct uart_port *port, struct ktermios *termios,
const struct ktermios *old)
{
@@ -454,6 +470,7 @@ static const struct sci_port_ops rsci_port_ops = {
.poll_put_char = rsci_poll_put_char,
.prepare_console_write = rsci_prepare_console_write,
.suspend_regs_size = rsci_suspend_regs_size,
+ .set_rtrg = rsci_scif_set_rtrg,
.shutdown_complete = rsci_shutdown_complete,
};
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-5.10] serial: 8250_dw: handle clock enable errors in runtime_resume
From: Sasha Levin @ 2026-02-19 2:03 UTC (permalink / raw)
To: patches, stable
Cc: Artem Shimko, Greg Kroah-Hartman, Sasha Levin, ilpo.jarvinen,
jirislaby, linux-kernel, linux-serial
In-Reply-To: <20260219020422.1539798-1-sashal@kernel.org>
From: Artem Shimko <a.shimko.dev@gmail.com>
[ 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 <a.shimko.dev@gmail.com>
Link: https://patch.msgid.link/20251104145433.2316165-2-a.shimko.dev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Classification
This is an **error handling fix** — a recognized category of bug fixes
for stable. The commit adds missing error checking for
`clk_prepare_enable()` return values in the runtime resume path.
## Bug Assessment
**What was broken:**
- `clk_prepare_enable()` can fail (e.g., clock hardware issues,
regulator failure), returning a negative error code.
- The old code ignored these return values and always returned 0
(success).
- This means the PM runtime framework would believe the device is active
when clocks may not actually be enabled.
**Consequences of the bug:**
1. **Inconsistent clock state**: If `clk` fails after `pclk` succeeds,
only one clock is enabled but the function claims success. On the
next `runtime_suspend`, both clocks will be disabled/unprepared —
leading to an unbalanced `clk_disable_unprepare()` on a clock that
was never successfully enabled.
2. **Serial port malfunction**: Without clocks properly enabled, the
UART hardware won't function, but the software stack thinks it's
ready.
3. **Clock framework imbalance**: Unbalanced enable/disable calls can
cause issues in the clock framework, potentially affecting other
devices sharing the same clock tree.
**Bug existed since 2013** (commit `ffc3ae6dd925b6`) — over 12 years.
## Severity Assessment
**Moderate severity.** While `clk_prepare_enable()` failing in runtime
resume is not a common occurrence in normal operation, when it does
happen:
- The consequences are real (clock imbalance, non-functional hardware)
- The PM framework gets incorrect state information
- Other drivers in the same subsystem (fsl_lpuart, imx) properly check
these return values, showing this is a known pattern
## Stable Kernel Criteria Check
1. **Obviously correct and tested**: Yes — the pattern is
straightforward error checking, matching what other serial drivers
already do. Merged by Greg Kroah-Hartman (the serial/stable
maintainer).
2. **Fixes a real bug**: Yes — ignoring clock enable failures leaves
hardware in inconsistent state and can cause unbalanced clock
operations.
3. **Important issue**: Moderate — clock enable failures can cause
device malfunction and clock framework inconsistency.
4. **Small and contained**: Yes — only ~10 lines changed in a single
function, single file.
5. **No new features**: Correct — purely error handling.
6. **Applies cleanly**: The affected code has been stable since 2019
(`a8afc193558a4`), so it should apply cleanly to all active stable
trees.
## Risk Assessment
**Very low risk.** The change:
- Only adds error checking to an existing code path
- Only affects the failure case (when `clk_prepare_enable()` returns
non-zero)
- The success path is unchanged
- Proper cleanup of `pclk` when `clk` fails prevents resource leaks
- Follows established patterns used by other serial drivers
## Verification
- **Git blame** confirmed the buggy code has been present since 2013
(`ffc3ae6dd925b6` by Heikki Krogerus) with pclk added in 2014
(`7d78cbefaa465`).
- **Code review** of other serial drivers (fsl_lpuart.c, imx.c)
confirmed they properly check `clk_prepare_enable()` return values in
runtime_resume, establishing this as an expected pattern.
- **8250_mtk.c** has the same unchecked pattern, confirming this is a
real class of bugs in 8250 drivers.
- **Commit was merged by Greg Kroah-Hartman** (serial subsystem and
stable maintainer), who linked it via patch.msgid.link.
- **dw8250_runtime_suspend** unconditionally calls
`clk_disable_unprepare()` on both clocks — verified that if
runtime_resume falsely reports success, the next suspend would call
disable on a clock that wasn't successfully enabled, causing clock
framework imbalance.
- **Could NOT verify** whether any user actually reported hitting this
bug in practice — the commit has no Reported-by tag, suggesting this
was found by code review rather than a user report.
## Conclusion
This is a legitimate bug fix that adds missing error handling for clock
enable operations in a runtime PM callback. The fix is small, surgical,
obviously correct, follows patterns established by other drivers in the
same subsystem, and carries essentially zero regression risk. While the
bug may not be frequently triggered in practice (clock enable failures
are relatively uncommon), when it does trigger, it causes real problems
(clock imbalance, non-functional hardware). The code has been present in
all stable trees since 2013-2014, so the fix is applicable broadly.
**YES**
drivers/tty/serial/8250/8250_dw.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 27af83f0ff463..0f8207652efe6 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -741,11 +741,18 @@ static int dw8250_runtime_suspend(struct device *dev)
static int dw8250_runtime_resume(struct device *dev)
{
+ int ret;
struct dw8250_data *data = dev_get_drvdata(dev);
- clk_prepare_enable(data->pclk);
+ ret = clk_prepare_enable(data->pclk);
+ if (ret)
+ return ret;
- clk_prepare_enable(data->clk);
+ ret = clk_prepare_enable(data->clk);
+ if (ret) {
+ clk_disable_unprepare(data->pclk);
+ return ret;
+ }
return 0;
}
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19] tty: vt/keyboard: Split apart vt_do_diacrit()
From: Sasha Levin @ 2026-02-19 2:03 UTC (permalink / raw)
To: patches, stable
Cc: Nathan Chancellor, kernel test robot, Greg Kroah-Hartman,
Sasha Levin, jirislaby, linux-kernel, linux-serial
In-Reply-To: <20260219020422.1539798-1-sashal@kernel.org>
From: Nathan Chancellor <nathan@kernel.org>
[ Upstream commit 0a76a17238f805b231d97b118232a5185bbb7a18 ]
After commit bfb24564b5fd ("tty: vt/keyboard: use __free()"), builds
using asm goto for put_user() and get_user() with a version of clang
older than 17 error with:
drivers/tty/vt/keyboard.c:1709:7: error: cannot jump from this asm goto statement to one of its possible targets
if (put_user(asize, &a->kb_cnt))
^
...
arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_mem_asm'
asm goto( \
^
drivers/tty/vt/keyboard.c:1687:7: note: possible target of asm goto statement
if (put_user(asize, &a->kb_cnt))
^
...
arch/arm64/include/asm/uaccess.h:342:2: note: expanded from macro '__raw_put_user'
__rpu_failed: \
^
drivers/tty/vt/keyboard.c:1697:23: note: jump exits scope of variable with __attribute__((cleanup))
void __free(kfree) *buf = kmalloc_array(MAX_DIACR, sizeof(struct kbdiacruc),
^
drivers/tty/vt/keyboard.c:1671:33: note: jump bypasses initialization of variable with __attribute__((cleanup))
struct kbdiacr __free(kfree) *dia = kmalloc_array(MAX_DIACR, sizeof(struct kbdiacr),
^
Prior to a fix to clang's scope checker in clang 17 [1], all labels in a
function were validated as potential targets of all asm gotos in a
function, regardless of whether they actually were a target of an asm
goto call, resulting in false positive errors about skipping over
variables marked with the cleanup attribute.
To workaround this error, split up the bodies of the case statements in
vt_do_diacrit() into their own functions so that the scope checker does
not trip up on the multiple instances of __free().
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202509091702.Oc7eCRDw-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511241835.EA8lShgH-lkp@intel.com/
Link: https://github.com/llvm/llvm-project/commit/f023f5cdb2e6c19026f04a15b5a935c041835d14 [1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20251125-tty-vt-keyboard-wa-clang-scope-check-error-v1-1-f5a5ea55c578@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
The current code in this tree has the `__free()` annotations from
`bfb24564b5fd8`, confirming that the prerequisite commit is present and
this fix is needed.
### Scope and Risk Assessment
- **Files changed**: 1 (drivers/tty/vt/keyboard.c)
- **Nature of change**: Pure mechanical refactoring - moving code into
separate functions
- **Logic changes**: None - the behavior is identical
- **Risk**: Very low. The code is simply moved into helper functions. No
logic changes, no new paths, no changed semantics.
- **Lines changed**: The diff looks large (~170 lines removed and added)
but it's entirely code movement, not new code.
### User Impact
- **Who is affected**: Anyone building the kernel with clang < 17 on
arm64 (or potentially other architectures using asm goto for
put_user/get_user)
- **Severity**: Build failure - the kernel **cannot be compiled** at all
with these toolchain combinations
- **Practical impact**: Enterprise distributions and CI systems that use
older clang versions would be completely blocked
### Stable Criteria Assessment
1. **Obviously correct and tested**: Yes - pure code movement, reported
by kernel test robot, authored by Nathan Chancellor (clang/compiler
expert), signed off by Greg KH
2. **Fixes a real bug**: Yes - build failure
3. **Important issue**: Yes - build failures prevent kernel compilation
entirely
4. **Small and contained**: Yes - single file, pure refactoring
5. **No new features**: Correct - no new features
6. **Applies cleanly**: Should apply cleanly since the prerequisite
`bfb24564b5fd8` must also be present
### Dependency
This commit depends on `bfb24564b5fd8` ("tty: vt/keyboard: use
__free()") being present in the stable tree. The fix is only needed if
`__free()` annotations were backported. If `bfb24564b5fd8` was
backported to a stable tree, then this fix **must** also be backported
to avoid build failures with older clang.
### Verification
- **git log master -- drivers/tty/vt/keyboard.c** confirmed
`bfb24564b5fd8` is present in the tree
- **Read of keyboard.c lines 1650-1699** confirmed the `__free(kfree)`
annotations are present in the current codebase, making this fix
necessary
- **git show bfb24564b5fd8** confirmed this is the prerequisite that
introduced the problematic `__free()` usage
- Commit message includes concrete error output from the kernel test
robot, confirming the build failure is real and reproducible
- The commit references the specific clang fix (llvm-project commit
f023f5cdb2e6c19) confirming this is a known compiler issue
- Author is Nathan Chancellor, the primary Linux kernel clang/LLVM
maintainer - expert in this area
- Signed-off by Greg KH (stable tree maintainer)
### Conclusion
This is a textbook **build fix** - one of the explicitly allowed
categories for stable backporting. It fixes a real compilation failure
with clang < 17 on arm64, the change is purely mechanical (code movement
into helper functions with zero logic changes), the risk is extremely
low, and it's authored by the kernel's clang expert and signed off by
the stable maintainer. The only caveat is that it requires the
prerequisite commit `bfb24564b5fd8` to be present in the stable tree.
**YES**
drivers/tty/vt/keyboard.c | 221 ++++++++++++++++++++------------------
1 file changed, 115 insertions(+), 106 deletions(-)
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index d65fc60dd7bed..3538d54d6a6ac 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1649,134 +1649,143 @@ int __init kbd_init(void)
/* Ioctl support code */
-/**
- * vt_do_diacrit - diacritical table updates
- * @cmd: ioctl request
- * @udp: pointer to user data for ioctl
- * @perm: permissions check computed by caller
- *
- * Update the diacritical tables atomically and safely. Lock them
- * against simultaneous keypresses
- */
-int vt_do_diacrit(unsigned int cmd, void __user *udp, int perm)
+static int vt_do_kdgkbdiacr(void __user *udp)
{
- int asize;
-
- switch (cmd) {
- case KDGKBDIACR:
- {
- struct kbdiacrs __user *a = udp;
- int i;
+ struct kbdiacrs __user *a = udp;
+ int i, asize;
- struct kbdiacr __free(kfree) *dia = kmalloc_array(MAX_DIACR, sizeof(struct kbdiacr),
- GFP_KERNEL);
- if (!dia)
- return -ENOMEM;
+ struct kbdiacr __free(kfree) *dia = kmalloc_array(MAX_DIACR, sizeof(struct kbdiacr),
+ GFP_KERNEL);
+ if (!dia)
+ return -ENOMEM;
- /* Lock the diacriticals table, make a copy and then
- copy it after we unlock */
- scoped_guard(spinlock_irqsave, &kbd_event_lock) {
- asize = accent_table_size;
- for (i = 0; i < asize; i++) {
- dia[i].diacr = conv_uni_to_8bit(accent_table[i].diacr);
- dia[i].base = conv_uni_to_8bit(accent_table[i].base);
- dia[i].result = conv_uni_to_8bit(accent_table[i].result);
- }
+ /* Lock the diacriticals table, make a copy and then
+ copy it after we unlock */
+ scoped_guard(spinlock_irqsave, &kbd_event_lock) {
+ asize = accent_table_size;
+ for (i = 0; i < asize; i++) {
+ dia[i].diacr = conv_uni_to_8bit(accent_table[i].diacr);
+ dia[i].base = conv_uni_to_8bit(accent_table[i].base);
+ dia[i].result = conv_uni_to_8bit(accent_table[i].result);
}
-
- if (put_user(asize, &a->kb_cnt))
- return -EFAULT;
- if (copy_to_user(a->kbdiacr, dia, asize * sizeof(struct kbdiacr)))
- return -EFAULT;
- return 0;
}
- case KDGKBDIACRUC:
- {
- struct kbdiacrsuc __user *a = udp;
- void __free(kfree) *buf = kmalloc_array(MAX_DIACR, sizeof(struct kbdiacruc),
- GFP_KERNEL);
- if (buf == NULL)
- return -ENOMEM;
+ if (put_user(asize, &a->kb_cnt))
+ return -EFAULT;
+ if (copy_to_user(a->kbdiacr, dia, asize * sizeof(struct kbdiacr)))
+ return -EFAULT;
+ return 0;
+}
- /* Lock the diacriticals table, make a copy and then
- copy it after we unlock */
- scoped_guard(spinlock_irqsave, &kbd_event_lock) {
- asize = accent_table_size;
- memcpy(buf, accent_table, asize * sizeof(struct kbdiacruc));
- }
+static int vt_do_kdgkbdiacruc(void __user *udp)
+{
+ struct kbdiacrsuc __user *a = udp;
+ int asize;
- if (put_user(asize, &a->kb_cnt))
- return -EFAULT;
- if (copy_to_user(a->kbdiacruc, buf, asize * sizeof(struct kbdiacruc)))
- return -EFAULT;
+ void __free(kfree) *buf = kmalloc_array(MAX_DIACR, sizeof(struct kbdiacruc),
+ GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
- return 0;
+ /* Lock the diacriticals table, make a copy and then
+ copy it after we unlock */
+ scoped_guard(spinlock_irqsave, &kbd_event_lock) {
+ asize = accent_table_size;
+ memcpy(buf, accent_table, asize * sizeof(struct kbdiacruc));
}
- case KDSKBDIACR:
- {
- struct kbdiacrs __user *a = udp;
- struct kbdiacr __free(kfree) *dia = NULL;
- unsigned int ct;
- int i;
+ if (put_user(asize, &a->kb_cnt))
+ return -EFAULT;
+ if (copy_to_user(a->kbdiacruc, buf, asize * sizeof(struct kbdiacruc)))
+ return -EFAULT;
- if (!perm)
- return -EPERM;
- if (get_user(ct, &a->kb_cnt))
- return -EFAULT;
- if (ct >= MAX_DIACR)
- return -EINVAL;
+ return 0;
+}
- if (ct) {
- dia = memdup_array_user(a->kbdiacr,
- ct, sizeof(struct kbdiacr));
- if (IS_ERR(dia))
- return PTR_ERR(dia);
- }
+static int vt_do_kdskbdiacr(void __user *udp, int perm)
+{
+ struct kbdiacrs __user *a = udp;
+ struct kbdiacr __free(kfree) *dia = NULL;
+ unsigned int ct;
+ int i;
- guard(spinlock_irqsave)(&kbd_event_lock);
- accent_table_size = ct;
- for (i = 0; i < ct; i++) {
- accent_table[i].diacr =
- conv_8bit_to_uni(dia[i].diacr);
- accent_table[i].base =
- conv_8bit_to_uni(dia[i].base);
- accent_table[i].result =
- conv_8bit_to_uni(dia[i].result);
- }
+ if (!perm)
+ return -EPERM;
+ if (get_user(ct, &a->kb_cnt))
+ return -EFAULT;
+ if (ct >= MAX_DIACR)
+ return -EINVAL;
- return 0;
+ if (ct) {
+ dia = memdup_array_user(a->kbdiacr,
+ ct, sizeof(struct kbdiacr));
+ if (IS_ERR(dia))
+ return PTR_ERR(dia);
}
- case KDSKBDIACRUC:
- {
- struct kbdiacrsuc __user *a = udp;
- unsigned int ct;
- void __free(kfree) *buf = NULL;
+ guard(spinlock_irqsave)(&kbd_event_lock);
+ accent_table_size = ct;
+ for (i = 0; i < ct; i++) {
+ accent_table[i].diacr =
+ conv_8bit_to_uni(dia[i].diacr);
+ accent_table[i].base =
+ conv_8bit_to_uni(dia[i].base);
+ accent_table[i].result =
+ conv_8bit_to_uni(dia[i].result);
+ }
- if (!perm)
- return -EPERM;
+ return 0;
+}
- if (get_user(ct, &a->kb_cnt))
- return -EFAULT;
+static int vt_do_kdskbdiacruc(void __user *udp, int perm)
+{
+ struct kbdiacrsuc __user *a = udp;
+ unsigned int ct;
+ void __free(kfree) *buf = NULL;
- if (ct >= MAX_DIACR)
- return -EINVAL;
+ if (!perm)
+ return -EPERM;
- if (ct) {
- buf = memdup_array_user(a->kbdiacruc,
- ct, sizeof(struct kbdiacruc));
- if (IS_ERR(buf))
- return PTR_ERR(buf);
- }
- guard(spinlock_irqsave)(&kbd_event_lock);
- if (ct)
- memcpy(accent_table, buf,
- ct * sizeof(struct kbdiacruc));
- accent_table_size = ct;
- return 0;
+ if (get_user(ct, &a->kb_cnt))
+ return -EFAULT;
+
+ if (ct >= MAX_DIACR)
+ return -EINVAL;
+
+ if (ct) {
+ buf = memdup_array_user(a->kbdiacruc,
+ ct, sizeof(struct kbdiacruc));
+ if (IS_ERR(buf))
+ return PTR_ERR(buf);
}
+ guard(spinlock_irqsave)(&kbd_event_lock);
+ if (ct)
+ memcpy(accent_table, buf,
+ ct * sizeof(struct kbdiacruc));
+ accent_table_size = ct;
+ return 0;
+}
+
+/**
+ * vt_do_diacrit - diacritical table updates
+ * @cmd: ioctl request
+ * @udp: pointer to user data for ioctl
+ * @perm: permissions check computed by caller
+ *
+ * Update the diacritical tables atomically and safely. Lock them
+ * against simultaneous keypresses
+ */
+int vt_do_diacrit(unsigned int cmd, void __user *udp, int perm)
+{
+ switch (cmd) {
+ case KDGKBDIACR:
+ return vt_do_kdgkbdiacr(udp);
+ case KDGKBDIACRUC:
+ return vt_do_kdgkbdiacruc(udp);
+ case KDSKBDIACR:
+ return vt_do_kdskbdiacr(udp, perm);
+ case KDSKBDIACRUC:
+ return vt_do_kdskbdiacruc(udp, perm);
}
return 0;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 09/13] dt-bindings: serial: fsl-linflexuart: add dma properties
From: Krzysztof Kozlowski @ 2026-02-18 19:49 UTC (permalink / raw)
To: Larisa Ileana Grigore, gregkh, jirislaby, robh, krzk+dt, conor+dt,
sumit.semwal, christian.koenig, chester62515, cosmin.stoica,
adrian.nitu, stefan-gabriel.mirea, Mihaela.Martinas
Cc: linux-kernel, linux-serial, devicetree, linux-media, dri-devel,
linaro-mm-sig, s32, imx, clizzi, aruizrui, eballetb, echanude,
jkangas, Radu Pirea
In-Reply-To: <4ad41c4c-3319-403b-93c7-c52a58658e84@oss.nxp.com>
On 18/02/2026 15:44, Larisa Ileana Grigore wrote:
> On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote:
>> On 16/02/2026 16:02, Larisa Grigore wrote:
>>> From: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>>
>>> Add 'dmas' and 'dma-names' properties to describe optional DMA support
>>> for RX and TX channels in the LINFlexD UART controller.
>>
>> Same question as in other patch about existing devices.
>>
> I will update the bindings so that `dmas`/`dma-names` are optional for
> S32G and not present on S32V234. Would this be acceptable?
>
Yes, with reason in the commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 08/13] dt-bindings: serial: fsl-linflexuart: add clock input properties
From: Krzysztof Kozlowski @ 2026-02-18 19:48 UTC (permalink / raw)
To: Larisa Ileana Grigore, gregkh, jirislaby, robh, krzk+dt, conor+dt,
sumit.semwal, christian.koenig, chester62515, cosmin.stoica,
adrian.nitu, stefan-gabriel.mirea, Mihaela.Martinas
Cc: linux-kernel, linux-serial, devicetree, linux-media, dri-devel,
linaro-mm-sig, s32, imx, clizzi, aruizrui, eballetb, echanude,
jkangas, Radu Pirea
In-Reply-To: <69fafe15-a539-4429-ad15-3ec44babab28@oss.nxp.com>
On 18/02/2026 14:57, Larisa Ileana Grigore wrote:
> On 2/18/2026 3:29 PM, Krzysztof Kozlowski wrote:
>> On 18/02/2026 14:26, Larisa Ileana Grigore wrote:
>>> On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote:
>>>> On 16/02/2026 16:02, Larisa Grigore wrote:
>>>>> From: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>>>>
>>>>> Add optional support for the two clock inputs used by the LINFlexD UART
>>>>> controller:
>>>>> - "lin": LIN_BAUD_CLK
>>>>> - "ipg": LINFLEXD_CLK
>>>>>
>>>>> The clock inputs are kept optional to maintain compatibility with the
>>>>> S32V234 platform.
>>>>
>>>> Does S32V234 have the clocks? I don't understand the "maintain
>>>> compatibility" in this context. Either you have or you have not clocks,
>>>> which should be expressed in schema (: false, see example schema).
>>>>
>>> Hello Krzysztof,
>>>
>>> Thanks for pointing this out! I will update both the schema and the
>>> commit description.
>>> S32V234 does not expose these clocks in its device tree—on this platform
>>> the LINFlexD clocks are set up and enabled by U‑Boot, so they are not
>>> available to the kernel.
>>
>> So there are clocks. DTS is being used by bootloader, so how bootloader
>> is going to set up clocks for S32V234 if no one provides them?
>>
>> This looks like buggy/incomplete approach, although I understand that
>> the original binding had the issue.
>>
> Indeed, I also believe the binding is not fully accurate on S32V234. As
> I mentioned earlier, the LINFlexD clocks are not managed by Linux on
> this platform. They, along with several other clocks, are usually
> initialized by U‑Boot, and Linux does not handle them. That is likely
> the reason they were omitted from the S32V234 binding.
> I’m willing to correct this for the S32V234 compatible by making that
> property optional, so we don’t break compatibility.
> For S32G, I would prefer to avoid repeating the same oversight we had on
> S32V234 and make the property required, since the IP, as you correctly
> pointed out, does have dedicated clock inputs.
>
> How would you approach this?
So the new device should require clocks, which can be left optional for
the old one with explanation in the commit msg. Linux is not the only
consumer of bindings and DTS.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] tty: ipwireless: Fix use-after-free in tasklet during device removal
From: David Sterba @ 2026-02-18 15:23 UTC (permalink / raw)
To: Jiri Slaby
Cc: Jiri Kosina, Greg KH, duoming, linux-serial, linux-kernel,
dsterba, kuba, alexander.deucher, akpm, pkshih, tglx, mingo
In-Reply-To: <a77224d3-04d8-4a62-bb48-06fee922013c@kernel.org>
On Tue, Feb 17, 2026 at 09:03:25AM +0100, Jiri Slaby wrote:
> Hi,
>
> On 09. 02. 26, 11:21, David Sterba wrote:
> > On Sun, Feb 08, 2026 at 06:25:38PM +0100, Jiri Kosina wrote:
> >> On Sun, 8 Feb 2026, Greg KH wrote:
> >>
> >>>> I don't have the real hardware. In order to reproduce the bug, I simulate
> >>>> the IPWireless PCMCIA card in the qemu by allocating and configuring the
> >>>> necessary resources(I/O ports, memory regions, interrupts and so on) to
> >>>> correspond with the hardware expected by the driver in the initialization
> >>>> code of the virtual device.
> >>>
> >>> I wonder if this device even is still around, given that pcmcia is all
> >>> but dead for a very long time.
> >>
> >> I doubt that this device is still around anywhere where reasonably new
> >> kernels (including LTS) would matter.
> >>
> >> I don't think I've seen this device (which was back then donated to me by
> >> T-Mobile CZ in order to get it supported in Linux, and I am not sure how
> >> much global adoption it got afterwards) for, let's say, past 15 years :)
> >>
> >> I think (let's see what David, ho took the maintainership over for me
> >> afterwards, has to say) we'd better deprecate and drop the whole thing,
> >> rather than trying to pretend that it's still actively being taken care
> >> of.
> >
> > https://lore.kernel.org/all/20230223172403.GW10580@suse.cz/ last time
> > the question of keeping the driver was asked (2023). Back then I was
> > able to find the cards on second hand market but now I can't on a local
> > market and there's exactly one hit on global eBay.
> >
> > Local linux related or telco support forums seem to mention the driver
> > until 2011 (root.cz, abclinuxu.cz, t-mobile.cz). It does not prove
> > nobody is using it but I think the chances are quite low to justify
> > keeping the driver. It is simple enough to be built as an external
> > module eventually, I can help with that in case somebody really needs
> > that.
>
> So, would you want to submit the removal? Or anyone else, if you don't
> want to lose time with this? (I can do that, if noone wants to.)
Let me do it after rc1 so I can finish the journey of this driver which
was my first nontrivial contribution to linux kernel.
^ permalink raw reply
* Re: [PATCH 09/13] dt-bindings: serial: fsl-linflexuart: add dma properties
From: Larisa Ileana Grigore @ 2026-02-18 14:44 UTC (permalink / raw)
To: Krzysztof Kozlowski, gregkh, jirislaby, robh, krzk+dt, conor+dt,
sumit.semwal, christian.koenig, chester62515, cosmin.stoica,
adrian.nitu, stefan-gabriel.mirea, Mihaela.Martinas
Cc: linux-kernel, linux-serial, devicetree, linux-media, dri-devel,
linaro-mm-sig, s32, imx, clizzi, aruizrui, eballetb, echanude,
jkangas, Radu Pirea
In-Reply-To: <be18bbef-02f1-416b-ad2a-739261b3cd97@kernel.org>
On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote:
> On 16/02/2026 16:02, Larisa Grigore wrote:
>> From: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>
>> Add 'dmas' and 'dma-names' properties to describe optional DMA support
>> for RX and TX channels in the LINFlexD UART controller.
>
> Same question as in other patch about existing devices.
>
I will update the bindings so that `dmas`/`dma-names` are optional for
S32G and not present on S32V234. Would this be acceptable?
Thanks,
Larisa
>>
>> This allows the device tree to specify DMA channels used for UART data
>> transfers. If not specified, the driver will fall to interrupt-based
>> operations.
>>
>> Signed-off-by: Radu Pirea <radu-nicolae.pirea@nxp.com>
>> Co-developed-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>> Signed-off-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>> ---
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 08/13] dt-bindings: serial: fsl-linflexuart: add clock input properties
From: Larisa Ileana Grigore @ 2026-02-18 13:57 UTC (permalink / raw)
To: Krzysztof Kozlowski, gregkh, jirislaby, robh, krzk+dt, conor+dt,
sumit.semwal, christian.koenig, chester62515, cosmin.stoica,
adrian.nitu, stefan-gabriel.mirea, Mihaela.Martinas
Cc: linux-kernel, linux-serial, devicetree, linux-media, dri-devel,
linaro-mm-sig, s32, imx, clizzi, aruizrui, eballetb, echanude,
jkangas, Radu Pirea
In-Reply-To: <b7adddfc-db7a-466d-a2e8-72bc6a87ae81@kernel.org>
On 2/18/2026 3:29 PM, Krzysztof Kozlowski wrote:
> On 18/02/2026 14:26, Larisa Ileana Grigore wrote:
>> On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote:
>>> On 16/02/2026 16:02, Larisa Grigore wrote:
>>>> From: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>>>
>>>> Add optional support for the two clock inputs used by the LINFlexD UART
>>>> controller:
>>>> - "lin": LIN_BAUD_CLK
>>>> - "ipg": LINFLEXD_CLK
>>>>
>>>> The clock inputs are kept optional to maintain compatibility with the
>>>> S32V234 platform.
>>>
>>> Does S32V234 have the clocks? I don't understand the "maintain
>>> compatibility" in this context. Either you have or you have not clocks,
>>> which should be expressed in schema (: false, see example schema).
>>>
>> Hello Krzysztof,
>>
>> Thanks for pointing this out! I will update both the schema and the
>> commit description.
>> S32V234 does not expose these clocks in its device tree—on this platform
>> the LINFlexD clocks are set up and enabled by U‑Boot, so they are not
>> available to the kernel.
>
> So there are clocks. DTS is being used by bootloader, so how bootloader
> is going to set up clocks for S32V234 if no one provides them?
>
> This looks like buggy/incomplete approach, although I understand that
> the original binding had the issue.
>
Indeed, I also believe the binding is not fully accurate on S32V234. As
I mentioned earlier, the LINFlexD clocks are not managed by Linux on
this platform. They, along with several other clocks, are usually
initialized by U‑Boot, and Linux does not handle them. That is likely
the reason they were omitted from the S32V234 binding.
I’m willing to correct this for the S32V234 compatible by making that
property optional, so we don’t break compatibility.
For S32G, I would prefer to avoid repeating the same oversight we had on
S32V234 and make the property required, since the IP, as you correctly
pointed out, does have dedicated clock inputs.
How would you approach this?
Thank you,
Larisa
>
>> The changes in this patch are intended specifically for S32G2/G3, where
>> the clocks are provided in the DT and required by the driver.
>>
>>>>
>>>> Signed-off-by: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>>> Co-developed-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>>>> Signed-off-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>>>> ---
>>>> .../bindings/serial/fsl,s32-linflexuart.yaml | 18 ++++++++++++++++++
>>>> 1 file changed, 18 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>>>> index 4171f524a928..885f0b1b3492 100644
>>>> --- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>>>> +++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>>>> @@ -34,6 +34,14 @@ properties:
>>>> interrupts:
>>>> maxItems: 1
>>>>
>>>> + clocks:
>>>> + maxItems: 2
>>>> +
>>>> + clock-names:
>>>> + items:
>>>> + - const: lin
>>>> + - const: ipg
>>>> +
>>>> required:
>>>> - compatible
>>>> - reg
>>>> @@ -48,3 +56,13 @@ examples:
>>>> reg = <0x40053000 0x1000>;
>>>> interrupts = <0 59 4>;
>>>> };
>>>> +
>>>> + - |
>>>> + serial@401c8000 {
>>>> + compatible = "nxp,s32g2-linflexuart",
>>>> + "fsl,s32v234-linflexuart";
>>>> + reg = <0x401C8000 0x3000>;
>>>> + interrupts = <0 82 1>;
>>>> + clocks = <&clks 14>, <&clks 13>;
>>>> + clock-names = "lin", "ipg";
>>>
>>> Just add the clocks to existing example. No need for new example for
>>> each new property.
>>>
>>>> + };
>>
>> The existing node refers to S32V234 which does not expose any clock
>> properties in its device tree. Because of this, I couldn’t extend that
>
> You just said S32V234 has clocks...
>
>> example with clocks and clock-names. The additional example is there
>> only to illustrate the S32G2 case, where the clocks are required and
>> actually present in the device tree. Should I remove it?
>>
>> Best regards,
>> Larisa
>>>
>>> Best regards,
>>> Krzysztof
>>
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 08/13] dt-bindings: serial: fsl-linflexuart: add clock input properties
From: Krzysztof Kozlowski @ 2026-02-18 13:29 UTC (permalink / raw)
To: Larisa Ileana Grigore, gregkh, jirislaby, robh, krzk+dt, conor+dt,
sumit.semwal, christian.koenig, chester62515, cosmin.stoica,
adrian.nitu, stefan-gabriel.mirea, Mihaela.Martinas
Cc: linux-kernel, linux-serial, devicetree, linux-media, dri-devel,
linaro-mm-sig, s32, imx, clizzi, aruizrui, eballetb, echanude,
jkangas, Radu Pirea
In-Reply-To: <e9c214be-840a-43fe-b24d-610fe90269b2@oss.nxp.com>
On 18/02/2026 14:26, Larisa Ileana Grigore wrote:
> On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote:
>> On 16/02/2026 16:02, Larisa Grigore wrote:
>>> From: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>>
>>> Add optional support for the two clock inputs used by the LINFlexD UART
>>> controller:
>>> - "lin": LIN_BAUD_CLK
>>> - "ipg": LINFLEXD_CLK
>>>
>>> The clock inputs are kept optional to maintain compatibility with the
>>> S32V234 platform.
>>
>> Does S32V234 have the clocks? I don't understand the "maintain
>> compatibility" in this context. Either you have or you have not clocks,
>> which should be expressed in schema (: false, see example schema).
>>
> Hello Krzysztof,
>
> Thanks for pointing this out! I will update both the schema and the
> commit description.
> S32V234 does not expose these clocks in its device tree—on this platform
> the LINFlexD clocks are set up and enabled by U‑Boot, so they are not
> available to the kernel.
So there are clocks. DTS is being used by bootloader, so how bootloader
is going to set up clocks for S32V234 if no one provides them?
This looks like buggy/incomplete approach, although I understand that
the original binding had the issue.
> The changes in this patch are intended specifically for S32G2/G3, where
> the clocks are provided in the DT and required by the driver.
>
>>>
>>> Signed-off-by: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>> Co-developed-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>>> Signed-off-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>>> ---
>>> .../bindings/serial/fsl,s32-linflexuart.yaml | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>>> index 4171f524a928..885f0b1b3492 100644
>>> --- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>>> +++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>>> @@ -34,6 +34,14 @@ properties:
>>> interrupts:
>>> maxItems: 1
>>>
>>> + clocks:
>>> + maxItems: 2
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: lin
>>> + - const: ipg
>>> +
>>> required:
>>> - compatible
>>> - reg
>>> @@ -48,3 +56,13 @@ examples:
>>> reg = <0x40053000 0x1000>;
>>> interrupts = <0 59 4>;
>>> };
>>> +
>>> + - |
>>> + serial@401c8000 {
>>> + compatible = "nxp,s32g2-linflexuart",
>>> + "fsl,s32v234-linflexuart";
>>> + reg = <0x401C8000 0x3000>;
>>> + interrupts = <0 82 1>;
>>> + clocks = <&clks 14>, <&clks 13>;
>>> + clock-names = "lin", "ipg";
>>
>> Just add the clocks to existing example. No need for new example for
>> each new property.
>>
>>> + };
>
> The existing node refers to S32V234 which does not expose any clock
> properties in its device tree. Because of this, I couldn’t extend that
You just said S32V234 has clocks...
> example with clocks and clock-names. The additional example is there
> only to illustrate the S32G2 case, where the clocks are required and
> actually present in the device tree. Should I remove it?
>
> Best regards,
> Larisa
>>
>> Best regards,
>> Krzysztof
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 08/13] dt-bindings: serial: fsl-linflexuart: add clock input properties
From: Larisa Ileana Grigore @ 2026-02-18 13:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, gregkh, jirislaby, robh, krzk+dt, conor+dt,
sumit.semwal, christian.koenig, chester62515, cosmin.stoica,
adrian.nitu, stefan-gabriel.mirea, Mihaela.Martinas
Cc: linux-kernel, linux-serial, devicetree, linux-media, dri-devel,
linaro-mm-sig, s32, imx, clizzi, aruizrui, eballetb, echanude,
jkangas, Radu Pirea
In-Reply-To: <24443e02-886e-48e2-911e-e4093d251155@kernel.org>
On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote:
> On 16/02/2026 16:02, Larisa Grigore wrote:
>> From: Radu Pirea <radu-nicolae.pirea@nxp.com>
>>
>> Add optional support for the two clock inputs used by the LINFlexD UART
>> controller:
>> - "lin": LIN_BAUD_CLK
>> - "ipg": LINFLEXD_CLK
>>
>> The clock inputs are kept optional to maintain compatibility with the
>> S32V234 platform.
>
> Does S32V234 have the clocks? I don't understand the "maintain
> compatibility" in this context. Either you have or you have not clocks,
> which should be expressed in schema (: false, see example schema).
>
Hello Krzysztof,
Thanks for pointing this out! I will update both the schema and the
commit description.
S32V234 does not expose these clocks in its device tree—on this platform
the LINFlexD clocks are set up and enabled by U‑Boot, so they are not
available to the kernel.
The changes in this patch are intended specifically for S32G2/G3, where
the clocks are provided in the DT and required by the driver.
>>
>> Signed-off-by: Radu Pirea <radu-nicolae.pirea@nxp.com>
>> Co-developed-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>> Signed-off-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>> ---
>> .../bindings/serial/fsl,s32-linflexuart.yaml | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>> index 4171f524a928..885f0b1b3492 100644
>> --- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>> +++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
>> @@ -34,6 +34,14 @@ properties:
>> interrupts:
>> maxItems: 1
>>
>> + clocks:
>> + maxItems: 2
>> +
>> + clock-names:
>> + items:
>> + - const: lin
>> + - const: ipg
>> +
>> required:
>> - compatible
>> - reg
>> @@ -48,3 +56,13 @@ examples:
>> reg = <0x40053000 0x1000>;
>> interrupts = <0 59 4>;
>> };
>> +
>> + - |
>> + serial@401c8000 {
>> + compatible = "nxp,s32g2-linflexuart",
>> + "fsl,s32v234-linflexuart";
>> + reg = <0x401C8000 0x3000>;
>> + interrupts = <0 82 1>;
>> + clocks = <&clks 14>, <&clks 13>;
>> + clock-names = "lin", "ipg";
>
> Just add the clocks to existing example. No need for new example for
> each new property.
>
>> + };
The existing node refers to S32V234 which does not expose any clock
properties in its device tree. Because of this, I couldn’t extend that
example with clocks and clock-names. The additional example is there
only to illustrate the S32G2 case, where the clocks are required and
actually present in the device tree. Should I remove it?
Best regards,
Larisa
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 02/13] serial: linflexuart: Clean SLEEP bit in LINCR1 after suspend
From: Larisa Ileana Grigore @ 2026-02-18 12:09 UTC (permalink / raw)
To: Frank Li
Cc: gregkh, jirislaby, robh, krzk+dt, conor+dt, sumit.semwal,
christian.koenig, chester62515, cosmin.stoica, adrian.nitu,
stefan-gabriel.mirea, Mihaela.Martinas, linux-kernel,
linux-serial, devicetree, linux-media, dri-devel, linaro-mm-sig,
s32, imx, clizzi, aruizrui, eballetb, echanude, jkangas
In-Reply-To: <aZN8hKJSsnnYhy1m@lizhi-Precision-Tower-5810>
On 2/16/2026 10:22 PM, Frank Li wrote:
> On Mon, Feb 16, 2026 at 04:01:54PM +0100, Larisa Grigore wrote:
>> When coming back from reset, we need to re-initialize LINCR1 register.
>> SLEEP bit should be cleared, otherwise we can't enter INITM mode.
>
> serial: linflexuart: Clean SLEEP bit in LINCR1 at linflex_set_termios()
>
> Re-initialize LINCR1 register (Clear the SLEEP bit) at
> linflex_set_termios(), otherwise the controller cannot enter INITM mode
> after suspend/resume.
>
> Frank
>>
Thanks!
>> Fixes: 09864c1cdf5c ("tty: serial: Add linflexuart driver for S32V234")
>> Signed-off-by: Larisa Grigore <larisa.grigore@oss.nxp.com>
>> ---
>> drivers/tty/serial/fsl_linflexuart.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/serial/fsl_linflexuart.c b/drivers/tty/serial/fsl_linflexuart.c
>> index 5a410e2d56ac..016011fd8760 100644
>> --- a/drivers/tty/serial/fsl_linflexuart.c
>> +++ b/drivers/tty/serial/fsl_linflexuart.c
>> @@ -413,8 +413,7 @@ linflex_set_termios(struct uart_port *port, struct ktermios *termios,
>> old_cr = cr;
>>
>> /* Enter initialization mode by setting INIT bit */
>> - cr1 = readl(port->membase + LINCR1);
>> - cr1 |= LINFLEXD_LINCR1_INIT;
>> + cr1 = LINFLEXD_LINCR1_INIT | LINFLEXD_LINCR1_MME;
>> writel(cr1, port->membase + LINCR1);
>>
>> /* wait for init mode entry */
>> --
>> 2.47.0
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox