Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2418831pxp; Mon, 7 Mar 2022 15:11:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJyRtOKpxjblc2+ze+wZHEwBW9Gfpd9GLRUhqwrdIXmaFhsWFimTU6NwJp1tXC4juMPiNvd1 X-Received: by 2002:a05:6402:4316:b0:416:6770:11de with SMTP id m22-20020a056402431600b00416677011demr1306590edc.316.1646694672711; Mon, 07 Mar 2022 15:11:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646694672; cv=none; d=google.com; s=arc-20160816; b=n/byaeJo40jKjdHQk2H2DXQNVRHNH487N6gBpakeLFsjWMn9L1UmA6XvsrHSIYO6Gp wPFvxZxhsJs4tzxFLwPpDYmt7UxLPlpEVeh6bb85gxEIqvOvdUgsBECC7woA1j17MemF 7WrgLh3M33LVK3mfaV9wM5gZFbMZCWZ5+z0bTbHT9bGsNo+v6zve1cigD20ze06zqq/p A0kA8NK11SSw3xO1Q/PVBJtt4vx0rUlNU4/5MZr9PCH8fHcq6Q/nj96DfzvRbefVZHKM DbFxiQdL/i5x5xxoceZfGN95usMU7toGqsGKTjKiABccwyK5yp0d+a8F8Yu9tsr4RVTu HpJQ== 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=Gsmx9JsR+nCJ1tL1LopmQSPZOhGLxmtw74vFEai5lBE=; b=c57CeHOl2TmwWPXkPf5+vozzsZwVb2MSN7fdp5vBr4U5j6wuQu7URG4nCgGbXuS0qX g7XRQrYt+YoOnCoxLSwsMhqfkMrudLVumy9rte3Z6nMk83/w7PIjc/2RGJy7UjZgJkLd gvTcLcOgLK0wkibRlVjowraNf8vdEgx6Lq7HjvYXHAOpGuPbf1PPrCb71qN4Br0xlUux IH3HlSAvZor0DDRsU3/aMpLevWaCURi1vn6qhNjdq56HrEe0YLS91NV1RQ+dW8ZwwV5k m5LZiRC3hW/9UFsviSgllO62D8nKWLI7z1TtugTWfib7WO+39myRAIegjL/pod8MUee/ nSPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=h5dj0Vv9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji5-20020a170907980500b006da970999d1si9105995ejc.409.2022.03.07.15.10.50; Mon, 07 Mar 2022 15:11:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=h5dj0Vv9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243803AbiCGPdy (ORCPT + 99 others); Mon, 7 Mar 2022 10:33:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243812AbiCGPdt (ORCPT ); Mon, 7 Mar 2022 10:33:49 -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 07665403D1; Mon, 7 Mar 2022 07:32: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=1646667173; x=1678203173; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Gsmx9JsR+nCJ1tL1LopmQSPZOhGLxmtw74vFEai5lBE=; b=h5dj0Vv9gfNotDjru9MdDRnenfhEOhcnjSHGQ8pH8HaEICjN3KH5h9de T3Q9lNJbjX84cD6mEAwSOxOXeIo+WzucdhjgAc02RvhXbkvyIThhF3t7A vWTftTVlRAh7QhiVxJ6JoaK39Emy6Hrt5QUZDfC8rAiWeE+clZpkU/nZC Y=; Received: from unknown (HELO ironmsg02-sd.qualcomm.com) ([10.53.140.142]) by alexa-out-sd-01.qualcomm.com with ESMTP; 07 Mar 2022 07:32:52 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg02-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Mar 2022 07:32:51 -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.986.15; Mon, 7 Mar 2022 07:32: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.986.15; Mon, 7 Mar 2022 07:32:50 -0800 From: Jeffrey Hugo To: , , , , , CC: , , , , Jeffrey Hugo Subject: [RESEND PATCH] drm/doc: Clarify what ioctls can be used on render nodes Date: Mon, 7 Mar 2022 08:32:36 -0700 Message-ID: <1646667156-16366-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=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Acked-by: Pekka Paalanen --- 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