[PATCH 0/2] power: sequencing: pcie-m2: Add 3.3Vaux supply support

[PATCH 0/2] power: sequencing: pcie-m2: Add 3.3Vaux supply support

[Sherry Sun (OSS)]

From: Sherry Sun <sherry.sun@nxp.com>

3.3Vaux supply has different power lifecycle requirements compared to other
supplies like vpcie3v3. It must remain enabled during system suspend to
support PCIe L2 link state and wake-up mechanisms. This is a requirement
for devices that need to maintain PCIe link presence and support remote
wakeup while the system is suspended.

This patchset adds support for the 3.3Vaux supply by:

  1. Extending the PCIe M.2 E-key connector DT binding to include the
     optional vpcie3v3aux-supply property.

  2. Updating the PCIe M.2 power sequencing driver to handle vpcie3v3aux
     separately from other supplies, keeping it enabled across system
     suspend/resume cycles when present.

This has been tested on i.MX95 & i.MX943 EVK board with a NXP Wi-Fi/BT M.2
AW693 module that requires 3.3Vaux to remain active during suspend for
wake-up support.

Sherry Sun (2):
  dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support
  power: sequencing: pcie-m2: Add 3.3Vaux supply support

 .../connector/pcie-m2-e-connector.yaml        |  3 ++
 drivers/power/sequencing/pwrseq-pcie-m2.c     | 42 ++++++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletion(-)

-- 
2.50.1

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

[Sherry Sun (OSS)]

From: Sherry Sun <sherry.sun@nxp.com>

Add 3.3Vaux separately for special handling. This supply has a different
lifecycle - it must remain enabled during system suspend to support PCIe
L2 link state and wake-up mechanisms.

Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
 .../devicetree/bindings/connector/pcie-m2-e-connector.yaml     | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
index f7859aa9b634..381b2ba8c80d 100644
--- 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.
+
   i2c-parent:
     $ref: /schemas/types.yaml#/definitions/phandle
     description: I2C interface
-- 
2.50.1

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

[sashiko-bot]

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

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

[Krzysztof Kozlowski]

On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> 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.

Feels valid. Describe which pin on M2 connector are you representing.

Best regards,
Krzysztof

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

[Sherry Sun]

> On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> > 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.
> 
> Feels valid. Describe which pin on M2 connector are you representing.
> 

Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
Grounds.

PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
source, 3.3 V, is expected to be available during the system’s
stand-by/suspend state to support wake event processing on the
communications card.

But the current vpcie3v3-supply may be gated off during system suspend.
So I  tried to add vpcie3v3aux-supply to let this 3.3 V power source
always on for PCIe M.2 Key E connector. That means vpcie3v3aux-supply
and vpcie3v3-supply actually refer to the same 3.3 V power source.

@Mani, do you think this is reasonable? Or do you have any other better
solutions? Thanks!

Best Regards
Sherry

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

[Krzysztof Kozlowski]

On 10/06/2026 10:40, Sherry Sun wrote:
>> On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
>>> 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.
>>
>> Feels valid. Describe which pin on M2 connector are you representing.
>>
> 
> Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> Grounds.
> 
> PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> source, 3.3 V, is expected to be available during the system’s
> stand-by/suspend state to support wake event processing on the
> communications card.

Again:
Describe which pin on M2 connector are you representing.

Best regards,
Krzysztof

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

[Sherry Sun]

> On 10/06/2026 10:40, Sherry Sun wrote:
> >> On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> >>> 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.
> >>
> >> Feels valid. Describe which pin on M2 connector are you representing.
> >>
> >
> > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> > Grounds.
> >
> > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > source, 3.3 V, is expected to be available during the system’s
> > stand-by/suspend state to support wake event processing on the
> > communications card.
> 
> Again:
> Describe which pin on M2 connector are you representing.

Same pin with the vpcie3v3-supply property in current dt-binding.
So from Device tree bindings perspective, vpcie3v3aux looks not that
reasonable. I am wondering if there are better solutions to support this.

Best Regards
Sherry

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

[Manivannan Sadhasivam]

On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> > > 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.
> > 
> > Feels valid. Describe which pin on M2 connector are you representing.
> > 
> 
> Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> Grounds.
> 
> PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> source, 3.3 V, is expected to be available during the system’s
> stand-by/suspend state to support wake event processing on the
> communications card.
> 
> But the current vpcie3v3-supply may be gated off during system suspend.
> So I  tried to add vpcie3v3aux-supply to let this 3.3 V power source
> always on for PCIe M.2 Key E connector. That means vpcie3v3aux-supply
> and vpcie3v3-supply actually refer to the same 3.3 V power source.
> 
> @Mani, do you think this is reasonable? Or do you have any other better
> solutions? Thanks!
> 

There is no Vaux defined in the M.2 spec. So you cannot define that supply in
the binding. You can define the custom Vaux supply as a fixed regulator in DT
and mark it always on so that it is keeps supplying 3.3v to the card.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Sherry Sun]

> On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> > > > 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.
> > >
> > > Feels valid. Describe which pin on M2 connector are you representing.
> > >
> >
> > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> > Grounds.
> >
> > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > source, 3.3 V, is expected to be available during the system’s
> > stand-by/suspend state to support wake event processing on the
> > communications card.
> >
> > But the current vpcie3v3-supply may be gated off during system suspend.
> > So I  tried to add vpcie3v3aux-supply to let this 3.3 V power source
> > always on for PCIe M.2 Key E connector. That means vpcie3v3aux-supply
> > and vpcie3v3-supply actually refer to the same 3.3 V power source.
> >
> > @Mani, do you think this is reasonable? Or do you have any other
> > better solutions? Thanks!
> >
> 
> There is no Vaux defined in the M.2 spec. So you cannot define that supply in
> the binding. You can define the custom Vaux supply as a fixed regulator in DT
> and mark it always on so that it is keeps supplying 3.3v to the card.
> 

Hi Mani, thanks for the suggestion, but adding an always on regulator may
cause board power waste, current solution ensures the 3.3v regulator is
only enabled when M.2 connector needs to work .

Best Regards
Sherry

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

[Manivannan Sadhasivam]

On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> > > > > 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.
> > > >
> > > > Feels valid. Describe which pin on M2 connector are you representing.
> > > >
> > >
> > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> > > Grounds.
> > >
> > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > > source, 3.3 V, is expected to be available during the system’s
> > > stand-by/suspend state to support wake event processing on the
> > > communications card.
> > >
> > > But the current vpcie3v3-supply may be gated off during system suspend.
> > > So I  tried to add vpcie3v3aux-supply to let this 3.3 V power source
> > > always on for PCIe M.2 Key E connector. That means vpcie3v3aux-supply
> > > and vpcie3v3-supply actually refer to the same 3.3 V power source.
> > >
> > > @Mani, do you think this is reasonable? Or do you have any other
> > > better solutions? Thanks!
> > >
> > 
> > There is no Vaux defined in the M.2 spec. So you cannot define that supply in
> > the binding. You can define the custom Vaux supply as a fixed regulator in DT
> > and mark it always on so that it is keeps supplying 3.3v to the card.
> > 
> 
> Hi Mani, thanks for the suggestion, but adding an always on regulator may
> cause board power waste, current solution ensures the 3.3v regulator is
> only enabled when M.2 connector needs to work .
> 

What do you mean by 'need to work'? For getting the M.2 card to work, you
already have 3.3v supply. If you want the board to be always ON, then you need
to supply 3.3Vaux, which should be always ON too.

But who is turning off vpcie3v3-supply? M.2 connector driver or the platform?

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Sherry Sun]

> On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org
> wrote:
> > > > > > 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.
> > > > >
> > > > > Feels valid. Describe which pin on M2 connector are you representing.
> > > > >
> > > >
> > > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources
> > > > and Grounds.
> > > >
> > > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> > > > voltage source, 3.3 V, is expected to be available during the
> > > > system’s stand-by/suspend state to support wake event processing
> > > > on the communications card.
> > > >
> > > > But the current vpcie3v3-supply may be gated off during system
> suspend.
> > > > So I  tried to add vpcie3v3aux-supply to let this 3.3 V power
> > > > source always on for PCIe M.2 Key E connector. That means
> > > > vpcie3v3aux-supply and vpcie3v3-supply actually refer to the same 3.3 V
> power source.
> > > >
> > > > @Mani, do you think this is reasonable? Or do you have any other
> > > > better solutions? Thanks!
> > > >
> > >
> > > There is no Vaux defined in the M.2 spec. So you cannot define that
> > > supply in the binding. You can define the custom Vaux supply as a
> > > fixed regulator in DT and mark it always on so that it is keeps supplying
> 3.3v to the card.
> > >
> >
> > Hi Mani, thanks for the suggestion, but adding an always on regulator
> > may cause board power waste, current solution ensures the 3.3v
> > regulator is only enabled when M.2 connector needs to work .
> >
> 
> What do you mean by 'need to work'? For getting the M.2 card to work, you
> already have 3.3v supply. If you want the board to be always ON, then you
> need to supply 3.3Vaux, which should be always ON too.
> 
> But who is turning off vpcie3v3-supply? M.2 connector driver or the
> platform?
> 

