KR102270531B1 - Systems and methods for host detection of usb asynchronous notification capability - Google Patents

Abstract

A system and method are disclosed for detecting legacy storage devices that may falsely and/or inaccurately report to a host system that they have removable media. Such false or inaccurate reports can cause the host system to periodically poll the storage device to see if it is ready for I/O processing. Such polling may be unnecessary and may indicate a waste of power consumed by the host system. In one embodiment, the system may implement a process for periodically polling the storage medium and updating the database. The database may be a list of storage devices indicating whether the storage devices truly have removable media or falsely report that they have removable media. In another embodiment, the system may apply some heuristically testing to determine if a storage device falsely represents a removable medium. In another embodiment, a telemetry service may be used by a group of hosts to share data related to such storage devices.

Description

SYSTEMS AND METHODS FOR HOST DETECTION OF USB ASYNCHRONOUS NOTIFICATION CAPABILITY

Minimal power consumption is an increasingly important feature that is gaining attention in newer computing platforms. Some aspects of the first Universal Serial Bus (USB) mass storage - such as Bulk-Only Transport (BOT) and USB Attached SCSI Protocol (UASP) - tend to conflict with this trend. The overall power consumption of a host system connected to a USB mass storage device can be improved with only minor modifications to these existing specifications.

Now, as part of the USB 3.0 specification, new features have been added to improve bus utilization and power efficiency. Certain devices connected via USB 3.0 may now have the ability to (asynchronously) notify the host of the device's readiness, eliminating the need to poll each and every connected device. Also, modifications to the BOT and UASP specifications tend to obviate the need for another type of polling to detect media state changes in devices with removable media.

A brief summary of the invention is provided below in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview of the claimed subject matter. It is not intended to identify key elements or critical points of the claimed subject matter or to delineate the scope of the invention. Its sole purpose is to present some concepts of the claimed subject matter in a simplified form as a prelude to the more detailed description that is presented later.

A system and method are disclosed for detecting legacy storage devices that may falsely and/or inaccurately report to a host system that they have removable media. Such false or inaccurate reports may cause the host system to periodically poll the storage device to see if the storage device is ready for I/O processing. Such polling may be unnecessary and may indicate a waste of power consumed by the host system. In one embodiment, the system may implement a process for periodically polling the storage medium and updating the database. The database may be a list of storage devices indicating whether the storage devices truly have removable media or falsely report that they have removable media. In another embodiment, the system may apply some heuristically testing to determine if a storage device falsely represents a removable medium. In another embodiment, a telemetry service may be used by a group of hosts to share data related to such storage devices.

In one embodiment, a method of detecting a storage device is disclosed, wherein the storage device is coupled to a host system, wherein the storage device includes associated metadata, wherein the storage device has a removable medium. , the method includes sending a media polling message from the host system to a first storage device, the media polling message querying whether the first storage device is ready; 1 if the storage device responds that it is not ready, then updating the database that the first storage device does indeed have a removable medium.

In yet another embodiment, a system for detecting a storage device in a host system is disclosed, the storage device further comprising associated metadata, the associated metadata falsely indicating that the storage device comprises a removable storage medium. wherein the system comprises a mass storage driver, the mass storage driver capable of being coupled to the storage device and capable of sending messages to and receiving messages from the storage device, and a block storage driver, the block storage driver comprising: a processor coupled to the mass storage driver and capable of sending messages to and receiving messages from the storage device, wherein the processor is capable of sending a media poll message to the storage device and is capable of sending messages to the storage device and not having truly removable media. may block additional media polling messages to the device.

Other features and aspects of the system are set forth in the detailed description below in connection with the drawings within this application.

Exemplary embodiments are described with reference to the drawings. The embodiments and drawings disclosed herein are to be regarded as illustrative and not restrictive.

1 illustrates one embodiment of a typical host/hub/peripheral configuration environment.
2 shows one exemplary embodiment of the processing that may occur under the revised BOS specification.
3 shows one exemplary embodiment of the present system made in accordance with the principles of the present application.
4 depicts one flow diagram of a process for identifying and/or discriminating between legacy devices that may or may not have removable media.
5 shows another flow diagram of a process to help implement power savings and identify devices that may misreport their removable media status.
6 shows another flow diagram of a process for collecting and aggregating telemetry data from participating host systems.

As used herein, the terms “component,” “system,” “interface,” “controller,” and the like, are intended to refer to computer-related entities: hardware, (eg, executable) software, and/or firmware. For example, any of these terms may refer to a process running on a processor, a processor, an object, an executable, a program, and/or a computer. For example, both an application running on a server and a server may be a component and/or a controller. One or more components/controllers may reside within a process and components/controllers may be localized on one computer and/or distributed between two or more computers.

BRIEF DESCRIPTION OF THE DRAWINGS The invention is described with reference to the drawings, wherein like reference numerals are used to denote like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.

intro

In one embodiment, power may be saved by eliminating polling of media status to the USB flash drive. However, doing this safely may be impossible for the following reasons. That is, (1) the majority of USB flash drives (UFDs) report removable media incorrectly, and (2) clearly distinguish these UFDs from devices that do indeed contain removable media (eg, USB flash card reader devices). Because there is currently no way to do it. This is especially true where legacy UFDs are represented (but falsely) as containing removable media even when they do not actually have such removable media.

Now, newer non-legacy devices can implement a new asynchronous notification mechanism, which allows the host to explicitly and safely eliminate media polling without risking any malfunction or data loss. However, this is not the case (now and in the near future) for all legacy devices currently in use.

To understand this situation, Figure 1 is one exemplary embodiment of one architecture diagram 100 of a typical USB 3.0 host/hub/peripheral configuration. As can be seen in Figure 1, the new high-speed bus is part of a dual-bus architecture that works with the conventional USB 2.0 bus. The controller 102 may communicate with a USB 3.0 host 104 to provide I/O processing and/or functionality. The USB 3.0 host 104 may provide compatible support for legacy USB 2.0 hosts 106 as well as new ultra-fast host capabilities 108 . The controller 102 may be a CPU, an I/O controller of the system, or a combination of such controller hardware and/or software components.

A host may include multiple ports (eg, 110a, 110b). The ports may be connected to a plurality of hubs 112 . Hub 112 may further include legacy hub 114 and new (eg, ultra-fast) hub 116 . This hub may then be connected to a plurality of USB peripherals 120 , which may include a set of non-ultra-high-speed functions 122 and ultra-high-speed functions 124 .

These peripherals may be various types of legacy devices, such as USB flash drivers 126 that do not have removable media (which may falsely report to the host that they have removable media), or actual removable media components (e.g. For example, it may include a camera 128 with a memory card 130 ).

2 shows an exemplary embodiment 200 of processing that may occur under the revised BOT or UASP specification. The USB mass storage device 208 may include a storage medium 216 , a processing unit 214 , and an interface bundle 210 , which may or may not be removable. Interface bundle 210 includes legacy (e.g., existing BOT and UASP specifications) interfaces IN endpoints (EPs) 210a and OUT EPs 210b, and newly introduced interrupt endpoints for asynchronous notification of status ( INT EP 212).

For example, a change in state as to whether removable storage has been removed or replaced can be asynchronously notified to the host system in the notification process 206a, such as to the US mass storage driver 206 . This notification may be further communicated asynchronously to the block storage driver 204 , specifically to the media change process 204a. Finally, this change of state may be reported to the higher level file system stack 202 .

As previously discussed, legacy devices will not asynchronously report this change of state because they are not implemented according to the new specification. In fact, a legacy device may be a device prior to the newly proposed changes to the BOT/UASP specification, or a device chosen not to implement these changes. Also, legacy devices may falsely report that they have removable media even if they do not (thus requiring constant polling). To better understand the various aspects for potential power savings, it may be desirable to consider the impact on the various components.

Hub and Controller Considerations

While managing power for each node in the USB device tree, all children of that specific node must be stopped before the specific node itself can be suspended. Then, if the entire tree of devices connected to the host controller is stopped, the controller itself can be stopped. A stopped controller may not only conserve power associated with keeping its own circuitry active, but may also reduce host CPU power consumption due to interruption of interrupts that the controller may generate.

CPU Considerations

To keep the host up-to-date with the current media status of devices with removable media, the system may perform periodic polling using a TEST UNIT READY (TUR) command (eg, a media poll message). This corresponds to the periodic execution of code in the context of timer procedure calls, which tends to cause the CPU to remain in a higher power state due to this activity. In an attempt to minimize overall system power consumption, it may be desirable to consider the following:

(1) Devices reporting removable media are continuously polled by the host via the TEST UNIT READY command to detect any change in media status. This tends to consume extra power to keep the USB device tree, host controller, and host CPU alive unnecessarily, even in the absence of actual data I/O.

(2) When connected to a more power-optimized host, a mass storage device powered over the bus may find itself in a quiescent state for a longer period of time than in previous host versions. This period of inactivity may exceed the period required for the device to maintain robust operation. In such circumstances, the device may require occasional port resumption, where the port remains active for a period of time that allows the device to complete a set set of internal housekeeping tasks.

