xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge Linus's 5.4-rc1-prerelease branch into android-mainline

Browse Source 
This merges Linus's tree as of commit b41dae061b ("Merge tag
'xfs-5.4-merge-7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux")
into android-mainline.

This "early" merge makes it easier to test and handle merge conflicts
instead of having to wait until the "end" of the merge window and handle
all 10000+ commits at once.

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6bebf55e5e2353f814e3c87f5033607b1ae5d812
This commit is contained in:
Greg Kroah-Hartman
2019-09-19 20:54:14 +02:00
committed by Alistair Delva
parent cae5e9966d b41dae061b
commit bfa0399bc8
7251 changed files with 330470 additions and 218144 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
.mailmap
View File

@@ -47,6 +47,8 @@ Boris Brezillon <bbrezillon@kernel.org> <b.brezillon.dev@gmail.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
Christoph Hellwig <hch@lst.de>
Christophe Ricard <christophe.ricard@gmail.com>
Corey Minyard <minyard@acm.org>
@@ -63,6 +65,7 @@ Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
Dengcheng Zhu <dzhu@wavecomp.com> <dczhu@mips.com>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@gmail.com>
<dev.kurt@vandijck-laurijssen.be> <kurt.van.dijck@eia.be>
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
@@ -80,6 +83,8 @@ Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
Frank Zago <fzago@systemfabricworks.com>
Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
Greg Kroah-Hartman <greg@echidna.(none)>
Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman <greg@kroah.com>
@@ -90,6 +95,9 @@ Henrik Kretzschmar <henne@nachtwindheim.de>
Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
Jacob Shin <Jacob.Shin@amd.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
James Bottomley <jejb@mulgrave.(none)>
James Bottomley <jejb@titanic.il.steeleye.com>
James E Wilson <wilson@specifix.com>
@@ -178,8 +186,14 @@ Morten Welinder <welinder@darter.rentec.com>
Morten Welinder <welinder@troll.com>
Mythri P K <mythripk@ti.com>
Nguyen Anh Quynh <aquynh@gmail.com>
Nicolas Ferre <nicolas.ferre@microchip.com> <nicolas.ferre@atmel.com>
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
Paul Burton <paul.burton@mips.com> <paul.burton@imgtec.com>
@@ -190,11 +204,7 @@ Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
Praveen BP <praveenbp@ti.com>
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com>
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
Rajesh Shah <rajesh.shah@intel.com>
Ralf Baechle <ralf@linux-mips.org>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
@@ -229,6 +239,7 @@ Sumit Semwal <sumit.semwal@ti.com>
Tejun Heo <htejun@gmail.com>
Thomas Graf <tgraf@suug.ch>
Thomas Pedersen <twp@codeaurora.org>
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>
Tony Luck <tony.luck@intel.com>
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>

2
CREDITS
View File

@@ -751,7 +751,7 @@ S: Santa Cruz, California
S: USA
N: Luis Correia
E: lfcorreia@users.sf.net
E: luisfcorreia@gmail.com
D: Ralink rt2x00 WLAN driver
S: Belas, Portugal

2
Documentation/ABI/stable/sysfs-bus-w1
View File

@@ -6,6 +6,6 @@ Description: Bus scanning interval, microseconds component.
control systems are attached/generate presence for as short as
100 ms - hence the tens-to-hundreds milliseconds scan intervals
are required.
see Documentation/w1/w1.generic for detailed information.
see Documentation/w1/w1-generic.rst for detailed information.
Users: any user space application which wants to know bus scanning
interval

4
Documentation/ABI/stable/sysfs-driver-w1_ds28e04
View File

@@ -2,7 +2,7 @@ What: /sys/bus/w1/devices/.../pio
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the two PIO's of the DS28E04-100
see Documentation/w1/slaves/w1_ds28e04 for detailed information
see Documentation/w1/slaves/w1_ds28e04.rst for detailed information
Users: any user space application which wants to communicate with DS28E04-100
@@ -11,5 +11,5 @@ What: /sys/bus/w1/devices/.../eeprom
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the EEPROM memory of the DS28E04-100
see Documentation/w1/slaves/w1_ds28e04 for detailed information
see Documentation/w1/slaves/w1_ds28e04.rst for detailed information
Users: any user space application which wants to communicate with DS28E04-100

2
Documentation/ABI/stable/sysfs-driver-w1_ds28ea00
View File

@@ -2,5 +2,5 @@ What: /sys/bus/w1/devices/.../w1_seq
Date: Apr 2015
Contact: Matt Campbell <mattrcampbell@gmail.com>
Description: Support for the DS28EA00 chain sequence function
see Documentation/w1/slaves/w1_therm for detailed information
see Documentation/w1/slaves/w1_therm.rst for detailed information
Users: any user space application which wants to communicate with DS28EA00

50
Documentation/ABI/testing/debugfs-hisi-zip Normal file
View File

@@ -0,0 +1,50 @@
What: /sys/kernel/debug/hisi_zip/<bdf>/comp_core[01]/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of compression cores related debug registers.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/decomp_core[0-5]/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of decompression cores related debug registers.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/clear_enable
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Compression/decompression core debug registers read clear
control. 1 means enable register read clear, otherwise 0.
Writing to this file has no functional effect, only enable or
disable counters clear after reading of these registers.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/current_qm
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: One ZIP controller has one PF and multiple VFs, each function
has a QM. Select the QM which below qm refers to.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/qm_regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of QM related debug registers.
Available for PF and VF in host. VF in guest currently only
has one debug register.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/current_q
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: One QM may contain multiple queues. Select specific queue to
show its debug registers in above qm_regs.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/clear_enable
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(qm_regs) read clear control. 1 means enable
register read clear, otherwise 0.
Writing to this file has no functional effect, only enable or
disable counters clear after reading of these registers.
Only available for PF.

23
Documentation/ABI/testing/debugfs-moxtet Normal file
View File

@@ -0,0 +1,23 @@
What: /sys/kernel/debug/moxtet/input
Date: March 2019
KernelVersion: 5.3
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) Read input from the shift registers, in hexadecimal.
Returns N+1 bytes, where N is the number of Moxtet connected
modules. The first byte is from the CPU board itself.
Example: 101214
10: CPU board with SD card
12: 2 = PCIe module, 1 = IRQ not active
14: 4 = Peridot module, 1 = IRQ not active
What: /sys/kernel/debug/moxtet/output
Date: March 2019
KernelVersion: 5.3
Contact: Marek Behún <marek.behun@nic.cz>
Description: (RW) Read last written value to the shift registers, in
hexadecimal, or write values to the shift registers, also
in hexadecimal.
Example: 0102
01: 01 was last written, or is to be written, to the
first module's shift register
02: the same for second module

23
Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
View File

@@ -91,29 +91,6 @@ Description:
When counting down the counter start from preset value
and fire event when reach 0.
What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
Description:
Reading returns the list possible quadrature modes.
What: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
Description:
Configure the device counter quadrature modes:
channel_A:
Encoder A input servers as the count input and B as
the UP/DOWN direction control input.
channel_B:
Encoder B input serves as the count input and A as
the UP/DOWN direction control input.
quadrature:
Encoder A and B inputs are mixed to get direction
and count with a scale of 0.25.
What: /sys/bus/iio/devices/iio:deviceX/in_count_enable_mode_available
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com

3
Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc
View File

@@ -12,7 +12,8 @@ Description: (RW) Configure MSC operating mode:
- "single", for contiguous buffer mode (high-order alloc);
- "multi", for multiblock mode;
- "ExI", for DCI handler mode;
- "debug", for debug mode.
- "debug", for debug mode;
- any of the currently loaded buffer sinks.
If operating mode changes, existing buffer is deallocated,
provided there are no active users and tracing is not enabled,
otherwise the write will fail.

17
Documentation/ABI/testing/sysfs-bus-moxtet-devices Normal file
View File

@@ -0,0 +1,17 @@
What: /sys/bus/moxtet/devices/moxtet-<name>.<addr>/module_description
Date: March 2019
KernelVersion: 5.3
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) Moxtet module description. Format: string
What: /sys/bus/moxtet/devices/moxtet-<name>.<addr>/module_id
Date: March 2019
KernelVersion: 5.3
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) Moxtet module ID. Format: %x
What: /sys/bus/moxtet/devices/moxtet-<name>.<addr>/module_name
Date: March 2019
KernelVersion: 5.3
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) Moxtet module name. Format: string

0
Documentation/ABI/testing/sysfs-class-mic.txt → Documentation/ABI/testing/sysfs-class-mic
View File

76
Documentation/ABI/testing/sysfs-class-wakeup Normal file
View File

@@ -0,0 +1,76 @@
What: /sys/class/wakeup/
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
The /sys/class/wakeup/ directory contains pointers to all
wakeup sources in the kernel at that moment in time.
What: /sys/class/wakeup/.../name
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the name of the wakeup source.
What: /sys/class/wakeup/.../active_count
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the number of times the wakeup source was
activated.
What: /sys/class/wakeup/.../event_count
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the number of signaled wakeup events
associated with the wakeup source.
What: /sys/class/wakeup/.../wakeup_count
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the number of times the wakeup source might
abort suspend.
What: /sys/class/wakeup/.../expire_count
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the number of times the wakeup source's
timeout has expired.
What: /sys/class/wakeup/.../active_time_ms
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the amount of time the wakeup source has
been continuously active, in milliseconds. If the wakeup
source is not active, this file contains '0'.
What: /sys/class/wakeup/.../total_time_ms
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the total amount of time this wakeup source
has been active, in milliseconds.
What: /sys/class/wakeup/.../max_time_ms
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the maximum amount of time this wakeup
source has been continuously active, in milliseconds.
What: /sys/class/wakeup/.../last_change_ms
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
This file contains the monotonic clock time when the wakeup
source was touched last time, in milliseconds.
What: /sys/class/wakeup/.../prevent_suspend_time_ms
Date: June 2019
Contact: Tri Vo <trong@android.com>
Description:
The file contains the total amount of time this wakeup source
has been preventing autosleep, in milliseconds.

128
Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu Normal file
View File

@@ -0,0 +1,128 @@
Intel Stratix10 Remote System Update (RSU) device attributes
What: /sys/devices/platform/stratix10-rsu.0/current_image
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(RO) the address in flash of currently running image.
What: /sys/devices/platform/stratix10-rsu.0/fail_image
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(RO) the address in flash of failed image.
What: /sys/devices/platform/stratix10-rsu.0/state
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(RO) the state of RSU system.
The state field has two parts: major error code in
upper 16 bits and minor error code in lower 16 bits.
b[15:0]
Currently used only when major error is 0xF006
(CPU watchdog timeout), in which case the minor
error code is the value reported by CPU to
firmware through the RSU notify command before
the watchdog timeout occurs.
b[31:16]
0xF001 bitstream error
0xF002 hardware access failure
0xF003 bitstream corruption
0xF004 internal error
0xF005 device error
0xF006 CPU watchdog timeout
0xF007 internal unknown error
What: /sys/devices/platform/stratix10-rsu.0/version
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(RO) the version number of RSU firmware. 19.3 or late
version includes information about the firmware which
reported the error.
pre 19.3:
b[31:0]
0x0 version number
19.3 or late:
b[15:0]
0x1 version number
b[31:16]
0x0 no error
0x0DCF Decision CMF error
0x0ACF Application CMF error
What: /sys/devices/platform/stratix10-rsu.0/error_location
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(RO) the error offset inside the image that failed.
What: /sys/devices/platform/stratix10-rsu.0/error_details
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(RO) error code.
What: /sys/devices/platform/stratix10-rsu.0/retry_counter
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(RO) the current image's retry counter, which is used by
user to know how many times the images is still allowed
to reload itself before giving up and starting RSU
fail-over flow.
What: /sys/devices/platform/stratix10-rsu.0/reboot_image
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(WO) the address in flash of image to be loaded on next
reboot command.
What: /sys/devices/platform/stratix10-rsu.0/notify
Date: August 2019
KernelVersion: 5.4
Contact: Richard Gong <richard.gong@linux.intel.com>
Description:
(WO) client to notify firmware with different actions.
b[15:0]
inform firmware the current software execution
stage.
0 the first stage bootloader didn't run or
didn't reach the point of launching second
stage bootloader.
1 failed in second bootloader or didn't get
to the point of launching the operating
system.
2 both first and second stage bootloader ran
and the operating system launch was
attempted.
b[16]
1 firmware to reset current image retry
counter.
0 no action.
b[17]
1 firmware to clear RSU log
0 no action.
b[18]
this is negative logic
1 no action
0 firmware record the notify code defined
in b[15:0].

9
Documentation/ABI/testing/sysfs-devices-power
View File

@@ -260,3 +260,12 @@ Description:
This attribute has no effect on system-wide suspend/resume and
hibernation.
What: /sys/devices/.../power/runtime_status
Date: April 2010
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power/runtime_status attribute contains
the current runtime PM status of the device, which may be
"suspended", "suspending", "resuming", "active", "error" (fatal
error), or "unsupported" (runtime PM is disabled).

7
Documentation/ABI/testing/sysfs-devices-soc
View File

@@ -26,6 +26,13 @@ Description:
Read-only attribute common to all SoCs. Contains SoC family name
(e.g. DB8500).
What: /sys/devices/socX/serial_number
Date: January 2019
contact: Bjorn Andersson <bjorn.andersson@linaro.org>
Description:
Read-only attribute supported by most SoCs. Contains the SoC's
serial number, if available.
What: /sys/devices/socX/soc_id
Date: January 2012
contact: Lee Jones <lee.jones@linaro.org>

12
Documentation/ABI/testing/sysfs-driver-habanalabs
View File

@@ -57,6 +57,7 @@ KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Allows the user to set the maximum clock frequency for MME, TPC
and IC when the power management profile is set to "automatic".
This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/ic_clk
Date: Jan 2019
@@ -127,8 +128,8 @@ Description: Power management profile. Values are "auto", "manual". In "auto"
the max clock frequency to a low value when there are no user
processes that are opened on the device's file. In "manual"
mode, the user sets the maximum clock frequency by writing to
ic_clk, mme_clk and tpc_clk
ic_clk, mme_clk and tpc_clk. This property is valid only for
the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/preboot_btl_ver
Date: Jan 2019
@@ -187,10 +188,3 @@ Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Version of the u-boot running on the device's CPU
What: /sys/class/habanalabs/hl<n>/write_open_cnt
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Displays the total number of user processes that are currently
opened on the device's file

8
Documentation/ABI/testing/sysfs-firmware-efi
View File

@@ -28,3 +28,11 @@ Description: Displays the physical addresses of all EFI Configuration
versions are always printed first, i.e. ACPI20 comes
before ACPI.
Users: dmidecode
What: /sys/firmware/efi/tables/rci2
Date: July 2019
Contact: Narendra K <Narendra.K@dell.com>, linux-bugs@dell.com
Description: Displays the content of the Runtime Configuration Interface
Table version 2 on Dell EMC PowerEdge systems in binary format
Users: It is used by Dell EMC OpenManage Server Administrator tool to
populate BIOS setup page.

37
Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm Normal file
View File

@@ -0,0 +1,37 @@
What: /sys/firmware/turris-mox-rwtm/board_version
Date: August 2019
KernelVersion: 5.4
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) Board version burned into eFuses of this Turris Mox board.
Format: %i
What: /sys/firmware/turris-mox-rwtm/mac_address*
Date: August 2019
KernelVersion: 5.4
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) MAC addresses burned into eFuses of this Turris Mox board.
Format: %pM
What: /sys/firmware/turris-mox-rwtm/pubkey
Date: August 2019
KernelVersion: 5.4
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) ECDSA public key (in pubkey hex compressed form) computed
as pair to the ECDSA private key burned into eFuses of this
Turris Mox Board.
Format: string
What: /sys/firmware/turris-mox-rwtm/ram_size
Date: August 2019
KernelVersion: 5.4
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) RAM size in MiB of this Turris Mox board as was detected
during manufacturing and burned into eFuses. Can be 512 or 1024.
Format: %i
What: /sys/firmware/turris-mox-rwtm/serial_number
Date: August 2019
KernelVersion: 5.4
Contact: Marek Behún <marek.behun@nic.cz>
Description: (R) Serial number burned into eFuses of this Turris Mox device.
Format: %016X

17
Documentation/ABI/testing/sysfs-kernel-btf Normal file
View File

@@ -0,0 +1,17 @@
What: /sys/kernel/btf
Date: Aug 2019
KernelVersion: 5.5
Contact: bpf@vger.kernel.org
Description:
Contains BTF type information and related data for kernel and
kernel modules.
What: /sys/kernel/btf/vmlinux
Date: Aug 2019
KernelVersion: 5.5
Contact: bpf@vger.kernel.org
Description:
Read-only binary attribute exposing kernel's own BTF type
information with description of all internal kernel types. See
Documentation/bpf/btf.rst for detailed description of format
itself.

85
Documentation/ABI/testing/sysfs-platform-dfl-fme
View File

@@ -21,3 +21,88 @@ Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns Bitstream (static FPGA region) meta
data, which includes the synthesis date, seed and other
information of this static FPGA region.
What: /sys/bus/platform/devices/dfl-fme.0/cache_size
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns cache size of this FPGA device.
What: /sys/bus/platform/devices/dfl-fme.0/fabric_version
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns fabric version of this FPGA device.
Userspace applications need this information to select
best data channels per different fabric design.
What: /sys/bus/platform/devices/dfl-fme.0/socket_id
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns socket_id to indicate which socket
this FPGA belongs to, only valid for integrated solution.
User only needs this information, in case standard numa node
can't provide correct information.
What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie0_errors
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file for errors detected on pcie0 link.
Write this file to clear errors logged in pcie0_errors. Write
fails with -EINVAL if input parsing fails or input error code
doesn't match.
What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie1_errors
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file for errors detected on pcie1 link.
Write this file to clear errors logged in pcie1_errors. Write
fails with -EINVAL if input parsing fails or input error code
doesn't match.
What: /sys/bus/platform/devices/dfl-fme.0/errors/nonfatal_errors
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns non-fatal errors detected.
What: /sys/bus/platform/devices/dfl-fme.0/errors/catfatal_errors
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns catastrophic and fatal errors detected.
What: /sys/bus/platform/devices/dfl-fme.0/errors/inject_errors
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file to check errors injected. Write this
file to inject errors for testing purpose. Write fails with
-EINVAL if input parsing fails or input inject error code isn't
supported.
What: /sys/bus/platform/devices/dfl-fme.0/errors/fme_errors
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file to get errors detected on FME.
Write this file to clear errors logged in fme_errors. Write
fials with -EINVAL if input parsing fails or input error code
doesn't match.
What: /sys/bus/platform/devices/dfl-fme.0/errors/first_error
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get the first error detected by
hardware.
What: /sys/bus/platform/devices/dfl-fme.0/errors/next_error
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get the second error detected by
hardware.

85
Documentation/ABI/testing/sysfs-platform-dfl-port
View File

@@ -14,3 +14,88 @@ Description: Read-only. User can program different PR bitstreams to FPGA
Accelerator Function Unit (AFU) for different functions. It
returns uuid which could be used to identify which PR bitstream
is programmed in this AFU.
What: /sys/bus/platform/devices/dfl-port.0/power_state
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It reports the APx (AFU Power) state, different APx
means different throttling level. When reading this file, it
returns "0" - Normal / "1" - AP1 / "2" - AP2 / "6" - AP6.
What: /sys/bus/platform/devices/dfl-port.0/ap1_event
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-write. Read this file for AP1 (AFU Power State 1) event.
It's used to indicate transient AP1 state. Write 1 to this
file to clear AP1 event.
What: /sys/bus/platform/devices/dfl-port.0/ap2_event
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-write. Read this file for AP2 (AFU Power State 2) event.
It's used to indicate transient AP2 state. Write 1 to this
file to clear AP2 event.
What: /sys/bus/platform/devices/dfl-port.0/ltr
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-write. Read or set AFU latency tolerance reporting value.
Set ltr to 1 if the AFU can tolerate latency >= 40us or set it
to 0 if it is latency sensitive.
What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcmd
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Write-only. User writes command to this interface to set
userclock to AFU.
What: /sys/bus/platform/devices/dfl-port.0/userclk_freqsts
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get the status of issued command
to userclck_freqcmd.
What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcntrcmd
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Write-only. User writes command to this interface to set
userclock counter.
What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcntrsts
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get the status of issued command
to userclck_freqcntrcmd.
What: /sys/bus/platform/devices/dfl-port.0/errors/errors
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file to get errors detected on port and
Accelerated Function Unit (AFU). Write error code to this file
to clear errors. Write fails with -EINVAL if input parsing
fails or input error code doesn't match. Write fails with
-EBUSY or -ETIMEDOUT if error can't be cleared as hardware
in low power state (-EBUSY) or not respoding (-ETIMEDOUT).
What: /sys/bus/platform/devices/dfl-port.0/errors/first_error
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get the first error detected by
hardware.
What: /sys/bus/platform/devices/dfl-port.0/errors/first_malformed_req
Date: August 2019
KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get the first malformed request
captured by hardware.

106
Documentation/ABI/testing/sysfs-power
View File

