Thanks Olivier and John for your feedback on the patches! I addressed your comments in the CLs. Let me know if you have additional questions.

Regarding testing, we verified these changes on our own board, but I would love to hear how your HiKey960 tests fair. Let me know if there is anything I can do to help in this area.

As a next step, can I get code review from the UFS owner for the patches linked above? Haojian?

Thanks!

Jorge Troncoso

On Mon, Oct 4, 2021 at 10:10 AM John Stultz <john.stultz@linaro.org> wrote:

On Mon, Oct 4, 2021 at 9:04 AM Olivier Deprez <Olivier.Deprez@arm.com> wrote:
> I left few comments.
>
> I think the main question is how do you test those changes?
>
> The only board supported in TF-A which has an UFS device on PCB is the Hikey960.
> I assume you have your own board against which you test those changes?
>
> As the changes are related to sensitive timings at init / identification (and changing the logic from an infinite poll loop to a finite counting loop) I sense there may be a lot of variation from one board to another, or even one flash chip to another (also depends on flash vendor). So while this may work with one particular configuration, it's difficult to tell if it scales stable to a variable number of configurations.
> I'll let the Hikey960 / UFS maintainer comment more if need be.
>

Yea, I too will defer to Haojian as he has more expertise on the
topic.  But as I mentioned in Gerrit, HiKey960 has had a number of UFS
related issues with the non-proprietary bootloader, especially with
regards to different versions of the board that used different UFS
chips. So this is a sensitive pathway.

Unfortunately thorough testing will take some time, and I'm a bit
short on bandwidth, so maybe if Haojian and others don't see any
issues in the logic, we can do some quick initial smoke tests and if
it seems ok go ahead, as I am not personally eager to respin the
bootloader for HiKey960 in the near future, and I'm not sure how much
longer the board will be actively useful.

thanks
-john