From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 535C3EA8105 for ; Tue, 10 Feb 2026 12:48:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id ADBD710E082; Tue, 10 Feb 2026 12:48:26 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="Omxd9ntP"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3CF8A10E082 for ; Tue, 10 Feb 2026 12:48:25 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 47D8A6013E; Tue, 10 Feb 2026 12:48:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AAD6C116C6; Tue, 10 Feb 2026 12:48:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770727704; bh=f9Hioy1nBNAN6Nj6FmxHzvPM8qjWxbtxXn6ma/BOEN4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Omxd9ntPib7buprI2avF9vcC5Snk52LrNPhoNyFSO+Pp/RnFY9OpJi8PDjJVaxHmb JXUYYvf8mDOqJL00C/SA5U6DUzy7M/eEd+7C4i1SVv3A4qZh92mM5Rm14mro68cR2t 6h0t8AeSTNBPNmliXeDF6glQjfeed1kx5MhPTPGFC1WpXrv0JLEgHiJbUaah2n5b5Z gAdRG3klf2YYAP5MWPc6bLxDm6TKYyUEZQvEGN2z5fMUW9rlSD2hezSOCJvY1XcU/+ BRxCvbm1bcNecNnEBO0TGKpRpqR28vrU2kjBTA1jfqTtyRVkkCx0KnIFJBp3Nan0jG VoQHRcdYSklIg== Date: Tue, 10 Feb 2026 14:48:19 +0200 From: Leon Romanovsky To: Jiri Pirko Cc: John Stultz , dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, iommu@lists.linux.dev, linux-media@vger.kernel.org, sumit.semwal@linaro.org, benjamin.gaignard@collabora.com, Brian.Starkey@arm.com, tjmercier@google.com, christian.koenig@amd.com, m.szyprowski@samsung.com, robin.murphy@arm.com, jgg@ziepe.ca, sean.anderson@linux.dev, ptesarik@suse.com, catalin.marinas@arm.com, aneesh.kumar@kernel.org, suzuki.poulose@arm.com, steven.price@arm.com, thomas.lendacky@amd.com, john.allen@amd.com, ashish.kalra@amd.com, suravee.suthikulpanit@amd.com, linux-coco@lists.linux.dev Subject: Re: [PATCH 4/5] dma-buf: heaps: allow heap to specify valid heap flags Message-ID: <20260210124819.GC12887@unreal> References: <20260209153809.250835-1-jiri@resnulli.us> <20260209153809.250835-5-jiri@resnulli.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Feb 10, 2026 at 10:05:14AM +0100, Jiri Pirko wrote: > Mon, Feb 09, 2026 at 09:08:03PM +0100, jstultz@google.com wrote: > >On Mon, Feb 9, 2026 at 7:38 AM Jiri Pirko wrote: > >> > >> From: Jiri Pirko > >> > >> Currently the flags, which are unused, are validated for all heaps. > >> Since the follow-up patch introduces a flag valid for only one of the > >> heaps, allow to specify the valid flags per-heap. > > > >I'm not really in this space anymore, so take my feedback with a grain of salt. > > > >While the heap allocate flags argument is unused, it was intended to > >be used for generic allocation flags that would apply to all or at > >least a wide majority of heaps. > > > >It was definitely not added to allow for per-heap or heap specific > >flags (as this patch tries to utilize it). That was the mess we had > >with ION driver that we were trying to avoid. > > > >The intent of dma-buf heaps is to try to abstract all the different > >device memory constraints so there only needs to be a [usage] -> > >[heap] mapping, and otherwise userland can be generalized so that it > >doesn't need to be re-written to work with different devices/memory > >types. Adding heap-specific allocation flags prevents that > >generalization. > > > >So instead of adding heap specific flags, the general advice has been > >to add a separate heap name for the flag property. > > Right, my original idea was to add a separate heap. Then I spotted the > flags and seemed like a great fit. Was not aware or the history or > original intention. Would be probably good to document it for > future generations. > > So instead of flag, I will add heap named something > like "system_cc_decrypted" to implement this. It is problematic to expose a user‑visible API that depends on a name. Such a design limits our ability to extend the functionality in the future, should new use cases arise. Thanks > > Thanks!