@@ -301,3 +301,109 @@ Description:
Using this sysfs file will override any values that were
set using the kernel command line for disk offset.
What: /sys/power/suspend_stats
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats directory contains suspend related
statistics.
What: /sys/power/suspend_stats/success
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/success file contains the number
of times entering system sleep state succeeded.
What: /sys/power/suspend_stats/fail
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/fail file contains the number
of times entering system sleep state failed.
What: /sys/power/suspend_stats/failed_freeze
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_freeze file contains the
number of times freezing processes failed.
What: /sys/power/suspend_stats/failed_prepare
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_prepare file contains the
number of times preparing all non-sysdev devices for
a system PM transition failed.
What: /sys/power/suspend_stats/failed_resume
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_resume file contains the
number of times executing "resume" callbacks of
non-sysdev devices failed.
What: /sys/power/suspend_stats/failed_resume_early
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_resume_early file contains
the number of times executing "early resume" callbacks
of devices failed.
What: /sys/power/suspend_stats/failed_resume_noirq
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_resume_noirq file contains
the number of times executing "noirq resume" callbacks
of devices failed.
What: /sys/power/suspend_stats/failed_suspend
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_suspend file contains
the number of times executing "suspend" callbacks
of all non-sysdev devices failed.
What: /sys/power/suspend_stats/failed_suspend_late
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_suspend_late file contains
the number of times executing "late suspend" callbacks
of all devices failed.
What: /sys/power/suspend_stats/failed_suspend_noirq
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/failed_suspend_noirq file contains
the number of times executing "noirq suspend" callbacks
of all devices failed.
What: /sys/power/suspend_stats/last_failed_dev
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/last_failed_dev file contains
the last device for which a suspend/resume callback failed.
What: /sys/power/suspend_stats/last_failed_errno
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/last_failed_errno file contains
the errno of the last failed attempt at entering
system sleep state.
What: /sys/power/suspend_stats/last_failed_step
Date: July 2019
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
Description:
The /sys/power/suspend_stats/last_failed_step file contains
the last failed step in the suspend/resume path.

1
Documentation/PCI/pci-error-recovery.rst
View File

@@ -421,7 +421,6 @@ That is, the recovery API only requires that:
- drivers/net/ixgbe
- drivers/net/cxgb3
- drivers/net/s2io.c
- drivers/net/qlge
The End
-------

73
Documentation/RCU/Design/Requirements/Requirements.html
View File

@@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows:
<li> <a href="#Hotplug CPU">Hotplug CPU</a>.
<li> <a href="#Scheduler and RCU">Scheduler and RCU</a>.
<li> <a href="#Tracing and RCU">Tracing and RCU</a>.
<li> <a href="#Accesses to User Memory and RCU">
Accesses to User Memory and RCU</a>.
<li> <a href="#Energy Efficiency">Energy Efficiency</a>.
<li> <a href="#Scheduling-Clock Interrupts and RCU">
Scheduling-Clock Interrupts and RCU</a>.
@@ -2512,7 +2514,7 @@ disabled across the entire RCU read-side critical section.
<p>
It is possible to use tracing on RCU code, but tracing itself
uses RCU.
For this reason, <tt>rcu_dereference_raw_notrace()</tt>
For this reason, <tt>rcu_dereference_raw_check()</tt>
is provided for use by tracing, which avoids the destructive
recursion that could otherwise ensue.
This API is also used by virtualization in some architectures,
@@ -2521,6 +2523,75 @@ cannot be used.
The tracing folks both located the requirement and provided the
needed fix, so this surprise requirement was relatively painless.
<h3><a name="Accesses to User Memory and RCU">
Accesses to User Memory and RCU</a></h3>
<p>
The kernel needs to access user-space memory, for example, to access
data referenced by system-call parameters.
The <tt>get_user()</tt> macro does this job.
<p>
However, user-space memory might well be paged out, which means
that <tt>get_user()</tt> might well page-fault and thus block while
waiting for the resulting I/O to complete.
It would be a very bad thing for the compiler to reorder
a <tt>get_user()</tt> invocation into an RCU read-side critical
section.
For example, suppose that the source code looked like this:
<blockquote>
<pre>
1 rcu_read_lock();
2 p = rcu_dereference(gp);
3 v = p-&gt;value;
4 rcu_read_unlock();
5 get_user(user_v, user_p);
6 do_something_with(v, user_v);
</pre>
</blockquote>
<p>
The compiler must not be permitted to transform this source code into
the following:
<blockquote>
<pre>
1 rcu_read_lock();
2 p = rcu_dereference(gp);
3 get_user(user_v, user_p); // BUG: POSSIBLE PAGE FAULT!!!
4 v = p-&gt;value;
5 rcu_read_unlock();
6 do_something_with(v, user_v);
</pre>
</blockquote>
<p>
If the compiler did make this transformation in a
<tt>CONFIG_PREEMPT=n</tt> kernel build, and if <tt>get_user()</tt> did
page fault, the result would be a quiescent state in the middle
of an RCU read-side critical section.
This misplaced quiescent state could result in line&nbsp;4 being
a use-after-free access, which could be bad for your kernel's
actuarial statistics.
Similar examples can be constructed with the call to <tt>get_user()</tt>
preceding the <tt>rcu_read_lock()</tt>.
<p>
Unfortunately, <tt>get_user()</tt> doesn't have any particular
ordering properties, and in some architectures the underlying <tt>asm</tt>
isn't even marked <tt>volatile</tt>.
And even if it was marked <tt>volatile</tt>, the above access to
<tt>p-&gt;value</tt> is not volatile, so the compiler would not have any
reason to keep those two accesses in order.
<p>
Therefore, the Linux-kernel definitions of <tt>rcu_read_lock()</tt>
and <tt>rcu_read_unlock()</tt> must act as compiler barriers,
at least for outermost instances of <tt>rcu_read_lock()</tt> and
<tt>rcu_read_unlock()</tt> within a nested set of RCU read-side critical
sections.
<h3><a name="Energy Efficiency">Energy Efficiency</a></h3>
<p>

6
Documentation/RCU/stallwarn.txt
View File

@@ -57,6 +57,12 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
CONFIG_PREEMPT_RCU case, you might see stall-warning
messages.
You can use the rcutree.kthread_prio kernel boot parameter to
increase the scheduling priority of RCU's kthreads, which can
help avoid this problem. However, please note that doing this
can increase your system's context-switch rate and thus degrade
performance.
o A periodic interrupt whose handler takes longer than the time
interval between successive pairs of interrupts. This can
prevent RCU's kthreads and softirq handlers from running.

98
Documentation/admin-guide/auxdisplay/cfag12864b.rst Normal file
View File

@@ -0,0 +1,98 @@
===================================
cfag12864b LCD Driver Documentation
===================================
:License: GPLv2
:Author & Maintainer: Miguel Ojeda Sandonis
:Date: 2006-10-27
.. INDEX
1. DRIVER INFORMATION
2. DEVICE INFORMATION
3. WIRING
4. USERSPACE PROGRAMMING
1. Driver Information
---------------------
This driver supports a cfag12864b LCD.
2. Device Information
---------------------
:Manufacturer: Crystalfontz
:Device Name: Crystalfontz 12864b LCD Series
:Device Code: cfag12864b
:Webpage: http://www.crystalfontz.com
:Device Webpage: http://www.crystalfontz.com/products/12864b/
:Type: LCD (Liquid Crystal Display)
:Width: 128
:Height: 64
:Colors: 2 (B/N)
:Controller: ks0108
:Controllers: 2
:Pages: 8 each controller
:Addresses: 64 each page
:Data size: 1 byte each address
:Memory size: 2 * 8 * 64 * 1 = 1024 bytes = 1 Kbyte
3. Wiring
---------
The cfag12864b LCD Series don't have official wiring.
The common wiring is done to the parallel port as shown::
Parallel Port cfag12864b
Name Pin# Pin# Name
Strobe ( 1)------------------------------(17) Enable
Data 0 ( 2)------------------------------( 4) Data 0
Data 1 ( 3)------------------------------( 5) Data 1
Data 2 ( 4)------------------------------( 6) Data 2
Data 3 ( 5)------------------------------( 7) Data 3
Data 4 ( 6)------------------------------( 8) Data 4
Data 5 ( 7)------------------------------( 9) Data 5
Data 6 ( 8)------------------------------(10) Data 6
Data 7 ( 9)------------------------------(11) Data 7
(10) [+5v]---( 1) Vdd
(11) [GND]---( 2) Ground
(12) [+5v]---(14) Reset
(13) [GND]---(15) Read / Write
Line (14)------------------------------(13) Controller Select 1
(15)
Init (16)------------------------------(12) Controller Select 2
Select (17)------------------------------(16) Data / Instruction
Ground (18)---[GND] [+5v]---(19) LED +
Ground (19)---[GND]
Ground (20)---[GND] E A Values:
Ground (21)---[GND] [GND]---[P1]---(18) Vee - R = Resistor = 22 ohm
Ground (22)---[GND] | - P1 = Preset = 10 Kohm
Ground (23)---[GND] ---- S ------( 3) V0 - P2 = Preset = 1 Kohm
Ground (24)---[GND] | |
Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED -
4. Userspace Programming
------------------------
The cfag12864bfb describes a framebuffer device (/dev/fbX).
It has a size of 1024 bytes = 1 Kbyte.
Each bit represents one pixel. If the bit is high, the pixel will
turn on. If the pixel is low, the pixel will turn off.
You can use the framebuffer as a file: fopen, fwrite, fclose...
Although the LCD won't get updated until the next refresh time arrives.
Also, you can mmap the framebuffer: open & mmap, munmap & close...
which is the best option for most uses.
Check samples/auxdisplay/cfag12864b-example.c
for a real working userspace complete program with usage examples.

16
Documentation/admin-guide/auxdisplay/index.rst Normal file
View File

@@ -0,0 +1,16 @@
=========================
Auxiliary Display Support
=========================
.. toctree::
:maxdepth: 1
ks0108.rst
cfag12864b.rst
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

50
Documentation/admin-guide/auxdisplay/ks0108.rst Normal file
View File

@@ -0,0 +1,50 @@
==========================================
ks0108 LCD Controller Driver Documentation
==========================================
:License: GPLv2
:Author & Maintainer: Miguel Ojeda Sandonis
:Date: 2006-10-27
.. INDEX
1. DRIVER INFORMATION
2. DEVICE INFORMATION
3. WIRING
1. Driver Information
---------------------
This driver supports the ks0108 LCD controller.
2. Device Information
---------------------
:Manufacturer: Samsung
:Device Name: KS0108 LCD Controller
:Device Code: ks0108
:Webpage: -
:Device Webpage: -
:Type: LCD Controller (Liquid Crystal Display Controller)
:Width: 64
:Height: 64
:Colors: 2 (B/N)
:Pages: 8
:Addresses: 64 each page
:Data size: 1 byte each address
:Memory size: 8 * 64 * 1 = 512 bytes
3. Wiring
---------
The driver supports data parallel port wiring.
If you aren't building LCD related hardware, you should check
your LCD specific wiring information in the same folder.
For example, check Documentation/admin-guide/auxdisplay/cfag12864b.rst

6
Documentation/admin-guide/cgroup-v1/blkio-controller.rst
View File

@@ -130,12 +130,6 @@ Proportional weight policy files
dev weight
8:16 300
- blkio.leaf_weight[_device]
- Equivalents of blkio.weight[_device] for the purpose of
deciding how much weight tasks in the given cgroup has while
competing with the cgroup's child cgroups. For details,
please refer to Documentation/block/cfq-iosched.txt.
- blkio.time
- disk time allocated to cgroup per device in milliseconds. First
two fields specify the major and minor number of the device and

131
Documentation/admin-guide/cgroup-v2.rst
View File

@@ -951,6 +951,13 @@ controller implements weight and absolute bandwidth limit models for
normal scheduling policy and absolute bandwidth allocation model for
realtime scheduling policy.
In all the above models, cycles distribution is defined only on a temporal
base and it does not account for the frequency at which tasks are executed.
The (optional) utilization clamping support allows to hint the schedutil
cpufreq governor about the minimum desired frequency which should always be
provided by a CPU, as well as the maximum desired frequency, which should not
be exceeded by a CPU.
WARNING: cgroup2 doesn't yet support control of realtime processes and
the cpu controller can only be enabled when all RT processes are in
the root cgroup. Be aware that system management software may already
@@ -1016,6 +1023,33 @@ All time durations are in microseconds.
Shows pressure stall information for CPU. See
Documentation/accounting/psi.rst for details.
cpu.uclamp.min
A read-write single value file which exists on non-root cgroups.
The default is "0", i.e. no utilization boosting.
The requested minimum utilization (protection) as a percentage
rational number, e.g. 12.34 for 12.34%.
This interface allows reading and setting minimum utilization clamp
values similar to the sched_setattr(2). This minimum utilization
value is used to clamp the task specific minimum utilization clamp.
The requested minimum utilization (protection) is always capped by
the current value for the maximum utilization (limit), i.e.
`cpu.uclamp.max`.
cpu.uclamp.max
A read-write single value file which exists on non-root cgroups.
The default is "max". i.e. no utilization capping
The requested maximum utilization (limit) as a percentage rational
number, e.g. 98.76 for 98.76%.
This interface allows reading and setting maximum utilization clamp
values similar to the sched_setattr(2). This maximum utilization
value is used to clamp the task specific maximum utilization clamp.
Memory
------
@@ -1435,6 +1469,103 @@ IO Interface Files
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021
io.cost.qos
A read-write nested-keyed file with exists only on the root
cgroup.
This file configures the Quality of Service of the IO cost
model based controller (CONFIG_BLK_CGROUP_IOCOST) which
currently implements "io.weight" proportional control. Lines
are keyed by $MAJ:$MIN device numbers and not ordered. The
line for a given device is populated on the first write for
the device on "io.cost.qos" or "io.cost.model". The following
nested keys are defined.
====== =====================================
enable Weight-based control enable
ctrl "auto" or "user"
rpct Read latency percentile [0, 100]
rlat Read latency threshold
wpct Write latency percentile [0, 100]
wlat Write latency threshold
min Minimum scaling percentage [1, 10000]
max Maximum scaling percentage [1, 10000]
====== =====================================
The controller is disabled by default and can be enabled by
setting "enable" to 1. "rpct" and "wpct" parameters default
to zero and the controller uses internal device saturation
state to adjust the overall IO rate between "min" and "max".
When a better control quality is needed, latency QoS
parameters can be configured. For example::
8:16 enable=1 ctrl=auto rpct=95.00 rlat=75000 wpct=95.00 wlat=150000 min=50.00 max=150.0
shows that on sdb, the controller is enabled, will consider
the device saturated if the 95th percentile of read completion
latencies is above 75ms or write 150ms, and adjust the overall
IO issue rate between 50% and 150% accordingly.
The lower the saturation point, the better the latency QoS at
the cost of aggregate bandwidth. The narrower the allowed
adjustment range between "min" and "max", the more conformant
to the cost model the IO behavior. Note that the IO issue
base rate may be far off from 100% and setting "min" and "max"
blindly can lead to a significant loss of device capacity or
control quality. "min" and "max" are useful for regulating
devices which show wide temporary behavior changes - e.g. a
ssd which accepts writes at the line speed for a while and
then completely stalls for multiple seconds.
When "ctrl" is "auto", the parameters are controlled by the
kernel and may change automatically. Setting "ctrl" to "user"
or setting any of the percentile and latency parameters puts
it into "user" mode and disables the automatic changes. The
automatic mode can be restored by setting "ctrl" to "auto".
io.cost.model
A read-write nested-keyed file with exists only on the root
cgroup.
This file configures the cost model of the IO cost model based
controller (CONFIG_BLK_CGROUP_IOCOST) which currently
implements "io.weight" proportional control. Lines are keyed
by $MAJ:$MIN device numbers and not ordered. The line for a
given device is populated on the first write for the device on
"io.cost.qos" or "io.cost.model". The following nested keys
are defined.
===== ================================
ctrl "auto" or "user"
model The cost model in use - "linear"
===== ================================
When "ctrl" is "auto", the kernel may change all parameters
dynamically. When "ctrl" is set to "user" or any other
parameters are written to, "ctrl" become "user" and the
automatic changes are disabled.
When "model" is "linear", the following model parameters are
defined.
============= ========================================
[r|w]bps The maximum sequential IO throughput
[r|w]seqiops The maximum 4k sequential IOs per second
[r|w]randiops The maximum 4k random IOs per second
============= ========================================
From the above, the builtin linear model determines the base
costs of a sequential and random IO and the cost coefficient
for the IO size. While simple, this model can cover most
common device classes acceptably.
The IO cost model isn't expected to be accurate in absolute
sense and is scaled to the device behavior dynamically.
If needed, tools/cgroup/iocost_coef_gen.py can be used to
generate device-specific coefficients.
io.weight
A read-write flat-keyed file which exists on non-root cgroups.
The default is "default 100".

62
Documentation/filesystems/cifs/AUTHORS → Documentation/admin-guide/cifs/authors.rst
View File

@@ -1,5 +1,10 @@
=======
Authors
=======
Original Author
===============
---------------
Steve French (sfrench@samba.org)
The author wishes to express his appreciation and thanks to:
@@ -20,33 +25,34 @@ thanks to the Samba team for their technical advice and encouragement.
Patch Contributors
------------------
Zwane Mwaikambo
Andi Kleen
Amrut Joshi
Shobhit Dayal
Sergey Vlasov
Richard Hughes
Yury Umanets
Mark Hamzy (for some of the early cifs IPv6 work)
Domen Puncer
Jesper Juhl (in particular for lots of whitespace/formatting cleanup)
Vince Negri and Dave Stahl (for finding an important caching bug)
Adrian Bunk (kcalloc cleanups)
Miklos Szeredi
Kazeon team for various fixes especially for 2.4 version.
Asser Ferno (Change Notify support)
Shaggy (Dave Kleikamp) for innumerable small fs suggestions and some good cleanup
Gunter Kukkukk (testing and suggestions for support of old servers)
Igor Mammedov (DFS support)
Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code)
Scott Lovenberg
Pavel Shilovsky (for great work adding SMB2 support, and various SMB3 features)
Aurelien Aptel (for DFS SMB3 work and some key bug fixes)
Ronnie Sahlberg (for SMB3 xattr work, bug fixes, and lots of great work on compounding)
Shirish Pargaonkar (for many ACL patches over the years)
Sachin Prabhu (many bug fixes, including for reconnect, copy offload and security)
Paulo Alcantara
Long Li (some great work on RDMA, SMB Direct)
- Zwane Mwaikambo
- Andi Kleen
- Amrut Joshi
- Shobhit Dayal
- Sergey Vlasov
- Richard Hughes
- Yury Umanets
- Mark Hamzy (for some of the early cifs IPv6 work)
- Domen Puncer
- Jesper Juhl (in particular for lots of whitespace/formatting cleanup)
- Vince Negri and Dave Stahl (for finding an important caching bug)
- Adrian Bunk (kcalloc cleanups)
- Miklos Szeredi
- Kazeon team for various fixes especially for 2.4 version.
- Asser Ferno (Change Notify support)
- Shaggy (Dave Kleikamp) for innumerable small fs suggestions and some good cleanup
- Gunter Kukkukk (testing and suggestions for support of old servers)
- Igor Mammedov (DFS support)
- Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code)
- Scott Lovenberg
- Pavel Shilovsky (for great work adding SMB2 support, and various SMB3 features)
- Aurelien Aptel (for DFS SMB3 work and some key bug fixes)
- Ronnie Sahlberg (for SMB3 xattr work, bug fixes, and lots of great work on compounding)
- Shirish Pargaonkar (for many ACL patches over the years)
- Sachin Prabhu (many bug fixes, including for reconnect, copy offload and security)
- Paulo Alcantara
- Long Li (some great work on RDMA, SMB Direct)
Test case and Bug Report contributors

4
Documentation/filesystems/cifs/CHANGES → Documentation/admin-guide/cifs/changes.rst
View File

