iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'dt/schema-cleanups' into dt/linus

Browse Source
This commit is contained in:
Rob Herring 2020-06-12 09:57:00 -06:00
commit 8440d4a75d
14193 changed files with 823989 additions and 291213 deletions
.clang-format.gitignore.mailmapCREDITS
Documentation
ABI
obsolete
sysfs-cpuidlesysfs-driver-intel_pmc_bxt
stable
sysfs-devices-nodesysfs-driver-dma-idxdsysfs-driver-firmware-zynqmp
testing
debugfs-cec-error-injdebugfs-driver-habanalabsdebugfs-hisi-hpredebugfs-hisi-secdebugfs-hisi-zipdev-kmsgprocfs-smaps_rollupsysfs-block-rnbdsysfs-bus-event_source-devices-dfl_fmesysfs-bus-event_source-devices-hv_24x7sysfs-bus-iio-proximitysysfs-bus-iio-sx9310sysfs-bus-mostsysfs-bus-soundwire-mastersysfs-bus-soundwire-slavesysfs-class-netsysfs-class-powersysfs-class-power-mp2629sysfs-class-rnbd-clientsysfs-class-rnbd-serversysfs-class-rtrs-clientsysfs-class-rtrs-serversysfs-devices-system-cpusysfs-driver-habanalabssysfs-driver-w1_thermsysfs-fs-f2fssysfs-platform-dptfsysfs-platform-intel-wmi-sbl-fw-update
COPYING-logoIRQ-domain.txtMakefile
PCI
boot-interrupts.rst
endpoint
pci-endpoint.rst
RCU/Design/Requirements
Requirements.rst
admin-guide
LSM
tomoyo.rst
README.rst
acpi
initrd_table_override.rstssdt-overlays.rst
bcache.rstbug-hunting.rst
cgroup-v1
memory.rst
cgroup-v2.rstcpu-load.rst
device-mapper
dm-ebs.rstdm-integrity.rstdm-zoned.rst
devices.rstdynamic-debug-howto.rst
gpio
gpio-aggregator.rstindex.rst
hw-vuln
index.rstl1tf.rstspecial-register-buffer-data-sampling.rst
index.rstinit.rstinitrd.rst
kdump
kdump.rstvmcoreinfo.rst
kernel-parameters.txtkernel-per-CPU-kthreads.rstmd.rst
media
au0828-cardlist.rstavermedia.rstbt8xx.rstbttv-cardlist.rstbttv.rstbuilding.rstcafe_ccic.rstcardlist.rstcec-drivers.rstci.rstcpia2.rstcx18-cardlist.rstcx231xx-cardlist.rstcx23885-cardlist.rstcx88-cardlist.rstcx88.rstdavinci-vpbe.rstdvb-drivers.rstdvb-usb-a800-cardlist.rstdvb-usb-af9005-cardlist.rstdvb-usb-af9015-cardlist.rstdvb-usb-af9035-cardlist.rstdvb-usb-anysee-cardlist.rstdvb-usb-au6610-cardlist.rstdvb-usb-az6007-cardlist.rstdvb-usb-az6027-cardlist.rstdvb-usb-ce6230-cardlist.rstdvb-usb-cinergyT2-cardlist.rstdvb-usb-cxusb-cardlist.rstdvb-usb-dib0700-cardlist.rst
Show More

19
.clang-format

@ -80,6 +80,7 @@ ForEachMacros:
- 'ax25_uid_for_each'
- '__bio_for_each_bvec'
- 'bio_for_each_bvec'
- 'bio_for_each_bvec_all'
- 'bio_for_each_integrity_vec'
- '__bio_for_each_segment'
- 'bio_for_each_segment'
@ -142,10 +143,13 @@ ForEachMacros:
- 'for_each_card_auxs'
- 'for_each_card_auxs_safe'
- 'for_each_card_components'
- 'for_each_card_dapms'
- 'for_each_card_pre_auxs'
- 'for_each_card_prelinks'
- 'for_each_card_rtds'
- 'for_each_card_rtds_safe'
- 'for_each_card_widgets'
- 'for_each_card_widgets_safe'
- 'for_each_cgroup_storage_type'
- 'for_each_child_of_node'
- 'for_each_clear_bit'
@ -160,6 +164,7 @@ ForEachMacros:
- 'for_each_cpu_and'
- 'for_each_cpu_not'
- 'for_each_cpu_wrap'
- 'for_each_dapm_widgets'
- 'for_each_dev_addr'
- 'for_each_dev_scope'
- 'for_each_displayid_db'
@ -170,7 +175,6 @@ ForEachMacros:
- 'for_each_dpcm_fe'
- 'for_each_drhd_unit'
- 'for_each_dss_dev'
- 'for_each_efi_handle'
- 'for_each_efi_memory_desc'
- 'for_each_efi_memory_desc_in_map'
- 'for_each_element'
@ -191,6 +195,7 @@ ForEachMacros:
- 'for_each_ip_tunnel_rcu'
- 'for_each_irq_nr'
- 'for_each_link_codecs'
- 'for_each_link_cpus'
- 'for_each_link_platforms'
- 'for_each_lru'
- 'for_each_matching_node'
@ -250,6 +255,7 @@ ForEachMacros:
- 'for_each_pci_bridge'
- 'for_each_pci_dev'
- 'for_each_pci_msi_entry'
- 'for_each_pcm_streams'
- 'for_each_populated_zone'
- 'for_each_possible_cpu'
- 'for_each_present_cpu'
@ -260,9 +266,12 @@ ForEachMacros:
- 'for_each_property_of_node'
- 'for_each_registered_fb'
- 'for_each_reserved_mem_region'
- 'for_each_rtd_codec_dai'
- 'for_each_rtd_codec_dai_rollback'
- 'for_each_rtd_codec_dais'
- 'for_each_rtd_codec_dais_rollback'
- 'for_each_rtd_components'
- 'for_each_rtd_cpu_dais'
- 'for_each_rtd_cpu_dais_rollback'
- 'for_each_rtd_dais'
- 'for_each_set_bit'
- 'for_each_set_bit_from'
- 'for_each_set_clump8'
@ -334,6 +343,7 @@ ForEachMacros:
- 'klp_for_each_object'
- 'klp_for_each_object_safe'
- 'klp_for_each_object_static'
- 'kunit_suite_for_each_test_case'
- 'kvm_for_each_memslot'
- 'kvm_for_each_vcpu'
- 'list_for_each'
@ -387,6 +397,7 @@ ForEachMacros:
- 'of_property_for_each_string'
- 'of_property_for_each_u32'
- 'pci_bus_for_each_resource'
- 'pcm_for_each_format'
- 'ping_portaddr_for_each_entry'
- 'plist_for_each'
- 'plist_for_each_continue'
@ -482,7 +493,7 @@ KeepEmptyLinesAtTheStartOfBlocks: false
MacroBlockBegin: ''
MacroBlockEnd: ''
MaxEmptyLinesToKeep: 1
NamespaceIndentation: Inner
NamespaceIndentation: None
#ObjCBinPackProtocolList: Auto # Unknown to clang-format-5.0
ObjCBlockIndentWidth: 8
ObjCSpaceAfterProperty: true

1
.gitignore vendored

@ -56,6 +56,7 @@ modules.order
/linux
/vmlinux
/vmlinux.32
/vmlinux.symvers
/vmlinux-gdb.py
/vmlinuz
/System.map

7
.mailmap

@ -152,6 +152,7 @@ Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
Leonid I Ananiev <leonid.i.ananiev@intel.com>
Linas Vepstas <linas@austin.ibm.com>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
@ -234,7 +235,9 @@ Ralf Baechle <ralf@linux-mips.org>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
Rémi Denis-Courmont <rdenis@simphalempin.com>
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>
Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
@ -288,6 +291,8 @@ Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Will Deacon <will@kernel.org> <will.deacon@arm.com>
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de>
Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
Yusuke Goda <goda.yusuke@renesas.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>

6
CREDITS

@ -3104,14 +3104,16 @@ W: http://www.qsl.net/dl1bke/
D: Generic Z8530 driver, AX.25 DAMA slave implementation
D: Several AX.25 hacks
N: Ricardo Ribalda Delgado
E: ricardo.ribalda@gmail.com
N: Ricardo Ribalda
E: ribalda@kernel.org
W: http://ribalda.com
D: PLX USB338x driver
D: PCA9634 driver
D: Option GTM671WFS
D: Fintek F81216A
D: AD5761 iio driver
D: TI DAC7612 driver
D: Sony IMX214 driver
D: Various kernel hacks
S: Qtechnology A/S
S: Valby Langgade 142

9
Documentation/ABI/obsolete/sysfs-cpuidle Normal file

@ -0,0 +1,9 @@
What: /sys/devices/system/cpu/cpuidle/current_governor_ro
Date: April, 2020
Contact: linux-pm@vger.kernel.org
Description:
current_governor_ro shows current using cpuidle governor, but read only.
with the update that cpuidle governor can be changed at runtime in default,
both current_governor and current_governor_ro co-exist under
/sys/devices/system/cpu/cpuidle/ file, it's duplicate so make
current_governor_ro obselete.

22
Documentation/ABI/obsolete/sysfs-driver-intel_pmc_bxt Normal file

@ -0,0 +1,22 @@
These files allow sending arbitrary IPC commands to the PMC/SCU which
may be dangerous. These will be removed eventually and should not be
used in any new applications.
What: /sys/bus/platform/devices/INT34D2:00/simplecmd
Date: Jun 2015
KernelVersion: 4.1
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This interface allows userspace to send an arbitrary
IPC command to the PMC/SCU.
Format: %d %d where first number is command and
second number is subcommand.
What: /sys/bus/platform/devices/INT34D2:00/northpeak
Date: Jun 2015
KernelVersion: 4.1
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This interface allows userspace to enable and disable
Northpeak through the PMC/SCU.
Format: %u.

2
Documentation/ABI/stable/sysfs-devices-node

@ -54,7 +54,7 @@ Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Provides information about the node's distribution and memory
utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt
utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.rst
What: /sys/devices/system/node/nodeX/numastat
Date: October 2002

6
Documentation/ABI/stable/sysfs-driver-dma-idxd

@ -1,3 +1,9 @@
What: sys/bus/dsa/devices/dsa<m>/version
Date: Apr 15, 2020
KernelVersion: 5.8.0
Contact: dmaengine@vger.kernel.org
Description: The hardware version number.
What: sys/bus/dsa/devices/dsa<m>/cdev_major
Date: Oct 25, 2019
KernelVersion: 5.6.0

103
Documentation/ABI/stable/sysfs-driver-firmware-zynqmp Normal file

@ -0,0 +1,103 @@
What: /sys/devices/platform/firmware\:zynqmp-firmware/ggs*
Date: March 2020
KernelVersion: 5.6
Contact: "Jolly Shah" <jollys@xilinx.com>
Description:
Read/Write PMU global general storage register value,
GLOBAL_GEN_STORAGE{0:3}.
Global general storage register that can be used
by system to pass information between masters.
The register is reset during system or power-on
resets. Three registers are used by the FSBL and
other Xilinx software products: GLOBAL_GEN_STORAGE{4:6}.
Usage:
# cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
# echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
Example:
# cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
# echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
Users: Xilinx
What: /sys/devices/platform/firmware\:zynqmp-firmware/pggs*
Date: March 2020
KernelVersion: 5.6
Contact: "Jolly Shah" <jollys@xilinx.com>
Description:
Read/Write PMU persistent global general storage register
value, PERS_GLOB_GEN_STORAGE{0:3}.
Persistent global general storage register that
can be used by system to pass information between
masters.
This register is only reset by the power-on reset
and maintains its value through a system reset.
Four registers are used by the FSBL and other Xilinx
software products: PERS_GLOB_GEN_STORAGE{4:7}.
Register is reset only by a POR reset.
Usage:
# cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
# echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
Example:
# cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
# echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
Users: Xilinx
What: /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
Date: March 2020
KernelVersion: 5.6
Contact: "Jolly Shah" <jollys@xilinx.com>
Description:
This sysfs interface allows to set the shutdown scope for the
next shutdown request. When the next shutdown is performed, the
platform specific portion of PSCI-system_off can use the chosen
shutdown scope.
Following are available shutdown scopes(subtypes):
subsystem: Only the APU along with all of its peripherals
not used by other processing units will be
shut down. This may result in the FPD power
domain being shut down provided that no other
processing unit uses FPD peripherals or DRAM.
ps_only: The complete PS will be shut down, including the
RPU, PMU, etc. Only the PL domain (FPGA)
remains untouched.
system: The complete system/device is shut down.
Usage:
# cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
# echo <scope> > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
Example:
# cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
# echo "subsystem" > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
Users: Xilinx
What: /sys/devices/platform/firmware\:zynqmp-firmware/health_status
Date: March 2020
KernelVersion: 5.6
Contact: "Jolly Shah" <jollys@xilinx.com>
Description:
This sysfs interface allows to set the health status. If PMUFW
is compiled with CHECK_HEALTHY_BOOT, it will check the healthy
bit on FPD WDT expiration. If healthy bit is set by a user
application running in Linux, PMUFW will do APU only restart. If
healthy bit is not set during FPD WDT expiration, PMUFW will do
system restart.
Usage:
Set healthy bit
# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
Unset healthy bit
# echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
Users: Xilinx

2
Documentation/ABI/testing/debugfs-cec-error-inj

@ -37,4 +37,4 @@ when changes are made.
The following CEC error injection implementations exist:
- Documentation/media/uapi/cec/cec-pin-error-inj.rst
- Documentation/userspace-api/media/cec/cec-pin-error-inj.rst

17
Documentation/ABI/testing/debugfs-driver-habanalabs

@ -8,6 +8,16 @@ Description: Sets the device address to be used for read or write through
only when the IOMMU is disabled.
The acceptable value is a string that starts with "0x"
What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate
Date: May 2020
KernelVersion: 5.8
Contact: oded.gabbay@gmail.com
Description: Allow the root user to disable/enable in runtime the clock
gating mechanism in Gaudi. Due to how Gaudi is built, the
clock gating needs to be disabled in order to access the
registers of the TPC and MME engines. This is sometimes needed
during debug by the user and hence the user needs this option
What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers
Date: Jan 2019
KernelVersion: 5.1
@ -150,3 +160,10 @@ KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Displays a list with information about all the active virtual
address mappings per ASID
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
Date: Mar 2020
KernelVersion: 5.6
Contact: oded.gabbay@gmail.com
Description: Sets the stop-on_error option for the device engines. Value of
"0" is for disable, otherwise enable.

89
Documentation/ABI/testing/debugfs-hisi-hpre

