Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754785Ab1CKLxw (ORCPT ); Fri, 11 Mar 2011 06:53:52 -0500 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:39276 "EHLO opensource2.wolfsonmicro.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752016Ab1CKLxu (ORCPT ); Fri, 11 Mar 2011 06:53:50 -0500 Date: Fri, 11 Mar 2011 11:53:44 +0000 From: Mark Brown To: "Cai, Cliff" Cc: Cliff Cai , Mike Frysinger , "alsa-devel@alsa-project.org" , "linux-kernel@vger.kernel.org" , "device-drivers-devel@blackfin.uclinux.org" , "akpm@linux-foundation.org" , "lrg@slimlogic.co.uk" Subject: Re: [alsa-devel] [Device-drivers-devel] [PATCH] Add driver for Analog Devices ADAU1701 SigmaDSP Message-ID: <20110311115344.GA1760@opensource.wolfsonmicro.com> References: <1299460302-15392-1-git-send-email-cliff.cai@analog.com> <20110307114142.GB13471@opensource.wolfsonmicro.com> <20110307121502.GG13471@opensource.wolfsonmicro.com> <20110309100055.GB6923@opensource.wolfsonmicro.com> <20110310134605.GC22195@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Cookie: You will contract a rare disease. 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 Content-Length: 1386 Lines: 25 On Fri, Mar 11, 2011 at 02:54:42AM -0500, Cai, Cliff wrote: > 1.The default firmware is used when the chip is just powered-up, > Once driver gets the control,it should load the custom firmware to replace > The default one, > 2.we don't need to worry about this case,the driver which needs loading firmware > Has to be compiled as a module,and of cause,we load it after the filesystem has been mounted. Forcing the driver to be build modular isn't great for usability either, though - it's not very general and some systems don't use modules at all for various reasons (eg, simplicity or difficulties in keeping the fs and the kernel partitions in sync). I'm not sure this gels well with the approach you're taking with the driver just passing the firmware through. On the one hand you don't want the driver to know anything about the firmware or join up the firmware handling with the audio subsystem but on the other hand the driver is requiring that a firmware be loaded as soon as the driver is even though it can provide some very basic functionality without it. It'd seem better to just let the user load firmware at their leisure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/