linux-kernel - RE: [alsa-devel] [Device-drivers-devel] [PATCH] Add driver for Analog Devices ADAU1701 SigmaDSP

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:	Sun, 13 Mar 2011 22:23:19 -0400
From:	"Cai, Cliff" <Cliff.Cai@...log.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Cliff Cai <cliffcai.sh@...il.com>,
	Mike Frysinger <vapier.adi@...il.com>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"device-drivers-devel@...ckfin.uclinux.org" 
	<device-drivers-devel@...ckfin.uclinux.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"lrg@...mlogic.co.uk" <lrg@...mlogic.co.uk>
Subject: RE: [alsa-devel] [Device-drivers-devel] [PATCH] Add driver for
 Analog Devices ADAU1701 SigmaDSP



>-----Original Message-----
>From: Mark Brown [mailto:broonie@...nsource.wolfsonmicro.com]
>Sent: 2011年3月11日 19:54
>To: Cai, Cliff
>Cc: Cliff Cai; Mike Frysinger; alsa-devel@...a-project.org;
>linux-kernel@...r.kernel.org;
>device-drivers-devel@...ckfin.uclinux.org;
>akpm@...ux-foundation.org; lrg@...mlogic.co.uk
>Subject: Re: [alsa-devel] [Device-drivers-devel] [PATCH] Add
>driver for Analog Devices ADAU1701 SigmaDSP
>
>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.
>

Hi Mark,

I think I need to have a check of the requirement from customer.
Anyway,if I modified the driver according to the comments here,
Would you like to accept it currently or we need to wait until the missing patch
Has been merged in mainline?