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
