From: Sibi Sankar <firstname.lastname@example.org> To: Brian Norris <email@example.com> Cc: Bjorn Andersson <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5 Date: Tue, 08 Jan 2019 16:20:41 +0530 Message-ID: <email@example.com> (raw) In-Reply-To: <20190105015430.GA67838@google.com> Hi Brian/Bjorn, Thanks for the review! On 2019-01-05 07:24, Brian Norris 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"'.) > > 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. > > But I might be off-base with the "bonus" paragraph. So I'd also be > somewhat happy with something much less ambitious, like just a built-in > prefix ('qcom/'). > > And you can also just ignore my thoughts entirely (and I'll be even > less > happy), since Rob did already provide his Reviewed-by ;) I mostly > wanted > to give food for thought, in the hopes that something in here would > help > improve this a bit. Bjorn, let me know how you want it implemented. I am okay with either of the following: * (variant tag based solution) or * (simply going ahead with what we have now). > > Regards, > Brian -- -- Sibi Sankar -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply index 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 [this message] 2019-01-08 15:22 ` Rob Herring 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 publically 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org email@example.com public-inbox-index lkml Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/ public-inbox