linux-kernel - Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5

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]

Message-ID: <CAL_JsqKF5i8HNT-ez+Q=Dv9OA-Lf1VaqpZbL2ouo0Bm+v5FxJg@mail.gmail.com>
Date:   Thu, 10 Jan 2019 08:56:12 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Sibi Sankar <sibis@...eaurora.org>,
        David Brown <david.brown@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Andy Gross <andy.gross@...aro.org>,
        Avaneesh Kumar Dwivedi <akdwived@...eaurora.org>,
        Chris Lew <clew@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm-msm-owner@...r.kernel.org,
        Ohad Ben-Cohen <ohad@...ery.com>,
        "open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM" 
        <linux-remoteproc@...r.kernel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware
 bindings for Q6V5

On Wed, Jan 9, 2019 at 3:55 PM Brian Norris <briannorris@...omium.org> wrote:
>
> On Tue, Jan 08, 2019 at 09:22:30AM -0600, Rob Herring wrote:
> > On Fri, Jan 4, 2019 at 7:54 PM Brian Norris <briannorris@...omium.org> wrote:
> > > To add to my thoughts, since I think maybe Sibi was a little unclear of
> > > my thoughts:
> > >
> > > One of my primary concerns with the existing approach is that it's
> > > basically a complete free-for-all. We should have some minimal standards
> > > (enforced in code) such that our DTB can never point us at something
> > > like /lib/firmware/<other-vendor>/foo.bin (or /lib/firmware/modem.mdt;
> > > or lots of other bad examples). This could probably be done simply by
> > > always prefixing 'qcom/' (I don't remember -- does request_firmware()
> > > follow '..'? e.g., 'firmware-name = "../bar/foo.bin"'.)
> >
> > We can write a schema to enforce some of this:
> >
> > firmware-name:
> >   pattern: "^\w.*"
>
> Are DT schemas ready to use/enforce? Or would this currently just be a
> suggestion? I'm out of the loop. But I guess that would be interesting.

Yes, please! Initial support is in 5.0-rc.

I'm not requiring new bindings to be written as schemas just yet
though. We need to ring out any issues with early adopters.

Rob