@ -33,7 +33,7 @@ Contact: linux-crypto@vger.kernel.org
Description: Dump debug registers from the HPRE.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/qm_regs
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/regs
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump debug registers from the QM.
@ -44,14 +44,97 @@ What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/current_q
Date: Sep 2019
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.
show its debug registers in above regs.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/clear_enable
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(qm_regs) read clear control. 1 means enable
Description: QM debug registers(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.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
QM task completion.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
Four states: initiated, started, stopped and closed.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests sent
with returning busy.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_fail_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of completed but error requests.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/invalid_req_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of invalid requests being received.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/overtime_thrhld
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Set the threshold time for counting the request which is
processed longer than the threshold.
0: disable(default), 1: 1 microsecond.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/over_thrhld_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of time out requests.
Available for both PF and VF, and take no other effect on HPRE.

94
Documentation/ABI/testing/debugfs-hisi-sec

@ -1,10 +1,4 @@
What: /sys/kernel/debug/hisi_sec/<bdf>/sec_dfx
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump the debug registers of SEC cores.
Only available for PF.
What: /sys/kernel/debug/hisi_sec/<bdf>/clear_enable
What: /sys/kernel/debug/hisi_sec2/<bdf>/clear_enable
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Enabling/disabling of clear action after reading
@ -12,7 +6,7 @@ Description: Enabling/disabling of clear action after reading
0: disable, 1: enable.
Only available for PF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec/<bdf>/current_qm
What: /sys/kernel/debug/hisi_sec2/<bdf>/current_qm
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: One SEC controller has one PF and multiple VFs, each function
@ -20,24 +14,100 @@ Description: One SEC controller has one PF and multiple VFs, each function
qm refers to.
Only available for PF.
What: /sys/kernel/debug/hisi_sec/<bdf>/qm/qm_regs
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/qm_regs
Date: Oct 2019
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_sec/<bdf>/qm/current_q
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/current_q
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: One QM of SEC may contain multiple queues. Select specific
queue to show its debug registers in above 'qm_regs'.
queue to show its debug registers in above 'regs'.
Only available for PF.
What: /sys/kernel/debug/hisi_sec/<bdf>/qm/clear_enable
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/clear_enable
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Enabling/disabling of clear action after reading
the SEC's QM debug registers.
0: disable, 1: enable.
Only available for PF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
QM task completion.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
Four states: initiated, started, stopped and closed.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests sent with returning busy.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/err_bd_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of BD type error requests
to be received.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/invalid_req_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of invalid requests being received.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/done_flag_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of completed but marked error requests
to be received.
Available for both PF and VF, and take no other effect on SEC.

70
Documentation/ABI/testing/debugfs-hisi-zip

@ -26,7 +26,7 @@ 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
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of QM related debug registers.
@ -37,14 +37,78 @@ 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.
show its debug registers in above 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
Description: QM debug registers(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.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
QM task completion.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
Four states: initiated, started, stopped and closed.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests received
with returning busy.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/err_bd_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of BD type error requests
to be received.
Available for both PF and VF, and take no other effect on ZIP.

5
Documentation/ABI/testing/dev-kmsg

@ -56,6 +56,11 @@ Description: The /dev/kmsg character device node provides userspace access
seek after the last record available at the time
the last SYSLOG_ACTION_CLEAR was issued.
Due to the record nature of this interface with a "read all"
behavior and the specific positions each seek operation sets,
SEEK_CUR is not supported, returning -ESPIPE (invalid seek) to
errno whenever requested.
The output format consists of a prefix carrying the syslog
prefix including priority and facility, the 64 bit message
sequence number and the monotonic timestamp in microseconds,

2
Documentation/ABI/testing/procfs-smaps_rollup

@ -11,7 +11,7 @@ Description:
Additionally, the fields Pss_Anon, Pss_File and Pss_Shmem
are not present in /proc/pid/smaps. These fields represent
the sum of the Pss field of each type (anon, file, shmem).
For more details, see Documentation/filesystems/proc.txt
For more details, see Documentation/filesystems/proc.rst
and the procfs man page.
Typical output looks like this:

46
Documentation/ABI/testing/sysfs-block-rnbd Normal file

@ -0,0 +1,46 @@
What: /sys/block/rnbd<N>/rnbd/unmap_device
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: To unmap a volume, "normal" or "force" has to be written to:
/sys/block/rnbd<N>/rnbd/unmap_device
When "normal" is used, the operation will fail with EBUSY if any process
is using the device. When "force" is used, the device is also unmapped
when device is in use. All I/Os that are in progress will fail.
Example:
# echo "normal" > /sys/block/rnbd0/rnbd/unmap_device
What: /sys/block/rnbd<N>/rnbd/state
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: The file contains the current state of the block device. The state file
returns "open" when the device is successfully mapped from the server
and accepting I/O requests. When the connection to the server gets
disconnected in case of an error (e.g. link failure), the state file
returns "closed" and all I/O requests submitted to it will fail with -EIO.
What: /sys/block/rnbd<N>/rnbd/session
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RNBD uses RTRS session to transport the data between client and
server. The entry "session" contains the name of the session, that
was used to establish the RTRS session. It's the same name that
was passed as server parameter to the map_device entry.
What: /sys/block/rnbd<N>/rnbd/mapping_path
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the path that was passed as "device_path" to the map_device
operation.
What: /sys/block/rnbd<N>/rnbd/access_mode
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the device access mode: ro, rw or migration.

104
Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme Normal file

@ -0,0 +1,104 @@
What: /sys/bus/event_source/devices/dfl_fmeX/format
Date: April 2020
KernelVersion: 5.8
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Attribute group to describe the magic bits
that go into perf_event_attr.config for a particular pmu.
(See ABI/testing/sysfs-bus-event_source-devices-format).
Each attribute under this group defines a bit range of the
perf_event_attr.config. All supported attributes are listed
below.
event = "config:0-11" - event ID
evtype = "config:12-15" - event type
portid = "config:16-23" - event source
For example,
fab_mmio_read = "event=0x06,evtype=0x02,portid=0xff"
It shows this fab_mmio_read is a fabric type (0x02) event with
0x06 local event id for overall monitoring (portid=0xff).
What: /sys/bus/event_source/devices/dfl_fmeX/cpumask
Date: April 2020
KernelVersion: 5.8
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. This file always returns cpu which the PMU is bound
for access to all fme pmu performance monitoring events.
What: /sys/bus/event_source/devices/dfl_fmeX/events
Date: April 2020
KernelVersion: 5.8
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Attribute group to describe performance monitoring
events specific to fme. Each attribute in this group describes
a single performance monitoring event supported by this fme pmu.
The name of the file is the name of the event.
(See ABI/testing/sysfs-bus-event_source-devices-events).
All supported performance monitoring events are listed below.
Basic events (evtype=0x00)
clock = "event=0x00,evtype=0x00,portid=0xff"
Cache events (evtype=0x01)
cache_read_hit = "event=0x00,evtype=0x01,portid=0xff"
cache_read_miss = "event=0x01,evtype=0x01,portid=0xff"
cache_write_hit = "event=0x02,evtype=0x01,portid=0xff"
cache_write_miss = "event=0x03,evtype=0x01,portid=0xff"
cache_hold_request = "event=0x05,evtype=0x01,portid=0xff"
cache_data_write_port_contention =
"event=0x06,evtype=0x01,portid=0xff"
cache_tag_write_port_contention =
"event=0x07,evtype=0x01,portid=0xff"
cache_tx_req_stall = "event=0x08,evtype=0x01,portid=0xff"
cache_rx_req_stall = "event=0x09,evtype=0x01,portid=0xff"
cache_eviction = "event=0x0a,evtype=0x01,portid=0xff"
Fabric events (evtype=0x02)
fab_pcie0_read = "event=0x00,evtype=0x02,portid=0xff"
fab_pcie0_write = "event=0x01,evtype=0x02,portid=0xff"
fab_pcie1_read = "event=0x02,evtype=0x02,portid=0xff"
fab_pcie1_write = "event=0x03,evtype=0x02,portid=0xff"
fab_upi_read = "event=0x04,evtype=0x02,portid=0xff"
fab_upi_write = "event=0x05,evtype=0x02,portid=0xff"
fab_mmio_read = "event=0x06,evtype=0x02,portid=0xff"
fab_mmio_write = "event=0x07,evtype=0x02,portid=0xff"
fab_port_pcie0_read = "event=0x00,evtype=0x02,portid=?"
fab_port_pcie0_write = "event=0x01,evtype=0x02,portid=?"
fab_port_pcie1_read = "event=0x02,evtype=0x02,portid=?"
fab_port_pcie1_write = "event=0x03,evtype=0x02,portid=?"
fab_port_upi_read = "event=0x04,evtype=0x02,portid=?"
fab_port_upi_write = "event=0x05,evtype=0x02,portid=?"
fab_port_mmio_read = "event=0x06,evtype=0x02,portid=?"
fab_port_mmio_write = "event=0x07,evtype=0x02,portid=?"
VTD events (evtype=0x03)
vtd_port_read_transaction = "event=0x00,evtype=0x03,portid=?"
vtd_port_write_transaction = "event=0x01,evtype=0x03,portid=?"
vtd_port_devtlb_read_hit = "event=0x02,evtype=0x03,portid=?"
vtd_port_devtlb_write_hit = "event=0x03,evtype=0x03,portid=?"
vtd_port_devtlb_4k_fill = "event=0x04,evtype=0x03,portid=?"
vtd_port_devtlb_2m_fill = "event=0x05,evtype=0x03,portid=?"
vtd_port_devtlb_1g_fill = "event=0x06,evtype=0x03,portid=?"
VTD SIP events (evtype=0x04)
vtd_sip_iotlb_4k_hit = "event=0x00,evtype=0x04,portid=0xff"
vtd_sip_iotlb_2m_hit = "event=0x01,evtype=0x04,portid=0xff"
vtd_sip_iotlb_1g_hit = "event=0x02,evtype=0x04,portid=0xff"
vtd_sip_slpwc_l3_hit = "event=0x03,evtype=0x04,portid=0xff"
vtd_sip_slpwc_l4_hit = "event=0x04,evtype=0x04,portid=0xff"
vtd_sip_rcc_hit = "event=0x05,evtype=0x04,portid=0xff"
vtd_sip_iotlb_4k_miss = "event=0x06,evtype=0x04,portid=0xff"
vtd_sip_iotlb_2m_miss = "event=0x07,evtype=0x04,portid=0xff"
vtd_sip_iotlb_1g_miss = "event=0x08,evtype=0x04,portid=0xff"
vtd_sip_slpwc_l3_miss = "event=0x09,evtype=0x04,portid=0xff"
vtd_sip_slpwc_l4_miss = "event=0x0a,evtype=0x04,portid=0xff"
vtd_sip_rcc_miss = "event=0x0b,evtype=0x04,portid=0xff"

21
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7

@ -22,6 +22,27 @@ Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.
What: /sys/devices/hv_24x7/interface/sockets
Date: May 2020
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description: read only
This sysfs interface exposes the number of sockets present in the
system.
What: /sys/devices/hv_24x7/interface/chipspersocket
Date: May 2020
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description: read only
This sysfs interface exposes the number of chips per socket
present in the system.
What: /sys/devices/hv_24x7/interface/coresperchip
Date: May 2020
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description: read only
This sysfs interface exposes the number of cores per chip
present in the system.
What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>

10
Documentation/ABI/testing/sysfs-bus-iio-proximity Normal file

@ -0,0 +1,10 @@
What: /sys/bus/iio/devices/iio:deviceX/in_proximity_nearlevel
Date: March 2020
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Near level for proximity sensors. This is a single integer
value that tells user space when an object should be
considered close to the device. If the value read from the
sensor is above or equal to the value in this file an object
should typically be considered near.

10
Documentation/ABI/testing/sysfs-bus-iio-sx9310 Normal file

@ -0,0 +1,10 @@
What: /sys/bus/iio/devices/iio:deviceX/in_proximity3_comb_raw
Date: February 2019
KernelVersion: 5.6
Contact: Daniel Campello <campello@chromium.org>
Description:
Proximity measurement indicating that some object is
near the combined sensor. The combined sensor presents
proximity measurements constructed by hardware by
combining measurements taken from a given set of
physical sensors.

104
Documentation/ABI/testing/sysfs-bus-most

@ -1,14 +1,14 @@
What: /sys/bus/most/devices/.../description
What: /sys/bus/most/devices/<dev>/description
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Provides information about the interface type and the physical
location of the device. Hardware attached via USB, for instance,
Provides information about the physical location of the
device. Hardware attached via USB, for instance,
might return <1-1.1:1.0>
Users:
What: /sys/bus/most/devices/.../interface
What: /sys/bus/most/devices/<dev>/interface
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -16,7 +16,7 @@ Description:
Indicates the type of peripheral interface the device uses.
Users:
What: /sys/bus/most/devices/.../dci
What: /sys/bus/most/devices/<dev>/dci
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -26,7 +26,7 @@ Description:
write the controller's DCI registers.
Users:
What: /sys/bus/most/devices/.../dci/arb_address
What: /sys/bus/most/devices/<dev>/dci/arb_address
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -35,7 +35,7 @@ Description:
application wants to read from or write to.
Users:
What: /sys/bus/most/devices/.../dci/arb_value
What: /sys/bus/most/devices/<dev>/dci/arb_value
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -44,7 +44,7 @@ Description:
is stored in arb_address.
Users:
What: /sys/bus/most/devices/.../dci/mep_eui48_hi
What: /sys/bus/most/devices/<dev>/dci/mep_eui48_hi
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -52,7 +52,7 @@ Description:
This is used to check and configure the MAC address.
Users:
What: /sys/bus/most/devices/.../dci/mep_eui48_lo
What: /sys/bus/most/devices/<dev>/dci/mep_eui48_lo
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -60,7 +60,7 @@ Description:
This is used to check and configure the MAC address.
Users:
What: /sys/bus/most/devices/.../dci/mep_eui48_mi
What: /sys/bus/most/devices/<dev>/dci/mep_eui48_mi
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -68,7 +68,7 @@ Description:
This is used to check and configure the MAC address.
Users:
What: /sys/bus/most/devices/.../dci/mep_filter
What: /sys/bus/most/devices/<dev>/dci/mep_filter
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -76,7 +76,7 @@ Description:
This is used to check and configure the MEP filter address.
Users:
What: /sys/bus/most/devices/.../dci/mep_hash0
What: /sys/bus/most/devices/<dev>/dci/mep_hash0
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -84,7 +84,7 @@ Description:
This is used to check and configure the MEP hash table.
Users:
What: /sys/bus/most/devices/.../dci/mep_hash1
What: /sys/bus/most/devices/<dev>/dci/mep_hash1
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -92,7 +92,7 @@ Description:
This is used to check and configure the MEP hash table.
Users:
What: /sys/bus/most/devices/.../dci/mep_hash2
What: /sys/bus/most/devices/<dev>/dci/mep_hash2
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -100,7 +100,7 @@ Description:
This is used to check and configure the MEP hash table.
Users:
What: /sys/bus/most/devices/.../dci/mep_hash3
What: /sys/bus/most/devices/<dev>/dci/mep_hash3
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -108,7 +108,7 @@ Description:
This is used to check and configure the MEP hash table.
Users:
What: /sys/bus/most/devices/.../dci/ni_state
What: /sys/bus/most/devices/<dev>/dci/ni_state
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -116,7 +116,7 @@ Description:
Indicates the current network interface state.
Users:
What: /sys/bus/most/devices/.../dci/node_address
What: /sys/bus/most/devices/<dev>/dci/node_address
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -124,7 +124,7 @@ Description:
Indicates the current node address.
Users:
What: /sys/bus/most/devices/.../dci/node_position
What: /sys/bus/most/devices/<dev>/dci/node_position
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -132,7 +132,7 @@ Description:
Indicates the current node position.
Users:
What: /sys/bus/most/devices/.../dci/packet_bandwidth
What: /sys/bus/most/devices/<dev>/dci/packet_bandwidth
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -140,7 +140,7 @@ Description:
Indicates the configured packet bandwidth.
Users:
What: /sys/bus/most/devices/.../dci/sync_ep
What: /sys/bus/most/devices/<dev>/dci/sync_ep
Date: June 2016
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -149,7 +149,7 @@ Description:
endpoint.
Users:
What: /sys/bus/most/devices/.../<channel>/
What: /sys/bus/most/devices/<dev>/<channel>/
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@ -160,91 +160,92 @@ Description:
configure it.
Users:
What: /sys/bus/most/devices/.../<channel>/available_datatypes
What: /sys/bus/most/devices/<dev>/<channel>/available_datatypes
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Indicates the data types the current channel can transport.
Indicates the data types the channel can transport.
Users:
What: /sys/bus/most/devices/.../<channel>/available_directions
What: /sys/bus/most/devices/<dev>/<channel>/available_directions
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Indicates the directions the current channel is capable of.
Indicates the directions the channel is capable of.
Users:
What: /sys/bus/most/devices/.../<channel>/number_of_packet_buffers
What: /sys/bus/most/devices/<dev>/<channel>/number_of_packet_buffers
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Indicates the number of packet buffers the current channel can
Indicates the number of packet buffers the channel can
handle.
Users:
What: /sys/bus/most/devices/.../<channel>/number_of_stream_buffers
What: /sys/bus/most/devices/<dev>/<channel>/number_of_stream_buffers
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Indicates the number of streaming buffers the current channel can
Indicates the number of streaming buffers the channel can
handle.
Users:
What: /sys/bus/most/devices/.../<channel>/size_of_packet_buffer
What: /sys/bus/most/devices/<dev>/<channel>/size_of_packet_buffer
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Indicates the size of a packet buffer the current channel can
Indicates the size of a packet buffer the channel can
handle.
Users:
What: /sys/bus/most/devices/.../<channel>/size_of_stream_buffer
What: /sys/bus/most/devices/<dev>/<channel>/size_of_stream_buffer
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Indicates the size of a streaming buffer the current channel can
Indicates the size of a streaming buffer the channel can
handle.
Users:
What: /sys/bus/most/devices/.../<channel>/set_number_of_buffers
What: /sys/bus/most/devices/<dev>/<channel>/set_number_of_buffers
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to configure the number of buffers of the current channel.
This is to read back the configured number of buffers of
the channel.
Users:
What: /sys/bus/most/devices/.../<channel>/set_buffer_size
What: /sys/bus/most/devices/<dev>/<channel>/set_buffer_size
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to configure the size of a buffer of the current channel.
This is to read back the configured buffer size of the channel.
Users:
What: /sys/bus/most/devices/.../<channel>/set_direction
What: /sys/bus/most/devices/<dev>/<channel>/set_direction
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to configure the direction of the current channel.
This is to read back the configured direction of the channel.
The following strings will be accepted:
'dir_tx',
'dir_rx'
'tx',
'rx'
Users:
What: /sys/bus/most/devices/.../<channel>/set_datatype
What: /sys/bus/most/devices/<dev>/<channel>/set_datatype
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to configure the data type of the current channel.
This is to read back the configured data type of the channel.
The following strings will be accepted:
'control',
'async',
@ -252,30 +253,31 @@ Description:
'isoc_avp'
Users:
What: /sys/bus/most/devices/.../<channel>/set_subbuffer_size
What: /sys/bus/most/devices/<dev>/<channel>/set_subbuffer_size
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to configure the subbuffer size of the current channel.
This is to read back the configured subbuffer size of
the channel.
Users:
What: /sys/bus/most/devices/.../<channel>/set_packets_per_xact
What: /sys/bus/most/devices/<dev>/<channel>/set_packets_per_xact
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to configure the number of packets per transaction of
the current channel. This is only needed network interface
controller is attached via USB.
This is to read back the configured number of packets per
transaction of the channel. This is only applicable when
connected via USB.
Users:
What: /sys/bus/most/devices/.../<channel>/channel_starving
What: /sys/bus/most/devices/<dev>/<channel>/channel_starving
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Indicates whether current channel ran out of buffers.
Indicates whether channel ran out of buffers.
Users:
What: /sys/bus/most/drivers/most_core/components

23
Documentation/ABI/testing/sysfs-bus-soundwire-master Normal file

@ -0,0 +1,23 @@
What: /sys/bus/soundwire/devices/sdw-master-N/revision
/sys/bus/soundwire/devices/sdw-master-N/clk_stop_modes
/sys/bus/soundwire/devices/sdw-master-N/clk_freq
/sys/bus/soundwire/devices/sdw-master-N/clk_gears
/sys/bus/soundwire/devices/sdw-master-N/default_col
/sys/bus/soundwire/devices/sdw-master-N/default_frame_rate
/sys/bus/soundwire/devices/sdw-master-N/default_row
/sys/bus/soundwire/devices/sdw-master-N/dynamic_shape
/sys/bus/soundwire/devices/sdw-master-N/err_threshold
/sys/bus/soundwire/devices/sdw-master-N/max_clk_freq
Date: April 2020
Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Bard Liao <yung-chuan.liao@linux.intel.com>
Vinod Koul <vkoul@kernel.org>
Description: SoundWire Master-N DisCo properties.
These properties are defined by MIPI DisCo Specification
for SoundWire. They define various properties of the Master
and are used by the bus to configure the Master. clk_stop_modes
is a bitmask for simplifications and combines the
clock-stop-mode0 and clock-stop-mode1 properties.

91
Documentation/ABI/testing/sysfs-bus-soundwire-slave Normal file

@ -0,0 +1,91 @@
What: /sys/bus/soundwire/devices/sdw:.../dev-properties/mipi_revision
/sys/bus/soundwire/devices/sdw:.../dev-properties/wake_capable
/sys/bus/soundwire/devices/sdw:.../dev-properties/test_mode_capable
/sys/bus/soundwire/devices/sdw:.../dev-properties/clk_stop_mode1
/sys/bus/soundwire/devices/sdw:.../dev-properties/simple_clk_stop_capable
/sys/bus/soundwire/devices/sdw:.../dev-properties/clk_stop_timeout
/sys/bus/soundwire/devices/sdw:.../dev-properties/ch_prep_timeout
/sys/bus/soundwire/devices/sdw:.../dev-properties/reset_behave
/sys/bus/soundwire/devices/sdw:.../dev-properties/high_PHY_capable
/sys/bus/soundwire/devices/sdw:.../dev-properties/paging_support
/sys/bus/soundwire/devices/sdw:.../dev-properties/bank_delay_support
/sys/bus/soundwire/devices/sdw:.../dev-properties/p15_behave
/sys/bus/soundwire/devices/sdw:.../dev-properties/master_count
/sys/bus/soundwire/devices/sdw:.../dev-properties/source_ports
/sys/bus/soundwire/devices/sdw:.../dev-properties/sink_ports
Date: May 2020
Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Bard Liao <yung-chuan.liao@linux.intel.com>
Vinod Koul <vkoul@kernel.org>
Description: SoundWire Slave DisCo properties.
These properties are defined by MIPI DisCo Specification
for SoundWire. They define various properties of the
SoundWire Slave and are used by the bus to configure
the Slave
What: /sys/bus/soundwire/devices/sdw:.../dp0/max_word
/sys/bus/soundwire/devices/sdw:.../dp0/min_word
/sys/bus/soundwire/devices/sdw:.../dp0/words
/sys/bus/soundwire/devices/sdw:.../dp0/BRA_flow_controlled
/sys/bus/soundwire/devices/sdw:.../dp0/simple_ch_prep_sm
/sys/bus/soundwire/devices/sdw:.../dp0/imp_def_interrupts
Date: May 2020
Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Bard Liao <yung-chuan.liao@linux.intel.com>
Vinod Koul <vkoul@kernel.org>
Description: SoundWire Slave Data Port-0 DisCo properties.
These properties are defined by MIPI DisCo Specification
for the SoundWire. They define various properties of the
Data port 0 are used by the bus to configure the Data Port 0.
What: /sys/bus/soundwire/devices/sdw:.../dpN_src/max_word
/sys/bus/soundwire/devices/sdw:.../dpN_src/min_word
/sys/bus/soundwire/devices/sdw:.../dpN_src/words
/sys/bus/soundwire/devices/sdw:.../dpN_src/type
/sys/bus/soundwire/devices/sdw:.../dpN_src/max_grouping
/sys/bus/soundwire/devices/sdw:.../dpN_src/simple_ch_prep_sm
/sys/bus/soundwire/devices/sdw:.../dpN_src/ch_prep_timeout
/sys/bus/soundwire/devices/sdw:.../dpN_src/imp_def_interrupts
/sys/bus/soundwire/devices/sdw:.../dpN_src/min_ch
/sys/bus/soundwire/devices/sdw:.../dpN_src/max_ch
/sys/bus/soundwire/devices/sdw:.../dpN_src/channels
/sys/bus/soundwire/devices/sdw:.../dpN_src/ch_combinations
/sys/bus/soundwire/devices/sdw:.../dpN_src/max_async_buffer
/sys/bus/soundwire/devices/sdw:.../dpN_src/block_pack_mode
/sys/bus/soundwire/devices/sdw:.../dpN_src/port_encoding
/sys/bus/soundwire/devices/sdw:.../dpN_sink/max_word
/sys/bus/soundwire/devices/sdw:.../dpN_sink/min_word
/sys/bus/soundwire/devices/sdw:.../dpN_sink/words
/sys/bus/soundwire/devices/sdw:.../dpN_sink/type
/sys/bus/soundwire/devices/sdw:.../dpN_sink/max_grouping
/sys/bus/soundwire/devices/sdw:.../dpN_sink/simple_ch_prep_sm
/sys/bus/soundwire/devices/sdw:.../dpN_sink/ch_prep_timeout
/sys/bus/soundwire/devices/sdw:.../dpN_sink/imp_def_interrupts
/sys/bus/soundwire/devices/sdw:.../dpN_sink/min_ch
/sys/bus/soundwire/devices/sdw:.../dpN_sink/max_ch
/sys/bus/soundwire/devices/sdw:.../dpN_sink/channels
/sys/bus/soundwire/devices/sdw:.../dpN_sink/ch_combinations
/sys/bus/soundwire/devices/sdw:.../dpN_sink/max_async_buffer
/sys/bus/soundwire/devices/sdw:.../dpN_sink/block_pack_mode
/sys/bus/soundwire/devices/sdw:.../dpN_sink/port_encoding
Date: May 2020
Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Bard Liao <yung-chuan.liao@linux.intel.com>
Vinod Koul <vkoul@kernel.org>
Description: SoundWire Slave Data Source/Sink Port-N DisCo properties.
These properties are defined by MIPI DisCo Specification
for SoundWire. They define various properties of the
Source/Sink Data port N and are used by the bus to configure
the Data Port N.

13
Documentation/ABI/testing/sysfs-class-net

@ -124,6 +124,19 @@ Description:
authentication is performed (e.g: 802.1x). 'link_mode' attribute
will also reflect the dormant state.
What: /sys/class/net/<iface>/testing
Date: April 2002
KernelVersion: 5.8
Contact: netdev@vger.kernel.org
Description:
Indicates whether the interface is under test. Possible
values are:
0: interface is not being tested
1: interface is being tested
When an interface is under test, it cannot be expected
to pass packets as normal.
What: /sys/clas/net/<iface>/duplex
Date: October 2009
KernelVersion: 2.6.33

45
Documentation/ABI/testing/sysfs-class-power

@ -74,6 +74,21 @@ Description:
Access: Read, Write
Valid values: 0 - 100 (percent)
What: /sys/class/power_supply/<supply_name>/capacity_error_margin
Date: April 2019
Contact: linux-pm@vger.kernel.org
Description:
Battery capacity measurement becomes unreliable without
recalibration. This values provides the maximum error
margin expected to exist by the fuel gauge in percent.
Values close to 0% will be returned after (re-)calibration
has happened. Over time the error margin will increase.
100% means, that the capacity related values are basically
completely useless.
Access: Read
Valid values: 0 - 100 (percent)
What: /sys/class/power_supply/<supply_name>/capacity_level
Date: June 2009
Contact: linux-pm@vger.kernel.org
@ -190,7 +205,7 @@ Description:
Valid values: "Unknown", "Good", "Overheat", "Dead",
"Over voltage", "Unspecified failure", "Cold",
"Watchdog timer expire", "Safety timer expire",
"Over current"
"Over current", "Calibration required"
What: /sys/class/power_supply/<supply_name>/precharge_current
Date: June 2017
@ -665,3 +680,31 @@ Description:
Valid values:
- 1: enabled
- 0: disabled
What: /sys/class/power_supply/<supply_name>/manufacture_year
Date: January 2020
Contact: linux-pm@vger.kernel.org
Description:
Reports the year (following Gregorian calendar) when the device has been
manufactured.
Access: Read
Valid values: Reported as integer
What: /sys/class/power_supply/<supply_name>/manufacture_month
Date: January 2020
Contact: linux-pm@vger.kernel.org
Description:
Reports the month when the device has been manufactured.
Access: Read
Valid values: 1-12
What: /sys/class/power_supply/<supply_name>/manufacture_day
Date: January 2020
Contact: linux-pm@vger.kernel.org
Description:
Reports the day of month when the device has been manufactured.
Access: Read
Valid values: 1-31

8
Documentation/ABI/testing/sysfs-class-power-mp2629 Normal file

@ -0,0 +1,8 @@
What: /sys/class/power_supply/mp2629_battery/batt_impedance_compen
Date: April 2020
KernelVersion: 5.7
Description:
Represents a battery impedance compensation to accelerate charging.
Access: Read, Write
Valid values: Represented in milli-ohms. Valid range is [0, 140].

111
Documentation/ABI/testing/sysfs-class-rnbd-client Normal file

@ -0,0 +1,111 @@
What: /sys/class/rnbd-client
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Provide information about RNBD-client.
All sysfs files that are not read-only provide the usage information on read:
Example:
# cat /sys/class/rnbd-client/ctl/map_device
> Usage: echo "sessname=<name of the rtrs session> path=<[srcaddr,]dstaddr>
> [path=<[srcaddr,]dstaddr>] device_path=<full path on remote side>
> [access_mode=<ro|rw|migration>] > map_device
>
> addr ::= [ ip:<ipv4> | ip:<ipv6> | gid:<gid> ]
What: /sys/class/rnbd-client/ctl/map_device
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Expected format is the following:
sessname=<name of the rtrs session>
path=<[srcaddr,]dstaddr> [path=<[srcaddr,]dstaddr> ...]
device_path=<full path on remote side>
[access_mode=<ro|rw|migration>]
Where:
sessname: accepts a string not bigger than 256 chars, which identifies
a given session on the client and on the server.
I.e. "clt_hostname-srv_hostname" could be a natural choice.
path: describes a connection between the client and the server by
specifying destination and, when required, the source address.
The addresses are to be provided in the following format:
ip:<IPv6>
ip:<IPv4>
gid:<GID>
for example:
path=ip:10.0.0.66
The single addr is treated as the destination.
The connection will be established to this server from any client IP address.
path=ip:10.0.0.66,ip:10.0.1.66
First addr is the source address and the second is the destination.
If multiple "path=" options are specified multiple connection
will be established and data will be sent according to
the selected multipath policy (see RTRS mp_policy sysfs entry description).
device_path: Path to the block device on the server side. Path is specified
relative to the directory on server side configured in the
'dev_search_path' module parameter of the rnbd_server.
The rnbd_server prepends the <device_path> received from client
with <dev_search_path> and tries to open the
<dev_search_path>/<device_path> block device. On success,
a /dev/rnbd<N> device file, a /sys/block/rnbd_client/rnbd<N>/
directory and an entry in /sys/class/rnbd-client/ctl/devices
will be created.
If 'dev_search_path' contains '%SESSNAME%', then each session can
have different devices namespace, e.g. server was configured with
the following parameter "dev_search_path=/run/rnbd-devs/%SESSNAME%",
client has this string "sessname=blya device_path=sda", then server
will try to open: /run/rnbd-devs/blya/sda.
access_mode: the access_mode parameter specifies if the device is to be
mapped as "ro" read-only or "rw" read-write. The server allows
a device to be exported in rw mode only once. The "migration"
access mode has to be specified if a second mapping in read-write
mode is desired.
By default "rw" is used.
Exit Codes:
If the device is already mapped it will fail with EEXIST. If the input
has an invalid format it will return EINVAL. If the device path cannot
be found on the server, it will fail with ENOENT.
Finding device file after mapping
---------------------------------
After mapping, the device file can be found by:
o The symlink /sys/class/rnbd-client/ctl/devices/<device_id>
points to /sys/block/<dev-name>. The last part of the symlink destination
is the same as the device name. By extracting the last part of the
path the path to the device /dev/<dev-name> can be build.
o /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>/dev)
How to find the <device_id> of the device is described on the next
section.
What: /sys/class/rnbd-client/ctl/devices/
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: For each device mapped on the client a new symbolic link is created as
/sys/class/rnbd-client/ctl/devices/<device_id>, which points
to the block device created by rnbd (/sys/block/rnbd<N>/).
The <device_id> of each device is created as follows:
- If the 'device_path' provided during mapping contains slashes ("/"),
they are replaced by exclamation mark ("!") and used as as the
<device_id>. Otherwise, the <device_id> will be the same as the
"device_path" provided.

50
Documentation/ABI/testing/sysfs-class-rnbd-server Normal file

@ -0,0 +1,50 @@
What: /sys/class/rnbd-server
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: provide information about RNBD-server.
What: /sys/class/rnbd-server/ctl/
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: When a client maps a device, a directory entry with the name of the
block device is created under /sys/class/rnbd-server/ctl/devices/.
What: /sys/class/rnbd-server/ctl/devices/<device_name>/block_dev
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Is a symlink to the sysfs entry of the exported device.
Example:
block_dev -> ../../../../class/block/ram0
What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: For each client a particular device is exported to, following directory will be
created:
/sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/
When the device is unmapped by that client, the directory will be removed.
What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/read_only
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains '1' if device is mapped read-only, otherwise '0'.
What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/mapping_path
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the relative device path provided by the user during mapping.
What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/access_mode
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the device access mode: ro, rw or migration.

131
Documentation/ABI/testing/sysfs-class-rtrs-client Normal file

@ -0,0 +1,131 @@
What: /sys/class/rtrs-client
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: When a user of RTRS API creates a new session, a directory entry with
the name of that session is created under /sys/class/rtrs-client/<session-name>/
What: /sys/class/rtrs-client/<session-name>/add_path
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RW, adds a new path (connection) to an existing session. Expected format is the
following:
<[source addr,]destination addr>
*addr ::= [ ip:<ipv4|ipv6> | gid:<gid> ]
What: /sys/class/rtrs-client/<session-name>/max_reconnect_attempts
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Maximum number reconnect attempts the client should make before giving up
after connection breaks unexpectedly.
What: /sys/class/rtrs-client/<session-name>/mp_policy
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Multipath policy specifies which path should be selected on each IO:
round-robin (0):
select path in per CPU round-robin manner.
min-inflight (1):
select path with minimum inflights.
What: /sys/class/rtrs-client/<session-name>/paths/
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Each path belonging to a given session is listed here by its source and
destination address. When a new path is added to a session by writing to
the "add_path" entry, a directory <src@dst> is created.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/state
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains "connected" if the session is connected to the peer and fully
functional. Otherwise the file contains "disconnected"
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/reconnect
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Write "1" to the file in order to reconnect the path.
Operation is blocking and returns 0 if reconnect was successful.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/disconnect
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Write "1" to the file in order to disconnect the path.
Operation blocks until RTRS path is disconnected.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/remove_path
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Write "1" to the file in order to disconnected and remove the path
from the session. Operation blocks until the path is disconnected
and removed from the session.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_name
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the the name of HCA the connection established on.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_port
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the port number of active port traffic is going through.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/src_addr
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the source address of the path
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/dst_addr
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the destination address of the path
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reset_all
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RW, Read will return usage help, write 0 will clear all the statistics.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/cpu_migration
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RTRS expects that each HCA IRQ is pinned to a separate CPU. If it's
not the case, the processing of an I/O response could be processed on a
different CPU than where it was originally submitted. This file shows
how many interrupts where generated on a non expected CPU.
"from:" is the CPU on which the IRQ was expected, but not generated.
"to:" is the CPU on which the IRQ was generated, but not expected.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reconnects
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains 2 unsigned int values, the first one records number of successful
reconnects in the path lifetime, the second one records number of failed
reconnects in the path lifetime.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/rdma
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains statistics regarding rdma operations and inflight operations.
The output consists of 6 values:
<read-count> <read-total-size> <write-count> <write-total-size> \
<inflights> <failovered>

53
Documentation/ABI/testing/sysfs-class-rtrs-server Normal file

@ -0,0 +1,53 @@
What: /sys/class/rtrs-server
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: When a user of RTRS API creates a new session on a client side, a
directory entry with the name of that session is created in here.
What: /sys/class/rtrs-server/<session-name>/paths/
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: When new path is created by writing to "add_path" entry on client side,
a directory entry named as <source address>@<destination address> is created
on server.
What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/disconnect
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: When "1" is written to the file, the RTRS session is being disconnected.
Operations is non-blocking and returns control immediately to the caller.
What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_name
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the the name of HCA the connection established on.
What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_port
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the port number of active port traffic is going through.
What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/src_addr
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the source address of the path
What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/dst_addr
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the destination address of the path
What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/stats/rdma
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains statistics regarding rdma operations and inflight operations.
The output consists of 5 values:
<read-count> <read-total-size> <write-count> <write-total-size> <inflights>

64
Documentation/ABI/testing/sysfs-devices-system-cpu

@ -106,10 +106,10 @@ Description: CPU topology files that describe a logical CPU's relationship
See Documentation/admin-guide/cputopology.rst for more information.
What: /sys/devices/system/cpu/cpuidle/current_driver
/sys/devices/system/cpu/cpuidle/current_governer_ro
/sys/devices/system/cpu/cpuidle/available_governors
What: /sys/devices/system/cpu/cpuidle/available_governors
/sys/devices/system/cpu/cpuidle/current_driver
/sys/devices/system/cpu/cpuidle/current_governor
/sys/devices/system/cpu/cpuidle/current_governer_ro
Date: September 2007
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Discover cpuidle policy and mechanism
@ -119,24 +119,18 @@ Description: Discover cpuidle policy and mechanism
consumption during idle.
Idle policy (governor) is differentiated from idle mechanism
(driver)
current_driver: (RO) displays current idle mechanism
current_governor_ro: (RO) displays current idle policy
With the cpuidle_sysfs_switch boot option enabled (meant for
developer testing), the following three attributes are visible
instead:
current_driver: same as described above
(driver).
available_governors: (RO) displays a space separated list of
available governors
available governors.
current_driver: (RO) displays current idle mechanism.
current_governor: (RW) displays current idle policy. Users can
switch the governor at runtime by writing to this file.
current_governor_ro: (RO) displays current idle policy.
See Documentation/admin-guide/pm/cpuidle.rst and
Documentation/driver-api/pm/cpuidle.rst for more information.
@ -492,6 +486,7 @@ What: /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
/sys/devices/system/cpu/vulnerabilities/l1tf
/sys/devices/system/cpu/vulnerabilities/mds
/sys/devices/system/cpu/vulnerabilities/srbds
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
Date: January 2018
@ -580,3 +575,42 @@ Description: Secure Virtual Machine
If 1, it means the system is using the Protected Execution
Facility in POWER9 and newer processors. i.e., it is a Secure
Virtual Machine.
What: /sys/devices/system/cpu/cpuX/purr
Date: Apr 2005
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: PURR ticks for this CPU since the system boot.
The Processor Utilization Resources Register (PURR) is
a 64-bit counter which provides an estimate of the
resources used by the CPU thread. The contents of this
register increases monotonically. This sysfs interface
exposes the number of PURR ticks for cpuX.
What: /sys/devices/system/cpu/cpuX/spurr
Date: Dec 2006
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: SPURR ticks for this CPU since the system boot.
The Scaled Processor Utilization Resources Register
(SPURR) is a 64-bit counter that provides a frequency
invariant estimate of the resources used by the CPU
thread. The contents of this register increases
monotonically. This sysfs interface exposes the number
of SPURR ticks for cpuX.
What: /sys/devices/system/cpu/cpuX/idle_purr
Date: Apr 2020
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: PURR ticks for cpuX when it was idle.
This sysfs interface exposes the number of PURR ticks
for cpuX when it was idle.
What: /sys/devices/system/cpu/cpuX/idle_spurr
Date: Apr 2020
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: SPURR ticks for cpuX when it was idle.
This sysfs interface exposes the number of SPURR ticks
for cpuX when it was idle.

17
Documentation/ABI/testing/sysfs-driver-habanalabs

@ -10,6 +10,23 @@ KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Version of the application running on the device's CPU
What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz
Date: Jun 2019
KernelVersion: not yet upstreamed
Contact: oded.gabbay@gmail.com
Description: Allows the user to set the maximum clock frequency, in MHz.
The device clock might be set to lower value than the maximum.
The user should read the clk_cur_freq_mhz to see the actual
frequency value of the device clock. This property is valid
only for the Gaudi ASIC family
What: /sys/class/habanalabs/hl<n>/clk_cur_freq_mhz
Date: Jun 2019
KernelVersion: not yet upstreamed
Contact: oded.gabbay@gmail.com
Description: Displays the current frequency, in MHz, of the device clock.
This property is valid only for the Gaudi ASIC family
What: /sys/class/habanalabs/hl<n>/cpld_ver
Date: Jan 2019
KernelVersion: 5.1

116
Documentation/ABI/testing/sysfs-driver-w1_therm Normal file

@ -0,0 +1,116 @@
What: /sys/bus/w1/devices/.../alarms
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RW) read or write TH and TL (Temperature High an Low) alarms.
Values shall be space separated and in the device range
(typical -55 degC to 125 degC), if not values will be trimmed
to device min/max capabilities. Values are integer as they are
stored in a 8bit register in the device. Lowest value is
automatically put to TL. Once set, alarms could be search at
master level, refer to Documentation/w1/w1_generic.rst for
detailed information
Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/.../eeprom
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(WO) writing that file will either trigger a save of the
device data to its embedded EEPROM, either restore data
embedded in device EEPROM. Be aware that devices support
limited EEPROM writing cycles (typical 50k)
* 'save': save device RAM to EEPROM
* 'restore': restore EEPROM data in device RAM
Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/.../ext_power
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RO) return the power status by asking the device
* '0': device parasite powered
* '1': device externally powered
* '-xx': xx is kernel error when reading power status
Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/.../resolution
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RW) get or set the device resolution (on supported devices,
if not, this entry is not present). Note that the resolution
will be changed only in device RAM, so it will be cleared when
power is lost. Trigger a 'save' to EEPROM command to keep
values after power-on. Read or write are :
* '9..12': device resolution in bit
or resolution to set in bit
* '-xx': xx is kernel error when reading the resolution
* Anything else: do nothing
Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/.../temperature
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RO) return the temperature in 1/1000 degC.
* If a bulk read has been triggered, it will directly
return the temperature computed when the bulk read
occurred, if available. If not yet available, nothing
is returned (a debug kernel message is sent), you
should retry later on.
* If no bulk read has been triggered, it will trigger
a conversion and send the result. Note that the
conversion duration depend on the resolution (if
device support this feature). It takes 94ms in 9bits
resolution, 750ms for 12bits.
Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/.../w1_slave
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RW) return the temperature in 1/1000 degC.
*read*: return 2 lines with the hexa output data sent on the
bus, return the CRC check and temperature in 1/1000 degC
*write* :
* '0' : save the 2 or 3 bytes to the device EEPROM
(i.e. TH, TL and config register)
* '9..12' : set the device resolution in RAM
(if supported)
* Anything else: do nothing
refer to Documentation/w1/slaves/w1_therm.rst for detailed
information.
Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/w1_bus_masterXX/therm_bulk_read
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RW) trigger a bulk read conversion. read the status
*read*:
* '-1': conversion in progress on at least 1 sensor
* '1' : conversion complete but at least one sensor
value has not been read yet
* '0' : no bulk operation. Reading temperature will
trigger a conversion on each device
*write*: 'trigger': trigger a bulk read on all supporting
devices on the bus
Note that if a bulk read is sent but one sensor is not read
immediately, the next access to temperature on this device
will return the temperature measured at the time of issue
of the bulk read command (not the current temperature).
Users: any user space application which wants to communicate with
w1_term device

24
Documentation/ABI/testing/sysfs-fs-f2fs

@ -323,3 +323,27 @@ What: /sys/fs/f2fs/<disk>/mounted_time_sec
Date: February 2020
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Show the mounted time in secs of this partition.
What: /sys/fs/f2fs/<disk>/data_io_flag
Date: April 2020
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Give a way to attach REQ_META|FUA to data writes
given temperature-based bits. Now the bits indicate:
* REQ_META | REQ_FUA |
* 5 | 4 | 3 | 2 | 1 | 0 |
* Cold | Warm | Hot | Cold | Warm | Hot |
What: /sys/fs/f2fs/<disk>/node_io_flag
Date: June 2020
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Give a way to attach REQ_META|FUA to node writes
given temperature-based bits. Now the bits indicate:
* REQ_META | REQ_FUA |
* 5 | 4 | 3 | 2 | 1 | 0 |
* Cold | Warm | Hot | Cold | Warm | Hot |
What: /sys/fs/f2fs/<disk>/iostat_period_ms
Date: April 2020
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Give a way to change iostat_period time. 3secs by default.
The new iostat trace gives stats gap given the period.

62
Documentation/ABI/testing/sysfs-platform-dptf

@ -27,10 +27,12 @@ KernelVersion: v4.10
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Display the platform power source
0x00 = DC
0x01 = AC
0x02 = USB
0x03 = Wireless Charger
bits[3:0] Current power source
0x00 = DC
0x01 = AC
0x02 = USB
0x03 = Wireless Charger
bits[7:4] Power source sequence number
What: /sys/bus/platform/devices/INT3407:00/dptf_power/battery_steady_power
Date: Jul, 2016
@ -38,3 +40,55 @@ KernelVersion: v4.10
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The maximum sustained power for battery in milliwatts.
What: /sys/bus/platform/devices/INT3407:00/dptf_power/rest_of_platform_power_mw
Date: June, 2020
KernelVersion: v5.8
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Shows the rest (outside of SoC) of worst-case platform power.
What: /sys/bus/platform/devices/INT3407:00/dptf_power/prochot_confirm
Date: June, 2020
KernelVersion: v5.8
Contact: linux-acpi@vger.kernel.org
Description:
(WO) Confirm embedded controller about a prochot notification.
What: /sys/bus/platform/devices/INT3532:00/dptf_battery/max_platform_power_mw
Date: June, 2020
KernelVersion: v5.8
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The maximum platform power that can be supported by the battery in milli watts.
What: /sys/bus/platform/devices/INT3532:00/dptf_battery/max_steady_state_power_mw
Date: June, 2020
KernelVersion: v5.8
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The maximum sustained power for battery in milli watts.
What: /sys/bus/platform/devices/INT3532:00/dptf_battery/high_freq_impedance_mohm
Date: June, 2020
KernelVersion: v5.8
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The high frequency impedance value that can be obtained from battery
fuel gauge in milli Ohms.
What: /sys/bus/platform/devices/INT3532:00/dptf_battery/no_load_voltage_mv
Date: June, 2020
KernelVersion: v5.8
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The no-load voltage that can be obtained from battery fuel gauge in
milli volts.
What: /sys/bus/platform/devices/INT3532:00/dptf_battery/current_discharge_capbility_ma
Date: June, 2020
KernelVersion: v5.8
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The battery discharge current capability obtained from battery fuel gauge in
milli Amps.

12
Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update Normal file

@ -0,0 +1,12 @@
What: /sys/bus/wmi/devices/44FADEB1-B204-40F2-8581-394BBDC1B651/firmware_update_request
Date: April 2020
KernelVersion: 5.7
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description:
Allow user space entities to trigger update of Slim
Bootloader (SBL). This attribute normally has a value
of 0 and userspace can signal SBL to update firmware,
on next reboot, by writing a value of 1.
There are two available states:
* 0 -> Skip firmware update while rebooting
* 1 -> Attempt firmware update on next reboot

2
Documentation/COPYING-logo

@ -9,5 +9,5 @@ scale down to smaller sizes and are better for letterheads or whatever
you want to use it for: for the full range of logos take a look at
Larry's web-page:
http://www.isc.tamu.edu/~lewing/linux/
https://www.isc.tamu.edu/~lewing/linux/

269
Documentation/IRQ-domain.txt

@ -1,269 +0,0 @@
===============================================
The irq_domain interrupt number mapping library
===============================================
The current design of the Linux kernel uses a single large number
space where each separate IRQ source is assigned a different number.
This is simple when there is only one interrupt controller, but in
systems with multiple interrupt controllers the kernel must ensure
that each one gets assigned non-overlapping allocations of Linux
IRQ numbers.
The number of interrupt controllers registered as unique irqchips
show a rising tendency: for example subdrivers of different kinds
such as GPIO controllers avoid reimplementing identical callback
mechanisms as the IRQ core system by modelling their interrupt
handlers as irqchips, i.e. in effect cascading interrupt controllers.
Here the interrupt number loose all kind of correspondence to
hardware interrupt numbers: whereas in the past, IRQ numbers could
be chosen so they matched the hardware IRQ line into the root
interrupt controller (i.e. the component actually fireing the
interrupt line to the CPU) nowadays this number is just a number.
For this reason we need a mechanism to separate controller-local
interrupt numbers, called hardware irq's, from Linux IRQ numbers.
The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
irq numbers, but they don't provide any support for reverse mapping of
the controller-local IRQ (hwirq) number into the Linux IRQ number
space.
The irq_domain library adds mapping between hwirq and IRQ numbers on
top of the irq_alloc_desc*() API. An irq_domain to manage mapping is
preferred over interrupt controller drivers open coding their own
reverse mapping scheme.
irq_domain also implements translation from an abstract irq_fwspec
structure to hwirq numbers (Device Tree and ACPI GSI so far), and can
be easily extended to support other IRQ topology data sources.
irq_domain usage
================
An interrupt controller driver creates and registers an irq_domain by
calling one of the irq_domain_add_*() functions (each mapping method
has a different allocator function, more on that later). The function
will return a pointer to the irq_domain on success. The caller must
provide the allocator function with an irq_domain_ops structure.
In most cases, the irq_domain will begin empty without any mappings
between hwirq and IRQ numbers. Mappings are added to the irq_domain
by calling irq_create_mapping() which accepts the irq_domain and a
hwirq number as arguments. If a mapping for the hwirq doesn't already
exist then it will allocate a new Linux irq_desc, associate it with
the hwirq, and call the .map() callback so the driver can perform any
required hardware setup.
When an interrupt is received, irq_find_mapping() function should
be used to find the Linux IRQ number from the hwirq number.
The irq_create_mapping() function must be called *atleast once*
before any call to irq_find_mapping(), lest the descriptor will not
be allocated.
If the driver has the Linux IRQ number or the irq_data pointer, and
needs to know the associated hwirq number (such as in the irq_chip
callbacks) then it can be directly obtained from irq_data->hwirq.
Types of irq_domain mappings
============================
There are several mechanisms available for reverse mapping from hwirq
to Linux irq, and each mechanism uses a different allocation function.
Which reverse map type should be used depends on the use case. Each
of the reverse map types are described below:
Linear
------
::
irq_domain_add_linear()
irq_domain_create_linear()
The linear reverse map maintains a fixed size table indexed by the
hwirq number. When a hwirq is mapped, an irq_desc is allocated for
the hwirq, and the IRQ number is stored in the table.
The Linear map is a good choice when the maximum number of hwirqs is
fixed and a relatively small number (~ < 256). The advantages of this
map are fixed time lookup for IRQ numbers, and irq_descs are only
allocated for in-use IRQs. The disadvantage is that the table must be
as large as the largest possible hwirq number.
irq_domain_add_linear() and irq_domain_create_linear() are functionally
equivalent, except for the first argument is different - the former
accepts an Open Firmware specific 'struct device_node', while the latter
accepts a more general abstraction 'struct fwnode_handle'.
The majority of drivers should use the linear map.
Tree
----
::
irq_domain_add_tree()
irq_domain_create_tree()
The irq_domain maintains a radix tree map from hwirq numbers to Linux
IRQs. When an hwirq is mapped, an irq_desc is allocated and the
hwirq is used as the lookup key for the radix tree.
The tree map is a good choice if the hwirq number can be very large
since it doesn't need to allocate a table as large as the largest
hwirq number. The disadvantage is that hwirq to IRQ number lookup is
dependent on how many entries are in the table.
irq_domain_add_tree() and irq_domain_create_tree() are functionally
equivalent, except for the first argument is different - the former
accepts an Open Firmware specific 'struct device_node', while the latter
accepts a more general abstraction 'struct fwnode_handle'.
Very few drivers should need this mapping.
No Map
------
::
irq_domain_add_nomap()
The No Map mapping is to be used when the hwirq number is
programmable in the hardware. In this case it is best to program the
Linux IRQ number into the hardware itself so that no mapping is
required. Calling irq_create_direct_mapping() will allocate a Linux
IRQ number and call the .map() callback so that driver can program the
Linux IRQ number into the hardware.
Most drivers cannot use this mapping.
Legacy
------
::
irq_domain_add_simple()
irq_domain_add_legacy()
irq_domain_add_legacy_isa()
The Legacy mapping is a special case for drivers that already have a
range of irq_descs allocated for the hwirqs. It is used when the
driver cannot be immediately converted to use the linear mapping. For
example, many embedded system board support files use a set of #defines
for IRQ numbers that are passed to struct device registrations. In that
case the Linux IRQ numbers cannot be dynamically assigned and the legacy
mapping should be used.
The legacy map assumes a contiguous range of IRQ numbers has already
been allocated for the controller and that the IRQ number can be
calculated by adding a fixed offset to the hwirq number, and
visa-versa. The disadvantage is that it requires the interrupt
controller to manage IRQ allocations and it requires an irq_desc to be
allocated for every hwirq, even if it is unused.
The legacy map should only be used if fixed IRQ mappings must be
supported. For example, ISA controllers would use the legacy map for
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
numbers.
Most users of legacy mappings should use irq_domain_add_simple() which
will use a legacy domain only if an IRQ range is supplied by the
system and will otherwise use a linear domain mapping. The semantics
of this call are such that if an IRQ range is specified then
descriptors will be allocated on-the-fly for it, and if no range is
specified it will fall through to irq_domain_add_linear() which means
*no* irq descriptors will be allocated.
A typical use case for simple domains is where an irqchip provider
is supporting both dynamic and static IRQ assignments.
In order to avoid ending up in a situation where a linear domain is
used and no descriptor gets allocated it is very important to make sure
that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
Hierarchy IRQ domain
--------------------
On some architectures, there may be multiple interrupt controllers
involved in delivering an interrupt from the device to the target CPU.
Let's look at a typical interrupt delivering path on x86 platforms::
Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU
There are three interrupt controllers involved:
1) IOAPIC controller
2) Interrupt remapping controller
3) Local APIC controller
To support such a hardware topology and make software architecture match
hardware architecture, an irq_domain data structure is built for each
interrupt controller and those irq_domains are organized into hierarchy.
When building irq_domain hierarchy, the irq_domain near to the device is
child and the irq_domain near to CPU is parent. So a hierarchy structure
as below will be built for the example above::
CPU Vector irq_domain (root irq_domain to manage CPU vectors)
^
|
Interrupt Remapping irq_domain (manage irq_remapping entries)
^
|
IOAPIC irq_domain (manage IOAPIC delivery entries/pins)
There are four major interfaces to use hierarchy irq_domain:
1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt
controller related resources to deliver these interrupts.
2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller
related resources associated with these interrupts.
3) irq_domain_activate_irq(): activate interrupt controller hardware to
deliver the interrupt.
4) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
to stop delivering the interrupt.
Following changes are needed to support hierarchy irq_domain:
1) a new field 'parent' is added to struct irq_domain; it's used to
maintain irq_domain hierarchy information.
2) a new field 'parent_data' is added to struct irq_data; it's used to
build hierarchy irq_data to match hierarchy irq_domains. The irq_data
is used to store irq_domain pointer and hardware irq number.
3) new callbacks are added to struct irq_domain_ops to support hierarchy
irq_domain operations.
With support of hierarchy irq_domain and hierarchy irq_data ready, an
irq_domain structure is built for each interrupt controller, and an
irq_data structure is allocated for each irq_domain associated with an
IRQ. Now we could go one step further to support stacked(hierarchy)
irq_chip. That is, an irq_chip is associated with each irq_data along
the hierarchy. A child irq_chip may implement a required action by
itself or by cooperating with its parent irq_chip.
With stacked irq_chip, interrupt controller driver only needs to deal
with the hardware managed by itself and may ask for services from its
parent irq_chip when needed. So we could achieve a much cleaner
software architecture.
For an interrupt controller driver to support hierarchy irq_domain, it
needs to:
1) Implement irq_domain_ops.alloc and irq_domain_ops.free
2) Optionally implement irq_domain_ops.activate and
irq_domain_ops.deactivate.
3) Optionally implement an irq_chip to manage the interrupt controller
hardware.
4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,
they are unused with hierarchy irq_domain.
Hierarchy irq_domain is in no way x86 specific, and is heavily used to
support other architectures, such as ARM, ARM64 etc.
=== Debugging ===
Most of the internals of the IRQ subsystem are exposed in debugfs by
turning CONFIG_GENERIC_IRQ_DEBUGFS on.

16
Documentation/Makefile