@@ -1,3 +1,7 @@
=======
Changes
=======
See https://wiki.samba.org/index.php/LinuxCIFSKernel for summary
information (that may be easier to read than parsing the output of
"git log fs/cifs") about fixes/improvements to CIFS/SMB2/SMB3 support (changes

21
Documentation/admin-guide/cifs/index.rst Normal file
View File

@@ -0,0 +1,21 @@
.. SPDX-License-Identifier: GPL-2.0
====
CIFS
====
.. toctree::
:maxdepth: 2
introduction
usage
todo
changes
authors
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

8
Documentation/filesystems/cifs/cifs.txt → Documentation/admin-guide/cifs/introduction.rst
View File

@@ -1,3 +1,7 @@
============
Introduction
============
This is the client VFS module for the SMB3 NAS protocol as well
as for older dialects such as the Common Internet File System (CIFS)
protocol which was the successor to the Server Message Block
@@ -33,7 +37,9 @@
tools (including smbinfo and setcifsacl) that can be obtained from
https://git.samba.org/?p=cifs-utils.git
or
git://git.samba.org/cifs-utils.git
mount.cifs should be installed in the directory with the other mount helpers.
@@ -41,5 +47,7 @@
For more information on the module see the project wiki page at
https://wiki.samba.org/index.php/LinuxCIFS
and
https://wiki.samba.org/index.php/LinuxCIFS_utils

94
Documentation/filesystems/cifs/TODO → Documentation/admin-guide/cifs/todo.rst
View File

@@ -1,3 +1,7 @@
====
TODO
====
Version 2.14 December 21, 2018
A Partial List of Missing Features
@@ -8,55 +12,58 @@ for visible, important contributions to this module. Here
is a partial list of the known problems and missing features:
a) SMB3 (and SMB3.1.1) missing optional features:
- multichannel (started), integration with RDMA
- directory leases (improved metadata caching), started (root dir only)
- T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
currently the only two server side copy mechanisms supported)
b) improved sparse file support (fiemap and SEEK_HOLE are implemented
but additional features would be supportable by the protocol).
but additional features would be supportable by the protocol).
c) Directory entry caching relies on a 1 second timer, rather than
using Directory Leases, currently only the root file handle is cached longer
using Directory Leases, currently only the root file handle is cached longer
d) quota support (needs minor kernel change since quota calls
to make it to network filesystems or deviceless filesystems)
to make it to network filesystems or deviceless filesystems)
e) Additional use cases can be optimized to use "compounding"
(e.g. open/query/close and open/setinfo/close) to reduce the number
of roundtrips to the server and improve performance. Various cases
(stat, statfs, create, unlink, mkdir) already have been improved by
using compounding but more can be done. In addition we could significantly
reduce redundant opens by using deferred close (with handle caching leases)
and better using reference counters on file handles.
e) Additional use cases can be optimized to use "compounding" (e.g.
open/query/close and open/setinfo/close) to reduce the number of
roundtrips to the server and improve performance. Various cases
(stat, statfs, create, unlink, mkdir) already have been improved by
using compounding but more can be done. In addition we could
significantly reduce redundant opens by using deferred close (with
handle caching leases) and better using reference counters on file
handles.
f) Finish inotify support so kde and gnome file list windows
will autorefresh (partially complete by Asser). Needs minor kernel
vfs change to support removing D_NOTIFY on a file.
will autorefresh (partially complete by Asser). Needs minor kernel
vfs change to support removing D_NOTIFY on a file.
g) Add GUI tool to configure /proc/fs/cifs settings and for display of
the CIFS statistics (started)
the CIFS statistics (started)
h) implement support for security and trusted categories of xattrs
(requires minor protocol extension) to enable better support for SELINUX
(requires minor protocol extension) to enable better support for SELINUX
i) Add support for tree connect contexts (see MS-SMB2) a new SMB3.1.1 protocol
feature (may be especially useful for virtualization).
j) Create UID mapping facility so server UIDs can be mapped on a per
mount or a per server basis to client UIDs or nobody if no mapping
exists. Also better integration with winbind for resolving SID owners
mount or a per server basis to client UIDs or nobody if no mapping
exists. Also better integration with winbind for resolving SID owners
k) Add tools to take advantage of more smb3 specific ioctls and features
(passthrough ioctl/fsctl is now implemented in cifs.ko to allow sending
various SMB3 fsctls and query info and set info calls directly from user space)
Add tools to make setting various non-POSIX metadata attributes easier
from tools (e.g. extending what was done in smb-info tool).
(passthrough ioctl/fsctl is now implemented in cifs.ko to allow
sending various SMB3 fsctls and query info and set info calls
directly from user space) Add tools to make setting various non-POSIX
metadata attributes easier from tools (e.g. extending what was done
in smb-info tool).
l) encrypted file support
m) improved stats gathering tools (perhaps integration with nfsometer?)
to extend and make easier to use what is currently in /proc/fs/cifs/Stats
to extend and make easier to use what is currently in /proc/fs/cifs/Stats
n) Add support for claims based ACLs ("DAC")
@@ -69,57 +76,58 @@ p) Add support for witness protocol (perhaps ioctl to cifs.ko from user space
different servers, and the server we are connected to has gone down.
q) Allow mount.cifs to be more verbose in reporting errors with dialect
or unsupported feature errors.
or unsupported feature errors.
r) updating cifs documentation, and user guide.
s) Addressing bugs found by running a broader set of xfstests in standard
file system xfstest suite.
file system xfstest suite.
t) split cifs and smb3 support into separate modules so legacy (and less
secure) CIFS dialect can be disabled in environments that don't need it
and simplify the code.
secure) CIFS dialect can be disabled in environments that don't need it
and simplify the code.
v) POSIX Extensions for SMB3.1.1 (started, create and mkdir support added
so far).
so far).
w) Add support for additional strong encryption types, and additional spnego
authentication mechanisms (see MS-SMB2)
authentication mechanisms (see MS-SMB2)
x) Finish support for SMB3.1.1 compression
KNOWN BUGS
====================================
Known Bugs
==========
See http://bugzilla.samba.org - search on product "CifsVFS" for
current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS)
1) existing symbolic links (Windows reparse points) are recognized but
can not be created remotely. They are implemented for Samba and those that
support the CIFS Unix extensions, although earlier versions of Samba
overly restrict the pathnames.
can not be created remotely. They are implemented for Samba and those that
support the CIFS Unix extensions, although earlier versions of Samba
overly restrict the pathnames.
2) follow_link and readdir code does not follow dfs junctions
but recognizes them
but recognizes them
Misc testing to do
==================
1) check out max path names and max path name components against various server
types. Try nested symlinks (8 deep). Return max path name in stat -f information
types. Try nested symlinks (8 deep). Return max path name in stat -f information
2) Improve xfstest's cifs/smb3 enablement and adapt xfstests where needed to test
cifs/smb3 better
cifs/smb3 better
3) Additional performance testing and optimization using iozone and similar -
there are some easy changes that can be done to parallelize sequential writes,
and when signing is disabled to request larger read sizes (larger than
negotiated size) and send larger write sizes to modern servers.
there are some easy changes that can be done to parallelize sequential writes,
and when signing is disabled to request larger read sizes (larger than
negotiated size) and send larger write sizes to modern servers.
4) More exhaustively test against less common servers
5) Continue to extend the smb3 "buildbot" which does automated xfstesting
against Windows, Samba and Azure currently - to add additional tests and
to allow the buildbot to execute the tests faster. The URL for the
buildbot is: http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com
against Windows, Samba and Azure currently - to add additional tests and
to allow the buildbot to execute the tests faster. The URL for the
buildbot is: http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com
6) Address various coverity warnings (most are not bugs per-se, but
the more warnings are addressed, the easier it is to spot real
problems that static analyzers will point out in the future).
the more warnings are addressed, the easier it is to spot real
problems that static analyzers will point out in the future).

438
Documentation/filesystems/cifs/README → Documentation/admin-guide/cifs/usage.rst
View File

