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
| ||
|
Date: Wed, 8 May 2013 15:10:20 +0200 From: Fabio Baltieri <fabio.baltieri@...aro.org> To: Mark Brown <broonie@...nel.org> Cc: Liam Girdwood <lgirdwood@...il.com>, alsa-devel@...a-project.org, linux-kernel@...r.kernel.org, Linus Walleij <linus.walleij@...aro.org>, Lee Jones <lee.jones@...aro.org>, Ola Lilja <ola.o.lilja@...ricsson.com> Subject: Re: [PATCH 3/6] ASoC: ux500: Drop pinctrl sleep support On Wed, May 08, 2013 at 01:32:25PM +0100, Mark Brown wrote: > On Wed, May 08, 2013 at 01:42:16PM +0200, Fabio Baltieri wrote: > > On Wed, May 08, 2013 at 11:51:24AM +0100, Mark Brown wrote: > > > > I tend to agree with Lee that this looks like a bad approach - there's a > > > whole bunch of other code in there which I'd guess is probably equally > > > broken but only the pinctrl code is being removed. Why not just fix it > > > (or better yet simplify all this stuff)? > > > Sorry I did not get the subject, are you referring to other broken code > > in the ux500 driver or to pinctrl and shared pins in generals? > > I'm saying that if functions like enable_msp() don't work reliably then > removing some but not all of their functionality isn't an obviously good > approach to fixing that. Why does the other functionality work well but > not this bit? It sounds like there's some reference counting bug here > is all... Yes, it started as a reference counting bug, due to the actual counter not being shared between ux500-msp-i2s instances. That said, the actual fork of this driver deployed by STE internally does not handle I2S pin sleep state, and I was not able to find any other ASoC driver that does that, which seems reasonable to me as I can't come up with a reason to put those pins in hi-z anyway. If I understood the problem correctly you do that when you want to cut power completely to some peripherals to avoid spurious current paths, and that should not be the case for the audio codec, especially in this case where it's part of a big multifuntion IC. So this is why I'm proposing to drop that code altogheter rather than fix it. Fabio -- Fabio Baltieri -- 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/
Powered by blists - more mailing lists