All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.