This proposal is based on an observation of Manuel's that we could construct all of our event codes in a much more logical fashion by breaking them up into a series of bit fields within the event code. So lets define this as a structure for the purposes of this discussion. The eventual implementation would probably be done with macros. I'm assuming it makes sense to have a single 32bit number as the event code. Sorry for the abuse of kernel doc. I have no idea how one actually documents unions or structures within structures. /** * iio_event_code - structure representing an event * @sensor_type: 256 codes for different classes of sensors * - accel, gyro, in, light etc. * @directedornot: Tells us whether the modifier is for a sensor * with axes or one where this doesn't make sense. * @modifier: identify which channel * @directed: modifier for sensor where an axis makes sense * @direction: 16 different directions, x, y, z + compound * versions x|y|z x|y x|z y|z x&y&z x&y x&z y&z * @number: allow up to 8 sensors in a given direction if * it is a sensor where direction makes sense. * @number: for sensor where axis doesn't make sense allow 128 channels * @type: thresh, mag, roc + specific things like free fall etc. * @direction: falling or rising or either. (so there are some spare bits here). **/ struct iio_event_code { unsigned sensor_type:8; union { unsigned directedornot:1; struct { unsigned direction:4; unsigned number:3; } directed; unsigned number:7; } modifer; unsigned type:8; unsigned direction:8; }; So would people be happy with this rough approach. + please comment on the exact layout and in particular point out classes of event that do not fit. The interpretation of everything after sensor_type for buffer events will probably have to be separately defined. It would complicate this too much. Given the resounding silence that followed my recent post asking for wider opinions on naming of such events (to lkml), I'll probably just get on with implementing the scheme we suggested there for naming the attributes etc. Thanks, 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