Technically, the kernel here is not at fault. The only kernel's involvement here is with the
dmcrypt device mapper device configured by
cryptsetup is able to configure the device mapper device based on the metadata as stored on the block device so is not at fault either.
The fact that there's no
/dev/disk/by-uuid entry for the LUKS device stored there points at
udev or whatever is responsible to discovering LUKS devices (see also the output of
udevadm info /dev/the-block-device).
blkid (well, the builtin version see rules in
/lib/udev/rules.d/60-persistent-storage.rules on Debian for instance) to find out about those.
In your case,
TYPE="jmicron_raid_member". If it's a RAID array member, it shouldn't be accessed directly, so
blkid is right not to try and report what may be stored inside.
If it's not meant to be a jmicron_raid_member, then maybe it just happens to still contain the signature for some RAID configuration, for instance because the SSD used to be connected to a PC with ATA Mode set to RAID instead of AHCI in the BIOS (and you forgot to run
blkdiscard before reusing it). Or maybe the 512th last byte happens to be
J and 511th
M by accident.
blkid to stop detecting it as a
jmicron_raid_member if you're sure it's not meant to be and the last 512-byte unit is otherwise not in use by anything, you'd need to wipe the RAID signature, which for jmraid is apparently found in the last 512 byte unit of the block device, either by hand with something like:
size=$(blockdev --getsize -- "$dev") &&
dd if=/dev/zero of="$dev" seek="$((size - 1))" count=1
wipefs -t jmicron_raid_member -- "$dev"
to list the signature.
wipefs -a -t jmicron_raid_member -n -- "$dev"
To show what it would erase.
wipefs -a -t jmicron_raid_member -- "$dev"