summaryrefslogtreecommitdiff
path: root/Documentation/ABI/obsolete
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2021-07-05 14:01:53 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2021-07-05 14:01:53 -0700
commita16d8644bad461bb073b92e812080ea6715ddf2b (patch)
tree2baa375527e57c0df2bf56d28e7cf36fb97a435c /Documentation/ABI/obsolete
parentf5c13f1fdef9fed65b95c3c5f343d22c425ac1d7 (diff)
parent77ad1f0e99bd00af024e650b862cfda3137af660 (diff)
Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging / IIO driver updates from Greg KH: "Here is the big set of IIO and staging driver patches for 5.14-rc1. Loads of IIO driver updates and additions in here, the shortlog has the full details. For the staging side, we moved a few drivers out of staging, and deleted the kpc2000 drivers as the original developer asked us to because no one was working on them anymore. Also in here are loads of coding style cleanups due to different intern projects focusing on the staging tree to try to get experience doing kernel development. All of these have been in the linux-next tree for a while with no reported problems" * tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (744 commits) staging: hi6421-spmi-pmic: cleanup some macros staging: hi6421-spmi-pmic: change identation of a table staging: hi6421-spmi-pmic: change a return code staging: hi6421-spmi-pmic: better name IRQs staging: hi6421-spmi-pmic: use devm_request_threaded_irq() staging: hisilicon,hi6421-spmi-pmic.yaml: cleanup descriptions spmi: hisi-spmi-controller: move driver from staging phy: phy-hi3670-usb3: move driver from staging into phy staging: rtl8188eu: remove include/rtw_debug.h header staging: rtl8188eu: remove GlobalDebugLevel variable staging: rtl8188eu: remove DRIVER_PREFIX preprocessor definition staging: rtl8188eu: remove RT_TRACE macro staging: rtl8188eu: remove all RT_TRACE calls from hal/rtl8188eu_recv.c staging: rtl8188eu: remove all RT_TRACE calls from hal/hal_intf.c staging: rtl8188eu: remove all RT_TRACE calls from hal/rtl8188eu_xmit.c staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_xmit.c staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_pwrctrl.c staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_recv.c staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_ioctl_set.c staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_ieee80211.c ...
Diffstat (limited to 'Documentation/ABI/obsolete')
-rw-r--r--Documentation/ABI/obsolete/sysfs-bus-iio182
1 files changed, 182 insertions, 0 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-bus-iio b/Documentation/ABI/obsolete/sysfs-bus-iio
new file mode 100644
index 000000000000..c9531bb64816
--- /dev/null
+++ b/Documentation/ABI/obsolete/sysfs-bus-iio
@@ -0,0 +1,182 @@
+What: /sys/bus/iio/devices/iio:deviceX/buffer/length
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Number of scans contained by the buffer.
+
+ Since Kernel 5.11, multiple buffers are supported.
+ so, it is better to use, instead:
+ /sys/bus/iio/devices/iio:deviceX/bufferY/length
+
+What: /sys/bus/iio/devices/iio:deviceX/buffer/enable
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Actually start the buffer capture up. Will start trigger
+ if first device and appropriate.
+
+ Since Kernel 5.11, multiple buffers are supported.
+ so, it is better to use, instead:
+ /sys/bus/iio/devices/iio:deviceX/bufferY/enable
+
+What: /sys/bus/iio/devices/iio:deviceX/scan_elements
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Directory containing interfaces for elements that will be
+ captured for a single triggered sample set in the buffer.
+
+ Since kernel 5.11 the scan_elements attributes are merged into
+ the bufferY directory, to be configurable per buffer.
+
+What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
+What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en
+What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en
+What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
+What: /sys/.../iio:deviceX/scan_elements/in_pressure_en
+What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
+What: /sys/.../iio:deviceX/scan_elements/in_proximity_en
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Scan element control for triggered data capture.
+
+ Since kernel 5.11 the scan_elements attributes are merged into
+ the bufferY directory, to be configurable per buffer.
+
+What: /sys/.../iio:deviceX/scan_elements/in_accel_type
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type
+What: /sys/.../iio:deviceX/scan_elements/in_magn_type
+What: /sys/.../iio:deviceX/scan_elements/in_incli_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type
+What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
+What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
+What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
+What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
+What: /sys/.../iio:deviceX/scan_elements/in_proximity_type
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Description of the scan element data storage within the buffer
+ and hence the form in which it is read from user-space.
+ Form is [be|le]:[s|u]bits/storagebits[>>shift].
+ be or le specifies big or little endian. 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. shift if specified, is the shift that
+ needs to be applied prior to masking out unused bits. Some
+ devices put their data in the middle of the transferred elements
+ with additional information on both sides. 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>>2 will be a
+ signed 48 bit integer stored in a 64 bit location aligned to
+ a 64 bit boundary. To obtain the clean value, shift right 2
+ and apply a mask to zero the top 16 bits of the result.
+ For other storage combinations this attribute will be extended
+ appropriately.
+
+ Since kernel 5.11 the scan_elements attributes are merged into
+ the bufferY directory, to be configurable per buffer.
+
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index
+What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
+What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index
+What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index
+What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
+What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index
+What: /sys/.../iio:deviceX/scan_elements/in_pressure_index
+What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
+What: /sys/.../iio:deviceX/scan_elements/in_proximity_index
+KernelVersion: 2.6.37
+Description:
+ A single positive integer specifying the position of this
+ scan element in the buffer. Note these are not dependent on
+ what is enabled and may not be contiguous. Thus for user-space
+ to establish the full layout these must be used in conjunction
+ with all _en attributes to establish which channels are present,
+ and the relevant _type attributes to establish the data storage
+ format.
+
+ Since kernel 5.11 the scan_elements attributes are merged into
+ the bufferY directory, to be configurable per buffer.
+
+What: /sys/bus/iio/devices/iio:deviceX/buffer/watermark
+KernelVersion: 4.2
+Contact: linux-iio@vger.kernel.org
+Description:
+ A single positive integer specifying the maximum number of scan
+ elements to wait for.
+
+ Poll will block until the watermark is reached.
+
+ Blocking read will wait until the minimum between the requested
+ read amount or the low water mark is available.
+
+ Non-blocking read will retrieve the available samples from the
+ buffer even if there are less samples then watermark level. This
+ allows the application to block on poll with a timeout and read
+ the available samples after the timeout expires and thus have a
+ maximum delay guarantee.
+
+ Since Kernel 5.11, multiple buffers are supported.
+ so, it is better to use, instead:
+ /sys/bus/iio/devices/iio:deviceX/bufferY/watermark
+
+What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available
+KernelVersion: 4.16
+Contact: linux-iio@vger.kernel.org
+Description:
+ A read-only value indicating the bytes of data available in the
+ buffer. In the case of an output buffer, this indicates the
+ amount of empty space available to write data to. In the case of
+ an input buffer, this indicates the amount of data available for
+ reading.
+
+ Since Kernel 5.11, multiple buffers are supported.
+ so, it is better to use, instead:
+ /sys/bus/iio/devices/iio:deviceX/bufferY/data_available