From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: SB16 build error. Date: Thu, 30 Jun 2011 14:38:20 +0200 Message-ID: References: <20110630091754.GA12119@linux-mips.org> <20110630105254.GA25732@linux-mips.org> <20110630123212.GA6690@linux-mips.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110630123212.GA6690@linux-mips.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Ralf Baechle Cc: linux-arch@vger.kernel.org, linux-mips@linux-mips.org, alsa-devel@alsa-project.org, florian@linux-mips.org, "David S. Miller" , Benjamin Herrenschmidt , linux-kernel@vger.kernel.org, Ivan Kokshaysky , sparclinux@vger.kernel.org, Paul Mackerras , Matt Turner , Florian Fainelli , Richard Henderson List-Id: linux-arch.vger.kernel.org At Thu, 30 Jun 2011 13:32:12 +0100, Ralf Baechle wrote: > > 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 ... Right. It has an invalid direction (3), but apps won't care such details anyway. > 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. Indeed. But which is uglier is hard to answer :) If you are fine with the hacked ioctl number above, I can put it with some comments. This won't break anything, at least. thanks, Takashi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cantor2.suse.de ([195.135.220.15]:43082 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752608Ab1F3MiY (ORCPT ); Thu, 30 Jun 2011 08:38:24 -0400 Date: Thu, 30 Jun 2011 14:38:20 +0200 Message-ID: From: Takashi Iwai Subject: Re: SB16 build error. In-Reply-To: <20110630123212.GA6690@linux-mips.org> References: <20110630091754.GA12119@linux-mips.org> <20110630105254.GA25732@linux-mips.org> <20110630123212.GA6690@linux-mips.org> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-arch-owner@vger.kernel.org List-ID: To: Ralf Baechle 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 Message-ID: <20110630123820.bRF0gwjEzC1CqzaZNqogX3oejtjwtgOcZ9HuDIeNaYg@z> At Thu, 30 Jun 2011 13:32:12 +0100, Ralf Baechle wrote: > > 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 ... Right. It has an invalid direction (3), but apps won't care such details anyway. > 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. Indeed. But which is uglier is hard to answer :) If you are fine with the hacked ioctl number above, I can put it with some comments. This won't break anything, at least. thanks, Takashi