Quoting Daniel Vetter (2018-09-12 09:39:30) > On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
