Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

+Cc: Herve (btw, any news on LAN966x support?)

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.
> > 
> > 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>;
> > 		};
> > 	};
> > };
> > 
> > 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
> > 1620 LGA card connected over PCIe and UART.

-- 
With Best Regards,
Andy Shevchenko