Hi, > > On Mon, Jan 21, 2019 at 11:17:31AM +0000, Avri Altman wrote: > > > > > > On Thu, Jan 10, 2019 at 05:53:03PM +0200, Avri Altman wrote: > > > > Allow to read descriptors via raw upiu. This in fact was forbidden just > > > > as a precaution, as ufs-bsg actually enforces which functionality is > > > > supported. > > > > > > This still looks rather odd. Why is this using a buffer after the > > > bsg_request? Nornally you'd directly pass down the pages that bsg > > > locked down to the low-level driver to work on. > > Right. All this is done in ufs-bsg as ufshcd has no concept of bsg job - > > See the next patch. > > Well, I still don't understand what you are actually doing in this patch > then. The second and third hunks are pretty obvious, they remove the > previous restriction on UPIU_QUERY_OPCODE_WRITE_DESC with a non-NULL > buffer, and seem to vaguely match the patch description. Right > > The first hunk on the other hand adds new code for the > UPIU_QUERY_OPCODE_READ_DESC case which copies data to the passed > in buffer from the hardware, that goes into the ->reply field of the > bsg buffer, which basically is the scsi sense buffer, that is out > of line return information. Ah - no. We are using job->request_payload on both write descriptor (sg_copy_to_buffer), As well as for read descriptor (sg_copy_from_buffer). See the 2nd patch. > > But why are we returning information in the out of line reply buffer, > and not the in-line data buffer? Maybe there is a good explanation for > that, but it clear is not documented in the commit log. > > > > > Thanks, > > Avri > ---end quoted text---
