* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-16 17:30 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, 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
In-Reply-To: <ysfkemsf4w7r3eoahfpjdr3z3buec5kvw4qol2njhxrz5tsdpo@4scz632uaj5i>
On Fri, Jan 16, 2026 at 8:43 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Fri, Jan 16, 2026 at 08:19:07AM -0600, Rob Herring wrote:
> > On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote:
> > > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >
> > > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote:
> > > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> > > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> > > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> > > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> > > > > > > devices. Spec also provides an optional interface to connect the UIM card,
> > > > > > > but that is not covered in this binding.
> > > > > > >
> > > > > > > The connector provides a primary power supply of 3.3v, along with an
> > > > > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > > > > 1.8v sideband signaling.
> > > > > > >
> > > > > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > > > > grained power management.
> > > > > > >
> > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > > ---
> > > > > > > .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> > > > > > > MAINTAINERS | 1 +
> > > > > > > 2 files changed, 155 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..b65b39ddfd19
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > > @@ -0,0 +1,154 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: PCIe M.2 Mechanical Key E Connector
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > > +
> > > > > > > +description:
> > > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> > > > > > > + connector. Mechanical Key E connectors are used to connect Wireless
> > > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> > > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > + compatible:
> > > > > > > + const: pcie-m2-e-connector
> > > > > > > +
> > > > > > > + vpcie3v3-supply:
> > > > > > > + description: A phandle to the regulator for 3.3v supply.
> > > > > > > +
> > > > > > > + vpcie1v8-supply:
> > > > > > > + description: A phandle to the regulator for VIO 1.8v supply.
> > > > > >
> > > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
> > > > > > may need something in DT to ensure those are powered. However, there's
> > > > > > no guarantee that it's a single supply.
> > > > > >
> > > > >
> > > > > 1.8v VIO supply is an optional supply and is only required if the platform
> > > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in
> > > > > the example for completeness.
> > > >
> > > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V
> > > > supplies and those supply the I/O pads of the GPIO pins (and possibly
> > > > external pull-ups) that drive them. The 1.8V supply doesn't supply
> > > > 1.8V to the slot, so making it a slot/connector property is wrong.
> > > >
> > >
> > > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and
> > > not the whole card/adapter. But I don't get your multiple supplies concern. Spec
> > > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O
> > > buffer circuitry operating at 1.8 V." So it implies that either the single
> > > supply available to the card through VIO might be used to power the whole I/O
> > > circuit logic or the card can derive its own 1.8v supply from 3.3v supply.
> > >
> > > So how come the card can have 2 different 1.8v supplies powering the I/O
> > > circuitry?
> >
> > Is there a pin on the connector for 1.8V supply? I don't have the
> > spec, but the pinout I found[1] didn't show one. If there's a pin,
> > then I have no concern.
> >
>
> Oh yes, there is a single VIO pin defined in the spec for multiple Keys. Since
> it is optional, it could've been omitted in the design you referenced.
>
> So should I name it as vio1v8-supply or vpcie1v8-supply? I don't see any other
> 1.8v supplies other than the VIO supply though.
vpcie1v8 is fine.
Rob
^ permalink raw reply
* [PATCH v2] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Kendall Willis @ 2026-01-16 19:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: d-gole, vishalm, sebin.francis, msp, khilman, linux-kernel,
linux-serial, Kendall Willis
In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when the
UART controller is off. Set UART device as wakeup capable using out-of-band
wakeup if the 'wakeup' pinctrl state exists and the device may wakeup.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Kendall Willis <k-willis@ti.com>
---
Testing
-------
Tested on a AM62P SK EVM board. Suspend/resume verified with the Main UART
wakeup source by entering a keypress on the console.
This github branch has all the necessary patches to test the patch
using Main UART as a wakeup source:
https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/all
---
Changes in v2:
- Remove extraneous information about patches that need to be
implemented to allow Main UART wakeup on K3 TI SoCs.
- Link to v1: https://lore.kernel.org/r/20251230-uart-wakeup-v1-1-13f1bb905f14@ti.com
---
drivers/tty/serial/8250/8250_omap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 9e49ef48b851bf6cd3b04a77a4d0d7b4e064dc5f..6a5722b722650c1710e79fb76fc1a01cdeccc68f 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1363,6 +1363,8 @@ static int omap8250_select_wakeup_pinctrl(struct device *dev,
if (!device_may_wakeup(dev))
return 0;
+ device_set_out_band_wakeup(dev);
+
return pinctrl_select_state(priv->pinctrl, priv->pinctrl_wakeup);
}
---
base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b
change-id: 20251230-uart-wakeup-00faeac7c994
Best regards,
--
Kendall Willis <k-willis@ti.com>
^ permalink raw reply related
* [tty:tty-testing] BUILD SUCCESS 0e19f73ffde187458fadfff60eb4771bff704296
From: kernel test robot @ 2026-01-17 2:01 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: 0e19f73ffde187458fadfff60eb4771bff704296 tty: hvc-iucv: Remove KMSG_COMPONENT macro
elapsed time: 728m
configs tested: 175
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-22
arc defconfig gcc-15.2.0
arc haps_hs_defconfig gcc-15.2.0
arc randconfig-001-20260117 gcc-12.5.0
arc randconfig-002-20260117 gcc-12.5.0
arm alldefconfig gcc-15.2.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm mxs_defconfig gcc-15.2.0
arm randconfig-001-20260117 gcc-12.5.0
arm randconfig-002-20260117 gcc-12.5.0
arm randconfig-003-20260117 gcc-12.5.0
arm randconfig-004-20260117 gcc-12.5.0
arm spear3xx_defconfig gcc-15.2.0
arm stm32_defconfig gcc-15.2.0
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260117 clang-22
arm64 randconfig-002-20260117 clang-22
arm64 randconfig-003-20260117 clang-22
arm64 randconfig-004-20260117 clang-22
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260117 clang-22
csky randconfig-002-20260117 clang-22
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260117 clang-22
hexagon randconfig-002-20260117 clang-22
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260117 gcc-13
i386 buildonly-randconfig-002-20260117 gcc-13
i386 buildonly-randconfig-003-20260117 gcc-13
i386 buildonly-randconfig-004-20260117 gcc-13
i386 buildonly-randconfig-005-20260117 gcc-13
i386 buildonly-randconfig-006-20260117 gcc-13
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260117 gcc-14
i386 randconfig-002-20260117 gcc-14
i386 randconfig-003-20260117 gcc-14
i386 randconfig-004-20260117 gcc-14
i386 randconfig-005-20260117 gcc-14
i386 randconfig-006-20260117 gcc-14
i386 randconfig-007-20260117 gcc-14
i386 randconfig-011-20260117 gcc-14
i386 randconfig-012-20260117 gcc-14
i386 randconfig-013-20260117 gcc-14
i386 randconfig-014-20260117 gcc-14
i386 randconfig-015-20260117 gcc-14
i386 randconfig-016-20260117 gcc-14
i386 randconfig-017-20260117 gcc-14
loongarch allmodconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260117 clang-22
loongarch randconfig-002-20260117 clang-22
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k amcore_defconfig gcc-15.2.0
m68k defconfig clang-19
m68k virt_defconfig gcc-15.2.0
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 cu1830-neo_defconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 defconfig clang-19
nios2 randconfig-001-20260117 clang-22
nios2 randconfig-002-20260117 clang-22
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260117 clang-22
parisc randconfig-002-20260117 clang-22
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc amigaone_defconfig gcc-15.2.0
powerpc ge_imp3a_defconfig gcc-15.2.0
powerpc randconfig-001-20260117 clang-22
powerpc randconfig-002-20260117 clang-22
powerpc tqm5200_defconfig gcc-15.2.0
powerpc tqm8540_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260117 clang-22
powerpc64 randconfig-002-20260117 clang-22
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260117 gcc-10.5.0
riscv randconfig-002-20260117 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260117 gcc-10.5.0
s390 randconfig-002-20260117 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260117 gcc-10.5.0
sh randconfig-002-20260117 gcc-10.5.0
sh sh7785lcr_defconfig gcc-15.2.0
sparc allnoconfig clang-22
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260117 gcc-14.3.0
sparc randconfig-002-20260117 gcc-14.3.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260117 gcc-14.3.0
sparc64 randconfig-002-20260117 gcc-14.3.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260117 gcc-14.3.0
um randconfig-002-20260117 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260117 clang-20
x86_64 randconfig-002-20260117 clang-20
x86_64 randconfig-003-20260117 clang-20
x86_64 randconfig-004-20260117 clang-20
x86_64 randconfig-005-20260117 clang-20
x86_64 randconfig-006-20260117 clang-20
x86_64 randconfig-011-20260117 clang-20
x86_64 randconfig-012-20260117 clang-20
x86_64 randconfig-013-20260117 clang-20
x86_64 randconfig-014-20260117 clang-20
x86_64 randconfig-015-20260117 clang-20
x86_64 randconfig-016-20260117 clang-20
x86_64 randconfig-071-20260117 clang-20
x86_64 randconfig-072-20260117 clang-20
x86_64 randconfig-073-20260117 clang-20
x86_64 randconfig-074-20260117 clang-20
x86_64 randconfig-075-20260117 clang-20
x86_64 randconfig-076-20260117 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-22
xtensa allyesconfig clang-22
xtensa randconfig-001-20260117 gcc-14.3.0
xtensa randconfig-002-20260117 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [tty:tty-linus] BUILD SUCCESS 27aff0a56b3c77ea1a73641c9b3c4172a8f7238f
From: kernel test robot @ 2026-01-17 2:02 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: 27aff0a56b3c77ea1a73641c9b3c4172a8f7238f serial: 8250_pci: Fix broken RS485 for F81504/508/512
elapsed time: 729m
configs tested: 175
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-22
arc defconfig gcc-15.2.0
arc haps_hs_defconfig gcc-15.2.0
arc randconfig-001-20260117 gcc-12.5.0
arc randconfig-002-20260117 gcc-12.5.0
arm alldefconfig gcc-15.2.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm mxs_defconfig gcc-15.2.0
arm randconfig-001-20260117 gcc-12.5.0
arm randconfig-002-20260117 gcc-12.5.0
arm randconfig-003-20260117 gcc-12.5.0
arm randconfig-004-20260117 gcc-12.5.0
arm spear3xx_defconfig gcc-15.2.0
arm stm32_defconfig gcc-15.2.0
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260117 clang-22
arm64 randconfig-002-20260117 clang-22
arm64 randconfig-003-20260117 clang-22
arm64 randconfig-004-20260117 clang-22
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260117 clang-22
csky randconfig-002-20260117 clang-22
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260117 clang-22
hexagon randconfig-002-20260117 clang-22
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260117 gcc-13
i386 buildonly-randconfig-002-20260117 gcc-13
i386 buildonly-randconfig-003-20260117 gcc-13
i386 buildonly-randconfig-004-20260117 gcc-13
i386 buildonly-randconfig-005-20260117 gcc-13
i386 buildonly-randconfig-006-20260117 gcc-13
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260117 gcc-14
i386 randconfig-002-20260117 gcc-14
i386 randconfig-003-20260117 gcc-14
i386 randconfig-004-20260117 gcc-14
i386 randconfig-005-20260117 gcc-14
i386 randconfig-006-20260117 gcc-14
i386 randconfig-007-20260117 gcc-14
i386 randconfig-011-20260117 gcc-14
i386 randconfig-012-20260117 gcc-14
i386 randconfig-013-20260117 gcc-14
i386 randconfig-014-20260117 gcc-14
i386 randconfig-015-20260117 gcc-14
i386 randconfig-016-20260117 gcc-14
i386 randconfig-017-20260117 gcc-14
loongarch allmodconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260117 clang-22
loongarch randconfig-002-20260117 clang-22
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k amcore_defconfig gcc-15.2.0
m68k defconfig clang-19
m68k virt_defconfig gcc-15.2.0
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 cu1830-neo_defconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 defconfig clang-19
nios2 randconfig-001-20260117 clang-22
nios2 randconfig-002-20260117 clang-22
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260117 clang-22
parisc randconfig-002-20260117 clang-22
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc amigaone_defconfig gcc-15.2.0
powerpc ge_imp3a_defconfig gcc-15.2.0
powerpc randconfig-001-20260117 clang-22
powerpc randconfig-002-20260117 clang-22
powerpc tqm5200_defconfig gcc-15.2.0
powerpc tqm8540_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260117 clang-22
powerpc64 randconfig-002-20260117 clang-22
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260117 gcc-10.5.0
riscv randconfig-002-20260117 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260117 gcc-10.5.0
s390 randconfig-002-20260117 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260117 gcc-10.5.0
sh randconfig-002-20260117 gcc-10.5.0
sh sh7785lcr_defconfig gcc-15.2.0
sparc allnoconfig clang-22
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260117 gcc-14.3.0
sparc randconfig-002-20260117 gcc-14.3.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260117 gcc-14.3.0
sparc64 randconfig-002-20260117 gcc-14.3.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260117 gcc-14.3.0
um randconfig-002-20260117 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260117 clang-20
x86_64 randconfig-002-20260117 clang-20
x86_64 randconfig-003-20260117 clang-20
x86_64 randconfig-004-20260117 clang-20
x86_64 randconfig-005-20260117 clang-20
x86_64 randconfig-006-20260117 clang-20
x86_64 randconfig-011-20260117 clang-20
x86_64 randconfig-012-20260117 clang-20
x86_64 randconfig-013-20260117 clang-20
x86_64 randconfig-014-20260117 clang-20
x86_64 randconfig-015-20260117 clang-20
x86_64 randconfig-016-20260117 clang-20
x86_64 randconfig-071-20260117 clang-20
x86_64 randconfig-072-20260117 clang-20
x86_64 randconfig-073-20260117 clang-20
x86_64 randconfig-074-20260117 clang-20
x86_64 randconfig-075-20260117 clang-20
x86_64 randconfig-076-20260117 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-22
xtensa allyesconfig clang-22
xtensa randconfig-001-20260117 gcc-14.3.0
xtensa randconfig-002-20260117 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v5 6/7] riscv: dts: spacemit: add initial support for K3 SoC
From: Heinrich Schuchardt @ 2026-01-17 23:41 UTC (permalink / raw)
To: Guodong Xu
Cc: Paul Walmsley, Conor Dooley, Kevin Meng Zhang, Andrew Jones,
devicetree, linux-riscv, linux-kernel, spacemit, linux-serial,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Samuel Holland, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen, Thomas Gleixner
In-Reply-To: <20260115-k3-basic-dt-v5-6-6990ac9f4308@riscstar.com>
On 1/15/26 07:51, Guodong Xu wrote:
> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
> Add nodes of uarts, timer and interrupt-controllers. Also add M-mode
> APLIC (maplic) and IMSIC (mimsic) nodes to represent the hardware
> topology and ready for potential firmware usage.
>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v5: Update the copyright year to 2026.
> Set M-mode maplic and mimsic status to "reserved".
> Update the commit message per Yixun's suggestion.
> In maplic node, use riscv,delegation to match kernel binding. OpenSBI
> accepts both delegate and delegation, but the binding documents only
> riscv,delegation.
> v4: Fix missing blank space after commas in compatible string.
> Add m-mode imsic and aplic node.
> Reorder properties in simsic, saplic, mimsic, and maplic nodes
> to match DTS coding style.
> v3: Remove "supm" from the riscv,isa-extensions list.
> v2: Remove aliases from k3.dtsi, they should be in board DTS.
> Updated riscv,isa-extensions with new extensions from the extensions.yaml.
> ---
> arch/riscv/boot/dts/spacemit/k3.dtsi | 590 +++++++++++++++++++++++++++++++++++
> 1 file changed, 590 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> new file mode 100644
> index 000000000000..53425badfea9
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> @@ -0,0 +1,590 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2026 SpacemiT (Hangzhou) Technology Co. Ltd
> + * Copyright (c) 2026 Guodong Xu <guodong@riscstar.com>
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + model = "SpacemiT K3";
> + compatible = "spacemit,k3";
> +
> + cpus: cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <24000000>;
> +
> + cpu_0: cpu@0 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <0>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu0_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_1: cpu@1 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <1>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu1_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_2: cpu@2 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <2>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu2_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_3: cpu@3 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <3>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu3_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_4: cpu@4 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <4>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu4_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_5: cpu@5 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <5>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
Should zvl256b be added to the X100 description to indicate the vector
length?
Best regards
Heinrich
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu5_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_6: cpu@6 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <6>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu6_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_7: cpu@7 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <7>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu7_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + l2_cache0: cache-controller-0 {
> + compatible = "cache";
> + cache-block-size = <64>;
> + cache-level = <2>;
> + cache-size = <4194304>;
> + cache-sets = <4096>;
> + cache-unified;
> + };
> +
> + l2_cache1: cache-controller-1 {
> + compatible = "cache";
> + cache-block-size = <64>;
> + cache-level = <2>;
> + cache-size = <4194304>;
> + cache-sets = <4096>;
> + cache-unified;
> + };
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu_0>;
> + };
> + core1 {
> + cpu = <&cpu_1>;
> + };
> + core2 {
> + cpu = <&cpu_2>;
> + };
> + core3 {
> + cpu = <&cpu_3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu_4>;
> + };
> + core1 {
> + cpu = <&cpu_5>;
> + };
> + core2 {
> + cpu = <&cpu_6>;
> + };
> + core3 {
> + cpu = <&cpu_7>;
> + };
> + };
> + };
> + };
> +
> + soc: soc {
> + compatible = "simple-bus";
> + interrupt-parent = <&saplic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-noncoherent;
> + ranges;
> +
> + uart0: serial@d4017000 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart2: serial@d4017100 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017100 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart3: serial@d4017200 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017200 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart4: serial@d4017300 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017300 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart5: serial@d4017400 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017400 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart6: serial@d4017500 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017500 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart7: serial@d4017600 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017600 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart8: serial@d4017700 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017700 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart9: serial@d4017800 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017800 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart10: serial@d401f000 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd401f000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + simsic: interrupt-controller@e0400000 {
> + compatible = "spacemit,k3-imsics", "riscv,imsics";
> + reg = <0x0 0xe0400000 0x0 0x200000>;
> + #interrupt-cells = <0>;
> + #msi-cells = <0>;
> + interrupt-controller;
> + interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
> + <&cpu2_intc 9>, <&cpu3_intc 9>,
> + <&cpu4_intc 9>, <&cpu5_intc 9>,
> + <&cpu6_intc 9>, <&cpu7_intc 9>;
> + msi-controller;
> + riscv,guest-index-bits = <6>;
> + riscv,hart-index-bits = <4>;
> + riscv,num-guest-ids = <511>;
> + riscv,num-ids = <511>;
> + };
> +
> + saplic: interrupt-controller@e0804000 {
> + compatible = "spacemit,k3-aplic", "riscv,aplic";
> + reg = <0x0 0xe0804000 0x0 0x4000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&simsic>;
> + riscv,num-sources = <512>;
> + };
> +
> + clint: timer@e081c000 {
> + compatible = "spacemit,k3-clint", "sifive,clint0";
> + reg = <0x0 0xe081c000 0x0 0x4000>;
> + interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> + <&cpu1_intc 3>, <&cpu1_intc 7>,
> + <&cpu2_intc 3>, <&cpu2_intc 7>,
> + <&cpu3_intc 3>, <&cpu3_intc 7>,
> + <&cpu4_intc 3>, <&cpu4_intc 7>,
> + <&cpu5_intc 3>, <&cpu5_intc 7>,
> + <&cpu6_intc 3>, <&cpu6_intc 7>,
> + <&cpu7_intc 3>, <&cpu7_intc 7>;
> + };
> +
> + mimsic: interrupt-controller@f1000000 {
> + compatible = "spacemit,k3-imsics", "riscv,imsics";
> + reg = <0x0 0xf1000000 0x0 0x10000>;
> + #interrupt-cells = <0>;
> + #msi-cells = <0>;
> + interrupt-controller;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>,
> + <&cpu2_intc 11>, <&cpu3_intc 11>,
> + <&cpu4_intc 11>, <&cpu5_intc 11>,
> + <&cpu6_intc 11>, <&cpu7_intc 11>;
> + msi-controller;
> + riscv,guest-index-bits = <6>;
> + riscv,hart-index-bits = <4>;
> + riscv,num-guest-ids = <511>;
> + riscv,num-ids = <511>;
> +
> + status = "reserved";
> + };
> +
> + maplic: interrupt-controller@f1800000 {
> + compatible = "spacemit,k3-aplic", "riscv,aplic";
> + reg = <0x0 0xf1800000 0x0 0x4000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&mimsic>;
> + riscv,children = <&saplic>;
> + riscv,delegation = <&saplic 1 512>;
> + riscv,num-sources = <512>;
> +
> + status = "reserved";
> + };
> + };
> +};
>
^ permalink raw reply
* Re: [PATCH v5 6/7] riscv: dts: spacemit: add initial support for K3 SoC
From: Guodong Xu @ 2026-01-18 13:58 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Paul Walmsley, Conor Dooley, Kevin Meng Zhang, Andrew Jones,
devicetree, linux-riscv, linux-kernel, spacemit, linux-serial,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Samuel Holland, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen, Thomas Gleixner
In-Reply-To: <c0395221-4248-4eb7-949e-ac86c40ec99b@gmx.de>
Hi, Heinrich
On Sun, Jan 18, 2026 at 7:41 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 1/15/26 07:51, Guodong Xu wrote:
> > SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
> > Add nodes of uarts, timer and interrupt-controllers. Also add M-mode
> > APLIC (maplic) and IMSIC (mimsic) nodes to represent the hardware
> > topology and ready for potential firmware usage.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> > v5: Update the copyright year to 2026.
> > Set M-mode maplic and mimsic status to "reserved".
> > Update the commit message per Yixun's suggestion.
> > In maplic node, use riscv,delegation to match kernel binding. OpenSBI
> > accepts both delegate and delegation, but the binding documents only
> > riscv,delegation.
> > v4: Fix missing blank space after commas in compatible string.
> > Add m-mode imsic and aplic node.
> > Reorder properties in simsic, saplic, mimsic, and maplic nodes
> > to match DTS coding style.
> > v3: Remove "supm" from the riscv,isa-extensions list.
> > v2: Remove aliases from k3.dtsi, they should be in board DTS.
> > Updated riscv,isa-extensions with new extensions from the extensions.yaml.
> > ---
> > arch/riscv/boot/dts/spacemit/k3.dtsi | 590 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 590 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > new file mode 100644
> > index 000000000000..53425badfea9
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > @@ -0,0 +1,590 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2026 SpacemiT (Hangzhou) Technology Co. Ltd
> > + * Copyright (c) 2026 Guodong Xu <guodong@riscstar.com>
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + model = "SpacemiT K3";
> > + compatible = "spacemit,k3";
> > +
> > + cpus: cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + timebase-frequency = <24000000>;
> > +
> > + cpu_0: cpu@0 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <0>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu0_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_1: cpu@1 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <1>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu1_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_2: cpu@2 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <2>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu2_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_3: cpu@3 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <3>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu3_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_4: cpu@4 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <4>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu4_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_5: cpu@5 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <5>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
>
> Should zvl256b be added to the X100 description to indicate the vector
> length?
This is a general topic relevant to all "v" capable RISC-V cores.
To my knowledge, there are currently no upstream Device Tree bindings defined
for zvl*b or vlen. Instead of defining this statically in the DTS, the kernel
history suggests a preference for dynamic discovery. With the existence of
CSR_VLENB, reading it during kernel boot (or say 'hart boot') makes more sense.
This is what actually happening in the kernel right now.
This approach has been part of the design since the earliest
implementations [1].
Link: https://lore.kernel.org/linux-riscv/e896db91e3303f64ac401021f848e536e9d42aaa.1590474856.git.greentime.hu@sifive.com/
[1]
BR,
Guodong Xu
>
> Best regards
>
> Heinrich
>
>
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu5_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_6: cpu@6 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <6>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu6_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_7: cpu@7 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <7>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu7_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + l2_cache0: cache-controller-0 {
> > + compatible = "cache";
> > + cache-block-size = <64>;
> > + cache-level = <2>;
> > + cache-size = <4194304>;
> > + cache-sets = <4096>;
> > + cache-unified;
> > + };
> > +
> > + l2_cache1: cache-controller-1 {
> > + compatible = "cache";
> > + cache-block-size = <64>;
> > + cache-level = <2>;
> > + cache-size = <4194304>;
> > + cache-sets = <4096>;
> > + cache-unified;
> > + };
> > +
> > + cpu-map {
> > + cluster0 {
> > + core0 {
> > + cpu = <&cpu_0>;
> > + };
> > + core1 {
> > + cpu = <&cpu_1>;
> > + };
> > + core2 {
> > + cpu = <&cpu_2>;
> > + };
> > + core3 {
> > + cpu = <&cpu_3>;
> > + };
> > + };
> > +
> > + cluster1 {
> > + core0 {
> > + cpu = <&cpu_4>;
> > + };
> > + core1 {
> > + cpu = <&cpu_5>;
> > + };
> > + core2 {
> > + cpu = <&cpu_6>;
> > + };
> > + core3 {
> > + cpu = <&cpu_7>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + soc: soc {
> > + compatible = "simple-bus";
> > + interrupt-parent = <&saplic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + dma-noncoherent;
> > + ranges;
> > +
> > + uart0: serial@d4017000 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017000 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@d4017100 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017100 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@d4017200 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017200 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart4: serial@d4017300 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017300 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial@d4017400 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017400 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart6: serial@d4017500 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017500 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart7: serial@d4017600 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017600 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart8: serial@d4017700 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017700 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart9: serial@d4017800 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017800 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart10: serial@d401f000 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd401f000 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + simsic: interrupt-controller@e0400000 {
> > + compatible = "spacemit,k3-imsics", "riscv,imsics";
> > + reg = <0x0 0xe0400000 0x0 0x200000>;
> > + #interrupt-cells = <0>;
> > + #msi-cells = <0>;
> > + interrupt-controller;
> > + interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
> > + <&cpu2_intc 9>, <&cpu3_intc 9>,
> > + <&cpu4_intc 9>, <&cpu5_intc 9>,
> > + <&cpu6_intc 9>, <&cpu7_intc 9>;
> > + msi-controller;
> > + riscv,guest-index-bits = <6>;
> > + riscv,hart-index-bits = <4>;
> > + riscv,num-guest-ids = <511>;
> > + riscv,num-ids = <511>;
> > + };
> > +
> > + saplic: interrupt-controller@e0804000 {
> > + compatible = "spacemit,k3-aplic", "riscv,aplic";
> > + reg = <0x0 0xe0804000 0x0 0x4000>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + msi-parent = <&simsic>;
> > + riscv,num-sources = <512>;
> > + };
> > +
> > + clint: timer@e081c000 {
> > + compatible = "spacemit,k3-clint", "sifive,clint0";
> > + reg = <0x0 0xe081c000 0x0 0x4000>;
> > + interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> > + <&cpu1_intc 3>, <&cpu1_intc 7>,
> > + <&cpu2_intc 3>, <&cpu2_intc 7>,
> > + <&cpu3_intc 3>, <&cpu3_intc 7>,
> > + <&cpu4_intc 3>, <&cpu4_intc 7>,
> > + <&cpu5_intc 3>, <&cpu5_intc 7>,
> > + <&cpu6_intc 3>, <&cpu6_intc 7>,
> > + <&cpu7_intc 3>, <&cpu7_intc 7>;
> > + };
> > +
> > + mimsic: interrupt-controller@f1000000 {
> > + compatible = "spacemit,k3-imsics", "riscv,imsics";
> > + reg = <0x0 0xf1000000 0x0 0x10000>;
> > + #interrupt-cells = <0>;
> > + #msi-cells = <0>;
> > + interrupt-controller;
> > + interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>,
> > + <&cpu2_intc 11>, <&cpu3_intc 11>,
> > + <&cpu4_intc 11>, <&cpu5_intc 11>,
> > + <&cpu6_intc 11>, <&cpu7_intc 11>;
> > + msi-controller;
> > + riscv,guest-index-bits = <6>;
> > + riscv,hart-index-bits = <4>;
> > + riscv,num-guest-ids = <511>;
> > + riscv,num-ids = <511>;
> > +
> > + status = "reserved";
> > + };
> > +
> > + maplic: interrupt-controller@f1800000 {
> > + compatible = "spacemit,k3-aplic", "riscv,aplic";
> > + reg = <0x0 0xf1800000 0x0 0x4000>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + msi-parent = <&mimsic>;
> > + riscv,children = <&saplic>;
> > + riscv,delegation = <&saplic 1 512>;
> > + riscv,num-sources = <512>;
> > +
> > + status = "reserved";
> > + };
> > + };
> > +};
> >
>
^ permalink raw reply
* Re: [PATCH v5 11/11] arm64: dts: microchip: add EV23X71A board
From: Claudiu Beznea @ 2026-01-18 14:03 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov
In-Reply-To: <20260115114021.111324-12-robert.marko@sartura.hr>
On 1/15/26 13:37, Robert Marko wrote:
> Microchip EV23X71A is an LAN9696 based evaluation board.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v8] tty: tty_port: add workqueue to flip TTY buffer
From: Jiri Slaby @ 2026-01-19 7:08 UTC (permalink / raw)
To: Xin Zhao, gregkh, tj; +Cc: hch, linux-kernel, linux-serial
In-Reply-To: <20251223034836.2625547-1-jackzxcui1989@163.com>
On 23. 12. 25, 4:48, Xin Zhao wrote:
> On the embedded platform, certain critical data, such as IMU data, is
> transmitted through UART. The tty_flip_buffer_push() interface in the TTY
> layer uses system_dfl_wq to handle the flipping of the TTY buffer.
> Although the unbound workqueue can create new threads on demand and wake
> up the kworker thread on an idle CPU, it may be preempted by real-time
> tasks or other high-prio tasks.
>
> flush_to_ldisc() needs to wake up the relevant data handle thread. When
> executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
> does not disable preemption but disables migration in RT-Linux. This
> prevents the kworker thread from being migrated to other cores by CPU's
> balancing logic, resulting in long delays. The call trace is as follows:
> __wake_up_common_lock
> __wake_up
> ep_poll_callback
> __wake_up_common
> __wake_up_common_lock
> __wake_up
> n_tty_receive_buf_common
> n_tty_receive_buf2
> tty_ldisc_receive_buf
> tty_port_default_receive_buf
> flush_to_ldisc
>
> In our system, the processing interval for each frame of IMU data
> transmitted via UART can experience significant jitter due to this issue.
> Instead of the expected 10 to 15 ms frame processing interval, we see
> spikes up to 30 to 35 ms. Moreover, in just one or two hours, there can
> be 2 to 3 occurrences of such high jitter, which is quite frequent. This
> jitter exceeds the software's tolerable limit of 20 ms.
>
> Introduce flip_wq in tty_port which can be set by tty_port_link_wq() or as
> default linked to default workqueue allocated when tty_register_driver().
> The default workqueue is allocated with flag WQ_SYSFS, so that cpumask and
> nice can be set dynamically. The execution timing of tty_port_link_wq() is
> not clearly restricted. The newly added function tty_port_link_driver_wq()
> checks whether the flip_wq of the tty_port has already been assigned when
> linking the default tty_driver's workqueue to the port. After the user has
> set a custom workqueue for a certain tty_port using tty_port_link_wq(), the
> system will only use this custom workqueue, even if tty_driver does not
> have %TTY_DRIVER_CUSTOM_WORKQUEUE flag.
>
> Introduce %TTY_DRIVER_CUSTOM_WORKQUEUE flag meaning not to create the
> default single tty_driver workqueue. Two reasons why need to introduce the
> %TTY_DRIVER_CUSTOM_WORKQUEUE flag:
> 1. If the WQ_SYSFS parameter is enabled, workqueue_sysfs_register() will
> fail when trying to create a workqueue with the same name. The pty is an
> example of this; if both CONFIG_LEGACY_PTYS and CONFIG_UNIX98_PTYS are
> enabled, the call to tty_register_driver() in unix98_pty_init() will fail.
> 2. Different tty ports may be used for different tasks, which may require
> separate core binding control via workqueues. In this case, the workqueue
> created by default in the tty driver is unnecessary. Enabling this flag
> prevents the creation of this redundant workqueue.
>
> After applying this patch, we can set the related UART TTY flip buffer
> workqueue by sysfs. We set the cpumask to CPU cores associated with the
> IMU tasks, and set the nice to -20. Testing has shown significant
> improvement in the previously described issue, with almost no stuttering
> occurring anymore.
>
> Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
This forgotten XMAS present LGTM ;).
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
--
js
suse labs
^ permalink raw reply
* Re: [PATCH 2/2] serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done
From: Kumar, Udit @ 2026-01-20 5:18 UTC (permalink / raw)
To: Moteen Shah, gregkh, jirislaby
Cc: linux-kernel, linux-serial, vigneshr, gehariprasath, g-praveen,
j-keerthy, u-kumar1
In-Reply-To: <20260112081829.63049-3-m-shah@ti.com>
Please check subject
git log drivers/tty/serial/8250/8250_omap.c
serial: 8250_omap: ....
On 1/12/2026 1:48 PM, Moteen Shah wrote:
> Clear rx_running flag only after DMA teardown polling completes. In the
> previous implementation the flag was being cleared while hardware teardown
hardware to DMA please,
> was still in progress, creating a mismatch between software state
> (flag = 0, "ready") and hardware state (still terminating).
>
> Signed-off-by: Moteen Shah <m-shah@ti.com>
> ---
> drivers/tty/serial/8250/8250_omap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index e26bae0a6488..272bc07c9a6b 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -931,7 +931,6 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
> goto out;
>
> cookie = dma->rx_cookie;
> - dma->rx_running = 0;
>
> /* Re-enable RX FIFO interrupt now that transfer is complete */
> if (priv->habit & UART_HAS_RHR_IT_DIS) {
> @@ -965,6 +964,7 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
> goto out;
> ret = tty_insert_flip_string(tty_port, dma->rx_buf, count);
>
> + dma->rx_running = 0;
> p->port.icount.rx += ret;
> p->port.icount.buf_overrun += count - ret;
> out:
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: 8250_omap.c: Add support for handling UART error conditions
From: Kumar, Udit @ 2026-01-20 5:28 UTC (permalink / raw)
To: Moteen Shah, gregkh, jirislaby
Cc: linux-kernel, linux-serial, vigneshr, gehariprasath, g-praveen,
j-keerthy, u-kumar1
In-Reply-To: <20260112081829.63049-2-m-shah@ti.com>
please check subject of patch
On 1/12/2026 1:48 PM, Moteen Shah wrote:
> The DMA IRQ handler does not accounts for the overrun(OE) or any other
accounts to account
> errors being reported by the IP before triggering a DMA transaction which
transaction, which
> leads to the interrupts not being handled resulting into an IRQ storm.
>
> The way to handle OE is to:
> 1. Reset the RX FIFO.
> 2. Read the UART_RESUME register, which clears the internal flag
>
> Earlier, the driver issued DMA transations even in case of OE which shouldn't
transations to transactions
> be done according to the OE handling mechanism mentioned above, as we are
> resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During
FIFO's to FIFO
> Receive" [0].
>
> [0] https://www.ti.com/lit/pdf/spruiu1
>
> Signed-off-by: Moteen Shah <m-shah@ti.com>
> ---
> drivers/tty/serial/8250/8250_omap.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 9e49ef48b851..e26bae0a6488 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -100,6 +100,9 @@
> #define OMAP_UART_REV_52 0x0502
> #define OMAP_UART_REV_63 0x0603
>
> +/* Resume register */
> +#define UART_OMAP_RESUME 0x0B
> +
> /* Interrupt Enable Register 2 */
> #define UART_OMAP_IER2 0x1B
> #define UART_OMAP_IER2_RHR_IT_DIS BIT(2)
> @@ -119,7 +122,6 @@
> /* Timeout low and High */
> #define UART_OMAP_TO_L 0x26
> #define UART_OMAP_TO_H 0x27
> -
> struct omap8250_priv {
> void __iomem *membase;
> int line;
> @@ -1256,6 +1258,20 @@ static u16 omap_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir, u16 status
> return status;
> }
>
> +static void am654_8250_handle_uart_errors(struct uart_8250_port *up, u8 iir, u16 status)
> +{
> + if (status & UART_LSR_OE) {
> + serial8250_clear_and_reinit_fifos(up);
> + serial_in(up, UART_LSR);
> + serial_in(up, UART_OMAP_RESUME);
> + } else {
> + if (status & (UART_LSR_FE | UART_LSR_PE | UART_LSR_BI))
> + serial_in(up, UART_RX);
> + if (iir & UART_IIR_XOFF)
> + serial_in(up, UART_IIR);
> + }
> +}
> +
> static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
> u16 status)
> {
> @@ -1266,7 +1282,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
> * Queue a new transfer if FIFO has data.
> */
> if ((status & (UART_LSR_DR | UART_LSR_BI)) &&
> - (up->ier & UART_IER_RDI)) {
> + (up->ier & UART_IER_RDI) && !(status & UART_LSR_OE)) {
> + am654_8250_handle_uart_errors(up, iir, status);
may be you can think of splitting error handing into 2 functions ie
handle BI or so and OE error.
when you call above function am654_8250_handle_uart_errors, first
condition will be always false.
> omap_8250_rx_dma(up);
> serial_out(up, UART_OMAP_EFR2, UART_OMAP_EFR2_TIMEOUT_BEHAVE);
> } else if ((iir & 0x3f) == UART_IIR_RX_TIMEOUT) {
> @@ -1282,6 +1299,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
> serial_out(up, UART_OMAP_EFR2, 0x0);
> up->ier |= UART_IER_RLSI | UART_IER_RDI;
> serial_out(up, UART_IER, up->ier);
> + } else {
> + am654_8250_handle_uart_errors(up, iir, status);
I assume , you will hit this else only case of OE ? , if yes then do you
think, call to error handling should be conditional ?
> }
> }
>
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao (陶志勇) @ 2026-01-20 9:07 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, Vasanth Reddy,
linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2026011631-zips-provider-6c46@gregkh>
On Fri, 2026-01-16 at 14:20 +0100, Greg KH wrote:
> On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> > From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
> >
> > Add ACPI support to 8250_mtk driver. This makes it possible to
> > use UART on ARM-based desktops with EDK2 UEFI firmware.
> >
> > Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> > Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
>
> Please use your name, not '.' in it, like your email has. Yenchia
> did
> it properly here.
>
> thanks,
>
> greg k-h
>
> ==> Thank you for your suggestion. I will fix this change in the next
> version.
^ permalink raw reply
* [PATCH 00/12] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Biju @ 2026-01-20 12:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Vinod Koul, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, dmaengine, devicetree,
linux-clk, linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Hi all,
This patch series adds initial support for the Renesas RZ/G3L SoC and
RZ/G3L SMARC EVK platform. The RZ/G3L device is a general-purpose
microprocessor with a quad-core CA-55, single core CM-33, Mali-G31
3-D Graphics and other peripherals.
Support for the below list of blocks is added in the SoC DTSI (r9a08g046.dtsi):
- EXT CLK
- 4X CA55
- SCIF
- CPG
- GIC
- ARMv8 Timer
This series also adds SCIF support for the RZ/G3L SMARC EVK board (r9a08g046l68-smarc.dts).
Test logs:
/ #uname -r
6.19.0-rc6-next-20260119-g31b78275d04b
/ # cat /proc/cpuinfo
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 1
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 2
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
/ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 262 109 324 98 GICv3 27 Level arch_timer
14: 0 0 0 0 GICv3 185 Edge error
15: 0 0 0 0 GICv3 186 Edge 11820000.dma-controller:0
16: 0 0 0 0 GICv3 187 Edge 11820000.dma-controller:1
17: 0 0 0 0 GICv3 188 Edge 11820000.dma-controller:2
18: 0 0 0 0 GICv3 189 Edge 11820000.dma-controller:3
19: 0 0 0 0 GICv3 190 Edge 11820000.dma-controller:4
20: 0 0 0 0 GICv3 191 Edge 11820000.dma-controller:5
21: 0 0 0 0 GICv3 192 Edge 11820000.dma-controller:6
22: 0 0 0 0 GICv3 193 Edge 11820000.dma-controller:7
23: 0 0 0 0 GICv3 194 Edge 11820000.dma-controller:8
24: 0 0 0 0 GICv3 195 Edge 11820000.dma-controller:9
25: 0 0 0 0 GICv3 196 Edge 11820000.dma-controller:10
26: 0 0 0 0 GICv3 197 Edge 11820000.dma-controller:11
27: 0 0 0 0 GICv3 198 Edge 11820000.dma-controller:12
28: 0 0 0 0 GICv3 199 Edge 11820000.dma-controller:13
29: 0 0 0 0 GICv3 200 Edge 11820000.dma-controller:14
30: 0 0 0 0 GICv3 201 Edge 11820000.dma-controller:15
31: 0 0 0 0 GICv3 418 Level 100ac000.serial:rx err
32: 4 0 0 0 GICv3 420 Level 100ac000.serial:rx full
33: 206 0 0 0 GICv3 421 Level 100ac000.serial:tx empty
34: 0 0 0 0 GICv3 419 Level 100ac000.serial:break
35: 13 0 0 0 GICv3 422 Level 100ac000.serial:rx ready
IPI0: 23 26 19 22 Rescheduling interrupts
IPI1: 237 385 152 90 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop NMIs
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU backtrace interrupts
IPI7: 0 0 0 0 KGDB roundup interrupts
/ # cat /proc/meminfo
MemTotal: 1887948 kB
MemFree: 1849056 kB
MemAvailable: 1816424 kB
/ # cat /sys/devices/soc0/family
RZ/G3L
/ # cat /sys/devices/soc0/machine
Renesas SMARC EVK version 2 based on r9a08g046l48
/ # cat /sys/devices/soc0/soc_id
r9a08g046
/ # cat /sys/devices/soc0/revision
0
Biju Das (12):
dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
dt-bindings: dma: rz-dmac: Document RZ/G3L SoC
dt-bindings: soc: renesas: Document Renesas RZ/G3L SoC variants
dt-bindings: soc: renesas: Document RZ/G3L SMARC SoM and Carrier-II
EVK
dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC
soc: renesas: rz-sysc: Add SoC identification for RZ/G3L SoC
dt-bindings: clock: Document RZ/G3L SoC
clk: renesas: Add support for RZ/G3L SoC
arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
arm64: dts: renesas: Add initial support for RZ/G3L SMARC SoM
arm64: dts: renesas: renesas-smarc2: Move usb3 nodes to board DTS
arm64: dts: renesas: Add initial device tree for RZ/G3L SMARC EVK
board
.../bindings/clock/renesas,rzg2l-cpg.yaml | 1 +
.../bindings/dma/renesas,rz-dmac.yaml | 1 +
.../bindings/serial/renesas,scif.yaml | 1 +
.../soc/renesas/renesas,rzg2l-sysc.yaml | 1 +
.../bindings/soc/renesas/renesas.yaml | 13 +
arch/arm64/boot/dts/renesas/Makefile | 2 +
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 219 +++++++++++
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 41 +++
arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi | 13 +
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 6 +
.../boot/dts/renesas/renesas-smarc2.dtsi | 8 -
.../boot/dts/renesas/rzg3l-smarc-som.dtsi | 22 ++
drivers/clk/renesas/Kconfig | 7 +-
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a08g046-cpg.c | 137 +++++++
drivers/clk/renesas/rzg2l-cpg.c | 6 +
drivers/clk/renesas/rzg2l-cpg.h | 1 +
drivers/soc/renesas/Kconfig | 12 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r9a08g046-sysc.c | 91 +++++
drivers/soc/renesas/rz-sysc.c | 3 +
drivers/soc/renesas/rz-sysc.h | 1 +
include/dt-bindings/clock/r9a08g046-cpg.h | 339 ++++++++++++++++++
23 files changed, 918 insertions(+), 9 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
create mode 100644 drivers/clk/renesas/r9a08g046-cpg.c
create mode 100644 drivers/soc/renesas/r9a08g046-sysc.c
create mode 100644 include/dt-bindings/clock/r9a08g046-cpg.h
--
2.43.0
^ permalink raw reply
* [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
From: Biju @ 2026-01-20 12:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, devicetree,
linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260120125232.349708-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Add SCIF binding documentation for Renesas RZ/G3L SoC. SCIF block on the
RZ/G3L is identical to one found on the RZ/G3S SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index a6ef02327be8..82f54446835e 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -82,6 +82,7 @@ properties:
- renesas,scif-r9a07g043 # RZ/G2UL and RZ/Five
- renesas,scif-r9a07g054 # RZ/V2L
- renesas,scif-r9a08g045 # RZ/G3S
+ - renesas,scif-r9a08g046 # RZ/G3L
- const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback
- items:
--
2.43.0
^ permalink raw reply related
* Re: (subset) [PATCH v4 02/15] dt-bindings: mfd: atmel,sama5d2-flexcom: add microchip,lan9691-flexcom
From: Lee Jones @ 2026-01-20 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb, Robert Marko
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-3-robert.marko@sartura.hr>
On Mon, 29 Dec 2025 19:37:43 +0100, Robert Marko wrote:
> Add binding documentation for Microchip LAN969x.
>
>
Applied, thanks!
[02/15] dt-bindings: mfd: atmel,sama5d2-flexcom: add microchip,lan9691-flexcom
commit: 41d1f3cf1f52c75f72ce1a3e2f2ee82e7c6eb59a
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Steven Rostedt @ 2026-01-20 16:08 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, linux-serial, linux-fbdev, Petr Mladek, John Ogness,
Sergey Senozhatsky, Greg Kroah-Hartman, Jiri Slaby, Simona Vetter,
Helge Deller
In-Reply-To: <20260114145955.d924Z-zu@linutronix.de>
On Wed, 14 Jan 2026 15:59:55 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> @@ -3362,22 +3362,6 @@ void console_unlock(void)
> }
> EXPORT_SYMBOL(console_unlock);
>
> -/**
> - * console_conditional_schedule - yield the CPU if required
Egad! That goes all the way back to 2002:
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=a880f45a48be2956d2c78a839c472287d54435c1
> - *
> - * If the console code is currently allowed to sleep, and
> - * if this CPU should yield the CPU to another task, do
> - * so here.
> - *
> - * Must be called within console_lock();.
> - */
> -void __sched console_conditional_schedule(void)
> -{
> - if (console_may_schedule)
> - cond_resched();
> -}
> -EXPORT_SYMBOL(console_conditional_schedule);
I'm assuming this likely isn't needed anymore. I don't know of any reason
it needs to stay.
Should we just remove it and see what breaks?
-- Steve
> -
> void console_unblank(void)
> {
> bool found_unblank = false;
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Sebastian Andrzej Siewior @ 2026-01-20 17:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-serial, linux-fbdev, Petr Mladek, John Ogness,
Sergey Senozhatsky, Greg Kroah-Hartman, Jiri Slaby, Simona Vetter,
Helge Deller
In-Reply-To: <20260120110845.2922a91a@gandalf.local.home>
On 2026-01-20 11:08:45 [-0500], Steven Rostedt wrote:
>
> I'm assuming this likely isn't needed anymore. I don't know of any reason
> it needs to stay.
>
> Should we just remove it and see what breaks?
I would say so.
> -- Steve
Sebastian
^ permalink raw reply
* RE: [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
From: Fabrizio Castro @ 2026-01-20 17:34 UTC (permalink / raw)
To: biju.das.au, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
magnus.damm
Cc: Biju Das, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad,
biju.das.au
In-Reply-To: <20260120125232.349708-2-biju.das.jz@bp.renesas.com>
> From: Biju <biju.das.au@gmail.com>
> Sent: 20 January 2026 12:52
> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Geert
> Uytterhoeven <geert+renesas@glider.be>; magnus.damm <magnus.damm@gmail.com>
> Cc: Biju Das <biju.das.jz@bp.renesas.com>; linux-kernel@vger.kernel.org; linux-serial@vger.kernel.org;
> devicetree@vger.kernel.org; linux-renesas-soc@vger.kernel.org; Prabhakar Mahadev Lad
> <prabhakar.mahadev-lad.rj@bp.renesas.com>; biju.das.au <biju.das.au@gmail.com>
> Subject: [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
>
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add SCIF binding documentation for Renesas RZ/G3L SoC. SCIF block on the
> RZ/G3L is identical to one found on the RZ/G3S SoC.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> index a6ef02327be8..82f54446835e 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> @@ -82,6 +82,7 @@ properties:
> - renesas,scif-r9a07g043 # RZ/G2UL and RZ/Five
> - renesas,scif-r9a07g054 # RZ/V2L
> - renesas,scif-r9a08g045 # RZ/G3S
> + - renesas,scif-r9a08g046 # RZ/G3L
> - const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback
>
> - items:
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
From: Conor Dooley @ 2026-01-20 19:49 UTC (permalink / raw)
To: Biju
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Biju Das,
linux-kernel, linux-serial, devicetree, linux-renesas-soc,
Prabhakar Mahadev Lad
In-Reply-To: <20260120125232.349708-2-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/6] dt-bindings: input: google,goldfish-events-keypad: Convert to DT schema
From: Dmitry Torokhov @ 2026-01-20 19:56 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, sre, gregkh, jirislaby, lgirdwood, broonie,
jserv, eleanor15x, dri-devel, devicetree, linux-kernel,
linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-4-visitorckw@gmail.com>
On Tue, Jan 13, 2026 at 09:25:59AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Events Keypad binding to DT schema format.
> Move the file to the input directory to match the subsystem.
> Update the example node name to 'keypad' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 10/11] dt-bindings: net: sparx5: do not require phys when RGMII is used
From: Rob Herring (Arm) @ 2026-01-21 2:20 UTC (permalink / raw)
To: Robert Marko
Cc: nicolas.ferre, UNGLinuxDriver, gregkh, horatiu.vultur,
andrew+netdev, luka.perkov, lars.povlsen, lee, kuba, linusw,
richardcochran, Steen.Hegelund, richard.genoud,
kavyasree.kotagiri, davem, krzk+dt, linux-spi, daniel.machon,
linux-kernel, edumazet, linux-crypto, conor+dt, linux-gpio,
linux-arm-kernel, pabeni, tudor.ambarus, claudiu.beznea, herbert,
alexandre.belloni, netdev, devicetree, olivia, radu_nicolae.pirea,
linux-serial, Ryan.Wanner
In-Reply-To: <20260115114021.111324-11-robert.marko@sartura.hr>
On Thu, 15 Jan 2026 12:37:35 +0100, Robert Marko wrote:
> LAN969x has 2 dedicated RGMII ports, so regular SERDES lanes are not used
> for RGMII.
>
> So, lets not require phys to be defined when any of the rgmii phy-modes are
> set.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> ---
> .../bindings/net/microchip,sparx5-switch.yaml | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 10/11] dt-bindings: net: sparx5: do not require phys when RGMII is used
From: Jakub Kicinski @ 2026-01-21 2:38 UTC (permalink / raw)
To: Robert Marko
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver, linusw,
olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial, luka.perkov
In-Reply-To: <20260115114021.111324-11-robert.marko@sartura.hr>
On Thu, 15 Jan 2026 12:37:35 +0100 Robert Marko wrote:
> LAN969x has 2 dedicated RGMII ports, so regular SERDES lanes are not used
> for RGMII.
>
> So, lets not require phys to be defined when any of the rgmii phy-modes are
> set.
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao (陶志勇) @ 2026-01-21 6:23 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, Vasanth Reddy,
linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2026010643-ladybug-tiring-7f3c@gregkh>
On Tue, 2026-01-06 at 11:02 +0100, Greg KH wrote:
> On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> > From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
> >
> > Add ACPI support to 8250_mtk driver. This makes it possible to
> > use UART on ARM-based desktops with EDK2 UEFI firmware.
> >
> > Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> > Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
> > ---
> > drivers/tty/serial/8250/8250_mtk.c | 23 +++++++++++++++++++----
> > 1 file changed, 19 insertions(+), 4 deletions(-)
>
> This is a resend of the previous version, right? Or did something
> change?
>
> confused,
>
> greg k-h
==> Hi Greg,
Yes, previously Yenchia Chen helped to send out a version. Currently,
this solution is specifically for the GB10 project and was made to
support Windows ACPI settings.
In actual application scenarios, the apdma clk will not be turned off
in normal mode. It is only turned off in the SSPM microprocessor after
entering standby, and when resuming, the apdma clk is re-enabled by
SSPM.
As for other Linux projects, apdma still uses the DTS node.
Thanks
^ permalink raw reply
* Re: [PATCH v5 06/11] dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
From: Linus Walleij @ 2026-01-21 12:44 UTC (permalink / raw)
To: Robert Marko
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial, luka.perkov, Conor Dooley
In-Reply-To: <20260115114021.111324-7-robert.marko@sartura.hr>
Hi Robert,
On Thu, Jan 15, 2026 at 12:41 PM Robert Marko <robert.marko@sartura.hr> wrote:
> Document LAN969x compatibles for SGPIO.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Should I just merge this one patch to the pinctrl tree?
Looks good to me.
Yours,
Linus Walleij
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Petr Mladek @ 2026-01-21 13:43 UTC (permalink / raw)
To: Steven Rostedt
Cc: Sebastian Andrzej Siewior, linux-kernel, linux-serial,
linux-fbdev, John Ogness, Sergey Senozhatsky, Greg Kroah-Hartman,
Jiri Slaby, Simona Vetter, Helge Deller
In-Reply-To: <20260120110845.2922a91a@gandalf.local.home>
On Tue 2026-01-20 11:08:45, Steven Rostedt wrote:
> On Wed, 14 Jan 2026 15:59:55 +0100
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>
> > @@ -3362,22 +3362,6 @@ void console_unlock(void)
> > }
> > EXPORT_SYMBOL(console_unlock);
> >
> > -/**
> > - * console_conditional_schedule - yield the CPU if required
>
> Egad! That goes all the way back to 2002:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=a880f45a48be2956d2c78a839c472287d54435c1
>
> > - *
> > - * If the console code is currently allowed to sleep, and
> > - * if this CPU should yield the CPU to another task, do
> > - * so here.
> > - *
> > - * Must be called within console_lock();.
> > - */
> > -void __sched console_conditional_schedule(void)
> > -{
> > - if (console_may_schedule)
> > - cond_resched();
> > -}
> > -EXPORT_SYMBOL(console_conditional_schedule);
>
> I'm assuming this likely isn't needed anymore. I don't know of any reason
> it needs to stay.
I know that there was a plan to get rid of cond_resched().
But what is the status now, please?
I still see more that 1k cond_resched() calls in the code:
$> git grep cond_resched\(\) | grep "\.c:" | wc -l
1263
And config PREEMPT_VOLUNTARY still talks about the explicit
preemption points.
> Should we just remove it and see what breaks?
Honestly, I do not feel comfortable with removing it. It is true that
it has no effect in the printk() code path. But the vt code is used
also when working on the terminal.
The vt code still uses console_lock() because it was intertwined
with printk console code since very old days. console_lock is a kind
of big kernel lock there.
Alternative solution is to get rid of the spin_trylock(). The only
purpose is to prevent race in console_flush_on_panic(). It used
to be a simple bit operation. The spin_lock() was added just to
get barriers right. But we have a great atomic_t API these days.
IMHO, it is a win-win solution because a preemptive context is
always better.
What about?
From 0fc61b6877e9beb20429effc599bc4bc6ec3a475 Mon Sep 17 00:00:00 2001
From: Petr Mladek <pmladek@suse.com>
Date: Wed, 21 Jan 2026 10:47:15 +0100
Subject: [RFC] tty/vt: Prevent re-entering vt_console_print() in panic()
without spin_lock
The commit b0940003f25dd ("vt: bitlock fix") replaced a simple bit
operation with spin_lock() to get proper memory barriers.
But the code called under this lock calls console_conditional_schedule()
which calls cond_resched() when console_sem() has been acquired
in a preemptive context using console_lock(). Note that the semaphore
can be taken also in an atomic context using console_trylock()
which is used by printk().
One solution would be to remove console_conditional_schedule().
It does not have any effect in the printk() code path anyway.
But the affected VT code is not used just by printk(). And
the cond_resched() calls were likely added for a reason.
Instead, convert the spin_lock back to an atomic operation with
proper barriers. The only purpose of the lock is to prevent
a concurrent access to the guarded code in
console_flush_on_panic() where console_lock() is ignored.
Using a full featured spin_trylock, just to get memory barriers
right, looks like an overkill anyway.
Fixes: b0940003f25dd ("vt: bitlock fix")
Closes: https://lore.kernel.org/all/20260114145955.d924Z-zu@linutronix.de/
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
drivers/tty/vt/vt.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba..5be64d1bba91 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3353,15 +3353,19 @@ static void vt_console_print(struct console *co, const char *b, unsigned count)
{
struct vc_data *vc = vc_cons[fg_console].d;
unsigned char c;
- static DEFINE_SPINLOCK(printing_lock);
+ static atomic_t printing_lock = ATOMIC_INIT(0);
const ushort *start;
ushort start_x, cnt;
int kmsg_console;
WARN_CONSOLE_UNLOCKED();
- /* this protects against concurrent oops only */
- if (!spin_trylock(&printing_lock))
+ /*
+ * Prevent concurrent printing in console_flush_on_panic() where
+ * console_lock is ignored. Easier (serial) console drivers
+ * have bigger chance to get the messages out.
+ */
+ if (atomic_cmpxchg_acquire(&printing_lock, 0, 1) != 0)
return;
kmsg_console = vt_get_kmsg_redirect();
@@ -3422,7 +3426,7 @@ static void vt_console_print(struct console *co, const char *b, unsigned count)
notify_update(vc);
quit:
- spin_unlock(&printing_lock);
+ atomic_set_release(&printing_lock, 0);
}
static struct tty_driver *vt_console_device(struct console *c, int *index)
--
2.52.0
Best Regards,
Petr
^ permalink raw reply related
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Sebastian Andrzej Siewior @ 2026-01-21 13:57 UTC (permalink / raw)
To: Petr Mladek
Cc: Steven Rostedt, linux-kernel, linux-serial, linux-fbdev,
John Ogness, Sergey Senozhatsky, Greg Kroah-Hartman, Jiri Slaby,
Simona Vetter, Helge Deller
In-Reply-To: <aXDYEVlkFgxdSVSG@pathway.suse.cz>
On 2026-01-21 14:43:45 [+0100], Petr Mladek wrote:
> I know that there was a plan to get rid of cond_resched().
> But what is the status now, please?
It is slowly moving => https://lore.kernel.org/all/20251219101502.GB1132199@noisy.programming.kicks-ass.net/
> I still see more that 1k cond_resched() calls in the code:
>
> $> git grep cond_resched\(\) | grep "\.c:" | wc -l
> 1263
>
> And config PREEMPT_VOLUNTARY still talks about the explicit
> preemption points.
>
> > Should we just remove it and see what breaks?
>
> Honestly, I do not feel comfortable with removing it. It is true that
> it has no effect in the printk() code path. But the vt code is used
> also when working on the terminal.
>
> The vt code still uses console_lock() because it was intertwined
> with printk console code since very old days. console_lock is a kind
> of big kernel lock there.
Do you a have path which loops and would mandate it? I found a few which
do not matter and have their own cond_resched() around. So I don't see a
reason to keep it. And I found one which breaks things so a removal
makes sense.
> Alternative solution is to get rid of the spin_trylock(). The only
> purpose is to prevent race in console_flush_on_panic(). It used
> to be a simple bit operation. The spin_lock() was added just to
> get barriers right. But we have a great atomic_t API these days.
>
> IMHO, it is a win-win solution because a preemptive context is
> always better.
So why do we keep warts again? Just because it *might* be required?
Keeping things preemptible makes sense but this is locking with no
annotation what so ever.
Again. printk has its cond_resched, the tty has it, too.
I'm with Steven on the removal side.
Sebastian
^ 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