[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <gwyjg43fnkzhrxmeub7zdoikvwfpatdrmaaoaqggdlfgopnpki@uba2ulvqruk3>
Date: Mon, 6 Nov 2023 08:00:44 +0100
From: Daniel Wagner <dwagner@...e.de>
To: Keith Busch <kbusch@...nel.org>
Cc: Christoph Hellwig <hch@....de>, linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org,
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 08:22:11AM -0600, Keith Busch wrote:
> > 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.
Thanks for the clarification.
Do you want me to send a follow up patch, a new version of this one or
do you fix up yourself?
Powered by blists - more mailing lists