* [PATCH] vt: resize saved unicode buffer on alt screen exit after resize
From: Nicolas Pitre @ 2026-03-28 3:09 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial, linux-kernel
Instead of discarding the saved unicode buffer when the console was
resized while in the alternate screen, resize it to the current
dimensions using vc_uniscr_copy_area() to preserve its content. This
properly restores the unicode screen on alt screen exit rather than
lazily rebuilding it from a lossy reverse glyph translation.
On allocation failure the stale buffer is freed and vc_uni_lines is
set to NULL so it gets lazily rebuilt via vc_uniscr_check() when next
needed.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
Liav Mordouch identified and fixed a bug of mine where the saved unicode
buffer would be blindly restored with stale dimensions after a console
resize during the alternate screen, causing out-of-bounds accesses:
https://lore.kernel.org/r/20260327170204.29706-1-liavmordouch@gmail.com
His fix correctly discards the stale buffer and lets it be lazily
rebuilt. I don't want to simply replace his patch as he deserves credits
for investigating the bug and providing a good fix.
This patch, which goes on top, improves on that by resizing the saved
unicode buffer to the current dimensions instead of discarding it. This
preserves the original unicode screen content rather than relying on a
lossy reverse glyph translation to reconstruct it.
It would be nice to have this in before v7.0 is released.
drivers/tty/vt/vt.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 99f15b3e9544..b4b19157f05c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1901,7 +1901,6 @@ static void leave_alt_screen(struct vc_data *vc)
unsigned int rows = min(vc->vc_saved_rows, vc->vc_rows);
unsigned int cols = min(vc->vc_saved_cols, vc->vc_cols);
u16 *src, *dest;
- bool uni_lines_stale;
if (vc->vc_saved_screen == NULL)
return; /* Not inside an alt-screen */
@@ -1912,16 +1911,23 @@ static void leave_alt_screen(struct vc_data *vc)
}
/*
* If the console was resized while in the alternate screen,
- * vc_saved_uni_lines was allocated for the old dimensions.
- * Restoring it would cause out-of-bounds accesses. Discard it
- * and let the unicode screen be lazily rebuilt.
+ * resize the saved unicode buffer to the current dimensions.
+ * On allocation failure new_uniscr is NULL, causing the old
+ * buffer to be freed and vc_uni_lines to be lazily rebuilt
+ * via vc_uniscr_check() when next needed.
*/
- uni_lines_stale = vc->vc_saved_rows != vc->vc_rows ||
- vc->vc_saved_cols != vc->vc_cols;
- if (uni_lines_stale)
+ if (vc->vc_saved_uni_lines &&
+ (vc->vc_saved_rows != vc->vc_rows ||
+ vc->vc_saved_cols != vc->vc_cols)) {
+ u32 **new_uniscr = vc_uniscr_alloc(vc->vc_cols, vc->vc_rows);
+
+ if (new_uniscr)
+ vc_uniscr_copy_area(new_uniscr, vc->vc_cols, vc->vc_rows,
+ vc->vc_saved_uni_lines, cols, 0, rows);
vc_uniscr_free(vc->vc_saved_uni_lines);
- else
- vc_uniscr_set(vc, vc->vc_saved_uni_lines);
+ vc->vc_saved_uni_lines = new_uniscr;
+ }
+ vc_uniscr_set(vc, vc->vc_saved_uni_lines);
vc->vc_saved_uni_lines = NULL;
restore_cur(vc);
/* Update the entire screen */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] vt: keyboard: add NULL check for vc_cons[fg_console].d in kbd_keycode and kbd_rawcode
From: Greg Kroah-Hartman @ 2026-03-30 15:32 UTC (permalink / raw)
To: Daniel Hodges
Cc: Daniel Hodges, Jiri Slaby, linux-kernel, linux-serial,
syzbot+c3693b491545af43db87, syzbot+03f79366754268a0f20c
In-Reply-To: <zwtqyw3ztjbgjodwrnriex3plpr4akz3nz3aj7tvfeyflo4be3@mp4emzvcug6r>
On Fri, Mar 13, 2026 at 02:54:01PM -0400, Daniel Hodges wrote:
> On Thu, Mar 12, 2026 at 03:22:09PM +0100, Greg Kroah-Hartman wrote:
> > On Sat, Feb 07, 2026 at 07:31:12PM -0500, Daniel Hodges wrote:
> > > kbd_keycode() and kbd_rawcode() dereference vc_cons[fg_console].d
> > > without checking if it is NULL. The foreground console should normally
> > > always be allocated, but there could be a time during console setup or
> > > teardown where this pointer could be NULL, leading to a general
> > > protection fault.
> > >
> > > Syzkaller triggers this by injecting USB HID input events that reach
> > > kbd_event() while the console state may not be fully consistent. The crash
> > > manifests as a null-ptr-deref in __queue_work when put_queue() or
> > > puts_queue() calls tty_flip_buffer_push() on the uninitialized vc port.
> > >
> > > Add a NULL check for vc at the start of both kbd_rawcode() and
> > > kbd_keycode() to bail out early if the foreground console is not allocated.
> > >
> > > Reported-by: syzbot+c3693b491545af43db87@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=c3693b491545af43db87
> > > Reported-by: syzbot+03f79366754268a0f20c@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=03f79366754268a0f20c
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Signed-off-by: Daniel Hodges <git@danielhodges.dev>
> > > ---
> > > drivers/tty/vt/keyboard.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> > > index a2116e135a82..975830013d24 100644
> > > --- a/drivers/tty/vt/keyboard.c
> > > +++ b/drivers/tty/vt/keyboard.c
> > > @@ -1389,6 +1389,9 @@ static void kbd_rawcode(unsigned char data)
> > > {
> > > struct vc_data *vc = vc_cons[fg_console].d;
> > >
> > > + if (!vc)
> > > + return;
> > > +
> >
> > What prevents vc from being NULL right after checking this?
>
> Yeah, your right about that. I spent a bit of time to make a reproducer
> using a kernel module and I think if RCU is used on vc_cons[].d it
> should then be properly protected. Let me know if that sounds like a
> reasonable approach and I can send a v2.
Maybe? But can this really ever be hit on a non-syzkaller workload?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 02/10] vt: Implement helpers for struct vc_font in source file
From: Greg KH @ 2026-03-30 15:35 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, jirislaby, simona, sam, linux-fbdev, dri-devel,
linux-kernel, linux-serial
In-Reply-To: <20260327130431.59481-3-tzimmermann@suse.de>
On Fri, Mar 27, 2026 at 01:49:35PM +0100, Thomas Zimmermann wrote:
> Move the helpers vc_font_pitch() and vc_font_size() from the VT
> header file into source file. They are not called very often, so
> there's no benefit in keeping them in the headers. Also avoids
> including <liux/math.h> from the header.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/tty/vt/vt.c | 35 ++++++++++++++++++++++++++++++++++
> include/linux/console_struct.h | 30 ++---------------------------
> 2 files changed, 37 insertions(+), 28 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v7 1/8] serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
From: Rob Herring @ 2026-03-30 19:28 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: 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, 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, Hans de Goede
In-Reply-To: <20260326-pci-m2-e-v7-1-43324a7866e6@oss.qualcomm.com>
On Thu, Mar 26, 2026 at 01:36:29PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 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.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
> 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(-)
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 2/8] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Rob Herring @ 2026-03-30 19:28 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: 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, 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, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260326-pci-m2-e-v7-2-43324a7866e6@oss.qualcomm.com>
On Thu, Mar 26, 2026 at 01:36:30PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 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.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> drivers/tty/serdev/core.c | 19 +++++++++++++++++++
> include/linux/serdev.h | 9 +++++++++
> 2 files changed, 28 insertions(+)
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 3/8] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
From: Rob Herring @ 2026-03-30 19:29 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: 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, 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, Hans de Goede
In-Reply-To: <20260326-pci-m2-e-v7-3-43324a7866e6@oss.qualcomm.com>
On Thu, Mar 26, 2026 at 01:36:31PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 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.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
> 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(-)
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [GIT PULL] Immutable branch between pwrseq and serdev trees for v7.1-rc1
From: Bartosz Golaszewski @ 2026-03-31 7:54 UTC (permalink / raw)
To: Rob Herring, Manivannan Sadhasivam, Bjorn Helgaas
Cc: linux-serial, linux-arm-msm, linux-kernel, linux-pci,
Bartosz Golaszewski
Hi Rob!
Please pull the following serdev changes I queued as prerequisite to the
power sequencing updates for the M.2 driver.
Thanks
Bartosz
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/ib-pwrseq-serdev-for-v7.1
for you to fetch changes up to 1785c7bc1495e4e22377edffaf0ff8c3c697647d:
dt-bindings: serial: Document the graph port (2026-03-31 09:48:43 +0200)
----------------------------------------------------------------
Immutable branch between the pwrseq and serdev trees for v7.1-rc1
Provide new serdev helper for looking up controllers by their OF node
to be used in the power sequencing driver for the PCIe M.2 connector.
----------------------------------------------------------------
Manivannan Sadhasivam (4):
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
.../devicetree/bindings/serial/serial.yaml | 3 +++
drivers/tty/serdev/core.c | 28 +++++++++++++++++++++-
include/linux/serdev.h | 24 +++++++++----------
3 files changed, 42 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: (subset) [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Bartosz Golaszewski @ 2026-03-31 7:55 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,
Manivannan Sadhasivam
Cc: 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, Hans de Goede
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
On Thu, 26 Mar 2026 13:36:28 +0530, Manivannan Sadhasivam wrote:
> 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.
>
> [...]
Applied, thanks!
[1/8] serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
https://git.kernel.org/brgl/c/e7fef85039ccdba67d97b2a09f313aceeb6691c8
[2/8] serdev: Add an API to find the serdev controller associated with the devicetree node
https://git.kernel.org/brgl/c/a2b4814190af5944b276c5fd708d95ea146106b3
[3/8] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
https://git.kernel.org/brgl/c/92fa16ecad07dddc5703f7e2ff342441b04c45af
[4/8] dt-bindings: serial: Document the graph port
https://git.kernel.org/brgl/c/1785c7bc1495e4e22377edffaf0ff8c3c697647d
[5/8] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
https://git.kernel.org/brgl/c/5970c1dafb8adbeab5f6d9a22a4ad5b1c0067888
[7/8] power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
https://git.kernel.org/brgl/c/0d38285a12a283e12cd589ad5bb46c6f4a8cc647
[8/8] power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
https://git.kernel.org/brgl/c/3f736aecbdc8e4faf2ed82c981812a6bfc76ea98
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [tty:tty-testing] BUILD SUCCESS d50dd728ced93a1900ff0be924b6f273baf59fb2
From: kernel test robot @ 2026-03-31 13:06 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
branch HEAD: d50dd728ced93a1900ff0be924b6f273baf59fb2 hvc/xen: Check console connection flag
elapsed time: 758m
configs tested: 170
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260331 clang-23
arc randconfig-002-20260331 clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260331 clang-23
arm randconfig-002-20260331 clang-23
arm randconfig-003-20260331 clang-23
arm randconfig-004-20260331 clang-23
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260331 clang-18
arm64 randconfig-002-20260331 clang-18
arm64 randconfig-003-20260331 clang-18
arm64 randconfig-004-20260331 clang-18
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260331 clang-18
csky randconfig-002-20260331 clang-18
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260331 gcc-11.5.0
hexagon randconfig-002-20260331 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260331 clang-20
i386 buildonly-randconfig-002-20260331 clang-20
i386 buildonly-randconfig-003-20260331 clang-20
i386 buildonly-randconfig-004-20260331 clang-20
i386 buildonly-randconfig-005-20260331 clang-20
i386 buildonly-randconfig-006-20260331 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260331 gcc-14
i386 randconfig-002-20260331 gcc-14
i386 randconfig-003-20260331 gcc-14
i386 randconfig-004-20260331 gcc-14
i386 randconfig-005-20260331 gcc-14
i386 randconfig-006-20260331 gcc-14
i386 randconfig-007-20260331 gcc-14
i386 randconfig-011-20260331 clang-20
i386 randconfig-012-20260331 clang-20
i386 randconfig-013-20260331 clang-20
i386 randconfig-014-20260331 clang-20
i386 randconfig-015-20260331 clang-20
i386 randconfig-016-20260331 clang-20
i386 randconfig-017-20260331 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260331 gcc-11.5.0
loongarch randconfig-002-20260331 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip32_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260331 gcc-11.5.0
nios2 randconfig-002-20260331 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260331 clang-23
parisc randconfig-002-20260331 clang-23
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc pcm030_defconfig clang-23
powerpc randconfig-001-20260331 clang-23
powerpc randconfig-002-20260331 clang-23
powerpc64 alldefconfig clang-23
powerpc64 randconfig-001-20260331 clang-23
powerpc64 randconfig-002-20260331 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260331 gcc-15.2.0
riscv randconfig-002-20260331 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260331 gcc-15.2.0
s390 randconfig-002-20260331 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260331 gcc-15.2.0
sh randconfig-002-20260331 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260331 gcc-15.2.0
sparc randconfig-002-20260331 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260331 gcc-15.2.0
sparc64 randconfig-002-20260331 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260331 gcc-15.2.0
um randconfig-002-20260331 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260331 clang-20
x86_64 buildonly-randconfig-002-20260331 clang-20
x86_64 buildonly-randconfig-003-20260331 clang-20
x86_64 buildonly-randconfig-004-20260331 clang-20
x86_64 buildonly-randconfig-005-20260331 clang-20
x86_64 buildonly-randconfig-006-20260331 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260331 gcc-14
x86_64 randconfig-002-20260331 gcc-14
x86_64 randconfig-003-20260331 gcc-14
x86_64 randconfig-004-20260331 gcc-14
x86_64 randconfig-005-20260331 gcc-14
x86_64 randconfig-006-20260331 gcc-14
x86_64 randconfig-011-20260331 clang-20
x86_64 randconfig-012-20260331 clang-20
x86_64 randconfig-013-20260331 clang-20
x86_64 randconfig-014-20260331 clang-20
x86_64 randconfig-015-20260331 clang-20
x86_64 randconfig-016-20260331 clang-20
x86_64 randconfig-071-20260331 clang-20
x86_64 randconfig-072-20260331 clang-20
x86_64 randconfig-073-20260331 clang-20
x86_64 randconfig-074-20260331 clang-20
x86_64 randconfig-075-20260331 clang-20
x86_64 randconfig-076-20260331 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260331 gcc-15.2.0
xtensa randconfig-002-20260331 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [tty:tty-linus] BUILD SUCCESS 3ddbea7542ae529c1a88ef9a8b1ce169126211f6
From: kernel test robot @ 2026-03-31 13:14 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-linus
branch HEAD: 3ddbea7542ae529c1a88ef9a8b1ce169126211f6 vt: resize saved unicode buffer on alt screen exit after resize
elapsed time: 765m
configs tested: 172
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260331 clang-23
arc randconfig-002-20260331 clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260331 clang-23
arm randconfig-002-20260331 clang-23
arm randconfig-003-20260331 clang-23
arm randconfig-004-20260331 clang-23
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260331 clang-18
arm64 randconfig-002-20260331 clang-18
arm64 randconfig-003-20260331 clang-18
arm64 randconfig-004-20260331 clang-18
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260331 clang-18
csky randconfig-002-20260331 clang-18
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260331 gcc-11.5.0
hexagon randconfig-002-20260331 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260331 clang-20
i386 buildonly-randconfig-002-20260331 clang-20
i386 buildonly-randconfig-003-20260331 clang-20
i386 buildonly-randconfig-004-20260331 clang-20
i386 buildonly-randconfig-005-20260331 clang-20
i386 buildonly-randconfig-006-20260331 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260331 gcc-14
i386 randconfig-002-20260331 gcc-14
i386 randconfig-003-20260331 gcc-14
i386 randconfig-004-20260331 gcc-14
i386 randconfig-005-20260331 gcc-14
i386 randconfig-006-20260331 gcc-14
i386 randconfig-007-20260331 gcc-14
i386 randconfig-011-20260331 clang-20
i386 randconfig-012-20260331 clang-20
i386 randconfig-013-20260331 clang-20
i386 randconfig-014-20260331 clang-20
i386 randconfig-015-20260331 clang-20
i386 randconfig-016-20260331 clang-20
i386 randconfig-017-20260331 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260331 gcc-11.5.0
loongarch randconfig-002-20260331 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip32_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260331 gcc-11.5.0
nios2 randconfig-002-20260331 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260331 clang-23
parisc randconfig-002-20260331 clang-23
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc pcm030_defconfig clang-23
powerpc randconfig-001-20260331 clang-23
powerpc randconfig-002-20260331 clang-23
powerpc64 alldefconfig clang-23
powerpc64 randconfig-001-20260331 clang-23
powerpc64 randconfig-002-20260331 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260331 gcc-15.2.0
riscv randconfig-002-20260331 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260331 gcc-15.2.0
s390 randconfig-002-20260331 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260331 gcc-15.2.0
sh randconfig-002-20260331 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260331 gcc-15.2.0
sparc randconfig-002-20260331 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260331 gcc-15.2.0
sparc64 randconfig-002-20260331 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260331 gcc-15.2.0
um randconfig-002-20260331 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260331 clang-20
x86_64 buildonly-randconfig-002-20260331 clang-20
x86_64 buildonly-randconfig-003-20260331 clang-20
x86_64 buildonly-randconfig-004-20260331 clang-20
x86_64 buildonly-randconfig-005-20260331 clang-20
x86_64 buildonly-randconfig-006-20260331 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260331 gcc-14
x86_64 randconfig-002-20260331 gcc-14
x86_64 randconfig-003-20260331 gcc-14
x86_64 randconfig-004-20260331 gcc-14
x86_64 randconfig-005-20260331 clang-20
x86_64 randconfig-005-20260331 gcc-14
x86_64 randconfig-006-20260331 clang-20
x86_64 randconfig-006-20260331 gcc-14
x86_64 randconfig-011-20260331 clang-20
x86_64 randconfig-012-20260331 clang-20
x86_64 randconfig-013-20260331 clang-20
x86_64 randconfig-014-20260331 clang-20
x86_64 randconfig-015-20260331 clang-20
x86_64 randconfig-016-20260331 clang-20
x86_64 randconfig-071-20260331 clang-20
x86_64 randconfig-072-20260331 clang-20
x86_64 randconfig-073-20260331 clang-20
x86_64 randconfig-074-20260331 clang-20
x86_64 randconfig-075-20260331 clang-20
x86_64 randconfig-076-20260331 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260331 gcc-15.2.0
xtensa randconfig-002-20260331 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH tty v1] serial: 8250: Add support for console hardware flow control
From: John Ogness @ 2026-03-31 14:14 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, Ilpo Järvinen, Thomas Gleixner, Ingo Molnar,
Xin Zhao, Andy Shevchenko, Dr. David Alan Gilbert, Joseph Tilahun,
linux-serial
The kernel documentation specifies that the console option 'r' can
be used to enable hardware flow control for console writes. The 8250
driver does include code for hardware flow control on the console if
the UPF_CONS_FLOW flag is set, but there is no code path that sets
this flag. However, that is not the only issue. The problems are:
1. Specifying the console option 'r' does not lead to UPF_CONS_FLOW
being set.
2. Even if UPF_CONS_FLOW would be set, serial8250_register_8250_port()
clears it.
3. When the console option 'r' is specified, uart_set_options()
attempts to initialize the port for CRTSCTS. However, afterwards
it does not set the UPSTAT_CTS_ENABLE status bit and therefore on
boot, uart_cts_enabled() is always false. This policy bit is
important for console drivers as a criteria if they may poll CTS.
4. Even though uart_set_options() attempts to initialized the port
for CRTSCTS, the 8250 set_termios() callback does not enable the
RTS signal (TIOCM_RTS) and thus the hardware is not properly
initialized for CTS polling.
5. Even if modem control was properly setup for CTS polling
(TIOCM_RTS), uart_configure_port() clears TIOCM_RTS, thus
breaking CTS polling.
6. wait_for_xmitr() and serial8250_console_write() use the
UPF_CONS_FLOW bit to decide if CTS polling should occur. However,
the condition should also include a check that it is not in rs485
mode and CRTSCTS is actually enabled in the hardware.
Address all these issues as conservatively as possible by gating them
behind checks focussed on the user specifying console hardware flow
control support and the hardware being configured for CTS polling
at the time of the write to the uart.
Since checking the UPSTAT_CTS_ENABLE status bit is a part of the new
condition gate, these changes also support runtime termios updates to
disable/enable CRTSCTS.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/8250/8250_core.c | 7 +++++++
drivers/tty/serial/8250/8250_port.c | 14 ++++++++++++--
drivers/tty/serial/serial_core.c | 18 +++++++++++++++++-
include/linux/serial_core.h | 8 ++++++++
4 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index a428e88938eb7..fd3441dd9a559 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -693,6 +693,7 @@ static void serial_8250_overrun_backoff_work(struct work_struct *work)
int serial8250_register_8250_port(const struct uart_8250_port *up)
{
struct uart_8250_port *uart;
+ bool console_hwflow;
int ret;
if (up->port.uartclk == 0)
@@ -716,6 +717,9 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
if (uart->port.type == PORT_8250_CIR)
return -ENODEV;
+ /* Preserve specified console hardware flow control. */
+ console_hwflow = uart->port.flags & UPF_CONS_FLOW;
+
if (uart->port.dev)
uart_remove_one_port(&serial8250_reg, &uart->port);
@@ -757,6 +761,9 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
goto err;
}
+ if (console_hwflow)
+ uart->port.flags |= UPF_CONS_FLOW;
+
if (up->port.flags & UPF_FIXED_TYPE)
uart->port.type = up->port.type;
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index af78cc02f38e7..88f5309a940e9 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1988,7 +1988,7 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
wait_for_lsr(up, bits);
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_console_hwflow_active(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
@@ -2782,6 +2782,12 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios,
serial8250_set_efr(port, termios);
serial8250_set_divisor(port, baud, quot, frac);
serial8250_set_fcr(port, termios);
+ /* Consoles manually poll CTS for hardware flow control. */
+ if (uart_console(port) &&
+ !(port->rs485.flags & SER_RS485_ENABLED)
+ && termios->c_cflag & CRTSCTS) {
+ port->mctrl |= TIOCM_RTS;
+ }
serial8250_set_mctrl(port, port->mctrl);
}
@@ -3351,7 +3357,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
* it regardless of the CTS state. Therefore, only use fifo
* if we don't use control flow.
*/
- !(up->port.flags & UPF_CONS_FLOW);
+ !uart_console_hwflow_active(&up->port);
if (likely(use_fifo))
serial8250_console_fifo_write(up, s, count);
@@ -3421,6 +3427,10 @@ int serial8250_console_setup(struct uart_port *port, char *options, bool probe)
if (ret)
return ret;
+ /* Allow user-specified hardware flow control. */
+ if (flow == 'r')
+ port->flags |= UPF_CONS_FLOW;
+
if (port->dev)
pm_runtime_get_sync(port->dev);
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 89cebdd278410..cce1fd728a1e4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2235,6 +2235,15 @@ uart_set_options(struct uart_port *port, struct console *co,
port->mctrl |= TIOCM_DTR;
port->ops->set_termios(port, &termios, &dummy);
+
+ /*
+ * If console hardware flow control was specified and is supported,
+ * the related policy UPSTAT_CTS_ENABLE must be set to allow console
+ * drivers to identify if CTS should be used for polling.
+ */
+ if (flow == 'r' && (termios.c_cflag & CRTSCTS))
+ port->status |= UPSTAT_CTS_ENABLE;
+
/*
* Allow the setting of the UART parameters with a NULL console
* too:
@@ -2541,7 +2550,14 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
* We probably don't need a spinlock around this, but
*/
scoped_guard(uart_port_lock_irqsave, port) {
- port->mctrl &= TIOCM_DTR;
+ unsigned int mask = TIOCM_DTR;
+
+ /* Console hardware flow control polls CTS. */
+ if (uart_console_hwflow_active(port))
+ mask |= TIOCM_RTS;
+
+ port->mctrl &= mask;
+
if (!(port->rs485.flags & SER_RS485_ENABLED))
port->ops->set_mctrl(port, port->mctrl);
}
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 666430b478997..07bd3bd6c8355 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -1163,6 +1163,14 @@ static inline bool uart_softcts_mode(struct uart_port *uport)
return ((uport->status & mask) == UPSTAT_CTS_ENABLE);
}
+static inline bool uart_console_hwflow_active(struct uart_port *uport)
+{
+ return uart_console(uport) &&
+ !(uport->rs485.flags & SER_RS485_ENABLED) &&
+ (uport->flags & UPF_CONS_FLOW) &&
+ uart_cts_enabled(uport);
+}
+
/*
* The following are helper functions for the low level drivers.
*/
base-commit: d50dd728ced93a1900ff0be924b6f273baf59fb2
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 00/10] fbcon,fonts: Refactor framebuffer console rotation
From: Helge Deller @ 2026-03-31 15:08 UTC (permalink / raw)
To: Thomas Zimmermann, gregkh, jirislaby, simona, sam
Cc: linux-fbdev, dri-devel, linux-kernel, linux-serial
In-Reply-To: <20260327130431.59481-1-tzimmermann@suse.de>
Hi Thomas,
On 3/27/26 13:49, Thomas Zimmermann wrote:
> Refactor the framebuffer console rotation into individual components
> for glyphs, fonts and the overall fbcon state. Right now this is mixed
> up in fbcon_rotate.{c,h}. Also build cursor rotation on top of the new
> interfaces.
>
> Start with an OOB fix in patch 1. If buffer allocation fails, fbcon
> currently uses a too-small glyph buffer for output. Avoid that.
>
> Patches 2 to 4 make a number of small improvements to the font library
> and its callers.
>
> Patches 5 to 8 refactor the font rotation. Fbcon rotation rotates each
> individual glphy in a font buffer and uses the rotated buffer's glyphs
> for output. The result looks like the console buffer has been rotated
> as a whole. Split this into helpers that rotate individual glyphs and
> a helper that rotates the font buffer of these. Then reimplement fbcon
> rotation on top. Document the public font helpers.
>
> Patch 9 rebuilds cursor rotation on top of the new glyph helpers. The
> fbcon cursor is itself a glyph that has to be rotated in sync with the
> font.
>
> Patch 10 moves the state of fbcon rotation into a single place and makes
> is a build-time conditional.
>
> Tested with fbcon under bochs on Qemu.
>
> Built upon the fbcon changes at [1].
>
> [1] https://lore.kernel.org/linux-fbdev/20260309141723.137364-1-tzimmermann@suse.de/
Thanks a lot for this cleanup work!
I've applied this series to the fbdev git tree.
Helge
> Thomas Zimmermann (10):
> fbcon: Avoid OOB font access if console rotation fails
> vt: Implement helpers for struct vc_font in source file
> lib/fonts: Provide helpers for calculating glyph pitch and size
> lib/fonts: Clean up Makefile
> lib/fonts: Implement glyph rotation
> lib/fonts: Refactor glyph-pattern helpers
> lib/fonts: Refactor glyph-rotation helpers
> lib/fonts: Implement font rotation
> fbcon: Fill cursor mask in helper function
> fbcon: Put font-rotation state into separate struct
>
> drivers/tty/vt/vt.c | 34 +++
> drivers/video/fbdev/core/bitblit.c | 35 +--
> drivers/video/fbdev/core/fbcon.c | 48 ++++-
> drivers/video/fbdev/core/fbcon.h | 14 +-
> drivers/video/fbdev/core/fbcon_ccw.c | 70 ++----
> drivers/video/fbdev/core/fbcon_cw.c | 70 ++----
> drivers/video/fbdev/core/fbcon_rotate.c | 88 ++------
> drivers/video/fbdev/core/fbcon_rotate.h | 71 ------
> drivers/video/fbdev/core/fbcon_ud.c | 67 ++----
> include/linux/console_struct.h | 30 +--
> include/linux/font.h | 51 +++++
> lib/fonts/Makefile | 36 ++--
> lib/fonts/font_rotate.c | 275 ++++++++++++++++++++++++
> lib/fonts/fonts.c | 2 +-
> 14 files changed, 525 insertions(+), 366 deletions(-)
> create mode 100644 lib/fonts/font_rotate.c
>
^ permalink raw reply
* Re: [PATCH 00/10] fbcon,fonts: Refactor framebuffer console rotation
From: Thomas Zimmermann @ 2026-03-31 15:29 UTC (permalink / raw)
To: Helge Deller, gregkh, jirislaby, simona, sam
Cc: linux-fbdev, dri-devel, linux-kernel, linux-serial
In-Reply-To: <7c963dce-7b39-4047-b0bb-548957852d65@gmx.de>
Hi
Am 31.03.26 um 17:08 schrieb Helge Deller:
> Hi Thomas,
>
> On 3/27/26 13:49, Thomas Zimmermann wrote:
>> Refactor the framebuffer console rotation into individual components
>> for glyphs, fonts and the overall fbcon state. Right now this is mixed
>> up in fbcon_rotate.{c,h}. Also build cursor rotation on top of the new
>> interfaces.
>>
>> Start with an OOB fix in patch 1. If buffer allocation fails, fbcon
>> currently uses a too-small glyph buffer for output. Avoid that.
>>
>> Patches 2 to 4 make a number of small improvements to the font library
>> and its callers.
>>
>> Patches 5 to 8 refactor the font rotation. Fbcon rotation rotates each
>> individual glphy in a font buffer and uses the rotated buffer's glyphs
>> for output. The result looks like the console buffer has been rotated
>> as a whole. Split this into helpers that rotate individual glyphs and
>> a helper that rotates the font buffer of these. Then reimplement fbcon
>> rotation on top. Document the public font helpers.
>>
>> Patch 9 rebuilds cursor rotation on top of the new glyph helpers. The
>> fbcon cursor is itself a glyph that has to be rotated in sync with the
>> font.
>>
>> Patch 10 moves the state of fbcon rotation into a single place and makes
>> is a build-time conditional.
>>
>> Tested with fbcon under bochs on Qemu.
>>
>> Built upon the fbcon changes at [1].
>>
>> [1]
>> https://lore.kernel.org/linux-fbdev/20260309141723.137364-1-tzimmermann@suse.de/
>
>
> Thanks a lot for this cleanup work!
>
> I've applied this series to the fbdev git tree.
Thanks a lot.
There's a small typo in patch 2 that I noticed when Greg gave his ack.
The commit description say <liux/math.h> instead of <linux/math.h>. Let
me know whether you can fix it or if I should send an update.
Best regards
Thomas
>
> Helge
>
>
>> Thomas Zimmermann (10):
>> fbcon: Avoid OOB font access if console rotation fails
>> vt: Implement helpers for struct vc_font in source file
>> lib/fonts: Provide helpers for calculating glyph pitch and size
>> lib/fonts: Clean up Makefile
>> lib/fonts: Implement glyph rotation
>> lib/fonts: Refactor glyph-pattern helpers
>> lib/fonts: Refactor glyph-rotation helpers
>> lib/fonts: Implement font rotation
>> fbcon: Fill cursor mask in helper function
>> fbcon: Put font-rotation state into separate struct
>>
>> drivers/tty/vt/vt.c | 34 +++
>> drivers/video/fbdev/core/bitblit.c | 35 +--
>> drivers/video/fbdev/core/fbcon.c | 48 ++++-
>> drivers/video/fbdev/core/fbcon.h | 14 +-
>> drivers/video/fbdev/core/fbcon_ccw.c | 70 ++----
>> drivers/video/fbdev/core/fbcon_cw.c | 70 ++----
>> drivers/video/fbdev/core/fbcon_rotate.c | 88 ++------
>> drivers/video/fbdev/core/fbcon_rotate.h | 71 ------
>> drivers/video/fbdev/core/fbcon_ud.c | 67 ++----
>> include/linux/console_struct.h | 30 +--
>> include/linux/font.h | 51 +++++
>> lib/fonts/Makefile | 36 ++--
>> lib/fonts/font_rotate.c | 275 ++++++++++++++++++++++++
>> lib/fonts/fonts.c | 2 +-
>> 14 files changed, 525 insertions(+), 366 deletions(-)
>> create mode 100644 lib/fonts/font_rotate.c
>>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Stephan Gerhold @ 2026-03-31 16:29 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Mark Pearson, Dmitry Baryshkov, Rob Herring,
Manivannan Sadhasivam, Greg KH, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen,
Derek J . Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Andy Shevchenko, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86@vger.kernel.org, linux-pci,
devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
linux-acpi@vger.kernel.org
In-Reply-To: <cvqdbqnzjmzoowxkvz2lyv4avropu5jw7h2r6zng3ecf245hgg@fsysjqflqd35>
On Wed, Mar 25, 2026 at 05:36:08PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 23, 2026 at 01:23:07PM -0400, Mark Pearson wrote:
> > On Mon, Mar 23, 2026, at 12:52 PM, Manivannan Sadhasivam wrote:
> > > On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
> > >> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> > >> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> > >> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > >> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > >> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >> > > > > >
> > >> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > >> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > >> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > >> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > >> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > >> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > >> > > > > > > > to reuse the Key E binding.
> > >> > > > > > >
> > >> > > > > > > What is LGA?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Land Grid Array
> > >> > > > > >
> > >> > > > > > > If not in the spec, is it really something generic?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > >> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > >> > > > > > the spec gives room for hardware designers to be as innovative as possible to
> > >> > > > > > save the BOM cost.
> > >> > > > >
> > >> > > > > innovation == incompatible changes
> > >> > > > >
> > >> > > >
> > >> > > > Yes, I was trying to sound nice :)
> > >> > > >
> > >> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > >> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > >> > > > >
> > >> > > > > Depends if you think that s/w needs to know the differences. Hard to
> > >> > > > > say with a sample size of 1.
> > >> > > > >
> > >> > > >
> > >> > > > Sure. Will add the 'lenovo' prefix then.
> > >> > >
> > >> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> > >> > > being used by Lenovo?
> > >> > >
> > >> > > I remember that DB820c also used some kind of a module for the WiFi card
> > >> > > (which might be M.2 compatible or might not, I can't find exact docs at
> > >> > > this point).
> > >> > >
> > >> >
> > >> > I don't know. These kind of designs might be reused by several vendors. But
> > >> > considering that we should not make it generic, I'd go with Lenovo as that's
> > >> > the only vendor we know as of now.
> > >>
> > >> ... and later we learn that other vendors use the same idea /pinout,
> > >> then nothing stops us from still telling that it's a
> > >> "lenovo,pcie-m2-something-lga".
> > >>
> > >
> > > How do you possibly know whether a single vendor has introduced this form factor
> > > or reused by multiple ones? Atleast, I don't have access to such a source to
> > > confirm.
> > >
> > I've not really been following this thread/patchset in detail; but want me to try and check with the T14s platform team if this device is specifically made for us (Lenovo) or not?
> > I doubt it is - we just don't do that usually, but I can go and ask the question if it will help resolve this (with the caveat that it could hold up the review for a bit and I may not be able to get a straight answer)
> >
>
> I can drop this specific patch in the meantime.
>
> > My vote (for what little it's worth) would be to make it non-Lenovo specific. Then when the same part causes issues on another vendors platform I won't get asked questions about why Lenovo is breaking <other vendor> :)
> >
>
> Even if Lenovo prefix is used, it won't break other vendors. Just that we will
> end up adding more compatibles.
>
> Anyhow, I'll wait for your reply and drop this patch for next revision.
>
If you need a vendor prefix, I think "qcom," would be more appropriate
than Lenovo. This form factor is used by most vendors for recent
soldered Qualcomm-based wireless cards, not just Lenovo:
- Dell XPS 13 9345 has exactly the same soldered M.2 card, I assume
there are several other vendors as well.
- https://www.sparklan.com/product/wnsq-290be/ is a third-party
(Qualcomm-based) M.2 LGA 1620 card, in the block diagram the
pinout is called "QM.2 1620 LGA 168pin".
- If you press F9 while booting the ThinkPad T14s, you should get to a
screen with "Regulatory Information". For the T14s, this screen says
"Contains FCC ID: J9C-QCNCM825". This is the WiFi/BT module in the
soldered form factor. If you look that up on the FCC website, the
applicant for this module is "Qualcomm Technologies, Inc.". This
seems to be some kind of "modular certification" that vendors can
reuse/adapt without going through the whole process again.
Perhaps you should ask around inside Qualcomm? :-)
Thanks,
Stephan
^ permalink raw reply
* Re: [PATCH tty v1] serial: 8250: Add support for console hardware flow control
From: John Ogness @ 2026-03-31 23:50 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, Ilpo Järvinen, Thomas Gleixner, Ingo Molnar,
Xin Zhao, Andy Shevchenko, Dr. David Alan Gilbert, Joseph Tilahun,
linux-serial
In-Reply-To: <20260331141502.6233-1-john.ogness@linutronix.de>
Hi,
Responding to Sashiko:
https://sashiko.dev/#/patchset/20260331141502.6233-1-john.ogness%40linutronix.de
On 2026-03-31, Sashiko wrote:
> This commit addresses issues with hardware flow control on the 8250 console.
> It modifies the driver and serial core to properly initialize CTS polling
> and handle the 'r' console option.
>
>> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
>> index d2e2c5dfef99..4ca7cac6b8a7 100644
>> --- a/drivers/tty/serial/8250/8250_core.c
>> +++ b/drivers/tty/serial/8250/8250_core.c
>> @@ -716,6 +717,9 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
>> if (uart->port.type == PORT_8250_CIR)
>> return -ENODEV;
>>
>> + /* Preserve specified console hardware flow control. */
>> + console_hwflow = uart->port.flags & UPF_CONS_FLOW;
>> +
>> if (uart->port.dev)
>> uart_remove_one_port(&serial8250_reg, &uart->port);
>>
>> @@ -757,6 +761,9 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
>> goto err;
>> }
>>
>> + if (console_hwflow)
>> + uart->port.flags |= UPF_CONS_FLOW;
>> +
>
> Can this create a race window where console flow control is temporarily
> disabled? The UPF_CONS_FLOW flag is saved, but uart->port.flags is
> overwritten earlier in this function. If an asynchronous printk (such as
> from an NMI) triggers serial8250_console_write() before the flag is
> restored, it seems uart_console_hwflow_active() will evaluate to false,
> bypassing CTS polling and potentially dropping characters.
Correct. I missed that serial8250_register_8250_port() is called after
the console is already registered via univ8250_console_init(). I can
remove the window with something like the following alternative change
to serial8250_register_8250_port():
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index a428e88938eb7..ff4c9972d4576 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -693,6 +693,7 @@ static void serial_8250_overrun_backoff_work(struct work_struct *work)
int serial8250_register_8250_port(const struct uart_8250_port *up)
{
struct uart_8250_port *uart;
+ upf_t console_hwflow;
int ret;
if (up->port.uartclk == 0)
@@ -716,6 +717,9 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
if (uart->port.type == PORT_8250_CIR)
return -ENODEV;
+ /* Preserve specified console hardware flow control. */
+ console_hwflow = uart->port.flags & UPF_CONS_FLOW;
+
if (uart->port.dev)
uart_remove_one_port(&serial8250_reg, &uart->port);
@@ -729,7 +733,7 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
uart->port.fifosize = up->port.fifosize;
uart->port.regshift = up->port.regshift;
uart->port.iotype = up->port.iotype;
- uart->port.flags = up->port.flags | UPF_BOOT_AUTOCONF;
+ uart->port.flags = up->port.flags | UPF_BOOT_AUTOCONF | console_hwflow;
uart->bugs = up->bugs;
uart->port.mapbase = up->port.mapbase;
uart->port.mapsize = up->port.mapsize;
>> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
>> index 328711b5df1a..71edac12473e 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -1988,7 +1988,7 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
>> wait_for_lsr(up, bits);
>>
>> /* Wait up to 1s for flow control if necessary */
>> - if (up->port.flags & UPF_CONS_FLOW) {
>> + if (uart_console_hwflow_active(&up->port)) {
>> for (tmout = 1000000; tmout; tmout--) {
>> unsigned int msr = serial_in(up, UART_MSR);
>> up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
>> if (msr & UART_MSR_CTS)
>> break;
>> udelay(1);
>> touch_nmi_watchdog();
>> }
>> }
>> }
>
> Does this sequence of checks cause data loss when CTS is deasserted?
> If wait_for_lsr() times out because the UART halts transmission, the holding
> register remains full. When CTS is subsequently asserted, the loop breaks
> and the function returns immediately without waiting for the holding register
> to actually empty. Will the next character overwrite the current one before it
> can be shifted out?
Correct. My patch does not address errors in the CTS polling, but
perhaps it should (since I am activating CTS polling). In this case I
suppose one final wait_for_lsr() is appropriate. Something like:
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 88f5309a940e9..18bc5600df181 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1984,16 +1984,20 @@ static bool wait_for_lsr(struct uart_8250_port *up, int bits)
static void wait_for_xmitr(struct uart_8250_port *up, int bits)
{
unsigned int tmout;
+ bool lsr_timeout;
- wait_for_lsr(up, bits);
+ lsr_timeout = wait_for_lsr(up, bits);
/* Wait up to 1s for flow control if necessary */
if (uart_console_hwflow_active(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
- if (msr & UART_MSR_CTS)
+ if (msr & UART_MSR_CTS) {
+ if (lsr_timeout)
+ wait_for_lsr(up, bits);
break;
+ }
udelay(1);
touch_nmi_watchdog();
}
> Also, could this polling loop cause a system stall?
> If the remote peer deasserts CTS (for example, if a terminal is disconnected),
> wait_for_xmitr() will poll for 1,000,000 microseconds. Since this is called
> for every single character during a printk, a standard 50-character printk
> could potentially stall the entire system for 50 seconds while holding the
> console lock.
Yes, this is a problem (for !PREEMPT_RT). But that is how console
hardware flow control is implemented. It is out of scope of my patch to
completely re-implement the CTS polling mechanism. AFAICT the other
serial drivers that already support console hardware flow control have
the same problem. Does this need to be resolved as a pre-requisite to my
patch?
>> @@ -3421,6 +3427,10 @@ int serial8250_console_setup(struct uart_port *port, char *options, bool probe)
>> if (ret)
>> return ret;
>>
>> + /* Allow user-specified hardware flow control. */
>> + if (flow == 'r')
>> + port->flags |= UPF_CONS_FLOW;
>> +
>> if (port->dev)
>> pm_runtime_get_sync(port->dev);
>
> Should this flag be cleared if flow != 'r'? By only setting the flag, it
> appears hardware flow control cannot be dynamically disabled once it has
> been enabled.
The flag comes from a boot argument. Boot arguments never change during
runtime. The hardware flow control can still by dynamically disabled by
disabling CRTSCTS via termios. For example:
# stty -F /dev/ttyS0 -crtscts
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index 89cebdd27841..cce1fd728a1e 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -2235,6 +2235,15 @@ uart_set_options(struct uart_port *port, struct console *co,
>> port->mctrl |= TIOCM_DTR;
>>
>> port->ops->set_termios(port, &termios, &dummy);
>> +
>> + /*
>> + * If console hardware flow control was specified and is supported,
>> + * the related policy UPSTAT_CTS_ENABLE must be set to allow console
>> + * drivers to identify if CTS should be used for polling.
>> + */
>> + if (flow == 'r' && (termios.c_cflag & CRTSCTS))
>> + port->status |= UPSTAT_CTS_ENABLE;
>> +
>
> Similar to the previous question, should UPSTAT_CTS_ENABLE be cleared
> if flow != 'r' to prevent the state from leaking?
This is a valid question. My patch is trying to be maximally
conservative and only make changes to allow CTS polling to become active
when 'r' is specified. For all other cases I do not want behavior
changes. Particularly since this is a function within serial_core.
> Additionally, does port->status need to be protected by the port lock here?
> Since this is a read-modify-write operation, and uart_set_options() can
> be invoked dynamically (like from kgdboc via tty_find_polling_driver()),
> could this race with concurrent modifications to port->status?
Yes. I was only considering the boot case where the tty layer is not yet
active. :-/ It seems some drivers are only taking the port lock for
@status updates.
The comments in serial_core.h say "Must hold termios_rwsem, port mutex
and port lock to change" but AFAICT the main @status modifiers are only
taking the last 2 locks. Still, the port mutex cannot be taken in
uart_set_options().
I would really like to leverage the UPSTAT_CTS_ENABLE policy bit. I will
need to think about this some more...
John Ogness
^ permalink raw reply related
* [PATCH 0/3] Pwrseq/serdev fixes
From: Manivannan Sadhasivam @ 2026-04-01 7:07 UTC (permalink / raw)
To: brgl, robh
Cc: linux-pci, linux-pm, linux-kernel, linux-serial, mani,
Manivannan Sadhasivam
Hi Bartosz,
This series fixes build issues reported by kernel test robot on the recently
merged M.2 Key E pwrseq series.
Patches 2 and 3 can be squashed with offending commits, while patch 1 should be
applied separately.
- Mani
Manivannan Sadhasivam (3):
serdev: Add missing stubs for serdev APIs when CONFIG_SERIAL_DEV_BUS
is not selected
serdev: Add CONFIG_SERIAL_DEV_BUS guard for
of_find_serdev_controller_by_node() API
power: sequencing: pcie-m2: Guard the helper functions making use of
PCI bus notifier
drivers/power/sequencing/pwrseq-pcie-m2.c | 9 +++++
include/linux/serdev.h | 46 +++++++++++++++++------
2 files changed, 43 insertions(+), 12 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH 1/3] serdev: Add missing stubs for serdev APIs when CONFIG_SERIAL_DEV_BUS is not selected
From: Manivannan Sadhasivam @ 2026-04-01 7:07 UTC (permalink / raw)
To: brgl, robh
Cc: linux-pci, linux-pm, linux-kernel, linux-serial, mani,
Manivannan Sadhasivam, kernel test robot
In-Reply-To: <20260401070735.107162-1-manivannan.sadhasivam@oss.qualcomm.com>
Some of the serdev APIs are not guarded by CONFIG_SERIAL_DEV_BUS and also
missing the stubs when the symbol is not selected. This leads to the below
build errors:
drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_pcie_m2_remove_serdev':
>> pwrseq-pcie-m2.c:(.text+0x260): undefined reference to `serdev_device_remove'
powerpc64-linux-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_m2_pcie_notify':
>> powerpc64-linux-ld: pwrseq-pcie-m2.c:(.text+0x9c8): undefined reference to `serdev_device_alloc'
>> powerpc64-linux-ld: pwrseq-pcie-m2.c:(.text+0xc00): undefined reference to `serdev_device_add'
Fix these issues by adding the CONFIG_SERIAL_DEV_BUS guard to function
prototypes and stubs when the symbol is not selected.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604011226.KGNn5974-lkp@intel.com/
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
include/linux/serdev.h | 42 ++++++++++++++++++++++++++++++++----------
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 188c0ba62d50..0de261a26284 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -156,16 +156,6 @@ static inline void serdev_controller_put(struct serdev_controller *ctrl)
put_device(&ctrl->dev);
}
-struct serdev_device *serdev_device_alloc(struct serdev_controller *);
-int serdev_device_add(struct serdev_device *);
-void serdev_device_remove(struct serdev_device *);
-
-struct serdev_controller *serdev_controller_alloc(struct device *host,
- struct device *parent,
- size_t size);
-int serdev_controller_add(struct serdev_controller *);
-void serdev_controller_remove(struct serdev_controller *);
-
static inline void serdev_controller_write_wakeup(struct serdev_controller *ctrl)
{
struct serdev_device *serdev = ctrl->serdev;
@@ -204,6 +194,16 @@ void serdev_device_write_wakeup(struct serdev_device *);
ssize_t serdev_device_write(struct serdev_device *, const u8 *, size_t, long);
void serdev_device_write_flush(struct serdev_device *);
+struct serdev_device *serdev_device_alloc(struct serdev_controller *);
+int serdev_device_add(struct serdev_device *);
+void serdev_device_remove(struct serdev_device *);
+
+struct serdev_controller *serdev_controller_alloc(struct device *host,
+ struct device *parent,
+ size_t size);
+int serdev_controller_add(struct serdev_controller *);
+void serdev_controller_remove(struct serdev_controller *);
+
/*
* serdev device driver functions
*/
@@ -264,6 +264,28 @@ static inline ssize_t serdev_device_write(struct serdev_device *sdev,
}
static inline void serdev_device_write_flush(struct serdev_device *sdev) {}
+static inline struct serdev_device *serdev_device_alloc(struct serdev_controller *)
+{
+ return NULL;
+}
+static inline int serdev_device_add(struct serdev_device *)
+{
+ return -ENODEV;
+}
+static inline void serdev_device_remove(struct serdev_device *) {}
+
+static inline struct serdev_controller *serdev_controller_alloc(struct device *host,
+ struct device *parent,
+ size_t size)
+{
+ return NULL;
+}
+static inline int serdev_controller_add(struct serdev_controller *)
+{
+ return -ENODEV;
+}
+static inline void serdev_controller_remove(struct serdev_controller *) {}
+
#define serdev_device_driver_register(x)
#define serdev_device_driver_unregister(x)
--
2.51.0
^ permalink raw reply related
* [PATCH 2/3] serdev: Add CONFIG_SERIAL_DEV_BUS guard for of_find_serdev_controller_by_node() API
From: Manivannan Sadhasivam @ 2026-04-01 7:07 UTC (permalink / raw)
To: brgl, robh
Cc: linux-pci, linux-pm, linux-kernel, linux-serial, mani,
Manivannan Sadhasivam, kernel test robot
In-Reply-To: <20260401070735.107162-1-manivannan.sadhasivam@oss.qualcomm.com>
Currently, this API is only guarded by CONFIG_OF. But the function
definition is guarded by CONFIG_SERIAL_DEV_BUS symbol in the .c file. This
causes below build error if CONFIG_SERIAL_DEV_BUS is not selected but only
CONFIG_OF:
pwrseq-pcie-m2.c:(.text+0x924): undefined reference to `of_find_serdev_controller_by_node'
Fix this issue by adding the CONFIG_SERIAL_DEV_BUS guard to the function
prototype.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604011226.KGNn5974-lkp@intel.com/
Fixes: a2b4814190af ("serdev: Add an API to find the serdev controller associated with the devicetree node")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
include/linux/serdev.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 0de261a26284..58f000534bdb 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -356,13 +356,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
}
#endif /* CONFIG_ACPI */
-#ifdef CONFIG_OF
+#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
#else
static inline struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
{
return NULL;
}
-#endif /* CONFIG_OF */
+#endif /* CONFIG_OF && CONFIG_SERIAL_DEV_BUS */
#endif /*_LINUX_SERDEV_H */
--
2.51.0
^ permalink raw reply related
* [PATCH 3/3] power: sequencing: pcie-m2: Guard the helper functions making use of PCI bus notifier
From: Manivannan Sadhasivam @ 2026-04-01 7:07 UTC (permalink / raw)
To: brgl, robh
Cc: linux-pci, linux-pm, linux-kernel, linux-serial, mani,
Manivannan Sadhasivam, kernel test robot
In-Reply-To: <20260401070735.107162-1-manivannan.sadhasivam@oss.qualcomm.com>
The PCI bus notifier is only visible if CONFIG_PCI symbol is selected in
Kconfig. But this driver can be built without CONFIG_PCI due to
CONFIG_COMPILE_TEST, leading to below build error:
drivers/power/sequencing/pwrseq-pcie-m2.c: In function 'pwrseq_pcie_m2_free_resources':
>> drivers/power/sequencing/pwrseq-pcie-m2.c:185:34: error: 'pci_bus_type' undeclared (first use in this function); did you mean 'pci_pcie_type'?
185 | bus_unregister_notifier(&pci_bus_type, &ctx->nb);
| ^~~~~~~~~~~~
| pci_pcie_type
drivers/power/sequencing/pwrseq-pcie-m2.c:185:34: note: each undeclared identifier is reported only once for each function it appears in
drivers/power/sequencing/pwrseq-pcie-m2.c: In function 'pwrseq_pcie_m2_register_notifier':
drivers/power/sequencing/pwrseq-pcie-m2.c:340:54: error: 'pci_bus_type' undeclared (first use in this function); did you mean 'pci_pcie_type'?
340 | ret = bus_register_notifier(&pci_bus_type, &ctx->nb);
| ^~~~~~~~~~~~
| pci_pcie_type
So add guards to make sure that all these helper functions making use of
the PCI bus notifier are only compiled if CONFIG_PCI is selected.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603180609.ucspJefN-lkp@intel.com
Fixes: 3f736aecbdc8 ("power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/power/sequencing/pwrseq-pcie-m2.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index a75ca4fda2eb..d3102fea8d93 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -177,6 +177,7 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
return PWRSEQ_NO_MATCH;
}
+#if IS_ENABLED(CONFIG_PCI)
static int pwrseq_m2_pcie_create_bt_node(struct pwrseq_pcie_m2_ctx *ctx,
struct device_node *parent)
{
@@ -374,6 +375,12 @@ static int pwrseq_pcie_m2_register_notifier(struct pwrseq_pcie_m2_ctx *ctx, stru
return 0;
}
+#else
+static int pwrseq_pcie_m2_register_notifier(struct pwrseq_pcie_m2_ctx *ctx, struct device *dev)
+{
+ return 0;
+}
+#endif /* CONFIG_PCI */
static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
{
@@ -452,8 +459,10 @@ static void pwrseq_pcie_m2_remove(struct platform_device *pdev)
{
struct pwrseq_pcie_m2_ctx *ctx = platform_get_drvdata(pdev);
+#if IS_ENABLED(CONFIG_PCI)
bus_unregister_notifier(&pci_bus_type, &ctx->nb);
pwrseq_pcie_m2_remove_serdev(ctx);
+#endif
regulator_bulk_free(ctx->num_vregs, ctx->regs);
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 04/10] lib/fonts: Clean up Makefile
From: Geert Uytterhoeven @ 2026-04-01 7:48 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, gregkh, jirislaby, simona, sam, linux-fbdev, dri-devel,
linux-kernel, linux-serial
In-Reply-To: <20260327130431.59481-5-tzimmermann@suse.de>
Hi Thomas,
On Fri, 27 Mar 2026 at 14:05, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Simplify the Makefile. Drop font-obj-y and sort the fonts by dictionary
> order. Done in preparation for supporting optional font rotation.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Thanks for your patch, which is now commit 3f90ea78f5fe9495
("lib/fonts: Clean up Makefile") in fbdev/for-next.
> --- a/lib/fonts/Makefile
> +++ b/lib/fonts/Makefile
> @@ -1,23 +1,22 @@
> # SPDX-License-Identifier: GPL-2.0
> # Font handling
>
> -font-objs := fonts.o
> +font-y := fonts.o
>
> -font-objs-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
> -font-objs-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
> -font-objs-$(CONFIG_FONT_8x8) += font_8x8.o
> -font-objs-$(CONFIG_FONT_8x16) += font_8x16.o
> -font-objs-$(CONFIG_FONT_6x11) += font_6x11.o
> -font-objs-$(CONFIG_FONT_7x14) += font_7x14.o
> -font-objs-$(CONFIG_FONT_10x18) += font_10x18.o
> -font-objs-$(CONFIG_FONT_PEARL_8x8) += font_pearl_8x8.o
> -font-objs-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
> -font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
> -font-objs-$(CONFIG_FONT_6x10) += font_6x10.o
> -font-objs-$(CONFIG_FONT_TER10x18) += font_ter10x18.o
> -font-objs-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
> -font-objs-$(CONFIG_FONT_6x8) += font_6x8.o
> +# Built-in fonts
> +font-$(CONFIG_FONT_10x18) += font_10x18.o
> +font-$(CONFIG_FONT_6x10) += font_6x10.o
> +font-$(CONFIG_FONT_6x11) += font_6x11.o
> +font-$(CONFIG_FONT_6x8) += font_6x8.o
> +font-$(CONFIG_FONT_7x14) += font_7x14.o
> +font-$(CONFIG_FONT_8x16) += font_8x16.o
> +font-$(CONFIG_FONT_8x8) += font_8x8.o
Please sort the anonymous entries by increasing font size.
> +font-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
> +font-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
> +font-$(CONFIG_FONT_PEARL_8x8) += font_pearl_8x8.o
> +font-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
> +font-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
> +font-$(CONFIG_FONT_TER10x18) += font_ter10x18.o
> +font-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
>
> -font-objs += $(font-objs-y)
> -
> -obj-$(CONFIG_FONT_SUPPORT) += font.o
> +obj-$(CONFIG_FONT_SUPPORT) += font.o
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 04/10] lib/fonts: Clean up Makefile
From: Thomas Zimmermann @ 2026-04-01 7:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: deller, gregkh, jirislaby, simona, sam, linux-fbdev, dri-devel,
linux-kernel, linux-serial
In-Reply-To: <CAMuHMdX1vUuKq-Q1-zA5tC5+LWap4osFJMqQ5pRJ373z++KQLQ@mail.gmail.com>
Hi
Am 01.04.26 um 09:48 schrieb Geert Uytterhoeven:
> Hi Thomas,
>
> On Fri, 27 Mar 2026 at 14:05, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Simplify the Makefile. Drop font-obj-y and sort the fonts by dictionary
>> order. Done in preparation for supporting optional font rotation.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Thanks for your patch, which is now commit 3f90ea78f5fe9495
> ("lib/fonts: Clean up Makefile") in fbdev/for-next.
>
>> --- a/lib/fonts/Makefile
>> +++ b/lib/fonts/Makefile
>> @@ -1,23 +1,22 @@
>> # SPDX-License-Identifier: GPL-2.0
>> # Font handling
>>
>> -font-objs := fonts.o
>> +font-y := fonts.o
>>
>> -font-objs-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
>> -font-objs-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
>> -font-objs-$(CONFIG_FONT_8x8) += font_8x8.o
>> -font-objs-$(CONFIG_FONT_8x16) += font_8x16.o
>> -font-objs-$(CONFIG_FONT_6x11) += font_6x11.o
>> -font-objs-$(CONFIG_FONT_7x14) += font_7x14.o
>> -font-objs-$(CONFIG_FONT_10x18) += font_10x18.o
>> -font-objs-$(CONFIG_FONT_PEARL_8x8) += font_pearl_8x8.o
>> -font-objs-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
>> -font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
>> -font-objs-$(CONFIG_FONT_6x10) += font_6x10.o
>> -font-objs-$(CONFIG_FONT_TER10x18) += font_ter10x18.o
>> -font-objs-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
>> -font-objs-$(CONFIG_FONT_6x8) += font_6x8.o
>> +# Built-in fonts
>> +font-$(CONFIG_FONT_10x18) += font_10x18.o
>> +font-$(CONFIG_FONT_6x10) += font_6x10.o
>> +font-$(CONFIG_FONT_6x11) += font_6x11.o
>> +font-$(CONFIG_FONT_6x8) += font_6x8.o
>> +font-$(CONFIG_FONT_7x14) += font_7x14.o
>> +font-$(CONFIG_FONT_8x16) += font_8x16.o
>> +font-$(CONFIG_FONT_8x8) += font_8x8.o
> Please sort the anonymous entries by increasing font size.
Makes sense. I'll also leave a comment on the sorting order.
Best regards
Thomas
>
>> +font-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
>> +font-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
>> +font-$(CONFIG_FONT_PEARL_8x8) += font_pearl_8x8.o
>> +font-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
>> +font-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
>> +font-$(CONFIG_FONT_TER10x18) += font_ter10x18.o
>> +font-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
>>
>> -font-objs += $(font-objs-y)
>> -
>> -obj-$(CONFIG_FONT_SUPPORT) += font.o
>> +obj-$(CONFIG_FONT_SUPPORT) += font.o
> Gr{oetje,eeting}s,
>
> Geert
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 04/10] lib/fonts: Clean up Makefile
From: Jiri Slaby @ 2026-04-01 8:58 UTC (permalink / raw)
To: Thomas Zimmermann, Geert Uytterhoeven
Cc: deller, gregkh, simona, sam, linux-fbdev, dri-devel, linux-kernel,
linux-serial
In-Reply-To: <a2b5aa02-2566-409f-960d-4ecb1419cbd5@suse.de>
On 01. 04. 26, 9:58, Thomas Zimmermann wrote:
>>> -font-objs-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
>>> -font-objs-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
>>> -font-objs-$(CONFIG_FONT_8x8) += font_8x8.o
>>> -font-objs-$(CONFIG_FONT_8x16) += font_8x16.o
>>> -font-objs-$(CONFIG_FONT_6x11) += font_6x11.o
>>> -font-objs-$(CONFIG_FONT_7x14) += font_7x14.o
>>> -font-objs-$(CONFIG_FONT_10x18) += font_10x18.o
>>> -font-objs-$(CONFIG_FONT_PEARL_8x8) += font_pearl_8x8.o
>>> -font-objs-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
>>> -font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
>>> -font-objs-$(CONFIG_FONT_6x10) += font_6x10.o
>>> -font-objs-$(CONFIG_FONT_TER10x18) += font_ter10x18.o
>>> -font-objs-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
>>> -font-objs-$(CONFIG_FONT_6x8) += font_6x8.o
>>> +# Built-in fonts
>>> +font-$(CONFIG_FONT_10x18) += font_10x18.o
>>> +font-$(CONFIG_FONT_6x10) += font_6x10.o
>>> +font-$(CONFIG_FONT_6x11) += font_6x11.o
>>> +font-$(CONFIG_FONT_6x8) += font_6x8.o
>>> +font-$(CONFIG_FONT_7x14) += font_7x14.o
>>> +font-$(CONFIG_FONT_8x16) += font_8x16.o
>>> +font-$(CONFIG_FONT_8x8) += font_8x8.o
>> Please sort the anonymous entries by increasing font size.
>
> Makes sense. I'll also leave a comment on the sorting order.
>>> +font-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
>>> +font-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
I'd sort even the non-anonymous ^^.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH 04/10] lib/fonts: Clean up Makefile
From: Thomas Zimmermann @ 2026-04-01 9:09 UTC (permalink / raw)
To: Jiri Slaby, Geert Uytterhoeven
Cc: deller, gregkh, simona, sam, linux-fbdev, dri-devel, linux-kernel,
linux-serial
In-Reply-To: <7eaf55fd-1ec9-4c30-877f-12961e8f9532@kernel.org>
Hi
Am 01.04.26 um 10:58 schrieb Jiri Slaby:
> On 01. 04. 26, 9:58, Thomas Zimmermann wrote:
>>>> -font-objs-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
>>>> -font-objs-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
>>>> -font-objs-$(CONFIG_FONT_8x8) += font_8x8.o
>>>> -font-objs-$(CONFIG_FONT_8x16) += font_8x16.o
>>>> -font-objs-$(CONFIG_FONT_6x11) += font_6x11.o
>>>> -font-objs-$(CONFIG_FONT_7x14) += font_7x14.o
>>>> -font-objs-$(CONFIG_FONT_10x18) += font_10x18.o
>>>> -font-objs-$(CONFIG_FONT_PEARL_8x8) += font_pearl_8x8.o
>>>> -font-objs-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
>>>> -font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
>>>> -font-objs-$(CONFIG_FONT_6x10) += font_6x10.o
>>>> -font-objs-$(CONFIG_FONT_TER10x18) += font_ter10x18.o
>>>> -font-objs-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
>>>> -font-objs-$(CONFIG_FONT_6x8) += font_6x8.o
>>>> +# Built-in fonts
>>>> +font-$(CONFIG_FONT_10x18) += font_10x18.o
>>>> +font-$(CONFIG_FONT_6x10) += font_6x10.o
>>>> +font-$(CONFIG_FONT_6x11) += font_6x11.o
>>>> +font-$(CONFIG_FONT_6x8) += font_6x8.o
>>>> +font-$(CONFIG_FONT_7x14) += font_7x14.o
>>>> +font-$(CONFIG_FONT_8x16) += font_8x16.o
>>>> +font-$(CONFIG_FONT_8x8) += font_8x8.o
>>> Please sort the anonymous entries by increasing font size.
>>
>> Makes sense. I'll also leave a comment on the sorting order.
>
>>>> +font-$(CONFIG_FONT_SUN12x22) += font_sun12x22.o
>>>> +font-$(CONFIG_FONT_SUN8x16) += font_sun8x16.o
>
> I'd sort even the non-anonymous ^^.
My plan is now to sort by font-family, then by font height, then by font
width. Each in ascending order.
Best regards
Thomas
>
> thanks,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [syzbot] Monthly serial report (Apr 2026)
From: syzbot @ 2026-04-01 13:14 UTC (permalink / raw)
To: gregkh, linux-kernel, linux-serial, syzkaller-bugs
Hello serial maintainers/developers,
This is a 31-day syzbot report for the serial subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/serial
During the period, 0 new issues were detected and 0 were fixed.
In total, 19 issues are still open and 48 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 3911 Yes possible deadlock in console_lock_spinning_enable (5)
https://syzkaller.appspot.com/bug?extid=622acb507894a48b2ce9
<2> 3418 Yes KMSAN: uninit-value in n_tty_receive_buf_standard
https://syzkaller.appspot.com/bug?extid=559c7fe4b8bac56d38c2
<3> 310 Yes KMSAN: uninit-value in n_tty_receive_buf_closing (3)
https://syzkaller.appspot.com/bug?extid=dd514b5f0cf048aec256
<4> 250 Yes INFO: task can't die in show_free_areas
https://syzkaller.appspot.com/bug?extid=8f41dccfb6c03cc36fd6
<5> 151 No possible deadlock in kbd_event
https://syzkaller.appspot.com/bug?extid=781c8bb5e4d62cc883d3
<6> 126 Yes possible deadlock in tty_buffer_flush (3)
https://syzkaller.appspot.com/bug?extid=52cf91760dcb1dac6376
<7> 9 No KASAN: slab-out-of-bounds Write in do_con_write (3)
https://syzkaller.appspot.com/bug?extid=8e9c1abac3ceb45abffe
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* [PATCH] tty: serial: ip22zilog: Fix section mispatch warning
From: Thomas Bogendoerfer @ 2026-04-02 10:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Thomas Bogendoerfer, linux-kernel,
linux-serial
Cc: kernel test robot
ip22zilog_prepare() is now called by driver probe routine, so it
shouldn't be in the __init section any longer.
Fixes: 3fc36ae6abd2 ("tty: serial: ip22zilog: Use platform device for probing")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604020945.c9jAvCPs-lkp@intel.com/
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
---
drivers/tty/serial/ip22zilog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/ip22zilog.c b/drivers/tty/serial/ip22zilog.c
index 6e19c6713849..a12101dc0554 100644
--- a/drivers/tty/serial/ip22zilog.c
+++ b/drivers/tty/serial/ip22zilog.c
@@ -1025,7 +1025,7 @@ static struct uart_driver ip22zilog_reg = {
#endif
};
-static void __init ip22zilog_prepare(struct uart_ip22zilog_port *up)
+static void ip22zilog_prepare(struct uart_ip22zilog_port *up)
{
unsigned char sysrq_on = IS_ENABLED(CONFIG_SERIAL_IP22_ZILOG_CONSOLE);
int brg;
--
2.43.0
^ 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