Hi Mani,
I'm not sure if I understand your question correctly, actually it's the platform
driver that calls the M.2 connector driver to turn off vpcie3v3-supply.
Take i.MX pci device as an example, 
pm_suspend() -> imx_pcie_suspend_noirq() -> imx_pcie_host_exit() ->
pci_pwrctrl_power_off_devices() -> pwrseq_power_off() ->
pwrseq_unit_disable() -> pwrseq_pcie_m2_vregs_disable()

Taking back to M.2 Specification:
PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
voltage source, 3.3 V, is expected to be available during the
system’s stand-by/suspend state to support wake event processing
on the communications card.

Per my understanding of the above, the M.2 Spec actually suggest the
3.3 V power source should not be turned off.
Should we simply enable the 3.3 V power source in pwrseq_pcie_m2_probe()
and remove the pwrseq_pcie_m2_vregs_unit_data?

Best Regards
Sherry

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

[Manivannan Sadhasivam]

On Thu, Jun 11, 2026 at 03:59:28AM +0000, Sherry Sun wrote:
> > On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > > > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org
> > wrote:
> > > > > > > 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.
> > > > > >
> > > > > > Feels valid. Describe which pin on M2 connector are you representing.
> > > > > >
> > > > >
> > > > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources
> > > > > and Grounds.
> > > > >
> > > > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> > > > > voltage source, 3.3 V, is expected to be available during the
> > > > > system’s stand-by/suspend state to support wake event processing
> > > > > on the communications card.
> > > > >
> > > > > But the current vpcie3v3-supply may be gated off during system
> > suspend.
> > > > > So I  tried to add vpcie3v3aux-supply to let this 3.3 V power
> > > > > source always on for PCIe M.2 Key E connector. That means
> > > > > vpcie3v3aux-supply and vpcie3v3-supply actually refer to the same 3.3 V
> > power source.
> > > > >
> > > > > @Mani, do you think this is reasonable? Or do you have any other
> > > > > better solutions? Thanks!
> > > > >
> > > >
> > > > There is no Vaux defined in the M.2 spec. So you cannot define that
> > > > supply in the binding. You can define the custom Vaux supply as a
> > > > fixed regulator in DT and mark it always on so that it is keeps supplying
> > 3.3v to the card.
> > > >
> > >
> > > Hi Mani, thanks for the suggestion, but adding an always on regulator
> > > may cause board power waste, current solution ensures the 3.3v
> > > regulator is only enabled when M.2 connector needs to work .
> > >
> > 
> > What do you mean by 'need to work'? For getting the M.2 card to work, you
> > already have 3.3v supply. If you want the board to be always ON, then you
> > need to supply 3.3Vaux, which should be always ON too.
> > 
> > But who is turning off vpcie3v3-supply? M.2 connector driver or the
> > platform?
> > 
> 
> Hi Mani,
> I'm not sure if I understand your question correctly, actually it's the platform
> driver that calls the M.2 connector driver to turn off vpcie3v3-supply.
> Take i.MX pci device as an example, 
> pm_suspend() -> imx_pcie_suspend_noirq() -> imx_pcie_host_exit() ->
> pci_pwrctrl_power_off_devices() -> pwrseq_power_off() ->
> pwrseq_unit_disable() -> pwrseq_pcie_m2_vregs_disable()
> 
> Taking back to M.2 Specification:
> PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> voltage source, 3.3 V, is expected to be available during the
> system’s stand-by/suspend state to support wake event processing
> on the communications card.
> 
> Per my understanding of the above, the M.2 Spec actually suggest the
> 3.3 V power source should not be turned off.
> Should we simply enable the 3.3 V power source in pwrseq_pcie_m2_probe()
> and remove the pwrseq_pcie_m2_vregs_unit_data?
> 

