From patchwork Fri Aug 18 17:43:28 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 9909669 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EC51C600CC for ; Fri, 18 Aug 2017 17:44:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E0A3928C9F for ; Fri, 18 Aug 2017 17:44:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D522328CBA; Fri, 18 Aug 2017 17:44:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 20FE328CA1 for ; Fri, 18 Aug 2017 17:44:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8C80B6E796; Fri, 18 Aug 2017 17:43:39 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9EB3E6E797 for ; Fri, 18 Aug 2017 17:43:38 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id d40so4952580wma.3 for ; Fri, 18 Aug 2017 10:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id; bh=2SEVEn8nd5U7/GCG3JUoTMFdIcDNHXRzlFKP2Nqcjn4=; b=PwKcdI2acLRMqb7fmXohb/wIVSino1BmYGGvziVxif7q/VddzGH1fV+ccWEUVQubtE f5Qz/vYyG24KujLzYal+u/QOCQFxkX5qMb+8q0X4vI0frNDF8y1rcbrzAF47bLFepTZ2 fiLHdgtmpxDyo/XWGfKKW77JY7j4uzQJ6vsAQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=2SEVEn8nd5U7/GCG3JUoTMFdIcDNHXRzlFKP2Nqcjn4=; b=muwElDArJfEwjtD7SrZKnaKZeg0tOrm/2MuyT0pIqzHcUBVJen5DLjh44UlBqL3CuR G7EgYLZJsByOOGdYMrqk1j9XFNRQwpXknP2y2eMEecQeitJxdcuACjB4PHvJbhtPJK9S aJtP3me4m+dYrEVYneBxe8FgH7tcCx1hy7OSQbzKMXUGhO6vq1VuY8f/ifY/x/Z1dNsY nKmkyTKlGv796rcGRs6kxEcpCtrq371syYtU23FpEGNnE0eSgifkToJhDzGO14keIL/N mWvoZtnvpFhGaI8iic8YEySK+SL4yQ1HN+4QW527jM/cnHyCZIg9Lk4eiSG4uabzUget eGAw== X-Gm-Message-State: AHYfb5jX0Fz3c5xfAo1dKpTGBGBYt4j7SAXqgF7lMtlMGJQDCSrCCXlR ON3BehSI2iAnJQ0UrrY= X-Received: by 10.80.165.181 with SMTP id a50mr5477580edc.26.1503078216769; Fri, 18 Aug 2017 10:43:36 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:56e6:0:e4bc:76a0:8042:669e]) by smtp.gmail.com with ESMTPSA id u3sm3736860edb.20.2017.08.18.10.43.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 10:43:35 -0700 (PDT) From: Daniel Vetter To: DRI Development Subject: [PATCH] drm/doc: Document ioctl errno value patterns Date: Fri, 18 Aug 2017 19:43:28 +0200 Message-Id: <20170818174328.6386-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.13.3 Cc: Daniel Vetter , Intel Graphics Development , Joonas Lahtinen , "Zhang, Tina" , Daniel Vetter X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP We're not super-consistent about these, but I think it's worth to document at least the commmon patterns. v2: - Add a not about ENOTTY (it's just a confusing name, but used exactly what it's meant for in DRM) (Chris). - Unconfuse the text for ENODEV (Daniel) - Move text undert the IOCTL heading (Chris). - typos Cc: Daniel Stone Cc: Joonas Lahtinen Cc: Chris Wilson Cc: "Zhang, Tina" Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-uapi.rst | 55 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 679373b4a03f..a2214cc1f821 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -168,6 +168,61 @@ IOCTL Support on Device Nodes .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c :doc: driver specific ioctls +Recommended IOCTL Return Values +------------------------------- + +In theory a driver's IOCTL callback is only allowed to return very few error +codes. In practice it's good to abuse a few more. This section documents common +practice within the DRM subsystem: + +ENOENT: + Strictly this should only be used when a file doesn't exist e.g. when + calling the open() syscall. We reuse that to signal any kind of object + lookup failure, e.g. for unknown GEM buffer object handles, unknown KMS + object handles and similar cases. + +ENOSPC: + Some drivers use this to differentiate "out of kernel memory" from "out + of VRAM". Sometimes also applies to other limited gpu resources used for + rendering (e.g. when you have a special limited compression buffer). + Sometimes resource allocation/reservation issues in command submission + IOCTLs are also signalled through EDEADLK. + + Simply running out of kernel/system memory is signalled through ENOMEM. + +EPERM/EACCESS: + Returned for an operation that is valid, but needs more privileges. + E.g. root-only or much more common, DRM master-only operations return + this when when called by unpriviledged clients. There's no clear + difference between EACCESS and EPERM. + +ENODEV: + Feature (like PRIME, modesetting, GEM) is not supported by the driver. + +ENXIO: + Remote failure, either a hardware transaction (like i2c), but also used + when the exporting driver of a shared dma-buf or fence doesn't support a + feature needed. + +EINTR: + DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can + return EINTR and in such a case should be restarted with the IOCTL + parameters left unchanged. + +EIO: + The GPU died and couldn't be resurrected through a reset. Modesetting + hardware failures are signalled through the "link status" connector + property. + +EINVAL: + Catch-all for anything that is an invalid argument combination which + cannot work. + +IOCTL also use other error codes like ETIME, EFAULT, EBUSY, ENOTTY but their +usage is in line with the common meanings. The above list tries to just document +DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of +"this IOCTL does not exist", and is used exactly as such in DRM. + .. kernel-doc:: include/drm/drm_ioctl.h :internal: