On Mon, 28 Aug 2017 12:23:45 -0400 William Breathitt Gray <vilhelm.gray@xxxxxxxxx> wrote: > On Sun, Aug 20, 2017 at 01:11:18PM +0100, Jonathan Cameron wrote: > >On Mon, 31 Jul 2017 12:03:46 -0400 > >William Breathitt Gray <vilhelm.gray@xxxxxxxxx> wrote: > > > >> This patch adds support for the IIO generic counter interface to the > >> 104-QUAD-8 driver. The existing 104-QUAD-8 device interface should not > >> be affected by this patch; all changes are intended as supplemental > >> additions as perceived by the user. > >> > >> IIO Counter Signals are defined for all quadrature input pairs > >> (A and B), as well as index input lines. However, IIO Counter Triggers > >> are not created for the index input Signals. IIO Counter Values are > >> created for the eight quadrature channel counts, and their respective > >> Signals are associated via IIO Counter Triggers. > >> > >> The new generic counter interface sysfs attributes expose the same > >> functionality and data available via the existing 104-QUAD-8 device > >> interface. Four IIO Counter Value function modes are available, > >> correlating to the four possible quadrature mode configurations: > >> "non-quadrature," "quadrature x1," "quadrature x2," and "quadrature x4." > >> > >> A quad8_remove function is defined to call iio_counter_unregister. This > >> function can be eliminated once a devm_iio_counter_register function is > >> defined. > >> > >> Signed-off-by: William Breathitt Gray <vilhelm.gray@xxxxxxxxx> > > > >A good example. > > > >I think it does make it clear that we need to be very careful on how much of > >the interface is defined by freeform strings. Even if we export other means > >of establishing the associations to userspace, the moment there are strings > >available giving them names, software will start to use those. > > > >May be fine but we need to be very careful. > > I would like to limit the amount of strings as well; the availability of > freeform strings has an unfortunate tendency to create situations where > different drivers form separate conventions for duplicate functionality. Absolutely. > > The reason freeform strings are available for the generic counter > interface is to provide the flexibility to support more complex classes > of counters. More specific counter class interfaces such as the future > quadrature counter interface will likely expose predefined constants > rather than allow drivers to create their own strings. In general > though, I believe your warning is a good word of caution and I'll keep > an eye on reducing the amount of freeform strings we allow. OK. That could work fine - we enforce the usage by review rather than code. > > In truth, while this is a good example of how a driver would utilize the > generic counter interface with real hardware, it's not a perfect case > for quadrature counters in general. As you noticed, the dynamic aspects > of the generic counter interface are not needed by the 104-QUAD-8. The > future quadrature counter interface would be more fitting for the > 104-QUAD-8. > > In addition, I may provide a dummy software counter driver in version 2 > of this patchset to showcase and exemplify the functionality of the > generic counter interface more directly and aptly. That could be very useful. An alternative would be to look at a simple device (if we can find one) and implement a userspace fake for it (similar to what Guenter has done with lots of hwmon devices). That way we can play with a real driver against fake hardware and get the best of all possible worlds. I've been meaning to look at doing this for various IIO drivers for a while (most complete for i2c devices I think). As you might imagine I don't actually have that many parts (and most of them aren't connected to boards at any given time) so any form of emulation can be very helpful. I'll see if I can dig up any interesting devices beyond the ones we already know are integrated in various SoCs. I think we really need say 2+ devices to justify decisions in the core code. I did the original IIO version against 3ish devices but that was more varied (and that wasn't nearly enough with hindsight!) Jonathan -- 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
