RE: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver

[Avri Altman]

One last word for the community members that are not into ufs day-to-day:

HPB implementation made its first public appearance around 2018 as part of Google's Pixel3 and some VIVO models.
Since then, more and more mobile platforms are publically using HPB: Galaxy Note10,
Galaxy S20 and VIVO NEX3 (that is already using HPB2.0), some Xiaomi models etc.

On the other hand, HPB1.0 spec was just recently closed - not even as part of UFS3.1,
but only after - about 2 months ago. The industry is rushing forward, we've seen this many times.

The fact is that HPB is here to stay - either as a horde of out-of-tree implementations,
or as a standard acceptable mainline driver.

Thanks,
Avri

> 
> Hi Bart,
> 
> > What are the similarities and differences compared to the lightnvm
> > framework that was added several years ago to the Linux kernel? Which of
> > the code in this patch can be shared with the lightnvm framework?
> Simply put, unlike lightnvn, HPB is not host-managed FTL, But instead can be
> perceived as a cost-reduction effort.
> Its aim is not to move the fw to the host, but to control the iNAND cost by
> limiting the amount of its internal RAM.
> It is done by using the host memory to cache the L2P tables, and replace
> READ_10 that have only the lba,
> by an alternative command - HPB_READ, that have both the logical and
> physical addresses.
> 
> Using Lightnvm was considered in the past as possible framework for HPB,
> but was rejected by both Christoph & Mattias.
> 
> The HPB feature was NAKed by Christoph in its entirety, regardless of the
> driver design.
> Until this is not reversed, keep commenting this patch is counterproductive
> and confusing.
> 
> Should this decision is reversed, I think this patch should be re-posted as a
> RFC,
> And fragment its 5,000 lines or so into a set of reviewable patches.
> 
> Thanks,
> Avri