lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_Jsq+rOGUETwhPuzSsC6bhq1Q10k=pCRnZrnoDbCxVYV91YA@mail.gmail.com>
Date: Wed, 12 Nov 2025 15:07:29 -0600
From: Rob Herring <robh@...nel.org>
To: manivannan.sadhasivam@....qualcomm.com
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Hans de Goede <hansg@...nel.org>, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Mark Pearson <mpearson-lenovo@...ebb.ca>, "Derek J. Clark" <derekjohn.clark@...il.com>, 
	Manivannan Sadhasivam <mani@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Marcel Holtmann <marcel@...tmann.org>, Luiz Augusto von Dentz <luiz.dentz@...il.com>, 
	Bartosz Golaszewski <brgl@...ev.pl>, linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kbuild@...r.kernel.org, platform-driver-x86@...r.kernel.org, 
	linux-pci@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, linux-bluetooth@...r.kernel.org, 
	linux-pm@...r.kernel.org, Stephan Gerhold <stephan.gerhold@...aro.org>, 
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: Re: [PATCH 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree

On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@...nel.org> 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 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. Until then, this series is *not* mergeable as a
> whole.
>
> 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.
>
> [1] https://lore.kernel.org/linux-pci/20251108-pci-m2-v2-0-e8bc4d7bf42d@oss.qualcomm.com
> [2] https://github.com/Mani-Sadhasivam/linux/commit/d39b81b3ff1ecfb0d423b4da0771925d41648b5a
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
> ---
> Manivannan Sadhasivam (9):
>       serdev: Convert to_serdev_device() and to_serdev_controller() helpers to macros
>       serdev: Add serdev device based driver match support
>       serdev: Allow passing the serdev device name to serdev_device_add()
>       serdev: Add an API to find the serdev controller associated with the devicetree node
>       serdev: Add modalias support for serdev client devices
>       serdev: Skip registering serdev devices from DT is external connector is used
>       dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
>       Bluetooth: hci_qca: Add support for WCN7850 PCIe M.2 card
>       power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
>
>  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++
>  MAINTAINERS                                        |   1 +
>  drivers/bluetooth/hci_qca.c                        |  20 ++
>  drivers/platform/x86/dell/dell-uart-backlight.c    |   2 +-
>  .../x86/lenovo/yoga-tab2-pro-1380-fastcharger.c    |   2 +-
>  drivers/platform/x86/x86-android-tablets/core.c    |   2 +-
>  drivers/power/sequencing/Kconfig                   |   1 +
>  drivers/power/sequencing/pwrseq-pcie-m2.c          | 218 ++++++++++++++++++++-
>  drivers/tty/serdev/core.c                          |  77 +++++++-
>  include/linux/mod_devicetable.h                    |   8 +
>  include/linux/serdev.h                             |  25 ++-
>  scripts/mod/devicetable-offsets.c                  |   3 +
>  scripts/mod/file2alias.c                           |   8 +
>  13 files changed, 494 insertions(+), 27 deletions(-)
> ---
> base-commit: db81ec30672bb228cd7cd809edeeae661d621f2d

git show db81ec30672bb228cd7cd80
fatal: ambiguous argument 'db81ec30672bb228cd7cd80': unknown revision
or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

This series doesn't apply.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