From: Sakari Ailus <sakari.ailus@iki.fi>
To: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Pavel Machek <pavel@ucw.cz>,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, kyungmin.park@samsung.com,
b.zolnierkie@samsung.com, cooloney@gmail.com, rpurdie@rpsys.net,
s.nawrocki@samsung.com
Subject: Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
Date: Mon, 1 Dec 2014 17:21:42 +0200 [thread overview]
Message-ID: <20141201152142.GT8907@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <547C7420.4080801@samsung.com>
Hi Jacek and Pavel,
On Mon, Dec 01, 2014 at 02:58:56PM +0100, Jacek Anaszewski wrote:
> Hi Pavel,
>
> On 12/01/2014 02:04 PM, Pavel Machek wrote:
> >Hi!
> >
> >>>How are faults cleared? Should it be list of strings, instead of
> >>>bitmask? We may want to add new fault modes in future...
> >>
> >>Faults are cleared by reading the attribute. I will add this note.
> >>There can be more than one fault at a time. I think that the bitmask
> >>is a flexible solution. I don't see any troubles related to adding
> >>new fault modes in the future, do you?
> >
> >I do not think that "read attribute to clear" is good idea. Normally,
> >you'd want the error attribute world-readable, but you don't want
> >non-root users to clear the errors.
>
> This is also V4L2_CID_FLASH_FAULT control semantics.
> Moreover many devices clear the errors upon reading register.
> I don't see anything wrong in the fact that an user can clear
> an error. If the user has a permission to use a device then
> it also should be allowed to clear the errors.
I agree. Some of these such as the timeout are not hardware related
problems at all, but others may be. I'd keep the same semantics as V4L2
already does.
> >I am not sure if bitmask is good solution. I'd return space-separated
> >strings like "overtemp". That way, there's good chance that other LED
> >drivers would be able to use similar interface...
>
> The format of a sysfs attribute should be concise.
> The error codes are generic and map directly to the V4L2 Flash
> error codes.
I'd guess a single application accesses either of the interfaces. From that
point of view it doesn't matter what are the bit definitions in V4L2.
The behaviour on sysfs could also be different, e.g. writing the attribute
would clear the faults. This would need more functionality from drivers.
The V4L2 behaviour mirrors the typical behaviour of flash controllers ---
the chips mostly do not operate until the faults have been read, and the
interface as well as the interface take no stance to that. So when the user
reads the fault control value, the fault register on the chip is cleared as
well.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
next prev parent reply other threads:[~2014-12-01 15:21 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-28 9:17 [PATCH/RFC v8 00/14] LED / flash API integration Jacek Anaszewski
2014-11-28 9:17 ` [PATCH/RFC v8 01/14] leds: Add LED Flash class extension to the LED subsystem Jacek Anaszewski
[not found] ` <CAK5ve-KMdJOLQ0ThKw9OM9u_CcwT87Bx4vcUjnX4fG2+t3pJsw@mail.gmail.com>
2014-12-08 17:07 ` Jacek Anaszewski
2014-11-28 9:17 ` [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension Jacek Anaszewski
2014-11-29 12:58 ` Pavel Machek
2014-12-01 11:40 ` Jacek Anaszewski
2014-12-01 13:04 ` Pavel Machek
2014-12-01 13:58 ` Jacek Anaszewski
2014-12-01 15:21 ` Sakari Ailus [this message]
2014-12-05 19:45 ` Bryan Wu
2014-12-06 12:43 ` Pavel Machek
2014-12-08 16:55 ` Jacek Anaszewski
2014-12-08 20:18 ` Pavel Machek
2014-12-09 8:54 ` Jacek Anaszewski
2014-12-09 15:50 ` Pavel Machek
2014-12-10 13:17 ` Jacek Anaszewski
2014-12-10 13:32 ` Pavel Machek
2014-12-10 23:14 ` Sakari Ailus
2015-01-29 21:24 ` Pavel Machek
2014-11-28 9:17 ` [PATCH/RFC v8 03/14] Documentation: leds: Add description of v4l2-flash sub-device Jacek Anaszewski
2014-11-29 23:44 ` Sakari Ailus
2014-12-05 19:50 ` Bryan Wu
2014-11-28 9:17 ` [PATCH/RFC v8 04/14] v4l2-async: change custom.match callback argument type Jacek Anaszewski
2014-11-29 13:00 ` Pavel Machek
2014-11-29 16:38 ` Laurent Pinchart
2014-12-01 9:35 ` Jacek Anaszewski
2014-11-28 9:17 ` [PATCH/RFC v8 05/14] v4l2-ctrls: Add V4L2_CID_FLASH_SYNC_STROBE control Jacek Anaszewski
2014-11-28 9:17 ` [PATCH/RFC v8 06/14] media: Add registration helpers for V4L2 flash sub-devices Jacek Anaszewski
2014-12-01 14:53 ` Jacek Anaszewski
2014-11-28 9:17 ` [PATCH/RFC v8 07/14] exynos4-is: Add support for v4l2-flash subdevs Jacek Anaszewski
2014-11-29 13:02 ` Pavel Machek
2014-11-28 9:18 ` [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property Jacek Anaszewski
2014-11-28 11:14 ` Mark Rutland
2014-11-28 12:09 ` Jacek Anaszewski
2014-11-28 12:30 ` Mark Rutland
2014-11-28 14:11 ` Jacek Anaszewski
2014-11-28 14:38 ` Mark Rutland
2014-11-28 9:18 ` [PATCH/RFC v8 09/14] mfd: max77693: adjust max77693_led_platform_data Jacek Anaszewski
2014-12-01 11:34 ` Lee Jones
2014-12-01 12:49 ` Jacek Anaszewski
2014-12-01 12:53 ` Lee Jones
2014-11-28 9:18 ` [PATCH/RFC v8 10/14] leds: Add support for max77693 mfd flash cell Jacek Anaszewski
2014-11-28 9:18 ` [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693 Jacek Anaszewski
2014-11-29 19:26 ` Pavel Machek
2014-12-01 12:58 ` Jacek Anaszewski
2014-12-01 13:02 ` Pavel Machek
2014-12-01 13:43 ` Jacek Anaszewski
2014-12-01 11:15 ` Lee Jones
2014-11-28 9:18 ` [PATCH/RFC v8 12/14] leds: Add driver for AAT1290 current regulator Jacek Anaszewski
2014-11-29 19:05 ` Pavel Machek
2014-12-01 11:47 ` Jacek Anaszewski
2014-11-28 9:18 ` [PATCH/RFC v8 13/14] of: Add Skyworks Solutions, Inc. vendor prefix Jacek Anaszewski
2014-11-28 9:18 ` [PATCH/RFC v8 14/14] DT: Add documentation for the Skyworks AAT1290 Jacek Anaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141201152142.GT8907@valkosipuli.retiisi.org.uk \
--to=sakari.ailus@iki.fi \
--cc=b.zolnierkie@samsung.com \
--cc=cooloney@gmail.com \
--cc=j.anaszewski@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rpurdie@rpsys.net \
--cc=s.nawrocki@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®