Messages in this thread | | | Date | Tue, 3 May 2011 22:39:26 +0100 | From | Mark Brown <> | Subject | Re: [PATCH 01/23] intel_sst: Save audio state across D3 on Medfield |
| |
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.
| |