Just don't call pci_pwrctrl_power_off_devices() from the suspend path.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Sherry Sun]

> On Thu, Jun 11, 2026 at 03:59:28AM +0000, Sherry Sun wrote:
> > > On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > > > > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000,
> > > > > > > sashiko-bot@kernel.org
> > > wrote:
> > > > > > > > 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.
> > > > > > >
> > > > > > > Feels valid. Describe which pin on M2 connector are you
> representing.
> > > > > > >
> > > > > >
> > > > > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power
> > > > > > Sources and Grounds.
> > > > > >
> > > > > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> > > > > > voltage source, 3.3 V, is expected to be available during the
> > > > > > system’s stand-by/suspend state to support wake event
> > > > > > processing on the communications card.
> > > > > >
> > > > > > But the current vpcie3v3-supply may be gated off during system
> > > suspend.
> > > > > > So I  tried to add vpcie3v3aux-supply to let this 3.3 V power
> > > > > > source always on for PCIe M.2 Key E connector. That means
> > > > > > vpcie3v3aux-supply and vpcie3v3-supply actually refer to the
> > > > > > same 3.3 V
> > > power source.
> > > > > >
> > > > > > @Mani, do you think this is reasonable? Or do you have any
> > > > > > other better solutions? Thanks!
> > > > > >
> > > > >
> > > > > There is no Vaux defined in the M.2 spec. So you cannot define
> > > > > that supply in the binding. You can define the custom Vaux
> > > > > supply as a fixed regulator in DT and mark it always on so that
> > > > > it is keeps supplying
> > > 3.3v to the card.
> > > > >
> > > >
> > > > Hi Mani, thanks for the suggestion, but adding an always on
> > > > regulator may cause board power waste, current solution ensures
> > > > the 3.3v regulator is only enabled when M.2 connector needs to work .
> > > >
> > >
> > > What do you mean by 'need to work'? For getting the M.2 card to
> > > work, you already have 3.3v supply. If you want the board to be
> > > always ON, then you need to supply 3.3Vaux, which should be always ON
> too.
> > >
> > > But who is turning off vpcie3v3-supply? M.2 connector driver or the
> > > platform?
> > >
> >
> > Hi Mani,
> > I'm not sure if I understand your question correctly, actually it's
> > the platform driver that calls the M.2 connector driver to turn off vpcie3v3-
> supply.
> > Take i.MX pci device as an example,
> > pm_suspend() -> imx_pcie_suspend_noirq() -> imx_pcie_host_exit() ->
> > pci_pwrctrl_power_off_devices() -> pwrseq_power_off() ->
> > pwrseq_unit_disable() -> pwrseq_pcie_m2_vregs_disable()
> >
> > Taking back to M.2 Specification:
> > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > source, 3.3 V, is expected to be available during the system’s
> > stand-by/suspend state to support wake event processing on the
> > communications card.
> >
> > Per my understanding of the above, the M.2 Spec actually suggest the
> > 3.3 V power source should not be turned off.
> > Should we simply enable the 3.3 V power source in
> > pwrseq_pcie_m2_probe() and remove the
> pwrseq_pcie_m2_vregs_unit_data?
> >
> 
> Just don't call pci_pwrctrl_power_off_devices() from the suspend path.
> 

Hi Mani, do you mean use dw_pcie_rp::skip_pwrctrl_off flag to avoid powering
off devices during suspend and also not power on the devices in the init path?

Best Regards
Sherry

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

[Manivannan Sadhasivam]