@ -55,15 +55,15 @@ I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
loop_cmd = $(echo-cmd) $(cmd_$(1)) || exit;
# $2 sphinx builder e.g. "html"
# $3 name of the build subfolder / e.g. "media", used as:
# $3 name of the build subfolder / e.g. "userspace-api/media", used as:
# * dest folder relative to $(BUILDDIR) and
# * cache folder relative to $(BUILDDIR)/.doctrees
# $4 dest subfolder e.g. "man" for man pages at media/man
# $4 dest subfolder e.g. "man" for man pages at userspace-api/media/man
# $5 reST source folder relative to $(srctree)/$(src),
# e.g. "media" for the linux-tv book-set at ./Documentation/media
# e.g. "userspace-api/media" for the linux-tv book-set at ./Documentation/userspace-api/media
quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media $2 && \
cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/userspace-api/media $2 && \
PYTHONDONTWRITEBYTECODE=1 \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(PYTHON) $(srctree)/scripts/jobserver-exec \
@ -98,7 +98,11 @@ else # HAVE_PDFLATEX
pdfdocs: latexdocs
@$(srctree)/scripts/sphinx-pre-install --version-check
$(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit;)
$(foreach var,$(SPHINXDIRS), \
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \
mkdir -p $(BUILDDIR)/$(var)/pdf; \
mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \
)
endif # HAVE_PDFLATEX
@ -120,7 +124,7 @@ refcheckdocs:
cleandocs:
$(Q)rm -rf $(BUILDDIR)
$(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean
$(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/userspace-api/media clean
dochelp:
@echo ' Linux kernel internal documentation in different formats from ReST:'

34
Documentation/PCI/boot-interrupts.rst

@ -32,12 +32,13 @@ interrupt goes unhandled over time, they are tracked by the Linux kernel as
Spurious Interrupts. The IRQ will be disabled by the Linux kernel after it
reaches a specific count with the error "nobody cared". This disabled IRQ
now prevents valid usage by an existing interrupt which may happen to share
the IRQ line.
the IRQ line::
irq 19: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 2988 Comm: irq/34-nipalk Tainted: 4.14.87-rt49-02410-g4a640ec-dirty #1
Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880, BIOS 2.1.5f1 01/09/2020
Call Trace:
<IRQ>
? dump_stack+0x46/0x5e
? __report_bad_irq+0x2e/0xb0
@ -85,15 +86,18 @@ Mitigations
The mitigations take the form of PCI quirks. The preference has been to
first identify and make use of a means to disable the routing to the PCH.
In such a case a quirk to disable boot interrupt generation can be
added.[1]
added. [1]_
Intel® 6300ESB I/O Controller Hub
Intel® 6300ESB I/O Controller Hub
Alternate Base Address Register:
BIE: Boot Interrupt Enable
0 = Boot interrupt is enabled.
1 = Boot interrupt is disabled.
Intel® Sandy Bridge through Sky Lake based Xeon servers:
== ===========================
0 Boot interrupt is enabled.
1 Boot interrupt is disabled.
== ===========================
Intel® Sandy Bridge through Sky Lake based Xeon servers:
Coherent Interface Protocol Interrupt Control
dis_intx_route2pch/dis_intx_route2ich/dis_intx_route2dmi2:
When this bit is set. Local INTx messages received from the
@ -109,12 +113,12 @@ line by default. Therefore, on chipsets where this INTx routing cannot be
disabled, the Linux kernel will reroute the valid interrupt to its legacy
interrupt. This redirection of the handler will prevent the occurrence of
the spurious interrupt detection which would ordinarily disable the IRQ
line due to excessive unhandled counts.[2]
line due to excessive unhandled counts. [2]_
The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS exists to enable (or
disable) the redirection of the interrupt handler to the PCH interrupt
line. The option can be overridden by either pci=ioapicreroute or
pci=noioapicreroute.[3]
pci=noioapicreroute. [3]_
More Documentation
@ -127,19 +131,19 @@ into the evolution of its handling with chipsets.
Example of disabling of the boot interrupt
------------------------------------------
Intel® 6300ESB I/O Controller Hub (Document # 300641-004US)
- Intel® 6300ESB I/O Controller Hub (Document # 300641-004US)
5.7.3 Boot Interrupt
https://www.intel.com/content/dam/doc/datasheet/6300esb-io-controller-hub-datasheet.pdf
Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families
Datasheet - Volume 2: Registers (Document # 330784-003)
- Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families
Datasheet - Volume 2: Registers (Document # 330784-003)
6.6.41 cipintrc Coherent Interface Protocol Interrupt Control
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-v3-datasheet-vol-2.pdf
Example of handler rerouting
----------------------------
Intel® 6700PXH 64-bit PCI Hub (Document # 302628)
- Intel® 6700PXH 64-bit PCI Hub (Document # 302628)
2.15.2 PCI Express Legacy INTx Support and Boot Interrupt
https://www.intel.com/content/dam/doc/datasheet/6700pxh-64-bit-pci-hub-datasheet.pdf
@ -150,6 +154,6 @@ Cheers,
Sean V Kelley
sean.v.kelley@linux.intel.com
[1] https://lore.kernel.org/r/12131949181903-git-send-email-sassmann@suse.de/
[2] https://lore.kernel.org/r/12131949182094-git-send-email-sassmann@suse.de/
[3] https://lore.kernel.org/r/487C8EA7.6020205@suse.de/
.. [1] https://lore.kernel.org/r/12131949181903-git-send-email-sassmann@suse.de/
.. [2] https://lore.kernel.org/r/12131949182094-git-send-email-sassmann@suse.de/
.. [3] https://lore.kernel.org/r/487C8EA7.6020205@suse.de/

16
Documentation/PCI/endpoint/pci-endpoint.rst

@ -78,8 +78,8 @@ by the PCI controller driver.
Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init().
APIs for the PCI Endpoint Function Driver
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EPC APIs for the PCI Endpoint Function Driver
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section lists the APIs that the PCI Endpoint core provides to be used
by the PCI endpoint function driver.
@ -117,8 +117,8 @@ by the PCI endpoint function driver.
The PCI endpoint function driver should use pci_epc_mem_free_addr() to
free the memory space allocated using pci_epc_mem_alloc_addr().
Other APIs
~~~~~~~~~~
Other EPC APIs
~~~~~~~~~~~~~~
There are other APIs provided by the EPC library. These are used for binding
the EPF device with EPC device. pci-ep-cfs.c can be used as reference for
@ -160,8 +160,8 @@ PCI Endpoint Function(EPF) Library
The EPF library provides APIs to be used by the function driver and the EPC
library to provide endpoint mode functionality.
APIs for the PCI Endpoint Function Driver
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EPF APIs for the PCI Endpoint Function Driver
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section lists the APIs that the PCI Endpoint core provides to be used
by the PCI endpoint function driver.
@ -204,8 +204,8 @@ by the PCI endpoint controller library.
The PCI endpoint controller library invokes pci_epf_linkup() when the
EPC device has established the connection to the host.
Other APIs
~~~~~~~~~~
Other EPF APIs
~~~~~~~~~~~~~~
There are other APIs provided by the EPF library. These are used to notify
the function driver when the EPF device is bound to the EPC device.

59
Documentation/RCU/Design/Requirements/Requirements.rst

@ -1943,56 +1943,27 @@ invoked from a CPU-hotplug notifier.
Scheduler and RCU
~~~~~~~~~~~~~~~~~
RCU depends on the scheduler, and the scheduler uses RCU to protect some
of its data structures. The preemptible-RCU ``rcu_read_unlock()``
implementation must therefore be written carefully to avoid deadlocks
involving the scheduler's runqueue and priority-inheritance locks. In
particular, ``rcu_read_unlock()`` must tolerate an interrupt where the
interrupt handler invokes both ``rcu_read_lock()`` and
``rcu_read_unlock()``. This possibility requires ``rcu_read_unlock()``
to use negative nesting levels to avoid destructive recursion via
interrupt handler's use of RCU.
This scheduler-RCU requirement came as a `complete
surprise <https://lwn.net/Articles/453002/>`__.
As noted above, RCU makes use of kthreads, and it is necessary to avoid
excessive CPU-time accumulation by these kthreads. This requirement was
no surprise, but RCU's violation of it when running context-switch-heavy
workloads when built with ``CONFIG_NO_HZ_FULL=y`` `did come as a
surprise
RCU makes use of kthreads, and it is necessary to avoid excessive CPU-time
accumulation by these kthreads. This requirement was no surprise, but
RCU's violation of it when running context-switch-heavy workloads when
built with ``CONFIG_NO_HZ_FULL=y`` `did come as a surprise
[PDF] <http://www.rdrop.com/users/paulmck/scalability/paper/BareMetal.2015.01.15b.pdf>`__.
RCU has made good progress towards meeting this requirement, even for
context-switch-heavy ``CONFIG_NO_HZ_FULL=y`` workloads, but there is
room for further improvement.
It is forbidden to hold any of scheduler's runqueue or
priority-inheritance spinlocks across an ``rcu_read_unlock()`` unless
interrupts have been disabled across the entire RCU read-side critical
section, that is, up to and including the matching ``rcu_read_lock()``.
Violating this restriction can result in deadlocks involving these
scheduler spinlocks. There was hope that this restriction might be
lifted when interrupt-disabled calls to ``rcu_read_unlock()`` started
deferring the reporting of the resulting RCU-preempt quiescent state
until the end of the corresponding interrupts-disabled region.
Unfortunately, timely reporting of the corresponding quiescent state to
expedited grace periods requires a call to ``raise_softirq()``, which
can acquire these scheduler spinlocks. In addition, real-time systems
using RCU priority boosting need this restriction to remain in effect
because deferred quiescent-state reporting would also defer deboosting,
which in turn would degrade real-time latencies.
There is no longer any prohibition against holding any of
scheduler's runqueue or priority-inheritance spinlocks across an
``rcu_read_unlock()``, even if interrupts and preemption were enabled
somewhere within the corresponding RCU read-side critical section.
Therefore, it is now perfectly legal to execute ``rcu_read_lock()``
with preemption enabled, acquire one of the scheduler locks, and hold
that lock across the matching ``rcu_read_unlock()``.
In theory, if a given RCU read-side critical section could be guaranteed
to be less than one second in duration, holding a scheduler spinlock
across that critical section's ``rcu_read_unlock()`` would require only
that preemption be disabled across the entire RCU read-side critical
section, not interrupts. Unfortunately, given the possibility of vCPU
preemption, long-running interrupts, and so on, it is not possible in
practice to guarantee that a given RCU read-side critical section will
complete in less than one second. Therefore, as noted above, if
scheduler spinlocks are held across a given call to
``rcu_read_unlock()``, interrupts must be disabled across the entire RCU
read-side critical section.
Similarly, the RCU flavor consolidation has removed the need for negative
nesting. The fact that interrupt-disabled regions of code act as RCU
read-side critical sections implicitly avoids earlier issues that used
to result in destructive recursion via interrupt handler's use of RCU.
Tracing and RCU
~~~~~~~~~~~~~~~

16
Documentation/admin-guide/LSM/tomoyo.rst

@ -27,29 +27,29 @@ Where is documentation?
=======================
User <-> Kernel interface documentation is available at
http://tomoyo.osdn.jp/2.5/policy-specification/index.html .
https://tomoyo.osdn.jp/2.5/policy-specification/index.html .
Materials we prepared for seminars and symposiums are available at
http://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 .
https://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 .
Below lists are chosen from three aspects.
What is TOMOYO?
TOMOYO Linux Overview
http://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf
https://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf
TOMOYO Linux: pragmatic and manageable security for Linux
http://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf
https://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf
TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box
http://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf
https://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf
What can TOMOYO do?
Deep inside TOMOYO Linux
http://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf
https://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf
The role of "pathname based access control" in security.
http://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf
https://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf
History of TOMOYO?
Realities of Mainlining
http://osdn.jp/projects/tomoyo/docs/lfj2008.pdf
https://osdn.jp/projects/tomoyo/docs/lfj2008.pdf
What is future plan?
====================

11
Documentation/admin-guide/README.rst

@ -209,15 +209,22 @@ Configuring the kernel
store the lsmod of that machine into a file
and pass it in as a LSMOD parameter.
Also, you can preserve modules in certain folders
or kconfig files by specifying their paths in
parameter LMC_KEEP.
target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp
host$ make LSMOD=/tmp/mylsmod localmodconfig
host$ make LSMOD=/tmp/mylsmod \
LMC_KEEP="drivers/usb:drivers/gpu:fs" \
localmodconfig
The above also works when cross compiling.
"make localyesconfig" Similar to localmodconfig, except it will convert
all module options to built in (=y) options.
all module options to built in (=y) options. You can
also preserve modules by LMC_KEEP.
"make kvmconfig" Enable additional options for kvm guest kernel support.

2
Documentation/admin-guide/acpi/initrd_table_override.rst

@ -102,7 +102,7 @@ Where to retrieve userspace tools
=================================
iasl and acpixtract are part of Intel's ACPICA project:
http://acpica.org/
https://acpica.org/
and should be packaged by distributions (for example in the acpica package
on SUSE).

2
Documentation/admin-guide/acpi/ssdt-overlays.rst

@ -63,7 +63,7 @@ which can then be compiled to AML binary format::
ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords
AML Output: minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes
[1] http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29
[1] https://www.elinux.org/Minnowboard:MinnowMax#Low_Speed_Expansion_.28Top.29
The resulting AML code can then be loaded by the kernel using one of the methods
below.

4
Documentation/admin-guide/bcache.rst

@ -7,9 +7,9 @@ nice if you could use them as cache... Hence bcache.
Wiki and git repositories are at:
- http://bcache.evilpiepirate.org
- https://bcache.evilpiepirate.org
- http://evilpiepirate.org/git/linux-bcache.git
- http://evilpiepirate.org/git/bcache-tools.git
- https://evilpiepirate.org/git/bcache-tools.git
It's designed around the performance characteristics of SSDs - it only allocates
in erase block sized buckets, and it uses a hybrid btree/log to track cached

53
Documentation/admin-guide/bug-hunting.rst

@ -49,15 +49,19 @@ the issue, it may also contain the word **Oops**, as on this one::
Despite being an **Oops** or some other sort of stack trace, the offended
line is usually required to identify and handle the bug. Along this chapter,
we'll refer to "Oops" for all kinds of stack traces that need to be analized.
we'll refer to "Oops" for all kinds of stack traces that need to be analyzed.
.. note::
If the kernel is compiled with ``CONFIG_DEBUG_INFO``, you can enhance the
quality of the stack trace by using file:`scripts/decode_stacktrace.sh`.
Modules linked in
-----------------
Modules that are tainted or are being loaded or unloaded are marked with
"(...)", where the taint flags are described in
file:`Documentation/admin-guide/tainted-kernels.rst`, "being loaded" is
annotated with "+", and "being unloaded" is annotated with "-".
``ksymoops`` is useless on 2.6 or upper. Please use the Oops in its original
format (from ``dmesg``, etc). Ignore any references in this or other docs to
"decoding the Oops" or "running it through ksymoops".
If you post an Oops from 2.6+ that has been run through ``ksymoops``,
people will just tell you to repost it.
Where is the Oops message is located?
-------------------------------------
@ -71,7 +75,7 @@ by running ``journalctl`` command.
Sometimes ``klogd`` dies, in which case you can run ``dmesg > file`` to
read the data from the kernel buffers and save it. Or you can
``cat /proc/kmsg > file``, however you have to break in to stop the transfer,
``kmsg`` is a "never ending file".
since ``kmsg`` is a "never ending file".
If the machine has crashed so badly that you cannot enter commands or
the disk is not available then you have three options:
@ -81,9 +85,9 @@ the disk is not available then you have three options:
planned for a crash. Alternatively, you can take a picture of
the screen with a digital camera - not nice, but better than
nothing. If the messages scroll off the top of the console, you
may find that booting with a higher resolution (eg, ``vga=791``)
may find that booting with a higher resolution (e.g., ``vga=791``)
will allow you to read more of the text. (Caveat: This needs ``vesafb``,
so won't help for 'early' oopses)
so won't help for 'early' oopses.)
(2) Boot with a serial console (see
:ref:`Documentation/admin-guide/serial-console.rst <serial_console>`),
@ -104,7 +108,7 @@ Kernel source file. There are two methods for doing that. Usually, using
gdb
^^^
The GNU debug (``gdb``) is the best way to figure out the exact file and line
The GNU debugger (``gdb``) is the best way to figure out the exact file and line
number of the OOPS from the ``vmlinux`` file.
The usage of gdb works best on a kernel compiled with ``CONFIG_DEBUG_INFO``.
@ -165,7 +169,7 @@ If you have a call trace, such as::
[<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
...
this shows the problem likely in the :jbd: module. You can load that module
this shows the problem likely is in the :jbd: module. You can load that module
in gdb and list the relevant code::
$ gdb fs/jbd/jbd.ko
@ -199,8 +203,9 @@ in the kernel hacking menu of the menu configuration.) For example::
You need to be at the top level of the kernel tree for this to pick up
your C files.
If you don't have access to the code you can also debug on some crash dumps
e.g. crash dump output as shown by Dave Miller::
If you don't have access to the source code you can still debug some crash
dumps using the following method (example crash dump output as shown by
Dave Miller)::
EIP is at +0x14/0x4c0
...
@ -230,6 +235,9 @@ e.g. crash dump output as shown by Dave Miller::
mov 0x8(%ebp), %ebx ! %ebx = skb->sk
mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
file:`scripts/decodecode` can be used to automate most of this, depending
on what CPU architecture is being debugged.
Reporting the bug
-----------------
@ -241,7 +249,7 @@ used for the development of the affected code. This can be done by using
the ``get_maintainer.pl`` script.
For example, if you find a bug at the gspca's sonixj.c file, you can get
their maintainers with::
its maintainers with::
$ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
@ -253,16 +261,17 @@ their maintainers with::
Please notice that it will point to:
- The last developers that touched on the source code. On the above example,
Tejun and Bhaktipriya (in this specific case, none really envolved on the
development of this file);
- The last developers that touched the source code (if this is done inside
a git tree). On the above example, Tejun and Bhaktipriya (in this
specific case, none really envolved on the development of this file);
- The driver maintainer (Hans Verkuil);
- The subsystem maintainer (Mauro Carvalho Chehab);
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
- the Linux Kernel mailing list (linux-kernel@vger.kernel.org).
Usually, the fastest way to have your bug fixed is to report it to mailing
list used for the development of the code (linux-media ML) copying the driver maintainer (Hans).
list used for the development of the code (linux-media ML) copying the
driver maintainer (Hans).
If you are totally stumped as to whom to send the report, and
``get_maintainer.pl`` didn't provide you anything useful, send it to
@ -303,9 +312,9 @@ protection fault message can be simply cut out of the message files
and forwarded to the kernel developers.
Two types of address resolution are performed by ``klogd``. The first is
static translation and the second is dynamic translation. Static
translation uses the System.map file in much the same manner that
ksymoops does. In order to do static translation the ``klogd`` daemon
static translation and the second is dynamic translation.
Static translation uses the System.map file.
In order to do static translation the ``klogd`` daemon
must be able to find a system map file at daemon initialization time.
See the klogd man page for information on how ``klogd`` searches for map
files.

19
Documentation/admin-guide/cgroup-v1/memory.rst

@ -199,11 +199,11 @@ An RSS page is unaccounted when it's fully unmapped. A PageCache page is
unaccounted when it's removed from radix-tree. Even if RSS pages are fully
unmapped (by kswapd), they may exist as SwapCache in the system until they
are really freed. Such SwapCaches are also accounted.
A swapped-in page is not accounted until it's mapped.
A swapped-in page is accounted after adding into swapcache.
Note: The kernel does swapin-readahead and reads multiple swaps at once.
This means swapped-in pages may contain pages for other tasks than a task
causing page fault. So, we avoid accounting at swap-in I/O.
Since page's memcg recorded into swap whatever memsw enabled, the page will
be accounted after swapin.
At page migration, accounting information is kept.
@ -222,18 +222,13 @@ the cgroup that brought it in -- this will happen on memory pressure).
But see section 8.2: when moving a task to another cgroup, its pages may
be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
Exception: If CONFIG_MEMCG_SWAP is not used.
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
be backed into memory in force, charges for pages are accounted against the
caller of swapoff rather than the users of shmem.
2.4 Swap Extension (CONFIG_MEMCG_SWAP)
2.4 Swap Extension
--------------------------------------
Swap Extension allows you to record charge for swap. A swapped-in page is
charged back to original page allocator if possible.
Swap usage is always recorded for each of cgroup. Swap Extension allows you to
read and limit it.
When swap is accounted, following files are added.
When CONFIG_SWAP is enabled, following files are added.
- memory.memsw.usage_in_bytes.
- memory.memsw.limit_in_bytes.

47
Documentation/admin-guide/cgroup-v2.rst

@ -714,9 +714,7 @@ Conventions
- Settings for a single feature should be contained in a single file.
- The root cgroup should be exempt from resource control and thus
shouldn't have resource control interface files. Also,
informational files on the root cgroup which end up showing global
information available elsewhere shouldn't exist.
shouldn't have resource control interface files.
- The default time unit is microseconds. If a different unit is ever
used, an explicit unit suffix must be present.
@ -985,7 +983,7 @@ CPU Interface Files
All time durations are in microseconds.
cpu.stat
A read-only flat-keyed file which exists on non-root cgroups.
A read-only flat-keyed file.
This file exists whether the controller is enabled or not.
It always reports the following three stats:
@ -1172,6 +1170,13 @@ PAGE_SIZE multiple when read back.
Under certain circumstances, the usage may go over the limit
temporarily.
In default configuration regular 0-order allocations always
succeed unless OOM killer chooses current task as a victim.
Some kinds of allocations don't invoke the OOM killer.
Caller could retry them differently, return into userspace
as -ENOMEM or silently ignore in cases like disk readahead.
This is the ultimate protection mechanism. As long as the
high limit is used and monitored properly, this limit's
utility is limited to providing the final safety net.
@ -1228,17 +1233,9 @@ PAGE_SIZE multiple when read back.
The number of time the cgroup's memory usage was
reached the limit and allocation was about to fail.
Depending on context result could be invocation of OOM
killer and retrying allocation or failing allocation.
Failed allocation in its turn could be returned into
userspace as -ENOMEM or silently ignored in cases like
disk readahead. For now OOM in memory cgroup kills
tasks iff shortage has happened inside page fault.
This event is not raised if the OOM killer is not
considered as an option, e.g. for failed high-order
allocations.
allocations or if caller asked to not retry attempts.
oom_kill
The number of processes belonging to this cgroup
@ -1329,6 +1326,10 @@ PAGE_SIZE multiple when read back.
workingset_activate
Number of refaulted pages that were immediately activated
workingset_restore
Number of restored pages which have been detected as an active
workingset before they got reclaimed.
workingset_nodereclaim
Number of times a shadow node has been reclaimed
@ -1370,6 +1371,22 @@ PAGE_SIZE multiple when read back.
The total amount of swap currently being used by the cgroup
and its descendants.
memory.swap.high
A read-write single value file which exists on non-root
cgroups. The default is "max".
Swap usage throttle limit. If a cgroup's swap usage exceeds
this limit, all its further allocations will be throttled to
allow userspace to implement custom out-of-memory procedures.
This limit marks a point of no return for the cgroup. It is NOT
designed to manage the amount of swapping a workload does
during regular operation. Compare to memory.swap.max, which
prohibits swapping past a set amount, but lets the cgroup
continue unimpeded as long as other memory can be reclaimed.
Healthy workloads are not expected to reach this limit.
memory.swap.max
A read-write single value file which exists on non-root
cgroups. The default is "max".
@ -1383,6 +1400,10 @@ PAGE_SIZE multiple when read back.
otherwise, a value change in this file generates a file
modified event.
high
The number of times the cgroup's swap usage was over
the high threshold.
max
The number of times the cgroup's swap usage was about
to go over the max boundary and swap allocation

2
Documentation/admin-guide/cpu-load.rst

@ -105,7 +105,7 @@ References
----------
- http://lkml.org/lkml/2007/2/12/6
- Documentation/filesystems/proc.txt (1.8)
- Documentation/filesystems/proc.rst (1.8)
Thanks

51
Documentation/admin-guide/device-mapper/dm-ebs.rst Normal file

@ -0,0 +1,51 @@
======
dm-ebs
======
This target is similar to the linear target except that it emulates
a smaller logical block size on a device with a larger logical block
size. Its main purpose is to provide emulation of 512 byte sectors on
devices that do not provide this emulation (i.e. 4K native disks).
Supported emulated logical block sizes 512, 1024, 2048 and 4096.
Underlying block size can be set to > 4K to test buffering larger units.
Table parameters
----------------
<dev path> <offset> <emulated sectors> [<underlying sectors>]
Mandatory parameters:
<dev path>:
Full pathname to the underlying block-device,
or a "major:minor" device-number.
<offset>:
Starting sector within the device;
has to be a multiple of <emulated sectors>.
<emulated sectors>:
Number of sectors defining the logical block size to be emulated;
1, 2, 4, 8 sectors of 512 bytes supported.
Optional parameter:
<underyling sectors>:
Number of sectors defining the logical block size of <dev path>.
2^N supported, e.g. 8 = emulate 8 sectors of 512 bytes = 4KiB.
If not provided, the logical block size of <dev path> will be used.
Examples:
Emulate 1 sector = 512 bytes logical block size on /dev/sda starting at
offset 1024 sectors with underlying devices block size automatically set:
ebs /dev/sda 1024 1
Emulate 2 sector = 1KiB logical block size on /dev/sda starting at
offset 128 sectors, enforce 2KiB underlying device block size.
This presumes 2KiB logical blocksize on /dev/sda or less to work:
ebs /dev/sda 128 2 4

21
Documentation/admin-guide/device-mapper/dm-integrity.rst

@ -182,12 +182,23 @@ fix_padding
space-efficient. If this option is not present, large padding is
used - that is for compatibility with older kernels.
allow_discards
Allow block discard requests (a.k.a. TRIM) for the integrity device.
Discards are only allowed to devices using internal hash.
The journal mode (D/J), buffer_sectors, journal_watermark, commit_time can
be changed when reloading the target (load an inactive table and swap the
tables with suspend and resume). The other arguments should not be changed
when reloading the target because the layout of disk data depend on them
and the reloaded target would be non-functional.
The journal mode (D/J), buffer_sectors, journal_watermark, commit_time and
allow_discards can be changed when reloading the target (load an inactive
table and swap the tables with suspend and resume). The other arguments
should not be changed when reloading the target because the layout of disk
data depend on them and the reloaded target would be non-functional.
Status line:
1. the number of integrity mismatches
2. provided data sectors - that is the number of sectors that the user
could use
3. the current recalculating position (or '-' if we didn't recalculate)
The layout of the formatted block device:

62
Documentation/admin-guide/device-mapper/dm-zoned.rst

@ -37,9 +37,13 @@ Algorithm
dm-zoned implements an on-disk buffering scheme to handle non-sequential
write accesses to the sequential zones of a zoned block device.
Conventional zones are used for caching as well as for storing internal
metadata.
metadata. It can also use a regular block device together with the zoned
block device; in that case the regular block device will be split logically
in zones with the same size as the zoned block device. These zones will be
placed in front of the zones from the zoned block device and will be handled
just like conventional zones.
The zones of the device are separated into 2 types:
The zones of the device(s) are separated into 2 types:
1) Metadata zones: these are conventional zones used to store metadata.
Metadata zones are not reported as useable capacity to the user.
@ -127,6 +131,13 @@ resumed. Flushing metadata thus only temporarily delays write and
discard requests. Read requests can be processed concurrently while
metadata flush is being executed.
If a regular device is used in conjunction with the zoned block device,
a third set of metadata (without the zone bitmaps) is written to the
start of the zoned block device. This metadata has a generation counter of
'0' and will never be updated during normal operation; it just serves for
identification purposes. The first and second copy of the metadata
are located at the start of the regular block device.
Usage
=====
@ -138,9 +149,46 @@ Ex::
dmzadm --format /dev/sdxx
For a formatted device, the target can be created normally with the
dmsetup utility. The only parameter that dm-zoned requires is the
underlying zoned block device name. Ex::
echo "0 `blockdev --getsize ${dev}` zoned ${dev}" | \
dmsetup create dmz-`basename ${dev}`
If two drives are to be used, both devices must be specified, with the
regular block device as the first device.
Ex::
dmzadm --format /dev/sdxx /dev/sdyy
Fomatted device(s) can be started with the dmzadm utility, too.:
Ex::
dmzadm --start /dev/sdxx /dev/sdyy
Information about the internal layout and current usage of the zones can
be obtained with the 'status' callback from dmsetup:
Ex::
dmsetup status /dev/dm-X
will return a line
0 <size> zoned <nr_zones> zones <nr_unmap_rnd>/<nr_rnd> random <nr_unmap_seq>/<nr_seq> sequential
where <nr_zones> is the total number of zones, <nr_unmap_rnd> is the number
of unmapped (ie free) random zones, <nr_rnd> the total number of zones,
<nr_unmap_seq> the number of unmapped sequential zones, and <nr_seq> the
total number of sequential zones.
Normally the reclaim process will be started once there are less than 50
percent free random zones. In order to start the reclaim process manually
even before reaching this threshold the 'dmsetup message' function can be
used:
Ex::
dmsetup message /dev/dm-X 0 reclaim
will start the reclaim process and random zones will be moved to sequential
zones.

2
Documentation/admin-guide/devices.rst

@ -17,7 +17,7 @@ Specifically explore the sections titled "CHAR and MISC DRIVERS", and
to involve for character and block devices.
This document is included by reference into the Filesystem Hierarchy
Standard (FHS). The FHS is available from http://www.pathname.com/fhs/.
Standard (FHS). The FHS is available from https://www.pathname.com/fhs/.
Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga
platform only. Allocations marked (68k/Atari) apply to Linux/68k on

5
Documentation/admin-guide/dynamic-debug-howto.rst

@ -13,6 +13,11 @@ kernel code to obtain additional kernel information. Currently, if
``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically
enabled per-callsite.
If you do not want to enable dynamic debug globally (i.e. in some embedded
system), you may set ``CONFIG_DYNAMIC_DEBUG_CORE`` as basic support of dynamic
debug and add ``ccflags := -DDYNAMIC_DEBUG_MODULE`` into the Makefile of any
modules which you'd like to dynamically debug later.
If ``CONFIG_DYNAMIC_DEBUG`` is not set, ``print_hex_dump_debug()`` is just
shortcut for ``print_hex_dump(KERN_DEBUG)``.

111
Documentation/admin-guide/gpio/gpio-aggregator.rst Normal file

@ -0,0 +1,111 @@
.. SPDX-License-Identifier: GPL-2.0-only
GPIO Aggregator
===============
The GPIO Aggregator provides a mechanism to aggregate GPIOs, and expose them as
a new gpio_chip. This supports the following use cases.
Aggregating GPIOs using Sysfs
-----------------------------
GPIO controllers are exported to userspace using /dev/gpiochip* character
devices. Access control to these devices is provided by standard UNIX file
system permissions, on an all-or-nothing basis: either a GPIO controller is
accessible for a user, or it is not.
The GPIO Aggregator provides access control for a set of one or more GPIOs, by
aggregating them into a new gpio_chip, which can be assigned to a group or user
using standard UNIX file ownership and permissions. Furthermore, this
simplifies and hardens exporting GPIOs to a virtual machine, as the VM can just
grab the full GPIO controller, and no longer needs to care about which GPIOs to
grab and which not, reducing the attack surface.
Aggregated GPIO controllers are instantiated and destroyed by writing to
write-only attribute files in sysfs.
/sys/bus/platform/drivers/gpio-aggregator/
"new_device" ...
Userspace may ask the kernel to instantiate an aggregated GPIO
controller by writing a string describing the GPIOs to
aggregate to the "new_device" file, using the format
.. code-block:: none
[<gpioA>] [<gpiochipB> <offsets>] ...
Where:
"<gpioA>" ...
is a GPIO line name,
"<gpiochipB>" ...
is a GPIO chip label, and
"<offsets>" ...
is a comma-separated list of GPIO offsets and/or
GPIO offset ranges denoted by dashes.
Example: Instantiate a new GPIO aggregator by aggregating GPIO
line 19 of "e6052000.gpio" and GPIO lines 20-21 of
"e6050000.gpio" into a new gpio_chip:
.. code-block:: sh
$ echo 'e6052000.gpio 19 e6050000.gpio 20-21' > new_device
"delete_device" ...
Userspace may ask the kernel to destroy an aggregated GPIO
controller after use by writing its device name to the
"delete_device" file.
Example: Destroy the previously-created aggregated GPIO
controller, assumed to be "gpio-aggregator.0":
.. code-block:: sh
$ echo gpio-aggregator.0 > delete_device
Generic GPIO Driver
-------------------
The GPIO Aggregator can also be used as a generic driver for a simple
GPIO-operated device described in DT, without a dedicated in-kernel driver.
This is useful in industrial control, and is not unlike e.g. spidev, which
allows the user to communicate with an SPI device from userspace.
Binding a device to the GPIO Aggregator is performed either by modifying the
gpio-aggregator driver, or by writing to the "driver_override" file in Sysfs.
Example: If "door" is a GPIO-operated device described in DT, using its own
compatible value::
door {
compatible = "myvendor,mydoor";
gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>,
<&gpio2 20 GPIO_ACTIVE_LOW>;
gpio-line-names = "open", "lock";
};
it can be bound to the GPIO Aggregator by either:
1. Adding its compatible value to ``gpio_aggregator_dt_ids[]``,
2. Binding manually using "driver_override":
.. code-block:: sh
$ echo gpio-aggregator > /sys/bus/platform/devices/door/driver_override
$ echo door > /sys/bus/platform/drivers/gpio-aggregator/bind
After that, a new gpiochip "door" has been created:
.. code-block:: sh
$ gpioinfo door
gpiochip12 - 2 lines:
line 0: "open" unused input active-high
line 1: "lock" unused input active-high

1
Documentation/admin-guide/gpio/index.rst

@ -7,6 +7,7 @@ gpio
.. toctree::
:maxdepth: 1
gpio-aggregator
sysfs
.. only:: subproject and html

1
Documentation/admin-guide/hw-vuln/index.rst

@ -14,3 +14,4 @@ are configurable at compile, boot or run time.
mds
tsx_async_abort
multihit.rst
special-register-buffer-data-sampling.rst

2
Documentation/admin-guide/hw-vuln/l1tf.rst

@ -268,7 +268,7 @@ Guest mitigation mechanisms
/proc/irq/$NR/smp_affinity[_list] files. Limited documentation is
available at:
https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
https://www.kernel.org/doc/Documentation/core-api/irq/irq-affinity.rst
.. _smt_control:

149
Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst Normal file

@ -0,0 +1,149 @@
.. SPDX-License-Identifier: GPL-2.0
SRBDS - Special Register Buffer Data Sampling
=============================================
SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to
infer values returned from special register accesses. Special register
accesses are accesses to off core registers. According to Intel's evaluation,
the special register reads that have a security expectation of privacy are
RDRAND, RDSEED and SGX EGETKEY.
When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved
to the core through the special register mechanism that is susceptible
to MDS attacks.
Affected processors
--------------------
Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may
be affected.
A processor is affected by SRBDS if its Family_Model and stepping is
in the following list, with the exception of the listed processors
exporting MDS_NO while Intel TSX is available yet not enabled. The
latter class of processors are only affected when Intel TSX is enabled
by software using TSX_CTRL_MSR otherwise they are not affected.
============= ============ ========
common name Family_Model Stepping
============= ============ ========
IvyBridge 06_3AH All
Haswell 06_3CH All
Haswell_L 06_45H All
Haswell_G 06_46H All
Broadwell_G 06_47H All
Broadwell 06_3DH All
Skylake_L 06_4EH All
Skylake 06_5EH All
Kabylake_L 06_8EH <= 0xC
Kabylake 06_9EH <= 0xD
============= ============ ========
Related CVEs
------------
The following CVE entry is related to this SRBDS issue:
============== ===== =====================================
CVE-2020-0543 SRBDS Special Register Buffer Data Sampling
============== ===== =====================================
Attack scenarios
----------------
An unprivileged user can extract values returned from RDRAND and RDSEED
executed on another core or sibling thread using MDS techniques.
Mitigation mechanism
-------------------
Intel will release microcode updates that modify the RDRAND, RDSEED, and
EGETKEY instructions to overwrite secret special register data in the shared
staging buffer before the secret data can be accessed by another logical
processor.
During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core
accesses from other logical processors will be delayed until the special
register read is complete and the secret data in the shared staging buffer is
overwritten.
This has three effects on performance:
#. RDRAND, RDSEED, or EGETKEY instructions have higher latency.
#. Executing RDRAND at the same time on multiple logical processors will be
serialized, resulting in an overall reduction in the maximum RDRAND
bandwidth.
#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other
logical processors that miss their core caches, with an impact similar to
legacy locked cache-line-split accesses.
The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable
the mitigation for RDRAND and RDSEED instructions executed outside of Intel
Software Guard Extensions (Intel SGX) enclaves. On logical processors that
disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not
take longer to execute and do not impact performance of sibling logical
processors memory accesses. The opt-out mechanism does not affect Intel SGX
enclaves (including execution of RDRAND or RDSEED inside an enclave, as well
as EGETKEY execution).
IA32_MCU_OPT_CTRL MSR Definition
--------------------------------
Along with the mitigation for this issue, Intel added a new thread-scope
IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and
RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL =
9]==1. This MSR is introduced through the microcode update.
Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor
disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX
enclave on that logical processor. Opting out of the mitigation for a
particular logical processor does not affect the RDRAND and RDSEED mitigations
for other logical processors.
Note that inside of an Intel SGX enclave, the mitigation is applied regardless
of the value of RNGDS_MITG_DS.
Mitigation control on the kernel command line
---------------------------------------------
The kernel command line allows control over the SRBDS mitigation at boot time
with the option "srbds=". The option for this is:
============= =============================================================
off This option disables SRBDS mitigation for RDRAND and RDSEED on
affected platforms.
============= =============================================================
SRBDS System Information
-----------------------
The Linux kernel provides vulnerability status information through sysfs. For
SRBDS this can be accessed by the following sysfs file:
/sys/devices/system/cpu/vulnerabilities/srbds
The possible values contained in this file are:
============================== =============================================
Not affected Processor not vulnerable
Vulnerable Processor vulnerable and mitigation disabled
Vulnerable: No microcode Processor vulnerable and microcode is missing
mitigation
Mitigation: Microcode Processor is vulnerable and mitigation is in
effect.
Mitigation: TSX disabled Processor is only vulnerable when TSX is
enabled while this system was booted with TSX
disabled.
Unknown: Dependent on
hypervisor status Running on virtual guest processor that is
affected but with no way to know if host
processor is mitigated or vulnerable.
============================== =============================================
SRBDS Default mitigation
------------------------
This new microcode serializes processor access during execution of RDRAND,
RDSEED ensures that the shared buffer is overwritten before it is released for
reuse. Use the "srbds=off" kernel command line to disable the mitigation for
RDRAND and RDSEED.

1
Documentation/admin-guide/index.rst

@ -93,6 +93,7 @@ configure specific aspects of kernel behavior to your liking.
lockup-watchdogs
LSM/index
md
media/index
mm/index
module-signing
mono

70
Documentation/admin-guide/init.rst

@ -1,52 +1,48 @@
Explaining the dreaded "No init found." boot hang message
Explaining the "No working init found." boot hang message
=========================================================
:Authors: Andreas Mohr <andi at lisas period de>
Cristian Souza <cristianmsbr at gmail period com>
OK, so you've got this pretty unintuitive message (currently located
in init/main.c) and are wondering what the H*** went wrong.
Some high-level reasons for failure (listed roughly in order of execution)
to load the init binary are:
This document provides some high-level reasons for failure
(listed roughly in order of execution) to load the init binary.
A) Unable to mount root FS
B) init binary doesn't exist on rootfs
C) broken console device
D) binary exists but dependencies not available
E) binary cannot be loaded
1) **Unable to mount root FS**: Set "debug" kernel parameter (in bootloader
config file or CONFIG_CMDLINE) to get more detailed kernel messages.
Detailed explanations:
2) **init binary doesn't exist on rootfs**: Make sure you have the correct
root FS type (and ``root=`` kernel parameter points to the correct
partition), required drivers such as storage hardware (such as SCSI or
USB!) and filesystem (ext3, jffs2, etc.) are builtin (alternatively as
modules, to be pre-loaded by an initrd).
A) Set "debug" kernel parameter (in bootloader config file or CONFIG_CMDLINE)
to get more detailed kernel messages.
B) make sure you have the correct root FS type
(and ``root=`` kernel parameter points to the correct partition),
required drivers such as storage hardware (such as SCSI or USB!)
and filesystem (ext3, jffs2 etc.) are builtin (alternatively as modules,
to be pre-loaded by an initrd)
C) Possibly a conflict in ``console= setup`` --> initial console unavailable.
E.g. some serial consoles are unreliable due to serial IRQ issues (e.g.
missing interrupt-based configuration).
3) **Broken console device**: Possibly a conflict in ``console= setup``
--> initial console unavailable. E.g. some serial consoles are unreliable
due to serial IRQ issues (e.g. missing interrupt-based configuration).
Try using a different ``console= device`` or e.g. ``netconsole=``.
D) e.g. required library dependencies of the init binary such as
``/lib/ld-linux.so.2`` missing or broken. Use
``readelf -d <INIT>|grep NEEDED`` to find out which libraries are required.
E) make sure the binary's architecture matches your hardware.
E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM hardware.
In case you tried loading a non-binary file here (shell script?),
you should make sure that the script specifies an interpreter in its shebang
header line (``#!/...``) that is fully working (including its library
dependencies). And before tackling scripts, better first test a simple
non-script binary such as ``/bin/sh`` and confirm its successful execution.
To find out more, add code ``to init/main.c`` to display kernel_execve()s
return values.
4) **Binary exists but dependencies not available**: E.g. required library
dependencies of the init binary such as ``/lib/ld-linux.so.2`` missing or
broken. Use ``readelf -d <INIT>|grep NEEDED`` to find out which libraries
are required.
5) **Binary cannot be loaded**: Make sure the binary's architecture matches
your hardware. E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM
hardware. In case you tried loading a non-binary file here (shell script?),
you should make sure that the script specifies an interpreter in its
shebang header line (``#!/...``) that is fully working (including its
library dependencies). And before tackling scripts, better first test a
simple non-script binary such as ``/bin/sh`` and confirm its successful
execution. To find out more, add code ``to init/main.c`` to display
kernel_execve()s return values.
Please extend this explanation whenever you find new failure causes
(after all loading the init binary is a CRITICAL and hard transition step
which needs to be made as painless as possible), then submit patch to LKML.
which needs to be made as painless as possible), then submit a patch to LKML.
Further TODOs:
- Implement the various ``run_init_process()`` invocations via a struct array
which can then store the ``kernel_execve()`` result value and on failure
log it all by iterating over **all** results (very important usability fix).
- try to make the implementation itself more helpful in general,
e.g. by providing additional error messages at affected places.
- Try to make the implementation itself more helpful in general, e.g. by
providing additional error messages at affected places.
Andreas Mohr <andi at lisas period de>

