From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 7 Jun 2013 21:10:35 +0200 Subject: [PATCH 03/14] bus: mvebu-mbus: Introduce device tree binding In-Reply-To: <1370623671-7748-4-git-send-email-ezequiel.garcia@free-electrons.com> References: <1370623671-7748-1-git-send-email-ezequiel.garcia@free-electrons.com> <1370623671-7748-4-git-send-email-ezequiel.garcia@free-electrons.com> Message-ID: <201306072110.35856.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Friday 07 June 2013, Ezequiel Garcia wrote: > + np = of_find_matching_node(NULL, of_mvebu_mbus_ids); > + if (!np) { > + pr_err("could not find a matching SoC family\n"); > + return -ENODEV; > + } > + > + of_id = of_match_node(of_mvebu_mbus_ids, np); > + mbus_state.soc = of_id->data; > + > + if (of_address_to_resource(np, 0, &mbuswins_res)) { > + pr_err("cannot get MBUS register address\n"); > + return -EINVAL; > + } > + > + if (of_address_to_resource(np, 1, &sdramwins_res)) { > + pr_err("cannot get SDRAM register address\n"); > + return -EINVAL; > + } Just an idea to make this more regular: Since the internal-regs can no longer be regarded as a fixed location, we might want to use the same "ranges" property mechanism for resolving the internal regs as we use for everything else. This would imply that the device node this driver binds to would actually end up being a child of the bus itself, which then goes on to modify the ranges property of its parent node. Does that make sense? Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 03/14] bus: mvebu-mbus: Introduce device tree binding Date: Fri, 7 Jun 2013 21:10:35 +0200 Message-ID: <201306072110.35856.arnd@arndb.de> References: <1370623671-7748-1-git-send-email-ezequiel.garcia@free-electrons.com> <1370623671-7748-4-git-send-email-ezequiel.garcia@free-electrons.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1370623671-7748-4-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Ezequiel Garcia Cc: Lior Amsalem , Jason Cooper , Andrew Lunn , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Jason Gunthorpe , Maen Suleiman , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Sebastian Hesselbarth List-Id: devicetree@vger.kernel.org On Friday 07 June 2013, Ezequiel Garcia wrote: > + np = of_find_matching_node(NULL, of_mvebu_mbus_ids); > + if (!np) { > + pr_err("could not find a matching SoC family\n"); > + return -ENODEV; > + } > + > + of_id = of_match_node(of_mvebu_mbus_ids, np); > + mbus_state.soc = of_id->data; > + > + if (of_address_to_resource(np, 0, &mbuswins_res)) { > + pr_err("cannot get MBUS register address\n"); > + return -EINVAL; > + } > + > + if (of_address_to_resource(np, 1, &sdramwins_res)) { > + pr_err("cannot get SDRAM register address\n"); > + return -EINVAL; > + } Just an idea to make this more regular: Since the internal-regs can no longer be regarded as a fixed location, we might want to use the same "ranges" property mechanism for resolving the internal regs as we use for everything else. This would imply that the device node this driver binds to would actually end up being a child of the bus itself, which then goes on to modify the ranges property of its parent node. Does that make sense? Arnd