Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2136488pxb; Wed, 9 Feb 2022 11:37:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJz0CRP4AxizuZvvd5ex4xBGuEINzoQoXJ0j0flsOpfscXpsIhkB+T1jLnDJtWXZbrlvzll5 X-Received: by 2002:a17:90b:1e41:: with SMTP id pi1mr4219396pjb.62.1644435424707; Wed, 09 Feb 2022 11:37:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644435424; cv=none; d=google.com; s=arc-20160816; b=Kl0F1ejzVNludLJSUdDzeBVZv4bUcgOe5Nc9BHk4x3gLayL+Lfwx/ngpW5LTld3RzV dz2hmX3cfI1M3HBE8LVM/sQBE6vC9dZtV2ipk3PdlpqWDMWnEKFFYXrR2zwtIU1y2vjb z+IcAYfPTed3Cdo67JkNB6D49i3GPS1LgXLsZ/YX+uUXrI3ky+lAum0MR8Fori4UjZMi 1DX92Hn0F25WRpXh7wu5DutX3bnqIxHqsEapSOuO+lKxhKS/S1seKwvB6NPKP2VyZ8B5 bHnwpza0pIY8dIHBuGiHa/IzUZ0kbuWzb9CnKquX3/4Woom8CWKl3Lza2otEoUnGLmS2 AB0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=blQ5+6q/LUbVLtrZhxoQdICeLoyj5HXqRvqkBFLbaVU=; b=s7niYa6F/LYs0Iwogz5X6PSKcqv3TjgGHe/Gt7o8L0/D+d9mifUEowXlZRhyw53rzT Vda3If3isem1l974j5dJPUG3Xf+t7K12C1qMVltnnLN/F6bHLD0YqZALjE6afBKvOYN1 6kNbZotHZsZx6e3FZ/cX96Y6xcZtNbuUi36Cufo3IB1KnO86rfHNz+Iv2jUKmgnJP5sg 6mwyOQA86S9tkEvpo0YJcN0xE0BmGeiohVNEQfQ22k22rP3Q9/jSkoIwZdK9ClY5XSKI bBGcLrTw1s0lbESrnoNZ+YrfIhpzqtXJH2OsEgIXLBsjrHO2IqiKkD2xeZLXkVZE7OEv /dbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=I2mu5Bt9; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q85si15888519pgq.656.2022.02.09.11.37.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 11:37:04 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=I2mu5Bt9; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F0D00C1DF8F4; Wed, 9 Feb 2022 11:36:30 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241512AbiBITAC (ORCPT + 99 others); Wed, 9 Feb 2022 14:00:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241773AbiBIS7o (ORCPT ); Wed, 9 Feb 2022 13:59:44 -0500 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 016C6C05CB88; Wed, 9 Feb 2022 10:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1644433073; x=1675969073; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=blQ5+6q/LUbVLtrZhxoQdICeLoyj5HXqRvqkBFLbaVU=; b=I2mu5Bt9CFFerjym4wTfFklZXhg8HBcKrHN/ajQDJj1s/GiVbFW6IGRQ 8Ca+wOAe5ScRdKsCjwWEW5glP+ZQ5t2NE1Jsq3ekvsaMC0bSGZe7Eeh5s F2FzLRxRpNNIWwkyERkWLvGSBV+1rsp2xveo7m0bQzRqsllGIGerGcOw7 8=; Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-01.qualcomm.com with ESMTP; 09 Feb 2022 10:57:52 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2022 10:57:52 -0800 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Wed, 9 Feb 2022 10:57:51 -0800 Received: from jhugo-lnx.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Wed, 9 Feb 2022 10:57:50 -0800 From: Jeffrey Hugo To: , , , , , CC: , , , Jeffrey Hugo Subject: [PATCH] drm/doc: Clarify what ioctls can be used on render nodes Date: Wed, 9 Feb 2022 11:57:27 -0700 Message-ID: <1644433047-20753-1-git-send-email-quic_jhugo@quicinc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The documentation for render nodes indicates that only "PRIME-related" ioctls are valid on render nodes, but the documentation does not clarify what that means. If the reader is not familiar with PRIME, they may beleive this to be only the ioctls with "PRIME" in the name and not other ioctls such as set of syncobj ioctls. Clarify the situation for the reader by referencing where the reader will find a current list of valid ioctls. Signed-off-by: Jeffrey Hugo --- I was confused by this when reading the documentation. Now that I have figured out what the documentation means, I would like to add a clarification for the next reader which would have helped me. Documentation/gpu/drm-uapi.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 199afb5..ce47b42 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -148,7 +148,9 @@ clients together with the legacy drmAuth authentication procedure. If a driver advertises render node support, DRM core will create a separate render node called renderD. There will be one render node per device. No ioctls except PRIME-related ioctls will be allowed on -this node. Especially GEM_OPEN will be explicitly prohibited. Render +this node. Especially GEM_OPEN will be explicitly prohibited. For a +complete list of driver-independent ioctls that can be used on render +nodes, see the ioctls marked DRM_RENDER_ALLOW in drm_ioctl.c Render nodes are designed to avoid the buffer-leaks, which occur if clients guess the flink names or mmap offsets on the legacy interface. Additionally to this basic interface, drivers must mark their -- 2.7.4