From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752218Ab1F3Mcq (ORCPT ); Thu, 30 Jun 2011 08:32:46 -0400 Received: from h5.dl5rb.org.uk ([81.2.74.5]:53821 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751730Ab1F3Mcm (ORCPT ); Thu, 30 Jun 2011 08:32:42 -0400 Date: Thu, 30 Jun 2011 13:32:12 +0100 From: Ralf Baechle To: Takashi Iwai Cc: Jaroslav Kysela , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, florian@linux-mips.org, Florian Fainelli , linux-arch@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , Benjamin Herrenschmidt , Paul Mackerras , "David S. Miller" , sparclinux@vger.kernel.org Subject: Re: SB16 build error. Message-ID: <20110630123212.GA6690@linux-mips.org> References: <20110630091754.GA12119@linux-mips.org> <20110630105254.GA25732@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 30, 2011 at 01:28:03PM +0200, Takashi Iwai wrote: > > > I have no idea how big the soundblaster microcode being loaded actually is, > > > that is if the reduced size of 0x1f00 will be sufficient. > > > > The files found in /lib/firmware/sb16 are all under 2kB, thus likely > > sufficient. > > Too shortly answered. It turned out that some CSP codes (like Qsound) > can be above that size, it's almost 12kB. So the size in the original > code is really the necessary requirement, and the patch breaks for > such a case. > > An ugly workaround would be to fake the ioctl size. But this is > certainly to be avoided, since it has been broken on the specific > platforms for ages, thus breaking for them would be mostly harmless, > too. > > > > Aside of that I > > > don't see a problem - I don't see how the old ioctl can possibly have been > > > used before so there isn't a compatibility problem. > > > > > > Or you could entirely sidestep the problem and use request_firmware() but > > > I guess that's more effort than you want to invest. > > > > Yeah, that's another option I thought of. But it's too intrusive for > > 3.0-rc6, so I'd like waive it for 3.1. > > Actually the request_firmware() was implemented for some auto-loadable > CSP codes. Others need the manual loading, so it is via ioctl. It > can be converted, but I don't think it makes sense for such old > stuff. After all, it still works with x86-ISA as is. In userland an empty definition will be used for _IOC_TYPECHECK so there won't be an error. So userland already is already using the existing value for SNDRV_SB_CSP_IOCTL_LOAD_CODE ... With a crude hack like #define SNDRV_SB_CSP_IOCTL_LOAD_CODE \ _IOC(_IOC_WRITE,'H', 0x11, sizeof(struct snd_sb_csp_microcode)) error checking can be bypassed and all will be fine as long as the resulting value doesn't result in in a a duplicate case value - which it doesn't, at least not in my testing. Should work but isn't nice. Ralf