]> git.proxmox.com Git - mirror_edk2.git/blobdiff - MdePkg/Include/Protocol/FirmwareVolumeBlock.h
Reviewed the code comments in the Include/Protocol directory for typos, grammar issue...
[mirror_edk2.git] / MdePkg / Include / Protocol / FirmwareVolumeBlock.h
index 9c20ba2296ae24fbdca61651affc67a8d41f6a08..d25a2a0fa0fabdc743a6a2614dc86993e2e57f29 100644 (file)
@@ -139,6 +139,8 @@ EFI_STATUS
 \r
 \r
 /**\r
+  Reads the specified number of bytes into a buffer from the specified block.\r
+\r
   The Read() function reads the requested number of bytes from the\r
   requested block and stores them in the provided buffer.\r
   Implementations should be mindful that the firmware volume\r
@@ -194,6 +196,8 @@ EFI_STATUS
 );\r
 \r
 /**\r
+  Writes the specified number of bytes from the input buffer to the block.\r
+\r
   The Write() function writes the specified number of bytes from\r
   the provided buffer to the specified block and offset. If the\r
   firmware volume is sticky write, the caller must ensure that\r
@@ -202,9 +206,9 @@ EFI_STATUS
   function, or else the result will be unpredictable. This\r
   unpredictability arises because, for a sticky-write firmware\r
   volume, a write may negate a bit in the EFI_FVB_ERASE_POLARITY\r
-  state but it cannot flip it back again. In general, before\r
+  state but cannot flip it back again. In general, before\r
   calling the Write() function, the caller should call the\r
-  EraseBlocks() function first to erase the specified block to\r
+  EraseBlocks() function first to erase the block it intends to\r
   write. A block erase cycle will transition bits from the\r
   (NOT)EFI_FVB_ERASE_POLARITY state back to the\r
   EFI_FVB_ERASE_POLARITY state. Implementations should be\r
@@ -270,7 +274,9 @@ EFI_STATUS
 \r
 \r
 /**\r
-  The EraseBlocks() function erases one or more blocks as denoted\r
+  Erases and initializes a firmware volume block.\r
+\r
+  The EraseBlocks() function erases one or more blocks, as denoted\r
   by the variable argument list. The entire parameter list of\r
   blocks must be verified before erasing any blocks. If a block is\r
   requested that does not exist within the associated firmware\r
@@ -322,30 +328,15 @@ EFI_STATUS
   ...\r
 );\r
 \r
-/**\r
-  @par Protocol Description:\r
-  The Firmware Volume Block Protocol is the low-level interface\r
-  to a firmware volume. File-level access to a firmware volume\r
-  should not be done using the Firmware Volume Block Protocol.\r
-  Normal access to a firmware volume must use the Firmware\r
-  Volume Protocol. Typically, only the file system driver that\r
-  produces the Firmware Volume Protocol will bind to the\r
-  Firmware Volume Block Protocol. The Firmware Volume Block\r
-  Protocol provides the following:\r
-  - Byte-level read/write functionality.\r
-  - Block-level erase functionality.\r
-  - It further exposes device-hardening features, such as may be\r
-    equired to protect the firmware from unwanted overwriting\r
-    and/or erasure.\r
-  - It is useful to layer a file system driver on top of the\r
-    Firmware Volume Block Protocol.\r
-\r
-  This file system driver produces the Firmware Volume Protocol,\r
-  which provides file-level access to a firmware volume. The\r
-  Firmware Volume Protocol abstracts the file system that is\r
-  used to format the firmware volume and the hardware\r
-  device-hardening features that may be present.\r
-**/\r
+///\r
+/// The Firmware Volume Block Protocol is the low-level interface\r
+/// to a firmware volume. File-level access to a firmware volume\r
+/// should not be done using the Firmware Volume Block Protocol.\r
+/// Normal access to a firmware volume must use the Firmware\r
+/// Volume Protocol. Typically, only the file system driver that\r
+/// produces the Firmware Volume Protocol will bind to the\r
+/// Firmware Volume Block Protocol.\r
+///\r
 struct _EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL {\r
   EFI_FVB_GET_ATTRIBUTES        GetAttributes;\r
   EFI_FVB_SET_ATTRIBUTES        SetAttributes;\r