linux-cxl.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Dave Jiang <dave.jiang@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <linux-cxl@vger.kernel.org>, <ira.weiny@intel.com>,
	<vishal.l.verma@intel.com>, <alison.schofield@intel.com>,
	<dave@stgolabs.net>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH] cxl: Add post reset warning if the reset is detected as Secondary Bus Reset (SBR)
Date: Wed, 21 Feb 2024 11:45:35 -0800	[thread overview]
Message-ID: <65d652df1e420_5c762941d@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <a251128e-ba9e-49fb-a237-f3b8c2b605e2@intel.com>

Dave Jiang wrote:
[..]
> > Dave, did you test this? I reacted to the addition of
> > ->active_rr_prereset as a case of putting code logic in a data
> > structure, but I doubt it is even effectice since nothing informs
> > software that the register values changed. I.e. the check should be to
> > walk through all the software committed decoders and see if they are
> > still hardware committed. No need for ->active_rr_prereset.
> 
> I've not got hold of hw to test yet. I just figured to see if this is
> the direction we want to go while I work on getting hold of hw. I
> added ->active_rr_prereset with the thinking that if we find there's
> nothing setup before the reset and after the reset we can skip
> emitting false warnings. But it sounds like we want only
> ->reset_done() to walk through the decoders and emit warning if
> nothing is setup regardless of previous state?

Wait, no. Previous state is already recorded in the 'struct cxl_decoder'
software state, right?  I.e. if CXL_DECODER_F_ENABLE was set before the
reset then when you go to read the hardware state you will see the
mismatch, if SBR was triggered. If FLR is triggered then the decoder's
CXL_DECODER_F_ENABLE state will still match hardware.

> Although would it be sufficient to just detect the range register
> Memory_Active bit? SBR would reset this bit to 0 right?

If the driver just revalidates all the device's decoder instances
against hardware that should be sufficient. Now there is a question
about whether it is sufficient to check one vs all, but might as well
check them all for a quick sanity check.

  reply	other threads:[~2024-02-21 19:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 23:23 [PATCH] cxl: Add post reset warning if the reset is detected as Secondary Bus Reset (SBR) Dave Jiang
2024-02-18 19:36 ` Ira Weiny
2024-02-19 14:20 ` Jonathan Cameron
2024-02-20 18:20   ` Dan Williams
2024-02-21 16:35     ` Dave Jiang
2024-02-21 19:45       ` Dan Williams [this message]
2024-02-20 20:39   ` Bjorn Helgaas
2024-02-20 21:00     ` Dan Williams

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=65d652df1e420_5c762941d@dwillia2-mobl3.amr.corp.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=vishal.l.verma@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).