* [PATCH 0/2] Enhancements to UART driver for error handling and DMA RX status
From: Moteen Shah @ 2026-01-12 8:18 UTC (permalink / raw)
To: gregkh, jirislaby
Cc: linux-kernel, linux-serial, vigneshr, u-kumar1, gehariprasath,
g-praveen, j-keerthy, m-shah
This series adds support for handling UART error conditions such as
overrun and other error conditions before any DMA transaction is
issued. It also ensures that the DMA RX running status is cleared
only after the DMA termination is fully done to maintain a sync between
software and the hardware states.
Moteen Shah (2):
serial: 8250: 8250_omap.c: Add support for handling UART error
conditions
serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA
termination is done
drivers/tty/serial/8250/8250_omap.c | 25 ++++++++++++++++++++++---
1 file changed, 22 insertions(+), 3 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 1/2] serial: 8250: 8250_omap.c: Add support for handling UART error conditions
From: Moteen Shah @ 2026-01-12 8:18 UTC (permalink / raw)
To: gregkh, jirislaby
Cc: linux-kernel, linux-serial, vigneshr, u-kumar1, gehariprasath,
g-praveen, j-keerthy, m-shah
In-Reply-To: <20260112081829.63049-1-m-shah@ti.com>
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>
---
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 9e49ef48b851..e26bae0a6488 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.34.1
^ permalink raw reply related
* [PATCH 2/2] serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done
From: Moteen Shah @ 2026-01-12 8:18 UTC (permalink / raw)
To: gregkh, jirislaby
Cc: linux-kernel, linux-serial, vigneshr, u-kumar1, gehariprasath,
g-praveen, j-keerthy, m-shah
In-Reply-To: <20260112081829.63049-1-m-shah@ti.com>
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>
---
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 e26bae0a6488..272bc07c9a6b 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.34.1
^ permalink raw reply related
* Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-01-12 8:18 UTC (permalink / raw)
To: manivannan.sadhasivam, Herve Codina
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Bartosz Golaszewski, Sui Jingfeng
In-Reply-To: <aWSq_7_5kkQIv9Hc@smile.fi.intel.com>
+Cc: Herve (btw, any news on LAN966x support?)
On Mon, Jan 12, 2026 at 10:04:24AM +0200, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > Hi,
> >
> > This series is the continuation of the series [1] that added the initial support
> > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > connectors. These connectors are used to connect the Wireless Connectivity
> > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > interfaces are left for future improvements.
> >
> > Serdev device support for BT
> > ============================
> >
> > Adding support for the PCIe interface was mostly straightforward and a lot
> > similar to the previous Key M connector. But adding UART interface has proved to
> > be tricky. This is mostly because of the fact UART is a non-discoverable bus,
> > unlike PCIe which is discoverable. So this series relied on the PCI notifier to
> > create the serdev device for UART/BT. This means the PCIe interface will be
> > brought up first and after the PCIe device enumeration, the serdev device will
> > be created by the pwrseq driver. This logic is necessary since the connector
> > driver and DT node don't describe the device, but just the connector. So to make
> > the connector interface Plug and Play, the connector driver uses the PCIe device
> > ID to identify the card and creates the serdev device. This logic could be
> > extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
> > interface for connecting WLAN, a SDIO notifier could be added to create the
> > serdev device.
> >
> > Open questions
> > ==============
> >
> > Though this series adds the relevant functionality for handling the M.2 Key M
> > connectors, there are still a few open questions exists on the design.
> >
> > 1. I've used the DT compatible for the serdev swnode to match the existing OF
> > device_id of the bluetooth driver. This avoids implementing custom serdev id
> > matching as implemented till v2.
>
> Yeah, swnodes are not designed to replace the real DT or other firmware
> interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> fixing up the broken or missed FW device properties). This should not have been
> done this way. Please, consider another approach, e.g. DT-overlay.
This is what I have in mind when replied to you:
https://lore.kernel.org/all/20251015071420.1173068-1-herve.codina@bootlin.com/
> > 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> > the PCIe device DT node to extract properties such as
> > 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> > add the PCIe DT node in the Root Port in conjunction with the Port node as
> > below?
> >
> > pcie@0 {
> > wifi@0 {
> > compatible = "pci17cb,1103";
> > ...
> > qcom,calibration-variant = "LE_X13S";
> > };
> >
> > port {
> > pcie4_port0_ep: endpoint {
> > remote-endpoint = <&m2_e_pcie_ep>;
> > };
> > };
> > };
> >
> > This will also require marking the PMU supplies optional in the relevant ath
> > bindings for M.2 cards.
> >
> > 3. Some M.2 cards require specific power up sequence like delays between
> > regulator/GPIO and such. For instance, the WCN7850 card supported in this series
> > requires 50ms delay between powering up an interface and driving it. I've just
> > hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
> > driver doesn't know anything about the device it is dealing with before powering
> > it ON, how should it handle the device specific power requirements? Should we
> > hardcode the device specific property in the connector node? But then, it will
> > no longer become a generic M.2 connector and sort of defeats the purpose of the
> > connector binding.
> >
> > I hope to address these questions with the help of the relevant subsystem
> > maintainers and the community.
> >
> > Testing
> > =======
> >
> > This series, together with the devicetree changes [2] was tested on the
> > Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
> > 1620 LGA card connected over PCIe and UART.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback
From: Manivannan Sadhasivam @ 2026-01-12 8:19 UTC (permalink / raw)
To: Andy Shevchenko, Dmitry Torokhov
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Sui Jingfeng
In-Reply-To: <aWSpFk9z0zpyKjr6@smile.fi.intel.com>
+ Dmitry Torokhov (who was against this patch previously)
On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>
> > Because the software node backend of the fwnode API framework lacks an
> > implementation for the .device_get_match_data function callback.
>
> Maybe this is done on purpose. Have you thought about this aspect?
>
IMO, software nodes were introduced to add sub-properties to the existing
firmware nodes, but it has usecase/potential to go beyond that. More below.
> > This makes it difficult to use(and/or test) a few drivers that originates
> > from DT world on the non-DT platform.
>
> How difficult? DSA implementation went to the way of taking DT overlay
> approach. Why that one can't be applied here?
>
Sometimes you do not have any DT node at all. For example, in this series, the
M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
match it with the existing OF based BT driver (for non-M2 device). From the
driver's point of view, a BT device attached to the M.2 slot and over custom
connectors are both the same. Only difference is that, in the case of custom
connectors, the bluetooth DT node will have the BT device described and in the
case of M.2, the device won't get described, but just the connector [1]. But for
the driver to identify the device (since it cannot enumerate it), either it has
to rely on DT/ACPI or some other means.
In the previous version of this series [2], I used the serdev ID based on the
product name for creating the serdev device and added a new id_table for serdev
driver to match with the device [3]. This almost duplicated the existing OF
match logic. Then Bartosz suggested to use swnode approach [4], to get rid of
the custom serdev ID based matching. When I prototyped, it mostly worked well,
except that swnode needed to have its own .device_get_match_data(), match() and
uevent/modalias functions. And if the swnode reused the existing DT compatible
string, it can work with the existing BT driver without modifications. And this
approach can also be extended to devices instantiated from the board specific
drivers.
[1] https://lore.kernel.org/all/20260110-pci-m2-e-v3-10-4faee7d0d5ae@oss.qualcomm.com/
[2] https://lore.kernel.org/all/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com/
[3] https://lore.kernel.org/all/20251125-pci-m2-e-v2-2-32826de07cc5@oss.qualcomm.com/
[4] https://lore.kernel.org/all/CAMRc=Mc-WebsQZ3jt2xirioNMticiWj9PJ3fsPTXGCeJ1iTLRg@mail.gmail.com/
> > Implement the .device_get_match_data fwnode callback, which helps to keep
> > the three backends of the fwnode API aligned as much as possible. This is
> > also a fundamental step to make a few drivers OF-independent truely
> > possible.
> >
> > Device drivers or platform setup codes are expected to provide a software
> > node string property, named as "compatible". At this moment, the value of
> > this string property is being used to match against the compatible entries
> > in the of_device_id table. It can be extended in the future though.
>
> I really do not want to see this patch without very good justification
> (note, there were at least two attempts in the past to add this stuff
> and no-one was merged, have you studied those cases?).
>
Yes I did. I didn't put the above justification in the cover letter, as it was
already overwhelmed with too much information regarding the connector node.
Maybe I should've added it in the comments section of this patch. But I didn't
know how to do that with b4.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback
From: Andy Shevchenko @ 2026-01-12 8:27 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Dmitry Torokhov, manivannan.sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Sui Jingfeng
In-Reply-To: <6l3rs5pv6xnrbygpvqrdxqoqtybjyefsltk5bl4336q56rfoza@ejo3sxuufghe>
On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> + Dmitry Torokhov (who was against this patch previously)
>
> On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> >
> > > Because the software node backend of the fwnode API framework lacks an
> > > implementation for the .device_get_match_data function callback.
> >
> > Maybe this is done on purpose. Have you thought about this aspect?
>
> IMO, software nodes were introduced to add sub-properties to the existing
> firmware nodes, but it has usecase/potential to go beyond that. More below.
Potential doesn't mean the necessity.
> > > This makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> >
> > How difficult? DSA implementation went to the way of taking DT overlay
> > approach. Why that one can't be applied here?
>
> Sometimes you do not have any DT node at all.
Yes, that is exactly the case I have referred to. The PCI core (in Linux)
is able to create DT subtree on non-OF based platforms.
> For example, in this series, the
> M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
> match it with the existing OF based BT driver (for non-M2 device). From the
> driver's point of view, a BT device attached to the M.2 slot and over custom
> connectors are both the same. Only difference is that, in the case of custom
> connectors, the bluetooth DT node will have the BT device described and in the
> case of M.2, the device won't get described, but just the connector [1].
So, what's the problem to add such a description? (Assuming you want a customisation
it can be done at run-time, correct?)
> But for the driver to identify the device (since it cannot enumerate it),
> either it has to rely on DT/ACPI or some other means.
Yes.
> In the previous version of this series [2], I used the serdev ID based on the
> product name for creating the serdev device and added a new id_table for serdev
> driver to match with the device [3]. This almost duplicated the existing OF
> match logic.
That's how we do when we want to add a board file, but thing is that we do not
want board files (only in the cases when other ways are impossible or make less
sense).
> Then Bartosz suggested to use swnode approach [4], to get rid of
> the custom serdev ID based matching. When I prototyped, it mostly worked well,
I know that Bart is fan of swnodes, but it should not be used as a silver
bullet, really.
> except that swnode needed to have its own .device_get_match_data(), match() and
> uevent/modalias functions. And if the swnode reused the existing DT compatible
> string, it can work with the existing BT driver without modifications. And this
> approach can also be extended to devices instantiated from the board specific
> drivers.
DT overlay should work without even modifications done to swnode code, right?
> [1] https://lore.kernel.org/all/20260110-pci-m2-e-v3-10-4faee7d0d5ae@oss.qualcomm.com/
> [2] https://lore.kernel.org/all/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com/
> [3] https://lore.kernel.org/all/20251125-pci-m2-e-v2-2-32826de07cc5@oss.qualcomm.com/
> [4] https://lore.kernel.org/all/CAMRc=Mc-WebsQZ3jt2xirioNMticiWj9PJ3fsPTXGCeJ1iTLRg@mail.gmail.com/
>
> > > Implement the .device_get_match_data fwnode callback, which helps to keep
> > > the three backends of the fwnode API aligned as much as possible. This is
> > > also a fundamental step to make a few drivers OF-independent truely
> > > possible.
> > >
> > > Device drivers or platform setup codes are expected to provide a software
> > > node string property, named as "compatible". At this moment, the value of
> > > this string property is being used to match against the compatible entries
> > > in the of_device_id table. It can be extended in the future though.
> >
> > I really do not want to see this patch without very good justification
> > (note, there were at least two attempts in the past to add this stuff
> > and no-one was merged, have you studied those cases?).
>
> Yes I did. I didn't put the above justification in the cover letter, as it was
> already overwhelmed with too much information regarding the connector node.
> Maybe I should've added it in the comments section of this patch. But I didn't
> know how to do that with b4.
Then you missed it. The cover letter for such a change is way too short.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 04/14] software node: Add software_node_match_device() API
From: Andy Shevchenko @ 2026-01-12 8:31 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi
In-Reply-To: <20260110-pci-m2-e-v3-4-4faee7d0d5ae@oss.qualcomm.com>
On Sat, Jan 10, 2026 at 12:26:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> Add software_node_match_device() API to match the swnode device with the
> swnode driver. The matching is based on the compatible property in the
> device and the driver's of_match_table.
NAK. swnodes != real firmware nodes.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 06/14] software node: Add software_node_device_modalias() API
From: Andy Shevchenko @ 2026-01-12 8:32 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi
In-Reply-To: <20260110-pci-m2-e-v3-6-4faee7d0d5ae@oss.qualcomm.com>
On Sat, Jan 10, 2026 at 12:26:24PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> Add software_node_device_modalias() API to return the MODALIAS string for
> swnode based on the swnode's compatible property.
NAK. swnodes != real firmware nodes.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 11/11] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree
From: Guodong Xu @ 2026-01-12 8:57 UTC (permalink / raw)
To: Yixun Lan
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Daniel Lezcano,
Thomas Gleixner, Samuel Holland, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen, Paul Walmsley,
Conor Dooley, Heinrich Schuchardt, Kevin Meng Zhang, Andrew Jones,
devicetree, linux-riscv, linux-kernel, spacemit, linux-serial
In-Reply-To: <20260110095707-GYA12783@gentoo.org>
Hi, Yixun
On Sat, Jan 10, 2026 at 5:57 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Guodong,
>
> I have a minor comment for the subject, it's kind of little bit redundant..
> so, how about (also apply to patch 10):
>
> [PATCH v4 10/11] riscv: dts: spacemit: add initial support for K3 SoC
> [PATCH v4 11/11] riscv: dts: spacemit: add K3 Pico-ITX board support
Thanks for the review. Sure, I can do it that way.
>
> On 13:18 Sat 10 Jan , Guodong Xu wrote:
> > K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
> > K3 SoC.
> >
> > This minimal device tree enables booting into a serial console with UART
> > output.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> > v4: No change.
> > v3: No change.
> > v2: Add aliases node in this board DT.
> > Update the memory node to reflect the hardware truth. Address
> > starts at 0x100000000 (4G) boundary.
> > ---
> > arch/riscv/boot/dts/spacemit/Makefile | 1 +
> > arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 38 ++++++++++++++++++++++++++++
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
> > index 95889e7269d1..7e2b87702571 100644
> > --- a/arch/riscv/boot/dts/spacemit/Makefile
> > +++ b/arch/riscv/boot/dts/spacemit/Makefile
> > @@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
> > dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
> > dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
> > dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
> > +dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
> > diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> > new file mode 100644
> > index 000000000000..037ce757e5bc
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
> > + * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
> strictly, should update to cover current year - which is 2026 now
Yes, that's a mistake. Happy New Year, 2026!
I will fix that.
>
> > + */
> > +
> > +#include "k3.dtsi"
> > +
> > +/ {
> > + model = "SpacemiT K3 Pico-ITX";
> > + compatible = "spacemit,k3-pico-itx", "spacemit,k3";
> > +
> > + aliases {
> > + serial0 = &uart0;
> ..
> > + serial2 = &uart2;
> > + serial3 = &uart3;
> > + serial4 = &uart4;
> > + serial5 = &uart5;
> > + serial6 = &uart6;
> > + serial7 = &uart7;
> > + serial8 = &uart8;
> > + serial9 = &uart9;
> > + serial10 = &uart10;
> I think we only add aliases for devices which actually enabled
Sure. I see your point.
There are different styles existing in the kernel dts. like sophgo, and thead.
I checked th1520-lichee-pi-4a.dts, which has aliases for serial0-5, but
only enables uart0 actually.
However, for SpacemiT convention, and several others, I see a different style.
In k1 boards, both k1-milkv-jupiter.dts and k1-bananapi-f3.dts only have the
serial0 alias, with only uart0 enabled.
For SpacemiT K3 boards, to follow the convention, I will remove the unused
aliases and fix that in my next version.
Best regards,
Guodong Xu
>
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0";
> > + };
> > +
> > + memory@100000000 {
> > + device_type = "memory";
> > + reg = <0x1 0x00000000 0x4 0x00000000>;
> > + };
> > +};
> > +
> > +&uart0 {
> > + status = "okay";
> > +};
> >
> > --
> > 2.43.0
> >
>
> --
>
> Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback
From: Manivannan Sadhasivam @ 2026-01-12 9:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, manivannan.sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Sui Jingfeng
In-Reply-To: <aWSwgRiEkT9unYw9@smile.fi.intel.com>
On Mon, Jan 12, 2026 at 10:27:45AM +0200, Andy Shevchenko wrote:
> On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > + Dmitry Torokhov (who was against this patch previously)
> >
> > On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > >
> > > > Because the software node backend of the fwnode API framework lacks an
> > > > implementation for the .device_get_match_data function callback.
> > >
> > > Maybe this is done on purpose. Have you thought about this aspect?
> >
> > IMO, software nodes were introduced to add sub-properties to the existing
> > firmware nodes, but it has usecase/potential to go beyond that. More below.
>
> Potential doesn't mean the necessity.
>
> > > > This makes it difficult to use(and/or test) a few drivers that originates
> > > > from DT world on the non-DT platform.
> > >
> > > How difficult? DSA implementation went to the way of taking DT overlay
> > > approach. Why that one can't be applied here?
> >
> > Sometimes you do not have any DT node at all.
>
> Yes, that is exactly the case I have referred to. The PCI core (in Linux)
> is able to create DT subtree on non-OF based platforms.
>
Maybe I should look into creating dynamic DT node for the device and insert it
to the uart node. Theoretically it should work.
> > For example, in this series, the
> > M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
> > match it with the existing OF based BT driver (for non-M2 device). From the
> > driver's point of view, a BT device attached to the M.2 slot and over custom
> > connectors are both the same. Only difference is that, in the case of custom
> > connectors, the bluetooth DT node will have the BT device described and in the
> > case of M.2, the device won't get described, but just the connector [1].
>
> So, what's the problem to add such a description? (Assuming you want a customisation
> it can be done at run-time, correct?)
>
> > But for the driver to identify the device (since it cannot enumerate it),
> > either it has to rely on DT/ACPI or some other means.
>
> Yes.
>
> > In the previous version of this series [2], I used the serdev ID based on the
> > product name for creating the serdev device and added a new id_table for serdev
> > driver to match with the device [3]. This almost duplicated the existing OF
> > match logic.
>
> That's how we do when we want to add a board file, but thing is that we do not
> want board files (only in the cases when other ways are impossible or make less
> sense).
>
> > Then Bartosz suggested to use swnode approach [4], to get rid of
> > the custom serdev ID based matching. When I prototyped, it mostly worked well,
>
> I know that Bart is fan of swnodes, but it should not be used as a silver
> bullet, really.
>
> > except that swnode needed to have its own .device_get_match_data(), match() and
> > uevent/modalias functions. And if the swnode reused the existing DT compatible
> > string, it can work with the existing BT driver without modifications. And this
> > approach can also be extended to devices instantiated from the board specific
> > drivers.
>
> DT overlay should work without even modifications done to swnode code, right?
>
Not from the overlay binaries (.dtbo), but adding dynamic BT node for the device
based on the enumerated PCI device should work.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] tty: replace use of system_unbound_wq with system_dfl_wq
From: Marco Crivellari @ 2026-01-12 9:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-serial, Tejun Heo, Lai Jiangshan,
Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko,
Jiri Slaby
In-Reply-To: <2026011107--0bfc@gregkh>
On Sun, Jan 11, 2026 at 11:26 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> [...]
> This isn't in my queue anymore, are you sure I didn't apply it (sorry,
> don't have access to my devel tree at the moment...)
>
> if not, can you resend it?
>
> thanks,
Hi Greg,
I checked, it is already applied!
Sorry for the noise.
Thanks!
--
Marco Crivellari
L3 Support Engineer
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: serial: 8250: Explicitly make LPC32xx UARTs compatible with 16550A
From: Krzysztof Kozlowski @ 2026-01-12 9:25 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lubomir Rintel, Piotr Wojtaszczyk, devicetree,
linux-serial, linux-arm-kernel
In-Reply-To: <20260110024647.3389345-2-vz@mleia.com>
On Sat, Jan 10, 2026 at 04:46:46AM +0200, Vladimir Zapolskiy wrote:
> NXP LPC32xx SoC has 4 16550A compatible UARTs with 64 byte TX and RX FIFO
> sizes, and the platform UART hardware is well supported as a standard
> 16550A UART.
Driver uses dedicated driver/match data, so some context here about
compatibility would be useful.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] dt-bindings: serial: sh-sci: Fold single-entry compatibles into enum
From: Prabhakar @ 2026-01-12 9:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: linux-kernel, linux-serial, devicetree, linux-renesas-soc,
Prabhakar, Biju Das, Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Group single compatibles into enum.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v1->v2:
- Dropped "- items:" to reduce indentation level.
- Added Reviewed-by tag.
---
.../devicetree/bindings/serial/renesas,scif.yaml | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index 72483bc3274d..a6ef02327be8 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -12,15 +12,16 @@ maintainers:
properties:
compatible:
oneOf:
+ - enum:
+ - renesas,scif-r7s9210 # RZ/A2
+ - renesas,scif-r9a07g044 # RZ/G2{L,LC}
+ - renesas,scif-r9a09g057 # RZ/V2H(P)
+
- items:
- enum:
- renesas,scif-r7s72100 # RZ/A1H
- const: renesas,scif # generic SCIF compatible UART
- - items:
- - enum:
- - renesas,scif-r7s9210 # RZ/A2
-
- items:
- enum:
- renesas,scif-r8a7778 # R-Car M1
@@ -76,10 +77,6 @@ properties:
- const: renesas,rcar-gen5-scif # R-Car Gen5
- const: renesas,scif # generic SCIF compatible UART
- - items:
- - enum:
- - renesas,scif-r9a07g044 # RZ/G2{L,LC}
-
- items:
- enum:
- renesas,scif-r9a07g043 # RZ/G2UL and RZ/Five
@@ -87,8 +84,6 @@ properties:
- renesas,scif-r9a08g045 # RZ/G3S
- const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback
- - const: renesas,scif-r9a09g057 # RZ/V2H(P)
-
- items:
- enum:
- renesas,scif-r9a09g047 # RZ/G3E
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 4/4 v2] serial: SH_SCI: improve "DMA support" prompt
From: Geert Uytterhoeven @ 2026-01-12 10:03 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, Greg Kroah-Hartman, Jiri Slaby, Geert Uytterhoeven,
linux-serial
In-Reply-To: <20260110232643.3533351-5-rdunlap@infradead.org>
On Sun, 11 Jan 2026 at 00:26, Randy Dunlap <rdunlap@infradead.org> wrote:
> Having a prompt of "DMA support" suddenly appear during a
> "make oldconfig" can be confusing. Add a little helpful text to
> the prompt message.
>
> Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> v2: make the prompt more like the other SH_SCI prompts (Geert)
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: serial: 8250: Explicitly make LPC32xx UARTs compatible with 16550A
From: Vladimir Zapolskiy @ 2026-01-12 10:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lubomir Rintel, Piotr Wojtaszczyk, devicetree,
linux-serial, linux-arm-kernel
In-Reply-To: <20260112-hopeful-spiffy-antelope-334765@quoll>
On 1/12/26 11:25, Krzysztof Kozlowski wrote:
> On Sat, Jan 10, 2026 at 04:46:46AM +0200, Vladimir Zapolskiy wrote:
>> NXP LPC32xx SoC has 4 16550A compatible UARTs with 64 byte TX and RX FIFO
>> sizes, and the platform UART hardware is well supported as a standard
>> 16550A UART.
>
> Driver uses dedicated driver/match data, so some context here about
> compatibility would be useful.
>
As the commit message says, 4 LPC32xx UARTs are NS16550A compatible, this
is the context of the change.
Any bootloader or operating system which does not locate "nxp,lpc3220-uart"
device driver shall use the general "ns16550" compatible device driver.
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Bartosz Golaszewski @ 2026-01-12 10:54 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Bartosz Golaszewski, Sui Jingfeng, manivannan.sadhasivam
In-Reply-To: <aWSq_7_5kkQIv9Hc@smile.fi.intel.com>
On Mon, 12 Jan 2026 09:04:15 +0100, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>>
[snip]
>> Though this series adds the relevant functionality for handling the M.2 Key M
>> connectors, there are still a few open questions exists on the design.
>>
>> 1. I've used the DT compatible for the serdev swnode to match the existing OF
>> device_id of the bluetooth driver. This avoids implementing custom serdev id
>> matching as implemented till v2.
>
> Yeah, swnodes are not designed to replace the real DT or other firmware
> interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> fixing up the broken or missed FW device properties). This should not have been
> done this way. Please, consider another approach, e.g. DT-overlay.
>
This may have been true historically but software nodes were introduced before
the auxiliary bus. With platform devices, the question has a clear response:
DT or ACPI first, then possibly additional software node. But with auxiliary
devices, where does the entirety of device properties come from if we - for
whatever reason - don't want to propagate any "real" firmware node?
This is not even about this particular series, rather it's a wider architecture
question.
Bartosz
^ permalink raw reply
* Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Bartosz Golaszewski @ 2026-01-12 10:59 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Andy Shevchenko, manivannan.sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi
In-Reply-To: <xbzcmhuebjlhsn7zumudeel7dbcmrslxcrxde23rgxrmvoy73h@aj6yxcpuzh46>
On Mon, 12 Jan 2026 08:55:21 +0100, Manivannan Sadhasivam
<mani@kernel.org> said:
> On Mon, Jan 12, 2026 at 09:50:33AM +0200, Andy Shevchenko wrote:
>> On Sat, Jan 10, 2026 at 12:26:20PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>>
>> > Add of_find_serdev_controller_by_node() API to find the serdev controller
>> > device associated with the devicetree node.
>>
>> Why OF-centric code? No, please do it fwnode-based.
>>
>
> No issues for me. But the existing APIs in serdev are OF based. If uniformity is
> not needed, I can change it to a fwnode based API.
>
Using fwnodes here shouldn't be an issue, even though serdev core assigns
dev->of_node, it will be converted to dev->fwnode when the device is registered.
Bart
^ permalink raw reply
* Re: [PATCH v3 04/14] software node: Add software_node_match_device() API
From: Bartosz Golaszewski @ 2026-01-12 11:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
manivannan.sadhasivam
In-Reply-To: <aWSxcJTLzBFbMGad@smile.fi.intel.com>
On Mon, 12 Jan 2026 09:31:44 +0100, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Sat, Jan 10, 2026 at 12:26:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>
>> Add software_node_match_device() API to match the swnode device with the
>> swnode driver. The matching is based on the compatible property in the
>> device and the driver's of_match_table.
>
> NAK. swnodes != real firmware nodes.
>
While I'm not arguing that this is *the* solution, I think it warrants
a discussion on proper matching of devices that are only backed by a software
node - for instance a serdev device on the auxiliary bus. I understand what
software nodes were historically but perhaps it's time to extend their role as
a full-blown firmware node allowing matching with drivers.
Reusing existing OF IDs is just one way, we could potentially think about a
high-level fwnode-based device to driver matching?
Bartosz
^ permalink raw reply
* Re: [PATCH v3 04/14] software node: Add software_node_match_device() API
From: Andy Shevchenko @ 2026-01-12 11:15 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, manivannan.sadhasivam
In-Reply-To: <CAMRc=Md6+hhLMOmmDejKW+_jbWu3_XB4qNobyi27pezfXsVLFw@mail.gmail.com>
On Mon, Jan 12, 2026 at 06:03:34AM -0500, Bartosz Golaszewski wrote:
> On Mon, 12 Jan 2026 09:31:44 +0100, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Sat, Jan 10, 2026 at 12:26:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> >
> >> Add software_node_match_device() API to match the swnode device with the
> >> swnode driver. The matching is based on the compatible property in the
> >> device and the driver's of_match_table.
> >
> > NAK. swnodes != real firmware nodes.
>
> While I'm not arguing that this is *the* solution, I think it warrants
> a discussion on proper matching of devices that are only backed by a software
> node - for instance a serdev device on the auxiliary bus. I understand what
> software nodes were historically but perhaps it's time to extend their role as
> a full-blown firmware node allowing matching with drivers.
>
> Reusing existing OF IDs is just one way, we could potentially think about a
> high-level fwnode-based device to driver matching?
There is already proposed and agree way to do that via DT overlays.
If one needs to describe the (PnP or hotpluggable) hardware, it's
the way to go as the HW maybe much complex than the just one small UART
appendix.
As per auxdevice, this should not be enumerable by compatible. The auxdevice
usually are created by other devices (from real ones) that _know_ the topology.
I don't see why we need to open the can of worms with the software nodes
to enumerate them as real ones.
P.S. Collect others' opinions (esp. device property reviewers and maintainers)
and we will see. But I do not see any even looking good justification for that.
It might be that I didn't get fully the use case and the other means can not
be used. But taking into account history of the rejection of the matching against
OF compatible string in swnodes suggests that this will stay the way it's now.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback
From: Konstantin Ryabitsev @ 2026-01-12 13:37 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Andy Shevchenko, Dmitry Torokhov, manivannan.sadhasivam,
Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Sui Jingfeng
In-Reply-To: <6l3rs5pv6xnrbygpvqrdxqoqtybjyefsltk5bl4336q56rfoza@ejo3sxuufghe>
On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > I really do not want to see this patch without very good justification
> > (note, there were at least two attempts in the past to add this stuff
> > and no-one was merged, have you studied those cases?).
> >
>
> Yes I did. I didn't put the above justification in the cover letter, as it was
> already overwhelmed with too much information regarding the connector node.
> Maybe I should've added it in the comments section of this patch. But I didn't
> know how to do that with b4.
You can just amend the commit directly and put comments under "---". They
will be preserved when email is sent, but won't be applied when the maintainer
pulls the series.
-K
^ permalink raw reply
* [PATCH v4 1/9] serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
From: Manivannan Sadhasivam via B4 Relay @ 2026-01-12 16:26 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
Cc: linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Manivannan Sadhasivam, Bartosz Golaszewski
In-Reply-To: <20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
If these helpers receive the 'const struct device' pointer, then the const
qualifier will get dropped, leading to below warning:
warning: passing argument 1 of ‘to_serdev_device_driver’ discards 'const'
qualifier from pointer target type [-Wdiscarded-qualifiers]
This is not an issue as of now, but with the future commits adding serdev
device based driver matching, this warning will get triggered. Hence,
convert these helpers to macros so that the qualifier get preserved and
also use container_of_const() as container_of() is deprecated.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
include/linux/serdev.h | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 34562eb99931..ecde0ad3e248 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -49,10 +49,7 @@ struct serdev_device {
struct mutex write_lock;
};
-static inline struct serdev_device *to_serdev_device(struct device *d)
-{
- return container_of(d, struct serdev_device, dev);
-}
+#define to_serdev_device(d) container_of_const(d, struct serdev_device, dev)
/**
* struct serdev_device_driver - serdev slave device driver
@@ -67,10 +64,7 @@ struct serdev_device_driver {
void (*remove)(struct serdev_device *);
};
-static inline struct serdev_device_driver *to_serdev_device_driver(struct device_driver *d)
-{
- return container_of(d, struct serdev_device_driver, driver);
-}
+#define to_serdev_device_driver(d) container_of_const(d, struct serdev_device_driver, driver)
enum serdev_parity {
SERDEV_PARITY_NONE,
@@ -111,10 +105,7 @@ struct serdev_controller {
const struct serdev_controller_ops *ops;
};
-static inline struct serdev_controller *to_serdev_controller(struct device *d)
-{
- return container_of(d, struct serdev_controller, dev);
-}
+#define to_serdev_controller(d) container_of_const(d, struct serdev_controller, dev)
static inline void *serdev_device_get_drvdata(const struct serdev_device *serdev)
{
--
2.48.1
^ permalink raw reply related
* [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam via B4 Relay @ 2026-01-12 16:26 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
Cc: linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Manivannan Sadhasivam
In-Reply-To: <20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Add of_find_serdev_controller_by_node() API to find the serdev controller
device associated with the devicetree node.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/tty/serdev/core.c | 16 ++++++++++++++++
include/linux/serdev.h | 9 +++++++++
2 files changed, 25 insertions(+)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index b33e708cb245..25382c2d63e6 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
}
EXPORT_SYMBOL_GPL(serdev_controller_alloc);
+/**
+ * of_find_serdev_controller_by_node() - Find the serdev controller associated
+ * with the devicetree node
+ * @node: Devicetree node
+ *
+ * Return: Pointer to the serdev controller associated with the node. NULL if
+ * the controller is not found.
+ */
+struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
+{
+ struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
+
+ return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
+}
+EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
+
static int of_serdev_register_devices(struct serdev_controller *ctrl)
{
struct device_node *node;
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index ecde0ad3e248..db9bfaba0662 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -333,4 +333,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
}
#endif /* CONFIG_ACPI */
+#ifdef CONFIG_OF
+struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
+#else
+struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
#endif /*_LINUX_SERDEV_H */
--
2.48.1
^ permalink raw reply related
* [PATCH v4 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Manivannan Sadhasivam via B4 Relay @ 2026-01-12 16:25 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
Cc: linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Manivannan Sadhasivam, Bartosz Golaszewski
Hi,
This series is the continuation of the series [1] that added the initial support
for the PCIe M.2 connectors. This series extends it by adding support for Key E
connectors. These connectors are used to connect the Wireless Connectivity
devices such as WiFi, BT, NFC and GNSS devices to the host machine over
interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
connectors that expose PCIe interface for WiFi and UART interface for BT. Other
interfaces are left for future improvements.
Serdev device support for BT
============================
Adding support for the PCIe interface was mostly straightforward and a lot
similar to the previous Key M connector. But adding UART interface has proved to
be tricky. This is mostly because of the fact UART is a non-discoverable bus,
unlike PCIe which is discoverable. So this series relied on the PCI notifier to
create the serdev device for UART/BT. This means the PCIe interface will be
brought up first and after the PCIe device enumeration, the serdev device will
be created by the pwrseq driver. This logic is necessary since the connector
driver and DT node don't describe the device, but just the connector. So to make
the connector interface Plug and Play, the connector driver uses the PCIe device
ID to identify the card and creates the serdev device. This logic could be
extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
interface for connecting WLAN, a SDIO notifier could be added to create the
serdev device.
Open questions
==============
Though this series adds the relevant functionality for handling the M.2 Key M
connectors, there are still a few open questions exists on the design.
1. Created a dynamic 'bluetooth' node with the compatible property matching the
WCN7850 device and attached it to the serdev device. This allowed reusing the
existing OF based BT driver without much modifications.
2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
the PCIe device DT node to extract properties such as
'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
add the PCIe DT node in the Root Port in conjunction with the Port node as
below?
pcie@0 {
wifi@0 {
compatible = "pci17cb,1103";
...
qcom,calibration-variant = "LE_X13S";
};
port {
pcie4_port0_ep: endpoint {
remote-endpoint = <&m2_e_pcie_ep>;
};
};
};
This will also require marking the PMU supplies optional in the relevant ath
bindings for M.2 cards.
3. Some M.2 cards require specific power up sequence like delays between
regulator/GPIO and such. For instance, the WCN7850 card supported in this series
requires 50ms delay between powering up an interface and driving it. I've just
hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
driver doesn't know anything about the device it is dealing with before powering
it ON, how should it handle the device specific power requirements? Should we
hardcode the device specific property in the connector node? But then, it will
no longer become a generic M.2 connector and sort of defeats the purpose of the
connector binding.
I hope to address these questions with the help of the relevant subsystem
maintainers and the community.
Testing
=======
This series, together with the devicetree changes [2] was tested on the
Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
1620 LGA card connected over PCIe and UART.
Dependency
==========
This series is dependent on the M.2 Key M series [1] on top of v6.19-rc1.
[1] https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com
[2] https://github.com/Mani-Sadhasivam/linux/commit/753033861360171f2af1fdd56e8985ff916e1ac2
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Changes in v4:
- Switched to dynamic OF node for serdev instead of swnode and dropped all
swnode related patches
- Link to v3: https://lore.kernel.org/r/20260110-pci-m2-e-v3-0-4faee7d0d5ae@oss.qualcomm.com
Changes in v3:
- Switched to swnode for the serdev device and dropped the custom
serdev_device_id related patches
- Added new swnode APIs to match the swnode with existing of_device_id
- Incorporated comments in the bindings patch
- Dropped the UIM interface from binding since it is not clear how it should get
wired
- Incorporated comments in the pwrseq driver patch
- Splitted the pwrseq patch into two
- Added the 1620 LGA compatible with Key E fallback based on Stephan's finding
- Link to v2: https://lore.kernel.org/r/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com
Changes in v2:
- Used '-' for GPIO names in the binding and removed led*-gpios properties
- Described the endpoint nodes for port@0 and port@1 nodes
- Added the OF graph port to the serial binding
- Fixed the hci_qca driver to return err if devm_pwrseq_get() fails
- Incorporated various review comments in pwrseq driver
- Collected Ack
- Link to v1: https://lore.kernel.org/r/20251112-pci-m2-e-v1-0-97413d6bf824@oss.qualcomm.com
---
Manivannan Sadhasivam (9):
serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
serdev: Add an API to find the serdev controller associated with the devicetree node
serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
dt-bindings: serial: Document the graph port
dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
.../bindings/connector/pcie-m2-e-connector.yaml | 161 ++++++++++++
.../devicetree/bindings/serial/serial.yaml | 3 +
MAINTAINERS | 1 +
drivers/bluetooth/hci_qca.c | 9 +
drivers/power/sequencing/Kconfig | 1 +
drivers/power/sequencing/pwrseq-pcie-m2.c | 278 ++++++++++++++++++++-
drivers/tty/serdev/core.c | 25 +-
include/linux/serdev.h | 24 +-
8 files changed, 482 insertions(+), 20 deletions(-)
---
base-commit: cb6649f6217c0331b885cf787f1d175963e2a1d2
change-id: 20251112-pci-m2-e-94695ac9d657
prerequisite-message-id: 20251125-pci-m2-v3-0-c528042aea47@oss.qualcomm.com
prerequisite-patch-id: 58778d8eb97ab86008cd48fb5d28ed6cc0bbbc1b
prerequisite-patch-id: 2dd7d793a67f59ef6e6b5137e69436896198b965
prerequisite-patch-id: 8ccaa5fdd95e64e69cd942f93c26e89b827d0453
prerequisite-patch-id: 3d3e1bb7959ab1e140c5024acdd8655e7a7e99ef
Best regards,
--
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 3/9] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
From: Manivannan Sadhasivam via B4 Relay @ 2026-01-12 16:26 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
Cc: linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Manivannan Sadhasivam, Bartosz Golaszewski
In-Reply-To: <20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
If an external connector like M.2 is connected to the serdev controller
in DT, then the serdev devices may be created dynamically by the connector
driver. So do not return -ENODEV from of_serdev_register_devices() if the
static nodes are not found and the graph node is used.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/tty/serdev/core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 25382c2d63e6..f8093b606dda 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/of_device.h>
#include <linux/pm_domain.h>
#include <linux/pm_runtime.h>
@@ -548,7 +549,13 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
} else
found = true;
}
- if (!found)
+
+ /*
+ * When the serdev controller is connected to an external connector like
+ * M.2 in DT, then the serdev devices may be created dynamically by the
+ * connector driver.
+ */
+ if (!found && !of_graph_is_present(ctrl->dev.of_node))
return -ENODEV;
return 0;
--
2.48.1
^ permalink raw reply related
* [PATCH v4 4/9] dt-bindings: serial: Document the graph port
From: Manivannan Sadhasivam via B4 Relay @ 2026-01-12 16:26 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
Cc: linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Manivannan Sadhasivam
In-Reply-To: <20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
A serial controller could be connected to an external connector like PCIe
M.2 for controlling the serial interface of the card. Hence, document the
OF graph port.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Documentation/devicetree/bindings/serial/serial.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
index 6aa9cfae417b..96eb1de8771e 100644
--- a/Documentation/devicetree/bindings/serial/serial.yaml
+++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -87,6 +87,9 @@ properties:
description:
TX FIFO threshold configuration (in bytes).
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
patternProperties:
"^(bluetooth|bluetooth-gnss|embedded-controller|gnss|gps|mcu|onewire)$":
if:
--
2.48.1
^ permalink raw reply related
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