linux-kernel - Re: [PATCH v3 1/2] scsi: ufs: pass device information to apply_dev

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