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
| ||
|
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