[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54EDE4F1.10000@cit-ec.uni-bielefeld.de>
Date: Wed, 25 Feb 2015 16:06:25 +0100
From: Robert Abel <rabel@...-ec.uni-bielefeld.de>
To: Roger Quadros <rogerq@...com>, linux-omap@...r.kernel.org
CC: linux-kernel@...r.kernel.org, tony@...mide.com,
linux@....linux.org.uk
Subject: Re: [PATCH 3/8 v2] ARM OMAP2+ GPMC: add bus children
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists