mirror of https://gitee.com/openkylin/linux.git
Merge branch 'for-5.1/hid-asus' into for-linus
Asus Transbook T100CHI and T90CHI support from NOGUCHI Hiroshi
This commit is contained in:
Jiri Kosina
commit
2c2e5bb975
|
|
@ -72,6 +72,10 @@ ForEachMacros:
|
|||
- 'apei_estatus_for_each_section'
|
||||
- 'ata_for_each_dev'
|
||||
- 'ata_for_each_link'
|
||||
- '__ata_qc_for_each'
|
||||
- 'ata_qc_for_each'
|
||||
- 'ata_qc_for_each_raw'
|
||||
- 'ata_qc_for_each_with_internal'
|
||||
- 'ax25_for_each'
|
||||
- 'ax25_uid_for_each'
|
||||
- 'bio_for_each_integrity_vec'
|
||||
|
|
@ -85,6 +89,7 @@ ForEachMacros:
|
|||
- 'blk_queue_for_each_rl'
|
||||
- 'bond_for_each_slave'
|
||||
- 'bond_for_each_slave_rcu'
|
||||
- 'bpf_for_each_spilled_reg'
|
||||
- 'btree_for_each_safe128'
|
||||
- 'btree_for_each_safe32'
|
||||
- 'btree_for_each_safe64'
|
||||
|
|
@ -103,6 +108,8 @@ ForEachMacros:
|
|||
- 'drm_atomic_crtc_for_each_plane'
|
||||
- 'drm_atomic_crtc_state_for_each_plane'
|
||||
- 'drm_atomic_crtc_state_for_each_plane_state'
|
||||
- 'drm_atomic_for_each_plane_damage'
|
||||
- 'drm_connector_for_each_possible_encoder'
|
||||
- 'drm_for_each_connector_iter'
|
||||
- 'drm_for_each_crtc'
|
||||
- 'drm_for_each_encoder'
|
||||
|
|
@ -121,11 +128,21 @@ ForEachMacros:
|
|||
- 'for_each_bio'
|
||||
- 'for_each_board_func_rsrc'
|
||||
- 'for_each_bvec'
|
||||
- 'for_each_card_components'
|
||||
- 'for_each_card_links'
|
||||
- 'for_each_card_links_safe'
|
||||
- 'for_each_card_prelinks'
|
||||
- 'for_each_card_rtds'
|
||||
- 'for_each_card_rtds_safe'
|
||||
- 'for_each_cgroup_storage_type'
|
||||
- 'for_each_child_of_node'
|
||||
- 'for_each_clear_bit'
|
||||
- 'for_each_clear_bit_from'
|
||||
- 'for_each_cmsghdr'
|
||||
- 'for_each_compatible_node'
|
||||
- 'for_each_component_dais'
|
||||
- 'for_each_component_dais_safe'
|
||||
- 'for_each_comp_order'
|
||||
- 'for_each_console'
|
||||
- 'for_each_cpu'
|
||||
- 'for_each_cpu_and'
|
||||
|
|
@ -133,6 +150,10 @@ ForEachMacros:
|
|||
- 'for_each_cpu_wrap'
|
||||
- 'for_each_dev_addr'
|
||||
- 'for_each_dma_cap_mask'
|
||||
- 'for_each_dpcm_be'
|
||||
- 'for_each_dpcm_be_rollback'
|
||||
- 'for_each_dpcm_be_safe'
|
||||
- 'for_each_dpcm_fe'
|
||||
- 'for_each_drhd_unit'
|
||||
- 'for_each_dss_dev'
|
||||
- 'for_each_efi_memory_desc'
|
||||
|
|
@ -149,6 +170,7 @@ ForEachMacros:
|
|||
- 'for_each_iommu'
|
||||
- 'for_each_ip_tunnel_rcu'
|
||||
- 'for_each_irq_nr'
|
||||
- 'for_each_link_codecs'
|
||||
- 'for_each_lru'
|
||||
- 'for_each_matching_node'
|
||||
- 'for_each_matching_node_and_match'
|
||||
|
|
@ -160,6 +182,7 @@ ForEachMacros:
|
|||
- 'for_each_mem_range_rev'
|
||||
- 'for_each_migratetype_order'
|
||||
- 'for_each_msi_entry'
|
||||
- 'for_each_msi_entry_safe'
|
||||
- 'for_each_net'
|
||||
- 'for_each_netdev'
|
||||
- 'for_each_netdev_continue'
|
||||
|
|
@ -183,12 +206,14 @@ ForEachMacros:
|
|||
- 'for_each_node_with_property'
|
||||
- 'for_each_of_allnodes'
|
||||
- 'for_each_of_allnodes_from'
|
||||
- 'for_each_of_cpu_node'
|
||||
- 'for_each_of_pci_range'
|
||||
- 'for_each_old_connector_in_state'
|
||||
- 'for_each_old_crtc_in_state'
|
||||
- 'for_each_oldnew_connector_in_state'
|
||||
- 'for_each_oldnew_crtc_in_state'
|
||||
- 'for_each_oldnew_plane_in_state'
|
||||
- 'for_each_oldnew_plane_in_state_reverse'
|
||||
- 'for_each_oldnew_private_obj_in_state'
|
||||
- 'for_each_old_plane_in_state'
|
||||
- 'for_each_old_private_obj_in_state'
|
||||
|
|
@ -206,14 +231,17 @@ ForEachMacros:
|
|||
- 'for_each_process'
|
||||
- 'for_each_process_thread'
|
||||
- 'for_each_property_of_node'
|
||||
- 'for_each_registered_fb'
|
||||
- 'for_each_reserved_mem_region'
|
||||
- 'for_each_resv_unavail_range'
|
||||
- 'for_each_rtd_codec_dai'
|
||||
- 'for_each_rtd_codec_dai_rollback'
|
||||
- 'for_each_rtdcom'
|
||||
- 'for_each_rtdcom_safe'
|
||||
- 'for_each_set_bit'
|
||||
- 'for_each_set_bit_from'
|
||||
- 'for_each_sg'
|
||||
- 'for_each_sg_page'
|
||||
- 'for_each_sibling_event'
|
||||
- '__for_each_thread'
|
||||
- 'for_each_thread'
|
||||
- 'for_each_zone'
|
||||
|
|
@ -251,6 +279,8 @@ ForEachMacros:
|
|||
- 'hlist_nulls_for_each_entry_from'
|
||||
- 'hlist_nulls_for_each_entry_rcu'
|
||||
- 'hlist_nulls_for_each_entry_safe'
|
||||
- 'i3c_bus_for_each_i2cdev'
|
||||
- 'i3c_bus_for_each_i3cdev'
|
||||
- 'ide_host_for_each_port'
|
||||
- 'ide_port_for_each_dev'
|
||||
- 'ide_port_for_each_present_dev'
|
||||
|
|
@ -267,11 +297,14 @@ ForEachMacros:
|
|||
- 'kvm_for_each_memslot'
|
||||
- 'kvm_for_each_vcpu'
|
||||
- 'list_for_each'
|
||||
- 'list_for_each_codec'
|
||||
- 'list_for_each_codec_safe'
|
||||
- 'list_for_each_entry'
|
||||
- 'list_for_each_entry_continue'
|
||||
- 'list_for_each_entry_continue_rcu'
|
||||
- 'list_for_each_entry_continue_reverse'
|
||||
- 'list_for_each_entry_from'
|
||||
- 'list_for_each_entry_from_rcu'
|
||||
- 'list_for_each_entry_from_reverse'
|
||||
- 'list_for_each_entry_lockless'
|
||||
- 'list_for_each_entry_rcu'
|
||||
|
|
@ -291,6 +324,7 @@ ForEachMacros:
|
|||
- 'media_device_for_each_intf'
|
||||
- 'media_device_for_each_link'
|
||||
- 'media_device_for_each_pad'
|
||||
- 'nanddev_io_for_each_page'
|
||||
- 'netdev_for_each_lower_dev'
|
||||
- 'netdev_for_each_lower_private'
|
||||
- 'netdev_for_each_lower_private_rcu'
|
||||
|
|
@ -357,12 +391,14 @@ ForEachMacros:
|
|||
- 'sk_nulls_for_each'
|
||||
- 'sk_nulls_for_each_from'
|
||||
- 'sk_nulls_for_each_rcu'
|
||||
- 'snd_array_for_each'
|
||||
- 'snd_pcm_group_for_each_entry'
|
||||
- 'snd_soc_dapm_widget_for_each_path'
|
||||
- 'snd_soc_dapm_widget_for_each_path_safe'
|
||||
- 'snd_soc_dapm_widget_for_each_sink_path'
|
||||
- 'snd_soc_dapm_widget_for_each_source_path'
|
||||
- 'tb_property_for_each'
|
||||
- 'tcf_exts_for_each_action'
|
||||
- 'udp_portaddr_for_each_entry'
|
||||
- 'udp_portaddr_for_each_entry_rcu'
|
||||
- 'usb_hub_for_each_child'
|
||||
|
|
@ -371,6 +407,11 @@ ForEachMacros:
|
|||
- 'v4l2_m2m_for_each_dst_buf_safe'
|
||||
- 'v4l2_m2m_for_each_src_buf'
|
||||
- 'v4l2_m2m_for_each_src_buf_safe'
|
||||
- 'virtio_device_for_each_vq'
|
||||
- 'xa_for_each'
|
||||
- 'xas_for_each'
|
||||
- 'xas_for_each_conflict'
|
||||
- 'xas_for_each_marked'
|
||||
- 'zorro_for_each_dev'
|
||||
|
||||
#IncludeBlocks: Preserve # Unknown to clang-format-5.0
|
||||
|
|
|
|||
6
CREDITS
6
CREDITS
|
|
@ -2208,6 +2208,12 @@ N: Christopher Li
|
|||
E: sparse@chrisli.org
|
||||
D: Sparse maintainer 2009 - 2018
|
||||
|
||||
N: Shaohua Li
|
||||
D: Worked on many parts of the kernel, from core x86, ACPI, PCI, KVM, MM,
|
||||
D: and much more. He was the maintainer of MD from 2016 to 2018. Shaohua
|
||||
D: passed away late 2018, he will be greatly missed.
|
||||
W: https://www.spinics.net/lists/raid/msg61993.html
|
||||
|
||||
N: Stephan Linz
|
||||
E: linz@mazet.de
|
||||
E: Stephan.Linz@gmx.de
|
||||
|
|
|
|||
|
|
@ -279,3 +279,12 @@ Description:
|
|||
size in 512B sectors of the zones of the device, with
|
||||
the eventual exception of the last zone of the device
|
||||
which may be smaller.
|
||||
|
||||
What: /sys/block/<disk>/queue/io_timeout
|
||||
Date: November 2018
|
||||
Contact: Weiping Zhang <zhangweiping@didiglobal.com>
|
||||
Description:
|
||||
io_timeout is the request timeout in milliseconds. If a request
|
||||
does not complete in this time then the block driver timeout
|
||||
handler is invoked. That timeout handler can decide to retry
|
||||
the request, to fail it or to start a device recovery strategy.
|
||||
|
|
|
|||
|
|
@ -122,11 +122,18 @@ Description:
|
|||
statistics (bd_count, bd_reads, bd_writes) in a format
|
||||
similar to block layer statistics file format.
|
||||
|
||||
What: /sys/block/zram<id>/writeback_limit_enable
|
||||
Date: November 2018
|
||||
Contact: Minchan Kim <minchan@kernel.org>
|
||||
Description:
|
||||
The writeback_limit_enable file is read-write and specifies
|
||||
eanbe of writeback_limit feature. "1" means eable the feature.
|
||||
No limit "0" is the initial state.
|
||||
|
||||
What: /sys/block/zram<id>/writeback_limit
|
||||
Date: November 2018
|
||||
Contact: Minchan Kim <minchan@kernel.org>
|
||||
Description:
|
||||
The writeback_limit file is read-write and specifies the maximum
|
||||
amount of writeback ZRAM can do. The limit could be changed
|
||||
in run time and "0" means disable the limit.
|
||||
No limit is the initial state.
|
||||
in run time.
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ If you can't figure out which subsystem caused the issue, you should file
|
|||
a bug in kernel.org bugzilla and send email to
|
||||
linux-kernel@vger.kernel.org, referencing the bugzilla URL. (For more
|
||||
information on the linux-kernel mailing list see
|
||||
http://www.tux.org/lkml/).
|
||||
http://vger.kernel.org/lkml/).
|
||||
|
||||
|
||||
Tips for reporting bugs
|
||||
|
|
|
|||
|
|
@ -357,6 +357,13 @@ video playing/streaming, a very low drop rate may be more important
|
|||
than maximum throughput. In these cases, consider setting the
|
||||
strict_guarantees parameter.
|
||||
|
||||
slice_idle_us
|
||||
-------------
|
||||
|
||||
Controls the same tuning parameter as slice_idle, but in microseconds.
|
||||
Either tunable can be used to set idling behavior. Afterwards, the
|
||||
other tunable will reflect the newly set value in sysfs.
|
||||
|
||||
strict_guarantees
|
||||
-----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,8 @@ shared_tags=[0/1]: Default: 0
|
|||
|
||||
zoned=[0/1]: Default: 0
|
||||
0: Block device is exposed as a random-access block device.
|
||||
1: Block device is exposed as a host-managed zoned block device.
|
||||
1: Block device is exposed as a host-managed zoned block device. Requires
|
||||
CONFIG_BLK_DEV_ZONED.
|
||||
|
||||
zone_size=[MB]: Default: 256
|
||||
Per zone size when exposed as a zoned block device. Must be a power of two.
|
||||
|
|
|
|||
|
|
@ -67,6 +67,13 @@ If set to a value larger than 0, the kernel will put the process issuing
|
|||
IO to sleep for this amount of microseconds before entering classic
|
||||
polling.
|
||||
|
||||
io_timeout (RW)
|
||||
---------------
|
||||
io_timeout is the request timeout in milliseconds. If a request does not
|
||||
complete in this time then the block driver timeout handler is invoked.
|
||||
That timeout handler can decide to retry the request, to fail it or to start
|
||||
a device recovery strategy.
|
||||
|
||||
iostats (RW)
|
||||
-------------
|
||||
This file is used to control (on/off) the iostats accounting of the
|
||||
|
|
|
|||
|
|
@ -156,22 +156,23 @@ Per-device statistics are exported as various nodes under /sys/block/zram<id>/
|
|||
A brief description of exported device attributes. 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
|
||||
mem_used_max WO reset the `mem_used_max' counter (see later)
|
||||
mem_limit WO specifies the maximum amount of memory ZRAM can use
|
||||
to store the compressed data
|
||||
writeback_limit WO specifies the maximum amount of write IO zram can
|
||||
write out to backing device as 4KB unit
|
||||
max_comp_streams RW the number of possible concurrent compress operations
|
||||
comp_algorithm RW show and change the compression algorithm
|
||||
compact WO trigger memory compaction
|
||||
debug_stat RO this file is used for zram debugging purposes
|
||||
backing_dev RW set up backend storage for zram to write out
|
||||
idle WO mark allocated slot as idle
|
||||
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
|
||||
mem_used_max WO reset the `mem_used_max' counter (see later)
|
||||
mem_limit WO specifies the maximum amount of memory ZRAM can use
|
||||
to store the compressed data
|
||||
writeback_limit WO specifies the maximum amount of write IO zram can
|
||||
write out to backing device as 4KB unit
|
||||
writeback_limit_enable RW show and set writeback_limit feature
|
||||
max_comp_streams RW the number of possible concurrent compress operations
|
||||
comp_algorithm RW show and change the compression algorithm
|
||||
compact WO trigger memory compaction
|
||||
debug_stat RO this file is used for zram debugging purposes
|
||||
backing_dev RW set up backend storage for zram to write out
|
||||
idle WO mark allocated slot as idle
|
||||
|
||||
|
||||
User space is advised to use the following files to read the device statistics.
|
||||
|
|
@ -280,32 +281,51 @@ With the command, zram writeback idle pages from memory to the storage.
|
|||
If there are lots of write IO with flash device, potentially, it has
|
||||
flash wearout problem so that admin needs to design write limitation
|
||||
to guarantee storage health for entire product life.
|
||||
To overcome the concern, zram supports "writeback_limit".
|
||||
The "writeback_limit"'s default value is 0 so that it doesn't limit
|
||||
any writeback. If admin want to measure writeback count in a certain
|
||||
period, he could know it via /sys/block/zram0/bd_stat's 3rd column.
|
||||
|
||||
To overcome the concern, zram supports "writeback_limit" feature.
|
||||
The "writeback_limit_enable"'s default value is 0 so that it doesn't limit
|
||||
any writeback. IOW, if admin want to apply writeback budget, he should
|
||||
enable writeback_limit_enable via
|
||||
|
||||
$ echo 1 > /sys/block/zramX/writeback_limit_enable
|
||||
|
||||
Once writeback_limit_enable is set, zram doesn't allow any writeback
|
||||
until admin set the budget via /sys/block/zramX/writeback_limit.
|
||||
|
||||
(If admin doesn't enable writeback_limit_enable, writeback_limit's value
|
||||
assigned via /sys/block/zramX/writeback_limit is meaninless.)
|
||||
|
||||
If admin want to limit writeback as per-day 400M, he could do it
|
||||
like below.
|
||||
|
||||
MB_SHIFT=20
|
||||
4K_SHIFT=12
|
||||
echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
||||
/sys/block/zram0/writeback_limit.
|
||||
$ MB_SHIFT=20
|
||||
$ 4K_SHIFT=12
|
||||
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
||||
/sys/block/zram0/writeback_limit.
|
||||
$ echo 1 > /sys/block/zram0/writeback_limit_enable
|
||||
|
||||
If admin want to allow further write again, he could do it like below
|
||||
If admin want to allow further write again once the bugdet is exausted,
|
||||
he could do it like below
|
||||
|
||||
echo 0 > /sys/block/zram0/writeback_limit
|
||||
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
||||
/sys/block/zram0/writeback_limit
|
||||
|
||||
If admin want to see remaining writeback budget since he set,
|
||||
|
||||
cat /sys/block/zram0/writeback_limit
|
||||
$ cat /sys/block/zramX/writeback_limit
|
||||
|
||||
If admin want to disable writeback limit, he could do
|
||||
|
||||
$ echo 0 > /sys/block/zramX/writeback_limit_enable
|
||||
|
||||
The writeback_limit count will reset whenever you reset zram(e.g.,
|
||||
system reboot, echo 1 > /sys/block/zramX/reset) so keeping how many of
|
||||
writeback happened until you reset the zram to allocate extra writeback
|
||||
budget in next setting is user's job.
|
||||
|
||||
If admin want to measure writeback count in a certain period, he could
|
||||
know it via /sys/block/zram0/bd_stat's 3rd column.
|
||||
|
||||
= memory tracking
|
||||
|
||||
With CONFIG_ZRAM_MEMORY_TRACKING, user can know information of the
|
||||
|
|
|
|||
|
|
@ -157,12 +157,11 @@ Q: Does BPF have a stable ABI?
|
|||
------------------------------
|
||||
A: YES. BPF instructions, arguments to BPF programs, set of helper
|
||||
functions and their arguments, recognized return codes are all part
|
||||
of ABI. However when tracing programs are using bpf_probe_read() helper
|
||||
to walk kernel internal datastructures and compile with kernel
|
||||
internal headers these accesses can and will break with newer
|
||||
kernels. The union bpf_attr -> kern_version is checked at load time
|
||||
to prevent accidentally loading kprobe-based bpf programs written
|
||||
for a different kernel. Networking programs don't do kern_version check.
|
||||
of ABI. However there is one specific exception to tracing programs
|
||||
which are using helpers like bpf_probe_read() to walk kernel internal
|
||||
data structures and compile with kernel internal headers. Both of these
|
||||
kernel internals are subject to change and can break with newer kernels
|
||||
such that the program needs to be adapted accordingly.
|
||||
|
||||
Q: How much stack space a BPF program uses?
|
||||
-------------------------------------------
|
||||
|
|
|
|||
|
|
@ -291,12 +291,6 @@ Block Devices
|
|||
.. kernel-doc:: block/blk-lib.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: block/blk-tag.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: block/blk-tag.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: block/blk-integrity.c
|
||||
:export:
|
||||
|
||||
|
|
|
|||
|
|
@ -108,12 +108,13 @@ some, but not all of the other indices changing.
|
|||
|
||||
Sometimes you need to ensure that a subsequent call to :c:func:`xa_store`
|
||||
will not need to allocate memory. The :c:func:`xa_reserve` function
|
||||
will store a reserved entry at the indicated index. Users of the normal
|
||||
API will see this entry as containing ``NULL``. If you do not need to
|
||||
use the reserved entry, you can call :c:func:`xa_release` to remove the
|
||||
unused entry. If another user has stored to the entry in the meantime,
|
||||
:c:func:`xa_release` will do nothing; if instead you want the entry to
|
||||
become ``NULL``, you should use :c:func:`xa_erase`.
|
||||
will store a reserved entry at the indicated index. Users of the
|
||||
normal API will see this entry as containing ``NULL``. If you do
|
||||
not need to use the reserved entry, you can call :c:func:`xa_release`
|
||||
to remove the unused entry. If another user has stored to the entry
|
||||
in the meantime, :c:func:`xa_release` will do nothing; if instead you
|
||||
want the entry to become ``NULL``, you should use :c:func:`xa_erase`.
|
||||
Using :c:func:`xa_insert` on a reserved entry will fail.
|
||||
|
||||
If all entries in the array are ``NULL``, the :c:func:`xa_empty` function
|
||||
will return ``true``.
|
||||
|
|
@ -183,6 +184,8 @@ Takes xa_lock internally:
|
|||
* :c:func:`xa_store_bh`
|
||||
* :c:func:`xa_store_irq`
|
||||
* :c:func:`xa_insert`
|
||||
* :c:func:`xa_insert_bh`
|
||||
* :c:func:`xa_insert_irq`
|
||||
* :c:func:`xa_erase`
|
||||
* :c:func:`xa_erase_bh`
|
||||
* :c:func:`xa_erase_irq`
|
||||
|
|
|
|||
|
|
@ -17,7 +17,11 @@ extra-y += $(DT_TMP_SCHEMA)
|
|||
quiet_cmd_mk_schema = SCHEMA $@
|
||||
cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(filter-out FORCE, $^)
|
||||
|
||||
DT_DOCS = $(shell cd $(srctree)/$(src) && find * -name '*.yaml')
|
||||
DT_DOCS = $(shell \
|
||||
cd $(srctree)/$(src) && \
|
||||
find * \( -name '*.yaml' ! -name $(DT_TMP_SCHEMA) \) \
|
||||
)
|
||||
|
||||
DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS))
|
||||
|
||||
extra-y += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
|
||||
|
|
|
|||
|
|
@ -235,4 +235,4 @@ cpus {
|
|||
===========================================
|
||||
|
||||
[1] ARM Linux Kernel documentation - CPUs bindings
|
||||
Documentation/devicetree/bindings/arm/cpus.txt
|
||||
Documentation/devicetree/bindings/arm/cpus.yaml
|
||||
|
|
|
|||
|
|
@ -684,7 +684,7 @@ cpus {
|
|||
===========================================
|
||||
|
||||
[1] ARM Linux Kernel documentation - CPUs bindings
|
||||
Documentation/devicetree/bindings/arm/cpus.txt
|
||||
Documentation/devicetree/bindings/arm/cpus.yaml
|
||||
|
||||
[2] ARM Linux Kernel documentation - PSCI bindings
|
||||
Documentation/devicetree/bindings/arm/psci.txt
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ SP810 System Controller
|
|||
Required properties:
|
||||
|
||||
- compatible: standard compatible string for a Primecell peripheral,
|
||||
see Documentation/devicetree/bindings/arm/primecell.txt
|
||||
see Documentation/devicetree/bindings/arm/primecell.yaml
|
||||
for more details
|
||||
should be: "arm,sp810", "arm,primecell"
|
||||
|
||||
|
|
|
|||
|
|
@ -472,4 +472,4 @@ cpus {
|
|||
|
||||
===============================================================================
|
||||
[1] ARM Linux kernel documentation
|
||||
Documentation/devicetree/bindings/arm/cpus.txt
|
||||
Documentation/devicetree/bindings/arm/cpus.yaml
|
||||
|
|
|
|||
|
|
@ -18,4 +18,4 @@ Required Properties:
|
|||
Each clock is assigned an identifier and client nodes use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All these identifier could be found in <dt-bindings/clock/marvell-mmp2.h>.
|
||||
All these identifiers could be found in <dt-bindings/clock/marvell,mmp2.h>.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
* ARM PrimeCell Color LCD Controller PL110/PL111
|
||||
|
||||
See also Documentation/devicetree/bindings/arm/primecell.txt
|
||||
See also Documentation/devicetree/bindings/arm/primecell.yaml
|
||||
|
||||
Required properties:
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,6 @@ Example:
|
|||
reg = <0x04300000 0x20000>;
|
||||
reg-names = "kgsl_3d0_reg_memory";
|
||||
interrupts = <GIC_SPI 80 0>;
|
||||
interrupt-names = "kgsl_3d0_irq";
|
||||
clock-names =
|
||||
"core",
|
||||
"iface",
|
||||
|
|
|
|||
|
|
@ -27,6 +27,7 @@ Required properties:
|
|||
"atmel,24c256",
|
||||
"atmel,24c512",
|
||||
"atmel,24c1024",
|
||||
"atmel,24c2048",
|
||||
|
||||
If <manufacturer> is not "atmel", then a fallback must be used
|
||||
with the same <model> and "atmel" as manufacturer.
|
||||
|
|
|
|||
|
|
@ -14,8 +14,6 @@ Required properties:
|
|||
|
||||
"marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
|
||||
SoCs (either from AP or CP), see
|
||||
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
|
||||
and
|
||||
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
|
||||
for specific details about the offset property.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
STM32 Hardware Spinlock Device Binding
|
||||
-------------------------------------
|
||||
|
||||
Required properties :
|
||||
- compatible : should be "st,stm32-hwspinlock".
|
||||
- reg : the register address of hwspinlock.
|
||||
- #hwlock-cells : hwlock users only use the hwlock id to represent a specific
|
||||
hwlock, so the number of cells should be <1> here.
|
||||
- clock-names : Must contain "hsem".
|
||||
- clocks : Must contain a phandle entry for the clock in clock-names, see the
|
||||
common clock bindings.
|
||||
|
||||
Please look at the generic hwlock binding for usage information for consumers,
|
||||
"Documentation/devicetree/bindings/hwlock/hwlock.txt"
|
||||
|
||||
Example of hwlock provider:
|
||||
hwspinlock@4c000000 {
|
||||
compatible = "st,stm32-hwspinlock";
|
||||
#hwlock-cells = <1>;
|
||||
reg = <0x4c000000 0x400>;
|
||||
clocks = <&rcc HSEM>;
|
||||
clock-names = "hsem";
|
||||
};
|
||||
|
|
@ -33,7 +33,7 @@ i2c0: i2c@fff84000 {
|
|||
clock-frequency = <400000>;
|
||||
|
||||
24c512@50 {
|
||||
compatible = "24c512";
|
||||
compatible = "atmel,24c512";
|
||||
reg = <0x50>;
|
||||
pagesize = <128>;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Example:
|
|||
reg = <0>;
|
||||
|
||||
eeprom@50 {
|
||||
compatible = "at,24c02";
|
||||
compatible = "atmel,24c02";
|
||||
reg = <0x50>;
|
||||
};
|
||||
};
|
||||
|
|
@ -54,7 +54,7 @@ Example:
|
|||
reg = <1>;
|
||||
|
||||
eeprom@50 {
|
||||
compatible = "at,24c02";
|
||||
compatible = "atmel,24c02";
|
||||
reg = <0x50>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Example:
|
|||
reg = <2>;
|
||||
|
||||
eeprom@54 {
|
||||
compatible = "at,24c08";
|
||||
compatible = "atmel,24c08";
|
||||
reg = <0x54>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@ Actions Semiconductor Owl I2C controller
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "actions,s900-i2c".
|
||||
- compatible : Should be one of the following:
|
||||
- "actions,s700-i2c" for S700 SoC
|
||||
- "actions,s900-i2c" for S900 SoC
|
||||
- reg : Offset and length of the register set for the device.
|
||||
- #address-cells : Should be 1.
|
||||
- #size-cells : Should be 0.
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ Required properties:
|
|||
"renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
|
||||
"renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC.
|
||||
"renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC.
|
||||
"renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC.
|
||||
"renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
|
||||
"renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
|
||||
"renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required properties:
|
|||
- "renesas,iic-r8a7744" (RZ/G1N)
|
||||
- "renesas,iic-r8a7745" (RZ/G1E)
|
||||
- "renesas,iic-r8a774a1" (RZ/G2M)
|
||||
- "renesas,iic-r8a774c0" (RZ/G2E)
|
||||
- "renesas,iic-r8a7790" (R-Car H2)
|
||||
- "renesas,iic-r8a7791" (R-Car M2-W)
|
||||
- "renesas,iic-r8a7792" (R-Car V2H)
|
||||
|
|
@ -16,6 +17,7 @@ Required properties:
|
|||
- "renesas,iic-r8a7795" (R-Car H3)
|
||||
- "renesas,iic-r8a7796" (R-Car M3-W)
|
||||
- "renesas,iic-r8a77965" (R-Car M3-N)
|
||||
- "renesas,iic-r8a77990" (R-Car E3)
|
||||
- "renesas,iic-sh73a0" (SH-Mobile AG5)
|
||||
- "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1
|
||||
compatible device)
|
||||
|
|
@ -28,7 +30,13 @@ Required properties:
|
|||
the platform first followed by the generic R-Car
|
||||
version.
|
||||
|
||||
renesas,rmobile-iic must always follow.
|
||||
When compatible with "renesas,rmobile-iic" it should
|
||||
be the last compatibility string listed.
|
||||
|
||||
The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E)
|
||||
controllers are not considered compatible with
|
||||
"renesas,rcar-gen3-iic" or "renesas,rmobile-iic"
|
||||
due to the absence of automatic transmission registers.
|
||||
|
||||
- reg : address start and address range size of device
|
||||
- interrupts : interrupt of device
|
||||
|
|
|
|||
|
|
@ -26,6 +26,11 @@ Optional properties :
|
|||
- i2c-scl-falling-time-ns : Only for STM32F7, I2C SCL Falling time for the board
|
||||
(default: 10)
|
||||
I2C Timings are derived from these 2 values
|
||||
- st,syscfg-fmp: Only for STM32F7, use to set Fast Mode Plus bit within SYSCFG
|
||||
whether Fast Mode Plus speed is selected by slave.
|
||||
1st cell : phandle to syscfg
|
||||
2nd cell : register offset within SYSCFG
|
||||
3rd cell : register bitmask for FMP bit
|
||||
|
||||
Example :
|
||||
|
||||
|
|
@ -53,4 +58,5 @@ Example :
|
|||
clocks = <&rcc 1 CLK_I2C1>;
|
||||
pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
|
||||
pinctrl-names = "default";
|
||||
st,syscfg-fmp = <&syscfg 0x4 0x1>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Example:
|
|||
#size-cells = <0>;
|
||||
|
||||
eeprom@54 {
|
||||
compatible = "at,24c08";
|
||||
compatible = "atmel,24c08";
|
||||
reg = <0x54>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ Sub-nodes:
|
|||
PPI affinity can be expressed as a single "ppi-partitions" node,
|
||||
containing a set of sub-nodes, each with the following property:
|
||||
- affinity: Should be a list of phandles to CPU nodes (as described in
|
||||
Documentation/devicetree/bindings/arm/cpus.txt).
|
||||
Documentation/devicetree/bindings/arm/cpus.yaml).
|
||||
|
||||
GICv3 has one or more Interrupt Translation Services (ITS) that are
|
||||
used to route Message Signalled Interrupts (MSI) to the CPUs.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,70 @@
|
|||
Amlogic Meson AXG DWC PCIE SoC controller
|
||||
|
||||
Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core.
|
||||
It shares common functions with the PCIe DesignWare core driver and
|
||||
inherits common properties defined in
|
||||
Documentation/devicetree/bindings/pci/designware-pci.txt.
|
||||
|
||||
Additional properties are described here:
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
should contain "amlogic,axg-pcie" to identify the core.
|
||||
- reg:
|
||||
should contain the configuration address space.
|
||||
- reg-names: Must be
|
||||
- "elbi" External local bus interface registers
|
||||
- "cfg" Meson specific registers
|
||||
- "phy" Meson PCIE PHY registers
|
||||
- "config" PCIe configuration space
|
||||
- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
- clock-names: Must include the following entries:
|
||||
- "pclk" PCIe GEN 100M PLL clock
|
||||
- "port" PCIe_x(A or B) RC clock gate
|
||||
- "general" PCIe Phy clock
|
||||
- "mipi" PCIe_x(A or B) 100M ref clock gate
|
||||
- resets: phandle to the reset lines.
|
||||
- reset-names: must contain "phy" "port" and "apb"
|
||||
- "phy" Share PHY reset
|
||||
- "port" Port A or B reset
|
||||
- "apb" Share APB reset
|
||||
- device_type:
|
||||
should be "pci". As specified in designware-pcie.txt
|
||||
|
||||
|
||||
Example configuration:
|
||||
|
||||
pcie: pcie@f9800000 {
|
||||
compatible = "amlogic,axg-pcie", "snps,dw-pcie";
|
||||
reg = <0x0 0xf9800000 0x0 0x400000
|
||||
0x0 0xff646000 0x0 0x2000
|
||||
0x0 0xff644000 0x0 0x2000
|
||||
0x0 0xf9f00000 0x0 0x100000>;
|
||||
reg-names = "elbi", "cfg", "phy", "config";
|
||||
reset-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
|
||||
interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-map-mask = <0 0 0 0>;
|
||||
interrupt-map = <0 0 0 0 &gic GIC_SPI 179 IRQ_TYPE_EDGE_RISING>;
|
||||
bus-range = <0x0 0xff>;
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
device_type = "pci";
|
||||
ranges = <0x82000000 0 0 0x0 0xf9c00000 0 0x00300000>;
|
||||
|
||||
clocks = <&clkc CLKID_USB
|
||||
&clkc CLKID_MIPI_ENABLE
|
||||
&clkc CLKID_PCIE_A
|
||||
&clkc CLKID_PCIE_CML_EN0>;
|
||||
clock-names = "general",
|
||||
"mipi",
|
||||
"pclk",
|
||||
"port";
|
||||
resets = <&reset RESET_PCIE_PHY>,
|
||||
<&reset RESET_PCIE_A>,
|
||||
<&reset RESET_PCIE_APB>;
|
||||
reset-names = "phy",
|
||||
"port",
|
||||
"apb";
|
||||
};
|
||||
|
|
@ -41,7 +41,9 @@ Optional properties:
|
|||
Additional required properties for imx6sx-pcie:
|
||||
- clock names: Must include the following additional entries:
|
||||
- "pcie_inbound_axi"
|
||||
- power-domains: Must be set to a phandle pointing to the PCIE_PHY power domain
|
||||
- power-domains: Must be set to phandles pointing to the DISPLAY and
|
||||
PCIE_PHY power domains
|
||||
- power-domain-names: Must be "pcie", "pcie_phy"
|
||||
|
||||
Additional required properties for imx7d-pcie:
|
||||
- power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
|
||||
|
|
|
|||
|
|
@ -65,7 +65,6 @@ Required properties:
|
|||
explanation.
|
||||
- ranges: Sub-ranges distributed from the PCIe controller node. An empty
|
||||
property is sufficient.
|
||||
- num-lanes: Number of lanes to use for this port.
|
||||
|
||||
Examples for MT7623:
|
||||
|
||||
|
|
@ -118,7 +117,6 @@ Examples for MT7623:
|
|||
interrupt-map-mask = <0 0 0 0>;
|
||||
interrupt-map = <0 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>;
|
||||
ranges;
|
||||
num-lanes = <1>;
|
||||
};
|
||||
|
||||
pcie@1,0 {
|
||||
|
|
@ -129,7 +127,6 @@ Examples for MT7623:
|
|||
interrupt-map-mask = <0 0 0 0>;
|
||||
interrupt-map = <0 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
|
||||
ranges;
|
||||
num-lanes = <1>;
|
||||
};
|
||||
|
||||
pcie@2,0 {
|
||||
|
|
@ -140,7 +137,6 @@ Examples for MT7623:
|
|||
interrupt-map-mask = <0 0 0 0>;
|
||||
interrupt-map = <0 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
|
||||
ranges;
|
||||
num-lanes = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
@ -172,7 +168,6 @@ Examples for MT2712:
|
|||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
ranges;
|
||||
num-lanes = <1>;
|
||||
interrupt-map-mask = <0 0 0 7>;
|
||||
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
|
||||
<0 0 0 2 &pcie_intc0 1>,
|
||||
|
|
@ -191,7 +186,6 @@ Examples for MT2712:
|
|||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
ranges;
|
||||
num-lanes = <1>;
|
||||
interrupt-map-mask = <0 0 0 7>;
|
||||
interrupt-map = <0 0 0 1 &pcie_intc1 0>,
|
||||
<0 0 0 2 &pcie_intc1 1>,
|
||||
|
|
@ -245,7 +239,6 @@ Examples for MT7622:
|
|||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
ranges;
|
||||
num-lanes = <1>;
|
||||
interrupt-map-mask = <0 0 0 7>;
|
||||
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
|
||||
<0 0 0 2 &pcie_intc0 1>,
|
||||
|
|
@ -264,7 +257,6 @@ Examples for MT7622:
|
|||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
ranges;
|
||||
num-lanes = <1>;
|
||||
interrupt-map-mask = <0 0 0 7>;
|
||||
interrupt-map = <0 0 0 1 &pcie_intc1 0>,
|
||||
<0 0 0 2 &pcie_intc1 1>,
|
||||
|
|
|
|||
|
|
@ -0,0 +1,81 @@
|
|||
Socionext UniPhier PCIe host controller bindings
|
||||
|
||||
This describes the devicetree bindings for PCIe host controller implemented
|
||||
on Socionext UniPhier SoCs.
|
||||
|
||||
UniPhier PCIe host controller is based on the Synopsys DesignWare PCI core.
|
||||
It shares common functions with the PCIe DesignWare core driver and inherits
|
||||
common properties defined in
|
||||
Documentation/devicetree/bindings/pci/designware-pcie.txt.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "socionext,uniphier-pcie".
|
||||
- reg: Specifies offset and length of the register set for the device.
|
||||
According to the reg-names, appropriate register sets are required.
|
||||
- reg-names: Must include the following entries:
|
||||
"dbi" - controller configuration registers
|
||||
"link" - SoC-specific glue layer registers
|
||||
"config" - PCIe configuration space
|
||||
- clocks: A phandle to the clock gate for PCIe glue layer including
|
||||
the host controller.
|
||||
- resets: A phandle to the reset line for PCIe glue layer including
|
||||
the host controller.
|
||||
- interrupts: A list of interrupt specifiers. According to the
|
||||
interrupt-names, appropriate interrupts are required.
|
||||
- interrupt-names: Must include the following entries:
|
||||
"dma" - DMA interrupt
|
||||
"msi" - MSI interrupt
|
||||
|
||||
Optional properties:
|
||||
- phys: A phandle to generic PCIe PHY. According to the phy-names, appropriate
|
||||
phys are required.
|
||||
- phy-names: Must be "pcie-phy".
|
||||
|
||||
Required sub-node:
|
||||
- legacy-interrupt-controller: Specifies interrupt controller for legacy PCI
|
||||
interrupts.
|
||||
|
||||
Required properties for legacy-interrupt-controller:
|
||||
- interrupt-controller: identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an
|
||||
interrupt source. The value must be 1.
|
||||
- interrupt-parent: Phandle to the parent interrupt controller.
|
||||
- interrupts: An interrupt specifier for legacy interrupt.
|
||||
|
||||
Example:
|
||||
|
||||
pcie: pcie@66000000 {
|
||||
compatible = "socionext,uniphier-pcie", "snps,dw-pcie";
|
||||
status = "disabled";
|
||||
reg-names = "dbi", "link", "config";
|
||||
reg = <0x66000000 0x1000>, <0x66010000 0x10000>,
|
||||
<0x2fff0000 0x10000>;
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
clocks = <&sys_clk 24>;
|
||||
resets = <&sys_rst 24>;
|
||||
num-lanes = <1>;
|
||||
num-viewport = <1>;
|
||||
bus-range = <0x0 0xff>;
|
||||
device_type = "pci";
|
||||
ranges =
|
||||
/* downstream I/O */
|
||||
<0x81000000 0 0x00000000 0x2ffe0000 0 0x00010000
|
||||
/* non-prefetchable memory */
|
||||
0x82000000 0 0x00000000 0x20000000 0 0x0ffe0000>;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-names = "dma", "msi";
|
||||
interrupts = <0 224 4>, <0 225 4>;
|
||||
interrupt-map-mask = <0 0 0 7>;
|
||||
interrupt-map = <0 0 0 1 &pcie_intc 0>, /* INTA */
|
||||
<0 0 0 2 &pcie_intc 1>, /* INTB */
|
||||
<0 0 0 3 &pcie_intc 2>, /* INTC */
|
||||
<0 0 0 4 &pcie_intc 3>; /* INTD */
|
||||
|
||||
pcie_intc: legacy-interrupt-controller {
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&gic>;
|
||||
interrupts = <0 226 4>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,7 +1,8 @@
|
|||
Altera SOCFPGA Reset Manager
|
||||
|
||||
Required properties:
|
||||
- compatible : "altr,rst-mgr"
|
||||
- compatible : "altr,rst-mgr" for (Cyclone5/Arria5/Arria10)
|
||||
"altr,stratix10-rst-mgr","altr,rst-mgr" for Stratix10 ARM64 SoC
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- altr,modrst-offset : Should contain the offset of the first modrst register.
|
||||
- #reset-cells: 1
|
||||
|
|
|
|||
|
|
@ -120,27 +120,30 @@ Example:
|
|||
};
|
||||
|
||||
|
||||
USB3 core reset
|
||||
---------------
|
||||
Peripheral core reset in glue layer
|
||||
-----------------------------------
|
||||
|
||||
USB3 core reset belongs to USB3 glue layer. Before using the core reset,
|
||||
it is necessary to control the clocks and resets to enable this layer.
|
||||
These clocks and resets should be described in each property.
|
||||
Some peripheral core reset belongs to its own glue layer. Before using
|
||||
this core reset, it is necessary to control the clocks and resets to enable
|
||||
this layer. These clocks and resets should be described in each property.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be
|
||||
"socionext,uniphier-pro4-usb3-reset" - for Pro4 SoC
|
||||
"socionext,uniphier-pxs2-usb3-reset" - for PXs2 SoC
|
||||
"socionext,uniphier-ld20-usb3-reset" - for LD20 SoC
|
||||
"socionext,uniphier-pxs3-usb3-reset" - for PXs3 SoC
|
||||
"socionext,uniphier-pro4-usb3-reset" - for Pro4 SoC USB3
|
||||
"socionext,uniphier-pxs2-usb3-reset" - for PXs2 SoC USB3
|
||||
"socionext,uniphier-ld20-usb3-reset" - for LD20 SoC USB3
|
||||
"socionext,uniphier-pxs3-usb3-reset" - for PXs3 SoC USB3
|
||||
"socionext,uniphier-pro4-ahci-reset" - for Pro4 SoC AHCI
|
||||
"socionext,uniphier-pxs2-ahci-reset" - for PXs2 SoC AHCI
|
||||
"socionext,uniphier-pxs3-ahci-reset" - for PXs3 SoC AHCI
|
||||
- #reset-cells: Should be 1.
|
||||
- reg: Specifies offset and length of the register set for the device.
|
||||
- clocks: A list of phandles to the clock gate for USB3 glue layer.
|
||||
- clocks: A list of phandles to the clock gate for the glue layer.
|
||||
According to the clock-names, appropriate clocks are required.
|
||||
- clock-names: Should contain
|
||||
"gio", "link" - for Pro4 SoC
|
||||
"link" - for others
|
||||
- resets: A list of phandles to the reset control for USB3 glue layer.
|
||||
- resets: A list of phandles to the reset control for the glue layer.
|
||||
According to the reset-names, appropriate resets are required.
|
||||
- reset-names: Should contain
|
||||
"gio", "link" - for Pro4 SoC
|
||||
|
|
|
|||
|
|
@ -4,14 +4,10 @@ Required properties:
|
|||
- compatible : "olpc,ap-sp"
|
||||
- reg : base address and length of SoC's WTM registers
|
||||
- interrupts : SP-AP interrupt
|
||||
- clocks : phandle + clock-specifier for the clock that drives the WTM
|
||||
- clock-names: should be "sp"
|
||||
|
||||
Example:
|
||||
ap-sp@d4290000 {
|
||||
compatible = "olpc,ap-sp";
|
||||
reg = <0xd4290000 0x1000>;
|
||||
interrupts = <40>;
|
||||
clocks = <&soc_clocks MMP2_CLK_SP>;
|
||||
clock-names = "sp";
|
||||
}
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ of these nodes are defined by the individual bindings for the specific function
|
|||
= EXAMPLE
|
||||
The following example represents the GLINK RPM node on a MSM8996 device, with
|
||||
the function for the "rpm_request" channel defined, which is used for
|
||||
regualtors and root clocks.
|
||||
regulators and root clocks.
|
||||
|
||||
apcs_glb: mailbox@9820000 {
|
||||
compatible = "qcom,msm8996-apcs-hmss-global";
|
||||
|
|
|
|||
|
|
@ -41,12 +41,12 @@ processor ID) and a string identifier.
|
|||
- qcom,local-pid:
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: specifies the identfier of the local endpoint of this edge
|
||||
Definition: specifies the identifier of the local endpoint of this edge
|
||||
|
||||
- qcom,remote-pid:
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: specifies the identfier of the remote endpoint of this edge
|
||||
Definition: specifies the identifier of the remote endpoint of this edge
|
||||
|
||||
= SUBNODES
|
||||
Each SMP2P pair contain a set of inbound and outbound entries, these are
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ For example, in the NVMe Target Copy Offload implementation:
|
|||
in that it exposes any CMB (Controller Memory Buffer) as a P2P memory
|
||||
resource (provider), it accepts P2P memory pages as buffers in requests
|
||||
to be used directly (client) and it can also make use of the CMB as
|
||||
submission queue entries (orchastrator).
|
||||
submission queue entries (orchestrator).
|
||||
* The RDMA driver is a client in this arrangement so that an RNIC
|
||||
can DMA directly to the memory exposed by the NVMe device.
|
||||
* The NVMe Target driver (nvmet) can orchestrate the data from the RNIC
|
||||
|
|
@ -111,7 +111,7 @@ that's compatible with all clients using :c:func:`pci_p2pmem_find()`.
|
|||
If more than one provider is supported, the one nearest to all the clients will
|
||||
be chosen first. If more than one provider is an equal distance away, the
|
||||
one returned will be chosen at random (it is not an arbitrary but
|
||||
truely random). This function returns the PCI device to use for the provider
|
||||
truly random). This function returns the PCI device to use for the provider
|
||||
with a reference taken and therefore when it's no longer needed it should be
|
||||
returned with pci_dev_put().
|
||||
|
||||
|
|
|
|||
|
|
@ -124,11 +124,11 @@ struct bus_attribute {
|
|||
ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
|
||||
};
|
||||
|
||||
Bus drivers can export attributes using the BUS_ATTR macro that works
|
||||
similarly to the DEVICE_ATTR macro for devices. For example, a definition
|
||||
like this:
|
||||
Bus drivers can export attributes using the BUS_ATTR_RW macro that works
|
||||
similarly to the DEVICE_ATTR_RW macro for devices. For example, a
|
||||
definition like this:
|
||||
|
||||
static BUS_ATTR(debug,0644,show_debug,store_debug);
|
||||
static BUS_ATTR_RW(debug);
|
||||
|
||||
is equivalent to declaring:
|
||||
|
||||
|
|
|
|||
|
|
@ -250,7 +250,6 @@ DMA
|
|||
dmaenginem_async_device_register()
|
||||
dmam_alloc_coherent()
|
||||
dmam_alloc_attrs()
|
||||
dmam_declare_coherent_memory()
|
||||
dmam_free_coherent()
|
||||
dmam_pool_create()
|
||||
dmam_pool_destroy()
|
||||
|
|
|
|||
|
|
@ -163,6 +163,14 @@ C. Boot options
|
|||
be preserved until there actually is some text is output to the console.
|
||||
This option causes fbcon to bind immediately to the fbdev device.
|
||||
|
||||
7. fbcon=logo-pos:<location>
|
||||
|
||||
The only possible 'location' is 'center' (without quotes), and when
|
||||
given, the bootup logo is moved from the default top-left corner
|
||||
location to the center of the framebuffer. If more than one logo is
|
||||
displayed due to multiple CPUs, the collected line of logos is moved
|
||||
as a whole.
|
||||
|
||||
C. Attaching, Detaching and Unloading
|
||||
|
||||
Before going on to how to attach, detach and unload the framebuffer console, an
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | ok |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | ok |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | ok |
|
||||
| csky: | ok |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | ok |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | ok |
|
||||
| hexagon: | ok |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | TODO |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | ok |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | ok |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | ok |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | ok |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -34,6 +34,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | .. |
|
||||
| arm64: | ok |
|
||||
| c6x: | .. |
|
||||
| csky: | .. |
|
||||
| h8300: | .. |
|
||||
| hexagon: | .. |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | ok |
|
||||
| csky: | ok |
|
||||
| h8300: | ok |
|
||||
| hexagon: | ok |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | .. |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| c6x: | ok |
|
||||
| csky: | ok |
|
||||
| h8300: | ok |
|
||||
| hexagon: | ok |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | .. |
|
||||
| csky: | .. |
|
||||
| h8300: | .. |
|
||||
| hexagon: | .. |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| c6x: | .. |
|
||||
| csky: | TODO |
|
||||
| h8300: | .. |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | .. |
|
||||
| arm64: | ok |
|
||||
| c6x: | .. |
|
||||
| csky: | .. |
|
||||
| h8300: | .. |
|
||||
| hexagon: | .. |
|
||||
| ia64: | ok |
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| c6x: | TODO |
|
||||
| csky: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ exposure of uninitialized data through mmap.
|
|||
|
||||
These filesystems may be used for inspiration:
|
||||
- ext2: see Documentation/filesystems/ext2.txt
|
||||
- ext4: see Documentation/filesystems/ext4/ext4.rst
|
||||
- ext4: see Documentation/filesystems/ext4/
|
||||
- xfs: see Documentation/filesystems/xfs.txt
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -358,7 +358,7 @@ and are copied into the filesystem. If a transaction is incomplete at
|
|||
the time of the crash, then there is no guarantee of consistency for
|
||||
the blocks in that transaction so they are discarded (which means any
|
||||
filesystem changes they represent are also lost).
|
||||
Check Documentation/filesystems/ext4/ext4.rst if you want to read more about
|
||||
Check Documentation/filesystems/ext4/ if you want to read more about
|
||||
ext4 and journaling.
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -132,47 +132,28 @@ designed for this purpose be used, such as scrypt, PBKDF2, or Argon2.
|
|||
Per-file keys
|
||||
-------------
|
||||
|
||||
Master keys are not used to encrypt file contents or names directly.
|
||||
Instead, a unique key is derived for each encrypted file, including
|
||||
each regular file, directory, and symbolic link. This has several
|
||||
advantages:
|
||||
Since each master key can protect many files, it is necessary to
|
||||
"tweak" the encryption of each file so that the same plaintext in two
|
||||
files doesn't map to the same ciphertext, or vice versa. In most
|
||||
cases, fscrypt does this by deriving per-file keys. When a new
|
||||
encrypted inode (regular file, directory, or symlink) is created,
|
||||
fscrypt randomly generates a 16-byte nonce and stores it in the
|
||||
inode's encryption xattr. Then, it uses a KDF (Key Derivation
|
||||
Function) to derive the file's key from the master key and nonce.
|
||||
|
||||
- In cryptosystems, the same key material should never be used for
|
||||
different purposes. Using the master key as both an XTS key for
|
||||
contents encryption and as a CTS-CBC key for filenames encryption
|
||||
would violate this rule.
|
||||
- Per-file keys simplify the choice of IVs (Initialization Vectors)
|
||||
for contents encryption. Without per-file keys, to ensure IV
|
||||
uniqueness both the inode and logical block number would need to be
|
||||
encoded in the IVs. This would make it impossible to renumber
|
||||
inodes, which e.g. ``resize2fs`` can do when resizing an ext4
|
||||
filesystem. With per-file keys, it is sufficient to encode just the
|
||||
logical block number in the IVs.
|
||||
- Per-file keys strengthen the encryption of filenames, where IVs are
|
||||
reused out of necessity. With a unique key per directory, IV reuse
|
||||
is limited to within a single directory.
|
||||
- Per-file keys allow individual files to be securely erased simply by
|
||||
securely erasing their keys. (Not yet implemented.)
|
||||
The Adiantum encryption mode (see `Encryption modes and usage`_) is
|
||||
special, since it accepts longer IVs and is suitable for both contents
|
||||
and filenames encryption. For it, a "direct key" option is offered
|
||||
where the file's nonce is included in the IVs and the master key is
|
||||
used for encryption directly. This improves performance; however,
|
||||
users must not use the same master key for any other encryption mode.
|
||||
|
||||
A KDF (Key Derivation Function) is used to derive per-file keys from
|
||||
the master key. This is done instead of wrapping a randomly-generated
|
||||
key for each file because it reduces the size of the encryption xattr,
|
||||
which for some filesystems makes the xattr more likely to fit in-line
|
||||
in the filesystem's inode table. With a KDF, only a 16-byte nonce is
|
||||
required --- long enough to make key reuse extremely unlikely. A
|
||||
wrapped key, on the other hand, would need to be up to 64 bytes ---
|
||||
the length of an AES-256-XTS key. Furthermore, currently there is no
|
||||
requirement to support unlocking a file with multiple alternative
|
||||
master keys or to support rotating master keys. Instead, the master
|
||||
keys may be wrapped in userspace, e.g. as done by the `fscrypt
|
||||
<https://github.com/google/fscrypt>`_ tool.
|
||||
Below, the KDF and design considerations are described in more detail.
|
||||
|
||||
The current KDF encrypts the master key using the 16-byte nonce as an
|
||||
AES-128-ECB key. The output is used as the derived key. If the
|
||||
output is longer than needed, then it is truncated to the needed
|
||||
length. Truncation is the norm for directories and symlinks, since
|
||||
those use the CTS-CBC encryption mode which requires a key half as
|
||||
long as that required by the XTS encryption mode.
|
||||
The current KDF works by encrypting the master key with AES-128-ECB,
|
||||
using the file's nonce as the AES key. The output is used as the
|
||||
derived key. If the output is longer than needed, then it is
|
||||
truncated to the needed length.
|
||||
|
||||
Note: this KDF meets the primary security requirement, which is to
|
||||
produce unique derived keys that preserve the entropy of the master
|
||||
|
|
@ -181,6 +162,20 @@ However, it is nonstandard and has some problems such as being
|
|||
reversible, so it is generally considered to be a mistake! It may be
|
||||
replaced with HKDF or another more standard KDF in the future.
|
||||
|
||||
Key derivation was chosen over key wrapping because wrapped keys would
|
||||
require larger xattrs which would be less likely to fit in-line in the
|
||||
filesystem's inode table, and there didn't appear to be any
|
||||
significant advantages to key wrapping. In particular, currently
|
||||
there is no requirement to support unlocking a file with multiple
|
||||
alternative master keys or to support rotating master keys. Instead,
|
||||
the master keys may be wrapped in userspace, e.g. as is done by the
|
||||
`fscrypt <https://github.com/google/fscrypt>`_ tool.
|
||||
|
||||
Including the inode number in the IVs was considered. However, it was
|
||||
rejected as it would have prevented ext4 filesystems from being
|
||||
resized, and by itself still wouldn't have been sufficient to prevent
|
||||
the same key from being directly reused for both XTS and CTS-CBC.
|
||||
|
||||
Encryption modes and usage
|
||||
==========================
|
||||
|
||||
|
|
@ -191,54 +186,80 @@ Currently, the following pairs of encryption modes are supported:
|
|||
|
||||
- AES-256-XTS for contents and AES-256-CTS-CBC for filenames
|
||||
- AES-128-CBC for contents and AES-128-CTS-CBC for filenames
|
||||
- Adiantum for both contents and filenames
|
||||
|
||||
If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair.
|
||||
|
||||
It is strongly recommended to use AES-256-XTS for contents encryption.
|
||||
AES-128-CBC was added only for low-powered embedded devices with
|
||||
crypto accelerators such as CAAM or CESA that do not support XTS.
|
||||
|
||||
Adiantum is a (primarily) stream cipher-based mode that is fast even
|
||||
on CPUs without dedicated crypto instructions. It's also a true
|
||||
wide-block mode, unlike XTS. It can also eliminate the need to derive
|
||||
per-file keys. However, it depends on the security of two primitives,
|
||||
XChaCha12 and AES-256, rather than just one. See the paper
|
||||
"Adiantum: length-preserving encryption for entry-level processors"
|
||||
(https://eprint.iacr.org/2018/720.pdf) for more details. To use
|
||||
Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled. Also, fast
|
||||
implementations of ChaCha and NHPoly1305 should be enabled, e.g.
|
||||
CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM.
|
||||
|
||||
New encryption modes can be added relatively easily, without changes
|
||||
to individual filesystems. However, authenticated encryption (AE)
|
||||
modes are not currently supported because of the difficulty of dealing
|
||||
with ciphertext expansion.
|
||||
|
||||
Contents encryption
|
||||
-------------------
|
||||
|
||||
For file contents, each filesystem block is encrypted independently.
|
||||
Currently, only the case where the filesystem block size is equal to
|
||||
the system's page size (usually 4096 bytes) is supported. With the
|
||||
XTS mode of operation (recommended), the logical block number within
|
||||
the file is used as the IV. With the CBC mode of operation (not
|
||||
recommended), ESSIV is used; specifically, the IV for CBC is the
|
||||
logical block number encrypted with AES-256, where the AES-256 key is
|
||||
the SHA-256 hash of the inode's data encryption key.
|
||||
the system's page size (usually 4096 bytes) is supported.
|
||||
|
||||
For filenames, the full filename is encrypted at once. Because of the
|
||||
requirements to retain support for efficient directory lookups and
|
||||
filenames of up to 255 bytes, a constant initialization vector (IV) is
|
||||
used. However, each encrypted directory uses a unique key, which
|
||||
limits IV reuse to within a single directory. Note that IV reuse in
|
||||
the context of CTS-CBC encryption means that when the original
|
||||
filenames share a common prefix at least as long as the cipher block
|
||||
size (16 bytes for AES), the corresponding encrypted filenames will
|
||||
also share a common prefix. This is undesirable; it may be fixed in
|
||||
the future by switching to an encryption mode that is a strong
|
||||
pseudorandom permutation on arbitrary-length messages, e.g. the HEH
|
||||
(Hash-Encrypt-Hash) mode.
|
||||
Each block's IV is set to the logical block number within the file as
|
||||
a little endian number, except that:
|
||||
|
||||
Since filenames are encrypted with the CTS-CBC mode of operation, the
|
||||
plaintext and ciphertext filenames need not be multiples of the AES
|
||||
block size, i.e. 16 bytes. However, the minimum size that can be
|
||||
encrypted is 16 bytes, so shorter filenames are NUL-padded to 16 bytes
|
||||
before being encrypted. In addition, to reduce leakage of filename
|
||||
lengths via their ciphertexts, all filenames are NUL-padded to the
|
||||
next 4, 8, 16, or 32-byte boundary (configurable). 32 is recommended
|
||||
since this provides the best confidentiality, at the cost of making
|
||||
directory entries consume slightly more space. Note that since NUL
|
||||
(``\0``) is not otherwise a valid character in filenames, the padding
|
||||
will never produce duplicate plaintexts.
|
||||
- With CBC mode encryption, ESSIV is also used. Specifically, each IV
|
||||
is encrypted with AES-256 where the AES-256 key is the SHA-256 hash
|
||||
of the file's data encryption key.
|
||||
|
||||
- In the "direct key" configuration (FS_POLICY_FLAG_DIRECT_KEY set in
|
||||
the fscrypt_policy), the file's nonce is also appended to the IV.
|
||||
Currently this is only allowed with the Adiantum encryption mode.
|
||||
|
||||
Filenames encryption
|
||||
--------------------
|
||||
|
||||
For filenames, each full filename is encrypted at once. Because of
|
||||
the requirements to retain support for efficient directory lookups and
|
||||
filenames of up to 255 bytes, the same IV is used for every filename
|
||||
in a directory.
|
||||
|
||||
However, each encrypted directory still uses a unique key; or
|
||||
alternatively (for the "direct key" configuration) has the file's
|
||||
nonce included in the IVs. Thus, IV reuse is limited to within a
|
||||
single directory.
|
||||
|
||||
With CTS-CBC, the IV reuse means that when the plaintext filenames
|
||||
share a common prefix at least as long as the cipher block size (16
|
||||
bytes for AES), the corresponding encrypted filenames will also share
|
||||
a common prefix. This is undesirable. Adiantum does not have this
|
||||
weakness, as it is a wide-block encryption mode.
|
||||
|
||||
All supported filenames encryption modes accept any plaintext length
|
||||
>= 16 bytes; cipher block alignment is not required. However,
|
||||
filenames shorter than 16 bytes are NUL-padded to 16 bytes before
|
||||
being encrypted. In addition, to reduce leakage of filename lengths
|
||||
via their ciphertexts, all filenames are NUL-padded to the next 4, 8,
|
||||
16, or 32-byte boundary (configurable). 32 is recommended since this
|
||||
provides the best confidentiality, at the cost of making directory
|
||||
entries consume slightly more space. Note that since NUL (``\0``) is
|
||||
not otherwise a valid character in filenames, the padding will never
|
||||
produce duplicate plaintexts.
|
||||
|
||||
Symbolic link targets are considered a type of filename and are
|
||||
encrypted in the same way as filenames in directory entries. Each
|
||||
symlink also uses a unique key; hence, the hardcoded IV is not a
|
||||
problem for symlinks.
|
||||
encrypted in the same way as filenames in directory entries, except
|
||||
that IV reuse is not a problem as each symlink has its own inode.
|
||||
|
||||
User API
|
||||
========
|
||||
|
|
@ -272,9 +293,13 @@ This structure must be initialized as follows:
|
|||
and FS_ENCRYPTION_MODE_AES_256_CTS (4) for
|
||||
``filenames_encryption_mode``.
|
||||
|
||||
- ``flags`` must be set to a value from ``<linux/fs.h>`` which
|
||||
- ``flags`` must contain a value from ``<linux/fs.h>`` which
|
||||
identifies the amount of NUL-padding to use when encrypting
|
||||
filenames. If unsure, use FS_POLICY_FLAGS_PAD_32 (0x3).
|
||||
In addition, if the chosen encryption modes are both
|
||||
FS_ENCRYPTION_MODE_ADIANTUM, this can contain
|
||||
FS_POLICY_FLAG_DIRECT_KEY to specify that the master key should be
|
||||
used directly, without key derivation.
|
||||
|
||||
- ``master_key_descriptor`` specifies how to find the master key in
|
||||
the keyring; see `Adding keys`_. It is up to userspace to choose a
|
||||
|
|
|
|||
|
|
@ -344,7 +344,9 @@ struct bus_attribute {
|
|||
|
||||
Declaring:
|
||||
|
||||
BUS_ATTR(_name, _mode, _show, _store)
|
||||
static BUS_ATTR_RW(name);
|
||||
static BUS_ATTR_RO(name);
|
||||
static BUS_ATTR_WO(name);
|
||||
|
||||
Creation/Removal:
|
||||
|
||||
|
|
|
|||
|
|
@ -1296,9 +1296,12 @@ See subsequent chapter for the syntax of the Kbuild file.
|
|||
|
||||
--- 7.4 mandatory-y
|
||||
|
||||
mandatory-y is essentially used by include/uapi/asm-generic/Kbuild.asm
|
||||
to define the minimum set of headers that must be exported in
|
||||
include/asm.
|
||||
mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild.asm
|
||||
to define the minimum set of ASM headers that all architectures must have.
|
||||
|
||||
This works like optional generic-y. If a mandatory header is missing
|
||||
in arch/$(ARCH)/include/(uapi/)/asm, Kbuild will automatically generate
|
||||
a wrapper of the asm-generic one.
|
||||
|
||||
The convention is to list one subdir per line and
|
||||
preferably in alphabetic order.
|
||||
|
|
|
|||
|
|
@ -11,19 +11,19 @@ Contents:
|
|||
batman-adv
|
||||
can
|
||||
can_ucan_protocol
|
||||
dpaa2/index
|
||||
e100
|
||||
e1000
|
||||
e1000e
|
||||
fm10k
|
||||
igb
|
||||
igbvf
|
||||
ixgb
|
||||
ixgbe
|
||||
ixgbevf
|
||||
i40e
|
||||
iavf
|
||||
ice
|
||||
device_drivers/freescale/dpaa2/index
|
||||
device_drivers/intel/e100
|
||||
device_drivers/intel/e1000
|
||||
device_drivers/intel/e1000e
|
||||
device_drivers/intel/fm10k
|
||||
device_drivers/intel/igb
|
||||
device_drivers/intel/igbvf
|
||||
device_drivers/intel/ixgb
|
||||
device_drivers/intel/ixgbe
|
||||
device_drivers/intel/ixgbevf
|
||||
device_drivers/intel/i40e
|
||||
device_drivers/intel/iavf
|
||||
device_drivers/intel/ice
|
||||
kapi
|
||||
z8530book
|
||||
msg_zerocopy
|
||||
|
|
|
|||
|
|
@ -1000,51 +1000,6 @@ The kernel interface functions are as follows:
|
|||
size should be set when the call is begun. tx_total_len may not be less
|
||||
than zero.
|
||||
|
||||
(*) Check to see the completion state of a call so that the caller can assess
|
||||
whether it needs to be retried.
|
||||
|
||||
enum rxrpc_call_completion {
|
||||
RXRPC_CALL_SUCCEEDED,
|
||||
RXRPC_CALL_REMOTELY_ABORTED,
|
||||
RXRPC_CALL_LOCALLY_ABORTED,
|
||||
RXRPC_CALL_LOCAL_ERROR,
|
||||
RXRPC_CALL_NETWORK_ERROR,
|
||||
};
|
||||
|
||||
int rxrpc_kernel_check_call(struct socket *sock, struct rxrpc_call *call,
|
||||
enum rxrpc_call_completion *_compl,
|
||||
u32 *_abort_code);
|
||||
|
||||
On return, -EINPROGRESS will be returned if the call is still ongoing; if
|
||||
it is finished, *_compl will be set to indicate the manner of completion,
|
||||
*_abort_code will be set to any abort code that occurred. 0 will be
|
||||
returned on a successful completion, -ECONNABORTED will be returned if the
|
||||
client failed due to a remote abort and anything else will return an
|
||||
appropriate error code.
|
||||
|
||||
The caller should look at this information to decide if it's worth
|
||||
retrying the call.
|
||||
|
||||
(*) Retry a client call.
|
||||
|
||||
int rxrpc_kernel_retry_call(struct socket *sock,
|
||||
struct rxrpc_call *call,
|
||||
struct sockaddr_rxrpc *srx,
|
||||
struct key *key);
|
||||
|
||||
This attempts to partially reinitialise a call and submit it again while
|
||||
reusing the original call's Tx queue to avoid the need to repackage and
|
||||
re-encrypt the data to be sent. call indicates the call to retry, srx the
|
||||
new address to send it to and key the encryption key to use for signing or
|
||||
encrypting the packets.
|
||||
|
||||
For this to work, the first Tx data packet must still be in the transmit
|
||||
queue, and currently this is only permitted for local and network errors
|
||||
and the call must not have been aborted. Any partially constructed Tx
|
||||
packet is left as is and can continue being filled afterwards.
|
||||
|
||||
It returns 0 if the call was requeued and an error otherwise.
|
||||
|
||||
(*) Get call RTT.
|
||||
|
||||
u64 rxrpc_kernel_get_rtt(struct socket *sock, struct rxrpc_call *call);
|
||||
|
|
|
|||
|
|
@ -336,7 +336,26 @@ time client replies ACK, this socket will get another chance to move
|
|||
to the accept queue.
|
||||
|
||||
|
||||
TCP Fast Open
|
||||
* TcpEstabResets
|
||||
Defined in `RFC1213 tcpEstabResets`_.
|
||||
|
||||
.. _RFC1213 tcpEstabResets: https://tools.ietf.org/html/rfc1213#page-48
|
||||
|
||||
* TcpAttemptFails
|
||||
Defined in `RFC1213 tcpAttemptFails`_.
|
||||
|
||||
.. _RFC1213 tcpAttemptFails: https://tools.ietf.org/html/rfc1213#page-48
|
||||
|
||||
* TcpOutRsts
|
||||
Defined in `RFC1213 tcpOutRsts`_. The RFC says this counter indicates
|
||||
the 'segments sent containing the RST flag', but in linux kernel, this
|
||||
couner indicates the segments kerenl tried to send. The sending
|
||||
process might be failed due to some errors (e.g. memory alloc failed).
|
||||
|
||||
.. _RFC1213 tcpOutRsts: https://tools.ietf.org/html/rfc1213#page-52
|
||||
|
||||
|
||||
TCP Fast Path
|
||||
============
|
||||
When kernel receives a TCP packet, it has two paths to handler the
|
||||
packet, one is fast path, another is slow path. The comment in kernel
|
||||
|
|
@ -383,8 +402,6 @@ increase 1.
|
|||
|
||||
TCP abort
|
||||
========
|
||||
|
||||
|
||||
* TcpExtTCPAbortOnData
|
||||
It means TCP layer has data in flight, but need to close the
|
||||
connection. So TCP layer sends a RST to the other side, indicate the
|
||||
|
|
@ -545,7 +562,6 @@ packet yet, the sender would know packet 4 is out of order. The TCP
|
|||
stack of kernel will increase TcpExtTCPSACKReorder for both of the
|
||||
above scenarios.
|
||||
|
||||
|
||||
DSACK
|
||||
=====
|
||||
The DSACK is defined in `RFC2883`_. The receiver uses DSACK to report
|
||||
|
|
@ -566,13 +582,63 @@ The TCP stack receives an out of order duplicate packet, so it sends a
|
|||
DSACK to the sender.
|
||||
|
||||
* TcpExtTCPDSACKRecv
|
||||
The TCP stack receives a DSACK, which indicate an acknowledged
|
||||
The TCP stack receives a DSACK, which indicates an acknowledged
|
||||
duplicate packet is received.
|
||||
|
||||
* TcpExtTCPDSACKOfoRecv
|
||||
The TCP stack receives a DSACK, which indicate an out of order
|
||||
duplicate packet is received.
|
||||
|
||||
invalid SACK and DSACK
|
||||
====================
|
||||
When a SACK (or DSACK) block is invalid, a corresponding counter would
|
||||
be updated. The validation method is base on the start/end sequence
|
||||
number of the SACK block. For more details, please refer the comment
|
||||
of the function tcp_is_sackblock_valid in the kernel source code. A
|
||||
SACK option could have up to 4 blocks, they are checked
|
||||
individually. E.g., if 3 blocks of a SACk is invalid, the
|
||||
corresponding counter would be updated 3 times. The comment of the
|
||||
`Add counters for discarded SACK blocks`_ patch has additional
|
||||
explaination:
|
||||
|
||||
.. _Add counters for discarded SACK blocks: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18f02545a9a16c9a89778b91a162ad16d510bb32
|
||||
|
||||
* TcpExtTCPSACKDiscard
|
||||
This counter indicates how many SACK blocks are invalid. If the invalid
|
||||
SACK block is caused by ACK recording, the TCP stack will only ignore
|
||||
it and won't update this counter.
|
||||
|
||||
* TcpExtTCPDSACKIgnoredOld and TcpExtTCPDSACKIgnoredNoUndo
|
||||
When a DSACK block is invalid, one of these two counters would be
|
||||
updated. Which counter will be updated depends on the undo_marker flag
|
||||
of the TCP socket. If the undo_marker is not set, the TCP stack isn't
|
||||
likely to re-transmit any packets, and we still receive an invalid
|
||||
DSACK block, the reason might be that the packet is duplicated in the
|
||||
middle of the network. In such scenario, TcpExtTCPDSACKIgnoredNoUndo
|
||||
will be updated. If the undo_marker is set, TcpExtTCPDSACKIgnoredOld
|
||||
will be updated. As implied in its name, it might be an old packet.
|
||||
|
||||
SACK shift
|
||||
=========
|
||||
The linux networking stack stores data in sk_buff struct (skb for
|
||||
short). If a SACK block acrosses multiple skb, the TCP stack will try
|
||||
to re-arrange data in these skb. E.g. if a SACK block acknowledges seq
|
||||
10 to 15, skb1 has seq 10 to 13, skb2 has seq 14 to 20. The seq 14 and
|
||||
15 in skb2 would be moved to skb1. This operation is 'shift'. If a
|
||||
SACK block acknowledges seq 10 to 20, skb1 has seq 10 to 13, skb2 has
|
||||
seq 14 to 20. All data in skb2 will be moved to skb1, and skb2 will be
|
||||
discard, this operation is 'merge'.
|
||||
|
||||
* TcpExtTCPSackShifted
|
||||
A skb is shifted
|
||||
|
||||
* TcpExtTCPSackMerged
|
||||
A skb is merged
|
||||
|
||||
* TcpExtTCPSackShiftFallback
|
||||
A skb should be shifted or merged, but the TCP stack doesn't do it for
|
||||
some reasons.
|
||||
|
||||
TCP out of order
|
||||
===============
|
||||
* TcpExtTCPOFOQueue
|
||||
|
|
@ -662,6 +728,60 @@ unacknowledged number (more strict than `RFC 5961 section 5.2`_).
|
|||
.. _RFC 5961 section 4.2: https://tools.ietf.org/html/rfc5961#page-9
|
||||
.. _RFC 5961 section 5.2: https://tools.ietf.org/html/rfc5961#page-11
|
||||
|
||||
TCP receive window
|
||||
=================
|
||||
* TcpExtTCPWantZeroWindowAdv
|
||||
Depending on current memory usage, the TCP stack tries to set receive
|
||||
window to zero. But the receive window might still be a no-zero
|
||||
value. For example, if the previous window size is 10, and the TCP
|
||||
stack receives 3 bytes, the current window size would be 7 even if the
|
||||
window size calculated by the memory usage is zero.
|
||||
|
||||
* TcpExtTCPToZeroWindowAdv
|
||||
The TCP receive window is set to zero from a no-zero value.
|
||||
|
||||
* TcpExtTCPFromZeroWindowAdv
|
||||
The TCP receive window is set to no-zero value from zero.
|
||||
|
||||
|
||||
Delayed ACK
|
||||
==========
|
||||
The TCP Delayed ACK is a technique which is used for reducing the
|
||||
packet count in the network. For more details, please refer the
|
||||
`Delayed ACK wiki`_
|
||||
|
||||
.. _Delayed ACK wiki: https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
|
||||
|
||||
* TcpExtDelayedACKs
|
||||
A delayed ACK timer expires. The TCP stack will send a pure ACK packet
|
||||
and exit the delayed ACK mode.
|
||||
|
||||
* TcpExtDelayedACKLocked
|
||||
A delayed ACK timer expires, but the TCP stack can't send an ACK
|
||||
immediately due to the socket is locked by a userspace program. The
|
||||
TCP stack will send a pure ACK later (after the userspace program
|
||||
unlock the socket). When the TCP stack sends the pure ACK later, the
|
||||
TCP stack will also update TcpExtDelayedACKs and exit the delayed ACK
|
||||
mode.
|
||||
|
||||
* TcpExtDelayedACKLost
|
||||
It will be updated when the TCP stack receives a packet which has been
|
||||
ACKed. A Delayed ACK loss might cause this issue, but it would also be
|
||||
triggered by other reasons, such as a packet is duplicated in the
|
||||
network.
|
||||
|
||||
Tail Loss Probe (TLP)
|
||||
===================
|
||||
TLP is an algorithm which is used to detect TCP packet loss. For more
|
||||
details, please refer the `TLP paper`_.
|
||||
|
||||
.. _TLP paper: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01
|
||||
|
||||
* TcpExtTCPLossProbes
|
||||
A TLP probe packet is sent.
|
||||
|
||||
* TcpExtTCPLossProbeRecovery
|
||||
A packet loss is detected and recovered by TLP.
|
||||
|
||||
examples
|
||||
=======
|
||||
|
|
|
|||
|
|
@ -417,7 +417,7 @@ is again deprecated and ts[2] holds a hardware timestamp if set.
|
|||
|
||||
Hardware time stamping must also be initialized for each device driver
|
||||
that is expected to do hardware time stamping. The parameter is defined in
|
||||
/include/linux/net_tstamp.h as:
|
||||
include/uapi/linux/net_tstamp.h as:
|
||||
|
||||
struct hwtstamp_config {
|
||||
int flags; /* no flags defined right now, must be zero */
|
||||
|
|
@ -487,7 +487,7 @@ enum {
|
|||
HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
|
||||
|
||||
/* for the complete list of values, please check
|
||||
* the include file /include/linux/net_tstamp.h
|
||||
* the include file include/uapi/linux/net_tstamp.h
|
||||
*/
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -56,26 +56,32 @@ of any kernel data structures.
|
|||
|
||||
dentry-state:
|
||||
|
||||
From linux/fs/dentry.c:
|
||||
From linux/include/linux/dcache.h:
|
||||
--------------------------------------------------------------
|
||||
struct {
|
||||
struct dentry_stat_t dentry_stat {
|
||||
int nr_dentry;
|
||||
int nr_unused;
|
||||
int age_limit; /* age in seconds */
|
||||
int want_pages; /* pages requested by system */
|
||||
int dummy[2];
|
||||
} dentry_stat = {0, 0, 45, 0,};
|
||||
--------------------------------------------------------------
|
||||
int nr_negative; /* # of unused negative dentries */
|
||||
int dummy; /* Reserved for future use */
|
||||
};
|
||||
--------------------------------------------------------------
|
||||
|
||||
Dentries are dynamically allocated and deallocated.
|
||||
|
||||
nr_dentry shows the total number of dentries allocated (active
|
||||
+ unused). nr_unused shows the number of dentries that are not
|
||||
actively used, but are saved in the LRU list for future reuse.
|
||||
|
||||
Dentries are dynamically allocated and deallocated, and
|
||||
nr_dentry seems to be 0 all the time. Hence it's safe to
|
||||
assume that only nr_unused, age_limit and want_pages are
|
||||
used. Nr_unused seems to be exactly what its name says.
|
||||
Age_limit is the age in seconds after which dcache entries
|
||||
can be reclaimed when memory is short and want_pages is
|
||||
nonzero when shrink_dcache_pages() has been called and the
|
||||
dcache isn't pruned yet.
|
||||
|
||||
nr_negative shows the number of unused dentries that are also
|
||||
negative dentries which do not mapped to actual files.
|
||||
|
||||
==============================================================
|
||||
|
||||
dquot-max & dquot-nr:
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ Do some work...
|
|||
The same can also be done from an application program.
|
||||
|
||||
Disable specific CPU's specific idle state from cpuidle sysfs (see
|
||||
Documentation/cpuidle/sysfs.txt):
|
||||
Documentation/admin-guide/pm/cpuidle.rst):
|
||||
# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -242,6 +242,6 @@ References
|
|||
==========
|
||||
|
||||
.. [white-paper] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
|
||||
.. [api-spec] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
|
||||
.. [api-spec] http://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
|
||||
.. [amd-apm] http://support.amd.com/TechDocs/24593.pdf (section 15.34)
|
||||
.. [kvm-forum] http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Fenghua Yu <fenghua.yu@intel.com>
|
|||
Tony Luck <tony.luck@intel.com>
|
||||
Vikas Shivappa <vikas.shivappa@intel.com>
|
||||
|
||||
This feature is enabled by the CONFIG_RESCTRL and the X86 /proc/cpuinfo
|
||||
This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo
|
||||
flag bits:
|
||||
RDT (Resource Director Technology) Allocation - "rdt_a"
|
||||
CAT (Cache Allocation Technology) - "cat_l3", "cat_l2"
|
||||
|
|
|
|||
4
Kbuild
4
Kbuild
|
|
@ -26,9 +26,7 @@ timeconst-file := include/generated/timeconst.h
|
|||
|
||||
targets += $(timeconst-file)
|
||||
|
||||
define filechk_gentimeconst
|
||||
(echo $(CONFIG_HZ) | bc -q $< )
|
||||
endef
|
||||
filechk_gentimeconst = echo $(CONFIG_HZ) | bc -q $<
|
||||
|
||||
$(timeconst-file): kernel/time/timeconst.bc FORCE
|
||||
$(call filechk,gentimeconst)
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue