Messages in this thread |  | | Date | Tue, 25 Nov 2025 20:57:18 +0100 | | From | Stephan Gerhold <> | | Subject | Re: [PATCH v2 00/10] Add support for handling PCIe M.2 Key E connectors in devicetree |
| |
On Tue, Nov 25, 2025 at 08:15:04PM +0530, Manivannan Sadhasivam via B4 Relay wrote: > This series is the continuation of the series [1] that added the initial support > for the PCIe M.2 connectors. This series extends it by adding support for Key E > connectors. These connectors are used to connect the Wireless Connectivity > devices such as WiFi, BT, NFC and GNSS devices to the host machine over > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for > connectors that expose PCIe interface for WiFi and UART interface for BT. Other > interfaces are left for future improvements. > > 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 M.2 card model name as the serdev device name. This is found > out by comparing the PCIe VID:PID in the notifier. Is this approach acceptable? > I did not use the PID as the serdev name since it will vary if the SDIO > interface is used in the future. > > 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>; > }; > }; > }; > > This will also require marking the PMU supplies optional in the relevant ath > bindings for M.2 cards. > > 3. Some M.2 cards require specific power up sequence like delays between > regulator/GPIO and such. For instance, the WCN7850 card supported in this series > requires 50ms delay between powering up an interface and driving it. I've just > hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq > driver doesn't know anything about the device it is dealing with before powering > it ON, how should it handle the device specific power requirements? Should we > hardcode the device specific property in the connector node? But then, it will > no longer become a generic M.2 connector and sort of defeats the purpose of the > connector binding. > > I hope to address these questions with the help of the relevant subsystem > maintainers and the community. > > 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 M.2 > card connected over PCIe and UART. > > [2] https://github.com/Mani-Sadhasivam/linux/commit/acbee74a5c90fc8839bb7b6f326c677ee1c0d89c
Thanks for working on describing the M.2 connectors properly in the device tree!
I haven't had time to look into this in detail yet, but a quick look at the dt-bindings and examples looks good to me! Thanks for keeping the bindings as generic as possible.
I have a small nitpick for the specific example you have here: The Lenovo ThinkPad T14s does not actually have a "M.2 Mechanical Key E connector". If you look at a picture of the mainboard [1], the WLAN/BT module is "soldered-down" (look on the right, on the right side next to the large copper bracket). In the M.2 specification, "soldered-down" modules do not have a "key", they have a specific pinout that is followed (see section 5.4). The power sequencing etc and the set of pins is quite similar/the same though.
My notes (from a few months ago) suggest the T14s probably uses a non-standard M.2 Type 1620 LGA pinout. I don't remember the exact chain of thought behind that, but you can find similarly looking modules with this type, e.g. https://www.sparklan.com/product/wnsq-290be/. There is a 1620 *BGA* pinout in the M.2 specification, but a 1620 *LGA* pinout does not exist there. Interestingly, in the block diagram of the module in the link above this type is called *Q*M.2 1620 LGA 168 pin, as if this is some Qualcomm-specific form factor.
A real mechanical key E connector can be found e.g. in the X1E CRD, X1E Devkit, or I think some of the X1E-based HP laptops (would need to check which one exactly).
I'm not sure if it's really appropriate modeling the "soldered-down" variant as "Mechanical Key E connector" in the DT. We might need a separate compatible for this. Do you have any thoughts about that?
Thanks, Stephan
[1]: https://www.notebookcheck.com/fileadmin/_processed_/d/c/csm_DSC_0003_aadae1ddd2.jpg
|  |