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:   Sun, 12 Nov 2023 13:13:30 +0800
From:   Can Guo <quic_cang@...cinc.com>
To:     Manivannan Sadhasivam <mani@...nel.org>
CC:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Can Guo <cang@....qualcomm.com>, <bvanassche@....org>,
        <stanley.chu@...iatek.com>, <adrian.hunter@...el.com>,
        <beanhuo@...ron.com>, <avri.altman@....com>,
        <junwoo80.lee@...sung.com>, <martin.petersen@...cle.com>,
        <linux-scsi@...r.kernel.org>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@...r.kernel.org>,
        "open list:GENERIC PHY FRAMEWORK" <linux-phy@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 6/7] phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed
 Gear 5 support for SM8550

Hi Mani,

On 11/11/2023 12:12 PM, Manivannan Sadhasivam wrote:
> On Fri, Nov 10, 2023 at 10:40:53PM +0800, Can Guo wrote:
>>
>>
>> On 11/10/2023 9:18 PM, Manivannan Sadhasivam wrote:
>>> On Fri, Nov 10, 2023 at 12:11:46AM +0200, Dmitry Baryshkov wrote:
>>>> On Thu, 9 Nov 2023 at 18:04, Manivannan Sadhasivam <mani@...nel.org> wrote:
>>>>>
>>>>> On Thu, Nov 09, 2023 at 01:00:51PM +0200, Dmitry Baryshkov wrote:
>>>>>> On Thu, 9 Nov 2023 at 12:43, Manivannan Sadhasivam <mani@...nel.org> wrote:
>>>>>>>
>>>>>>> On Thu, Nov 09, 2023 at 11:40:51AM +0200, Dmitry Baryshkov wrote:
>>>>>>>> On Thu, 9 Nov 2023 at 05:24, Manivannan Sadhasivam <mani@...nel.org> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Nov 08, 2023 at 08:56:16AM +0200, Dmitry Baryshkov wrote:
>>>>>>>>>> On Wed, 8 Nov 2023 at 07:49, Manivannan Sadhasivam <mani@...nel.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 07, 2023 at 03:18:09PM +0200, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Tue, 7 Nov 2023 at 06:47, Can Guo <cang@....qualcomm.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: Can Guo <quic_cang@...cinc.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On SM8550, two sets of UFS PHY settings are provided, one set is to support
>>>>>>>>>>>>> HS-G5, another set is to support HS-G4 and lower gears. The two sets of PHY
>>>>>>>>>>>>> settings are programming different values to different registers, mixing
>>>>>>>>>>>>> the two sets and/or overwriting one set with another set is definitely not
>>>>>>>>>>>>> blessed by UFS PHY designers. In order to add HS-G5 support for SM8550, we
>>>>>>>>>>>>> need to split the two sets into their dedicated tables, and leave only the
>>>>>>>>>>>>> common settings in the .tlbs. To have the PHY programmed with the correct
>>>>>>>>>>>>> set of PHY settings, the submode passed to PHY driver must be either HS-G4
>>>>>>>>>>>>> or HS-G5.
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You should also mention that this issue is also present in G4 supported targets.
>>>>>>>>>>> And a note that it will get fixed later.
>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Can Guo <quic_cang@...cinc.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>    drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h     |   2 +
>>>>>>>>>>>>>    drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |   2 +
>>>>>>>>>>>>>    .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h    |  12 +++
>>>>>>>>>>>>>    drivers/phy/qualcomm/phy-qcom-qmp-ufs.c            | 112 ++++++++++++++++++---
>>>>>>>>>>>>>    4 files changed, 115 insertions(+), 13 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
>>>>>>>>>>>>> index c23d5e4..e563af5 100644
>>>>>>>>>>>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
>>>>>>>>>>>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
>>>>>>>>>>>>> @@ -18,6 +18,7 @@
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_BIST_FIXED_PAT_CTRL            0x060
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY           0x074
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY           0x0bc
>>>>>>>>>>>>> +#define QPHY_V6_PCS_UFS_RX_HS_G5_SYNC_LENGTH_CAPABILITY        0x12c
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_DEBUG_BUS_CLKSEL               0x158
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_LINECFG_DISABLE                        0x17c
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_RX_MIN_HIBERN8_TIME            0x184
>>>>>>>>>>>>> @@ -27,5 +28,6 @@
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_READY_STATUS                   0x1a8
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_TX_MID_TERM_CTRL1              0x1f4
>>>>>>>>>>>>>    #define QPHY_V6_PCS_UFS_MULTI_LANE_CTRL1               0x1fc
>>>>>>>>>>>>> +#define QPHY_V6_PCS_UFS_RX_HSG5_SYNC_WAIT_TIME         0x220
>>>>>>>>>>>>>
>>>>>>>>>>>>>    #endif
>>>>>>>>>>>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
>>>>>>>>>>>>> index f420f8f..ef392ce 100644
>>>>>>>>>>>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
>>>>>>>>>>>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
>>>>>>>>>>>>> @@ -56,6 +56,8 @@
>>>>>>>>>>>>>    #define QSERDES_V6_COM_SYS_CLK_CTRL                            0xe4
>>>>>>>>>>>>>    #define QSERDES_V6_COM_SYSCLK_BUF_ENABLE                       0xe8
>>>>>>>>>>>>>    #define QSERDES_V6_COM_PLL_IVCO                                        0xf4
>>>>>>>>>>>>> +#define QSERDES_V6_COM_CMN_IETRIM                              0xfc
>>>>>>>>>>>>> +#define QSERDES_V6_COM_CMN_IPTRIM                              0x100
>>>>>>>>>>>>>    #define QSERDES_V6_COM_SYSCLK_EN_SEL                           0x110
>>>>>>>>>>>>>    #define QSERDES_V6_COM_RESETSM_CNTRL                           0x118
>>>>>>>>>>>>>    #define QSERDES_V6_COM_LOCK_CMP_EN                             0x120
>>>>>>>>>>>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
>>>>>>>>>>>>> index 15bcb4b..48f31c8 100644
>>>>>>>>>>>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
>>>>>>>>>>>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
>>>>>>>>>>>>> @@ -10,10 +10,20 @@
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_TX_RES_CODE_LANE_RX                     0x2c
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_TX              0x30
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_RX              0x34
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_TX_LANE_MODE_1                          0x7c
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_TX_FR_DCC_CTRL                          0x108
>>>>>>>>>>>>>
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE2          0x08
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE4          0x10
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_SO_GAIN_RATE4          0x24
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_COUNT_HIGH_RATE4       0x54
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE2                   0xd4
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE4                   0xdc
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_UCDR_SO_GAIN_RATE4                   0xf0
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_UCDR_PI_CONTROLS                     0xf4
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL                      0x178
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_EQ_OFFSET_ADAPTOR_CNTRL1             0x1bc
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_OFFSET_ADAPTOR_CNTRL3                        0x1c4
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B0                     0x208
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B1                     0x20c
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B3                     0x214
>>>>>>>>>>>>> @@ -25,6 +35,8 @@
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_MODE_RATE3_B5                                0x264
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_MODE_RATE3_B8                                0x270
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_MODE_RATE4_B3                                0x280
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_MODE_RATE4_B4                                0x284
>>>>>>>>>>>>>    #define QSERDES_UFS_V6_RX_MODE_RATE4_B6                                0x28c
>>>>>>>>>>>>> +#define QSERDES_UFS_V6_RX_DLL0_FTUNE_CTRL                      0x2f8
>>>>>>>>>>>>>
>>>>>>>>>>>>>    #endif
>>>>>>>>>>>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>>>>>>>>>>>>> index 3927eba..e0a01497 100644
>>>>>>>>>>>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>>>>>>>>>>>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>>>>>>>>>>>>> @@ -649,32 +649,51 @@ static const struct qmp_phy_init_tbl sm8550_ufsphy_serdes[] = {
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_SEL_1, 0x11),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_HS_SWITCH_SEL_1, 0x00),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP_EN, 0x01),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x04),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
>>>>>>>>>>>>> +
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_INITVAL2, 0x00),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x41),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x0a),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x18),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x14),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x7f),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x06),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x4c),
>>>>>>>>>>>>> +};
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static const struct qmp_phy_init_tbl sm8550_ufsphy_hs_b_serdes[] = {
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x44),
>>>>>>>>>>>>> +};
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_serdes[] = {
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x04),
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
>>>>>>>>>>>>>           QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x0a),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x18),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x14),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x99),
>>>>>>>>>>>>> -       QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x07),
>>>>>>>>>>>>
>>>>>>>>>>>> Aside from moving these registers to the HS_G4 table, you are also
>>>>>>>>>>>> changing these registers. It makes me think that there was an error in
>>>>>>>>>>>> the original programming sequence.
>>>>>>>>>>>> If that is correct, could you please split the patch into two pieces:
>>>>>>>>>>>> - Fix programming sequence (add proper Fixes tags)
>>>>>>>>>>>> - Split G4 and G5 tables.
>>>>>>>>>>>
>>>>>>>>>>> Ack
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE1, 0x4c),
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE1, 0x0a),
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE1, 0x18),
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE1, 0x14),
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE1, 0x99),
>>>>>>>>>>>>> +       QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE1, 0x07),
>>>>>>>>>>>>
>>>>>>>>>>>> I see all the MODE1 registers being only present in G4 and G5 tables.
>>>>>>>>>>>> Should they be programmed for the modes lower than G4?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We use G4 table for all the modes <= G4.
>>>>>>>>>>
>>>>>>>>>> Could you please point me how it's handled?
>>>>>>>>>> In the patch I see just:
>>>>>>>>>>
>>>>>>>>>>          if (qmp->submode == UFS_HS_G4)
>>>>>>>>>>                  qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_g4);
>>>>>>>>>>          else if (qmp->submode == UFS_HS_G5)
>>>>>>>>>>                  qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_g5);
>>>>>>>>>>
>>>>>>>>>> Which looks like two special cases (HS_G4 and HS_G5) and nothing for
>>>>>>>>>> anything else.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, and the UFS driver passes only G4/G5. For all the gears <=G4, G4 init
>>>>>>>>> sequence will be used and for G5, G5 sequence will be used.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's what I could not find in the UFS driver. I see a call to
>>>>>>>> `phy_set_mode_ext(phy, PHY_MODE_UFS_HS_B, host->phy_gear);` and
>>>>>>>> host->phy_gear is initialised to UFS_HS_G2.
>>>>>>>>
>>>>>>>
>>>>>>> You need to check the UFS driver changes in this series to get the complete
>>>>>>> picture as the logic is getting changed.
>>>>>>>
>>>>>>> It is common to get confused because of the way the UFS driver (qcom mostly)
>>>>>>> handles the PHY init sequence programming. We used to have only one init
>>>>>>> sequence for older targets and life was easy. But when I wanted to add G4
>>>>>>> support for SM8250, I learned that there are 2 separate init sequences. One for
>>>>>>> non-G4 and other for G4. So I used the phy_sub_mode property to pass the
>>>>>>> relevant mode from the UFS driver to the PHY driver and programmed the sequence
>>>>>>> accordingly. This got extended to non-G5 and G5 now.
>>>>>>>
>>>>>>> Now, the UFS driver will start probing from a low gear for older targets (G2)
>>>>>>> and G4/G5 for newer ones then scale up based on the device and host capability.
>>>>>>> For older targets, the common table (tbls) will be used if the submode doesn't
>>>>>>> match G4/G5. But for newer targets, the UFS driver will _only_ pass G4 or G5 as
>>>>>>> the phy_gear, so those specific sequence will only be used.
>>>>>>>
>>>>>>> Hope I'm clear.
>>>>>>
>>>>>> Yes, it is now clear, thank you!
>>>>>>
>>>>>> Would it be possible / feasible / logical to maintain this idea even
>>>>>> for newer platforms (leaving the HS_A  / HS_B aside)?
>>>>>>
>>>>>> tbls - works for HS_G2
>>>>>> tbls + tbls_g4 - works for HS_G4
>>>>>> tbls + tbls_g5 - works for HS_G5
>>>>>>
>>>>>
>>>>> No. The PHY team only gives 2 init sequences for any SoC now.
>>>>
>>>> Ack. Then the code should become
>>>> if (HS_G5)
>>>>      program(tbls_hs_g5)
>>>> else
>>>>      program(tbls_hs_g4);
>>>>
>>>
>>> This should work. Even if we have to accomodate G6 in the future, we can use
>>> "else if" for that and keep G4 as the "else" condition. This logic can also be
>>> optimized in the future.
>>
>> That would make dual init meaningless for old targets. Say on SM8450, the
>> initial PHY gear is G2, with the "else" condition, during the first init, G4
>> table would be programmed, then gear negotiation happens btw host and device
>> and the negotiated gear is G3 (assume a UFS2.x is connected). During the 2nd
>> init, the "else" condition would __again__ program the G4 table - it is not
>> programming the non-G4 table for power saving. The dual init is supposed to
>> find the optimal PHY settings, but the "else" condition is programming G4
>> table unconditinally.
>>
>> With the original code change in this patch, the dual init works as it is
>> for old targets. say SM8450, the initial PHY gear is G2, during the 2nd
>> init, it is programming the non-G4 table (assume a UFS2.x is connected), but
>> not the G4 table.
>>
> 
> You are right. I completely overlooked the compatibility for old targets. But
> still we can move the common table to the "else" condition. This makes it clear
> that one of the 3 will be programmed at a time. But with the current logic, I
> get the impression that common table is overridden by G4/G5 tables.
> 
> So this is what I'm suggesting:
> 
> if (HS_G5)
> 	program(tbls_hs_g5)
> else if (HS_G4)
> 	program(tbls_hs_g4);
> else
> 	program(tbls_hs_common);
> 

