* [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
* Re: [PATCH v4 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
From: Guodong Xu @ 2026-01-12 8:14 UTC (permalink / raw)
To: Yixun Lan
Cc: Inochi Amaoto, 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: <20260110110502-GYB12783@gentoo.org>
Hi, Yixun and Inochi
On Sat, Jan 10, 2026 at 7:05 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Guodong,
>
> On 18:00 Sat 10 Jan , Inochi Amaoto wrote:
> > On Sat, Jan 10, 2026 at 01:18:22PM +0800, Guodong Xu wrote:
> > > SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
> > > Add nodes of uarts, timer and interrupt-controllers.
> > >
> > > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > > ---
> > > v4: Fix missing blank space after commas in compatible string.
> > > Add m-mode imsic and aplic node.
> > > Reorder properties in simsic, saplic, mimsic, and maplic nodes
> > > to match DTS coding style.
> > > v3: Remove "supm" from the riscv,isa-extensions list.
> > > v2: Remove aliases from k3.dtsi, they should be in board DTS.
> > > Updated riscv,isa-extensions with new extensions from the extensions.yaml.
> > > ---
> > > arch/riscv/boot/dts/spacemit/k3.dtsi | 590 +++++++++++++++++++++++++++++++++++
> > > 1 file changed, 590 insertions(+)
> > >
> > > diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > > new file mode 100644
> > > index 000000000000..a815f85cf5a6
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > > @@ -0,0 +1,590 @@
> ...
> > > + d-cache-sets = <256>;
> > > + next-level-cache = <&l2_cache0>;
> >
> > > + mmu-type = "riscv,sv39";
> >
> > I think this should be riscv,sv48? IIRC K3 supports it.
You are right that the underlying X100 IP core is capable of supporting
both SV39 and SV48. However, not K3.
> >
> I would second the idea here, if the underlying hardware support sv48,
> there is no reason we should limit it in DTS, DT should reflect the actual
> hardware.. if user still prefer to use sv39 for simplicity, a "no4lvl"
> command line argument can be passed.. see
> arch/riscv/mm/init.c +860 -> set_satp_mode()
I have double-checked with SpacemiT, according to SpacemiT, while the X100
core itself supports both SV39 and SV48, when it was integrated into the K3
SoC, it was specifically configured to support only SV39.
In this case, the K3 SoC's MMU is configured for SV39 only, so mmu-type =
"riscv,sv39" is the correct representation.
Best regards,
Guodong Xu
>
> --
> Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v3 05/14] software node: Add software_node_device_uevent() API
From: Andy Shevchenko @ 2026-01-12 8:09 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-5-4faee7d0d5ae@oss.qualcomm.com>
On Sat, Jan 10, 2026 at 12:26:23PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> Add software_node_device_uevent() API to return the uevent variable for
> swnode using the DT compatible property. The uevent will have the DT prefix
> of "of:N*T*C" to match the DT's module device table.
This even sounds wrong.
NAK.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Andy Shevchenko @ 2026-01-12 8:06 UTC (permalink / raw)
To: Manivannan Sadhasivam
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
In-Reply-To: <xbzcmhuebjlhsn7zumudeel7dbcmrslxcrxde23rgxrmvoy73h@aj6yxcpuzh46>
On Mon, Jan 12, 2026 at 01:25:21PM +0530, Manivannan Sadhasivam wrote:
> 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.
Really? serdev.h has no OF APIs.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-01-12 8:04 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,
Bartosz Golaszewski, Sui Jingfeng
In-Reply-To: <20260110-pci-m2-e-v3-0-4faee7d0d5ae@oss.qualcomm.com>
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.
> 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 v4 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
From: Guodong Xu @ 2026-01-12 7:59 UTC (permalink / raw)
To: Maud Spierings
Cc: ajones, alex, anup, aou, conor+dt, conor, cyy, daniel.lezcano,
devicetree, dlan, gregkh, jirislaby, krzk+dt, linux-kernel,
linux-riscv, linux-serial, lkundrak, palmer, paul.walmsley, pjw,
robh, samuel.holland, spacemit, tglx, xypron.glpk,
zhangmeng.kevin
In-Reply-To: <AM7P189MB10095424D5EECEF98761C227E381A@AM7P189MB1009.EURP189.PROD.OUTLOOK.COM>
On Mon, Jan 12, 2026 at 3:43 PM Maud Spierings
<maud_spierings@hotmail.com> wrote:
>
> > + mimsic: interrupt-controller@f1000000 {
> > + compatible = "spacemit,k3-imsics", "riscv,imsics";
> > + reg = <0x0 0xf1000000 0x0 0x10000>;
> > + #interrupt-cells = <0>;
> > + #msi-cells = <0>;
> > + interrupt-controller;
> > + interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>,
> > + <&cpu2_intc 11>, <&cpu3_intc 11>,
> > + <&cpu4_intc 11>, <&cpu5_intc 11>,
> > + <&cpu6_intc 11>, <&cpu7_intc 11>;
> > + msi-controller;
> > + riscv,guest-index-bits = <6>;
> > + riscv,hart-index-bits = <4>;
> > + riscv,num-guest-ids = <511>;
> > + riscv,num-ids = <511>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + maplic: interrupt-controller@f1800000 {
> > + compatible = "spacemit,k3-aplic", "riscv,aplic";
> > + reg = <0x0 0xf1800000 0x0 0x4000>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + msi-parent = <&mimsic>;
> > + riscv,children = <&saplic>;
> > + riscv,delegate = <&saplic 1 512>;
> > + riscv,num-sources = <512>;
> > +
> > + status = "disabled";
> > + };
>
>
> from reading the chatter on v3 I think the right status here may be
> "reserved", for elements that are reserved by firmware. But I could be
> mistaken.
Thanks Maud. Good catch. I think you are right, both M-mode maplic and mimsic
should be listed as "reserved" to signify that they are intended to be used
in OpenSBI, not the S-mode kernel.
I will fix that in the next version.
BR,
Guodong Xu
>
> Kind regards,
> Maud
^ permalink raw reply
* Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback
From: Andy Shevchenko @ 2026-01-12 7:56 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, Sui Jingfeng
In-Reply-To: <20260110-pci-m2-e-v3-3-4faee7d0d5ae@oss.qualcomm.com>
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?
> 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?
> 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?).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam @ 2026-01-12 7:55 UTC (permalink / raw)
To: Andy Shevchenko
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
In-Reply-To: <aWSnyc8Eiq56ckXB@smile.fi.intel.com>
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.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Andy Shevchenko @ 2026-01-12 7:50 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-2-4faee7d0d5ae@oss.qualcomm.com>
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.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
From: Maud Spierings @ 2026-01-12 7:42 UTC (permalink / raw)
To: guodong
Cc: ajones, alex, anup, aou, conor+dt, conor, cyy, daniel.lezcano,
devicetree, dlan, gregkh, jirislaby, krzk+dt, linux-kernel,
linux-riscv, linux-serial, lkundrak, palmer, paul.walmsley, pjw,
robh, samuel.holland, spacemit, tglx, xypron.glpk,
zhangmeng.kevin
In-Reply-To: <20260110-k3-basic-dt-v4-10-d492f3a30ffa@riscstar.com>
> + mimsic: interrupt-controller@f1000000 {
> + compatible = "spacemit,k3-imsics", "riscv,imsics";
> + reg = <0x0 0xf1000000 0x0 0x10000>;
> + #interrupt-cells = <0>;
> + #msi-cells = <0>;
> + interrupt-controller;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>,
> + <&cpu2_intc 11>, <&cpu3_intc 11>,
> + <&cpu4_intc 11>, <&cpu5_intc 11>,
> + <&cpu6_intc 11>, <&cpu7_intc 11>;
> + msi-controller;
> + riscv,guest-index-bits = <6>;
> + riscv,hart-index-bits = <4>;
> + riscv,num-guest-ids = <511>;
> + riscv,num-ids = <511>;
> +
> + status = "disabled";
> + };
> +
> + maplic: interrupt-controller@f1800000 {
> + compatible = "spacemit,k3-aplic", "riscv,aplic";
> + reg = <0x0 0xf1800000 0x0 0x4000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&mimsic>;
> + riscv,children = <&saplic>;
> + riscv,delegate = <&saplic 1 512>;
> + riscv,num-sources = <512>;
> +
> + status = "disabled";
> + };
from reading the chatter on v3 I think the right status here may be
"reserved", for elements that are reserved by firmware. But I could be
mistaken.
Kind regards,
Maud
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: input: google,goldfish-events-keypad: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-12 7:22 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <aWPUwCbFoIItG7n3@google.com>
On 11/01/2026 17:50, Kuan-Wei Chiu wrote:
> Hi Krzysztof,
>
> On Fri, Jan 09, 2026 at 09:23:33AM +0100, Krzysztof Kozlowski wrote:
>> On Thu, Jan 08, 2026 at 08:08:33AM +0000, Kuan-Wei Chiu wrote:
>>> +
>>> +examples:
>>> + - |
>>> + keypad@9040000 {
>>> + compatible = "google,goldfish-events-keypad";
>>> + reg = <0x9040000 0x1000>;
>>> + interrupts = <0x5>;
>>
>> Same comment as before. It applies everywhere, btw.
>
> Oops, I actually had a local fixup for this but forgot to apply it
> before sending. Sorry about that.
>
> On a side note, none of your replies regarding v2 appeared in my inbox
> or spam folder. I had to retrieve this message content from the lore
> web interface to reply. However, your replies to v1 arrived without any
> issues.
I think this was issue on oss.qualcomm.com side, because email did not
reach my other mailbox either.
Well, Gmail sucks a lot and brings a lot of pain for all other people
(e.g. LF infrastructure), so if switching maybe avoid Gmail...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] serial: 8250_pci: Fix broken RS485 for F81504/508/512
From: Marnix Rijnart @ 2026-01-12 0:08 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-serial, regressions, Marnix Rijnart, stable
Fintek F81504/508/512 can support both RTS_ON_SEND and RTS_AFTER_SEND,
but pci_fintek_rs485_supported only announces the former.
This makes it impossible to unset SER_RS485_RTS_ON_SEND from
userspace because of uart_sanitize_serial_rs485(). Some devices
with these chips need RTS low on TX, so they are effectively broken.
Fix this by announcing the support for SER_RS485_RTS_AFTER_SEND,
similar to commit 068d35a7be65 ("serial: sc16is7xx: announce support
for SER_RS485_RTS_ON_SEND").
Fixes: 4afeced55baa ("serial: core: fix sanitizing check for RTS settings")
Cc: stable@vger.kernel.org
Signed-off-by: Marnix Rijnart <marnix.rijnart@iwell.eu>
---
Changes in v3:
- Rewrite commit message to clarify problem
- Use longer commit hashes
- v2: https://patch.msgid.link/20260111135933.31316-1-marnix.rijnart@iwell.eu
Changes in v2:
- Added fixes tags
- Cc stable
- v1: https://patch.msgid.link/20250923221756.26770-1-marnix.rijnart@iwell.eu
---
drivers/tty/serial/8250/8250_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 152f914c599d..a9da222bd174 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1645,7 +1645,7 @@ static int pci_fintek_rs485_config(struct uart_port *port, struct ktermios *term
}
static const struct serial_rs485 pci_fintek_rs485_supported = {
- .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
+ .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RTS_AFTER_SEND,
/* F81504/508/512 does not support RTS delay before or after send */
};
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 3/6] dt-bindings: input: google,goldfish-events-keypad: Convert to DT schema
From: Kuan-Wei Chiu @ 2026-01-11 16:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260109-remarkable-crane-of-exercise-6bc17f@quoll>
Hi Krzysztof,
On Fri, Jan 09, 2026 at 09:23:33AM +0100, Krzysztof Kozlowski wrote:
> On Thu, Jan 08, 2026 at 08:08:33AM +0000, Kuan-Wei Chiu wrote:
> > +
> > +examples:
> > + - |
> > + keypad@9040000 {
> > + compatible = "google,goldfish-events-keypad";
> > + reg = <0x9040000 0x1000>;
> > + interrupts = <0x5>;
>
> Same comment as before. It applies everywhere, btw.
Oops, I actually had a local fixup for this but forgot to apply it
before sending. Sorry about that.
On a side note, none of your replies regarding v2 appeared in my inbox
or spam folder. I had to retrieve this message content from the lore
web interface to reply. However, your replies to v1 arrived without any
issues.
The only difference I noticed is the sender address:
v1 came from <krzk@kernel.org>,
while v2 came from <krzysztof.kozlowski@oss.qualcomm.com>.
I suspect gmail might be silently dropping the latter due to some check?
I'm not familiar with the email protocols, but perhaps it really is time
for me to start looking for a gmail alternative... even though I see many
entries in MAINTAINERS still using gmail.com addresses.
Regards,
Kuan-Wei
^ permalink raw reply
* Re: [PATCH v4 14/15] dt-bindings: arm: AT91: document EV23X71A board
From: claudiu beznea @ 2026-01-11 14:46 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov
In-Reply-To: <20251229184004.571837-15-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Microchip EV23X71A board is an LAN9696 based evaluation board.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 11/15] dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
From: claudiu beznea @ 2026-01-11 14:46 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-12-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Document LAN969x compatibles for SGPIO.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
> Acked-by: Conor Dooley<conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 10/15] dt-bindings: net: mscc-miim: add microchip,lan9691-miim
From: claudiu beznea @ 2026-01-11 14:45 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-11-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Document Microchip LAN969x MIIM compatible.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
> Acked-by: Conor Dooley<conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 09/15] dt-bindings: dma: atmel: add microchip,lan9691-dma
From: claudiu beznea @ 2026-01-11 14:45 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov
In-Reply-To: <20251229184004.571837-10-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Document Microchip LAN969x DMA compatible which is compatible to SAMA7G5.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 08/15] dt-bindings: crypto: atmel,at91sam9g46-sha: add microchip,lan9691-sha
From: claudiu beznea @ 2026-01-11 14:45 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-9-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Document Microchip LAN969x SHA compatible.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
> Acked-by: Conor Dooley<conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 07/15] dt-bindings: crypto: atmel,at91sam9g46-aes: add microchip,lan9691-aes
From: claudiu beznea @ 2026-01-11 14:44 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-8-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Document Microchip LAN969x AES compatible.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
> Acked-by: Conor Dooley<conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 03/15] dt-bindings: serial: atmel,at91-usart: add microchip,lan9691-usart
From: claudiu beznea @ 2026-01-11 14:44 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-4-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Document Microchip LAN969x USART compatible.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
> Acked-by: Conor Dooley<conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 02/15] dt-bindings: mfd: atmel,sama5d2-flexcom: add microchip,lan9691-flexcom
From: claudiu beznea @ 2026-01-11 14:43 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-3-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> Add binding documentation for Microchip LAN969x.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
> Acked-by: Conor Dooley<conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v4 15/15] arm64: dts: microchip: add EV23X71A board
From: claudiu beznea @ 2026-01-11 14:42 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov
In-Reply-To: <20251229184004.571837-16-robert.marko@sartura.hr>
Hi, Robert,
On 12/29/25 20:37, Robert Marko wrote:
> Microchip EV23X71A is an LAN9696 based evaluation board.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> ---
> Changes in v2:
> * Split from SoC DTSI commit
> * Apply DTS coding style
> * Enclose array in i2c-mux
> * Alphanumericaly sort nodes
> * Change management port mode to RGMII-ID
>
> arch/arm64/boot/dts/microchip/Makefile | 1 +
> .../boot/dts/microchip/lan9696-ev23x71a.dts | 757 ++++++++++++++++++
> 2 files changed, 758 insertions(+)
> create mode 100644 arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
>
> diff --git a/arch/arm64/boot/dts/microchip/Makefile b/arch/arm64/boot/dts/microchip/Makefile
> index c6e0313eea0f..09d16fc1ce9a 100644
> --- a/arch/arm64/boot/dts/microchip/Makefile
> +++ b/arch/arm64/boot/dts/microchip/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_LAN969X) += lan9696-ev23x71a.dtb
> dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb125.dtb
> dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb134.dtb sparx5_pcb134_emmc.dtb
> dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb135.dtb sparx5_pcb135_emmc.dtb
> diff --git a/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts b/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
> new file mode 100644
> index 000000000000..435df455b078
> --- /dev/null
> +++ b/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
[ ...]
> +&gpio {
> + emmc_sd_pins: emmc-sd-pins {
> + /* eMMC_SD - CMD, CLK, D0, D1, D2, D3, D4, D5, D6, D7, RSTN */
> + pins = "GPIO_14", "GPIO_15", "GPIO_16", "GPIO_17",
> + "GPIO_18", "GPIO_19", "GPIO_20", "GPIO_21",
> + "GPIO_22", "GPIO_23", "GPIO_24";
> + function = "emmc_sd";
> + };
> +
> + fan_pins: fan-pins {
> + pins = "GPIO_25", "GPIO_26";
> + function = "fan";
> + };
> +
> + fc0_pins: fc0-pins {
> + pins = "GPIO_3", "GPIO_4";
> + function = "fc";
> + };
> +
> + fc2_pins: fc2-pins {
> + pins = "GPIO_64", "GPIO_65", "GPIO_66";
> + function = "fc";
> + };
> +
> + fc3_pins: fc3-pins {
> + pins = "GPIO_55", "GPIO_56";
> + function = "fc";
> + };
> +
> + mdio_pins: mdio-pins {
> + pins = "GPIO_9", "GPIO_10";
> + function = "miim";
> + };
> +
> + mdio_irq_pins: mdio-irq-pins {
> + pins = "GPIO_11";
> + function = "miim_irq";
> + };
> +
> + sgpio_pins: sgpio-pins {
> + /* SCK, D0, D1, LD */
> + pins = "GPIO_5", "GPIO_6", "GPIO_7", "GPIO_8";
> + function = "sgpio_a";
> + };
> +
> + usb_ulpi_pins: usb-ulpi-pins {
> + pins = "GPIO_30", "GPIO_31", "GPIO_32", "GPIO_33",
> + "GPIO_34", "GPIO_35", "GPIO_36", "GPIO_37",
> + "GPIO_38", "GPIO_39", "GPIO_40", "GPIO_41";
> + function = "usb_ulpi";
> + };
> +
> + usb_rst_pins: usb-rst-pins {
> + pins = "GPIO_12";
> + function = "usb2phy_rst";
> + };
> +
> + usb_over_pins: usb-over-pins {
> + pins = "GPIO_13";
> + function = "usb_over_detect";
> + };
> +
> + usb_power_pins: usb-power-pins {
> + pins = "GPIO_1";
> + function = "usb_power";
> + };
> +
> + ptp_out_pins: ptp-out-pins {
> + pins = "GPIO_58";
> + function = "ptpsync_4";
> + };
Could you please move this one upper to have all the entries in the gpio
container alphanumerically sorted?
> +
> + ptp_ext_pins: ptp-ext-pins {
> + pins = "GPIO_59";
> + function = "ptpsync_5";
> + };
Same here.
[ ...]
> + port29: port@29 {
> + reg = <29>;
> + phys = <&serdes 11>;
> + phy-handle = <&phy3>;
> + phy-mode = "rgmii-id";
> + microchip,bandwidth = <1000>;
There are some questions around this node from Andrew in v1 of this series,
which I don't see an answer for in any of the following versions. Could you
please clarify?
The rest looks good to me.
Thank you,
Claudiu
^ permalink raw reply
* Re: [PATCH v4 12/15] arm64: dts: microchip: add LAN969x clock header file
From: claudiu beznea @ 2026-01-11 14:42 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb
Cc: luka.perkov
In-Reply-To: <20251229184004.571837-13-robert.marko@sartura.hr>
On 12/29/25 20:37, Robert Marko wrote:
> LAN969x uses hardware clock indexes, so document theses in a header to make
> them humanly readable.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> ---
> Changes in v4:
> * Move clock indexes from dt-bindings to a DTS header
>
> Changes in v2:
> * Rename file to microchip,lan9691.h
>
> arch/arm64/boot/dts/microchip/clk-lan9691.h | 24 +++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 arch/arm64/boot/dts/microchip/clk-lan9691.h
>
> diff --git a/arch/arm64/boot/dts/microchip/clk-lan9691.h b/arch/arm64/boot/dts/microchip/clk-lan9691.h
> new file mode 100644
> index 000000000000..f0006a603747
> --- /dev/null
> +++ b/arch/arm64/boot/dts/microchip/clk-lan9691.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
Shouldn't this use the same license as the dtsi including it?
> +
> +#ifndef _DTS_CLK_LAN9691_H
> +#define _DTS_CLK_LAN9691_H
> +
> +#define GCK_ID_QSPI0 0
> +#define GCK_ID_QSPI2 1
> +#define GCK_ID_SDMMC0 2
> +#define GCK_ID_SDMMC1 3
> +#define GCK_ID_MCAN0 4
> +#define GCK_ID_MCAN1 5
> +#define GCK_ID_FLEXCOM0 6
> +#define GCK_ID_FLEXCOM1 7
> +#define GCK_ID_FLEXCOM2 8
> +#define GCK_ID_FLEXCOM3 9
> +#define GCK_ID_TIMER 10
> +#define GCK_ID_USB_REFCLK 11
> +
> +/* Gate clocks */
> +#define GCK_GATE_USB_DRD 12
> +#define GCK_GATE_MCRAMC 13
> +#define GCK_GATE_HMATRIX 14
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v2] serial: 8250_pci: Fix broken RS485 for F81504/508/512
From: Greg Kroah-Hartman @ 2026-01-11 14:16 UTC (permalink / raw)
To: Marnix Rijnart
Cc: Jiri Slaby, linux-kernel, linux-serial, regressions, stable
In-Reply-To: <20260111135933.31316-1-marnix.rijnart@iwell.eu>
On Sun, Jan 11, 2026 at 02:59:17PM +0100, Marnix Rijnart wrote:
> v1: https://patch.msgid.link/20250923221756.26770-1-marnix.rijnart@iwell.eu
> Changes:
> * Added fixes tags
> * Cc stable
>
> Commit 4afeced ("serial: core: fix sanitizing check for RTS settings")
Please use more digits here, "4afeced55baa", like you did in the Fixes:
lines.
> introduced a regression making it impossible to unset
> SER_RS485_RTS_ON_SEND from userspace if SER_RS485_RTS_AFTER_SEND is
> unsupported. Because these devices need RTS to be low on TX (fecf27a)
> they are effectively broken.
>
> The hardware supports both RTS_ON_SEND and RTS_AFTER_SEND,
> so fix this by announcing support for SER_RS485_RTS_AFTER_SEND,
> similar to commit 068d35a.
You can line-wrap at 72 columns, and again, use more digits for the
commit, and spell out the full name of the commit.
> Fixes: 4afeced55baa ("serial: core: fix sanitizing check for RTS settings")
> Fixes: fecf27a373f5 ("serial: 8250_pci: add RS485 for F81504/508/512")
> Cc: stable@vger.kernel.org
So where does this need to be backported to, where the first commit is,
or the second?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] serial: 8250_pci: Fix broken RS485 for F81504/508/512
From: Greg Kroah-Hartman @ 2026-01-11 14:14 UTC (permalink / raw)
To: Marnix Rijnart
Cc: Jiri Slaby, linux-kernel, linux-serial, regressions, stable
In-Reply-To: <20260111135933.31316-1-marnix.rijnart@iwell.eu>
On Sun, Jan 11, 2026 at 02:59:17PM +0100, Marnix Rijnart wrote:
> v1: https://patch.msgid.link/20250923221756.26770-1-marnix.rijnart@iwell.eu
> Changes:
> * Added fixes tags
> * Cc stable
This needs to go below the --- line, so that it doesn't show up in the
changelog. The in-kernel documentation should explain this.
thanks,
greg k-h
^ 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