linux-kernel - Re: [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too

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]

Date:	Thu, 2 Aug 2012 10:59:00 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Ola Lilja <olalilja@...oo.se>
Cc:	'Lee Jones' <lee.jones@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	STEricsson_nomadik_linux@...t.st.com, linus.walleij@...ricsson.com,
	arnd@...db.de, ola.o.lilja@...ricsson.com,
	alsa-devel@...a-project.org, lrg@...com
Subject: Re: [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all
 subsequent widgets to fail too

On Thu, Aug 02, 2012 at 07:58:24AM +0200, Ola Lilja wrote:

> Accusing me of having "no interest in fixing the driver" is just absurd
> regarding the time I've spent on this. I'm also still driving for

Sorry, this is more directed at the current round of fixes that are
being sent than the driver itself - the patches to bodge around the
issue are being pushed fairly aggressively as an urgent fix without
even mentioning what the issue is.  I don't have any concerns with
the driver, only with the way it's being fixed.

> Regarding the problem with the failing DAPM-widget I can probably guess
> What is going wrong when Lee is trying it out. There will be two failing
> clock-supply widgets due to the fact that on the mainline-code these
> clocks simply is not there yet. I have, of course, tested this driver
> before submitting it, and I wouldn't dream on submitting a driver where
> there were failing widgets/routes. Internally, I have put a patch with our
> clock-tree for Ux500 on, but this is not mainline-quality code and that is

This sort of reliance on out of tree patches which any real user of the
device would be expected to have sounds like exactly the sort of thing
I'd expect to have caused an issue like this, and obviously the fix here
is to get the clocks in place (even if just as stubs, though I'd expect
there to be a major impact on the functionality of the device if it's
not clocked...) rather than to just bodge out the error checking.

It does also suggest that the DT binding for this device will need to
include the setup of these clocks (I believe the clock bindings for DT
have just gone into mainline this merge window but I'd need to check).
--
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/