On Tue, Feb 10, 2026 at 10:05:14AM +0100, Jiri Pirko wrote: > Mon, Feb 09, 2026 at 09:08:03PM +0100, [email protected] wrote: > >On Mon, Feb 9, 2026 at 7:38 AM Jiri Pirko <[email protected]> wrote: > >> > >> From: Jiri Pirko <[email protected]> > >> > >> 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!
