Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Fri, 4 Mar 2022 08:45:30 +0100
From:   Francesco Dolcini <francesco.dolcini@toradex.com>
To:     Hongxing Zhu <hongxing.zhu@nxp.com>
Cc:     Francesco Dolcini <francesco.dolcini@toradex.com>,
        "l.stach@pengutronix.de" <l.stach@pengutronix.de>,
        "bhelgaas@google.com" <bhelgaas@google.com>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
        "jingoohan1@gmail.com" <jingoohan1@gmail.com>,
        "festevam@gmail.com" <festevam@gmail.com>,
        "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v8 5/8] PCI: imx6: Refine the regulator usage
Message-ID: <20220304074530.GA1164950@francesco-nb.int.toradex.com>
References: <1645760667-10510-1-git-send-email-hongxing.zhu@nxp.com>
 <1645760667-10510-6-git-send-email-hongxing.zhu@nxp.com>
 <20220225094301.GA2171975@francesco-nb.int.toradex.com>
 <AS8PR04MB8676418087498F9CAF9849FD8C019@AS8PR04MB8676.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AS8PR04MB8676418087498F9CAF9849FD8C019@AS8PR04MB8676.eurprd04.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?qodQKHs3tKwufAU7xKihCiQYGpGUgcNlsoqLUxo00a5GEbNtJlTK2wvickgn?=
 =?us-ascii?Q?Cco8CgatUwPePP6/BbfNIwcZA3mGML7DgCl9E3rdzMRekP04gGxU9NdnZG02?=
 =?us-ascii?Q?6aH2jLfutxnkTpld/tHq6fwZrrlqyB0BuG5PJUw/98l49haSYlHxnyUmC9PK?=
 =?us-ascii?Q?83A2qKa5fBAL295y8YAj9js2UdroFUBFKrE205Lm64TzGoJKmgCCpLQXLeM7?=
 =?us-ascii?Q?RSBq/l9BIFkCD/ZpFyKQO4MiMdzB3/SFjgGNCsdNLB6ldvqan6IEFI2wFCJN?=
 =?us-ascii?Q?jEBjRWJ4ch+OYthfnpyFkaLUHUJi7g6jX+7qToenajubStsbDoJU/+yi6EpF?=
 =?us-ascii?Q?Hm7BVQgtEttgD6MGpy6qCWOswvuWEJQ3v2faPf5sv9KVa3KlciZF5Y9RPEWE?=
 =?us-ascii?Q?vKIFq5KKAqExSrIeNDZfJa6RcxcaXCqr6P3xaQNPw9fIvY64O2wmkf2OqHQL?=
 =?us-ascii?Q?xHKLj8NS3YByPJ+2TOPB9CpzeAGzxsyLaDdNLm1FcUX7K9ui2ql8vR6FIYYY?=
 =?us-ascii?Q?vEpcK1ZZWxxKsVQ2gM5QTR0cyg+lqxstRORkXKDC+eIrRVdW+bRqkiejEcHb?=
 =?us-ascii?Q?5o6Laru0+l8uGYU4n5c0QqIZO+DCGHG9W2HePfV2V0c09LoDSh0ngWn69hBB?=
 =?us-ascii?Q?iKEObOCzQ1UJMg9v1UQ1ehCpb9qwqA8fqsBKDRdWO6pbRklLO63BHcYfyrEJ?=
 =?us-ascii?Q?e7oQIxZRga+g0FpPygPfiYxXNFC3F0mMqup3WUBUz8Sh8Y+0hpbAlwEXAVZJ?=
 =?us-ascii?Q?PEuTYxYxM0wthCBsEuxVRTKXytCAWIAJRukNIYBx8PK0grRfnt9swCgd15vd?=
 =?us-ascii?Q?9UkKlMcvw5036l5fV6IwsDaIT+Hqxvf11n257VXtI7gd3BHQXPyRSrIuFJ1p?=
 =?us-ascii?Q?v3UVwqRJHm5hc++PzdN3tg4G0DSC5Bh9guI1DBB+poEVa+TvcTQzG2KDZsz+?=
 =?us-ascii?Q?aQ3d8dhWWnAmfIusd2Pd8HKXkgoVW6HSX2GJS5dpPAguXJxN2DNGjA4HJgeZ?=
 =?us-ascii?Q?5OgwS48USGdAgrjU/NnAnGifxUa/fy5bsZdc3Ehw0cJC6GPRoO/OMX9oLPtf?=
 =?us-ascii?Q?NFOZMf4hVhO0mZLCYfz+lXICykWnfOUKfsBkrIetdW+L8Oih5ZnyZ0NCXRkq?=
 =?us-ascii?Q?/nJZhAvbL2oRT76nyd8M3U5UPsIqJH274xUPJdYjzBoEQ7IsASomkTWllSk1?=
 =?us-ascii?Q?z1Ec1cS+1cWnuHu22nIh6o/JIsR9FH4AGYOcHpOvaAelvRA+uzV1MuxuloUu?=
 =?us-ascii?Q?zatL8DLmN684L9iToCsqvofUGJx/zeEKvsGYrYFy0epATqEYTTtQPLaIagtP?=
 =?us-ascii?Q?+FnWQg7zPg1cFQdozu5d6l4VXf2nTC4z7amqBUGDbVybm7lrJ8CVEqbejwkF?=
 =?us-ascii?Q?QGqQIbKjh56OBavTQMMCMhJJbW3bHX1OekXKvpjLtxRdv48plF1JRsa6jP8o?=
 =?us-ascii?Q?x4a266qTh6+Tt5jJDw9jqKH4NPzqrb2i//5Ms6hIR6jWhyd0gtQoNO8Hgr5r?=
 =?us-ascii?Q?xb9S9L/SIZp4Coa6Q0sz5TA/76UCfnNFqQcrud6csf2tZiwoGy1bCcre7oMy?=
 =?us-ascii?Q?nThCuxAMgu22hJdRxNbk9RHr05KnmfCxmy+ZATtNSl+oy9Aj4c6dg+Nng9vX?=
 =?us-ascii?Q?IHMbHRonz/iPMk5dEz6vRYzwyvZ/1jwHi4k/u8laso07Of1/IDvFPVRTJDdp?=
 =?us-ascii?Q?st/Dxw=3D=3D?=
