Re: [PATCH v1 1/1] cxl/hdm: Verify HDM decoder capabilities after parsing

[Li Ming <ming.li@zohomail.com>]

On 3/1/2025 7:45 AM, Dan Williams wrote:
> Alison Schofield wrote:
>> On Fri, Feb 28, 2025 at 10:47:12AM +0800, Li Ming wrote:
>>> On 2/28/2025 5:47 AM, Alison Schofield wrote:
>>>> On Thu, Feb 27, 2025 at 06:32:51PM +0800, Li Ming wrote:
>>>>> devm_cxl_setup_hdm() only checks if decoder_count is 0 after parsing HDM
>>>>> decoder capability, But according to the implementation of
>>>>> cxl_hdm_decoder_count(), cxlhdm->decoder_count will never be 0.
>>>> How does a check against the spec maximums benefit this driver? Is there
>>>> a bad path we avoid by checking and quitting at this point.
>>>
>>> My understanding is that no a bad path on driver side if the decoder_count is greater than the maximum number spec defines.
>>>
>>> Driver just allocates cxl decoders on the port based on the value of decoder_count. But I am not sure if hardware will have other potential problems when it didn't follow the spec.
>> I had the general thought that the driver is not responsible for
>> compliance checking the device, unless it affects function. Excessive
>> decoder_count's sound like they cause needless allocations, so let's
>> stop doing that - as best we can. 
> Only if we see a device in the wild that causes an actual problem.
> Otherwise this is a losing theoretical game of adding checks for things
> that will likely never be violated. The way to address devices that
> violate spec expectations *and* cause end user visible pain is to add
> quirks. The allocation of a few extra decoders is does not amount to
> that standard.
>
> Lets not add checks for benign issues "just because", or "just in case".
> If the check is cheap and we need to do it for the driver's own internal
> sanity, fine, but if it's just being strict for strictness sake, please
> no.

Got it, thanks for explanation.


Ming