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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110503213925.GA7453@opensource.wolfsonmicro.com>
Date:	Tue, 3 May 2011 22:39:26 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
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.
--
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/