2
Documentation/admin-guide/initrd.rst

@ -376,7 +376,7 @@ Resources
---------
.. [#f1] Almesberger, Werner; "Booting Linux: The History and the Future"
http://www.almesberger.net/cv/papers/ols2k-9.ps.gz
https://www.almesberger.net/cv/papers/ols2k-9.ps.gz
.. [#f2] newlib package (experimental), with initrd example
https://www.sourceware.org/newlib/
.. [#f3] util-linux: Miscellaneous utilities for Linux

8
Documentation/admin-guide/kdump/kdump.rst

@ -521,6 +521,14 @@ will cause a kdump to occur at the panic() call. In cases where a user wants
to specify this during runtime, /proc/sys/kernel/panic_on_warn can be set to 1
to achieve the same behaviour.
Trigger Kdump on add_taint()
============================
The kernel parameter panic_on_taint facilitates a conditional call to panic()
from within add_taint() whenever the value set in this bitmask matches with the
bit flag being set by add_taint().
This will cause a kdump to occur at the add_taint()->panic() call.
Contact
=======

6
Documentation/admin-guide/kdump/vmcoreinfo.rst

@ -393,6 +393,12 @@ KERNELOFFSET
The kernel randomization offset. Used to compute the page offset. If
KASLR is disabled, this value is zero.
KERNELPACMASK
-------------
The mask to extract the Pointer Authentication Code from a kernel virtual
address.
arm
===

174
Documentation/admin-guide/kernel-parameters.txt

@ -356,7 +356,7 @@
shot down by NMI
autoconf= [IPV6]
See Documentation/networking/ipv6.txt.
See Documentation/networking/ipv6.rst.
show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
Limit apic dumping. The parameter defines the maximal
@ -458,7 +458,7 @@
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
bttv.pll= See Documentation/media/v4l-drivers/bttv.rst
bttv.pll= See Documentation/admin-guide/media/bttv.rst
bttv.tuner=
bulk_remove=off [PPC] This parameter disables the use of the pSeries
@ -638,7 +638,7 @@
See Documentation/admin-guide/serial-console.rst for more
information. See
Documentation/networking/netconsole.txt for an
Documentation/networking/netconsole.rst for an
alternative.
uart[8250],io,<addr>[,options]
@ -831,15 +831,18 @@
decnet.addr= [HW,NET]
Format: <area>[,<node>]
See also Documentation/networking/decnet.txt.
See also Documentation/networking/decnet.rst.
default_hugepagesz=
[same as hugepagesz=] The size of the default
HugeTLB page size. This is the size represented by
the legacy /proc/ hugepages APIs, used for SHM, and
default size when mounting hugetlbfs filesystems.
Defaults to the default architecture's huge page size
if not specified.
[HW] The size of the default HugeTLB page. This is
the size represented by the legacy /proc/ hugepages
APIs. In addition, this is the default hugetlb size
used for shmget(), mmap() and mounting hugetlbfs
filesystems. If not specified, defaults to the
architecture's default huge page size. Huge page
sizes are architecture dependent. See also
Documentation/admin-guide/mm/hugetlbpage.rst.
Format: size[KMG]
deferred_probe_timeout=
[KNL] Debugging option to set a timeout in seconds for
@ -871,8 +874,13 @@
can be useful when debugging issues that require an SLB
miss to occur.
stress_slb [PPC]
Limits the number of kernel SLB entries, and flushes
them frequently to increase the rate of SLB faults
on kernel addresses.
disable= [IPV6]
See Documentation/networking/ipv6.txt.
See Documentation/networking/ipv6.rst.
hardened_usercopy=
[KNL] Under CONFIG_HARDENED_USERCOPY, whether
@ -912,7 +920,7 @@
to workaround buggy firmware.
disable_ipv6= [IPV6]
See Documentation/networking/ipv6.txt.
See Documentation/networking/ipv6.rst.
disable_mtrr_cleanup [X86]
The kernel tries to adjust MTRR layout from continuous
@ -1190,6 +1198,11 @@
This is designed to be used in conjunction with
the boot argument: earlyprintk=vga
This parameter works in place of the kgdboc parameter
but can only be used if the backing tty is available
very early in the boot process. For early debugging
via a serial port see kgdboc_earlycon instead.
edd= [EDD]
Format: {"off" | "on" | "skip[mbr]"}
@ -1432,7 +1445,7 @@
hardlockup_all_cpu_backtrace=
[KNL] Should the hard-lockup detector generate
backtraces on all cpus.
Format: <integer>
Format: 0 | 1
hashdist= [KNL,NUMA] Large hashes allocated during boot
are distributed across NUMA nodes. Defaults on
@ -1479,19 +1492,30 @@
hugepages using the cma allocator. If enabled, the
boot-time allocation of gigantic hugepages is skipped.
hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
multiple times interleaved with hugepages= to reserve
huge pages of different sizes. Valid pages sizes on
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
hugepages= [HW] Number of HugeTLB pages to allocate at boot.
If this follows hugepagesz (below), it specifies
the number of pages of hugepagesz to be allocated.
If this is the first HugeTLB parameter on the command
line, it specifies the number of pages to allocate for
the default huge page size. See also
Documentation/admin-guide/mm/hugetlbpage.rst.
Format: <integer>
hugepagesz=
[HW] The size of the HugeTLB pages. This is used in
conjunction with hugepages (above) to allocate huge
pages of a specific size at boot. The pair
hugepagesz=X hugepages=Y can be specified once for
each supported huge page size. Huge page sizes are
architecture dependent. See also
Documentation/admin-guide/mm/hugetlbpage.rst.
Format: size[KMG]
hung_task_panic=
[KNL] Should the hung task detector generate panics.
Format: <integer>
Format: 0 | 1
A nonzero value instructs the kernel to panic when a
A value of 1 instructs the kernel to panic when a
hung task is detected. The default value is controlled
by the CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time
option. The value selected by this boot parameter can
@ -1748,6 +1772,13 @@
initrd= [BOOT] Specify the location of the initial ramdisk
initrdmem= [KNL] Specify a physical address and size from which to
load the initrd. If an initrd is compiled in or
specified in the bootparams, it takes priority over this
setting.
Format: ss[KMG],nn[KMG]
Default is 0, 0
init_on_alloc= [MM] Fill newly allocated pages and heap objects with
zeroes.
Format: 0 | 1
@ -2105,6 +2136,21 @@
kms, kbd format: kms,kbd
kms, kbd and serial format: kms,kbd,<ser_dev>[,baud]
kgdboc_earlycon= [KGDB,HW]
If the boot console provides the ability to read
characters and can work in polling mode, you can use
this parameter to tell kgdb to use it as a backend
until the normal console is registered. Intended to
be used together with the kgdboc parameter which
specifies the normal console to transition to.
The name of the early console should be specified
as the value of this parameter. Note that the name of
the early console might be different than the tty
name passed to kgdboc. It's OK to leave the value
blank and the first boot console that implements
read() will be picked.
kgdbwait [KGDB] Stop kernel execution and enter the
kernel debugger at the earliest opportunity.
@ -2705,7 +2751,7 @@
See Documentation/admin-guide/pm/sleep-states.rst.
meye.*= [HW] Set MotionEye Camera parameters
See Documentation/media/v4l-drivers/meye.rst.
See Documentation/admin-guide/media/meye.rst.
mfgpt_irq= [IA-32] Specify the IRQ to use for the
Multi-Function General Purpose Timers on AMD Geode
@ -3329,7 +3375,7 @@
See Documentation/admin-guide/sysctl/vm.rst for details.
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
See Documentation/debugging-via-ohci1394.txt for more
See Documentation/core-api/debugging-via-ohci1394.rst for more
info.
olpc_ec_timeout= [OLPC] ms delay when issuing EC commands
@ -3401,6 +3447,19 @@
bit 4: print ftrace buffer
bit 5: print all printk messages in buffer
panic_on_taint= Bitmask for conditionally calling panic() in add_taint()
Format: <hex>[,nousertaint]
Hexadecimal bitmask representing the set of TAINT flags
that will cause the kernel to panic when add_taint() is
called with any of the flags in this set.
The optional switch "nousertaint" can be utilized to
prevent userspace forced crashes by writing to sysctl
/proc/sys/kernel/tainted any flagset matching with the
bitmask set on panic_on_taint.
See Documentation/admin-guide/tainted-kernels.rst for
extra details on the taint flags that users can pick
to compose the bitmask to assign to panic_on_taint.
panic_on_warn panic() instead of WARN(). Useful to cause kdump
on a WARN().
@ -3669,6 +3728,8 @@
may put more devices in an IOMMU group.
force_floating [S390] Force usage of floating interrupts.
nomio [S390] Do not use MIO instructions.
norid [S390] ignore the RID field and force use of
one PCI domain per PCI function
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
Management.
@ -4210,12 +4271,24 @@
Duration of CPU stall (s) to test RCU CPU stall
warnings, zero to disable.
rcutorture.stall_cpu_block= [KNL]
Sleep while stalling if set. This will result
in warnings from preemptible RCU in addition
to any other stall-related activity.
rcutorture.stall_cpu_holdoff= [KNL]
Time to wait (s) after boot before inducing stall.
rcutorture.stall_cpu_irqsoff= [KNL]
Disable interrupts while stalling if set.
rcutorture.stall_gp_kthread= [KNL]
Duration (s) of forced sleep within RCU
grace-period kthread to test RCU CPU stall
warnings, zero to disable. If both stall_cpu
and stall_gp_kthread are specified, the
kthread is starved first, then the CPU.
rcutorture.stat_interval= [KNL]
Time (s) between statistics printk()s.
@ -4286,6 +4359,13 @@
only normal grace-period primitives. No effect
on CONFIG_TINY_RCU kernels.
rcupdate.rcu_task_ipi_delay= [KNL]
Set time in jiffies during which RCU tasks will
avoid sending IPIs, starting with the beginning
of a given grace period. Setting a large
number avoids disturbing real-time workloads,
but lengthens grace periods.
rcupdate.rcu_task_stall_timeout= [KNL]
Set timeout in jiffies for RCU task stall warning
messages. Disable with a value less than or equal
@ -4587,9 +4667,9 @@
softlockup_panic=
[KNL] Should the soft-lockup detector generate panics.
Format: <integer>
Format: 0 | 1
A nonzero value instructs the soft-lockup detector
A value of 1 instructs the soft-lockup detector
to panic the machine when a soft-lockup occurs. It is
also controlled by the kernel.softlockup_panic sysctl
and CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC, which is the
@ -4598,7 +4678,7 @@
softlockup_all_cpu_backtrace=
[KNL] Should the soft-lockup detector generate
backtraces on all cpus.
Format: <integer>
Format: 0 | 1
sonypi.*= [HW] Sony Programmable I/O Control Device driver
See Documentation/admin-guide/laptops/sonypi.rst
@ -4757,6 +4837,26 @@
the kernel will oops in either "warn" or "fatal"
mode.
srbds= [X86,INTEL]
Control the Special Register Buffer Data Sampling
(SRBDS) mitigation.
Certain CPUs are vulnerable to an MDS-like
exploit which can leak bits from the random
number generator.
By default, this issue is mitigated by
microcode. However, the microcode fix can cause
the RDRAND and RDSEED instructions to become
much slower. Among other effects, this will
result in reduced throughput from /dev/urandom.
The microcode mitigation can be disabled with
the following option:
off: Disable mitigation and remove
performance impact to RDRAND and RDSEED
srcutree.counter_wrap_check [KNL]
Specifies how frequently to check for
grace-period sequence counter wrap for the
@ -4891,6 +4991,15 @@
switches= [HW,M68k]
sysctl.*= [KNL]
Set a sysctl parameter, right before loading the init
process, as if the value was written to the respective
/proc/sys/... file. Both '.' and '/' are recognized as
separators. Unrecognized parameters and invalid values
are reported in the kernel log. Sysctls registered
later by a loaded module cannot be set this way.
Example: sysctl.vm.swappiness=40
sysfs.deprecated=0|1 [KNL]
Enable/disable old style sysfs layout for old udev
on older distributions. When this option is enabled
@ -4910,7 +5019,7 @@
Set the number of tcp_metrics_hash slots.
Default value is 8192 or 16384 depending on total
ram pages. This is used to specify the TCP metrics
cache size. See Documentation/networking/ip-sysctl.txt
cache size. See Documentation/networking/ip-sysctl.rst
"tcp_no_metrics_save" section for more details.
tdfx= [HW,DRM]
@ -5067,6 +5176,12 @@
interruptions from clocksource watchdog are not
acceptable).
tsc_early_khz= [X86] Skip early TSC calibration and use the given
value instead. Useful when the early TSC frequency discovery
procedure is not reliable, such as on overclocked systems
with CPUID.16h support and partial CPUID.15h support.
Format: <unsigned int>
tsx= [X86] Control Transactional Synchronization
Extensions (TSX) feature in Intel processors that
support TSX control.
@ -5187,8 +5302,7 @@
usbcore.old_scheme_first=
[USB] Start with the old device initialization
scheme, applies only to low and full-speed devices
(default 0 = off).
scheme (default 0 = off).
usbcore.usbfs_memory_mb=
[USB] Memory limit (in MB) for buffers allocated by

2
Documentation/admin-guide/kernel-per-CPU-kthreads.rst

@ -10,7 +10,7 @@ them to a "housekeeping" CPU dedicated to such work.
References
==========
- Documentation/IRQ-affinity.txt: Binding interrupts to sets of CPUs.
- Documentation/core-api/irq/irq-affinity.rst: Binding interrupts to sets of CPUs.
- Documentation/admin-guide/cgroup-v1: Using cgroups to bind tasks to sets of CPUs.

2
Documentation/admin-guide/md.rst

@ -5,7 +5,7 @@ Boot time assembly of RAID arrays
---------------------------------
Tools that manage md devices can be found at
http://www.kernel.org/pub/linux/utils/raid/
https://www.kernel.org/pub/linux/utils/raid/
You can boot with your md device with the following kernel command

0
Documentation/media/v4l-drivers/au0828-cardlist.rst → Documentation/admin-guide/media/au0828-cardlist.rst

94
Documentation/admin-guide/media/avermedia.rst Normal file

@ -0,0 +1,94 @@
.. SPDX-License-Identifier: GPL-2.0
======================================
Avermedia DVB-T on BT878 Release Notes
======================================
February 14th 2006
.. note::
Several other Avermedia devices are supported. For a more
broader and updated content about that, please check:
https://linuxtv.org/wiki/index.php/AVerMedia
The Avermedia DVB-T
~~~~~~~~~~~~~~~~~~~
The Avermedia DVB-T is a budget PCI DVB card. It has 3 inputs:
* RF Tuner Input
* Composite Video Input (RCA Jack)
* SVIDEO Input (Mini-DIN)
The RF Tuner Input is the input to the tuner module of the
card. The Tuner is otherwise known as the "Frontend" . The
Frontend of the Avermedia DVB-T is a Microtune 7202D. A timely
post to the linux-dvb mailing list ascertained that the
Microtune 7202D is supported by the sp887x driver which is
found in the dvb-hw CVS module.
The DVB-T card is based around the BT878 chip which is a very
common multimedia bridge and often found on Analogue TV cards.
There is no on-board MPEG2 decoder, which means that all MPEG2
decoding must be done in software, or if you have one, on an
MPEG2 hardware decoding card or chipset.
Getting the card going
~~~~~~~~~~~~~~~~~~~~~~
At this stage, it has not been able to ascertain the
functionality of the remaining device nodes in respect of the
Avermedia DVBT. However, full functionality in respect of
tuning, receiving and supplying the MPEG2 data stream is
possible with the currently available versions of the driver.
It may be possible that additional functionality is available
from the card (i.e. viewing the additional analogue inputs
that the card presents), but this has not been tested yet. If
I get around to this, I'll update the document with whatever I
find.
To power up the card, load the following modules in the
following order:
* modprobe bttv (normally loaded automatically)
* modprobe dvb-bt8xx (or place dvb-bt8xx in /etc/modules)
Insertion of these modules into the running kernel will
activate the appropriate DVB device nodes. It is then possible
to start accessing the card with utilities such as scan, tzap,
dvbstream etc.
The frontend module sp887x.o, requires an external firmware.
Please use the command "get_dvb_firmware sp887x" to download
it. Then copy it to /usr/lib/hotplug/firmware or /lib/firmware/
(depending on configuration of firmware hotplug).
Known Limitations
~~~~~~~~~~~~~~~~~
At present I can say with confidence that the frontend tunes
via /dev/dvb/adapter{x}/frontend0 and supplies an MPEG2 stream
via /dev/dvb/adapter{x}/dvr0. I have not tested the
functionality of any other part of the card yet. I will do so
over time and update this document.
There are some limitations in the i2c layer due to a returned
error message inconsistency. Although this generates errors in
dmesg and the system logs, it does not appear to affect the
ability of the frontend to function correctly.
Further Update
~~~~~~~~~~~~~~
dvbstream and VideoLAN Client on windows works a treat with
DVB, in fact this is currently serving as my main way of
viewing DVB-T at the moment. Additionally, VLC is happily
decoding HDTV signals, although the PC is dropping the odd
frame here and there - I assume due to processing capability -
as all the decoding is being done under windows in software.
Many thanks to Nigel Pearson for the updates to this document
since the recent revision of the driver.

156
Documentation/admin-guide/media/bt8xx.rst Normal file

@ -0,0 +1,156 @@
.. SPDX-License-Identifier: GPL-2.0
==================================
How to get the bt8xx cards working
==================================
Authors:
Richard Walker,
Jamie Honan,
Michael Hunold,
Manu Abraham,
Uwe Bugla,
Michael Krufky
General information
-------------------
This class of cards has a bt878a as the PCI interface, and require the bttv driver
for accessing the i2c bus and the gpio pins of the bt8xx chipset.
Please see :doc:`bttv-cardlist` for a complete list of Cards based on the
Conexant Bt8xx PCI bridge supported by the Linux Kernel.
In order to be able to compile the kernel, some config options should be
enabled::
./scripts/config -e PCI
./scripts/config -e INPUT
./scripts/config -m I2C
./scripts/config -m MEDIA_SUPPORT
./scripts/config -e MEDIA_PCI_SUPPORT
./scripts/config -e MEDIA_ANALOG_TV_SUPPORT
./scripts/config -e MEDIA_DIGITAL_TV_SUPPORT
./scripts/config -e MEDIA_RADIO_SUPPORT
./scripts/config -e RC_CORE
./scripts/config -m VIDEO_BT848
./scripts/config -m DVB_BT8XX
If you want to automatically support all possible variants of the Bt8xx
cards, you should also do::
./scripts/config -e MEDIA_SUBDRV_AUTOSELECT
.. note::
Please use the following options with care as deselection of drivers which
are in fact necessary may result in DVB devices that cannot be tuned due
to lack of driver support.
If your goal is to just support an specific board, you may, instead,
disable MEDIA_SUBDRV_AUTOSELECT and manually select the frontend drivers
required by your board. With that, you can save some RAM.
You can do that by calling make xconfig/qconfig/menuconfig and look at
the options on those menu options (only enabled if
``Autoselect ancillary drivers`` is disabled:
#) ``Device drivers`` => ``Multimedia support`` => ``Customize TV tuners``
#) ``Device drivers`` => ``Multimedia support`` => ``Customize DVB frontends``
Then, on each of the above menu, please select your card-specific
frontend and tuner modules.
Loading Modules
---------------
Regular case: If the bttv driver detects a bt8xx-based DVB card, all
frontend and backend modules will be loaded automatically.
Exceptions are:
- Old TV cards without EEPROMs, sharing a common PCI subsystem ID;
- Old TwinHan DST cards or clones with or without CA slot and not
containing an Eeprom.
In the following cases overriding the PCI type detection for bttv and
for dvb-bt8xx drivers by passing modprobe parameters may be necessary.
Running TwinHan and Clones
~~~~~~~~~~~~~~~~~~~~~~~~~~
As shown at :doc:`bttv-cardlist`, TwinHan and
clones use ``card=113`` modprobe parameter. So, in order to properly
detect it for devices without EEPROM, you should use::
$ modprobe bttv card=113
$ modprobe dst
Useful parameters for verbosity level and debugging the dst module::
verbose=0: messages are disabled
1: only error messages are displayed
2: notifications are displayed
3: other useful messages are displayed
4: debug setting
dst_addons=0: card is a free to air (FTA) card only
0x20: card has a conditional access slot for scrambled channels
dst_algo=0: (default) Software tuning algorithm
1: Hardware tuning algorithm
The autodetected values are determined by the cards' "response string".
In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI].
For bug reports please send in a complete log with verbose=4 activated.
Please also see :doc:`ci`.
Running multiple cards
~~~~~~~~~~~~~~~~~~~~~~
See :doc:`bttv-cardlist` for a complete list of
Card ID. Some examples:
=========================== ===
Brand name ID
=========================== ===
Pinnacle PCTV Sat 94
Nebula Electronics Digi TV 104
pcHDTV HD-2000 TV 112
Twinhan DST and clones 113
Avermedia AverTV DVB-T 77: 123
Avermedia AverTV DVB-T 761 124
DViCO FusionHDTV DVB-T Lite 128
DViCO FusionHDTV 5 Lite 135
=========================== ===
.. note::
When you have multiple cards, the order of the card ID should
match the order where they're detected by the system. Please notice
that removing/inserting other PCI cards may change the detection
order.
Example::
$ modprobe bttv card=113 card=135
In case of further problems please subscribe and send questions to
the mailing list: linux-media@vger.kernel.org.
Probing the cards with broken PCI subsystem ID
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are some TwinHan cards whose EEPROM has become corrupted for some
reason. The cards do not have a correct PCI subsystem ID.
Still, it is possible to force probing the cards with::
$ echo 109e 0878 $subvendor $subdevice > \
/sys/bus/pci/drivers/bt878/new_id
The two numbers there are::
109e: PCI_VENDOR_ID_BROOKTREE
0878: PCI_DEVICE_ID_BROOKTREE_878

2
Documentation/media/v4l-drivers/bttv-cardlist.rst → Documentation/admin-guide/media/bttv-cardlist.rst

@ -12,7 +12,7 @@ BTTV cards list
* - Card number
- Card name
- PCI IDs
- PCI subsystem IDs
* - 0
- *** UNKNOWN/GENERIC ***

431
Documentation/media/v4l-drivers/bttv.rst → Documentation/admin-guide/media/bttv.rst

@ -1,48 +1,64 @@
.. SPDX-License-Identifier: GPL-2.0
===============
The bttv driver
===============
Release notes for bttv
----------------------
You'll need at least these config options for bttv:
You'll need at least these config options for bttv::
.. code-block:: none
./scripts/config -e PCI
./scripts/config -m I2C
./scripts/config -m INPUT
./scripts/config -m MEDIA_SUPPORT
./scripts/config -e MEDIA_PCI_SUPPORT
./scripts/config -e MEDIA_ANALOG_TV_SUPPORT
./scripts/config -e MEDIA_DIGITAL_TV_SUPPORT
./scripts/config -e MEDIA_RADIO_SUPPORT
./scripts/config -e RC_CORE
./scripts/config -m VIDEO_BT848
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_VIDEO_DEV=m
If your board has digital TV, you'll also need::
The latest bttv version is available from http://bytesex.org/bttv/
./scripts/config -m DVB_BT8XX
In this case, please see :doc:`bt8xx` for additional notes.
Make bttv work with your card
-----------------------------
Just try "modprobe bttv" and see if that works.
If you have bttv compiled and installed, just booting the Kernel
should be enough for it to try probing it. However, depending
on the model, the Kernel may require additional information about
the hardware, as the device may not be able to provide such info
directly to the Kernel.
If it doesn't bttv likely could not autodetect your card and needs some
insmod options. The most important insmod option for bttv is "card=n"
to select the correct card type. If you get video but no sound you've
very likely specified the wrong (or no) card type. A list of supported
cards is in CARDLIST.bttv
cards is in :doc:`bttv-cardlist`.
If bttv takes very long to load (happens sometimes with the cheap
cards which have no tuner), try adding this to your modules.conf:
.. code-block:: none
cards which have no tuner), try adding this to your modules configuration
file (usually, it is either ``/etc/modules.conf`` or some file at
``/etc/modules-load.d/``, but the actual place depends on your
distribution)::
options i2c-algo-bit bit_test=1
For the WinTV/PVR you need one firmware file from the driver CD:
hcwamc.rbf. The file is in the pvr45xxx.exe archive (self-extracting
zip file, unzip can unpack it). Put it into the /etc/pvr directory or
use the firm_altera=<path> insmod option to point the driver to the
location of the file.
Some cards may require an extra firmware file to work. For example,
for the WinTV/PVR you need one firmware file from its driver CD,
called: ``hcwamc.rbf``. It is inside a self-extracting zip file
called ``pvr45xxx.exe``. Just placing it at the ``/etc/firmware``
directory should be enough for it to be autoload during the driver's
probing mode (e. g. when the Kernel boots or when the driver is
manually loaded via ``modprobe`` command).
If your card isn't listed in CARDLIST.bttv or if you have trouble making
audio work, you should read the Sound-FAQ.
If your card isn't listed in :doc:`bttv-cardlist` or if you have
trouble making audio work, please read :ref:`still_doesnt_work`.
Autodetecting cards
@ -61,16 +77,19 @@ the Subsystem ID in the second line, looks like this:
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
ID and therefore can't be autodetected. There is a list with the ID's
in bttv-cards.c (in case you are intrested or want to mail patches
with updates).
at :doc:`bttv-cardlist` (in case you are intrested or want to mail
patches with updates).
.. _still_doesnt_work:
Still doesn't work?
-------------------
I do NOT have a lab with 30+ different grabber boards and a
PAL/NTSC/SECAM test signal generator at home, so I often can't
reproduce your problems. This makes debugging very difficult for me.
If you have some knowledge and spare time, please try to fix this
yourself (patches very welcome of course...) You know: The linux
slogan is "Do it yourself".
@ -92,102 +111,103 @@ at least the country you are living in).
Modprobe options
----------------
Note: "modinfo <module>" prints various information about a kernel
module, among them a complete and up-to-date list of insmod options.
This list tends to be outdated because it is updated manually ...
.. note::
==========================================================================
bttv.o
The following argument list can be outdated, as we might add more
options if ever needed. In case of doubt, please check with
``modinfo <module>``.
.. code-block:: none
This command prints various information about a kernel
module, among them a complete and up-to-date list of insmod options.
the bt848/878 (grabber chip) driver
insmod args:
card=n card type, see CARDLIST for a list.
tuner=n tuner type, see CARDLIST for a list.
radio=0/1 card supports radio
pll=0/1/2 pll settings
0: don't use PLL
1: 28 MHz crystal installed
2: 35 MHz crystal installed
triton1=0/1 for Triton1 (+others) compatibility
vsfx=0/1 yet another chipset bug compatibility bit
see README.quirks for details on these two.
bttv
The bt848/878 (grabber chip) driver
bigendian=n Set the endianness of the gfx framebuffer.
Default is native endian.
fieldnr=0/1 Count fields. Some TV descrambling software
needs this, for others it only generates
50 useless IRQs/sec. default is 0 (off).
autoload=0/1 autoload helper modules (tuner, audio).
default is 1 (on).
bttv_verbose=0/1/2 verbose level (at insmod time, while
looking at the hardware). default is 1.
bttv_debug=0/1 debug messages (for capture).
default is 0 (off).
irq_debug=0/1 irq handler debug messages.
default is 0 (off).
gbuffers=2-32 number of capture buffers for mmap'ed capture.
default is 4.
gbufsize= size of capture buffers. default and
maximum value is 0x208000 (~2MB)
no_overlay=0 Enable overlay on broken hardware. There
are some chipsets (SIS for example) which
are known to have problems with the PCI DMA
push used by bttv. bttv will disable overlay
by default on this hardware to avoid crashes.
With this insmod option you can override this.
no_overlay=1 Disable overlay. It should be used by broken
hardware that doesn't support PCI2PCI direct
transfers.
automute=0/1 Automatically mutes the sound if there is
no TV signal, on by default. You might try
to disable this if you have bad input signal
quality which leading to unwanted sound
dropouts.
chroma_agc=0/1 AGC of chroma signal, off by default.
adc_crush=0/1 Luminance ADC crush, on by default.
i2c_udelay= Allow reduce I2C speed. Default is 5 usecs
(meaning 66,67 Kbps). The default is the
maximum supported speed by kernel bitbang
algorithm. You may use lower numbers, if I2C
messages are lost (16 is known to work on
all supported cards).
insmod args::
bttv_gpio=0/1
gpiomask=
audioall=
audiomux=
See Sound-FAQ for a detailed description.
card=n card type, see CARDLIST for a list.
tuner=n tuner type, see CARDLIST for a list.
radio=0/1 card supports radio
pll=0/1/2 pll settings
0: don't use PLL
1: 28 MHz crystal installed
2: 35 MHz crystal installed
triton1=0/1 for Triton1 (+others) compatibility
vsfx=0/1 yet another chipset bug compatibility bit
see README.quirks for details on these two.
bigendian=n Set the endianness of the gfx framebuffer.
Default is native endian.
fieldnr=0/1 Count fields. Some TV descrambling software
needs this, for others it only generates
50 useless IRQs/sec. default is 0 (off).
autoload=0/1 autoload helper modules (tuner, audio).
default is 1 (on).
bttv_verbose=0/1/2 verbose level (at insmod time, while
looking at the hardware). default is 1.
bttv_debug=0/1 debug messages (for capture).
default is 0 (off).
irq_debug=0/1 irq handler debug messages.
default is 0 (off).
gbuffers=2-32 number of capture buffers for mmap'ed capture.
default is 4.
gbufsize= size of capture buffers. default and
maximum value is 0x208000 (~2MB)
no_overlay=0 Enable overlay on broken hardware. There
are some chipsets (SIS for example) which
are known to have problems with the PCI DMA
push used by bttv. bttv will disable overlay
by default on this hardware to avoid crashes.
With this insmod option you can override this.
no_overlay=1 Disable overlay. It should be used by broken
hardware that doesn't support PCI2PCI direct
transfers.
automute=0/1 Automatically mutes the sound if there is
no TV signal, on by default. You might try
to disable this if you have bad input signal
quality which leading to unwanted sound
dropouts.
chroma_agc=0/1 AGC of chroma signal, off by default.
adc_crush=0/1 Luminance ADC crush, on by default.
i2c_udelay= Allow reduce I2C speed. Default is 5 usecs
(meaning 66,67 Kbps). The default is the
maximum supported speed by kernel bitbang
algorithm. You may use lower numbers, if I2C
messages are lost (16 is known to work on
all supported cards).
bttv_gpio=0/1
gpiomask=
audioall=
audiomux=
See Sound-FAQ for a detailed description.
remap, card, radio and pll accept up to four comma-separated arguments
(for multiple boards).
tuner.o
.. code-block:: none
tuner
The tuner driver. You need this unless you want to use only
with a camera or external tuner ...
with a camera or the board doesn't provide analog TV tuning.
insmod args::
insmod args:
debug=1 print some debug info to the syslog
type=n type of the tuner chip. n as follows:
see CARDLIST for a complete list.
pal=[bdgil] select PAL variant (used for some tuners
only, important for the audio carrier).
tvaudio.o
tvaudio
Provide a single driver for all simple i2c audio control
chips (tda/tea*).
.. code-block:: none
insmod args::
new, experimental module which is supported to provide a single
driver for all simple i2c audio control chips (tda/tea*).
insmod args:
tda8425 = 1 enable/disable the support for the
tda9840 = 1 various chips.
tda9850 = 1 The tea6300 can't be autodetected and is
@ -200,45 +220,12 @@ tvaudio.o
the wrong one.
debug = 1 print debug messages
insmod args for tda9874a:
tda9874a_SIF=1/2 select sound IF input pin (1 or 2)
(default is pin 1)
tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0)
Please read note 3 below!
tda9874a_STD=n select TV sound standard (0..8):
0 - A2, B/G
1 - A2, M (Korea)
2 - A2, D/K (1)
3 - A2, D/K (2)
4 - A2, D/K (3)
5 - NICAM, I
6 - NICAM, B/G
7 - NICAM, D/K (default)
8 - NICAM, L
Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips.
Note 2: tda9874h/a and tda9875 (which is supported separately by
tda9875.o) use the same i2c address so both modules should not be
used at the same time.
Note 3: Using tda9874a_AMSEL option depends on your TV card design!
AMSEL=0: auto-mute will switch between NICAM sound
and the sound on 1st carrier (i.e. FM mono or AM).
AMSEL=1: auto-mute will switch between NICAM sound
and the analog mono input (MONOIN pin).
If tda9874a decoder on your card has MONOIN pin not connected, then
use only tda9874_AMSEL=0 or don't specify this option at all.
For example:
card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0
card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only
msp3400.o
.. code-block:: none
msp3400
The driver for the msp34xx sound processor chips. If you have a
stereo card, you probably want to insmod this one.
insmod args:
insmod args::
debug=1/2 print some debug info to the syslog,
2 is more verbose.
simple=1 Use the "short programming" method. Newer
@ -252,40 +239,6 @@ msp3400.o
should improve things for french people, the
carrier autoscan seems to work with FM only...
tea6300.o - OBSOLETE (use tvaudio instead)
.. code-block:: none
The driver for the tea6300 fader chip. If you have a stereo
card and the msp3400.o doesn't work, you might want to try this
one. This chip is seen on most STB TV/FM cards (usually from
Gateway OEM sold surplus on auction sites).
insmod args:
debug=1 print some debug info to the syslog.
tda8425.o - OBSOLETE (use tvaudio instead)
.. code-block:: none
The driver for the tda8425 fader chip. This driver used to be
part of bttv.c, so if your sound used to work but does not
anymore, try loading this module.
insmod args:
debug=1 print some debug info to the syslog.
tda985x.o - OBSOLETE (use tvaudio instead)
.. code-block:: none
The driver for the tda9850/55 audio chips.
insmod args:
debug=1 print some debug info to the syslog.
chip=9850/9855 set the chip type.
If the box freezes hard with bttv
---------------------------------
@ -306,15 +259,15 @@ bug. It is very helpful if you can tell where exactly it broke
With a hard freeze you probably doesn't find anything in the logfiles.
The only way to capture any kernel messages is to hook up a serial
console and let some terminal application log the messages. /me uses
screen. See Documentation/admin-guide/serial-console.rst for details on setting
screen. See :doc:`/admin-guide/serial-console` for details on setting
up a serial console.
Read Documentation/admin-guide/bug-hunting.rst to learn how to get any useful
Read :doc:`/admin-guide/bug-hunting` to learn how to get any useful
information out of a register+stack dump printed by the kernel on
protection faults (so-called "kernel oops").
If you run into some kind of deadlock, you can try to dump a call trace
for each process using sysrq-t (see Documentation/admin-guide/sysrq.rst).
for each process using sysrq-t (see :doc:`/admin-guide/sysrq`).
This way it is possible to figure where *exactly* some process in "D"
state is stuck.
@ -438,134 +391,12 @@ parking, thus lowering arbitration performance. The Bt879 drivers must
query for these non-compliant devices, and set the EN_VSFX bit only if
required.
bttv and sound mini howto
-------------------------
There are a lot of different bt848/849/878/879 based boards available.
Making video work often is not a big deal, because this is handled
completely by the bt8xx chip, which is common on all boards. But
sound is handled in slightly different ways on each board.
To handle the grabber boards correctly, there is a array tvcards[] in
bttv-cards.c, which holds the information required for each board.
Sound will work only, if the correct entry is used (for video it often
makes no difference). The bttv driver prints a line to the kernel
log, telling which card type is used. Like this one:
.. code-block:: none
bttv0: model: BT848(Hauppauge old) [autodetected]
You should verify this is correct. If it isn't, you have to pass the
correct board type as insmod argument, "insmod bttv card=2" for
example. The file CARDLIST has a list of valid arguments for card.
If your card isn't listed there, you might check the source code for
new entries which are not listed yet. If there isn't one for your
card, you can check if one of the existing entries does work for you
(just trial and error...).
Some boards have an extra processor for sound to do stereo decoding
and other nice features. The msp34xx chips are used by Hauppauge for
example. If your board has one, you might have to load a helper
module like msp3400.o to make sound work. If there isn't one for the
chip used on your board: Bad luck. Start writing a new one. Well,
you might want to check the video4linux mailing list archive first...
Of course you need a correctly installed soundcard unless you have the
speakers connected directly to the grabber board. Hint: check the
mixer settings too. ALSA for example has everything muted by default.
How sound works in detail
~~~~~~~~~~~~~~~~~~~~~~~~~
Still doesn't work? Looks like some driver hacking is required.
Below is a do-it-yourself description for you.
The bt8xx chips have 32 general purpose pins, and registers to control
these pins. One register is the output enable register
(BT848_GPIO_OUT_EN), it says which pins are actively driven by the
bt848 chip. Another one is the data register (BT848_GPIO_DATA), where
you can get/set the status if these pins. They can be used for input
and output.
Most grabber board vendors use these pins to control an external chip
which does the sound routing. But every board is a little different.
These pins are also used by some companies to drive remote control
receiver chips. Some boards use the i2c bus instead of the gpio pins
to connect the mux chip.
As mentioned above, there is a array which holds the required
information for each known board. You basically have to create a new
line for your board. The important fields are these two:
.. code-block:: c
struct tvcard
{
[ ... ]
u32 gpiomask;
u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
};
gpiomask specifies which pins are used to control the audio mux chip.
The corresponding bits in the output enable register
(BT848_GPIO_OUT_EN) will be set as these pins must be driven by the
bt848 chip.
The audiomux\[\] array holds the data values for the different inputs
(i.e. which pins must be high/low for tuner/mute/...). This will be
written to the data register (BT848_GPIO_DATA) to switch the audio
mux.
What you have to do is figure out the correct values for gpiomask and
the audiomux array. If you have Windows and the drivers four your
card installed, you might to check out if you can read these registers
values used by the windows driver. A tool to do this is available
from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it
doesn't work with bt878 boards according to some reports I received.
Another one with bt878 support is available from
http://btwincap.sourceforge.net/Files/btspy2.00.zip
You might also dig around in the \*.ini files of the Windows applications.
You can have a look at the board to see which of the gpio pins are
connected at all and then start trial-and-error ...
Starting with release 0.7.41 bttv has a number of insmod options to
make the gpio debugging easier:
.. code-block:: none
bttv_gpio=0/1 enable/disable gpio debug messages
gpiomask=n set the gpiomask value
audiomux=i,j,... set the values of the audiomux array
audioall=a set the values of the audiomux array (one
value for all array elements, useful to check
out which effect the particular value has).
The messages printed with bttv_gpio=1 look like this:
.. code-block:: none
bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off]
en = output _en_able register (BT848_GPIO_OUT_EN)
out = _out_put bits of the data register (BT848_GPIO_DATA),
i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN
in = _in_put bits of the data register,
i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN
Other elements of the tvcards array
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are trying to make a new card work you might find it useful to
know what the other elements in the tvcards array are good for:
.. code-block:: none
know what the other elements in the tvcards array are good for::
video_inputs - # of video inputs the card has
audio_inputs - historical cruft, not used any more.
@ -798,7 +629,9 @@ Typhoon TV card series:
~~~~~~~~~~~~~~~~~~~~~~~
These can be CPH, Flyvideo, Pixelview or KNC1 series.
Typhoon is the brand of Anubis.
Model 50680 got re-used, some model no. had different contents over time.
Models:
@ -950,12 +783,13 @@ is wrong. If it doesn't work, send me email.
on their server are the full data-sheets, but don't ask how I found it.
To use the driver I use the following options, the tuner and pll settings might
be different in your country
be different in your country. You can force it via modprobe parameters.
For example::
insmod videodev
insmod i2c scan=1 i2c_debug=0 verbose=0
insmod tuner type=1 debug=0
insmod bttv pll=1 radio=1 card=17
modprobe bttv tuner=1 pll=28 radio=1 card=17
Sets tuner type 1 (Philips PAL_I), PLL with a 28 MHz crystal, enables
FM radio and selects bttv card ID 17 (Leadtek WinView 601).
KNC One
@ -974,15 +808,16 @@ KNC One
Provideo
~~~~~~~~
- PV951 or PV-951 (also are sold as:
- PV951 or PV-951, now named PV-951T
(also are sold as:
Boeder TV-FM Video Capture Card,
Titanmedia Supervision TV-2400,
Provideo PV951 TF,
3DeMon PV951,
MediaForte TV-Vision PV951,
Yoko PV951,
Vivanco Tuner Card PCI Art.-Nr.: 68404,
) now named PV-951T
Vivanco Tuner Card PCI Art.-Nr.: 68404
)
- Surveillance Series:

357
Documentation/admin-guide/media/building.rst Normal file

@ -0,0 +1,357 @@
.. SPDX-License-Identifier: GPL-2.0
===================================
Building support for a media device
===================================
The first step is to download the Kernel's source code, either via a
distribution-specific source file or via the Kernel's main git tree\ [1]_.
Please notice, however, that, if:
- you're a braveheart and want to experiment with new stuff;
- if you want to report a bug;
- if you're developing new patches
you should use the main media development tree ``master`` branch:
https://git.linuxtv.org/media_tree.git/
In this case, you may find some useful information at the
`LinuxTv wiki pages <https://linuxtv.org/wiki>`_:
https://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
.. [1] The upstream Linux Kernel development tree is located at
https://git.kernel.org/pub/scm/li nux/kernel/git/torvalds/linux.git/
Configuring the Linux Kernel
============================
You can access a menu of Kernel building options with::
$ make menuconfig
Then, select all desired options and exit it, saving the configuration.
The changed configuration will be at the ``.config`` file. It would
look like::
...
# CONFIG_RC_CORE is not set
# CONFIG_CEC_CORE is not set
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_SUPPORT_FILTER=y
...
The media subsystem is controlled by those menu configuration options::
Device Drivers --->
<M> Remote Controller support --->
[ ] HDMI CEC RC integration
[ ] Enable CEC error injection support
[*] HDMI CEC drivers --->
<*> Multimedia support --->
The ``Remote Controller support`` option enables the core support for
remote controllers\ [2]_.
The ``HDMI CEC RC integration`` option enables integration of HDMI CEC
with Linux, allowing to receive data via HDMI CEC as if it were produced
by a remote controller directly connected to the machine.
The ``HDMI CEC drivers`` option allow selecting platform and USB drivers
that receives and/or transmits CEC codes via HDMI interfaces\ [3]_.
The last option (``Multimedia support``) enables support for cameras,
audio/video grabbers and TV.
The media subsystem support can either be built together with the main
Kernel or as a module. For most use cases, it is preferred to have it
built as modules.
.. note::
Instead of using a menu, the Kernel provides a script with allows
enabling configuration options directly. To enable media support
and remote controller support using Kernel modules, you could use::
$ scripts/config -m RC_CORE
$ scripts/config -m MEDIA_SUPPORT
.. [2] ``Remote Controller support`` should also be enabled if you
want to use some TV card drivers that may depend on the remote
controller core support.
.. [3] Please notice that the DRM subsystem also have drivers for GPUs
that use the media HDMI CEC support.
Those GPU-specific drivers are selected via the ``Graphics support``
menu, under ``Device Drivers``.
When a GPU driver supports supports HDMI CEC, it will automatically
enable the CEC core support at the media subsystem.
Media dependencies
------------------
It should be noticed that enabling the above from a clean config is
usually not enough. The media subsystem depends on several other Linux
core support in order to work.
For example, most media devices use a serial communication bus in
order to talk with some peripherals. Such bus is called I²C
(Inter-Integrated Circuit). In order to be able to build support
for such hardware, the I²C bus support should be enabled, either via
menu or with::
./scripts/config -m I2C
Another example: the remote controller core requires support for
input devices, with can be enabled with::
./scripts/config -m INPUT
Other core functionality may also be needed (like PCI and/or USB support),
depending on the specific driver(s) you would like to enable.
Enabling Remote Controller Support
----------------------------------
The remote controller menu allows selecting drivers for specific devices.
It's menu looks like this::
--- Remote Controller support
<M> Compile Remote Controller keymap modules
[*] LIRC user interface
[*] Support for eBPF programs attached to lirc devices
[*] Remote controller decoders --->
[*] Remote Controller devices --->
The ``Compile Remote Controller keymap modules`` option creates key maps for
several popular remote controllers.
The ``LIRC user interface`` option adds enhanced functionality when using the
``lirc`` program, by enabling an API that allows userspace to receive raw data
from remote controllers.
The ``Support for eBPF programs attached to lirc devices`` option allows
the usage of special programs (called eBPF) that would allow aplications
to add extra remote controller decoding functionality to the Linux Kernel.
The ``Remote controller decoders`` option allows selecting the
protocols that will be recognized by the Linux Kernel. Except if you
want to disable some specific decoder, it is suggested to keep all
sub-options enabled.
The ``Remote Controller devices`` allows you to select the drivers
that would be needed to support your device.
The same configuration can also be set via the ``script/config``
script. So, for instance, in order to support the ITE remote controller
driver (found on Intel NUCs and on some ASUS x86 desktops), you could do::
$ scripts/config -e INPUT
$ scripts/config -e ACPI
$ scripts/config -e MODULES
$ scripts/config -m RC_CORE
$ scripts/config -e RC_DEVICES
$ scripts/config -e RC_DECODERS
$ scripts/config -m IR_RC5_DECODER
$ scripts/config -m IR_ITE_CIR
Enabling HDMI CEC Support
-------------------------
The HDMI CEC support is set automatically when a driver requires it. So,
all you need to do is to enable support either for a graphics card
that needs it or by one of the existing HDMI drivers.
The HDMI-specific drivers are available at the ``HDMI CEC drivers``
menu\ [4]_::
--- HDMI CEC drivers
< > ChromeOS EC CEC driver
< > Amlogic Meson AO CEC driver
< > Amlogic Meson G12A AO CEC driver
< > Generic GPIO-based CEC driver
< > Samsung S5P CEC driver
< > STMicroelectronics STiH4xx HDMI CEC driver
< > STMicroelectronics STM32 HDMI CEC driver
< > Tegra HDMI CEC driver
< > SECO Boards HDMI CEC driver
[ ] SECO Boards IR RC5 support
< > Pulse Eight HDMI CEC
< > RainShadow Tech HDMI CEC
.. [4] The above contents is just an example. The actual options for
HDMI devices depends on the system's architecture and may vary
on new Kernels.
Enabling Media Support
----------------------
The Media menu has a lot more options than the remote controller menu.
Once selected, you should see the following options::
--- Media support
[ ] Filter media drivers
[*] Autoselect ancillary drivers
Media device types --->
Media core support --->
Video4Linux options --->
Media controller options --->
Digital TV options --->
HDMI CEC options --->
Media drivers --->
Media ancillary drivers --->
Except if you know exactly what you're doing, or if you want to build
a driver for a SoC platform, it is strongly recommended to keep the
``Autoselect ancillary drivers`` option turned on, as it will auto-select
the needed I²C ancillary drivers.
There are now two ways to select media device drivers, as described
below.
``Filter media drivers`` menu
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This menu is meant to easy setup for PC and Laptop hardware. It works
by letting the user to specify what kind of media drivers are desired,
with those options::
[ ] Cameras and video grabbers
[ ] Analog TV
[ ] Digital TV
[ ] AM/FM radio receivers/transmitters
[ ] Software defined radio
[ ] Platform-specific devices
[ ] Test drivers
So, if you want to add support to a camera or video grabber only,
select just the first option. Multiple options are allowed.
Once the options on this menu are selected, the building system will
auto-select the needed core drivers in order to support the selected
functionality.
.. note::
Most TV cards are hybrid: they support both Analog TV and Digital TV.
If you have an hybrid card, you may need to enable both ``Analog TV``
and ``Digital TV`` at the menu.
When using this option, the defaults for the the media support core
functionality are usually good enough to provide the basic functionality
for the driver. Yet, you could manually enable some desired extra (optional)
functionality using the settings under each of the following
``Media support`` sub-menus::
Media core support --->
Video4Linux options --->
Media controller options --->
Digital TV options --->
HDMI CEC options --->
Once you select the desired filters, the drivers that matches the filtering
criteria will be available at the ``Media support->Media drivers`` sub-menu.
``Media Core Support`` menu without filtering
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you disable the ``Filter media drivers`` menu, all drivers available
for your system whose dependencies are met should be shown at the
``Media drivers`` menu.
Please notice, however, that you should first ensure that the
``Media Core Support`` menu has all the core functionality your drivers
would need, as otherwise the corresponding device drivers won't be shown.
Example
-------
In order to enable modular support for one of the boards listed on
:doc:`this table <cx231xx-cardlist>`, with modular media core modules, the
``.config`` file should contain those lines::
CONFIG_MODULES=y
CONFIG_USB=y
CONFIG_I2C=y
CONFIG_INPUT=y
CONFIG_RC_CORE=m
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_SUPPORT_FILTER=y
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_VIDEO_CX231XX=y
CONFIG_VIDEO_CX231XX_DVB=y
Building and installing a new Kernel
====================================
Once the ``.config`` file has everything needed, all it takes to build
is to run the ``make`` command::
$ make
And then install the new Kernel and its modules::
$ sudo make modules_install
$ sudo make install
Building just the new media drivers and core
============================================
Running a new development Kernel from the development tree is usually risky,
because it may have experimental changes that may have bugs. So, there are
some ways to build just the new drivers, using alternative trees.
There is the `Linux Kernel backports project
<https://backports.wiki.kernel.org/index.php/Main_Page>`_, with contains
newer drivers meant to be compiled against stable Kernels.
The LinuxTV developers, with are responsible for maintaining the media
subsystem also maintains a backport tree, with just the media drivers
daily updated from the newest kernel. Such tree is available at:
https://git.linuxtv.org/media_build.git/
It should be noticed that, while it should be relatively safe to use the
``media_build`` tree for testing purposes, there are not warranties that
it would work (or even build) on a random Kernel. This tree is maintained
using a "best-efforts" principle, as time permits us to fix issues there.
If you notice anything wrong on it, feel free to submit patches at the
Linux media subsystem's mailing list: media@vger.kernel.org. Please
add ``[PATCH media-build]`` at the e-mail's subject if you submit a new
patch for the media-build.
Before using it, you should run::
$ ./build
.. note::
1) you may need to run it twice if the ``media-build`` tree gets
updated;
2) you may need to do a ``make distclean`` if you had built it
in the past for a different Kernel version than the one you're
currently using;
3) by default, it will use the same config options for media as
the ones defined on the Kernel you're running.
In order to select different drivers or different config options,
use::
$ make menuconfig
Then, you can build and install the new drivers::
$ make && sudo make install
This will override the previous media drivers that your Kernel were
using.

