Re: [PATCH v3 05/16] cxl/mbox: Add GET_FEATURE mailbox command

[Dan Williams <dan.j.williams@intel.com>]

Jonathan Cameron wrote:
> On Wed, 5 Feb 2025 15:12:16 -0800
> Dan Williams <dan.j.williams@intel.com> wrote:
> 
> > Jonathan Cameron wrote:
> > [..]
> > > > So I see this is exported to a new cxl_fwtcl.ko module, but I think all
> > > > of this can be core built-in functionality similar to memdev ioctl and
> > > > firmware upload support. As long as distributions can opt-out of FWCTL
> > > > and Features at build time then this is no worse than
> > > > CONFIG_CXL_MEM_RAW_COMMANDS from a proprietary use case / security model
> > > > stance. With that software only needs to worry about finding a
> > > > cxl_memdev object and not manually loading a cxl_fwctl module.  
> > > 
> > > It'll get exported shortly anyway as it's used by the EDAC series
> > > and that should be separate modules.    
> > 
> > What additional modules are needed for EDAC support? The registration is
> > done by the cxl_mem and cxl_region drivers. Are you thinking of a pure
> > helper library module to the CXL core?
> > 
> > Does it really matter if it's a separate module if cxl_core.ko is going
> > to demand load it always?
> 
> I've lost track of all the reorganizing.  Might indeed not be needed
> because it is wrapped up other calls that are in the cxl core.
> 
> I'll let Shiju figure that out when rebasing!  Note the two sets may
> well race as I don't want to hold the discussion on remaining 
> controversial bits of that set whilst Dave refactors this one.
> The need to eventually rebase on this doesn't stop the EDAC core bits
> going forwards.

Given the EDAC entanglements and ongoing discussions about FWCTL, I
suggest we merge the common bits to a shared topic branch.

It is not clear to me that either consumer, EDAC / FWCTL, can clearly
claim to be ahead of the other, but I do think we land the common bits
to get that part settled while the rest plays out.