Re: [PATCH 1/9] cxl/port: Cleanup handling of the nr_dports 0 -> 1 transition

[Jonathan Cameron <jonathan.cameron@huawei.com>]

On Wed, 21 Jan 2026 19:33:22 -0800
Dan Williams <dan.j.williams@intel.com> wrote:

> There are multiple setup actions that can occur for a switch port after it
> is known that it has at least one active downstream link. That work is
> currently split between __devm_cxl_add_dport(), the add_dport() helper, and
> cxl_port_add_dport() where decoder setup occurs.
> 
> Clean this up by moving all @dport object setup responsibilities into
> add_dport() and all port effects into cxl_port_add_dport().
> 
> add_dport() handles taking a reference on @dport->dport_dev, and
> cxl_port_add_dport() grows the awareness to setup the port component
> registers. This removes an awkward open-coded xa_erase() from the middle of
> __devm_cxl_add_dport() and instead tasks cxl_port_add_dport() with calling
> the common @dport destruction path if anything goes wrong.
> 
> After this @port->nr_dports is always the count of @dports in the
> @port->dports xarray, and cxl_dport_remove() is symmetric with add_dport().
> With ->nr_dports now reliably tracking the number of dports the use of
> ida_is_empty() can be dropped. Recall that the ida is only cleared on
> "release" of decoder objects, and release can be arbitrarily delayed past
> unregistration.

Given we only care about nr_dports going to and and from 0, why do
we need nr_dports at all?  Why not use xa_empty() as the condition.

Does this now guarantee we don't need the extra nr_dports reset in
cxl_switch_port_probe()?  That also made me suspicious of something
funny going on as the count should have dropped to zero if we
are in state to rebind.

Other than those this looks good to me and both of those are perhaps
topics for other patches even if maybe they could be done in here.

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>