Re: [PATCH v21 00/23] Type2 device basic support

[Alejandro Lucero Palau <alucerop@amd.com>]

On 11/28/25 19:44, PJ Waskiewicz wrote:
> Hi Alejandro,
>
> On Wed, 2025-11-19 at 19:22 +0000, alejandro.lucero-palau@amd.com
> wrote:
>> From: Alejandro Lucero <alucerop@amd.com>
>>
>> The patchset should be applied on the described base commit then
>> applying
>> Terry's v13 about CXL error handling. The first 4 patches come from
>> Dan's
>> for-6.18/cxl-probe-order branch with minor modifications.
>>
>> v21 changes;
>>
>>    patch1-2: v20 patch1 splitted up doing the code move in the second
>> 	    patch in v21. (Jonathan)
>>   
>>    patch1-4: adding my Signed-off tag along with Dan's
>>
>>    patch5: fix duplication of CXL_NR_PARTITION definition
>>
>>    patch7: dropped the cxl test fixes removing unused function. It was
>> 	  sent independently ahead of this version.
>>
>>    patch12: optimization for max free space calculation (Jonathan)
>>
>>    patch19: optimization for returning on error (Jonathan)
>>
> So I'm unable to get these patches working with a Type2 device that
> just needs its existing resources auto-discovered by the CXL core.
> These patches are assuming the underlying device will require full
> setup and allocations for DPA and HPA.  I'd argue that a true Type2
> device will not be doing that today with existing BIOS implementations.


Well, I'd argue this patchset is what the sfc driver needs, which is the 
client for this "initial Type2 basic support".


> I've tested this behavior on both Intel and AMD platforms (GNR and
> Turin), and they're behaving the same way.  Both will train up the
> Type2 device, see there's an advertised CXL.mem region marked EFI
> Special Purpose memory, and will map it and program the decoders.
> These patches partially see those decoders are already programmed, but
> does not bypass that fact, and still attemps to dynamically allocate,
> configure, and commit, the whole flow.  This assumption fails the init
> path.


Fair enough. We knew about this and as I said, something I would prefer 
to do as a follow up work or this patchset will be delayed, likely until 
a new requirement is found out like the problem about DVSEC BAR already 
being mapped, then waiting for the next thing not covered in this 
"initial Type2 basic support".


>
> I think there needs to be a bit of a re-think here.  I briefly chatted
> with Dan offline about this, and we do think a different approach is
> likely needed.  The current CXL core for Type3 devices can handle when
> the BIOS/platform firmware already discovers and maps resources, so we
> should be able to do that for this case.


I'm sad to hear that ... I'm getting internal pressure for getting this 
Type2 done and I realize now it will require "a different approach" for 
being accepted.


Being honest, this is quite demoralizing. Maybe I'm not the right person 
to get this through.



> If you're going to be at Plumbers in a week or so, this would be a
> great topic if we could grab a whiteboard somewhere and just hack on
> it.  Otherwise we can also chat on the Discord (I just joined finally)
>
> Cheers,
> -PJ