On Mon, Oct 18, 2010 at 10:33, Jean Delvare wrote: > Why do we have set_irq_type() if we're not supposed to call it? I am > not claiming to be an expert in the area, but it seems totally > reasonable to me that the same piece of code instantiating an I2C > device is also responsible for setting its IRQ type. but we're back to the same issue mentioned earlier -- you cant have a single kernel build with modules supporting multiple drivers simultaneously. we like to ship development boards with a single kernel build on it with many modules. then people can pick the addon boards they wish to prototype with at runtime by plugging in the card and loading the module. if the only way to change flags on a pin is via set_irq_type(), that kernel build is instantly tied to whatever device you've decided to compile statically into the board's init code. so now to prototype multiple boards, we have to tell people to boot different kernels !? and we have to store multiple kernels and sets of kernel modules in the rootfs !? >> The user decides which add-on module is plugged onto the processor board, >> by loading the appropriate driver module. > > This can't work, sorry. Unless you are using I2C device auto-detection, > which I seem to understand is NOT used in the embedded world at all, > loading a driver module doesn't do anything if a device it supports > hasn't been instantiated first. So the user can't just load a driver > and see the required I2C devices magically appear for the driver to > bind to them. why cant user selection work ? the user picks `modprobe foo` because they have a 'foo' device plugged in. i'm not sure what "I2C device auto-detection" means. are you talking about a userspace app/daemon that scans the I2C bus, looks up the slave ids in the module db, and then automatically loads the modules that it finds bindings for ? >> There are drivers that work around this deficiency, by adding irq_flags to the bus >> clients dev.platform_data. See include/linux/spi/ads7846.h for one example. > > Interesting example, better matching the initial comment that came > along with the patch. But it also seems to be an isolated case, as I > can't find any other irq_flags in include/linux/{i2c,spi}/. we've been holding off posting things because we need the core extended first -mike -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html