From: "Łukasz Gieryk" <lukasz.gieryk@linux.intel.com>
To: Klaus Jensen <its@irrelevant.dk>
Cc: Lukasz Maniak <lukasz.maniak@linux.intel.com>,
qemu-devel@nongnu.org, Keith Busch <kbusch@kernel.org>,
qemu-block@nongnu.org, Klaus Jensen <k.jensen@samsung.com>
Subject: Re: [PATCH v2] hw/nvme: clean up CC register write logic
Date: Tue, 7 Jun 2022 13:06:45 +0200 [thread overview]
Message-ID: <20220607110645.GA28312@lgieryk-VirtualBox> (raw)
In-Reply-To: <YppuEyXp/iL06z/C@apples>
On Fri, Jun 03, 2022 at 10:24:51PM +0200, Klaus Jensen wrote:
> On Jun 1 15:28, Lukasz Maniak wrote:
> > On Wed, May 25, 2022 at 09:35:24AM +0200, Klaus Jensen wrote:
> > >
> > > + stl_le_p(&n->bar.intms, 0);
> > > + stl_le_p(&n->bar.intmc, 0);
> > > + stl_le_p(&n->bar.cc, 0);
> >
> > Looks fine, though it seems the NVMe spec says the above registers
> > should be cleared during each reset for VF as well.
> >
>
> Aren't the values of all other registers than CSTS just undefined? (NVMe
> v2.0b, Section 8.26.3)
My 2 cents –
When VF is online:
- Both Controller Reset (CR) and PCIe Function Level Reset (FLR) can be
issued to given VF
- Both resets shall return all (except specific) Nvme registers of given
VF to their reset values (3.7.2)
When VF is offline:
- CR cannot be issued (only CSTS is defined, writes to CC are dropped),
so doesn’t need an explicit IF
- FLR is allowed as it’s a part of the procedure to bring VF online
(mentioned in 8.26.3)
- At least FLR shall reset the registers for VF
So I agree with the other Lukasz's suggestion. I would also clear
intms/intmc/cc for both: VF and PF reset paths, regardless of the actual
reset type.
next prev parent reply other threads:[~2022-06-07 12:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 7:35 [PATCH v2] hw/nvme: clean up CC register write logic Klaus Jensen
2022-06-01 13:28 ` Lukasz Maniak
2022-06-03 20:24 ` Klaus Jensen
2022-06-07 11:06 ` Łukasz Gieryk [this message]
2022-06-07 11:23 ` Klaus Jensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220607110645.GA28312@lgieryk-VirtualBox \
--to=lukasz.gieryk@linux.intel.com \
--cc=its@irrelevant.dk \
--cc=k.jensen@samsung.com \
--cc=kbusch@kernel.org \
--cc=lukasz.maniak@linux.intel.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.