From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754628AbaG2Xp3 (ORCPT ); Tue, 29 Jul 2014 19:45:29 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:36627 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754189AbaG2XpZ (ORCPT ); Tue, 29 Jul 2014 19:45:25 -0400 From: Grant Likely Subject: Re: use IORESOURCE_REG resource type for non-translatable addresses in DT To: Stanimir Varbanov , Arnd Bergmann Cc: Rob Herring , Rob Herring , Lee Jones , "linux-arm-msm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , linux-arm-kernel@lists.infradead.org, Stephen Boyd , Mark Brown In-Reply-To: <53D7AA72.6010309@mm-sol.com> References: <53D788A7.4020303@mm-sol.com> <3794875.CZFbAag5Sv@wuerfel> <53D7AA72.6010309@mm-sol.com> Date: Tue, 29 Jul 2014 17:45:22 -0600 Message-Id: <20140729234522.E9FF1C40738@trevor.secretlab.ca> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Jul 2014 17:06:42 +0300, Stanimir Varbanov 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