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

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Wed, 12 Jun 2024 06:54:13 +0100
Alejandro Lucero Palau <alucerop@amd.com> wrote:

> On 6/12/24 05:30, 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.  
> 
> 
> Well, yes, I see your point, and it is absolutely correct.
> 
> It was a bad way of explaining the need of a driver supporting a 
> specific hardware.
> 
> 
> >> 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.
> >  
> 
> My initial thought was drivers for ethernet, gpus, or any other kind of 
> standard device binding to the CXL/PCIe.io and doing the CXL 
> initialization. Your comment seems to suggest other approach, which I 
> can only relate to using auxbus for the device CXL.mem and CXL.cache, 
> and  then being handled by a generic driver inside the CXL core. Is this 
> what you are suggesting?
> 
> If so, I'm not against it, although it would require to study the 
> implications.

I'd be very careful with that level of complexity.
So far I'm not seeing it as useful for this case (but I could be wrong)

Maybe just a case of well defined library code with only
opaque state etc being exposed by the CXL driver framework.

The bulk of any type2 driver needs to be in the appropriate subsystem
not drivers/cxl/  The non CXL parts will be more important to keep
aligned with appropriate subsystem than the CXL part. 

Jonathan

> 
>