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