On Fri, Jun 12, 2026 at 10:52:10AM +0000, Sherry Sun wrote:
> > On Thu, Jun 11, 2026 at 03:59:28AM +0000, Sherry Sun wrote:
> > > > On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > > > > > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > > > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000,
> > > > > > > > sashiko-bot@kernel.org
> > > > wrote:
> > > > > > > > > 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.
> > > > > > > >
> > > > > > > > Feels valid. Describe which pin on M2 connector are you
> > representing.
> > > > > > > >
> > > > > > >
> > > > > > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power
> > > > > > > Sources and Grounds.
> > > > > > >
> > > > > > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> > > > > > > voltage source, 3.3 V, is expected to be available during the
> > > > > > > system’s stand-by/suspend state to support wake event
> > > > > > > processing on the communications card.
> > > > > > >
> > > > > > > But the current vpcie3v3-supply may be gated off during system
> > > > suspend.
> > > > > > > So I  tried to add vpcie3v3aux-supply to let this 3.3 V power
> > > > > > > source always on for PCIe M.2 Key E connector. That means
> > > > > > > vpcie3v3aux-supply and vpcie3v3-supply actually refer to the
> > > > > > > same 3.3 V
> > > > power source.
> > > > > > >
> > > > > > > @Mani, do you think this is reasonable? Or do you have any
> > > > > > > other better solutions? Thanks!
> > > > > > >
> > > > > >
> > > > > > There is no Vaux defined in the M.2 spec. So you cannot define
> > > > > > that supply in the binding. You can define the custom Vaux
> > > > > > supply as a fixed regulator in DT and mark it always on so that
> > > > > > it is keeps supplying
> > > > 3.3v to the card.
> > > > > >
> > > > >
> > > > > Hi Mani, thanks for the suggestion, but adding an always on
> > > > > regulator may cause board power waste, current solution ensures
> > > > > the 3.3v regulator is only enabled when M.2 connector needs to work .
> > > > >
> > > >
> > > > What do you mean by 'need to work'? For getting the M.2 card to
> > > > work, you already have 3.3v supply. If you want the board to be
> > > > always ON, then you need to supply 3.3Vaux, which should be always ON
> > too.
> > > >
> > > > But who is turning off vpcie3v3-supply? M.2 connector driver or the
> > > > platform?
> > > >
> > >
> > > Hi Mani,
> > > I'm not sure if I understand your question correctly, actually it's
> > > the platform driver that calls the M.2 connector driver to turn off vpcie3v3-
> > supply.
> > > Take i.MX pci device as an example,
> > > pm_suspend() -> imx_pcie_suspend_noirq() -> imx_pcie_host_exit() ->
> > > pci_pwrctrl_power_off_devices() -> pwrseq_power_off() ->
> > > pwrseq_unit_disable() -> pwrseq_pcie_m2_vregs_disable()
> > >
> > > Taking back to M.2 Specification:
> > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > > source, 3.3 V, is expected to be available during the system’s
> > > stand-by/suspend state to support wake event processing on the
> > > communications card.
> > >
> > > Per my understanding of the above, the M.2 Spec actually suggest the
> > > 3.3 V power source should not be turned off.
> > > Should we simply enable the 3.3 V power source in
> > > pwrseq_pcie_m2_probe() and remove the
> > pwrseq_pcie_m2_vregs_unit_data?
> > >
> > 
> > Just don't call pci_pwrctrl_power_off_devices() from the suspend path.
> > 
> 
> Hi Mani, do you mean use dw_pcie_rp::skip_pwrctrl_off flag to avoid powering
> off devices during suspend and also not power on the devices in the init path?
> 

Yes, something along those lines.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

[PATCH 2/2] power: sequencing: pcie-m2: Add 3.3Vaux supply support

[Sherry Sun (OSS)]

From: Sherry Sun <sherry.sun@nxp.com>

