Hi!
[Actually, you could _always_ do two reads on those devices, discard
first result, and return the second. But I'm not sure how hardware
will like that.]
This would be the most sensible option.
However, let's analyze the typical use cases for flash strobing:
-------------------------------------------------------------
Version without faults caching:
============
Driver side:
============
read_faults()
faults = read_i2c(); //read faults
if faults
write_i2c(); //clear faults, only for some devices
faults = read_i2c(); //read faults
return faults
================
User space side:
================
1. faults = `cat flash_faults` //read_faults()
2. if faults then
print "Unable to strobe the flash LED due to faults"
else
echo 1 > flash_strobe
Version with faults caching:
============
Driver side:
============
read_faults()
faults |= read_i2c(); //read faults
clear_faults()
write_i2c(); //clear faults
faults = 0;
================
User space side:
================
1. faults = `cat flash_faults` //read_faults()
2. if faults then
echo 0 > flash_faults //clear_faults()
faults = `cat flash_faults` //read_faults()
3, if !faults
echo 1 > flash_strobe
else
print "Unable to strobe the flash LED due to faults"
-------------------------------------------------------------
From the above it seems that version with clearing faults on read
results in the simpler flash strobing procedure on userspace side,
by the cost of additional bus access on the driver side.
I like caching version more (as it will allow by-hand debugging of
"why did not flash fire? Aha, lets see in the file, there was fault),
but both should be acceptable.
we don't need additional attribute, just writing the flash_faults
attribute can do the clearing.
Yes, writing flash_faults to clear is acceptable.