* Re: [PATCH v3 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
From: Heinrich Schuchardt @ 2026-01-15 6:19 UTC (permalink / raw)
To: Samuel Holland, 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, Thomas Gleixner, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen
In-Reply-To: <fd95c2f2-9292-483c-9613-4adf3c65c500@sifive.com>
Am 15. Januar 2026 00:57:04 MEZ schrieb Samuel Holland <samuel.holland@sifive.com>:
>Hi Guodong,
>
>On 2026-01-09 3:58 AM, Guodong Xu wrote:
>> Hi, Samuel
>>
>> On Fri, Jan 9, 2026 at 2:19 AM Samuel Holland <samuel.holland@sifive.com> wrote:
>>>
>>> On 2026-01-08 6:26 AM, Guodong Xu wrote:
>>>> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
>>>> Add nodes of uarts, timer and interrupt-controllers.
>>>>
>>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>>> ---
>>>> 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 | 548 +++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 548 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>>> new file mode 100644
>>>> index 0000000000000000000000000000000000000000..be9335fba32cb9e81915b2b91cf08c55a5e96809
>>>> --- /dev/null
>>>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>>> [...]
>>>> + reg = <0x0 0xe0400000 0x0 0x00200000>;
>>>> + interrupt-controller;
>>>> + #interrupt-cells = <0>;
>>>> + msi-controller;
>>>> + #msi-cells = <0>;
>>>> + 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>;
>>>> + riscv,num-ids = <511>;
>>>> + riscv,num-guest-ids = <511>;
>>>> + riscv,hart-index-bits = <4>;
>>>> + riscv,guest-index-bits = <6>;
>>>> + };
>>>> +
>>>> + saplic: interrupt-controller@e0804000 {
>>>> + compatible = "spacemit,k3-aplic", "riscv,aplic";
>>>> + reg = <0x0 0xe0804000 0x0 0x4000>;
>>>> + msi-parent = <&simsic>;
>>>> + #interrupt-cells = <2>;
>>>> + interrupt-controller;
>>>> + riscv,num-sources = <512>;
>>>> + };
>>>
>>> Does the chip also have M-mode IMSIC and APLIC instances? Those need to be
>>> represented in the devicetree as well, for M-mode firmware to access them, just
>>> like the CLINT below.
>>
>> Yes, the K3 chip does have M-mode IMSIC and APLIC instances. Currently, the
>> boot firmware (U-Boot) transfers information about these nodes to OpenSBI.
>> However, you are correct that they should be properly described in the DT.
>>
>> In the next version, I will add the M-mode APLIC (maplic) and IMSIC (mimsic)
>> nodes to k3.dtsi, for topology representation and potential firmware usage.
>> I will set their status to "disabled" because exposing them as "okay" to Linux
>> causes access faults during driver probing.
>>
>> Please let me know if this approach (adding them but keeping them disabled)
>> looks okay to you.
>
>I think this is a reasonable compromise.
>
>Personally, I think of the DTS files in the Linux repository as the "static"
>devicetree, which should describe a "complete" view of the hardware--that is, as
>seen from the highest privilege level. Then it is the responsibility of that
>highly-privileged software to modify the FDT as needed to provide a limited view
>of the hardware to lower-privileged software. And this modification is exactly
>what OpenSBI does before it passes the FDT to U-Boot. So the "static" devicetree
>would not disable these M-mode-only devices.
>
>However, I recognize that people want to use the DTB files generated by the
>Linux build process with Linux directly, ignoring the firmware-provided FDT. In
>that cases the M-mode-only devices need to be disabled. And then you need a
>-u-boot.dtsi file to set `status = "okay"` for the firmware build. I think
U-Boot offers the EFI_DT_FIXUP_PROTOCOL (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) to adjust device-trees loaded by systemd-boot or GRUB.
The disabling should be done there to avoid having different device-trees in firmware and Linux code.
A pull request for providing the protocol in EDK II is pending.
Best regards
Heinrich
>that's a reasonable compromise to make the "static" devicetree as complete as
>possible while still being usable directly in S-mode in some cases. (It still
>breaks if some peripheral is assigned to a different supervisor domain, or some
>DRAM is reserved by M-mode, etc., which is why I really recommend using the
>firmware FDT and not a file.)
>
>Regards,
>Samuel
>
^ permalink raw reply
* Re: [PATCH v3 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
From: Samuel Holland @ 2026-01-14 23:57 UTC (permalink / raw)
To: Guodong Xu
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
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,
Thomas Gleixner, Anup Patel, Greg Kroah-Hartman, Jiri Slaby,
Lubomir Rintel, Yangyu Chen
In-Reply-To: <CAH1PCMZ5rKbG8xEbB9jt6TqyB28T5aLgRtf3iJ8Gt6Fk+3XFhQ@mail.gmail.com>
Hi Guodong,
On 2026-01-09 3:58 AM, Guodong Xu wrote:
> Hi, Samuel
>
> On Fri, Jan 9, 2026 at 2:19 AM Samuel Holland <samuel.holland@sifive.com> wrote:
>>
>> On 2026-01-08 6:26 AM, Guodong Xu wrote:
>>> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
>>> Add nodes of uarts, timer and interrupt-controllers.
>>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>> 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 | 548 +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 548 insertions(+)
>>>
>>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..be9335fba32cb9e81915b2b91cf08c55a5e96809
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> [...]
>>> + reg = <0x0 0xe0400000 0x0 0x00200000>;
>>> + interrupt-controller;
>>> + #interrupt-cells = <0>;
>>> + msi-controller;
>>> + #msi-cells = <0>;
>>> + 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>;
>>> + riscv,num-ids = <511>;
>>> + riscv,num-guest-ids = <511>;
>>> + riscv,hart-index-bits = <4>;
>>> + riscv,guest-index-bits = <6>;
>>> + };
>>> +
>>> + saplic: interrupt-controller@e0804000 {
>>> + compatible = "spacemit,k3-aplic", "riscv,aplic";
>>> + reg = <0x0 0xe0804000 0x0 0x4000>;
>>> + msi-parent = <&simsic>;
>>> + #interrupt-cells = <2>;
>>> + interrupt-controller;
>>> + riscv,num-sources = <512>;
>>> + };
>>
>> Does the chip also have M-mode IMSIC and APLIC instances? Those need to be
>> represented in the devicetree as well, for M-mode firmware to access them, just
>> like the CLINT below.
>
> Yes, the K3 chip does have M-mode IMSIC and APLIC instances. Currently, the
> boot firmware (U-Boot) transfers information about these nodes to OpenSBI.
> However, you are correct that they should be properly described in the DT.
>
> In the next version, I will add the M-mode APLIC (maplic) and IMSIC (mimsic)
> nodes to k3.dtsi, for topology representation and potential firmware usage.
> I will set their status to "disabled" because exposing them as "okay" to Linux
> causes access faults during driver probing.
>
> Please let me know if this approach (adding them but keeping them disabled)
> looks okay to you.
I think this is a reasonable compromise.
Personally, I think of the DTS files in the Linux repository as the "static"
devicetree, which should describe a "complete" view of the hardware--that is, as
seen from the highest privilege level. Then it is the responsibility of that
highly-privileged software to modify the FDT as needed to provide a limited view
of the hardware to lower-privileged software. And this modification is exactly
what OpenSBI does before it passes the FDT to U-Boot. So the "static" devicetree
would not disable these M-mode-only devices.
However, I recognize that people want to use the DTB files generated by the
Linux build process with Linux directly, ignoring the firmware-provided FDT. In
that cases the M-mode-only devices need to be disabled. And then you need a
-u-boot.dtsi file to set `status = "okay"` for the firmware build. I think
that's a reasonable compromise to make the "static" devicetree as complete as
possible while still being usable directly in S-mode in some cases. (It still
breaks if some peripheral is assigned to a different supervisor domain, or some
DRAM is reserved by M-mode, etc., which is why I really recommend using the
firmware FDT and not a file.)
Regards,
Samuel
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: riscv: add SpacemiT X100 CPU compatible
From: Paul Walmsley @ 2026-01-14 23:27 UTC (permalink / raw)
To: Guodong Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Andrew Jones, devicetree, linux-riscv,
linux-kernel, spacemit, linux-serial, Krzysztof Kozlowski,
Heinrich Schuchardt
In-Reply-To: <20260110-k3-basic-dt-v4-1-d492f3a30ffa@riscstar.com>
On Sat, 10 Jan 2026, Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 core. [1]
>
> The X100 is a 64-bit RVA23-compliant RISC-V core from SpacemiT. X100
> supports the RISC-V vector and hypervisor extensions and all mandatory
> extersions as required by the RVA23U64 and RVA23S64 profiles, per the
> definition in 'RVA23 Profile, Version 1.0'. [2]
>
> >From a microarchieture viewpoint, the X100 features a 4-issue
> out-of-order pipeline.
>
> X100 is used in SpacemiT K3 SoC.
>
> Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
> Link: https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf [2]
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: Yixun Lan <dlan@gentoo.org>
> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
(just for completeness, since I acked the older version)
Acked-by: Paul Walmsley <pjw@kernel.org>
- Paul
^ permalink raw reply
* Re: [PATCH v3 01/11] dt-bindings: riscv: add SpacemiT X100 CPU compatible
From: Paul Walmsley @ 2026-01-14 23:17 UTC (permalink / raw)
To: Guodong Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Andrew Jones, devicetree, linux-riscv,
linux-kernel, spacemit, linux-serial, Krzysztof Kozlowski,
Heinrich Schuchardt
In-Reply-To: <20260108-k3-basic-dt-v3-1-ed99eb4c3ad3@riscstar.com>
On Thu, 8 Jan 2026, Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 core. [1]
>
> The X100 is a 64-bit RVA23-compliant RISC-V core from SpacemiT. X100
> supports the RISC-V vector and hypervisor extensions and all mandatory
> extersions as required by the RVA23U64 and RVA23S64 profiles, per the
> definition in 'RVA23 Profile, Version 1.0'. [2]
>
> >From a microarchieture viewpoint, the X100 features a 4-issue
> out-of-order pipeline.
>
> X100 is used in SpacemiT K3 SoC.
>
> Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
> Link: https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf [2]
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: Yixun Lan <dlan@gentoo.org>
> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
I think Yixun Lan is going to pick this up, so
Acked-by: Paul Walmsley <pjw@kernel.org>
- Paul
^ permalink raw reply
* Re: (subset) [PATCH v4 0/6] dt-bindings: goldfish: Convert to DT schema
From: Mark Brown @ 2026-01-14 21:36 UTC (permalink / raw)
To: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, Kuan-Wei Chiu
Cc: jserv, dri-devel, devicetree, linux-kernel, linux-input, linux-pm,
linux-serial, linux-sound, Yu-Chun Lin
In-Reply-To: <20260113092602.3197681-1-visitorckw@gmail.com>
On Tue, 13 Jan 2026 09:25:56 +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish emulator platform bindings from text
> format to DT schema.
>
> Most of these bindings are currently located in
> Documentation/devicetree/bindings/goldfish/. Move them to the
> appropriate subsystem directories (serial, input, power, sound, misc)
> to align with the kernel directory structure.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[5/6] dt-bindings: sound: google,goldfish-audio: Convert to DT schema
commit: 10303b32519f52a5afd40593a507543143c8ec6a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: misc: google,android-pipe: Convert to DT schema
From: Rob Herring (Arm) @ 2026-01-14 20:27 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: broonie, lgirdwood, conor+dt, linux-serial, simona,
maarten.lankhorst, eleanor15x, airlied, linux-pm, tzimmermann,
dri-devel, mripard, Krzysztof Kozlowski, linux-sound, gregkh,
jserv, krzk+dt, dmitry.torokhov, devicetree, jirislaby,
linux-input, linux-kernel, sre
In-Reply-To: <20260113092602.3197681-3-visitorckw@gmail.com>
On Tue, 13 Jan 2026 09:25:58 +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish QEMU Pipe binding to DT schema format.
> Move the file to the misc directory as it represents a miscellaneous
> communication device.
> Update the example node name to 'pipe' to comply with generic node
> naming standards and fix the mismatch between unit address and reg
> property in the original example.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Changes in v4:
> - Use decimal format for interrupts in the example.
>
> .../devicetree/bindings/goldfish/pipe.txt | 17 ---------
> .../bindings/misc/google,android-pipe.yaml | 38 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/goldfish/pipe.txt
> create mode 100644 Documentation/devicetree/bindings/misc/google,android-pipe.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 00/11] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board
From: Rob Herring @ 2026-01-14 20:26 UTC (permalink / raw)
To: Yixun Lan
Cc: Conor Dooley, Paul Walmsley, Guodong Xu, Krzysztof Kozlowski,
Conor Dooley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Paul Walmsley, Heinrich Schuchardt, Kevin Meng Zhang,
Andrew Jones, devicetree, linux-riscv, linux-kernel, spacemit,
linux-serial, Krzysztof Kozlowski, Heinrich Schuchardt,
Conor Dooley
In-Reply-To: <20260114021405-GYB25466@gentoo.org>
On Wed, Jan 14, 2026 at 10:14:05AM +0800, Yixun Lan wrote:
>
> On 22:17 Tue 13 Jan , Conor Dooley wrote:
> > On Tue, Jan 13, 2026 at 08:21:23AM +0800, Yixun Lan wrote:
> > > Hi Conor,
> > >
> > > On 21:45 Mon 12 Jan , Conor Dooley wrote:
> > > > On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> > > >
> > > > > Hi, Conor
> > > > >
> > > > > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > > > > change in v4):
> > > > >
> > > > > 1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> > > > > time, I will start another patchset which implements the strategy
> > > > > outlined by Conor in Link [2] and by Samuel in Link [3].
> > > >
> > > > Okay, that seems reasonable to separate out.
> > > >
> > > > >
> > > > > 2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> > > > > 6 others. "sha" implies these extensions, and it should be allowed
> > > > > to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > > > >
> > > > > 3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> > > > > - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> > > > > - added the dependency check of "za64rs" on "zalrsc" or on "a".
> > > > > - added the dependency check of "ziccrse" on "zalrsc" or "a".
> > > > > The commit message of this patch is updated too, to better explain the
> > > > > relationship between "ziccamoa", "za64rs", "ziccrse" and "a".
> > > > >
> > > > > 4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> > > > > dependency check in both directions, as discussed in [4]. Since "b"
> > > > > was ratified much later than its component extensions (zba/zbb/zbs),
> > > > > existing software and kernels expect these explicit strings. This
> > > > > bidirectional check ensures cores declaring "b" remain compatible
> > > > > with older software that only recognizes zba/zbb/zbs.
> > > >
> > > > This I asked about in the relevant patch, I would like to know what your
> > > > plan for adding the "b"s is.
> > > >
> > > ..
> > > > Spacemit folks, I assume you weren't planning on taking the
> > > > extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> > > > the question about b is answered.
> > >
> > > sure, please take extension stuff which are patches 6-9, for 1-5, it's
> > > all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
> > > I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT
> >
> > Stuff for spacemit is either for you or for the relevant subsystem
> > maintainers. You're probably safe enough taking the
> > timer/interrupt-controller stuff if the maintainers don't apply it in a
> > reasonable period, it's not abnormal for those in particular to go via
> > the platform maintainer in my experience. Just be clear that you have
> > done so. I'm only interested in taking 6-9.
> Hi Conor,
> Ok, I got, thank you!
>
> Hi Paul Walmsley,
> I assume you're responsible for more general riscv stuff with your
> effective maintainer hat, so do you mind if I take patches 1-5 via SpacemiT
> SoC tree? I think the potential conflicts should be low and easy to fix.
> Or, in the other hand, just let me know which patches you would like
> to take, then I will handle the rest. Thanks
Paul would generally only ever take patch 1. You can take 1-5. The timer
and interrupt-controller bindings tend to not get picked up by the
subsystem unless there are driver changes too.
Rob
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-14 17:45 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: <xyttom64ht5hrrp5hecjqehnyfgsv4mfl2t36e2sveu44ccpjl@lkzquse2kqsx>
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.
This isn't exactly a new issue. It could be an issue on any binding
with GPIOs. Perhaps this needs to be handled within GPIO or pinctrl.
> > > +
> > > + oneOf:
> > > + - required:
> > > + - port@0
> > > +
> > > + clocks:
> > > + description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> > > + the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> > > + more details.
> > > + maxItems: 1
> > > +
> > > + w-disable1-gpios:
> > > + description: GPIO input to W_DISABLE1# signal. This signal is used by the
> > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > > + Specification r4.0, sec 3.1.12.3 for more details.
> > > + maxItems: 1
> > > +
> > > + w-disable2-gpios:
> > > + description: GPIO input to W_DISABLE2# signal. This signal is used by the
> > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > > + Specification r4.0, sec 3.1.12.3 for more details.
> > > + maxItems: 1
> > > +
> > > + viocfg-gpios:
> > > + description: GPIO output to IO voltage configuration (VIO_CFG) signal. This
> > > + signal is used by the M.2 card to indicate to the host system that the
> > > + card supports an independent IO voltage domain for the sideband signals.
> > > + Refer, PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details.
> > > + maxItems: 1
> >
> > What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals?
> >
>
> Not sure about vendor defined signals as they can be either GPIO or interface
> signals. How should them be defined?
That kind of breaks any notion of this being a generic slot/connector.
How's the host supposed to know how to connect them? What if a card
required them to be driven a certain way before you can discover the
card? If they can be GPIOs and can be hooked up to the host system
GPIOs, then you should define GPIOs for them. If they aren't GPIOs on
a host, then you omit them.
Rob
^ permalink raw reply
* Re: [PATCH 00/19] printk cleanup - part 3
From: Daniel Thompson @ 2026-01-14 16:38 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Daniel Thompson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Douglas Anderson, Petr Mladek,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Jiri Slaby,
Breno Leitao, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven, Kees Cook,
Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <89409a0f48e6998ff6dd2245691b9954f0e1e435.camel@suse.com>
On Tue, Jan 13, 2026 at 09:32:33PM -0300, Marcos Paulo de Souza wrote:
> I talked with Petr Mladek and it would need to rework the way that we
> register a console, and he's already working on it. For now I believe
> that we could take a look in all the patches besides the last one that
> currently breaks the earlycon with kgdb and maybe other usecases.
>
> Sorry for not catching this issue before. I'll use kgdb next time to
> make sure that it keeps working :)
As I understood things the bug was in earlycon rather then kgdb.
It was picked up by the kgdbtest suite since kgdb does some cool things
with earlycon (thanks to Doug Anderson) so I added a few earlycon tests
to the kgdbtest suite. However it wasn't kgdb itself that failed here.
So... if you want to run https://gitlab.com/daniel-thompson/kgdbtest
then certainly feel free but its probably less effort just to include
a couple of earlycon checks in your testing.
Daniel.
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam @ 2026-01-14 16:14 UTC (permalink / raw)
To: Rob Herring
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: <20260113171424.GA3925312-robh@kernel.org>
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.
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > + description: OF graph bindings modeling the interfaces exposed on the
> > + connector. Since a single connector can have multiple interfaces, every
> > + interface has an assigned OF graph port number as described below.
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Connector interfaces for Wi-Fi
> > +
> > + properties:
> > + endpoint@0:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: PCIe interface
> > +
> > + endpoint@1:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: SDIO interface
>
> I think I already said this, but multiple endpoints are generally for
> something that's muxed. Looking at the connector pinout, PCIe and SDIO
> are not muxed. So these 2 should be 2 port nodes.
>
Sorry, I didn't know that you were asking for 2 port nodes. Will switch to it.
> > +
> > + anyOf:
> > + - required:
> > + - endpoint@0
> > + - required:
> > + - endpoint@1
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Connector interfaces for BT
> > +
> > + properties:
> > + endpoint@0:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: USB 2.0 interface
> > +
> > + endpoint@1:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: UART interface
>
> And UART and USB are not muxed either.
>
Ack.
>
> > +
> > + anyOf:
> > + - required:
> > + - endpoint@0
> > + - required:
> > + - endpoint@1
> > +
> > + port@2:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: PCM/I2S interface
> > +
> > + i2c-parent:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description: I2C interface
>
> Move out of 'ports'.
>
Ack.
> > +
> > + oneOf:
> > + - required:
> > + - port@0
> > +
> > + clocks:
> > + description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> > + the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> > + more details.
> > + maxItems: 1
> > +
> > + w-disable1-gpios:
> > + description: GPIO input to W_DISABLE1# signal. This signal is used by the
> > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > + Specification r4.0, sec 3.1.12.3 for more details.
> > + maxItems: 1
> > +
> > + w-disable2-gpios:
> > + description: GPIO input to W_DISABLE2# signal. This signal is used by the
> > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > + Specification r4.0, sec 3.1.12.3 for more details.
> > + maxItems: 1
> > +
> > + viocfg-gpios:
> > + description: GPIO output to IO voltage configuration (VIO_CFG) signal. This
> > + signal is used by the M.2 card to indicate to the host system that the
> > + card supports an independent IO voltage domain for the sideband signals.
> > + Refer, PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details.
> > + maxItems: 1
>
> What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals?
>
Not sure about vendor defined signals as they can be either GPIO or interface
signals. How should them be defined?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 3/9] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
From: Manivannan Sadhasivam @ 2026-01-14 16:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi,
Bartosz Golaszewski
In-Reply-To: <aWVKTnatLTGwmNVh@smile.fi.intel.com>
On Mon, Jan 12, 2026 at 09:23:58PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 12, 2026 at 09:56:02PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>
> > If an external connector like M.2 is connected to the serdev controller
> > in DT, then the serdev devices may be created dynamically by the connector
> > driver. So do not return -ENODEV from of_serdev_register_devices() if the
> > static nodes are not found and the graph node is used.
>
> ...
>
> > + if (!found && !of_graph_is_present(ctrl->dev.of_node))
>
> dev_of_node()
>
Ack.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam @ 2026-01-14 16:00 UTC (permalink / raw)
To: Hans de Goede
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, 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: <2a44e967-ebae-4641-88d7-ccb4536ee3b7@kernel.org>
On Wed, Jan 14, 2026 at 03:01:51PM +0100, Hans de Goede wrote:
> Hi Mani,
>
> Thank you for your work in this.
>
> On 12-Jan-26 17:26, Manivannan Sadhasivam via B4 Relay wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >
> > Add of_find_serdev_controller_by_node() API to find the serdev controller
> > device associated with the devicetree node.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > drivers/tty/serdev/core.c | 16 ++++++++++++++++
> > include/linux/serdev.h | 9 +++++++++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index b33e708cb245..25382c2d63e6 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> > }
> > EXPORT_SYMBOL_GPL(serdev_controller_alloc);
> >
> > +/**
> > + * of_find_serdev_controller_by_node() - Find the serdev controller associated
> > + * with the devicetree node
> > + * @node: Devicetree node
> > + *
> > + * Return: Pointer to the serdev controller associated with the node. NULL if
> > + * the controller is not found.
> > + */
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
> > +
> > + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
> > +
>
> This new of_find_serdev_controller_by_node() function needs:
>
> #ifdef CONFIG_OF ... #endif
>
> around it, to match the stubbing you are doing in serdev.h
>
Ack.
> > static int of_serdev_register_devices(struct serdev_controller *ctrl)
> > {
> > struct device_node *node;
> > diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> > index ecde0ad3e248..db9bfaba0662 100644
> > --- a/include/linux/serdev.h
> > +++ b/include/linux/serdev.h
> > @@ -333,4 +333,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
> > }
> > #endif /* CONFIG_ACPI */
> >
> > +#ifdef CONFIG_OF
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
> > +#else
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + return NULL;
> > +}
>
> stubs like this one should be static inline to avoid warnings like this one:
>
> In file included from drivers/tty/serdev/core.c:21:
> ./include/linux/serdev.h:339:27: warning: no previous prototype for ‘of_find_serdev_controller_by_node’ [-Wmissing-prototypes]
> 339 | struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Darn... Will fix it. Thanks for spotting!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam @ 2026-01-14 15:57 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Manivannan Sadhasivam via B4 Relay, 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: <CAMRc=McDvQoqfH0Gy-wzbcEGvNCZACSACCcviwpCc4YNSpKYrw@mail.gmail.com>
On Tue, Jan 13, 2026 at 08:54:55AM -0500, Bartosz Golaszewski wrote:
> On Mon, 12 Jan 2026 17:26:01 +0100, Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >
> > Add of_find_serdev_controller_by_node() API to find the serdev controller
> > device associated with the devicetree node.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > drivers/tty/serdev/core.c | 16 ++++++++++++++++
> > include/linux/serdev.h | 9 +++++++++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index b33e708cb245..25382c2d63e6 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> > }
> > EXPORT_SYMBOL_GPL(serdev_controller_alloc);
> >
> > +/**
> > + * of_find_serdev_controller_by_node() - Find the serdev controller associated
> > + * with the devicetree node
> > + * @node: Devicetree node
> > + *
> > + * Return: Pointer to the serdev controller associated with the node. NULL if
> > + * the controller is not found.
> > + */
>
> Please also say that the caller is responsible for calling
> serdev_controller_put() on the returned object.
>
Ack.
- Mani
> Bart
>
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
> > +
> > + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
> > +
> > static int of_serdev_register_devices(struct serdev_controller *ctrl)
> > {
> > struct device_node *node;
> > diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> > index ecde0ad3e248..db9bfaba0662 100644
> > --- a/include/linux/serdev.h
> > +++ b/include/linux/serdev.h
> > @@ -333,4 +333,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
> > }
> > #endif /* CONFIG_ACPI */
> >
> > +#ifdef CONFIG_OF
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
> > +#else
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + return NULL;
> > +}
> > +#endif /* CONFIG_OF */
> > +
> > #endif /*_LINUX_SERDEV_H */
> >
> > --
> > 2.48.1
> >
> >
> >
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* printk's threaded legacy console + fbcon => schedule where it should not
From: Sebastian Andrzej Siewior @ 2026-01-14 14:59 UTC (permalink / raw)
To: linux-kernel, linux-serial, linux-fbdev
Cc: Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Greg Kroah-Hartman, Jiri Slaby, Simona Vetter, Helge Deller
Hi,
legacy_kthread_func() does console_lock() which means
console_may_schedule is 1.
The other path is from vprintk_emit() where we have
if (ft.legacy_direct) {
preempt_disable();
if (console_trylock_spinning())
console_unlock();
preempt_enable();
}
so all printing happens from console_unlock() where
console_may_schedule is 0. This is a small difference. With the legacy
console enabled I get:
| BUG: sleeping function called from invalid context at kernel/printk/printk.c:3377
| in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 15, name: pr/legacy
| preempt_count: 1, expected: 0
| RCU nest depth: 0, expected: 0
| 3 locks held by pr/legacy/15:
| #0: ffffffffa8aebac0 (console_lock){+.+.}-{0:0}, at: legacy_kthread_func+0x6c/0x130
| #1: ffffffffa8aebb18 (console_srcu){....}-{0:0}, at: console_flush_one_record+0x7e/0x4d0
| #2: ffffffffa8c49818 (printing_lock){+.+.}-{3:3}, at: vt_console_print+0x55/0x490
| Preemption disabled at:
| [<0000000000000000>] 0x0
| CPU: 7 UID: 0 PID: 15 Comm: pr/legacy Not tainted 6.19.0-rc5+ #19 PREEMPT(lazy)
| Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3-M, BIOS P2.30 06/29/2012
| Call Trace:
| <TASK>
| dump_stack_lvl+0x68/0x90
| __might_resched.cold+0xf0/0x12b
| console_conditional_schedule+0x27/0x30
| fbcon_redraw+0xa0/0x240
| fbcon_scroll+0x164/0x1c0
| con_scroll+0xfa/0x200
| lf+0xa5/0xb0
| vt_console_print+0x313/0x490
| console_flush_one_record+0x2a0/0x4d0
| legacy_kthread_func+0x83/0x130
| kthread+0x118/0x250
| ret_from_fork+0x309/0x3b0
| ret_from_fork_asm+0x1a/0x30
| </TASK>
because vt_console_print() acquires a spin_lock for synchronisation
against another caller while console_conditional_schedule() would like
to schedule.
Most callers of console_unlock() do trylock except for few such as
__pr_flush() which are affected by this the same way as the legacy
printing thread. But we don't have much pr_flush() so this is hidden.
Is there a strict need for fbcon_scroll() to schedule in fbcon_redraw()?
From a quick look it looks that intense callers such the printk flush do
cond_resched() on their own and tty does it, too
| fbcon_scroll+0x164/0x1c0
| con_scroll+0xfa/0x200
| lf+0xa5/0xb0
| do_con_write+0xc68/0x2630
| con_write+0xf/0x40
| do_output_char+0x180/0x1e0
| n_tty_write+0x1ba/0x580
| file_tty_write.isra.0+0x17e/0x2c0
the cond_resched() is in file_tty_write()/ iterate_tty_write().
Therefore I would suggest to simply
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba1..53daf7614b1af 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3236,7 +3236,6 @@ static int do_con_write(struct tty_struct *tty, const u8 *buf, int count)
goto rescan_last_byte;
}
con_flush(vc, &draw);
- console_conditional_schedule();
notify_update(vc);
return n;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 7be9e865325d9..36dd9d4a46ae0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1607,12 +1607,10 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
start = s;
}
}
- console_conditional_schedule();
s++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, dy, x);
- console_conditional_schedule();
dy++;
}
}
@@ -1648,14 +1646,12 @@ static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
par->bitops->bmove(vc, info, line + ycount, x, line, x, 1,
s - start);
- console_conditional_schedule();
if (ycount > 0)
line++;
else {
@@ -1703,13 +1699,11 @@ static void fbcon_redraw(struct vc_data *vc, int line, int count, int offset)
}
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, line, x);
- console_conditional_schedule();
if (offset > 0)
line++;
else {
diff --git a/include/linux/console.h b/include/linux/console.h
index fc9f5c5c1b04c..ec506d3501965 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -697,7 +697,6 @@ extern int unregister_console(struct console *);
extern void console_lock(void);
extern int console_trylock(void);
extern void console_unlock(void);
-extern void console_conditional_schedule(void);
extern void console_unblank(void);
extern void console_flush_on_panic(enum con_flush_mode mode);
extern struct tty_driver *console_device(int *);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1d765ad242b82..52b1fefdff4e0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3362,22 +3362,6 @@ void console_unlock(void)
}
EXPORT_SYMBOL(console_unlock);
-/**
- * console_conditional_schedule - yield the CPU if required
- *
- * 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);
-
void console_unblank(void)
{
bool found_unblank = false;
Sebastian
^ permalink raw reply related
* Re: [PATCH 06/19] printk: Introduce register_console_force
From: Petr Mladek @ 2026-01-14 14:22 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-6-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:13, Marcos Paulo de Souza wrote:
> The register_console_force function will register a console even if it
> wasn't specified on boot. The new function will act like all consoles
> being registered were using the CON_ENABLED flag.
I am a bit confused by the last sentence. It might be bacause I am not
a native speaker. I wonder if the following is more clear:
<proposal>
The register_console_force() function will register a console even if it
wasn't preferred via the command line, SPCR, or device tree. Currently,
certain drivers pre-set the CON_ENABLE flag to achieve this.
</proposal>
> The CON_ENABLED flag will be removed in the following patches and the
> drivers that use it will migrate to register_console_force instead.
>
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3858,7 +3858,7 @@ static int console_call_setup(struct console *newcon, char *options)
> * enabled such as netconsole
> */
> static int try_enable_preferred_console(struct console *newcon,
> - bool user_specified)
> + bool user_specified, bool force)
> {
> struct console_cmdline *c;
> int i, err;
> @@ -3896,12 +3896,15 @@ static int try_enable_preferred_console(struct console *newcon,
> return 0;
> }
>
> + if (force)
> + newcon->flags |= CON_ENABLED;
> +
This makes sense because the pre-enabled CON_ENABLED flag is handled
right below.
> /*
> * Some consoles, such as pstore and netconsole, can be enabled even
> * without matching. Accept the pre-enabled consoles only when match()
> * and setup() had a chance to be called.
> */
> - if (newcon->flags & CON_ENABLED && c->user_specified == user_specified)
> + if (newcon->flags & CON_ENABLED && c->user_specified == user_specified)
> return 0;
But this location was not a good idea in the first place. It hides an unexpected
side-effect into this function. It is easy to miss. A good example is
the regression caused by the last patch in this patch set, see
https://lore.kernel.org/all/89409a0f48e6998ff6dd2245691b9954f0e1e435.camel@suse.com/
I actually have a patch removing this side-effect:
From d24cd6b812967669900f9866f6202e8b0b65325a Mon Sep 17 00:00:00 2001
From: Petr Mladek <pmladek@suse.com>
Date: Mon, 24 Nov 2025 17:34:25 +0100
Subject: [PATCH] printk/console: Do not rely on
try_enable_preferred_console() for pre-enabled consoles
try_enable_preferred_console() has non-obvious side effects. It returns
success for pre-enabled consoles.
Move the check for pre-enabled consoles to register_console(). It makes
the handling of pre-enabled consoles more obvious.
Also it will allow call try_enable_preferred_console() only when there
is an entry in preferred_consoles[] array. But it would need some more
changes.
It is part of the code clean up. It should not change the existing
behavior.
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/printk/printk.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index abf1b93de056..d6b1d0a26217 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3826,14 +3826,6 @@ static int try_enable_preferred_console(struct console *newcon,
return 0;
}
- /*
- * Some consoles, such as pstore and netconsole, can be enabled even
- * without matching. Accept the pre-enabled consoles only when match()
- * and setup() had a chance to be called.
- */
- if (newcon->flags & CON_ENABLED && pc->user_specified == user_specified)
- return 0;
-
return -ENOENT;
}
@@ -4022,6 +4014,14 @@ void register_console(struct console *newcon)
if (err == -ENOENT)
err = try_enable_preferred_console(newcon, false);
+ /*
+ * Some consoles, such as pstore and netconsole, can be enabled even
+ * without matching. Accept them at this stage when they had a chance
+ * to match() and call setup().
+ */
+ if (err == -ENOENT && (newcon->flags & CON_ENABLED))
+ err = 0;
+
/* printk() messages are not printed to the Braille console. */
if (err || newcon->flags & CON_BRL) {
if (newcon->flags & CON_NBCON)
--
2.52.0
It would be better to do the above change 1st. Then the @force
parameter might be checked in __register_console() directly, like:
/*
* Some consoles, such as pstore and netconsole, can be enabled even
* without matching. Accept them at this stage when they had a chance
* to match() and call setup().
*/
if (err == -ENOENT && (force || newcon->flags & CON_ENABLED))
err = 0;
You might just remove the check of CON_ENABLED in the last patch.
I think that this should actually fix the regression. It will
handle also the case when the console was enabled by
try_enable_default_console() and try_enable_preferred_console()
returned -ENOENT.
Note: I have some more patches which clean up this mess. But they are
more complicated because of how the Braille console support
is wired. They still need some love. Anyway, the above patch should
be good enough for removing CON_ENABLED flag.
Best Regards,
Petr
^ permalink raw reply related
* Re: [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Hans de Goede @ 2026-01-14 14:01 UTC (permalink / raw)
To: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Ilpo Järvinen,
Mark Pearson, Derek J. Clark, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski
Cc: 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: <20260112-pci-m2-e-v4-2-eff84d2c6d26@oss.qualcomm.com>
Hi Mani,
Thank you for your work in this.
On 12-Jan-26 17:26, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> Add of_find_serdev_controller_by_node() API to find the serdev controller
> device associated with the devicetree node.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> drivers/tty/serdev/core.c | 16 ++++++++++++++++
> include/linux/serdev.h | 9 +++++++++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index b33e708cb245..25382c2d63e6 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> }
> EXPORT_SYMBOL_GPL(serdev_controller_alloc);
>
> +/**
> + * of_find_serdev_controller_by_node() - Find the serdev controller associated
> + * with the devicetree node
> + * @node: Devicetree node
> + *
> + * Return: Pointer to the serdev controller associated with the node. NULL if
> + * the controller is not found.
> + */
> +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> +{
> + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
> +
> + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
> +
This new of_find_serdev_controller_by_node() function needs:
#ifdef CONFIG_OF ... #endif
around it, to match the stubbing you are doing in serdev.h
> static int of_serdev_register_devices(struct serdev_controller *ctrl)
> {
> struct device_node *node;
> diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> index ecde0ad3e248..db9bfaba0662 100644
> --- a/include/linux/serdev.h
> +++ b/include/linux/serdev.h
> @@ -333,4 +333,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
> }
> #endif /* CONFIG_ACPI */
>
> +#ifdef CONFIG_OF
> +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
> +#else
> +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> +{
> + return NULL;
> +}
stubs like this one should be static inline to avoid warnings like this one:
In file included from drivers/tty/serdev/core.c:21:
./include/linux/serdev.h:339:27: warning: no previous prototype for ‘of_find_serdev_controller_by_node’ [-Wmissing-prototypes]
339 | struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 05/19] printk: Add more context to suspend/resume functions
From: Petr Mladek @ 2026-01-14 13:20 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-5-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:12, Marcos Paulo de Souza wrote:
> The new comments clarifies from where the functions are supposed to be
> called.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
The improved comments would have helped to understand the previous patch.
I would either merge it into the previous patch or switch the
ordering.
If this stays as a separate patch, feel free to use:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 04/19] printk: Reintroduce consoles_suspended global state
From: Petr Mladek @ 2026-01-14 13:12 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-4-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:11, Marcos Paulo de Souza wrote:
> This change partially reverts commit 9e70a5e109a4
> ("printk: Add per-console suspended state"). The intent of the original
> commit was to move the management of the console suspended state to the
> consoles themselves to be able to use SRCU instead of console lock.
>
> But having a global state is still useful when checking if the global
> suspend was triggered by power management. This way, instead of setting
> the state of each individual console, the code would only set/read from the
> global state.
>
> Along with this change, two more fixes are necessary: change
> console_{suspend,resume} to set/clear CON_SUSPEND instead of setting
> CON_ENABLED and change show_cons_active to call __console_is_usable to
> check console usefulness.
I would invert the logic a bit. I think that the main motivation
is to replace CON_ENABLE -> CON_SUSPEND.
<proposal>
The flag CON_ENABLE is cleared when serial drivers get suspended. This
"hack" has been added by the commit 33c0d1b0c3ebb6 ("[PATCH] Serial
driver stuff") back in v2.5.28.
Stop hijacking CON_ENABLE flag and use the CON_SUSPEND flag instead.
Still allow to distinguish when:
- the backing device is being suspended, see console_suspend().
- the power management wants to calm down all consoles using
a big-hammer, see console_suspend_all().
And restore the global "consoles_suspended" flag which was removed
by the commit 9e70a5e109a4 ("printk: Add per-console suspended state").
The difference is that accesses to the new global flag are
synchronized the same way as to the CON_SUSPEND flag. It allows
to read it under console_srcu_read_lock().
Finally, use __console_is_usable() in show_cons_active(). It is the
last location where the CON_ENABLED flag was checked directly.
The patch should not change the existing behavior because all users check
the state of the console using console_is_usable().
</proposal>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index e2d92cf70eb7..7d2bded75b75 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3552,9 +3552,9 @@ static ssize_t show_cons_active(struct device *dev,
> for_each_console(c) {
> if (!c->device)
> continue;
> - if (!(c->flags & CON_NBCON) && !c->write)
> - continue;
> - if ((c->flags & CON_ENABLED) == 0)
> + if (!__console_is_usable(c, c->flags,
> + consoles_suspended,
> + NBCON_USE_ANY))
It would be better to move this into a separate patch.
> continue;
> cs[i++] = c;
> if (i >= ARRAY_SIZE(cs))
Otherwise, it looks good.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Herve Codina @ 2026-01-14 12:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Bartosz Golaszewski, Sui Jingfeng
In-Reply-To: <aWSuYd8zqCxZ9DYE@smile.fi.intel.com>
Hi Andy, Manivannan,
On Mon, 12 Jan 2026 10:18:41 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> +Cc: Herve (btw, any news on LAN966x support?)
Related to LAN966x support, I am still stucked on issues related to
fw_devlink and DT overlays [1].
[1] https://lore.kernel.org/all/20260112154731.6540453b@bootlin.com/
>
> On Mon, Jan 12, 2026 at 10:04:24AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > Hi,
> > >
> > > This series is the continuation of the series [1] that added the initial support
> > > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > > connectors. These connectors are used to connect the Wireless Connectivity
> > > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > > interfaces are left for future improvements.
Related to describing a connector in DT. If DT overlays are involved to described
what is connected to this connector, some issues need to be fixed.
Those issues are related to referencing an external symbol from the overlay.
We, at Boolin, have been working on the topic
A talk (last year at ELC Europe) gives all details about the topic an related issue:
https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
https://www.youtube.com/watch?v=C8dEQ4OzMnc
Also a discussion took place after this talk:
https://lore.kernel.org/all/20250902105710.00512c6d@booty/
Recently, I also send a RFC series to DTC in order to move forward on this symbol
reverence topic. This series implements features emerged from the pointed out
discussion.
> > >
> > > Serdev device support for BT
> > > ============================
> > >
> > > Adding support for the PCIe interface was mostly straightforward and a lot
> > > similar to the previous Key M connector. But adding UART interface has proved to
> > > be tricky. This is mostly because of the fact UART is a non-discoverable bus,
> > > unlike PCIe which is discoverable. So this series relied on the PCI notifier to
> > > create the serdev device for UART/BT. This means the PCIe interface will be
> > > brought up first and after the PCIe device enumeration, the serdev device will
> > > be created by the pwrseq driver. This logic is necessary since the connector
> > > driver and DT node don't describe the device, but just the connector. So to make
> > > the connector interface Plug and Play, the connector driver uses the PCIe device
> > > ID to identify the card and creates the serdev device. This logic could be
> > > extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
> > > interface for connecting WLAN, a SDIO notifier could be added to create the
> > > serdev device.
> > >
> > > Open questions
> > > ==============
> > >
> > > Though this series adds the relevant functionality for handling the M.2 Key M
> > > connectors, there are still a few open questions exists on the design.
> > >
> > > 1. I've used the DT compatible for the serdev swnode to match the existing OF
> > > device_id of the bluetooth driver. This avoids implementing custom serdev id
> > > matching as implemented till v2.
> >
> > Yeah, swnodes are not designed to replace the real DT or other firmware
> > interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> > fixing up the broken or missed FW device properties). This should not have been
> > done this way. Please, consider another approach, e.g. DT-overlay.
>
> This is what I have in mind when replied to you:
>
> https://lore.kernel.org/all/20251015071420.1173068-1-herve.codina@bootlin.com/
>
> > > 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> > > the PCIe device DT node to extract properties such as
> > > 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> > > add the PCIe DT node in the Root Port in conjunction with the Port node as
> > > below?
> > >
> > > pcie@0 {
> > > wifi@0 {
> > > compatible = "pci17cb,1103";
> > > ...
> > > qcom,calibration-variant = "LE_X13S";
> > > };
> > >
> > > port {
> > > pcie4_port0_ep: endpoint {
> > > remote-endpoint = <&m2_e_pcie_ep>;
> > > };
> > > };
> > > };
Using mechanisms used by the LAN966x, those wifi@0 and port nodes could be added by
a DT overlay by the PCI device driver handling the Qcom QCA6390 PCI device.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 03/19] printk: Drop flags argument from console_is_usable
From: Petr Mladek @ 2026-01-14 8:44 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-3-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:10, Marcos Paulo de Souza wrote:
> The flags argument was also used to check if CON_NBCON was set, but their
> usage was fixed in the last commit. All current users are reading the
> variable just to call console_is_usable.
>
> By calling console_srcu_read_flags inside console_is_usable makes the
> code cleaner and removes one argument from the function.
>
> Along with it, create a variant called __console_is_usable that can be
> used under console_list_lock(), like unregister_console_locked.
>
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -656,13 +656,8 @@ extern bool nbcon_kdb_try_acquire(struct console *con,
> struct nbcon_write_context *wctxt);
> extern void nbcon_kdb_release(struct nbcon_write_context *wctxt);
>
> -/*
> - * Check if the given console is currently capable and allowed to print
> - * records. Note that this function does not consider the current context,
> - * which can also play a role in deciding if @con can be used to print
> - * records.
> - */
> -static inline bool console_is_usable(struct console *con, short flags,
> +/* Variant of console_is_usable() when the console_list_lock is held. */
Nit: The comment is a bit misleading because this function is called
also from console_is_usable() under console_srcu_read_lock().
I would say something like:
/*
* The caller must ensure that @con can't disappear either by taking
* console_list_lock() or console_srcu_read_lock(). See also
* console_is_usable().
*/
> +static inline bool __console_is_usable(struct console *con, short flags,
> enum nbcon_write_cb nwc)
> {
> if (!(flags & CON_ENABLED))
> @@ -707,6 +702,18 @@ static inline bool console_is_usable(struct console *con, short flags,
> return true;
> }
>
> +/*
> + * Check if the given console is currently capable and allowed to print
> + * records. Note that this function does not consider the current context,
> + * which can also play a role in deciding if @con can be used to print
> + * records.
And I would add here something like:
*
* Context: Must be called under console_srcu_read_lock().
> + */
> +static inline bool console_is_usable(struct console *con,
> + enum nbcon_write_cb nwc)
> +{
> + return __console_is_usable(con, console_srcu_read_flags(con), nwc);
> +}
> +
> #else
> static inline void nbcon_cpu_emergency_enter(void) { }
> static inline void nbcon_cpu_emergency_exit(void) { }
Otherwise, it looks good. It is a nice clean up.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 00/19] printk cleanup - part 3
From: Petr Mladek @ 2026-01-14 8:20 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Daniel Thompson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <89409a0f48e6998ff6dd2245691b9954f0e1e435.camel@suse.com>
On Tue 2026-01-13 21:32:33, Marcos Paulo de Souza wrote:
> On Tue, 2026-01-13 at 09:41 -0300, Marcos Paulo de Souza wrote:
> > On Mon, 2026-01-05 at 14:08 +0000, Daniel Thompson wrote:
> > > On Mon, Jan 05, 2026 at 12:52:14PM +0000, Daniel Thompson wrote:
> > > > Hi Marcos
> > > >
> > > > On Sat, Dec 27, 2025 at 09:16:07AM -0300, Marcos Paulo de Souza
> > > > wrote:
> > > > > The parts 1 and 2 can be found here [1] and here[2].
> > > > >
> > > > > The changes proposed in this part 3 are mostly to clarify the
> > > > > usage of
> > > > > the interfaces for NBCON, and use the printk helpers more
> > > > > broadly.
> > > > > Besides it, it also introduces a new way to register consoles
> > > > > and drop thes the CON_ENABLED flag. It seems too much, but in
> > > > > reality
> > > > > the changes are not complex, and as the title says, it's
> > > > > basically a
> > > > > cleanup without changing the functional changes.
> > > >
> > > > I ran this patchset through the kgdb test suite and I'm afraid it
> > > > is
> > > > reporting functional changes.
> > > >
> > > > Specifically the earlycon support for kdb has regressed (FWIW the
> > > > problem bisects down to the final patch in the series where
> > > > CON_ENABLED
> > > > is removed).
> > > >
> > > > Reproduction on x86-64 KVM outside of the test suite should be
> > > > easy:
> > > >
> > > > make defconfig
> > > > scripts/config \
> > > > --enable DEBUG_INFO \
> > > > --enable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
> > > > --enable DEBUG_FS \
> > > > --enable KALLSYMS_ALL \
> > > > --enable MAGIC_SYSRQ \
> > > > --enable KGDB \
> > > > --enable KGDB_TESTS \
> > > > --enable KGDB_KDB \
> > > > --enable KDB_KEYBOARD \
> > > > --enable LKDTM \
> > > > --enable SECURITY_LOCKDOWN_LSM
> > > > make olddefconfig
> > > > make -j$(nproc)
> > > > qemu-system-x86_64 \
> > > > -m 1G -smp 2 -nographic \
> > > > -kernel arch/x86/boot/bzImage \
> > > > -append "console=ttyS0,115200 kgdboc=ttyS0
> > > > earlycon=uart8250,io,0x3f8 kgdboc_earlycon kgdbwait"
> > >
> > > Actually I realized there was a simpler reproduction (hinted at by
> > > the
> > > missing "printk: legacy bootconsole [uart8250] enabled" in the
> > > regressed
> > > case). It looks like the earlycon simply doesn't work and that
> > > means
> > > the
> > > reproduction doesn't require anything related to kgdb at all.
> > > Simply:
> > >
> > > make defconfig
> > > make -j$(nproc)
> > > qemu-system-x86_64 -m 1G -smp 2 -nographic -kernel
> > > arch/x86/boot/bzImage \
> > > -append "earlycon=uart8250,io,0x3f8"
> > >
> > > With the part 3 patchset applied I get no output from the earlycon
> > > (without the patch set I get the early boot messages which, as
> > > expected,
> > > stop when tty0 comes up).
> >
> > Hi Daniel, sorry for the late reply! Lots of things to check lately
> > :)
> >
> > Ok, I reproduced here, thanks a lot for testing kgdboc, it's a quick
> > way to check that the new register_console_force is not working. Let
> > me
> > take a look to find what's wrong. Thanks a lot for finding this
> > issue!
>
> Ok, I did a bisect and found out that the issue lies in the last
> commit, where CON_ENABLED was removed. After it, I then checked what
> was wrong, since everything was being plumbed correctly (tm), and then
> I found that it was not:
>
> On _register_console, the function try_enable_default_console is called
> when there are not registered consoles, and then it sets CON_ENABLED
> for the console. Later on, try_enable_preferred_console it checks if
> the console was specified by the user, and at the same time it had
> CON_ENABLED set.
>
> It worked by chance, but now, we don't have this flag anymore, and then
> we are not _marking_ the console on try_enable_default_console so
> try_enable_preferred_console returns ENOENT.
Great catch! Yeah, it worked just by chance.
> So, without any console kgdb is activated much later in the boot
> process, as you found it.
>
> I talked with Petr Mladek and it would need to rework the way that we
> register a console, and he's already working on it.
Yes, I have some patches in early stages of developnent of another
feature which would help here.
> For now I believe
> that we could take a look in all the patches besides the last one that
> currently breaks the earlycon with kgdb and maybe other usecases.
I agree. I am going to review this patchset first. Then I'll try to
clean up the patches which remove the ugly side effect from
try_enable_preferred_console(). Then we could discuss how
to move forward. It might make sense to push this patchset
first without the last patch...
> Sorry for not catching this issue before. I'll use kgdb next time to
> make sure that it keeps working :)
Do not worry at all. It was a well hidden catch. It is great that
Daniel found the regression in time...
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v4 5/6] dt-bindings: sound: google,goldfish-audio: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14 7:31 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-6-visitorckw@gmail.com>
On Tue, Jan 13, 2026 at 09:26:01AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Audio binding to DT schema format.
> Move the file to the sound directory to match the subsystem.
> Update the example node name to 'sound' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> .../devicetree/bindings/goldfish/audio.txt | 17 ---------
> .../bindings/sound/google,goldfish-audio.yaml | 38 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/goldfish/audio.txt
> create mode 100644 Documentation/devicetree/bindings/sound/google,goldfish-audio.yaml
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 4/6] dt-bindings: power: supply: google,goldfish-battery: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14 7:31 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-5-visitorckw@gmail.com>
On Tue, Jan 13, 2026 at 09:26:00AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Battery binding to DT schema format.
> Move the file to the power/supply directory to match the subsystem.
> Update the example node name to 'battery' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/6] dt-bindings: input: google,goldfish-events-keypad: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14 7:31 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <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>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] serial:xilinx_uartps:fix rs485 delay_rts_after_send
From: Shubhrajyoti Datta @ 2026-01-14 4:38 UTC (permalink / raw)
To: j.turek
Cc: gregkh, jirislaby, michal.simek, namcao, tglx, zack.rusin,
sean.anderson, hshah, linux-serial, linux-arm-kernel,
linux-kernel
In-Reply-To: <20251221103221.1971125-1-jakub.turek@elsta.tech>
On Sun, Dec 21, 2025 at 4:03 PM j.turek <jakub.turek@elsta.tech> wrote:
>
> RTS line control with delay should be triggered when there is no more bytes
> in kfifo and hardware buffer is empty. Without this patch RTS control is
> scheduled right after feeding hardware buffer and this is too early.
> RTS line may change state before hardware buffer is empty.
> With this patch delayed RTS state change is triggered when function
> cdns_uart_handle_tx is called from cdns_uart_isr on CDNS_UART_IXR_TXEMPTY
> exactly when hardware completed transmission
>
> Signed-off-by: Jakub Turek <jakub.turek@elsta.tech>
>
> Fixes: fccc9d9233f9 ("tty: serial: uartps: Add rs485 support to uartps driver")
Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
^ 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