Merge branches 'iommu/fixes', 'arm/msm', 'arm/tegra', 'arm/mediatek', 'x86/vt-d', 'x86/amd', 'hyper-v' and 'core' into next
This commit is contained in:
Joerg Roedel
commit
d05e4c8600
|
|
@ -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
|
||||
|
|
|
|||
20
CREDITS
20
CREDITS
|
|
@ -842,10 +842,9 @@ D: ax25-utils maintainer.
|
|||
|
||||
N: Helge Deller
|
||||
E: deller@gmx.de
|
||||
E: hdeller@redhat.de
|
||||
D: PA-RISC Linux hacker, LASI-, ASP-, WAX-, LCD/LED-driver
|
||||
S: Schimmelsrain 1
|
||||
S: D-69231 Rauenberg
|
||||
W: http://www.parisc-linux.org/
|
||||
D: PA-RISC Linux architecture maintainer
|
||||
D: LASI-, ASP-, WAX-, LCD/LED-driver
|
||||
S: Germany
|
||||
|
||||
N: Jean Delvare
|
||||
|
|
@ -1361,7 +1360,7 @@ S: Stellenbosch, Western Cape
|
|||
S: South Africa
|
||||
|
||||
N: Grant Grundler
|
||||
E: grundler@parisc-linux.org
|
||||
E: grantgrundler@gmail.com
|
||||
W: http://obmouse.sourceforge.net/
|
||||
W: http://www.parisc-linux.org/
|
||||
D: obmouse - rewrote Olivier Florent's Omnibook 600 "pop-up" mouse driver
|
||||
|
|
@ -2492,7 +2491,7 @@ S: Syracuse, New York 13206
|
|||
S: USA
|
||||
|
||||
N: Kyle McMartin
|
||||
E: kyle@parisc-linux.org
|
||||
E: kyle@mcmartin.ca
|
||||
D: Linux/PARISC hacker
|
||||
D: AD1889 sound driver
|
||||
S: Ottawa, Canada
|
||||
|
|
@ -3780,14 +3779,13 @@ S: 21513 Conradia Ct
|
|||
S: Cupertino, CA 95014
|
||||
S: USA
|
||||
|
||||
N: Thibaut Varene
|
||||
E: T-Bone@parisc-linux.org
|
||||
W: http://www.parisc-linux.org/~varenet/
|
||||
P: 1024D/B7D2F063 E67C 0D43 A75E 12A5 BB1C FA2F 1E32 C3DA B7D2 F063
|
||||
N: Thibaut Varène
|
||||
E: hacks+kernel@slashdirt.org
|
||||
W: http://hacks.slashdirt.org/
|
||||
D: PA-RISC port minion, PDC and GSCPS2 drivers, debuglocks and other bits
|
||||
D: Some ARM at91rm9200 bits, S1D13XXX FB driver, random patches here and there
|
||||
D: AD1889 sound driver
|
||||
S: Paris, France
|
||||
S: France
|
||||
|
||||
N: Heikki Vatiainen
|
||||
E: hessu@cs.tut.fi
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
|||
cpld3_version
|
||||
|
||||
Date: November 2018
|
||||
KernelVersion: 4.21
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on LED board.
|
||||
|
|
@ -35,7 +35,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
|||
jtag_enable
|
||||
|
||||
Date: November 2018
|
||||
KernelVersion: 4.21
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files enable and disable the access to the JTAG domain.
|
||||
By default access to the JTAG domain is disabled.
|
||||
|
|
@ -105,7 +105,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
|||
reset_voltmon_upgrade_fail
|
||||
|
||||
Date: November 2018
|
||||
KernelVersion: 4.21
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show the system reset cause, as following: ComEx
|
||||
power fail, reset from ComEx, system platform reset, reset
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
.. _readme:
|
||||
|
||||
Linux kernel release 4.x <http://kernel.org/>
|
||||
Linux kernel release 5.x <http://kernel.org/>
|
||||
=============================================
|
||||
|
||||
These are the release notes for Linux version 4. Read them carefully,
|
||||
These are the release notes for Linux version 5. Read them carefully,
|
||||
as they tell you what this is all about, explain how to install the
|
||||
kernel, and what to do if something goes wrong.
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ Installing the kernel source
|
|||
directory where you have permissions (e.g. your home directory) and
|
||||
unpack it::
|
||||
|
||||
xz -cd linux-4.X.tar.xz | tar xvf -
|
||||
xz -cd linux-5.x.tar.xz | tar xvf -
|
||||
|
||||
Replace "X" with the version number of the latest kernel.
|
||||
|
||||
|
|
@ -72,26 +72,26 @@ Installing the kernel source
|
|||
files. They should match the library, and not get messed up by
|
||||
whatever the kernel-du-jour happens to be.
|
||||
|
||||
- You can also upgrade between 4.x releases by patching. Patches are
|
||||
- You can also upgrade between 5.x releases by patching. Patches are
|
||||
distributed in the xz format. To install by patching, get all the
|
||||
newer patch files, enter the top level directory of the kernel source
|
||||
(linux-4.X) and execute::
|
||||
(linux-5.x) and execute::
|
||||
|
||||
xz -cd ../patch-4.x.xz | patch -p1
|
||||
xz -cd ../patch-5.x.xz | patch -p1
|
||||
|
||||
Replace "x" for all versions bigger than the version "X" of your current
|
||||
Replace "x" for all versions bigger than the version "x" of your current
|
||||
source tree, **in_order**, and you should be ok. You may want to remove
|
||||
the backup files (some-file-name~ or some-file-name.orig), and make sure
|
||||
that there are no failed patches (some-file-name# or some-file-name.rej).
|
||||
If there are, either you or I have made a mistake.
|
||||
|
||||
Unlike patches for the 4.x kernels, patches for the 4.x.y kernels
|
||||
Unlike patches for the 5.x kernels, patches for the 5.x.y kernels
|
||||
(also known as the -stable kernels) are not incremental but instead apply
|
||||
directly to the base 4.x kernel. For example, if your base kernel is 4.0
|
||||
and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1
|
||||
and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and
|
||||
want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is,
|
||||
patch -R) **before** applying the 4.0.3 patch. You can read more on this in
|
||||
directly to the base 5.x kernel. For example, if your base kernel is 5.0
|
||||
and you want to apply the 5.0.3 patch, you must not first apply the 5.0.1
|
||||
and 5.0.2 patches. Similarly, if you are running kernel version 5.0.2 and
|
||||
want to jump to 5.0.3, you must first reverse the 5.0.2 patch (that is,
|
||||
patch -R) **before** applying the 5.0.3 patch. You can read more on this in
|
||||
:ref:`Documentation/process/applying-patches.rst <applying_patches>`.
|
||||
|
||||
Alternatively, the script patch-kernel can be used to automate this
|
||||
|
|
@ -114,7 +114,7 @@ Installing the kernel source
|
|||
Software requirements
|
||||
---------------------
|
||||
|
||||
Compiling and running the 4.x kernels requires up-to-date
|
||||
Compiling and running the 5.x kernels requires up-to-date
|
||||
versions of various software packages. Consult
|
||||
:ref:`Documentation/process/changes.rst <changes>` for the minimum version numbers
|
||||
required and how to get updates for these packages. Beware that using
|
||||
|
|
@ -132,12 +132,12 @@ Build directory for the kernel
|
|||
place for the output files (including .config).
|
||||
Example::
|
||||
|
||||
kernel source code: /usr/src/linux-4.X
|
||||
kernel source code: /usr/src/linux-5.x
|
||||
build directory: /home/name/build/kernel
|
||||
|
||||
To configure and build the kernel, use::
|
||||
|
||||
cd /usr/src/linux-4.X
|
||||
cd /usr/src/linux-5.x
|
||||
make O=/home/name/build/kernel menuconfig
|
||||
make O=/home/name/build/kernel
|
||||
sudo make O=/home/name/build/kernel modules_install install
|
||||
|
|
|
|||
|
|
@ -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?
|
||||
-------------------------------------------
|
||||
|
|
|
|||
|
|
@ -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",
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1,14 +0,0 @@
|
|||
NVIDIA Tegra 20 GART
|
||||
|
||||
Required properties:
|
||||
- compatible: "nvidia,tegra20-gart"
|
||||
- reg: Two pairs of cells specifying the physical address and size of
|
||||
the memory controller registers and the GART aperture respectively.
|
||||
|
||||
Example:
|
||||
|
||||
gart {
|
||||
compatible = "nvidia,tegra20-gart";
|
||||
reg = <0x7000f024 0x00000018 /* controller registers */
|
||||
0x58000000 0x02000000>; /* GART aperture */
|
||||
};
|
||||
|
|
@ -1,26 +1,37 @@
|
|||
NVIDIA Tegra20 MC(Memory Controller)
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-mc"
|
||||
- reg : Should contain 2 register ranges(address and length); see the
|
||||
example below. Note that the MC registers are interleaved with the
|
||||
GART registers, and hence must be represented as multiple ranges.
|
||||
- compatible : "nvidia,tegra20-mc-gart"
|
||||
- reg : Should contain 2 register ranges: physical base address and length of
|
||||
the controller's registers and the GART aperture respectively.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- mc: the module's clock input
|
||||
- interrupts : Should contain MC General interrupt.
|
||||
- #reset-cells : Should be 1. This cell represents memory client module ID.
|
||||
The assignments may be found in header file <dt-bindings/memory/tegra20-mc.h>
|
||||
or in the TRM documentation.
|
||||
- #iommu-cells: Should be 0. This cell represents the number of cells in an
|
||||
IOMMU specifier needed to encode an address. GART supports only a single
|
||||
address space that is shared by all devices, therefore no additional
|
||||
information needed for the address encoding.
|
||||
|
||||
Example:
|
||||
mc: memory-controller@7000f000 {
|
||||
compatible = "nvidia,tegra20-mc";
|
||||
reg = <0x7000f000 0x024
|
||||
0x7000f03c 0x3c4>;
|
||||
interrupts = <0 77 0x04>;
|
||||
compatible = "nvidia,tegra20-mc-gart";
|
||||
reg = <0x7000f000 0x400 /* controller registers */
|
||||
0x58000000 0x02000000>; /* GART aperture */
|
||||
clocks = <&tegra_car TEGRA20_CLK_MC>;
|
||||
clock-names = "mc";
|
||||
interrupts = <GIC_SPI 77 0x04>;
|
||||
#reset-cells = <1>;
|
||||
#iommu-cells = <0>;
|
||||
};
|
||||
|
||||
video-codec@6001a000 {
|
||||
compatible = "nvidia,tegra20-vde";
|
||||
...
|
||||
resets = <&mc TEGRA20_MC_RESET_VDE>;
|
||||
iommus = <&mc>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -533,16 +533,12 @@ Bridge VLAN filtering
|
|||
function that the driver has to call for each VLAN the given port is a member
|
||||
of. A switchdev object is used to carry the VID and bridge flags.
|
||||
|
||||
- port_fdb_prepare: bridge layer function invoked when the bridge prepares the
|
||||
installation of a Forwarding Database entry. If the operation is not
|
||||
supported, this function should return -EOPNOTSUPP to inform the bridge code
|
||||
to fallback to a software implementation. No hardware setup must be done in
|
||||
this function. See port_fdb_add for this and details.
|
||||
|
||||
- port_fdb_add: bridge layer function invoked when the bridge wants to install a
|
||||
Forwarding Database entry, the switch hardware should be programmed with the
|
||||
specified address in the specified VLAN Id in the forwarding database
|
||||
associated with this VLAN ID
|
||||
associated with this VLAN ID. If the operation is not supported, this
|
||||
function should return -EOPNOTSUPP to inform the bridge code to fallback to
|
||||
a software implementation.
|
||||
|
||||
Note: VLAN ID 0 corresponds to the port private database, which, in the context
|
||||
of DSA, would be the its port-based VLAN, used by the associated bridge device.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Intro
|
|||
=====
|
||||
|
||||
The MSG_ZEROCOPY flag enables copy avoidance for socket send calls.
|
||||
The feature is currently implemented for TCP sockets.
|
||||
The feature is currently implemented for TCP and UDP sockets.
|
||||
|
||||
|
||||
Opportunity and Caveats
|
||||
|
|
|
|||
|
|
@ -22,8 +22,9 @@ and changeable from userspace under certain rules.
|
|||
2. Querying from userspace
|
||||
|
||||
Both admin and operational state can be queried via the netlink
|
||||
operation RTM_GETLINK. It is also possible to subscribe to RTMGRP_LINK
|
||||
to be notified of updates. This is important for setting from userspace.
|
||||
operation RTM_GETLINK. It is also possible to subscribe to RTNLGRP_LINK
|
||||
to be notified of updates while the interface is admin up. This is
|
||||
important for setting from userspace.
|
||||
|
||||
These values contain interface state:
|
||||
|
||||
|
|
@ -101,8 +102,9 @@ because some driver controlled protocol establishment has to
|
|||
complete. Corresponding functions are netif_dormant_on() to set the
|
||||
flag, netif_dormant_off() to clear it and netif_dormant() to query.
|
||||
|
||||
On device allocation, networking core sets the flags equivalent to
|
||||
netif_carrier_ok() and !netif_dormant().
|
||||
On device allocation, both flags __LINK_STATE_NOCARRIER and
|
||||
__LINK_STATE_DORMANT are cleared, so the effective state is equivalent
|
||||
to netif_carrier_ok() and !netif_dormant().
|
||||
|
||||
|
||||
Whenever the driver CHANGES one of these flags, a workqueue event is
|
||||
|
|
@ -133,11 +135,11 @@ netif_carrier_ok() && !netif_dormant() is set by the
|
|||
driver. Afterwards, the userspace application can set IFLA_OPERSTATE
|
||||
to IF_OPER_DORMANT or IF_OPER_UP as long as the driver does not set
|
||||
netif_carrier_off() or netif_dormant_on(). Changes made by userspace
|
||||
are multicasted on the netlink group RTMGRP_LINK.
|
||||
are multicasted on the netlink group RTNLGRP_LINK.
|
||||
|
||||
So basically a 802.1X supplicant interacts with the kernel like this:
|
||||
|
||||
-subscribe to RTMGRP_LINK
|
||||
-subscribe to RTNLGRP_LINK
|
||||
-set IFLA_LINKMODE to 1 via RTM_SETLINK
|
||||
-query RTM_GETLINK once to get initial state
|
||||
-if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until
|
||||
|
|
|
|||
|
|
@ -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
|
||||
=======
|
||||
|
|
|
|||
|
|
@ -92,11 +92,11 @@ device.
|
|||
Switch ID
|
||||
^^^^^^^^^
|
||||
|
||||
The switchdev driver must implement the switchdev op switchdev_port_attr_get
|
||||
for SWITCHDEV_ATTR_ID_PORT_PARENT_ID for each port netdev, returning the same
|
||||
physical ID for each port of a switch. The ID must be unique between switches
|
||||
on the same system. The ID does not need to be unique between switches on
|
||||
different systems.
|
||||
The switchdev driver must implement the net_device operation
|
||||
ndo_get_port_parent_id for each port netdev, returning the same physical ID for
|
||||
each port of a switch. The ID must be unique between switches on the same
|
||||
system. The ID does not need to be unique between switches on different
|
||||
systems.
|
||||
|
||||
The switch ID is used to locate ports on a switch and to know if aggregated
|
||||
ports belong to the same switch.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
*/
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -216,14 +216,14 @@ You can use the ``interdiff`` program (http://cyberelk.net/tim/patchutils/) to
|
|||
generate a patch representing the differences between two patches and then
|
||||
apply the result.
|
||||
|
||||
This will let you move from something like 4.7.2 to 4.7.3 in a single
|
||||
This will let you move from something like 5.7.2 to 5.7.3 in a single
|
||||
step. The -z flag to interdiff will even let you feed it patches in gzip or
|
||||
bzip2 compressed form directly without the use of zcat or bzcat or manual
|
||||
decompression.
|
||||
|
||||
Here's how you'd go from 4.7.2 to 4.7.3 in a single step::
|
||||
Here's how you'd go from 5.7.2 to 5.7.3 in a single step::
|
||||
|
||||
interdiff -z ../patch-4.7.2.gz ../patch-4.7.3.gz | patch -p1
|
||||
interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
|
||||
|
||||
Although interdiff may save you a step or two you are generally advised to
|
||||
do the additional steps since interdiff can get things wrong in some cases.
|
||||
|
|
@ -245,62 +245,67 @@ The patches are available at http://kernel.org/
|
|||
Most recent patches are linked from the front page, but they also have
|
||||
specific homes.
|
||||
|
||||
The 4.x.y (-stable) and 4.x patches live at
|
||||
The 5.x.y (-stable) and 5.x patches live at
|
||||
|
||||
https://www.kernel.org/pub/linux/kernel/v4.x/
|
||||
https://www.kernel.org/pub/linux/kernel/v5.x/
|
||||
|
||||
The -rc patches live at
|
||||
The -rc patches are not stored on the webserver but are generated on
|
||||
demand from git tags such as
|
||||
|
||||
https://www.kernel.org/pub/linux/kernel/v4.x/testing/
|
||||
https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
|
||||
|
||||
The stable -rc patches live at
|
||||
|
||||
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
|
||||
|
||||
|
||||
The 4.x kernels
|
||||
The 5.x kernels
|
||||
===============
|
||||
|
||||
These are the base stable releases released by Linus. The highest numbered
|
||||
release is the most recent.
|
||||
|
||||
If regressions or other serious flaws are found, then a -stable fix patch
|
||||
will be released (see below) on top of this base. Once a new 4.x base
|
||||
will be released (see below) on top of this base. Once a new 5.x base
|
||||
kernel is released, a patch is made available that is a delta between the
|
||||
previous 4.x kernel and the new one.
|
||||
previous 5.x kernel and the new one.
|
||||
|
||||
To apply a patch moving from 4.6 to 4.7, you'd do the following (note
|
||||
that such patches do **NOT** apply on top of 4.x.y kernels but on top of the
|
||||
base 4.x kernel -- if you need to move from 4.x.y to 4.x+1 you need to
|
||||
first revert the 4.x.y patch).
|
||||
To apply a patch moving from 5.6 to 5.7, you'd do the following (note
|
||||
that such patches do **NOT** apply on top of 5.x.y kernels but on top of the
|
||||
base 5.x kernel -- if you need to move from 5.x.y to 5.x+1 you need to
|
||||
first revert the 5.x.y patch).
|
||||
|
||||
Here are some examples::
|
||||
|
||||
# moving from 4.6 to 4.7
|
||||
# moving from 5.6 to 5.7
|
||||
|
||||
$ cd ~/linux-4.6 # change to kernel source dir
|
||||
$ patch -p1 < ../patch-4.7 # apply the 4.7 patch
|
||||
$ cd ~/linux-5.6 # change to kernel source dir
|
||||
$ patch -p1 < ../patch-5.7 # apply the 5.7 patch
|
||||
$ cd ..
|
||||
$ mv linux-4.6 linux-4.7 # rename source dir
|
||||
$ mv linux-5.6 linux-5.7 # rename source dir
|
||||
|
||||
# moving from 4.6.1 to 4.7
|
||||
# moving from 5.6.1 to 5.7
|
||||
|
||||
$ cd ~/linux-4.6.1 # change to kernel source dir
|
||||
$ patch -p1 -R < ../patch-4.6.1 # revert the 4.6.1 patch
|
||||
# source dir is now 4.6
|
||||
$ patch -p1 < ../patch-4.7 # apply new 4.7 patch
|
||||
$ cd ~/linux-5.6.1 # change to kernel source dir
|
||||
$ patch -p1 -R < ../patch-5.6.1 # revert the 5.6.1 patch
|
||||
# source dir is now 5.6
|
||||
$ patch -p1 < ../patch-5.7 # apply new 5.7 patch
|
||||
$ cd ..
|
||||
$ mv linux-4.6.1 linux-4.7 # rename source dir
|
||||
$ mv linux-5.6.1 linux-5.7 # rename source dir
|
||||
|
||||
|
||||
The 4.x.y kernels
|
||||
The 5.x.y kernels
|
||||
=================
|
||||
|
||||
Kernels with 3-digit versions are -stable kernels. They contain small(ish)
|
||||
critical fixes for security problems or significant regressions discovered
|
||||
in a given 4.x kernel.
|
||||
in a given 5.x kernel.
|
||||
|
||||
This is the recommended branch for users who want the most recent stable
|
||||
kernel and are not interested in helping test development/experimental
|
||||
versions.
|
||||
|
||||
If no 4.x.y kernel is available, then the highest numbered 4.x kernel is
|
||||
If no 5.x.y kernel is available, then the highest numbered 5.x kernel is
|
||||
the current stable kernel.
|
||||
|
||||
.. note::
|
||||
|
|
@ -308,23 +313,23 @@ the current stable kernel.
|
|||
The -stable team usually do make incremental patches available as well
|
||||
as patches against the latest mainline release, but I only cover the
|
||||
non-incremental ones below. The incremental ones can be found at
|
||||
https://www.kernel.org/pub/linux/kernel/v4.x/incr/
|
||||
https://www.kernel.org/pub/linux/kernel/v5.x/incr/
|
||||
|
||||
These patches are not incremental, meaning that for example the 4.7.3
|
||||
patch does not apply on top of the 4.7.2 kernel source, but rather on top
|
||||
of the base 4.7 kernel source.
|
||||
These patches are not incremental, meaning that for example the 5.7.3
|
||||
patch does not apply on top of the 5.7.2 kernel source, but rather on top
|
||||
of the base 5.7 kernel source.
|
||||
|
||||
So, in order to apply the 4.7.3 patch to your existing 4.7.2 kernel
|
||||
source you have to first back out the 4.7.2 patch (so you are left with a
|
||||
base 4.7 kernel source) and then apply the new 4.7.3 patch.
|
||||
So, in order to apply the 5.7.3 patch to your existing 5.7.2 kernel
|
||||
source you have to first back out the 5.7.2 patch (so you are left with a
|
||||
base 5.7 kernel source) and then apply the new 5.7.3 patch.
|
||||
|
||||
Here's a small example::
|
||||
|
||||
$ cd ~/linux-4.7.2 # change to the kernel source dir
|
||||
$ patch -p1 -R < ../patch-4.7.2 # revert the 4.7.2 patch
|
||||
$ patch -p1 < ../patch-4.7.3 # apply the new 4.7.3 patch
|
||||
$ cd ~/linux-5.7.2 # change to the kernel source dir
|
||||
$ patch -p1 -R < ../patch-5.7.2 # revert the 5.7.2 patch
|
||||
$ patch -p1 < ../patch-5.7.3 # apply the new 5.7.3 patch
|
||||
$ cd ..
|
||||
$ mv linux-4.7.2 linux-4.7.3 # rename the kernel source dir
|
||||
$ mv linux-5.7.2 linux-5.7.3 # rename the kernel source dir
|
||||
|
||||
The -rc kernels
|
||||
===============
|
||||
|
|
@ -343,38 +348,38 @@ This is a good branch to run for people who want to help out testing
|
|||
development kernels but do not want to run some of the really experimental
|
||||
stuff (such people should see the sections about -next and -mm kernels below).
|
||||
|
||||
The -rc patches are not incremental, they apply to a base 4.x kernel, just
|
||||
like the 4.x.y patches described above. The kernel version before the -rcN
|
||||
The -rc patches are not incremental, they apply to a base 5.x kernel, just
|
||||
like the 5.x.y patches described above. The kernel version before the -rcN
|
||||
suffix denotes the version of the kernel that this -rc kernel will eventually
|
||||
turn into.
|
||||
|
||||
So, 4.8-rc5 means that this is the fifth release candidate for the 4.8
|
||||
kernel and the patch should be applied on top of the 4.7 kernel source.
|
||||
So, 5.8-rc5 means that this is the fifth release candidate for the 5.8
|
||||
kernel and the patch should be applied on top of the 5.7 kernel source.
|
||||
|
||||
Here are 3 examples of how to apply these patches::
|
||||
|
||||
# first an example of moving from 4.7 to 4.8-rc3
|
||||
# first an example of moving from 5.7 to 5.8-rc3
|
||||
|
||||
$ cd ~/linux-4.7 # change to the 4.7 source dir
|
||||
$ patch -p1 < ../patch-4.8-rc3 # apply the 4.8-rc3 patch
|
||||
$ cd ~/linux-5.7 # change to the 5.7 source dir
|
||||
$ patch -p1 < ../patch-5.8-rc3 # apply the 5.8-rc3 patch
|
||||
$ cd ..
|
||||
$ mv linux-4.7 linux-4.8-rc3 # rename the source dir
|
||||
$ mv linux-5.7 linux-5.8-rc3 # rename the source dir
|
||||
|
||||
# now let's move from 4.8-rc3 to 4.8-rc5
|
||||
# now let's move from 5.8-rc3 to 5.8-rc5
|
||||
|
||||
$ cd ~/linux-4.8-rc3 # change to the 4.8-rc3 dir
|
||||
$ patch -p1 -R < ../patch-4.8-rc3 # revert the 4.8-rc3 patch
|
||||
$ patch -p1 < ../patch-4.8-rc5 # apply the new 4.8-rc5 patch
|
||||
$ cd ~/linux-5.8-rc3 # change to the 5.8-rc3 dir
|
||||
$ patch -p1 -R < ../patch-5.8-rc3 # revert the 5.8-rc3 patch
|
||||
$ patch -p1 < ../patch-5.8-rc5 # apply the new 5.8-rc5 patch
|
||||
$ cd ..
|
||||
$ mv linux-4.8-rc3 linux-4.8-rc5 # rename the source dir
|
||||
$ mv linux-5.8-rc3 linux-5.8-rc5 # rename the source dir
|
||||
|
||||
# finally let's try and move from 4.7.3 to 4.8-rc5
|
||||
# finally let's try and move from 5.7.3 to 5.8-rc5
|
||||
|
||||
$ cd ~/linux-4.7.3 # change to the kernel source dir
|
||||
$ patch -p1 -R < ../patch-4.7.3 # revert the 4.7.3 patch
|
||||
$ patch -p1 < ../patch-4.8-rc5 # apply new 4.8-rc5 patch
|
||||
$ cd ~/linux-5.7.3 # change to the kernel source dir
|
||||
$ patch -p1 -R < ../patch-5.7.3 # revert the 5.7.3 patch
|
||||
$ patch -p1 < ../patch-5.8-rc5 # apply new 5.8-rc5 patch
|
||||
$ cd ..
|
||||
$ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir
|
||||
$ mv linux-5.7.3 linux-5.8-rc5 # rename the kernel source dir
|
||||
|
||||
|
||||
The -mm patches and the linux-next tree
|
||||
|
|
|
|||
|
|
@ -56,26 +56,34 @@ 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 map to any files. Instead,
|
||||
they help speeding up rejection of non-existing files provided
|
||||
by the users.
|
||||
|
||||
==============================================================
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
.. _it_readme:
|
||||
|
||||
Rilascio del kernel Linux 4.x <http://kernel.org/>
|
||||
Rilascio del kernel Linux 5.x <http://kernel.org/>
|
||||
===================================================
|
||||
|
||||
.. warning::
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
147
MAINTAINERS
147
MAINTAINERS
|
|
@ -409,8 +409,7 @@ F: drivers/platform/x86/wmi.c
|
|||
F: include/uapi/linux/wmi.h
|
||||
|
||||
AD1889 ALSA SOUND DRIVER
|
||||
M: Thibaut Varene <T-Bone@parisc-linux.org>
|
||||
W: http://wiki.parisc-linux.org/AD1889
|
||||
W: https://parisc.wiki.kernel.org/index.php/AD1889
|
||||
L: linux-parisc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: sound/pci/ad1889.*
|
||||
|
|
@ -2848,8 +2847,11 @@ F: include/uapi/linux/if_bonding.h
|
|||
BPF (Safe dynamic programs and tools)
|
||||
M: Alexei Starovoitov <ast@kernel.org>
|
||||
M: Daniel Borkmann <daniel@iogearbox.net>
|
||||
R: Martin KaFai Lau <kafai@fb.com>
|
||||
R: Song Liu <songliubraving@fb.com>
|
||||
R: Yonghong Song <yhs@fb.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
|
||||
Q: https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147
|
||||
|
|
@ -2873,10 +2875,13 @@ F: samples/bpf/
|
|||
F: tools/bpf/
|
||||
F: tools/lib/bpf/
|
||||
F: tools/testing/selftests/bpf/
|
||||
K: bpf
|
||||
N: bpf
|
||||
|
||||
BPF JIT for ARM
|
||||
M: Shubham Bansal <illusionist.neo@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/arm/net/
|
||||
|
||||
|
|
@ -2885,18 +2890,21 @@ M: Daniel Borkmann <daniel@iogearbox.net>
|
|||
M: Alexei Starovoitov <ast@kernel.org>
|
||||
M: Zi Shen Lim <zlim.lnx@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Supported
|
||||
F: arch/arm64/net/
|
||||
|
||||
BPF JIT for MIPS (32-BIT AND 64-BIT)
|
||||
M: Paul Burton <paul.burton@mips.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/mips/net/
|
||||
|
||||
BPF JIT for NFP NICs
|
||||
M: Jakub Kicinski <jakub.kicinski@netronome.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/netronome/nfp/bpf/
|
||||
|
||||
|
|
@ -2904,6 +2912,7 @@ BPF JIT for POWERPC (32-BIT AND 64-BIT)
|
|||
M: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
|
||||
M: Sandipan Das <sandipan@linux.ibm.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/powerpc/net/
|
||||
|
||||
|
|
@ -2911,6 +2920,7 @@ BPF JIT for S390
|
|||
M: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
||||
M: Heiko Carstens <heiko.carstens@de.ibm.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/s390/net/
|
||||
X: arch/s390/net/pnet.c
|
||||
|
|
@ -2918,12 +2928,14 @@ X: arch/s390/net/pnet.c
|
|||
BPF JIT for SPARC (32-BIT AND 64-BIT)
|
||||
M: David S. Miller <davem@davemloft.net>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/sparc/net/
|
||||
|
||||
BPF JIT for X86 32-BIT
|
||||
M: Wang YanQing <udknight@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/x86/net/bpf_jit_comp32.c
|
||||
|
||||
|
|
@ -2931,6 +2943,7 @@ BPF JIT for X86 64-BIT
|
|||
M: Alexei Starovoitov <ast@kernel.org>
|
||||
M: Daniel Borkmann <daniel@iogearbox.net>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Supported
|
||||
F: arch/x86/net/
|
||||
X: arch/x86/net/bpf_jit_comp32.c
|
||||
|
|
@ -3052,8 +3065,8 @@ F: include/linux/bcm963xx_nvram.h
|
|||
F: include/linux/bcm963xx_tag.h
|
||||
|
||||
BROADCOM BNX2 GIGABIT ETHERNET DRIVER
|
||||
M: Rasesh Mody <rasesh.mody@cavium.com>
|
||||
M: Dept-GELinuxNICDev@cavium.com
|
||||
M: Rasesh Mody <rmody@marvell.com>
|
||||
M: GR-Linux-NIC-Dev@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/broadcom/bnx2.*
|
||||
|
|
@ -3072,9 +3085,9 @@ S: Supported
|
|||
F: drivers/scsi/bnx2i/
|
||||
|
||||
BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER
|
||||
M: Ariel Elior <ariel.elior@cavium.com>
|
||||
M: Sudarsana Kalluru <sudarsana.kalluru@cavium.com>
|
||||
M: everest-linux-l2@cavium.com
|
||||
M: Ariel Elior <aelior@marvell.com>
|
||||
M: Sudarsana Kalluru <skalluru@marvell.com>
|
||||
M: GR-everest-linux-l2@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/broadcom/bnx2x/
|
||||
|
|
@ -3249,9 +3262,9 @@ S: Supported
|
|||
F: drivers/scsi/bfa/
|
||||
|
||||
BROCADE BNA 10 GIGABIT ETHERNET DRIVER
|
||||
M: Rasesh Mody <rasesh.mody@cavium.com>
|
||||
M: Sudarsana Kalluru <sudarsana.kalluru@cavium.com>
|
||||
M: Dept-GELinuxNICDev@cavium.com
|
||||
M: Rasesh Mody <rmody@marvell.com>
|
||||
M: Sudarsana Kalluru <skalluru@marvell.com>
|
||||
M: GR-Linux-NIC-Dev@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/brocade/bna/
|
||||
|
|
@ -3385,9 +3398,8 @@ F: Documentation/media/v4l-drivers/cafe_ccic*
|
|||
F: drivers/media/platform/marvell-ccic/
|
||||
|
||||
CAIF NETWORK LAYER
|
||||
M: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
S: Orphan
|
||||
F: Documentation/networking/caif/
|
||||
F: drivers/net/caif/
|
||||
F: include/uapi/linux/caif/
|
||||
|
|
@ -3471,10 +3483,9 @@ F: drivers/i2c/busses/i2c-octeon*
|
|||
F: drivers/i2c/busses/i2c-thunderx*
|
||||
|
||||
CAVIUM LIQUIDIO NETWORK DRIVER
|
||||
M: Derek Chickles <derek.chickles@caviumnetworks.com>
|
||||
M: Satanand Burla <satananda.burla@caviumnetworks.com>
|
||||
M: Felix Manlunas <felix.manlunas@caviumnetworks.com>
|
||||
M: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
|
||||
M: Derek Chickles <dchickles@marvell.com>
|
||||
M: Satanand Burla <sburla@marvell.com>
|
||||
M: Felix Manlunas <fmanlunas@marvell.com>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.cavium.com
|
||||
S: Supported
|
||||
|
|
@ -3951,7 +3962,7 @@ L: netdev@vger.kernel.org
|
|||
S: Maintained
|
||||
F: drivers/net/ethernet/ti/cpmac.c
|
||||
|
||||
CPU FREQUENCY DRIVERS
|
||||
CPU FREQUENCY SCALING FRAMEWORK
|
||||
M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
|
||||
M: Viresh Kumar <viresh.kumar@linaro.org>
|
||||
L: linux-pm@vger.kernel.org
|
||||
|
|
@ -3959,6 +3970,8 @@ S: Maintained
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
|
||||
T: git git://git.linaro.org/people/vireshk/linux.git (For ARM Updates)
|
||||
B: https://bugzilla.kernel.org
|
||||
F: Documentation/admin-guide/pm/cpufreq.rst
|
||||
F: Documentation/admin-guide/pm/intel_pstate.rst
|
||||
F: Documentation/cpu-freq/
|
||||
F: Documentation/devicetree/bindings/cpufreq/
|
||||
F: drivers/cpufreq/
|
||||
|
|
@ -3977,6 +3990,7 @@ F: drivers/cpufreq/arm_big_little.c
|
|||
CPU POWER MONITORING SUBSYSTEM
|
||||
M: Thomas Renninger <trenn@suse.com>
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
M: Shuah Khan <skhan@linuxfoundation.org>
|
||||
L: linux-pm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: tools/power/cpupower/
|
||||
|
|
@ -4006,13 +4020,14 @@ S: Supported
|
|||
F: drivers/cpuidle/cpuidle-exynos.c
|
||||
F: arch/arm/mach-exynos/pm.c
|
||||
|
||||
CPUIDLE DRIVERS
|
||||
CPU IDLE TIME MANAGEMENT FRAMEWORK
|
||||
M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
|
||||
M: Daniel Lezcano <daniel.lezcano@linaro.org>
|
||||
L: linux-pm@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
|
||||
B: https://bugzilla.kernel.org
|
||||
F: Documentation/admin-guide/pm/cpuidle.rst
|
||||
F: drivers/cpuidle/*
|
||||
F: include/linux/cpuidle.h
|
||||
|
||||
|
|
@ -5178,7 +5193,7 @@ DRM DRIVERS FOR XEN
|
|||
M: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
L: xen-devel@lists.xen.org
|
||||
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: drivers/gpu/drm/xen/
|
||||
F: Documentation/gpu/xen-front.rst
|
||||
|
|
@ -6143,7 +6158,7 @@ FREESCALE SOC SOUND DRIVERS
|
|||
M: Timur Tabi <timur@kernel.org>
|
||||
M: Nicolin Chen <nicoleotsuka@gmail.com>
|
||||
M: Xiubo Li <Xiubo.Lee@gmail.com>
|
||||
R: Fabio Estevam <fabio.estevam@nxp.com>
|
||||
R: Fabio Estevam <festevam@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
S: Maintained
|
||||
|
|
@ -7012,6 +7027,7 @@ F: drivers/net/hyperv/
|
|||
F: drivers/scsi/storvsc_drv.c
|
||||
F: drivers/uio/uio_hv_generic.c
|
||||
F: drivers/video/fbdev/hyperv_fb.c
|
||||
F: drivers/iommu/hyperv_iommu.c
|
||||
F: net/vmw_vsock/hyperv_transport.c
|
||||
F: include/linux/hyperv.h
|
||||
F: include/uapi/linux/hyperv.h
|
||||
|
|
@ -8256,6 +8272,7 @@ F: include/uapi/linux/sunrpc/
|
|||
|
||||
KERNEL SELFTEST FRAMEWORK
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
M: Shuah Khan <skhan@linuxfoundation.org>
|
||||
L: linux-kselftest@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git
|
||||
Q: https://patchwork.kernel.org/project/linux-kselftest/list/
|
||||
|
|
@ -8478,6 +8495,7 @@ L7 BPF FRAMEWORK
|
|||
M: John Fastabend <john.fastabend@gmail.com>
|
||||
M: Daniel Borkmann <daniel@iogearbox.net>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: include/linux/skmsg.h
|
||||
F: net/core/skmsg.c
|
||||
|
|
@ -10686,9 +10704,9 @@ S: Maintained
|
|||
F: drivers/net/netdevsim/*
|
||||
|
||||
NETXEN (1/10) GbE SUPPORT
|
||||
M: Manish Chopra <manish.chopra@cavium.com>
|
||||
M: Rahul Verma <rahul.verma@cavium.com>
|
||||
M: Dept-GELinuxNICDev@cavium.com
|
||||
M: Manish Chopra <manishc@marvell.com>
|
||||
M: Rahul Verma <rahulv@marvell.com>
|
||||
M: GR-Linux-NIC-Dev@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/qlogic/netxen/
|
||||
|
|
@ -10889,7 +10907,7 @@ F: include/linux/nvmem-consumer.h
|
|||
F: include/linux/nvmem-provider.h
|
||||
|
||||
NXP SGTL5000 DRIVER
|
||||
M: Fabio Estevam <fabio.estevam@nxp.com>
|
||||
M: Fabio Estevam <festevam@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/sgtl5000.txt
|
||||
|
|
@ -11303,10 +11321,12 @@ F: include/dt-bindings/
|
|||
|
||||
OPENCORES I2C BUS DRIVER
|
||||
M: Peter Korsgaard <peter@korsgaard.com>
|
||||
M: Andrew Lunn <andrew@lunn.ch>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/i2c/busses/i2c-ocores
|
||||
F: drivers/i2c/busses/i2c-ocores.c
|
||||
F: include/linux/platform_data/i2c-ocores.h
|
||||
|
||||
OPENRISC ARCHITECTURE
|
||||
M: Jonas Bonn <jonas@southpole.se>
|
||||
|
|
@ -11477,7 +11497,7 @@ F: Documentation/blockdev/paride.txt
|
|||
F: drivers/block/paride/
|
||||
|
||||
PARISC ARCHITECTURE
|
||||
M: "James E.J. Bottomley" <jejb@parisc-linux.org>
|
||||
M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
|
||||
M: Helge Deller <deller@gmx.de>
|
||||
L: linux-parisc@vger.kernel.org
|
||||
W: http://www.parisc-linux.org/
|
||||
|
|
@ -12472,8 +12492,8 @@ S: Supported
|
|||
F: drivers/scsi/qedi/
|
||||
|
||||
QLOGIC QL4xxx ETHERNET DRIVER
|
||||
M: Ariel Elior <Ariel.Elior@cavium.com>
|
||||
M: everest-linux-l2@cavium.com
|
||||
M: Ariel Elior <aelior@marvell.com>
|
||||
M: GR-everest-linux-l2@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/qlogic/qed/
|
||||
|
|
@ -12481,8 +12501,8 @@ F: include/linux/qed/
|
|||
F: drivers/net/ethernet/qlogic/qede/
|
||||
|
||||
QLOGIC QL4xxx RDMA DRIVER
|
||||
M: Michal Kalderon <Michal.Kalderon@cavium.com>
|
||||
M: Ariel Elior <Ariel.Elior@cavium.com>
|
||||
M: Michal Kalderon <mkalderon@marvell.com>
|
||||
M: Ariel Elior <aelior@marvell.com>
|
||||
L: linux-rdma@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/infiniband/hw/qedr/
|
||||
|
|
@ -12502,7 +12522,7 @@ F: Documentation/scsi/LICENSE.qla2xxx
|
|||
F: drivers/scsi/qla2xxx/
|
||||
|
||||
QLOGIC QLA3XXX NETWORK DRIVER
|
||||
M: Dept-GELinuxNICDev@cavium.com
|
||||
M: GR-Linux-NIC-Dev@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/networking/device_drivers/qlogic/LICENSE.qla3xxx
|
||||
|
|
@ -12516,16 +12536,16 @@ F: Documentation/scsi/LICENSE.qla4xxx
|
|||
F: drivers/scsi/qla4xxx/
|
||||
|
||||
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
|
||||
M: Shahed Shaikh <Shahed.Shaikh@cavium.com>
|
||||
M: Manish Chopra <manish.chopra@cavium.com>
|
||||
M: Dept-GELinuxNICDev@cavium.com
|
||||
M: Shahed Shaikh <shshaikh@marvell.com>
|
||||
M: Manish Chopra <manishc@marvell.com>
|
||||
M: GR-Linux-NIC-Dev@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/qlogic/qlcnic/
|
||||
|
||||
QLOGIC QLGE 10Gb ETHERNET DRIVER
|
||||
M: Manish Chopra <manish.chopra@cavium.com>
|
||||
M: Dept-GELinuxNICDev@cavium.com
|
||||
M: Manish Chopra <manishc@marvell.com>
|
||||
M: GR-Linux-NIC-Dev@marvell.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/qlogic/qlge/
|
||||
|
|
@ -12864,6 +12884,13 @@ F: Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
|
|||
F: drivers/net/dsa/realtek-smi*
|
||||
F: drivers/net/dsa/rtl83*
|
||||
|
||||
REDPINE WIRELESS DRIVER
|
||||
M: Amitkumar Karwar <amitkarwar@gmail.com>
|
||||
M: Siva Rebbagondla <siva8118@gmail.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/wireless/rsi/
|
||||
|
||||
REGISTER MAP ABSTRACTION
|
||||
M: Mark Brown <broonie@kernel.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
|
|
@ -13692,6 +13719,15 @@ L: netdev@vger.kernel.org
|
|||
S: Supported
|
||||
F: drivers/net/ethernet/sfc/
|
||||
|
||||
SFF/SFP/SFP+ MODULE SUPPORT
|
||||
M: Russell King <linux@armlinux.org.uk>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/phy/phylink.c
|
||||
F: drivers/net/phy/sfp*
|
||||
F: include/linux/phylink.h
|
||||
F: include/linux/sfp.h
|
||||
|
||||
SGI GRU DRIVER
|
||||
M: Dimitri Sivanich <sivanich@sgi.com>
|
||||
S: Maintained
|
||||
|
|
@ -13820,8 +13856,9 @@ F: drivers/media/mmc/siano/
|
|||
|
||||
SIFIVE DRIVERS
|
||||
M: Palmer Dabbelt <palmer@sifive.com>
|
||||
M: Paul Walmsley <paul.walmsley@sifive.com>
|
||||
L: linux-riscv@lists.infradead.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
|
||||
T: git git://github.com/sifive/riscv-linux.git
|
||||
S: Supported
|
||||
K: sifive
|
||||
N: sifive
|
||||
|
|
@ -14432,6 +14469,11 @@ M: Florian Schilhabel <florian.c.schilhabel@googlemail.com>.
|
|||
S: Odd Fixes
|
||||
F: drivers/staging/rtl8712/
|
||||
|
||||
STAGING - REALTEK RTL8188EU DRIVERS
|
||||
M: Larry Finger <Larry.Finger@lwfinger.net>
|
||||
S: Odd Fixes
|
||||
F: drivers/staging/rtl8188eu/
|
||||
|
||||
STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
|
||||
M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
|
||||
M: Teddy Wang <teddy.wang@siliconmotion.com>
|
||||
|
|
@ -15802,7 +15844,6 @@ M: Alan Stern <stern@rowland.harvard.edu>
|
|||
L: linux-usb@vger.kernel.org
|
||||
L: usb-storage@lists.one-eyed-alien.net
|
||||
S: Maintained
|
||||
W: http://www.one-eyed-alien.net/~mdharm/linux-usb/
|
||||
F: drivers/usb/storage/
|
||||
|
||||
USB MIDI DRIVER
|
||||
|
|
@ -15834,6 +15875,7 @@ F: drivers/usb/common/usb-otg-fsm.c
|
|||
USB OVER IP DRIVER
|
||||
M: Valentina Manea <valentina.manea.m@gmail.com>
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
M: Shuah Khan <skhan@linuxfoundation.org>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/usb/usbip_protocol.txt
|
||||
|
|
@ -16631,6 +16673,15 @@ S: Maintained
|
|||
F: drivers/platform/x86/
|
||||
F: drivers/platform/olpc/
|
||||
|
||||
X86 PLATFORM DRIVERS - ARCH
|
||||
R: Darren Hart <dvhart@infradead.org>
|
||||
R: Andy Shevchenko <andy@infradead.org>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
L: x86@kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core
|
||||
S: Maintained
|
||||
F: arch/x86/platform
|
||||
|
||||
X86 VDSO
|
||||
M: Andy Lutomirski <luto@kernel.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
|
|
@ -16663,10 +16714,30 @@ T: git git://linuxtv.org/media_tree.git
|
|||
S: Maintained
|
||||
F: drivers/media/tuners/tuner-xc2028.*
|
||||
|
||||
XDP (eXpress Data Path)
|
||||
M: Alexei Starovoitov <ast@kernel.org>
|
||||
M: Daniel Borkmann <daniel@iogearbox.net>
|
||||
M: David S. Miller <davem@davemloft.net>
|
||||
M: Jakub Kicinski <jakub.kicinski@netronome.com>
|
||||
M: Jesper Dangaard Brouer <hawk@kernel.org>
|
||||
M: John Fastabend <john.fastabend@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: xdp-newbies@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Supported
|
||||
F: net/core/xdp.c
|
||||
F: include/net/xdp.h
|
||||
F: kernel/bpf/devmap.c
|
||||
F: kernel/bpf/cpumap.c
|
||||
F: include/trace/events/xdp.h
|
||||
K: xdp
|
||||
N: xdp
|
||||
|
||||
XDP SOCKETS (AF_XDP)
|
||||
M: Björn Töpel <bjorn.topel@intel.com>
|
||||
M: Magnus Karlsson <magnus.karlsson@intel.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: bpf@vger.kernel.org
|
||||
S: Maintained
|
||||
F: kernel/bpf/xskmap.c
|
||||
F: net/xdp/
|
||||
|
|
|
|||
10
Makefile
10
Makefile
|
|
@ -2,7 +2,7 @@
|
|||
VERSION = 5
|
||||
PATCHLEVEL = 0
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc8
|
||||
NAME = Shy Crocodile
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -955,6 +955,7 @@ ifdef CONFIG_STACK_VALIDATION
|
|||
endif
|
||||
endif
|
||||
|
||||
PHONY += prepare0
|
||||
|
||||
ifeq ($(KBUILD_EXTMOD),)
|
||||
core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/
|
||||
|
|
@ -1061,8 +1062,7 @@ scripts: scripts_basic scripts_dtc
|
|||
# archprepare is used in arch Makefiles and when processed asm symlink,
|
||||
# version.h and scripts_basic is processed / created.
|
||||
|
||||
# Listed in dependency order
|
||||
PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3
|
||||
PHONY += prepare archprepare prepare1 prepare2 prepare3
|
||||
|
||||
# prepare3 is used to check if we are building in a separate output directory,
|
||||
# and if so do:
|
||||
|
|
@ -1360,11 +1360,11 @@ mrproper: rm-dirs := $(wildcard $(MRPROPER_DIRS))
|
|||
mrproper: rm-files := $(wildcard $(MRPROPER_FILES))
|
||||
mrproper-dirs := $(addprefix _mrproper_,scripts)
|
||||
|
||||
PHONY += $(mrproper-dirs) mrproper archmrproper
|
||||
PHONY += $(mrproper-dirs) mrproper
|
||||
$(mrproper-dirs):
|
||||
$(Q)$(MAKE) $(clean)=$(patsubst _mrproper_%,%,$@)
|
||||
|
||||
mrproper: clean archmrproper $(mrproper-dirs)
|
||||
mrproper: clean $(mrproper-dirs)
|
||||
$(call cmd,rmdirs)
|
||||
$(call cmd,rmfiles)
|
||||
|
||||
|
|
|
|||
|
|
@ -56,15 +56,15 @@
|
|||
|
||||
#elif defined(CONFIG_ALPHA_DP264) || \
|
||||
defined(CONFIG_ALPHA_LYNX) || \
|
||||
defined(CONFIG_ALPHA_SHARK) || \
|
||||
defined(CONFIG_ALPHA_EIGER)
|
||||
defined(CONFIG_ALPHA_SHARK)
|
||||
# define NR_IRQS 64
|
||||
|
||||
#elif defined(CONFIG_ALPHA_TITAN)
|
||||
#define NR_IRQS 80
|
||||
|
||||
#elif defined(CONFIG_ALPHA_RAWHIDE) || \
|
||||
defined(CONFIG_ALPHA_TAKARA)
|
||||
defined(CONFIG_ALPHA_TAKARA) || \
|
||||
defined(CONFIG_ALPHA_EIGER)
|
||||
# define NR_IRQS 128
|
||||
|
||||
#elif defined(CONFIG_ALPHA_WILDFIRE)
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ __load_new_mm_context(struct mm_struct *next_mm)
|
|||
/* Macro for exception fixup code to access integer registers. */
|
||||
#define dpf_reg(r) \
|
||||
(((unsigned long *)regs)[(r) <= 8 ? (r) : (r) <= 15 ? (r)-16 : \
|
||||
(r) <= 18 ? (r)+8 : (r)-10])
|
||||
(r) <= 18 ? (r)+10 : (r)-10])
|
||||
|
||||
asmlinkage void
|
||||
do_page_fault(unsigned long address, unsigned long mmcsr,
|
||||
|
|
|
|||
|
|
@ -191,7 +191,6 @@ config NR_CPUS
|
|||
|
||||
config ARC_SMP_HALT_ON_RESET
|
||||
bool "Enable Halt-on-reset boot mode"
|
||||
default y if ARC_UBOOT_SUPPORT
|
||||
help
|
||||
In SMP configuration cores can be configured as Halt-on-reset
|
||||
or they could all start at same time. For Halt-on-reset, non
|
||||
|
|
@ -407,6 +406,14 @@ config ARC_HAS_ACCL_REGS
|
|||
(also referred to as r58:r59). These can also be used by gcc as GPR so
|
||||
kernel needs to save/restore per process
|
||||
|
||||
config ARC_IRQ_NO_AUTOSAVE
|
||||
bool "Disable hardware autosave regfile on interrupts"
|
||||
default n
|
||||
help
|
||||
On HS cores, taken interrupt auto saves the regfile on stack.
|
||||
This is programmable and can be optionally disabled in which case
|
||||
software INTERRUPT_PROLOGUE/EPILGUE do the needed work
|
||||
|
||||
endif # ISA_ARCV2
|
||||
|
||||
endmenu # "ARC CPU Configuration"
|
||||
|
|
@ -515,17 +522,6 @@ config ARC_DBG_TLB_PARANOIA
|
|||
|
||||
endif
|
||||
|
||||
config ARC_UBOOT_SUPPORT
|
||||
bool "Support uboot arg Handling"
|
||||
help
|
||||
ARC Linux by default checks for uboot provided args as pointers to
|
||||
external cmdline or DTB. This however breaks in absence of uboot,
|
||||
when booting from Metaware debugger directly, as the registers are
|
||||
not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus
|
||||
registers look like uboot args to kernel which then chokes.
|
||||
So only enable the uboot arg checking/processing if users are sure
|
||||
of uboot being in play.
|
||||
|
||||
config ARC_BUILTIN_DTB_NAME
|
||||
string "Built in DTB"
|
||||
help
|
||||
|
|
|
|||
|
|
@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5
|
|||
# CONFIG_ARC_HAS_LLSC is not set
|
||||
CONFIG_ARC_KVADDR_SIZE=402
|
||||
CONFIG_ARC_EMUL_UNALIGNED=y
|
||||
CONFIG_ARC_UBOOT_SUPPORT=y
|
||||
CONFIG_PREEMPT=y
|
||||
CONFIG_NET=y
|
||||
CONFIG_UNIX=y
|
||||
|
|
|
|||
|
|
@ -13,7 +13,6 @@ CONFIG_PARTITION_ADVANCED=y
|
|||
CONFIG_ARC_PLAT_AXS10X=y
|
||||
CONFIG_AXS103=y
|
||||
CONFIG_ISA_ARCV2=y
|
||||
CONFIG_ARC_UBOOT_SUPPORT=y
|
||||
CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38"
|
||||
CONFIG_PREEMPT=y
|
||||
CONFIG_NET=y
|
||||
|
|
|
|||
|
|
@ -15,8 +15,6 @@ CONFIG_AXS103=y
|
|||
CONFIG_ISA_ARCV2=y
|
||||
CONFIG_SMP=y
|
||||
# CONFIG_ARC_TIMERS_64BIT is not set
|
||||
# CONFIG_ARC_SMP_HALT_ON_RESET is not set
|
||||
CONFIG_ARC_UBOOT_SUPPORT=y
|
||||
CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38_smp"
|
||||
CONFIG_PREEMPT=y
|
||||
CONFIG_NET=y
|
||||
|
|
|
|||
|
|
@ -3,23 +3,19 @@ generic-y += bugs.h
|
|||
generic-y += compat.h
|
||||
generic-y += device.h
|
||||
generic-y += div64.h
|
||||
generic-y += dma-mapping.h
|
||||
generic-y += emergency-restart.h
|
||||
generic-y += extable.h
|
||||
generic-y += fb.h
|
||||
generic-y += ftrace.h
|
||||
generic-y += hardirq.h
|
||||
generic-y += hw_irq.h
|
||||
generic-y += irq_regs.h
|
||||
generic-y += irq_work.h
|
||||
generic-y += kmap_types.h
|
||||
generic-y += local.h
|
||||
generic-y += local64.h
|
||||
generic-y += mcs_spinlock.h
|
||||
generic-y += mm-arch-hooks.h
|
||||
generic-y += msi.h
|
||||
generic-y += parport.h
|
||||
generic-y += pci.h
|
||||
generic-y += percpu.h
|
||||
generic-y += preempt.h
|
||||
generic-y += topology.h
|
||||
|
|
|
|||
|
|
@ -151,6 +151,14 @@ struct bcr_isa_arcv2 {
|
|||
#endif
|
||||
};
|
||||
|
||||
struct bcr_uarch_build_arcv2 {
|
||||
#ifdef CONFIG_CPU_BIG_ENDIAN
|
||||
unsigned int pad:8, prod:8, maj:8, min:8;
|
||||
#else
|
||||
unsigned int min:8, maj:8, prod:8, pad:8;
|
||||
#endif
|
||||
};
|
||||
|
||||
struct bcr_mpy {
|
||||
#ifdef CONFIG_CPU_BIG_ENDIAN
|
||||
unsigned int pad:8, x1616:8, dsp:4, cycles:2, type:2, ver:8;
|
||||
|
|
@ -216,6 +224,14 @@ struct bcr_fp_arcv2 {
|
|||
#endif
|
||||
};
|
||||
|
||||
struct bcr_actionpoint {
|
||||
#ifdef CONFIG_CPU_BIG_ENDIAN
|
||||
unsigned int pad:21, min:1, num:2, ver:8;
|
||||
#else
|
||||
unsigned int ver:8, num:2, min:1, pad:21;
|
||||
#endif
|
||||
};
|
||||
|
||||
#include <soc/arc/timers.h>
|
||||
|
||||
struct bcr_bpu_arcompact {
|
||||
|
|
@ -283,7 +299,7 @@ struct cpuinfo_arc_cache {
|
|||
};
|
||||
|
||||
struct cpuinfo_arc_bpu {
|
||||
unsigned int ver, full, num_cache, num_pred;
|
||||
unsigned int ver, full, num_cache, num_pred, ret_stk;
|
||||
};
|
||||
|
||||
struct cpuinfo_arc_ccm {
|
||||
|
|
@ -302,7 +318,7 @@ struct cpuinfo_arc {
|
|||
struct {
|
||||
unsigned int swap:1, norm:1, minmax:1, barrel:1, crc:1, swape:1, pad1:2,
|
||||
fpu_sp:1, fpu_dp:1, dual:1, dual_enb:1, pad2:4,
|
||||
debug:1, ap:1, smart:1, rtt:1, pad3:4,
|
||||
ap_num:4, ap_full:1, smart:1, rtt:1, pad3:1,
|
||||
timer0:1, timer1:1, rtc:1, gfrc:1, pad4:4;
|
||||
} extn;
|
||||
struct bcr_mpy extn_mpy;
|
||||
|
|
|
|||
|
|
@ -340,7 +340,7 @@ static inline __attribute__ ((const)) int __fls(unsigned long x)
|
|||
/*
|
||||
* __ffs: Similar to ffs, but zero based (0-31)
|
||||
*/
|
||||
static inline __attribute__ ((const)) int __ffs(unsigned long word)
|
||||
static inline __attribute__ ((const)) unsigned long __ffs(unsigned long word)
|
||||
{
|
||||
if (!word)
|
||||
return word;
|
||||
|
|
@ -400,9 +400,9 @@ static inline __attribute__ ((const)) int ffs(unsigned long x)
|
|||
/*
|
||||
* __ffs: Similar to ffs, but zero based (0-31)
|
||||
*/
|
||||
static inline __attribute__ ((const)) int __ffs(unsigned long x)
|
||||
static inline __attribute__ ((const)) unsigned long __ffs(unsigned long x)
|
||||
{
|
||||
int n;
|
||||
unsigned long n;
|
||||
|
||||
asm volatile(
|
||||
" ffs.f %0, %1 \n" /* 0:31; 31(Z) if src 0 */
|
||||
|
|
|
|||
|
|
@ -52,6 +52,17 @@
|
|||
#define cache_line_size() SMP_CACHE_BYTES
|
||||
#define ARCH_DMA_MINALIGN SMP_CACHE_BYTES
|
||||
|
||||
/*
|
||||
* Make sure slab-allocated buffers are 64-bit aligned when atomic64_t uses
|
||||
* ARCv2 64-bit atomics (LLOCKD/SCONDD). This guarantess runtime 64-bit
|
||||
* alignment for any atomic64_t embedded in buffer.
|
||||
* Default ARCH_SLAB_MINALIGN is __alignof__(long long) which has a relaxed
|
||||
* value of 4 (and not 8) in ARC ABI.
|
||||
*/
|
||||
#if defined(CONFIG_ARC_HAS_LL64) && defined(CONFIG_ARC_HAS_LLSC)
|
||||
#define ARCH_SLAB_MINALIGN 8
|
||||
#endif
|
||||
|
||||
extern void arc_cache_init(void);
|
||||
extern char *arc_cache_mumbojumbo(int cpu_id, char *buf, int len);
|
||||
extern void read_decode_cache_bcr(void);
|
||||
|
|
|
|||
|
|
@ -17,6 +17,33 @@
|
|||
;
|
||||
; Now manually save: r12, sp, fp, gp, r25
|
||||
|
||||
#ifdef CONFIG_ARC_IRQ_NO_AUTOSAVE
|
||||
.ifnc \called_from, exception
|
||||
st.as r9, [sp, -10] ; save r9 in it's final stack slot
|
||||
sub sp, sp, 12 ; skip JLI, LDI, EI
|
||||
|
||||
PUSH lp_count
|
||||
PUSHAX lp_start
|
||||
PUSHAX lp_end
|
||||
PUSH blink
|
||||
|
||||
PUSH r11
|
||||
PUSH r10
|
||||
|
||||
sub sp, sp, 4 ; skip r9
|
||||
|
||||
PUSH r8
|
||||
PUSH r7
|
||||
PUSH r6
|
||||
PUSH r5
|
||||
PUSH r4
|
||||
PUSH r3
|
||||
PUSH r2
|
||||
PUSH r1
|
||||
PUSH r0
|
||||
.endif
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_ARC_HAS_ACCL_REGS
|
||||
PUSH r59
|
||||
PUSH r58
|
||||
|
|
@ -86,6 +113,33 @@
|
|||
POP r59
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_ARC_IRQ_NO_AUTOSAVE
|
||||
.ifnc \called_from, exception
|
||||
POP r0
|
||||
POP r1
|
||||
POP r2
|
||||
POP r3
|
||||
POP r4
|
||||
POP r5
|
||||
POP r6
|
||||
POP r7
|
||||
POP r8
|
||||
POP r9
|
||||
POP r10
|
||||
POP r11
|
||||
|
||||
POP blink
|
||||
POPAX lp_end
|
||||
POPAX lp_start
|
||||
|
||||
POP r9
|
||||
mov lp_count, r9
|
||||
|
||||
add sp, sp, 12 ; skip JLI, LDI, EI
|
||||
ld.as r9, [sp, -10] ; reload r9 which got clobbered
|
||||
.endif
|
||||
#endif
|
||||
|
||||
.endm
|
||||
|
||||
/*------------------------------------------------------------------------*/
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue