Re: [RFC PATCH 01/13] cxl: move header files for absolute references

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

On 6/12/24 22:18, Dan Williams wrote:
> Christoph Hellwig wrote:
>> On Tue, Jun 11, 2024 at 09:27:38PM -0700, Dan Williams wrote:
>>> alucerop@ wrote:
>>>> From: Alejandro Lucero <alucerop@amd.com>
>>>>
>>>> CXL Type 2 devices imply specific vendor drivers binding to those
>>>> devices instead of generic ones offered by CXL core like the PCI driver.
>> No, it absolutelt does not.  There is no such thing as a vendor driver
>> in Linux.
>>
>>> So I don't like this approach, there are details that are private to the
>>> CXL generic memory-expander use case, and some that are suitable for
>>> CXL.mem and CXL.cache capabilities in other drivers. That distinct
>>> subset should move to include/linux/. I.e. I want to see the incremental
>>> conversion of what 3rd party drivers need compared to the generic
>>> expander case, and consider when and where new shared infrastructure
>>> needs to be refactored.
>> And I'd much rather keep all these drivers in drivers/cxl/ anyway so
>> that we can keep a tight control over them.
> Yeah, especially for the common pieces like CXL memory where the
> endpoint driver is responsible for registering a 'struct cxl_memdev' and
> the existing 'cxl_mem' driver just grows to accommodate device-memory
> alongside host-only memory expansion.
>
> For CXL accelerator use case that's where more specifics are needed
> because CXL.cache operation gets entangled with IOMMU / DMA mapping
> policy for ATS.

I think we all agree the central pieces should be in CXL core and other 
drivers requiring CXL setup going through such central management.

But this can be implemented as I thought and tried, and Jonathan has 
also suggested, that is an API with opaque structs, or through a more 
disjointed way from a client/driver perspective using an approach like 
auxbus. Maybe there is another approach for "keep all these drivers in 
drivers/cxl/ anyway so that we can keep a tight control over them" which 
needs to be more explicitly elaborated.

My plan is for a v2 removing the test/mock driver and adding the sfc 
driver as a client, but only if the original approach with the CXL core 
exporting functions is the approved one. If auxbus or other way is the 
way to go, it will be just a new patchset and requiring more time.