On 10/05/10 15:11, Hennerich, Michael wrote: > Jonathan Cameron wrote on 2010-10-05: >> On 10/05/10 14:00, Michael Hennerich wrote: >>> >>> Signed-off-by: Michael Hennerich <michael.hennerich@xxxxxxxxxx> >> Acked-by: Jonathan Cameron <jic23@xxxxxxxxx> >> >> Send it to Greg with the first user... Also need to update the >> documentation in sysfs-bus-iio to cover this, but that can be a >> separate patch. >> >> Jonathan > > Hi Jonathan, > > I wonder why the documentation is specific to accel? > I think that can be many things... Simply because the format of those file doesn't (I think) allow for a variable in the name and as you say there are lots of sensor types. Hence if I did it as a [accel|magn| etc] I'd end up with a very very long line. It appears that those file were created by Greg KH (according to git blame on the readme) So Greg, if you are the person to ask (if not please suggest who is!)... In the sysfs abi docs, we have been rather fast and loose with the formatting and Michael's question in this email motivated me to ask for some guidance. We have an awful lot of possible sysfs attributes to document. So far we have been using [] to indicate optional elements in naming (explained in the description). (e.g. accel[_x]_type ) A lot of the file sysfs-bus-iio uses only accel as an example whereas the attributes equally exist for all the other types (e.g. magn, gyro, illuminance etc). In discussions on list we have been using <type> to indicate a variable which can take any of the channel types, but I don't know if it is valid to use this in the abi files. That is, can we define some variable that takes a set of values just once for the file and then use <type> in the naming to indicate replacement with one of the set? Another option would be to have multiple what lines. e.g. What: accel_[x|y|z]_type What: gyro_[x|y|z]_type What: magn_[x|y|z]_type etc. The approach of just doing it for accel has caused a number of people to miss certain definitions so far so we need to work out some want of making this clearer preferably without obliging people to have sections like the following What: gyro_[x|y|z]_type ... Description: Equivalent of accel_[x|y|z]_type but for gyroscope channels. Thanks, Jonathan > > What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_type > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Description of the scan element data storage within the buffer > and hence the form in which it is read from userspace. > Form is [s|u]bits/storagebits. s or u specifies if signed > (2's complement) or unsigned. bits is the number of bits of > data and storagebits is the space (after padding) that it > occupies in the buffer. Note that some devices will have > additional information in the unused bits so to get a clean > value, the bits value must be used to mask the buffer output > value appropriately. The storagebits value also specifies the > data alignment. So s48/64 will be a signed 48 bit integer > stored in a 64 bit location aligned to a a64 bit boundary. > For other storage combinations this attribute will be extended > appropriately. > > > > > > Greetings, > Michael > > Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen > Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif > > > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
