From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752897AbbBYPG2 (ORCPT ); Wed, 25 Feb 2015 10:06:28 -0500 Received: from mail-we0-f177.google.com ([74.125.82.177]:46526 "EHLO mail-we0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbbBYPG0 (ORCPT ); Wed, 25 Feb 2015 10:06:26 -0500 Message-ID: <54EDE4F1.10000@cit-ec.uni-bielefeld.de> Date: Wed, 25 Feb 2015 16:06:25 +0100 From: Robert Abel Reply-To: rabel@cit-ec.uni-bielefeld.de User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Roger Quadros , linux-omap@vger.kernel.org CC: linux-kernel@vger.kernel.org, tony@atomide.com, linux@arm.linux.org.uk Subject: Re: [PATCH 3/8 v2] ARM OMAP2+ GPMC: add bus children References: <1424808331-17592-1-git-send-email-rabel@cit-ec.uni-bielefeld.de> <1424808331-17592-2-git-send-email-rabel@cit-ec.uni-bielefeld.de> <1424808331-17592-3-git-send-email-rabel@cit-ec.uni-bielefeld.de> <54EDB9F0.9030701@ti.com> In-Reply-To: <54EDB9F0.9030701@ti.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roger, On 25 Feb 2015 13:02, Roger Quadros wrote: > This creates platform devices for the children of child, but what > about platform device for the child itself? It seems my first try in the other patch set wasn't so wrong after all. Maybe unconditionally call of_platform_device_create(child,...) and of_platform_populate(child, ...)? > Shouldn't the bus driver for that bus be responsible for spawning children of its bus? Well, a bus driver doesn't actually do much work here. The standard buses are just there for offset and so on. And that's my use case. Have one CS region with fixed settings and multiple devices in it. Creating code that in effect replicates what simple-bus does isn't worthwhile. Basically, it would replicate half the code that of_platform_populate goes through anyway without good reason. If complex bus-behavior is needed -- more than single-bus offset shifts --, a complex bus driver can always be written. Since it wouldn't match of_default_match_table, it itself would be responsible for creating children. I think I'll go with my first patch for this one, maybe call of_platform_decide_create unconditionally to check whether buses are available. Regards, Robert