linux-kernel - Re: [RFC][PATCH 1/3] dt-bindings: dma-buf: heaps: Describe CMA regions to be added to dmabuf heaps interface.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALAqxLXG8LrWAQevEyj7BJ00CiAkodfgFMdCbuMRucO5w5yhKg@mail.gmail.com>
Date:   Fri, 25 Oct 2019 16:55:35 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Rob Herring <rob.e.herring@...il.com>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Laura Abbott <labbott@...hat.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Pratik Patel <pratikp@...eaurora.org>,
        Brian Starkey <Brian.Starkey@....com>,
        "Andrew F . Davis" <afd@...com>, Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        Sandeep Patil <sspatil@...gle.com>,
        Hridya Valsaraju <hridya@...gle.com>,
        devicetree <devicetree@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC][PATCH 1/3] dt-bindings: dma-buf: heaps: Describe CMA
 regions to be added to dmabuf heaps interface.

On Fri, Oct 25, 2019 at 4:32 PM Rob Herring <rob.e.herring@...il.com> wrote:
>
> On Fri, Oct 25, 2019 at 5:51 PM John Stultz <john.stultz@...aro.org> wrote:
> >
> > This binding specifies which CMA regions should be added to the
> > dmabuf heaps interface.
>
> Is this an ION DT binding in disguise? I thought I killed that. ;)

Maybe? I may not have been paying attention back then.  :)

> > +Example:
> > +This example has a camera CMA node in reserved memory, which is then
> > +referenced by the dmabuf-heap-cma node.
> > +
> > +
> > +       reserved-memory {
> > +               #address-cells = <2>;
> > +               #size-cells = <2>;
> > +               ranges;
> > +               ...
> > +               cma_camera: cma-camera {
> > +                       compatible = "shared-dma-pool";
> > +                       reg = <0x0 0x24C00000 0x0 0x4000000>;
> > +                       reusable;
> > +               };
> > +               ...
> > +       };
> > +
> > +       cma_heap {
> > +               compatible = "dmabuf-heap-cma";
> > +               memory-region = <&cma_camera>;
>
> Why the indirection here? Can't you just add a flag property to
> reserved-memory nodes like we do to flag CMA nodes?

Happy to try. Do you mean like with the "reuasable" tag?  Or more like
the "linux,cma-default" tag?

Do you have a preference for the flag name here?

> As I suspected, it's because in patch 2 you're just abusing DT to
> instantiate platform devices. We already support binding drivers to
> reserved-memory nodes directly.

Sorry, one of those "when all you know how to do is hammer, everything
looks like a nail" issues.
Is there a specific example for binding drivers to reserved-memory
nodes I can try to follow?

Appreciate the review and feedback!

thanks
-john