Add 3.3Vaux separately for special handling. This supply has a different
lifecycle - it must remain enabled during system suspend to support PCIe
L2 link state and wake-up mechanisms.

Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
 drivers/power/sequencing/pwrseq-pcie-m2.c | 42 ++++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index e82821655fc4..6b8c77cf20a9 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -37,6 +37,8 @@ struct pwrseq_pcie_m2_ctx {
 	const struct pwrseq_pcie_m2_pdata *pdata;
 	struct regulator_bulk_data *regs;
 	size_t num_vregs;
+	struct regulator *vaux_reg;
+	bool vaux_enabled;
 	struct notifier_block nb;
 	struct gpio_desc *w_disable1_gpio;
 	struct gpio_desc *w_disable2_gpio;
@@ -48,8 +50,23 @@ struct pwrseq_pcie_m2_ctx {
 static int pwrseq_pcie_m2_vregs_enable(struct pwrseq_device *pwrseq)
 {
 	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+	int ret;
+
+	/* Enable 3.3Vaux if present and not already enabled. */
+	if (ctx->vaux_reg && !ctx->vaux_enabled) {
+		ret = regulator_enable(ctx->vaux_reg);
+		if (ret)
+			return ret;
+		ctx->vaux_enabled = true;
+	}
 
-	return regulator_bulk_enable(ctx->num_vregs, ctx->regs);
+	ret = regulator_bulk_enable(ctx->num_vregs, ctx->regs);
+	if (ret && ctx->vaux_reg && ctx->vaux_enabled) {
+		regulator_disable(ctx->vaux_reg);
+		ctx->vaux_enabled = false;
+	}
+
+	return ret;
 }
 
 static int pwrseq_pcie_m2_vregs_disable(struct pwrseq_device *pwrseq)
@@ -497,10 +514,28 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, -ENODEV,
 				     "Failed to obtain platform data\n");
 
+	/*
+	 * Get 3.3Vaux separately for special handling. This supply has a
+	 * different lifecycle - it must remain enabled during system suspend
+	 * to support PCIe L2 link state and wake-up mechanisms.
+	 */
+	ctx->vaux_reg = devm_regulator_get_optional(dev, "vpcie3v3aux");
+	if (IS_ERR(ctx->vaux_reg)) {
+		if (PTR_ERR(ctx->vaux_reg) != -ENODEV)
+			return PTR_ERR(ctx->vaux_reg);
+		ctx->vaux_reg = NULL;
+	}
+	ctx->vaux_enabled = false;
+
 	/*
 	 * Currently, of_regulator_bulk_get_all() is the only regulator API that
 	 * allows to get all supplies in the devicetree node without manually
 	 * specifying them.
+	 *
+	 * This will include vaux again, but we'll manage it separately via
+	 * vaux_reg. The regulator framework handles multiple gets of the same
+	 * regulator correctly via refcounting, so having vaux in both places is
+	 * safe.
 	 */
 	ret = of_regulator_bulk_get_all(dev, dev_of_node(dev), &ctx->regs);
 	if (ret < 0)
@@ -573,6 +608,11 @@ static void pwrseq_pcie_m2_remove(struct platform_device *pdev)
 	pwrseq_pcie_m2_remove_serdev(ctx, NULL);
 	mutex_destroy(&ctx->list_lock);
 
+	if (ctx->vaux_reg && ctx->vaux_enabled) {
+		regulator_disable(ctx->vaux_reg);
+		ctx->vaux_enabled = false;
+	}
+
 	regulator_bulk_free(ctx->num_vregs, ctx->regs);
 }
 
-- 
2.50.1

Re: [PATCH 2/2] power: sequencing: pcie-m2: Add 3.3Vaux supply support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Data race on `ctx->vaux_enabled` and unprotected access to `ctx->vaux_reg` between `pwrseq_pcie_m2_remove()` and concurrent power sequencer callbacks.
- [Medium] If `probe` fails after the power sequencer has been registered and a consumer has already utilized it, the `vaux_reg` regulator is never disabled. This leaks the enable count and causes a `WARN_ON` during `devres` cleanup.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the `regulator_bulk_enable()` error path will dereference an uninitialized `.supply` pointer, leading to a kernel crash. This occurs because `of_regulator_bulk_get_all()` allocates the consumers array without zeroing memory.
- [High] This problem wasn't introduced by this patch, but there is a NULL pointer dereference of `ctx->regs[i].consumer` causing a Use-After-Free kernel crash if a consumer unbinds concurrently with or immediately after the provider's `remove()` function.
--

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

power: sequencing: pcie-m2: Add 3.3Vaux supply support

This commit adds support for the 3.3Vaux supply to the PCIe M.2 power
sequencer. The supply is handled separately because it has a different
lifecycle and must remain enabled during system suspend for L2 link states.

> diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
> index e82821655fc4b..6b8c77cf20a9c 100644
> --- a/drivers/power/sequencing/pwrseq-pcie-m2.c
> +++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
[ ... ]
> @@ -48,8 +50,23 @@ struct pwrseq_pcie_m2_ctx {
>  static int pwrseq_pcie_m2_vregs_enable(struct pwrseq_device *pwrseq)
>  {
>  	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +	int ret;
> +
> +	/* Enable 3.3Vaux if present and not already enabled. */
> +	if (ctx->vaux_reg && !ctx->vaux_enabled) {
> +		ret = regulator_enable(ctx->vaux_reg);
> +		if (ret)
> +			return ret;
> +		ctx->vaux_enabled = true;
> +	}
>  
> -	return regulator_bulk_enable(ctx->num_vregs, ctx->regs);
> +	ret = regulator_bulk_enable(ctx->num_vregs, ctx->regs);

[Severity: High]
This is a pre-existing issue, but does this regulator_bulk_enable() error
path handle uninitialized pointers correctly?

If regulator_bulk_enable() fails, its error unwind path attempts to print
the name of the failing supply. However, of_regulator_bulk_get_all()
allocates the consumers array using kmalloc_objs() which does not zero
memory, leaving the .supply field uninitialized.

Could this lead to an out-of-bounds read and kernel panic when the error
message dereferences the uninitialized string pointer?

> +	if (ret && ctx->vaux_reg && ctx->vaux_enabled) {
> +		regulator_disable(ctx->vaux_reg);
> +		ctx->vaux_enabled = false;
> +	}
> +
> +	return ret;
>  }
[ ... ]
> @@ -497,10 +514,28 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
>  		return dev_err_probe(dev, -ENODEV,
>  				     "Failed to obtain platform data\n");
>  
> +	/*
> +	 * Get 3.3Vaux separately for special handling. This supply has a
> +	 * different lifecycle - it must remain enabled during system suspend
> +	 * to support PCIe L2 link state and wake-up mechanisms.
> +	 */
> +	ctx->vaux_reg = devm_regulator_get_optional(dev, "vpcie3v3aux");
> +	if (IS_ERR(ctx->vaux_reg)) {
> +		if (PTR_ERR(ctx->vaux_reg) != -ENODEV)
> +			return PTR_ERR(ctx->vaux_reg);
> +		ctx->vaux_reg = NULL;
> +	}
> +	ctx->vaux_enabled = false;
> +

[Severity: Medium]
If pwrseq_pcie_m2_probe() fails later on (for example, in
pwrseq_pcie_m2_create_serdev()), is the vaux_reg properly disabled?

When devm_pwrseq_device_register() succeeds, the power sequencer becomes
active and a consumer can synchronously bind and call pwrseq_power_on(),
setting ctx->vaux_enabled to true.

If the probe subsequently fails, the err_free_regulators error path calls
regulator_bulk_free() without explicitly disabling ctx->vaux_reg. When the
consumer is unbound by devres and calls pwrseq_power_off(), it skips
disabling vaux_reg because the driver relies on explicit cleanup.

Could this leak the enable count and cause a kernel warning during devres
cleanup?

>  	/*
>  	 * Currently, of_regulator_bulk_get_all() is the only regulator API that
>  	 * allows to get all supplies in the devicetree node without manually
>  	 * specifying them.
[ ... ]
> @@ -573,6 +608,11 @@ static void pwrseq_pcie_m2_remove(struct platform_device *pdev)
>  	pwrseq_pcie_m2_remove_serdev(ctx, NULL);
>  	mutex_destroy(&ctx->list_lock);
>  
> +	if (ctx->vaux_reg && ctx->vaux_enabled) {
> +		regulator_disable(ctx->vaux_reg);
> +		ctx->vaux_enabled = false;
> +	}
> +

[Severity: High]
Are these accesses to ctx->vaux_enabled and ctx->vaux_reg protected against
concurrent modification?

This check and regulator_disable() are called without holding the
pwrseq->state_lock. Since devm_pwrseq_device_register() was used, the power
sequencer remains available to consumers until devres cleanup runs strictly
after pwrseq_pcie_m2_remove() completes.

If a consumer concurrently invokes pwrseq_power_on(),
pwrseq_pcie_m2_vregs_enable() executes and modifies ctx->vaux_enabled under
the lock. 

Could this race lead to an unbalanced disable warning or leave the regulator
disabled prematurely while a consumer thinks the power sequence completed
successfully?

>  	regulator_bulk_free(ctx->num_vregs, ctx->regs);

[Severity: High]
This is a pre-existing issue, but does this regulator_bulk_free() call
introduce a risk of dereferencing a NULL pointer?

The regulator_bulk_free() call explicitly sets consumers[i].consumer to
NULL. However, because the device was registered with
devm_pwrseq_device_register(), it is still active in the pwrseq core until
devres callbacks run.

If a consumer unbinds concurrently and invokes pwrseq_power_off(),
pwrseq_pcie_m2_vregs_disable() securely calls regulator_bulk_disable().

Could this cause a kernel crash when the bulk disable function blindly
dereferences the consumers[i].consumer pointers that were just set to NULL?

>  }

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