LKML Archive on lore.kernel.org
 help / Atom feed
From: Sibi Sankar <sibis@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	david.brown@linaro.org, robh+dt@kernel.org, mark.rutland@arm.com,
	andy.gross@linaro.org, akdwived@codeaurora.org,
	clew@codeaurora.org, linux-kernel@vger.kernel.org,
	linux-arm-msm-owner@vger.kernel.org, ohad@wizery.com,
	linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-remoteproc-owner@vger.kernel.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: <7f6eb454bb27d3c060bb415cba3f1b49@codeaurora.org> (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.

  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 \
    --in-reply-to=7f6eb454bb27d3c060bb415cba3f1b49@codeaurora.org \
    --to=sibis@codeaurora.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-owner@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ohad@wizery.com \
    --cc=robh+dt@kernel.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

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

	# 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 \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	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