mirror of
https://github.com/a52xq-dev/kernel.git
synced 2026-10-18 21:58:11 +07:00
Merge branch 'drm-next-merged' of git://people.freedesktop.org/~airlied/linux into v4l_for_linus
* 'drm-next-merged' of git://people.freedesktop.org/~airlied/linux: (9717 commits) media-bus: Fixup RGB444_1X12, RGB565_1X16, and YUV8_1X24 media bus format hexdump: avoid warning in test function fs: take i_mutex during prepare_binprm for set[ug]id executables smp: Fix error case handling in smp_call_function_*() iommu-common: Fix PARISC compile-time warnings sparc: Make LDC use common iommu poll management functions sparc: Make sparc64 use scalable lib/iommu-common.c functions Break up monolithic iommu table/lock into finer graularity pools and lock sparc: Revert generic IOMMU allocator. tools/power turbostat: correct dumped pkg-cstate-limit value tools/power turbostat: calculate TSC frequency from CPUID(0x15) on SKL tools/power turbostat: correct DRAM RAPL units on recent Xeon processors tools/power turbostat: Initial Skylake support tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile tools/power turbostat: modprobe msr, if needed tools/power turbostat: dump MSR_TURBO_RATIO_LIMIT2 tools/power turbostat: use new MSR_TURBO_RATIO_LIMIT names Bluetooth: hidp: Fix regression with older userspace and flags validation config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected perf/x86/intel/pt: Fix and clean up error handling in pt_event_add() ... That solves several merge conflicts: Documentation/DocBook/media/v4l/subdev-formats.xml Documentation/devicetree/bindings/vendor-prefixes.txt drivers/staging/media/mn88473/mn88473.c include/linux/kconfig.h include/uapi/linux/media-bus-format.h The ones at subdev-formats.xml and media-bus-format.h are not trivial. That's why we opted to merge from DRM.
This commit is contained in:
Mauro Carvalho Chehab
commit
64131a87f2
7787 changed files with 316308 additions and 156694 deletions
1
.gitignore
vendored
1
.gitignore
vendored
|
|
@ -24,6 +24,7 @@
|
|||
*.order
|
||||
*.elf
|
||||
*.bin
|
||||
*.tar
|
||||
*.gz
|
||||
*.bz2
|
||||
*.lzma
|
||||
|
|
|
|||
1
.mailmap
1
.mailmap
|
|
@ -100,6 +100,7 @@ Rajesh Shah <rajesh.shah@intel.com>
|
|||
Ralf Baechle <ralf@linux-mips.org>
|
||||
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
|
||||
Rémi Denis-Courmont <rdenis@simphalempin.com>
|
||||
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
|
||||
Rudolf Marek <R.Marek@sh.cvut.cz>
|
||||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
|
|
|
|||
21
CREDITS
21
CREDITS
|
|
@ -187,6 +187,10 @@ N: Krishna Balasubramanian
|
|||
E: balasub@cis.ohio-state.edu
|
||||
D: Wrote SYS V IPC (part of standard kernel since 0.99.10)
|
||||
|
||||
N: Chris Ball
|
||||
E: chris@printf.net
|
||||
D: Former maintainer of the MMC/SD/SDIO subsystem.
|
||||
|
||||
N: Dario Ballabio
|
||||
E: ballabio_dario@emc.com
|
||||
E: dario.ballabio@tiscalinet.it
|
||||
|
|
@ -504,6 +508,10 @@ E: paul@paulbristow.net
|
|||
W: http://paulbristow.net/linux/idefloppy.html
|
||||
D: Maintainer of IDE/ATAPI floppy driver
|
||||
|
||||
N: Stefano Brivio
|
||||
E: stefano.brivio@polimi.it
|
||||
D: Broadcom B43 driver
|
||||
|
||||
N: Dominik Brodowski
|
||||
E: linux@brodo.de
|
||||
W: http://www.brodo.de/
|
||||
|
|
@ -3004,6 +3012,19 @@ W: http://www.qsl.net/dl1bke/
|
|||
D: Generic Z8530 driver, AX.25 DAMA slave implementation
|
||||
D: Several AX.25 hacks
|
||||
|
||||
N: Ricardo Ribalda Delgado
|
||||
E: ricardo.ribalda@gmail.com
|
||||
W: http://ribalda.com
|
||||
D: PLX USB338x driver
|
||||
D: PCA9634 driver
|
||||
D: Option GTM671WFS
|
||||
D: Fintek F81216A
|
||||
D: Various kernel hacks
|
||||
S: Qtechnology A/S
|
||||
S: Valby Langgade 142
|
||||
S: 2500 Valby
|
||||
S: Denmark
|
||||
|
||||
N: Francois-Rene Rideau
|
||||
E: fare@tunes.org
|
||||
W: http://www.tunes.org/~fare
|
||||
|
|
|
|||
119
Documentation/ABI/obsolete/sysfs-block-zram
Normal file
119
Documentation/ABI/obsolete/sysfs-block-zram
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
What: /sys/block/zram<id>/num_reads
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The num_reads file is read-only and specifies the number of
|
||||
reads (failed or successful) done on this device.
|
||||
Now accessible via zram<id>/stat node.
|
||||
|
||||
What: /sys/block/zram<id>/num_writes
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The num_writes file is read-only and specifies the number of
|
||||
writes (failed or successful) done on this device.
|
||||
Now accessible via zram<id>/stat node.
|
||||
|
||||
What: /sys/block/zram<id>/invalid_io
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The invalid_io file is read-only and specifies the number of
|
||||
non-page-size-aligned I/O requests issued to this device.
|
||||
Now accessible via zram<id>/io_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/failed_reads
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The failed_reads file is read-only and specifies the number of
|
||||
failed reads happened on this device.
|
||||
Now accessible via zram<id>/io_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/failed_writes
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The failed_writes file is read-only and specifies the number of
|
||||
failed writes happened on this device.
|
||||
Now accessible via zram<id>/io_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/notify_free
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The notify_free file is read-only. Depending on device usage
|
||||
scenario it may account a) the number of pages freed because
|
||||
of swap slot free notifications or b) the number of pages freed
|
||||
because of REQ_DISCARD requests sent by bio. The former ones
|
||||
are sent to a swap block device when a swap slot is freed, which
|
||||
implies that this disk is being used as a swap disk. The latter
|
||||
ones are sent by filesystem mounted with discard option,
|
||||
whenever some data blocks are getting discarded.
|
||||
Now accessible via zram<id>/io_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/zero_pages
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The zero_pages file is read-only and specifies number of zero
|
||||
filled pages written to this disk. No memory is allocated for
|
||||
such pages.
|
||||
Now accessible via zram<id>/mm_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/orig_data_size
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The orig_data_size file is read-only and specifies uncompressed
|
||||
size of data stored in this disk. This excludes zero-filled
|
||||
pages (zero_pages) since no memory is allocated for them.
|
||||
Unit: bytes
|
||||
Now accessible via zram<id>/mm_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/compr_data_size
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The compr_data_size file is read-only and specifies compressed
|
||||
size of data stored in this disk. So, compression ratio can be
|
||||
calculated using orig_data_size and this statistic.
|
||||
Unit: bytes
|
||||
Now accessible via zram<id>/mm_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/mem_used_total
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The mem_used_total file is read-only and specifies the amount
|
||||
of memory, including allocator fragmentation and metadata
|
||||
overhead, allocated for this disk. So, allocator space
|
||||
efficiency can be calculated using compr_data_size and this
|
||||
statistic.
|
||||
Unit: bytes
|
||||
Now accessible via zram<id>/mm_stat node.
|
||||
|
||||
What: /sys/block/zram<id>/mem_used_max
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The mem_used_max file is read/write and specifies the amount
|
||||
of maximum memory zram have consumed to store compressed data.
|
||||
For resetting the value, you should write "0". Otherwise,
|
||||
you could see -EINVAL.
|
||||
Unit: bytes
|
||||
Downgraded to write-only node: so it's possible to set new
|
||||
value only; its current value is stored in zram<id>/mm_stat
|
||||
node.
|
||||
|
||||
What: /sys/block/zram<id>/mem_limit
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The mem_limit file is read/write and specifies the maximum
|
||||
amount of memory ZRAM can use to store the compressed data.
|
||||
The limit could be changed in run time and "0" means disable
|
||||
the limit. No limit is the initial state. Unit: bytes
|
||||
Downgraded to write-only node: so it's possible to set new
|
||||
value only; its current value is stored in zram<id>/mm_stat
|
||||
node.
|
||||
10
Documentation/ABI/stable/sysfs-devices
Normal file
10
Documentation/ABI/stable/sysfs-devices
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# Note: This documents additional properties of any device beyond what
|
||||
# is documented in Documentation/sysfs-rules.txt
|
||||
|
||||
What: /sys/devices/*/of_path
|
||||
Date: February 2015
|
||||
Contact: Device Tree mailing list <devicetree@vger.kernel.org>
|
||||
Description:
|
||||
Any device associated with a device-tree node will have
|
||||
an of_path symlink pointing to the corresponding device
|
||||
node in /sys/firmware/devicetree/
|
||||
9
Documentation/ABI/testing/configfs-usb-gadget-printer
Normal file
9
Documentation/ABI/testing/configfs-usb-gadget-printer
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
What: /config/usb-gadget/gadget/functions/printer.name
|
||||
Date: Apr 2015
|
||||
KernelVersion: 4.1
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
pnp_string - Data to be passed to the host in pnp string
|
||||
q_len - Number of requests per endpoint
|
||||
|
||||
|
|
@ -23,3 +23,25 @@ Description: Device-mapper device suspend state.
|
|||
Contains the value 1 while the device is suspended.
|
||||
Otherwise it contains 0. Read-only attribute.
|
||||
Users: util-linux, device-mapper udev rules
|
||||
|
||||
What: /sys/block/dm-<num>/dm/rq_based_seq_io_merge_deadline
|
||||
Date: March 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Allow control over how long a request that is a
|
||||
reasonable merge candidate can be queued on the request
|
||||
queue. The resolution of this deadline is in
|
||||
microseconds (ranging from 1 to 100000 usecs).
|
||||
Setting this attribute to 0 (the default) will disable
|
||||
request-based DM's merge heuristic and associated extra
|
||||
accounting. This attribute is not applicable to
|
||||
bio-based DM devices so it will only ever report 0 for
|
||||
them.
|
||||
|
||||
What: /sys/block/dm-<num>/dm/use_blk_mq
|
||||
Date: March 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: dm-devel@redhat.com
|
||||
Description: Request-based Device-mapper blk-mq I/O path mode.
|
||||
Contains the value 1 if the device is using blk-mq.
|
||||
Otherwise it contains 0. Read-only attribute.
|
||||
|
|
|
|||
|
|
@ -141,3 +141,28 @@ Description:
|
|||
amount of memory ZRAM can use to store the compressed data. The
|
||||
limit could be changed in run time and "0" means disable the
|
||||
limit. No limit is the initial state. Unit: bytes
|
||||
|
||||
What: /sys/block/zram<id>/compact
|
||||
Date: August 2015
|
||||
Contact: Minchan Kim <minchan@kernel.org>
|
||||
Description:
|
||||
The compact file is write-only and trigger compaction for
|
||||
allocator zrm uses. The allocator moves some objects so that
|
||||
it could free fragment space.
|
||||
|
||||
What: /sys/block/zram<id>/io_stat
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The io_stat file is read-only and accumulates device's I/O
|
||||
statistics not accounted by block layer. For example,
|
||||
failed_reads, failed_writes, etc. File format is similar to
|
||||
block layer statistics file format.
|
||||
|
||||
What: /sys/block/zram<id>/mm_stat
|
||||
Date: August 2015
|
||||
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
|
||||
Description:
|
||||
The mm_stat file is read-only and represents device's mm
|
||||
statistics (orig_data_size, compr_data_size, etc.) in a format
|
||||
similar to block layer statistics file format.
|
||||
|
|
|
|||
|
|
@ -253,6 +253,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_magn_offset
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_rot_offset
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -296,6 +298,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -336,6 +339,7 @@ what /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale
|
|||
what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -347,7 +351,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Gender of the user (e.g.: male, female) used by some pedometers
|
||||
|
|
@ -358,7 +362,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Lists all available gender values (e.g.: male, female).
|
||||
|
|
@ -375,7 +379,7 @@ Description:
|
|||
type.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibweight
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Weight of the user (in kg). It is needed by some pedometers
|
||||
|
|
@ -612,6 +616,8 @@ Description:
|
|||
a given event type is enabled a future point (and not those for
|
||||
whatever event was previously enabled).
|
||||
|
||||
What: /sys/.../events/in_accel_thresh_rising_value
|
||||
What: /sys/.../events/in_accel_thresh_falling_value
|
||||
What: /sys/.../events/in_accel_x_raw_thresh_rising_value
|
||||
What: /sys/.../events/in_accel_x_raw_thresh_falling_value
|
||||
What: /sys/.../events/in_accel_y_raw_thresh_rising_value
|
||||
|
|
@ -661,6 +667,24 @@ Description:
|
|||
value is in raw device units or in processed units (as _raw
|
||||
and _input do on sysfs direct channel read attributes).
|
||||
|
||||
What: /sys/.../events/in_accel_scale
|
||||
What: /sys/.../events/in_accel_peak_scale
|
||||
What: /sys/.../events/in_anglvel_scale
|
||||
What: /sys/.../events/in_magn_scale
|
||||
What: /sys/.../events/in_rot_from_north_magnetic_scale
|
||||
What: /sys/.../events/in_rot_from_north_true_scale
|
||||
What: /sys/.../events/in_voltage_scale
|
||||
What: /sys/.../events/in_voltage_supply_scale
|
||||
What: /sys/.../events/in_temp_scale
|
||||
What: /sys/.../events/in_illuminance_scale
|
||||
What: /sys/.../events/in_proximity_scale
|
||||
KernelVersion: 3.21
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the conversion factor from the standard units
|
||||
to device specific units used to set the event trigger
|
||||
threshold.
|
||||
|
||||
What: /sys/.../events/in_accel_x_thresh_rising_hysteresis
|
||||
What: /sys/.../events/in_accel_x_thresh_falling_hysteresis
|
||||
What: /sys/.../events/in_accel_x_thresh_either_hysteresis
|
||||
|
|
@ -776,7 +800,7 @@ Description:
|
|||
|
||||
What: /sys/.../events/in_accel_x_thresh_rising_period
|
||||
What: /sys/.../events/in_accel_x_thresh_falling_period
|
||||
hat: /sys/.../events/in_accel_x_roc_rising_period
|
||||
What: /sys/.../events/in_accel_x_roc_rising_period
|
||||
What: /sys/.../events/in_accel_x_roc_falling_period
|
||||
What: /sys/.../events/in_accel_y_thresh_rising_period
|
||||
What: /sys/.../events/in_accel_y_thresh_falling_period
|
||||
|
|
@ -923,7 +947,7 @@ Description:
|
|||
this type.
|
||||
|
||||
What: /sys/.../events/in_steps_change_en
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Event generated when channel passes a threshold on the absolute
|
||||
|
|
@ -932,7 +956,7 @@ Description:
|
|||
in_steps_change_value.
|
||||
|
||||
What: /sys/.../events/in_steps_change_value
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the value of change threshold that the
|
||||
|
|
@ -997,6 +1021,7 @@ 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:
|
||||
|
|
@ -1013,6 +1038,7 @@ 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:
|
||||
|
|
@ -1064,6 +1090,7 @@ 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
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -1104,7 +1131,7 @@ Description:
|
|||
|
||||
What: /sys/.../iio:deviceX/in_energy_input
|
||||
What: /sys/.../iio:deviceX/in_energy_raw
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute is used to read the energy value reported by the
|
||||
|
|
@ -1113,7 +1140,7 @@ Description:
|
|||
|
||||
What: /sys/.../iio:deviceX/in_distance_input
|
||||
What: /sys/.../iio:deviceX/in_distance_raw
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute is used to read the distance covered by the user
|
||||
|
|
@ -1143,9 +1170,13 @@ Description:
|
|||
values should behave in the same way as a distance, i.e. lower
|
||||
values indicate something is closer to the sensor.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_illuminance_input
|
||||
What: /sys/.../iio:deviceX/in_illuminance_raw
|
||||
What: /sys/.../iio:deviceX/in_illuminanceY_input
|
||||
What: /sys/.../iio:deviceX/in_illuminanceY_raw
|
||||
What: /sys/.../iio:deviceX/in_illuminanceY_mean_raw
|
||||
What: /sys/.../iio:deviceX/in_illuminance_ir_raw
|
||||
What: /sys/.../iio:deviceX/in_illuminance_clear_raw
|
||||
KernelVersion: 3.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -1174,7 +1205,7 @@ Description:
|
|||
seconds.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_integration_time
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Number of seconds in which to compute speed.
|
||||
|
|
@ -1236,7 +1267,7 @@ Description:
|
|||
Units after application of scale are m/s.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_steps_debounce_count
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the number of steps that must occur within
|
||||
|
|
@ -1244,8 +1275,92 @@ Description:
|
|||
consumer is making steps.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_steps_debounce_time
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies number of seconds in which we compute the steps
|
||||
that occur in order to decide if the consumer is making steps.
|
||||
|
||||
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.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_enabled
|
||||
KernelVersion: 4.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
A read-only boolean value that indicates if the hardware fifo is
|
||||
currently enabled or disabled. If the device does not have a
|
||||
hardware fifo this entry is not present.
|
||||
The hardware fifo is enabled when the buffer is enabled if the
|
||||
current hardware fifo watermark level is set and other current
|
||||
device settings allows it (e.g. if a trigger is set that samples
|
||||
data differently that the hardware fifo does then hardware fifo
|
||||
will not enabled).
|
||||
If the hardware fifo is enabled and the level of the hardware
|
||||
fifo reaches the hardware fifo watermark level the device will
|
||||
flush its hardware fifo to the device buffer. Doing a non
|
||||
blocking read on the device when no samples are present in the
|
||||
device buffer will also force a flush.
|
||||
When the hardware fifo is enabled there is no need to use a
|
||||
trigger to use buffer mode since the watermark settings
|
||||
guarantees that the hardware fifo is flushed to the device
|
||||
buffer.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark
|
||||
KernelVersion: 4.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Read-only entry that contains a single integer specifying the
|
||||
current watermark level for the hardware fifo. If the device
|
||||
does not have a hardware fifo this entry is not present.
|
||||
The watermark level for the hardware fifo is set by the driver
|
||||
based on the value set by the user in buffer/watermark but
|
||||
taking into account hardware limitations (e.g. most hardware
|
||||
buffers are limited to 32-64 samples, some hardware buffers
|
||||
watermarks are fixed or have minimum levels). A value of 0
|
||||
means that the hardware watermark is unset.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_min
|
||||
KernelVersion: 4.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
A single positive integer specifying the minimum watermark level
|
||||
for the hardware fifo of this device. If the device does not
|
||||
have a hardware fifo this entry is not present.
|
||||
If the user sets buffer/watermark to a value less than this one,
|
||||
then the hardware watermark will remain unset.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_max
|
||||
KernelVersion: 4.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
A single positive integer specifying the maximum watermark level
|
||||
for the hardware fifo of this device. If the device does not
|
||||
have a hardware fifo this entry is not present.
|
||||
If the user sets buffer/watermark to a value greater than this
|
||||
one, then the hardware watermark will be capped at this value.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_available
|
||||
KernelVersion: 4.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
A list of positive integers specifying the available watermark
|
||||
levels for the hardware fifo. This entry is optional and if it
|
||||
is not present it means that all the values between
|
||||
hwfifo_watermark_min and hwfifo_watermark_max are supported.
|
||||
If the user sets buffer/watermark to a value greater than
|
||||
hwfifo_watermak_min but not equal to any of the values in this
|
||||
list, the driver will chose an appropriate value for the
|
||||
hardware fifo watermark level.
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Description: read only
|
|||
Hexadecimal value of the device ID found in this AFU
|
||||
configuration record.
|
||||
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/vendor
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/class
|
||||
Date: February 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
|
|
|
|||
80
Documentation/ABI/testing/sysfs-class-led-flash
Normal file
80
Documentation/ABI/testing/sysfs-class-led-flash
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
What: /sys/class/leds/<led>/flash_brightness
|
||||
Date: March 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
|
||||
Description: read/write
|
||||
Set the brightness of this LED in the flash strobe mode, in
|
||||
microamperes. The file is created only for the flash LED devices
|
||||
that support setting flash brightness.
|
||||
|
||||
The value is between 0 and
|
||||
/sys/class/leds/<led>/max_flash_brightness.
|
||||
|
||||
What: /sys/class/leds/<led>/max_flash_brightness
|
||||
Date: March 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
|
||||
Description: read only
|
||||
Maximum brightness level for this LED in the flash strobe mode,
|
||||
in microamperes.
|
||||
|
||||
What: /sys/class/leds/<led>/flash_timeout
|
||||
Date: March 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
|
||||
Description: read/write
|
||||
Hardware timeout for flash, in microseconds. The flash strobe
|
||||
is stopped after this period of time has passed from the start
|
||||
of the strobe. The file is created only for the flash LED
|
||||
devices that support setting flash timeout.
|
||||
|
||||
What: /sys/class/leds/<led>/max_flash_timeout
|
||||
Date: March 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
|
||||
Description: read only
|
||||
Maximum flash timeout for this LED, in microseconds.
|
||||
|
||||
What: /sys/class/leds/<led>/flash_strobe
|
||||
Date: March 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
|
||||
Description: read/write
|
||||
Flash strobe state. When written with 1 it triggers flash strobe
|
||||
and when written with 0 it turns the flash off.
|
||||
|
||||
On read 1 means that flash is currently strobing and 0 means
|
||||
that flash is off.
|
||||
|
||||
What: /sys/class/leds/<led>/flash_fault
|
||||
Date: March 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
|
||||
Description: read only
|
||||
Space separated list of flash faults that may have occurred.
|
||||
Flash faults are re-read after strobing the flash. Possible
|
||||
flash faults:
|
||||
|
||||
* led-over-voltage - flash controller voltage to the flash LED
|
||||
has exceeded the limit specific to the flash controller
|
||||
* flash-timeout-exceeded - the flash strobe was still on when
|
||||
the timeout set by the user has expired; not all flash
|
||||
controllers may set this in all such conditions
|
||||
* controller-over-temperature - the flash controller has
|
||||
overheated
|
||||
* controller-short-circuit - the short circuit protection
|
||||
of the flash controller has been triggered
|
||||
* led-power-supply-over-current - current in the LED power
|
||||
supply has exceeded the limit specific to the flash
|
||||
controller
|
||||
* indicator-led-fault - the flash controller has detected
|
||||
a short or open circuit condition on the indicator LED
|
||||
* led-under-voltage - flash controller voltage to the flash
|
||||
LED has been below the minimum limit specific to
|
||||
the flash
|
||||
* controller-under-voltage - the input voltage of the flash
|
||||
controller is below the limit under which strobing the
|
||||
flash at full current will not be possible;
|
||||
the condition persists until this flag is no longer set
|
||||
* led-over-temperature - the temperature of the LED has exceeded
|
||||
its allowed upper limit
|
||||
|
|
@ -188,6 +188,14 @@ Description:
|
|||
Indicates the interface unique physical port identifier within
|
||||
the NIC, as a string.
|
||||
|
||||
What: /sys/class/net/<iface>/phys_port_name
|
||||
Date: March 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: netdev@vger.kernel.org
|
||||
Description:
|
||||
Indicates the interface physical port name within the NIC,
|
||||
as a string.
|
||||
|
||||
What: /sys/class/net/<iface>/speed
|
||||
Date: October 2009
|
||||
KernelVersion: 2.6.33
|
||||
|
|
|
|||
|
|
@ -24,6 +24,14 @@ Description:
|
|||
Indicates the number of transmit timeout events seen by this
|
||||
network interface transmit queue.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/tx_maxrate
|
||||
Date: March 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: netdev@vger.kernel.org
|
||||
Description:
|
||||
A Mbps max-rate set for the queue, a value of zero means disabled,
|
||||
default is disabled.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/xps_cpus
|
||||
Date: November 2010
|
||||
KernelVersion: 2.6.38
|
||||
|
|
|
|||
|
|
@ -8,3 +8,13 @@ Description: When read, this file returns the device's raw binary HID
|
|||
report descriptor.
|
||||
This file cannot be written.
|
||||
Users: HIDAPI library (http://www.signal11.us/oss/hidapi)
|
||||
|
||||
What: For USB devices : /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
|
||||
For BT devices : /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
|
||||
Symlink : /sys/class/hidraw/hidraw<num>/device/country
|
||||
Date: February 2015
|
||||
KernelVersion: 3.19
|
||||
Contact: Olivier Gay <ogay@logitech.com>
|
||||
Description: When read, this file returns the hex integer value in ASCII
|
||||
of the device's HID country code (e.g. 21 for US).
|
||||
This file cannot be written.
|
||||
|
|
|
|||
|
|
@ -5,3 +5,48 @@ Contact: Michal Malý <madcatxster@gmail.com>
|
|||
Description: Display minimum, maximum and current range of the steering
|
||||
wheel. Writing a value within min and max boundaries sets the
|
||||
range of the wheel.
|
||||
|
||||
What: /sys/bus/hid/drivers/logitech/<dev>/alternate_modes
|
||||
Date: Feb 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: Michal Malý <madcatxster@gmail.com>
|
||||
Description: Displays a set of alternate modes supported by a wheel. Each
|
||||
mode is listed as follows:
|
||||
Tag: Mode Name
|
||||
Currently active mode is marked with an asterisk. List also
|
||||
contains an abstract item "native" which always denotes the
|
||||
native mode of the wheel. Echoing the mode tag switches the
|
||||
wheel into the corresponding mode. Depending on the exact model
|
||||
of the wheel not all listed modes might always be selectable.
|
||||
If a wheel cannot be switched into the desired mode, -EINVAL
|
||||
is returned accompanied with an explanatory message in the
|
||||
kernel log.
|
||||
This entry is not created for devices that have only one mode.
|
||||
|
||||
Currently supported mode switches:
|
||||
Driving Force Pro:
|
||||
DF-EX --> DFP
|
||||
|
||||
G25:
|
||||
DF-EX --> DFP --> G25
|
||||
|
||||
G27:
|
||||
DF-EX <*> DFP <-> G25 <-> G27
|
||||
DF-EX <*--------> G25 <-> G27
|
||||
DF-EX <*----------------> G27
|
||||
|
||||
DFGT:
|
||||
DF-EX <*> DFP <-> DFGT
|
||||
DF-EX <*--------> DFGT
|
||||
|
||||
* hid_logitech module must be loaded with lg4ff_no_autoswitch=1
|
||||
parameter set in order for the switch to DF-EX mode to work.
|
||||
|
||||
What: /sys/bus/hid/drivers/logitech/<dev>/real_id
|
||||
Date: Feb 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: Michal Malý <madcatxster@gmail.com>
|
||||
Description: Displays the real model of the wheel regardless of any
|
||||
alternate mode the wheel might be switched to.
|
||||
It is a read-only value.
|
||||
This entry is not created for devices that have only one mode.
|
||||
|
|
|
|||
27
Documentation/CodeOfConflict
Normal file
27
Documentation/CodeOfConflict
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
Code of Conflict
|
||||
----------------
|
||||
|
||||
The Linux kernel development effort is a very personal process compared
|
||||
to "traditional" ways of developing software. Your code and ideas
|
||||
behind it will be carefully reviewed, often resulting in critique and
|
||||
criticism. The review will almost always require improvements to the
|
||||
code before it can be included in the kernel. Know that this happens
|
||||
because everyone involved wants to see the best possible solution for
|
||||
the overall success of Linux. This development process has been proven
|
||||
to create the most robust operating system kernel ever, and we do not
|
||||
want to do anything to cause the quality of submission and eventual
|
||||
result to ever decrease.
|
||||
|
||||
If however, anyone feels personally abused, threatened, or otherwise
|
||||
uncomfortable due to this process, that is not acceptable. If so,
|
||||
please contact the Linux Foundation's Technical Advisory Board at
|
||||
<tab@lists.linux-foundation.org>, or the individual members, and they
|
||||
will work to resolve the issue to the best of their ability. For more
|
||||
information on who is on the Technical Advisory Board and what their
|
||||
role is, please see:
|
||||
http://www.linuxfoundation.org/programs/advisory-councils/tab
|
||||
|
||||
As a reviewer of code, please strive to keep things civil and focused on
|
||||
the technical issues involved. We are all humans, and frustrations can
|
||||
be high on both sides of the process. Try to keep in mind the immortal
|
||||
words of Bill and Ted, "Be excellent to each other."
|
||||
|
|
@ -13,7 +13,7 @@ and NOT read it. Burn them, it's a great symbolic gesture.
|
|||
Anyway, here goes:
|
||||
|
||||
|
||||
Chapter 1: Indentation
|
||||
Chapter 1: Indentation
|
||||
|
||||
Tabs are 8 characters, and thus indentations are also 8 characters.
|
||||
There are heretic movements that try to make indentations 4 (or even 2!)
|
||||
|
|
@ -56,7 +56,6 @@ instead of "double-indenting" the "case" labels. E.g.:
|
|||
break;
|
||||
}
|
||||
|
||||
|
||||
Don't put multiple statements on a single line unless you have
|
||||
something to hide:
|
||||
|
||||
|
|
@ -156,25 +155,25 @@ comments on.
|
|||
|
||||
Do not unnecessarily use braces where a single statement will do.
|
||||
|
||||
if (condition)
|
||||
action();
|
||||
if (condition)
|
||||
action();
|
||||
|
||||
and
|
||||
|
||||
if (condition)
|
||||
do_this();
|
||||
else
|
||||
do_that();
|
||||
if (condition)
|
||||
do_this();
|
||||
else
|
||||
do_that();
|
||||
|
||||
This does not apply if only one branch of a conditional statement is a single
|
||||
statement; in the latter case use braces in both branches:
|
||||
|
||||
if (condition) {
|
||||
do_this();
|
||||
do_that();
|
||||
} else {
|
||||
otherwise();
|
||||
}
|
||||
if (condition) {
|
||||
do_this();
|
||||
do_that();
|
||||
} else {
|
||||
otherwise();
|
||||
}
|
||||
|
||||
3.1: Spaces
|
||||
|
||||
|
|
@ -186,8 +185,11 @@ although they are not required in the language, as in: "sizeof info" after
|
|||
"struct fileinfo info;" is declared).
|
||||
|
||||
So use a space after these keywords:
|
||||
|
||||
if, switch, case, for, do, while
|
||||
|
||||
but not with sizeof, typeof, alignof, or __attribute__. E.g.,
|
||||
|
||||
s = sizeof(struct file);
|
||||
|
||||
Do not add spaces around (inside) parenthesized expressions. This example is
|
||||
|
|
@ -209,12 +211,15 @@ such as any of these:
|
|||
= + - < > * / % | & ^ <= >= == != ? :
|
||||
|
||||
but no space after unary operators:
|
||||
|
||||
& * + - ~ ! sizeof typeof alignof __attribute__ defined
|
||||
|
||||
no space before the postfix increment & decrement unary operators:
|
||||
|
||||
++ --
|
||||
|
||||
no space after the prefix increment & decrement unary operators:
|
||||
|
||||
++ --
|
||||
|
||||
and no space around the '.' and "->" structure member operators.
|
||||
|
|
@ -268,13 +273,11 @@ See chapter 6 (Functions).
|
|||
Chapter 5: Typedefs
|
||||
|
||||
Please don't use things like "vps_t".
|
||||
|
||||
It's a _mistake_ to use typedef for structures and pointers. When you see a
|
||||
|
||||
vps_t a;
|
||||
|
||||
in the source, what does it mean?
|
||||
|
||||
In contrast, if it says
|
||||
|
||||
struct virtual_container *a;
|
||||
|
|
@ -372,11 +375,11 @@ In source files, separate functions with one blank line. If the function is
|
|||
exported, the EXPORT* macro for it should follow immediately after the closing
|
||||
function brace line. E.g.:
|
||||
|
||||
int system_is_up(void)
|
||||
{
|
||||
return system_state == SYSTEM_RUNNING;
|
||||
}
|
||||
EXPORT_SYMBOL(system_is_up);
|
||||
int system_is_up(void)
|
||||
{
|
||||
return system_state == SYSTEM_RUNNING;
|
||||
}
|
||||
EXPORT_SYMBOL(system_is_up);
|
||||
|
||||
In function prototypes, include parameter names with their data types.
|
||||
Although this is not required by the C language, it is preferred in Linux
|
||||
|
|
@ -405,34 +408,34 @@ The rationale for using gotos is:
|
|||
modifications are prevented
|
||||
- saves the compiler work to optimize redundant code away ;)
|
||||
|
||||
int fun(int a)
|
||||
{
|
||||
int result = 0;
|
||||
char *buffer;
|
||||
int fun(int a)
|
||||
{
|
||||
int result = 0;
|
||||
char *buffer;
|
||||
|
||||
buffer = kmalloc(SIZE, GFP_KERNEL);
|
||||
if (!buffer)
|
||||
return -ENOMEM;
|
||||
buffer = kmalloc(SIZE, GFP_KERNEL);
|
||||
if (!buffer)
|
||||
return -ENOMEM;
|
||||
|
||||
if (condition1) {
|
||||
while (loop1) {
|
||||
...
|
||||
if (condition1) {
|
||||
while (loop1) {
|
||||
...
|
||||
}
|
||||
result = 1;
|
||||
goto out_buffer;
|
||||
}
|
||||
result = 1;
|
||||
goto out_buffer;
|
||||
...
|
||||
out_buffer:
|
||||
kfree(buffer);
|
||||
return result;
|
||||
}
|
||||
...
|
||||
out_buffer:
|
||||
kfree(buffer);
|
||||
return result;
|
||||
}
|
||||
|
||||
A common type of bug to be aware of it "one err bugs" which look like this:
|
||||
|
||||
err:
|
||||
kfree(foo->bar);
|
||||
kfree(foo);
|
||||
return ret;
|
||||
err:
|
||||
kfree(foo->bar);
|
||||
kfree(foo);
|
||||
return ret;
|
||||
|
||||
The bug in this code is that on some exit paths "foo" is NULL. Normally the
|
||||
fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
|
||||
|
|
@ -503,9 +506,9 @@ values. To do the latter, you can stick the following in your .emacs file:
|
|||
(defun c-lineup-arglist-tabs-only (ignored)
|
||||
"Line up argument lists by tabs, not spaces"
|
||||
(let* ((anchor (c-langelem-pos c-syntactic-element))
|
||||
(column (c-langelem-2nd-pos c-syntactic-element))
|
||||
(offset (- (1+ column) anchor))
|
||||
(steps (floor offset c-basic-offset)))
|
||||
(column (c-langelem-2nd-pos c-syntactic-element))
|
||||
(offset (- (1+ column) anchor))
|
||||
(steps (floor offset c-basic-offset)))
|
||||
(* (max steps 1)
|
||||
c-basic-offset)))
|
||||
|
||||
|
|
@ -612,7 +615,7 @@ have a reference count on it, you almost certainly have a bug.
|
|||
|
||||
Names of macros defining constants and labels in enums are capitalized.
|
||||
|
||||
#define CONSTANT 0x12345
|
||||
#define CONSTANT 0x12345
|
||||
|
||||
Enums are preferred when defining several related constants.
|
||||
|
||||
|
|
@ -623,28 +626,28 @@ Generally, inline functions are preferable to macros resembling functions.
|
|||
|
||||
Macros with multiple statements should be enclosed in a do - while block:
|
||||
|
||||
#define macrofun(a, b, c) \
|
||||
do { \
|
||||
if (a == 5) \
|
||||
do_this(b, c); \
|
||||
} while (0)
|
||||
#define macrofun(a, b, c) \
|
||||
do { \
|
||||
if (a == 5) \
|
||||
do_this(b, c); \
|
||||
} while (0)
|
||||
|
||||
Things to avoid when using macros:
|
||||
|
||||
1) macros that affect control flow:
|
||||
|
||||
#define FOO(x) \
|
||||
do { \
|
||||
if (blah(x) < 0) \
|
||||
return -EBUGGERED; \
|
||||
} while(0)
|
||||
#define FOO(x) \
|
||||
do { \
|
||||
if (blah(x) < 0) \
|
||||
return -EBUGGERED; \
|
||||
} while(0)
|
||||
|
||||
is a _very_ bad idea. It looks like a function call but exits the "calling"
|
||||
function; don't break the internal parsers of those who will read the code.
|
||||
|
||||
2) macros that depend on having a local variable with a magic name:
|
||||
|
||||
#define FOO(val) bar(index, val)
|
||||
#define FOO(val) bar(index, val)
|
||||
|
||||
might look like a good thing, but it's confusing as hell when one reads the
|
||||
code and it's prone to breakage from seemingly innocent changes.
|
||||
|
|
@ -656,8 +659,21 @@ bite you if somebody e.g. turns FOO into an inline function.
|
|||
must enclose the expression in parentheses. Beware of similar issues with
|
||||
macros using parameters.
|
||||
|
||||
#define CONSTANT 0x4000
|
||||
#define CONSTEXP (CONSTANT | 3)
|
||||
#define CONSTANT 0x4000
|
||||
#define CONSTEXP (CONSTANT | 3)
|
||||
|
||||
5) namespace collisions when defining local variables in macros resembling
|
||||
functions:
|
||||
|
||||
#define FOO(x) \
|
||||
({ \
|
||||
typeof(x) ret; \
|
||||
ret = calc_ret(x); \
|
||||
(ret); \
|
||||
)}
|
||||
|
||||
ret is a common name for a local variable - __foo_ret is less likely
|
||||
to collide with an existing variable.
|
||||
|
||||
The cpp manual deals with macros exhaustively. The gcc internals manual also
|
||||
covers RTL which is used frequently with assembly language in the kernel.
|
||||
|
|
@ -796,11 +812,11 @@ you should use, rather than explicitly coding some variant of them yourself.
|
|||
For example, if you need to calculate the length of an array, take advantage
|
||||
of the macro
|
||||
|
||||
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
|
||||
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
|
||||
|
||||
Similarly, if you need to calculate the size of some structure member, use
|
||||
|
||||
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
|
||||
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
|
||||
|
||||
There are also min() and max() macros that do strict type checking if you
|
||||
need them. Feel free to peruse that header file to see what else is already
|
||||
|
|
@ -813,19 +829,19 @@ Some editors can interpret configuration information embedded in source files,
|
|||
indicated with special markers. For example, emacs interprets lines marked
|
||||
like this:
|
||||
|
||||
-*- mode: c -*-
|
||||
-*- mode: c -*-
|
||||
|
||||
Or like this:
|
||||
|
||||
/*
|
||||
Local Variables:
|
||||
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
|
||||
End:
|
||||
*/
|
||||
/*
|
||||
Local Variables:
|
||||
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
|
||||
End:
|
||||
*/
|
||||
|
||||
Vim interprets markers that look like this:
|
||||
|
||||
/* vim:set sw=8 noet */
|
||||
/* vim:set sw=8 noet */
|
||||
|
||||
Do not include any of these in source files. People have their own personal
|
||||
editor configurations, and your source files should not override them. This
|
||||
|
|
@ -902,9 +918,9 @@ At the end of any non-trivial #if or #ifdef block (more than a few lines),
|
|||
place a comment after the #endif on the same line, noting the conditional
|
||||
expression used. For instance:
|
||||
|
||||
#ifdef CONFIG_SOMETHING
|
||||
...
|
||||
#endif /* CONFIG_SOMETHING */
|
||||
#ifdef CONFIG_SOMETHING
|
||||
...
|
||||
#endif /* CONFIG_SOMETHING */
|
||||
|
||||
|
||||
Appendix I: References
|
||||
|
|
|
|||
|
|
@ -509,6 +509,270 @@
|
|||
select it due to the used type and mask field.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Internal Structure of Kernel Crypto API</title>
|
||||
|
||||
<para>
|
||||
The kernel crypto API has an internal structure where a cipher
|
||||
implementation may use many layers and indirections. This section
|
||||
shall help to clarify how the kernel crypto API uses
|
||||
various components to implement the complete cipher.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following subsections explain the internal structure based
|
||||
on existing cipher implementations. The first section addresses
|
||||
the most complex scenario where all other scenarios form a logical
|
||||
subset.
|
||||
</para>
|
||||
|
||||
<sect2><title>Generic AEAD Cipher Structure</title>
|
||||
|
||||
<para>
|
||||
The following ASCII art decomposes the kernel crypto API layers
|
||||
when using the AEAD cipher with the automated IV generation. The
|
||||
shown example is used by the IPSEC layer.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For other use cases of AEAD ciphers, the ASCII art applies as
|
||||
well, but the caller may not use the GIVCIPHER interface. In
|
||||
this case, the caller must generate the IV.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The depicted example decomposes the AEAD cipher of GCM(AES) based
|
||||
on the generic C implementations (gcm.c, aes-generic.c, ctr.c,
|
||||
ghash-generic.c, seqiv.c). The generic implementation serves as an
|
||||
example showing the complete logic of the kernel crypto API.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is possible that some streamlined cipher implementations (like
|
||||
AES-NI) provide implementations merging aspects which in the view
|
||||
of the kernel crypto API cannot be decomposed into layers any more.
|
||||
In case of the AES-NI implementation, the CTR mode, the GHASH
|
||||
implementation and the AES cipher are all merged into one cipher
|
||||
implementation registered with the kernel crypto API. In this case,
|
||||
the concept described by the following ASCII art applies too. However,
|
||||
the decomposition of GCM into the individual sub-components
|
||||
by the kernel crypto API is not done any more.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Each block in the following ASCII art is an independent cipher
|
||||
instance obtained from the kernel crypto API. Each block
|
||||
is accessed by the caller or by other blocks using the API functions
|
||||
defined by the kernel crypto API for the cipher implementation type.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The blocks below indicate the cipher type as well as the specific
|
||||
logic implemented in the cipher.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The ASCII art picture also indicates the call structure, i.e. who
|
||||
calls which component. The arrows point to the invoked block
|
||||
where the caller uses the API applicable to the cipher type
|
||||
specified for the block.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
kernel crypto API | IPSEC Layer
|
||||
|
|
||||
+-----------+ |
|
||||
| | (1)
|
||||
| givcipher | <----------------------------------- esp_output
|
||||
| (seqiv) | ---+
|
||||
+-----------+ |
|
||||
| (2)
|
||||
+-----------+ |
|
||||
| | <--+ (2)
|
||||
| aead | <----------------------------------- esp_input
|
||||
| (gcm) | ------------+
|
||||
+-----------+ |
|
||||
| (3) | (5)
|
||||
v v
|
||||
+-----------+ +-----------+
|
||||
| | | |
|
||||
| ablkcipher| | ahash |
|
||||
| (ctr) | ---+ | (ghash) |
|
||||
+-----------+ | +-----------+
|
||||
|
|
||||
+-----------+ | (4)
|
||||
| | <--+
|
||||
| cipher |
|
||||
| (aes) |
|
||||
+-----------+
|
||||
]]>
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The following call sequence is applicable when the IPSEC layer
|
||||
triggers an encryption operation with the esp_output function. During
|
||||
configuration, the administrator set up the use of rfc4106(gcm(aes)) as
|
||||
the cipher for ESP. The following call sequence is now depicted in the
|
||||
ASCII art above:
|
||||
</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
esp_output() invokes crypto_aead_givencrypt() to trigger an encryption
|
||||
operation of the GIVCIPHER implementation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In case of GCM, the SEQIV implementation is registered as GIVCIPHER
|
||||
in crypto_rfc4106_alloc().
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The SEQIV performs its operation to generate an IV where the core
|
||||
function is seqiv_geniv().
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Now, SEQIV uses the AEAD API function calls to invoke the associated
|
||||
AEAD cipher. In our case, during the instantiation of SEQIV, the
|
||||
cipher handle for GCM is provided to SEQIV. This means that SEQIV
|
||||
invokes AEAD cipher operations with the GCM cipher handle.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
During instantiation of the GCM handle, the CTR(AES) and GHASH
|
||||
ciphers are instantiated. The cipher handles for CTR(AES) and GHASH
|
||||
are retained for later use.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The GCM implementation is responsible to invoke the CTR mode AES and
|
||||
the GHASH cipher in the right manner to implement the GCM
|
||||
specification.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API
|
||||
with the instantiated CTR(AES) cipher handle.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
During instantiation of the CTR(AES) cipher, the CIPHER type
|
||||
implementation of AES is instantiated. The cipher handle for AES is
|
||||
retained.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
That means that the ABLKCIPHER implementation of CTR(AES) only
|
||||
implements the CTR block chaining mode. After performing the block
|
||||
chaining operation, the CIPHER implementation of AES is invoked.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
|
||||
cipher handle to encrypt one block.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The GCM AEAD implementation also invokes the GHASH cipher
|
||||
implementation via the AHASH API.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>
|
||||
When the IPSEC layer triggers the esp_input() function, the same call
|
||||
sequence is followed with the only difference that the operation starts
|
||||
with step (2).
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Generic Block Cipher Structure</title>
|
||||
<para>
|
||||
Generic block ciphers follow the same concept as depicted with the ASCII
|
||||
art picture above.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
|
||||
ASCII art picture above applies as well with the difference that only
|
||||
step (4) is used and the ABLKCIPHER block chaining mode is CBC.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Generic Keyed Message Digest Structure</title>
|
||||
<para>
|
||||
Keyed message digest implementations again follow the same concept as
|
||||
depicted in the ASCII art picture above.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example, HMAC(SHA256) is implemented with hmac.c and
|
||||
sha256_generic.c. The following ASCII art illustrates the
|
||||
implementation:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
kernel crypto API | Caller
|
||||
|
|
||||
+-----------+ (1) |
|
||||
| | <------------------ some_function
|
||||
| ahash |
|
||||
| (hmac) | ---+
|
||||
+-----------+ |
|
||||
| (2)
|
||||
+-----------+ |
|
||||
| | <--+
|
||||
| shash |
|
||||
| (sha256) |
|
||||
+-----------+
|
||||
]]>
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The following call sequence is applicable when a caller triggers
|
||||
an HMAC operation:
|
||||
</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The AHASH API functions are invoked by the caller. The HMAC
|
||||
implementation performs its operation as needed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
During initialization of the HMAC cipher, the SHASH cipher type of
|
||||
SHA256 is instantiated. The cipher handle for the SHA256 instance is
|
||||
retained.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
At one time, the HMAC implementation requires a SHA256 operation
|
||||
where the SHA256 cipher handle is used.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The HMAC instance now invokes the SHASH API with the SHA256
|
||||
cipher handle to calculate the message digest.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="Development"><title>Developing Cipher Algorithms</title>
|
||||
|
|
@ -808,6 +1072,602 @@
|
|||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="User"><title>User Space Interface</title>
|
||||
<sect1><title>Introduction</title>
|
||||
<para>
|
||||
The concepts of the kernel crypto API visible to kernel space is fully
|
||||
applicable to the user space interface as well. Therefore, the kernel
|
||||
crypto API high level discussion for the in-kernel use cases applies
|
||||
here as well.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The major difference, however, is that user space can only act as a
|
||||
consumer and never as a provider of a transformation or cipher algorithm.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following covers the user space interface exported by the kernel
|
||||
crypto API. A working example of this description is libkcapi that
|
||||
can be obtained from [1]. That library can be used by user space
|
||||
applications that require cryptographic services from the kernel.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some details of the in-kernel kernel crypto API aspects do not
|
||||
apply to user space, however. This includes the difference between
|
||||
synchronous and asynchronous invocations. The user space API call
|
||||
is fully synchronous.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1><title>User Space API General Remarks</title>
|
||||
<para>
|
||||
The kernel crypto API is accessible from user space. Currently,
|
||||
the following ciphers are accessible:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Message digest including keyed message digest (HMAC, CMAC)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Symmetric ciphers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>AEAD ciphers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Random Number Generators</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The interface is provided via socket type using the type AF_ALG.
|
||||
In addition, the setsockopt option type is SOL_ALG. In case the
|
||||
user space header files do not export these flags yet, use the
|
||||
following macros:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
#ifndef AF_ALG
|
||||
#define AF_ALG 38
|
||||
#endif
|
||||
#ifndef SOL_ALG
|
||||
#define SOL_ALG 279
|
||||
#endif
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
A cipher is accessed with the same name as done for the in-kernel
|
||||
API calls. This includes the generic vs. unique naming schema for
|
||||
ciphers as well as the enforcement of priorities for generic names.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To interact with the kernel crypto API, a socket must be
|
||||
created by the user space application. User space invokes the cipher
|
||||
operation with the send()/write() system call family. The result of the
|
||||
cipher operation is obtained with the read()/recv() system call family.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following API calls assume that the socket descriptor
|
||||
is already opened by the user space application and discusses only
|
||||
the kernel crypto API specific invocations.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To initialize the socket interface, the following sequence has to
|
||||
be performed by the consumer:
|
||||
</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Create a socket of type AF_ALG with the struct sockaddr_alg
|
||||
parameter specified below for the different cipher types.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Invoke bind with the socket descriptor
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Invoke accept with the socket descriptor. The accept system call
|
||||
returns a new file descriptor that is to be used to interact with
|
||||
the particular cipher instance. When invoking send/write or recv/read
|
||||
system calls to send data to the kernel or obtain data from the
|
||||
kernel, the file descriptor returned by accept must be used.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>In-place Cipher operation</title>
|
||||
<para>
|
||||
Just like the in-kernel operation of the kernel crypto API, the user
|
||||
space interface allows the cipher operation in-place. That means that
|
||||
the input buffer used for the send/write system call and the output
|
||||
buffer used by the read/recv system call may be one and the same.
|
||||
This is of particular interest for symmetric cipher operations where a
|
||||
copying of the output data to its final destination can be avoided.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If a consumer on the other hand wants to maintain the plaintext and
|
||||
the ciphertext in different memory locations, all a consumer needs
|
||||
to do is to provide different memory pointers for the encryption and
|
||||
decryption operation.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Message Digest API</title>
|
||||
<para>
|
||||
The message digest type to be used for the cipher operation is
|
||||
selected when invoking the bind syscall. bind requires the caller
|
||||
to provide a filled struct sockaddr data structure. This data
|
||||
structure must be filled as follows:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "hash", /* this selects the hash logic in the kernel */
|
||||
.salg_name = "sha1" /* this is the cipher name */
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The salg_type value "hash" applies to message digests and keyed
|
||||
message digests. Though, a keyed message digest is referenced by
|
||||
the appropriate salg_name. Please see below for the setsockopt
|
||||
interface that explains how the key can be set for a keyed message
|
||||
digest.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Using the send() system call, the application provides the data that
|
||||
should be processed with the message digest. The send system call
|
||||
allows the following flags to be specified:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
MSG_MORE: If this flag is set, the send system call acts like a
|
||||
message digest update function where the final hash is not
|
||||
yet calculated. If the flag is not set, the send system call
|
||||
calculates the final message digest immediately.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
With the recv() system call, the application can read the message
|
||||
digest from the kernel crypto API. If the buffer is too small for the
|
||||
message digest, the flag MSG_TRUNC is set by the kernel.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In order to set a message digest key, the calling application must use
|
||||
the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
|
||||
operation is performed without the initial HMAC state change caused by
|
||||
the key.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Symmetric Cipher API</title>
|
||||
<para>
|
||||
The operation is very similar to the message digest discussion.
|
||||
During initialization, the struct sockaddr data structure must be
|
||||
filled as follows:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "skcipher", /* this selects the symmetric cipher */
|
||||
.salg_name = "cbc(aes)" /* this is the cipher name */
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Before data can be sent to the kernel using the write/send system
|
||||
call family, the consumer must set the key. The key setting is
|
||||
described with the setsockopt invocation below.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
|
||||
specified with the data structure provided by the sendmsg() system call.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The sendmsg system call parameter of struct msghdr is embedded into the
|
||||
struct cmsghdr data structure. See recv(2) and cmsg(3) for more
|
||||
information on how the cmsghdr data structure is used together with the
|
||||
send/recv system call family. That cmsghdr data structure holds the
|
||||
following information specified with a separate header instances:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
specification of the cipher operation type with one of these flags:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>ALG_OP_ENCRYPT - encryption of data</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>ALG_OP_DECRYPT - decryption of data</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
specification of the IV information marked with the flag ALG_SET_IV
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The send system call family allows the following flag to be specified:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
MSG_MORE: If this flag is set, the send system call acts like a
|
||||
cipher update function where more input data is expected
|
||||
with a subsequent invocation of the send system call.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Note: The kernel reports -EINVAL for any unexpected data. The caller
|
||||
must make sure that all data matches the constraints given in
|
||||
/proc/crypto for the selected cipher.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
With the recv() system call, the application can read the result of
|
||||
the cipher operation from the kernel crypto API. The output buffer
|
||||
must be at least as large as to hold all blocks of the encrypted or
|
||||
decrypted data. If the output data size is smaller, only as many
|
||||
blocks are returned that fit into that output buffer size.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>AEAD Cipher API</title>
|
||||
<para>
|
||||
The operation is very similar to the symmetric cipher discussion.
|
||||
During initialization, the struct sockaddr data structure must be
|
||||
filled as follows:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "aead", /* this selects the symmetric cipher */
|
||||
.salg_name = "gcm(aes)" /* this is the cipher name */
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Before data can be sent to the kernel using the write/send system
|
||||
call family, the consumer must set the key. The key setting is
|
||||
described with the setsockopt invocation below.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In addition, before data can be sent to the kernel using the
|
||||
write/send system call family, the consumer must set the authentication
|
||||
tag size. To set the authentication tag size, the caller must use the
|
||||
setsockopt invocation described below.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
|
||||
specified with the data structure provided by the sendmsg() system call.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The sendmsg system call parameter of struct msghdr is embedded into the
|
||||
struct cmsghdr data structure. See recv(2) and cmsg(3) for more
|
||||
information on how the cmsghdr data structure is used together with the
|
||||
send/recv system call family. That cmsghdr data structure holds the
|
||||
following information specified with a separate header instances:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
specification of the cipher operation type with one of these flags:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>ALG_OP_ENCRYPT - encryption of data</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>ALG_OP_DECRYPT - decryption of data</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
specification of the IV information marked with the flag ALG_SET_IV
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
specification of the associated authentication data (AAD) with the
|
||||
flag ALG_SET_AEAD_ASSOCLEN. The AAD is sent to the kernel together
|
||||
with the plaintext / ciphertext. See below for the memory structure.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The send system call family allows the following flag to be specified:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
MSG_MORE: If this flag is set, the send system call acts like a
|
||||
cipher update function where more input data is expected
|
||||
with a subsequent invocation of the send system call.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Note: The kernel reports -EINVAL for any unexpected data. The caller
|
||||
must make sure that all data matches the constraints given in
|
||||
/proc/crypto for the selected cipher.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
With the recv() system call, the application can read the result of
|
||||
the cipher operation from the kernel crypto API. The output buffer
|
||||
must be at least as large as defined with the memory structure below.
|
||||
If the output data size is smaller, the cipher operation is not performed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The authenticated decryption operation may indicate an integrity error.
|
||||
Such breach in integrity is marked with the -EBADMSG error code.
|
||||
</para>
|
||||
|
||||
<sect2><title>AEAD Memory Structure</title>
|
||||
<para>
|
||||
The AEAD cipher operates with the following information that
|
||||
is communicated between user and kernel space as one data stream:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>plaintext or ciphertext</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>associated authentication data (AAD)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>authentication tag</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The sizes of the AAD and the authentication tag are provided with
|
||||
the sendmsg and setsockopt calls (see there). As the kernel knows
|
||||
the size of the entire data stream, the kernel is now able to
|
||||
calculate the right offsets of the data components in the data
|
||||
stream.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The user space caller must arrange the aforementioned information
|
||||
in the following order:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
AEAD encryption input: AAD || plaintext
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
AEAD decryption input: AAD || ciphertext || authentication tag
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The output buffer the user space caller provides must be at least as
|
||||
large to hold the following data:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
AEAD encryption output: ciphertext || authentication tag
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
AEAD decryption output: plaintext
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Random Number Generator API</title>
|
||||
<para>
|
||||
Again, the operation is very similar to the other APIs.
|
||||
During initialization, the struct sockaddr data structure must be
|
||||
filled as follows:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
struct sockaddr_alg sa = {
|
||||
.salg_family = AF_ALG,
|
||||
.salg_type = "rng", /* this selects the symmetric cipher */
|
||||
.salg_name = "drbg_nopr_sha256" /* this is the cipher name */
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Depending on the RNG type, the RNG must be seeded. The seed is provided
|
||||
using the setsockopt interface to set the key. For example, the
|
||||
ansi_cprng requires a seed. The DRBGs do not require a seed, but
|
||||
may be seeded.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Using the read()/recvmsg() system calls, random numbers can be obtained.
|
||||
The kernel generates at most 128 bytes in one call. If user space
|
||||
requires more data, multiple calls to read()/recvmsg() must be made.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
WARNING: The user space caller may invoke the initially mentioned
|
||||
accept system call multiple times. In this case, the returned file
|
||||
descriptors have the same state.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Zero-Copy Interface</title>
|
||||
<para>
|
||||
In addition to the send/write/read/recv system call familty, the AF_ALG
|
||||
interface can be accessed with the zero-copy interface of splice/vmsplice.
|
||||
As the name indicates, the kernel tries to avoid a copy operation into
|
||||
kernel space.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The zero-copy operation requires data to be aligned at the page boundary.
|
||||
Non-aligned data can be used as well, but may require more operations of
|
||||
the kernel which would defeat the speed gains obtained from the zero-copy
|
||||
interface.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The system-interent limit for the size of one zero-copy operation is
|
||||
16 pages. If more data is to be sent to AF_ALG, user space must slice
|
||||
the input into segments with a maximum size of 16 pages.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Zero-copy can be used with the following code example (a complete working
|
||||
example is provided with libkcapi):
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
int pipes[2];
|
||||
|
||||
pipe(pipes);
|
||||
/* input data in iov */
|
||||
vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
|
||||
/* opfd is the file descriptor returned from accept() system call */
|
||||
splice(pipes[0], NULL, opfd, NULL, ret, 0);
|
||||
read(opfd, out, outlen);
|
||||
</programlisting>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Setsockopt Interface</title>
|
||||
<para>
|
||||
In addition to the read/recv and send/write system call handling
|
||||
to send and retrieve data subject to the cipher operation, a consumer
|
||||
also needs to set the additional information for the cipher operation.
|
||||
This additional information is set using the setsockopt system call
|
||||
that must be invoked with the file descriptor of the open cipher
|
||||
(i.e. the file descriptor returned by the accept system call).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Each setsockopt invocation must use the level SOL_ALG.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The setsockopt interface allows setting the following data using
|
||||
the mentioned optname:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
ALG_SET_KEY -- Setting the key. Key setting is applicable to:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>the skcipher cipher type (symmetric ciphers)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>the hash cipher type (keyed message digests)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>the AEAD cipher type</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>the RNG cipher type to provide the seed</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size
|
||||
for AEAD ciphers. For a encryption operation, the authentication
|
||||
tag of the given size will be generated. For a decryption operation,
|
||||
the provided ciphertext is assumed to contain an authentication tag
|
||||
of the given size (see section about AEAD memory layout below).
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1><title>User space API example</title>
|
||||
<para>
|
||||
Please see [1] for libkcapi which provides an easy-to-use wrapper
|
||||
around the aforementioned Netlink kernel interface. [1] also contains
|
||||
a test application that invokes all libkcapi API calls.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="API"><title>Programming Interface</title>
|
||||
<sect1><title>Block Cipher Context Data Structures</title>
|
||||
!Pinclude/linux/crypto.h Block Cipher Context Data Structures
|
||||
|
|
|
|||
|
|
@ -1293,7 +1293,7 @@ int max_width, max_height;</synopsis>
|
|||
</para>
|
||||
<para>
|
||||
If a page flip can be successfully scheduled the driver must set the
|
||||
<code>drm_crtc-<fb</code> field to the new framebuffer pointed to
|
||||
<code>drm_crtc->fb</code> field to the new framebuffer pointed to
|
||||
by <code>fb</code>. This is important so that the reference counting
|
||||
on framebuffers stays balanced.
|
||||
</para>
|
||||
|
|
@ -3979,6 +3979,11 @@ int num_ioctls;</synopsis>
|
|||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Intel GVT-g Guest Support(vGPU)</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_vgpu.c Intel GVT-g guest support
|
||||
!Idrivers/gpu/drm/i915/i915_vgpu.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Display Hardware Handling</title>
|
||||
|
|
@ -4046,6 +4051,17 @@ int num_ioctls;</synopsis>
|
|||
<title>Frame Buffer Compression (FBC)</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC)
|
||||
!Idrivers/gpu/drm/i915/intel_fbc.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Display Refresh Rate Switching (DRRS)</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_dp.c Display Refresh Rate Switching (DRRS)
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_set_drrs_state
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_enable
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_disable
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_invalidate
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_flush
|
||||
!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_drrs_init
|
||||
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>DPIO</title>
|
||||
|
|
@ -4168,7 +4184,7 @@ int num_ioctls;</synopsis>
|
|||
<sect2>
|
||||
<title>Buffer Object Eviction</title>
|
||||
<para>
|
||||
This section documents the interface function for evicting buffer
|
||||
This section documents the interface functions for evicting buffer
|
||||
objects to make space available in the virtual gpu address spaces.
|
||||
Note that this is mostly orthogonal to shrinking buffer objects
|
||||
caches, which has the goal to make main memory (shared with the gpu
|
||||
|
|
@ -4176,6 +4192,17 @@ int num_ioctls;</synopsis>
|
|||
</para>
|
||||
!Idrivers/gpu/drm/i915/i915_gem_evict.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Buffer Object Memory Shrinking</title>
|
||||
<para>
|
||||
This section documents the interface function for shrinking memory
|
||||
usage of buffer object caches. Shrinking is used to make main memory
|
||||
available. Note that this is mostly orthogonal to evicting buffer
|
||||
objects, which has the goal to make space in gpu virtual address
|
||||
spaces.
|
||||
</para>
|
||||
!Idrivers/gpu/drm/i915/i915_gem_shrinker.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
|
|
|
|||
|
|
@ -91,7 +91,9 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<listitem><para>For formats where the total number of bits per pixel is smaller
|
||||
than the number of bus samples per pixel times the bus width, a padding
|
||||
value stating if the bytes are padded in their most high order bits
|
||||
(PADHI) or low order bits (PADLO).</para></listitem>
|
||||
(PADHI) or low order bits (PADLO). A "C" prefix is used for component-wise
|
||||
padding in the most high order bits (CPADHI) or low order bits (CPADLO)
|
||||
of each separate component.</para></listitem>
|
||||
<listitem><para>For formats where the number of bus samples per pixel is larger
|
||||
than 1, an endianness value stating if the pixel is transferred MSB first
|
||||
(BE) or LSB first (LE).</para></listitem>
|
||||
|
|
@ -192,6 +194,24 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
</row>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<row id="MEDIA-BUS-FMT-RGB444-1X12">
|
||||
<entry>MEDIA_BUS_FMT_RGB444_1X12</entry>
|
||||
<entry>0x1016</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE">
|
||||
<entry>MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE</entry>
|
||||
<entry>0x1001</entry>
|
||||
|
|
@ -304,6 +324,28 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB565-1X16">
|
||||
<entry>MEDIA_BUS_FMT_RGB565_1X16</entry>
|
||||
<entry>0x1017</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-16;
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-BGR565-2X8-BE">
|
||||
<entry>MEDIA_BUS_FMT_BGR565_2X8_BE</entry>
|
||||
<entry>0x1005</entry>
|
||||
|
|
@ -470,6 +512,96 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB666-1X24_CPADHI">
|
||||
<entry>MEDIA_BUS_FMT_RGB666_1X24_CPADHI</entry>
|
||||
<entry>0x1015</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-8;
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-BGR888-1X24">
|
||||
<entry>MEDIA_BUS_FMT_BGR888_1X24</entry>
|
||||
<entry>0x1013</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-8;
|
||||
<entry>b<subscript>7</subscript></entry>
|
||||
<entry>b<subscript>6</subscript></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>7</subscript></entry>
|
||||
<entry>g<subscript>6</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>7</subscript></entry>
|
||||
<entry>r<subscript>6</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-GBR888-1X24">
|
||||
<entry>MEDIA_BUS_FMT_GBR888_1X24</entry>
|
||||
<entry>0x1014</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-8;
|
||||
<entry>g<subscript>7</subscript></entry>
|
||||
<entry>g<subscript>6</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>b<subscript>7</subscript></entry>
|
||||
<entry>b<subscript>6</subscript></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>7</subscript></entry>
|
||||
<entry>r<subscript>6</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB888-1X24">
|
||||
<entry>MEDIA_BUS_FMT_RGB888_1X24</entry>
|
||||
<entry>0x100a</entry>
|
||||
|
|
@ -649,6 +781,261 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>On LVDS buses, usually each sample is transferred serialized in
|
||||
seven time slots per pixel clock, on three (18-bit) or four (24-bit)
|
||||
differential data pairs at the same time. The remaining bits are used for
|
||||
control signals as defined by SPWG/PSWG/VESA or JEIDA standards.
|
||||
The 24-bit RGB format serialized in seven time slots on four lanes using
|
||||
JEIDA defined bit mapping will be named
|
||||
<constant>MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA</constant>, for example.
|
||||
</para>
|
||||
|
||||
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb-lvds">
|
||||
<title>LVDS RGB formats</title>
|
||||
<tgroup cols="8">
|
||||
<colspec colname="id" align="left" />
|
||||
<colspec colname="code" align="center" />
|
||||
<colspec colname="slot" align="center" />
|
||||
<colspec colname="lane" />
|
||||
<colspec colnum="5" colname="l03" align="center" />
|
||||
<colspec colnum="6" colname="l02" align="center" />
|
||||
<colspec colnum="7" colname="l01" align="center" />
|
||||
<colspec colnum="8" colname="l00" align="center" />
|
||||
<spanspec namest="l03" nameend="l00" spanname="l0" />
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Identifier</entry>
|
||||
<entry>Code</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry spanname="l0">Data organization</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Timeslot</entry>
|
||||
<entry>Lane</entry>
|
||||
<entry>3</entry>
|
||||
<entry>2</entry>
|
||||
<entry>1</entry>
|
||||
<entry>0</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<row id="MEDIA-BUS-FMT-RGB666-1X7X3-SPWG">
|
||||
<entry>MEDIA_BUS_FMT_RGB666_1X7X3_SPWG</entry>
|
||||
<entry>0x1010</entry>
|
||||
<entry>0</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>d</entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>1</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>d</entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>2</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>d</entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>3</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>4</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>5</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>6</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB888-1X7X4-SPWG">
|
||||
<entry>MEDIA_BUS_FMT_RGB888_1X7X4_SPWG</entry>
|
||||
<entry>0x1011</entry>
|
||||
<entry>0</entry>
|
||||
<entry></entry>
|
||||
<entry>d</entry>
|
||||
<entry>d</entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>1</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>7</subscript></entry>
|
||||
<entry>d</entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>2</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>6</subscript></entry>
|
||||
<entry>d</entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>3</entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>7</subscript></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>4</entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>6</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>5</entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>7</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>6</entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>6</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB888-1X7X4-JEIDA">
|
||||
<entry>MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA</entry>
|
||||
<entry>0x1012</entry>
|
||||
<entry>0</entry>
|
||||
<entry></entry>
|
||||
<entry>d</entry>
|
||||
<entry>d</entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>1</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>d</entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>7</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>2</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>d</entry>
|
||||
<entry>g<subscript>7</subscript></entry>
|
||||
<entry>r<subscript>6</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>3</entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>7</subscript></entry>
|
||||
<entry>g<subscript>6</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>4</entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>b<subscript>6</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>5</entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>6</entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
|
@ -3045,6 +3432,43 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YUV8-1X24">
|
||||
<entry>MEDIA_BUS_FMT_YUV8_1X24</entry>
|
||||
<entry>0x2025</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-UYVY12-1X24">
|
||||
<entry>MEDIA_BUS_FMT_UYVY12_1X24</entry>
|
||||
<entry>0x2020</entry>
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue