linux-kernel - Re: [PATCH v8 10/11] PCI: qcom: Add SM8550 PCIe support

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: <Y+PUuy0qbO9EWOXb@hovoldconsulting.com>
Date:   Wed, 8 Feb 2023 17:58:35 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Abel Vesa <abel.vesa@...aro.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org,
        linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 10/11] PCI: qcom: Add SM8550 PCIe support

On Mon, Feb 06, 2023 at 11:26:18PM +0200, Abel Vesa wrote:
> Add compatible for both PCIe found on SM8550.
> Also add the noc_aggr and cnoc_sf_axi clocks needed by the SM8550.
> 
> Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> Reviewed-by: Manivannan Sadhasivam <mani@...nel.org>
> ---

> @@ -1237,17 +1239,17 @@ static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie)
>  	if (ret < 0)
>  		goto err_disable_regulators;
>  
> -	ret = reset_control_assert(res->pci_reset);
> -	if (ret < 0) {
> -		dev_err(dev, "cannot assert pci reset\n");
> +	ret = reset_control_assert(res->rst);
> +	if (ret) {
> +		dev_err(dev, "reset assert failed (%d)\n", ret);
>  		goto err_disable_clocks;
>  	}
>  
>  	usleep_range(1000, 1500);
>  
> -	ret = reset_control_deassert(res->pci_reset);
> -	if (ret < 0) {
> -		dev_err(dev, "cannot deassert pci reset\n");
> +	ret = reset_control_deassert(res->rst);
> +	if (ret) {
> +		dev_err(dev, "reset deassert failed (%d)\n", ret);
>  		goto err_disable_clocks;
>  	}

I'd still like to know if it's indeed ok the deassert the 'pci' reset
before the new 'link_down' reset here which is what this code currently
would do (i.e. same order as for assert, while if you had used the bulk
reset API it would have deasserted in the reverse order).

Other than that:

Reviewed-by: Johan Hovold <johan+linaro@...nel.org>