From: Rob Herring <robh+dt@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Sibi Sankar <sibis@codeaurora.org>,
David Brown <david.brown@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Andy Gross <andy.gross@linaro.org>,
Avaneesh Kumar Dwivedi <akdwived@codeaurora.org>,
Chris Lew <clew@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-arm-msm-owner@vger.kernel.org,
Ohad Ben-Cohen <ohad@wizery.com>,
"open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM"
<linux-remoteproc@vger.kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5
Date: Tue, 8 Jan 2019 09:22:30 -0600 [thread overview]
Message-ID: <CAL_JsqLbMNB6EzYCzmq5PBc9EvVmYifsoJBwymV621h385Hv0w@mail.gmail.com> (raw)
In-Reply-To: <20190105015430.GA67838@google.com>
On Fri, Jan 4, 2019 at 7:54 PM Brian Norris <briannorris@chromium.org> wrote:
>
> Hi again,
>
> On Thu, Jan 03, 2019 at 04:11:58PM -0800, Brian Norris wrote:
> > On Thu, Jan 03, 2019 at 04:01:45PM -0800, Bjorn Andersson wrote:
> > > I share your concern about this, but I came to suggest this as the
> > > driver cares about platforms but the firmware is (often?)
> > > device/product-specific.
> > >
> > > E.g. we will serve the MTP and Pixel 3 with the qcom,sdm845-adsp-pas
> > > compatible, but they are unlikely to run the same adsp firmware. This
> > > allows the individual dtb to specify which firmware the driver should
> > > use.
> >
> > I understand this, but that still doesn't mean we should be suggesting
> > each DTB to clutter the top-level firmware search path, especially since
> > lazy people will probably just use "modem.mdt" and similar. That means
> > you no longer can ship the same rootfs that supports both QCOM and
> > <other> modems, if <other> modem also uses the same lazy format.
> >
> > It seems like a much better practice to at least enforce a particular
> > prefix to things. e.g., the driver could assume:
> >
> > qcom/sdm845-adsp-pas/ (or if you must, just qcom/)
> >
> > and your DTB only gets to add .../<your-string-here> to that path.
> >
> > In case it isn't clear: I think it's also severely misguided that the
> > existing driver gets away with lines like
> >
> > request_firmware(&fw, "modem.mdt", ...);
> >
> > today ;)
>
> 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.*"
And you can have a device specific schema to enforce a subdir and/or
filename(s).
I tend to think we should not put part of the path in drivers. No real
good reason other than we already allow that for other users of
'firmware-name'.
> As a bonus: it would be very nice if we can provide a little more
> structure by default, and avoid arbitrary hierarchy in the DTS. That's
> where I brought up ath10k's "variant" as an example; if we can use
> 'compatible' to capture most of this particular Hexagon core's
> properties, then we only leave a single level of variability to the DTS.
Some bindings use compatible to determine/construct the firmware name.
If you want to restrict things, then that's probably how you should do
it IMO.
Rob
next prev parent reply other threads:[~2019-01-08 15:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-28 4:48 [PATCH v2 0/2] Add firmware bindings for Q6V5 MSS/PAS Sibi Sankar
2018-12-28 4:48 ` [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5 Sibi Sankar
2018-12-28 22:17 ` Rob Herring
2019-01-03 23:30 ` Brian Norris
2019-01-03 23:50 ` Brian Norris
2019-01-04 0:01 ` Bjorn Andersson
2019-01-04 0:11 ` Brian Norris
2019-01-05 1:54 ` Brian Norris
2019-01-08 10:50 ` Sibi Sankar
2019-01-08 15:22 ` Rob Herring [this message]
2019-01-09 21:55 ` Brian Norris
2019-01-10 14:56 ` Rob Herring
2018-12-28 4:48 ` [PATCH v2 2/2] remoteproc: qcom: Add support for parsing fw dt bindings Sibi Sankar
2019-01-03 23:09 ` Bjorn Andersson
2019-01-03 23:44 ` Brian Norris
2019-01-08 10:32 ` Sibi Sankar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAL_JsqLbMNB6EzYCzmq5PBc9EvVmYifsoJBwymV621h385Hv0w@mail.gmail.com \
--to=robh+dt@kernel.org \
--cc=akdwived@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=briannorris@chromium.org \
--cc=clew@codeaurora.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ohad@wizery.com \
--cc=sibis@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).