linux-kernel - Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Dec 2014 16:50:33 +0100
From:	Pavel Machek <pavel@....cz>
To:	Jacek Anaszewski <j.anaszewski@...sung.com>
Cc:	Bryan Wu <cooloney@...il.com>,
	Linux LED Subsystem <linux-leds@...r.kernel.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	b.zolnierkie@...sung.com, "rpurdie@...ys.net" <rpurdie@...ys.net>,
	Sakari Ailus <sakari.ailus@....fi>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>
Subject: Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED
 Flash class extension

On Tue 2014-12-09 09:54:06, Jacek Anaszewski wrote:
> Hi Pavel,
> 
> On 12/08/2014 09:18 PM, Pavel Machek wrote:
> >On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote:
> >>On 12/06/2014 01:43 PM, Pavel Machek wrote:
> >>>
> >>>>>The format of a sysfs attribute should be concise.
> >>>>>The error codes are generic and map directly to the V4L2 Flash
> >>>>>error codes.
> >>>>>
> >>>>
> >>>>Actually I'd like to see those flash fault code defined in LED
> >>>>subsystem. And V4L2 will just include LED flash header file to use it.
> >>>>Because flash fault code is not for V4L2 specific but it's a feature
> >>>>of LED flash devices.
> >>>>
> >>>>For clearing error code of flash devices, I think it depends on the
> >>>>hardware. If most of our LED flash is using reading to clear error
> >>>>code, we probably can make it simple as this now. But what if some
> >>>>other LED flash devices are using writing to clear error code? we
> >>>>should provide a API to that?
> >>>
> >>>Actually, we should provide API that makes sense, and that is easy to
> >>>use by userspace.
> >>>
> >>>I believe "read" is called read because it does not change anything,
> >>>and it should stay that way in /sysfs. You may want to talk to sysfs
> >>>maintainers if you plan on doing another semantics.
> >>
> >>How would you proceed in case of devices which clear their fault
> >>register upon I2C readout (e.g. AS3645)? In this case read does have
> >>a side effect. For such devices attribute semantics would have to be
> >>different than for the devices which don't clear faults on readout.
> >
> >No, semantics should be same for all devices.
> >
> >If device clears fault register during I2C readout, kernel will simply
> >gather faults in an variable, and clear them upon write to sysfs file.
> 
> This approach would require implementing additional mechanisms on
> both sides: LED Flash class core and a LED Flash class driver.
> In the former the sysfs attribute write permissions would have
> to be decided in the runtime and in the latter caching mechanism

Write attributes at runtime? Why? We can emulate sane and consistent
behaviour for all the controllers: read gives you list of faults,
write clears it. We can do it for all the controllers.

Only cost is few lines of code in the drivers where hardware clears
faults at read.

> would have to be implemented per driver. We would have to also
> consider how to approach the issue in case of sub-leds.

Actually.. sub-leds. That is one physical LED being connected to two
current sources at the same time, right? 

> The only reason for this overhead is trying to avoid side effects
> on reading sysfs attribute. After weighing the pros and cons,
> I am not sure if it is worthwhile.

I am pretty sure.

									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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/