debian wheezy for RPi still uses old kernel

I quickly came across Chris Boot's site last week when trying to figure out how to use i2c.  However, I didn't stop to read more about the security vulneribility until I saw your post.  Very interesting: http://blog.zx2c4.com/749

it looks like i2c and spi drivers are another reason to want to move

from the 3.1.9 kernel to 3.2.x.

security issues aside, it really is trivial to backport the drivers to 3.1.9 if you really want to. The total of the difference is here https://github.com/selsinork/raspberry-pi-i2c-spi-drivers/commit/b9278572966c6797dac216e1703e56c812ec076a

They do work happily on 3.1.9, I've used them there while the sd card issues were worked on - I had lots more sdcard problems with 3.2.x before Grigori integrated his latest stuff into 3.2.x

That said, I'd still suggest moving to 3.2.20 regardless.

There's a bunch of other niggles that haven't been sorted yet, even in Chris' 3.2.20 kernel:

the bcm2708_gpio driver will claim all available gpios - makes properly integrating your mcp23017 impossible as the driver won't load

no gpio interrupts - patches have been posted for this

"bcm2708_gpio driver will claim all available gpios" - do you mean that i2c won't work then?  I'm going to try hooking up a DS1307 RTC board via level converter tonight and was planning to use bootc's latest 3.2 kernel.

thanks,

drew

"bcm2708_gpio driver will claim all available gpios" - do you mean that i2c won't work then?  I'm going to try hooking up a DS1307 RTC board via level converter tonight and was planning to use bootc's latest 3.2 kernel.

thanks,

drew

I2C will work fine, both the I2C and SPI drivers work with the gpio driver to deal with that as they use existing gpio pins but just change the function.

Essentially RPi has 54 gpios on the SoC. The way the machine definition has been written defines the maximum number of possible gpio pins, ever, as being 54. The bcm2708_gpio driver then blindly claims all gpios up to the maximum number.

Raise the maximum to 100 and the driver claims them all, even though there are still only 54 real ones on the SoC and that's all the driver knows what to do with.

So, try to setup a mcp23017 using the in-kernel driver and it'll fail to initialise the driver, no free gpios..

Increase the maximum gpios and tell the mcp23017 to start at gpio 55, different cryptic error.

You have to stop the bcm2708_gpio driver from claiming all possible gpios, and convince it to only try to claim the 54 that it knows what to do with.  You can then remove the maximum and the mcp23017 driver can load.

Most of these little problems will go away in time. I'm hoping that Chris and Simon will get their port / rewrite to the 3.5 mainline kernel to a useful point fairly soon at which point most of the current pain will probably cease to exist

Ah, thanks for clarifying.  I see that I wasn't thinking about it right.  The i2c pins to the mcp23017 work, but, since it's a port expander, the pins that it offers can't be accessed due to the bcm2708_gpio interference.

Thanks,

Drew

You could always write a 'driver' for  the expander completely in userspace. But that leaves you to deal with all the details and is work that the folks who wrote the kernel driver already did for you.

IMHO it's better to use the stuff that's already there, makes it easier to seamlessly switch between onboard and exapnder provided gpios too.

Don't get me wrong, I've written userspcae drivers for i2c stuff when there isn't an in-kernel driver available.  I'm trying to get the kernel version of one of those drivers accepted just now.