Re: [PATCH 01/23] intel_sst: Save audio state across D3 on Medfield

[Mark Brown]

On Tue, May 03, 2011 at 10:29:03PM +0100, Alan Cox wrote:

> I see the problem - Mark Brown took a patch in staging via the ASoC tree
> which clashes with this.

> fa880004682cf0d10e7a7c71dc8d56bbd67ac3d5

> which is not only a staging patch but also breaks compilation of the code
> because the sst_drv_ctx symbol isn't even exported or visible to the
> intelmid module, which suggests it wasn't even compile tested.

I am assured that this patch is essential to build with the Intel
drivers that are currently upstream in ASoC, though I've not personally
verified that.  I'd not be surprised if the tests whoever submitted it
did had only been done with the module built in, though I'd have
expected whatever tests people do on -next to pick that up since x86
seems to be a popular target there.

> In general we have a bigger problem here, the ASoC driver appears to be
> violating rule #1 of staging - nothing outside of staging should be using
> or depending upon staging code in the first place.

To recap the previous discussion: staging is just not in the slightest
bit viable for ASoC stuff, code that does anything non-trivial is going
to get broken between releases.  Especially with something like this
where the drivers are for unreleased hardware that has no current end
users it's just not a problem for the core if drivers do stuff like this
so long as they don't do anything visibly bad or cause problems for the
people who do build test whatever architecture is affected.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/