Some additional technical background of this problem(source: [1/1] sd: do not let LBPME bit stop the VPDs speak - Patchwork), the kernel maintainer specifically mentions:
We don't skip the entire VPD page if LBPME=1, just the parts that are
related to the logical block provisioning.
The reason we read those values in the first place is so that we can set
up discard. If the device signals that it does not support discard we
have had no reason to read them or parse them.
Since there are a plethora of USB-SATA devices out there that get this
incredibly wrong (including discarding blocks *outside* of the specified
block range), I am not going to blindly enable this feature.
If you want to tinker with your own setup that's fine. And you are
clearly capable of doing so.
I, however, have to be extremely cautious not to enable something that
might inadvertently cause data corruption for users out there. That's
all I care about.
If the device manufacturer had intended to support discards then they
would presumably have set the LBPME flag per the spec. And if they
intended to support it but messed up setting the single bit flag that
enables the feature, then I would not trust their implementation.
The root cause of the compatibility issue is that the bridge chip manufacturer didn’t conform to the SCSI specification, not that the operating system doesn’t support the feature. As you’re assumed to be the direct customer of the NVMe to USB bridge solution you should have the right to inform the solution manufacturer that something is wrong with their firmware implementation, not us.
And in the very unfortunate case where your solution provider is incompetent to fix their implementation, it should be clearly mentioned on the product’s specification page, not in a forum post that is nowhere to be found on the product website.