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 315977 additions and 156363 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>
|
||||
|
|
|
|||
|
|
@ -95,8 +95,7 @@ since it doesn't need to allocate a table as large as the largest
|
|||
hwirq number. The disadvantage is that hwirq to IRQ number lookup is
|
||||
dependent on how many entries are in the table.
|
||||
|
||||
Very few drivers should need this mapping. At the moment, powerpc
|
||||
iseries is the only user.
|
||||
Very few drivers should need this mapping.
|
||||
|
||||
==== No Map ===-
|
||||
irq_domain_add_nomap()
|
||||
|
|
|
|||
|
|
@ -353,7 +353,7 @@ retry:
|
|||
rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
maxvec, maxvec);
|
||||
/*
|
||||
* -ENOSPC is the only error code allowed to be analized
|
||||
* -ENOSPC is the only error code allowed to be analyzed
|
||||
*/
|
||||
if (rc == -ENOSPC) {
|
||||
if (maxvec == 1)
|
||||
|
|
@ -370,7 +370,7 @@ retry:
|
|||
return rc;
|
||||
}
|
||||
|
||||
Note how pci_enable_msix_range() return value is analized for a fallback -
|
||||
Note how pci_enable_msix_range() return value is analyzed for a fallback -
|
||||
any error code other than -ENOSPC indicates a fatal error and should not
|
||||
be retried.
|
||||
|
||||
|
|
@ -486,7 +486,7 @@ during development.
|
|||
If your device supports both MSI-X and MSI capabilities, you should use
|
||||
the MSI-X facilities in preference to the MSI facilities. As mentioned
|
||||
above, MSI-X supports any number of interrupts between 1 and 2048.
|
||||
In constrast, MSI is restricted to a maximum of 32 interrupts (and
|
||||
In contrast, MSI is restricted to a maximum of 32 interrupts (and
|
||||
must be a power of two). In addition, the MSI interrupt vectors must
|
||||
be allocated consecutively, so the system might not be able to allocate
|
||||
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
|
||||
|
|
@ -501,18 +501,9 @@ necessary to disable interrupts (Linux guarantees the same interrupt will
|
|||
not be re-entered). If a device uses multiple interrupts, the driver
|
||||
must disable interrupts while the lock is held. If the device sends
|
||||
a different interrupt, the driver will deadlock trying to recursively
|
||||
acquire the spinlock.
|
||||
|
||||
There are two solutions. The first is to take the lock with
|
||||
spin_lock_irqsave() or spin_lock_irq() (see
|
||||
Documentation/DocBook/kernel-locking). The second is to specify
|
||||
IRQF_DISABLED to request_irq() so that the kernel runs the entire
|
||||
interrupt routine with interrupts disabled.
|
||||
|
||||
If your MSI interrupt routine does not hold the lock for the whole time
|
||||
it is running, the first solution may be best. The second solution is
|
||||
normally preferred as it avoids making two transitions from interrupt
|
||||
disabled to enabled and back again.
|
||||
acquire the spinlock. Such deadlocks can be avoided by using
|
||||
spin_lock_irqsave() or spin_lock_irq() which disable local interrupts
|
||||
and acquire the lock (see Documentation/DocBook/kernel-locking).
|
||||
|
||||
4.6 How to tell whether MSI/MSI-X is enabled on a device
|
||||
|
||||
|
|
|
|||
|
|
@ -256,7 +256,7 @@ STEP 4: Slot Reset
|
|||
------------------
|
||||
|
||||
In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
|
||||
the platform will peform a slot reset on the requesting PCI device(s).
|
||||
the platform will perform a slot reset on the requesting PCI device(s).
|
||||
The actual steps taken by a platform to perform a slot reset
|
||||
will be platform-dependent. Upon completion of slot reset, the
|
||||
platform will call the device slot_reset() callback.
|
||||
|
|
|
|||
|
|
@ -564,14 +564,14 @@ to be handled by platform and generic code, not individual drivers.
|
|||
8. Vendor and device identifications
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
One is not required to add new device ids to include/linux/pci_ids.h.
|
||||
Please add PCI_VENDOR_ID_xxx for vendors and a hex constant for device ids.
|
||||
Do not add new device or vendor IDs to include/linux/pci_ids.h unless they
|
||||
are shared across multiple drivers. You can add private definitions in
|
||||
your driver if they're helpful, or just use plain hex constants.
|
||||
|
||||
PCI_VENDOR_ID_xxx constants are re-used. The device ids are arbitrary
|
||||
hex numbers (vendor controlled) and normally used only in a single
|
||||
location, the pci_device_id table.
|
||||
The device IDs are arbitrary hex numbers (vendor controlled) and normally used
|
||||
only in a single location, the pci_device_id table.
|
||||
|
||||
Please DO submit new vendor/device ids to pciids.sourceforge.net project.
|
||||
Please DO submit new vendor/device IDs to http://pciids.sourceforge.net/.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -66,8 +66,8 @@ hardware (mostly chipsets) has root ports that cannot obtain the reporting
|
|||
source ID. nosourceid=n by default.
|
||||
|
||||
2.3 AER error output
|
||||
When a PCI-E AER error is captured, an error message will be outputed to
|
||||
console. If it's a correctable error, it is outputed as a warning.
|
||||
When a PCI-E AER error is captured, an error message will be outputted to
|
||||
console. If it's a correctable error, it is outputted as a warning.
|
||||
Otherwise, it is printed as an error. So users could choose different
|
||||
log level to filter out correctable error messages.
|
||||
|
||||
|
|
|
|||
|
|
@ -614,8 +614,8 @@ The canonical patch message body contains the following:
|
|||
|
||||
- An empty line.
|
||||
|
||||
- The body of the explanation, which will be copied to the
|
||||
permanent changelog to describe this patch.
|
||||
- The body of the explanation, line wrapped at 75 columns, which will
|
||||
be copied to the permanent changelog to describe this patch.
|
||||
|
||||
- The "Signed-off-by:" lines, described above, which will
|
||||
also go in the changelog.
|
||||
|
|
|
|||
|
|
@ -1,129 +1,177 @@
|
|||
APEI Error INJection
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
EINJ provides a hardware error injection mechanism
|
||||
It is very useful for debugging and testing of other APEI and RAS features.
|
||||
EINJ provides a hardware error injection mechanism. It is very useful
|
||||
for debugging and testing APEI and RAS features in general.
|
||||
|
||||
To use EINJ, make sure the following are enabled in your kernel
|
||||
You need to check whether your BIOS supports EINJ first. For that, look
|
||||
for early boot messages similar to this one:
|
||||
|
||||
ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL 00000001 INTL 00000001)
|
||||
|
||||
which shows that the BIOS is exposing an EINJ table - it is the
|
||||
mechanism through which the injection is done.
|
||||
|
||||
Alternatively, look in /sys/firmware/acpi/tables for an "EINJ" file,
|
||||
which is a different representation of the same thing.
|
||||
|
||||
It doesn't necessarily mean that EINJ is not supported if those above
|
||||
don't exist: before you give up, go into BIOS setup to see if the BIOS
|
||||
has an option to enable error injection. Look for something called WHEA
|
||||
or similar. Often, you need to enable an ACPI5 support option prior, in
|
||||
order to see the APEI,EINJ,... functionality supported and exposed by
|
||||
the BIOS menu.
|
||||
|
||||
To use EINJ, make sure the following are options enabled in your kernel
|
||||
configuration:
|
||||
|
||||
CONFIG_DEBUG_FS
|
||||
CONFIG_ACPI_APEI
|
||||
CONFIG_ACPI_APEI_EINJ
|
||||
|
||||
The user interface of EINJ is debug file system, under the
|
||||
directory apei/einj. The following files are provided.
|
||||
The EINJ user interface is in <debugfs mount point>/apei/einj.
|
||||
|
||||
The following files belong to it:
|
||||
|
||||
- available_error_type
|
||||
Reading this file returns the error injection capability of the
|
||||
platform, that is, which error types are supported. The error type
|
||||
definition is as follow, the left field is the error type value, the
|
||||
right field is error description.
|
||||
|
||||
0x00000001 Processor Correctable
|
||||
0x00000002 Processor Uncorrectable non-fatal
|
||||
0x00000004 Processor Uncorrectable fatal
|
||||
0x00000008 Memory Correctable
|
||||
0x00000010 Memory Uncorrectable non-fatal
|
||||
0x00000020 Memory Uncorrectable fatal
|
||||
0x00000040 PCI Express Correctable
|
||||
0x00000080 PCI Express Uncorrectable fatal
|
||||
0x00000100 PCI Express Uncorrectable non-fatal
|
||||
0x00000200 Platform Correctable
|
||||
0x00000400 Platform Uncorrectable non-fatal
|
||||
0x00000800 Platform Uncorrectable fatal
|
||||
This file shows which error types are supported:
|
||||
|
||||
The format of file contents are as above, except there are only the
|
||||
available error type lines.
|
||||
Error Type Value Error Description
|
||||
================ =================
|
||||
0x00000001 Processor Correctable
|
||||
0x00000002 Processor Uncorrectable non-fatal
|
||||
0x00000004 Processor Uncorrectable fatal
|
||||
0x00000008 Memory Correctable
|
||||
0x00000010 Memory Uncorrectable non-fatal
|
||||
0x00000020 Memory Uncorrectable fatal
|
||||
0x00000040 PCI Express Correctable
|
||||
0x00000080 PCI Express Uncorrectable fatal
|
||||
0x00000100 PCI Express Uncorrectable non-fatal
|
||||
0x00000200 Platform Correctable
|
||||
0x00000400 Platform Uncorrectable non-fatal
|
||||
0x00000800 Platform Uncorrectable fatal
|
||||
|
||||
The format of the file contents are as above, except present are only
|
||||
the available error types.
|
||||
|
||||
- error_type
|
||||
This file is used to set the error type value. The error type value
|
||||
is defined in "available_error_type" description.
|
||||
|
||||
Set the value of the error type being injected. Possible error types
|
||||
are defined in the file available_error_type above.
|
||||
|
||||
- error_inject
|
||||
Write any integer to this file to trigger the error
|
||||
injection. Before this, please specify all necessary error
|
||||
parameters.
|
||||
|
||||
Write any integer to this file to trigger the error injection. Make
|
||||
sure you have specified all necessary error parameters, i.e. this
|
||||
write should be the last step when injecting errors.
|
||||
|
||||
- flags
|
||||
Present for kernel version 3.13 and above. Used to specify which
|
||||
of param{1..4} are valid and should be used by BIOS during injection.
|
||||
Value is a bitmask as specified in ACPI5.0 spec for the
|
||||
|
||||
Present for kernel versions 3.13 and above. Used to specify which
|
||||
of param{1..4} are valid and should be used by the firmware during
|
||||
injection. Value is a bitmask as specified in ACPI5.0 spec for the
|
||||
SET_ERROR_TYPE_WITH_ADDRESS data structure:
|
||||
Bit 0 - Processor APIC field valid (see param3 below)
|
||||
Bit 1 - Memory address and mask valid (param1 and param2)
|
||||
Bit 2 - PCIe (seg,bus,dev,fn) valid (param4 below)
|
||||
If set to zero, legacy behaviour is used where the type of injection
|
||||
specifies just one bit set, and param1 is multiplexed.
|
||||
|
||||
Bit 0 - Processor APIC field valid (see param3 below).
|
||||
Bit 1 - Memory address and mask valid (param1 and param2).
|
||||
Bit 2 - PCIe (seg,bus,dev,fn) valid (see param4 below).
|
||||
|
||||
If set to zero, legacy behavior is mimicked where the type of
|
||||
injection specifies just one bit set, and param1 is multiplexed.
|
||||
|
||||
- param1
|
||||
This file is used to set the first error parameter value. Effect of
|
||||
parameter depends on error_type specified. For example, if error
|
||||
type is memory related type, the param1 should be a valid physical
|
||||
memory address. [Unless "flag" is set - see above]
|
||||
|
||||
This file is used to set the first error parameter value. Its effect
|
||||
depends on the error type specified in error_type. For example, if
|
||||
error type is memory related type, the param1 should be a valid
|
||||
physical memory address. [Unless "flag" is set - see above]
|
||||
|
||||
- param2
|
||||
This file is used to set the second error parameter value. Effect of
|
||||
parameter depends on error_type specified. For example, if error
|
||||
type is memory related type, the param2 should be a physical memory
|
||||
address mask. Linux requires page or narrower granularity, say,
|
||||
0xfffffffffffff000.
|
||||
|
||||
Same use as param1 above. For example, if error type is of memory
|
||||
related type, then param2 should be a physical memory address mask.
|
||||
Linux requires page or narrower granularity, say, 0xfffffffffffff000.
|
||||
|
||||
- param3
|
||||
Used when the 0x1 bit is set in "flag" to specify the APIC id
|
||||
|
||||
Used when the 0x1 bit is set in "flags" to specify the APIC id
|
||||
|
||||
- param4
|
||||
Used when the 0x4 bit is set in "flag" to specify target PCIe device
|
||||
Used when the 0x4 bit is set in "flags" to specify target PCIe device
|
||||
|
||||
- notrigger
|
||||
The EINJ mechanism is a two step process. First inject the error, then
|
||||
perform some actions to trigger it. Setting "notrigger" to 1 skips the
|
||||
trigger phase, which *may* allow the user to cause the error in some other
|
||||
context by a simple access to the cpu, memory location, or device that is
|
||||
the target of the error injection. Whether this actually works depends
|
||||
on what operations the BIOS actually includes in the trigger phase.
|
||||
|
||||
BIOS versions based in the ACPI 4.0 specification have limited options
|
||||
to control where the errors are injected. Your BIOS may support an
|
||||
extension (enabled with the param_extension=1 module parameter, or
|
||||
boot command line einj.param_extension=1). This allows the address
|
||||
and mask for memory injections to be specified by the param1 and
|
||||
param2 files in apei/einj.
|
||||
The error injection mechanism is a two-step process. First inject the
|
||||
error, then perform some actions to trigger it. Setting "notrigger"
|
||||
to 1 skips the trigger phase, which *may* allow the user to cause the
|
||||
error in some other context by a simple access to the CPU, memory
|
||||
location, or device that is the target of the error injection. Whether
|
||||
this actually works depends on what operations the BIOS actually
|
||||
includes in the trigger phase.
|
||||
|
||||
BIOS versions using the ACPI 5.0 specification have more control over
|
||||
the target of the injection. For processor related errors (type 0x1,
|
||||
0x2 and 0x4) the APICID of the target should be provided using the
|
||||
param1 file in apei/einj. For memory errors (type 0x8, 0x10 and 0x20)
|
||||
the address is set using param1 with a mask in param2 (0x0 is equivalent
|
||||
to all ones). For PCI express errors (type 0x40, 0x80 and 0x100) the
|
||||
segment, bus, device and function are specified using param1:
|
||||
BIOS versions based on the ACPI 4.0 specification have limited options
|
||||
in controlling where the errors are injected. Your BIOS may support an
|
||||
extension (enabled with the param_extension=1 module parameter, or boot
|
||||
command line einj.param_extension=1). This allows the address and mask
|
||||
for memory injections to be specified by the param1 and param2 files in
|
||||
apei/einj.
|
||||
|
||||
BIOS versions based on the ACPI 5.0 specification have more control over
|
||||
the target of the injection. For processor-related errors (type 0x1, 0x2
|
||||
and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and
|
||||
param2 for bit 1) so that you have more information added to the error
|
||||
signature being injected. The actual data passed is this:
|
||||
|
||||
memory_address = param1;
|
||||
memory_address_range = param2;
|
||||
apicid = param3;
|
||||
pcie_sbdf = param4;
|
||||
|
||||
For memory errors (type 0x8, 0x10 and 0x20) the address is set using
|
||||
param1 with a mask in param2 (0x0 is equivalent to all ones). For PCI
|
||||
express errors (type 0x40, 0x80 and 0x100) the segment, bus, device and
|
||||
function are specified using param1:
|
||||
|
||||
31 24 23 16 15 11 10 8 7 0
|
||||
+-------------------------------------------------+
|
||||
| segment | bus | device | function | reserved |
|
||||
+-------------------------------------------------+
|
||||
|
||||
An ACPI 5.0 BIOS may also allow vendor specific errors to be injected.
|
||||
Anyway, you get the idea, if there's doubt just take a look at the code
|
||||
in drivers/acpi/apei/einj.c.
|
||||
|
||||
An ACPI 5.0 BIOS may also allow vendor-specific errors to be injected.
|
||||
In this case a file named vendor will contain identifying information
|
||||
from the BIOS that hopefully will allow an application wishing to use
|
||||
the vendor specific extension to tell that they are running on a BIOS
|
||||
the vendor-specific extension to tell that they are running on a BIOS
|
||||
that supports it. All vendor extensions have the 0x80000000 bit set in
|
||||
error_type. A file vendor_flags controls the interpretation of param1
|
||||
and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor
|
||||
documentation for details (and expect changes to this API if vendors
|
||||
creativity in using this feature expands beyond our expectations).
|
||||
|
||||
Example:
|
||||
|
||||
An error injection example:
|
||||
|
||||
# cd /sys/kernel/debug/apei/einj
|
||||
# cat available_error_type # See which errors can be injected
|
||||
0x00000002 Processor Uncorrectable non-fatal
|
||||
0x00000008 Memory Correctable
|
||||
0x00000010 Memory Uncorrectable non-fatal
|
||||
# echo 0x12345000 > param1 # Set memory address for injection
|
||||
# echo 0xfffffffffffff000 > param2 # Mask - anywhere in this page
|
||||
# echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page
|
||||
# echo 0x8 > error_type # Choose correctable memory error
|
||||
# echo 1 > error_inject # Inject now
|
||||
|
||||
You should see something like this in dmesg:
|
||||
|
||||
[22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR
|
||||
[22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090
|
||||
[22715.834759] EDAC sbridge MC3: TSC 0
|
||||
[22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86
|
||||
[22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0
|
||||
[22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0)
|
||||
|
||||
For more information about EINJ, please refer to ACPI specification
|
||||
version 4.0, section 17.5 and ACPI 5.0, section 18.6.
|
||||
|
|
|
|||
|
|
@ -254,8 +254,13 @@ GPIO support
|
|||
~~~~~~~~~~~~
|
||||
ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
|
||||
and GpioInt. These resources are used be used to pass GPIO numbers used by
|
||||
the device to the driver. For example:
|
||||
the device to the driver. ACPI 5.1 extended this with _DSD (Device
|
||||
Specific Data) which made it possible to name the GPIOs among other things.
|
||||
|
||||
For example:
|
||||
|
||||
Device (DEV)
|
||||
{
|
||||
Method (_CRS, 0, NotSerialized)
|
||||
{
|
||||
Name (SBUF, ResourceTemplate()
|
||||
|
|
@ -285,6 +290,18 @@ the device to the driver. For example:
|
|||
Return (SBUF)
|
||||
}
|
||||
|
||||
// ACPI 5.1 _DSD used for naming the GPIOs
|
||||
Name (_DSD, Package ()
|
||||
{
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package ()
|
||||
{
|
||||
Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }},
|
||||
Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }},
|
||||
}
|
||||
})
|
||||
...
|
||||
|
||||
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
|
||||
specifies the path to the controller. In order to use these GPIOs in Linux
|
||||
we need to translate them to the corresponding Linux GPIO descriptors.
|
||||
|
|
@ -300,11 +317,11 @@ a code like this:
|
|||
|
||||
struct gpio_desc *irq_desc, *power_desc;
|
||||
|
||||
irq_desc = gpiod_get_index(dev, NULL, 1);
|
||||
irq_desc = gpiod_get(dev, "irq");
|
||||
if (IS_ERR(irq_desc))
|
||||
/* handle error */
|
||||
|
||||
power_desc = gpiod_get_index(dev, NULL, 0);
|
||||
power_desc = gpiod_get(dev, "power");
|
||||
if (IS_ERR(power_desc))
|
||||
/* handle error */
|
||||
|
||||
|
|
@ -313,6 +330,9 @@ a code like this:
|
|||
There are also devm_* versions of these functions which release the
|
||||
descriptors once the device is released.
|
||||
|
||||
See Documentation/acpi/gpio-properties.txt for more information about the
|
||||
_DSD binding related to GPIOs.
|
||||
|
||||
MFD devices
|
||||
~~~~~~~~~~~
|
||||
The MFD devices register their children as platform devices. For the child
|
||||
|
|
|
|||
|
|
@ -58,13 +58,18 @@ serial format options as described in
|
|||
--------------------------
|
||||
|
||||
Existing boot loaders: OPTIONAL
|
||||
New boot loaders: MANDATORY
|
||||
New boot loaders: MANDATORY except for DT-only platforms
|
||||
|
||||
The boot loader should detect the machine type its running on by some
|
||||
method. Whether this is a hard coded value or some algorithm that
|
||||
looks at the connected hardware is beyond the scope of this document.
|
||||
The boot loader must ultimately be able to provide a MACH_TYPE_xxx
|
||||
value to the kernel. (see linux/arch/arm/tools/mach-types).
|
||||
value to the kernel. (see linux/arch/arm/tools/mach-types). This
|
||||
should be passed to the kernel in register r1.
|
||||
|
||||
For DT-only platforms, the machine type will be determined by device
|
||||
tree. set the machine type to all ones (~0). This is not strictly
|
||||
necessary, but assures that it will not match any existing types.
|
||||
|
||||
4. Setup boot data
|
||||
------------------
|
||||
|
|
|
|||
|
|
@ -185,13 +185,20 @@ Kernel entry (head.S)
|
|||
board devices are used, or the device is setup, and provides that
|
||||
machine specific "personality."
|
||||
|
||||
This fine-grained machine specific selection is controlled by the machine
|
||||
type ID, which acts both as a run-time and a compile-time code selection
|
||||
method.
|
||||
For platforms that support device tree (DT), the machine selection is
|
||||
controlled at runtime by passing the device tree blob to the kernel. At
|
||||
compile-time, support for the machine type must be selected. This allows for
|
||||
a single multiplatform kernel build to be used for several machine types.
|
||||
|
||||
You can register a new machine via the web site at:
|
||||
For platforms that do not use device tree, this machine selection is
|
||||
controlled by the machine type ID, which acts both as a run-time and a
|
||||
compile-time code selection method. You can register a new machine via the
|
||||
web site at:
|
||||
|
||||
<http://www.arm.linux.org.uk/developer/machines/>
|
||||
|
||||
Note: Please do not register a machine type for DT-only platforms. If your
|
||||
platform is DT-only, you do not need a registered machine type.
|
||||
|
||||
---
|
||||
Russell King (15/03/2004)
|
||||
|
|
|
|||
|
|
@ -201,11 +201,11 @@ These routines add 1 and subtract 1, respectively, from the given
|
|||
atomic_t and return the new counter value after the operation is
|
||||
performed.
|
||||
|
||||
Unlike the above routines, it is required that explicit memory
|
||||
barriers are performed before and after the operation. It must be
|
||||
done such that all memory operations before and after the atomic
|
||||
operation calls are strongly ordered with respect to the atomic
|
||||
operation itself.
|
||||
Unlike the above routines, it is required that these primitives
|
||||
include explicit memory barriers that are performed before and after
|
||||
the operation. It must be done such that all memory operations before
|
||||
and after the atomic operation calls are strongly ordered with respect
|
||||
to the atomic operation itself.
|
||||
|
||||
For example, it should behave as if a smp_mb() call existed both
|
||||
before and after the atomic operation.
|
||||
|
|
@ -233,21 +233,21 @@ These two routines increment and decrement by 1, respectively, the
|
|||
given atomic counter. They return a boolean indicating whether the
|
||||
resulting counter value was zero or not.
|
||||
|
||||
It requires explicit memory barrier semantics around the operation as
|
||||
above.
|
||||
Again, these primitives provide explicit memory barrier semantics around
|
||||
the atomic operation.
|
||||
|
||||
int atomic_sub_and_test(int i, atomic_t *v);
|
||||
|
||||
This is identical to atomic_dec_and_test() except that an explicit
|
||||
decrement is given instead of the implicit "1". It requires explicit
|
||||
memory barrier semantics around the operation.
|
||||
decrement is given instead of the implicit "1". This primitive must
|
||||
provide explicit memory barrier semantics around the operation.
|
||||
|
||||
int atomic_add_negative(int i, atomic_t *v);
|
||||
|
||||
The given increment is added to the given atomic counter value. A
|
||||
boolean is return which indicates whether the resulting counter value
|
||||
is negative. It requires explicit memory barrier semantics around the
|
||||
operation.
|
||||
The given increment is added to the given atomic counter value. A boolean
|
||||
is return which indicates whether the resulting counter value is negative.
|
||||
This primitive must provide explicit memory barrier semantics around
|
||||
the operation.
|
||||
|
||||
Then:
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ This performs an atomic exchange operation on the atomic variable v, setting
|
|||
the given new value. It returns the old value that the atomic variable v had
|
||||
just before the operation.
|
||||
|
||||
atomic_xchg requires explicit memory barriers around the operation.
|
||||
atomic_xchg must provide explicit memory barriers around the operation.
|
||||
|
||||
int atomic_cmpxchg(atomic_t *v, int old, int new);
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ with the given old and new values. Like all atomic_xxx operations,
|
|||
atomic_cmpxchg will only satisfy its atomicity semantics as long as all
|
||||
other accesses of *v are performed through atomic_xxx operations.
|
||||
|
||||
atomic_cmpxchg requires explicit memory barriers around the operation.
|
||||
atomic_cmpxchg must provide explicit memory barriers around the operation.
|
||||
|
||||
The semantics for atomic_cmpxchg are the same as those defined for 'cas'
|
||||
below.
|
||||
|
|
@ -279,8 +279,8 @@ If the atomic value v is not equal to u, this function adds a to v, and
|
|||
returns non zero. If v is equal to u then it returns zero. This is done as
|
||||
an atomic operation.
|
||||
|
||||
atomic_add_unless requires explicit memory barriers around the operation
|
||||
unless it fails (returns 0).
|
||||
atomic_add_unless must provide explicit memory barriers around the
|
||||
operation unless it fails (returns 0).
|
||||
|
||||
atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)
|
||||
|
||||
|
|
@ -460,9 +460,9 @@ the return value into an int. There are other places where things
|
|||
like this occur as well.
|
||||
|
||||
These routines, like the atomic_t counter operations returning values,
|
||||
require explicit memory barrier semantics around their execution. All
|
||||
memory operations before the atomic bit operation call must be made
|
||||
visible globally before the atomic bit operation is made visible.
|
||||
must provide explicit memory barrier semantics around their execution.
|
||||
All memory operations before the atomic bit operation call must be
|
||||
made visible globally before the atomic bit operation is made visible.
|
||||
Likewise, the atomic bit operation must be visible globally before any
|
||||
subsequent memory operation is made visible. For example:
|
||||
|
||||
|
|
@ -536,8 +536,9 @@ except that two underscores are prefixed to the interface name.
|
|||
These non-atomic variants also do not require any special memory
|
||||
barrier semantics.
|
||||
|
||||
The routines xchg() and cmpxchg() need the same exact memory barriers
|
||||
as the atomic and bit operations returning values.
|
||||
The routines xchg() and cmpxchg() must provide the same exact
|
||||
memory-barrier semantics as the atomic and bit operations returning
|
||||
values.
|
||||
|
||||
Spinlocks and rwlocks have memory barrier expectations as well.
|
||||
The rule to follow is simple:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
ifneq ($(CONFIG_BLACKFIN),)
|
||||
ifneq ($(CONFIG_BFIN_GPTIMERS,)
|
||||
ifneq ($(CONFIG_BFIN_GPTIMERS),)
|
||||
obj-m := gptimers-example.o
|
||||
endif
|
||||
endif
|
||||
|
|
|
|||
|
|
@ -48,8 +48,7 @@ Description of Contents:
|
|||
- Highmem I/O support
|
||||
- I/O scheduler modularization
|
||||
1.2 Tuning based on high level requirements/capabilities
|
||||
1.2.1 I/O Barriers
|
||||
1.2.2 Request Priority/Latency
|
||||
1.2.1 Request Priority/Latency
|
||||
1.3 Direct access/bypass to lower layers for diagnostics and special
|
||||
device operations
|
||||
1.3.1 Pre-built commands
|
||||
|
|
@ -255,29 +254,12 @@ some control over i/o ordering.
|
|||
What kind of support exists at the generic block layer for this ?
|
||||
|
||||
The flags and rw fields in the bio structure can be used for some tuning
|
||||
from above e.g indicating that an i/o is just a readahead request, or for
|
||||
marking barrier requests (discussed next), or priority settings (currently
|
||||
unused). As far as user applications are concerned they would need an
|
||||
additional mechanism either via open flags or ioctls, or some other upper
|
||||
level mechanism to communicate such settings to block.
|
||||
from above e.g indicating that an i/o is just a readahead request, or priority
|
||||
settings (currently unused). As far as user applications are concerned they
|
||||
would need an additional mechanism either via open flags or ioctls, or some
|
||||
other upper level mechanism to communicate such settings to block.
|
||||
|
||||
1.2.1 I/O Barriers
|
||||
|
||||
There is a way to enforce strict ordering for i/os through barriers.
|
||||
All requests before a barrier point must be serviced before the barrier
|
||||
request and any other requests arriving after the barrier will not be
|
||||
serviced until after the barrier has completed. This is useful for higher
|
||||
level control on write ordering, e.g flushing a log of committed updates
|
||||
to disk before the corresponding updates themselves.
|
||||
|
||||
A flag in the bio structure, BIO_BARRIER is used to identify a barrier i/o.
|
||||
The generic i/o scheduler would make sure that it places the barrier request and
|
||||
all other requests coming after it after all the previous requests in the
|
||||
queue. Barriers may be implemented in different ways depending on the
|
||||
driver. For more details regarding I/O barriers, please read barrier.txt
|
||||
in this directory.
|
||||
|
||||
1.2.2 Request Priority/Latency
|
||||
1.2.1 Request Priority/Latency
|
||||
|
||||
Todo/Under discussion:
|
||||
Arjan's proposed request priority scheme allows higher levels some broad
|
||||
|
|
@ -906,8 +888,8 @@ queue and specific I/O schedulers. Unless stated otherwise, elevator is used
|
|||
to refer to both parts and I/O scheduler to specific I/O schedulers.
|
||||
|
||||
Block layer implements generic dispatch queue in block/*.c.
|
||||
The generic dispatch queue is responsible for properly ordering barrier
|
||||
requests, requeueing, handling non-fs requests and all other subtleties.
|
||||
The generic dispatch queue is responsible for requeueing, handling non-fs
|
||||
requests and all other subtleties.
|
||||
|
||||
Specific I/O schedulers are responsible for ordering normal filesystem
|
||||
requests. They can also choose to delay certain requests to improve
|
||||
|
|
|
|||
|
|
@ -1,17 +1,31 @@
|
|||
Network Block Device (TCP version)
|
||||
|
||||
What is it: With this compiled in the kernel (or as a module), Linux
|
||||
can use a remote server as one of its block devices. So every time
|
||||
the client computer wants to read, e.g., /dev/nb0, it sends a
|
||||
request over TCP to the server, which will reply with the data read.
|
||||
This can be used for stations with low disk space (or even diskless)
|
||||
to borrow disk space from another computer.
|
||||
Unlike NFS, it is possible to put any filesystem on it, etc.
|
||||
Network Block Device (TCP version)
|
||||
==================================
|
||||
|
||||
For more information, or to download the nbd-client and nbd-server
|
||||
tools, go to http://nbd.sf.net/.
|
||||
1) Overview
|
||||
-----------
|
||||
|
||||
What is it: With this compiled in the kernel (or as a module), Linux
|
||||
can use a remote server as one of its block devices. So every time
|
||||
the client computer wants to read, e.g., /dev/nb0, it sends a
|
||||
request over TCP to the server, which will reply with the data read.
|
||||
This can be used for stations with low disk space (or even diskless)
|
||||
to borrow disk space from another computer.
|
||||
Unlike NFS, it is possible to put any filesystem on it, etc.
|
||||
|
||||
For more information, or to download the nbd-client and nbd-server
|
||||
tools, go to http://nbd.sf.net/.
|
||||
|
||||
The nbd kernel module need only be installed on the client
|
||||
system, as the nbd-server is completely in userspace. In fact,
|
||||
the nbd-server has been successfully ported to other operating
|
||||
systems, including Windows.
|
||||
|
||||
A) NBD parameters
|
||||
-----------------
|
||||
|
||||
max_part
|
||||
Number of partitions per device (default: 0).
|
||||
|
||||
nbds_max
|
||||
Number of block devices that should be initialized (default: 16).
|
||||
|
||||
The nbd kernel module need only be installed on the client
|
||||
system, as the nbd-server is completely in userspace. In fact,
|
||||
the nbd-server has been successfully ported to other operating
|
||||
systems, including Windows.
|
||||
|
|
|
|||
|
|
@ -98,20 +98,79 @@ size of the disk when not in use so a huge zram is wasteful.
|
|||
mount /dev/zram1 /tmp
|
||||
|
||||
7) Stats:
|
||||
Per-device statistics are exported as various nodes under
|
||||
/sys/block/zram<id>/
|
||||
disksize
|
||||
num_reads
|
||||
num_writes
|
||||
failed_reads
|
||||
failed_writes
|
||||
invalid_io
|
||||
notify_free
|
||||
zero_pages
|
||||
orig_data_size
|
||||
compr_data_size
|
||||
mem_used_total
|
||||
mem_used_max
|
||||
Per-device statistics are exported as various nodes under /sys/block/zram<id>/
|
||||
|
||||
A brief description of exported device attritbutes. For more details please
|
||||
read Documentation/ABI/testing/sysfs-block-zram.
|
||||
|
||||
Name access description
|
||||
---- ------ -----------
|
||||
disksize RW show and set the device's disk size
|
||||
initstate RO shows the initialization state of the device
|
||||
reset WO trigger device reset
|
||||
num_reads RO the number of reads
|
||||
failed_reads RO the number of failed reads
|
||||
num_write RO the number of writes
|
||||
failed_writes RO the number of failed writes
|
||||
invalid_io RO the number of non-page-size-aligned I/O requests
|
||||
max_comp_streams RW the number of possible concurrent compress operations
|
||||
comp_algorithm RW show and change the compression algorithm
|
||||
notify_free RO the number of notifications to free pages (either
|
||||
slot free notifications or REQ_DISCARD requests)
|
||||
zero_pages RO the number of zero filled pages written to this disk
|
||||
orig_data_size RO uncompressed size of data stored in this disk
|
||||
compr_data_size RO compressed size of data stored in this disk
|
||||
mem_used_total RO the amount of memory allocated for this disk
|
||||
mem_used_max RW the maximum amount memory zram have consumed to
|
||||
store compressed data
|
||||
mem_limit RW the maximum amount of memory ZRAM can use to store
|
||||
the compressed data
|
||||
num_migrated RO the number of objects migrated migrated by compaction
|
||||
|
||||
|
||||
WARNING
|
||||
=======
|
||||
per-stat sysfs attributes are considered to be deprecated.
|
||||
The basic strategy is:
|
||||
-- the existing RW nodes will be downgraded to WO nodes (in linux 4.11)
|
||||
-- deprecated RO sysfs nodes will eventually be removed (in linux 4.11)
|
||||
|
||||
The list of deprecated attributes can be found here:
|
||||
Documentation/ABI/obsolete/sysfs-block-zram
|
||||
|
||||
Basically, every attribute that has its own read accessible sysfs node
|
||||
(e.g. num_reads) *AND* is accessible via one of the stat files (zram<id>/stat
|
||||
or zram<id>/io_stat or zram<id>/mm_stat) is considered to be deprecated.
|
||||
|
||||
User space is advised to use the following files to read the device statistics.
|
||||
|
||||
File /sys/block/zram<id>/stat
|
||||
|
||||
Represents block layer statistics. Read Documentation/block/stat.txt for
|
||||
details.
|
||||
|
||||
File /sys/block/zram<id>/io_stat
|
||||
|
||||
The stat file represents device's I/O statistics not accounted by block
|
||||
layer and, thus, not available in zram<id>/stat file. It consists of a
|
||||
single line of text and contains the following stats separated by
|
||||
whitespace:
|
||||
failed_reads
|
||||
failed_writes
|
||||
invalid_io
|
||||
notify_free
|
||||
|
||||
File /sys/block/zram<id>/mm_stat
|
||||
|
||||
The stat file represents device's mm statistics. It consists of a single
|
||||
line of text and contains the following stats separated by whitespace:
|
||||
orig_data_size
|
||||
compr_data_size
|
||||
mem_used_total
|
||||
mem_limit
|
||||
mem_used_max
|
||||
zero_pages
|
||||
num_migrated
|
||||
|
||||
8) Deactivate:
|
||||
swapoff /dev/zram0
|
||||
|
|
|
|||
|
|
@ -392,8 +392,10 @@ Put simply, it costs less to balance between two smaller sched domains
|
|||
than one big one, but doing so means that overloads in one of the
|
||||
two domains won't be load balanced to the other one.
|
||||
|
||||
By default, there is one sched domain covering all CPUs, except those
|
||||
marked isolated using the kernel boot time "isolcpus=" argument.
|
||||
By default, there is one sched domain covering all CPUs, including those
|
||||
marked isolated using the kernel boot time "isolcpus=" argument. However,
|
||||
the isolated CPUs will not participate in load balancing, and will not
|
||||
have tasks running on them unless explicitly assigned.
|
||||
|
||||
This default load balancing across all CPUs is not well suited for
|
||||
the following two situations:
|
||||
|
|
@ -465,6 +467,10 @@ such partially load balanced cpusets, as they may be artificially
|
|||
constrained to some subset of the CPUs allowed to them, for lack of
|
||||
load balancing to the other CPUs.
|
||||
|
||||
CPUs in "cpuset.isolcpus" were excluded from load balancing by the
|
||||
isolcpus= kernel boot option, and will never be load balanced regardless
|
||||
of the value of "cpuset.sched_load_balance" in any cpuset.
|
||||
|
||||
1.7.1 sched_load_balance implementation details.
|
||||
------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -275,11 +275,6 @@ When oom event notifier is registered, event will be delivered.
|
|||
|
||||
2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
|
||||
|
||||
WARNING: Current implementation lacks reclaim support. That means allocation
|
||||
attempts will fail when close to the limit even if there are plenty of
|
||||
kmem available for reclaim. That makes this option unusable in real
|
||||
life so DO NOT SELECT IT unless for development purposes.
|
||||
|
||||
With the Kernel memory extension, the Memory Controller is able to limit
|
||||
the amount of kernel memory used by the system. Kernel memory is fundamentally
|
||||
different than user memory, since it can't be swapped out, which makes it
|
||||
|
|
@ -345,6 +340,9 @@ set:
|
|||
In this case, the admin could set up K so that the sum of all groups is
|
||||
never greater than the total memory, and freely set U at the cost of his
|
||||
QoS.
|
||||
WARNING: In the current implementation, memory reclaim will NOT be
|
||||
triggered for a cgroup when it hits K while staying below U, which makes
|
||||
this setup impractical.
|
||||
|
||||
U != 0, K >= U:
|
||||
Since kmem charges will also be fed to the user counter and reclaim will be
|
||||
|
|
|
|||
|
|
@ -404,8 +404,8 @@ supported and the interface files "release_agent" and
|
|||
be understood as an underflow into the highest possible value, -2 or
|
||||
-10M etc. do not work, so it's not consistent.
|
||||
|
||||
memory.low, memory.high, and memory.max will use the string
|
||||
"infinity" to indicate and set the highest possible value.
|
||||
memory.low, memory.high, and memory.max will use the string "max" to
|
||||
indicate and set the highest possible value.
|
||||
|
||||
5. Planned Changes
|
||||
|
||||
|
|
|
|||
21
Documentation/cma/debugfs.txt
Normal file
21
Documentation/cma/debugfs.txt
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
The CMA debugfs interface is useful to retrieve basic information out of the
|
||||
different CMA areas and to test allocation/release in each of the areas.
|
||||
|
||||
Each CMA zone represents a directory under <debugfs>/cma/, indexed by the
|
||||
kernel's CMA index. So the first CMA zone would be:
|
||||
|
||||
<debugfs>/cma/cma-0
|
||||
|
||||
The structure of the files created under that directory is as follows:
|
||||
|
||||
- [RO] base_pfn: The base PFN (Page Frame Number) of the zone.
|
||||
- [RO] count: Amount of memory in the CMA area.
|
||||
- [RO] order_per_bit: Order of pages represented by one bit.
|
||||
- [RO] bitmap: The bitmap of page states in the zone.
|
||||
- [WO] alloc: Allocate N pages from that CMA area. For example:
|
||||
|
||||
echo 5 > <debugfs>/cma/cma-2/alloc
|
||||
|
||||
would try to allocate 5 pages from the cma-2 area.
|
||||
|
||||
- [WO] free: Free N pages from that CMA area, similar to the above.
|
||||
|
|
@ -1,205 +0,0 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
In addition, only a subset of all cipher types are available as documented
|
||||
below.
|
||||
|
||||
|
||||
User space API general remarks
|
||||
==============================
|
||||
|
||||
The kernel crypto API is accessible from user space. Currently, the following
|
||||
ciphers are accessible:
|
||||
|
||||
* Message digest including keyed message digest (HMAC, CMAC)
|
||||
|
||||
* Symmetric ciphers
|
||||
|
||||
Note, AEAD ciphers are currently not supported via the symmetric cipher
|
||||
interface.
|
||||
|
||||
The interface is provided via Netlink 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:
|
||||
|
||||
#ifndef AF_ALG
|
||||
#define AF_ALG 38
|
||||
#endif
|
||||
#ifndef SOL_ALG
|
||||
#define SOL_ALG 279
|
||||
#endif
|
||||
|
||||
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.
|
||||
|
||||
To interact with the kernel crypto API, a Netlink 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.
|
||||
|
||||
The following API calls assume that the Netlink socket descriptor is already
|
||||
opened by the user space application and discusses only the kernel crypto API
|
||||
specific invocations.
|
||||
|
||||
To initialize a Netlink interface, the following sequence has to be performed
|
||||
by the consumer:
|
||||
|
||||
1. Create a socket of type AF_ALG with the struct sockaddr_alg parameter
|
||||
specified below for the different cipher types.
|
||||
|
||||
2. Invoke bind with the socket descriptor
|
||||
|
||||
3. 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.
|
||||
|
||||
In-place cipher operation
|
||||
=========================
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Message digest API
|
||||
==================
|
||||
|
||||
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:
|
||||
|
||||
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 */
|
||||
};
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
* 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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Symmetric cipher API
|
||||
====================
|
||||
|
||||
The operation is very similar to the message digest discussion. During
|
||||
initialization, the struct sockaddr data structure must be filled as follows:
|
||||
|
||||
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 */
|
||||
};
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
* specification of the cipher operation type with one of these flags:
|
||||
ALG_OP_ENCRYPT - encryption of data
|
||||
ALG_OP_DECRYPT - decryption of data
|
||||
|
||||
* specification of the IV information marked with the flag ALG_SET_IV
|
||||
|
||||
The send system call family allows the following flag to be specified:
|
||||
|
||||
* 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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Setsockopt interface
|
||||
====================
|
||||
|
||||
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).
|
||||
|
||||
Each setsockopt invocation must use the level SOL_ALG.
|
||||
|
||||
The setsockopt interface allows setting the following data using the mentioned
|
||||
optname:
|
||||
|
||||
* ALG_SET_KEY -- Setting the key. Key setting is applicable to:
|
||||
|
||||
- the skcipher cipher type (symmetric ciphers)
|
||||
|
||||
- the hash cipher type (keyed message digests)
|
||||
|
||||
User space API example
|
||||
======================
|
||||
|
||||
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.
|
||||
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
|
||||
Author
|
||||
======
|
||||
|
||||
Stephan Mueller <smueller@chronox.de>
|
||||
|
|
@ -5,7 +5,7 @@ Device-Mapper's "crypt" target provides transparent encryption of block devices
|
|||
using the kernel crypto API.
|
||||
|
||||
For a more detailed description of supported parameters see:
|
||||
http://code.google.com/p/cryptsetup/wiki/DMCrypt
|
||||
https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt
|
||||
|
||||
Parameters: <cipher> <key> <iv_offset> <device path> \
|
||||
<offset> [<#opt_params> <opt_params>]
|
||||
|
|
@ -80,7 +80,7 @@ Example scripts
|
|||
===============
|
||||
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
|
||||
encryption with dm-crypt using the 'cryptsetup' utility, see
|
||||
http://code.google.com/p/cryptsetup/
|
||||
https://gitlab.com/cryptsetup/cryptsetup
|
||||
|
||||
[[
|
||||
#!/bin/sh
|
||||
|
|
|
|||
140
Documentation/device-mapper/log-writes.txt
Normal file
140
Documentation/device-mapper/log-writes.txt
Normal file
|
|
@ -0,0 +1,140 @@
|
|||
dm-log-writes
|
||||
=============
|
||||
|
||||
This target takes 2 devices, one to pass all IO to normally, and one to log all
|
||||
of the write operations to. This is intended for file system developers wishing
|
||||
to verify the integrity of metadata or data as the file system is written to.
|
||||
There is a log_write_entry written for every WRITE request and the target is
|
||||
able to take arbitrary data from userspace to insert into the log. The data
|
||||
that is in the WRITE requests is copied into the log to make the replay happen
|
||||
exactly as it happened originally.
|
||||
|
||||
Log Ordering
|
||||
============
|
||||
|
||||
We log things in order of completion once we are sure the write is no longer in
|
||||
cache. This means that normal WRITE requests are not actually logged until the
|
||||
next REQ_FLUSH request. This is to make it easier for userspace to replay the
|
||||
log in a way that correlates to what is on disk and not what is in cache, to
|
||||
make it easier to detect improper waiting/flushing.
|
||||
|
||||
This works by attaching all WRITE requests to a list once the write completes.
|
||||
Once we see a REQ_FLUSH request we splice this list onto the request and once
|
||||
the FLUSH request completes we log all of the WRITEs and then the FLUSH. Only
|
||||
completed WRITEs, at the time the REQ_FLUSH is issued, are added in order to
|
||||
simulate the worst case scenario with regard to power failures. Consider the
|
||||
following example (W means write, C means complete):
|
||||
|
||||
W1,W2,W3,C3,C2,Wflush,C1,Cflush
|
||||
|
||||
The log would show the following
|
||||
|
||||
W3,W2,flush,W1....
|
||||
|
||||
Again this is to simulate what is actually on disk, this allows us to detect
|
||||
cases where a power failure at a particular point in time would create an
|
||||
inconsistent file system.
|
||||
|
||||
Any REQ_FUA requests bypass this flushing mechanism and are logged as soon as
|
||||
they complete as those requests will obviously bypass the device cache.
|
||||
|
||||
Any REQ_DISCARD requests are treated like WRITE requests. Otherwise we would
|
||||
have all the DISCARD requests, and then the WRITE requests and then the FLUSH
|
||||
request. Consider the following example:
|
||||
|
||||
WRITE block 1, DISCARD block 1, FLUSH
|
||||
|
||||
If we logged DISCARD when it completed, the replay would look like this
|
||||
|
||||
DISCARD 1, WRITE 1, FLUSH
|
||||
|
||||
which isn't quite what happened and wouldn't be caught during the log replay.
|
||||
|
||||
Target interface
|
||||
================
|
||||
|
||||
i) Constructor
|
||||
|
||||
log-writes <dev_path> <log_dev_path>
|
||||
|
||||
dev_path : Device that all of the IO will go to normally.
|
||||
log_dev_path : Device where the log entries are written to.
|
||||
|
||||
ii) Status
|
||||
|
||||
<#logged entries> <highest allocated sector>
|
||||
|
||||
#logged entries : Number of logged entries
|
||||
highest allocated sector : Highest allocated sector
|
||||
|
||||
iii) Messages
|
||||
|
||||
mark <description>
|
||||
|
||||
You can use a dmsetup message to set an arbitrary mark in a log.
|
||||
For example say you want to fsck a file system after every
|
||||
write, but first you need to replay up to the mkfs to make sure
|
||||
we're fsck'ing something reasonable, you would do something like
|
||||
this:
|
||||
|
||||
mkfs.btrfs -f /dev/mapper/log
|
||||
dmsetup message log 0 mark mkfs
|
||||
<run test>
|
||||
|
||||
This would allow you to replay the log up to the mkfs mark and
|
||||
then replay from that point on doing the fsck check in the
|
||||
interval that you want.
|
||||
|
||||
Every log has a mark at the end labeled "dm-log-writes-end".
|
||||
|
||||
Userspace component
|
||||
===================
|
||||
|
||||
There is a userspace tool that will replay the log for you in various ways.
|
||||
It can be found here: https://github.com/josefbacik/log-writes
|
||||
|
||||
Example usage
|
||||
=============
|
||||
|
||||
Say you want to test fsync on your file system. You would do something like
|
||||
this:
|
||||
|
||||
TABLE="0 $(blockdev --getsz /dev/sdb) log-writes /dev/sdb /dev/sdc"
|
||||
dmsetup create log --table "$TABLE"
|
||||
mkfs.btrfs -f /dev/mapper/log
|
||||
dmsetup message log 0 mark mkfs
|
||||
|
||||
mount /dev/mapper/log /mnt/btrfs-test
|
||||
<some test that does fsync at the end>
|
||||
dmsetup message log 0 mark fsync
|
||||
md5sum /mnt/btrfs-test/foo
|
||||
umount /mnt/btrfs-test
|
||||
|
||||
dmsetup remove log
|
||||
replay-log --log /dev/sdc --replay /dev/sdb --end-mark fsync
|
||||
mount /dev/sdb /mnt/btrfs-test
|
||||
md5sum /mnt/btrfs-test/foo
|
||||
<verify md5sum's are correct>
|
||||
|
||||
Another option is to do a complicated file system operation and verify the file
|
||||
system is consistent during the entire operation. You could do this with:
|
||||
|
||||
TABLE="0 $(blockdev --getsz /dev/sdb) log-writes /dev/sdb /dev/sdc"
|
||||
dmsetup create log --table "$TABLE"
|
||||
mkfs.btrfs -f /dev/mapper/log
|
||||
dmsetup message log 0 mark mkfs
|
||||
|
||||
mount /dev/mapper/log /mnt/btrfs-test
|
||||
<fsstress to dirty the fs>
|
||||
btrfs filesystem balance /mnt/btrfs-test
|
||||
umount /mnt/btrfs-test
|
||||
dmsetup remove log
|
||||
|
||||
replay-log --log /dev/sdc --replay /dev/sdb --end-mark mkfs
|
||||
btrfsck /dev/sdb
|
||||
replay-log --log /dev/sdc --replay /dev/sdb --start-mark mkfs \
|
||||
--fsck "btrfsck /dev/sdb" --check fua
|
||||
|
||||
And that will replay the log until it sees a FUA request, run the fsck command
|
||||
and if the fsck passes it will replay to the next FUA, until it is completed or
|
||||
the fsck command exists abnormally.
|
||||
|
|
@ -47,8 +47,8 @@ consume far too much memory.
|
|||
Using this device-mapper switch target we can now build a two-layer
|
||||
device hierarchy:
|
||||
|
||||
Upper Tier – Determine which array member the I/O should be sent to.
|
||||
Lower Tier – Load balance amongst paths to a particular member.
|
||||
Upper Tier - Determine which array member the I/O should be sent to.
|
||||
Lower Tier - Load balance amongst paths to a particular member.
|
||||
|
||||
The lower tier consists of a single dm multipath device for each member.
|
||||
Each of these multipath devices contains the set of paths directly to
|
||||
|
|
|
|||
|
|
@ -380,9 +380,6 @@ then you'll have no access to blocks mapped beyond the end. If you
|
|||
load a target that is bigger than before, then extra blocks will be
|
||||
provisioned as and when needed.
|
||||
|
||||
If you wish to reduce the size of your thin device and potentially
|
||||
regain some space then send the 'trim' message to the pool.
|
||||
|
||||
ii) Status
|
||||
|
||||
<nr mapped sectors> <highest mapped sector>
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ Construction Parameters
|
|||
<data_block_size> <hash_block_size>
|
||||
<num_data_blocks> <hash_start_block>
|
||||
<algorithm> <digest> <salt>
|
||||
[<#opt_params> <opt_params>]
|
||||
|
||||
<version>
|
||||
This is the type of the on-disk hash format.
|
||||
|
|
@ -62,6 +63,22 @@ Construction Parameters
|
|||
<salt>
|
||||
The hexadecimal encoding of the salt value.
|
||||
|
||||
<#opt_params>
|
||||
Number of optional parameters. If there are no optional parameters,
|
||||
the optional paramaters section can be skipped or #opt_params can be zero.
|
||||
Otherwise #opt_params is the number of following arguments.
|
||||
|
||||
Example of optional parameters section:
|
||||
1 ignore_corruption
|
||||
|
||||
ignore_corruption
|
||||
Log corrupted blocks, but allow read operations to proceed normally.
|
||||
|
||||
restart_on_corruption
|
||||
Restart the system when a corrupted block is discovered. This option is
|
||||
not compatible with ignore_corruption and requires user space support to
|
||||
avoid restart loops.
|
||||
|
||||
Theory of operation
|
||||
===================
|
||||
|
||||
|
|
@ -125,7 +142,7 @@ block boundary) are the hash blocks which are stored a depth at a time
|
|||
|
||||
The full specification of kernel parameters and on-disk metadata format
|
||||
is available at the cryptsetup project's wiki page
|
||||
http://code.google.com/p/cryptsetup/wiki/DMVerity
|
||||
https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity
|
||||
|
||||
Status
|
||||
======
|
||||
|
|
@ -142,7 +159,7 @@ Set up a device:
|
|||
|
||||
A command line tool veritysetup is available to compute or verify
|
||||
the hash tree or activate the kernel device. This is available from
|
||||
the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
|
||||
the cryptsetup upstream repository https://gitlab.com/cryptsetup/cryptsetup/
|
||||
(as a libcryptsetup extension).
|
||||
|
||||
Create hash on the device:
|
||||
|
|
|
|||
|
|
@ -22,6 +22,8 @@ Optional Properties:
|
|||
- pclkN, clkN: Pairs of parent of input clock and input clock to the
|
||||
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
||||
are supported currently.
|
||||
- power-domains: phandle pointing to the parent power domain, for more details
|
||||
see Documentation/devicetree/bindings/power/power_domain.txt
|
||||
|
||||
Node of a device using power domains must have a power-domains property
|
||||
defined with a phandle to respective power domain.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,14 @@
|
|||
Freescale Vybrid Miscellaneous System Control - CPU Configuration
|
||||
|
||||
The MSCM IP contains multiple sub modules, this binding describes the first
|
||||
block of registers which contains CPU configuration information.
|
||||
|
||||
Required properties:
|
||||
- compatible: "fsl,vf610-mscm-cpucfg", "syscon"
|
||||
- reg: the register range of the MSCM CPU configuration registers
|
||||
|
||||
Example:
|
||||
mscm_cpucfg: cpucfg@40001000 {
|
||||
compatible = "fsl,vf610-mscm-cpucfg", "syscon";
|
||||
reg = <0x40001000 0x800>;
|
||||
}
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
Freescale Vybrid Miscellaneous System Control - Interrupt Router
|
||||
|
||||
The MSCM IP contains multiple sub modules, this binding describes the second
|
||||
block of registers which control the interrupt router. The interrupt router
|
||||
allows to configure the recipient of each peripheral interrupt. Furthermore
|
||||
it controls the directed processor interrupts. The module is available in all
|
||||
Vybrid SoC's but is only really useful in dual core configurations (VF6xx
|
||||
which comes with a Cortex-A5/Cortex-M4 combination).
|
||||
|
||||
Required properties:
|
||||
- compatible: "fsl,vf610-mscm-ir"
|
||||
- reg: the register range of the MSCM Interrupt Router
|
||||
- fsl,cpucfg: The handle to the MSCM CPU configuration node, required
|
||||
to get the current CPU ID
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- #interrupt-cells: Two cells, interrupt number and cells.
|
||||
The hardware interrupt number according to interrupt
|
||||
assignment of the interrupt router is required.
|
||||
Flags get passed only when using GIC as parent. Flags
|
||||
encoding as documented by the GIC bindings.
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller of
|
||||
the CPU the device tree is intended to be used on. This
|
||||
is either the node of the GIC or NVIC controller.
|
||||
|
||||
Example:
|
||||
mscm_ir: interrupt-controller@40001800 {
|
||||
compatible = "fsl,vf610-mscm-ir";
|
||||
reg = <0x40001800 0x400>;
|
||||
fsl,cpucfg = <&mscm_cpucfg>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-parent = <&intc>;
|
||||
}
|
||||
|
|
@ -56,11 +56,6 @@ Optional
|
|||
regions, used when the GIC doesn't have banked registers. The offset is
|
||||
cpu-offset * cpu-nr.
|
||||
|
||||
- arm,routable-irqs : Total number of gic irq inputs which are not directly
|
||||
connected from the peripherals, but are routed dynamically
|
||||
by a crossbar/multiplexer preceding the GIC. The GIC irq
|
||||
input line is assigned dynamically when the corresponding
|
||||
peripheral's crossbar line is mapped.
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@fff11000 {
|
||||
|
|
@ -68,7 +63,6 @@ Example:
|
|||
#interrupt-cells = <3>;
|
||||
#address-cells = <1>;
|
||||
interrupt-controller;
|
||||
arm,routable-irqs = <160>;
|
||||
reg = <0xfff11000 0x1000>,
|
||||
<0xfff10100 0x100>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -9,7 +9,9 @@ inputs.
|
|||
Required properties:
|
||||
- compatible : Should be "ti,irq-crossbar"
|
||||
- reg: Base address and the size of the crossbar registers.
|
||||
- ti,max-irqs: Total number of irqs available at the interrupt controller.
|
||||
- interrupt-controller: indicates that this block is an interrupt controller.
|
||||
- interrupt-parent: the interrupt controller this block is connected to.
|
||||
- ti,max-irqs: Total number of irqs available at the parent interrupt controller.
|
||||
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
|
||||
- ti,reg-size: Size of a individual register in bytes. Every individual
|
||||
register is assumed to be of same size. Valid sizes are 1, 2, 4.
|
||||
|
|
@ -27,13 +29,13 @@ Optional properties:
|
|||
when the interrupt controller irq is unused (when not provided, default is 0)
|
||||
|
||||
Examples:
|
||||
crossbar_mpu: @4a020000 {
|
||||
crossbar_mpu: crossbar@4a002a48 {
|
||||
compatible = "ti,irq-crossbar";
|
||||
reg = <0x4a002a48 0x130>;
|
||||
ti,max-irqs = <160>;
|
||||
ti,max-crossbar-sources = <400>;
|
||||
ti,reg-size = <2>;
|
||||
ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
|
||||
ti,irqs-reserved = <0 1 2 3 5 6 131 132>;
|
||||
ti,irqs-skip = <10 133 139 140>;
|
||||
};
|
||||
|
||||
|
|
@ -44,10 +46,6 @@ Documentation/devicetree/bindings/arm/gic.txt for further details.
|
|||
|
||||
An interrupt consumer on an SoC using crossbar will use:
|
||||
interrupts = <GIC_SPI request_number interrupt_level>
|
||||
When the request number is between 0 to that described by
|
||||
"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
|
||||
request_number is greater than "ti,max-crossbar-sources", then it is mapped as a
|
||||
quirky hardware mapping direct to GIC.
|
||||
|
||||
Example:
|
||||
device_x@0x4a023000 {
|
||||
|
|
@ -55,9 +53,3 @@ Example:
|
|||
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
|
||||
...
|
||||
};
|
||||
|
||||
device_y@0x4a033000 {
|
||||
/* Direct mapped GIC SPI 1 used */
|
||||
interrupts = <GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH>;
|
||||
...
|
||||
};
|
||||
|
|
|
|||
|
|
@ -18,12 +18,21 @@ Required properties:
|
|||
"arm,arm11mpcore-pmu"
|
||||
"arm,arm1176-pmu"
|
||||
"arm,arm1136-pmu"
|
||||
"qcom,scorpion-pmu"
|
||||
"qcom,scorpion-mp-pmu"
|
||||
"qcom,krait-pmu"
|
||||
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
|
||||
interrupt (PPI) then 1 interrupt should be specified.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- interrupt-affinity : Valid only when using SPIs, specifies a list of phandles
|
||||
to CPU nodes corresponding directly to the affinity of
|
||||
the SPIs listed in the interrupts property.
|
||||
|
||||
This property should be present when there is more than
|
||||
a single SPI.
|
||||
|
||||
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
|
||||
events.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,10 +29,27 @@ Properties:
|
|||
- clocks : list of phandles and specifiers to all input clocks listed in
|
||||
clock-names property.
|
||||
|
||||
Optional properties:
|
||||
|
||||
Some PMUs are capable of behaving as an interrupt controller (mostly
|
||||
to wake up a suspended PMU). In which case, they can have the
|
||||
following properties:
|
||||
|
||||
- interrupt-controller: indicate that said PMU is an interrupt controller
|
||||
|
||||
- #interrupt-cells: must be identical to the that of the parent interrupt
|
||||
controller.
|
||||
|
||||
- interrupt-parent: a phandle indicating which interrupt controller
|
||||
this PMU signals interrupts to.
|
||||
|
||||
Example :
|
||||
pmu_system_controller: system-controller@10040000 {
|
||||
compatible = "samsung,exynos5250-pmu", "syscon";
|
||||
reg = <0x10040000 0x5000>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-parent = <&gic>;
|
||||
#clock-cells = <1>;
|
||||
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
|
||||
"clkout4", "clkout8", "clkout9";
|
||||
|
|
|
|||
|
|
@ -13,6 +13,10 @@ Boards with the ST STiH407 SoC shall have the following properties:
|
|||
Required root node property:
|
||||
compatible = "st,stih407";
|
||||
|
||||
Boards with the ST STiH410 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih410";
|
||||
|
||||
Boards with the ST STiH418 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih418";
|
||||
|
|
|
|||
|
|
@ -5,9 +5,12 @@ Required properties:
|
|||
Tegra30, must contain "nvidia,tegra30-ahb". Otherwise, must contain
|
||||
'"nvidia,<chip>-ahb", "nvidia,tegra30-ahb"' where <chip> is tegra124,
|
||||
tegra132, or tegra210.
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- reg : Should contain 1 register ranges(address and length). For
|
||||
Tegra20, Tegra30, and Tegra114 chips, the value must be <0x6000c004
|
||||
0x10c>. For Tegra124, Tegra132 and Tegra210 chips, the value should
|
||||
be be <0x6000c000 0x150>.
|
||||
|
||||
Example:
|
||||
Example (for a Tegra20 chip):
|
||||
ahb: ahb@6000c004 {
|
||||
compatible = "nvidia,tegra20-ahb";
|
||||
reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
|
||||
|
|
|
|||
|
|
@ -3,29 +3,48 @@ STMicroelectronics STi SATA controller
|
|||
This binding describes a SATA device.
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "st,sti-ahci"
|
||||
- compatible : Must be "st,ahci"
|
||||
- reg : Physical base addresses and length of register sets
|
||||
- interrupts : Interrupt associated with the SATA device
|
||||
- interrupt-names : Associated name must be; "hostc"
|
||||
- resets : The power-down and soft-reset lines of SATA IP
|
||||
- reset-names : Associated names must be; "pwr-dwn" and "sw-rst"
|
||||
- clocks : The phandle for the clock
|
||||
- clock-names : Associated name must be; "ahci_clk"
|
||||
- phys : The phandle for the PHY device
|
||||
- phys : The phandle for the PHY port
|
||||
- phy-names : Associated name must be; "ahci_phy"
|
||||
|
||||
Optional properties:
|
||||
- resets : The power-down, soft-reset and power-reset lines of SATA IP
|
||||
- reset-names : Associated names must be; "pwr-dwn", "sw-rst" and "pwr-rst"
|
||||
|
||||
Example:
|
||||
|
||||
/* Example for stih416 */
|
||||
sata0: sata@fe380000 {
|
||||
compatible = "st,sti-ahci";
|
||||
reg = <0xfe380000 0x1000>;
|
||||
interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
|
||||
interrupt-names = "hostc";
|
||||
phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
|
||||
phy-names = "ahci_phy";
|
||||
resets = <&powerdown STIH416_SATA0_POWERDOWN>,
|
||||
compatible = "st,ahci";
|
||||
reg = <0xfe380000 0x1000>;
|
||||
interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
|
||||
interrupt-names = "hostc";
|
||||
phys = <&phy_port0 PHY_TYPE_SATA>;
|
||||
phy-names = "ahci_phy";
|
||||
resets = <&powerdown STIH416_SATA0_POWERDOWN>,
|
||||
<&softreset STIH416_SATA0_SOFTRESET>;
|
||||
reset-names = "pwr-dwn", "sw-rst";
|
||||
clocks = <&clk_s_a0_ls CLK_ICN_REG>;
|
||||
clock-names = "ahci_clk";
|
||||
reset-names = "pwr-dwn", "sw-rst";
|
||||
clocks = <&clk_s_a0_ls CLK_ICN_REG>;
|
||||
clock-names = "ahci_clk";
|
||||
};
|
||||
|
||||
/* Example for stih407 family silicon */
|
||||
sata0: sata@9b20000 {
|
||||
compatible = "st,ahci";
|
||||
reg = <0x9b20000 0x1000>;
|
||||
interrupts = <GIC_SPI 159 IRQ_TYPE_NONE>;
|
||||
interrupt-names = "hostc";
|
||||
phys = <&phy_port0 PHY_TYPE_SATA>;
|
||||
phy-names = "ahci_phy";
|
||||
resets = <&powerdown STIH407_SATA0_POWERDOWN>,
|
||||
<&softreset STIH407_SATA0_SOFTRESET>,
|
||||
<&softreset STIH407_SATA0_PWR_SOFTRESET>;
|
||||
reset-names = "pwr-dwn", "sw-rst", "pwr-rst";
|
||||
clocks = <&clk_s_c0_flexgen CLK_ICN_REG>;
|
||||
clock-names = "ahci_clk";
|
||||
};
|
||||
|
|
|
|||
123
Documentation/devicetree/bindings/clock/pistachio-clock.txt
Normal file
123
Documentation/devicetree/bindings/clock/pistachio-clock.txt
Normal file
|
|
@ -0,0 +1,123 @@
|
|||
Imagination Technologies Pistachio SoC clock controllers
|
||||
========================================================
|
||||
|
||||
Pistachio has four clock controllers (core clock, peripheral clock, peripheral
|
||||
general control, and top general control) which are instantiated individually
|
||||
from the device-tree.
|
||||
|
||||
External clocks:
|
||||
----------------
|
||||
|
||||
There are three external inputs to the clock controllers which should be
|
||||
defined with the following clock-output-names:
|
||||
- "xtal": External 52Mhz oscillator (required)
|
||||
- "audio_clk_in": Alternate audio reference clock (optional)
|
||||
- "enet_clk_in": Alternate ethernet PHY clock (optional)
|
||||
|
||||
Core clock controller:
|
||||
----------------------
|
||||
|
||||
The core clock controller generates clocks for the CPU, RPU (WiFi + BT
|
||||
co-processor), audio, and several peripherals.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "img,pistachio-clk".
|
||||
- reg: Must contain the base address and length of the core clock controller.
|
||||
- #clock-cells: Must be 1. The single cell is the clock identifier.
|
||||
See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
|
||||
- clocks: Must contain an entry for each clock in clock-names.
|
||||
- clock-names: Must include "xtal" (see "External clocks") and
|
||||
"audio_clk_in_gate", "enet_clk_in_gate" which are generated by the
|
||||
top-level general control.
|
||||
|
||||
Example:
|
||||
clk_core: clock-controller@18144000 {
|
||||
compatible = "img,pistachio-clk";
|
||||
reg = <0x18144000 0x800>;
|
||||
clocks = <&xtal>, <&cr_top EXT_CLK_AUDIO_IN>,
|
||||
<&cr_top EXT_CLK_ENET_IN>;
|
||||
clock-names = "xtal", "audio_clk_in_gate", "enet_clk_in_gate";
|
||||
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Peripheral clock controller:
|
||||
----------------------------
|
||||
|
||||
The peripheral clock controller generates clocks for the DDR, ROM, and other
|
||||
peripherals. The peripheral system clock ("periph_sys") generated by the core
|
||||
clock controller is the input clock to the peripheral clock controller.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "img,pistachio-periph-clk".
|
||||
- reg: Must contain the base address and length of the peripheral clock
|
||||
controller.
|
||||
- #clock-cells: Must be 1. The single cell is the clock identifier.
|
||||
See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
|
||||
- clocks: Must contain an entry for each clock in clock-names.
|
||||
- clock-names: Must include "periph_sys", the peripheral system clock generated
|
||||
by the core clock controller.
|
||||
|
||||
Example:
|
||||
clk_periph: clock-controller@18144800 {
|
||||
compatible = "img,pistachio-clk-periph";
|
||||
reg = <0x18144800 0x800>;
|
||||
clocks = <&clk_core CLK_PERIPH_SYS>;
|
||||
clock-names = "periph_sys";
|
||||
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Peripheral general control:
|
||||
---------------------------
|
||||
|
||||
The peripheral general control block generates system interface clocks and
|
||||
resets for various peripherals. It also contains miscellaneous peripheral
|
||||
control registers. The system clock ("sys") generated by the peripheral clock
|
||||
controller is the input clock to the system clock controller.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must include "img,pistachio-periph-cr" and "syscon".
|
||||
- reg: Must contain the base address and length of the peripheral general
|
||||
control registers.
|
||||
- #clock-cells: Must be 1. The single cell is the clock identifier.
|
||||
See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
|
||||
- clocks: Must contain an entry for each clock in clock-names.
|
||||
- clock-names: Must include "sys", the system clock generated by the peripheral
|
||||
clock controller.
|
||||
|
||||
Example:
|
||||
cr_periph: syscon@18144800 {
|
||||
compatible = "img,pistachio-cr-periph", "syscon";
|
||||
reg = <0x18148000 0x1000>;
|
||||
clocks = <&clock_periph PERIPH_CLK_PERIPH_SYS>;
|
||||
clock-names = "sys";
|
||||
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Top-level general control:
|
||||
--------------------------
|
||||
|
||||
The top-level general control block contains miscellaneous control registers and
|
||||
gates for the external clocks "audio_clk_in" and "enet_clk_in".
|
||||
|
||||
Required properties:
|
||||
- compatible: Must include "img,pistachio-cr-top" and "syscon".
|
||||
- reg: Must contain the base address and length of the top-level
|
||||
control registers.
|
||||
- clocks: Must contain an entry for each clock in clock-names.
|
||||
- clock-names: Two optional clocks, "audio_clk_in" and "enet_clk_in" (see
|
||||
"External clocks").
|
||||
- #clock-cells: Must be 1. The single cell is the clock identifier.
|
||||
See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
|
||||
|
||||
Example:
|
||||
cr_top: syscon@18144800 {
|
||||
compatible = "img,pistachio-cr-top", "syscon";
|
||||
reg = <0x18149000 0x200>;
|
||||
clocks = <&audio_refclk>, <&ext_enet_in>;
|
||||
clock-names = "audio_clk_in", "enet_clk_in";
|
||||
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
27
Documentation/devicetree/bindings/crypto/img-hash.txt
Normal file
27
Documentation/devicetree/bindings/crypto/img-hash.txt
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
Imagination Technologies hardware hash accelerator
|
||||
|
||||
The hash accelerator provides hardware hashing acceleration for
|
||||
SHA1, SHA224, SHA256 and MD5 hashes
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "img,hash-accelerator"
|
||||
- reg : Offset and length of the register set for the module, and the DMA port
|
||||
- interrupts : The designated IRQ line for the hashing module.
|
||||
- dmas : DMA specifier as per Documentation/devicetree/bindings/dma/dma.txt
|
||||
- dma-names : Should be "tx"
|
||||
- clocks : Clock specifiers
|
||||
- clock-names : "sys" Used to clock the hash block registers
|
||||
"hash" Used to clock data through the accelerator
|
||||
|
||||
Example:
|
||||
|
||||
hash: hash@18149600 {
|
||||
compatible = "img,hash-accelerator";
|
||||
reg = <0x18149600 0x100>, <0x18101100 0x4>;
|
||||
interrupts = <GIC_SHARED 59 IRQ_TYPE_LEVEL_HIGH>;
|
||||
dmas = <&dma 8 0xffffffff 0>;
|
||||
dma-names = "tx";
|
||||
clocks = <&cr_periph SYS_CLK_HASH>, <&clk_periph PERIPH_CLK_ROM>;
|
||||
clock-names = "sys", "hash";
|
||||
};
|
||||
|
|
@ -44,23 +44,30 @@ Optional properties:
|
|||
LVDS Channel
|
||||
============
|
||||
|
||||
Each LVDS Channel has to contain a display-timings node that describes the
|
||||
video timings for the connected LVDS display. For detailed information, also
|
||||
have a look at Documentation/devicetree/bindings/video/display-timing.txt.
|
||||
Each LVDS Channel has to contain either an of graph link to a panel device node
|
||||
or a display-timings node that describes the video timings for the connected
|
||||
LVDS display as well as the fsl,data-mapping and fsl,data-width properties.
|
||||
|
||||
Required properties:
|
||||
- reg : should be <0> or <1>
|
||||
- port: Input and output port nodes with endpoint definitions as defined in
|
||||
Documentation/devicetree/bindings/graph.txt.
|
||||
On i.MX5, the internal two-input-multiplexer is used. Due to hardware
|
||||
limitations, only one input port (port@[0,1]) can be used for each channel
|
||||
(lvds-channel@[0,1], respectively).
|
||||
On i.MX6, there should be four input ports (port@[0-3]) that correspond
|
||||
to the four LVDS multiplexer inputs.
|
||||
A single output port (port@2 on i.MX5, port@4 on i.MX6) must be connected
|
||||
to a panel input port. Optionally, the output port can be left out if
|
||||
display-timings are used instead.
|
||||
|
||||
Optional properties (required if display-timings are used):
|
||||
- display-timings : A node that describes the display timings as defined in
|
||||
Documentation/devicetree/bindings/video/display-timing.txt.
|
||||
- fsl,data-mapping : should be "spwg" or "jeida"
|
||||
This describes how the color bits are laid out in the
|
||||
serialized LVDS signal.
|
||||
- fsl,data-width : should be <18> or <24>
|
||||
- port: A port node with endpoint definitions as defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
On i.MX5, the internal two-input-multiplexer is used.
|
||||
Due to hardware limitations, only one port (port@[0,1])
|
||||
can be used for each channel (lvds-channel@[0,1], respectively)
|
||||
On i.MX6, there should be four ports (port@[0-3]) that correspond
|
||||
to the four LVDS multiplexer inputs.
|
||||
|
||||
example:
|
||||
|
||||
|
|
@ -73,23 +80,21 @@ ldb: ldb@53fa8008 {
|
|||
#size-cells = <0>;
|
||||
compatible = "fsl,imx53-ldb";
|
||||
gpr = <&gpr>;
|
||||
clocks = <&clks 122>, <&clks 120>,
|
||||
<&clks 115>, <&clks 116>,
|
||||
<&clks 123>, <&clks 85>;
|
||||
clocks = <&clks IMX5_CLK_LDB_DI0_SEL>,
|
||||
<&clks IMX5_CLK_LDB_DI1_SEL>,
|
||||
<&clks IMX5_CLK_IPU_DI0_SEL>,
|
||||
<&clks IMX5_CLK_IPU_DI1_SEL>,
|
||||
<&clks IMX5_CLK_LDB_DI0_GATE>,
|
||||
<&clks IMX5_CLK_LDB_DI1_GATE>;
|
||||
clock-names = "di0_pll", "di1_pll",
|
||||
"di0_sel", "di1_sel",
|
||||
"di0", "di1";
|
||||
|
||||
/* Using an of-graph endpoint link to connect the panel */
|
||||
lvds-channel@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
fsl,data-mapping = "spwg";
|
||||
fsl,data-width = <24>;
|
||||
|
||||
display-timings {
|
||||
/* ... */
|
||||
};
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
|
@ -98,8 +103,17 @@ ldb: ldb@53fa8008 {
|
|||
remote-endpoint = <&ipu_di0_lvds0>;
|
||||
};
|
||||
};
|
||||
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
|
||||
lvds0_out: endpoint {
|
||||
remote-endpoint = <&panel_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* Using display-timings and fsl,data-mapping/width instead */
|
||||
lvds-channel@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
@ -120,3 +134,13 @@ ldb: ldb@53fa8008 {
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
panel: lvds-panel {
|
||||
/* ... */
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds0_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
43
Documentation/devicetree/bindings/gpio/gpio-altera.txt
Normal file
43
Documentation/devicetree/bindings/gpio/gpio-altera.txt
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
Altera GPIO controller bindings
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
- "altr,pio-1.0"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- #gpio-cells : Should be 2
|
||||
- The first cell is the gpio offset number.
|
||||
- The second cell is reserved and is currently unused.
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- interrupt-controller: Mark the device node as an interrupt controller
|
||||
- #interrupt-cells : Should be 1. The interrupt type is fixed in the hardware.
|
||||
- The first cell is the GPIO offset number within the GPIO controller.
|
||||
- interrupts: Specify the interrupt.
|
||||
- altr,interrupt-trigger: Specifies the interrupt trigger type the GPIO
|
||||
hardware is synthesized. This field is required if the Altera GPIO controller
|
||||
used has IRQ enabled as the interrupt type is not software controlled,
|
||||
but hardware synthesized. Required if GPIO is used as an interrupt
|
||||
controller. The value is defined in <dt-bindings/interrupt-controller/irq.h>
|
||||
Only the following flags are supported:
|
||||
IRQ_TYPE_EDGE_RISING
|
||||
IRQ_TYPE_EDGE_FALLING
|
||||
IRQ_TYPE_EDGE_BOTH
|
||||
IRQ_TYPE_LEVEL_HIGH
|
||||
|
||||
Optional properties:
|
||||
- altr,ngpio: Width of the GPIO bank. This defines how many pins the
|
||||
GPIO device has. Ranges between 1-32. Optional and defaults to 32 if not
|
||||
specified.
|
||||
|
||||
Example:
|
||||
|
||||
gpio_altr: gpio@0xff200000 {
|
||||
compatible = "altr,pio-1.0";
|
||||
reg = <0xff200000 0x10>;
|
||||
interrupts = <0 45 4>;
|
||||
altr,ngpio = <32>;
|
||||
altr,interrupt-trigger = <IRQ_TYPE_EDGE_RISING>;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
@ -2,15 +2,20 @@ Bindings for fan connected to GPIO lines
|
|||
|
||||
Required properties:
|
||||
- compatible : "gpio-fan"
|
||||
|
||||
Optional properties:
|
||||
- gpios: Specifies the pins that map to bits in the control value,
|
||||
ordered MSB-->LSB.
|
||||
- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
|
||||
control value that should be set to achieve them. This array
|
||||
must have the RPM values in ascending order.
|
||||
|
||||
Optional properties:
|
||||
- alarm-gpios: This pin going active indicates something is wrong with
|
||||
the fan, and a udev event will be fired.
|
||||
- cooling-cells: If used as a cooling device, must be <2>
|
||||
Also see: Documentation/devicetree/bindings/thermal/thermal.txt
|
||||
min and max states are derived from the speed-map of the fan.
|
||||
|
||||
Note: At least one the "gpios" or "alarm-gpios" properties must be set.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
@ -23,3 +28,13 @@ Examples:
|
|||
6000 2>;
|
||||
alarm-gpios = <&gpio1 15 1>;
|
||||
};
|
||||
gpio_fan_cool: gpio_fan {
|
||||
compatible = "gpio-fan";
|
||||
gpios = <&gpio2 14 1
|
||||
&gpio2 13 1>;
|
||||
gpio-fan,speed-map = <0 0>,
|
||||
<3000 1>,
|
||||
<6000 2>;
|
||||
alarm-gpios = <&gpio2 15 1>;
|
||||
#cooling-cells = <2>; /* min followed by max */
|
||||
};
|
||||
|
|
|
|||
|
|
@ -116,6 +116,29 @@ Every GPIO controller node must contain both an empty "gpio-controller"
|
|||
property, and a #gpio-cells integer property, which indicates the number of
|
||||
cells in a gpio-specifier.
|
||||
|
||||
The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
|
||||
providing automatic GPIO request and configuration as part of the
|
||||
gpio-controller's driver probe function.
|
||||
|
||||
Each GPIO hog definition is represented as a child node of the GPIO controller.
|
||||
Required properties:
|
||||
- gpio-hog: A property specifying that this child node represent a GPIO hog.
|
||||
- gpios: Store the GPIO information (id, flags, ...). Shall contain the
|
||||
number of cells specified in its parent node (GPIO controller
|
||||
node).
|
||||
Only one of the following properties scanned in the order shown below.
|
||||
This means that when multiple properties are present they will be searched
|
||||
in the order presented below and the first match is taken as the intended
|
||||
configuration.
|
||||
- input: A property specifying to set the GPIO direction as input.
|
||||
- output-low A property specifying to set the GPIO direction as output with
|
||||
the value low.
|
||||
- output-high A property specifying to set the GPIO direction as output with
|
||||
the value high.
|
||||
|
||||
Optional properties:
|
||||
- line-name: The GPIO label name. If not present the node name is used.
|
||||
|
||||
Example of two SOC GPIO banks defined as gpio-controller nodes:
|
||||
|
||||
qe_pio_a: gpio-controller@1400 {
|
||||
|
|
@ -123,6 +146,13 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
|
|||
reg = <0x1400 0x18>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
||||
line_b {
|
||||
gpio-hog;
|
||||
gpios = <6 0>;
|
||||
output-low;
|
||||
line-name = "foo-bar-gpio";
|
||||
};
|
||||
};
|
||||
|
||||
qe_pio_e: gpio-controller@1460 {
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Required properties:
|
|||
gpio_mux.
|
||||
- interrupt-names : Should be the names of irq resources. Each interrupt
|
||||
uses its own interrupt name, so there should be as many interrupt names
|
||||
as referenced interrups.
|
||||
as referenced interrupts.
|
||||
- interrupt-controller : Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
HWRNG support for the iproc-rng200 driver
|
||||
|
||||
Required properties:
|
||||
- compatible : "brcm,iproc-rng200"
|
||||
- reg : base address and size of control register block
|
||||
|
||||
Example:
|
||||
|
||||
rng {
|
||||
compatible = "brcm,iproc-rng200";
|
||||
reg = <0x18032000 0x28>;
|
||||
};
|
||||
|
|
@ -10,6 +10,9 @@ Required properties:
|
|||
Recommended properties :
|
||||
- interrupts : standard interrupt property.
|
||||
- clock-frequency : desired I2C bus clock frequency in Hz.
|
||||
- ti,has-pfunc: boolean; if defined, it indicates that SoC supports PFUNC
|
||||
registers. PFUNC registers allow to switch I2C pins to function as
|
||||
GPIOs, so they can by toggled manually.
|
||||
|
||||
Example (enbw_cmc board):
|
||||
i2c@1c22000 {
|
||||
|
|
|
|||
25
Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
Normal file
25
Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
Conexant Digicolor I2C controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "cnxt,cx92755-i2c"
|
||||
- reg: physical address and length of the device registers
|
||||
- interrupts: a single interrupt specifier
|
||||
- clocks: clock for the device
|
||||
- #address-cells: should be <1>
|
||||
- #size-cells: should be <0>
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency: the desired I2C bus clock frequency in Hz; in
|
||||
absence of this property the default value is used (100 kHz).
|
||||
|
||||
Example:
|
||||
|
||||
i2c: i2c@f0000120 {
|
||||
compatible = "cnxt,cx92755-i2c";
|
||||
reg = <0xf0000120 0x10>;
|
||||
interrupts = <28>;
|
||||
clocks = <&main_clk>;
|
||||
clock-frequency = <100000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
|
@ -7,6 +7,7 @@ Required properties:
|
|||
- "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC
|
||||
- reg : Should contain I2C/HS-I2C registers location and length
|
||||
- interrupts : Should contain I2C/HS-I2C interrupt
|
||||
- clocks : Should contain the I2C/HS-I2C clock specifier
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||
|
|
|
|||
35
Documentation/devicetree/bindings/i2c/i2c-jz4780.txt
Normal file
35
Documentation/devicetree/bindings/i2c/i2c-jz4780.txt
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
* Ingenic JZ4780 I2C Bus controller
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "ingenic,jz4780-i2c"
|
||||
- reg: Should contain the address & size of the I2C controller registers.
|
||||
- interrupts: Should specify the interrupt provided by parent.
|
||||
- clocks: Should contain a single clock specifier for the JZ4780 I2C clock.
|
||||
- clock-frequency: desired I2C bus clock frequency in Hz.
|
||||
|
||||
Recommended properties:
|
||||
- pinctrl-names: should be "default";
|
||||
- pinctrl-0: phandle to pinctrl function
|
||||
|
||||
Optional properties:
|
||||
- interrupt-parent: Should be the phandle of the interrupt controller that
|
||||
delivers interrupts to the I2C block.
|
||||
|
||||
Example
|
||||
|
||||
/ {
|
||||
i2c4: i2c4@0x10054000 {
|
||||
compatible = "ingenic,jz4780-i2c";
|
||||
reg = <0x10054000 0x1000>;
|
||||
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <56>;
|
||||
|
||||
clocks = <&cgu JZ4780_CLK_SMB4>;
|
||||
clock-frequency = <100000>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pins_i2c4_data>;
|
||||
|
||||
};
|
||||
};
|
||||
|
||||
22
Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
Normal file
22
Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
Device tree configuration for the I2C controller on the XLP9xx/5xx SoC
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "netlogic,xlp980-i2c"
|
||||
- reg : bus address start and address range size of device
|
||||
- interrupts : interrupt number
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : frequency of bus clock in Hz
|
||||
Defaults to 100 KHz when the property is not specified
|
||||
|
||||
Example:
|
||||
|
||||
i2c0: i2c@113100 {
|
||||
compatible = "netlogic,xlp980-i2c";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0 0x113100 0x100>;
|
||||
clock-frequency = <400000>;
|
||||
interrupts = <30>;
|
||||
interrupt-parent = <&pic>;
|
||||
};
|
||||
|
|
@ -89,6 +89,7 @@ ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
|||
ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
|
||||
sii,s35390a 2-wire CMOS real-time clock
|
||||
skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply
|
||||
st-micro,24c256 i2c serial eeprom (24cxx)
|
||||
stm,m41t00 Serial Access TIMEKEEPER
|
||||
stm,m41t62 Serial real-time clock (RTC) with alarm
|
||||
|
|
|
|||
16
Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt
Normal file
16
Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
Dialog Semiconductor DA9150 IIO GPADC bindings
|
||||
|
||||
Required properties:
|
||||
- compatible: "dlg,da9150-gpadc" for DA9150 IIO GPADC
|
||||
- #io-channel-cells: Should be set to <1>
|
||||
(See Documentation/devicetree/bindings/iio/iio-bindings.txt for further info)
|
||||
|
||||
For further information on GPADC channels, see device datasheet.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
gpadc: da9150-gpadc {
|
||||
compatible = "dlg,da9150-gpadc";
|
||||
#io-channel-cells = <1>;
|
||||
};
|
||||
30
Documentation/devicetree/bindings/iio/adc/mcp320x.txt
Normal file
30
Documentation/devicetree/bindings/iio/adc/mcp320x.txt
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
* Microchip Analog to Digital Converter (ADC)
|
||||
|
||||
The node for this driver must be a child node of a SPI controller, hence
|
||||
all mandatory properties described in
|
||||
|
||||
Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
|
||||
must be specified.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of the following, depending on the
|
||||
model:
|
||||
"mcp3001"
|
||||
"mcp3002"
|
||||
"mcp3004"
|
||||
"mcp3008"
|
||||
"mcp3201"
|
||||
"mcp3202"
|
||||
"mcp3204"
|
||||
"mcp3208"
|
||||
|
||||
|
||||
Examples:
|
||||
spi_controller {
|
||||
mcp3x0x@0 {
|
||||
compatible = "mcp3002";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <1000000>;
|
||||
};
|
||||
};
|
||||
17
Documentation/devicetree/bindings/iio/adc/mcp3422.txt
Normal file
17
Documentation/devicetree/bindings/iio/adc/mcp3422.txt
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
* Microchip mcp3422/3/4/6/7/8 chip family (ADC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be
|
||||
"microchip,mcp3422" or
|
||||
"microchip,mcp3423" or
|
||||
"microchip,mcp3424" or
|
||||
"microchip,mcp3426" or
|
||||
"microchip,mcp3427" or
|
||||
"microchip,mcp3428"
|
||||
- reg: I2C address for the device
|
||||
|
||||
Example:
|
||||
adc@0 {
|
||||
compatible = "microchip,mcp3424";
|
||||
reg = <0x68>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt
Normal file
18
Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
* Texas Instruments' ADC128S052 ADC chip
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "ti,adc128s052"
|
||||
- reg: spi chip select number for the device
|
||||
- vref-supply: The regulator supply for ADC reference voltage
|
||||
|
||||
Recommended properties:
|
||||
- spi-max-frequency: Definition as per
|
||||
Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
|
||||
Example:
|
||||
adc@0 {
|
||||
compatible = "ti,adc128s052";
|
||||
reg = <0>;
|
||||
vref-supply = <&vdd_supply>;
|
||||
spi-max-frequency = <1000000>;
|
||||
};
|
||||
|
|
@ -23,6 +23,7 @@ standard bindings from pinctrl/pinctrl-bindings.txt.
|
|||
Valid compatible strings:
|
||||
|
||||
Accelerometers:
|
||||
- st,lis3lv02dl-accel
|
||||
- st,lsm303dlh-accel
|
||||
- st,lsm303dlhc-accel
|
||||
- st,lis3dh-accel
|
||||
|
|
|
|||
108
Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
Normal file
108
Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
Normal file
|
|
@ -0,0 +1,108 @@
|
|||
* Broadcom Keypad Controller device tree bindings
|
||||
|
||||
Broadcom Keypad controller is used to interface a SoC with a matrix-type
|
||||
keypad device. The keypad controller supports multiple row and column lines.
|
||||
A key can be placed at each intersection of a unique row and a unique column.
|
||||
The keypad controller can sense a key-press and key-release and report the
|
||||
event using a interrupt to the cpu.
|
||||
|
||||
This binding is based on the matrix-keymap binding with the following
|
||||
changes:
|
||||
|
||||
keypad,num-rows and keypad,num-columns are required.
|
||||
|
||||
Required SoC Specific Properties:
|
||||
- compatible: should be "brcm,bcm-keypad"
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- interrupts: The interrupt number to the cpu.
|
||||
|
||||
Board Specific Properties:
|
||||
- keypad,num-rows: Number of row lines connected to the keypad
|
||||
controller.
|
||||
|
||||
- keypad,num-columns: Number of column lines connected to the
|
||||
keypad controller.
|
||||
|
||||
- col-debounce-filter-period: The debounce period for the Column filter.
|
||||
|
||||
KEYPAD_DEBOUNCE_1_ms = 0
|
||||
KEYPAD_DEBOUNCE_2_ms = 1
|
||||
KEYPAD_DEBOUNCE_4_ms = 2
|
||||
KEYPAD_DEBOUNCE_8_ms = 3
|
||||
KEYPAD_DEBOUNCE_16_ms = 4
|
||||
KEYPAD_DEBOUNCE_32_ms = 5
|
||||
KEYPAD_DEBOUNCE_64_ms = 6
|
||||
KEYPAD_DEBOUNCE_128_ms = 7
|
||||
|
||||
- status-debounce-filter-period: The debounce period for the Status filter.
|
||||
|
||||
KEYPAD_DEBOUNCE_1_ms = 0
|
||||
KEYPAD_DEBOUNCE_2_ms = 1
|
||||
KEYPAD_DEBOUNCE_4_ms = 2
|
||||
KEYPAD_DEBOUNCE_8_ms = 3
|
||||
KEYPAD_DEBOUNCE_16_ms = 4
|
||||
KEYPAD_DEBOUNCE_32_ms = 5
|
||||
KEYPAD_DEBOUNCE_64_ms = 6
|
||||
KEYPAD_DEBOUNCE_128_ms = 7
|
||||
|
||||
- row-output-enabled: An optional property indicating whether the row or
|
||||
column is being used as output. If specified the row is being used
|
||||
as the output. Else defaults to column.
|
||||
|
||||
- pull-up-enabled: An optional property indicating the Keypad scan mode.
|
||||
If specified implies the keypad scan pull-up has been enabled.
|
||||
|
||||
- autorepeat: Boolean, Enable auto repeat feature of Linux input
|
||||
subsystem (optional).
|
||||
|
||||
- linux,keymap: The keymap for keys as described in the binding document
|
||||
devicetree/bindings/input/matrix-keymap.txt.
|
||||
|
||||
Example:
|
||||
#include "dt-bindings/input/input.h"
|
||||
|
||||
/ {
|
||||
keypad: keypad@180ac000 {
|
||||
/* Required SoC specific properties */
|
||||
compatible = "brcm,bcm-keypad";
|
||||
|
||||
/* Required Board specific properties */
|
||||
keypad,num-rows = <5>;
|
||||
keypad,num-columns = <5>;
|
||||
status = "okay";
|
||||
|
||||
linux,keymap = <MATRIX_KEY(0x00, 0x02, KEY_F) /* key_forward */
|
||||
MATRIX_KEY(0x00, 0x03, KEY_HOME) /* key_home */
|
||||
MATRIX_KEY(0x00, 0x04, KEY_M) /* key_message */
|
||||
MATRIX_KEY(0x01, 0x00, KEY_A) /* key_contacts */
|
||||
MATRIX_KEY(0x01, 0x01, KEY_1) /* key_1 */
|
||||
MATRIX_KEY(0x01, 0x02, KEY_2) /* key_2 */
|
||||
MATRIX_KEY(0x01, 0x03, KEY_3) /* key_3 */
|
||||
MATRIX_KEY(0x01, 0x04, KEY_S) /* key_speaker */
|
||||
MATRIX_KEY(0x02, 0x00, KEY_P) /* key_phone */
|
||||
MATRIX_KEY(0x02, 0x01, KEY_4) /* key_4 */
|
||||
MATRIX_KEY(0x02, 0x02, KEY_5) /* key_5 */
|
||||
MATRIX_KEY(0x02, 0x03, KEY_6) /* key_6 */
|
||||
MATRIX_KEY(0x02, 0x04, KEY_VOLUMEUP) /* key_vol_up */
|
||||
MATRIX_KEY(0x03, 0x00, KEY_C) /* key_call_log */
|
||||
MATRIX_KEY(0x03, 0x01, KEY_7) /* key_7 */
|
||||
MATRIX_KEY(0x03, 0x02, KEY_8) /* key_8 */
|
||||
MATRIX_KEY(0x03, 0x03, KEY_9) /* key_9 */
|
||||
MATRIX_KEY(0x03, 0x04, KEY_VOLUMEDOWN) /* key_vol_down */
|
||||
MATRIX_KEY(0x04, 0x00, KEY_H) /* key_headset */
|
||||
MATRIX_KEY(0x04, 0x01, KEY_KPASTERISK) /* key_* */
|
||||
MATRIX_KEY(0x04, 0x02, KEY_0) /* key_0 */
|
||||
MATRIX_KEY(0x04, 0x03, KEY_GRAVE) /* key_# */
|
||||
MATRIX_KEY(0x04, 0x04, KEY_MUTE) /* key_mute */
|
||||
>;
|
||||
|
||||
/* Optional board specific properties */
|
||||
col-debounce-filter-period = <5>;
|
||||
row-output-enabled;
|
||||
pull-up-enabled;
|
||||
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
Qualcomm PM8941 PMIC Power Key
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be one of:
|
||||
"qcom,pm8941-pwrkey"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: base address of registers for block
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: key change interrupt; The format of the specifier is
|
||||
defined by the binding document describing the node's
|
||||
interrupt parent.
|
||||
|
||||
- debounce:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: time in microseconds that key must be pressed or released
|
||||
for state change interrupt to trigger.
|
||||
|
||||
- bias-pull-up:
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
Definition: presence of this property indicates that the KPDPWR_N pin
|
||||
should be configured for pull up.
|
||||
|
||||
EXAMPLE
|
||||
|
||||
pwrkey@800 {
|
||||
compatible = "qcom,pm8941-pwrkey";
|
||||
reg = <0x800>;
|
||||
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
|
||||
debounce = <15625>;
|
||||
bias-pull-up;
|
||||
};
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
* Broadcom's IPROC Touchscreen Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "brcm,iproc-touchscreen"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- clocks: The clock provided by the SOC to driver the tsc
|
||||
- clock-name: name for the clock
|
||||
- interrupts: The touchscreen controller's interrupt
|
||||
|
||||
Optional properties:
|
||||
- scanning_period: Time between scans. Each step is 1024 us. Valid 1-256.
|
||||
- debounce_timeout: Each step is 512 us. Valid 0-255
|
||||
- settling_timeout: The settling duration (in ms) is the amount of time
|
||||
the tsc waits to allow the voltage to settle after
|
||||
turning on the drivers in detection mode.
|
||||
Valid values: 0-11
|
||||
0 = 0.008 ms
|
||||
1 = 0.01 ms
|
||||
2 = 0.02 ms
|
||||
3 = 0.04 ms
|
||||
4 = 0.08 ms
|
||||
5 = 0.16 ms
|
||||
6 = 0.32 ms
|
||||
7 = 0.64 ms
|
||||
8 = 1.28 ms
|
||||
9 = 2.56 ms
|
||||
10 = 5.12 ms
|
||||
11 = 10.24 ms
|
||||
- touch_timeout: The continuous number of scan periods in which touch is
|
||||
not detected before the controller returns to idle state.
|
||||
Valid values 0-255.
|
||||
- average_data: Number of data samples which are averaged before a final
|
||||
data point is placed into the FIFO
|
||||
Valid values 0-7
|
||||
0 = 1 sample
|
||||
1 = 2 samples
|
||||
2 = 4 samples
|
||||
3 = 8 samples
|
||||
4 = 16 samples
|
||||
5 = 32 samples
|
||||
6 = 64 samples
|
||||
7 = 128 samples
|
||||
- fifo_threshold: Interrupt is generated whenever the number of fifo
|
||||
entries exceeds this value
|
||||
Valid values 0-31
|
||||
- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
|
||||
- touchscreen-size-y: vertical resolution of touchscreen (in pixels)
|
||||
- touchscreen-fuzz-x: horizontal noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-fuzz-y: vertical noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-inverted-x: X axis is inverted (boolean)
|
||||
- touchscreen-inverted-y: Y axis is inverted (boolean)
|
||||
|
||||
Example:
|
||||
|
||||
touchscreen: tsc@0x180A6000 {
|
||||
compatible = "brcm,iproc-touchscreen";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x180A6000 0x40>;
|
||||
clocks = <&adc_clk>;
|
||||
clock-names = "tsc_clk";
|
||||
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
scanning_period = <5>;
|
||||
debounce_timeout = <40>;
|
||||
settling_timeout = <7>;
|
||||
touch_timeout = <10>;
|
||||
average_data = <5>;
|
||||
fifo_threshold = <1>;
|
||||
/* Touchscreen is rotated 180 degrees. */
|
||||
touchscreen-inverted-x;
|
||||
touchscreen-inverted-y;
|
||||
};
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
* ChipOne icn8318 I2C touchscreen controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "chipone,icn8318"
|
||||
- reg : I2C slave address of the chip (0x40)
|
||||
- interrupt-parent : a phandle pointing to the interrupt controller
|
||||
serving the interrupt for this chip
|
||||
- interrupts : interrupt specification for the icn8318 interrupt
|
||||
- wake-gpios : GPIO specification for the WAKE input
|
||||
- touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
|
||||
- touchscreen-size-y : vertical resolution of touchscreen (in pixels)
|
||||
|
||||
Optional properties:
|
||||
- pinctrl-names : should be "default"
|
||||
- pinctrl-0: : a phandle pointing to the pin settings for the
|
||||
control gpios
|
||||
- touchscreen-fuzz-x : horizontal noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-fuzz-y : vertical noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-inverted-x : X axis is inverted (boolean)
|
||||
- touchscreen-inverted-y : Y axis is inverted (boolean)
|
||||
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
|
||||
Swapping is done after inverting the axis
|
||||
|
||||
Example:
|
||||
|
||||
i2c@00000000 {
|
||||
/* ... */
|
||||
|
||||
chipone_icn8318@40 {
|
||||
compatible = "chipone,icn8318";
|
||||
reg = <0x40>;
|
||||
interrupt-parent = <&pio>;
|
||||
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ts_wake_pin_p66>;
|
||||
wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <480>;
|
||||
touchscreen-inverted-x;
|
||||
touchscreen-swapped-x-y;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
Device tree bindings for Goodix GT9xx series touchscreen controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "goodix,gt911"
|
||||
or "goodix,gt9110"
|
||||
or "goodix,gt912"
|
||||
or "goodix,gt927"
|
||||
or "goodix,gt9271"
|
||||
or "goodix,gt928"
|
||||
or "goodix,gt967"
|
||||
- reg : I2C address of the chip. Should be 0x5d or 0x14
|
||||
- interrupt-parent : Interrupt controller to which the chip is connected
|
||||
- interrupts : Interrupt to which the chip is connected
|
||||
|
||||
Example:
|
||||
|
||||
i2c@00000000 {
|
||||
/* ... */
|
||||
|
||||
gt928@5d {
|
||||
compatible = "goodix,gt928";
|
||||
reg = <0x5d>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <0 0>;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
||||
|
|
@ -2,14 +2,27 @@ sun4i resistive touchscreen controller
|
|||
--------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: "allwinner,sun4i-a10-ts" or "allwinner,sun6i-a31-ts"
|
||||
- compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
|
||||
"allwinner,sun6i-a31-ts"
|
||||
- reg: mmio address range of the chip
|
||||
- interrupts: interrupt to which the chip is connected
|
||||
- #thermal-sensor-cells: shall be 0
|
||||
|
||||
Optional properties:
|
||||
- allwinner,ts-attached: boolean indicating that an actual touchscreen is
|
||||
attached to the controller
|
||||
- allwinner,ts-attached : boolean indicating that an actual touchscreen
|
||||
is attached to the controller
|
||||
- allwinner,tp-sensitive-adjust : integer (4 bits)
|
||||
adjust sensitivity of pen down detection
|
||||
between 0 (least sensitive) and 15
|
||||
(defaults to 15)
|
||||
- allwinner,filter-type : integer (2 bits)
|
||||
select median and averaging filter
|
||||
samples used for median / averaging filter
|
||||
0: 4/2
|
||||
1: 5/3
|
||||
2: 8/4
|
||||
3: 16/8
|
||||
(defaults to 1)
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -19,4 +32,7 @@ Example:
|
|||
interrupts = <29>;
|
||||
allwinner,ts-attached;
|
||||
#thermal-sensor-cells = <0>;
|
||||
/* sensitive/noisy touch panel */
|
||||
allwinner,tp-sensitive-adjust = <0>;
|
||||
allwinner,filter-type = <3>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
* Semtech SX8654 I2C Touchscreen Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "semtech,sx8654"
|
||||
- reg: i2c slave address
|
||||
- interrupt-parent: the phandle for the interrupt controller
|
||||
- interrupts: touch controller interrupt
|
||||
|
||||
Example:
|
||||
|
||||
sx8654@48 {
|
||||
compatible = "semtech,sx8654";
|
||||
reg = <0x48>;
|
||||
interrupt-parent = <&gpio6>;
|
||||
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
|
||||
};
|
||||
|
|
@ -16,6 +16,8 @@ Optional properties for Touchscreens:
|
|||
controller)
|
||||
- touchscreen-inverted-x : X axis is inverted (boolean)
|
||||
- touchscreen-inverted-y : Y axis is inverted (boolean)
|
||||
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
|
||||
Swapping is done after inverting the axis
|
||||
|
||||
Deprecated properties for Touchscreens:
|
||||
- x-size : deprecated name for touchscreen-size-x
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
Broadcom BCM3380-style Level 1 / Level 2 interrupt controller
|
||||
|
||||
This interrupt controller shows up in various forms on many BCM338x/BCM63xx
|
||||
chipsets. It has the following properties:
|
||||
|
||||
- outputs a single interrupt signal to its interrupt controller parent
|
||||
|
||||
- contains one or more enable/status word pairs, which often appear at
|
||||
different offsets in different blocks
|
||||
|
||||
- no atomic set/clear operations
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be "brcm,bcm3380-l2-intc"
|
||||
- reg: specifies one or more enable/status pairs, in the following format:
|
||||
<enable_reg 0x4 status_reg 0x4>...
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
|
||||
source, should be 1.
|
||||
- interrupt-parent: specifies the phandle to the parent interrupt controller
|
||||
this one is cascaded from
|
||||
- interrupts: specifies the interrupt line in the interrupt-parent controller
|
||||
node, valid values depend on the type of parent interrupt controller
|
||||
|
||||
Optional properties:
|
||||
|
||||
- brcm,irq-can-wake: if present, this means the L2 controller can be used as a
|
||||
wakeup source for system suspend/resume.
|
||||
|
||||
Example:
|
||||
|
||||
irq0_intc: interrupt-controller@10000020 {
|
||||
compatible = "brcm,bcm3380-l2-intc";
|
||||
reg = <0x10000024 0x4 0x1000002c 0x4>,
|
||||
<0x10000020 0x4 0x10000028 0x4>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&cpu_intc>;
|
||||
interrupts = <2>;
|
||||
};
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
Broadcom BCM7038-style Level 1 interrupt controller
|
||||
|
||||
This block is a first level interrupt controller that is typically connected
|
||||
directly to one of the HW INT lines on each CPU. Every BCM7xxx set-top chip
|
||||
since BCM7038 has contained this hardware.
|
||||
|
||||
Key elements of the hardware design include:
|
||||
|
||||
- 64, 96, 128, or 160 incoming level IRQ lines
|
||||
|
||||
- Most onchip peripherals are wired directly to an L1 input
|
||||
|
||||
- A separate instance of the register set for each CPU, allowing individual
|
||||
peripheral IRQs to be routed to any CPU
|
||||
|
||||
- Atomic mask/unmask operations
|
||||
|
||||
- No polarity/level/edge settings
|
||||
|
||||
- No FIFO or priority encoder logic; software is expected to read all
|
||||
2-5 status words to determine which IRQs are pending
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be "brcm,bcm7038-l1-intc"
|
||||
- reg: specifies the base physical address and size of the registers;
|
||||
the number of supported IRQs is inferred from the size argument
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
|
||||
source, should be 1.
|
||||
- interrupt-parent: specifies the phandle to the parent interrupt controller(s)
|
||||
this one is cascaded from
|
||||
- interrupts: specifies the interrupt line(s) in the interrupt-parent controller
|
||||
node; valid values depend on the type of parent interrupt controller
|
||||
|
||||
If multiple reg ranges and interrupt-parent entries are present on an SMP
|
||||
system, the driver will allow IRQ SMP affinity to be set up through the
|
||||
/proc/irq/ interface. In the simplest possible configuration, only one
|
||||
reg range and one interrupt-parent is needed.
|
||||
|
||||
Example:
|
||||
|
||||
periph_intc: periph_intc@1041a400 {
|
||||
compatible = "brcm,bcm7038-l1-intc";
|
||||
reg = <0x1041a400 0x30 0x1041a600 0x30>;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
interrupt-parent = <&cpu_intc>;
|
||||
interrupts = <2>, <3>;
|
||||
};
|
||||
|
|
@ -13,8 +13,7 @@ Such an interrupt controller has the following hardware design:
|
|||
or if they will output an interrupt signal at this 2nd level interrupt
|
||||
controller, in particular for UARTs
|
||||
|
||||
- typically has one 32-bit enable word and one 32-bit status word, but on
|
||||
some hardware may have more than one enable/status pair
|
||||
- has one 32-bit enable word and one 32-bit status word
|
||||
|
||||
- no atomic set/clear operations
|
||||
|
||||
|
|
@ -53,9 +52,7 @@ The typical hardware layout for this controller is represented below:
|
|||
Required properties:
|
||||
|
||||
- compatible: should be "brcm,bcm7120-l2-intc"
|
||||
- reg: specifies the base physical address and size of the registers;
|
||||
multiple pairs may be specified, with the first pair handling IRQ offsets
|
||||
0..31 and the second pair handling 32..63
|
||||
- reg: specifies the base physical address and size of the registers
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
|
||||
source, should be 1.
|
||||
|
|
@ -66,10 +63,7 @@ Required properties:
|
|||
- brcm,int-map-mask: 32-bits bit mask describing how many and which interrupts
|
||||
are wired to this 2nd level interrupt controller, and how they match their
|
||||
respective interrupt parents. Should match exactly the number of interrupts
|
||||
specified in the 'interrupts' property, multiplied by the number of
|
||||
enable/status register pairs implemented by this controller. For
|
||||
multiple parent IRQs with multiple enable/status words, this looks like:
|
||||
<irq0_w0 irq0_w1 irq1_w0 irq1_w1 ...>
|
||||
specified in the 'interrupts' property.
|
||||
|
||||
Optional properties:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
* Xtensa Interrupt Distributor and Programmable Interrupt Controller (MX)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "cdns,xtensa-mx".
|
||||
|
||||
Remaining properties have exact same meaning as in Xtensa PIC
|
||||
(see cdns,xtensa-pic.txt).
|
||||
|
||||
Examples:
|
||||
pic: pic {
|
||||
compatible = "cdns,xtensa-mx";
|
||||
/* one cell: internal irq number,
|
||||
* two cells: second cell == 0: internal irq number
|
||||
* second cell == 1: external irq number
|
||||
*/
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
* Xtensa built-in Programmable Interrupt Controller (PIC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "cdns,xtensa-pic".
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: The number of cells to define the interrupts.
|
||||
It may be either 1 or 2.
|
||||
When it's 1, the first cell is the internal IRQ number.
|
||||
When it's 2, the first cell is the IRQ number, and the second cell
|
||||
specifies whether it's internal (0) or external (1).
|
||||
Periferals are usually connected to a fixed external IRQ, but for different
|
||||
core variants it may be mapped to different internal IRQ.
|
||||
IRQ sensitivity and priority are fixed for each core variant and may not be
|
||||
changed at runtime.
|
||||
|
||||
Examples:
|
||||
pic: pic {
|
||||
compatible = "cdns,xtensa-pic";
|
||||
/* one cell: internal irq number,
|
||||
* two cells: second cell == 0: internal irq number
|
||||
* second cell == 1: external irq number
|
||||
*/
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue