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

[Herve Codina <herve.codina@bootlin.com>]

Hi Andy, Manivannan,

On Mon, 12 Jan 2026 10:18:41 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

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

Related to LAN966x support, I am still stucked on issues related to
fw_devlink and DT overlays [1].

[1] https://lore.kernel.org/all/20260112154731.6540453b@bootlin.com/

> 
> On Mon, Jan 12, 2026 at 10:04:24AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay wrote:  
> > > Hi,
> > > 
> > > This series is the continuation of the series [1] that added the initial support
> > > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > > connectors. These connectors are used to connect the Wireless Connectivity
> > > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > > interfaces are left for future improvements.

Related to describing a connector in DT. If DT overlays are involved to described
what is connected to this connector, some issues need to be fixed.

Those issues are related to referencing an external symbol from the overlay.

We, at Boolin, have been working on the topic

A talk (last year at ELC Europe) gives all details about the topic an related issue:
  https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
  https://www.youtube.com/watch?v=C8dEQ4OzMnc

Also a discussion took place after this talk:
  https://lore.kernel.org/all/20250902105710.00512c6d@booty/

Recently, I also send a RFC series to DTC in order to move forward on this symbol
reverence topic. This series implements features emerged from the pointed out
discussion.

> > > 
> > > Serdev device support for BT
> > > ============================
> > > 
> > > Adding support for the PCIe interface was mostly straightforward and a lot
> > > similar to the previous Key M connector. But adding UART interface has proved to
> > > be tricky. This is mostly because of the fact UART is a non-discoverable bus,
> > > unlike PCIe which is discoverable. So this series relied on the PCI notifier to
> > > create the serdev device for UART/BT. This means the PCIe interface will be
> > > brought up first and after the PCIe device enumeration, the serdev device will
> > > be created by the pwrseq driver. This logic is necessary since the connector
> > > driver and DT node don't describe the device, but just the connector. So to make
> > > the connector interface Plug and Play, the connector driver uses the PCIe device
> > > ID to identify the card and creates the serdev device. This logic could be
> > > extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
> > > interface for connecting WLAN, a SDIO notifier could be added to create the
> > > serdev device.
> > > 
> > > Open questions
> > > ==============
> > > 
> > > Though this series adds the relevant functionality for handling the M.2 Key M
> > > connectors, there are still a few open questions exists on the design. 
> > > 
> > > 1. I've used the DT compatible for the serdev swnode to match the existing OF
> > > device_id of the bluetooth driver. This avoids implementing custom serdev id
> > > matching as implemented till v2.  
> > 
> > Yeah, swnodes are not designed to replace the real DT or other firmware
> > interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> > fixing up the broken or missed FW device properties). This should not have been
> > done this way. Please, consider another approach, e.g. DT-overlay.  
> 
> This is what I have in mind when replied to you:
> 
> https://lore.kernel.org/all/20251015071420.1173068-1-herve.codina@bootlin.com/
> 
> > > 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> > > the PCIe device DT node to extract properties such as
> > > 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> > > add the PCIe DT node in the Root Port in conjunction with the Port node as
> > > below?
> > > 
> > > pcie@0 {
> > > 	wifi@0 {
> > > 		compatible = "pci17cb,1103";
> > > 		...
> > > 		qcom,calibration-variant = "LE_X13S";
> > > 	};
> > > 
> > > 	port {
> > > 		pcie4_port0_ep: endpoint {
> > > 			remote-endpoint = <&m2_e_pcie_ep>;
> > > 		};
> > > 	};
> > > };

Using mechanisms used by the LAN966x, those wifi@0 and port nodes could be added by
a DT overlay by the PCI device driver handling the Qcom QCA6390 PCI device.

Best regards,
Hervé