On Sun, Apr 24, 2016 at 2:28 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > On 20/04/16 16:45, Daniel Baluta wrote: >> For testing purposes is nice to have a quick way of creating IIO devices. >> This patch series introduces support for creating IIO devices via configs >> (patch 1), allowing users to register "device types". For the moment we >> support "dummy" device type (patch 2). >> >> This is just a RFC in order to see if the interface is acceptable. We also >> need a way to create IIO devices with configurable number of channels. >> >> Patch 3 introduces configfs entries documentation for easier review. >> >> Daniel Baluta (3): >> iio: Add support for creating IIO devices via configfs >> iio: dummy: Convert IIO dummy to configfs >> Documentation: iio: Add IIO software devices docs >> >> Documentation/ABI/testing/configfs-iio | 13 +++ >> drivers/iio/Kconfig | 9 ++ >> drivers/iio/Makefile | 1 + >> drivers/iio/dummy/iio_simple_dummy.c | 98 ++++++------------ >> drivers/iio/industrialio-sw-device.c | 181 +++++++++++++++++++++++++++++++++ >> include/linux/iio/sw_device.h | 70 +++++++++++++ >> 6 files changed, 307 insertions(+), 65 deletions(-) >> create mode 100644 drivers/iio/industrialio-sw-device.c >> create mode 100644 include/linux/iio/sw_device.h >> > Sorry, I was a muppet and delete patch one due to a misstap on my phone... > Anyhow, pasting it in here to review... > >> This is similar with support for creating triggers via configfs. >> Devices will be hosted under: >> * /config/iio/devices >> >> We allow users to register "device types" under: >> * /config/iio/devices/<device_types>/ >> >> Signed-off-by: Daniel Baluta <daniel.baluta@xxxxxxxxx> > As you observed, there is room in here to share some code with the sw-trigger > support. Looks like we are going to have an iio-configfs helper library > or perhaps just move them into the industrialio-configfs module... > > However, I'm not sure it's actually a good idea. Seems to me that the amount > of fiddly indirection needed would outway the advantages in reduced code > replication. > > Other than a few nitpicks this looks good to me - though that's not surprising > as it's a find and replace job on the trigger version! Yes, I think we can live with the code as it is now. I'm now thinking of a more flexibly interface, that will allow us creating an IIO devices with configurable number and types of IIO channels. This will be later useful in evaluating the choices for sensor hubs with lots of sensors attached: Single IIO device for all sensors VS One IIO device per sensor type. Daniel. -- 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
