Re: [PATCH v2 05/10] cxl: Defer hardware dport->port_id assignment and registers probing

[Dave Jiang <dave.jiang@intel.com>]

On 5/20/25 4:26 AM, Jonathan Cameron wrote:
>   
>>>> diff --git a/drivers/cxl/port.c b/drivers/cxl/port.c
>>>> index a35fc5552845..4d840a6ef802 100644
>>>> --- a/drivers/cxl/port.c
>>>> +++ b/drivers/cxl/port.c  
>>> ... snip ...  
>>>>  	/* Cache the data early to ensure is_visible() works */
>>>> @@ -69,24 +68,7 @@ static int cxl_switch_port_probe(struct cxl_port *port)
>>>>  	if (rc < 0)
>>>>  		return rc;
>>>>    
>>> ... snip ...  
>>>> -	return -ENXIO;
>>>> +	return 0;
>>>>  }  
>>>
>>> 	return devm_cxl_port_enumerate_dports(port);  
>>
>> This was actually done on purpose. devm_cxl_port_enumerate_dports() returns the number of dports enumerated. So usually the return value is greater than 0. in drivers/base/dd.c, call_driver_probe() throws the return value into a switch() where any value not 0 are errors. So the probe() call would fail. Here we are intercepting the return value and return a 0 if it's positive. I got bitten here during this series's debug. I should add a comment and explain why.  
> 
> I'll ask a 'silly' follow up.  Why does devm_cxl_port_enumerate_dports()
> return the number.  From a quick look does anyone use it?  If not
> just change that as a precursor patch and allow this
> tiny bit of code improvement.

I think originally the return value was used to determine of the decoder is passthrough or not. I guess with the new behavior, I don't have access to that and use the dports_ida to do the same thing. We can have it return 0 going forward.

DJ

> 
>>
>>
>>>
>>>
>>> ~Gregory  
>>
>>
>