On 10/24/2019 8:44 AM, Somnath Kotur wrote:
> @@ -32523,7 +33886,7 @@
>
> struct hwrm_nvm_write_input {
>
> * The requested length of the allocated NVM for the item, in bytes. This
> value may be greater than or equal to the specified data length
> (dir_data_length).
> * If this value is less than the specified data length, it will be ignored.
> * The response will contain the actual allocated item length, which may be
> greater than the requested item length.
> - * The purpose for allocating more than the required number of bytes for an
> item's data is to pre-allocate extra storage (padding) to accomodate
> + * The purpose for allocating more than the required number of bytes for an
> item's data is to pre-allocate extra storage (padding) to accommodate
> * the potential future growth of an item (e.g. upgraded firmware with a size
> increase, log growth, expanded configuration data).
> */
> uint32_t dir_item_length;
We are more flexible on the base files and their compatibility to
our coding convention, but for later can it be possible to take the
line length under more control.
>
> @@ -33105,7 +34468,7 @@
>
> struct hwrm_nvm_install_update_input {
>
> #define HWRM_NVM_INSTALL_UPDATE_INPUT_FLAGS_ERASE_UNUSED_SPACE \
> UINT32_C(0x1)
> /*
> - * If set to 1, then unspecifed images, images not in the package file, will
> be safely deleted.
> + * If set to 1, then unspecified images, images not in the package file,
> will be safely deleted.
> * When combined with erase_unused_space then unspecified images will be
> securely erased.
> */
> #define HWRM_NVM_INSTALL_UPDATE_INPUT_FLAGS_REMOVE_UNUSED_PKG \
>
> --
> 2.10.1.613.g2cc2e70
>
>
>
>
>
