* [PATCH v7 5/8] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam via B4 Relay @ 2026-03-26 8:06 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
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,
Manivannan Sadhasivam
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
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.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
.../bindings/connector/pcie-m2-e-connector.yaml | 184 +++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 185 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..f7859aa9b634
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
@@ -0,0 +1,184 @@
+# 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.
+
+ i2c-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: I2C interface
+
+ 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 output to W_DISABLE1# signal. This signal is used by the
+ host 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 output to W_DISABLE2# signal. This signal is used by the
+ host system to disable BT 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 input to IO voltage configuration (VIO_CFG) signal. The
+ card drives this signal to indicate to the host system whether the card
+ supports an independent IO voltage domain for sideband signals. Refer,
+ PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details.
+ maxItems: 1
+
+ uart-wake-gpios:
+ description: GPIO input to UART_WAKE# signal. The card asserts this signal
+ to wake the host system and initiate UART interface communication. Refer,
+ PCI Express M.2 Specification r4.0, sec 3.1.8.1 for more details.
+ maxItems: 1
+
+ sdio-wake-gpios:
+ description: GPIO input to SDIO_WAKE# signal. The card asserts this signal
+ to wake the host system and initiate SDIO interface communication. Refer,
+ PCI Express M.2 Specification r4.0, sec 3.1.7 for more details.
+ maxItems: 1
+
+ sdio-reset-gpios:
+ description: GPIO output to SDIO_RESET# signal. This signal is used by the
+ host system to reset SDIO interface of the M.2 card. Refer, PCI Express
+ M.2 Specification r4.0, sec 3.1.7 for more details.
+ maxItems: 1
+
+ vendor-porta-gpios:
+ description: GPIO for the first vendor specific signal (VENDOR_PORTA). This
+ signal's functionality is defined by the card manufacturer and may be
+ used for proprietary features. Refer the card vendor's documentation for
+ details.
+ maxItems: 1
+
+ vendor-portb-gpios:
+ description: GPIO for the second vendor specific signal (VENDOR_PORTB). This
+ signal's functionality is defined by the card manufacturer and may be
+ used for proprietary features. Refer the card vendor's documentation for
+ details.
+ maxItems: 1
+
+ vendor-portc-gpios:
+ description: GPIO for the third vendor specific signal (VENDOR_PORTC). This
+ signal's functionality is defined by the card manufacturer and may be
+ used for proprietary features. Refer the card vendor's documentation for
+ details.
+ maxItems: 1
+
+ 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: PCIe interface for Wi-Fi
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: SDIO interface for Wi-Fi
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: USB 2.0 interface for BT
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: UART interface for BT
+
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: PCM/I2S interface
+
+ anyOf:
+ - anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+ - anyOf:
+ - required:
+ - port@2
+ - required:
+ - port@3
+
+required:
+ - compatible
+ - vpcie3v3-supply
+
+additionalProperties: false
+
+examples:
+ # PCI M.2 Key E connector for Wi-Fi/BT with PCIe/UART interfaces
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <&vreg_wcn_3p3>;
+ vpcie1v8-supply = <&vreg_l15b_1p8>;
+ i2c-parent = <&i2c0>;
+ w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>;
+ w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
+ viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+ uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
+ sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
+ sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcie4_port0_ep>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&uart14_ep>;
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index a38fe0ed7144..bd72ce52f00c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21029,6 +21029,7 @@ PCIE M.2 POWER SEQUENCING
M: Manivannan Sadhasivam <mani@kernel.org>
L: linux-pci@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
F: Documentation/devicetree/bindings/connector/pcie-m2-m-connector.yaml
F: drivers/power/sequencing/pwrseq-pcie-m2.c
--
2.51.0
^ permalink raw reply related
* [PATCH v7 4/8] dt-bindings: serial: Document the graph port
From: Manivannan Sadhasivam via B4 Relay @ 2026-03-26 8:06 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
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,
Manivannan Sadhasivam, Bartosz Golaszewski
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
A serial controller could be connected to an external connector like PCIe
M.2 for controlling the serial interface of the card. Hence, document the
OF graph port.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Documentation/devicetree/bindings/serial/serial.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
index 6aa9cfae417b..96eb1de8771e 100644
--- a/Documentation/devicetree/bindings/serial/serial.yaml
+++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -87,6 +87,9 @@ properties:
description:
TX FIFO threshold configuration (in bytes).
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
patternProperties:
"^(bluetooth|bluetooth-gnss|embedded-controller|gnss|gps|mcu|onewire)$":
if:
--
2.51.0
^ permalink raw reply related
* [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Manivannan Sadhasivam via B4 Relay @ 2026-03-26 8:06 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski,
Bartosz Golaszewski
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.
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.
Testing
=======
This series, together with the devicetree changes [2] was tested on the
Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
1620 LGA card connected over PCIe and UART.
Merge Strategy
==============
Due to the API dependency, both the serdev and pwrseq patches need to go through
a single tree, maybe through pwrseq tree. So the serdev patches need Ack from
Greg. But Bluetooth patch can be merged separately.
NOTE
====
This series is based on bluetooth-next/master to resolve the conflict with the
Bluetooth patch. Other pathces should apply cleanly on top of v7.0-rc1.
[1] https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com
[2] https://github.com/Mani-Sadhasivam/linux/commit/b50f8386900990eed3dce8d91c3b643fb0e8739d
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Changes in v7:
- Dropped the LGA binding change due to vendor prefix concern. This will be
submitted later once I get clarity.
- Fixed several issues in the cleanup path of the pwrseq-pci-m2 driver which
includes adding the .remove() callback.
- Rebased on top of bluetooth-next/master to resolve conflict with bluetooth
patch.
- Link to v6: https://lore.kernel.org/r/20260317-pci-m2-e-v6-0-9c898f108d3d@oss.qualcomm.com
Changes in v6:
- Added a check to bail out if the serdev device was already added during notifier.
- Collected tags
- Link to v5: https://lore.kernel.org/r/20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com
Changes in v5:
- Incorporated comments in the binding patch by using single endpoint per port,
reordering port nodes, adding missing properties and using a complete example.
- Incorporated comments in the pwrseq patch (nothing major)
- Fixed the build issue in patch 2
- Collected tags
- Rebased on top of 7.0-rc1
- Link to v4: https://lore.kernel.org/r/20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com
Changes in v4:
- Switched to dynamic OF node for serdev instead of swnode and dropped all
swnode related patches
- Link to v3: https://lore.kernel.org/r/20260110-pci-m2-e-v3-0-4faee7d0d5ae@oss.qualcomm.com
Changes in v3:
- Switched to swnode for the serdev device and dropped the custom
serdev_device_id related patches
- Added new swnode APIs to match the swnode with existing of_device_id
- Incorporated comments in the bindings patch
- Dropped the UIM interface from binding since it is not clear how it should get
wired
- Incorporated comments in the pwrseq driver patch
- Splitted the pwrseq patch into two
- Added the 1620 LGA compatible with Key E fallback based on Stephan's finding
- Link to v2: https://lore.kernel.org/r/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com
Changes in v2:
- Used '-' for GPIO names in the binding and removed led*-gpios properties
- Described the endpoint nodes for port@0 and port@1 nodes
- Added the OF graph port to the serial binding
- Fixed the hci_qca driver to return err if devm_pwrseq_get() fails
- Incorporated various review comments in pwrseq driver
- Collected Ack
- Link to v1: https://lore.kernel.org/r/20251112-pci-m2-e-v1-0-97413d6bf824@oss.qualcomm.com
---
Manivannan Sadhasivam (8):
serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
serdev: Add an API to find the serdev controller associated with the devicetree node
serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
dt-bindings: serial: Document the graph port
dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
.../bindings/connector/pcie-m2-e-connector.yaml | 184 +++++++++++
.../devicetree/bindings/serial/serial.yaml | 3 +
MAINTAINERS | 1 +
drivers/bluetooth/hci_qca.c | 9 +
drivers/power/sequencing/Kconfig | 3 +-
drivers/power/sequencing/pwrseq-pcie-m2.c | 346 ++++++++++++++++++++-
drivers/tty/serdev/core.c | 28 +-
include/linux/serdev.h | 24 +-
8 files changed, 570 insertions(+), 28 deletions(-)
---
base-commit: 559f264e403e4d58d56a17595c60a1de011c5e20
change-id: 20251112-pci-m2-e-94695ac9d657
Best regards,
--
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v7 1/8] serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
From: Manivannan Sadhasivam via B4 Relay @ 2026-03-26 8:06 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
If these helpers receive the 'const struct device' pointer, then the const
qualifier will get dropped, leading to below warning:
warning: passing argument 1 of ‘to_serdev_device_driver’ discards 'const'
qualifier from pointer target type [-Wdiscarded-qualifiers]
This is not an issue as of now, but with the future commits adding serdev
device based driver matching, this warning will get triggered. Hence,
convert these helpers to macros so that the qualifier get preserved and
also use container_of_const() as container_of() is deprecated.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
include/linux/serdev.h | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 5654c58eb73c..0c7d3c27d1f8 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -49,10 +49,7 @@ struct serdev_device {
struct mutex write_lock;
};
-static inline struct serdev_device *to_serdev_device(struct device *d)
-{
- return container_of(d, struct serdev_device, dev);
-}
+#define to_serdev_device(d) container_of_const(d, struct serdev_device, dev)
/**
* struct serdev_device_driver - serdev slave device driver
@@ -68,10 +65,7 @@ struct serdev_device_driver {
void (*shutdown)(struct serdev_device *);
};
-static inline struct serdev_device_driver *to_serdev_device_driver(struct device_driver *d)
-{
- return container_of(d, struct serdev_device_driver, driver);
-}
+#define to_serdev_device_driver(d) container_of_const(d, struct serdev_device_driver, driver)
enum serdev_parity {
SERDEV_PARITY_NONE,
@@ -112,10 +106,7 @@ struct serdev_controller {
const struct serdev_controller_ops *ops;
};
-static inline struct serdev_controller *to_serdev_controller(struct device *d)
-{
- return container_of(d, struct serdev_controller, dev);
-}
+#define to_serdev_controller(d) container_of_const(d, struct serdev_controller, dev)
static inline void *serdev_device_get_drvdata(const struct serdev_device *serdev)
{
--
2.51.0
^ permalink raw reply related
* [PATCH v7 3/8] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
From: Manivannan Sadhasivam via B4 Relay @ 2026-03-26 8:06 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
If an external connector like M.2 is connected to the serdev controller
in DT, then the serdev devices may be created dynamically by the connector
driver. So do not return -ENODEV from of_serdev_register_devices() if the
static nodes are not found and the graph node is used.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/tty/serdev/core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index bf88b95f7458..e9d044a331b0 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/of_device.h>
#include <linux/pm_domain.h>
#include <linux/pm_runtime.h>
@@ -561,7 +562,13 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
} else
found = true;
}
- if (!found)
+
+ /*
+ * When the serdev controller is connected to an external connector like
+ * M.2 in DT, then the serdev devices may be created dynamically by the
+ * connector driver.
+ */
+ if (!found && !of_graph_is_present(dev_of_node(&ctrl->dev)))
return -ENODEV;
return 0;
--
2.51.0
^ permalink raw reply related
* [PATCH v7 2/8] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam via B4 Relay @ 2026-03-26 8:06 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski
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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Add of_find_serdev_controller_by_node() API to find the serdev controller
device associated with the devicetree node.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/tty/serdev/core.c | 19 +++++++++++++++++++
include/linux/serdev.h | 9 +++++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 8f25510f89b6..bf88b95f7458 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -514,6 +514,25 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
}
EXPORT_SYMBOL_GPL(serdev_controller_alloc);
+#ifdef CONFIG_OF
+/**
+ * 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. Caller is responsible for calling
+ * serdev_controller_put() to drop the reference.
+ */
+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);
+#endif
+
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 0c7d3c27d1f8..188c0ba62d50 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -334,4 +334,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
+static inline struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
#endif /*_LINUX_SERDEV_H */
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-03-25 12:06 UTC (permalink / raw)
To: Mark Pearson
Cc: Dmitry Baryshkov, Rob Herring, Manivannan Sadhasivam, Greg KH,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Derek J . Clark, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86@vger.kernel.org, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
linux-acpi@vger.kernel.org
In-Reply-To: <3faffec9-dc9d-4eec-a652-a84d30d85c96@app.fastmail.com>
On Mon, Mar 23, 2026 at 01:23:07PM -0400, Mark Pearson wrote:
>
>
> On Mon, Mar 23, 2026, at 12:52 PM, Manivannan Sadhasivam wrote:
> > On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
> >> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> >> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> >> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> >> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> >> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >> > > > > >
> >> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> >> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> >> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> >> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> >> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> >> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> >> > > > > > > > to reuse the Key E binding.
> >> > > > > > >
> >> > > > > > > What is LGA?
> >> > > > > > >
> >> > > > > >
> >> > > > > > Land Grid Array
> >> > > > > >
> >> > > > > > > If not in the spec, is it really something generic?
> >> > > > > > >
> >> > > > > >
> >> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> >> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> >> > > > > > the spec gives room for hardware designers to be as innovative as possible to
> >> > > > > > save the BOM cost.
> >> > > > >
> >> > > > > innovation == incompatible changes
> >> > > > >
> >> > > >
> >> > > > Yes, I was trying to sound nice :)
> >> > > >
> >> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> >> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> >> > > > >
> >> > > > > Depends if you think that s/w needs to know the differences. Hard to
> >> > > > > say with a sample size of 1.
> >> > > > >
> >> > > >
> >> > > > Sure. Will add the 'lenovo' prefix then.
> >> > >
> >> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> >> > > being used by Lenovo?
> >> > >
> >> > > I remember that DB820c also used some kind of a module for the WiFi card
> >> > > (which might be M.2 compatible or might not, I can't find exact docs at
> >> > > this point).
> >> > >
> >> >
> >> > I don't know. These kind of designs might be reused by several vendors. But
> >> > considering that we should not make it generic, I'd go with Lenovo as that's
> >> > the only vendor we know as of now.
> >>
> >> ... and later we learn that other vendors use the same idea /pinout,
> >> then nothing stops us from still telling that it's a
> >> "lenovo,pcie-m2-something-lga".
> >>
> >
> > How do you possibly know whether a single vendor has introduced this form factor
> > or reused by multiple ones? Atleast, I don't have access to such a source to
> > confirm.
> >
> I've not really been following this thread/patchset in detail; but want me to try and check with the T14s platform team if this device is specifically made for us (Lenovo) or not?
> I doubt it is - we just don't do that usually, but I can go and ask the question if it will help resolve this (with the caveat that it could hold up the review for a bit and I may not be able to get a straight answer)
>
I can drop this specific patch in the meantime.
> My vote (for what little it's worth) would be to make it non-Lenovo specific. Then when the same part causes issues on another vendors platform I won't get asked questions about why Lenovo is breaking <other vendor> :)
>
Even if Lenovo prefix is used, it won't break other vendors. Just that we will
end up adding more compatibles.
Anyhow, I'll wait for your reply and drop this patch for next revision.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao (陶志勇) @ 2026-03-25 6:39 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, Vasanth Reddy,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <2026031837-slimness-playset-a62b@gregkh>
On Wed, 2026-03-18 at 15:19 +0100, gregkh@linuxfoundation.org wrote:
> On Wed, Mar 18, 2026 at 12:12:36PM +0000, Zhiyong Tao (陶志勇) wrote:
> > On Wed, 2026-01-21 at 14:23 +0800, Zhiyong Tao wrote:
> > > 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(-)
==>Hi Greg,
Yes, it is a resend of the previous version to rebase to tip for
friendly ping. it is based on the latest linux-next version.
Thanks
> > > >
> > > > 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
> > >
> >
> > Hi Greg,
> > Do you have other suggestion for this?
>
> You can't just resend something and not say why you are resending it.
> Also, the authorship information seems to be backwards.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH v8 00/11] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Biju @ 2026-03-24 11:43 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, 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 (r9a08g046l48-smarc.dts).
v7->v8:
* Added logs for MSTOP state during suspend/resume cycle of s2idle.
* Fixed the R9A08G046_ADC1_ADCLK macro value 138->139.
* Added helper for mod clock enable/disable to allow callers to control
whether the module stop state is updated alongside the clock
enable/disable operation.
* Fit the comments in rzg2l_mod_clock_init_mstop_helper() to 80 character
space.
* Updated comment in rzg2l_mod_clock_init_mstop_helper() as resume()
calls this function.
* To avoid setting module state twice and also not to update the initial
mstop state for the critical clocks state during probe, replaced
rzg2l_mod_clock_endisable()->rzg2l_mod_clock_endisable_helper().
* Fixed the typo RZ/G3E->RZ/G3L in r9a08g046l48.dtsi
v6->v7:
* Collected tag
* Updated r9a07g043_cpg_info by inserting a blank line before
.has_clk_mon_regs
* Replaced r9a07g044_critical_resets->r9a07g044_crit_resets,
r9a08g045_critical_resets->r9a08g045_crit_resets and
r9a08g046_critical_resets->r9a08g046_crit_resets for consistency
* RZ/V2M has critical clocks but no mstop, so move the mstop check after
enabling critical clocks. After this, we need to restore only mstop for
module clocks, so remove the inverted logic and continue statement and
directly call rzg2l_mod_clock_init_mstop_helper() if the clock has
mstop.
v5->v6:
* Collected tags
* Moved loop variable declaration inside for loops in
__rzg2l_cpg_assert() and rzg2l_cpg_deassert_crit_resets()
* Replaced r9a07g043_critical_resets[] -> r9a07g043_crit_resets[] for
consistency
* Introduced rzg2l_mod_clock_init_mstop_helper() for code reuse
in probe() and resume().
* Dropped the list implementation.
* Replaced rzg2l_mod_clock_init_mstop->rzg2l_mod_enable_crit_clock_init_mstop()
for enabling critical clks and restoring mstop state during resume.
* Dropped dma-ranges, bus-range and comment from the pcie device node
v4->v5:
* Rebased to next-20260317.
v3->v4:
* Dropped SoC identification patches as it is accepted for renesas-devel.
* Updated commit description related to core clocks section in the
hardware manual
* Dropped CLK_P4_DIV2 from core clocks
* Added MIPI_DSI_PLLCLK and USB_SCLK to core clocks
* Dropped LVDS_PCLK module clock
* Added BSC_X_PRESET_BSC reset
* Moved the patch series from [1] to here as it is boot-dependent.
* Updated commit description
* Updated LAST_DT_CORE_CLK with R9A08G046_USB_SCLK
* Fixed typo 2->8 in dtable_4_128[].
* Added critical reset table r9a08g046_critical_resets[]
* Updated num_resets
* Added crit_resets and num_crit_resets to r9a08g046_cpg_info.
* Fixed typo R0A08G046L->R9A08G046L in commit description
* Dropped R9A08G046L46 from commit description
* Dropped unused audio_clk{1,2} andcan_clk device nodes
* Reordered i2c device node and updated reg entries by using lower-case
hexadecimal number
* Added placeholder in pinctrl node
* Dropped unused DMAC device node
* Added pcie node with placeholder
* Collected the tags.
* Updated commit description for patch#8
[1] https://lore.kernel.org/all/20260306134228.871815-1-biju.das.jz@bp.renesas.com/
v2->v3:
* Added macros R9A08G046_ETH{0,1}_CLK_{TX,RX}_I_RMII in r9a08g046-cpg.h.
* Keep the tag from Conor as it is trivial change for just adding macros.
v1->v2:
* Dropped scif bindings patch as it is accepted.
* Collected tags.
* Squashed the patch#3 and #4
* Documented GE3D/VCP for all SoC variants
* Documented external ethernet clocks as it is a clock source for MUX
inside CPG
* Updated commit description for bindings.
* Keep the tag from Conor as it is trivial change for adding more
clks.
* Added CLK_ETH{0,1}_TXC_TX_CLK_IN and CLK_ETH{0,1}_RXC_RX_CLK_IN clocks
in clk table.
* Dropped R9A08G046_IA55_PCLK from critical clock list.
* Added external clocks eth{0,1}_txc_tx_clk and eth{0,1}_rxc_rx_clk
in soc dtsi as it needed for cpg as it is a clock source for mux.
* Updated cpg node.
* Dropped gpio.h header from SoM dtsi.
* Dropped scif node as it is already included in common platform
file.
Test logs:
/ # uname -r
7.0.0-rc5-next-20260323-g862cf6e2b2bf
/ # cat /sys/kernel/debug/mstop
MSTOP
clk -------------------------
clk_name cnt cnt off val shared
-------- ----- ----- ----- ------ ------
gic_gicclk 1 1 0xb6c 0x0
ia55_clk 1 1 0xb70 0x0 ia55_pclk ia55_clk
ia55_pclk 0 1 0xb70 0x0 ia55_pclk ia55_clk
dmac_aclk 1 1 0xb80 0x0
dmac_pclk 0 0 0xb80 0x8
scif0_clk_pck 2 1 0xb68 0x0
/ # echo enabled > /sys/class/tty/ttySC3/power/wakeup
/ # echo N > /sys/module/printk/parameters/console_suspend
/ # echo 7 > /proc/sys/kernel/printk
/ # echo freeze > /sys/power/state
[ 66.381552] PM: suspend entry (s2idle)
[ 66.385460] Filesystems sync: 0.000 seconds
[ 66.390461] Freezing user space processes
[ 66.394563] Freezing user space processes completed (elapsed 0.000 seconds)
[ 66.401515] OOM killer disabled.
[ 66.404731] Freezing remaining freezable tasks
[ 66.410340] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 72.270183] OOM killer enabled.
[ 72.273365] Restarting tasks: Starting
[ 72.277266] Restarting tasks: Done
[ 72.280780] PM: suspend exit
jfdngdf/ #
/ # cat /sys/kernel/debug/mstop
MSTOP
clk -------------------------
clk_name cnt cnt off val shared
-------- ----- ----- ----- ------ ------
gic_gicclk 1 1 0xb6c 0x0
ia55_clk 1 1 0xb70 0x0 ia55_pclk ia55_clk
ia55_pclk 0 1 0xb70 0x0 ia55_pclk ia55_clk
dmac_aclk 1 1 0xb80 0x0
dmac_pclk 0 0 0xb80 0x8
scif0_clk_pck 2 1 0xb68 0x0
/ #
/ # 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: 104 191 429 62 GICv3 27 Level arch_timer
14: 0 0 0 0 GICv3 418 Level 100ac000.serial:rx err
15: 4 0 0 0 GICv3 420 Level 100ac000.serial:rx full
16: 229 0 0 0 GICv3 421 Level 100ac000.serial:tx empty
17: 0 0 0 0 GICv3 419 Level 100ac000.serial:break
18: 17 0 0 0 GICv3 422 Level 100ac000.serial:rx ready
IPI0: 3 16 13 21 Rescheduling interrupts
IPI1: 315 240 180 217 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
Err: 0
/ # cat /proc/meminfo
MemTotal: 1887304 kB
MemFree: 1852164 kB
MemAvailable: 1819524 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
dmesg | grep r9a
[ 0.000000] Machine model: Renesas SMARC EVK version 2 based on r9a08g046l48
[ 0.066480] renesas-rz-sysc 11020000.system-controller: Detected Renesas RZ/G3L r9a08g046 Rev 0
Biju Das (11):
dt-bindings: clock: Document RZ/G3L SoC
clk: renesas: rzg2l-cpg: Add support for critical resets
clk: renesas: r9a07g04{3,4}/r9a08g045-cpg: Add critical reset entries
clk: renesas: rzg2l-cpg: Add helper for mod clock enable/disable
clk: renesas: rzg2l-cpg: Add rzg2l_mod_clock_init_mstop_helper()
clk: renesas: rzg2l-cpg: Re-enable critical module clocks during
resume
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 | 40 +-
arch/arm64/boot/dts/renesas/Makefile | 2 +
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 212 +++++++++++
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 37 ++
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 | 20 +
drivers/clk/renesas/Kconfig | 7 +-
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a07g043-cpg.c | 9 +
drivers/clk/renesas/r9a07g044-cpg.c | 13 +
drivers/clk/renesas/r9a08g045-cpg.c | 9 +
drivers/clk/renesas/r9a08g046-cpg.c | 153 ++++++++
drivers/clk/renesas/rzg2l-cpg.c | 91 ++++-
drivers/clk/renesas/rzg2l-cpg.h | 8 +
include/dt-bindings/clock/r9a08g046-cpg.h | 342 ++++++++++++++++++
17 files changed, 944 insertions(+), 27 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 include/dt-bindings/clock/r9a08g046-cpg.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2] tty: atmel_serial: update outdated reference to atmel_tasklet_func()
From: Greg KH @ 2026-03-24 7:58 UTC (permalink / raw)
To: Richard GENOUD
Cc: Kexin Sun, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-kernel, linux-serial, linux-arm-kernel,
julia.lawall, xutong.ma, yunbolyu, ratnadiraw
In-Reply-To: <89bc9543-9fcb-4563-b6ff-01b186231ce8@bootlin.com>
On Tue, Mar 24, 2026 at 08:08:40AM +0100, Richard GENOUD wrote:
> Le 24/03/2026 à 03:48, Kexin Sun a écrit :
> > The modem-status comparison that used irq_status_prev was
> > moved from atmel_tasklet_func() into atmel_handle_status() in
> > commit d033e82db9a5 ("tty/serial: at91: handle IRQ status
> > more safely"). Update the comment accordingly.
> Double space here, but I don't think it's necessary to send another
> iteration for that.
Double spaces are the "real way", so this is all good :)
^ permalink raw reply
* Re: [PATCH v2] tty: atmel_serial: update outdated reference to atmel_tasklet_func()
From: Richard GENOUD @ 2026-03-24 7:08 UTC (permalink / raw)
To: Kexin Sun, gregkh, jirislaby
Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea, linux-kernel,
linux-serial, linux-arm-kernel, julia.lawall, xutong.ma, yunbolyu,
ratnadiraw
In-Reply-To: <20260324024857.3244-1-kexinsun@smail.nju.edu.cn>
Le 24/03/2026 à 03:48, Kexin Sun a écrit :
> The modem-status comparison that used irq_status_prev was
> moved from atmel_tasklet_func() into atmel_handle_status() in
> commit d033e82db9a5 ("tty/serial: at91: handle IRQ status
> more safely"). Update the comment accordingly.
Double space here, but I don't think it's necessary to send another
iteration for that.
>
> Assisted-by: unnamed:deepseek-v3.2 coccinelle
> Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn>
Acked-by Richard Genoud <richard.genoud@bootlin.com>
> ---
> drivers/tty/serial/atmel_serial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 08dd8f887956..5d8c1cfc1c60 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1927,7 +1927,7 @@ static int atmel_startup(struct uart_port *port)
> atmel_uart_writel(port, ATMEL_US_FMR, fmr);
> }
>
> - /* Save current CSR for comparison in atmel_tasklet_func() */
> + /* Save current CSR for comparison in atmel_handle_status() */
> atmel_port->irq_status_prev = atmel_uart_readl(port, ATMEL_US_CSR);
>
> /*
Thanks!
^ permalink raw reply
* [tty:tty-testing] BUILD SUCCESS 6872c84dc6f5d18e02ebc34b257f4152895e236c
From: kernel test robot @ 2026-03-24 6:37 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: 6872c84dc6f5d18e02ebc34b257f4152895e236c Merge 7.0-rc5 into tty-next
elapsed time: 753m
configs tested: 170
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260324 gcc-8.5.0
arc randconfig-002-20260324 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260324 gcc-8.5.0
arm randconfig-002-20260324 gcc-8.5.0
arm randconfig-003-20260324 gcc-8.5.0
arm randconfig-004-20260324 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260324 gcc-13.4.0
arm64 randconfig-002-20260324 gcc-13.4.0
arm64 randconfig-003-20260324 gcc-13.4.0
arm64 randconfig-004-20260324 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260324 gcc-13.4.0
csky randconfig-002-20260324 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260324 gcc-11.5.0
hexagon randconfig-002-20260324 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260324 gcc-12
i386 buildonly-randconfig-002-20260324 gcc-12
i386 buildonly-randconfig-003-20260324 gcc-12
i386 buildonly-randconfig-004-20260324 gcc-12
i386 buildonly-randconfig-005-20260324 gcc-12
i386 buildonly-randconfig-006-20260324 gcc-12
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260324 clang-20
i386 randconfig-002-20260324 clang-20
i386 randconfig-003-20260324 clang-20
i386 randconfig-004-20260324 clang-20
i386 randconfig-005-20260324 clang-20
i386 randconfig-006-20260324 clang-20
i386 randconfig-007-20260324 clang-20
i386 randconfig-011-20260324 gcc-13
i386 randconfig-012-20260324 gcc-13
i386 randconfig-013-20260324 gcc-13
i386 randconfig-014-20260324 gcc-13
i386 randconfig-015-20260324 gcc-13
i386 randconfig-016-20260324 gcc-13
i386 randconfig-017-20260324 gcc-13
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260324 gcc-11.5.0
loongarch randconfig-002-20260324 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips mtx1_defconfig clang-23
mips rb532_defconfig clang-18
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260324 gcc-11.5.0
nios2 randconfig-002-20260324 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260324 gcc-8.5.0
parisc randconfig-002-20260324 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260324 gcc-8.5.0
powerpc randconfig-002-20260324 gcc-8.5.0
powerpc storcenter_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260324 gcc-8.5.0
powerpc64 randconfig-002-20260324 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260324 clang-23
riscv randconfig-002-20260324 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260324 clang-23
s390 randconfig-002-20260324 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260324 clang-23
sh randconfig-002-20260324 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260324 gcc-14
sparc randconfig-002-20260324 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260324 gcc-14
sparc64 randconfig-002-20260324 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260324 gcc-14
um randconfig-002-20260324 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260324 gcc-14
x86_64 buildonly-randconfig-002-20260324 gcc-14
x86_64 buildonly-randconfig-003-20260324 gcc-14
x86_64 buildonly-randconfig-004-20260324 gcc-14
x86_64 buildonly-randconfig-005-20260324 gcc-14
x86_64 buildonly-randconfig-006-20260324 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260324 clang-20
x86_64 randconfig-002-20260324 clang-20
x86_64 randconfig-003-20260324 clang-20
x86_64 randconfig-004-20260324 clang-20
x86_64 randconfig-005-20260324 clang-20
x86_64 randconfig-006-20260324 clang-20
x86_64 randconfig-011-20260324 gcc-14
x86_64 randconfig-012-20260324 gcc-14
x86_64 randconfig-013-20260324 gcc-14
x86_64 randconfig-014-20260324 gcc-14
x86_64 randconfig-015-20260324 gcc-14
x86_64 randconfig-016-20260324 gcc-14
x86_64 randconfig-071-20260324 gcc-12
x86_64 randconfig-072-20260324 gcc-12
x86_64 randconfig-073-20260324 gcc-12
x86_64 randconfig-074-20260324 gcc-12
x86_64 randconfig-075-20260324 gcc-12
x86_64 randconfig-076-20260324 gcc-12
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260324 gcc-14
xtensa randconfig-002-20260324 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] tty: atmel_serial: update outdated reference to atmel_tasklet_func()
From: Kexin Sun @ 2026-03-24 2:48 UTC (permalink / raw)
To: gregkh, jirislaby
Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea, richard.genoud,
linux-kernel, linux-serial, linux-arm-kernel, julia.lawall,
xutong.ma, yunbolyu, ratnadiraw, Kexin Sun
In-Reply-To: <3bd295ee-1607-49db-a12e-5a4d4fc81c5c@bootlin.com>
The modem-status comparison that used irq_status_prev was
moved from atmel_tasklet_func() into atmel_handle_status() in
commit d033e82db9a5 ("tty/serial: at91: handle IRQ status
more safely"). Update the comment accordingly.
Assisted-by: unnamed:deepseek-v3.2 coccinelle
Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn>
---
drivers/tty/serial/atmel_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 08dd8f887956..5d8c1cfc1c60 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1927,7 +1927,7 @@ static int atmel_startup(struct uart_port *port)
atmel_uart_writel(port, ATMEL_US_FMR, fmr);
}
- /* Save current CSR for comparison in atmel_tasklet_func() */
+ /* Save current CSR for comparison in atmel_handle_status() */
atmel_port->irq_status_prev = atmel_uart_readl(port, ATMEL_US_CSR);
/*
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] n_tty: add null check for tty->link in packet mode
From: Osama Abdelkader @ 2026-03-23 20:39 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Jiri Slaby, linux-kernel, linux-serial
In-Reply-To: <2026031501-recolor-runaround-0ed5@gregkh>
On Sun, Mar 15, 2026 at 07:57:53AM +0100, Greg Kroah-Hartman wrote:
> On Sat, Mar 14, 2026 at 11:10:44PM +0100, Osama Abdelkader wrote:
> > Add null check for tty->link before dereferencing in n_tty_read and
> > n_tty_poll. When the pty master closes, tty->link can be NULL while
> > the slave is still reading, causing a null pointer dereference.
>
> How can that happen?
>
> > Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> > ---
> > drivers/tty/n_tty.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> > index e6a0f5b40d0a..dc04b87364f6 100644
> > --- a/drivers/tty/n_tty.c
> > +++ b/drivers/tty/n_tty.c
> > @@ -2232,7 +2232,7 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct file *file, u8 *kbuf,
> > add_wait_queue(&tty->read_wait, &wait);
> > while (nr) {
> > /* First test for status change. */
> > - if (packet && tty->link->ctrl.pktstatus) {
> > + if (packet && tty->link && tty->link->ctrl.pktstatus) {
> > u8 cs;
> > if (kb != kbuf)
> > break;
> > @@ -2444,7 +2444,7 @@ static __poll_t n_tty_poll(struct tty_struct *tty, struct file *file,
> > if (input_available_p(tty, 1))
> > mask |= EPOLLIN | EPOLLRDNORM;
> > }
> > - if (tty->ctrl.packet && tty->link->ctrl.pktstatus)
> > + if (tty->ctrl.packet && tty->link && tty->link->ctrl.pktstatus)
>
> What happens if link changes right after you test it? Where is the
> lock?
>
> And what changed to cause this to show up now?
>
> thanks,
>
> greg k-h
Hi Greg,
I was just thinking about null dereferencing possiblity in tty->link->ctrl.pktstatus. But, you are right
It’s reasonable to drop this patch and reopen it only if I get a solid reproducer or bug report.
BR,
Osama
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Mark Pearson @ 2026-03-23 17:23 UTC (permalink / raw)
To: Manivannan Sadhasivam, Dmitry Baryshkov
Cc: Rob Herring, Manivannan Sadhasivam, Greg KH, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Derek J . Clark, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86@vger.kernel.org, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
linux-acpi@vger.kernel.org
In-Reply-To: <m44mupdmg7kgco62n4evcviagqo7wwgyt3gybugbxwesd4ekjz@o24r6v4tpezc>
On Mon, Mar 23, 2026, at 12:52 PM, Manivannan Sadhasivam wrote:
> On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
>> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
>> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
>> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
>> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
>> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>> > > > > >
>> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
>> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
>> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
>> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
>> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
>> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
>> > > > > > > > to reuse the Key E binding.
>> > > > > > >
>> > > > > > > What is LGA?
>> > > > > > >
>> > > > > >
>> > > > > > Land Grid Array
>> > > > > >
>> > > > > > > If not in the spec, is it really something generic?
>> > > > > > >
>> > > > > >
>> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
>> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
>> > > > > > the spec gives room for hardware designers to be as innovative as possible to
>> > > > > > save the BOM cost.
>> > > > >
>> > > > > innovation == incompatible changes
>> > > > >
>> > > >
>> > > > Yes, I was trying to sound nice :)
>> > > >
>> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
>> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
>> > > > >
>> > > > > Depends if you think that s/w needs to know the differences. Hard to
>> > > > > say with a sample size of 1.
>> > > > >
>> > > >
>> > > > Sure. Will add the 'lenovo' prefix then.
>> > >
>> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
>> > > being used by Lenovo?
>> > >
>> > > I remember that DB820c also used some kind of a module for the WiFi card
>> > > (which might be M.2 compatible or might not, I can't find exact docs at
>> > > this point).
>> > >
>> >
>> > I don't know. These kind of designs might be reused by several vendors. But
>> > considering that we should not make it generic, I'd go with Lenovo as that's
>> > the only vendor we know as of now.
>>
>> ... and later we learn that other vendors use the same idea /pinout,
>> then nothing stops us from still telling that it's a
>> "lenovo,pcie-m2-something-lga".
>>
>
> How do you possibly know whether a single vendor has introduced this form factor
> or reused by multiple ones? Atleast, I don't have access to such a source to
> confirm.
>
I've not really been following this thread/patchset in detail; but want me to try and check with the T14s platform team if this device is specifically made for us (Lenovo) or not?
I doubt it is - we just don't do that usually, but I can go and ask the question if it will help resolve this (with the caveat that it could hold up the review for a bit and I may not be able to get a straight answer)
My vote (for what little it's worth) would be to make it non-Lenovo specific. Then when the same part causes issues on another vendors platform I won't get asked questions about why Lenovo is breaking <other vendor> :)
Mark
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-03-23 16:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, 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, linux-acpi
In-Reply-To: <blhm4csjyw6r667cleljgzd6rpwagttjo5rau7wjrlnjakq2qm@ekyhc4jvwmwf>
On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > >
> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > > > > > to reuse the Key E binding.
> > > > > > >
> > > > > > > What is LGA?
> > > > > > >
> > > > > >
> > > > > > Land Grid Array
> > > > > >
> > > > > > > If not in the spec, is it really something generic?
> > > > > > >
> > > > > >
> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > > > > the spec gives room for hardware designers to be as innovative as possible to
> > > > > > save the BOM cost.
> > > > >
> > > > > innovation == incompatible changes
> > > > >
> > > >
> > > > Yes, I was trying to sound nice :)
> > > >
> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > > > >
> > > > > Depends if you think that s/w needs to know the differences. Hard to
> > > > > say with a sample size of 1.
> > > > >
> > > >
> > > > Sure. Will add the 'lenovo' prefix then.
> > >
> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> > > being used by Lenovo?
> > >
> > > I remember that DB820c also used some kind of a module for the WiFi card
> > > (which might be M.2 compatible or might not, I can't find exact docs at
> > > this point).
> > >
> >
> > I don't know. These kind of designs might be reused by several vendors. But
> > considering that we should not make it generic, I'd go with Lenovo as that's
> > the only vendor we know as of now.
>
> ... and later we learn that other vendors use the same idea /pinout,
> then nothing stops us from still telling that it's a
> "lenovo,pcie-m2-something-lga".
>
How do you possibly know whether a single vendor has introduced this form factor
or reused by multiple ones? Atleast, I don't have access to such a source to
confirm.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Dmitry Baryshkov @ 2026-03-23 16:45 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Rob Herring, 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, linux-acpi
In-Reply-To: <bguhzabwryayyqkv4ilzwr3ixwv6bzxncblo3ircz2wm3fs52k@66zvcrfcb4oe>
On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >
> > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > > > > to reuse the Key E binding.
> > > > > >
> > > > > > What is LGA?
> > > > > >
> > > > >
> > > > > Land Grid Array
> > > > >
> > > > > > If not in the spec, is it really something generic?
> > > > > >
> > > > >
> > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > > > the spec gives room for hardware designers to be as innovative as possible to
> > > > > save the BOM cost.
> > > >
> > > > innovation == incompatible changes
> > > >
> > >
> > > Yes, I was trying to sound nice :)
> > >
> > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > > >
> > > > Depends if you think that s/w needs to know the differences. Hard to
> > > > say with a sample size of 1.
> > > >
> > >
> > > Sure. Will add the 'lenovo' prefix then.
> >
> > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> > being used by Lenovo?
> >
> > I remember that DB820c also used some kind of a module for the WiFi card
> > (which might be M.2 compatible or might not, I can't find exact docs at
> > this point).
> >
>
> I don't know. These kind of designs might be reused by several vendors. But
> considering that we should not make it generic, I'd go with Lenovo as that's
> the only vendor we know as of now.
... and later we learn that other vendors use the same idea /pinout,
then nothing stops us from still telling that it's a
"lenovo,pcie-m2-something-lga".
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-03-23 15:56 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, 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, linux-acpi
In-Reply-To: <fsvmmgoe5wslmxebhrrwmdg2ldcmhzvj53gjkdfnfg2m2rz2lw@dcfboaakz7ae>
On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > >
> > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > > > to reuse the Key E binding.
> > > > >
> > > > > What is LGA?
> > > > >
> > > >
> > > > Land Grid Array
> > > >
> > > > > If not in the spec, is it really something generic?
> > > > >
> > > >
> > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > > the spec gives room for hardware designers to be as innovative as possible to
> > > > save the BOM cost.
> > >
> > > innovation == incompatible changes
> > >
> >
> > Yes, I was trying to sound nice :)
> >
> > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > >
> > > Depends if you think that s/w needs to know the differences. Hard to
> > > say with a sample size of 1.
> > >
> >
> > Sure. Will add the 'lenovo' prefix then.
>
> Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> being used by Lenovo?
>
> I remember that DB820c also used some kind of a module for the WiFi card
> (which might be M.2 compatible or might not, I can't find exact docs at
> this point).
>
I don't know. These kind of designs might be reused by several vendors. But
considering that we should not make it generic, I'd go with Lenovo as that's
the only vendor we know as of now.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Dmitry Baryshkov @ 2026-03-23 15:14 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Rob Herring, 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, linux-acpi
In-Reply-To: <6aef3xxjjd4nbgrfx6jc6jt6rpqmttoui6hil5zqgdpas2j6gj@ie6j72orenou>
On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > > to reuse the Key E binding.
> > > >
> > > > What is LGA?
> > > >
> > >
> > > Land Grid Array
> > >
> > > > If not in the spec, is it really something generic?
> > > >
> > >
> > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > the spec gives room for hardware designers to be as innovative as possible to
> > > save the BOM cost.
> >
> > innovation == incompatible changes
> >
>
> Yes, I was trying to sound nice :)
>
> > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> >
> > Depends if you think that s/w needs to know the differences. Hard to
> > say with a sample size of 1.
> >
>
> Sure. Will add the 'lenovo' prefix then.
Is it really Lenovo? Or is it some other module vendor, whose LGAs are
being used by Lenovo?
I remember that DB820c also used some kind of a module for the WiFi card
(which might be M.2 compatible or might not, I can't find exact docs at
this point).
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-03-23 13:44 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: <CAL_JsqJXrHCJt770bJkMmAUhirSF3kHjYwSzkG7cXp7-eys8Rg@mail.gmail.com>
On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > to reuse the Key E binding.
> > >
> > > What is LGA?
> > >
> >
> > Land Grid Array
> >
> > > If not in the spec, is it really something generic?
> > >
> >
> > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > vendors may also use this form factor. PCIe connectors are full of innovation as
> > the spec gives room for hardware designers to be as innovative as possible to
> > save the BOM cost.
>
> innovation == incompatible changes
>
Yes, I was trying to sound nice :)
> > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > can name it as "lenovo,pcie-m2-1620-lga-connector".
>
> Depends if you think that s/w needs to know the differences. Hard to
> say with a sample size of 1.
>
Sure. Will add the 'lenovo' prefix then.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Rob Herring @ 2026-03-23 13:39 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: <to2mrizprc3hjufqbiplpqyek7f4uutqtn4hx4gkmdgv2rykbc@ybwwjhdec4nm>
On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > to reuse the Key E binding.
> >
> > What is LGA?
> >
>
> Land Grid Array
>
> > If not in the spec, is it really something generic?
> >
>
> Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> vendors may also use this form factor. PCIe connectors are full of innovation as
> the spec gives room for hardware designers to be as innovative as possible to
> save the BOM cost.
innovation == incompatible changes
> This is why I do not want to make it Lenovo specific. But if you prefer that, I
> can name it as "lenovo,pcie-m2-1620-lga-connector".
Depends if you think that s/w needs to know the differences. Hard to
say with a sample size of 1.
Rob
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-03-23 12:16 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: <20260322233713.GA98177-robh@kernel.org>
On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > spec, it looks very similar to the M.2 Key E connector. So add the
> > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > to reuse the Key E binding.
>
> What is LGA?
>
Land Grid Array
> If not in the spec, is it really something generic?
>
Good question. Yes and No! LGA is not something that Lenovo only uses. Other
vendors may also use this form factor. PCIe connectors are full of innovation as
the spec gives room for hardware designers to be as innovative as possible to
save the BOM cost.
This is why I do not want to make it Lenovo specific. But if you prefer that, I
can name it as "lenovo,pcie-m2-1620-lga-connector".
- Mani
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > .../devicetree/bindings/connector/pcie-m2-e-connector.yaml | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > index f7859aa9b634..d8cf9a9ec7d0 100644
> > --- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > @@ -17,7 +17,14 @@ description:
> >
> > properties:
> > compatible:
> > - const: pcie-m2-e-connector
> > + oneOf:
> > + - items:
> > + - enum:
> > + - pcie-m2-1620-lga-connector
> > + - const: pcie-m2-e-connector
> > + - items:
> > + - enum:
> > + - pcie-m2-e-connector
> >
> > vpcie3v3-supply:
> > description: A phandle to the regulator for 3.3v supply.
> >
> > --
> > 2.51.0
> >
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] tty: atmel_serial: update outdated reference to atmel_tasklet_func()
From: Richard GENOUD @ 2026-03-23 9:29 UTC (permalink / raw)
To: Kexin Sun, gregkh, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-kernel, linux-serial, linux-arm-kernel
Cc: julia.lawall, xutong.ma, yunbolyu, ratnadiraw
In-Reply-To: <20260321105956.8401-1-kexinsun@smail.nju.edu.cn>
Le 21/03/2026 à 11:59, Kexin Sun a écrit :
> The modem-status comparison that used irq_status_prev was
> moved from atmel_tasklet_func() into atmel_handle_status() in
> commit 2c7af5ba65cf ("tty: serial: atmel: rework interrupt and
> wakeup handling"). atmel_tasklet_func() itself was later split
> into atmel_tasklet_rx_func() and atmel_tasklet_tx_func() in
> commit 00e8e65870cc ("tty/serial: atmel: split tx and rx
> paths"). Update the comment to reference
> atmel_handle_status(), which now performs the comparison.
Actually, it was in commit:
d033e82db9a5 ("tty/serial: at91: handle IRQ status more safely")
That irq_status prev/actual comparison was moved from
atmel_tasklet_func() to atmel_handle_status().
And we don't need the rx/tx tasklet splitting history there.
IHMO, only the last sentence should suffice, but now that I've done the
right commit research, you may add a reference to it :)
>
> Assisted-by: unnamed:deepseek-v3.2 coccinelle
> Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn>
> ---
> drivers/tty/serial/atmel_serial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 08dd8f887956..5d8c1cfc1c60 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1927,7 +1927,7 @@ static int atmel_startup(struct uart_port *port)
> atmel_uart_writel(port, ATMEL_US_FMR, fmr);
> }
>
> - /* Save current CSR for comparison in atmel_tasklet_func() */
> + /* Save current CSR for comparison in atmel_handle_status() */
> atmel_port->irq_status_prev = atmel_uart_readl(port, ATMEL_US_CSR);
>
> /*
Thanks!
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Rob Herring @ 2026-03-22 23:37 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Andy Shevchenko, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi
In-Reply-To: <20260317-pci-m2-e-v6-6-9c898f108d3d@oss.qualcomm.com>
On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> spec, it looks very similar to the M.2 Key E connector. So add the
> "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> to reuse the Key E binding.
What is LGA?
If not in the spec, is it really something generic?
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> .../devicetree/bindings/connector/pcie-m2-e-connector.yaml | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> index f7859aa9b634..d8cf9a9ec7d0 100644
> --- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> @@ -17,7 +17,14 @@ description:
>
> properties:
> compatible:
> - const: pcie-m2-e-connector
> + oneOf:
> + - items:
> + - enum:
> + - pcie-m2-1620-lga-connector
> + - const: pcie-m2-e-connector
> + - items:
> + - enum:
> + - pcie-m2-e-connector
>
> vpcie3v3-supply:
> description: A phandle to the regulator for 3.3v supply.
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write
From: Haocheng Yu @ 2026-03-22 7:32 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Pitre, linux-kernel, linux-serial,
Calixte Pernot
In-Reply-To: <2026032123-earplugs-stunning-0c6f@gregkh>
I only ran my fuzzer on v6.18, so I'm unsure what commit caused the issue.
I tried analyzing the cause, but the crash report provided limited information.
I tried directly analyzing the code, but a possible race condition
with vc_do_resize()
is unlikely due to the console_lock, and the state.x out-of-bounds
issue is invalidated
by the restrictions in gotoxy(). Furthermore, no reproducer were
provided, making it
difficult to verify some of my hypotheses.
My initial thought was that although the specific cause was uncertain,
since scr_writew()
causes slab-out-of-bounds writes, adding a check before scr_writew()
would solve the
problem. After reading your explanation, I realize my thinking was
quite naive. Therefore,
I think I may not be able to provide a better patch at the moment.
Please ignore this patch.
BTW, I ran `./scripts/checkpatch.pl --strict` indeed, but it didn't
warn me about the variable
created. I'll pay attention next time.
Anyway, thanks for reviewing my patch.
Best regards,
Haocheng
> What commit caused this problem to show up?
>
> And without more information, or a reproducer, I'm a bit loath to take
> this change.
>
> > ---
> > drivers/tty/vt/vt.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index 6e0089b85c27..95d860f09837 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -3138,6 +3138,13 @@ static int vc_con_write_normal(struct vc_data *vc, int tc, int c,
> > (tc & 0xff);
> > tc |= (vc_attr << 8) & ~himask;
> >
> > + unsigned long end = vc->vc_origin + vc->vc_screenbuf_size;
>
> Ideally do not create new variables in the middle of a function,
> checkpatch should have warned about this.
>
> > +
> > + if (WARN_ON_ONCE(vc->vc_screenbuf_size < 2 ||
> > + end < vc->vc_origin ||
> > + vc->vc_pos < vc->vc_origin ||
> > + vc->vc_pos > end - 2))
>
> That's not good, if panic-on-warn is enabled, as it is in a few billion
> Linux systems, you just rebooted the machine, turning a simple overwrite
> into a denial-of-service, not fixing anything at all, but making it
> worse :(
>
> > + return -1;
>
> Do not make up error numbers :(
>
> thanks,
>
> greg k-h
^ 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