On Tue, Aug 20, 2024 at 02:50:58PM -0700, Bart Van Assche wrote: > On 8/19/24 11:09 PM, Manivannan Sadhasivam wrote: > > On Mon, Aug 19, 2024 at 08:17:10PM +0200, Mary Guillemard wrote: > > > On Mon, Aug 19, 2024 at 05:38:52PM +0530, Manivannan Sadhasivam wrote: > > > > On Mon, Aug 19, 2024 at 12:24:42AM +0200, Mary Guillemard wrote: > > > > > + if (host->caps & UFS_MTK_CAP_DISABLE_MCQ) > > > > > > > > How can this be the deciding factor? You said above that the issue is with > > > > MT8183 SoC. So why not just use the quirk only for that platform? > > > > > > So my current assumption is that it also affect other Mediatek SoCs > > > that are also based on UFS 2.1 spec but I cannot check this. > > > > > > Instead, we know that if MCQ isn't supported, we must fallback to LSDB > > > as there is no other ways to drive the device. > > > > > > UFS_MTK_CAP_DISABLE_MCQ (mediatek,ufs-disable-mcq) being unused upstream, > > > I think that's an acceptable fix. > > > > > > > If you use this quirk, then you need to use the corresponding DT property. But > > using the 'mediatek,ufs-disable-mcq' property for 2.1 controller doesn't make > > sense as MCQ is for controllers >= 4.0. > > > > > Another way to handle this would be to add a new dt property and add it > > > to ufs_mtk_host_caps but I feel that my approach should be enough. > > > > > > > No need to add a DT property. Just use the SoC specific compatible as I did for > > SM8550 SoC. > > Mary, do you plan to implement Manivannan's feedback? > > Thanks, > > Bart. > Hello Bart, I think that considering Peter's reply, explicitly checking for the MT8183 controller isn't required. I also think it could be required for at least the MT8192 and MT8195 considering they are apparently also based on UFS 2.1 spec [1]. However, if you want me to add an explicit check, I will happily send a v2. Thanks, Mary. [1]https://corp.mediatek.com/news-events/press-releases/mediatek-announces-new-mt8192-and-mt8195-chipsets-designed-for-next-generation-of-chromebooks
