> > Hi, Christoph > Thanks for your feedback. > > > > To avoid touching the traditional SCSI core, the HPB driver in this > > > series HPB patch chooses to develop under SCSI sub-system layer, and > > > sits the same layer with UFSHCD. At the same time, to minimize changes > > > to UFSHCD driver, the HPB driver submits its HPB READ BUFFER and HPB > > > WRITE BUFFER requests to the scsi > > > device->request_queueu to execute, rather than that directly go > > > device->through > > > raw UPIU request path. > > > > This feature is completley broken, and rather dangerous due to feeding > > "physical" addresses looked up by the host in. I do not think we should > support > > something that broken in Linux. > > > > It Is not plain physical address, has been encrypted before loading from UFS > to > HPB memory, I think we don't worry about its safety. > > > Independent of that using two requests in the I/O path is not going to fly > either. > > The whole thing seems like an exercise in benchmarketing. > > I agree with you. This is my major concern. I have been thinking about HPB > implementation in SCSI layer. > That will let SCSI layer manage HPB by calling UFS helper interface. > If you don't consider UFS HPB is an idiot design, I want to change in another > version. Firstly, we really > want to hear your suggestion. > Thanks, > > //Bean If indeed this will move forward, please publish your patches as a RFC, To allow competing approaches to be published as well. Thanks, Avri
