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
next prev parent 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: linkBe 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.