Peripheral/Device Type

In the embodiments disclosed herein, the benefits obtained as a reward for implementing the described mechanism may vary depending on the type of device. It may be beneficial to broadly consider the two types of mobility that may affect the outcome: device mobility and media mobility. Table 1 below shows examples of various device types representing permutations of these two properties.

Devices in categories 1 and 3 clearly tend to benefit from the elimination of TEST UNIT READY polling, while devices in categories 2 and 4 can generally benefit from the ability to remotely wake up ports. Also, it may be desirable to consider that a user of a Category 1 device may simply unplug the devices to conserve power, whereas a user of a Category 3 device may not be able to make the same choice. It is also understandable that Category 3 devices consume system power regardless of whether the removable media slot is empty. It is also understandable that regular USB flash drives appear to belong to both categories 1 and 2. The reason this is true is that most existing flash drives specify a bit value of 1 (TRUE) for the Removable Media bit (RMB) (even though it is not a true mount for removable storage media), thus causing a TEST UNIT READY poll. . However, some flash drives correctly represent their non-removable media (eg, by setting the removable media bit (RMB) to 0 (ie RMB=0)) and report an incorrect value (RMB=1). It effectively helps conserve more power for the attached host system (compared to the device).

one embodiment

As discussed, there are a number of benefits to be gained by safely removing this unnecessary media polling of a USB flash drive.

(1) Continuous polling tends to keep the device active, thus preventing selective quiescing. Elimination of polling allows the device itself to reach an idle state and thus put it into a low-power inactive state.

(2) This can affect not only devices, but the entire USB device tree, since all intermediate hub devices besides the USB host controller tend to remain active.

(3) Continuously polling DPC timers may tend to keep the CPU unnecessarily active.

Thus, it may be desirable to safely eliminate polling by making an accurate identification of a truly removable reader device versus a USB flash drive. Also, incorrect identification may result in missed media changes, thus possibly resulting in degraded functionality and data corruption.

3 shows one exemplary embodiment of the present system 300 (which may affect the USB 3.0 standard, etc.). The legacy USB mass storage device 308 includes a storage medium 316 , a processing component 314 , and an interface bundle 310 (which may further include legacy interfaces IN EP 310a and OUT EP 310b ). .

In this case, even if the legacy device incorrectly specifies whether it has removable media or not, the system can still use this asynchronous notification for the USB mass storage driver 306 expecting an asynchronous notification (which will not be reached). . When a system receives an asynchronous notification message from a storage device, the system tends to indicate that the storage device is not a legacy device, and the system can treat the device accordingly, such that it receives this notification message. If so, the system may use the storage device's ID or other metadata associated with the storage device to update the metadata so that the storage device truly has the removable medium. Such data and/or databases may be further shared with other host systems via telemetry or otherwise.

The state may be passed asynchronously to the block storage driver 304 via the media change process 304a. Finally, this state may be further passed to the higher level file system driver stack 302 . The block storage driver 304 further includes a processor for executing a medium change process or executing some sufficient process to detect the state of the attached storage device and query for their ready state or RMB state for I/O processing. may (or have access to sufficient processing power).

To perform such power saving asynchronous state updates, some embodiments of the present system may utilize various techniques and/or methods to improve accurate designation and/or detection of removable media.

As just one example, data may be collected prior to shipping a product. First, you can identify as many known (legacy or otherwise) USB flash drives versus reader devices as possible. Metadata regarding these readers and devices may be placed in a searchable table or other suitable database. This database can be referenced (eg, as an initial table) and the system can apply the correct polling behavior as appropriate.

However, since this initial table/database may be limited by not being complete as well as not being advanced, some follow on heuristic procedures and/or methods for the host system to further refine it as follows: can be used

(1) During initialization, issue a TUR command (or some other "ready" command to indicate that the device is ready to do I/O processing) once to some or all legacy units (LUNs) reporting RMB=1 . If at least one LUN responds to TUR with NOT READY - MEDIA NOT PRESENT, then this is truly a flash card reader or other device with removable media. The system or host can then process it accordingly, including disabling polling for that device and/or updating the table/database that the device does indeed have removable media.

(2) If everyone reports READY, additional evidence may be desirable for accurate confirmation. When reporting telemetry, data can be uploaded and shared to include the device's hardware ID (manufacturer ID (VID) and product ID (PID)), number of LUNs, and the number of times each LUN reported READY versus NOT READY ( For example, you can update the device errorer database with other hosts) (this is desirable because some small fractions of RMB=0 devices occasionally and intermittently report NOT READY).

