Re: [alsa-devel] SB16 build error.
![](https://secure.gravatar.com/avatar/091e52bf20dead91ded99470048602a5.jpg?s=120&d=mm&r=g)
On Thu, Jun 30, 2011 at 12:15:56PM +0200, Takashi Iwai wrote:
At Thu, 30 Jun 2011 10:17:54 +0100, Ralf Baechle wrote:
Found on a MIPS build but certain other architectures will have the same issue:
CC sound/isa/sb/sb16_csp.o sound/isa/sb/sb16_csp.c: In function ‘snd_sb_csp_ioctl’: sound/isa/sb/sb16_csp.c:228: error: case label does not reduce to an integer constant make[1]: *** [sound/isa/sb/sb16_csp.o] Error 1 make: *** [sound/isa/sb/sb16_csp.o] Error 2
This error message is caused by the _IOC_TYPECHECK() error check triggering due to excessive ioctl size on Alpha, PowerPC, MIPS and SPARC which define _IOC_SIZEBITS as 13. On all other architectures define it as 14 so struct snd_sb_csp_microcode with it's little over 12kB will just about fit into the 16kB limit.
What about the patch below?
I have no idea how big the soundblaster microcode being loaded actually is, that is if the reduced size of 0x1f00 will be sufficient. 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.
This is an old ISA driver, so the impact must be very low.
True. I notice that sort of stuff in automated mass builds - not necessarily the sort of kernels one would actually use. Still build errors are annoying :)
Ralf
![](https://secure.gravatar.com/avatar/586424ca0847070dc1868aa58077003e.jpg?s=120&d=mm&r=g)
Ralf Baechle 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 biggest file is WFM0001A.CSP with 0x2df0 bytes.
I don't see how the old ioctl can possibly have been used before so there isn't a compatibility problem.
The code uses SNDRV_SB_CSP_MAX_MICROCODE_FILE_SIZE but doesn't care what the size field of the ioctl code is, so we could use any random value on those architectures.
Or you could entirely sidestep the problem and use request_firmware() but I guess that's more effort than you want to invest.
The driver already implements this for a bunch of predefined CSP code blobs. I'm not sure whether anybody has ever loaded additional .csp files.
Regards, Clemens
participants (2)
-
Clemens Ladisch
-
Ralf Baechle