* 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
* Re: [PATCH] tty: serial: ip22zilog: Fix section mispatch warning
From: Randy Dunlap @ 2026-04-02 18:35 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby,
Thomas Bogendoerfer, linux-kernel, linux-serial
Cc: kernel test robot
In-Reply-To: <20260402102154.136620-1-tbogendoerfer@suse.de>
s/mispatch/mismatch/ in $Subject.
On 4/2/26 3:21 AM, Thomas Bogendoerfer wrote:
> 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>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> 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;
--
~Randy
^ permalink raw reply
* Re: [PATCH 3/3] power: sequencing: pcie-m2: Guard the helper functions making use of PCI bus notifier
From: kernel test robot @ 2026-04-02 22:56 UTC (permalink / raw)
To: Manivannan Sadhasivam, brgl, robh
Cc: llvm, oe-kbuild-all, linux-pci, linux-pm, linux-kernel,
linux-serial, mani, Manivannan Sadhasivam, kernel test robot
In-Reply-To: <20260401070735.107162-4-manivannan.sadhasivam@oss.qualcomm.com>
Hi Manivannan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linux-next/master]
[also build test WARNING on linus/master v6.16-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Manivannan-Sadhasivam/serdev-Add-missing-stubs-for-serdev-APIs-when-CONFIG_SERIAL_DEV_BUS-is-not-selected/20260402-225703
base: linux-next/master
patch link: https://lore.kernel.org/r/20260401070735.107162-4-manivannan.sadhasivam%40oss.qualcomm.com
patch subject: [PATCH 3/3] power: sequencing: pcie-m2: Guard the helper functions making use of PCI bus notifier
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260403/202604030008.5exLAPFm-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260403/202604030008.5exLAPFm-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604030008.5exLAPFm-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/tty/tty_port.c:20:
>> include/linux/serdev.h:268:83: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
268 | static inline struct serdev_device *serdev_device_alloc(struct serdev_controller *)
| ^
include/linux/serdev.h:272:59: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
272 | static inline int serdev_device_add(struct serdev_device *)
| ^
include/linux/serdev.h:276:63: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
276 | static inline void serdev_device_remove(struct serdev_device *) {}
| ^
include/linux/serdev.h:284:67: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
284 | static inline int serdev_controller_add(struct serdev_controller *)
| ^
include/linux/serdev.h:288:71: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
288 | static inline void serdev_controller_remove(struct serdev_controller *) {}
| ^
5 warnings generated.
vim +268 include/linux/serdev.h
267
> 268 static inline struct serdev_device *serdev_device_alloc(struct serdev_controller *)
269 {
270 return NULL;
271 }
272 static inline int serdev_device_add(struct serdev_device *)
273 {
274 return -ENODEV;
275 }
276 static inline void serdev_device_remove(struct serdev_device *) {}
277
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 0/9] driver core: Fix some race conditions
From: Douglas Anderson @ 2026-04-03 0:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Robin Murphy, Leon Romanovsky, Paul Burton, Saravana Kannan,
Alexander Lobakin, Eric Dumazet, Toshi Kani, Christoph Hellwig,
Alexey Kardashevskiy, Johan Hovold, Douglas Anderson,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
astewart, bhelgaas, brgl, broonie, catalin.marinas, chleroy,
davem, david, devicetree, dmaengine, driver-core, gbatra,
gregory.clement, hkallweit1, iommu, jirislaby, joel, joro, kees,
kevin.brodsky, kuba, lenb, lgirdwood, linux-acpi,
linux-arm-kernel, linux-aspeed, linux-cxl, linux-kernel,
linux-mips, linux-mm, linux-pci, linux-riscv, linux-serial,
linux-snps-arc, linux-usb, linux, linuxppc-dev, m.szyprowski,
maddy, mani, maz, miko.lenczewski, mpe, netdev, npiggin,
osalvador, oupton, pabeni, palmer, peter.ujfalusi, peterz, pjw,
robh, sebastian.hesselbarth, tglx, tsbogend, vgupta, vkoul, will,
willy, yangyicong, yeoreum.yun
The main goal of this series is to fix the observed bug talked about
in the first patch ("driver core: Don't let a device probe until it's
ready"). That patch fixes a problem that has been observed in the real
world and could land even if the rest of the patches are found
unacceptable or need to be spun.
That said, during patch review Danilo correctly pointed out that many
of the bitfield accesses in "struct device" are unsafe. I added a
bunch of patches in the series to address each one.
Danilo said he's most worried about "can_match", so I put that one
first. After that, I tried to transition bitfields to flags in reverse
order to when the bitfield was added.
Even if transitioning from bitfields to flags isn't truly needed for
correctness, it seems silly (and wasteful of space in struct device)
to have some in bitfields and some as flags. Thus I didn't spend time
for each bitfield showing that it's truly needed for correctness.
Transition was done semi manually. Presumably someone skilled at
coccinelle could do a better job, but I just used sed in a heavy-
handed manner and then reviewed/fixed the results, undoing anything my
script got wrong. My terrible/ugly script was:
var=can_match
caps="${var^^}"
for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
echo $f
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1.flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1.flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1.flags, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1.flags)\\2/" "$f"
done
NOTE: one potentially "controversial" choice I made in some patches
was to always reserve a flag ID even if a flag is only used under
certain CONFIG_ settings. This is a change from how things were
before. Keeping the numbering consistent and allowing easy
compile-testing of both CONFIG settings seemed worth it, especially
since it won't take up any extra space until we've added a lot more
flags.
I only marked the first patch as a "Fix" since it is the only one
fixing observed problems. Other patches could be considered fixes too
if folks want.
I tested the first patch in the series backported to kernel 6.6 on the
Pixel phone that was experiencing the race. I added extra printouts to
make sure that the problem was hitting / addressed. The rest of the
patches are tested with allmodconfig with arm32, arm64, ppc, and
x86. I boot tested on an arm64 Chromebook running mainline.
Changes in v3:
- Use a new "flags" bitfield
- Add missing \n in probe error message
Changes in v2:
- Instead of adjusting the ordering, use "ready_to_probe" flag
Douglas Anderson (9):
driver core: Don't let a device probe until it's ready
driver core: Replace dev->can_match with DEV_FLAG_CAN_MATCH
driver core: Replace dev->dma_iommu with DEV_FLAG_DMA_IOMMU
driver core: Replace dev->dma_skip_sync with DEV_FLAG_DMA_SKIP_SYNC
driver core: Replace dev->dma_ops_bypass with DEV_FLAG_DMA_OPS_BYPASS
driver core: Replace dev->state_synced with DEV_FLAG_STATE_SYNCED
driver core: Replace dev->dma_coherent with DEV_FLAG_DMA_COHERENT
driver core: Replace dev->of_node_reused with DEV_FLAG_OF_NODE_REUSED
driver core: Replace dev->offline + ->offline_disabled with DEV_FLAGs
arch/arc/mm/dma.c | 4 +-
arch/arm/mach-highbank/highbank.c | 2 +-
arch/arm/mach-mvebu/coherency.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 4 +-
arch/arm/mm/dma-mapping.c | 30 +++----
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/mm/dma-mapping.c | 2 +-
arch/mips/mm/dma-noncoherent.c | 2 +-
arch/powerpc/kernel/dma-iommu.c | 8 +-
.../platforms/pseries/hotplug-memory.c | 4 +-
arch/riscv/mm/dma-noncoherent.c | 2 +-
drivers/acpi/scan.c | 3 +-
drivers/base/core.c | 55 +++++++-----
drivers/base/cpu.c | 4 +-
drivers/base/dd.c | 28 +++++--
drivers/base/memory.c | 2 +-
drivers/base/pinctrl.c | 2 +-
drivers/base/platform.c | 2 +-
drivers/dma/ti/k3-udma-glue.c | 6 +-
drivers/dma/ti/k3-udma.c | 6 +-
drivers/iommu/dma-iommu.c | 9 +-
drivers/iommu/iommu.c | 5 +-
drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
drivers/of/device.c | 6 +-
drivers/pci/of.c | 2 +-
drivers/pci/pwrctrl/core.c | 2 +-
drivers/regulator/bq257xx-regulator.c | 2 +-
drivers/regulator/rk808-regulator.c | 2 +-
drivers/tty/serial/serial_base_bus.c | 2 +-
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
include/linux/device.h | 83 ++++++++++---------
include/linux/dma-map-ops.h | 6 +-
include/linux/dma-mapping.h | 2 +-
include/linux/iommu-dma.h | 4 +-
kernel/cpu.c | 4 +-
kernel/dma/mapping.c | 16 ++--
mm/hmm.c | 2 +-
37 files changed, 178 insertions(+), 143 deletions(-)
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply
* [PATCH v3 8/9] driver core: Replace dev->of_node_reused with DEV_FLAG_OF_NODE_REUSED
From: Douglas Anderson @ 2026-04-03 0:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Robin Murphy, Leon Romanovsky, Paul Burton, Saravana Kannan,
Alexander Lobakin, Eric Dumazet, Toshi Kani, Christoph Hellwig,
Alexey Kardashevskiy, Johan Hovold, Douglas Anderson,
alexander.stein, andrew, andrew, andriy.shevchenko, astewart,
bhelgaas, brgl, broonie, davem, devicetree, driver-core,
hkallweit1, jirislaby, joel, kees, kuba, lgirdwood,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pci,
linux-serial, linux-usb, linux, mani, netdev, pabeni, robh
In-Reply-To: <20260403005005.30424-1-dianders@chromium.org>
In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "of_node_reused" over to the "flags"
field so modifications are safe.
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Not fixing any known bugs; problem is theoretical and found by code
inspection. Change is done somewhat manually and only lightly tested
(mostly compile-time tested).
Changes in v3:
- New
drivers/base/core.c | 2 +-
drivers/base/pinctrl.c | 2 +-
drivers/base/platform.c | 2 +-
drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
drivers/of/device.c | 6 +++---
drivers/pci/of.c | 2 +-
drivers/pci/pwrctrl/core.c | 2 +-
drivers/regulator/bq257xx-regulator.c | 2 +-
drivers/regulator/rk808-regulator.c | 2 +-
drivers/tty/serial/serial_base_bus.c | 2 +-
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
include/linux/device.h | 6 +++---
12 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 00005777c21f..a87bd40499b6 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -5282,7 +5282,7 @@ void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
{
of_node_put(dev->of_node);
dev->of_node = of_node_get(dev2->of_node);
- dev->of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags);
}
EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 6e250272c843..62c228c75d50 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -24,7 +24,7 @@ int pinctrl_bind_pins(struct device *dev)
{
int ret;
- if (dev->of_node_reused)
+ if (test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
return 0;
dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d44591d52e36..5128ff7e5e78 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -856,7 +856,7 @@ struct platform_device *platform_device_register_full(
pdev->dev.parent = pdevinfo->parent;
pdev->dev.fwnode = pdevinfo->fwnode;
pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
- pdev->dev.of_node_reused = pdevinfo->of_node_reused;
+ assign_bit(DEV_FLAG_OF_NODE_REUSED, &pdev->dev.flags, pdevinfo->of_node_reused);
if (pdevinfo->dma_mask) {
pdev->platform_dma_mask = pdevinfo->dma_mask;
diff --git a/drivers/net/pcs/pcs-xpcs-plat.c b/drivers/net/pcs/pcs-xpcs-plat.c
index b8c48f9effbf..c2722d8bd98a 100644
--- a/drivers/net/pcs/pcs-xpcs-plat.c
+++ b/drivers/net/pcs/pcs-xpcs-plat.c
@@ -349,7 +349,7 @@ static int xpcs_plat_init_dev(struct dw_xpcs_plat *pxpcs)
* up later. Make sure DD-core is aware of the OF-node being re-used.
*/
device_set_node(&mdiodev->dev, fwnode_handle_get(dev_fwnode(dev)));
- mdiodev->dev.of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &mdiodev->dev.flags);
/* Pass the data further so the DW XPCS driver core could use it */
mdiodev->dev.platform_data = (void *)device_get_match_data(dev);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index f7e75e527667..fd77295a8c0f 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -26,7 +26,7 @@
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
- if (!matches || !dev->of_node || dev->of_node_reused)
+ if (!matches || !dev->of_node || test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
return NULL;
return of_match_node(matches, dev->of_node);
}
@@ -192,7 +192,7 @@ ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
{
ssize_t sl;
- if (!dev || !dev->of_node || dev->of_node_reused)
+ if (!dev || !dev->of_node || test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
return -ENODEV;
sl = of_modalias(dev->of_node, str, len - 2);
@@ -254,7 +254,7 @@ int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *
{
int sl;
- if ((!dev) || (!dev->of_node) || dev->of_node_reused)
+ if ((!dev) || (!dev->of_node) || test_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags))
return -ENODEV;
/* Devicetree modalias is tricky, we add it in 2 steps */
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 9f8eb5df279e..197b60c5a660 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -38,7 +38,7 @@ int pci_set_of_node(struct pci_dev *dev)
struct device *pdev __free(put_device) =
bus_find_device_by_of_node(&platform_bus_type, node);
if (pdev)
- dev->bus->dev.of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->bus->dev.flags);
device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
return 0;
diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
index 7754baed67f2..cfbe9b615b88 100644
--- a/drivers/pci/pwrctrl/core.c
+++ b/drivers/pci/pwrctrl/core.c
@@ -39,7 +39,7 @@ static int pci_pwrctrl_notify(struct notifier_block *nb, unsigned long action,
* If we got here then the PCI device is the second after the
* power control platform device. Mark its OF node as reused.
*/
- dev->of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags);
break;
}
diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
index dab8f1ab4450..01d3139e1d87 100644
--- a/drivers/regulator/bq257xx-regulator.c
+++ b/drivers/regulator/bq257xx-regulator.c
@@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
struct regulator_config cfg = {};
pdev->dev.of_node = pdev->dev.parent->of_node;
- pdev->dev.of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &pdev->dev.flags);
pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
if (!pdata)
diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
index e66408f23bb6..375ea7861134 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
int ret, i, nregulators;
pdev->dev.of_node = pdev->dev.parent->of_node;
- pdev->dev.of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &pdev->dev.flags);
regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!regmap)
diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
index a12935f6b992..86c6003bbebb 100644
--- a/drivers/tty/serial/serial_base_bus.c
+++ b/drivers/tty/serial/serial_base_bus.c
@@ -74,7 +74,7 @@ static int serial_base_device_init(struct uart_port *port,
dev->parent = parent_dev;
dev->bus = &serial_base_bus_type;
dev->release = release;
- dev->of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &dev->flags);
device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
index 2ecd049dacc2..57048e3aa6bb 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
@@ -593,7 +593,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx)
d->gadget.max_speed = USB_SPEED_HIGH;
d->gadget.speed = USB_SPEED_UNKNOWN;
d->gadget.dev.of_node = vhub->pdev->dev.of_node;
- d->gadget.dev.of_node_reused = true;
+ set_bit(DEV_FLAG_OF_NODE_REUSED, &d->gadget.dev.flags);
rc = usb_add_gadget_udc(d->port_dev, &d->gadget);
if (rc != 0)
diff --git a/include/linux/device.h b/include/linux/device.h
index c2a6dba7a036..f6ca067bacca 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -482,6 +482,8 @@ struct device_physical_location {
* driver/bus sync_state() callback.
* @DEV_FLAG_DMA_COHERENT: This particular device is dma coherent, even if the
* architecture supports non-coherent devices.
+ * @DEV_FLAG_OF_NODE_REUSED: Set if the device-tree node is shared with an
+ * ancestor device.
*/
enum struct_device_flags {
DEV_FLAG_READY_TO_PROBE,
@@ -491,6 +493,7 @@ enum struct_device_flags {
DEV_FLAG_DMA_OPS_BYPASS,
DEV_FLAG_STATE_SYNCED,
DEV_FLAG_DMA_COHERENT,
+ DEV_FLAG_OF_NODE_REUSED,
};
/**
@@ -570,8 +573,6 @@ enum struct_device_flags {
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
- * @of_node_reused: Set if the device-tree node is shared with an ancestor
- * device.
* @flags: DEV_FLAG_XXX flags. Use atomic bitfield operations to modify.
*
* At the lowest level, every device in a Linux system is represented by an
@@ -678,7 +679,6 @@ struct device {
bool offline_disabled:1;
bool offline:1;
- bool of_node_reused:1;
unsigned long flags;
};
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [tty:tty-testing] BUILD SUCCESS a1a81aef99e853dec84241d701fbf587d713eb5b
From: kernel test robot @ 2026-04-03 3:25 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: a1a81aef99e853dec84241d701fbf587d713eb5b tty: serial: ip22zilog: Fix section mispatch warning
elapsed time: 735m
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-20260403 gcc-10.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260403 gcc-14
i386 randconfig-002-20260403 gcc-14
i386 randconfig-003-20260403 gcc-14
i386 randconfig-004-20260403 gcc-14
i386 randconfig-005-20260403 gcc-14
i386 randconfig-006-20260403 gcc-14
i386 randconfig-007-20260403 gcc-14
i386 randconfig-011-20260403 clang-20
i386 randconfig-012-20260403 clang-20
i386 randconfig-013-20260403 clang-20
i386 randconfig-014-20260403 clang-20
i386 randconfig-015-20260403 clang-20
i386 randconfig-016-20260403 clang-20
i386 randconfig-017-20260403 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260403 clang-23
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
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260403 clang-23
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-20260403 gcc-10.5.0
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc tqm5200_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh magicpanelr2_defconfig gcc-15.2.0
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260403 clang-20
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-20260403 clang-20
um randconfig-002-20260403 clang-20
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-20260403 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260403 clang-20
x86_64 randconfig-002-20260403 clang-20
x86_64 randconfig-003-20260403 clang-20
x86_64 randconfig-004-20260403 clang-20
x86_64 randconfig-005-20260403 clang-20
x86_64 randconfig-006-20260403 clang-20
x86_64 randconfig-011-20260403 gcc-14
x86_64 randconfig-012-20260403 gcc-14
x86_64 randconfig-013-20260403 gcc-14
x86_64 randconfig-014-20260403 gcc-14
x86_64 randconfig-015-20260403 gcc-14
x86_64 randconfig-016-20260403 gcc-14
x86_64 randconfig-071-20260403 gcc-14
x86_64 randconfig-072-20260403 gcc-14
x86_64 randconfig-073-20260403 gcc-14
x86_64 randconfig-074-20260403 gcc-14
x86_64 randconfig-075-20260403 gcc-14
x86_64 randconfig-076-20260403 gcc-14
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-20260403 clang-20
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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