Messages in this thread | | | Date | Wed, 10 Dec 2014 14:17:15 +0100 | From | Jacek Anaszewski <> | Subject | Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension |
| |
On 12/09/2014 04:50 PM, Pavel Machek wrote: > 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.
I don't like the idea of listing the faults in the form of strings. I'd like to see the third opinion :)
> Only cost is few lines of code in the drivers where hardware clears > faults at read.
As above - the third opinion would be appreciated.
>> 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?
There are possible designs with two separate LEDs.
-- Best Regards, Jacek Anaszewski
| |