There's upstream demand for SED OPAL2 (self encrypting drives) support in LUKS2. The supporting arguments for it being added in LUKS2 format follows:

• The HW encryption in current NVME drives may offer performance advantage over SW FDE (TODO: ask performance testing team to provide us with data)
• SED OPAL2 drives reached COTS level prices and are generally available.
• The OPAL2 drives needs to be provided with a key to unlock locking ranges (HW encrypted area). The key needs to be stored/managed somewhere. LUKS2 already solves the problem in a industry standard way.

Supporting arguments for support in RHEL:

• There may be customer case if we decide to certify RHEL for FDE CC in a future (there is HW+SW FDE requirement for some potential customers. IDTech (partner) aims to certify it in a similar approach. The LUKS2 would very easily integrate it in single activation step: "dm-crypt put on top of OPAL2 locking range")
• Another argument for LUKS2 to accommodate suport for SED OPAL2 is very easy integration with current systems. blkid probe would report the device as LUKS2. Less pain to support with products layered currently on top of LUKS2 (NBDE, Stratis and others)
• No additional package required (just libcryptsetup, cryptsetup cli)
• OPAL2 command will be passed via existing sed_opal interface in kernel (already available in RHEL9, but switched off)