0
Documentation/media/v4l-drivers/cafe_ccic.rst → Documentation/admin-guide/media/cafe_ccic.rst

29
Documentation/admin-guide/media/cardlist.rst Normal file

@ -0,0 +1,29 @@
.. SPDX-License-Identifier: GPL-2.0
==========
Cards List
==========
The media subsystem provide support for lots of PCI and USB drivers, plus
platform-specific drivers. It also contains several ancillary I²C drivers.
The platform-specific drivers are usually present on embedded systems,
or are supported by the main board. Usually, setting them is done via
OpenFirmware or ACPI.
The PCI and USB drivers, however, are independent of the system's board,
and may be added/removed by the user.
You may also take a look at
https://linuxtv.org/wiki/index.php/Hardware_Device_Information
for more details about supported cards.
.. toctree::
:maxdepth: 2
usb-cardlist
pci-cardlist
platform-cardlist
radio-cardlist
i2c-cardlist
misc-cardlist

10
Documentation/admin-guide/media/cec-drivers.rst Normal file

@ -0,0 +1,10 @@
.. SPDX-License-Identifier: GPL-2.0
=================================
CEC driver-specific documentation
=================================
.. toctree::
:maxdepth: 2
pulse8-cec

77
Documentation/admin-guide/media/ci.rst Normal file

@ -0,0 +1,77 @@
.. SPDX-License-Identifier: GPL-2.0
Digital TV Conditional Access Interface
=======================================
.. note::
This documentation is outdated.
This document describes the usage of the high level CI API as
in accordance to the Linux DVB API. This is a not a documentation for the,
existing low level CI API.
.. note::
For the Twinhan/Twinhan clones, the dst_ca module handles the CI
hardware handling. This module is loaded automatically if a CI
(Common Interface, that holds the CAM (Conditional Access Module)
is detected.
ca_zap
~~~~~~
A userspace application, like ``ca_zap`` is required to handle encrypted
MPEG-TS streams.
The ``ca_zap`` userland application is in charge of sending the
descrambling related information to the Conditional Access Module (CAM).
This application requires the following to function properly as of now.
a) Tune to a valid channel, with szap.
eg: $ szap -c channels.conf -r "TMC" -x
b) a channels.conf containing a valid PMT PID
eg: TMC:11996:h:0:27500:278:512:650:321
here 278 is a valid PMT PID. the rest of the values are the
same ones that szap uses.
c) after running a szap, you have to run ca_zap, for the
descrambler to function,
eg: $ ca_zap channels.conf "TMC"
d) Hopefully enjoy your favourite subscribed channel as you do with
a FTA card.
.. note::
Currently ca_zap, and dst_test, both are meant for demonstration
purposes only, they can become full fledged applications if necessary.
Cards that fall in this category
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At present the cards that fall in this category are the Twinhan and its
clones, these cards are available as VVMER, Tomato, Hercules, Orange and
so on.
CI modules that are supported
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The CI module support is largely dependent upon the firmware on the cards
Some cards do support almost all of the available CI modules. There is
nothing much that can be done in order to make additional CI modules
working with these cards.
Modules that have been tested by this driver at present are
(1) Irdeto 1 and 2 from SCM
(2) Viaccess from SCM
(3) Dragoncam

145
Documentation/admin-guide/media/cpia2.rst Normal file

