[PATCH v3] nvme: update firmware version after commit

[Keith Busch]

On Fri, Nov 03, 2023 at 02:58:57PM +0100, Christoph Hellwig wrote:
> 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.

Yeah, it's just the firmware slot number, taken literally. AFI = 1 means
slot 1, AFI = 2 means slot 2, etc... Slot 0 either has special meaning
(firmware commit SF field, or fw log AFI bits 6:4), or is reserved
value, like in Identify Controller FRMW.NOFS, and has no place in the FW
Slot Info log page.

Our first slot in the log page is defined as slot one, so we have to
subtract one from the AFI field to index into the slot array. I messed
up for not catching that earlier, but thanks for pointing it out now.