(3) Collect telemetry sample data and identify highly probable UFD vs. flash card reader devices that may not be included in the initial table/database. This review process can help remove any anomalies or anomalies from consideration.

(4) Apply these new information periodically to update tables/databases and dynamically update drivers.

As described, new USB mass storage devices that implement asynchronous notifications can do so via an additional interrupt endpoint inserted into an interface descriptor bundle exposed to the host. Legacy (or down-level) hosts that are not aware of this new asynchronous notification feature may simply ignore the additional interrupt endpoints and may not benefit from this new feature.

However, only newer host systems can recognize and use this new asynchronous notification mechanism. The host system does so by selecting a new interrupt endpoint and maintaining persistent and outstanding requests to this endpoint as long as the device remains in the active DO power state. This request is resolved by the device upon any media change event by the device. After this, the host reissues another interrupt endpoint request to replace the recently resolved request. As the device transitions to the D3 power state, the host system cancels these outstanding requests to the interrupt endpoint. The host then re-establishes a persistent interrupt endpoint asynchronous notification request as the device resumes to the active DO power state, either due to device wake signaling corresponding to a locally detected media change at the device or due to a host-initiated transition. .

some processing examples

4 illustrates one flow diagram embodiment 400 of a process that may help identify and/or differentiate between legacy devices that may or may not have removable media and may also help conserve power.

At 402 , the device may be inserted into the hub, and then, at 404 , the system may issue an Inquiry command (ie, some prepare commands). If the device reports that it does not have removable media (RMB=0), then at 414 the system may transition to a power saving path, in which case the device idle timer may be reset. The system may receive a report that the device is disconnected, in which case at 424 the device is no longer considered and may be removed.

However, if there is an I/O request from the system, at 414 the device idle timer may be reset while the request is being served. If there is no such I/O request, the device's idle timer may expire at 420 . In that case, the device port can be stopped at 422 to save power.

However, at 406, if the device reports RMB=1 (i.e., the device reports that it has removable media), the system applies some heuristic testing to determine whether the device truly has removable media. can do. In one embodiment, such heuristic testing may proceed as described above. According to the heuristic, if the device has a non-removable medium, the process may transition to 414 and proceed accordingly.

Alternatively, the system may further inquire as to whether the device implements asynchronous media notification (eg, according to a BOT/UASP specification extension or any other specification capable of supporting such asynchronous notification). In such case, the system may transition to 414 . Alternatively, the system may implement periodic TUR polling and the device may not be idle.

5 illustrates another process (eg, FIG. 4 , etc.) that may help implement power savings (and also update and refine metadata for devices that may falsely report their removable media status); Another flow embodiment 500 that can be complemented. At 502 , a device may be inserted. At 504, the system may refer to a table/database to ascertain the state of a particular device. If at 506 the device is listed as not having removable media, then at 508 the system may disable TUR polling for that device.

Alternatively, if there is no database entry, the system may transition to 510 and detect whether the device is disconnected. In such a case, the system may transition to the device removed state 518 . Alternatively, the system may monitor the device's response to the TUR poll. If there is a response indicating that there is no medium, at 516 the system can collect data about the device and report on the device via telemetry. Otherwise, the system may continue to monitor the device's response to the TUR poll and may proceed accordingly.

6 is another flow diagram embodiment 600 of a process for collecting and aggregating data from participating host systems (eg, possibly executed offline on a server system). This can be used to update tables/databases to properly identify devices that may misidentify their removable media status. This process may proceed offline or otherwise. At 602 , the system may review the telemetry data to update the device database. With such an updated database, at 604 the system can ascertain whether any non-removable media is present. In such a case, at 606 the system may update the database for the purpose of notifying all updatable host systems about operation of a particular device. When there are new devices to report, the system can pass this information to the database. After a certain amount of time, this database can be shared with all updatable host systems via ^{an appropriate update process (eg Windows Update ® computer service).}

What has been described above includes examples of the invention. Of course, it is not possible to describe every conceivable combination of components or methodologies for the purposes of describing claimed subject matter, but those skilled in the art will recognize that many further combinations and alternative embodiments of the invention are possible. Accordingly, the claimed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

In particular with respect to the various functions performed by the aforementioned components, apparatus, circuits, systems, etc., the terminology (including "means") used to describe such components, unless otherwise specifically indicated, refers to the subject matter illustrated herein It is intended to correspond to any component that performs a particular function (eg, functionally equivalent) of the disclosed component (even if it is not structurally equivalent to the disclosed structure) that performs the function in terms of . In this regard, it will be appreciated that the present invention includes computer-readable media and systems having computer-executable instructions for performing the acts and/or inventions of the various methods of the claimed subject matter.