@ -0,0 +1,145 @@
.. SPDX-License-Identifier: GPL-2.0
The cpia2 driver
================
Authors: Peter Pregler <Peter_Pregler@email.com>,
Scott J. Bertin <scottbertin@yahoo.com>, and
Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
this one was modelled from.
Introduction
------------
This is a driver for STMicroelectronics's CPiA2 (second generation
Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG
stream at up to vga size. It implements the Video4Linux interface as much as
possible. Since the V4L interface does not support compressed formats, only
an mjpeg enabled application can be used with the camera. We have modified the
gqcam application to view this stream.
The driver is implemented as two kernel modules. The cpia2 module
contains the camera functions and the V4L interface. The cpia2_usb module
contains usb specific functions. The main reason for this was the size of the
module was getting out of hand, so I separated them. It is not likely that
there will be a parallel port version.
Features
--------
- Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos
sensors. I only have the vga sensor, so can't test the other.
- Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between.
VGA and QVGA are the native image sizes for the VGA camera. CIF is done
in the coprocessor by scaling QVGA. All other sizes are done by clipping.
- Palette: YCrCb, compressed with MJPEG.
- Some compression parameters are settable.
- Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA).
- Adjust brightness, color, contrast while streaming.
- Flicker control settable for 50 or 60 Hz mains frequency.
Making and installing the stv672 driver modules
-----------------------------------------------
Requirements
~~~~~~~~~~~~
Video4Linux must be either compiled into the kernel or
available as a module. Video4Linux2 is automatically detected and made
available at compile time.
Setup
~~~~~
Use ``modprobe cpia2`` to load and ``modprobe -r cpia2`` to unload. This
may be done automatically by your distribution.
Driver options
~~~~~~~~~~~~~~
.. tabularcolumns:: |p{13ex}|L|
============== ========================================================
Option Description
============== ========================================================
video_nr video device to register (0=/dev/video0, etc)
range -1 to 64. default is -1 (first available)
If you have more than 1 camera, this MUST be -1.
buffer_size Size for each frame buffer in bytes (default 68k)
num_buffers Number of frame buffers (1-32, default 3)
alternate USB Alternate (2-7, default 7)
flicker_freq Frequency for flicker reduction(50 or 60, default 60)
flicker_mode 0 to disable, or 1 to enable flicker reduction.
(default 0). This is only effective if the camera
uses a stv0672 coprocessor.
============== ========================================================
Setting the options
~~~~~~~~~~~~~~~~~~~
If you are using modules, edit /etc/modules.conf and add an options
line like this::
options cpia2 num_buffers=3 buffer_size=65535
If the driver is compiled into the kernel, at boot time specify them
like this::
cpia2.num_buffers=3 cpia2.buffer_size=65535
What buffer size should I use?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The maximum image size depends on the alternate you choose, and the
frame rate achieved by the camera. If the compression engine is able to
keep up with the frame rate, the maximum image size is given by the table
below.
The compression engine starts out at maximum compression, and will
increase image quality until it is close to the size in the table. As long
as the compression engine can keep up with the frame rate, after a short time
the images will all be about the size in the table, regardless of resolution.
At low alternate settings, the compression engine may not be able to
compress the image enough and will reduce the frame rate by producing larger
images.
The default of 68k should be good for most users. This will handle
any alternate at frame rates down to 15fps. For lower frame rates, it may
be necessary to increase the buffer size to avoid having frames dropped due
to insufficient space.
========== ========== ======== =====
Alternate bytes/ms 15fps 30fps
========== ========== ======== =====
2 128 8533 4267
3 384 25600 12800
4 640 42667 21333
5 768 51200 25600
6 896 59733 29867
7 1023 68200 34100
========== ========== ======== =====
Table: Image size(bytes)
How many buffers should I use?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For normal streaming, 3 should give the best results. With only 2,
it is possible for the camera to finish sending one image just after a
program has started reading the other. If this happens, the driver must drop
a frame. The exception to this is if you have a heavily loaded machine. In
this case use 2 buffers. You are probably not reading at the full frame rate.
If the camera can send multiple images before a read finishes, it could
overwrite the third buffer before the read finishes, leading to a corrupt
image. Single and double buffering have extra checks to avoid overwriting.
Using the camera
~~~~~~~~~~~~~~~~
We are providing a modified gqcam application to view the output. In
order to avoid confusion, here it is called mview. There is also the qx5view
program which can also control the lights on the qx5 microscope. MJPEG Tools
(http://mjpeg.sourceforge.net) can also be used to record from the camera.

17
Documentation/admin-guide/media/cx18-cardlist.rst Normal file

@ -0,0 +1,17 @@
.. SPDX-License-Identifier: GPL-2.0
CX18 cards list
===============
Those cards are supported by cx18 driver:
- Hauppauge HVR-1600 (ESMT memory)
- Hauppauge HVR-1600 (Samsung memory)
- Compro VideoMate H900
- Yuan MPC718 MiniPCI DVB-T/Analog
- Conexant Raptor PAL/SECAM
- Toshiba Qosmio DVB-T/Analog
- Leadtek WinFast PVR2100
- Leadtek WinFast DVR3100
- GoTView PCI DVD3 Hybrid
- Hauppauge HVR-1600 (s5h1411/tda18271)

99
Documentation/admin-guide/media/cx231xx-cardlist.rst Normal file

@ -0,0 +1,99 @@
.. SPDX-License-Identifier: GPL-2.0
cx231xx cards list
==================
.. tabularcolumns:: |p{1.4cm}|p{10.0cm}|p{6.5cm}|
.. flat-table::
:header-rows: 1
:widths: 2 12 19
:stub-columns: 0
* - Card number
- Card name
- USB IDs
* - 0
- Unknown CX231xx video grabber
- 0572:5A3C
* - 1
- Conexant Hybrid TV - CARRAERA
- 0572:58A2
* - 2
- Conexant Hybrid TV - SHELBY
- 0572:58A1
* - 3
- Conexant Hybrid TV - RDE253S
- 0572:58A4
* - 4
- Conexant Hybrid TV - RDU253S
- 0572:58A5
* - 5
- Conexant VIDEO GRABBER
- 0572:58A6, 07ca:c039
* - 6
- Conexant Hybrid TV - rde 250
- 0572:589E
* - 7
- Conexant Hybrid TV - RDU 250
- 0572:58A0
* - 8
- Hauppauge EXETER
- 2040:b120, 2040:b140
* - 9
- Hauppauge USB Live 2
- 2040:c200
* - 10
- Pixelview PlayTV USB Hybrid
- 4000:4001
* - 11
- Pixelview Xcapture USB
- 1D19:6109, 4000:4001
* - 12
- Kworld UB430 USB Hybrid
- 1b80:e424
* - 13
- Iconbit Analog Stick U100 FM
- 1f4d:0237
* - 14
- Hauppauge WinTV USB2 FM (PAL)
- 2040:b110
* - 15
- Hauppauge WinTV USB2 FM (NTSC)
- 2040:b111
* - 16
- Elgato Video Capture V2
- 0fd9:0037
* - 17
- Geniatech OTG102
- 1f4d:0102
* - 18
- Kworld UB445 USB Hybrid
- 1b80:e421
* - 19
- Hauppauge WinTV 930C-HD (1113xx) / HVR-900H (111xxx) / PCTV QuatroStick 521e
- 2040:b130, 2040:b138, 2013:0259
* - 20
- Hauppauge WinTV 930C-HD (1114xx) / HVR-901H (1114xx) / PCTV QuatroStick 522e
- 2040:b131, 2040:b139, 2013:025e
* - 21
- Hauppauge WinTV-HVR-955Q (111401)
- 2040:b123, 2040:b124
* - 22
- Terratec Grabby
- 1f4d:0102
* - 23
- Evromedia USB Full Hybrid Full HD
- 1b80:d3b2
* - 24
- Astrometa T2hybrid
- 15f4:0135
* - 25
- The Imaging Source DFG/USB2pro
- 199e:8002
* - 26
- Hauppauge WinTV-HVR-935C
- 2040:b151
* - 27
- Hauppauge WinTV-HVR-975
- 2040:b150

6
Documentation/media/v4l-drivers/cx23885-cardlist.rst → Documentation/admin-guide/media/cx23885-cardlist.rst

@ -12,7 +12,7 @@ cx23885 cards list
* - Card number
- Card name
- PCI IDs
- PCI subsystem IDs
* - 0
- UNKNOWN/GENERIC
@ -261,3 +261,7 @@ cx23885 cards list
* - 61
- Hauppauge WinTV-QuadHD-ATSC(885)
-
* - 62
- AVerMedia CE310B
- 1461:3100

6
Documentation/media/v4l-drivers/cx88-cardlist.rst → Documentation/admin-guide/media/cx88-cardlist.rst

@ -12,7 +12,7 @@ CX88 cards list
* - Card number
- Card name
- PCI IDs
- PCI subsystem IDs
* - 0
- UNKNOWN/GENERIC
@ -377,3 +377,7 @@ CX88 cards list
* - 90
- Leadtek TV2000 XP Global (XC4100)
- 107d:6f43
* - 91
- NotOnlyTV LV3H
-

58
Documentation/admin-guide/media/cx88.rst Normal file

@ -0,0 +1,58 @@
.. SPDX-License-Identifier: GPL-2.0
The cx88 driver
===============
Author: Gerd Hoffmann
This is a v4l2 device driver for the cx2388x chip.
Current status
--------------
video
- Works.
- Overlay isn't supported.
audio
- Works. The TV standard detection is made by the driver, as the
hardware has bugs to auto-detect.
- audio data dma (i.e. recording without loopback cable to the
sound card) is supported via cx88-alsa.
vbi
- Works.
How to add support for new cards
--------------------------------
The driver needs some config info for the TV cards. This stuff is in
cx88-cards.c. If the driver doesn't work well you likely need a new
entry for your card in that file. Check the kernel log (using dmesg)
to see whenever the driver knows your card or not. There is a line
like this one:
.. code-block:: none
cx8800[0]: subsystem: 0070:3400, board: Hauppauge WinTV \
34xxx models [card=1,autodetected]
If your card is listed as "board: UNKNOWN/GENERIC" it is unknown to
the driver. What to do then?
1) Try upgrading to the latest snapshot, maybe it has been added
meanwhile.
2) You can try to create a new entry yourself, have a look at
cx88-cards.c. If that worked, mail me your changes as unified
diff ("diff -u").
3) Or you can mail me the config information. We need at least the
following information to add the card:
- the PCI Subsystem ID ("0070:3400" from the line above,
"lspci -v" output is fine too).
- the tuner type used by the card. You can try to find one by
trial-and-error using the tuner=<n> insmod option. If you
know which one the card has you can also have a look at the
list in CARDLIST.tuner

65
Documentation/admin-guide/media/davinci-vpbe.rst Normal file

@ -0,0 +1,65 @@
.. SPDX-License-Identifier: GPL-2.0
The VPBE V4L2 driver design
===========================
Functional partitioning
-----------------------
Consists of the following:
1. V4L2 display driver
Implements creation of video2 and video3 device nodes and
provides v4l2 device interface to manage VID0 and VID1 layers.
2. Display controller
Loads up VENC, OSD and external encoders such as ths8200. It provides
a set of API calls to V4L2 drivers to set the output/standards
in the VENC or external sub devices. It also provides
a device object to access the services from OSD subdevice
using sub device ops. The connection of external encoders to VENC LCD
controller port is done at init time based on default output and standard
selection or at run time when application change the output through
V4L2 IOCTLs.
When connected to an external encoder, vpbe controller is also responsible
for setting up the interface between VENC and external encoders based on
board specific settings (specified in board-xxx-evm.c). This allows
interfacing external encoders such as ths8200. The setup_if_config()
is implemented for this as well as configure_venc() (part of the next patch)
API to set timings in VENC for a specific display resolution. As of this
patch series, the interconnection and enabling and setting of the external
encoders is not present, and would be a part of the next patch series.
3. VENC subdevice module
Responsible for setting outputs provided through internal DACs and also
setting timings at LCD controller port when external encoders are connected
at the port or LCD panel timings required. When external encoder/LCD panel
is connected, the timings for a specific standard/preset is retrieved from
the board specific table and the values are used to set the timings in
venc using non-standard timing mode.
Support LCD Panel displays using the VENC. For example to support a Logic
PD display, it requires setting up the LCD controller port with a set of
timings for the resolution supported and setting the dot clock. So we could
add the available outputs as a board specific entry (i.e add the "LogicPD"
output name to board-xxx-evm.c). A table of timings for various LCDs
supported can be maintained in the board specific setup file to support
various LCD displays.As of this patch a basic driver is present, and this
support for external encoders and displays forms a part of the next
patch series.
4. OSD module
OSD module implements all OSD layer management and hardware specific
features. The VPBE module interacts with the OSD for enabling and
disabling appropriate features of the OSD.
Current status
--------------
A fully functional working version of the V4L2 driver is available. This
driver has been tested with NTSC and PAL standards and buffer streaming.

16
Documentation/admin-guide/media/dvb-drivers.rst Normal file

@ -0,0 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
========================================
Digital TV driver-specific documentation
========================================
.. toctree::
:maxdepth: 2
avermedia
bt8xx
lmedm04
opera-firmware
technisat
ttusb-dec
zr364xx

16
Documentation/admin-guide/media/dvb-usb-a800-cardlist.rst Normal file

@ -0,0 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-a800 cards list
=======================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - AVerMedia AverTV DVB-T USB 2.0 (A800)
- 07ca:a800, 07ca:a801

20
Documentation/admin-guide/media/dvb-usb-af9005-cardlist.rst Normal file

@ -0,0 +1,20 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-af9005 cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - Afatech DVB-T USB1.1 stick
- 15a4:9020
* - Ansonic DVB-T USB1.1 stick
- 10b9:6000
* - TerraTec Cinergy T USB XE
- 0ccd:0055

80
Documentation/admin-guide/media/dvb-usb-af9015-cardlist.rst Normal file

@ -0,0 +1,80 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-af9015 cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - AVerMedia A309
- 07ca:a309
* - AVerMedia AVerTV DVB-T Volar X
- 07ca:a815
* - Afatech AF9015 reference design
- 15a4:9015, 15a4:9016
* - AverMedia AVerTV Red HD+ (A850T)
- 07ca:850b
* - AverMedia AVerTV Volar Black HD (A850)
- 07ca:850a
* - AverMedia AVerTV Volar GPS 805 (A805)
- 07ca:a805
* - AverMedia AVerTV Volar M (A815Mac)
- 07ca:815a
* - Conceptronic USB2.0 DVB-T CTVDIGRCU V3.0
- 1b80:e397
* - DigitalNow TinyTwin
- 13d3:3226
* - DigitalNow TinyTwin v2
- 1b80:e402
* - DigitalNow TinyTwin v3
- 1f4d:9016
* - Fujitsu-Siemens Slim Mobile USB DVB-T
- 07ca:8150
* - Genius TVGo DVB-T03
- 0458:4012
* - KWorld Digital MC-810
- 1b80:c810
* - KWorld PlusTV DVB-T PCI Pro Card (DVB-T PC160-T)
- 1b80:c161
* - KWorld PlusTV Dual DVB-T PCI (DVB-T PC160-2T)
- 1b80:c160
* - KWorld PlusTV Dual DVB-T Stick (DVB-T 399U)
- 1b80:e399, 1b80:e400
* - KWorld USB DVB-T Stick Mobile (UB383-T)
- 1b80:e383
* - KWorld USB DVB-T TV Stick II (VS-DVB-T 395U)
- 1b80:e396, 1b80:e39b, 1b80:e395, 1b80:e39a
* - Leadtek WinFast DTV Dongle Gold
- 0413:6029
* - Leadtek WinFast DTV2000DS
- 0413:6a04
* - MSI DIGIVOX Duo
- 1462:8801
* - MSI Digi VOX mini III
- 1462:8807
* - Pinnacle PCTV 71e
- 2304:022b
* - Sveon STV20 Tuner USB DVB-T HDTV
- 1b80:e39d
* - Sveon STV22 Dual USB DVB-T Tuner HDTV
- 1b80:e401
* - Telestar Starstick 2
- 10b9:8000
* - TerraTec Cinergy T Stick Dual RC
- 0ccd:0099
* - TerraTec Cinergy T Stick RC
- 0ccd:0097
* - TerraTec Cinergy T USB XE
- 0ccd:0069
* - TrekStor DVB-T USB Stick
- 15a4:901b
* - TwinHan AzureWave AD-TU700(704J)
- 13d3:3237
* - Xtensions XD-380
- 1ae7:0381

74
Documentation/admin-guide/media/dvb-usb-af9035-cardlist.rst Normal file

@ -0,0 +1,74 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-af9035 cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - AVerMedia AVerTV Volar HD/PRO (A835)
- 07ca:a835, 07ca:b835
* - AVerMedia HD Volar (A867)
- 07ca:1867, 07ca:a867, 07ca:0337
* - AVerMedia TD310 DVB-T2
- 07ca:1871
* - AVerMedia Twinstar (A825)
- 07ca:0825
* - Afatech AF9035 reference design
- 15a4:9035, 15a4:1000, 15a4:1001, 15a4:1002, 15a4:1003
* - Asus U3100Mini Plus
- 0b05:1779
* - Avermedia A835B(1835)
- 07ca:1835
* - Avermedia A835B(2835)
- 07ca:2835
* - Avermedia A835B(3835)
- 07ca:3835
* - Avermedia A835B(4835)
- 07ca:4835
* - Avermedia AverTV Volar HD 2 (TD110)
- 07ca:a110
* - Avermedia H335
- 07ca:0335
* - Digital Dual TV Receiver CTVDIGDUAL_V2
- 1b80:e410
* - EVOLVEO XtraTV stick
- 1f4d:a115
* - Hauppauge WinTV-MiniStick 2
- 2040:f900
* - ITE 9135 Generic
- 048d:9135
* - ITE 9135(9005) Generic
- 048d:9005
* - ITE 9135(9006) Generic
- 048d:9006
* - ITE 9303 Generic
- 048d:9306
* - Kworld UB499-2T T09
- 1b80:e409
* - Leadtek WinFast DTV Dongle Dual
- 0413:6a05
* - Logilink VG0022A
- 1d19:0100
* - PCTV AndroiDTV (78e)
- 2013:025a
* - PCTV microStick (79e)
- 2013:0262
* - Sveon STV22 Dual DVB-T HDTV
- 1b80:e411
* - TerraTec Cinergy T Stick
- 0ccd:0093
* - TerraTec Cinergy T Stick (rev. 2)
- 0ccd:00aa
* - TerraTec Cinergy T Stick Dual RC (rev. 2)
- 0ccd:0099
* - TerraTec Cinergy TC2 Stick
- 0ccd:10b2
* - TerraTec T1
- 0ccd:10ae

16
Documentation/admin-guide/media/dvb-usb-anysee-cardlist.rst Normal file

@ -0,0 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-anysee cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - Anysee
- 04b4:861f, 1c73:861f

16
Documentation/admin-guide/media/dvb-usb-au6610-cardlist.rst Normal file

@ -0,0 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-au6610 cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - Sigmatek DVB-110
- 058f:6610

20
Documentation/admin-guide/media/dvb-usb-az6007-cardlist.rst Normal file

@ -0,0 +1,20 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-az6007 cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - Azurewave 6007
- 13d3:0ccd
* - Technisat CableStar Combo HD CI
- 14f7:0003
* - Terratec H7
- 0ccd:10b4, 0ccd:10a3

24
Documentation/admin-guide/media/dvb-usb-az6027-cardlist.rst Normal file

@ -0,0 +1,24 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-az6027 cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - AZUREWAVE DVB-S/S2 USB2.0 (AZ6027)
- 13d3:3275
* - Elgato EyeTV Sat
- 0fd9:002a, 0fd9:0025, 0fd9:0036
* - TERRATEC S7
- 0ccd:10a4
* - TERRATEC S7 MKII
- 0ccd:10ac
* - Technisat SkyStar USB 2 HD CI
- 14f7:0001, 14f7:0002

18
Documentation/admin-guide/media/dvb-usb-ce6230-cardlist.rst Normal file

@ -0,0 +1,18 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-ce6230 cards list
=========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - AVerMedia A310 USB 2.0 DVB-T tuner
- 07ca:a310
* - Intel CE9500 reference design
- 8086:9500

16
Documentation/admin-guide/media/dvb-usb-cinergyT2-cardlist.rst Normal file

@ -0,0 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-cinergyT2 cards list
============================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - TerraTec/qanu USB2.0 Highspeed DVB-T Receiver
- 0ccd:0x0038

40
Documentation/admin-guide/media/dvb-usb-cxusb-cardlist.rst Normal file

@ -0,0 +1,40 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-cxusb cards list
========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - AVerMedia AVerTVHD Volar (A868R)
-
* - Conexant DMB-TH Stick
-
* - DViCO FusionHDTV DVB-T Dual Digital 2
-
* - DViCO FusionHDTV DVB-T Dual Digital 4
-
* - DViCO FusionHDTV DVB-T Dual Digital 4 (rev 2)
-
* - DViCO FusionHDTV DVB-T Dual USB
-
* - DViCO FusionHDTV DVB-T NANO2
-
* - DViCO FusionHDTV DVB-T USB (LGZ201)
-
* - DViCO FusionHDTV DVB-T USB (TH7579)
-
* - DViCO FusionHDTV5 USB Gold
-
* - DigitalNow DVB-T Dual USB
-
* - Medion MD95700 (MDUSBTV-HYBRID)
-
* - Mygica D689 DMB-TH
-

162
Documentation/admin-guide/media/dvb-usb-dib0700-cardlist.rst Normal file

@ -0,0 +1,162 @@
.. SPDX-License-Identifier: GPL-2.0
dvb-usb-dib0700 cards list
==========================
.. tabularcolumns:: |p{7.0cm}|p{10.5cm}|
.. flat-table::
:header-rows: 1
:widths: 7 13
:stub-columns: 0
* - Card name
- USB IDs
* - ASUS My Cinema U3000 Mini DVBT Tuner
- 0b05:171f
* - ASUS My Cinema U3100 Mini DVBT Tuner
- 0b05:173f
* - AVerMedia AVerTV DVB-T Express
- 07ca:b568
* - AVerMedia AVerTV DVB-T Volar
- 07ca:a807, 07ca:b808
* - Artec T14BR DVB-T
- 05d8:810f
* - Asus My Cinema-U3000Hybrid
- 0b05:1736
* - Compro Videomate U500
- 185b:1e78, 185b:1e80
* - DiBcom NIM7090 reference design
- 10b8:1bb2
* - DiBcom NIM8096MD reference design
- 10b8:1fa8
* - DiBcom NIM9090MD reference design
- 10b8:2384
* - DiBcom STK7070P reference design
- 10b8:1ebc
* - DiBcom STK7070PD reference design
- 10b8:1ebe
* - DiBcom STK7700D reference design
- 10b8:1ef0
* - DiBcom STK7700P reference design
- 10b8:1e14, 10b8:1e78
* - DiBcom STK7770P reference design
- 10b8:1e80
* - DiBcom STK807xP reference design
- 10b8:1f90
* - DiBcom STK807xPVR reference design
- 10b8:1f98
* - DiBcom STK8096-PVR reference design
- 2013:1faa, 10b8:1faa
* - DiBcom STK8096GP reference design
- 10b8:1fa0
* - DiBcom STK9090M reference design
- 10b8:2383
* - DiBcom TFE7090PVR reference design
- 10b8:1bb4
* - DiBcom TFE7790P reference design
- 10b8:1e6e
* - DiBcom TFE8096P reference design
- 10b8:1f9C
* - Elgato EyeTV DTT
- 0fd9:0021
* - Elgato EyeTV DTT rev. 2
- 0fd9:003f
* - Elgato EyeTV Diversity
- 0fd9:0011
* - Elgato EyeTV Dtt Dlx PD378S
- 0fd9:0020
* - EvolutePC TVWay+
- 1e59:0002
* - Gigabyte U7000
- 1044:7001
* - Gigabyte U8000-RH
- 1044:7002
* - Hama DVB=T Hybrid USB Stick
- 147f:2758
* - Hauppauge ATSC MiniCard (B200)
- 2040:b200
* - Hauppauge ATSC MiniCard (B210)
- 2040:b210
* - Hauppauge Nova-T 500 Dual DVB-T
- 2040:9941, 2040:9950
* - Hauppauge Nova-T MyTV.t
- 2040:7080
* - Hauppauge Nova-T Stick
- 2040:7050, 2040:7060, 2040:7070
* - Hauppauge Nova-TD Stick (52009)
- 2040:5200
* - Hauppauge Nova-TD Stick/Elgato Eye-TV Diversity
- 2040:9580
* - Hauppauge Nova-TD-500 (84xxx)
- 2040:8400
* - Leadtek WinFast DTV Dongle H
- 0413:60f6
* - Leadtek Winfast DTV Dongle (STK7700P based)
- 0413:6f00, 0413:6f01
* - Medion CTX1921 DVB-T USB
- 1660:1921
* - Microsoft Xbox One Digital TV Tuner
- 045e:02d5
* - PCTV 2002e
- 2013:025c
* - PCTV 2002e SE
- 2013:025d
* - Pinnacle Expresscard 320cx
- 2304:022e
* - Pinnacle PCTV 2000e
- 2304:022c
* - Pinnacle PCTV 282e
- 2013:0248, 2304:0248
* - Pinnacle PCTV 340e HD Pro USB Stick
- 2304:023d
* - Pinnacle PCTV 72e
- 2304:0236
* - Pinnacle PCTV 73A
- 2304:0243
* - Pinnacle PCTV 73e
- 2304:0237
* - Pinnacle PCTV 73e SE
- 2013:0245, 2304:0245
* - Pinnacle PCTV DVB-T Flash Stick
- 2304:0228
* - Pinnacle PCTV Dual DVB-T Diversity Stick
- 2304:0229
* - Pinnacle PCTV HD Pro USB Stick
- 2304:023a
* - Pinnacle PCTV HD USB Stick
- 2304:023b
* - Pinnacle PCTV Hybrid Stick Solo
- 2304:023e
* - Prolink Pixelview SBTVD
- 1554:5010
* - Sony PlayTV
- 1415:0003
* - TechniSat AirStar TeleStick 2
- 14f7:0004
* - Terratec Cinergy DT USB XS Diversity/ T5
- 0ccd:0081, 0ccd:10a1
* - Terratec Cinergy DT XS Diversity
- 0ccd:005a
* - Terratec Cinergy HT Express
- 0ccd:0060
* - Terratec Cinergy HT USB XE
- 0ccd:0058
* - Terratec Cinergy T Express
- 0ccd:0062
* - Terratec Cinergy T USB XXS (HD)/ T3
- 0ccd:0078, 0ccd:10a0, 0ccd:00ab
* - Uniwill STK7700P based (Hama and others)
- 1584:6003
* - YUAN High-Tech DiBcom STK7700D
- 1164:1e8c
* - YUAN High-Tech MC770
- 1164:0871
* - YUAN High-Tech STK7700D
- 1164:1efc
* - YUAN High-Tech STK7700PH
- 1164:1f08
* - Yuan EC372S
- 1164:1edc
* - Yuan PD378S
- 1164:2edc

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