I thought BitLocker stopped trusting SEDs after the last time around when drives were discovered to be trivially broken? 
But apparently this change only just happened a couple months ago. 
 - https://www.zdnet.com/google-amp/article/flaws-in-self-encry...
 - https://www.pcworld.com/article/3441864/bitlocker-windows-bu...
Edit: In fact the conference was in May so about six months after the first story based on the draft version. Not quite sure why it's hitting HN front page now
If you can't see the final data after encryption, you have no way of verifying if it was actually done or how well it was done.
Nothing short of a standard SSD platform with independently removable, externally readable/writeable, and installable firmware and flash modules would completely satisfy that requirement though. It'd be interesting to have but certainly cost prohibitive.
For circumstances where the data is genuinely sensitive, we've pushed for physical destruction of the drive. Bonus: throwing pallets of old drives into the incredibly loud shredder our destruction partners use is a lot of fun.
The downside of having encryption done on the CPU is that it has a max throughput and latency burden (even with AES acceleration) which isn't a problem for SATA devices (both HDD & SSD) but it is with new high-end NVMe drives that can see througput in excess of 1GB/s.
On the other hand, LUKS still has it's own attack methods when a volume is opened (cold->hot). If the keyfile/password is stored on a seperate drive or entered manually, the interface (USB keyboard, SATA connection, motherboard chipset, etc) could be exploited to retrieve the key in cleartext. If the key is stored or tied to the machines TPM, then it's up in the air as to wheter Intel/AMD + the motherboard's manufacture didn't leave a flaw somewhere. i.e How much more secure is the mobo/CPU TPM than the OPAL/ATA based encryption found on these drives?
Anyway, neither kernel fscrypt, nor dmcrypt have any dependency on drive embedded crypto. They do use AES-NI or equivalent, if available and if that support is compiled into the kernel.
Detail output from top while doing a scrub on a LUKS encrypted system. (Expires in 7 days.)
dm-crypt (of which LUKS is a part) certainly does not do that.
Edit: Looks like the models they chose to test are consumer oriented products. I'm more interested in enterprise oriented products. They didn't cover any drives that I actually use in the encrypted laptops that I deploy.