Re: [PATCH v12 1/8] cxl/mbox: Flag support for Dynamic Capacity Devices (DCD)

On Tue, Aug 04, 2026 at 12:12:45AM +0100, Jonathan Cameron wrote:
> > 
> > When I view how this lands in the entirety of cxl_walk_cel() it seems
> > to needlessly be different from the pattern set by poison and security
> > handling in the same function and structures. Could this follow that
> > more closely?  Doing so would remove this 'tail' work here of checking
> > and setting the boolean.
> > 
> > This appended diff touches patch 2 where it has the first caller, but
> > pasting all here for simplicity - you'll apply per patch if you take it.
> > 
> > The bitmap lives in mds structure and it is already where the bool is now.
> > The only piece of the poison and security pattern not worth copying
> > yet is the wrapper struct cxl_poison_state and struct cxl_security_state
> > exist because each grew a mutex and other per-class state, and DCD has
> > none of that in this series (yet).
> Hi Alison,
> 
> This rang a bell as I remembered Ira did it this way originally -
> so I did some archaeology.
> 
> [PATCH v8 01/21] cxl/mbox: Flag support for Dynamic Capacity Devices (DCD)
> https://lore.kernel.org/all/[email protected]/
> 
> Dan's point was that we need that infrastructure for poison and security
> because a subset is a realistic possibility. For DCD today it's all or
> nothing so why keep a bitmap around?
> 
> I agree there is merit in having all the command types handled the same
> but perhaps it is clearer to just have a bool.  Of course when someone
> adds another DCD command on the device side (which by definition will have
> to be optional) then we will need to revisit.
> 

Yeah, and it's not really binding ABI so no need for complexity until we
get there.  Honestly the feature bit check is essentially the same as
the bitmap check at this point, so seems find to push that
generalization off until we actually need it.

~Gregory