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  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:   Tue, 18 Feb 2020 15:02:39 +0800
From:   Stanley Chu <stanley.chu@...iatek.com>
To:     Can Guo <cang@...eaurora.org>
CC:     <linux-scsi@...r.kernel.org>, <martin.petersen@...cle.com>,
        <avri.altman@....com>, <alim.akhtar@...sung.com>,
        <jejb@...ux.ibm.com>, <beanhuo@...ron.com>,
        <asutoshd@...eaurora.org>, <matthias.bgg@...il.com>,
        <bvanassche@....org>, <linux-mediatek@...ts.infradead.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <kuohong.wang@...iatek.com>,
        <peter.wang@...iatek.com>, <chun-hung.wu@...iatek.com>,
        <andy.teng@...iatek.com>
Subject: Re: [PATCH v3 1/2] scsi: ufs: pass device information to
 apply_dev_quirks

Hi Can,


> Hi Stanley,
> 
> Is this series merged? If no, would you mind moving
> ufshcd_vops_apply_dev_quirks(hba, card); a little bit? Like below.
> 
> @@ -6852,14 +6852,14 @@ static void ufshcd_tune_unipro_params(struct 
> ufs_hba *hba)
>                  ufshcd_tune_pa_hibern8time(hba);
>          }
> 
> +       ufshcd_vops_apply_dev_quirks(hba, card);
> +
>          if (hba->dev_quirks & UFS_DEVICE_QUIRK_PA_TACTIVATE)
>                  /* set 1ms timeout for PA_TACTIVATE */
>                  ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TACTIVATE), 10);
> 
> In this way, vendor codes have a chance to modify the dev_quirks
> before ufshcd_tune_unipro_params() does the rest of its job.
> 

This patch has been merged to 5.6-rc1.

Basically I am fine with your proposal. But if you need to move it to
new mentioned position, our apply_dev_quirks callback also need
corresponding change so it might need our co-works : )

For example, you could just post your proposed changes and then we would
provide corresponding change as soon as possible?

Besides, I would like to remind that allowing vendor to "fix" device
quirks in advance imply that current common device quirks have some
problems? If so, would you consider to fix common device quirks instead?


> Thanks,
> Can Guo.

Thanks,
Stanley Chu


Powered by blists - more mailing lists