From: Stanimir Varbanov <svarbanov@mm-sol.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>,
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:06:42 +0300 [thread overview]
Message-ID: <53D7AA72.6010309@mm-sol.com> (raw)
In-Reply-To: <3794875.CZFbAag5Sv@wuerfel>
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.
> 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
WARNING: multiple messages have this Message-ID (diff)
From: svarbanov@mm-sol.com (Stanimir Varbanov)
To: linux-arm-kernel@lists.infradead.org
Subject: use IORESOURCE_REG resource type for non-translatable addresses in DT
Date: Tue, 29 Jul 2014 17:06:42 +0300 [thread overview]
Message-ID: <53D7AA72.6010309@mm-sol.com> (raw)
In-Reply-To: <3794875.CZFbAag5Sv@wuerfel>
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.
> 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
next prev parent reply other threads:[~2014-07-29 14:06 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 11:42 use IORESOURCE_REG resource type for non-translatable addresses in DT Stanimir Varbanov
2014-07-29 11:42 ` Stanimir Varbanov
[not found] ` <53D788A7.4020303-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-07-29 12:00 ` Arnd Bergmann
2014-07-29 12:00 ` Arnd Bergmann
2014-07-29 12:00 ` Arnd Bergmann
2014-07-29 14:06 ` Stanimir Varbanov [this message]
2014-07-29 14:06 ` Stanimir Varbanov
2014-07-29 15:29 ` Rob Herring
2014-07-29 15:29 ` Rob Herring
2014-07-29 23:45 ` Grant Likely
2014-07-29 23:45 ` Grant Likely
2014-07-30 1:07 ` Stephen Boyd
2014-07-30 1:07 ` Stephen Boyd
2014-07-30 2:53 ` Rob Herring
2014-07-30 2:53 ` Rob Herring
[not found] ` <CAL_JsqJjH0OH+X=fzwqAPeWarjoLev7v6Nv_QhAa+nZyztMnFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-30 6:06 ` Stephen Boyd
2014-07-30 6:06 ` Stephen Boyd
2014-07-30 6:06 ` Stephen Boyd
2014-08-27 16:27 ` Stanimir Varbanov
2014-08-27 16:27 ` Stanimir Varbanov
2014-08-27 18:24 ` Bjorn Andersson
2014-08-27 18:24 ` Bjorn Andersson
2014-08-27 21:55 ` Stephen Boyd
2014-08-27 21:55 ` Stephen Boyd
2014-08-29 4:09 ` Bjorn Andersson
2014-08-29 4:09 ` Bjorn Andersson
2014-08-28 7:58 ` Stanimir Varbanov
2014-08-28 7:58 ` Stanimir Varbanov
2014-09-02 15:45 ` [PATCH] RFC: add function for localbus address Stanimir Varbanov
2014-09-02 15:45 ` Stanimir Varbanov
2014-09-05 23:29 ` Stephen Boyd
2014-09-05 23:29 ` Stephen Boyd
2014-09-08 14:52 ` Grant Likely
2014-09-08 14:52 ` Grant Likely
2014-09-08 14:52 ` Grant Likely
2014-09-08 20:22 ` Stephen Boyd
2014-09-08 20:22 ` Stephen Boyd
2014-09-08 21:21 ` Mark Brown
2014-09-08 21:21 ` Mark Brown
2014-09-08 21:21 ` Mark Brown
2014-09-14 4:46 ` Grant Likely
2014-09-14 4:46 ` Grant Likely
2014-10-22 23:01 ` Stephen Boyd
2014-10-22 23:01 ` Stephen Boyd
2014-10-22 23:20 ` Russell King - ARM Linux
2014-10-22 23:20 ` Russell King - ARM Linux
2014-10-22 23:53 ` Stephen Boyd
2014-10-22 23:53 ` Stephen Boyd
2014-10-22 23:51 ` Mark Brown
2014-10-22 23:51 ` Mark Brown
2014-09-09 15:07 ` Stanimir Varbanov
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=53D7AA72.6010309@mm-sol.com \
--to=svarbanov@mm-sol.com \
--cc=arnd@arndb.de \
--cc=broonie@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.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 \
/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.