Alistair Francis wrote:
> On Thu, Feb 12, 2026 at 3:56 PM <dan.j.williams@intel.com> wrote:
[..]
> >
> > So this is where it will collide with TSM that also emits an
> > authenticated attribute. See Documentation/ABI/testing/sysfs-bus-pci.
> >
> > The rough plan Lukas and I worked out is that switching between TSM and
> > CMA based authentication would use sysfs visibility to coordinate. I.e.
> > TSM to CMA conversion hides the TSM "authenticated" attribute and
> > unhides the CMA attribute of the same name.
> 
> That seems straightforward and is already documented upstream as well,
> so that's pretty easy.

Later in the thread I proposed an alternative that instead of supporting
2 flavors of uapi through "authenticated", instead implement CMA as
another TSM driver [1].

[1]: http://lore.kernel.org/69976d7d39c60_2f4a1009@dwillia2-mobl4.notmuch

> > The most significant unsolved point of contention between TSM and CMA is
> > the policy on when authentication is mandated and the driver probe
> > policy. The proposed model for enforcing device security for
> > Confidential Computing is make it completely amenable to userspace
> > policy. Draft details here [2] to be refreshed "soon" when I send out
> > the next version of that.
> >
> > [2]: http://lore.kernel.org/20250827035259.1356758-6-dan.j.williams@intel.com
> 
> CMA will eventually need to support some sort of drive probe policy as
> well, but that can wait until later and isn't going to be dealt with
> in this series.

Makes sense, and Greg wants to a see a more universal "device trust"
mechanism for this. This also means CMA as a TSM driver gets that
mechanism "for free" when the PCI/TSM effort moves it forward.

> > To be clear I am ok if there is an incremental option to have auto_cma
> > and/or auto_tsm that arranges for authentication or link encryption to
> > happen without asking. I take issue with auto_cma being the only hard
> > coded option.
> 
> I have been working through all of the comments and discussions and I
> think I have addressed everything, except for this one.
> 
> To summerise, is the high level issue is how do we know if we should
> use CMA or TSM?
> 
> Do you have any more thoughts on this?

So most of the thinking is in that [1] above, and the new mechanism
would just be to auto-connect to the first TSM driver that appears, or
auto-connect to the TSM driver with the most capbility. For example,
auto-connect to the CMA-TSM at initial discovery, switch to Platform-TSM
if the device additionally supports IDE.