Novel approach to encode HASH pointer in UTP transfer request descriptor
By repurposing the PRDT entry or using an HP-specific structure to store hash pointers, the UTRD size is maintained, addressing the performance and cost issues associated with expanded UTRDs, enhancing UFS host controller efficiency and reducing resource consumption.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- QUALCOMM INC
- Filing Date
- 2024-11-26
- Publication Date
- 2026-06-04
AI Technical Summary
The expansion of UFS transport protocol (UTP) transfer request descriptors (UTRDs) to include hash pointers (HPs) for hardware-based inline hashing increases the size of the UTRD data structure, impacting RAM size and UFS host controller hardware design, leading to performance degradation or increased costs.
Repurpose the physical region description table (PRDT) entry data structure to contain the HP or use an HP-specific data structure (HPT) after the PRDT, maintaining the UTRD size at eight DWs while indicating the location of hash values, thus minimizing RAM size and design impact.
This approach maintains UTRD size and reduces RAM and power consumption, improving UFS host controller performance and efficiency without increasing hardware costs.
Smart Images

Figure CN2024134466_04062026_PF_FP_ABST
Abstract
Description
NOVEL APPROACH TO ENCODE HASH POINTER IN UTP TRANSFER REQUEST DESCRIPTORFIELD OF THE DISCLOSURE
[0001] Aspects of the present disclosure generally relate to wireless communication and specifically relate to techniques, apparatuses, and methods associated with encoding a hash pointer in a universal flash storage transport layer transfer request descriptor.BACKGROUND
[0002] Memory devices are widely used to store information in various electronic devices. A memory device includes memory cells. A memory cell is an electronic circuit capable of being programmed to a data state of two or more data states. For example, a memory cell may be programmed to a data state that represents a single binary value, often denoted by a binary “1” or a binary “0. ” To store information, an electronic device may write to, or program, a set of memory cells. To access the stored information, the electronic device may read, or sense, the stored state from the set of memory cells.
[0003] Various types of memory devices exist, including random access memory (RAM) , read only memory (ROM) , dynamic RAM (DRAM) , static RAM (SRAM) , synchronous dynamic RAM (SDRAM) , ferroelectric RAM (FeRAM) , magnetic RAM (MRAM) , resistive RAM (RRAM) , holographic RAM (HRAM) , flash memory (e.g., NAND memory and NOR memory) , and others. A memory device may be volatile or non-volatile. Non-volatile memory (e.g., flash memory) can store data for extended periods of time even in the absence of an external power source. Volatile memory (e.g., DRAM) may lose stored data over time unless the volatile memory is refreshed by a power source.
[0004] In some examples, a host device may employ various protocols or systems to ensure an integrity and / or security of software running on the host device. For example, a host device may employ a hardware-based, inline hashing procedure to ensure integrity of data received from a memory device, such as a universal flash storage (UFS) memory device or a similar memory device. In such examples, the host device may calculate cryptographic hash values and / or the host device may associate the cryptographic hash values with data. In some examples, for security purposes or similar reasons, the cryptographic hash value calculation may be performed by a cryptographic hash engine located in a UFS host controller of the host device.SUMMARY
[0005] Some aspects described herein relate to a method performed by a universal flash storage (UFS) host controller. The method may include accessing a UFS transport protocol (UTP) transfer request that includes a hash pointer (HP) indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored. The method may include reading the HP from the data structure. The method may include accessing the one or more hash values in the memory location indicated by the HP.
[0006] Some aspects described herein relate to a UFS host device. The UFS host device may include one or more memories and one or more processors coupled to the one or more memories. The one or more processors may be configured to access a UTP transfer request that includes an HP indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored. The one or more processors may be configured to read the HP from the data structure. The one or more processors may be configured to access the one or more hash values in the memory location indicated by the HP.
[0007] Some aspects described herein relate to a non-transitory computer-readable medium that stores a set of instructions. The set of instructions, when executed by a UFS host controller, may cause the UFS host controller to access a UTP transfer request that includes an HP indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored. The set of instructions, when executed by the UFS host controller, may cause the UFS host controller to read the HP from the data structure. The set of instructions, when executed by the UFS host controller, may cause the UFS host controller to access the one or more hash values in the memory location indicated by the HP.
[0008] Some aspects described herein relate to an apparatus. The apparatus may include means for accessing a UTP transfer request that includes an HP indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored. The apparatus may include means for reading the HP from the data structure. The apparatus may include means for accessing the one or more hash values in the memory location indicated by the HP.
[0009] Aspects of the present disclosure may generally be implemented by or as a method, apparatus, system, computer program product, non-transitory computer-readable medium, user equipment, base station, network node, network entity, wireless communication device, and / or processing system as substantially described with reference to, and as illustrated by, this specification and accompanying drawings.
[0010] The foregoing paragraphs of this section have broadly summarized some aspects of the present disclosure. These and additional aspects and associated advantages will be described hereinafter. The disclosed aspects may be used as a basis for modifying or designing other aspects for carrying out the same or similar purposes of the present disclosure. Such equivalent aspects do not depart from the scope of the appended claims. Characteristics of the aspects disclosed herein, both their organization and method of operation, together with associated advantages, will be better understood from the following description when considered in connection with the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The appended drawings illustrate some aspects of the present disclosure but are not limiting of the scope of the present disclosure because the description may enable other aspects. Each of the drawings is provided for purposes of illustration and description, and not as a definition of the limits of the claims. The same or similar reference numbers in different drawings may identify the same or similar elements.
[0012] Fig. 1 is a diagram illustrating an example associated with universal flash storage (UFS) , in accordance with the present disclosure.
[0013] Fig. 2 is a diagram illustrating an example associated with cryptographic hash generation for UFS devices, in accordance with the present disclosure.
[0014] Figs. 3A-3B are diagrams illustrating an example associated with storing hash pointers (HPs) in UFS transport protocol (UTP) transfer request descriptors, in accordance with the present disclosure.
[0015] Fig. 4 is a diagram illustrating an example associated with encoding an HP in a UTP transfer request, in accordance with the present disclosure.
[0016] Figs. 5A-5B are diagrams illustrating another example associated with encoding an HP in a UTP transfer request, in accordance with the present disclosure.
[0017] Fig. 6 is a diagram of example components of a device, in accordance with the present disclosure.
[0018] Fig. 7 is a flowchart of an example process associated with encoding an HP associated with a UTP transfer request, in accordance with the present disclosure.DETAILED DESCRIPTION
[0019] Various aspects of the present disclosure are described hereinafter with reference to the accompanying drawings. However, aspects of the present disclosure may be embodied in many different forms. The present disclosure is not to be construed as limited to any specific aspect illustrated by or described with reference to an accompanying drawing or otherwise presented in this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. One skilled in the art may appreciate that the scope of the disclosure is intended to cover any aspect of the disclosure disclosed herein, whether implemented independently of or in combination with any other aspect of the disclosure. For example, an apparatus may be implemented or a method may be practiced using various combinations or quantities of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover an apparatus having, or a method that is practiced using, other structures and / or functionalities in addition to or other than the structures and / or functionalities with which various aspects of the disclosure set forth herein may be practiced. Any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.
[0020] Universal flash storage (UFS) is a specification for non-volatile memory. UFS was developed by the Joint Electron Device Engineering Council (JEDEC) solid state technology association. UFS may be utilized in a variety of electronic devices, such as smart phones, tablets, and digital cameras. UFS may offer a high-performance and efficient storage solution. UFS may provide high-speed data transfer capabilities, which may be useful for high-resolution video recording, fast application loading, and / or quick data transfers. UFS may support simultaneous read and write operations, known as full duplex, which may enhance a multitasking performance. UFS may be power-efficient, which may be beneficial for mobile devices and similar applications. UFS may utilize a command queue, allowing for multiple commands to be processed in parallel, which may improve overall efficiency and performance. The command queue may reduce power usage during data processing.
[0021] In some examples, a host device may employ various protocols or systems to ensure an integrity and / or security of software running on the host device. For example, the host device may use a verified boot (VB) process, which is a process of assuring the end user of the integrity of the software running on a device. A VB process typically starts with a read-only portion of the device firmware that loads code and executes the code only after cryptographically verifying that the code is authentic and does not have any known security flaws. A VB process may leverage a Linux kernel driver dm-verity, which is used to check the integrity of a block device. Dm-verity works by verifying the integrity of each device block as it is read from a disk and using a pre-calculated hash tree. This Linux kernel approach has several drawbacks. For example, utilizing the Linux kernel driver dm-verity consumes central processing unit (CPU) cycles to generate a cryptographic hash value (e.g., a hash value associated with secure hash algorithm 256 (SHA256) , among other examples) and / or utilizing the Linux kernel driver dm-verity adds scheduling overhead because this task is normally deferred to kernel threads.
[0022] To overcome the drawbacks of software-based hashing, such as the VB process described above, a host device may employ hardware-based, inline hashing. In such examples, the host device may calculate cryptographic hash values (such as hash values associated with SHA256, among other examples) and / or the host device may associate the cryptographic hash values with data. For example, in examples in which the host device calculates hash values associated with SHA256, the host device (e.g., a UFS host controller located at the host device) may create a 256-bit (e.g., a 32-byte) hash value for every 4 kibibytes (KiB) block of data. In some examples, for security purposes or similar reasons, the cryptographic hash value calculation may be performed by a cryptographic hash engine located in the UFS host controller. In such examples, a UFS transport protocol (UTP) transfer request descriptor (UTRD) may be expanded to include a hash pointer (HP) (e.g., a metadata address pointing to a portion of host memory storing one or more hash values) , and the UFS host controller hardware may store the hash values in host memory indicated by the HP.
[0023] The UTRD may be the main method of communication between host software and the UFS host controller hardware. The UTRD describes which commands are to be executed, and data transfer operations that are part of those commands. In certain versions of the UFS host controller interface (UFSHCI) JEDEC standard, the UTRD is eight double words (DWs) , with each DW corresponding to a character string that is 32 bits in length (e.g., thus the UTRD is 32 bytes in size) . Moreover, an internal random access memory (RAM) or similar volatile memory inside the UFS host controller may be used to cache UTRDs. In that regard, the maximum quantity of UTRDs that can be consumed by UFS host controller hardware simultaneously may be limited by the RAM size or other volatile memory size. Moreover, expanding a UTRD to include the HP may require increasing the UTRD data structure size from eight DWs to eleven DWs, such as for a purpose of supporting hardware-based, inline hashing. Increasing the UTRD from eight DWs to eleven DWs may have a sizeable impact on a UFS host controller hardware design. For example, if internal RAM size at the UFS host controller is not increased to accommodate the extended UTRD, the maximum number of UTRDs that can be consumed by UFS host controller hardware will decrease, adversely impacting performance of the UFS host controller. On the other hand, if internal RAM size at the UFS host controller is increased in order to accommodate the extended UTRD, cost and die size will increase.
[0024] Various aspects relate generally to memory devices and / or associated host devices. Some aspects more specifically relate to UFS-based memory devices and / or UFS host devices. For example, some aspects relate to more efficient storage of HPs associated with UFS-based memory devices and / or UFS host devices. In some aspects, a UFS host controller may access a UTP transfer request that includes an HP indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure. The UFS host controller may read the HP from the data structure and access the one or more hash values in the memory location indicated by the HP. In some aspects, the HP indicator may be included as part of a physical region description table (PRDT) entry data structure associated with the UTP transfer request, and the HP may be stored within the PRDT (e.g., the PRDT may be repurposed to contain the HP, and / or a reserved bit and / or field within the PRDT may be used as the HP indicator) . In some other aspects, the HP may be stored in an HP-specific data structure (sometimes referred to herein as an HP data structure and / or an HP table (HPT) ) that is located in host memory directly after the PRDT. In such aspects, a UTRD associated with the UTP transfer request may include the HP indicator (e.g., the HP indicator may be a repurposed reserved bit associated with the UTRD to indicate that an HP is stored in the HPT) and / or the UFS host controller may access the HP using the information provided about the PRDT in the UTRD (e.g., using a base address, PRDT offset, and / or PRDT length, among other information) . In some aspects, the HPT may consecutively store multiple HPs, and each HP may include a one-bit indicator to indicate whether that HP is the last HP in the HPT.
[0025] Particular aspects of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. In some examples, by repurposing a PRDT entry data structure to contain an HP and / or by placing the HP data structure (e.g., HPT) right after the PRDT in host memory, the size of a UTRD data structure specified by certain versions of the JEDEC standard remains unchanged (e.g., remains at eight DW and / or 32 bytes) . In this way, particular aspects of the subject matter described in this disclosure can be implemented to minimize the impact to RAM size and UFS host controller hardware design associated with an inline-hashing process, thereby improving UFS host controller performance and / or reducing power, computing, and storage resource consumption otherwise associated with inefficient performance of the UFS host controller associated with storing and / or processing extended UTRDs.
[0026] Fig. 1 is a diagram illustrating an example 100 associated with UFS, in accordance with the present disclosure.
[0027] As shown in Fig. 1, a host device 102, such as a UFS host, may communicate with a memory device 104, such as a UFS device. The host device 102 may be associated with an application processor or a system on chip (SoC) , for example, in a mobile device. The memory device 104 may include a controller and non-volatile memory, such as flash memory. The host device 102 may communicate with the memory device 104 via an interconnect. The interconnect may utilize a high-speed interface to allow for rapid data transfer between the host device 102 and the memory device 104.
[0028] In some examples, the host device 102 may include a UFS host controller 106 (e.g., the application processor and / or system-on-chip (SoC) of the host device 102 may include the UFS host controller 106) . The UFS host controller 106 may be a hardware component of the host device 102 that manages communication between the host device 102 and the memory device 104 (e.g., the UFS device) . In some examples, the UFS host controller 106 may be responsible for interpreting commands, managing data transfers, ensuring efficient and reliable interactions with the UFS device, and / or performing similar tasks. More particularly, the UFS host controller 106 may perform command processing tasks (e.g., tasks associated with interpreting and managing commands from the host device 102 to the memory device 104, such as read, write, and / or erase operations) , data transfer management tasks (e.g., tasks associated with data transfer between the host device 102 and the memory device 104, such as data transfer via high-speed interfaces like mobile industry processor interface (MIPI) M-PHY and unified protocol (UniPro) , among other examples) , power management tasks, error checking and correction tasks, and / or similar tasks. In some examples, the UFS host controller 106 may be part of an SoC in mobile and embedded systems.
[0029] As indicated above, Fig. 1 is provided as an example. Other examples may differ from what is described with regard to Fig. 1.
[0030] Fig. 2 is a diagram illustrating an example 200 associated with cryptographic hash generation for UFS devices, in accordance with the present disclosure.
[0031] As described above, to overcome the drawbacks of software-based hashing or for a similar purpose, a host device may employ hardware-based, inline hashing. For example, as shown in Fig. 2, a host device (e.g., host device 102) may include an SoC 202, which may include a central processing unit (CPU) 204, a memory controller 206, and / or a UFS host controller 208 (e.g., UFS host controller 106) , among other components. In some examples, the UFS host controller 208 may include a cryptographic hash engine 210 capable of performing cryptographic hash calculations on data received from certain memory locations, such as from a UFS device 216 (e.g., memory device 104) . For example, the cryptographic hash engine 210 may be a hardware component located within the UFS host controller 208 that is capable of performing cryptographic hash value calculations associated with SHA256 or similar SHA standards. The UFS host controller 208 may include additional blocks and / or components configured to interface with the UFS device 216, such as a UniPro component 212, an M-PHY component 214, and / or a similar component configured to enable communications and / or data transfer with the UFS device 216 via an interface 217. In such examples, the UFS device 216 may include similar components (e.g., a UniPro component 218, an M-PHY component 220, and / or a similar component) configured to enable communications and / or data transfer with the SoC 202 (and, more particularly, the UFS host controller 208) via the interface 217.
[0032] The cryptographic hash engine 210 may be capable of performing cryptographic hash value calculations on data as the data is copied and / or transferred from the UFS device 216 to a host memory space, such as to a RAM 222 associated with the host device. In that regard, the memory controller 206 may be a component of the SoC 202 configured to communicate with the RAM 222 and / or otherwise control operations of the RAM 222 via the interface 223. In such aspects, as data 224 is requested from the UFS device 216 (e.g., via host software and / or an application running at the host device) , the data passes from the UFS device 216 to the UFS host controller 208 (e.g., via interface 217) , and, more particularly, to the cryptographic hash engine 210 of the UFS host controller 208. The cryptographic hash engine 210 may calculate a hash value 226 associated with the data 224, such as by calculating a 256-bit hash value for every 4 KiB block of data 224, in examples in which the cryptographic hash engine 210 performs hash calculations in accordance with SHA256. The UFS host controller 208, via the memory controller 206, may then store the data 224 and the hash value 226 in host memory (e.g., RAM 222) , such as for subsequent access by host software and / or an application running at the host device.
[0033] In some examples, an HP may be used to indicate a location in host memory (e.g., RAM 222) at which the hash value 226 is stored. In that regard, the HP is a pointer, data structure, metadata address, and / or reference mechanism that points to a specific block or location of data in memory or storage (e.g., RAM 222) where a hash value (e.g., hash value 226) is located. In some examples, when performing hardware-based, inline hashing as described above, a UTRD may be expanded to include an HP, such that the UFS host controller 208, after calculating the hash values for each transaction (e.g., using the cryptographic hash engine 210 of the UFS host controller 208) , may store the hash values into host memory where the HP points. Aspects of using an extended UTRD to indicate an HP is described in more detail below in connection with Figs. 3A-3B.
[0034] The host device 102, SoC 202, memory device 104, UFS device 216, UFS host controller 106, UFS host controller 208, CPU 204, cryptographic hash engine 210, memory controller 206, RAM 222, or any other component (s) of Fig. 1 and / or Fig. 2 may implement one or more techniques or perform one or more operations associated with encoding a hash pointer in a UTP transfer request, as described in more detail elsewhere herein. For example, the host device 102, SoC 202, memory device 104, UFS device 216, UFS host controller 106, UFS host controller 208, CPU 204, cryptographic hash engine 210, memory controller 206, RAM 222 may perform or direct operations of, for example, process 700 of Fig. 7, or other processes as described herein (alone or in conjunction with one or more other processors) . Memory of the host device 102 and / or SoC 202 may store data and program code (or instructions) for the host device 102 and / or SoC 202, such as configuration information and / or context information. In some examples, the memory of the host device 102 and / or SoC 202 may store data relating to a UFS device 216. Memory of a memory device 104 and / or UFS device 216 may store data and program code (or instructions) for the memory device 104 and / or UFS device 216, such as configuration information and / or context information. In some examples, the memory of the memory device 104 and / or UFS device 216 or the memory of the host device 102 and / or SoC 202 may include a non-transitory computer-readable medium storing a set of instructions for memory operations. For example, the set of instructions, when executed by one or more processors (for example, the UFS host controller 208, the memory controller 206, and / or a controller associated with the UFS device 216) of the host device 102, SoC 202, memory device 104, and / or UFS device 216, may cause the one or more processors to perform process 700 of Fig. 7, or other processes as described herein. In some examples, executing instructions may include running the instructions, converting the instructions, compiling the instructions, and / or interpreting the instructions, among other examples.
[0035] Figs. 3A-3B are diagrams illustrating an example 300 associated with storing HPs in UTRDs, in accordance with the present disclosure.
[0036] More particularly, Fig. 3A shows an example UFS host controller interface 300. The UFS host controller interface 300 may define the interaction between a UFS host (e.g., a CPU or SoC, such as SoC 202) and a UFS storage device (e.g., UFS device 216) . In some examples, the UFS host controller interface 300 provides a standardized way to issue commands, manage data transfers, and handle responses between a UFS host and a UFS device.
[0037] As shown in Fig. 3A, the UFS host controller interface 300 may be associated with an input / output (IO) memory register space 302 and a host memory space 304. The IO memory register space 302 includes a set of memory-mapped registers 306 within the UFS host controller (e.g., UFS host controller 208) . In some examples, the memory-mapped registers 306 may be used to configure the UFS host device (e.g., host device 102) , monitor the UFS host device’s status, control the UFS host device’s operations, and / or similar purposes. For example, and as shown in Fig. 3A, the memory-mapped registers 306 may include a host controller capabilities register, an interrupt and host status register, a UTP transfer request register, a UTP task management request register, a UFS interconnect (UIC) command register, one or more vendor specific registers, and / or one or more other registers.
[0038] The host memory space 304 may be system memory (e.g., RAM 222) managed by the host CPU (e.g., via memory controller 206) in which data structures and / or buffers used for UFS operations are stored. For example, the host memory space 304 may be used to store multiple (e.g., N) UTRDs 308 (shown in Fig. 3A as a first UTRD 308-1 through an Nth UTRD 308-N and indexed as UTRD 0 through UTRD N-1) , which may describe commands and data flow between the UFS host device and the UFS device. The UFS host controller may process the UTRDs 308 to execute UFS transactions.
[0039] Each UTRD 308 may include a pointer to a corresponding command UFS protocol information unit (UPIU) (e.g., a protocol packet exchanged between the host and UFS device) , a corresponding response UPIU, and, optionally, a corresponding PRDT. In some examples, the command UPIU, response UPIU, and optional PRDT for a given UTRD 308 may be collectively referred to as a UTP command descriptor (UCD) 310 (shown in Fig. 3A as a first UCD 310-1 through an Nth UCD 310-N) . The command UPIUs and response UPIUs may contain commands sent to the UFS device and / or responses received from the UFS device, among other examples. The optional PRDTs may point to memory locations of data buffers 312 (shown in Fig. 3A as a first data buffer 312-1 and an Nth data buffer 312-N) in the host memory space 304 associated with a given UTRD 308. In that regard, each PRDT may indicate a base address associated with the data buffer 312 (e.g., a starting location of the data buffer 312) , a data length of the data buffer 312 (e.g., a size of the data buffer 312) , and / or control information associated with the data buffer 312, which is described in more detail below in connection with Fig. 4. The data buffer 312, in turn, may be used to store actual payload data for read and write operations associated with the UFS device.
[0040] In some examples, a UTRD 308 may be expanded to include an HP, such that the UFS host controller hardware, when processing a UTP transfer request, can store the hash values into host memory where the HP points, and / or access hash values from the host memory where the HP points. More particularly, as shown in Fig. 3B, as indicated by reference number 314, according to certain versions of the UFSHCI JEDEC standard, a traditional UTRD may be associated with eight DWs (indexed in Fig. 3B as DW0 through DW7, and as shown without hatching) , with each DW corresponding to a character string that is 32 bits in length (e.g., thus a traditional UTRD may be 32 bytes in size) . More particularly, bits [7: 0] of DW0 may be used as a cryptographic configuration index (CCI) field, bits [15: 8] of DW0 may be used as a total extended header segments (EHS) length field, bits [22: 16] of DW0 may be reserved, bit
[0023] of DW0 may be used as a command enable (CE) field, bit
[0024] of DW0 may be used as an interrupt (I) field, bits [26: 25] of DW0 may be used as a data direction (DD) field, bit
[0027] of DW0 may be reserved, and / or bits [31: 28] of DW0 may be used as a command type field. DW1 may be used as a data unit number lower 32 bits (DUNL) field and DW3 may be used as a data unit number upper 32 bits (DUNU) field. Bits [7: 0] of DW2 may be used as an overall command status field, bits [15: 8] of DW2 may be used as a common data size (CDS) field, and bits [31: 16] of DW2 may be used as a last data bytes count (LDBC) field. Bits [6: 0] of DW4 may be reserved, bits [31: 7] of DW4 may be used as a UTP command descriptor base address field, and DW5 may be used as a UTP command descriptor base address upper 32 bits field. Bits [15: 0] and bits [31: 16] of DW6 may be used as a response UPIU length field and a response UPIU offset field, respectively, and bits [15: 0] and bits [31: 16] of DW7 may be used as a PRDT length field and a PRDT offset field, respectively.
[0041] In examples in which the UTRD is expanded to include an HP associated with the UTRD, the UTRD may include three additional DWs, such as the DWs indexed as DW8 through DW10 and shown using hatching in Fig. 3B. In such examples, bits [6: 0] of DW8 may be reserved, bits [31: 7] of DW8 may be used as a metadata address (e.g., HP) field, bits [31: 0] of the DW9 may be used as a metadata address upper 32 bits field, bits [15: 0] of DW10 may be reserved, and bits [31: 16] of DW10 may be used as a metadata length field. In such examples, in addition to providing information regarding the location of the command UPIU, the response UPIU, and the optional PRDT, among other information, the UTRD may provide information as to a location where one or more hash values associated with the UTRD are stored in the host memory space 304. For example, the host memory space 304 may include an array of hash values 316 associated with the UTRD, with the metadata address bits indicating a starting location of the array of hash values 316 in the host memory space 304 (as shown by the arrow indicated by reference number 318) and with the metadata length bits indicating a size of the array of hash values 316 (as shown by the arrow indicated by reference number 320) .
[0042] In some examples, an internal RAM or similar memory inside a UFS host controller may be used to cache UTRDs to be processed (e.g., to cache UTRDs associated with UTP transfer requests to be completed by the UFS host controller in order to optimize the execution of UFS commands and / or reduce latency associated with accessing the UTRDs) , such as one or more of the UTRDs shown in Fig. 3B. In that regard, the maximum quantity of UTRDs that may be simultaneously consumed by UFS host controller hardware is limited by the RAM size associated with the UFS host controller. Moreover, as described above in connection with Fig. 3B, expanding a UTRD to include the HP may require increasing the UTRD data structure size from eight DWs to eleven DWs, which may have an adverse impact on a UFS host controller hardware design. For example, assuming internal RAM size at the UFS host controller is not increased for a purpose of caching extended UTRDs, the maximum number of UTRDs which can be consumed by UFS host controller hardware will decrease, adversely impacting performance of the UFS host controller. On the other hand, if internal RAM size at the UFS host controller is increased to accommodate the extended UTRDs, cost and die size associated with the UFS host controller will increase.
[0043] Accordingly, in some aspects described herein, an HP associated with a UTRD may be stored in a data structure other than the UTRD in order to reduce an impact on UFS host controller hardware design while providing adequate information to a UFS host controller as to a location of one or more hash values associated with the UTRD. Aspects of storing an HP in a data structure other than the UTRD are described in more detail below in connection with Fig. 4 and Figs. 5A-5B.
[0044] As indicated above, Figs. 3A-3B are provided as examples. Other examples may differ from what is described with respect to Figs. 3A-3B.
[0045] Fig. 4 is a diagram illustrating an example 400 associated with encoding an HP in a UTP transfer request, in accordance with the present disclosure.
[0046] In some aspects, a data structure other than a UTRD may be used for a purpose of storing one or more HPs associated with a UTP transfer request. In such aspects, a UTP transfer request may be associated with an HP indicator to indicate whether that data structure contains one or more HPs (such as for a purpose of alerting a UFS host controller that the HP may be accessed at the data structure) . For example, in some aspects, the HP indicator bit may be a one-bit indicator that, when set to one of 0 or 1, indicates that the data structure includes the one or more HPs, and, when set to the other one of 0 or 1, indicates that the data structure does not include the one or more HPs. In such aspects, when a UFS host controller (e.g., UFS host controller 106 and / or UFS host controller 208) accesses a UTP transfer request (such as by accessing a UTRD cached in local RAM, among other examples) , the UFS host controller may identify whether the UTP transfer request is associated with an HP based on the HP indicator. If the HP indicator indicates that an HP associated with the UTP transfer request is encoded at a data structure, the UFS host controller may read the HP from the data structure and / or access the one or more hash values in a memory location indicated by the HP. On the other hand, if the HP indicator indicates that there is no HP encoded at a data structure, the UFS host controller may omit operations associated with accessing a hash value.
[0047] In some aspects, a PRDT entry data structure may be repurposed to contain an HP associated with a UTP transfer request. Put another way, the data structure described above (e.g., the data structure that is used to store the one or more HPs for the UTP transfer request) may be a PRDT entry data structure. In such aspects, a reserved field and / or bit of the PRDT may be used to indicate whether a specific PRDT entry is repurposed to contain an HP or not. Put another way, a reserved field and / or bit of the PRDT may be used as the HP indicator described above. In such aspects, upon accessing a PRDT, a UFS host controller may identify whether the PRDT is used as a normal PRDT (e.g., used as a pointer to data buffers that store a payload associated with the UTP transfer request) or else is used to store one or more HPs (e.g., used as a pointer to an array of hash values (e.g., array of hash values 316) ) based on whether the HP indicator is set.
[0048] More particularly, as shown in Fig. 4, and in a similar manner as described above in connection with the UCD 310 of Fig. 3A, a UCD 401 included in a host memory space (e.g., host memory space 304) may include a transfer request 402 (e.g., a command UPIU) , a transfer response 404 (e.g., a response UPIU) , and, optionally, a PRDT 406. In a similar manner as described above in connection with Figs. 3A-3B, a UTRD (e.g., UTRD 308) may indicate a location, in the host memory space, of the transfer request 402, the transfer response 404, and / or the PRDT 406, such as by indicating a base address associated with a start of the transfer request 402, a transfer response offset (shown in Fig. 4 as “RUO” ) associated with a start of the transfer response 404, and / or a PRDT offset (shown in Fig. 4 as “PRDTO” ) associated with a start of the PRDT 406, among other information.
[0049] As indicated by dashed lines in Fig. 4, the expanded PRDT 406 may include multiple DWs (e.g., four DWs, indexed DW0 through DW3 in Fig. 4) traditionally used to indicate a location of data buffers (e.g., data buffers 312) associated with the UTP transfer request. For example, the bits [31: 0] of DW0 and bits [31: 0] of DW1 may be used as a data base address field and a data base address upper 32 bits field, respectively, bits [31: 0] of DW2 may be reserved, bits [16: 0] of DW3 may used as a data base count field, and bits 31: 17 of DW3 may be reserved. In such aspects, one of the reserved bits (e.g., one of the reserved bits in DW2 or DW3) may be used as an HP indicator field. For example, as shown in Fig. 4, and as indicated by reference number 408, bit
[0031] of DW3 may be used as an HP indicator field. In such aspects, setting the HP indicator field to a certain value (e.g., 0) may be used to indicate that the PRDT entry is a normal PRDT entry (e.g., setting the HP indicator to 0 may be used to indicate that the PRDT entry points to a location of data buffers associated with a payload of the UTP transfer request) , while setting the HP indicator field to a different value (e.g., 1) may be used to indicate that the PRDT entry is an HP PRDT entry (e.g., setting the HP indicator to 1 may be used to indicate that the PRDT entry points to a location of one or more hash values associated with the UTP transfer request) .
[0050] In some other aspects, an HP-specific data structure, such as an HPT or similar data structure, may be used to store one or more HPs associated with a UTP transfer request. For example, Figs. 5A-5B are diagrams illustrating an example 500 associated with encoding an HP in a UTP transfer request, in accordance with the present disclosure. In this example, one or more HPs associated with a UTP transfer request may be stored in an HPT 502 located in a host memory space (e.g., host memory space 304) , such as at a portion of a host memory space that immediately follows a PRDT 406 associated with a given UTP transfer request. Put another way, in some aspects a transfer request 402 for a given UTP transfer request may be located at a first section of a UCD 501 in a host memory (e.g., host memory space 304) , a transfer response 404 for that UTP transfer request may be located at a second section of the UCD 501 that immediately follows the first section of the UCD 501, a PRDT 406 for that UTP transfer request may be located at a third section of the UCD 501 that immediately follows the second section of the UCD 501, and / or the HPT 502 for that UTP transfer request may be located at a fourth section of the UCD 501 that immediately follows the third section of the UCD 501.
[0051] In such aspects, the UFS host controller may access the HPT 502 using the information provided in the UTRD. For example, Fig. 5A shows a UTRD 503 that is similar to the UTRD described above in connection with reference number 314, but which does not include the hatched portions used in that example to indicate the HP. In that regard, the UTRD 503 may include only eight DWs as compared to the eleven DWs of the expanded UTRD described above in connection with reference number 314. Moreover, in a similar manner as described above in connection with Fig. 3B, the UTRD 503 may include information used to determine the location of the transfer request 402, the transfer response 404, and / or the PRDT 406 in host memory (e.g., host memory space 304) .
[0052] More particularly, the UTP command descriptor base address indicated by DW4 and / or DW5 may indicate a start location of the transfer request 402, as indicated by arrow 504. The response UPIU offset field indicated by DW6 may correspond to an RUO and / or may indicate a start location of the transfer response 404, as indicated by arrow 505. The PRDT offset field indicated by DW7 may correspond to a PRDTO and / or may indicate a start location of the PRDT 406, as indicated by arrow 506. Moreover, the PRDT length field indicated by DW7 may indicate a size of the PRDT 406, as indicated by reference number 507. In such examples, the UFS host controller may be capable of identifying a location of the HPT 502 using one or more of the fields in the UTRD 503. More particularly, because the HPT 502 may be provided in host memory immediately after the PRDT 406, as described above, the UFS host controller may fetch the one or more HPs using the base address (e.g., indicated by the UTP command descriptor base field) , the RUO (e.g., indicated by the response UPIU offset field) , the PRDTO (e.g., indicated by the PRDT offset field) , and / or the PRDT size (indicated by the PRDT length field) , among other information.
[0053] In aspects in which the HPT 502 is used to store the one or more HPs associated with the UTP transfer request, the UTRD 503 may include the HP indicator. For example, one of the reserved bits of the UTRD 503 (e.g., one reserved bit in DW0 or DW4) may be used as an HP indicator field. For example, as shown in Fig. 5A, and as indicated by reference number 508, bit
[0022] of DW0 may be used as an HP indicator field. In such aspects, setting the HP indicator field to a certain value (e.g., 0) may be used to indicate that an HPT 502 is not included for the UTP transfer request and / or that the UFS host controller otherwise does not need to access an HP for the UTP transfer request (e.g., if the HP indicator is set to 0 by host software, the UFS host controller may ignore the HP and / or HPT 502) , while setting the HP indicator field to a different value (e.g., 1) may be used to indicate that an HPT 502 is included for the UTP transfer request and / or that the UFS host controller is to access an HP for the UTP transfer request (e.g., if the HP indicator is set to 1 by host software, the UFS host controller may use the HP and / or HPT 502) . In such aspects, when the HP indicator field it set to indicate that the HPT 502 is included for the UTP transfer request, the UFS host controller may access the HPT 502 using the information provided in the UTRD 503 (e.g., the base address, the RUO, the PRDTO, and / or the PRDT size, among other information) because the HPT 502 may be located directly after the PRDT 406, as described above.
[0054] In some aspects, the HPT 502 may include multiple HP entries associated with the UTP transfer request. For example, in some aspects, the HPT 502 may include multiple HPs associated with the UTP transfer request that are consecutively stored in the HPT 502. In such aspects, each HP entry in the HPT 502 may be associated with a respective chained indicator (shown as “C” in Fig. 5B) that indicates whether that HP is a last HP in the HPT 502 or whether one or more HP entries consecutively follow that HP entry in the HPT 502. In this way, when using the HPT 502 to indicate multiple HP entries, the host software or similar application does not need to indicate to the UFS host controller how many HP entries are included in the HPT 502, but instead may simply set a chained indicator bit for a last HP entry to indicate that no additional HPs follow the last HP entry.
[0055] More particularly, as shown in Fig. 5B, and as indicated using dashed lines in connection with the HPT 502, the HPT 502 may be associated with multiple DWs (e.g., three DWs, indexed as DW0 through DW2 in Fig. 5B) for each HP associated with the UTP transfer request. In that regard, the HPT 502 may be associated with a total of 3N DWs, with N corresponding to the quantity of HPs indicated by the HPT 502 (with only the DWs corresponding to the first HP of the N HPs shown in Fig. 5B for ease of description) . For example, bits [31: 0] of DW0 and bits [31: 0] of DW1 may be used as an HP base address field and an HP base address upper 32 bits field, respectively. Moreover, bits [16: 0] of DW2 may be used as an HP byte count field, bits [30: 17] of DW2 may be reserved, and bit
[0031] of DW2 may be used as a chained indicator field. In such aspects, the UFS host controller may identify a start location of a given HP using the HP base address indicated by reference DW0 and / or DW1, and / or may identify a size of the given HP using the HP byte count field. Moreover, based at least in part on whether the chained indicator field has been set, the UFS host controller may identify whether one or more HP entries consecutively follow the current HP entry. For example, if the chained indicator field is set to 0, the HP entry may be the last HP entry in the HPT 502. Otherwise, if the chained indicator field is set to 1, there are one or more HP entries that consecutively follow the HP entry.
[0056] Based at least in part on storing one or more HPs in a data structure other than an UTRD (such as a PRDT or an HPT) , the UFS host controller and / or the UFS device may conserve computing, power, storage, and / or other resources that may have otherwise been consumed storing one or more HPs in an extended UTRD. For example, based at least in part on storing one or more HPs in a data structure other than a UTRD (such as a PRDT or an HPT) , the UFS host controller may cache more UTRDs than otherwise would be possible using an extended UTRD, and / or the UFS host controller may dedicate less RAM space to caching UTRDs than would be needed for extended UTRDs, which may conserve computing, power, storage, and / or other resources that may have otherwise been consumed to retrieve and / or cache UTRDs.
[0057] As indicated above, Figs. 4 and 5A-5B are provided as examples. Other examples may differ from what is described with respect to Figs. 4 and 5A-5B.
[0058] Fig. 6 is a diagram of example components of a device 600, in accordance with the present disclosure. The device 600 may correspond to the host device 102, the memory device 104, the UFS host controller 106, the SoC 202, the CPU 204, the memory controller 206, the UFS host controller 208, the cryptographic hash engine 210, the UFS device 216, and / or the RAM 222. In some implementations, the host device 102, the memory device 104, the UFS host controller 106, the SoC 202, the CPU 204, the memory controller 206, the UFS host controller 208, the cryptographic hash engine 210, the UFS device 216, and / or the RAM 222 may include one or more devices 600 and / or one or more components of device 600. As shown in Fig. 6, device 600 may include a bus 610, a processor 620, a memory 630, a storage component 640, an input component 650, an output component 660, and a communication component 670.
[0059] Bus 610 includes a component that enables wired and / or wireless communication among the components of device 600. Processor 620 includes a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field-programmable gate array, an application-specific integrated circuit, and / or another type of processing component. Processor 620 is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor 620 includes one or more processors capable of being programmed to perform a function. Memory 630 includes a random access memory) , a read only memory, and / or another type of memory (e.g., a flash memory, a magnetic memory, and / or an optical memory) .
[0060] Storage component 640 stores information and / or software related to the operation of device 600. For example, storage component 640 may include a hard disk drive, a magnetic disk drive, an optical disk drive, a solid state disk drive, a compact disc, a digital versatile disc, and / or another type of non-transitory computer-readable medium. Input component 650 enables device 600 to receive input, such as user input and / or sensed inputs. For example, input component 650 may include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system component, an accelerometer, a gyroscope, an actuator, and / or the like. Output component 660 enables device 600 to provide output, such as via a display, a speaker, and / or one or more light-emitting diodes. Communication component 670 enables device 600 to communicate with other devices, such as via a wired connection and / or a wireless connection. For example, communication component 670 may include a receiver, a transmitter, a transceiver, a modem, a network interface card, an antenna, and / or the like.
[0061] Device 600 may perform one or more processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 630 and / or storage component 640) may store a set of instructions (e.g., one or more instructions, code, software code, program code, and / or the like) for execution by processor 620. Processor 620 may execute the set of instructions to perform one or more processes described herein. In some implementations, execution of the set of instructions, by one or more processors 620, causes the one or more processors 620 and / or the device 600 to perform one or more processes described herein. In some implementations, hardwired circuitry may be used instead of or in combination with the instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
[0062] The number and arrangement of components shown in Fig. 6 are provided as an example. Device 600 may include additional components, fewer components, different components, or differently arranged components than those shown in Fig. 6. Additionally, or alternatively, a set of components (e.g., one or more components) of device 600 may perform one or more functions described as being performed by another set of components of device 600.
[0063] Fig. 7 is a flowchart of an example process 700 associated with encoding an HP associated with a UTP transfer request, in accordance with the present disclosure. In some implementations, one or more process blocks of Fig. 7 are performed by a UFS host controller (e.g., UFS host controller 106 and / or UFS host controller 208) . In some implementations, one or more process blocks of Fig. 7 are performed by another device or a group of devices separate from or including the UFS host controller, such as a host device (e.g., host device 102) , a memory device (e.g., memory device 104) , a SoC (e.g., SoC 202) , a CPU (e.g., CPU 204) , a memory controller (e.g., memory controller 206) , a cryptographic hash engine (e.g., cryptographic hash engine 210) , a UFS device (e.g., UFS device 216) , and / or a RAM (e.g., RAM 222) . Additionally, or alternatively, one or more process blocks of Fig. 7 may be performed by one or more components of device 600, such as processor 620, memory 630, storage component 640, input component 650, output component 660, and / or communication component 670.
[0064] As shown in Fig. 7, process 700 may include accessing a UTP transfer request that includes an HP indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored (block 710) . For example, the UFS may access a UTP transfer request that includes an HP indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored, as described above.
[0065] As further shown in Fig. 7, process 700 may include reading the HP from the data structure (block 720) . For example, the UFS may read the HP from the data structure, as described above.
[0066] As further shown in Fig. 7, process 700 may include accessing the one or more hash values in the memory location indicated by the HP (block 730) . For example, the UFS may access the one or more hash values in the memory location indicated by the HP, as described above.
[0067] Process 700 may include additional implementations, such as any single implementation or any combination of implementations described below and / or in connection with one or more other processes described elsewhere herein.
[0068] In a first implementation, the HP indicator is included as part of a PRDT entry data structure associated with the UTP transfer request.
[0069] In a second implementation, alone or in combination with the first implementation, the data structure is the PRDT entry data structure.
[0070] In a third implementation, alone or in combination with one or more of the first and second implementations, the HP indicator is a repurposed reserved bit associated with the PRDT entry data structure.
[0071] In a fourth implementation, alone or in combination with one or more of the first through third implementations, the repurposed reserved bit is a reserved bit located in a double word of the PRDT associated with index 3.
[0072] In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, the HP indicator is included as part of a UTRD associated with the UTP transfer request.
[0073] In a sixth implementation, alone or in combination with one or more of the first through fifth implementations, the data structure is associated with a fourth section of a UCD in a host memory, a PRDT entry data structure for the UTP transfer request is associated with a third section of the UCD in the host memory, and the fourth section of the UCD immediately follows the third section of the UCD.
[0074] In a seventh implementation, alone or in combination with one or more of the first through sixth implementations, reading the HP from the data structure includes accessing the fourth section of the UCD based at least in part on a base address indicated by the UTRD, a PRDT offset indicated by the UTRD, and a PRDT length indicated by the UTRD.
[0075] In an eighth implementation, alone or in combination with one or more of the first through seventh implementations, the fourth section of the UCD includes multiple HPs that are consecutively stored in the fourth section of the UCD.
[0076] In a ninth implementation, alone or in combination with one or more of the first through eighth implementations, each HP, of the multiple HPs, is associated with a respective chained indicator that indicates whether that HP is a last HP of the multiple HPs.
[0077] In a tenth implementation, alone or in combination with one or more of the first through ninth implementations, the HP indicator is a repurposed reserved bit associated with the UTRD.
[0078] In an eleventh implementation, alone or in combination with one or more of the first through tenth implementations, the repurposed reserved bit is a reserved bit located in a double word of the UTRD associated with index 0.
[0079] Although Fig. 7 shows example blocks of process 700, in some implementations, process 700 includes additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in Fig. 7. Additionally, or alternatively, two or more of the blocks of process 700 may be performed in parallel.
[0080] The following provides an overview of some Aspects of the present disclosure:
[0081] Aspect 1: A method performed by a universal flash storage (UFS) host controller, comprising: accessing a UFS transport protocol (UTP) transfer request that includes a hash pointer (HP) indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored; reading the HP from the data structure; and accessing the one or more hash values in the memory location indicated by the HP.
[0082] Aspect 2: The method of Aspect 1, wherein the HP indicator is included as part of a physical region description table (PRDT) entry data structure associated with the UTP transfer request.
[0083] Aspect 3: The method of Aspect 2, wherein the data structure is the PRDT entry data structure.
[0084] Aspect 4: The method of Aspect 2, wherein the HP indicator is a repurposed reserved bit associated with the PRDT entry data structure.
[0085] Aspect 5: The method of Aspect 4, wherein the repurposed reserved bit is a reserved bit located in a double word of the PRDT associated with index 3.
[0086] Aspect 6: The method of any of Aspects 1-5, wherein the HP indicator is included as part of a UTP transfer request descriptor (UTRD) associated with the UTP transfer request.
[0087] Aspect 7: The method of Aspect 6, wherein the data structure is associated with a fourth section of a UTP command descriptor (UCD) in a host memory, wherein a physical region description table (PRDT) entry data structure for the UTP transfer request is associated with a third section of the UCD in the host memory, and wherein the fourth section of the UCD immediately follows the third section of the UCD.
[0088] Aspect 8: The method of Aspect 7, wherein reading the HP from the data structure includes accessing the fourth section of the UCD based at least in part on a base address indicated by the UTRD, a PRDT offset indicated by the UTRD, and a PRDT length indicated by the UTRD.
[0089] Aspect 9: The method of Aspect 7, wherein the fourth section of the UCD includes multiple HPs that are consecutively stored in the fourth section of the UCD.
[0090] Aspect 10: The method of Aspect 9, wherein each HP, of the multiple HPs, is associated with a respective chained indicator that indicates whether that HP is a last HP of the multiple HPs.
[0091] Aspect 11: The method of Aspect 6, wherein the HP indicator is a repurposed reserved bit associated with the UTRD.
[0092] Aspect 12: The method of Aspect 11, wherein the repurposed reserved bit is a reserved bit located in a double word of the UTRD associated with index 0.
[0093] Aspect 13: A system configured to perform one or more operations recited in one or more of Aspects 1-12.
[0094] Aspect 14: An apparatus comprising means for performing one or more operations recited in one or more of Aspects 1-12.
[0095] Aspect 15: A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising one or more instructions that, when executed by a device, cause the device to perform one or more operations recited in one or more of Aspects 1-12.
[0096] Aspect 16: A computer program product comprising instructions or code for executing one or more operations recited in one or more of Aspects 1-12.
[0097] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise forms disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. No element, act, or instruction described herein should be construed as critical or essential unless explicitly described as such.
[0098] As used herein, the term “component” is intended to be broadly construed as hardware and / or a combination of hardware and software. “Software” shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, and / or functions, among other examples, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. As used herein, a “processor” is implemented in hardware and / or a combination of hardware and software. It will be apparent that systems and / or methods described herein may be implemented in different forms of hardware and / or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the aspects. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, since those skilled in the art will understand that software and hardware can be designed to implement the systems and / or methods based, at least in part, on the description herein.
[0099] As used herein, “satisfying a threshold” may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.
[0100] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of various aspects. Many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. The disclosure of various aspects includes each dependent claim in combination with every other claim in the claim set. As used herein, a phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a + b, a + c, b + c, and a + b + c, as well as any combination with multiples of the same element (e.g., a + a, a + a + a, a + a + b, a + a + c, a + b + b, a + c + c, b + b, b + b + b, b + b + c, c + c, and c + c + c, or any other ordering of a, b, and c) .
[0101] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more. ” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more. ” Furthermore, as used herein, the terms “set” and “group” are intended to include one or more items and may be used interchangeably with “one or more. ” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has, ” “have, ” “having, ” or the like are intended to be open-ended terms that do not limit an element that they modify (e.g., an element “having” A may also have B) . Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “and / or, ” unless explicitly stated otherwise (e.g., if used in combination with “either” or “only one of” ) .
Claims
1.A universal flash storage (UFS) host device, comprising:a controller configured to:access a UFS transport protocol (UTP) transfer request that includes a hash pointer (HP) indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored;read the HP from the data structure; andaccess the one or more hash values in the memory location indicated by the HP.2.The UFS host device of claim 1, wherein the HP indicator is included as part of a physical region description table (PRDT) entry data structure associated with the UTP transfer request.3.The UFS host device of claim 2, wherein the data structure is the PRDT entry data structure.4.The UFS host device of claim 2, wherein the HP indicator is a repurposed reserved bit associated with the PRDT entry data structure.5.The UFS host device of claim 4, wherein the repurposed reserved bit is a reserved bit located in a double word of the PRDT associated with index 3.6.The UFS host device of claim 1, wherein the HP indicator is included as part of a UTP transfer request descriptor (UTRD) associated with the UTP transfer request.7.The UFS host device of claim 6, wherein the data structure is associated with a fourth section of a UTP command descriptor (UCD) in a host memory,wherein a physical region description table (PRDT) entry data structure for the UTP transfer request is associated with a third section of the UCD in the host memory, andwherein the fourth section of the UCD immediately follows the third section of the UCD.8.The UFS host device of claim 7, wherein the controller, to read the HP from the data structure, is configured to access the fourth section of the UCD based at least in part on a base address indicated by the UTRD, a PRDT offset indicated by the UTRD, and a PRDT length indicated by the UTRD.9.The UFS host device of claim 7, wherein the fourth section of the UCD includes multiple HPs that are consecutively stored in the fourth section of the UCD.10.The UFS host device of claim 9, wherein each HP, of the multiple HPs, is associated with a respective chained indicator that indicates whether that HP is a last HP of the multiple HPs.11.The UFS host device of claim 6, wherein the HP indicator is a repurposed reserved bit associated with the UTRD.12.The UFS host device of claim 11, wherein the repurposed reserved bit is a reserved bit located in a double word of the UTRD associated with index 0.13.A method performed by a universal flash storage (UFS) host controller, comprising:accessing a UFS transport protocol (UTP) transfer request that includes a hash pointer (HP) indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored;reading the HP from the data structure; andaccessing the one or more hash values in the memory location indicated by the HP.14.The method of claim 13, wherein the HP indicator is included as part of a physical region description table (PRDT) entry data structure associated with the UTP transfer request.15.The method of claim 14, wherein the data structure is the PRDT entry data structure.16.The method of claim 13, wherein the HP indicator is included as part of a UTP transfer request descriptor (UTRD) associated with the UTP transfer request.17.The method of claim 16, wherein the data structure is associated with a fourth section of a UTP command descriptor (UCD) in a host memory,wherein a physical region description table (PRDT) entry data structure for the UTP transfer request is associated with a third section of the UCD in the host memory, andwherein the fourth section of the UCD immediately follows the third section of the UCD.18.The method of claim 17, wherein the fourth section of the UCD includes multiple HPs that are consecutively stored in the fourth section of the UCD.19.The method of claim 18, wherein each HP, of the multiple HPs, is associated with a respective chained indicator that indicates whether that HP is a last HP of the multiple HPs.20.A non-transitory computer-readable medium storing a set of instructions for wireless communication, the set of instructions comprising:one or more instructions that, when executed by a universal flash storage (UFS) host controller, cause the UFS host controller to:access a UFS transport protocol (UTP) transfer request that includes a hash pointer (HP) indicator indicating that an HP associated with the UTP transfer request is encoded at a data structure, wherein the HP indicates a memory location where one or more hash values associated with the UTP transfer request are stored;read the HP from the data structure; andaccess the one or more hash values in the memory location indicated by the HP.