From: Dan Williams <dan.j.williams@intel.com>
To: Davidlohr Bueso <dave@stgolabs.net>,
Dan Williams <dan.j.williams@intel.com>
Cc: <linux-cxl@vger.kernel.org>, <alison.schofield@intel.com>,
<bwidawsk@kernel.org>, <ira.weiny@intel.com>,
<vishal.l.verma@intel.com>, <a.manzanares@samsung.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cxl/acpi: Verify CHBS consistency
Date: Tue, 21 Jun 2022 16:04:43 -0700 [thread overview]
Message-ID: <62b24e8b61cec_89207294e@dwillia2-xfh.notmuch> (raw)
In-Reply-To: <20220621223829.zdyqoej76kyfut4o@offworld>
Davidlohr Bueso wrote:
> On Tue, 21 Jun 2022, Dan Williams wrote:
>
> >For cxl_port objects this happens "for free" as a side effect of the:
> >
> > crb = devm_cxl_iomap_block(dev, port->component_reg_phys,
> > CXL_COMPONENT_REG_BLOCK_SIZE);
> >
> >...call in devm_cxl_setup_hdm(), where it tries to exclusively claim the
> >component register block for that cxl_port driver instance.
>
> Fair enough, I had noticed this.
>
> >
> >I.e. if the CHBS provides overlapping / duplicated ranges the failure is
> >localized to the cxl_port_probe() event for that port, and can be
> >debugged further by disabling one of the conflicts.
>
> Ok. Although imo it does make sense for failing directly in the cxl_acpi
> driver at an early stage instead of bogusly passing it down the hierarchy.
You could make that argument for almost any resource range advertised to
the kernel. The expected place where they finally collide is at
request_region() time.
> So is a v2 still worth it without this check?
I do notice that you also added a CXL 1.1 version check. That seems
useful to break out, but probably needs a rationale for what that means
for CXL 2.0 device on CXL 1.1 host compatibility. So a patch per new
CHBS consistency check is my preference, but I think only the CXL 1.1
check is still open.
prev parent reply other threads:[~2022-06-21 23:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 20:12 Davidlohr Bueso
2022-06-21 20:56 ` Dan Williams
2022-06-21 22:38 ` Davidlohr Bueso
2022-06-21 23:04 ` Dan Williams [this message]
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=62b24e8b61cec_89207294e@dwillia2-xfh.notmuch \
--to=dan.j.williams@intel.com \
--cc=a.manzanares@samsung.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®