[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZUkX9z1M3ZxjIp6Z@kbusch-mbp.dhcp.thefacebook.com>
Date: Mon, 6 Nov 2023 09:44:39 -0700
From: Keith Busch <kbusch@...nel.org>
To: Daniel Wagner <dwagner@...e.de>
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 Mon, Nov 06, 2023 at 08:00:44AM +0100, Daniel Wagner wrote:
> 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?
Fixed up inline when applying the original patch. Let me know if you
have any concerns with the result, currently here:
https://git.infradead.org/nvme.git/commitdiff/983a338b96c8a25b81e773b643f80634358e81bc
Powered by blists - more mailing lists