Received-SPF: pass (google.com: domain of linux-kernel+bounces-62373-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Mon, 12 Feb 2024 15:14:32 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Johan Hovold <johan+linaro@kernel.org>
Subject: Re: [PATCH v2 1/3] PCI: qcom: reshuffle reset logic in 2_7_0 .init
Message-ID: <20240212211432.GA1145620@bhelgaas>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240210-topic-8280_pcie-v2-1-1cef4b606883@linaro.org>

Would be nice to have a hint in the subject line about what this does.
Also capitalize to match the others ("PCI: qcom: <Capitalized verb>").

On Sat, Feb 10, 2024 at 06:10:05PM +0100, Konrad Dybcio wrote:
> At least on SC8280XP, if the PCIe reset is asserted, the corresponding
> AUX_CLK will be stuck at 'off'. This has not been an issue so far,
> since the reset is both left de-asserted by the previous boot stages
> and the driver only toggles it briefly in .init.
> 
> As part of the upcoming suspend prodecure however, the reset will be
> held asserted.

s/prodecure/procedure/

> Assert the reset (which may end up being a NOP in some cases) and
> de-assert it back *before* turning on the clocks in preparation for
> introducing RC powerdown and reinitialization.

Bjorn