Re: [PATCH 1/2] dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `vpcie3v3aux-supply` property describes a non-existent hardware feature on the M.2 Key E connector to work around a software policy.
--

commit 0268cb00caa35acacc055d760f1155866bebdf1d
Author: Sherry Sun <sherry.sun@nxp.com>

dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support

This commit adds a vpcie3v3aux-supply property to the M.2 Key E connector
binding. The commit message indicates this is added to support special
lifecycle handling for the regulator during system suspend.

> diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> --- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> @@ -25,6 +25,9 @@ properties:
>    vpcie1v8-supply:
>      description: A phandle to the regulator for VIO 1.8v supply.
>  
> +  vpcie3v3aux-supply:
> +    description: A phandle to the regulator for 3.3v AUX supply.
> +

[Severity: Medium]
Does this property model a physical hardware pin that actually exists in the
M.2 specification?

The PCI Express M.2 Specification does not define a separate 3.3Vaux power
rail; it only defines a single primary 3.3V supply alongside an optional 1.8V
VIO supply. The concept of 3.3Vaux existed in older standards like PCIe Mini
Card and standard PCIe CEM slots, but was removed in the M.2 standard.

Device tree bindings are expected to strictly model physical hardware rather
than software lifecycle policies. Adding a non-existent hardware pin to the
standard M.2 connector binding purely to instruct the driver to keep the
regulator enabled during system suspend pollutes the permanent device tree ABI.

Could the existing vpcie3v3-supply regulator instead be properly configured in
the board device tree using standard regulator suspend states (such as
regulator-state-mem), or could the host driver be made aware of the wake
requirements to leave the primary supply on?

>    i2c-parent:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description: I2C interface

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609033840.2006078-1-sherry.sun@oss.nxp.com?part=1