From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: <dave.jiang@intel.com>, <dan.j.williams@intel.com>,
<alison.schofield@intel.com>, <ira.weiny@intel.com>,
<gourry@gourry.net>, <dongjoo.seo1@samsung.com>,
<anisa.su@samsung.com>, <linux-cxl@vger.kernel.org>
Subject: Re: [PATCH 2/6] cxl: Add BI register probing and port initialization
Date: Fri, 20 Mar 2026 15:46:46 +0000 [thread overview]
Message-ID: <20260320154646.00002d4a@huawei.com> (raw)
In-Reply-To: <20260315202741.3264295-3-dave@stgolabs.net>
On Sun, 15 Mar 2026 13:27:37 -0700
Davidlohr Bueso <dave@stgolabs.net> wrote:
> Add register probing for BI Route Table and BI Decoder capability
> structures in cxl_probe_component_regs(), and initialize BI registers
> during port probe for both switch ports and endpoint ports.
>
> For switch ports, map BI Decoder registers on downstream ports and
> BI Route Table registers on upstream ports. For endpoint ports, map
> the BI Decoder registers directly into the port's register block.
>
> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Various minor things in here. Biggest one is whether we can use port->regs
for the switch upstream port registers.
> ---
> drivers/cxl/core/regs.c | 13 ++++++
> drivers/cxl/port.c | 88 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 101 insertions(+)
>
> diff --git a/drivers/cxl/core/regs.c b/drivers/cxl/core/regs.c
> index 93710cf4f0a6..82e6018fd4cf 100644
> --- a/drivers/cxl/core/regs.c
> +++ b/drivers/cxl/core/regs.c
> @@ -92,6 +92,18 @@ void cxl_probe_component_regs(struct device *dev, void __iomem *base,
> length = CXL_RAS_CAPABILITY_LENGTH;
> rmap = &map->ras;
> break;
> + case CXL_CM_CAP_CAP_ID_BI_RT:
> + dev_dbg(dev, "found BI RT capability (0x%x)\n",
> + offset);
> + length = CXL_BI_RT_CAPABILITY_LENGTH;
> + rmap = &map->bi;
> + break;
> + case CXL_CM_CAP_CAP_ID_BI_DECODER:
> + dev_dbg(dev, "found BI Decoder capability (0x%x)\n",
> + offset);
> + length = CXL_BI_DECODER_CAPABILITY_LENGTH;
> + rmap = &map->bi;
This was what triggered my reply on whether we should separate the two bi
capabilities.
> + break;
> default:
> dev_dbg(dev, "Unknown CM cap ID: %d (0x%x)\n", cap_id,
> offset);
> @@ -211,6 +223,7 @@ int cxl_map_component_regs(const struct cxl_register_map *map,
> } mapinfo[] = {
> { &map->component_map.hdm_decoder, ®s->hdm_decoder },
> { &map->component_map.ras, ®s->ras },
> + { &map->component_map.bi, ®s->bi },
> };
> int i;
>
> diff --git a/drivers/cxl/port.c b/drivers/cxl/port.c
> index ada51948d52f..0540f0681ffb 100644
> --- a/drivers/cxl/port.c
> +++ b/drivers/cxl/port.c
> @@ -58,6 +58,90 @@ static int discover_region(struct device *dev, void *unused)
> return 0;
> }
>
> +static int cxl_dport_init_bi(struct cxl_dport *dport)
> +{
> + struct cxl_register_map *map = &dport->reg_map;
> + struct device *dev = dport->dport_dev;
> +
> + if (dport->regs.bi)
As below. Maybe a comment on why we might hit this twice.
> + return 0;
> +
> + if (!cxl_pci_flit_256(to_pci_dev(dev)))
> + return 0;
> +
> + if (!map->component_map.bi.valid) {
> + dev_dbg(dev, "BI decoder registers not found\n");
> + return 0;
> + }
> +
> + if (cxl_map_component_regs(map, &dport->regs.component,
> + BIT(CXL_CM_CAP_CAP_ID_BI_DECODER))) {
> + dev_dbg(dev, "Failed to map BI decoder capability.\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static void cxl_uport_init_bi(struct cxl_port *port, struct device *host)
> +{
> + struct cxl_register_map *map = &port->reg_map;
> +
> + if (port->uport_regs.bi)
Maybe a comment on why we'd hit this twice and locking requirements
that we don't end up racing between this check and initializing it.
In general uport_regs feels too general a name to me given we have
uport related registers mapped in various different places already.
I.e. in cxl_hdm and devm_cxl_port_ras_setup() which puts it in
port->regs. Can we not put this one in there as well alongside the RAS
register map? Assuming I read this right I'd be keen on a comment
update to make it clear that one is all about upstream port component
regs.
> + return;
> +
> + if (!map->component_map.bi.valid) {
> + dev_dbg(host, "BI RT registers not found\n");
> + return;
> + }
> +
> + map->host = host;
> + if (cxl_map_component_regs(map, &port->uport_regs,
> + BIT(CXL_CM_CAP_CAP_ID_BI_RT)))
> + dev_dbg(&port->dev, "Failed to map BI RT capability\n");
> +}
> +
> +static void cxl_endpoint_init_bi(struct cxl_port *port)
> +{
> + struct cxl_register_map *map = &port->reg_map;
> +
> + cxl_dport_init_bi(port->parent_dport);
> +
> + if (!map->component_map.bi.valid)
> + return;
> +
> + if (cxl_map_component_regs(map, &port->regs,
> + BIT(CXL_CM_CAP_CAP_ID_BI_DECODER)))
> + dev_dbg(&port->dev, "Failed to map BI decoder capability\n");
> +}
> +
> +static void cxl_switch_port_init_bi(struct cxl_port *port)
> +{
> + struct cxl_dport *parent_dport = port->parent_dport;
> +
> + if (is_cxl_root(to_cxl_port(port->dev.parent)))
Rings a bell as something I moaned about before in a different series
as a pattern that is repeated too much. Though I'm still not
hugely keen on this not being named for what it is really checking
about this device. I believe this is excluding the
devices/platform/ACPI0017:00/root0/portX which are the host bridges.
if (parent_port_is_cxl_root(port))
return;
> + return;
> +
> + if (dev_is_pci(port->uport_dev) &&
I kind of wish we also had this named to indicate (I think) that it's
excluding CXL test devices.
> + !cxl_pci_flit_256(to_pci_dev(port->uport_dev)))
> + return;
> +
> + if (parent_dport && dev_is_pci(parent_dport->dport_dev)) {
> + struct pci_dev *pdev = to_pci_dev(parent_dport->dport_dev);
> +
> + switch (pci_pcie_type(pdev)) {
> + case PCI_EXP_TYPE_ROOT_PORT:
> + case PCI_EXP_TYPE_DOWNSTREAM:
> + cxl_dport_init_bi(parent_dport);
> + break;
> + default:
> + break;
> + }
> + }
> +
> + cxl_uport_init_bi(port, &port->dev);
> +}
> +
> static int cxl_switch_port_probe(struct cxl_port *port)
> {
> /* Reset nr_dports for rebind of driver */
> @@ -66,6 +150,8 @@ static int cxl_switch_port_probe(struct cxl_port *port)
> /* Cache the data early to ensure is_visible() works */
> read_cdat_data(port);
>
> + cxl_switch_port_init_bi(port);
> +
> return 0;
> }
>
> @@ -128,6 +214,8 @@ static int cxl_endpoint_port_probe(struct cxl_port *port)
> read_cdat_data(port);
> cxl_endpoint_parse_cdat(port);
>
> + cxl_endpoint_init_bi(port);
> +
> get_device(&cxlmd->dev);
> rc = devm_add_action_or_reset(&port->dev, schedule_detach, cxlmd);
> if (rc)
next prev parent reply other threads:[~2026-03-20 15:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-15 20:27 [PATCH 0/6] cxl: Support Back-Invalidate Davidlohr Bueso
2026-03-15 20:27 ` [PATCH 1/6] cxl: Add Back-Invalidate register definitions and structures Davidlohr Bueso
2026-03-19 16:59 ` Jonathan Cameron
2026-03-20 14:57 ` Jonathan Cameron
2026-03-23 22:11 ` Dave Jiang
2026-03-15 20:27 ` [PATCH 2/6] cxl: Add BI register probing and port initialization Davidlohr Bueso
2026-03-20 15:46 ` Jonathan Cameron [this message]
2026-03-20 16:19 ` Cheatham, Benjamin
2026-03-23 23:10 ` Dave Jiang
2026-03-15 20:27 ` [PATCH 3/6] cxl/pci: Add Back-Invalidate topology enable/disable Davidlohr Bueso
2026-03-20 16:20 ` Cheatham, Benjamin
2026-03-20 20:52 ` Alison Schofield
2026-03-20 16:27 ` [PATCH 3/6] cxl/pci: Add Back-Invalidate topology enable/disabl Jonathan Cameron
2026-03-24 0:21 ` [PATCH 3/6] cxl/pci: Add Back-Invalidate topology enable/disable Dave Jiang
2026-03-15 20:27 ` [PATCH 4/6] cxl: Wire BI setup and dealloc into device lifecycle Davidlohr Bueso
2026-03-20 16:20 ` Cheatham, Benjamin
2026-03-20 16:29 ` Jonathan Cameron
2026-03-15 20:27 ` [PATCH 5/6] cxl/hdm: Add BI coherency support for endpoint decoders Davidlohr Bueso
2026-03-20 16:20 ` Cheatham, Benjamin
2026-03-15 20:27 ` [PATCH 6/6] cxl: Add HDM-DB region creation and sysfs interface Davidlohr Bueso
2026-03-20 16:39 ` Jonathan Cameron
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=20260320154646.00002d4a@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=anisa.su@samsung.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=dongjoo.seo1@samsung.com \
--cc=gourry@gourry.net \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox