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]

Message-ID: <20110311115344.GA1760@opensource.wolfsonmicro.com>
Date:	Fri, 11 Mar 2011 11:53:44 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	"Cai, Cliff" <Cliff.Cai@...log.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

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/