linux-kernel - Re: [PATCH 06/13] phy: qcom-qmp-pcie: drop bogus register update

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]

Date:   Wed, 28 Sep 2022 22:48:40 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Johan Hovold <johan+linaro@...nel.org>,
        Vinod Koul <vkoul@...nel.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/13] phy: qcom-qmp-pcie: drop bogus register update

On 28/09/2022 22:10, Dmitry Baryshkov wrote:
> On 28/09/2022 18:28, Johan Hovold wrote:
>> Since commit 0d58280cf1e6 ("phy: Update PHY power control sequence") the
>> PHY is powered on before configuring the registers and only the MSM8996
>> PCIe PHY, which includes the POWER_DOWN_CONTROL register in its PCS
>> initialisation table, may possibly require a second update afterwards.
>>
>> To make things worse, the POWER_DOWN_CONTROL register lies at a
>> different offset on more recent SoCs so that the second update, which
>> still used a hard-coded offset, would write to an unrelated register
>> (e.g. a revision-id register on SC8280XP).
>>
>> As the MSM8996 PCIe PHY is now handled by a separate driver, simply drop
>> the bogus register update.
>>
>> Fixes: e4d8b05ad5f9 ("phy: qcom-qmp: Use proper PWRDOWN offset for 
>> sm8150 USB") added support
> 
> I'm not sure about the particular fixes tag. Backporting from the split 
> driver into old qmp driver would be a complete pain.
> 
>> Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>

After digging some more, I stumbled upon the commit 0d58280cf1e6 ("phy: 
Update PHY power control sequence"), which puts explicit register write 
here, telling that 'PCIe PHYs need an extra power control before 
deasserts reset state'.

I can confirm this with the register tables from downstream dtsi. E.g. 
consider sdm845-pcie.dts, pcie0 table. The PCS_POWER_DOWN_CONTROL is the 
register 0x804.

The programmings starts with <0x804 0x1 0x0>, writing 1 to 
PCS_POWER_DOWN_CONTROL (which if I'm not mistaken we do not do at this 
moment). Then after writing all the serdes/tx/rx/pcs/pcs_misc tables 
comes the write <0x804 0x3 0x0> (which you are trying to remove here).

Same sequence applies to the PCIe PHY on msm8998.

Most newer PHYs have the expected sequence (of writing 0x3 to 
PCS_POWER_DOWN_CONTROL) before writing all registers.

As a short summary: unless we get any additional information that 8998 
and sdm845 tables are incorrect, I'd suggest adding a conditional here 
(ugh) and using it here and in qmp_pcie_init() call.

Vinod, Bjorn, do you have any additional info?

> 
>> ---
>>   drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 6 ------
>>   1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c 
>> b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
>> index 4146545fdf5f..eea66c24cf7e 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
>> @@ -1953,12 +1953,6 @@ static int qmp_pcie_power_on(struct phy *phy)
>>       qmp_pcie_configure(pcs_misc, cfg->regs, cfg->pcs_misc_tbl, 
>> cfg->pcs_misc_tbl_num);
>>       qmp_pcie_configure(pcs_misc, cfg->regs, cfg->pcs_misc_tbl_sec, 
>> cfg->pcs_misc_tbl_num_sec);
>> -    /*
>> -     * Pull out PHY from POWER DOWN state.
>> -     * This is active low enable signal to power-down PHY.
>> -     */
>> -    qphy_setbits(pcs, QPHY_V2_PCS_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
>> -
>>       if (cfg->has_pwrdn_delay)
>>           usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
> 

-- 
With best wishes
Dmitry