On Thu, 2014-07-03 at 18:51 +0100, Jonathan Cameron wrote: > On 01/07/14 13:10, Bastien Nocera wrote: > > Hey again Jonathan, > > > > On Sat, 2014-06-21 at 13:01 +0100, Jonathan Cameron wrote: > > <snip> > >> Just to throw it in there. There is an out of tree bridge driver from > >> IIO to input. It's only out of tree because I haven't had a chance to > >> tidy it up (anyone else is welcome to take this on if they like!) > >> Google for iio_input.c to find it. > >> > >> The intent of that was to allow general accelerometer drivers and similar > >> in IIO to work in conjunction with iio-input to provide input style interfaces. > >> This came about after previous debates on where the 'right' place for > >> accelerometers was in the kernel. I believe that at least in principle, > >> Dmitry was happy with this concept. > > > > After updating forward-porting the driver so that it runs on a more > > recent version of the kernel, I tried to get it running. > > > > I'm guessing that you expected the iio_input driver to be instantiated > > by a board specific file. Is there any way to have it generically try > > out all the IIO devices, similarly to pci_register_driver()? Or should I > > do that in the hid-sensor-accel driver? > At the moment we only have support to instantiate it via such a board specific > file. We probably want to be a little careful about how to add more generic > means for creating such bindings.. > > Simply generically trying all IIO drivers isn't the way to go as there is > no obvious way of deciding what it makes sense to bind to on a given machine. > > Perhaps something closer to the way you can instantiate i2c devices from > userspace, or perhaps we need to consider something else such as configfs for > creating such bindings... (cc'd Lars for comments on whether that makes sense...) Are there cases where we have a hid-sensor that we wouldn't want to expose through the input layer? > We did also have a uinput based approach at one point but it was fairly clunky. > That took data from iio buffers and pushed it back into the kernel via inputs > userspace driver support. Not particularly nice but I thought I'd best mention > it! That's actually something that I looked at and discussed with Benjamin. And it currently looks like the best possible solution in the short-term (I will only have the machine for a couple more weeks...). Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
