[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231103135857.GA1871@lst.de>
Date: Fri, 3 Nov 2023 14:58:57 +0100
From: Christoph Hellwig <hch@....de>
To: Daniel Wagner <dwagner@...e.de>
Cc: Keith Busch <kbusch@...nel.org>, linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
Niklas Cassel <Niklas.Cassel@....com>,
Kenji Tomonaga <tkenbo@...il.com>
Subject: Re: [PATCH v3] nvme: update firmware version after commit
On Fri, Nov 03, 2023 at 01:11:02PM +0100, Daniel Wagner wrote:
> This particular firmware seem to interpret afi one based, while
> the this patch assumes it is zero based
> Active Firmware Info (AFI): Specifies information about the active
> firmware revision.
>
> Bit 7 is reserved.
> Bits 6:4 indicates the firmware slot that is going to be activated
> at the next Controller Level Reset. If this field is 0h,
> then the controller does not indicate the firmware slot that
> is going to be activated at the next Controller Level Reset.
> Bit 3 is reserved.
> Bits 2:0 indicates the firmware slot from which the actively running
> firmware revision was loaded.
>
>
> It's not clear to me if afi bits 2:0 is zero or one based. Bits 6:4
> indicate to be 1 based.
All 0's based (what a stupid term..) fields in NVMe are explicitly
marked as such. And even if that wasn't the case I'd very much
expect the same encoding for the two sub-fields.
Powered by blists - more mailing lists