All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <rob.herring@linaro.org>
To: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Grant Likely <grant.likely@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 <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 10:29:50 -0500	[thread overview]
Message-ID: <CABGGisy6_TOkT7fHp049rwH_FhQxCRGQqGBCsODUFTTchhsLvg@mail.gmail.com> (raw)
In-Reply-To: <53D7AA72.6010309@mm-sol.com>

On Tue, Jul 29, 2014 at 9:06 AM, 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.

I guess the question I have is what is the advantage of making this a
resource? You can't really pass it to other functions.

We're moving in the opposite direction for IRQs as now
platform_get_irq translates the IRQ directly rather than using the
resource (but the resource is still there just to avoid potentially
breaking things for now).

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

You would have to look for the presence or absence of ranges property.

Rob

WARNING: multiple messages have this Message-ID (diff)
From: rob.herring@linaro.org (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: use IORESOURCE_REG resource type for non-translatable addresses in DT
Date: Tue, 29 Jul 2014 10:29:50 -0500	[thread overview]
Message-ID: <CABGGisy6_TOkT7fHp049rwH_FhQxCRGQqGBCsODUFTTchhsLvg@mail.gmail.com> (raw)
In-Reply-To: <53D7AA72.6010309@mm-sol.com>

On Tue, Jul 29, 2014 at 9:06 AM, 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.

I guess the question I have is what is the advantage of making this a
resource? You can't really pass it to other functions.

We're moving in the opposite direction for IRQs as now
platform_get_irq translates the IRQ directly rather than using the
resource (but the resource is still there just to avoid potentially
breaking things for now).

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

You would have to look for the presence or absence of ranges property.

Rob

  reply	other threads:[~2014-07-29 15:29 UTC|newest]

Thread overview: 58+ 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
2014-07-29 14:06       ` Stanimir Varbanov
2014-07-29 15:29       ` Rob Herring [this message]
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
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 16:27                   ` Stanimir Varbanov
2014-08-27 18:24                 ` Bjorn Andersson
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-27 21:55                     ` Stephen Boyd
2014-08-29  4:09                     ` Bjorn Andersson
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-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=CABGGisy6_TOkT7fHp049rwH_FhQxCRGQqGBCsODUFTTchhsLvg@mail.gmail.com \
    --to=rob.herring@linaro.org \
    --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=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 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.