linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).