From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, Andy Gross <andy.gross@linaro.com>
Subject: Re: [PATCH 3/5] remoteproc: qcom: mdt_loader: Refactor MDT loader
Date: Wed, 15 Feb 2017 22:01:18 -0800 [thread overview]
Message-ID: <20170216060118.GC23255@minitux> (raw)
In-Reply-To: <156a64cf-0efa-2313-f8bd-f948a108df19@linaro.org>
On Wed 08 Feb 02:33 PST 2017, Stanimir Varbanov wrote:
> Hi Bjorn,
>
> On 01/30/2017 06:55 PM, Bjorn Andersson wrote:
[..]
> > +int qcom_mdt_load(struct device *dev, const struct firmware *fw,
[..]
> > + size_t offset;
[..]
> > + for (i = 0; i < ehdr->e_phnum; i++) {
> > + phdr = &phdrs[i];
> > +
> > + if (!mdt_phdr_valid(phdr))
> > continue;
> >
> > - ptr = rproc_da_to_va(rproc, phdr->p_paddr, phdr->p_memsz);
> > - if (!ptr) {
> > - dev_err(&rproc->dev, "segment outside memory range\n");
> > + offset = phdr->p_paddr - mem_reloc;
>
> Shouldn't 'offset' variable be of signed type i.e. ssize_t?
It should, as a small "negative" value will wrap back into the
acceptable range of the second part of the check below. I got another
report of this as well yesterday, so I will prepare a patch for this.
> Also p_paddr is of type Elf32_Addr and mem_reloc is of type
> phys_addr_t which on 64bit systems is 64bit long, I think it should be
> better to make mem_reloc of the same type as p_paddr.
>
If I remember what the C standard says, mem_reloc would in the 64-bit
case have higher "rank" and the type of p_paddr would therefor be
converted to the type of mem_reloc (i.e. u64) and the result would be
stored in a 64 bit type. But it's been a while and I can't find my C
reference manual right now...
Casting mem_reloc to the type of p_paddr would cause invalid results in
the event that the system is configured to actually load a relocatable
blob into memory above 4GB.
> > + if (offset < 0 || offset + phdr->p_memsz > mem_size) {
> > + dev_err(dev, "segment outside memory range\n");
> > ret = -EINVAL;
> > break;
> > }
> >
> > + ptr = mem_region + offset;
> > +
> > if (phdr->p_filesz) {
> > sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> > - ret = request_firmware(&seg_fw, fw_name, &rproc->dev);
> > + ret = request_firmware(&seg_fw, fw_name, dev);
> > if (ret) {
> > - dev_err(&rproc->dev, "failed to load %s\n",
> > - fw_name);
> > + dev_err(dev, "failed to load %s\n", fw_name);
> > break;
> > }
> >
>
Regards,
Bjorn
next prev parent reply other threads:[~2017-02-16 6:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-30 16:55 [PATCH 1/5] remoteproc: qcom: q6v5: Decouple driver from MDT loader Bjorn Andersson
2017-01-30 16:55 ` [PATCH 2/5] remoteproc: qcom: mdt_loader: Don't overwrite firmware object Bjorn Andersson
2017-01-30 16:55 ` [PATCH 3/5] remoteproc: qcom: mdt_loader: Refactor MDT loader Bjorn Andersson
2017-02-02 15:21 ` Stanimir Varbanov
2017-02-08 10:33 ` Stanimir Varbanov
2017-02-16 6:01 ` Bjorn Andersson [this message]
2017-01-30 16:55 ` [PATCH 4/5] remoteproc: qcom-common: Extract non-mdt related helper Bjorn Andersson
2017-01-30 16:55 ` [PATCH 5/5] soc/qcom: Move qcom_mdt_loader from remoteproc Bjorn Andersson
2017-02-01 23:24 ` Andy Gross
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=20170216060118.GC23255@minitux \
--to=bjorn.andersson@linaro.org \
--cc=andy.gross@linaro.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=stanimir.varbanov@linaro.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).