[Intel-gfx] [PATCH] drm: Differentiate the lack of an interface from invalid parameter

[Chris Wilson]

Quoting Daniel Vetter (2018-09-12 09:39:30)
> On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > If the ioctl is not supported on a particular piece of HW/driver
> > combination, report ENODEV so that it can be easily distinguished from
> > both the lack of the ioctl and from a regular invalid parameter.
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Daniel Vetter <daniel at ffwll.ch>
> > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> Hm, I thought the canonical errno for "ioctl doesn't apply to this
> device" is ENOTTY?

That's ioctl doesn't exist. Sometimes it's nice to know the kernel knows
about the ioctl but it isn't applicable. Either is fine for my purpose,
which is to know the ioctl exists, I just need to distinguish it from
EINVAL.

> And ENODEV means that it applies, but atm nothing
> plugged in, or device gone already.
> 
> I found a few more modeset ioctl:
> - drm_mode_gamma_set_ioctl, drm_mode_gamma_get_ioctl
> - drm_mode_getconnector
> - drm_mode_getcrtc, drm_mode_setcrtc
> - drm_mode_getencoder
> - drm_mode_create_lease_ioctl, drm_mode_list_lessees_ioctl, ...
> 
> Ok now I stop looking through the grep thing, looks like we've been
> using EINVAL consistently. I'm all for switching, it makes sense, but
> I think we should at least try to be consistent across all kms ioctl.

Ah, but we've been consistent on the other side and have been using
ENODEV for the better part of a decade for this meaning (that the ioctl
doesn't apply to this HW) :)
-Chris