Here's what happened when I tried to omit an iio_info struct during my simple probe-only driver. iio_info stores some constant info about the device, like attributes and pointers to the functions that sysfs will use. Since, I wasn't defining my read_raw yet, I removed it and here's what happened:
My probe failed with an OOPs! When you're doing the kind of stuff I was doing and you get a kernel oops saying something about dereferencing a null pointer, it really doesn't require must investigative work, unless you want to try out gdb.
Use gdb to find that offset in the code. I had not built with CONFIG_DEBUG_INFO. I just rebuilt drivers/iio with it now and was able to get the correct offsets in gdb.
Since the null pointer dereference was in something with the word 'debug' in it, I thought, hey, I can work around that. I can turn off a compile option. Alternatively, debugfs should be checking for null pointer. So, I added the null pointer check:
And, here's what happened next:
It worked(!) until it failed on another null pointer dereference of the same field. A second opportunity to use gdb, but of course I know what I'm going to find. It's ok to have an empty iio_info, with no attributes and no functions, but you must have one.
I put an empty mcp9808_info back in for that probe-only driver and moved on. It's not empty any longer since I've created my read_raw routine.
I added this to my WAT (What About That) list. I'm pretty sure no one would write a driver without it, so that specifically is not the curiosity. It did make me think about how we define structures and note what's required and how we check for potential null pointer dereferences.
Labels: gdb. iio_info, IIO Driver
