From: Robert Richter <rrichter@amd.com>
To: Dave Jiang <dave.jiang@intel.com>
Cc: linux-cxl@vger.kernel.org, dave@stgolabs.net,
jonathan.cameron@huawei.com, alison.schofield@intel.com,
vishal.l.verma@intel.com, ira.weiny@intel.com,
dan.j.williams@intel.com, Alejandro Lucero <alucerop@amd.com>,
Gregory Price <gourry@gourry.net>,
Jonathan Cameron <Jonsathan.Cameron@huawei.com>,
Li Ming <ming.li@zohomail.com>
Subject: Re: [PATCH v3 0/9] cxl: Delay HB port and switch dport probing until endpoint dev probe
Date: Wed, 4 Jun 2025 17:44:31 +0200 [thread overview]
Message-ID: <aEBp30k03GP46eBd@rric.localdomain> (raw)
In-Reply-To: <ff8ec7f0-6cae-4c1b-973d-c126ce60435a@intel.com>
On 03.06.25 06:55:15, Dave Jiang wrote:
> On 5/30/25 6:51 AM, Robert Richter wrote:
> > The port_num can no longer retrieved using sysfs. Previously, the X in
> > dportX could be used to identify the port number (former port_id)
> > which was identical to the numbers in the sysfs target_list entries.
> > This is esp. useful to reconstruct the decoder tree and map pci child
> > devices and its decoders to a parent decoder including its positions
> > in the target list. Maybe create a targetX symlink from the decoder
> > device to the child decoders of it?
>
> The numbers in the target_list are dport->id and should reflect the
> dportX. Is this not what you are seeing?
Exactly, but I would prefer real numbers for the target list, that is,
uid and port_num.
> >
> > Due to the different initialization order there is an odd port
> > numbering now showing up with unexpected, out-of-order sequence
> > numbers, e.g.:
> >
> > /sys/bus/cxl/devices/port1/endpoint2
> > /sys/bus/cxl/devices/port1/endpoint3
> > /sys/bus/cxl/devices/port1/endpoint6
> > /sys/bus/cxl/devices/port4/endpoint5
> > /sys/bus/cxl/devices/port4/endpoint7
> > /sys/bus/cxl/devices/port4/endpoint10
> > /sys/bus/cxl/devices/port4/endpoint11
> > /sys/bus/cxl/devices/port8/endpoint9
> > /sys/bus/cxl/devices/port12/endpoint13
> > /sys/bus/cxl/devices/port12/endpoint14
> >
> > Still, this is correct, but maybe we could force a specific order
> > during initialization, such as per-port initialization which should
> > result in a defined order? Note the shared numbering of ports and
> > endpoints is also confusing, maybe that could be changed here too?
>
> I think the upstream expectation WRT sysfs device number enumeration
> (for all Linux kernel devices) is that no ordering should be
> expected as the devices are initialized async. And previous ordering
> appearance is merely coincidence and not the expectation. And the
> expectation for user tools is that they should not depend on device
> numbering order and identify the devices by other stable means.
sysfs still is human readable and for good reasons not some binary
blob you need a viewer for. Avoiding un-ordered enumeration where
possible helps understanding the topology. So let's think about it and
if possible find a way to get a defined numbering.
Thanks,
-Robert
next prev parent reply other threads:[~2025-06-04 15:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 18:34 [PATCH v3 0/9] cxl: Delay HB port and switch dport probing until endpoint dev probe Dave Jiang
2025-05-21 18:34 ` [PATCH v3 1/9] cxl/region: Add decoder check to check_commit_order() Dave Jiang
2025-05-21 18:34 ` [PATCH v3 2/9] cxl: Add helper to detect top of CXL device topology Dave Jiang
2025-05-21 18:39 ` Dave Jiang
2025-05-22 9:18 ` Jonathan Cameron
2025-05-22 9:43 ` Li Ming
2025-05-21 18:34 ` [PATCH v3 3/9] cxl: Separate out CXL dport->id vs actual dport hardware id Dave Jiang
2025-05-22 9:43 ` Li Ming
2025-05-28 12:53 ` Robert Richter
2025-05-21 18:34 ` [PATCH v3 4/9] cxl: Remove adding of port_num via devm_cxl_add_dport() Dave Jiang
2025-05-21 18:34 ` [PATCH v3 5/9] cxl: Defer hardware dport->port_id assignment and registers probing Dave Jiang
2025-05-22 10:55 ` Li Ming
2025-06-04 15:27 ` Robert Richter
2025-05-21 18:34 ` [PATCH v3 6/9] cxl/test: Add workaround for cxl_test for cxl_core calling mocked functions Dave Jiang
2025-05-21 18:34 ` [PATCH v3 7/9] cxl: Change sslbis handler to only handle single dport Dave Jiang
2025-05-22 11:04 ` Li Ming
2025-05-21 18:34 ` [PATCH v3 8/9] cxl: Create an xarray to tie a host bridge to the cxl_root Dave Jiang
2025-05-21 18:34 ` [PATCH v3 9/9] cxl: Move enumeration of hostbridge ports to the memdev probe path Dave Jiang
2025-05-30 13:51 ` [PATCH v3 0/9] cxl: Delay HB port and switch dport probing until endpoint dev probe Robert Richter
2025-06-03 13:55 ` Dave Jiang
2025-06-04 15:44 ` Robert Richter [this message]
2025-06-05 15:17 ` Dave Jiang
2025-06-06 9:44 ` Robert Richter
2025-06-13 15:15 ` Gregory Price
2025-06-13 15:43 ` Dave Jiang
2025-06-17 17:47 ` Robert Richter
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=aEBp30k03GP46eBd@rric.localdomain \
--to=rrichter@amd.com \
--cc=Jonsathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=alucerop@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=gourry@gourry.net \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=ming.li@zohomail.com \
--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 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.