From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A8AB270EDF; Thu, 7 May 2026 08:16:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778141796; cv=none; b=DnUNoeO++NzSnOXIKtsf8TO6Q3hn/iBdVg5qrDozXqu9GClJNpb1SuDeixsoNQSpuo4w+jphSnqxW75kF53Ww47yY2d37I3cOOhyxMoGaotdUipJCGWm0jGVPZDA6O7uGH4BVtmEFAEyD7VJhYtsJgqkWo5owH2wl/Hd0toRxWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778141796; c=relaxed/simple; bh=QPfTt+pyBlnDFF1TwXqztL0WqBfkEElueSQtmdgH5To=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=fcngh2WiJqIQ3vU5si0Zkd5+pfWfTCmCdXeNzLAES0Hfe4DaGQaUwZ5brt3tZfyR1g3vpOvgTiOlco2ZcTa4qWF4fEBKZa6zkFb3HYtsWm3jhj5gsQzXOe9Jb2umUivTNYVv/3dv6vBORUWv5qDxV+6ilFpAfY3dvwGfh1QArlw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=hv/yPiVn; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="hv/yPiVn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1778141386; bh=QPfTt+pyBlnDFF1TwXqztL0WqBfkEElueSQtmdgH5To=; h=From:To:Cc:Subject:Date:From; b=hv/yPiVncdmnZ13tD75UzM5X5p5h068RXRGnc7vRhfPMdWvhSPk1aBAp2eyF/HRiP yNb6N73Q6LQOyaCwABxEosR4WN1+6MxrLWRr6b/SmjXjUCwvZGfMh0ul8TYzEWPUv0 2NEwLuGoiBENgl+0Bf/Kp7+KNAr4TYEXT88lM6eRXhGoCx1sVmqd81K+xgXBcGb6JA 14R9EU22sE8U0Dc3mSCBQxmMWJnj5AM/shI+7eZTeb4BXkAwTONZt7qZ5sdr//TleM 2cS9ocWUftzEQsf7/kmWc3LtouOymQmsJK5skFLD1Jl6dvYY+R3Q6ZEv12kN/dKlhU hEutmloxNvc7w== Received: from laura.lan (unknown [100.64.0.215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: laura.nao) by bali.collaboradmins.com (Postfix) with ESMTPSA id D7CF917E04AE; Thu, 7 May 2026 10:09:45 +0200 (CEST) From: Laura Nao To: dakr@kernel.org, aliceryhl@google.com, airlied@gmail.com, simona@ffwll.ch, ojeda@kernel.org, boqun@kernel.org, gary@garyguo.net, bjorn3_gh@protonmail.com, lossin@kernel.org, a.hindborg@kernel.org, tmgross@umich.edu, boris.brezillon@collabora.com Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, kernel@collabora.com, Laura Nao Subject: [PATCH v3 0/1] DRM 'feature' support for DRM drivers Date: Thu, 7 May 2026 10:09:13 +0200 Message-Id: <20260507080914.95478-1-laura.nao@collabora.com> X-Mailer: git-send-email 2.39.5 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This is a follow up to [1], which introduces feature support for DRM drivers, as will soon be needed by Tyr and rvkms. Based on feedback and discussion on the first iteration, render node support has been reworked. Support for render nodes was initially modeled as an unsafe trait, to require drivers to comply with any safety requirements tied to enabling a given feature. For DRIVER_RENDER specifically, the intent was to force implementors to ensure that any ioctl declared with DRM_RENDER_ALLOW does not call KMS/modesetting APIs or require DRM_MASTER. However, the C DRM core already enforces render node access control at the ioctl dispatch level: if a client opens a render node, any ioctl without the DRM_RENDER_ALLOW flag will fail. So the C DRM framework already ensures the rules are respected for core ioctls, and the unsafe trait doesn't add any meaningful protection beyond this. For these reasons and since enabling DRIVER_RENDER doesn't require any particular method to be implemented, there's no real need to model this as a trait, and a boolean flag is sufficient. This does not prevent other driver features to be modeled differently based on their requirements. Features that require additional ops (e.g. FEAT_MODESET) could instead be modeled as a trait, and some other constant type that can only be constructed when the relevant trait is implemented. Introducing the FEAT_RENDER bool flag here leaves room for implementing other features differently at a later stage. Changes since v2[2]: - Renamed RENDER_CAPABILITY const to FEAT_RENDER - Expanded documentation for FEAT_RENDER [1] v1: https://lore.kernel.org/rust-for-linux/20260119-drm-render-v1-0-8326e4d5cb44@collabora.com/ [2] v2: https://lore.kernel.org/rust-for-linux/20260505092304.108262-1-laura.nao@collabora.com/ Laura Nao (1): rust: drm: add FEAT_RENDER flag for render node support drivers/gpu/drm/tyr/driver.rs | 1 + rust/kernel/drm/device.rs | 12 +++++++++++- rust/kernel/drm/driver.rs | 12 ++++++++++++ 3 files changed, 24 insertions(+), 1 deletion(-) -- 2.39.5