2018-10-07 22:30:34 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
/*
|
|
|
|
* UFS Transport SGIO v4 BSG Message Support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2011-2013 Samsung India Software Operations
|
scsi: ufs: Add a bsg endpoint that supports UPIUs
For now, just provide an API to allocate and remove ufs-bsg node. We
will use this framework to manage ufs devices by sending UPIU
transactions.
For the time being, implements an empty bsg_request() - will add some
more functionality in coming patches.
Nonetheless, we reveal here the protocol we are planning to use: UFS
Transport Protocol Transactions. UFS transactions consist of packets
called UFS Protocol Information Units (UPIU).
There are UPIU’s defined for UFS SCSI commands, responses, data in and
data out, task management, utility functions, vendor functions,
transaction synchronization and control, and more.
By using UPIUs, we get access to the most fine-grained internals of this
protocol, and able to communicate with the device in ways, that are
sometimes beyond the capacity of the ufs driver.
Moreover and as a result, our core structure - ufs_bsg_node has a pretty
lean structure: using upiu transactions that contains the outmost
detailed info, so we don't really need complex constructs to support it.
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <Bart.VanAssche@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-10-07 22:30:35 +08:00
|
|
|
* Copyright (C) 2018 Western Digital Corporation
|
2018-10-07 22:30:34 +08:00
|
|
|
*/
|
|
|
|
#ifndef SCSI_BSG_UFS_H
|
|
|
|
#define SCSI_BSG_UFS_H
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This file intended to be included by both kernel and user space
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define UFS_CDB_SIZE 16
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct utp_upiu_header - UPIU header structure
|
|
|
|
* @dword_0: UPIU header DW-0
|
|
|
|
* @dword_1: UPIU header DW-1
|
|
|
|
* @dword_2: UPIU header DW-2
|
|
|
|
*/
|
|
|
|
struct utp_upiu_header {
|
|
|
|
__be32 dword_0;
|
|
|
|
__be32 dword_1;
|
|
|
|
__be32 dword_2;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct utp_upiu_query - upiu request buffer structure for
|
|
|
|
* query request.
|
|
|
|
* @opcode: command to perform B-0
|
|
|
|
* @idn: a value that indicates the particular type of data B-1
|
|
|
|
* @index: Index to further identify data B-2
|
|
|
|
* @selector: Index to further identify data B-3
|
|
|
|
* @reserved_osf: spec reserved field B-4,5
|
|
|
|
* @length: number of descriptor bytes to read/write B-6,7
|
|
|
|
* @value: Attribute value to be written DW-5
|
|
|
|
* @reserved: spec reserved DW-6,7
|
|
|
|
*/
|
|
|
|
struct utp_upiu_query {
|
|
|
|
__u8 opcode;
|
|
|
|
__u8 idn;
|
|
|
|
__u8 index;
|
|
|
|
__u8 selector;
|
|
|
|
__be16 reserved_osf;
|
|
|
|
__be16 length;
|
|
|
|
__be32 value;
|
|
|
|
__be32 reserved[2];
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct utp_upiu_cmd - Command UPIU structure
|
|
|
|
* @data_transfer_len: Data Transfer Length DW-3
|
|
|
|
* @cdb: Command Descriptor Block CDB DW-4 to DW-7
|
|
|
|
*/
|
|
|
|
struct utp_upiu_cmd {
|
|
|
|
__be32 exp_data_transfer_len;
|
|
|
|
u8 cdb[UFS_CDB_SIZE];
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct utp_upiu_req - general upiu request structure
|
|
|
|
* @header:UPIU header structure DW-0 to DW-2
|
|
|
|
* @sc: fields structure for scsi command DW-3 to DW-7
|
|
|
|
* @qr: fields structure for query request DW-3 to DW-7
|
|
|
|
*/
|
|
|
|
struct utp_upiu_req {
|
|
|
|
struct utp_upiu_header header;
|
|
|
|
union {
|
|
|
|
struct utp_upiu_cmd sc;
|
|
|
|
struct utp_upiu_query qr;
|
scsi: ufs: Add a bsg endpoint that supports UPIUs
For now, just provide an API to allocate and remove ufs-bsg node. We
will use this framework to manage ufs devices by sending UPIU
transactions.
For the time being, implements an empty bsg_request() - will add some
more functionality in coming patches.
Nonetheless, we reveal here the protocol we are planning to use: UFS
Transport Protocol Transactions. UFS transactions consist of packets
called UFS Protocol Information Units (UPIU).
There are UPIU’s defined for UFS SCSI commands, responses, data in and
data out, task management, utility functions, vendor functions,
transaction synchronization and control, and more.
By using UPIUs, we get access to the most fine-grained internals of this
protocol, and able to communicate with the device in ways, that are
sometimes beyond the capacity of the ufs driver.
Moreover and as a result, our core structure - ufs_bsg_node has a pretty
lean structure: using upiu transactions that contains the outmost
detailed info, so we don't really need complex constructs to support it.
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <Bart.VanAssche@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-10-07 22:30:35 +08:00
|
|
|
struct utp_upiu_query tr;
|
|
|
|
/* use utp_upiu_query to host the 4 dwords of uic command */
|
|
|
|
struct utp_upiu_query uc;
|
2018-10-07 22:30:34 +08:00
|
|
|
};
|
|
|
|
};
|
scsi: ufs: Add a bsg endpoint that supports UPIUs
For now, just provide an API to allocate and remove ufs-bsg node. We
will use this framework to manage ufs devices by sending UPIU
transactions.
For the time being, implements an empty bsg_request() - will add some
more functionality in coming patches.
Nonetheless, we reveal here the protocol we are planning to use: UFS
Transport Protocol Transactions. UFS transactions consist of packets
called UFS Protocol Information Units (UPIU).
There are UPIU’s defined for UFS SCSI commands, responses, data in and
data out, task management, utility functions, vendor functions,
transaction synchronization and control, and more.
By using UPIUs, we get access to the most fine-grained internals of this
protocol, and able to communicate with the device in ways, that are
sometimes beyond the capacity of the ufs driver.
Moreover and as a result, our core structure - ufs_bsg_node has a pretty
lean structure: using upiu transactions that contains the outmost
detailed info, so we don't really need complex constructs to support it.
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <Bart.VanAssche@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-10-07 22:30:35 +08:00
|
|
|
|
|
|
|
/* request (CDB) structure of the sg_io_v4 */
|
|
|
|
struct ufs_bsg_request {
|
|
|
|
uint32_t msgcode;
|
|
|
|
struct utp_upiu_req upiu_req;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* response (request sense data) structure of the sg_io_v4 */
|
|
|
|
struct ufs_bsg_reply {
|
|
|
|
/*
|
|
|
|
* The completion result. Result exists in two forms:
|
|
|
|
* if negative, it is an -Exxx system errno value. There will
|
|
|
|
* be no further reply information supplied.
|
|
|
|
* else, it's the 4-byte scsi error result, with driver, host,
|
|
|
|
* msg and status fields. The per-msgcode reply structure
|
|
|
|
* will contain valid data.
|
|
|
|
*/
|
|
|
|
uint32_t result;
|
|
|
|
|
|
|
|
/* If there was reply_payload, how much was received? */
|
|
|
|
uint32_t reply_payload_rcv_len;
|
|
|
|
|
|
|
|
struct utp_upiu_req upiu_rsp;
|
|
|
|
};
|
2018-10-07 22:30:34 +08:00
|
|
|
#endif /* UFS_BSG_H */
|