Hi! > >>+ - flash_fault - list of flash faults that may have occurred: > >>+ * led-over-voltage - flash controller voltage to the flash LED > >>+ has exceededthe limit specific to the flash controller > >>+ * flash-timeout-exceeded - the flash strobe was still on when > >>+ the timeout set by the user has expired; not all flash > >>+ controllers may set this in all such conditions > >>+ * controller-over-temperature - the flash controller has > >>+ overheated > >>+ * controller-short-circuit - the short circuit protection > >>+ of the flash controller has been triggered > >>+ * led-power-supply-over-current - current in the LED power > >>+ supply has exceeded the limit specific to the flash > >>+ controller > >>+ * indicator-led-fault - the flash controller has detected > >>+ a short or open circuit condition on the indicator LED > >>+ * led-under-voltage - flash controller voltage to the flash > >>+ LED has been below the minimum limit specific to > >>+ the flash > >>+ * controller-under-voltage - the input voltage of the flash > >>+ controller is below the limit under which strobing the > >>+ flash at full current will not be possible. The condition > >>+ persists until this flag is no longer set > >>+ * led-over-temperature - the temperature of the LED has exceeded > >>+ its allowed upper limit > >>+ > >>+ Flash faults are cleared, if possible, by reading the attribute. > > > >That's bad. Now you can no longer present flash_fault file as readable > >to non-root users, and grep -ri foo /sys will interfere with your > >camera application. > > > >Bad interface, just fix it. > > In my opinion it isn't crucial for the user to be aware of the > fact that some non-persistent fault happened right after strobing the > flash (e.g. over temperature). > > I cannot see anything harmful in the situation when someone does grep > on /sys and clears non-persistent fault on a flash LED device. So why export the faults at all? I mean... another user can just read the file in loop, and the camera application will not get any useful information. > Also, not all devices may be able to report the faults that happened > earlier but are not valid at the time of I2C readout. In that case the > user will never now that the fault has ever occurred, unless they read > the flash_fault attribute at the proper moment. > > In this case we cannot enforce consistent policy for all devices. Too bad. But lets do a good job at least for devices where we can do a good job, ok? > Please describe the use case when clearing the fault on read can be > harmful, if you have any. while true; grep -ri foo /sys; done And no, your application trying to read the faults will very probably read nothing. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
