umac.ko for 2.6.26

Gregoire Gentil gregoire at gentil.com
Tue Aug 19 08:29:09 EEST 2008


On Sun, 2008-08-17 at 17:03 -0400, Gregoire Gentil wrote: 
> Faheem,
> 
> Thanks for the tip. I tried it and it worked. I can insmod both umac and
> cx3110x in 2.6.26 and it looks fine in dmesg:
> 
> cx3110x: chip variant STLC4550
> cx3110x: firmware version 2.13.0.0.a.22.8.
> cx3110x: driver version 2.0.15 loaded.
> 
> But then I get multiple errors:
> 
> ifconfig wlan0 up reports "SIOCSIFFLAGS: Cannot assign requested
> address"
> 
> iwlist wlan0 scan doesn't work
> 
> and in dmesg, I get many:
> cx3110x: WARNING SoftMAC not initialized, chip not booted
> 
> I compiled cx3110x from
> http://repository.maemo.org/pool/maemo4.1/free/c/cx3110x-module-src/cx3110x-module-src_2.0.15-1.tar.gz
> against my 2.6.26 kernel. I had to modify the code in two locations:
> 
> - in sm_drv_spi_io.c, replace SA_INTERRUPT by IRQF_DISABLED
> - in sm_drv.c, remove the line where mac.raw is assigned
> 
> 
> Any idea? Has anyone successfully tried what I'm doing now?
A little bit more of information from dmesg with the full
debug flag in cx3110x:

[  274.247192] umac: module license 'Proprietary' taints kernel.
[ 1328.262176] sm_drv_spi_probe
[ 1328.262237] sm_drv_netdev_create
[ 1328.262298] Registering WLAN platform device
[ 1328.262847] Creating WLAN sysfs
[ 1328.463775] sm_drv_statistics 
[ 1328.465545] cx3110x: chip variant STLC4550.
[ 1328.465606] sm_drv_fetch_firmware
[ 1328.465606] firmware: requesting 3826.arm
[ 1328.708282] sm_drv_fetch_firmware: file 3826.arm (31284 bytes)
[ 1328.708343] cx3110x: firmware version 2.13.0.0.a.22.8.
[ 1328.708740] cx3110x: driver version 2.0.15 loaded.
[ 1370.573364] GET RANGE
[ 1370.573455] cx3110x: WARNING SoftMAC not initialized, chip not booted (get oid 0x17000012)

The last message means that lp->sm_initialization = 0. Indeed,
sm_drv_spi_initialize is not reached. sm_drv_spi_wq which
calls sm_drv_spi_initialize, seems also never reached - so
no ifconfig! -:( I checked that INIT_WORK(&lp->work,sm_drv_spi_wq);
is reached inside sm_drv_spi_probe.

So why don't we get this first crucial interrupt?
Kalle? A little bit of help? ;-)

Grégoire


More information about the cx3110x-devel mailing list