From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757580AbbA2VOZ (ORCPT ); Thu, 29 Jan 2015 16:14:25 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:33511 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752239AbbA2VOX (ORCPT ); Thu, 29 Jan 2015 16:14:23 -0500 Date: Thu, 29 Jan 2015 22:14:20 +0100 From: Pavel Machek To: Jacek Anaszewski Cc: Greg KH , kernel list , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, kyungmin.park@samsung.com, b.zolnierkie@samsung.com, cooloney@gmail.com, rpurdie@rpsys.net, sakari.ailus@iki.fi, s.nawrocki@samsung.com Subject: Re: Reading /sys with side effects (was Re: [PATCH 1/2] Documentation: leds: Add description of LED Flash class extension) Message-ID: <20150129211420.GA21140@amd> References: <1422346028-16739-1-git-send-email-j.anaszewski@samsung.com> <20150127221958.GA18993@amd> <54C8A130.8000807@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C8A130.8000807@samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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