Hi Asutosh, Sorry for the inconvenience, we will discuss internally to see if there's a better fix that meets both our needs. -----Original Message----- From: Asutosh Das <quic_asutoshd@xxxxxxxxxxx> Sent: Tuesday, November 22, 2022 6:57 AM To: Powen Kao (高伯文) <Powen.Kao@xxxxxxxxxxxx> Cc: Bart Van Assche <bvanassche@xxxxxxx>; Stanley Chu (朱原陞) <stanley.chu@xxxxxxxxxxxx>; martin.petersen@xxxxxxxxxx; Peter Wang (王信友) <peter.wang@xxxxxxxxxxxx>; Naomi Chu (朱詠田) <Naomi.Chu@xxxxxxxxxxxx>; Alice Chao (趙珮均) <Alice.Chao@xxxxxxxxxxxx>; linux-scsi@xxxxxxxxxxxxxxx; mani@xxxxxxxxxx; quic_cang@xxxxxxxxxxx Subject: Re: 52a518019c causes issue with Qualcomm UFSHC On Sat, Nov 19 2022 at 20:16 -0800, Powen Kao (高伯文) wrote: >Hi Asutosh, > > > >Reverting the patch doesn't sound feasible on MTK platform ☹ > > > >>>I don't think invoking a clock scaling notification during > >>>ufshcd_host_reset_and_restore() sounds right to me. > >But the point is that driver has the right to know that the clk is scaled no matter where ufshcd_scale_clks() is invoked, no? > > > >Do you mind applying this patch on qcom driver to check on host status before further operation? + Mani, linux-scsi Hello Powen Thanks for the change. I will think of something to work-around the issue. However, I would like to point out that a change that breaks an existing driver must be fixed or reverted, not the other way around. -asd
