* [PATCH] tty: n_tty: fix KCSAN data-race in n_tty_flush_buffer / n_tty_lookahead_flow_ctrl
From: Osama Abdelkader @ 2026-02-11 21:08 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Ilpo Järvinen, linux-kernel, linux-serial
Cc: Osama Abdelkader, syzbot+80806cf7508e92c7cc86
n_tty_lookahead_flow_ctrl() accesses ldata->lookahead_count without
holding termios_rwsem, while reset_buffer_flags() in n_tty_flush_buffer()
resets it with exclusive termios_rwsem held. This causes a data race
reported by KCSAN when a PTY is closed while flush_to_ldisc is still
processing lookahead data.
Fix by taking termios_rwsem (read) in n_tty_lookahead_flow_ctrl(),
consistent with __receive_buf() which also modifies lookahead_count
under the read lock.
Reported-by: syzbot+80806cf7508e92c7cc86@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=80806cf7508e92c7cc86
Fixes: 6bb6fa6908eb ("tty: Implement lookahead to process XON/XOFF timely")
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
drivers/tty/n_tty.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index e6a0f5b40d0a..725d6ed2b863 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1480,6 +1480,8 @@ static void n_tty_lookahead_flow_ctrl(struct tty_struct *tty, const u8 *cp,
struct n_tty_data *ldata = tty->disc_data;
u8 flag = TTY_NORMAL;
+ guard(rwsem_read)(&tty->termios_rwsem);
+
ldata->lookahead_count += count;
if (!I_IXON(tty))
--
2.43.0
^ permalink raw reply related
* RE: rts-gpios support in fsl_lpuart driver?
From: Sherry Sun @ 2026-02-11 9:59 UTC (permalink / raw)
To: Frank Li, imx@lists.linux.dev, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Roelf-Erik Carsjens,
Josua Mayer
In-Reply-To: <aYtVNxZU4tqtj2fo@lizhi-Precision-Tower-5810>
> Subject: Re: rts-gpios support in fsl_lpuart driver?
>
> On Tue, Feb 10, 2026 at 12:48:05PM +0100, Alexander Dahl wrote:
> > Hello everyone,
>
> Add sherry. look like we have not implemented it at lpuart.
Yes, currently the lpuart driver only supports auto RS-485 RTS mode.
We haven't received any requests for sw-controlled RTS mode (rts-gpio).
We can consider adding this feature in the future if such requests arise.
Best Regards
Sherry
>
> Frank
> >
> > we are currently experimenting with the SolidRun 8XLite SoM featuring
> > an i.MX 8XLite SoC on a custom base board. Due to how our peripheral
> > hardware is connected we need to use rs485 with uart3, which has no
> > native soc controlled rts line. On different SoCs you just use
> > 'rts-gpios' in devicetree then, letting the kernel switch this line
> > through gpio. Alas it does not work on this SoC, the RTS line is not
> > switched at all. :-/
> >
> > According to my analysis the i.MX8 family has different variants using
> > different uarts with different drivers. For the variants using the
> > imx.c driver, you find dts files using rts-gpios, but for variants
> > using the fsl_lpuart.c driver you find none.
> >
> > The rts-gpios property is evaluated by the serial core in
> > `mctrl_gpio_init()` right? And the actual switching is also done
> > through that mctrl_gpio interface, right? As far as I understand the
> > source code, the serial core calls the .set_mctrl function pointer,
> > and then it is up to the driver what to do? Some (like atmel_serial.c
> > and imx.c) call mctrl_gpio_set() in the function mapped to that
> > pointer, some (like fsl_lpuart.c) don't. Correct so far?
> >
> > Up to this point I'm somewhat confused this is no generic feature in
> > the core which works for any uart, but there's probably a reason for
> > that? Maybe interaction with the actual uart registers in some way?
> >
> > If it is like described, I'd say the fsl_lpuart driver currently just
> > does not support this usecase? Is it possible to implement the
> > necessary things? Is anybody already working on that? I looked in my
> > mailing list archive and in the imx downstream kernel, but could not
> > find any hints.
> >
> > Any advice welcome. :-)
> >
> > Greets
> > Alex
> >
^ permalink raw reply
* Re: [PATCH v2] serial: 8250: add CONFIG_SERIAL_8250_PROBE_BAUD option
From: Maciej W. Rozycki @ 2026-02-10 17:49 UTC (permalink / raw)
To: Sheng Yu; +Cc: Greg Kroah-Hartman, jirislaby, linux-serial, linux-kernel
In-Reply-To: <20260209042643.565418-1-yushenglive@gmail.com>
On Sun, 8 Feb 2026, Sheng Yu wrote:
> Currently, the 8250 driver defaults to 9600 baud if no console options
> are provided via the command line. This can result in garbled output if
> the firmware or bootloader has already initialized the UART to a
> different speed.
FWIW this seems like a generic option that shouldn't be limited to 8250
hardware, i.e. for drivers/tty/serial/Kconfig and to be named accordingly,
as there's nothing specific to the 8250 in it. Then individual drivers
could opt in via a dependency where feasible (i.e. the baud rate generator
setting being readable) and someone actually did it, such as you for the
8250 driver. This could be mentioned in the option description so as not
to confuse people with configurations featuring multiple serial device
drivers.
Maciej
^ permalink raw reply
* Re: rts-gpios support in fsl_lpuart driver?
From: Manikanta guntupalli @ 2026-02-10 17:10 UTC (permalink / raw)
To: Frank Li
Cc: imx, linux-serial, linux-kernel, linux-arm-kernel,
Roelf-Erik Carsjens, Josua Mayer, sherry.sun
In-Reply-To: <aYtVNxZU4tqtj2fo@lizhi-Precision-Tower-5810>
Hi Alex,
On Tue, 10 Feb 2026, 21:28 Frank Li, <Frank.li@nxp.com> wrote:
>
> On Tue, Feb 10, 2026 at 12:48:05PM +0100, Alexander Dahl wrote:
> > Hello everyone,
>
> Add sherry. look like we have not implemented it at lpuart.
>
> Frank
> >
> > we are currently experimenting with the SolidRun 8XLite SoM featuring
> > an i.MX 8XLite SoC on a custom base board. Due to how our peripheral
> > hardware is connected we need to use rs485 with uart3, which has no
> > native soc controlled rts line. On different SoCs you just use
> > 'rts-gpios' in devicetree then, letting the kernel switch this line
> > through gpio. Alas it does not work on this SoC, the RTS line is not
> > switched at all. :-/
> >
> > According to my analysis the i.MX8 family has different variants using
> > different uarts with different drivers. For the variants using the
> > imx.c driver, you find dts files using rts-gpios, but for variants
> > using the fsl_lpuart.c driver you find none.
> >
> > The rts-gpios property is evaluated by the serial core in
> > `mctrl_gpio_init()` right? And the actual switching is also done
> > through that mctrl_gpio interface, right? As far as I understand the
> > source code, the serial core calls the .set_mctrl function pointer,
> > and then it is up to the driver what to do? Some (like atmel_serial.c
> > and imx.c) call mctrl_gpio_set() in the function mapped to that
> > pointer, some (like fsl_lpuart.c) don't. Correct so far?
> >
> > Up to this point I'm somewhat confused this is no generic feature in
> > the core which works for any uart, but there's probably a reason for
> > that? Maybe interaction with the actual uart registers in some way?
> >
> > If it is like described, I'd say the fsl_lpuart driver currently just
> > does not support this usecase? Is it possible to implement the
> > necessary things? Is anybody already working on that? I looked in my
> > mailing list archive and in the imx downstream kernel, but could not
> > find any hints.
> >
> > Any advice welcome. :-)
> >
> > Greets
> > Alex
> >
>
If we are using gpio as rts line, we need to handle it in the driver sequence.
Please refer to the patch below, that may be helpful.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=fccc9d9233f918ee50cf2955ae7134a7f3418351
Thanks,
Manikanta.
^ permalink raw reply
* Re: rts-gpios support in fsl_lpuart driver?
From: Frank Li @ 2026-02-10 15:56 UTC (permalink / raw)
To: imx, linux-serial, linux-kernel, linux-arm-kernel,
Roelf-Erik Carsjens, Josua Mayer, sherry.sun
In-Reply-To: <20260210-rearview-hungrily-536a95fc3385@thorsis.com>
On Tue, Feb 10, 2026 at 12:48:05PM +0100, Alexander Dahl wrote:
> Hello everyone,
Add sherry. look like we have not implemented it at lpuart.
Frank
>
> we are currently experimenting with the SolidRun 8XLite SoM featuring
> an i.MX 8XLite SoC on a custom base board. Due to how our peripheral
> hardware is connected we need to use rs485 with uart3, which has no
> native soc controlled rts line. On different SoCs you just use
> 'rts-gpios' in devicetree then, letting the kernel switch this line
> through gpio. Alas it does not work on this SoC, the RTS line is not
> switched at all. :-/
>
> According to my analysis the i.MX8 family has different variants using
> different uarts with different drivers. For the variants using the
> imx.c driver, you find dts files using rts-gpios, but for variants
> using the fsl_lpuart.c driver you find none.
>
> The rts-gpios property is evaluated by the serial core in
> `mctrl_gpio_init()` right? And the actual switching is also done
> through that mctrl_gpio interface, right? As far as I understand the
> source code, the serial core calls the .set_mctrl function pointer,
> and then it is up to the driver what to do? Some (like atmel_serial.c
> and imx.c) call mctrl_gpio_set() in the function mapped to that
> pointer, some (like fsl_lpuart.c) don't. Correct so far?
>
> Up to this point I'm somewhat confused this is no generic feature in
> the core which works for any uart, but there's probably a reason for
> that? Maybe interaction with the actual uart registers in some way?
>
> If it is like described, I'd say the fsl_lpuart driver currently just
> does not support this usecase? Is it possible to implement the
> necessary things? Is anybody already working on that? I looked in my
> mailing list archive and in the imx downstream kernel, but could not
> find any hints.
>
> Any advice welcome. :-)
>
> Greets
> Alex
>
^ permalink raw reply
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Thomas Bogendoerfer @ 2026-02-10 15:50 UTC (permalink / raw)
To: Brian Masney
Cc: Claudiu Beznea, linux-mips, linux-kernel, Michael Turquette,
Stephen Boyd, linux-clk, Thomas Gleixner, Adrian Hunter,
Ulf Hansson, linux-mmc, Linus Walleij, linux-gpio,
Alexandre Belloni, linux-rtc, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, Guenter Roeck, Wim Van Sebroeck, linux-watchdog,
Lukas Bulwahn
In-Reply-To: <aYsnsecPa8bWMbaA@redhat.com>
On Tue, Feb 10, 2026 at 07:42:25AM -0500, Brian Masney wrote:
> Hi Thomas,
>
> On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> > There are currently some pic32 MIPS drivers that are in tree, and are
> > only configured to be compiled on the MIPS pic32 platform. There's a
> > risk of breaking some of these drivers when migrating drivers away from
> > legacy APIs. It happened to me with a pic32 clk driver.
> >
> > Let's go ahead and move the pic32.h from the asm to the platform_data
> > include directory in the tree. This will make it easier, and cleaner to
> > enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> > updating some includes, which I do at the beginning of this series.
> >
> > This series was compile tested on a centos-stream-10 arm64 host in two
> > different configurations:
> >
> > - native arm64 build with COMPILE_TEST (via make allmodconfig)
> > - MIPS cross compile on arm64 with:
> > ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
> >
> > Note that there is a separate MIPS compile error in linux-next, and I
> > reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
> >
> > I included a patch at the end that shows enabling COMPILE_TEST for a
> > pic32 clk driver.
> >
> > Merge Strategy
> > ==============
> > - Patches 1-15 can go through the MIPS tree.
> > - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
> > tree after the next merge window. There is a separate patch set that
> > fixes a compiler error I unintentionally introduced via the clk tree.
> > https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
>
> Sorry about the duplicate message. I just wanted to reply to the series
> with MIPS in the header so this message isn't lost.
>
> Can you back out these two patches from your tree in linux-next, and not
> send these to Linus?
>
> clk: microchip: core: allow driver to be compiled with COMPILE_TEST
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=026d70dcfe5de1543bb8edb8e50d22dc16863e6b
>
> clk: microchip: fix typo in reference to a config option
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a6ab150deb4b740334721d18e02ad400a9d888f5
I've reverted both patches in mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH] serial: amba-pl011: Enable UART in earlycon setup
From: Arnd Bergmann @ 2026-02-10 14:10 UTC (permalink / raw)
To: Peter Maydell
Cc: linux-serial, linux-kernel, Greg Kroah-Hartman, Jiri Slaby,
Thomas Gleixner, Russell King, Miaoqian Lin
In-Reply-To: <CAFEAcA_nUiQ9ROXBq6Q=3G1wzLtBHDEKSB+4OyYWkt-tR_ZTJA@mail.gmail.com>
On Tue, Feb 10, 2026, at 14:49, Peter Maydell wrote:
> On Tue, 10 Feb 2026 at 13:23, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Feb 10, 2026, at 13:50, Peter Maydell wrote:
>>
>> One more question: what is the symptom without this patch with
>> qemu? You mentioned on IRC that qemu may warn about attempting
>> to write to the uart when it is disabled. Would we still get
>> the correct early console output before the uart is enabled?
>
> The symptom is that if you run QEMU with '-d guest_errors' to ask
> it to log things the guest does that it thinks are bugs in the
> guest, then you get a lot of "PL011 data written to disabled UART"
> warnings. The guest still boots fine, and assuming you directed
> the logging to a file rather than stdout you see the guest output.
Ok, thanks for the explanation! I still wonder whether we will
want a stable backport of the patch. It sounds like it won't
be needed for qemu (because most people won't see the harmless
warning especially after your patch) or most real hardware
(because the bootloader will have initialized the console),
but there may still be corner cases that need it.
Arnd
^ permalink raw reply
* Re: [PATCH] serial: amba-pl011: Enable UART in earlycon setup
From: Peter Maydell @ 2026-02-10 13:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-serial, linux-kernel, Greg Kroah-Hartman, Jiri Slaby,
Thomas Gleixner, Russell King, Miaoqian Lin
In-Reply-To: <316ebe17-5938-4e8b-9269-934c7c773c01@app.fastmail.com>
On Tue, 10 Feb 2026 at 13:23, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 10, 2026, at 13:50, Peter Maydell wrote:
> > Currently the PL011 driver only enables the UART (by setting UARTEN
> > in REG_CR) in pl011_startup(), so if it is used for earlycon it is
> > relying on the bootrom/firmware having left the UART enabled.
> >
> > There's no particular reason not to actively enable the UART before
> > using it for earlycon, and the earlycon handling for e.g. the 8250
> > UART sets up the UART in its setup function, so follow that in the
> > PL011.
> >
> > This allows use of earlycon with a UART that the firmware hasn't
> > already been using for its own output, but the main motivation is
> > that QEMU will otherwise log a message complaining that the guest is
> > trying to write to a UART it never enabled.
> >
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > ---
> > NB: I have tested this under QEMU, but I do not have any real
> > PL011-using hardware to hand to test with.
>
> Looks good to me,
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> One more question: what is the symptom without this patch with
> qemu? You mentioned on IRC that qemu may warn about attempting
> to write to the uart when it is disabled. Would we still get
> the correct early console output before the uart is enabled?
The symptom is that if you run QEMU with '-d guest_errors' to ask
it to log things the guest does that it thinks are bugs in the
guest, then you get a lot of "PL011 data written to disabled UART"
warnings. The guest still boots fine, and assuming you directed
the logging to a file rather than stdout you see the guest output.
(This is because for PL011 we have deliberately not emulated the
hardware behaviour of discarding data when the UART isn't initialized,
because we think there is a lot of "my first bare metal hello
world program" type code out there that was written against older
QEMU versions and not tested on hardware and never enables the
PL011, and we figured that making all that code break wasn't a
sensible tradeoff for theoretically increased emulation fidelity.
For newer UART models where we modelled the enable flag correctly
from the start, you would have to explicitly enable. The CMSDK
UART model is one example of that.)
I have also sent a QEMU patch to restrict the complaint to
"print this once" rather than "print this every time the
guest writes to the UART TX register".
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH] serial: amba-pl011: Enable UART in earlycon setup
From: Arnd Bergmann @ 2026-02-10 13:22 UTC (permalink / raw)
To: Peter Maydell, linux-serial
Cc: linux-kernel, Greg Kroah-Hartman, Jiri Slaby, Thomas Gleixner,
Russell King, Miaoqian Lin
In-Reply-To: <20260210125100.223138-1-peter.maydell@linaro.org>
On Tue, Feb 10, 2026, at 13:50, Peter Maydell wrote:
> Currently the PL011 driver only enables the UART (by setting UARTEN
> in REG_CR) in pl011_startup(), so if it is used for earlycon it is
> relying on the bootrom/firmware having left the UART enabled.
>
> There's no particular reason not to actively enable the UART before
> using it for earlycon, and the earlycon handling for e.g. the 8250
> UART sets up the UART in its setup function, so follow that in the
> PL011.
>
> This allows use of earlycon with a UART that the firmware hasn't
> already been using for its own output, but the main motivation is
> that QEMU will otherwise log a message complaining that the guest is
> trying to write to a UART it never enabled.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> NB: I have tested this under QEMU, but I do not have any real
> PL011-using hardware to hand to test with.
Looks good to me,
Acked-by: Arnd Bergmann <arnd@arndb.de>
One more question: what is the symptom without this patch with
qemu? You mentioned on IRC that qemu may warn about attempting
to write to the uart when it is disabled. Would we still get
the correct early console output before the uart is enabled?
Arnd
^ permalink raw reply
* [PATCH] serial: amba-pl011: Enable UART in earlycon setup
From: Peter Maydell @ 2026-02-10 12:50 UTC (permalink / raw)
To: linux-serial
Cc: linux-kernel, Greg Kroah-Hartman, Jiri Slaby, Thomas Gleixner,
Arnd Bergmann, Russell King, Miaoqian Lin
Currently the PL011 driver only enables the UART (by setting UARTEN
in REG_CR) in pl011_startup(), so if it is used for earlycon it is
relying on the bootrom/firmware having left the UART enabled.
There's no particular reason not to actively enable the UART before
using it for earlycon, and the earlycon handling for e.g. the 8250
UART sets up the UART in its setup function, so follow that in the
PL011.
This allows use of earlycon with a UART that the firmware hasn't
already been using for its own output, but the main motivation is
that QEMU will otherwise log a message complaining that the guest is
trying to write to a UART it never enabled.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
NB: I have tested this under QEMU, but I do not have any real
PL011-using hardware to hand to test with.
---
drivers/tty/serial/amba-pl011.c | 35 ++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f17d288c807..462a8c380059 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2700,6 +2700,37 @@ static int pl011_early_read(struct console *con, char *s, unsigned int n)
*/
static int __init pl011_early_console_setup(struct earlycon_device *device,
const char *opt)
+{
+ unsigned int cr;
+
+ if (!device->port.membase)
+ return -ENODEV;
+
+ device->con->write = pl011_early_write;
+ device->con->read = pl011_early_read;
+
+ if (device->port.iotype == UPIO_MEM32)
+ cr = readl(device->port.membase + UART011_CR);
+ else
+ cr = readw(device->port.membase + UART011_CR);
+ cr &= UART011_CR_RTS | UART011_CR_DTR;
+ cr |= UART01x_CR_UARTEN | UART011_CR_RXE | UART011_CR_TXE;
+ if (device->port.iotype == UPIO_MEM32)
+ writel(cr, device->port.membase + UART011_CR);
+ else
+ writew(cr, device->port.membase + UART011_CR);
+
+ return 0;
+}
+
+OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
+
+/*
+ * The SBSA UART has no defined control register and is assumed to
+ * be pre-enabled by firmware, so we do not write to UART011_CR.
+ */
+static int __init sbsa_uart_early_console_setup(struct earlycon_device *device,
+ const char *opt)
{
if (!device->port.membase)
return -ENODEV;
@@ -2710,9 +2741,7 @@ static int __init pl011_early_console_setup(struct earlycon_device *device,
return 0;
}
-OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
-
-OF_EARLYCON_DECLARE(pl011, "arm,sbsa-uart", pl011_early_console_setup);
+OF_EARLYCON_DECLARE(pl011, "arm,sbsa-uart", sbsa_uart_early_console_setup);
/*
* On Qualcomm Datacenter Technologies QDF2400 SOCs affected by
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Brian Masney @ 2026-02-10 12:42 UTC (permalink / raw)
To: Thomas Bogendoerfer, Claudiu Beznea
Cc: linux-mips, linux-kernel, Michael Turquette, Stephen Boyd,
linux-clk, Thomas Gleixner, Adrian Hunter, Ulf Hansson, linux-mmc,
Linus Walleij, linux-gpio, Alexandre Belloni, linux-rtc,
Greg Kroah-Hartman, Jiri Slaby, linux-serial, Guenter Roeck,
Wim Van Sebroeck, linux-watchdog, Lukas Bulwahn
In-Reply-To: <20260112-mips-pic32-header-move-v2-0-927d516b1ff9@redhat.com>
Hi Thomas,
On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> There are currently some pic32 MIPS drivers that are in tree, and are
> only configured to be compiled on the MIPS pic32 platform. There's a
> risk of breaking some of these drivers when migrating drivers away from
> legacy APIs. It happened to me with a pic32 clk driver.
>
> Let's go ahead and move the pic32.h from the asm to the platform_data
> include directory in the tree. This will make it easier, and cleaner to
> enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> updating some includes, which I do at the beginning of this series.
>
> This series was compile tested on a centos-stream-10 arm64 host in two
> different configurations:
>
> - native arm64 build with COMPILE_TEST (via make allmodconfig)
> - MIPS cross compile on arm64 with:
> ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
>
> Note that there is a separate MIPS compile error in linux-next, and I
> reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
>
> I included a patch at the end that shows enabling COMPILE_TEST for a
> pic32 clk driver.
>
> Merge Strategy
> ==============
> - Patches 1-15 can go through the MIPS tree.
> - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
> tree after the next merge window. There is a separate patch set that
> fixes a compiler error I unintentionally introduced via the clk tree.
> https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
Sorry about the duplicate message. I just wanted to reply to the series
with MIPS in the header so this message isn't lost.
Can you back out these two patches from your tree in linux-next, and not
send these to Linus?
clk: microchip: core: allow driver to be compiled with COMPILE_TEST
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=026d70dcfe5de1543bb8edb8e50d22dc16863e6b
clk: microchip: fix typo in reference to a config option
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a6ab150deb4b740334721d18e02ad400a9d888f5
See
https://lore.kernel.org/oe-kbuild-all/202602100954.BAVYq6aC-lkp@intel.com/
All of the other patches with the include changes are good. I have
patches queued to send out in two weeks to other subsystems once the
include changes land in Linus's tree.
Thanks,
Brian
^ permalink raw reply
* rts-gpios support in fsl_lpuart driver?
From: Alexander Dahl @ 2026-02-10 11:48 UTC (permalink / raw)
To: imx
Cc: linux-serial, linux-kernel, linux-arm-kernel, Roelf-Erik Carsjens,
Josua Mayer
Hello everyone,
we are currently experimenting with the SolidRun 8XLite SoM featuring
an i.MX 8XLite SoC on a custom base board. Due to how our peripheral
hardware is connected we need to use rs485 with uart3, which has no
native soc controlled rts line. On different SoCs you just use
'rts-gpios' in devicetree then, letting the kernel switch this line
through gpio. Alas it does not work on this SoC, the RTS line is not
switched at all. :-/
According to my analysis the i.MX8 family has different variants using
different uarts with different drivers. For the variants using the
imx.c driver, you find dts files using rts-gpios, but for variants
using the fsl_lpuart.c driver you find none.
The rts-gpios property is evaluated by the serial core in
`mctrl_gpio_init()` right? And the actual switching is also done
through that mctrl_gpio interface, right? As far as I understand the
source code, the serial core calls the .set_mctrl function pointer,
and then it is up to the driver what to do? Some (like atmel_serial.c
and imx.c) call mctrl_gpio_set() in the function mapped to that
pointer, some (like fsl_lpuart.c) don't. Correct so far?
Up to this point I'm somewhat confused this is no generic feature in
the core which works for any uart, but there's probably a reason for
that? Maybe interaction with the actual uart registers in some way?
If it is like described, I'd say the fsl_lpuart driver currently just
does not support this usecase? Is it possible to implement the
necessary things? Is anybody already working on that? I looked in my
mailing list archive and in the imx downstream kernel, but could not
find any hints.
Any advice welcome. :-)
Greets
Alex
^ permalink raw reply
* Re: [PATCH 0/3] vt: add modifier support to cursor and navigation keys
From: Greg Kroah-Hartman @ 2026-02-10 6:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jiri Slaby, Alexey Gladkov, linux-serial, linux-kernel
In-Reply-To: <q19s9nr3-6o47-4pq9-7r49-8q25p0021o1q@syhkavp.arg>
On Sun, Feb 08, 2026 at 11:22:27AM -0500, Nicolas Pitre wrote:
> On Sun, 8 Feb 2026, Greg Kroah-Hartman wrote:
>
> > Argh, sorry, I saw this patch series too late for this merge window.
> > I'll review it after -rc1 is out.
>
> Too bad.
>
> But please at least consider this one now
> https://lkml.org/lkml/2026/1/27/1886
> and queue it for the stable tree as well.
Sorry, that slipped through as well, I'll grab it after -rc1 is out and
get it backported to stable kernels.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: add support for A9 based Amlogic BY401
From: Martin Blumenstingl @ 2026-02-09 22:19 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Jerome Brunet, Kevin Hilman, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-kernel, linux-serial, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20260205-a9-baisc-dts-v1-3-1212b46f95a7@amlogic.com>
On Thu, Feb 5, 2026 at 7:04 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
[...]
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-a9-a311y3-by401.dts b/arch/arm64/boot/dts/amlogic/amlogic-a9-a311y3-by401.dts
> new file mode 100644
> index 000000000000..ad35a3292d49
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-a9-a311y3-by401.dts
> @@ -0,0 +1,41 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2026 Amlogic, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include "amlogic-a9.dtsi"
> +/ {
> + model = "Amlogic A311DY3 BY401 Development Board";
> + compatible = "amlogic,by401", "amlogic,a9";
> + interrupt-parent = <&gic>;
Shouldn't this go into amlogic-a9.dtsi (I can't see why different
boards may choose a different default interrupt-parent)?
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: arm: amlogic: add A311Y3 support
From: Martin Blumenstingl @ 2026-02-09 22:16 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Jerome Brunet, Kevin Hilman, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-kernel, linux-serial, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20260205-a9-baisc-dts-v1-1-1212b46f95a7@amlogic.com>
On Thu, Feb 5, 2026 at 7:04 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Add bindings for the Amlogic BY401 board, using A311Y3 Soc from
> Amlogic A9 family chip.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: serial: amlogic,meson-uart: Add compatible string for A9
From: Martin Blumenstingl @ 2026-02-09 22:16 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Jerome Brunet, Kevin Hilman, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-kernel, linux-serial, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20260205-a9-baisc-dts-v1-2-1212b46f95a7@amlogic.com>
On Thu, Feb 5, 2026 at 7:04 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Amlogic A9 SoCs uses the same UART controller as S4 SoCs.
> There is no need for an extra compatible line in the driver,
> but add A9 compatible line for documentation.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* [PATCH] serial: 8250: Fix TX deadlock when using DMA
From: Raul E Rangel @ 2026-02-09 20:58 UTC (permalink / raw)
To: linux-serial
Cc: jkeeping, Raul E Rangel, Greg Kroah-Hartman, Ilpo Järvinen,
Jiri Slaby, linux-kernel
`dmaengine_terminate_async` does not guarantee that the
`__dma_tx_complete` callback will run. The callback is currently the
only place where `dma->tx_running` gets cleared. If the transaction is
canceled and the callback never runs, then `dma->tx_running` will never
get cleared and we will never schedule new TX DMA transactions again.
This change makes it so we clear `dma->tx_running` after we terminate
the DMA transaction. This is "safe" because `serial8250_tx_dma_flush`
is holding the UART port lock. The first thing the callback does is also
grab the UART port lock, so access to `dma->tx_running` is serialized.
Fixes: 9e512eaaf8f4 ("serial: 8250: Fix fifo underflow on flush")
Signed-off-by: Raul E Rangel <rrangel@google.com>
---
drivers/tty/serial/8250/8250_dma.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dma.c b/drivers/tty/serial/8250/8250_dma.c
index bdd26c9f34bd..3b6452e759d5 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -162,7 +162,22 @@ void serial8250_tx_dma_flush(struct uart_8250_port *p)
*/
dma->tx_size = 0;
+ /*
+ * We can't use `dmaengine_terminate_sync` because `uart_flush_buffer` is
+ * holding the uart port spinlock.
+ */
dmaengine_terminate_async(dma->txchan);
+
+ /*
+ * The callback might or might not run. If it doesn't run, we need to ensure
+ * that `tx_running` is cleared so that we can schedule new transactions.
+ * If it does run, then the zombie callback will clear `tx_running` again
+ * and perform a no-op since `tx_size` was cleared above.
+ *
+ * In either case, we ASSUME the DMA transaction will terminate before we
+ * issue a new `serial8250_tx_dma`.
+ */
+ dma->tx_running = 0;
}
int serial8250_rx_dma(struct uart_8250_port *p)
--
2.53.0.rc2.204.g2597b5adb4-goog
^ permalink raw reply related
* Re: [PATCH v5 11/11] arm64: dts: microchip: add EV23X71A board
From: Daniel Machon @ 2026-02-09 13:27 UTC (permalink / raw)
To: Robert Marko
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, UNGLinuxDriver, linusw, olivia,
richard.genoud, radu_nicolae.pirea, gregkh, richardcochran,
horatiu.vultur, Ryan.Wanner, tudor.ambarus, kavyasree.kotagiri,
lars.povlsen, devicetree, linux-arm-kernel, linux-kernel,
linux-crypto, netdev, linux-gpio, linux-spi, linux-serial,
luka.perkov
In-Reply-To: <20260115114021.111324-12-robert.marko@sartura.hr>
Hi Robert,
Tested on EV23X71A.
Thanks!
> Microchip EV23X71A is an LAN9696 based evaluation board.
Acked-by: Daniel Machon <daniel.machon@microchip.com>
Tested-by: Daniel Machon <daniel.machon@microchip.com>
^ permalink raw reply
* Re: [PATCH v5 08/11] arm64: dts: microchip: add LAN969x support
From: Daniel Machon @ 2026-02-09 13:24 UTC (permalink / raw)
To: Robert Marko
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, UNGLinuxDriver, linusw, olivia,
richard.genoud, radu_nicolae.pirea, gregkh, richardcochran,
horatiu.vultur, Ryan.Wanner, tudor.ambarus, kavyasree.kotagiri,
lars.povlsen, devicetree, linux-arm-kernel, linux-kernel,
linux-crypto, netdev, linux-gpio, linux-spi, linux-serial,
luka.perkov
In-Reply-To: <20260115114021.111324-9-robert.marko@sartura.hr>
> Add support for Microchip LAN969x switch SoC series by adding the SoC DTSI.
Acked-by: Daniel Machon <daniel.machon@microchip.com>
^ permalink raw reply
* [PATCH v3] serial: 8250: always disable IRQ during THRE test
From: Alban Bedel @ 2026-02-09 11:32 UTC (permalink / raw)
To: linux-serial
Cc: linux-kernel, Nam Cao, Andy Shevchenko, Ilpo Järvinen,
Jiri Slaby, Greg Kroah-Hartman, Lennert Buytenhek, Peng Zhang,
stable, Muchun Song, Alban Bedel, Maximilian Lueer
From: Peng Zhang <zhangpeng.00@bytedance.com>
commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq
has been set up") moved IRQ setup before the THRE test, so the interrupt
handler can run during the test and race with its IIR reads. This can
produce wrong THRE test results and cause spurious registration of the
serial8250_backup_timeout timer. Unconditionally disable the IRQ for the
short duration of the test and re-enable it afterwards to avoid the race.
Cc: stable@vger.kernel.org
Fixes: 039d4926379b ("serial: 8250: Toggle IER bits on only after irq has been set up")
Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
Tested-by: Maximilian Lueer <maximilian.lueer@lht.dlh.de>
---
Changelog:
v2: Replaced disable_irq_nosync() with disable_irq() to prevent interrupts
that are currently being handled
v3: Added changelog
---
Commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq
has been set up") introduced a bug which showed in some of our devices
after updating them to kernel 5.15.169. These devices have an I2C
touch screen which is behind an UART to I2C bridge. This bug lead to
an ever growing latency on the bus, delaying the touch events by up to
several seconds.
Looking for other solutions than reverting commit 039d4926379b I found
Peng Zhang's patch, backported it to 5.15 and could confirm that it
solve the high delay issue.
As this a quiet sever regression I'm taking the liberty to re-submit
Peng Zhang's patch in the hope it will be considered for inclusion. I
added the changelog requested by greg k-h's patch email bot after the
last submission.
Also please note that commit 039d4926379b was backported as far back as
5.10, so quiet a few stable kernels are affected. This patch doesn't
apply as-is on older kernels, I can provide a patch for 5.15 if desired.
Alban Bedel
---
drivers/tty/serial/8250/8250_port.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 719faf92aa8ae..f1740cc911431 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2147,8 +2147,7 @@ static void serial8250_THRE_test(struct uart_port *port)
if (up->port.flags & UPF_NO_THRE_TEST)
return;
- if (port->irqflags & IRQF_SHARED)
- disable_irq_nosync(port->irq);
+ disable_irq(port->irq);
/*
* Test for UARTs that do not reassert THRE when the transmitter is idle and the interrupt
@@ -2170,8 +2169,7 @@ static void serial8250_THRE_test(struct uart_port *port)
serial_port_out(port, UART_IER, 0);
}
- if (port->irqflags & IRQF_SHARED)
- enable_irq(port->irq);
+ enable_irq(port->irq);
/*
* If the interrupt is not reasserted, or we otherwise don't trust the iir, setup a timer to
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] tty: ipwireless: Fix use-after-free in tasklet during device removal
From: David Sterba @ 2026-02-09 10:21 UTC (permalink / raw)
To: Jiri Kosina
Cc: Greg KH, duoming, linux-serial, linux-kernel, dsterba, jirislaby,
kuba, alexander.deucher, akpm, pkshih, tglx, mingo
In-Reply-To: <p16239r9-692o-859r-6006-7o611r2rn2qs@xreary.bet>
On Sun, Feb 08, 2026 at 06:25:38PM +0100, Jiri Kosina wrote:
> On Sun, 8 Feb 2026, Greg KH wrote:
>
> > > I don't have the real hardware. In order to reproduce the bug, I simulate
> > > the IPWireless PCMCIA card in the qemu by allocating and configuring the
> > > necessary resources(I/O ports, memory regions, interrupts and so on) to
> > > correspond with the hardware expected by the driver in the initialization
> > > code of the virtual device.
> >
> > I wonder if this device even is still around, given that pcmcia is all
> > but dead for a very long time.
>
> I doubt that this device is still around anywhere where reasonably new
> kernels (including LTS) would matter.
>
> I don't think I've seen this device (which was back then donated to me by
> T-Mobile CZ in order to get it supported in Linux, and I am not sure how
> much global adoption it got afterwards) for, let's say, past 15 years :)
>
> I think (let's see what David, ho took the maintainership over for me
> afterwards, has to say) we'd better deprecate and drop the whole thing,
> rather than trying to pretend that it's still actively being taken care
> of.
https://lore.kernel.org/all/20230223172403.GW10580@suse.cz/ last time
the question of keeping the driver was asked (2023). Back then I was
able to find the cards on second hand market but now I can't on a local
market and there's exactly one hit on global eBay.
Local linux related or telco support forums seem to mention the driver
until 2011 (root.cz, abclinuxu.cz, t-mobile.cz). It does not prove
nobody is using it but I think the chances are quite low to justify
keeping the driver. It is simple enough to be built as an external
module eventually, I can help with that in case somebody really needs
that.
^ permalink raw reply
* [PATCH v2] serial: 8250: add CONFIG_SERIAL_8250_PROBE_BAUD option
From: Sheng Yu @ 2026-02-09 4:26 UTC (permalink / raw)
To: gregkh; +Cc: jirislaby, linux-serial, linux-kernel, Sheng Yu
Currently, the 8250 driver defaults to 9600 baud if no console options
are provided via the command line. This can result in garbled output if
the firmware or bootloader has already initialized the UART to a
different speed.
Introduce CONFIG_SERIAL_8250_PROBE_BAUD. When enabled, the driver will
attempt to read the current baud rate from the hardware registers if
no options are specified, rather than forcing the 9600 default.
Signed-off-by: Sheng Yu <yushenglive@gmail.com>
---
v2: Removed empty line accidently added.
drivers/tty/serial/8250/8250_core.c | 2 +-
drivers/tty/serial/8250/8250_port.c | 5 ++++-
drivers/tty/serial/8250/Kconfig | 12 ++++++++++++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 0e81f78c6063..c11b19921a1f 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -427,7 +427,7 @@ static int univ8250_console_setup(struct console *co, char *options)
/* link port to console */
uart_port_set_cons(port, co);
- retval = serial8250_console_setup(port, options, false);
+ retval = serial8250_console_setup(port, options, IS_ENABLED(CONFIG_SERIAL_8250_PROBE_BAUD));
if (retval != 0)
uart_port_set_cons(port, NULL);
return retval;
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 719faf92aa8a..5309b921e7b7 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -3399,8 +3399,11 @@ int serial8250_console_setup(struct uart_port *port, char *options, bool probe)
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
- else if (probe)
+ else if (probe) {
baud = probe_baud(port);
+ pr_info("console [%s%d] probed baud rate: %d\n",
+ port->cons->name, port->cons->index, baud);
+ }
ret = uart_set_options(port, port->cons, baud, parity, bits, flow);
if (ret)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index c488ff6f2865..bee6a82023d4 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -596,3 +596,15 @@ config SERIAL_OF_PLATFORM
are probed through devicetree, including Open Firmware based
PowerPC systems and embedded systems on architectures using the
flattened device tree format.
+
+config SERIAL_8250_PROBE_BAUD
+ bool "Probe baud rate if console options are missing"
+ depends on SERIAL_8250
+ help
+ If the "console=" command line parameter is missing options (e.g.,
+ "console=ttyS0" instead of "console=ttyS0,115200n8"), this option
+ allows the kernel to probe the baud rate from hardware instead of
+ defaulting to 9600.
+
+ If a baud rate is explicitly provided in the options, that value
+ is always respected.
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] tty: ipwireless: Fix use-after-free in tasklet during device removal
From: Jiri Kosina @ 2026-02-08 17:25 UTC (permalink / raw)
To: Greg KH
Cc: duoming, linux-serial, linux-kernel, dsterba, jirislaby, kuba,
alexander.deucher, akpm, pkshih, tglx, mingo
In-Reply-To: <2026020859-caretaker-duckbill-0fb3@gregkh>
On Sun, 8 Feb 2026, Greg KH wrote:
> > I don't have the real hardware. In order to reproduce the bug, I simulate
> > the IPWireless PCMCIA card in the qemu by allocating and configuring the
> > necessary resources(I/O ports, memory regions, interrupts and so on) to
> > correspond with the hardware expected by the driver in the initialization
> > code of the virtual device.
>
> I wonder if this device even is still around, given that pcmcia is all
> but dead for a very long time.
I doubt that this device is still around anywhere where reasonably new
kernels (including LTS) would matter.
I don't think I've seen this device (which was back then donated to me by
T-Mobile CZ in order to get it supported in Linux, and I am not sure how
much global adoption it got afterwards) for, let's say, past 15 years :)
I think (let's see what David, ho took the maintainership over for me
afterwards, has to say) we'd better deprecate and drop the whole thing,
rather than trying to pretend that it's still actively being taken care
of.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/3] vt: add modifier support to cursor and navigation keys
From: Nicolas Pitre @ 2026-02-08 16:22 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Jiri Slaby, Alexey Gladkov, linux-serial, linux-kernel
In-Reply-To: <2026020851-bullhorn-glitch-0e37@gregkh>
On Sun, 8 Feb 2026, Greg Kroah-Hartman wrote:
> Argh, sorry, I saw this patch series too late for this merge window.
> I'll review it after -rc1 is out.
Too bad.
But please at least consider this one now
https://lkml.org/lkml/2026/1/27/1886
and queue it for the stable tree as well.
Nicolas
^ permalink raw reply
* Re: [PATCH] serial: 8250: add CONFIG_SERIAL_8250_PROBE_BAUD option
From: Greg KH @ 2026-02-08 15:28 UTC (permalink / raw)
To: Sheng Yu; +Cc: jirislaby, linux-serial, linux-kernel
In-Reply-To: <20260201043615.524435-1-yushenglive@gmail.com>
On Sat, Jan 31, 2026 at 08:36:14PM -0800, Sheng Yu wrote:
> Currently, the 8250 driver defaults to 9600 baud if no console options
> are provided via the command line. This can result in garbled output if
> the firmware or bootloader has already initialized the UART to a
> different speed.
>
> Introduce CONFIG_SERIAL_8250_PROBE_BAUD. When enabled, the driver will
> attempt to read the current baud rate from the hardware registers if
> no options are specified, rather than forcing the 9600 default.
>
> Signed-off-by: Sheng Yu <yushenglive@gmail.com>
> ---
> drivers/tty/serial/8250/8250_core.c | 2 +-
> drivers/tty/serial/8250/8250_port.c | 5 ++++-
> drivers/tty/serial/8250/Kconfig | 12 ++++++++++++
> 3 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index 0e81f78c6063..c11b19921a1f 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -427,7 +427,7 @@ static int univ8250_console_setup(struct console *co, char *options)
> /* link port to console */
> uart_port_set_cons(port, co);
>
> - retval = serial8250_console_setup(port, options, false);
> + retval = serial8250_console_setup(port, options, IS_ENABLED(CONFIG_SERIAL_8250_PROBE_BAUD));
> if (retval != 0)
> uart_port_set_cons(port, NULL);
> return retval;
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 719faf92aa8a..5309b921e7b7 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -3399,8 +3399,11 @@ int serial8250_console_setup(struct uart_port *port, char *options, bool probe)
>
> if (options)
> uart_parse_options(options, &baud, &parity, &bits, &flow);
> - else if (probe)
> + else if (probe) {
> baud = probe_baud(port);
> + pr_info("console [%s%d] probed baud rate: %d\n",
> + port->cons->name, port->cons->index, baud);
> + }
>
> ret = uart_set_options(port, port->cons, baud, parity, bits, flow);
> if (ret)
> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index c488ff6f2865..bee6a82023d4 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -596,3 +596,15 @@ config SERIAL_OF_PLATFORM
> are probed through devicetree, including Open Firmware based
> PowerPC systems and embedded systems on architectures using the
> flattened device tree format.
> +
> +config SERIAL_8250_PROBE_BAUD
> + bool "Probe baud rate if console options are missing"
> + depends on SERIAL_8250
> + help
> + If the "console=" command line parameter is missing options (e.g.,
> + "console=ttyS0" instead of "console=ttyS0,115200n8"), this option
> + allows the kernel to probe the baud rate from hardware instead of
> + defaulting to 9600.
> +
> + If a baud rate is explicitly provided in the options, that value
> + is always respected.
> --
> 2.51.0
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ 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