| Message ID | 1536313783-13025-1-git-send-email-avri.altman@wdc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | scsi: ufs bsg endpoint | expand |
On Fri, 2018-09-07 at 12:49 +0300, Avri Altman wrote: > drivers/scsi/ufs/Kconfig | 19 +++ > drivers/scsi/ufs/Makefile | 3 + > drivers/scsi/ufs/ufs.h | 30 ---- > drivers/scsi/ufs/ufs_bsg.c | 327 ++++++++++++++++++++++++++++++++++++++++ > drivers/scsi/ufs/ufs_bsg.h | 67 +++++++++ > drivers/scsi/ufs/ufshcd.c | 362 ++++++++++++++++++++++++++++++----------- > ---- > drivers/scsi/ufs/ufshcd.h | 8 + > drivers/scsi/ufs/ufshci.h | 25 ++-- Since this patch series does not touch any include/uapi header and since no uapi UFS header files already exist, how is user space software expected to know which message format it should use for communicating over the UFS BSG endpoint? I don't think that "read the source" is an acceptable answer. Thanks, Bart.
Hi Bart, > Since this patch series does not touch any include/uapi header and since no > uapi UFS header files already exist, how is user space software expected to > know which message format it should use for communicating over the UFS BSG > endpoint? I don't think that "read the source" is an acceptable answer. I was thinking in V5 to move some of the notations from include/uapi to ufs_bsg.h. Or, I can add a "bsg support" paragraph to Documentation/scsi/ufs.txt, Or even a new entry to Documentation/ABI/testing/ - whatever you think is best? Thanks, Avri > > Thanks, > > Bart.
On 09/15/18 23:41, Avri Altman wrote: >> Since this patch series does not touch any include/uapi header and since no >> uapi UFS header files already exist, how is user space software expected to >> know which message format it should use for communicating over the UFS BSG >> endpoint? I don't think that "read the source" is an acceptable answer. > > I was thinking in V5 to move some of the notations from include/uapi to ufs_bsg.h. > Or, I can add a "bsg support" paragraph to Documentation/scsi/ufs.txt, > Or even a new entry to Documentation/ABI/testing/ - whatever you think is best? Adding a paragraph to Documentation/scsi/ufs.txt sounds like a good idea to me. Thanks, Bart.
> > On 09/15/18 23:41, Avri Altman wrote: > >> Since this patch series does not touch any include/uapi header and since no > >> uapi UFS header files already exist, how is user space software expected to > >> know which message format it should use for communicating over the UFS > BSG > >> endpoint? I don't think that "read the source" is an acceptable answer. > > > > I was thinking in V5 to move some of the notations from include/uapi to > ufs_bsg.h. > > Or, I can add a "bsg support" paragraph to Documentation/scsi/ufs.txt, > > Or even a new entry to Documentation/ABI/testing/ - whatever you think is > best? > > Adding a paragraph to Documentation/scsi/ufs.txt sounds like a good idea > to me. Done. Thanks, Avri > > Thanks, > > Bart.
Here is a proposal to use a bsg endpoint to manage ufs devices. We will do that by adding a bsg device node to the ufs driver, and use it to send UPIU transactions to the ufs device. It will serve as a ufs device management infrastructure, for device configuration, provisioning, testing and validation, etc. We added a new ufs-bsg module, and some new API to the ufs driver. For the time being, we will not use it for data transfer, but just for device management per-se. This has nothing to do with the recent removal of bsg read/write support, we might add this capability in the future, but it is not our current focus. We tested it on a Hikey-960 platform with a V4.14 kernel, "modernized" by recent bsg and ufs patches. We also used a htc11 with a V4.4 kernel, but needed much more transport/bsg/ufs patches to make it relevant. V3->v4: Squashed the bsg node Instantiation into "Add ufs-bsg". Build ufs-bsg as part of ufshcd-core and not as a separate module. Also merged the ufs_bsg_node into the ufs_hba structure. Christoph refactored the task management code, cleaning it up and making it much more readable - attached as the first 2 patches In the series. Afterward passing an external upiu to ufshcd_issue_tm_cmd Just blends in. V2->v3: We dropped the scsi transport code (and changed this patch title to account for it) as we actually just need the bsg device node. We also withdraw (brokenhearted) from our intension to create several bsg devices, and add just one. Rephrased the doc in Kconfig. V1->v2: Use inline functions instead of defines, and ida to obtain the port indices, in scsi_transport_ufs module. Remove the closing data pointer and __packed notation from struct ufs_bsg_{request_reply}. Re-use ufshcd_issue_tm_cmd code - needed a couple of patches for that, and call req_upiu and rsp_upio with their appropriate struct pointers. Use a more appropriate name when checking if enough memory was allocated for write descriptor, and remove redundant goto. Add reference to the spec to explain uic command size. Fix a lot of typos. Avri Altman (5): scsi: ufs: Allow ufshcd_issue_tm_cmd accept raw upiu scsi: ufs: Add ufs-bsg module scsi: ufs: Add API to execute raw upiu commands scsi: ufs-bsg: Add support for raw upiu in ufs_bsg_request() scsi: ufs-bsg: Add support for uic commands in ufs_bsg_request() Christoph Hellwig (2): scsi: ufs: cleanup struct utp_task_req_desc scsi: ufs: add a low-level __ufshcd_issue_tm_cmd helper drivers/scsi/ufs/Kconfig | 19 +++ drivers/scsi/ufs/Makefile | 3 + drivers/scsi/ufs/ufs.h | 30 ---- drivers/scsi/ufs/ufs_bsg.c | 327 ++++++++++++++++++++++++++++++++++++++++ drivers/scsi/ufs/ufs_bsg.h | 67 +++++++++ drivers/scsi/ufs/ufshcd.c | 362 ++++++++++++++++++++++++++++++--------------- drivers/scsi/ufs/ufshcd.h | 8 + drivers/scsi/ufs/ufshci.h | 25 ++-- 8 files changed, 681 insertions(+), 160 deletions(-) create mode 100644 drivers/scsi/ufs/ufs_bsg.c create mode 100644 drivers/scsi/ufs/ufs_bsg.h