X-OriginatorOrg: toradex.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 980f813e-bec2-4709-cd02-08d9fdb2f561
X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0642.CHEP278.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2022 07:45:31.3719
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d9995866-0d9b-4251-8315-093f062abab4
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: D00t8aGcYylmHYo1JUmym8/1cvVIW6cMDvOAfBWpocugyrIv58MDaAZiKRlDAKmwrpOU6/36ksdOP5CVJQtrqXDOPrcRV1cSG74qQl3N7QQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVAP278MB0565
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 28, 2022 at 03:43:03AM +0000, Hongxing Zhu wrote:
> > 2. We are playing around with vpcie during regulator during suspend/resume,
> > why? We currently have issue with suspend/resume when a PCIe switch is
> > there, with the final effect of PCIe being not usable afterward. I fear like this is
> > related to our issue.
> >
> To my understands, the VPCIE is the abstract of the DIESABLE# signal.
> Refer to the Chapter 3.1.12.3 W_DISABLE# Signal of PCI Express M.2 SPEC.
> These signals are used to disable the Adapter's radio operation to meet public
> Safety regulations or when otherwise desired.
> It's reasonable to assert/de-assert W_DISABLE# signal during suspend/resume.
> 
> > What about vpcie enable in probe, and vpcie disable in shutdown and that's
> > all?
> The W_DISABLE# Signal is used to control the radios on the Adapters.
> I think you can do that, if the radios are always on in your system.

According to the binding documentation (imx6q-pcie.yaml)

  vpcie-supply:
    description: Should specify the regulator in charge of PCIe port power.
      The regulator will be enabled when initializing the PCIe host and
      disabled either as part of the init process or when shutting down
      the host (optional required).

This is how it's documented to be used, if this is used according to the
documentation (and this is happening) what you are already doing (not
changed in this patch, you are right) is not correct.

Abusing this for the W_DISABLE# disable is new to me and does not look
legit.

Francesco