On Wed, 2022-04-06 at 10:32 -0700, Bart Van Assche wrote: > > It's the SCSI BSG driver, in fact, we don't have a dedicated UFS > > RPMB > > driver in the kernel. RPMB is a well known LU, we are using > > userspace > > tools to issue SCSI commands directly to the UFS RPMB LU via > > ioctl() > > from the BSG device node in the /dev/sg/ folder. > > > > Here is the BSG part of the code in the userspace tools: > > > > io_hdr_v4.guard = 'Q'; > > io_hdr_v4.protocol = BSG_PROTOCOL_SCSI; > > io_hdr_v4.subprotocol = BSG_SUB_PROTOCOL_SCSI_CMD; > > io_hdr_v4.response = (__u64)sense_buffer; > > io_hdr_v4.max_response_len = SENSE_BUFF_LEN; > > io_hdr_v4.request_len = cmd_len; > > io_hdr_v4.request = (__u64)cdb; > > > > > > > > > > ioctl(fd, SG_IO, &io_hdr_v4)) > > Hi Bean, > > I'm not sure where the above comes from? The Android RPMB client uses > slightly different code. Additionally, the retry loop around the > submission of SG/IO commands is very important. See also the > check_sg_io_hdr() call in send_ufs_rpmb_req(). See also > https://cs.android.com/android/platform/superproject/+/master:system/core/trusty/storage/proxy/rpmb.c > > Bart, It is from the ufs-utils. So, do you vote to add the UFS RPMB driver based on this new framework to resolve this conflict? Kind regards, Bean > Thanks, > > Bart.
