The vague POSIX number/name for EREMOTE has nothing to do with the
error condition in inteldrm(4).

It has to do with path handling, probably NFS, it is very unclear.

I suspect what's going on here is the driver wants to provide a unique
error number for a failure condition which will print a different
(obscure, but different) error message to a user or an unknown test
program.  So they chose EREMOTE, rather than ENOMEDIUM or EBADRPC or
37373.

We could document it, but that changes nothing.  POSIX has become
infected with the idea of copying errno names from various systems
without clearly identifing which operations return it in which
conditions, and this has turned into a trashfire where many system calls
can return pretty much any error value, and applications can only do
specific behaviour for a handful of errnos, the rest they either consider
(all?) fatal or (all?) ignorable.

That's the state of the art.  <SHRUG>