From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753870Ab1CUQix (ORCPT ); Mon, 21 Mar 2011 12:38:53 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:51470 "EHLO opensource2.wolfsonmicro.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753512Ab1CUQiw (ORCPT ); Mon, 21 Mar 2011 12:38:52 -0400 Date: Mon, 21 Mar 2011 16:38:49 +0000 From: Mark Brown To: Ingo Molnar Cc: Takashi Iwai , Linus Torvalds , Jaroslav Kysela , Liam Girdwood , Andrew Morton , linux-kernel@vger.kernel.org, Randy Dunlap , Zeng Zhaoming Subject: Re: [build failure] Re: [GIT PULL] sound updates for 2.6.39-rc1 Message-ID: <20110321163849.GF2570@opensource.wolfsonmicro.com> References: <20110321153719.GA12325@elte.hu> <20110321155836.GE2570@opensource.wolfsonmicro.com> <20110321161102.GB23614@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110321161102.GB23614@elte.hu> X-Cookie: You're at the end of the road again. User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 21, 2011 at 05:11:02PM +0100, Ingo Molnar wrote: > * Mark Brown wrote: > > As indicated that's not a good fix since the affected code is all runtime > > conditional already. [...] > Well, AFAICS Randy's patch correctly expresses current infrastructure > dependencies the driver has. That's because the driver code is trivially broken, though - the build test has identified a flaw in the driver which we should fix. > SND_SOC_ALL_CODECS=y but !REGULATOR case, i.e. if it's desirable to have the > driver build more widely, then that can be enhanced further - but first please > If it's undesirable to disable the driver in the (unlikely but possible) > get things to build. Right, and as I indicated in my reply Zeng said he'd fix this. I'd rather encourage vendors to take responsibility for their own drivers. > > [...] It'd be more likely to impede than help the sort of build coverage > > tests where one would encounter it. > It's an invariant mostly - both Randy's and my testing will find breakages > regardless of how restrictively enabled this driver is. My point is that this is the build test equivalent of using memset to fix uninitialised variables, it's making the test pass rather than making things work. When fixing this sort of thing you need to at least consider if the appropriate fix is to knock out the whole thing in Kconfig or to make sure the code copes with the dependency set either way.