Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree

[Chen-Yu Tsai]

On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
>
> [Resending as my previous reply got bounced]
>
> On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > Hi,
> > >
> > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam 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.
> > >
> > > Thanks for working on this. I started playing with it now that it is in
> > > -next. The PCIe part works fine. I'm looking into how to fit the pwrseq
> > >
> > > A couple questions:
> > >
> > > - Given that this connector actually represents two devices, how do I
> > >   say I want the BT part to be a wakeup source, but not the WiFi part?
> > >   Does wakeup-source even work at this point?
> > >
> >
> > You can't use the DT property since the devices are not described in DT
> > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > wakeup.

I see. I think not being able to specify generic properties for the devices
on the connector is going to be a bit problematic. Another use case I have
requires specifying a bounce buffer / SWIOTLB for the PCIe WiFi card. The
PCIe controller does not have an IOMMU behind it.

> > > - Are there plans to do the SDIO part?
> > >
> >
> > No, not at the moment. Feel free to take it up if you have the hardware and
> > motivation :)

Ack. I think I still need to figure out what the plan is after mmc-pwrseq
is deprecated.

> > > - The matching done in the M.2 connector driver for pwrseq_get() seems a
> > >   bit naive. It simply checks if the remote device in the OF graph is
> > >   the same as the requesting device.
> > >
> > >   I think this would run into issues with USB hubs. If I have a USB hub
> > >   and two M.2 connectors, with both connectors connected to the same
> > >   hub, pwrseq_get() is going to always return only one of the instances.
> > >   This is because the USB hub has one device node with multiple OF graph
> > >   ports.
> > >
> >
> > Yeah, this is a known limitation. I'm trying to improve this part now and have
> > the WIP commits here: https://github.com/Mani-Sadhasivam/linux/tree/pwrseq-bt-en-fixes
> >
> > Once the merge window closes, I'll submit these.

I couldn't tell which commit would help with this.

In my head I think we would need to extend pwrseq_get() to add something
like an index parameter that the provider is free to interpret. The M.2
connector driver could interpret it as the USB port number on the remote
end.


Thanks
ChenYu