Further, while certain features of the invention may be described with respect to only one of several embodiments, such features may be combined with one or more other features of other embodiments as may be desirable and advantageous for any given or particular application. have. Also, when the terms "includes" and "comprising" and variations thereof are used in the specification or claims, these terms are intended to have a similar scope to the term "comprising". .

Claims (20)

A method of managing a storage device, comprising:
sending a media polling message from the host system to a first storage device, the media polling message querying whether the first storage device is ready;
if the first storage device responds that it is not ready, updating the database with an indication that the first storage device has removable media;
sending another media polling message from the host system to a second storage device, the other media polling message querying whether the second storage device is ready;
receiving an indication that the second storage device does not have removable media;
in response to an indication that the second storage device does not have removable media, disabling polling by the host system for the second storage device;
How to manage storage devices.
According to claim 1,
wherein the response to the media poll message includes an indication of whether the first storage device is a removable storage medium;
How to manage storage devices.
According to claim 1,
receiving an asynchronous notification message from a third storage device;
in response to the asynchronous notification message from the third storage device, further comprising updating the database with an indication that the third storage device has removable media.
How to manage storage devices.
According to claim 1,
said database. associating storage devices with the mobility of media relative to the storage devices;
How to manage storage devices.
5. The method of claim 4,
searching the database for an entry corresponding to a third storage device;
locating an entry corresponding to the third storage device;
in response to locating an entry corresponding to the third storage device in the database, disabling polling by the host system for the third storage device;
How to manage storage devices.
5. The method of claim 4,
wherein the storage devices include at least a flash memory drive;
How to manage storage devices.
According to claim 1,
and sharing with a second host system data pertaining to storage devices that provide metadata falsely indicating the mobility of the medium.
How to manage storage devices.
8. The method of claim 7,
The sharing of the data includes uploading to the second host system at least one of a hardware ID, a manufacturer ID (VID), a product ID (PID), and a legacy unit (LUN)
How to manage storage devices.
8. The method of claim 7,
Sharing the data includes reporting the data to a telemetry server.
How to manage storage devices.
According to claim 1,
further comprising receiving, from a second host system, data relating to the storage devices providing metadata falsely indicative of the mobility of the medium.
How to manage storage devices.
A computing device comprising:
including memory and processor;
The memory and the processor are each configured to store and execute instructions that cause the computing device to perform operations,
The actions are
interface the computing device to at least one storage device;
sending a media polling message to the at least one storage device;
receiving a response to the media poll message from the at least one storage device, the response falsely indicating that the at least one storage device has removable media;
determining that the response falsely indicates that the at least one storage device has removable media;
in response to the determination, disabling media polling for the at least one storage device;
computing device.
12. The method of claim 11,
The actions are
responsive to the determination, further comprising adding to a database an entry corresponding to the at least one storage device, the entry indicating that the at least one storage device falsely provides a removable media indication;
computing device.
12. The method of claim 11,
Determining that the response falsely indicates that the at least one storage device has removable media comprises:
comprising searching a database of storage devices known to falsely represent the mobility of the medium;
computing device.
14. The method of claim 13,
The operations also include sharing with another computing device data pertaining to storage devices that are known to falsely indicate the mobility of the medium.
computing device.
15. The method of claim 14,
Sharing the data is
reporting the data to a telemetry server;
computing device.
16. The method of claim 15,
The actions are
further comprising receiving, from another computing device, data relating to storage devices known to falsely indicate the mobility of the medium;
computing device.
A method of interacting with a storage device, comprising:
sending a media polling message to the storage device;
receiving a response to the media poll message from the storage device, the response falsely indicating that the storage device has removable media;
determining that the response falsely indicates that the storage device has removable media;
in response to the determination, disabling media polling for the storage device;
How to interact with the storage device.
18. The method of claim 17,
responsive to the determination, adding to a database an entry corresponding to the storage device, the entry indicating that the storage device falsely provides a removable media indication;
How to interact with the storage device.
18. The method of claim 17,
Determining that the response falsely indicates that the storage device has removable media comprises:
searching a database of storage devices known to falsely represent the mobility of the medium;
locating, in the database, an entry corresponding to the storage device;
How to interact with the storage device.
20. The method of claim 19,
The method is performed on a first computing device,
The method is
receiving, from another computing device, data relating to storage devices known to falsely indicate the mobility of the medium;
and updating the database based on the received data.
How to interact with the storage device.

Images