Thread (22 messages) flat view 22 messages, 6 authors, 2011-09-10

[PATCH v2] ASoC: omap: convert per-board modules to platform drivers

From: Russell King - ARM Linux <hidden>
Date: 2011-09-09 19:02:10
Also in: alsa-devel, linux-omap, lkml

On Fri, Sep 09, 2011 at 09:11:52AM -0700, Mark Brown wrote:
On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote:
quoted
On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
quoted
quoted
The problem is that someone has to manually go and add the device to
every board that needs one and people find that tedious and slightly
inelegant
quoted
Sheesh.  So now you're arguing against your statement above?  Please
stop wasting my time.
There's two things going on here - what we are doing and what people
would like to be able to do.  What we are doing is explicitly adding
devices, what people would like to do is infer the devices from the
board type.  Personally I'm totally happy with explicitly adding an
audio device, but not everyone is and I do understand where they're
coming from.
Well, with DT, there won't be any 'board type' anymore.  There won't be
any 'machine_is_xxx()' to sort it out anymore.  Using DT, all that will
be history - it's all got to be sorted out by either devices or device
properties.

So, given that, I don't see the logic of having two methods - it might
as well be dealt with by devices and [platform data for non-DT | DT
properties], and which then means we have everything working the same
way irrespective of what the backing data for the platform actually is.

Therefore, as we are heading for DT, I'd definitely say that having
machine_is_xxx() outside of arch/arm is a bug, no less and no more.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help