mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@linaro.org>
To: Stanimir Varbanov <svarbanov@mm-sol.com>, Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <rob.herring@linaro.org>,
	Rob Herring <robherring2@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Stephen Boyd <sboyd@codeaurora.org>,
	Mark Brown <broonie@linaro.org>
Subject: Re: use IORESOURCE_REG resource type for non-translatable addresses in DT
Date: Tue, 29 Jul 2014 17:45:22 -0600	[thread overview]
Message-ID: <20140729234522.E9FF1C40738@trevor.secretlab.ca> (raw)
In-Reply-To: <53D7AA72.6010309@mm-sol.com>

On Tue, 29 Jul 2014 17:06:42 +0300, Stanimir Varbanov <svarbanov@mm-sol.com> wrote:
> Arnd, thanks for the comments.
> 
> On 07/29/2014 03:00 PM, Arnd Bergmann wrote:
> > On Tuesday 29 July 2014 14:42:31 Stanimir Varbanov wrote:
> >>         taddr = of_translate_address(dev, addrp);
> >> -       if (taddr == OF_BAD_ADDR)
> >> -               return -EINVAL;
> >> +       /*
> >> +        * if the address is non-translatable to cpu physical address
> >> +        * fallback to a IORESOURCE_REG resource.
> >> +        */
> >> +       if (taddr == OF_BAD_ADDR) {
> >> +               memset(r, 0, sizeof(*r));
> >> +               taddr = of_read_number(addrp, 1);
> >> +               if (taddr == OF_BAD_ADDR)
> >> +                       return -EINVAL;
> >> +               r->start = taddr;
> >> +               r->end = taddr + size - 1;
> >> +               r->flags = IORESOURCE_REG;
> >> +               r->name = name ? name : dev->full_name;
> >> +               return 0;
> >> +       }
> >> +
> > 
> > I don't think that everything returning OF_BAD_ADDR makes sense
> > to turn into IORESOURCE_REG. It could be an e.g. invalid DT
> > representation, a node with #size-cells=<0>, or it could be
> > something that gets translated one or more nodes up in the
> > tree before it reaches a bus without a ranges property.
> > 
> > Also, you should not rely on #address-cells being hardcoded
> > to <1> above.
> > 
> 
> This was just an example. Of course it has many issues and probaly it is
> wrong:) The main goal was to understand does IORESOURCE_REG resource
> type and parsing the *reg* properties for non-translatable addresses are
> feasible. And also does it acceptable by community and OF platform
> maintainers.

The use case is actually very different from of_address_to_resource or
of_get_address() because those APIs explicitly return physical memory
addresses from the CPU perspective. It makes more sense to create a new
API that doesn't attempt to translate the reg address. Alternately, a
new API that only translates upto a given parent node.

You don't want to automagically translate as far up the tree as
possible because the code won't know what node the address is associated
with. Translated addresses only make sense if the node it was translated
to as also known.

g.

> 
> > How about modifying of_get_address() rather than
> > __of_address_to_resource() instead? You could introduce
> > a new of_bus entry for each bus you expect to return
> > an IORESOURCE_REG, or you could change of_bus_default_get_flags
> > to return IORESOURCE_REG if the parent node has no ranges property
> > and is not the root node.
> 
> IMO the clearer solution is to introduce a new of_bus bus. In that case
> one possible problem will be how to distinguish the non-translatable and
> the other buses. Also the *device_type* property is deprecated for non
> PCI devices.
> 
> The second option will need to change the prototype of .get_flags method
> to receive device_node structure.
> 
> Thoughts?
> 
> -- 
> regards,
> Stan


  parent reply	other threads:[~2014-07-29 23:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29 11:42 Stanimir Varbanov
2014-07-29 12:00 ` Arnd Bergmann
2014-07-29 14:06   ` Stanimir Varbanov
2014-07-29 15:29     ` Rob Herring
2014-07-29 23:45     ` Grant Likely [this message]
2014-07-30  1:07       ` Stephen Boyd
2014-07-30  2:53         ` Rob Herring
2014-07-30  6:06           ` Stephen Boyd
2014-08-27 16:27             ` Stanimir Varbanov
2014-08-27 18:24             ` Bjorn Andersson
2014-08-27 21:55               ` Stephen Boyd
2014-08-29  4:09                 ` Bjorn Andersson
2014-08-28  7:58               ` Stanimir Varbanov
2014-09-02 15:45       ` [PATCH] RFC: add function for localbus address Stanimir Varbanov
2014-09-05 23:29         ` Stephen Boyd
2014-09-08 14:52         ` Grant Likely
2014-09-08 20:22           ` Stephen Boyd
2014-09-08 21:21             ` Mark Brown
2014-09-14  4:46             ` Grant Likely
2014-10-22 23:01               ` Stephen Boyd
2014-10-22 23:20                 ` Russell King - ARM Linux
2014-10-22 23:53                   ` Stephen Boyd
2014-10-22 23:51                 ` Mark Brown
2014-09-09 15:07           ` Stanimir Varbanov

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=20140729234522.E9FF1C40738@trevor.secretlab.ca \
    --to=grant.likely@linaro.org \
    --cc=arnd@arndb.de \
    --cc=broonie@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob.herring@linaro.org \
    --cc=robherring2@gmail.com \
    --cc=sboyd@codeaurora.org \
    --cc=svarbanov@mm-sol.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
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

all inboxes | Powered by JetHome®