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

Mark Brown
2011-05-03T21:39:17Z

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.