On 10/24/11 14:47, Lars-Peter Clausen wrote: > Hi, > > Some chips generate events which don't really map to a channel, but are > rather chip global. For example over-temperature events. That one is a channel. > Do you think this is something we should add support for or should we rather > use a dummy channel, which doesn't report any actual values, for propagating > the event? Yup, have a temp channel for that one. Conceptually you might have two chips that are otherwise identical but one has a readable temp channel, the other doesn't. Userspace that is interested only in events won't care about this difference. Also we want to report what the conditions are as if it were a channel we could read. We want to know at what temperature this occurs. There are others events such as loss of tracking / wire out for the resolvers, but they so far have always corresponded to 'gah, it's all gone wrong' events. Last time I asked more generally about this, Alan Cox suggested using the signals typically employed for network sockets. General view is we didn't want them coming through our normal event path and for example being blocked behind the handling of another event. I then got bogged down with this in kernel interface stuff so haven't looked at it again. > > My idea for supporting channel-less events is to add a event_mask to struct > iio_info, which would be used just like a channels event_mask, but there > would be no index for the sysfs attributes and for events we would set the > event number to 0xffff. Could you give more examples? The temp one to my mind definitely needs a channel, perhaps others do not? I am not against in principal but not yet certain exactly when this would make sense... > > Thanks > - Lars > -- 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