Common table is needed regardlessly, we cannot put it in "else", 
otherwise it would break all targets -

On old targets (no G5 supported):
Common table 		- supports non-G4 (G3 and lower)
Common table + G4 table - supports G4

On new targets (G5 supported):
Common table 		- supports nothing, as it is just common parts of G4 
table and G5 table.
Common table + G4 table - support non-G5 (G4 and lower)
Common table + G5 table - support G5

Thanks,
Can Guo.

> - Mani
> 
>> Thanks,
>> Can Guo.
>>>
>>> - Mani
>>>
>>>>>
>>>>> - Mani
>>>>>
>>>>>> I mean here that the PHY driver should not depend on the knowledge
>>>>>> that the UFS driver will not be setting HS_G2 for some particular
>>>>>> platform and ideally it should continue working if at some point we
>>>>>> change the UFS driver to set HS_G2.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> - Mani
>>>>>>>
>>>>>>>> Maybe we should change the condition here (in the PHY driver) to:
>>>>>>>>
>>>>>>>> if (qmp->submode <= UFS_HS_G4)
>>>>>>>>
>>>>>>>> ?
>>>>>>>> --
>>>>>>>> With best wishes
>>>>>>>> Dmitry
>>>>>>>
>>>>>>> --
>>>>>>> மணிவண்ணன் சதாசிவம்
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> With best wishes
>>>>>> Dmitry
>>>>>
>>>>> --
>>>>> மணிவண்ணன் சதாசிவம்
>>>>
>>>>
>>>>
>>>> -- 
>>>> With best wishes
>>>> Dmitry
>>>
> 

Powered by blists - more mailing lists