>> I think that trying to make this generic is purely synthetic. This >> information is board-specific per it's nature, it comes from what board >> is designed for, different boards have quite different sets of possible >> reset reasons. What is needed is - pass this board-specific information >> to board-specific user space. >> >> What's proper API for that, if not a sysfs attribute? > > Please go through the thread. > > Sysfs attribute is okay, but: > > 1) it should probably be a string > > 2) it should certainly be superset of all the reasons > > 3) it should be in generic place, say /sys/power/reset_reason > > 4) it should be documented what each state means
What I'm concerned here is that a requirement appears for kernel driver to keep and maintain knowledge of what all that codes mean. For me, it looks like information locality breakage. Information in question is application-specific, it definitely changes from board to board and probably will change for particular board over time. It's desirable to keep this information application-private, and have kernel only passed it from hardware to application, unmodified and uninterpreted. Requiring kernel driver to interpret application-specific information only increases complexity (i.e. any changes will have to be maintained in two places - in driver and in application). So question is - is there any proper API to communicate application-private information from hardware through kernel to userspace without any in-kernel interpretation?