@@ -1,3 +1,7 @@
=====
Usage
=====
This module supports the SMB3 family of advanced network protocols (as well
as older dialects, originally called "CIFS" or SMB1).
@@ -11,43 +15,47 @@ Information Foundation. CIFS and now SMB3 has now become a defacto
standard for interoperating between Macs and Windows and major NAS appliances.
Please see
MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification)
http://protocolfreedom.org/ and
http://samba.org/samba/PFIF/
MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification)
http://protocolfreedom.org/ and
http://samba.org/samba/PFIF/
for more details.
For questions or bug reports please contact:
smfrench@gmail.com
See the project page at: https://wiki.samba.org/index.php/LinuxCIFS_utils
Build instructions:
Build instructions
==================
For Linux:
1) Download the kernel (e.g. from http://www.kernel.org)
and change directory into the top of the kernel directory tree
(e.g. /usr/src/linux-2.5.73)
and change directory into the top of the kernel directory tree
(e.g. /usr/src/linux-2.5.73)
2) make menuconfig (or make xconfig)
3) select cifs from within the network filesystem choices
4) save and exit
5) make
Installation instructions:
Installation instructions
=========================
If you have built the CIFS vfs as module (successfully) simply
type "make modules_install" (or if you prefer, manually copy the file to
type ``make modules_install`` (or if you prefer, manually copy the file to
the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.ko).
If you have built the CIFS vfs into the kernel itself, follow the instructions
for your distribution on how to install a new kernel (usually you
would simply type "make install").
would simply type ``make install``).
If you do not have the utility mount.cifs (in the Samba 4.x source tree and on
the CIFS VFS web site) copy it to the same directory in which mount helpers
reside (usually /sbin). Although the helper software is not
required, mount.cifs is recommended. Most distros include a "cifs-utils"
required, mount.cifs is recommended. Most distros include a ``cifs-utils``
package that includes this utility so it is recommended to install this.
Note that running the Winbind pam/nss module (logon service) on all of your
@@ -57,13 +65,16 @@ found at cifs-utils.git on git.samba.org
If cifs is built as a module, then the size and number of network buffers
and maximum number of simultaneous requests to one server can be configured.
Changing these from their defaults is not recommended. By executing modinfo
Changing these from their defaults is not recommended. By executing modinfo::
modinfo kernel/fs/cifs/cifs.ko
on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made
at module initialization time (by running insmod cifs.ko) can be seen.
Recommendations
===============
To improve security the SMB2.1 dialect or later (usually will get SMB3) is now
the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0"
on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is
@@ -72,26 +83,30 @@ many advanced security features such as downgrade attack detection
and encrypted shares and stronger signing and authentication algorithms.
There are additional mount options that may be helpful for SMB3 to get
improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1):
"mfsymlinks" and "cifsacl" and "idsfromsid"
``mfsymlinks`` and ``cifsacl`` and ``idsfromsid``
Allowing User Mounts
====================
To permit users to mount and unmount over directories they own is possible
with the cifs vfs. A way to enable such mounting is to mark the mount.cifs
utility as suid (e.g. "chmod +s /sbin/mount.cifs). To enable users to
utility as suid (e.g. ``chmod +s /sbin/mount.cifs``). To enable users to
umount shares they mount requires
1) mount.cifs version 1.4 or later
2) an entry for the share in /etc/fstab indicating that a user may
unmount it e.g.
//server/usersharename /mnt/username cifs user 0 0
unmount it e.g.::
//server/usersharename /mnt/username cifs user 0 0
Note that when the mount.cifs utility is run suid (allowing user mounts),
in order to reduce risks, the "nosuid" mount flag is passed in on mount to
in order to reduce risks, the ``nosuid`` mount flag is passed in on mount to
disallow execution of an suid program mounted on the remote target.
When mount is executed as root, nosuid is not passed in by default,
and execution of suid programs on the remote target would be enabled
by default. This can be changed, as with nfs and other filesystems,
by simply specifying "nosuid" among the mount options. For user mounts
by simply specifying ``nosuid`` among the mount options. For user mounts
though to be able to pass the suid flag to mount requires rebuilding
mount.cifs with the following flag: CIFS_ALLOW_USR_SUID
@@ -100,13 +115,14 @@ later source tree in docs/manpages/mount.cifs.8
Allowing User Unmounts
======================
To permit users to ummount directories that they have user mounted (see above),
the utility umount.cifs may be used. It may be invoked directly, or if
umount.cifs is placed in /sbin, umount can invoke the cifs umount helper
(at least for most versions of the umount utility) for umount of cifs
mounts, unless umount is invoked with -i (which will avoid invoking a umount
helper). As with mount.cifs, to enable user unmounts umount.cifs must be marked
as suid (e.g. "chmod +s /sbin/umount.cifs") or equivalent (some distributions
as suid (e.g. ``chmod +s /sbin/umount.cifs``) or equivalent (some distributions
allow adding entries to a file to the /etc/permissions file to achieve the
equivalent suid effect). For this utility to succeed the target path
must be a cifs mount, and the uid of the current user must match the uid
@@ -120,6 +136,7 @@ or unpredictable UNC names.
Samba Considerations
====================
Most current servers support SMB2.1 and SMB3 which are more secure,
but there are useful protocol extensions for the older less secure CIFS
dialect, so to get the maximum benefit if mounting using the older dialect
@@ -129,13 +146,13 @@ Unix Extensions standard (e.g. almost any version of Samba ie version
Note that uid, gid and file permissions will display default values if you do
not have a server that supports the Unix extensions for CIFS (such as Samba
2.2.5 or later). To enable the Unix CIFS Extensions in the Samba server, add
the line:
the line::
unix extensions = yes
to your smb.conf file on the server. Note that the following smb.conf settings
are also useful (on the Samba server) when the majority of clients are Unix or
Linux:
Linux::
case sensitive = yes
delete readonly = yes
@@ -147,31 +164,33 @@ cifs client, and that EA support is present in later versions of Samba (e.g.
shares on NTFS filesystems). Extended Attribute (xattr) support is an optional
feature of most Linux filesystems which may require enabling via
make menuconfig. Client support for extended attributes (user xattr) can be
disabled on a per-mount basis by specifying "nouser_xattr" on mount.
disabled on a per-mount basis by specifying ``nouser_xattr`` on mount.
The CIFS client can get and set POSIX ACLs (getfacl, setfacl) to Samba servers
version 3.10 and later. Setting POSIX ACLs requires enabling both XATTR and
then POSIX support in the CIFS configuration options when building the cifs
module. POSIX ACL support can be disabled on a per mount basic by specifying
"noacl" on mount.
``noacl`` on mount.
Some administrators may want to change Samba's smb.conf "map archive" and
"create mask" parameters from the default. Unless the create mask is changed
Some administrators may want to change Samba's smb.conf ``map archive`` and
``create mask`` parameters from the default. Unless the create mask is changed
newly created files can end up with an unnecessarily restrictive default mode,
which may not be what you want, although if the CIFS Unix extensions are
enabled on the server and client, subsequent setattr calls (e.g. chmod) can
fix the mode. Note that creating special devices (mknod) remotely
may require specifying a mkdev function to Samba if you are not using
Samba 3.0.6 or later. For more information on these see the manual pages
("man smb.conf") on the Samba server system. Note that the cifs vfs,
(``man smb.conf``) on the Samba server system. Note that the cifs vfs,
unlike the smbfs vfs, does not read the smb.conf on the client system
(the few optional settings are passed in on mount via -o parameters instead).
Note that Samba 2.2.7 or later includes a fix that allows the CIFS VFS to delete
open files (required for strict POSIX compliance). Windows Servers already
supported this feature. Samba server does not allow symlinks that refer to files
outside of the share, so in Samba versions prior to 3.0.6, most symlinks to
files with absolute paths (ie beginning with slash) such as:
files with absolute paths (ie beginning with slash) such as::
ln -s /mnt/foo bar
would be forbidden. Samba 3.0.6 server or later includes the ability to create
such symlinks safely by converting unsafe symlinks (ie symlinks to server
files that are outside of the share) to a samba specific format on the server
@@ -182,18 +201,19 @@ later, but only for remote clients using the CIFS Unix extensions, and will
be invisbile to Windows clients and typically will not affect local
applications running on the same server as Samba.
Use instructions:
Use instructions
================
Once the CIFS VFS support is built into the kernel or installed as a module
(cifs.ko), you can use mount syntax like the following to access Samba or
Mac or Windows servers:
Mac or Windows servers::
mount -t cifs //9.53.216.11/e$ /mnt -o username=myname,password=mypassword
Before -o the option -v may be specified to make the mount.cifs
mount helper display the mount steps more verbosely.
After -o the following commonly used cifs vfs specific options
are supported:
are supported::
username=<username>
password=<password>
@@ -203,25 +223,28 @@ Other cifs mount options are described below. Use of TCP names (in addition to
ip addresses) is available if the mount helper (mount.cifs) is installed. If
you do not trust the server to which are mounted, or if you do not have
cifs signing enabled (and the physical network is insecure), consider use
of the standard mount options "noexec" and "nosuid" to reduce the risk of
of the standard mount options ``noexec`` and ``nosuid`` to reduce the risk of
running an altered binary on your local system (downloaded from a hostile server
or altered by a hostile router).
Although mounting using format corresponding to the CIFS URL specification is
not possible in mount.cifs yet, it is possible to use an alternate format
for the server and sharename (which is somewhat similar to NFS style mount
syntax) instead of the more widely used UNC format (i.e. \\server\share):
syntax) instead of the more widely used UNC format (i.e. \\server\share)::
mount -t cifs tcp_name_of_server:share_name /mnt -o user=myname,pass=mypasswd
When using the mount helper mount.cifs, passwords may be specified via alternate
mechanisms, instead of specifying it after -o using the normal "pass=" syntax
mechanisms, instead of specifying it after -o using the normal ``pass=`` syntax
on the command line:
1) By including it in a credential file. Specify credentials=filename as one
of the mount options. Credential files contain two lines
username=someuser
password=your_password
of the mount options. Credential files contain two lines::
username=someuser
password=your_password
2) By specifying the password in the PASSWD environment variable (similarly
the user name can be taken from the USER environment variable).
the user name can be taken from the USER environment variable).
3) By specifying the password in a file by name via PASSWD_FILE
4) By specifying the password in a file by file descriptor via PASSWD_FD
@@ -229,6 +252,7 @@ If no password is provided, mount.cifs will prompt for password entry
Restrictions
============
Servers must support either "pure-TCP" (port 445 TCP/IP CIFS connections) or RFC
1001/1002 support for "Netbios-Over-TCP/IP." This is not likely to be a
problem as most servers support this.
@@ -243,25 +267,32 @@ filenames (ie those which contain valid Linux characters, which normally
would be forbidden for Windows/CIFS semantics) as long as the server is
configured for Unix Extensions (and the client has not disabled
/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option
"mapposix" can be used on CIFS (vers=1.0) to force the mapping of
``mapposix`` can be used on CIFS (vers=1.0) to force the mapping of
illegal Windows/NTFS/SMB characters to a remap range (this mount parm
is the default for SMB3). This remap ("mapposix") range is also
is the default for SMB3). This remap (``mapposix``) range is also
compatible with Mac (and "Services for Mac" on some older Windows).
CIFS VFS Mount Options
======================
A partial list of the supported mount options follows:
username The user name to use when trying to establish
username
The user name to use when trying to establish
the CIFS session.
password The user password. If the mount helper is
password
The user password. If the mount helper is
installed, the user will be prompted for password
if not supplied.
ip The ip address of the target server
unc The target server Universal Network Name (export) to
ip
The ip address of the target server
unc
The target server Universal Network Name (export) to
mount.
domain Set the SMB/CIFS workgroup name prepended to the
domain
Set the SMB/CIFS workgroup name prepended to the
username during CIFS session establishment
forceuid Set the default uid for inodes to the uid
forceuid
Set the default uid for inodes to the uid
passed in on mount. For mounts to servers
which do support the CIFS Unix extensions, such as a
properly configured Samba server, the server provides
@@ -276,7 +307,7 @@ A partial list of the supported mount options follows:
extensions, the default uid (and gid) returned on lookup
of existing files will be the uid (gid) of the person
who executed the mount (root, except when mount.cifs
is configured setuid for user mounts) unless the "uid="
is configured setuid for user mounts) unless the ``uid=``
(gid) mount option is specified. Also note that permission
checks (authorization checks) on accesses to a file occur
at the server, but there are cases in which an administrator
@@ -286,22 +317,29 @@ A partial list of the supported mount options follows:
client, and a crude form of client side permission checking
can be enabled by specifying file_mode and dir_mode on
the client. (default)
forcegid (similar to above but for the groupid instead of uid) (default)
noforceuid Fill in file owner information (uid) by requesting it from
forcegid
(similar to above but for the groupid instead of uid) (default)
noforceuid
Fill in file owner information (uid) by requesting it from
the server if possible. With this option, the value given in
the uid= option (on mount) will only be used if the server
can not support returning uids on inodes.
noforcegid (similar to above but for the group owner, gid, instead of uid)
uid Set the default uid for inodes, and indicate to the
noforcegid
(similar to above but for the group owner, gid, instead of uid)
uid
Set the default uid for inodes, and indicate to the
cifs kernel driver which local user mounted. If the server
supports the unix extensions the default uid is
not used to fill in the owner fields of inodes (files)
unless the "forceuid" parameter is specified.
gid Set the default gid for inodes (similar to above).
file_mode If CIFS Unix extensions are not supported by the server
unless the ``forceuid`` parameter is specified.
gid
Set the default gid for inodes (similar to above).
file_mode
If CIFS Unix extensions are not supported by the server
this overrides the default mode for file inodes.
fsc Enable local disk caching using FS-Cache (off by default). This
option could be useful to improve performance on a slow link,
fsc
Enable local disk caching using FS-Cache (off by default). This
option could be useful to improve performance on a slow link,
heavily loaded server and/or network where reading from the
disk is faster than reading from the server (over the network).
This could also impact scalability positively as the
@@ -310,18 +348,22 @@ A partial list of the supported mount options follows:
type workloads. So, you need to consider carefully your
workload/scenario before using this option. Currently, local
disk caching is functional for CIFS files opened as read-only.
dir_mode If CIFS Unix extensions are not supported by the server
dir_mode
If CIFS Unix extensions are not supported by the server
this overrides the default mode for directory inodes.
port attempt to contact the server on this tcp port, before
port
attempt to contact the server on this tcp port, before
trying the usual ports (port 445, then 139).
iocharset Codepage used to convert local path names to and from
iocharset
Codepage used to convert local path names to and from
Unicode. Unicode is used by default for network path
names if the server supports it. If iocharset is
not specified then the nls_default specified
during the local client kernel build will be used.
If server does not support Unicode, this parameter is
unused.
rsize default read size (usually 16K). The client currently
rsize
default read size (usually 16K). The client currently
can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize
defaults to 16K and may be changed (from 8K to the maximum
kmalloc size allowed by your kernel) at module install time
@@ -333,10 +375,12 @@ A partial list of the supported mount options follows:
newer servers (e.g. Samba 3.0.26 or later) do. rsize can be
set from a minimum of 2048 to a maximum of 130048 (127K or
CIFSMaxBufSize, whichever is smaller)
wsize default write size (default 57344)
wsize
default write size (default 57344)
maximum wsize currently allowed by CIFS is 57344 (fourteen
4096 byte pages)
actimeo=n attribute cache timeout in seconds (default 1 second).
actimeo=n
attribute cache timeout in seconds (default 1 second).
After this timeout, the cifs client requests fresh attribute
information from the server. This option allows to tune the
attribute cache timeout to suit the workload needs. Shorter
@@ -345,49 +389,67 @@ A partial list of the supported mount options follows:
of calls to the server at the expense of less stricter cache
coherency checks (i.e. incorrect attribute cache for a short
period of time).
rw mount the network share read-write (note that the
rw
mount the network share read-write (note that the
server may still consider the share read-only)
ro mount network share read-only
version used to distinguish different versions of the
ro
mount network share read-only
version
used to distinguish different versions of the
mount helper utility (not typically needed)
sep if first mount option (after the -o), overrides
sep
if first mount option (after the -o), overrides
the comma as the separator between the mount
parms. e.g.
parms. e.g.::
-o user=myname,password=mypassword,domain=mydom
could be passed instead with period as the separator by
could be passed instead with period as the separator by::
-o sep=.user=myname.password=mypassword.domain=mydom
this might be useful when comma is contained within username
or password or domain. This option is less important
when the cifs mount helper cifs.mount (version 1.1 or later)
is used.
nosuid Do not allow remote executables with the suid bit
nosuid
Do not allow remote executables with the suid bit
program to be executed. This is only meaningful for mounts
to servers such as Samba which support the CIFS Unix Extensions.
If you do not trust the servers in your network (your mount
targets) it is recommended that you specify this option for
greater security.
exec Permit execution of binaries on the mount.
noexec Do not permit execution of binaries on the mount.
dev Recognize block devices on the remote mount.
nodev Do not recognize devices on the remote mount.
suid Allow remote files on this mountpoint with suid enabled to
exec
Permit execution of binaries on the mount.
noexec
Do not permit execution of binaries on the mount.
dev
Recognize block devices on the remote mount.
nodev
Do not recognize devices on the remote mount.
suid
Allow remote files on this mountpoint with suid enabled to
be executed (default for mounts when executed as root,
nosuid is default for user mounts).
credentials Although ignored by the cifs kernel component, it is used by
credentials
Although ignored by the cifs kernel component, it is used by
the mount helper, mount.cifs. When mount.cifs is installed it
opens and reads the credential file specified in order
to obtain the userid and password arguments which are passed to
the cifs vfs.
guest Although ignored by the kernel component, the mount.cifs
guest
Although ignored by the kernel component, the mount.cifs
mount helper will not prompt the user for a password
if guest is specified on the mount options. If no
password is specified a null password will be used.
perm Client does permission checks (vfs_permission check of uid
perm
Client does permission checks (vfs_permission check of uid
and gid of the file against the mode and desired operation),
Note that this is in addition to the normal ACL check on the
target machine done by the server software.
Client permission checking is enabled by default.
noperm Client does not do permission checks. This can expose
noperm
Client does not do permission checks. This can expose
files on this mount to access by other users on the local
client system. It is typically only needed when the server
supports the CIFS Unix Extensions but the UIDs/GIDs on the
@@ -399,7 +461,8 @@ A partial list of the supported mount options follows:
Note that this does not affect the normal ACL check on the
target machine done by the server software (of the server
ACL against the user name provided at mount time).
serverino Use server's inode numbers instead of generating automatically
serverino
Use server's inode numbers instead of generating automatically
incrementing inode numbers on the client. Although this will
make it easier to spot hardlinked files (as they will have
the same inode numbers) and inode numbers may be persistent,
@@ -414,12 +477,14 @@ A partial list of the supported mount options follows:
under nfsd requires this mount option on the cifs mount.
This is now the default if server supports the
required network operation.
noserverino Client generates inode numbers (rather than using the actual one
noserverino
Client generates inode numbers (rather than using the actual one
from the server). These inode numbers will vary after
unmount or reboot which can confuse some applications,
but not all server filesystems support unique inode
numbers.
setuids If the CIFS Unix extensions are negotiated with the server
setuids
If the CIFS Unix extensions are negotiated with the server
the client will attempt to set the effective uid and gid of
the local process on newly created files, directories, and
devices (create, mkdir, mknod). If the CIFS Unix Extensions
@@ -427,8 +492,9 @@ A partial list of the supported mount options follows:
instead of using the default uid and gid specified on
the mount, cache the new file's uid and gid locally which means
that the uid for the file can change when the inode is
reloaded (or the user remounts the share).
nosetuids The client will not attempt to set the uid and gid on
reloaded (or the user remounts the share).
nosetuids
The client will not attempt to set the uid and gid on
on newly created files, directories, and devices (create,
mkdir, mknod) which will result in the server setting the
uid and gid to the default (usually the server uid of the
@@ -437,10 +503,12 @@ A partial list of the supported mount options follows:
Unix Extensions are not negotiated then the uid and gid for
new files will appear to be the uid (gid) of the mounter or the
uid (gid) parameter specified on the mount.
netbiosname When mounting to servers via port 139, specifies the RFC1001
netbiosname
When mounting to servers via port 139, specifies the RFC1001
source name to use to represent the client netbios machine
name when doing the RFC1001 netbios session initialize.
direct Do not do inode data caching on files opened on this mount.
direct
Do not do inode data caching on files opened on this mount.
This precludes mmapping files on this mount. In some cases
with fast networks and little or no caching benefits on the
client (e.g. when the application is doing large sequential
@@ -451,24 +519,33 @@ A partial list of the supported mount options follows:
if oplock (caching token) is granted and held. Note that
direct allows write operations larger than page size
to be sent to the server.
strictcache Use for switching on strict cache mode. In this mode the
strictcache
Use for switching on strict cache mode. In this mode the
client read from the cache all the time it has Oplock Level II,
otherwise - read from the server. All written data are stored
in the cache, but if the client doesn't have Exclusive Oplock,
it writes the data to the server.
rwpidforward Forward pid of a process who opened a file to any read or write
rwpidforward
Forward pid of a process who opened a file to any read or write
operation on that file. This prevent applications like WINE
from failing on read and write if we use mandatory brlock style.
acl Allow setfacl and getfacl to manage posix ACLs if server
acl
Allow setfacl and getfacl to manage posix ACLs if server
supports them. (default)
noacl Do not allow setfacl and getfacl calls on this mount
user_xattr Allow getting and setting user xattrs (those attributes whose
name begins with "user." or "os2.") as OS/2 EAs (extended
noacl
Do not allow setfacl and getfacl calls on this mount
user_xattr
Allow getting and setting user xattrs (those attributes whose
name begins with ``user.`` or ``os2.``) as OS/2 EAs (extended
attributes) to the server. This allows support of the
setfattr and getfattr utilities. (default)
nouser_xattr Do not allow getfattr/setfattr to get/set/list xattrs
mapchars Translate six of the seven reserved characters (not backslash)
nouser_xattr
Do not allow getfattr/setfattr to get/set/list xattrs
mapchars
Translate six of the seven reserved characters (not backslash)::
*?<>|:
to the remap range (above 0xF000), which also
allows the CIFS client to recognize files created with
such characters by Windows's POSIX emulation. This can
@@ -477,39 +554,47 @@ A partial list of the supported mount options follows:
whose names contain any of these seven characters).
This has no effect if the server does not support
Unicode on the wire.
nomapchars Do not translate any of these seven characters (default).
nocase Request case insensitive path name matching (case
nomapchars
Do not translate any of these seven characters (default).
nocase
Request case insensitive path name matching (case
sensitive is the default if the server supports it).
(mount option "ignorecase" is identical to "nocase")
posixpaths If CIFS Unix extensions are supported, attempt to
(mount option ``ignorecase`` is identical to ``nocase``)
posixpaths
If CIFS Unix extensions are supported, attempt to
negotiate posix path name support which allows certain
characters forbidden in typical CIFS filenames, without
requiring remapping. (default)
noposixpaths If CIFS Unix extensions are supported, do not request
noposixpaths
If CIFS Unix extensions are supported, do not request
posix path name support (this may cause servers to
reject creatingfile with certain reserved characters).
nounix Disable the CIFS Unix Extensions for this mount (tree
nounix
Disable the CIFS Unix Extensions for this mount (tree
connection). This is rarely needed, but it may be useful
in order to turn off multiple settings all at once (ie
posix acls, posix locks, posix paths, symlink support
and retrieving uids/gids/mode from the server) or to
work around a bug in server which implement the Unix
Extensions.
nobrl Do not send byte range lock requests to the server.
nobrl
Do not send byte range lock requests to the server.
This is necessary for certain applications that break
with cifs style mandatory byte range locks (and most
cifs servers do not yet support requesting advisory
byte range locks).
forcemandatorylock Even if the server supports posix (advisory) byte range
forcemandatorylock
Even if the server supports posix (advisory) byte range
locking, send only mandatory lock requests. For some
(presumably rare) applications, originally coded for
DOS/Windows, which require Windows style mandatory byte range
locking, they may be able to take advantage of this option,
forcing the cifs client to only send mandatory locks
even if the cifs server would support posix advisory locks.
"forcemand" is accepted as a shorter form of this mount
``forcemand`` is accepted as a shorter form of this mount
option.
nostrictsync If this mount option is set, when an application does an
nostrictsync
If this mount option is set, when an application does an
fsync call then the cifs client does not send an SMB Flush
to the server (to force the server to write all dirty data
for this file immediately to disk), although cifs still sends
@@ -522,41 +607,50 @@ A partial list of the supported mount options follows:
crash. If this mount option is not set, by default cifs will
send an SMB flush request (and wait for a response) on every
fsync call.
nodfs Disable DFS (global name space support) even if the
nodfs
Disable DFS (global name space support) even if the
server claims to support it. This can help work around
a problem with parsing of DFS paths with Samba server
versions 3.0.24 and 3.0.25.
remount remount the share (often used to change from ro to rw mounts
or vice versa)
cifsacl Report mode bits (e.g. on stat) based on the Windows ACL for
the file. (EXPERIMENTAL)
servern Specify the server 's netbios name (RFC1001 name) to use
remount
remount the share (often used to change from ro to rw mounts
or vice versa)
cifsacl
Report mode bits (e.g. on stat) based on the Windows ACL for
the file. (EXPERIMENTAL)
servern
Specify the server 's netbios name (RFC1001 name) to use
when attempting to setup a session to the server.
This is needed for mounting to some older servers (such
as OS/2 or Windows 98 and Windows ME) since they do not
support a default server name. A server name can be up
to 15 characters long and is usually uppercased.
sfu When the CIFS Unix Extensions are not negotiated, attempt to
sfu
When the CIFS Unix Extensions are not negotiated, attempt to
create device files and fifos in a format compatible with
Services for Unix (SFU). In addition retrieve bits 10-12
of the mode via the SETFILEBITS extended attribute (as
SFU does). In the future the bottom 9 bits of the
mode also will be emulated using queries of the security
descriptor (ACL).
mfsymlinks Enable support for Minshall+French symlinks
mfsymlinks
Enable support for Minshall+French symlinks
(see http://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks)
This option is ignored when specified together with the
'sfu' option. Minshall+French symlinks are used even if
the server supports the CIFS Unix Extensions.
sign Must use packet signing (helps avoid unwanted data modification
sign
Must use packet signing (helps avoid unwanted data modification
by intermediate systems in the route). Note that signing
does not work with lanman or plaintext authentication.
seal Must seal (encrypt) all data on this mounted share before
seal
Must seal (encrypt) all data on this mounted share before
sending on the network. Requires support for Unix Extensions.
Note that this differs from the sign mount option in that it
causes encryption of data sent over this mounted share but other
shares mounted to the same server are unaffected.
locallease This option is rarely needed. Fcntl F_SETLEASE is
locallease
This option is rarely needed. Fcntl F_SETLEASE is
used by some applications such as Samba and NFSv4 server to
check to see whether a file is cacheable. CIFS has no way
to explicitly request a lease, but can check whether a file
@@ -569,50 +663,72 @@ A partial list of the supported mount options follows:
will allow the cifs client to check for leases (only) locally
for files which are not oplocked instead of denying leases
in that case. (EXPERIMENTAL)
sec Security mode. Allowed values are:
none attempt to connection as a null user (no name)
krb5 Use Kerberos version 5 authentication
krb5i Use Kerberos authentication and packet signing
ntlm Use NTLM password hashing (default)
ntlmi Use NTLM password hashing with signing (if
sec
Security mode. Allowed values are:
none
attempt to connection as a null user (no name)
krb5
Use Kerberos version 5 authentication
krb5i
Use Kerberos authentication and packet signing
ntlm
Use NTLM password hashing (default)
ntlmi
Use NTLM password hashing with signing (if
/proc/fs/cifs/PacketSigningEnabled on or if
server requires signing also can be the default)
ntlmv2 Use NTLMv2 password hashing
ntlmv2i Use NTLMv2 password hashing with packet signing
lanman (if configured in kernel config) use older
ntlmv2
Use NTLMv2 password hashing
ntlmv2i
Use NTLMv2 password hashing with packet signing
lanman
(if configured in kernel config) use older
lanman hash
hard Retry file operations if server is not responding
soft Limit retries to unresponsive servers (usually only
hard
Retry file operations if server is not responding
soft
Limit retries to unresponsive servers (usually only
one retry) before returning an error. (default)
The mount.cifs mount helper also accepts a few mount options before -o
including:
=============== ===============================================================
-S take password from stdin (equivalent to setting the environment
variable "PASSWD_FD=0"
variable ``PASSWD_FD=0``
-V print mount.cifs version
-? display simple usage information
=============== ===============================================================
With most 2.6 kernel versions of modutils, the version of the cifs kernel
module can be displayed via modinfo.
Misc /proc/fs/cifs Flags and Debug Info
=======================================
Informational pseudo-files:
======================= =======================================================
DebugData Displays information about active CIFS sessions and
shares, features enabled as well as the cifs.ko
version.
Stats Lists summary resource usage information as well as per
share statistics.
======================= =======================================================
Configuration pseudo-files:
======================= =======================================================
SecurityFlags Flags which control security negotiation and
also packet signing. Authentication (may/must)
flags (e.g. for NTLM and/or NTLMv2) may be combined with
the signing flags. Specifying two different password
hashing mechanisms (as "must use") on the other hand
does not make much sense. Default flags are
does not make much sense. Default flags are::
0x07007
(NTLM, NTLMv2 and packet signing allowed). The maximum
allowable flags if you want to allow mounts to servers
using weaker password hashes is 0x37037 (lanman,
@@ -626,21 +742,21 @@ SecurityFlags Flags which control security negotiation and
laintext passwords using the older lanman dialect
form of the session setup SMB. (e.g. for authentication
using plain text passwords, set the SecurityFlags
to 0x30030):
to 0x30030)::
may use packet signing 0x00001
must use packet signing 0x01001
may use NTLM (most common password hash) 0x00002
must use NTLM 0x02002
may use NTLMv2 0x00004
must use NTLMv2 0x04004
may use Kerberos security 0x00008
must use Kerberos 0x08008
may use lanman (weak) password hash 0x00010
must use lanman password hash 0x10010
may use plaintext passwords 0x00020
must use plaintext passwords 0x20020
(reserved for future packet encryption) 0x00040
may use packet signing 0x00001
must use packet signing 0x01001
may use NTLM (most common password hash) 0x00002
must use NTLM 0x02002
may use NTLMv2 0x00004
must use NTLMv2 0x04004
may use Kerberos security 0x00008
must use Kerberos 0x08008
may use lanman (weak) password hash 0x00010
must use lanman password hash 0x10010
may use plaintext passwords 0x00020
must use plaintext passwords 0x20020
(reserved for future packet encryption) 0x00040
cifsFYI If set to non-zero value, additional debug information
will be logged to the system error log. This field
@@ -650,13 +766,18 @@ cifsFYI If set to non-zero value, additional debug information
Some debugging statements are not compiled into the
cifs kernel unless CONFIG_CIFS_DEBUG2 is enabled in the
kernel configuration. cifsFYI may be set to one or
nore of the following flags (7 sets them all):
log cifs informational messages 0x01
log return codes from cifs entry points 0x02
log slow responses (ie which take longer than 1 second)
CONFIG_CIFS_STATS2 must be enabled in .config 0x04
nore of the following flags (7 sets them all)::
+-----------------------------------------------+------+
| log cifs informational messages | 0x01 |
+-----------------------------------------------+------+
| log return codes from cifs entry points | 0x02 |
+-----------------------------------------------+------+
| log slow responses | 0x04 |
| (ie which take longer than 1 second) | |
| | |
| CONFIG_CIFS_STATS2 must be enabled in .config | |
+-----------------------------------------------+------+
traceSMB If set to one, debug information is logged to the
system error log with the start of smb requests
@@ -674,11 +795,12 @@ LinuxExtensionsEnabled If set to one then the client will attempt to
support and want to map the uid and gid fields
to values supplied at mount (rather than the
actual values, then set this to zero. (default 1)
======================= =======================================================
These experimental features and tracing can be enabled by changing flags in
/proc/fs/cifs (after the cifs module has been installed or built into the
kernel, e.g. insmod cifs). To enable a feature set it to 1 e.g. to enable
tracing to the kernel message log type:
tracing to the kernel message log type::
echo 7 > /proc/fs/cifs/cifsFYI
@@ -688,7 +810,7 @@ SMB return codes while 4 enables logging of requests that take longer
than one second to complete (except for byte range lock requests).
Setting it to 4 requires CONFIG_CIFS_STATS2 to be set in kernel configuration
(.config). Setting it to seven enables all three. Finally, tracing
the start of smb requests and responses can be enabled via:
the start of smb requests and responses can be enabled via::
echo 1 > /proc/fs/cifs/traceSMB
@@ -700,10 +822,10 @@ server) SMB3 (or cifs) requests grouped by request type (read, write, close etc.
Also recorded is the total bytes read and bytes written to the server for
that share. Note that due to client caching effects this can be less than the
number of bytes read and written by the application running on the client.
Statistics can be reset to zero by "echo 0 > /proc/fs/cifs/Stats" which may be
Statistics can be reset to zero by ``echo 0 > /proc/fs/cifs/Stats`` which may be
useful if comparing performance of two different scenarios.
Also note that "cat /proc/fs/cifs/DebugData" will display information about
Also note that ``cat /proc/fs/cifs/DebugData`` will display information about
the active sessions and the shares that are mounted.
Enabling Kerberos (extended security) works but requires version 1.2 or later
@@ -725,19 +847,23 @@ space to ease network configuration and improve reliability.
To use cifs Kerberos and DFS support, the Linux keyutils package should be
installed and something like the following lines should be added to the
/etc/request-key.conf file:
/etc/request-key.conf file::
create cifs.spnego * * /usr/local/sbin/cifs.upcall %k
create dns_resolver * * /usr/local/sbin/cifs.upcall %k
create cifs.spnego * * /usr/local/sbin/cifs.upcall %k
create dns_resolver * * /usr/local/sbin/cifs.upcall %k
CIFS kernel module parameters
=============================
These module parameters can be specified or modified either during the time of
module loading or during the runtime by using the interface
module loading or during the runtime by using the interface::
/proc/module/cifs/parameters/<param>
i.e. echo "value" > /sys/module/cifs/parameters/<param>
i.e.::
1. enable_oplocks - Enable or disable oplocks. Oplocks are enabled by default.
[Y/y/1]. To disable use any of [N/n/0].
echo "value" > /sys/module/cifs/parameters/<param>
================= ==========================================================
1. enable_oplocks Enable or disable oplocks. Oplocks are enabled by default.
[Y/y/1]. To disable use any of [N/n/0].
================= ==========================================================

0
Documentation/filesystems/cifs/winucase_convert.pl → Documentation/admin-guide/cifs/winucase_convert.pl
View File

11
Documentation/admin-guide/devices.txt
View File

@@ -1647,8 +1647,17 @@
0 = /dev/comedi0 First comedi device
1 = /dev/comedi1 Second comedi device
...
47 = /dev/comedi47 48th comedi device
See http://stm.lbl.gov/comedi.
Minors 48 to 255 are reserved for comedi subdevices with
pathnames of the form "/dev/comediX_subdY", where "X" is the
minor number of the associated comedi device and "Y" is the
subdevice number. These subdevice minors are assigned
dynamically, so there is no fixed mapping from subdevice
pathnames to minor numbers.
See http://www.comedi.org/ for information about the Comedi
project.
98 block User-mode virtual block device
0 = /dev/ubda First user-mode block device

5
Documentation/admin-guide/index.rst
View File

@@ -77,7 +77,10 @@ configure specific aspects of kernel behavior to your liking.
blockdev/index
ext4
binderfs
cifs/index
xfs
jfs
ufs
pm/index
thunderbolt
LSM/index
@@ -98,6 +101,7 @@ configure specific aspects of kernel behavior to your liking.
iostats
kernel-per-CPU-kthreads
laptops/index
auxdisplay/index
lcd-panel-cgram
ldm
lockup-watchdogs
@@ -105,6 +109,7 @@ configure specific aspects of kernel behavior to your liking.
pnp
rtc
svga
wimax/index
video-output
.. only:: subproject and html

44
Documentation/filesystems/jfs.txt → Documentation/admin-guide/jfs.rst
View File

@@ -1,45 +1,59 @@
===========================================
IBM's Journaled File System (JFS) for Linux
===========================================
JFS Homepage: http://jfs.sourceforge.net/
The following mount options are supported:
(*) == default
iocharset=name Character set to use for converting from Unicode to
iocharset=name
Character set to use for converting from Unicode to
ASCII. The default is to do no conversion. Use
iocharset=utf8 for UTF-8 translations. This requires
CONFIG_NLS_UTF8 to be set in the kernel .config file.
iocharset=none specifies the default behavior explicitly.
resize=value Resize the volume to <value> blocks. JFS only supports
resize=value
Resize the volume to <value> blocks. JFS only supports
growing a volume, not shrinking it. This option is only
valid during a remount, when the volume is mounted
read-write. The resize keyword with no value will grow
the volume to the full size of the partition.
nointegrity Do not write to the journal. The primary use of this option
nointegrity
Do not write to the journal. The primary use of this option
is to allow for higher performance when restoring a volume
from backup media. The integrity of the volume is not
guaranteed if the system abnormally abends.
integrity(*) Commit metadata changes to the journal. Use this option to
integrity(*)
Commit metadata changes to the journal. Use this option to
remount a volume where the nointegrity option was
previously specified in order to restore normal behavior.
errors=continue Keep going on a filesystem error.
errors=remount-ro(*) Remount the filesystem read-only on an error.
errors=panic Panic and halt the machine if an error occurs.
errors=continue
Keep going on a filesystem error.
errors=remount-ro(*)
Remount the filesystem read-only on an error.
errors=panic
Panic and halt the machine if an error occurs.
uid=value Override on-disk uid with specified value
gid=value Override on-disk gid with specified value
umask=value Override on-disk umask with specified octal value. For
directories, the execute bit will be set if the corresponding
uid=value
Override on-disk uid with specified value
gid=value
Override on-disk gid with specified value
umask=value
Override on-disk umask with specified octal value. For
directories, the execute bit will be set if the corresponding
read bit is set.
discard=minlen This enables/disables the use of discard/TRIM commands.
discard The discard/TRIM commands are sent to the underlying
nodiscard(*) block device when blocks are freed. This is useful for SSD
devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
discard=minlen, discard/nodiscard(*)
This enables/disables the use of discard/TRIM commands.
The discard/TRIM commands are sent to the underlying
block device when blocks are freed. This is useful for SSD
devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
command is also available together with the nodiscard option.
The value of minlen specifies the minimum blockcount, when
a TRIM command to the block device is considered useful.

42
Documentation/admin-guide/kernel-parameters.txt
View File

@@ -1044,6 +1044,10 @@
specified address. The serial port must already be
setup and configured. Options are not yet supported.
sbi
Use RISC-V SBI (Supervisor Binary Interface) for early
console.
smh Use ARM semihosting calls for early console.
s3c2410,<addr>
@@ -1090,6 +1094,12 @@
the framebuffer, pass the 'ram' option so that it is
mapped with the correct attributes.
linflex,<addr>
Use early console provided by Freescale LinFlex UART
serial driver for NXP S32V234 SoCs. A valid base
address must be provided, and the serial port must
already be setup and configured.
earlyprintk= [X86,SH,ARM,M68k,S390]
earlyprintk=vga
earlyprintk=sclp
@@ -1197,12 +1207,6 @@
See comment before function elanfreq_setup() in
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
elevator= [IOSCHED]
Format: { "mq-deadline" | "kyber" | "bfq" }
See Documentation/block/deadline-iosched.rst,
Documentation/block/kyber-iosched.rst and
Documentation/block/bfq-iosched.rst for details.
elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
Specifies physical address of start of kernel core
image elf header and optionally the size. Generally
@@ -1732,6 +1736,11 @@
Note that using this option lowers the security
provided by tboot because it makes the system
vulnerable to DMA attacks.
nobounce [Default off]
Disable bounce buffer for unstrusted devices such as
the Thunderbolt devices. This will treat the untrusted
devices as the trusted ones, hence might expose security
risks of DMA attacks.
intel_idle.max_cstate= [KNL,HW,ACPI,X86]
0 disables intel_idle and fall back on acpi_idle.
@@ -1811,7 +1820,7 @@
synchronously.
iommu.passthrough=
[ARM64] Configure DMA to bypass the IOMMU by default.
[ARM64, X86] Configure DMA to bypass the IOMMU by default.
Format: { "0" | "1" }
0 - Use IOMMU translation for DMA.
1 - Bypass the IOMMU for DMA.
@@ -2373,7 +2382,7 @@
machvec= [IA-64] Force the use of a particular machine-vector
(machvec) in a generic kernel.
Example: machvec=hpzx1_swiotlb
Example: machvec=hpzx1
machtype= [Loongson] Share the same kernel image file between different
yeeloong laptop.
@@ -3837,12 +3846,13 @@
RCU_BOOST is not set, valid values are 0-99 and
the default is zero (non-realtime operation).
rcutree.rcu_nocb_leader_stride= [KNL]
Set the number of NOCB kthread groups, which
defaults to the square root of the number of
CPUs. Larger numbers reduces the wakeup overhead
on the per-CPU grace-period kthreads, but increases
that same overhead on each group's leader.
rcutree.rcu_nocb_gp_stride= [KNL]
Set the number of NOCB callback kthreads in
each group, which defaults to the square root
of the number of CPUs. Larger numbers reduce
the wakeup overhead on the global grace-period
kthread, but increases that same overhead on
each group's NOCB grace-period kthread.
rcutree.qhimark= [KNL]
Set threshold of queued RCU callbacks beyond which
@@ -4047,6 +4057,10 @@
rcutorture.verbose= [KNL]
Enable additional printk() statements.
rcupdate.rcu_cpu_stall_ftrace_dump= [KNL]
Dump ftrace buffer after reporting RCU CPU
stall warning.
rcupdate.rcu_cpu_stall_suppress= [KNL]
Suppress RCU CPU stall warning messages.

8
Documentation/admin-guide/kernel-per-CPU-kthreads.rst
View File

@@ -274,9 +274,7 @@ To reduce its OS jitter, do any of the following:
(based on an earlier one from Gilad Ben-Yossef) that
reduces or even eliminates vmstat overhead for some
workloads at https://lkml.org/lkml/2013/9/4/379.
e. Boot with "elevator=noop" to avoid workqueue use by
the block layer.
f. If running on high-end powerpc servers, build with
e. If running on high-end powerpc servers, build with
CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS
daemon from running on each CPU every second or so.
(This will require editing Kconfig files and will defeat
@@ -284,12 +282,12 @@ To reduce its OS jitter, do any of the following:
due to the rtas_event_scan() function.
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
g. If running on Cell Processor, build your kernel with
f. If running on Cell Processor, build your kernel with
CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
spu_gov_work().
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
h. If running on PowerMAC, build your kernel with
g. If running on PowerMAC, build your kernel with
CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
avoiding OS jitter from rackmeter_do_timer().

23
Documentation/admin-guide/laptops/thinkpad-acpi.rst
View File

@@ -49,6 +49,7 @@ detailed description):
- Fan control and monitoring: fan speed, fan enable/disable
- WAN enable and disable
- UWB enable and disable
- LCD Shadow (PrivacyGuard) enable and disable
A compatibility table by model and feature is maintained on the web
site, http://ibm-acpi.sf.net/. I appreciate any success or failure
@@ -1409,6 +1410,28 @@ Sysfs notes
Documentation/driver-api/rfkill.rst for details.
LCD Shadow control
------------------
procfs: /proc/acpi/ibm/lcdshadow
Some newer T480s and T490s ThinkPads provide a feature called
PrivacyGuard. By turning this feature on, the usable vertical and
horizontal viewing angles of the LCD can be limited (as if some privacy
screen was applied manually in front of the display).
procfs notes
^^^^^^^^^^^^
The available commands are::
echo '0' >/proc/acpi/ibm/lcdshadow
echo '1' >/proc/acpi/ibm/lcdshadow
The first command ensures the best viewing angle and the latter one turns
on the feature, restricting the viewing angles.
EXPERIMENTAL: UWB
-----------------

52
Documentation/admin-guide/perf/imx-ddr.rst Normal file
View File

@@ -0,0 +1,52 @@
=====================================================
Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
=====================================================
There are no performance counters inside the DRAM controller, so performance
signals are brought out to the edge of the controller where a set of 4 x 32 bit
counters is implemented. This is controlled by the CSV modes programed in counter
control register which causes a large number of PERF signals to be generated.
Selection of the value for each counter is done via the config registers. There
is one register for each counter. Counter 0 is special in that it always counts
“time” and when expired causes a lock on itself and the other counters and an
interrupt is raised. If any other counter overflows, it continues counting, and
no interrupt is raised.
The "format" directory describes format of the config (event ID) and config1
(AXI filtering) fields of the perf_event_attr structure, see /sys/bus/event_source/
devices/imx8_ddr0/format/. The "events" directory describes the events types
hardware supported that can be used with perf tool, see /sys/bus/event_source/
devices/imx8_ddr0/events/.
e.g.::
perf stat -a -e imx8_ddr0/cycles/ cmd
perf stat -a -e imx8_ddr0/read/,imx8_ddr0/write/ cmd
AXI filtering is only used by CSV modes 0x41 (axid-read) and 0x42 (axid-write)
to count reading or writing matches filter setting. Filter setting is various
from different DRAM controller implementations, which is distinguished by quirks
in the driver.
* With DDR_CAP_AXI_ID_FILTER quirk.
Filter is defined with two configuration parts:
--AXI_ID defines AxID matching value.
--AXI_MASKING defines which bits of AxID are meaningful for the matching.
0：corresponding bit is masked.
1: corresponding bit is not masked, i.e. used to do the matching.
AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
When non-masked bits are matching corresponding AXI_ID bits then counter is
incremented. Perf counter is incremented if
AxID && AXI_MASKING == AXI_ID && AXI_MASKING
This filter doesn't support filter different AXI ID for axid-read and axid-write
event at the same time as this filter is shared between counters.
e.g.::
perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
it will be reverted in driver automatically. so that the user can just specify
axi_id to monitor a specific id, rather than having to specify axi_mask.
e.g.::
perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12

20
Documentation/admin-guide/sysrq.rst
View File

@@ -171,22 +171,20 @@ It seems others find it useful as (System Attention Key) which is
useful when you want to exit a program that will not let you switch consoles.
(For example, X or a svgalib program.)
``reboot(b)`` is good when you're unable to shut down. But you should also
``sync(s)`` and ``umount(u)`` first.
``reboot(b)`` is good when you're unable to shut down, it is an equivalent
of pressing the "reset" button.
``crash(c)`` can be used to manually trigger a crashdump when the system is hung.
Note that this just triggers a crash if there is no dump mechanism available.
``sync(s)`` is great when your system is locked up, it allows you to sync your
disks and will certainly lessen the chance of data loss and fscking. Note
that the sync hasn't taken place until you see the "OK" and "Done" appear
on the screen. (If the kernel is really in strife, you may not ever get the
OK or Done message...)
``sync(s)`` is handy before yanking removable medium or after using a rescue
shell that provides no graceful shutdown -- it will ensure your data is
safely written to the disk. Note that the sync hasn't taken place until you see
the "OK" and "Done" appear on the screen.
``umount(u)`` is basically useful in the same ways as ``sync(s)``. I generally
``sync(s)``, ``umount(u)``, then ``reboot(b)`` when my system locks. It's saved
me many a fsck. Again, the unmount (remount read-only) hasn't taken place until
you see the "OK" and "Done" message appear on the screen.
``umount(u)`` can be used to mark filesystems as properly unmounted. From the
running system's point of view, they will be remounted read-only. The remount
isn't complete until you see the "OK" and "Done" message appear on the screen.
The loglevels ``0``-``9`` are useful when your console is being flooded with
kernel messages you do not want to see. Selecting ``0`` will prevent all but

34
Documentation/filesystems/ufs.txt → Documentation/admin-guide/ufs.rst
View File

@@ -1,10 +1,11 @@
USING UFS
=========
Using UFS
=========
mount -t ufs -o ufstype=type_of_ufs device dir
UFS OPTIONS
UFS Options
===========
ufstype=type_of_ufs
@@ -14,24 +15,31 @@ ufstype=type_of_ufs
type of ufs automatically. That's why user must specify type of
ufs manually by mount option ufstype. Possible values are:
old old format of ufs
old
old format of ufs
default value, supported as read-only
44bsd used in FreeBSD, NetBSD, OpenBSD
44bsd
used in FreeBSD, NetBSD, OpenBSD
supported as read-write
ufs2 used in FreeBSD 5.x
ufs2
used in FreeBSD 5.x
supported as read-write
5xbsd synonym for ufs2
5xbsd
synonym for ufs2
sun used in SunOS (Solaris)
sun
used in SunOS (Solaris)
supported as read-write
sunx86 used in SunOS for Intel (Solarisx86)
sunx86
used in SunOS for Intel (Solarisx86)
supported as read-write
hp used in HP-UX
hp
used in HP-UX
supported as read-only
nextstep
@@ -47,14 +55,14 @@ ufstype=type_of_ufs
supported as read-only
POSSIBLE PROBLEMS
=================
Possible Problems
-----------------
See next section, if you have any.
BUG REPORTS
===========
Bug Reports
-----------
Any ufs bug report you can send to daniel.pirkl@email.cz or
to dushistov@mail.ru (do not send partition tables bug reports).

145
Documentation/wimax/README.i2400m → Documentation/admin-guide/wimax/i2400m.rst
View File

@@ -1,18 +1,23 @@
.. include:: <isonum.txt>
Driver for the Intel Wireless Wimax Connection 2400m
====================================================
Driver for the Intel Wireless Wimax Connection 2400m
====================================================
(C) 2008 Intel Corporation < linux-wimax@intel.com >
:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com >
This provides a driver for the Intel Wireless WiMAX Connection 2400m
and a basic Linux kernel WiMAX stack.
1. Requirements
===============
* Linux installation with Linux kernel 2.6.22 or newer (if building
from a separate tree)
* Intel i2400m Echo Peak or Baxter Peak; this includes the Intel
Wireless WiMAX/WiFi Link 5x50 series.
* build tools:
+ Linux kernel development package for the target kernel; to
build against your currently running kernel, you need to have
the kernel development package corresponding to the running
@@ -22,8 +27,10 @@
+ GNU C Compiler, make
2. Compilation and installation
===============================
2.1. Compilation of the drivers included in the kernel
------------------------------------------------------
Configure the kernel; to enable the WiMAX drivers select Drivers >
Networking Drivers > WiMAX device support. Enable all of them as
@@ -36,37 +43,39 @@
Compile and install your kernel as usual.
2.2. Compilation of the drivers distributed as an standalone module
-------------------------------------------------------------------
To compile
To compile::
$ cd source/directory
$ make
$ cd source/directory
$ make
Once built you can load and unload using the provided load.sh script;
load.sh will load the modules, load.sh u will unload them.
To install in the default kernel directories (and enable auto loading
when the device is plugged):
when the device is plugged)::
$ make install
$ depmod -a
$ make install
$ depmod -a
If your kernel development files are located in a non standard
directory or if you want to build for a kernel that is not the
currently running one, set KDIR to the right location:
currently running one, set KDIR to the right location::
$ make KDIR=/path/to/kernel/dev/tree
$ make KDIR=/path/to/kernel/dev/tree
For more information, please contact linux-wimax@intel.com.
3. Installing the firmware
--------------------------
The firmware can be obtained from http://linuxwimax.org or might have
been supplied with your hardware.
It has to be installed in the target system:
*
$ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf
It has to be installed in the target system::
$ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf
* NOTE: if your firmware came in an .rpm or .deb file, just install
it as normal, with the rpm (rpm -i FIRMWARE.rpm) or dpkg
@@ -76,6 +85,7 @@ $ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf
with other types.
4. Design
=========
This package contains two major parts: a WiMAX kernel stack and a
driver for the Intel i2400m.
@@ -102,16 +112,17 @@ $ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf
API calls should be replaced with the target OS's.
5. Usage
========
To load the driver, follow the instructions in the install section;
once the driver is loaded, plug in the device (unless it is permanently
plugged in). The driver will enumerate the device, upload the firmware
and output messages in the kernel log (dmesg, /var/log/messages or
/var/log/kern.log) such as:
/var/log/kern.log) such as::
...
i2400m_usb 5-4:1.0: firmware interface version 8.0.0
i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready
...
i2400m_usb 5-4:1.0: firmware interface version 8.0.0
i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready
At this point the device is ready to work.
@@ -120,38 +131,42 @@ i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready
on how to scan, connect and disconnect.
5.1. Module parameters
----------------------
Module parameters can be set at kernel or module load time or by
echoing values:
echoing values::
$ echo VALUE > /sys/module/MODULENAME/parameters/PARAMETERNAME
$ echo VALUE > /sys/module/MODULENAME/parameters/PARAMETERNAME
To make changes permanent, for example, for the i2400m module, you can
also create a file named /etc/modprobe.d/i2400m containing:
also create a file named /etc/modprobe.d/i2400m containing::
options i2400m idle_mode_disabled=1
options i2400m idle_mode_disabled=1
To find which parameters are supported by a module, run:
To find which parameters are supported by a module, run::
$ modinfo path/to/module.ko
$ modinfo path/to/module.ko
During kernel bootup (if the driver is linked in the kernel), specify
the following to the kernel command line:
the following to the kernel command line::
i2400m.PARAMETER=VALUE
i2400m.PARAMETER=VALUE
5.1.1. i2400m: idle_mode_disabled
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The i2400m module supports a parameter to disable idle mode. This
parameter, once set, will take effect only when the device is
reinitialized by the driver (eg: following a reset or a reconnect).
5.2. Debug operations: debugfs entries
--------------------------------------
The driver will register debugfs entries that allow the user to tweak
debug settings. There are three main container directories where
entries are placed, which correspond to the three blocks a i2400m WiMAX
driver has:
* /sys/kernel/debug/wimax:DEVNAME/ for the generic WiMAX stack
controls
* /sys/kernel/debug/wimax:DEVNAME/i2400m for the i2400m generic
@@ -163,52 +178,55 @@ i2400m.PARAMETER=VALUE
/sys/kernel/debug, those paths will change.
5.2.1. Increasing debug output
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The files named *dl_* indicate knobs for controlling the debug output
of different submodules:
*
# find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\*
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_tx
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_rx
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_notif
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_fw
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_usb
/sys/kernel/debug/wimax:wmx0/i2400m/dl_tx
/sys/kernel/debug/wimax:wmx0/i2400m/dl_rx
/sys/kernel/debug/wimax:wmx0/i2400m/dl_rfkill
/sys/kernel/debug/wimax:wmx0/i2400m/dl_netdev
/sys/kernel/debug/wimax:wmx0/i2400m/dl_fw
/sys/kernel/debug/wimax:wmx0/i2400m/dl_debugfs
/sys/kernel/debug/wimax:wmx0/i2400m/dl_driver
/sys/kernel/debug/wimax:wmx0/i2400m/dl_control
/sys/kernel/debug/wimax:wmx0/wimax_dl_stack
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg
/sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
/sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs
of different submodules::
# find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\*
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_tx
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_rx
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_notif
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_fw
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_usb
/sys/kernel/debug/wimax:wmx0/i2400m/dl_tx
/sys/kernel/debug/wimax:wmx0/i2400m/dl_rx
/sys/kernel/debug/wimax:wmx0/i2400m/dl_rfkill
/sys/kernel/debug/wimax:wmx0/i2400m/dl_netdev
/sys/kernel/debug/wimax:wmx0/i2400m/dl_fw
/sys/kernel/debug/wimax:wmx0/i2400m/dl_debugfs
/sys/kernel/debug/wimax:wmx0/i2400m/dl_driver
/sys/kernel/debug/wimax:wmx0/i2400m/dl_control
/sys/kernel/debug/wimax:wmx0/wimax_dl_stack
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg
/sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
/sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs
By reading the file you can obtain the current value of said debug
level; by writing to it, you can set it.
To increase the debug level of, for example, the i2400m's generic TX
engine, just write:
engine, just write::
$ echo 3 > /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx
$ echo 3 > /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx
Increasing numbers yield increasing debug information; for details of
what is printed and the available levels, check the source. The code
uses 0 for disabled and increasing values until 8.
5.2.2. RX and TX statistics
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The i2400m/rx_stats and i2400m/tx_stats provide statistics about the
data reception/delivery from the device:
data reception/delivery from the device::
$ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats
45 1 3 34 3104 48 480
$ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats
45 1 3 34 3104 48 480
The numbers reported are:
The numbers reported are
* packets/RX-buffer: total, min, max
* RX-buffers: total RX buffers received, accumulated RX buffer size
in bytes, min size received, max size received
@@ -216,9 +234,9 @@ $ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats
Thus, to find the average buffer size received, divide accumulated
RX-buffer / total RX-buffers.
To clear the statistics back to 0, write anything to the rx_stats file:
To clear the statistics back to 0, write anything to the rx_stats file::
$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats
$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats
Likewise for TX.
@@ -227,14 +245,16 @@ $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats
to the host. See drivers/net/wimax/i2400m/tx.c.
5.2.3. Tracing messages received from user space
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To echo messages received from user space into the trace pipe that the
i2400m driver creates, set the debug file i2400m/trace_msg_from_user to
1:
*
$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user
1::
$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user
5.2.4. Performing a device reset
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By writing a 0, a 1 or a 2 to the file
/sys/kernel/debug/wimax:wmx0/reset, the driver performs a warm (without
@@ -242,18 +262,21 @@ $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user
(bus specific) reset on the device.
5.2.5. Asking the device to enter power saving mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By writing any value to the /sys/kernel/debug/wimax:wmx0 file, the
device will attempt to enter power saving mode.
6. Troubleshooting
==================
6.1. Driver complains about 'i2400m-fw-usb-1.2.sbcf: request failed'
6.1. Driver complains about ``i2400m-fw-usb-1.2.sbcf: request failed``
----------------------------------------------------------------------
If upon connecting the device, the following is output in the kernel
log:
log::
i2400m_usb 5-4:1.0: fw i2400m-fw-usb-1.3.sbcf: request failed: -2
i2400m_usb 5-4:1.0: fw i2400m-fw-usb-1.3.sbcf: request failed: -2
This means that the driver cannot locate the firmware file named
/lib/firmware/i2400m-fw-usb-1.2.sbcf. Check that the file is present in

19
Documentation/admin-guide/wimax/index.rst Normal file
View File

@@ -0,0 +1,19 @@
.. SPDX-License-Identifier: GPL-2.0
===============
WiMAX subsystem
===============
.. toctree::
:maxdepth: 2
wimax
i2400m
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

36
Documentation/wimax/README.wimax → Documentation/admin-guide/wimax/wimax.rst
View File

@@ -1,12 +1,16 @@
.. include:: <isonum.txt>
Linux kernel WiMAX stack
========================
Linux kernel WiMAX stack
========================
(C) 2008 Intel Corporation < linux-wimax@intel.com >
:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com >
This provides a basic Linux kernel WiMAX stack to provide a common
control API for WiMAX devices, usable from kernel and user space.
1. Design
=========
The WiMAX stack is designed to provide for common WiMAX control
services to current and future WiMAX devices from any vendor.
@@ -31,6 +35,7 @@
include/linux/wimax.h.
2. Usage
========
For usage in a driver (registration, API, etc) please refer to the
instructions in the header file include/linux/wimax.h.
@@ -40,6 +45,7 @@
control.
2.1. Obtaining debug information: debugfs entries
-------------------------------------------------
The WiMAX stack is compiled, by default, with debug messages that can
be used to diagnose issues. By default, said messages are disabled.
@@ -52,20 +58,22 @@
create more subentries below it.
2.1.1. Increasing debug output
------------------------------
The files named *dl_* indicate knobs for controlling the debug output
of different submodules of the WiMAX stack:
*
# find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\*
/sys/kernel/debug/wimax:wmx0/wimax_dl_stack
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg
/sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
/sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs
/sys/kernel/debug/wimax:wmx0/.... # other driver specific files
of different submodules of the WiMAX stack::
NOTE: Of course, if debugfs is mounted in a directory other than
# find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\*
/sys/kernel/debug/wimax:wmx0/wimax_dl_stack
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg
/sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
/sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs
/sys/kernel/debug/wimax:wmx0/.... # other driver specific files
NOTE:
Of course, if debugfs is mounted in a directory other than
/sys/kernel/debug, those paths will change.
By reading the file you can obtain the current value of said debug
@@ -74,7 +82,7 @@
To increase the debug level of, for example, the id-table submodule,
just write:
$ echo 3 > /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
$ echo 3 > /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
Increasing numbers yield increasing debug information; for details of
what is printed and the available levels, check the source. The code

5
Documentation/admin-guide/xfs.rst
View File

@@ -337,11 +337,12 @@ None at present.
Removed Sysctls
===============
============================= =======
Name Removed
---- -------
============================= =======
fs.xfs.xfsbufd_centisec v4.0
fs.xfs.age_buffer_centisecs v4.0
============================= =======
Error handling
==============

51
Documentation/arm/sa1100/adsbitsy.rst
View File

@@ -1,51 +0,0 @@
===============================
ADS Bitsy Single Board Computer
===============================
(It is different from Bitsy(iPAQ) of Compaq)
For more details, contact Applied Data Systems or see
http://www.applieddata.net/products.html
The Linux support for this product has been provided by
Woojung Huh <whuh@applieddata.net>
Use 'make adsbitsy_config' before any 'make config'.
This will set up defaults for ADS Bitsy support.
The kernel zImage is linked to be loaded and executed at 0xc0400000.
Linux can be used with the ADS BootLoader that ships with the
newer rev boards. See their documentation on how to load Linux.
Supported peripherals
=====================
- SA1100 LCD frame buffer (8/16bpp...sort of)
- SA1111 USB Master
- SA1100 serial port
- pcmcia, compact flash
- touchscreen(ucb1200)
- console on LCD screen
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
To do
=====
- everything else! :-)
Notes
=====
- The flash on board is divided into 3 partitions.
You should be careful to use flash on board.
Its partition is different from GraphicsClient Plus and GraphicsMaster
- 16bpp mode requires a different cable than what ships with the board.
Contact ADS or look through the manual to wire your own. Currently,
if you compile with 16bit mode support and switch into a lower bpp
mode, the timing is off so the image is corrupted. This will be
fixed soon.
Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!

2
Documentation/arm/sa1100/assabet.rst
View File

@@ -14,7 +14,7 @@ Building the kernel
To build the kernel with current defaults::
make assabet_config
make assabet_defconfig
make oldconfig
make zImage

69
Documentation/arm/sa1100/brutus.rst
View File

@@ -1,69 +0,0 @@
======
Brutus
======
Brutus is an evaluation platform for the SA1100 manufactured by Intel.
For more details, see:
http://developer.intel.com
To compile for Brutus, you must issue the following commands::
make brutus_config
make config
[accept all the defaults]
make zImage
The resulting kernel will end up in linux/arch/arm/boot/zImage. This file
must be loaded at 0xc0008000 in Brutus's memory and execution started at
0xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon
entry.
But prior to execute the kernel, a ramdisk image must also be loaded in
memory. Use memory address 0xd8000000 for this. Note that the file
containing the (compressed) ramdisk image must not exceed 4 MB.
Typically, you'll need angelboot to load the kernel.
The following angelboot.opt file should be used::
base 0xc0008000
entry 0xc0008000
r0 0x00000000
r1 0x00000010
device /dev/ttyS0
options "9600 8N1"
baud 115200
otherfile ramdisk_img.gz
otherbase 0xd8000000
Then load the kernel and ramdisk with::
angelboot -f angelboot.opt zImage
The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your
host PC) is used by angel to load the kernel and ramdisk image. The serial
console is provided through the second Brutus serial port. To access it,
you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow
control.
Currently supported
===================
- RS232 serial ports
- audio output
- LCD screen
- keyboard
The actual Brutus support may not be complete without extra patches.
If such patches exist, they should be found from
ftp.netwinder.org/users/n/nico.
A full PCMCIA support is still missing, although it's possible to hack
some drivers in order to drive already inserted cards at boot time with
little modifications.
Any contribution is welcome.
Please send patches to nico@fluxnic.net
Have Fun !

25
Documentation/arm/sa1100/freebird.rst
View File

@@ -1,25 +0,0 @@
========
Freebird
========
Freebird-1.1 is produced by Legend(C), Inc.
`http://web.archive.org/web/*/http://www.legend.com.cn`
and software/linux maintained by Coventive(C), Inc.
(http://www.coventive.com)
Based on the Nicolas's strongarm kernel tree.
Maintainer:
Chester Kuo
- <chester@coventive.com>
- <chester@linux.org.tw>
Author:
- Tim wu <timwu@coventive.com>
- CIH <cih@coventive.com>
- Eric Peng <ericpeng@coventive.com>
- Jeff Lee <jeff_lee@coventive.com>
- Allen Cheng
- Tony Liu <tonyliu@coventive.com>

102
Documentation/arm/sa1100/graphicsclient.rst
View File

@@ -1,102 +0,0 @@
=============================================
ADS GraphicsClient Plus Single Board Computer
=============================================
For more details, contact Applied Data Systems or see
http://www.applieddata.net/products.html
The original Linux support for this product has been provided by
Nicolas Pitre <nico@fluxnic.net>. Continued development work by
Woojung Huh <whuh@applieddata.net>
It's currently possible to mount a root filesystem via NFS providing a
complete Linux environment. Otherwise a ramdisk image may be used. The
board supports MTD/JFFS, so you could also mount something on there.
Use 'make graphicsclient_config' before any 'make config'. This will set up
defaults for GraphicsClient Plus support.
The kernel zImage is linked to be loaded and executed at 0xc0200000.
Also the following registers should have the specified values upon entry::
r0 = 0
r1 = 29 (this is the GraphicsClient architecture number)
Linux can be used with the ADS BootLoader that ships with the
newer rev boards. See their documentation on how to load Linux.
Angel is not available for the GraphicsClient Plus AFAIK.
There is a board known as just the GraphicsClient that ADS used to
produce but has end of lifed. This code will not work on the older
board with the ADS bootloader, but should still work with Angel,
as outlined below. In any case, if you're planning on deploying
something en masse, you should probably get the newer board.
If using Angel on the older boards, here is a typical angel.opt option file
if the kernel is loaded through the Angel Debug Monitor::
base 0xc0200000
entry 0xc0200000
r0 0x00000000
r1 0x0000001d
device /dev/ttyS1
options "38400 8N1"
baud 115200
#otherfile ramdisk.gz
#otherbase 0xc0800000
exec minicom
Then the kernel (and ramdisk if otherfile/otherbase lines above are
uncommented) would be loaded with::
angelboot -f angelboot.opt zImage
Here it is assumed that the board is connected to ttyS1 on your PC
and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow
control by default.
If any other bootloader is used, ensure it accomplish the same, especially
for r0/r1 register values before jumping into the kernel.
Supported peripherals
=====================
- SA1100 LCD frame buffer (8/16bpp...sort of)
- on-board SMC 92C96 ethernet NIC
- SA1100 serial port
- flash memory access (MTD/JFFS)
- pcmcia
- touchscreen(ucb1200)
- ps/2 keyboard
- console on LCD screen
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
- Smart I/O (ADC, keypad, digital inputs, etc)
See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
and example user space code. ps/2 keybd is multiplexed through this driver
To do
=====
- UCB1200 audio with new ucb_generic layer
- everything else! :-)
Notes
=====
- The flash on board is divided into 3 partitions. mtd0 is where
the ADS boot ROM and zImage is stored. It's been marked as
read-only to keep you from blasting over the bootloader. :) mtd1 is
for the ramdisk.gz image. mtd2 is user flash space and can be
utilized for either JFFS or if you're feeling crazy, running ext2
on top of it. If you're not using the ADS bootloader, you're
welcome to blast over the mtd1 partition also.
- 16bpp mode requires a different cable than what ships with the board.
Contact ADS or look through the manual to wire your own. Currently,
if you compile with 16bit mode support and switch into a lower bpp
mode, the timing is off so the image is corrupted. This will be
fixed soon.
Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!

60
Documentation/arm/sa1100/graphicsmaster.rst
View File

@@ -1,60 +0,0 @@
========================================
ADS GraphicsMaster Single Board Computer
========================================
For more details, contact Applied Data Systems or see
http://www.applieddata.net/products.html
The original Linux support for this product has been provided by
Nicolas Pitre <nico@fluxnic.net>. Continued development work by
Woojung Huh <whuh@applieddata.net>
Use 'make graphicsmaster_config' before any 'make config'.
This will set up defaults for GraphicsMaster support.
The kernel zImage is linked to be loaded and executed at 0xc0400000.
Linux can be used with the ADS BootLoader that ships with the
newer rev boards. See their documentation on how to load Linux.
Supported peripherals
=====================
- SA1100 LCD frame buffer (8/16bpp...sort of)
- SA1111 USB Master
- on-board SMC 92C96 ethernet NIC
- SA1100 serial port
- flash memory access (MTD/JFFS)
- pcmcia, compact flash
- touchscreen(ucb1200)
- ps/2 keyboard
- console on LCD screen
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
- Smart I/O (ADC, keypad, digital inputs, etc)
See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
and example user space code. ps/2 keybd is multiplexed through this driver
To do
=====
- everything else! :-)
Notes
=====
- The flash on board is divided into 3 partitions. mtd0 is where
the zImage is stored. It's been marked as read-only to keep you
from blasting over the bootloader. :) mtd1 is
for the ramdisk.gz image. mtd2 is user flash space and can be
utilized for either JFFS or if you're feeling crazy, running ext2
on top of it. If you're not using the ADS bootloader, you're
welcome to blast over the mtd1 partition also.
- 16bpp mode requires a different cable than what ships with the board.
Contact ADS or look through the manual to wire your own. Currently,
if you compile with 16bit mode support and switch into a lower bpp
mode, the timing is off so the image is corrupted. This will be
fixed soon.
Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!

21
Documentation/arm/sa1100/huw_webpanel.rst
View File

@@ -1,21 +0,0 @@
=======================
Hoeft & Wessel Webpanel
=======================
The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG
If you want more information, please visit
http://www.hoeft-wessel.de
To build the kernel::
make huw_webpanel_config
make oldconfig
[accept all defaults]
make zImage
Mostly of the work is done by:
Roman Jordan jor@hoeft-wessel.de
Christoph Schulz schu@hoeft-wessel.de
2000/12/18/

12
Documentation/arm/sa1100/index.rst
View File

@@ -7,19 +7,7 @@ Intel StrongARM 1100
.. toctree::
:maxdepth: 1
adsbitsy
assabet
brutus
cerf
freebird
graphicsclient
graphicsmaster
huw_webpanel
itsy
lart
nanoengine
pangolin
pleb
serial_uart
tifon
yopy

47
Documentation/arm/sa1100/itsy.rst
View File

@@ -1,47 +0,0 @@
====
Itsy
====
Itsy is a research project done by the Western Research Lab, and Systems
Research Center in Palo Alto, CA. The Itsy project is one of several
research projects at Compaq that are related to pocket computing.
For more information, see:
http://www.hpl.hp.com/downloads/crl/itsy/
Notes on initial 2.4 Itsy support (8/27/2000) :
The port was done on an Itsy version 1.5 machine with a daughtercard with
64 Meg of DRAM and 32 Meg of Flash. The initial work includes support for
serial console (to see what you're doing). No other devices have been
enabled.
To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support.
Disable Flash and LCD support. and then do a make zImage.
Finally, you will need to cd to arch/arm/boot/tools and execute a make there
to build the params-itsy program used to boot the kernel.
In order to install the port of 2.4 to the itsy, You will need to set the
configuration parameters in the monitor as follows::
Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0
Make sure the start-routine address is set to 0x00060000.
Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the
flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000
("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000
("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on
handhelds.org.
The serial connection we established was at:
8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the
params-itsy program, and in the kernel itself. This can be changed, but
not easily. The monitor parameters are easily changed, the params program
setup is assembly outl's, and the kernel is a configuration item specific to
the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.)
This should get you a properly booting 2.4 kernel on the itsy.

11
Documentation/arm/sa1100/nanoengine.rst
View File

@@ -1,11 +0,0 @@
==========
nanoEngine
==========
"nanoEngine" is a SA1110 based single board computer from
Bright Star Engineering Inc. See www.brightstareng.com/arm
for more info.
(Ref: Stuart Adams <sja@brightstareng.com>)
Also visit Larry Doolittle's "Linux for the nanoEngine" site:
http://www.brightstareng.com/arm/nanoeng.htm

29
Documentation/arm/sa1100/pangolin.rst
View File

@@ -1,29 +0,0 @@
========
Pangolin
========
Pangolin is a StrongARM 1110-based evaluation platform produced
by Dialogue Technology (http://www.dialogue.com.tw/).
It has EISA slots for ease of configuration with SDRAM/Flash
memory card, USB/Serial/Audio card, Compact Flash card,
PCMCIA/IDE card and TFT-LCD card.
To compile for Pangolin, you must issue the following commands::
make pangolin_config
make oldconfig
make zImage
Supported peripherals
=====================
- SA1110 serial port (UART1/UART2/UART3)
- flash memory access
- compact flash driver
- UDA1341 sound driver
- SA1100 LCD controller for 800x600 16bpp TFT-LCD
- MQ-200 driver for 800x600 16bpp TFT-LCD
- Penmount(touch panel) driver
- PCMCIA driver
- SMC91C94 LAN driver
- IDE driver (experimental)

13
Documentation/arm/sa1100/pleb.rst
View File

@@ -1,13 +0,0 @@
====
PLEB
====
The PLEB project was started as a student initiative at the School of
Computer Science and Engineering, University of New South Wales to make a
pocket computer capable of running the Linux Kernel.
PLEB support has yet to be fully integrated.
For more information, see:
http://www.cse.unsw.edu.au

7
Documentation/arm/sa1100/tifon.rst
View File

@@ -1,7 +0,0 @@
=====
Tifon
=====
More info has to come...
Contact: Peter Danielsson <peter.danielsson@era-t.ericsson.se>

5
Documentation/arm/sa1100/yopy.rst
View File

@@ -1,5 +0,0 @@
====
Yopy
====
See http://www.yopydeveloper.org for more.

2
Documentation/arm/samsung-s3c24xx/index.rst
View File

@@ -1,6 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0
==========================
==========================
Samsung S3C24XX SoC Family
==========================

1
Documentation/arm/sh-mobile/.gitignore vendored
View File

@@ -1 +0,0 @@
vrl4

1
Documentation/arm64/index.rst
View File

@@ -16,6 +16,7 @@ ARM64 Architecture
pointer-authentication
silicon-errata
sve
tagged-address-abi
tagged-pointers
.. only:: subproject and html

27
Documentation/arm64/kasan-offsets.sh Normal file
View File

@@ -0,0 +1,27 @@
#!/bin/sh
# Print out the KASAN_SHADOW_OFFSETS required to place the KASAN SHADOW
# start address at the mid-point of the kernel VA space
print_kasan_offset () {
printf "%02d\t" $1
printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
+ (1 << ($1 - 32 - $2)) \
- (1 << (64 - 32 - $2)) ))
}
echo KASAN_SHADOW_SCALE_SHIFT = 3
printf "VABITS\tKASAN_SHADOW_OFFSET\n"
print_kasan_offset 48 3
print_kasan_offset 47 3
print_kasan_offset 42 3
print_kasan_offset 39 3
print_kasan_offset 36 3
echo
echo KASAN_SHADOW_SCALE_SHIFT = 4
printf "VABITS\tKASAN_SHADOW_OFFSET\n"
print_kasan_offset 48 4
print_kasan_offset 47 4
print_kasan_offset 42 4
print_kasan_offset 39 4
print_kasan_offset 36 4

119
Documentation/arm64/memory.rst
View File

@@ -14,6 +14,10 @@ with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
virtual address, are used but the memory layout is the same.
ARMv8.2 adds optional support for Large Virtual Address space. This is
only available when running with a 64KB page size and expands the
number of descriptors in the first level of translation.
User addresses have bits 63:48 set to 0 while the kernel addresses have
the same bits set to 1. TTBRx selection is given by bit 63 of the
virtual address. The swapper_pg_dir contains only kernel (global)
@@ -22,40 +26,43 @@ The swapper_pg_dir address is written to TTBR1 and never written to
TTBR0.
AArch64 Linux memory layout with 4KB pages + 3 levels::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000007fffffffff 512GB user
ffffff8000000000 ffffffffffffffff 512GB kernel
AArch64 Linux memory layout with 4KB pages + 4 levels::
AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
ffff800000000000 ffff9fffffffffff 32TB kasan shadow region
ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
ffffa00008000000 ffffa0000fffffff 128MB modules
ffffa00010000000 fffffdffbffeffff ~93TB vmalloc
fffffdffbfff0000 fffffdfffe5f8fff ~998MB [guard region]
fffffdfffe5f9000 fffffdfffe9fffff 4124KB fixed mappings
fffffdfffea00000 fffffdfffebfffff 2MB [guard region]
fffffdfffec00000 fffffdffffbfffff 16MB PCI I/O space
fffffdffffc00000 fffffdffffdfffff 2MB [guard region]
fffffdffffe00000 ffffffffffdfffff 2TB vmemmap
ffffffffffe00000 ffffffffffffffff 2MB [guard region]
AArch64 Linux memory layout with 64KB pages + 2 levels::
AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 000003ffffffffff 4TB user
fffffc0000000000 ffffffffffffffff 4TB kernel
AArch64 Linux memory layout with 64KB pages + 3 levels::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
For details of the virtual kernel memory layout please see the kernel
booting log.
0000000000000000 000fffffffffffff 4PB user
fff0000000000000 fff7ffffffffffff 2PB kernel logical memory map
fff8000000000000 fffd9fffffffffff 1440TB [gap]
fffda00000000000 ffff9fffffffffff 512TB kasan shadow region
ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
ffffa00008000000 ffffa0000fffffff 128MB modules
ffffa00010000000 fffff81ffffeffff ~88TB vmalloc
fffff81fffff0000 fffffc1ffe58ffff ~3TB [guard region]
fffffc1ffe590000 fffffc1ffe9fffff 4544KB fixed mappings
fffffc1ffea00000 fffffc1ffebfffff 2MB [guard region]
fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O space
fffffc1fffc00000 fffffc1fffdfffff 2MB [guard region]
fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap
ffffffffffe00000 ffffffffffffffff 2MB [guard region]
Translation table lookup with 4KB pages::
@@ -83,7 +90,8 @@ Translation table lookup with 64KB pages::
| | | | [15:0] in-page offset
| | | +----------> [28:16] L3 index
| | +--------------------------> [41:29] L2 index
| +-------------------------------> [47:42] L1 index
| +-------------------------------> [47:42] L1 index (48-bit)
| [51:42] L1 index (52-bit)
+-------------------------------------------------> [63] TTBR0/1
@@ -96,3 +104,62 @@ ARM64_HARDEN_EL2_VECTORS is selected for particular CPUs.
When using KVM with the Virtualization Host Extensions, no additional
mappings are created, since the host kernel runs directly in EL2.
52-bit VA support in the kernel
-------------------------------
If the ARMv8.2-LVA optional feature is present, and we are running
with a 64KB page size; then it is possible to use 52-bits of address
space for both userspace and kernel addresses. However, any kernel
binary that supports 52-bit must also be able to fall back to 48-bit
at early boot time if the hardware feature is not present.
This fallback mechanism necessitates the kernel .text to be in the
higher addresses such that they are invariant to 48/52-bit VAs. Due
to the kasan shadow being a fraction of the entire kernel VA space,
the end of the kasan shadow must also be in the higher half of the
kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit,
the end of the kasan shadow is invariant and dependent on ~0UL,
whilst the start address will "grow" towards the lower addresses).
In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET
is kept constant at 0xFFF0000000000000 (corresponding to 52-bit),
this obviates the need for an extra variable read. The physvirt
offset and vmemmap offsets are computed at early boot to enable
this logic.
As a single binary will need to support both 48-bit and 52-bit VA
spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
also must be sized large enought to accommodate a fixed PAGE_OFFSET.
Most code in the kernel should not need to consider the VA_BITS, for
code that does need to know the VA size the variables are
defined as follows:
VA_BITS constant the *maximum* VA space size
VA_BITS_MIN constant the *minimum* VA space size
vabits_actual variable the *actual* VA space size
Maximum and minimum sizes can be useful to ensure that buffers are
sized large enough or that addresses are positioned close enough for
the "worst" case.
52-bit userspace VAs
--------------------
To maintain compatibility with software that relies on the ARMv8.0
VA space maximum size of 48-bits, the kernel will, by default,
return virtual addresses to userspace from a 48-bit range.
Software can "opt-in" to receiving VAs from a 52-bit space by
specifying an mmap hint parameter that is larger than 48-bit.
For example:
maybe_high_address = mmap(~0UL, size, prot, flags,...);
It is also possible to build a debug kernel that returns addresses
from a 52-bit space by enabling the following kernel config options:
CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
Note that this option is only intended for debugging applications
and should not be used in production.

2
Documentation/arm64/silicon-errata.rst
View File

@@ -115,6 +115,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{6,7} | #161010701 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{6,7} | #161010803 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |

156
Documentation/arm64/tagged-address-abi.rst Normal file
View File

@@ -0,0 +1,156 @@
==========================
AArch64 TAGGED ADDRESS ABI
==========================
Authors: Vincenzo Frascino <vincenzo.frascino@arm.com>
Catalin Marinas <catalin.marinas@arm.com>
Date: 21 August 2019
This document describes the usage and semantics of the Tagged Address
ABI on AArch64 Linux.
1. Introduction
---------------
On AArch64 the ``TCR_EL1.TBI0`` bit is set by default, allowing
userspace (EL0) to perform memory accesses through 64-bit pointers with
a non-zero top byte. This document describes the relaxation of the
syscall ABI that allows userspace to pass certain tagged pointers to
kernel syscalls.
2. AArch64 Tagged Address ABI
-----------------------------
From the kernel syscall interface perspective and for the purposes of
this document, a "valid tagged pointer" is a pointer with a potentially
non-zero top-byte that references an address in the user process address
space obtained in one of the following ways:
- ``mmap()`` syscall where either:
- flags have the ``MAP_ANONYMOUS`` bit set or
- the file descriptor refers to a regular file (including those
returned by ``memfd_create()``) or ``/dev/zero``
- ``brk()`` syscall (i.e. the heap area between the initial location of
the program break at process creation and its current location).
- any memory mapped by the kernel in the address space of the process
during creation and with the same restrictions as for ``mmap()`` above
(e.g. data, bss, stack).
The AArch64 Tagged Address ABI has two stages of relaxation depending
how the user addresses are used by the kernel:
1. User addresses not accessed by the kernel but used for address space
management (e.g. ``mmap()``, ``mprotect()``, ``madvise()``). The use
of valid tagged pointers in this context is always allowed.
2. User addresses accessed by the kernel (e.g. ``write()``). This ABI
relaxation is disabled by default and the application thread needs to
explicitly enable it via ``prctl()`` as follows:
- ``PR_SET_TAGGED_ADDR_CTRL``: enable or disable the AArch64 Tagged
Address ABI for the calling thread.
The ``(unsigned int) arg2`` argument is a bit mask describing the
control mode used:
- ``PR_TAGGED_ADDR_ENABLE``: enable AArch64 Tagged Address ABI.
Default status is disabled.
Arguments ``arg3``, ``arg4``, and ``arg5`` must be 0.
- ``PR_GET_TAGGED_ADDR_CTRL``: get the status of the AArch64 Tagged
Address ABI for the calling thread.
Arguments ``arg2``, ``arg3``, ``arg4``, and ``arg5`` must be 0.
The ABI properties described above are thread-scoped, inherited on
clone() and fork() and cleared on exec().
Calling ``prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)``
returns ``-EINVAL`` if the AArch64 Tagged Address ABI is globally
disabled by ``sysctl abi.tagged_addr_disabled=1``. The default
``sysctl abi.tagged_addr_disabled`` configuration is 0.
When the AArch64 Tagged Address ABI is enabled for a thread, the
following behaviours are guaranteed:
- All syscalls except the cases mentioned in section 3 can accept any
valid tagged pointer.
- The syscall behaviour is undefined for invalid tagged pointers: it may
result in an error code being returned, a (fatal) signal being raised,
or other modes of failure.
- The syscall behaviour for a valid tagged pointer is the same as for
the corresponding untagged pointer.
A definition of the meaning of tagged pointers on AArch64 can be found
in Documentation/arm64/tagged-pointers.rst.
3. AArch64 Tagged Address ABI Exceptions
-----------------------------------------
The following system call parameters must be untagged regardless of the
ABI relaxation:
- ``prctl()`` other than pointers to user data either passed directly or
indirectly as arguments to be accessed by the kernel.
- ``ioctl()`` other than pointers to user data either passed directly or
indirectly as arguments to be accessed by the kernel.
- ``shmat()`` and ``shmdt()``.
Any attempt to use non-zero tagged pointers may result in an error code
being returned, a (fatal) signal being raised, or other modes of
failure.
4. Example of correct usage
---------------------------
.. code-block:: c
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/prctl.h>
#define PR_SET_TAGGED_ADDR_CTRL 55
#define PR_TAGGED_ADDR_ENABLE (1UL << 0)
#define TAG_SHIFT 56
int main(void)
{
int tbi_enabled = 0;
unsigned long tag = 0;
char *ptr;
/* check/enable the tagged address ABI */
if (!prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0))
tbi_enabled = 1;
/* memory allocation */
ptr = mmap(NULL, sysconf(_SC_PAGE_SIZE), PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (ptr == MAP_FAILED)
return 1;
/* set a non-zero tag if the ABI is available */
if (tbi_enabled)
tag = rand() & 0xff;
ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
/* memory access to a tagged address */
strcpy(ptr, "tagged pointer\n");
/* syscall with a tagged pointer */
write(1, ptr, strlen(ptr));
return 0;
}

21
Documentation/arm64/tagged-pointers.rst
View File

@@ -20,7 +20,9 @@ Passing tagged addresses to the kernel
--------------------------------------
All interpretation of userspace memory addresses by the kernel assumes
an address tag of 0x00.
an address tag of 0x00, unless the application enables the AArch64
Tagged Address ABI explicitly
(Documentation/arm64/tagged-address-abi.rst).
This includes, but is not limited to, addresses found in:
@@ -33,13 +35,15 @@ This includes, but is not limited to, addresses found in:
- the frame pointer (x29) and frame records, e.g. when interpreting
them to generate a backtrace or call graph.
Using non-zero address tags in any of these locations may result in an
error code being returned, a (fatal) signal being raised, or other modes
of failure.
Using non-zero address tags in any of these locations when the
userspace application did not enable the AArch64 Tagged Address ABI may
result in an error code being returned, a (fatal) signal being raised,
or other modes of failure.
For these reasons, passing non-zero address tags to the kernel via
system calls is forbidden, and using a non-zero address tag for sp is
strongly discouraged.
For these reasons, when the AArch64 Tagged Address ABI is disabled,
passing non-zero address tags to the kernel via system calls is
forbidden, and using a non-zero address tag for sp is strongly
discouraged.
Programs maintaining a frame pointer and frame records that use non-zero
address tags may suffer impaired or inaccurate debug and profiling
@@ -59,6 +63,9 @@ be preserved.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
This behaviour is maintained when the AArch64 Tagged Address ABI is
enabled.
Other considerations
--------------------

105
Documentation/auxdisplay/cfag12864b
View File

@@ -1,105 +0,0 @@
===================================
cfag12864b LCD Driver Documentation
===================================
License: GPLv2
Author & Maintainer: Miguel Ojeda Sandonis
Date: 2006-10-27
--------
0. INDEX
--------
1. DRIVER INFORMATION
2. DEVICE INFORMATION
3. WIRING
4. USERSPACE PROGRAMMING
---------------------
1. DRIVER INFORMATION
---------------------
This driver supports a cfag12864b LCD.
---------------------
2. DEVICE INFORMATION
---------------------
Manufacturer: Crystalfontz
Device Name: Crystalfontz 12864b LCD Series
Device Code: cfag12864b
Webpage: http://www.crystalfontz.com
Device Webpage: http://www.crystalfontz.com/products/12864b/
Type: LCD (Liquid Crystal Display)
Width: 128
Height: 64
Colors: 2 (B/N)
Controller: ks0108
Controllers: 2
Pages: 8 each controller
Addresses: 64 each page
Data size: 1 byte each address
Memory size: 2 * 8 * 64 * 1 = 1024 bytes = 1 Kbyte
---------
3. WIRING
---------
The cfag12864b LCD Series don't have official wiring.
The common wiring is done to the parallel port as shown:
Parallel Port cfag12864b
Name Pin# Pin# Name
Strobe ( 1)------------------------------(17) Enable
Data 0 ( 2)------------------------------( 4) Data 0
Data 1 ( 3)------------------------------( 5) Data 1
Data 2 ( 4)------------------------------( 6) Data 2
Data 3 ( 5)------------------------------( 7) Data 3
Data 4 ( 6)------------------------------( 8) Data 4
Data 5 ( 7)------------------------------( 9) Data 5
Data 6 ( 8)------------------------------(10) Data 6
Data 7 ( 9)------------------------------(11) Data 7
(10) [+5v]---( 1) Vdd
(11) [GND]---( 2) Ground
(12) [+5v]---(14) Reset
(13) [GND]---(15) Read / Write
Line (14)------------------------------(13) Controller Select 1
(15)
Init (16)------------------------------(12) Controller Select 2
Select (17)------------------------------(16) Data / Instruction
Ground (18)---[GND] [+5v]---(19) LED +
Ground (19)---[GND]
Ground (20)---[GND] E A Values:
Ground (21)---[GND] [GND]---[P1]---(18) Vee - R = Resistor = 22 ohm
Ground (22)---[GND] | - P1 = Preset = 10 Kohm
Ground (23)---[GND] ---- S ------( 3) V0 - P2 = Preset = 1 Kohm
Ground (24)---[GND] | |
Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED -
------------------------
4. USERSPACE PROGRAMMING
------------------------
The cfag12864bfb describes a framebuffer device (/dev/fbX).
It has a size of 1024 bytes = 1 Kbyte.
Each bit represents one pixel. If the bit is high, the pixel will
turn on. If the pixel is low, the pixel will turn off.
You can use the framebuffer as a file: fopen, fwrite, fclose...
Although the LCD won't get updated until the next refresh time arrives.
Also, you can mmap the framebuffer: open & mmap, munmap & close...
which is the best option for most uses.
Check samples/auxdisplay/cfag12864b-example.c
for a real working userspace complete program with usage examples.

55
Documentation/auxdisplay/ks0108
View File

@@ -1,55 +0,0 @@
==========================================
ks0108 LCD Controller Driver Documentation
==========================================
License: GPLv2
Author & Maintainer: Miguel Ojeda Sandonis
Date: 2006-10-27
--------
0. INDEX
--------
1. DRIVER INFORMATION
2. DEVICE INFORMATION
3. WIRING
---------------------
1. DRIVER INFORMATION
---------------------
This driver supports the ks0108 LCD controller.
---------------------
2. DEVICE INFORMATION
---------------------
Manufacturer: Samsung
Device Name: KS0108 LCD Controller
Device Code: ks0108
Webpage: -
Device Webpage: -
Type: LCD Controller (Liquid Crystal Display Controller)
Width: 64
Height: 64
Colors: 2 (B/N)
Pages: 8
Addresses: 64 each page
Data size: 1 byte each address
Memory size: 8 * 64 * 1 = 512 bytes
---------
3. WIRING
---------
The driver supports data parallel port wiring.
If you aren't building LCD related hardware, you should check
your LCD specific wiring information in the same folder.
For example, check Documentation/auxdisplay/cfag12864b.

33
Documentation/block/null_blk.rst
View File

@@ -1,19 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
========================
Null block device driver
========================
1. Overview
===========
Overview
========
The null block device (/dev/nullb*) is used for benchmarking the various
The null block device (``/dev/nullb*``) is used for benchmarking the various
block-layer implementations. It emulates a block device of X gigabytes in size.
The following instances are possible:
Single-queue block-layer
- Request-based.
- Single submission queue per device.
- Implements IO scheduling algorithms (CFQ, Deadline, noop).
It does not execute any read/write operation, just mark them as complete in
the request queue. The following instances are possible:
Multi-queue block-layer
@@ -27,15 +24,15 @@ The following instances are possible:
All of them have a completion queue for each core in the system.
2. Module parameters applicable for all instances
=================================================
Module parameters
=================
queue_mode=[0-2]: Default: 2-Multi-queue
Selects which block-layer the module should instantiate with.
= ============
0 Bio-based
1 Single-queue
1 Single-queue (deprecated)
2 Multi-queue
= ============
@@ -67,7 +64,7 @@ irqmode=[0-2]: Default: 1-Soft-irq
completion_nsec=[ns]: Default: 10,000ns
Combined with irqmode=2 (timer). The time each completion event must wait.
submit_queues=[1..nr_cpus]:
submit_queues=[1..nr_cpus]: Default: 1
The number of submission queues attached to the device driver. If unset, it
defaults to 1. For multi-queue, it is ignored when use_per_node_hctx module
parameter is 1.
@@ -75,9 +72,11 @@ submit_queues=[1..nr_cpus]:
hw_queue_depth=[0..qdepth]: Default: 64
The hardware queue depth of the device.
III: Multi-queue specific parameters
Multi-queue specific parameters
-------------------------------
use_per_node_hctx=[0/1]: Default: 0
Number of hardware context queues.
= =====================================================================
0 The number of submit queues are set to the value of the submit_queues
@@ -87,6 +86,7 @@ use_per_node_hctx=[0/1]: Default: 0
= =====================================================================
no_sched=[0/1]: Default: 0
Enable/disable the io scheduler.
= ======================================
0 nullb* use default blk-mq io scheduler
@@ -94,6 +94,7 @@ no_sched=[0/1]: Default: 0
= ======================================
blocking=[0/1]: Default: 0
Blocking behavior of the request queue.
= ===============================================================
0 Register as a non-blocking blk-mq driver device.
@@ -103,6 +104,7 @@ blocking=[0/1]: Default: 0
= ===============================================================
shared_tags=[0/1]: Default: 0
Sharing tags between devices.
= ================================================================
0 Tag set is not shared.
@@ -111,6 +113,7 @@ shared_tags=[0/1]: Default: 0
= ================================================================
zoned=[0/1]: Default: 0
Device is a random-access or a zoned block device.
= ======================================================================
0 Block device is exposed as a random-access block device.

4
Documentation/block/switching-sched.rst
View File

@@ -2,10 +2,6 @@
Switching Scheduler
===================
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
'noop' and 'cfq' (the default) are also available. IO schedulers are assigned
globally at boot time only presently.
Each io queue has a set of io scheduler tunables associated with it. These
tunables control how the io scheduler works. You can find these entries
in::

18
Documentation/bpf/prog_flow_dissector.rst
View File

@@ -26,6 +26,7 @@ The inputs are:
* ``nhoff`` - initial offset of the networking header
* ``thoff`` - initial offset of the transport header, initialized to nhoff
* ``n_proto`` - L3 protocol type, parsed out of L2 header
* ``flags`` - optional flags
Flow dissector BPF program should fill out the rest of the ``struct
bpf_flow_keys`` fields. Input arguments ``nhoff/thoff/n_proto`` should be
@@ -101,6 +102,23 @@ can be called for both cases and would have to be written carefully to
handle both cases.
Flags
=====
``flow_keys->flags`` might contain optional input flags that work as follows:
* ``BPF_FLOW_DISSECTOR_F_PARSE_1ST_FRAG`` - tells BPF flow dissector to
continue parsing first fragment; the default expected behavior is that
flow dissector returns as soon as it finds out that the packet is fragmented;
used by ``eth_get_headlen`` to estimate length of all headers for GRO.
* ``BPF_FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL`` - tells BPF flow dissector to
stop parsing as soon as it reaches IPv6 flow label; used by
``___skb_get_hash`` and ``__skb_get_hash_symmetric`` to get flow hash.
* ``BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP`` - tells BPF flow dissector to stop
parsing as soon as it reaches encapsulated headers; used by routing
infrastructure.
Reference Implementation
========================

3
Documentation/core-api/index.rst
View File

@@ -25,6 +25,7 @@ Core utilities
librs
genalloc
errseq
packing
printk-formats
circular-buffers
generic-radix-tree
@@ -48,7 +49,7 @@ Interfaces for kernel debugging
debug-objects
tracepoint
.. only:: subproject
.. only:: subproject and html
Indices
=======

81
Documentation/packing.txt → Documentation/core-api/packing.rst
View File

@@ -30,6 +30,7 @@ The solution
------------
This API deals with 2 basic operations:
- Packing a CPU-usable number into a memory buffer (with hardware
constraints/quirks)
- Unpacking a memory buffer (which has hardware constraints/quirks)
@@ -49,10 +50,12 @@ What the examples show is where the logical bytes and bits sit.
1. Normally (no quirks), we would do it like this:
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
7 6 5 4
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
3 2 1 0
::
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
7 6 5 4
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
3 2 1 0
That is, the MSByte (7) of the CPU-usable u64 sits at memory offset 0, and the
LSByte (0) of the u64 sits at memory offset 7.
@@ -63,10 +66,12 @@ comments as "logical" notation.
2. If QUIRK_MSB_ON_THE_RIGHT is set, we do it like this:
56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
7 6 5 4
24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
3 2 1 0
::
56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
7 6 5 4
24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
3 2 1 0
That is, QUIRK_MSB_ON_THE_RIGHT does not affect byte positioning, but
inverts bit offsets inside a byte.
@@ -74,10 +79,12 @@ inverts bit offsets inside a byte.
3. If QUIRK_LITTLE_ENDIAN is set, we do it like this:
39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
4 5 6 7
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
0 1 2 3
::
39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
4 5 6 7
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
0 1 2 3
Therefore, QUIRK_LITTLE_ENDIAN means that inside the memory region, every
byte from each 4-byte word is placed at its mirrored position compared to
@@ -86,18 +93,22 @@ the boundary of that word.
4. If QUIRK_MSB_ON_THE_RIGHT and QUIRK_LITTLE_ENDIAN are both set, we do it
like this:
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
4 5 6 7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 1 2 3
::
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
4 5 6 7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 1 2 3
5. If just QUIRK_LSW32_IS_FIRST is set, we do it like this:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
3 2 1 0
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
7 6 5 4
::
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
3 2 1 0
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
7 6 5 4
In this case the 8 byte memory region is interpreted as follows: first
4 bytes correspond to the least significant 4-byte word, next 4 bytes to
@@ -107,28 +118,34 @@ the more significant 4-byte word.
6. If QUIRK_LSW32_IS_FIRST and QUIRK_MSB_ON_THE_RIGHT are set, we do it like
this:
24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
3 2 1 0
56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
7 6 5 4
::
24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
3 2 1 0
56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
7 6 5 4
7. If QUIRK_LSW32_IS_FIRST and QUIRK_LITTLE_ENDIAN are set, it looks like
this:
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
0 1 2 3
39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
4 5 6 7
::
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
0 1 2 3
39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
4 5 6 7
8. If QUIRK_LSW32_IS_FIRST, QUIRK_LITTLE_ENDIAN and QUIRK_MSB_ON_THE_RIGHT
are set, it looks like this:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 1 2 3
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
4 5 6 7
::
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 1 2 3
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
4 5 6 7
We always think of our offsets as if there were no quirk, and we translate

16
Documentation/core-api/printk-formats.rst
View File

@@ -13,10 +13,10 @@ Integer types
If variable is of Type, use printk format specifier:
------------------------------------------------------------
char %hhd or %hhx
unsigned char %hhu or %hhx
short int %hd or %hx
unsigned short int %hu or %hx
char %d or %x
unsigned char %u or %x
short int %d or %x
unsigned short int %u or %x
int %d or %x
unsigned int %u or %x
long %ld or %lx
@@ -25,10 +25,10 @@ Integer types
unsigned long long %llu or %llx
size_t %zu or %zx
ssize_t %zd or %zx
s8 %hhd or %hhx
u8 %hhu or %hhx
s16 %hd or %hx
u16 %hu or %hx
s8 %d or %x
u8 %u or %x
s16 %d or %x
u16 %u or %x
s32 %d or %x
u32 %u or %x
s64 %lld or %llx

16
Documentation/cpu-freq/core.txt
View File

@@ -57,19 +57,11 @@ transition notifiers.
2.1 CPUFreq policy notifiers
----------------------------
These are notified when a new policy is intended to be set. Each
CPUFreq policy notifier is called twice for a policy transition:
These are notified when a new policy is created or removed.
1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
they see a need for this - may it be thermal considerations or
hardware limitations.
2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
- if two hardware drivers failed to agree on a new policy before this
stage, the incompatible hardware shall be shut down, and the user
informed of this.
The phase is specified in the second argument to the notifier.
The phase is specified in the second argument to the notifier. The phase is
CPUFREQ_CREATE_POLICY when the policy is first created and it is
CPUFREQ_REMOVE_POLICY when the policy is removed.
The third argument, a void *pointer, points to a struct cpufreq_policy
consisting of several values, including min, max (the lower and upper

1
Documentation/crypto/crypto_engine.rst
View File

@@ -1,4 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
Crypto Engine
=============

21
Documentation/devicetree/bindings/arm/amlogic.yaml
View File

@@ -91,13 +91,11 @@ properties:
- description: Boards with the Amlogic Meson GXL S905X SoC
items:
- enum:
- amediatech,x96-max
- amlogic,p212
- hwacom,amazetv
- khadas,vim
- libretech,cc
- nexbox,a95x
- seirobotics,sei510
- const: amlogic,s905x
- const: amlogic,meson-gxl
@@ -129,16 +127,33 @@ properties:
- const: amlogic,a113d
- const: amlogic,meson-axg
- description: Boards with the Amlogic Meson G12A S905D2 SoC
- description: Boards with the Amlogic Meson G12A S905D2/X2/Y2 SoC
items:
- enum:
- amediatech,x96-max
- amlogic,u200
- seirobotics,sei510
- const: amlogic,g12a
- description: Boards with the Amlogic Meson G12B A311D SoC
items:
- enum:
- khadas,vim3
- const: amlogic,a311d
- const: amlogic,g12b
- description: Boards with the Amlogic Meson G12B S922X SoC
items:
- enum:
- hardkernel,odroid-n2
- khadas,vim3
- const: amlogic,s922x
- const: amlogic,g12b
- description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
items:
- enum:
- seirobotics,sei610
- khadas,vim3l
- const: amlogic,sm1
...

17
Documentation/devicetree/bindings/arm/arm,scmi.txt
View File

@@ -73,6 +73,16 @@ Required properties:
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Reset signal bindings for the reset domains based on SCMI Message Protocol
------------------------------------------------------------
This binding for the SCMI reset domain providers uses the generic reset
signal binding[5].
Required properties:
- #reset-cells : Should be 1. Contains the reset domain ID value used
by SCMI commands.
SRAM and Shared Memory for SCMI
-------------------------------
@@ -93,6 +103,7 @@ Required sub-node properties:
[2] Documentation/devicetree/bindings/power/power_domain.txt
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.txt
[5] Documentation/devicetree/bindings/reset/reset.txt
Example:
@@ -152,6 +163,11 @@ firmware {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
scmi_reset: protocol@16 {
reg = <0x16>;
#reset-cells = <1>;
};
};
};
@@ -166,6 +182,7 @@ hdlcd@7ff60000 {
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scmi_clk 4>;
power-domains = <&scmi_devpd 1>;
resets = <&scmi_reset 10>;
};
thermal-zones {

1
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@@ -175,6 +175,7 @@ properties:
- amlogic,meson8-smp
- amlogic,meson8b-smp
- arm,realview-smp
- aspeed,ast2600-smp
- brcm,bcm11351-cpu-method
- brcm,bcm23550
- brcm,bcm2836-smp

4
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
View File

@@ -136,7 +136,9 @@ Required properties:
OCOTP bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: Should be "fsl,imx8qxp-scu-ocotp"
- compatible: Should be one of:
"fsl,imx8qm-scu-ocotp",
"fsl,imx8qxp-scu-ocotp".
- #address-cells: Must be 1. Contains byte index
- #size-cells: Must be 1. Contains byte length

26
Documentation/devicetree/bindings/arm/fsl.yaml
View File

@@ -161,6 +161,20 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
- const: fsl,imx6ul
- description: Kontron N6310 S Board
items:
- const: kontron,imx6ul-n6310-s
- const: kontron,imx6ul-n6310-som
- const: fsl,imx6ul
- description: Kontron N6310 S 43 Board
items:
- const: kontron,imx6ul-n6310-s-43
- const: kontron,imx6ul-n6310-s
- const: kontron,imx6ul-n6310-som
- const: fsl,imx6ul
- description: i.MX6ULL based Boards
@@ -188,6 +202,7 @@ properties:
- fsl,imx7d-sdb # i.MX7 SabreSD Board
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
- zii,imx7d-rmu2 # ZII RMU2 Board
- zii,imx7d-rpu2 # ZII RPU2 Board
- const: fsl,imx7d
@@ -214,16 +229,26 @@ properties:
- fsl,imx8mm-evk # i.MX8MM EVK Board
- const: fsl,imx8mm
- description: i.MX8MN based Boards
items:
- enum:
- fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
- const: fsl,imx8mn
- description: i.MX8MQ based Boards
items:
- enum:
- boundary,imx8mq-nitrogen8m # i.MX8MQ NITROGEN Board
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- purism,librem5-devkit # Purism Librem5 devkit
- solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse
- technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk
- const: fsl,imx8mq
- description: i.MX8QXP based Boards
items:
- enum:
- einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board
- fsl,imx8qxp-mek # i.MX8QXP MEK Board
- const: fsl,imx8qxp
@@ -283,6 +308,7 @@ properties:
- description: LS1046A based Boards
items:
- enum:
- fsl,ls1046a-frwy
- fsl,ls1046a-qds
- fsl,ls1046a-rdb
- const: fsl,ls1046a

4
Documentation/devicetree/bindings/arm/mediatek.yaml
View File

@@ -46,6 +46,10 @@ properties:
- enum:
- mediatek,mt6765-evb
- const: mediatek,mt6765
- items:
- enum:
- mediatek,mt6779-evb
- const: mediatek,mt6779
- items:
- enum:
- mediatek,mt6795-evb

2
Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
View File

@@ -9,8 +9,6 @@ Required Properties:
- "mediatek,mt7622-sgmiisys", "syscon"
- "mediatek,mt7629-sgmiisys", "syscon"
- #clock-cells: Must be 1
- mediatek,physpeed: Should be one of "auto", "1000" or "2500" to match up
the capability of the target PHY.
The SGMIISYS controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt

8
Documentation/devicetree/bindings/arm/qcom.yaml
View File

@@ -45,6 +45,7 @@ description: |
mtp
sbc
hk01
qrd
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
@@ -115,6 +116,13 @@ properties:
- const: qcom,msm8916-mtp
- const: qcom,msm8916
- items:
- enum:
- longcheer,l8150
- samsung,a3u-eur
- samsung,a5u-eur
- const: qcom,msm8916
- items:
- const: qcom,msm8996-mtp

45
Documentation/devicetree/bindings/arm/rockchip.yaml
View File

@@ -128,6 +128,21 @@ properties:
- const: google,veyron
- const: rockchip,rk3288
- description: Google Fievel (AOPEN Chromebox Mini)
items:
- const: google,veyron-fievel-rev8
- const: google,veyron-fievel-rev7
- const: google,veyron-fievel-rev6
- const: google,veyron-fievel-rev5
- const: google,veyron-fievel-rev4
- const: google,veyron-fievel-rev3
- const: google,veyron-fievel-rev2
- const: google,veyron-fievel-rev1
- const: google,veyron-fievel-rev0
- const: google,veyron-fievel
- const: google,veyron
- const: rockchip,rk3288
- description: Google Gru (dev-board)
items:
- const: google,gru-rev15
@@ -311,6 +326,21 @@ properties:
- const: google,veyron
- const: rockchip,rk3288
- description: Google Tiger (AOpen Chromebase Mini)
items:
- const: google,veyron-tiger-rev8
- const: google,veyron-tiger-rev7
- const: google,veyron-tiger-rev6
- const: google,veyron-tiger-rev5
- const: google,veyron-tiger-rev4
- const: google,veyron-tiger-rev3
- const: google,veyron-tiger-rev2
- const: google,veyron-tiger-rev1
- const: google,veyron-tiger-rev0
- const: google,veyron-tiger
- const: google,veyron
- const: rockchip,rk3288
- description: Haoyu MarsBoard RK3066
items:
- const: haoyu,marsboard-rk3066
@@ -329,6 +359,16 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
- description: Mecer Xtreme Mini S6
items:
- const: mecer,xms6
- const: rockchip,rk3229
- description: Leez RK3399 P710
items:
- const: leez,p710
- const: rockchip,rk3399
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
@@ -424,11 +464,6 @@ properties:
- rockchip,rk3288-evb-rk808
- const: rockchip,rk3288
- description: Rockchip RK3288 Fennec
items:
- const: rockchip,rk3288-fennec
- const: rockchip,rk3288
- description: Rockchip RK3328 Evaluation board
items:
- const: rockchip,rk3328-evb

16
Documentation/devicetree/bindings/arm/sunxi.yaml
View File

@@ -353,6 +353,12 @@ properties:
- const: licheepi,licheepi-zero
- const: allwinner,sun8i-v3s
- description: Lichee Zero Plus (with S3, without eMMC/SPI Flash)
items:
- const: sipeed,lichee-zero-plus
- const: sochip,s3
- const: allwinner,sun8i-v3
- description: Linksprite PCDuino
items:
- const: linksprite,a10-pcduino
@@ -568,6 +574,11 @@ properties:
- const: olimex,a64-olinuxino
- const: allwinner,sun50i-a64
- description: Olimex A64-OlinuXino (with eMMC)
items:
- const: olimex,a64-olinuxino-emmc
- const: allwinner,sun50i-a64
- description: Olimex A64 Teres-I
items:
- const: olimex,a64-teres-i
@@ -671,6 +682,11 @@ properties:
- const: sinlinx,sina33
- const: allwinner,sun8i-a33
- description: Tanix TX6
items:
- const: oranth,tanix-tx6
- const: allwinner,sun50i-h6
- description: TBS A711 Tablet
items:
- const: tbs-biometrics,a711

4
Documentation/devicetree/bindings/bus/imx-weim.txt
View File

@@ -44,6 +44,10 @@ Optional properties:
what bootloader sets up in IOMUXC_GPR1[11:0] will be
used.
- fsl,burst-clk-enable For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
devices, the presence of this property indicates that
the weim bus should operate in Burst Clock Mode.
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains timing values for the

46
Documentation/devicetree/bindings/bus/moxtet.txt Normal file
View File

@@ -0,0 +1,46 @@
Turris Mox module status and configuration bus (over SPI)
Required properties:
- compatible : Should be "cznic,moxtet"
- #address-cells : Has to be 1
- #size-cells : Has to be 0
- spi-cpol : Required inverted clock polarity
- spi-cpha : Required shifted clock phase
- interrupts : Must contain reference to the shared interrupt line
- interrupt-controller : Required
- #interrupt-cells : Has to be 1
For other required and optional properties of SPI slave nodes please refer to
../spi/spi-bus.txt.
Required properties of subnodes:
- reg : Should be position on the Moxtet bus (how many Moxtet
modules are between this module and CPU module, so
either 0 or a positive integer)
The driver finds the devices connected to the bus by itself, but it may be
needed to reference some of them from other parts of the device tree. In that
case the devices can be defined as subnodes of the moxtet node.
Example:
moxtet@1 {
compatible = "cznic,moxtet";
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
spi-max-frequency = <10000000>;
spi-cpol;
spi-cpha;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&gpiosb>;
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
moxtet_sfp: gpio@0 {
compatible = "cznic,moxtet-gpio";
gpio-controller;
#gpio-cells = <2>;
reg = <0>;
}
};

1
Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
View File

@@ -22,6 +22,7 @@ Required Properties:
components.
- resets : phandle of the internal reset line
- #clock-cells : should be 1.
- #reset-cells : should be 1 on the g12a (and following) soc family
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as

1
Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
View File

@@ -11,6 +11,7 @@ Required Properties:
"amlogic,axg-clkc" for AXG SoC.
"amlogic,g12a-clkc" for G12A SoC.
"amlogic,g12b-clkc" for G12B SoC.
"amlogic,sm1-clkc" for SM1 SoC.
- clocks : list of clock phandle, one for each entry clock-names.
- clock-names : should contain the following:
* "xtal": the platform xtal

112
Documentation/devicetree/bindings/clock/imx8mn-clock.yaml Normal file
View File

@@ -0,0 +1,112 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/clock/imx8mn-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX8M Nano Clock Control Module Binding
maintainers:
- Anson Huang <Anson.Huang@nxp.com>
description: |
NXP i.MX8M Nano clock control module is an integrated clock controller, which
generates and supplies to all modules.
properties:
compatible:
const: fsl,imx8mn-ccm
reg:
maxItems: 1
clocks:
items:
- description: 32k osc
- description: 24m osc
- description: ext1 clock input
- description: ext2 clock input
- description: ext3 clock input
- description: ext4 clock input
clock-names:
items:
- const: osc_32k
- const: osc_24m
- const: clk_ext1
- const: clk_ext2
- const: clk_ext3
- const: clk_ext4
'#clock-cells':
const: 1
description: |
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mn-clock.h
for the full list of i.MX8M Nano clock IDs.
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
examples:
# Clock Control Module node:
- |
clk: clock-controller@30380000 {
compatible = "fsl,imx8mn-ccm";
reg = <0x0 0x30380000 0x0 0x10000>;
#clock-cells = <1>;
clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
<&clk_ext2>, <&clk_ext3>, <&clk_ext4>;
clock-names = "osc_32k", "osc_24m", "clk_ext1",
"clk_ext2", "clk_ext3", "clk_ext4";
};
# Required external clocks for Clock Control Module node:
- |
osc_32k: clock-osc-32k {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
clock-output-names = "osc_32k";
};
osc_24m: clock-osc-24m {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <24000000>;
clock-output-names = "osc_24m";
};
clk_ext1: clock-ext1 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <133000000>;
clock-output-names = "clk_ext1";
};
clk_ext2: clock-ext2 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <133000000>;
clock-output-names = "clk_ext2";
};
clk_ext3: clock-ext3 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <133000000>;
clock-output-names = "clk_ext3";
};
clk_ext4: clock-ext4 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency= <133000000>;
clock-output-names = "clk_ext4";
};
...

14
Documentation/devicetree/bindings/connector/usb-connector.txt
View File

@@ -17,6 +17,20 @@ Optional properties:
- self-powered: Set this property if the usb device that has its own power
source.
Optional properties for usb-b-connector:
- id-gpios: an input gpio for USB ID pin.
- vbus-gpios: an input gpio for USB VBUS pin, used to detect presence of
VBUS 5V.
see gpio/gpio.txt.
- vbus-supply: a phandle to the regulator for USB VBUS if needed when host
mode or dual role mode is supported.
Particularly, if use an output GPIO to control a VBUS regulator, should
model it as a regulator.
see regulator/fixed-regulator.yaml
- pinctrl-names : a pinctrl state named "default" is optional
- pinctrl-0 : pin control group
see pinctrl/pinctrl-bindings.txt
Optional properties for usb-c-connector:
- power-role: should be one of "source", "sink" or "dual"(DRP) if typec
connector has power support.

258
Documentation/devicetree/bindings/arm/topology.txt → Documentation/devicetree/bindings/cpu/cpu-topology.txt
View File

@@ -1,21 +1,19 @@
===========================================
ARM topology binding description
CPU topology binding description
===========================================
===========================================
1 - Introduction
===========================================
In an ARM system, the hierarchy of CPUs is defined through three entities that
In a SMP system, the hierarchy of CPUs is defined through three entities that
are used to describe the layout of physical CPUs in the system:
- socket
- cluster
- core
- thread
The cpu nodes (bindings defined in [1]) represent the devices that
correspond to physical CPUs and are to be mapped to the hierarchy levels.
The bottom hierarchy level sits at core or thread level depending on whether
symmetric multi-threading (SMT) is supported or not.
@@ -24,33 +22,31 @@ threads existing in the system and map to the hierarchy level "thread" above.
In systems where SMT is not supported "cpu" nodes represent all cores present
in the system and map to the hierarchy level "core" above.
ARM topology bindings allow one to associate cpu nodes with hierarchical groups
CPU topology bindings allow one to associate cpu nodes with hierarchical groups
corresponding to the system hierarchy; syntactically they are defined as device
tree nodes.
The remainder of this document provides the topology bindings for ARM, based
on the Devicetree Specification, available from:
Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be
used for any other architecture as well.
https://www.devicetree.org/specifications/
The cpu nodes, as per bindings defined in [4], represent the devices that
correspond to physical CPUs and are to be mapped to the hierarchy levels.
If not stated otherwise, whenever a reference to a cpu node phandle is made its
value must point to a cpu node compliant with the cpu node bindings as
documented in [1].
A topology description containing phandles to cpu nodes that are not compliant
with bindings standardized in [1] is therefore considered invalid.
with bindings standardized in [4] is therefore considered invalid.
===========================================
2 - cpu-map node
===========================================
The ARM CPU topology is defined within the cpu-map node, which is a direct
The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct
child of the cpus node and provides a container where the actual topology
nodes are listed.
- cpu-map node
Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
ARM uniprocessor systems do not require a topology
Usage: Optional - On SMP systems provide CPUs topology to the OS.
Uniprocessor systems do not require a topology
description and therefore should not define a
cpu-map node.
@@ -63,21 +59,23 @@ nodes are listed.
The cpu-map node's child nodes can be:
- one or more cluster nodes
- one or more cluster nodes or
- one or more socket nodes in a multi-socket system
Any other configuration is considered invalid.
The cpu-map node can only contain three types of child nodes:
The cpu-map node can only contain 4 types of child nodes:
- socket node
- cluster node
- core node
- thread node
whose bindings are described in paragraph 3.
The nodes describing the CPU topology (cluster/core/thread) can only
be defined within the cpu-map node and every core/thread in the system
must be defined within the topology. Any other configuration is
The nodes describing the CPU topology (socket/cluster/core/thread) can
only be defined within the cpu-map node and every core/thread in the
system must be defined within the topology. Any other configuration is
invalid and therefore must be ignored.
===========================================
@@ -85,26 +83,44 @@ invalid and therefore must be ignored.
===========================================
cpu-map child nodes must follow a naming convention where the node name
must be "clusterN", "coreN", "threadN" depending on the node type (ie
cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
are siblings within a single common parent node must be given a unique and
must be "socketN", "clusterN", "coreN", "threadN" depending on the node type
(ie socket/cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes
which are siblings within a single common parent node must be given a unique and
sequential N value, starting from 0).
cpu-map child nodes which do not share a common parent node can have the same
name (ie same number N as other cpu-map child nodes at different device tree
levels) since name uniqueness will be guaranteed by the device tree hierarchy.
===========================================
3 - cluster/core/thread node bindings
3 - socket/cluster/core/thread node bindings
===========================================
Bindings for cluster/cpu/thread nodes are defined as follows:
Bindings for socket/cluster/cpu/thread nodes are defined as follows:
- socket node
Description: must be declared within a cpu-map node, one node
per physical socket in the system. A system can
contain single or multiple physical socket.
The association of sockets and NUMA nodes is beyond
the scope of this bindings, please refer [2] for
NUMA bindings.
This node is optional for a single socket system.
The socket node name must be "socketN" as described in 2.1 above.
A socket node can not be a leaf node.
A socket node's child nodes must be one or more cluster nodes.
Any other configuration is considered invalid.
- cluster node
Description: must be declared within a cpu-map node, one node
per cluster. A system can contain several layers of
clustering and cluster nodes can be contained in parent
cluster nodes.
clustering within a single physical socket and cluster
nodes can be contained in parent cluster nodes.
The cluster node name must be "clusterN" as described in 2.1 above.
A cluster node can not be a leaf node.
@@ -164,90 +180,93 @@ Bindings for cluster/cpu/thread nodes are defined as follows:
4 - Example dts
===========================================
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters in a single
physical socket):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu-map {
cluster0 {
socket0 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU0>;
cluster0 {
core0 {
thread0 {
cpu = <&CPU0>;
};
thread1 {
cpu = <&CPU1>;
};
};
thread1 {
cpu = <&CPU1>;
core1 {
thread0 {
cpu = <&CPU2>;
};
thread1 {
cpu = <&CPU3>;
};
};
};
core1 {
thread0 {
cpu = <&CPU2>;
cluster1 {
core0 {
thread0 {
cpu = <&CPU4>;
};
thread1 {
cpu = <&CPU5>;
};
};
thread1 {
cpu = <&CPU3>;
core1 {
thread0 {
cpu = <&CPU6>;
};
thread1 {
cpu = <&CPU7>;
};
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU4>;
cluster0 {
core0 {
thread0 {
cpu = <&CPU8>;
};
thread1 {
cpu = <&CPU9>;
};
};
thread1 {
cpu = <&CPU5>;
core1 {
thread0 {
cpu = <&CPU10>;
};
thread1 {
cpu = <&CPU11>;
};
};
};
core1 {
thread0 {
cpu = <&CPU6>;
cluster1 {
core0 {
thread0 {
cpu = <&CPU12>;
};
thread1 {
cpu = <&CPU13>;
};
};
thread1 {
cpu = <&CPU7>;
};
};
};
};
cluster1 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU8>;
};
thread1 {
cpu = <&CPU9>;
};
};
core1 {
thread0 {
cpu = <&CPU10>;
};
thread1 {
cpu = <&CPU11>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU12>;
};
thread1 {
cpu = <&CPU13>;
};
};
core1 {
thread0 {
cpu = <&CPU14>;
};
thread1 {
cpu = <&CPU15>;
core1 {
thread0 {
cpu = <&CPU14>;
};
thread1 {
cpu = <&CPU15>;
};
};
};
};
@@ -470,6 +489,65 @@ cpus {
};
};
Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
{
#address-cells = <2>;
#size-cells = <2>;
compatible = "sifive,fu540g", "sifive,fu500";
model = "sifive,hifive-unleashed-a00";
...
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu-map {
socket0 {
cluster0 {
core0 {
cpu = <&CPU1>;
};
core1 {
cpu = <&CPU2>;
};
core2 {
cpu0 = <&CPU2>;
};
core3 {
cpu0 = <&CPU3>;
};
};
};
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x1>;
}
CPU2: cpu@2 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x2>;
}
CPU3: cpu@3 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x3>;
}
CPU4: cpu@4 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x4>;
}
}
};
===============================================================================
[1] ARM Linux kernel documentation
Documentation/devicetree/bindings/arm/cpus.yaml
[2] Devicetree NUMA binding description
Documentation/devicetree/bindings/numa.txt
[3] RISC-V Linux kernel documentation
Documentation/devicetree/bindings/riscv/cpus.txt
[4] https://www.devicetree.org/specifications/

55
Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml Normal file
View File

@@ -0,0 +1,55 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/allwinner,sun4i-a10-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 DMA Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
allOf:
- $ref: "dma-controller.yaml#"
properties:
"#dma-cells":
const: 2
description:
The first cell is either 0 or 1, the former to use the normal
DMA, 1 for dedicated DMA. The second cell is the request line
number.
compatible:
const: allwinner,sun4i-a10-dma
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
required:
- "#dma-cells"
- compatible
- reg
- interrupts
- clocks
additionalProperties: false
examples:
- |
dma: dma-controller@1c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
interrupts = <27>;
clocks = <&ahb_gates 6>;
#dma-cells = <2>;
};
...

Some files were not shown because too many files have changed in this diff Show More