linux-kernel - Re: [Patch 4/6] dt-bindings: media: ti-vpe: Document VPE driver

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] [day] [month] [year] [list]

Date:   Thu, 19 Oct 2017 14:20:32 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Benoit Parrot <bparrot@...com>, Tero Kristo <t-kristo@...com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: Re: [Patch 4/6] dt-bindings: media: ti-vpe: Document VPE driver

* Rob Herring <robh@...nel.org> [171019 14:07]:
> On Wed, Oct 18, 2017 at 8:02 AM, Benoit Parrot <bparrot@...com> wrote:
> >> > +Example:
> >> > +   vpe {
> >> > +           compatible = "ti,vpe";
> >> > +           ti,hwmods = "vpe";
> >> > +           clocks = <&dpll_core_h23x2_ck>;
> >> > +           clock-names = "fck";
> >> > +           reg =   <0x489d0000 0x120>,
> >> > +                   <0x489d0300 0x20>,
> >> > +                   <0x489d0400 0x20>,
> >> > +                   <0x489d0500 0x20>,
> >> > +                   <0x489d0600 0x3c>,
> >> > +                   <0x489d0700 0x80>,
> >>
> >> Is there other stuff between these regions?
> >
> > No, they listed separately because each sub-region/module is
> > individually mapped and accessed using a starting 0 offset.
> 
> So you are going to use 48KB of virtual memory to map 2KB of
> registers? Because each ioremap uses 8KB (1 page plus 1 guard page)
> last time i looked (which has been a while).
> 
> But it's your platform.

We should have cached regions for all interconnects so this should
not be a problem. Worth checking that the areas are listed in
dra7xx_io_desc[] and for other SoCs too to avoid this issue.

Regards,

Tony