ALSA/ASoC/SOF/SoundWire: fix Kconfig issues
In January, Intel kbuild bot and Arnd Bergmann reported multiple issues with randconfig. This patchset builds on Arnd's suggestions to a) expose ACPI and PCI devices in separate modules, while sof-acpi-dev and sof-pci-dev become helpers. This will result in minor changes required for developers/testers, i.e. modprobe snd-sof-pci will no longer result in a probe. The SOF CI was already updated to deal with this module dependency change and introduction of new modules. b) Fix SOF/SoundWire/DSP_config dependencies by moving the code required to detect SoundWire presence in ACPI tables to sound/hda. Link: https://lore.kernel.org/r/20210302003125.1178419-1-pierre-louis.bossart@linux.intel.com -----BEGIN PGP SIGNATURE----- iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmA+Tc4OHHRpd2FpQHN1 c2UuZGUACgkQLtJE4w1nLE9r6w/9E/pkuOIX9qTTeuVhOk2uoODQeSd9JSNXMvoN rm9oamjBrugBl/x0V5UAFVLO3AXGfDJTGJT71dF51RbODyj0ISim+Ve7/2ObggN6 LRGoiAL850KGYhaAsLxTm/7OI2gH/WYwMerRdrvrJRDXAFHW5U2zLpHuj9TaZSDE LgpwJvQbSBNbMu72xix2/KuWUnh7UVVhT9guvi+wLJkC4F81FHO5btu5rWo/BGfW ekWVKw4raLMfjx2Y1P3X5/veCTgPTMOQC2Z5nuB6o9btXPTRf3tTigJcnt2xlpVk d0FtoFyn0blJ1rC3bkzAjTh3wiaLvSoz9Z8MPRoLECqk70Dtg6l1IQHmK7JCol0B EHNcW4WKAbUpRfohBw2xahZU4KJddPsdWUwSWCcY3a6rwa6MGJ2Vc1Foy3uZ0kW5 uIvwuxtuZDDazLTSr2wXeD+lF3Y6fKU4DPbpEbcYrTV+K9F6jUiArAXRQ98CrxUe MtiC2L5ll24XhxL4m5XO0DLBa0Rx+qlJ7ZoGq4iG6ekRZwC+Q6UEvjnIa5ZnnPBC veV+0Z243/y0TBy+VoVOS1XxR3xjEYYErGms6A/WBSMEZAX7AhGmre4iusgNNSyU bCIcIyjIuCLLAilwfS0siG87KYYFpEHOz+XFliM6qWDr+6cIbXmNrQhlsAVLoQ8G BcBiIiA= =ttBB -----END PGP SIGNATURE----- Merge tag 'tags/sound-sdw-kconfig-fixes' into for-linus ALSA/ASoC/SOF/SoundWire: fix Kconfig issues In January, Intel kbuild bot and Arnd Bergmann reported multiple issues with randconfig. This patchset builds on Arnd's suggestions to a) expose ACPI and PCI devices in separate modules, while sof-acpi-dev and sof-pci-dev become helpers. This will result in minor changes required for developers/testers, i.e. modprobe snd-sof-pci will no longer result in a probe. The SOF CI was already updated to deal with this module dependency change and introduction of new modules. b) Fix SOF/SoundWire/DSP_config dependencies by moving the code required to detect SoundWire presence in ACPI tables to sound/hda. Link: https://lore.kernel.org/r/20210302003125.1178419-1-pierre-louis.bossart@linux.intel.com
This commit is contained in:
commit
9b838a3c32
|
@ -109,6 +109,7 @@ ForEachMacros:
|
|||
- 'css_for_each_child'
|
||||
- 'css_for_each_descendant_post'
|
||||
- 'css_for_each_descendant_pre'
|
||||
- 'cxl_for_each_cmd'
|
||||
- 'device_for_each_child_node'
|
||||
- 'dma_fence_chain_for_each'
|
||||
- 'do_for_each_ftrace_op'
|
||||
|
|
|
@ -18,6 +18,7 @@
|
|||
*.c.[012]*.*
|
||||
*.dt.yaml
|
||||
*.dtb
|
||||
*.dtbo
|
||||
*.dtb.S
|
||||
*.dwo
|
||||
*.elf
|
||||
|
@ -41,6 +42,7 @@
|
|||
*.so.dbg
|
||||
*.su
|
||||
*.symtypes
|
||||
*.symversions
|
||||
*.tab.[ch]
|
||||
*.tar
|
||||
*.xz
|
||||
|
|
2
.mailmap
2
.mailmap
|
@ -174,7 +174,6 @@ Juha Yrjola <at solidboot.com>
|
|||
Juha Yrjola <juha.yrjola@nokia.com>
|
||||
Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
Julien Thierry <julien.thierry.kdev@gmail.com> <julien.thierry@arm.com>
|
||||
Kamil Konieczny <k.konieczny@samsung.com> <k.konieczny@partner.samsung.com>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kees Cook <keescook@chromium.org> <kees.cook@canonical.com>
|
||||
Kees Cook <keescook@chromium.org> <keescook@google.com>
|
||||
|
@ -238,6 +237,7 @@ Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
|
|||
Mayuresh Janorkar <mayur@ti.com>
|
||||
Michael Buesch <m@bues.ch>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
Miguel Ojeda <ojeda@kernel.org> <miguel.ojeda.sandonis@gmail.com>
|
||||
Mike Rapoport <rppt@kernel.org> <mike@compulab.co.il>
|
||||
Mike Rapoport <rppt@kernel.org> <mike.rapoport@gmail.com>
|
||||
Mike Rapoport <rppt@kernel.org> <rppt@linux.ibm.com>
|
||||
|
|
17
CREDITS
17
CREDITS
|
@ -1244,10 +1244,10 @@ S: 80050-430 - Curitiba - Paraná
|
|||
S: Brazil
|
||||
|
||||
N: Oded Gabbay
|
||||
E: oded.gabbay@gmail.com
|
||||
D: HabanaLabs and AMD KFD maintainer
|
||||
S: 12 Shraga Raphaeli
|
||||
S: Petah-Tikva, 4906418
|
||||
E: ogabbay@kernel.org
|
||||
D: HabanaLabs maintainer
|
||||
S: 29 Duchifat St.
|
||||
S: Ra'anana 4372029
|
||||
S: Israel
|
||||
|
||||
N: Kumar Gala
|
||||
|
@ -2841,14 +2841,11 @@ S: Subiaco, 6008
|
|||
S: Perth, Western Australia
|
||||
S: Australia
|
||||
|
||||
N: Miguel Ojeda Sandonis
|
||||
E: miguel.ojeda.sandonis@gmail.com
|
||||
W: http://miguelojeda.es
|
||||
W: http://jair.lab.fi.uva.es/~migojed/
|
||||
N: Miguel Ojeda
|
||||
E: ojeda@kernel.org
|
||||
W: https://ojeda.dev
|
||||
D: Author of the ks0108, cfag12864b and cfag12864bfb auxiliary display drivers.
|
||||
D: Maintainer of the auxiliary display drivers tree (drivers/auxdisplay/*)
|
||||
S: C/ Mieses 20, 9-B
|
||||
S: Valladolid 47009
|
||||
S: Spain
|
||||
|
||||
N: Peter Oruba
|
||||
|
|
|
@ -0,0 +1,19 @@
|
|||
What: /sys/bus/fsl-mc/rescan
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Ioana Ciornei <ioana.ciornei@nxp.com>
|
||||
Description: Writing a non-zero value to this attribute will
|
||||
force a rescan of fsl-mc bus in the system and
|
||||
synchronize the objects under fsl-mc bus and the
|
||||
Management Complex firmware.
|
||||
Users: Userspace drivers and management tools
|
||||
|
||||
What: /sys/bus/fsl-mc/autorescan
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Ioana Ciornei <ioana.ciornei@nxp.com>
|
||||
Description: Writing a zero value to this attribute will
|
||||
disable the DPRC IRQs on which automatic rescan
|
||||
of the fsl-mc bus is performed. A non-zero value
|
||||
will enable the DPRC IRQs.
|
||||
Users: Userspace drivers and management tools
|
|
@ -194,3 +194,17 @@ Description: The "tpm_version_major" property shows the TCG spec major version
|
|||
Example output::
|
||||
|
||||
2
|
||||
|
||||
What: /sys/class/tpm/tpmX/pcr-H/N
|
||||
Date: March 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: produces output in compact hex representation for PCR
|
||||
number N from hash bank H. N is the numeric value of
|
||||
the PCR number and H is the crypto string
|
||||
representation of the hash
|
||||
|
||||
Example output::
|
||||
|
||||
cat /sys/class/tpm/tpm0/pcr-sha256/7
|
||||
2ED93F199692DC6788EFA6A1FE74514AB9760B2A6CEEAEF6C808C13E4ABB0D42
|
||||
|
|
|
@ -273,7 +273,7 @@ Description: In `/sys/accessibility/speakup` is a directory corresponding to
|
|||
Below is a description of values and parameters for soft
|
||||
synthesizer, which is currently the most commonly used.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/caps_start
|
||||
What: /sys/accessibility/speakup/<synth-name>/caps_start
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This is the string that is sent to the synthesizer to cause it
|
||||
|
@ -281,7 +281,7 @@ Description: This is the string that is sent to the synthesizer to cause it
|
|||
and most others, this causes the pitch of the voice to rise
|
||||
above the currently set pitch.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/caps_stop
|
||||
What: /sys/accessibility/speakup/<synth-name>/caps_stop
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This is the string sent to the synthesizer to cause it to stop
|
||||
|
@ -290,12 +290,12 @@ Description: This is the string sent to the synthesizer to cause it to stop
|
|||
down to the
|
||||
currently set pitch.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/delay_time
|
||||
What: /sys/accessibility/speakup/<synth-name>/delay_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/soft/direct
|
||||
What: /sys/accessibility/speakup/<synth-name>/direct
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Controls if punctuation is spoken by speakup, or by the
|
||||
|
@ -306,36 +306,43 @@ Description: Controls if punctuation is spoken by speakup, or by the
|
|||
than". Zero lets speakup speak the punctuation. One lets the
|
||||
synthesizer itself speak punctuation.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/freq
|
||||
What: /sys/accessibility/speakup/<synth-name>/freq
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the frequency of the speech synthesizer. Range is
|
||||
0-9.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/full_time
|
||||
What: /sys/accessibility/speakup/<synth-name>/flush_time
|
||||
KernelVersion: 5.12
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the timeout to wait for the synthesizer flush to
|
||||
complete. This can be used when the cable gets faulty and flush
|
||||
notifications are getting lost.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/full_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/soft/jiffy_delta
|
||||
What: /sys/accessibility/speakup/<synth-name>/jiffy_delta
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This controls how many jiffys the kernel gives to the
|
||||
synthesizer. Setting this too high can make a system unstable,
|
||||
or even crash it.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/pitch
|
||||
What: /sys/accessibility/speakup/<synth-name>/pitch
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the pitch of the synthesizer. The range is 0-9.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/inflection
|
||||
What: /sys/accessibility/speakup/<synth-name>/inflection
|
||||
KernelVersion: 5.8
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the inflection of the synthesizer, i.e. the pitch
|
||||
range. The range is 0-9.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/punct
|
||||
What: /sys/accessibility/speakup/<synth-name>/punct
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the amount of punctuation spoken by the
|
||||
|
@ -343,13 +350,13 @@ Description: Gets or sets the amount of punctuation spoken by the
|
|||
TODO: How is this related to speakup's punc_level, or
|
||||
reading_punc.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/rate
|
||||
What: /sys/accessibility/speakup/<synth-name>/rate
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the rate of the synthesizer. Range is from zero
|
||||
slowest, to nine fastest.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/tone
|
||||
What: /sys/accessibility/speakup/<synth-name>/tone
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the tone of the speech synthesizer. The range for
|
||||
|
@ -357,12 +364,12 @@ Description: Gets or sets the tone of the speech synthesizer. The range for
|
|||
difference if using espeak and the espeakup connector.
|
||||
TODO: does espeakup support different tonalities?
|
||||
|
||||
What: /sys/accessibility/speakup/soft/trigger_time
|
||||
What: /sys/accessibility/speakup/<synth-name>/trigger_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/soft/voice
|
||||
What: /sys/accessibility/speakup/<synth-name>/voice
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the voice used by the synthesizer if the
|
||||
|
@ -371,7 +378,7 @@ Description: Gets or sets the voice used by the synthesizer if the
|
|||
voices, this parameter will not set the voice when the espeakup
|
||||
connector is used between speakup and espeak.
|
||||
|
||||
What: /sys/accessibility/speakup/soft/vol
|
||||
What: /sys/accessibility/speakup/<synth-name>/vol
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the volume of the speech synthesizer. Range is 0-9,
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/addr
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the device address to be used for read or write through
|
||||
PCI bar, or the device VA of a host mapped memory to be read or
|
||||
written directly from the host. The latter option is allowed
|
||||
|
@ -11,7 +11,7 @@ Description: Sets the device address to be used for read or write through
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate
|
||||
Date: May 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
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
|
||||
|
@ -34,28 +34,28 @@ Description: Allow the root user to disable/enable in runtime the clock
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays a list with information about the currently allocated
|
||||
command buffers
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/command_submission
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays a list with information about the currently active
|
||||
command submissions
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/command_submission_jobs
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays a list with detailed information about each JOB (CB) of
|
||||
each active command submission
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/data32
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the root user to read or write directly through the
|
||||
device's PCI bar. Writing to this file generates a write
|
||||
transaction while reading from the file generates a read
|
||||
|
@ -70,7 +70,7 @@ Description: Allows the root user to read or write directly through the
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/data64
|
||||
Date: Jan 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the root user to read or write 64 bit data directly
|
||||
through the device's PCI bar. Writing to this file generates a
|
||||
write transaction while reading from the file generates a read
|
||||
|
@ -85,7 +85,7 @@ Description: Allows the root user to read or write 64 bit data directly
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/device
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Enables the root user to set the device to specific state.
|
||||
Valid values are "disable", "enable", "suspend", "resume".
|
||||
User can read this property to see the valid values
|
||||
|
@ -93,28 +93,28 @@ Description: Enables the root user to set the device to specific state.
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/engines
|
||||
Date: Jul 2019
|
||||
KernelVersion: 5.3
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the status registers values of the device engines and
|
||||
their derived idle status
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_addr
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets I2C device address for I2C transaction that is generated
|
||||
by the device's CPU
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets I2C bus address for I2C transaction that is generated by
|
||||
the device's CPU
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Triggers an I2C transaction that is generated by the device's
|
||||
CPU. Writing to this file generates a write transaction while
|
||||
reading from the file generates a read transcation
|
||||
|
@ -122,32 +122,32 @@ Description: Triggers an I2C transaction that is generated by the device's
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets I2C register id for I2C transaction that is generated by
|
||||
the device's CPU
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/led0
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the state of the first S/W led on the device
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/led1
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the state of the second S/W led on the device
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/led2
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the state of the third S/W led on the device
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/mmu
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the hop values and physical address for a given ASID
|
||||
and virtual address. The user should write the ASID and VA into
|
||||
the file and then read the file to get the result.
|
||||
|
@ -157,14 +157,14 @@ Description: Displays the hop values and physical address for a given ASID
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/set_power_state
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the PCI power state. Valid values are "1" for D0 and "2"
|
||||
for D3Hot
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/userptr
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays a list with information about the currently user
|
||||
pointers (user virtual addresses) that are pinned and mapped
|
||||
to DMA addresses
|
||||
|
@ -172,13 +172,21 @@ Description: Displays a list with information about the currently user
|
|||
What: /sys/kernel/debug/habanalabs/hl<n>/vm
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
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
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the stop-on_error option for the device engines. Value of
|
||||
"0" is for disable, otherwise enable.
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/dump_security_violations
|
||||
Date: Jan 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Dumps all security violations to dmesg. This will also ack
|
||||
all security violations meanings those violations will not be
|
||||
dumped next time user calls this API
|
||||
|
|
|
@ -29,10 +29,10 @@ Description:
|
|||
option: [[appraise_type=]] [template=] [permit_directio]
|
||||
[appraise_flag=] [keyrings=]
|
||||
base:
|
||||
func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK]MODULE_CHECK]
|
||||
func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
|
||||
[FIRMWARE_CHECK]
|
||||
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
|
||||
[KEXEC_CMDLINE] [KEY_CHECK]
|
||||
[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
|
||||
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
|
||||
[[^]MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
|
@ -52,6 +52,9 @@ Description:
|
|||
template:= name of a defined IMA template type
|
||||
(eg, ima-ng). Only valid when action is "measure".
|
||||
pcr:= decimal value
|
||||
label:= [selinux]|[kernel_info]|[data_label]
|
||||
data_label:= a unique string used for grouping and limiting critical data.
|
||||
For example, "selinux" to measure critical data for SELinux.
|
||||
|
||||
default policy:
|
||||
# PROC_SUPER_MAGIC
|
||||
|
|
|
@ -371,6 +371,14 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|||
Description: (Read) Print the content of the Device ID Register
|
||||
(0xFC8). The value is taken directly from the HW.
|
||||
|
||||
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevarch
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
Description: (Read) Print the content of the Device Architecture Register
|
||||
(offset 0xFBC). The value is taken directly read
|
||||
from the HW.
|
||||
|
||||
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevtype
|
||||
Date: April 2015
|
||||
KernelVersion: 4.01
|
||||
|
|
|
@ -0,0 +1,26 @@
|
|||
What: /sys/bus/cxl/devices/memX/firmware_version
|
||||
Date: December, 2020
|
||||
KernelVersion: v5.12
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) "FW Revision" string as reported by the Identify
|
||||
Memory Device Output Payload in the CXL-2.0
|
||||
specification.
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/ram/size
|
||||
Date: December, 2020
|
||||
KernelVersion: v5.12
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) "Volatile Only Capacity" as bytes. Represents the
|
||||
identically named field in the Identify Memory Device Output
|
||||
Payload in the CXL-2.0 specification.
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/pmem/size
|
||||
Date: December, 2020
|
||||
KernelVersion: v5.12
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) "Persistent Only Capacity" as bytes. Represents the
|
||||
identically named field in the Identify Memory Device Output
|
||||
Payload in the CXL-2.0 specification.
|
|
@ -0,0 +1,25 @@
|
|||
What: /sys/bus/dfl/devices/dfl_dev.X/infX_cal_fail
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Xu Yilun <yilun.xu@intel.com>
|
||||
Description: Read-only. It indicates if the calibration failed on this
|
||||
memory interface. "1" for calibration failure, "0" for OK.
|
||||
Format: %u
|
||||
|
||||
What: /sys/bus/dfl/devices/dfl_dev.X/infX_init_done
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Xu Yilun <yilun.xu@intel.com>
|
||||
Description: Read-only. It indicates if the initialization completed on
|
||||
this memory interface. "1" for initialization complete, "0"
|
||||
for not yet.
|
||||
Format: %u
|
||||
|
||||
What: /sys/bus/dfl/devices/dfl_dev.X/infX_clear
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Xu Yilun <yilun.xu@intel.com>
|
||||
Description: Write-only. Writing "1" to this file will zero out all memory
|
||||
data in this memory interface. Writing of other values is
|
||||
invalid.
|
||||
Format: %u
|
|
@ -0,0 +1,47 @@
|
|||
What: /sys/bus/dfl/devices/dfl_dev.X/fec_mode
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Xu Yilun <yilun.xu@intel.com>
|
||||
Description: Read-only. Returns the FEC mode of the 25G links of the
|
||||
ethernet retimers configured by Nios firmware. "rs" for Reed
|
||||
Solomon FEC, "kr" for Fire Code FEC, "no" for NO FEC.
|
||||
"not supported" if the FEC mode setting is not supported, this
|
||||
happens when the Nios firmware version major < 3, or no link is
|
||||
configured to 25G.
|
||||
Format: string
|
||||
|
||||
What: /sys/bus/dfl/devices/dfl_dev.X/retimer_A_mode
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Xu Yilun <yilun.xu@intel.com>
|
||||
Description: Read-only. Returns the enumeration value of the working mode of
|
||||
the retimer A configured by the Nios firmware. The value is
|
||||
read out from shared registers filled by the Nios firmware. Now
|
||||
the values could be:
|
||||
|
||||
- "0": Reset
|
||||
- "1": 4x10G
|
||||
- "2": 4x25G
|
||||
- "3": 2x25G
|
||||
- "4": 2x25G+2x10G
|
||||
- "5": 1x25G
|
||||
|
||||
If the Nios firmware is updated in future to support more
|
||||
retimer modes, more enumeration value is expected.
|
||||
Format: 0x%x
|
||||
|
||||
What: /sys/bus/dfl/devices/dfl_dev.X/retimer_B_mode
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Xu Yilun <yilun.xu@intel.com>
|
||||
Description: Read-only. Returns the enumeration value of the working mode of
|
||||
the retimer B configured by the Nios firmware. The value format
|
||||
is the same as retimer_A_mode.
|
||||
|
||||
What: /sys/bus/dfl/devices/dfl_dev.X/nios_fw_version
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Xu Yilun <yilun.xu@intel.com>
|
||||
Description: Read-only. Returns the version of the Nios firmware in the
|
||||
FPGA. Its format is "major.minor.patch".
|
||||
Format: %x.%x.%x
|
|
@ -0,0 +1,24 @@
|
|||
What: /sys/devices/pci0000:00/*/QEMU0001:00/capability
|
||||
Date: Jan 2021
|
||||
Contact: zhenwei pi <pizhenwei@bytedance.com>
|
||||
Description:
|
||||
Read-only attribute. Capabilities of pvpanic device which
|
||||
are supported by QEMU.
|
||||
|
||||
Format: %x.
|
||||
|
||||
Detailed bit definition refers to section <Bit Definition>
|
||||
from pvpanic device specification:
|
||||
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
|
||||
|
||||
What: /sys/devices/pci0000:00/*/QEMU0001:00/events
|
||||
Date: Jan 2021
|
||||
Contact: zhenwei pi <pizhenwei@bytedance.com>
|
||||
Description:
|
||||
RW attribute. Set/get which features in-use. This attribute
|
||||
is used to enable/disable feature(s) of pvpanic device.
|
||||
Notice that this value should be a subset of capability.
|
||||
|
||||
Format: %x.
|
||||
|
||||
Also refer to pvpanic device specification.
|
|
@ -0,0 +1,82 @@
|
|||
What: /sys/class/power_supply/ltc4162-l/charge_status
|
||||
Date: Januari 2021
|
||||
KernelVersion: 5.11
|
||||
Description:
|
||||
Detailed charge status information as reported by the chip.
|
||||
|
||||
Access: Read
|
||||
|
||||
Valid values:
|
||||
ilim_reg_active
|
||||
thermal_reg_active
|
||||
vin_uvcl_active
|
||||
iin_limit_active
|
||||
constant_current
|
||||
constant_voltage
|
||||
charger_off
|
||||
|
||||
What: /sys/class/power_supply/ltc4162-l/ibat
|
||||
Date: Januari 2021
|
||||
KernelVersion: 5.11
|
||||
Description:
|
||||
Battery input current as measured by the charger. Negative value
|
||||
means that the battery is discharging.
|
||||
|
||||
Access: Read
|
||||
|
||||
Valid values: Signed value in microamps
|
||||
|
||||
What: /sys/class/power_supply/ltc4162-l/vbat
|
||||
Date: Januari 2021
|
||||
KernelVersion: 5.11
|
||||
Description:
|
||||
Battery voltage as measured by the charger.
|
||||
|
||||
Access: Read
|
||||
|
||||
Valid values: In microvolts
|
||||
|
||||
What: /sys/class/power_supply/ltc4162-l/vbat_avg
|
||||
Date: Januari 2021
|
||||
KernelVersion: 5.11
|
||||
Description:
|
||||
Battery voltage, averaged over time, as measured by the charger.
|
||||
|
||||
Access: Read
|
||||
|
||||
Valid values: In microvolts
|
||||
|
||||
What: /sys/class/power_supply/ltc4162-l/force_telemetry
|
||||
Date: Januari 2021
|
||||
KernelVersion: 5.11
|
||||
Description:
|
||||
To save battery current, the measurement system is disabled if
|
||||
the battery is the only source of power. This affects all
|
||||
voltage, current and temperature measurements.
|
||||
Write a "1" to this to keep performing telemetry once every few
|
||||
seconds, even when running on battery (as reported by the online
|
||||
property, which is "1" when external power is available and "0"
|
||||
when the system runs on battery).
|
||||
|
||||
Access: Read, Write
|
||||
|
||||
Valid values: 0 (disabled) or 1 (enabled)
|
||||
|
||||
What: /sys/class/power_supply/ltc4162-l/arm_ship_mode
|
||||
Date: Januari 2021
|
||||
KernelVersion: 5.11
|
||||
Description:
|
||||
The charger will normally drain the battery while inactive,
|
||||
typically drawing about 54 microamps. Write a "1" to this
|
||||
property to arm a special "ship" mode that extends shelf life
|
||||
by reducing the leakage to about 2.8 microamps. The chip will
|
||||
remain in this mode (and no longer respond to I2C commands)
|
||||
until some external power-supply is attached raising the input
|
||||
voltage above 1V. It will then automatically revert to "0".
|
||||
Writing a "0" to the property cancels the "ship" mode request.
|
||||
The ship mode, when armed, activates once the input voltage
|
||||
drops below 1V.
|
||||
|
||||
Access: Read, Write
|
||||
|
||||
Valid values: 0 (disable) or 1 (enable)
|
|
@ -13,21 +13,22 @@ What: /sys/devices/system/memory/memoryX/removable
|
|||
Date: June 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/removable
|
||||
indicates whether this memory block is removable or not.
|
||||
This is useful for a user-level agent to determine
|
||||
identify removable sections of the memory before attempting
|
||||
potentially expensive hot-remove memory operation
|
||||
The file /sys/devices/system/memory/memoryX/removable is a
|
||||
legacy interface used to indicated whether a memory block is
|
||||
likely to be offlineable or not. Newer kernel versions return
|
||||
"1" if and only if the kernel supports memory offlining.
|
||||
Users: hotplug memory remove tools
|
||||
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
|
||||
lsmem/chmem part of util-linux
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_device
|
||||
Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/phys_device
|
||||
is read-only and is designed to show the name of physical
|
||||
memory device. Implementation is currently incomplete.
|
||||
is read-only; it is a legacy interface only ever used on s390x
|
||||
to expose the covered storage increment.
|
||||
Users: Legacy s390-tools lsmem/chmem
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_index
|
||||
Date: September 2008
|
||||
|
@ -43,23 +44,25 @@ Date: September 2008
|
|||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/state
|
||||
is read-write. When read, its contents show the
|
||||
online/offline state of the memory section. When written,
|
||||
root can toggle the the online/offline state of a removable
|
||||
memory section (see removable file description above)
|
||||
using the following commands::
|
||||
is read-write. When read, it returns the online/offline
|
||||
state of the memory block. When written, root can toggle
|
||||
the online/offline state of a memory block using the following
|
||||
commands::
|
||||
|
||||
# echo online > /sys/devices/system/memory/memoryX/state
|
||||
# echo offline > /sys/devices/system/memory/memoryX/state
|
||||
|
||||
For example, if /sys/devices/system/memory/memory22/removable
|
||||
contains a value of 1 and
|
||||
/sys/devices/system/memory/memory22/state contains the
|
||||
string "online" the following command can be executed by
|
||||
by root to offline that section::
|
||||
|
||||
# echo offline > /sys/devices/system/memory/memory22/state
|
||||
On newer kernel versions, advanced states can be specified
|
||||
when onlining to select a target zone: "online_movable"
|
||||
selects the movable zone. "online_kernel" selects the
|
||||
applicable kernel zone (DMA, DMA32, or Normal). However,
|
||||
after successfully setting one of the advanced states,
|
||||
reading the file will return "online"; the zone information
|
||||
can be obtained via "valid_zones" instead.
|
||||
|
||||
While onlining is unlikely to fail, there are no guarantees
|
||||
that offlining will succeed. Offlining is more likely to
|
||||
succeed if "valid_zones" indicates "Movable".
|
||||
Users: hotplug memory remove tools
|
||||
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
|
||||
|
||||
|
@ -69,8 +72,19 @@ Date: July 2014
|
|||
Contact: Zhang Zhen <zhenzhang.zhang@huawei.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/valid_zones is
|
||||
read-only and is designed to show which zone this memory
|
||||
block can be onlined to.
|
||||
read-only.
|
||||
|
||||
For online memory blocks, it returns in which zone memory
|
||||
provided by a memory block is managed. If multiple zones
|
||||
apply (not applicable for hotplugged memory), "None" is returned
|
||||
and the memory block cannot be offlined.
|
||||
|
||||
For offline memory blocks, it returns by which zone memory
|
||||
provided by a memory block can be managed when onlining.
|
||||
The first returned zone ("default") will be used when setting
|
||||
the state of an offline memory block to "online". Only one of
|
||||
the kernel zones (DMA, DMA32, Normal) is applicable for a single
|
||||
memory block.
|
||||
|
||||
What: /sys/devices/system/memoryX/nodeY
|
||||
Date: October 2009
|
||||
|
|
|
@ -0,0 +1,41 @@
|
|||
What: /sys/devices/*/xenbus/event_channels
|
||||
Date: February 2021
|
||||
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
|
||||
Description:
|
||||
Number of Xen event channels associated with a kernel based
|
||||
paravirtualized device frontend or backend.
|
||||
|
||||
What: /sys/devices/*/xenbus/events
|
||||
Date: February 2021
|
||||
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
|
||||
Description:
|
||||
Total number of Xen events received for a Xen pv device
|
||||
frontend or backend.
|
||||
|
||||
What: /sys/devices/*/xenbus/jiffies_eoi_delayed
|
||||
Date: February 2021
|
||||
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
|
||||
Description:
|
||||
Summed up time in jiffies the EOI of an interrupt for a Xen
|
||||
pv device has been delayed in order to avoid stalls due to
|
||||
event storms. This value rising is a first sign for a rogue
|
||||
other end of the pv device.
|
||||
|
||||
What: /sys/devices/*/xenbus/spurious_events
|
||||
Date: February 2021
|
||||
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
|
||||
Description:
|
||||
Number of events received for a Xen pv device which did not
|
||||
require any action. Too many spurious events in a row will
|
||||
trigger delayed EOI processing.
|
||||
|
||||
What: /sys/devices/*/xenbus/spurious_threshold
|
||||
Date: February 2021
|
||||
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
|
||||
Description:
|
||||
Controls the tolerated number of subsequent spurious events
|
||||
before delayed EOI processing is triggered for a Xen pv
|
||||
device. Default is 1. This can be modified in case the other
|
||||
end of the pv device is issuing spurious events on a regular
|
||||
basis and is known not to be malicious on purpose. Raising
|
||||
the value for such cases can improve pv device performance.
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/class/habanalabs/hl<n>/armcp_kernel_ver
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the Linux kernel running on the device's CPU.
|
||||
Will be DEPRECATED in Linux kernel version 5.10, and be
|
||||
replaced with cpucp_kernel_ver
|
||||
|
@ -9,7 +9,7 @@ Description: Version of the Linux kernel running on the device's CPU.
|
|||
What: /sys/class/habanalabs/hl<n>/armcp_ver
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the application running on the device's CPU
|
||||
Will be DEPRECATED in Linux kernel version 5.10, and be
|
||||
replaced with cpucp_ver
|
||||
|
@ -17,7 +17,7 @@ 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
|
||||
Contact: ogabbay@kernel.org
|
||||
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
|
||||
|
@ -27,52 +27,52 @@ Description: Allows the user to set the maximum clock frequency, in MHz.
|
|||
What: /sys/class/habanalabs/hl<n>/clk_cur_freq_mhz
|
||||
Date: Jun 2019
|
||||
KernelVersion: not yet upstreamed
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
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
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the Device's CPLD F/W
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/cpucp_kernel_ver
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.10
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the Linux kernel running on the device's CPU
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/cpucp_ver
|
||||
Date: Oct 2020
|
||||
KernelVersion: 5.10
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the application running on the device's CPU
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/device_type
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the code name of the device according to its type.
|
||||
The supported values are: "GOYA"
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/eeprom
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: A binary file attribute that contains the contents of the
|
||||
on-board EEPROM
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/fuse_ver
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the device's version from the eFuse
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/hard_reset
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Interface to trigger a hard-reset operation for the device.
|
||||
Hard-reset will reset ALL internal components of the device
|
||||
except for the PCI interface and the internal PLLs
|
||||
|
@ -80,14 +80,14 @@ Description: Interface to trigger a hard-reset operation for the device.
|
|||
What: /sys/class/habanalabs/hl<n>/hard_reset_cnt
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays how many times the device have undergone a hard-reset
|
||||
operation since the driver was loaded
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/high_pll
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the user to set the maximum clock frequency for MME, TPC
|
||||
and IC when the power management profile is set to "automatic".
|
||||
This property is valid only for the Goya ASIC family
|
||||
|
@ -95,7 +95,7 @@ Description: Allows the user to set the maximum clock frequency for MME, TPC
|
|||
What: /sys/class/habanalabs/hl<n>/ic_clk
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the user to set the maximum clock frequency, in Hz, of
|
||||
the Interconnect fabric. Writes to this parameter affect the
|
||||
device only when the power management profile is set to "manual"
|
||||
|
@ -107,27 +107,27 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
|
|||
What: /sys/class/habanalabs/hl<n>/ic_clk_curr
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the current clock frequency, in Hz, of the Interconnect
|
||||
fabric. This property is valid only for the Goya ASIC family
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/infineon_ver
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the Device's power supply F/W code
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/max_power
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the user to set the maximum power consumption of the
|
||||
device in milliwatts.
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/mme_clk
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the user to set the maximum clock frequency, in Hz, of
|
||||
the MME compute engine. Writes to this parameter affect the
|
||||
device only when the power management profile is set to "manual"
|
||||
|
@ -139,21 +139,21 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
|
|||
What: /sys/class/habanalabs/hl<n>/mme_clk_curr
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the current clock frequency, in Hz, of the MME compute
|
||||
engine. This property is valid only for the Goya ASIC family
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/pci_addr
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the PCI address of the device. This is needed so the
|
||||
user would be able to open a device based on its PCI address
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/pm_mng_profile
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Power management profile. Values are "auto", "manual". In "auto"
|
||||
mode, the driver will set the maximum clock frequency to a high
|
||||
value when a user-space process opens the device's file (unless
|
||||
|
@ -167,13 +167,13 @@ Description: Power management profile. Values are "auto", "manual". In "auto"
|
|||
What: /sys/class/habanalabs/hl<n>/preboot_btl_ver
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the device's preboot F/W code
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/soft_reset
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Interface to trigger a soft-reset operation for the device.
|
||||
Soft-reset will reset only the compute and DMA engines of the
|
||||
device
|
||||
|
@ -181,26 +181,26 @@ Description: Interface to trigger a soft-reset operation for the device.
|
|||
What: /sys/class/habanalabs/hl<n>/soft_reset_cnt
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays how many times the device have undergone a soft-reset
|
||||
operation since the driver was loaded
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/status
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Status of the card: "Operational", "Malfunction", "In reset".
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/thermal_ver
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the Device's thermal daemon
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/tpc_clk
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the user to set the maximum clock frequency, in Hz, of
|
||||
the TPC compute engines. Writes to this parameter affect the
|
||||
device only when the power management profile is set to "manual"
|
||||
|
@ -212,12 +212,12 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
|
|||
What: /sys/class/habanalabs/hl<n>/tpc_clk_curr
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the current clock frequency, in Hz, of the TPC compute
|
||||
engines. This property is valid only for the Goya ASIC family
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/uboot_ver
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: oded.gabbay@gmail.com
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the u-boot running on the device's CPU
|
|
@ -0,0 +1,6 @@
|
|||
What: /sys/class/input/input(x)/device/function_row_physmap
|
||||
Date: January 2021
|
||||
Contact: Philip Chen <philipchen@chromium.org>
|
||||
Description: A space separated list of scancodes for the top row keys,
|
||||
ordered by the physical positions of the keys, from left
|
||||
to right.
|
|
@ -13,3 +13,24 @@ Contact: Xu Yilun <yilun.xu@intel.com>
|
|||
Description: Read only. Returns the firmware version of Intel MAX10
|
||||
BMC chip.
|
||||
Format: "0x%x".
|
||||
|
||||
What: /sys/bus/spi/devices/.../mac_address
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns the first MAC address in a block
|
||||
of sequential MAC addresses assigned to the board
|
||||
that is managed by the Intel MAX10 BMC. It is stored in
|
||||
FLASH storage and is mirrored in the MAX10 BMC register
|
||||
space.
|
||||
Format: "%02x:%02x:%02x:%02x:%02x:%02x".
|
||||
|
||||
What: /sys/bus/spi/devices/.../mac_count
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns the number of sequential MAC
|
||||
addresses assigned to the board managed by the Intel
|
||||
MAX10 BMC. This value is stored in FLASH and is mirrored
|
||||
in the MAX10 BMC register space.
|
||||
Format: "%u".
|
||||
|
|
|
@ -1161,3 +1161,14 @@ Description: This entry shows the configured size of WriteBooster buffer.
|
|||
0400h corresponds to 4GB.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/wb_on
|
||||
Date: January 2021
|
||||
Contact: Bean Huo <beanhuo@micron.com>
|
||||
Description: This node is used to set or display whether UFS WriteBooster is
|
||||
enabled. Echo 0 to this file to disable UFS WriteBooster or 1 to
|
||||
enable it. The WriteBooster is enabled after power-on/reset,
|
||||
however, it will be disabled/enable while CLK scaling down/up
|
||||
(if the platform supports UFSHCD_CAP_CLK_SCALING). For a
|
||||
platform that doesn't support UFSHCD_CAP_CLK_SCALING, we can
|
||||
disable/enable WriteBooster through this sysfs node.
|
||||
|
|
|
@ -1,3 +1,46 @@
|
|||
What: /sys/firmware/acpi/fpdt/
|
||||
Date: Jan 2021
|
||||
Contact: Zhang Rui <rui.zhang@intel.com>
|
||||
Description:
|
||||
ACPI Firmware Performance Data Table (FPDT) provides
|
||||
information for firmware performance data for system boot,
|
||||
S3 suspend and S3 resume. This sysfs entry contains the
|
||||
performance data retrieved from the FPDT.
|
||||
|
||||
boot:
|
||||
firmware_start_ns: Timer value logged at the beginning
|
||||
of firmware image execution. In nanoseconds.
|
||||
bootloader_load_ns: Timer value logged just prior to
|
||||
loading the OS boot loader into memory.
|
||||
In nanoseconds.
|
||||
bootloader_launch_ns: Timer value logged just prior to
|
||||
launching the currently loaded OS boot loader
|
||||
image. In nanoseconds.
|
||||
exitbootservice_start_ns: Timer value logged at the
|
||||
point when the OS loader calls the
|
||||
ExitBootServices function for UEFI compatible
|
||||
firmware. In nanoseconds.
|
||||
exitbootservice_end_ns: Timer value logged at the point
|
||||
just prior to the OS loader gaining control
|
||||
back from the ExitBootServices function for
|
||||
UEFI compatible firmware. In nanoseconds.
|
||||
suspend:
|
||||
suspend_start_ns: Timer value recorded at the previous
|
||||
OS write to SLP_TYP upon entry to S3. In
|
||||
nanoseconds.
|
||||
suspend_end_ns: Timer value recorded at the previous
|
||||
firmware write to SLP_TYP used to trigger
|
||||
hardware entry to S3. In nanoseconds.
|
||||
resume:
|
||||
resume_count: A count of the number of S3 resume cycles
|
||||
since the last full boot sequence.
|
||||
resume_avg_ns: Average timer value of all resume cycles
|
||||
logged since the last full boot sequence,
|
||||
including the most recent resume. In nanoseconds.
|
||||
resume_prev_ns: Timer recorded at the end of the previous
|
||||
platform runtime firmware S3 resume, just prior to
|
||||
handoff to the OS waking vector. In nanoseconds.
|
||||
|
||||
What: /sys/firmware/acpi/bgrt/
|
||||
Date: January 2012
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
|
|
|
@ -1,15 +0,0 @@
|
|||
What: /sys/firmware/sfi/tables/
|
||||
Date: May 2010
|
||||
Contact: Len Brown <lenb@kernel.org>
|
||||
Description:
|
||||
SFI defines a number of small static memory tables
|
||||
so the kernel can get platform information from firmware.
|
||||
|
||||
The tables are defined in the latest SFI specification:
|
||||
http://simplefirmware.org/documentation
|
||||
|
||||
While the tables are used by the kernel, user-space
|
||||
can observe them this way::
|
||||
|
||||
# cd /sys/firmware/sfi/tables
|
||||
# cat $TABLENAME > $TABLENAME.bin
|
|
@ -1,11 +1,11 @@
|
|||
What: /sys/devices/platform/ideapad/camera_power
|
||||
What: /sys/bus/platform/devices/VPC2004:*/camera_power
|
||||
Date: Dec 2010
|
||||
KernelVersion: 2.6.37
|
||||
Contact: "Ike Panhc <ike.pan@canonical.com>"
|
||||
Description:
|
||||
Control the power of camera module. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/ideapad/fan_mode
|
||||
What: /sys/bus/platform/devices/VPC2004:*/fan_mode
|
||||
Date: June 2012
|
||||
KernelVersion: 3.6
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
|
@ -18,7 +18,7 @@ Description:
|
|||
* 2 -> Dust Cleaning
|
||||
* 4 -> Efficient Thermal Dissipation Mode
|
||||
|
||||
What: /sys/devices/platform/ideapad/touchpad
|
||||
What: /sys/bus/platform/devices/VPC2004:*/touchpad
|
||||
Date: May 2017
|
||||
KernelVersion: 4.13
|
||||
Contact: "Ritesh Raj Sarraf <rrs@debian.org>"
|
||||
|
@ -27,7 +27,16 @@ Description:
|
|||
* 1 -> Switched On
|
||||
* 0 -> Switched Off
|
||||
|
||||
What: /sys/bus/pci/devices/<bdf>/<device>/VPC2004:00/fn_lock
|
||||
What: /sys/bus/platform/devices/VPC2004:*/conservation_mode
|
||||
Date: Aug 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: platform-driver-x86@vger.kernel.org
|
||||
Description:
|
||||
Controls whether the conservation mode is enabled or not.
|
||||
This feature limits the maximum battery charge percentage to
|
||||
around 50-60% in order to prolong the lifetime of the battery.
|
||||
|
||||
What: /sys/bus/platform/devices/VPC2004:*/fn_lock
|
||||
Date: May 2018
|
||||
KernelVersion: 4.18
|
||||
Contact: "Oleg Keri <ezhi99@gmail.com>"
|
||||
|
@ -41,3 +50,12 @@ Description:
|
|||
|
||||
# echo "0" > \
|
||||
/sys/bus/pci/devices/0000:00:1f.0/PNP0C09:00/VPC2004:00/fn_lock
|
||||
|
||||
What: /sys/bus/platform/devices/VPC2004:*/usb_charging
|
||||
Date: Feb 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: platform-driver-x86@vger.kernel.org
|
||||
Description:
|
||||
Controls whether the "always on USB charging" feature is
|
||||
enabled or not. This feature enables charging USB devices
|
||||
even if the computer is not turned on.
|
||||
|
|
|
@ -7,7 +7,7 @@ Description:
|
|||
is connected. example: "/dev/ttyS0".
|
||||
|
||||
The device name flows down to architecture specific board
|
||||
initialization file from the SFI/ATAGS bootloader
|
||||
initialization file from the ATAGS bootloader
|
||||
firmware. The name exposed is read from the user-space
|
||||
dameon and opens the device when install is requested.
|
||||
|
||||
|
|
|
@ -5,13 +5,17 @@ Description: This file contains a space-separated list of profiles supported for
|
|||
|
||||
Drivers must use the following standard profile-names:
|
||||
|
||||
============ ============================================
|
||||
low-power Low power consumption
|
||||
cool Cooler operation
|
||||
quiet Quieter operation
|
||||
balanced Balance between low power consumption and performance
|
||||
performance High performance operation
|
||||
============ ============================================
|
||||
==================== ========================================
|
||||
low-power Low power consumption
|
||||
cool Cooler operation
|
||||
quiet Quieter operation
|
||||
balanced Balance between low power consumption
|
||||
and performance
|
||||
balanced-performance Balance between performance and low
|
||||
power consumption with a slight bias
|
||||
towards performance
|
||||
performance High performance operation
|
||||
==================== ========================================
|
||||
|
||||
Userspace may expect drivers to offer more than one of these
|
||||
standard profile names.
|
||||
|
|
|
@ -0,0 +1,38 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==========================
|
||||
PCI NTB Endpoint Function
|
||||
==========================
|
||||
|
||||
1) Create a subdirectory to pci_epf_ntb directory in configfs.
|
||||
|
||||
Standard EPF Configurable Fields:
|
||||
|
||||
================ ===========================================================
|
||||
vendorid should be 0x104c
|
||||
deviceid should be 0xb00d for TI's J721E SoC
|
||||
revid don't care
|
||||
progif_code don't care
|
||||
subclass_code should be 0x00
|
||||
baseclass_code should be 0x5
|
||||
cache_line_size don't care
|
||||
subsys_vendor_id don't care
|
||||
subsys_id don't care
|
||||
interrupt_pin don't care
|
||||
msi_interrupts don't care
|
||||
msix_interrupts don't care
|
||||
================ ===========================================================
|
||||
|
||||
2) Create a subdirectory to directory created in 1
|
||||
|
||||
NTB EPF specific configurable fields:
|
||||
|
||||
================ ===========================================================
|
||||
db_count Number of doorbells; default = 4
|
||||
mw1 size of memory window1
|
||||
mw2 size of memory window2
|
||||
mw3 size of memory window3
|
||||
mw4 size of memory window4
|
||||
num_mws Number of memory windows; max = 4
|
||||
spad_count Number of scratchpad registers; default = 64
|
||||
================ ===========================================================
|
|
@ -11,5 +11,8 @@ PCI Endpoint Framework
|
|||
pci-endpoint-cfs
|
||||
pci-test-function
|
||||
pci-test-howto
|
||||
pci-ntb-function
|
||||
pci-ntb-howto
|
||||
|
||||
function/binding/pci-test
|
||||
function/binding/pci-ntb
|
||||
|
|
|
@ -68,6 +68,16 @@ created)
|
|||
... subsys_vendor_id
|
||||
... subsys_id
|
||||
... interrupt_pin
|
||||
... primary/
|
||||
... <Symlink EPC Device1>/
|
||||
... secondary/
|
||||
... <Symlink EPC Device2>/
|
||||
|
||||
If an EPF device has to be associated with 2 EPCs (like in the case of
|
||||
Non-transparent bridge), symlink of endpoint controller connected to primary
|
||||
interface should be added in 'primary' directory and symlink of endpoint
|
||||
controller connected to secondary interface should be added in 'secondary'
|
||||
directory.
|
||||
|
||||
EPC Device
|
||||
==========
|
||||
|
|
|
@ -0,0 +1,348 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================
|
||||
PCI NTB Function
|
||||
=================
|
||||
|
||||
:Author: Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
||||
PCI Non-Transparent Bridges (NTB) allow two host systems to communicate
|
||||
with each other by exposing each host as a device to the other host.
|
||||
NTBs typically support the ability to generate interrupts on the remote
|
||||
machine, expose memory ranges as BARs, and perform DMA. They also support
|
||||
scratchpads, which are areas of memory within the NTB that are accessible
|
||||
from both machines.
|
||||
|
||||
PCI NTB Function allows two different systems (or hosts) to communicate
|
||||
with each other by configuring the endpoint instances in such a way that
|
||||
transactions from one system are routed to the other system.
|
||||
|
||||
In the below diagram, PCI NTB function configures the SoC with multiple
|
||||
PCI Endpoint (EP) instances in such a way that transactions from one EP
|
||||
controller are routed to the other EP controller. Once PCI NTB function
|
||||
configures the SoC with multiple EP instances, HOST1 and HOST2 can
|
||||
communicate with each other using SoC as a bridge.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
+-------------+ +-------------+
|
||||
| | | |
|
||||
| HOST1 | | HOST2 |
|
||||
| | | |
|
||||
+------^------+ +------^------+
|
||||
| |
|
||||
| |
|
||||
+---------|-------------------------------------------------|---------+
|
||||
| +------v------+ +------v------+ |
|
||||
| | | | | |
|
||||
| | EP | | EP | |
|
||||
| | CONTROLLER1 | | CONTROLLER2 | |
|
||||
| | <-----------------------------------> | |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
| | | SoC With Multiple EP Instances | | |
|
||||
| | | (Configured using NTB Function) | | |
|
||||
| +-------------+ +-------------+ |
|
||||
+---------------------------------------------------------------------+
|
||||
|
||||
Constructs used for Implementing NTB
|
||||
====================================
|
||||
|
||||
1) Config Region
|
||||
2) Self Scratchpad Registers
|
||||
3) Peer Scratchpad Registers
|
||||
4) Doorbell (DB) Registers
|
||||
5) Memory Window (MW)
|
||||
|
||||
|
||||
Config Region:
|
||||
--------------
|
||||
|
||||
Config Region is a construct that is specific to NTB implemented using NTB
|
||||
Endpoint Function Driver. The host and endpoint side NTB function driver will
|
||||
exchange information with each other using this region. Config Region has
|
||||
Control/Status Registers for configuring the Endpoint Controller. Host can
|
||||
write into this region for configuring the outbound Address Translation Unit
|
||||
(ATU) and to indicate the link status. Endpoint can indicate the status of
|
||||
commands issued by host in this region. Endpoint can also indicate the
|
||||
scratchpad offset and number of memory windows to the host using this region.
|
||||
|
||||
The format of Config Region is given below. All the fields here are 32 bits.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
+------------------------+
|
||||
| COMMAND |
|
||||
+------------------------+
|
||||
| ARGUMENT |
|
||||
+------------------------+
|
||||
| STATUS |
|
||||
+------------------------+
|
||||
| TOPOLOGY |
|
||||
+------------------------+
|
||||
| ADDRESS (LOWER 32) |
|
||||
+------------------------+
|
||||
| ADDRESS (UPPER 32) |
|
||||
+------------------------+
|
||||
| SIZE |
|
||||
+------------------------+
|
||||
| NO OF MEMORY WINDOW |
|
||||
+------------------------+
|
||||
| MEMORY WINDOW1 OFFSET |
|
||||
+------------------------+
|
||||
| SPAD OFFSET |
|
||||
+------------------------+
|
||||
| SPAD COUNT |
|
||||
+------------------------+
|
||||
| DB ENTRY SIZE |
|
||||
+------------------------+
|
||||
| DB DATA |
|
||||
+------------------------+
|
||||
| : |
|
||||
+------------------------+
|
||||
| : |
|
||||
+------------------------+
|
||||
| DB DATA |
|
||||
+------------------------+
|
||||
|
||||
|
||||
COMMAND:
|
||||
|
||||
NTB function supports three commands:
|
||||
|
||||
CMD_CONFIGURE_DOORBELL (0x1): Command to configure doorbell. Before
|
||||
invoking this command, the host should allocate and initialize
|
||||
MSI/MSI-X vectors (i.e., initialize the MSI/MSI-X Capability in the
|
||||
Endpoint). The endpoint on receiving this command will configure
|
||||
the outbound ATU such that transactions to Doorbell BAR will be routed
|
||||
to the MSI/MSI-X address programmed by the host. The ARGUMENT
|
||||
register should be populated with number of DBs to configure (in the
|
||||
lower 16 bits) and if MSI or MSI-X should be configured (BIT 16).
|
||||
|
||||
CMD_CONFIGURE_MW (0x2): Command to configure memory window (MW). The
|
||||
host invokes this command after allocating a buffer that can be
|
||||
accessed by remote host. The allocated address should be programmed
|
||||
in the ADDRESS register (64 bit), the size should be programmed in
|
||||
the SIZE register and the memory window index should be programmed
|
||||
in the ARGUMENT register. The endpoint on receiving this command
|
||||
will configure the outbound ATU such that transactions to MW BAR
|
||||
are routed to the address provided by the host.
|
||||
|
||||
CMD_LINK_UP (0x3): Command to indicate an NTB application is
|
||||
bound to the EP device on the host side. Once the endpoint
|
||||
receives this command from both the hosts, the endpoint will
|
||||
raise a LINK_UP event to both the hosts to indicate the host
|
||||
NTB applications can start communicating with each other.
|
||||
|
||||
ARGUMENT:
|
||||
|
||||
The value of this register is based on the commands issued in
|
||||
command register. See COMMAND section for more information.
|
||||
|
||||
TOPOLOGY:
|
||||
|
||||
Set to NTB_TOPO_B2B_USD for Primary interface
|
||||
Set to NTB_TOPO_B2B_DSD for Secondary interface
|
||||
|
||||
ADDRESS/SIZE:
|
||||
|
||||
Address and Size to be used while configuring the memory window.
|
||||
See "CMD_CONFIGURE_MW" for more info.
|
||||
|
||||
MEMORY WINDOW1 OFFSET:
|
||||
|
||||
Memory Window 1 and Doorbell registers are packed together in the
|
||||
same BAR. The initial portion of the region will have doorbell
|
||||
registers and the latter portion of the region is for memory window 1.
|
||||
This register will specify the offset of the memory window 1.
|
||||
|
||||
NO OF MEMORY WINDOW:
|
||||
|
||||
Specifies the number of memory windows supported by the NTB device.
|
||||
|
||||
SPAD OFFSET:
|
||||
|
||||
Self scratchpad region and config region are packed together in the
|
||||
same BAR. The initial portion of the region will have config region
|
||||
and the latter portion of the region is for self scratchpad. This
|
||||
register will specify the offset of the self scratchpad registers.
|
||||
|
||||
SPAD COUNT:
|
||||
|
||||
Specifies the number of scratchpad registers supported by the NTB
|
||||
device.
|
||||
|
||||
DB ENTRY SIZE:
|
||||
|
||||
Used to determine the offset within the DB BAR that should be written
|
||||
in order to raise doorbell. EPF NTB can use either MSI or MSI-X to
|
||||
ring doorbell (MSI-X support will be added later). MSI uses same
|
||||
address for all the interrupts and MSI-X can provide different
|
||||
addresses for different interrupts. The MSI/MSI-X address is provided
|
||||
by the host and the address it gives is based on the MSI/MSI-X
|
||||
implementation supported by the host. For instance, ARM platform
|
||||
using GIC ITS will have the same MSI-X address for all the interrupts.
|
||||
In order to support all the combinations and use the same mechanism
|
||||
for both MSI and MSI-X, EPF NTB allocates a separate region in the
|
||||
Outbound Address Space for each of the interrupts. This region will
|
||||
be mapped to the MSI/MSI-X address provided by the host. If a host
|
||||
provides the same address for all the interrupts, all the regions
|
||||
will be translated to the same address. If a host provides different
|
||||
addresses, the regions will be translated to different addresses. This
|
||||
will ensure there is no difference while raising the doorbell.
|
||||
|
||||
DB DATA:
|
||||
|
||||
EPF NTB supports 32 interrupts, so there are 32 DB DATA registers.
|
||||
This holds the MSI/MSI-X data that has to be written to MSI address
|
||||
for raising doorbell interrupt. This will be populated by EPF NTB
|
||||
while invoking CMD_CONFIGURE_DOORBELL.
|
||||
|
||||
Scratchpad Registers:
|
||||
---------------------
|
||||
|
||||
Each host has its own register space allocated in the memory of NTB endpoint
|
||||
controller. They are both readable and writable from both sides of the bridge.
|
||||
They are used by applications built over NTB and can be used to pass control
|
||||
and status information between both sides of a device.
|
||||
|
||||
Scratchpad registers has 2 parts
|
||||
1) Self Scratchpad: Host's own register space
|
||||
2) Peer Scratchpad: Remote host's register space.
|
||||
|
||||
Doorbell Registers:
|
||||
-------------------
|
||||
|
||||
Doorbell Registers are used by the hosts to interrupt each other.
|
||||
|
||||
Memory Window:
|
||||
--------------
|
||||
|
||||
Actual transfer of data between the two hosts will happen using the
|
||||
memory window.
|
||||
|
||||
Modeling Constructs:
|
||||
====================
|
||||
|
||||
There are 5 or more distinct regions (config, self scratchpad, peer
|
||||
scratchpad, doorbell, one or more memory windows) to be modeled to achieve
|
||||
NTB functionality. At least one memory window is required while more than
|
||||
one is permitted. All these regions should be mapped to BARs for hosts to
|
||||
access these regions.
|
||||
|
||||
If one 32-bit BAR is allocated for each of these regions, the scheme would
|
||||
look like this:
|
||||
|
||||
====== ===============
|
||||
BAR NO CONSTRUCTS USED
|
||||
====== ===============
|
||||
BAR0 Config Region
|
||||
BAR1 Self Scratchpad
|
||||
BAR2 Peer Scratchpad
|
||||
BAR3 Doorbell
|
||||
BAR4 Memory Window 1
|
||||
BAR5 Memory Window 2
|
||||
====== ===============
|
||||
|
||||
However if we allocate a separate BAR for each of the regions, there would not
|
||||
be enough BARs for all the regions in a platform that supports only 64-bit
|
||||
BARs.
|
||||
|
||||
In order to be supported by most of the platforms, the regions should be
|
||||
packed and mapped to BARs in a way that provides NTB functionality and
|
||||
also makes sure the host doesn't access any region that it is not supposed
|
||||
to.
|
||||
|
||||
The following scheme is used in EPF NTB Function:
|
||||
|
||||
====== ===============================
|
||||
BAR NO CONSTRUCTS USED
|
||||
====== ===============================
|
||||
BAR0 Config Region + Self Scratchpad
|
||||
BAR1 Peer Scratchpad
|
||||
BAR2 Doorbell + Memory Window 1
|
||||
BAR3 Memory Window 2
|
||||
BAR4 Memory Window 3
|
||||
BAR5 Memory Window 4
|
||||
====== ===============================
|
||||
|
||||
With this scheme, for the basic NTB functionality 3 BARs should be sufficient.
|
||||
|
||||
Modeling Config/Scratchpad Region:
|
||||
----------------------------------
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
+-----------------+------->+------------------+ +-----------------+
|
||||
| BAR0 | | CONFIG REGION | | BAR0 |
|
||||
+-----------------+----+ +------------------+<-------+-----------------+
|
||||
| BAR1 | | |SCRATCHPAD REGION | | BAR1 |
|
||||
+-----------------+ +-->+------------------+<-------+-----------------+
|
||||
| BAR2 | Local Memory | BAR2 |
|
||||
+-----------------+ +-----------------+
|
||||
| BAR3 | | BAR3 |
|
||||
+-----------------+ +-----------------+
|
||||
| BAR4 | | BAR4 |
|
||||
+-----------------+ +-----------------+
|
||||
| BAR5 | | BAR5 |
|
||||
+-----------------+ +-----------------+
|
||||
EP CONTROLLER 1 EP CONTROLLER 2
|
||||
|
||||
Above diagram shows Config region + Scratchpad region for HOST1 (connected to
|
||||
EP controller 1) allocated in local memory. The HOST1 can access the config
|
||||
region and scratchpad region (self scratchpad) using BAR0 of EP controller 1.
|
||||
The peer host (HOST2 connected to EP controller 2) can also access this
|
||||
scratchpad region (peer scratchpad) using BAR1 of EP controller 2. This
|
||||
diagram shows the case where Config region and Scratchpad regions are allocated
|
||||
for HOST1, however the same is applicable for HOST2.
|
||||
|
||||
Modeling Doorbell/Memory Window 1:
|
||||
----------------------------------
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
+-----------------+ +----->+----------------+-----------+-----------------+
|
||||
| BAR0 | | | Doorbell 1 +-----------> MSI-X ADDRESS 1 |
|
||||
+-----------------+ | +----------------+ +-----------------+
|
||||
| BAR1 | | | Doorbell 2 +---------+ | |
|
||||
+-----------------+----+ +----------------+ | | |
|
||||
| BAR2 | | Doorbell 3 +-------+ | +-----------------+
|
||||
+-----------------+----+ +----------------+ | +-> MSI-X ADDRESS 2 |
|
||||
| BAR3 | | | Doorbell 4 +-----+ | +-----------------+
|
||||
+-----------------+ | |----------------+ | | | |
|
||||
| BAR4 | | | | | | +-----------------+
|
||||
+-----------------+ | | MW1 +---+ | +-->+ MSI-X ADDRESS 3||
|
||||
| BAR5 | | | | | | +-----------------+
|
||||
+-----------------+ +----->-----------------+ | | | |
|
||||
EP CONTROLLER 1 | | | | +-----------------+
|
||||
| | | +---->+ MSI-X ADDRESS 4 |
|
||||
+----------------+ | +-----------------+
|
||||
EP CONTROLLER 2 | | |
|
||||
(OB SPACE) | | |
|
||||
+-------> MW1 |
|
||||
| |
|
||||
| |
|
||||
+-----------------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+-----------------+
|
||||
PCI Address Space
|
||||
(Managed by HOST2)
|
||||
|
||||
Above diagram shows how the doorbell and memory window 1 is mapped so that
|
||||
HOST1 can raise doorbell interrupt on HOST2 and also how HOST1 can access
|
||||
buffers exposed by HOST2 using memory window1 (MW1). Here doorbell and
|
||||
memory window 1 regions are allocated in EP controller 2 outbound (OB) address
|
||||
space. Allocating and configuring BARs for doorbell and memory window1
|
||||
is done during the initialization phase of NTB endpoint function driver.
|
||||
Mapping from EP controller 2 OB space to PCI address space is done when HOST2
|
||||
sends CMD_CONFIGURE_MW/CMD_CONFIGURE_DOORBELL.
|
||||
|
||||
Modeling Optional Memory Windows:
|
||||
---------------------------------
|
||||
|
||||
This is modeled the same was as MW1 but each of the additional memory windows
|
||||
is mapped to separate BARs.
|
|
@ -0,0 +1,161 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===================================================================
|
||||
PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
|
||||
===================================================================
|
||||
|
||||
:Author: Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
||||
This document is a guide to help users use pci-epf-ntb function driver
|
||||
and ntb_hw_epf host driver for NTB functionality. The list of steps to
|
||||
be followed in the host side and EP side is given below. For the hardware
|
||||
configuration and internals of NTB using configurable endpoints see
|
||||
Documentation/PCI/endpoint/pci-ntb-function.rst
|
||||
|
||||
Endpoint Device
|
||||
===============
|
||||
|
||||
Endpoint Controller Devices
|
||||
---------------------------
|
||||
|
||||
For implementing NTB functionality at least two endpoint controller devices
|
||||
are required.
|
||||
|
||||
To find the list of endpoint controller devices in the system::
|
||||
|
||||
# ls /sys/class/pci_epc/
|
||||
2900000.pcie-ep 2910000.pcie-ep
|
||||
|
||||
If PCI_ENDPOINT_CONFIGFS is enabled::
|
||||
|
||||
# ls /sys/kernel/config/pci_ep/controllers
|
||||
2900000.pcie-ep 2910000.pcie-ep
|
||||
|
||||
|
||||
Endpoint Function Drivers
|
||||
-------------------------
|
||||
|
||||
To find the list of endpoint function drivers in the system::
|
||||
|
||||
# ls /sys/bus/pci-epf/drivers
|
||||
pci_epf_ntb pci_epf_ntb
|
||||
|
||||
If PCI_ENDPOINT_CONFIGFS is enabled::
|
||||
|
||||
# ls /sys/kernel/config/pci_ep/functions
|
||||
pci_epf_ntb pci_epf_ntb
|
||||
|
||||
|
||||
Creating pci-epf-ntb Device
|
||||
----------------------------
|
||||
|
||||
PCI endpoint function device can be created using the configfs. To create
|
||||
pci-epf-ntb device, the following commands can be used::
|
||||
|
||||
# mount -t configfs none /sys/kernel/config
|
||||
# cd /sys/kernel/config/pci_ep/
|
||||
# mkdir functions/pci_epf_ntb/func1
|
||||
|
||||
The "mkdir func1" above creates the pci-epf-ntb function device that will
|
||||
be probed by pci_epf_ntb driver.
|
||||
|
||||
The PCI endpoint framework populates the directory with the following
|
||||
configurable fields::
|
||||
|
||||
# ls functions/pci_epf_ntb/func1
|
||||
baseclass_code deviceid msi_interrupts pci-epf-ntb.0
|
||||
progif_code secondary subsys_id vendorid
|
||||
cache_line_size interrupt_pin msix_interrupts primary
|
||||
revid subclass_code subsys_vendor_id
|
||||
|
||||
The PCI endpoint function driver populates these entries with default values
|
||||
when the device is bound to the driver. The pci-epf-ntb driver populates
|
||||
vendorid with 0xffff and interrupt_pin with 0x0001::
|
||||
|
||||
# cat functions/pci_epf_ntb/func1/vendorid
|
||||
0xffff
|
||||
# cat functions/pci_epf_ntb/func1/interrupt_pin
|
||||
0x0001
|
||||
|
||||
|
||||
Configuring pci-epf-ntb Device
|
||||
-------------------------------
|
||||
|
||||
The user can configure the pci-epf-ntb device using its configfs entry. In order
|
||||
to change the vendorid and the deviceid, the following
|
||||
commands can be used::
|
||||
|
||||
# echo 0x104c > functions/pci_epf_ntb/func1/vendorid
|
||||
# echo 0xb00d > functions/pci_epf_ntb/func1/deviceid
|
||||
|
||||
In order to configure NTB specific attributes, a new sub-directory to func1
|
||||
should be created::
|
||||
|
||||
# mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/
|
||||
|
||||
The NTB function driver will populate this directory with various attributes
|
||||
that can be configured by the user::
|
||||
|
||||
# ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/
|
||||
db_count mw1 mw2 mw3 mw4 num_mws
|
||||
spad_count
|
||||
|
||||
A sample configuration for NTB function is given below::
|
||||
|
||||
# echo 4 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/db_count
|
||||
# echo 128 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/spad_count
|
||||
# echo 2 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/num_mws
|
||||
# echo 0x100000 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw1
|
||||
# echo 0x100000 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw2
|
||||
|
||||
Binding pci-epf-ntb Device to EP Controller
|
||||
--------------------------------------------
|
||||
|
||||
NTB function device should be attached to two PCI endpoint controllers
|
||||
connected to the two hosts. Use the 'primary' and 'secondary' entries
|
||||
inside NTB function device to attach one PCI endpoint controller to
|
||||
primary interface and the other PCI endpoint controller to the secondary
|
||||
interface::
|
||||
|
||||
# ln -s controllers/2900000.pcie-ep/ functions/pci-epf-ntb/func1/primary
|
||||
# ln -s controllers/2910000.pcie-ep/ functions/pci-epf-ntb/func1/secondary
|
||||
|
||||
Once the above step is completed, both the PCI endpoint controllers are ready to
|
||||
establish a link with the host.
|
||||
|
||||
|
||||
Start the Link
|
||||
--------------
|
||||
|
||||
In order for the endpoint device to establish a link with the host, the _start_
|
||||
field should be populated with '1'. For NTB, both the PCI endpoint controllers
|
||||
should establish link with the host::
|
||||
|
||||
# echo 1 > controllers/2900000.pcie-ep/start
|
||||
# echo 1 > controllers/2910000.pcie-ep/start
|
||||
|
||||
|
||||
RootComplex Device
|
||||
==================
|
||||
|
||||
lspci Output
|
||||
------------
|
||||
|
||||
Note that the devices listed here correspond to the values populated in
|
||||
"Creating pci-epf-ntb Device" section above::
|
||||
|
||||
# lspci
|
||||
0000:00:00.0 PCI bridge: Texas Instruments Device b00d
|
||||
0000:01:00.0 RAM memory: Texas Instruments Device b00d
|
||||
|
||||
|
||||
Using ntb_hw_epf Device
|
||||
-----------------------
|
||||
|
||||
The host side software follows the standard NTB software architecture in Linux.
|
||||
All the existing client side NTB utilities like NTB Transport Client and NTB
|
||||
Netdev, NTB Ping Pong Test Client and NTB Tool Test Client can be used with NTB
|
||||
function device.
|
||||
|
||||
For more information on NTB see
|
||||
:doc:`Non-Transparent Bridge <../../driver-api/ntb>`
|
|
@ -683,7 +683,7 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni"
|
|||
,month="October"
|
||||
,year="2001"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2001/10/13/105}
|
||||
\url{https://lore.kernel.org/r/Pine.LNX.4.33.0110131015410.8707-100000@penguin.transmeta.com}
|
||||
[Viewed August 21, 2004]"
|
||||
,annotation={
|
||||
}
|
||||
|
@ -826,7 +826,7 @@ Symposium on Distributed Computing}
|
|||
,month="October"
|
||||
,year="2002"
|
||||
,note="Available:
|
||||
\url{https://lkml.org/lkml/2002/10/24/262}
|
||||
\url{https://lore.kernel.org/r/3DB86B05.447E7410@us.ibm.com}
|
||||
[Viewed February 15, 2014]"
|
||||
,annotation={
|
||||
Mingming Cao's patch to introduce RCU to SysV IPC.
|
||||
|
@ -839,7 +839,7 @@ Symposium on Distributed Computing}
|
|||
,month="March"
|
||||
,year="2003"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2003/3/9/205}
|
||||
\url{https://lore.kernel.org/r/Pine.LNX.4.44.0303091831560.2129-100000@home.transmeta.com}
|
||||
[Viewed March 13, 2006]"
|
||||
,annotation={
|
||||
Linus suggests replacing brlock with RCU and/or seqlocks:
|
||||
|
@ -1036,15 +1036,15 @@ Add per-cpu batch counter"
|
|||
,annotation={
|
||||
RCU runs reasonably on a 512-CPU SGI using Manfred Spraul's patches,
|
||||
which may be found at:
|
||||
https://lkml.org/lkml/2004/5/20/49 (split vars into cachelines)
|
||||
https://lkml.org/lkml/2004/5/22/114 (cpu_quiet() patch)
|
||||
https://lkml.org/lkml/2004/5/25/24 (0/5)
|
||||
https://lkml.org/lkml/2004/5/25/23 (1/5)
|
||||
https://lkml.org/lkml/2004/5/25/265 (works for Jack)
|
||||
https://lkml.org/lkml/2004/5/25/20 (2/5)
|
||||
https://lkml.org/lkml/2004/5/25/22 (3/5)
|
||||
https://lkml.org/lkml/2004/5/25/19 (4/5)
|
||||
https://lkml.org/lkml/2004/5/25/21 (5/5)
|
||||
https://lore.kernel.org/r/40AC9823.6020709@colorfullife.com (split vars into cachelines)
|
||||
https://lore.kernel.org/r/Pine.LNX.4.44.0405222141260.11106-100000@dbl.q-ag.de (cpu_quiet() patch)
|
||||
https://lore.kernel.org/r/200405250535.i4P5ZJo8017583@dbl.q-ag.de (0/5)
|
||||
https://lore.kernel.org/r/200405250535.i4P5ZKAQ017591@dbl.q-ag.de (1/5)
|
||||
https://lore.kernel.org/r/20040525203215.GB5127@sgi.com (works for Jack)
|
||||
https://lore.kernel.org/r/200405250535.i4P5ZLiR017599@dbl.q-ag.de (2/5)
|
||||
https://lore.kernel.org/r/200405250535.i4P5ZMFt017607@dbl.q-ag.de (3/5)
|
||||
https://lore.kernel.org/r/200405250535.i4P5ZN6g017615@dbl.q-ag.de (4/5)
|
||||
https://lore.kernel.org/r/200405250535.i4P5ZO7I017623@dbl.q-ag.de (5/5)
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -1106,7 +1106,7 @@ Oregon Health and Sciences University"
|
|||
,month="August"
|
||||
,year="2004"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2004/8/6/237}
|
||||
\url{https://lore.kernel.org/r/20040807192424.GF3936@in.ibm.com}
|
||||
[Viewed June 8, 2010]"
|
||||
,annotation={
|
||||
Introduce rcu_dereference().
|
||||
|
@ -1119,7 +1119,7 @@ Oregon Health and Sciences University"
|
|||
,month="August"
|
||||
,year="2004"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2004/8/30/87}
|
||||
\url{https://lore.kernel.org/r/1093873222.984.12.camel@new.localdomain}
|
||||
[Viewed February 17, 2005]"
|
||||
,annotation={
|
||||
Uses active code in rcu_read_lock() and rcu_read_unlock() to
|
||||
|
@ -1186,7 +1186,7 @@ Oregon Health and Sciences University"
|
|||
,month="October"
|
||||
,year="2004"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2004/10/23/241}
|
||||
\url{https://lore.kernel.org/r/20041023202723.GA1930@us.ibm.com}
|
||||
[Viewed June 8, 2010]"
|
||||
,annotation={
|
||||
Introduce rcu_assign_pointer().
|
||||
|
@ -1203,7 +1203,7 @@ Oregon Health and Sciences University"
|
|||
,annotation={
|
||||
James Morris posts Kaigai Kohei's patch to LKML.
|
||||
[Viewed December 10, 2004]
|
||||
Kaigai's patch is at https://lkml.org/lkml/2004/9/27/52
|
||||
Kaigai's patch is at https://lore.kernel.org/r/200409271057.i8RAvcA1007873@mailsv.bs1.fc.nec.co.jp
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -1241,7 +1241,7 @@ Oregon Health and Sciences University"
|
|||
,year="2005"
|
||||
,day="17"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2005/3/17/199}
|
||||
\url{https://lore.kernel.org/r/20050318002026.GA2693@us.ibm.com}
|
||||
[Viewed September 5, 2005]"
|
||||
,annotation={
|
||||
First posting showing how RCU can be safely adapted for
|
||||
|
@ -1256,7 +1256,7 @@ Oregon Health and Sciences University"
|
|||
,year="2005"
|
||||
,day="18"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2005/3/18/122}
|
||||
\url{https://lore.kernel.org/r/Pine.OSF.4.05.10503181336310.2466-100000@da410.phys.au.dk}
|
||||
[Viewed March 30, 2006]"
|
||||
,annotation={
|
||||
Esben Neilsen suggests read-side suppression of grace-period
|
||||
|
@ -1302,7 +1302,7 @@ Data Structures"
|
|||
,month="May"
|
||||
,year="2005"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2005/5/9/185}
|
||||
\url{https://lore.kernel.org/r/20050510012444.GA3011@us.ibm.com}
|
||||
[Viewed May 13, 2005]"
|
||||
,annotation={
|
||||
First publication of working lock-based deferred free patches
|
||||
|
@ -1385,7 +1385,7 @@ Data Structures"
|
|||
,day="1"
|
||||
,year="2005"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2005/8/1/155}
|
||||
\url{https://lore.kernel.org/r/20050801171137.GA1754@us.ibm.com}
|
||||
[Viewed March 14, 2006]"
|
||||
,annotation={
|
||||
First operating counter-based realtime RCU patch posted to LKML.
|
||||
|
@ -1399,7 +1399,7 @@ Data Structures"
|
|||
,day="8"
|
||||
,year="2005"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2005/8/8/108}
|
||||
\url{https://lore.kernel.org/r/20050808144216.GA1307@us.ibm.com}
|
||||
[Viewed March 14, 2006]"
|
||||
,annotation={
|
||||
First operating counter-based realtime RCU patch posted to LKML,
|
||||
|
@ -1415,7 +1415,7 @@ Data Structures"
|
|||
,day="1"
|
||||
,year="2005"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2005/10/1/70}
|
||||
\url{https://lore.kernel.org/r/20051001182056.GA1613@us.ibm.com}
|
||||
[Viewed March 14, 2006]"
|
||||
,annotation={
|
||||
First rcutorture patch.
|
||||
|
@ -1429,7 +1429,7 @@ Data Structures"
|
|||
,day="6"
|
||||
,year="2006"
|
||||
,note="Available:
|
||||
\url{https://lkml.org/lkml/2006/1/7/22}
|
||||
\url{https://lore.kernel.org/r/20060106.231054.43576567.davem@davemloft.net}
|
||||
[Viewed February 29, 2012]"
|
||||
,annotation={
|
||||
David Miller's view on hashed arrays of locks: used to really
|
||||
|
@ -1464,7 +1464,7 @@ Distributed Processing Symposium"
|
|||
,day="20"
|
||||
,year="2006"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2006/6/20/238}
|
||||
\url{https://lore.kernel.org/r/20060408134707.22479.33814.sendpatchset@linux.site}
|
||||
[Viewed March 25, 2008]"
|
||||
,annotation={
|
||||
RCU-protected radix tree.
|
||||
|
@ -1554,7 +1554,7 @@ Revised:
|
|||
,day="28"
|
||||
,year="2006"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2006/9/28/160}
|
||||
\url{https://lore.kernel.org/r/20060928142616.GA20185@infradead.org}
|
||||
[Viewed March 27, 2008]"
|
||||
}
|
||||
|
||||
|
@ -1593,7 +1593,7 @@ Revised:
|
|||
,year="2006"
|
||||
,day=26
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2006/10/26/73}
|
||||
\url{https://lore.kernel.org/r/20061026105731.GE11803@in.ibm.com}
|
||||
[Viewed January 26, 2009]"
|
||||
,annotation={
|
||||
RCU-based reader-writer lock that allows readers to proceed with
|
||||
|
@ -1612,12 +1612,12 @@ Revised:
|
|||
,year="2006"
|
||||
,day=17
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2006/11/17/56}
|
||||
\url{https://lore.kernel.org/r/20061117092925.GT7164@kernel.dk}
|
||||
[Viewed May 28, 2007]"
|
||||
,annotation={
|
||||
SRCU's grace periods are too slow for Jens, even after a
|
||||
factor-of-three speedup.
|
||||
Sped-up version of SRCU at http://lkml.org/lkml/2006/11/17/359.
|
||||
Sped-up version of SRCU at https://lore.kernel.org/r/20061118002845.GF2632@us.ibm.com.
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -1629,7 +1629,7 @@ Revised:
|
|||
,year="2006"
|
||||
,day=19
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2006/11/19/69}
|
||||
\url{https://lore.kernel.org/r/20061119190027.GA3676@oleg}
|
||||
[Viewed May 28, 2007]"
|
||||
,annotation={
|
||||
First cut of QRCU. Expanded/corrected versions followed.
|
||||
|
@ -1644,7 +1644,7 @@ Revised:
|
|||
,year="2006"
|
||||
,day=30
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2006/11/29/330}
|
||||
\url{https://lore.kernel.org/r/20061130015714.GC1350@oleg}
|
||||
[Viewed November 26, 2008]"
|
||||
,annotation={
|
||||
Expanded/corrected version of QRCU.
|
||||
|
@ -1709,7 +1709,7 @@ Revised:
|
|||
,year="2007"
|
||||
,day=3
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2007/1/3/112}
|
||||
\url{https://lore.kernel.org/r/20070103152738.GA16063@localdomain}
|
||||
[Viewed May 28, 2007]"
|
||||
,annotation={
|
||||
Patch for list_splice_rcu().
|
||||
|
@ -1737,7 +1737,7 @@ Revised:
|
|||
,year="2007"
|
||||
,day=28
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2007/1/28/34}
|
||||
\url{https://lore.kernel.org/r/20070128120509.719287000@programming.kicks-ass.net}
|
||||
[Viewed March 27, 2008]"
|
||||
,annotation={
|
||||
RCU-like implementation for frequent updaters and rare readers(!).
|
||||
|
@ -1767,7 +1767,7 @@ Revised:
|
|||
,year="2007"
|
||||
,day=24
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2007/2/25/18}
|
||||
\url{https://lore.kernel.org/r/20070225062349.GA17468@linux.vnet.ibm.com}
|
||||
[Viewed March 27, 2008]"
|
||||
,annotation={
|
||||
Patch for QRCU supplying lock-free fast path.
|
||||
|
@ -1846,7 +1846,7 @@ Revised:
|
|||
,annotation={
|
||||
LWN article describing Promela and spin, and also using Oleg
|
||||
Nesterov's QRCU as an example (with Paul McKenney's fastpath).
|
||||
Merged patch at: http://lkml.org/lkml/2007/2/25/18
|
||||
Merged patch at: https://lore.kernel.org/r/20070225062349.GA17468@linux.vnet.ibm.com
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -1885,7 +1885,7 @@ Revised:
|
|||
,day="10"
|
||||
,year="2007"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2007/9/10/213}
|
||||
\url{https://lore.kernel.org/r/20070910183004.GA3299@linux.vnet.ibm.com}
|
||||
[Viewed October 25, 2007]"
|
||||
,annotation={
|
||||
Final patch for preemptable RCU to -rt. (Later patches were
|
||||
|
@ -1933,7 +1933,7 @@ Revised:
|
|||
,day="20"
|
||||
,year="2007"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2007/12/20/244}
|
||||
\url{https://lore.kernel.org/r/20071220142540.GB22523@Krystal}
|
||||
[Viewed March 27, 2008]"
|
||||
,annotation={
|
||||
Request for call_rcu_sched() and rcu_barrier_sched().
|
||||
|
@ -2013,7 +2013,7 @@ Revised:
|
|||
,day="29"
|
||||
,year="2008"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2008/1/29/208}
|
||||
\url{https://lore.kernel.org/r/Pine.LNX.4.58.0801291113350.20371@gandalf.stny.rr.com}
|
||||
[Viewed March 27, 2008]"
|
||||
,annotation={
|
||||
Patch that prevents preemptible RCU from unnecessarily waking
|
||||
|
@ -2028,7 +2028,7 @@ Revised:
|
|||
,day="1"
|
||||
,year="2008"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2008/2/2/255}
|
||||
\url{https://lore.kernel.org/r/20080202214124.GA28612@linux.vnet.ibm.com}
|
||||
[Viewed October 18, 2008]"
|
||||
,annotation={
|
||||
Explanation of compilers violating dependency ordering.
|
||||
|
@ -2088,7 +2088,7 @@ lot of {Linux} into your technology!!!"
|
|||
,day="3"
|
||||
,year="2008"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2008/6/2/539}
|
||||
\url{https://lore.kernel.org/r/4844BE83.5010401@cn.fujitsu.com}
|
||||
[Viewed December 10, 2008]"
|
||||
,annotation={
|
||||
Updated RCU classic algorithm. Introduced multi-tailed list
|
||||
|
@ -2122,7 +2122,7 @@ lot of {Linux} into your technology!!!"
|
|||
,day="21"
|
||||
,year="2008"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2008/8/21/336}
|
||||
\url{https://lore.kernel.org/r/48AD8969.7060900@colorfullife.com}
|
||||
[Viewed December 8, 2008]"
|
||||
,annotation={
|
||||
State-based RCU. One key thing that this patch does is to
|
||||
|
@ -2137,7 +2137,7 @@ lot of {Linux} into your technology!!!"
|
|||
,day="6"
|
||||
,year="2008"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2008/9/6/86}
|
||||
\url{https://lore.kernel.org/r/48C2B1D2.5070801@colorfullife.com}
|
||||
[Viewed December 8, 2008]"
|
||||
,annotation={
|
||||
Manfred notes a fix required to my attempt to separate irq
|
||||
|
@ -2183,7 +2183,7 @@ lot of {Linux} into your technology!!!"
|
|||
,day="14"
|
||||
,year="2009"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2009/1/14/449}
|
||||
\url{https://lore.kernel.org/r/20090114202044.GJ6734@linux.vnet.ibm.com}
|
||||
[Viewed January 15, 2009]"
|
||||
,annotation={
|
||||
Small-footprint implementation of RCU for uniprocessor
|
||||
|
@ -2218,7 +2218,7 @@ lot of {Linux} into your technology!!!"
|
|||
git://lttng.org/userspace-rcu.git
|
||||
http://lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git
|
||||
http://lttng.org/urcu
|
||||
http://lkml.org/lkml/2009/2/5/572
|
||||
https://lore.kernel.org/r/20090206030543.GB8560@Krystal
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -2258,7 +2258,7 @@ lot of {Linux} into your technology!!!"
|
|||
,day="25"
|
||||
,year="2009"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2009/6/25/306}
|
||||
\url{https://lore.kernel.org/r/20090625160706.GA9467@linux.vnet.ibm.com}
|
||||
[Viewed August 16, 2009]"
|
||||
,annotation={
|
||||
First posting of expedited RCU to be accepted into -tip.
|
||||
|
@ -2272,7 +2272,7 @@ lot of {Linux} into your technology!!!"
|
|||
,day="23"
|
||||
,year="2009"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2009/7/23/294}
|
||||
\url{https://lore.kernel.org/r/20090724001429.GA17374@linux.vnet.ibm.com}
|
||||
[Viewed August 15, 2009]"
|
||||
,annotation={
|
||||
First posting of simple and fast preemptable RCU.
|
||||
|
@ -2350,7 +2350,7 @@ lot of {Linux} into your technology!!!"
|
|||
,month="December"
|
||||
,year="2009"
|
||||
,note="Available:
|
||||
\url{http://lkml.org/lkml/2009/10/18/129}
|
||||
\url{https://lore.kernel.org/r/20091018232918.GA7385@Krystal}
|
||||
[Viewed December 29, 2009]"
|
||||
,annotation={
|
||||
Mathieu proposed defer_rcu() with fixed-size per-thread pool
|
||||
|
@ -2518,7 +2518,7 @@ lot of {Linux} into your technology!!!"
|
|||
,month="January"
|
||||
,year="2011"
|
||||
,note="Available:
|
||||
\url{https://lkml.org/lkml/2011/1/18/322}
|
||||
\url{https://lore.kernel.org/r/AANLkTimajU0x1v6y3rH2+jr-bZ=tNLs1S_agXdGGAa3S@mail.gmail.com}
|
||||
[Viewed March 4, 2011]"
|
||||
,annotation={
|
||||
"The RCU-based name lookup is at the other end of the spectrum - the
|
||||
|
|
|
@ -3,8 +3,8 @@ Control Groupstats
|
|||
==================
|
||||
|
||||
Control Groupstats is inspired by the discussion at
|
||||
http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics as
|
||||
suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263.
|
||||
https://lore.kernel.org/r/461CF883.2030308@sw.ru and implements per cgroup statistics as
|
||||
suggested by Andrew Morton in https://lore.kernel.org/r/20070411114927.1277d7c9.akpm@linux-foundation.org.
|
||||
|
||||
Per cgroup statistics infrastructure re-uses code from the taskstats
|
||||
interface. A new set of cgroup operations are registered with commands
|
||||
|
|
|
@ -226,10 +226,11 @@ Configuring the kernel
|
|||
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.
|
||||
"make kvm_guest.config" Enable additional options for kvm guest kernel
|
||||
support.
|
||||
|
||||
"make xenconfig" Enable additional options for xen dom0 guest kernel
|
||||
support.
|
||||
"make xen.config" Enable additional options for xen dom0 guest kernel
|
||||
support.
|
||||
|
||||
"make tinyconfig" Configure the tiniest possible kernel.
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ cfag12864b LCD Driver Documentation
|
|||
===================================
|
||||
|
||||
:License: GPLv2
|
||||
:Author & Maintainer: Miguel Ojeda Sandonis
|
||||
:Author & Maintainer: Miguel Ojeda <ojeda@kernel.org>
|
||||
:Date: 2006-10-27
|
||||
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ ks0108 LCD Controller Driver Documentation
|
|||
==========================================
|
||||
|
||||
:License: GPLv2
|
||||
:Author & Maintainer: Miguel Ojeda Sandonis
|
||||
:Author & Maintainer: Miguel Ojeda <ojeda@kernel.org>
|
||||
:Date: 2006-10-27
|
||||
|
||||
|
||||
|
|
|
@ -963,21 +963,21 @@ References
|
|||
2. Singh, Balbir. Memory Controller (RSS Control),
|
||||
http://lwn.net/Articles/222762/
|
||||
3. Emelianov, Pavel. Resource controllers based on process cgroups
|
||||
http://lkml.org/lkml/2007/3/6/198
|
||||
https://lore.kernel.org/r/45ED7DEC.7010403@sw.ru
|
||||
4. Emelianov, Pavel. RSS controller based on process cgroups (v2)
|
||||
http://lkml.org/lkml/2007/4/9/78
|
||||
https://lore.kernel.org/r/461A3010.90403@sw.ru
|
||||
5. Emelianov, Pavel. RSS controller based on process cgroups (v3)
|
||||
http://lkml.org/lkml/2007/5/30/244
|
||||
https://lore.kernel.org/r/465D9739.8070209@openvz.org
|
||||
6. Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/
|
||||
7. Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control
|
||||
subsystem (v3), http://lwn.net/Articles/235534/
|
||||
8. Singh, Balbir. RSS controller v2 test results (lmbench),
|
||||
http://lkml.org/lkml/2007/5/17/232
|
||||
https://lore.kernel.org/r/464C95D4.7070806@linux.vnet.ibm.com
|
||||
9. Singh, Balbir. RSS controller v2 AIM9 results
|
||||
http://lkml.org/lkml/2007/5/18/1
|
||||
https://lore.kernel.org/r/464D267A.50107@linux.vnet.ibm.com
|
||||
10. Singh, Balbir. Memory controller v6 test results,
|
||||
http://lkml.org/lkml/2007/8/19/36
|
||||
https://lore.kernel.org/r/20070819094658.654.84837.sendpatchset@balbir-laptop
|
||||
11. Singh, Balbir. Memory controller introduction (v6),
|
||||
http://lkml.org/lkml/2007/8/17/69
|
||||
https://lore.kernel.org/r/20070817084228.26003.12568.sendpatchset@balbir-laptop
|
||||
12. Corbet, Jonathan, Controlling memory use in cgroups,
|
||||
http://lwn.net/Articles/243795/
|
||||
|
|
|
@ -1,3 +1,5 @@
|
|||
.. _cgroup-v2:
|
||||
|
||||
================
|
||||
Control Group v2
|
||||
================
|
||||
|
@ -172,7 +174,6 @@ disabling controllers in v1 and make them always available in v2.
|
|||
cgroup v2 currently supports the following mount options.
|
||||
|
||||
nsdelegate
|
||||
|
||||
Consider cgroup namespaces as delegation boundaries. This
|
||||
option is system wide and can only be set on mount or modified
|
||||
through remount from the init namespace. The mount option is
|
||||
|
@ -180,7 +181,6 @@ cgroup v2 currently supports the following mount options.
|
|||
Delegation section for details.
|
||||
|
||||
memory_localevents
|
||||
|
||||
Only populate memory.events with data for the current cgroup,
|
||||
and not any subtrees. This is legacy behaviour, the default
|
||||
behaviour without this option is to include subtree counts.
|
||||
|
@ -189,7 +189,6 @@ cgroup v2 currently supports the following mount options.
|
|||
option is ignored on non-init namespace mounts.
|
||||
|
||||
memory_recursiveprot
|
||||
|
||||
Recursively apply memory.min and memory.low protection to
|
||||
entire subtrees, without requiring explicit downward
|
||||
propagation into leaf cgroups. This allows protecting entire
|
||||
|
@ -786,7 +785,6 @@ Core Interface Files
|
|||
All cgroup core files are prefixed with "cgroup."
|
||||
|
||||
cgroup.type
|
||||
|
||||
A read-write single value file which exists on non-root
|
||||
cgroups.
|
||||
|
||||
|
@ -954,6 +952,8 @@ All cgroup core files are prefixed with "cgroup."
|
|||
Controllers
|
||||
===========
|
||||
|
||||
.. _cgroup-v2-cpu:
|
||||
|
||||
CPU
|
||||
---
|
||||
|
||||
|
@ -1259,9 +1259,9 @@ PAGE_SIZE multiple when read back.
|
|||
can show up in the middle. Don't rely on items remaining in a
|
||||
fixed position; use the keys to look up specific values!
|
||||
|
||||
If the entry has no per-node counter(or not show in the
|
||||
mempry.numa_stat). We use 'npn'(non-per-node) as the tag
|
||||
to indicate that it will not show in the mempry.numa_stat.
|
||||
If the entry has no per-node counter (or not show in the
|
||||
memory.numa_stat). We use 'npn' (non-per-node) as the tag
|
||||
to indicate that it will not show in the memory.numa_stat.
|
||||
|
||||
anon
|
||||
Amount of memory used in anonymous mappings such as
|
||||
|
@ -1277,11 +1277,11 @@ PAGE_SIZE multiple when read back.
|
|||
pagetables
|
||||
Amount of memory allocated for page tables.
|
||||
|
||||
percpu(npn)
|
||||
percpu (npn)
|
||||
Amount of memory used for storing per-cpu kernel
|
||||
data structures.
|
||||
|
||||
sock(npn)
|
||||
sock (npn)
|
||||
Amount of memory used in network transmission buffers
|
||||
|
||||
shmem
|
||||
|
@ -1299,6 +1299,10 @@ PAGE_SIZE multiple when read back.
|
|||
Amount of cached filesystem data that was modified and
|
||||
is currently being written back to disk
|
||||
|
||||
swapcached
|
||||
Amount of swap cached in memory. The swapcache is accounted
|
||||
against both memory and swap usage.
|
||||
|
||||
anon_thp
|
||||
Amount of memory used in anonymous mappings backed by
|
||||
transparent hugepages
|
||||
|
@ -1329,7 +1333,7 @@ PAGE_SIZE multiple when read back.
|
|||
Part of "slab" that cannot be reclaimed on memory
|
||||
pressure.
|
||||
|
||||
slab(npn)
|
||||
slab (npn)
|
||||
Amount of memory used for storing in-kernel data
|
||||
structures.
|
||||
|
||||
|
@ -1357,39 +1361,39 @@ PAGE_SIZE multiple when read back.
|
|||
workingset_nodereclaim
|
||||
Number of times a shadow node has been reclaimed
|
||||
|
||||
pgfault(npn)
|
||||
pgfault (npn)
|
||||
Total number of page faults incurred
|
||||
|
||||
pgmajfault(npn)
|
||||
pgmajfault (npn)
|
||||
Number of major page faults incurred
|
||||
|
||||
pgrefill(npn)
|
||||
pgrefill (npn)
|
||||
Amount of scanned pages (in an active LRU list)
|
||||
|
||||
pgscan(npn)
|
||||
pgscan (npn)
|
||||
Amount of scanned pages (in an inactive LRU list)
|
||||
|
||||
pgsteal(npn)
|
||||
pgsteal (npn)
|
||||
Amount of reclaimed pages
|
||||
|
||||
pgactivate(npn)
|
||||
pgactivate (npn)
|
||||
Amount of pages moved to the active LRU list
|
||||
|
||||
pgdeactivate(npn)
|
||||
pgdeactivate (npn)
|
||||
Amount of pages moved to the inactive LRU list
|
||||
|
||||
pglazyfree(npn)
|
||||
pglazyfree (npn)
|
||||
Amount of pages postponed to be freed under memory pressure
|
||||
|
||||
pglazyfreed(npn)
|
||||
pglazyfreed (npn)
|
||||
Amount of reclaimed lazyfree pages
|
||||
|
||||
thp_fault_alloc(npn)
|
||||
thp_fault_alloc (npn)
|
||||
Number of transparent hugepages which were allocated to satisfy
|
||||
a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
|
||||
is not set.
|
||||
|
||||
thp_collapse_alloc(npn)
|
||||
thp_collapse_alloc (npn)
|
||||
Number of transparent hugepages which were allocated to allow
|
||||
collapsing an existing range of pages. This counter is not
|
||||
present when CONFIG_TRANSPARENT_HUGEPAGE is not set.
|
||||
|
@ -1558,7 +1562,7 @@ IO Interface Files
|
|||
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021
|
||||
|
||||
io.cost.qos
|
||||
A read-write nested-keyed file with exists only on the root
|
||||
A read-write nested-keyed file which exists only on the root
|
||||
cgroup.
|
||||
|
||||
This file configures the Quality of Service of the IO cost
|
||||
|
@ -1613,7 +1617,7 @@ IO Interface Files
|
|||
automatic mode can be restored by setting "ctrl" to "auto".
|
||||
|
||||
io.cost.model
|
||||
A read-write nested-keyed file with exists only on the root
|
||||
A read-write nested-keyed file which exists only on the root
|
||||
cgroup.
|
||||
|
||||
This file configures the cost model of the IO cost model based
|
||||
|
@ -2000,10 +2004,12 @@ Cpuset Interface Files
|
|||
cpuset-enabled cgroups. This flag is owned by the parent cgroup
|
||||
and is not delegatable.
|
||||
|
||||
It accepts only the following input values when written to.
|
||||
It accepts only the following input values when written to.
|
||||
|
||||
"root" - a partition root
|
||||
"member" - a non-root member of a partition
|
||||
======== ================================
|
||||
"root" a partition root
|
||||
"member" a non-root member of a partition
|
||||
======== ================================
|
||||
|
||||
When set to be a partition root, the current cgroup is the
|
||||
root of a new partition or scheduling domain that comprises
|
||||
|
@ -2044,9 +2050,11 @@ Cpuset Interface Files
|
|||
root to change. On read, the "cpuset.sched.partition" file
|
||||
can show the following values.
|
||||
|
||||
"member" Non-root member of a partition
|
||||
"root" Partition root
|
||||
"root invalid" Invalid partition root
|
||||
============== ==============================
|
||||
"member" Non-root member of a partition
|
||||
"root" Partition root
|
||||
"root invalid" Invalid partition root
|
||||
============== ==============================
|
||||
|
||||
It is a partition root if the first 2 partition root conditions
|
||||
above are true and at least one CPU from "cpuset.cpus" is
|
||||
|
@ -2090,7 +2098,7 @@ If the program returns 0, the attempt fails with -EPERM, otherwise
|
|||
it succeeds.
|
||||
|
||||
An example of BPF_CGROUP_DEVICE program may be found in the kernel
|
||||
source tree in the tools/testing/selftests/bpf/dev_cgroup.c file.
|
||||
source tree in the tools/testing/selftests/bpf/progs/dev_cgroup.c file.
|
||||
|
||||
|
||||
RDMA
|
||||
|
@ -2219,7 +2227,7 @@ Without cgroup namespace, the "/proc/$PID/cgroup" file shows the
|
|||
complete path of the cgroup of a process. In a container setup where
|
||||
a set of cgroups and namespaces are intended to isolate processes the
|
||||
"/proc/$PID/cgroup" file may leak potential system level information
|
||||
to the isolated processes. For Example::
|
||||
to the isolated processes. For example::
|
||||
|
||||
# cat /proc/self/cgroup
|
||||
0::/batchjobs/container_id1
|
||||
|
|
|
@ -5,10 +5,10 @@ Authors
|
|||
Original Author
|
||||
---------------
|
||||
|
||||
Steve French (sfrench@samba.org)
|
||||
Steve French (smfrench@gmail.com, sfrench@samba.org)
|
||||
|
||||
The author wishes to express his appreciation and thanks to:
|
||||
Andrew Tridgell (Samba team) for his early suggestions about smb/cifs VFS
|
||||
Andrew Tridgell (Samba team) for his early suggestions about SMB/CIFS VFS
|
||||
improvements. Thanks to IBM for allowing me time and test resources to pursue
|
||||
this project, to Jim McDonough from IBM (and the Samba Team) for his help, to
|
||||
the IBM Linux JFS team for explaining many esoteric Linux filesystem features.
|
||||
|
@ -51,7 +51,7 @@ Patch Contributors
|
|||
- Ronnie Sahlberg (for SMB3 xattr work, bug fixes, and lots of great work on compounding)
|
||||
- Shirish Pargaonkar (for many ACL patches over the years)
|
||||
- Sachin Prabhu (many bug fixes, including for reconnect, copy offload and security)
|
||||
- Paulo Alcantara
|
||||
- Paulo Alcantara (for some excellent work in DFS, and in booting from SMB3)
|
||||
- Long Li (some great work on RDMA, SMB Direct)
|
||||
|
||||
|
||||
|
|
|
@ -3,6 +3,7 @@ Changes
|
|||
=======
|
||||
|
||||
See https://wiki.samba.org/index.php/LinuxCIFSKernel for summary
|
||||
information (that may be easier to read than parsing the output of
|
||||
"git log fs/cifs") about fixes/improvements to CIFS/SMB2/SMB3 support (changes
|
||||
information about fixes/improvements to CIFS/SMB2/SMB3 support (changes
|
||||
to cifs.ko module) by kernel version (and cifs internal module version).
|
||||
This may be easier to read than parsing the output of "git log fs/cifs"
|
||||
by release.
|
||||
|
|
|
@ -7,19 +7,19 @@ Introduction
|
|||
protocol which was the successor to the Server Message Block
|
||||
(SMB) protocol, the native file sharing mechanism for most early
|
||||
PC operating systems. New and improved versions of CIFS are now
|
||||
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1)
|
||||
is strongly preferred over using older dialects like CIFS due to
|
||||
security reasons. All modern dialects, including the most recent,
|
||||
SMB3.1.1 are supported by the CIFS VFS module. The SMB3 protocol
|
||||
is implemented and supported by all major file servers
|
||||
such as all modern versions of Windows (including Windows 2016
|
||||
Server), as well as by Samba (which provides excellent
|
||||
CIFS/SMB2/SMB3 server support and tools for Linux and many other
|
||||
operating systems). Apple systems also support SMB3 well, as
|
||||
do most Network Attached Storage vendors, so this network
|
||||
filesystem client can mount to a wide variety of systems.
|
||||
It also supports mounting to the cloud (for example
|
||||
Microsoft Azure), including the necessary security features.
|
||||
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1
|
||||
the most current dialect) is strongly preferred over using older
|
||||
dialects like CIFS due to security reasons. All modern dialects,
|
||||
including the most recent, SMB3.1.1, are supported by the CIFS VFS
|
||||
module. The SMB3 protocol is implemented and supported by all major
|
||||
file servers such as Windows (including Windows 2019 Server), as
|
||||
well as by Samba (which provides excellent CIFS/SMB2/SMB3 server
|
||||
support and tools for Linux and many other operating systems).
|
||||
Apple systems also support SMB3 well, as do most Network Attached
|
||||
Storage vendors, so this network filesystem client can mount to a
|
||||
wide variety of systems. It also supports mounting to the cloud
|
||||
(for example Microsoft Azure), including the necessary security
|
||||
features.
|
||||
|
||||
The intent of this module is to provide the most advanced network
|
||||
file system function for SMB3 compliant servers, including advanced
|
||||
|
@ -27,8 +27,8 @@ Introduction
|
|||
POSIX compliance, secure per-user session establishment, encryption,
|
||||
high performance safe distributed caching (leases/oplocks), optional packet
|
||||
signing, large files, Unicode support and other internationalization
|
||||
improvements. Since both Samba server and this filesystem client support
|
||||
the CIFS Unix extensions (and in the future SMB3 POSIX extensions),
|
||||
improvements. Since both Samba server and this filesystem client support the
|
||||
CIFS Unix extensions, and the Linux client also suppors SMB3 POSIX extensions,
|
||||
the combination can provide a reasonable alternative to other network and
|
||||
cluster file systems for fileserving in some Linux to Linux environments,
|
||||
not just in Linux to Windows (or Linux to Mac) environments.
|
||||
|
|
|
@ -13,24 +13,26 @@ is a partial list of the known problems and missing features:
|
|||
|
||||
a) SMB3 (and SMB3.1.1) missing optional features:
|
||||
|
||||
- multichannel (started), integration with RDMA
|
||||
- directory leases (improved metadata caching), started (root dir only)
|
||||
- multichannel (partially integrated), integration of multichannel with RDMA
|
||||
- directory leases (improved metadata caching). Currently only implemented for root dir
|
||||
- T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
|
||||
currently the only two server side copy mechanisms supported)
|
||||
|
||||
b) improved sparse file support (fiemap and SEEK_HOLE are implemented
|
||||
but additional features would be supportable by the protocol).
|
||||
but additional features would be supportable by the protocol such
|
||||
as FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE)
|
||||
|
||||
c) Directory entry caching relies on a 1 second timer, rather than
|
||||
using Directory Leases, currently only the root file handle is cached longer
|
||||
by leveraging Directory Leases
|
||||
|
||||
d) quota support (needs minor kernel change since quota calls
|
||||
to make it to network filesystems or deviceless filesystems)
|
||||
d) quota support (needs minor kernel change since quota calls otherwise
|
||||
won't make it to network filesystems or deviceless filesystems).
|
||||
|
||||
e) Additional use cases can be optimized to use "compounding" (e.g.
|
||||
open/query/close and open/setinfo/close) to reduce the number of
|
||||
roundtrips to the server and improve performance. Various cases
|
||||
(stat, statfs, create, unlink, mkdir) already have been improved by
|
||||
(stat, statfs, create, unlink, mkdir, xattrs) already have been improved by
|
||||
using compounding but more can be done. In addition we could
|
||||
significantly reduce redundant opens by using deferred close (with
|
||||
handle caching leases) and better using reference counters on file
|
||||
|
@ -60,7 +62,9 @@ k) Add tools to take advantage of more smb3 specific ioctls and features
|
|||
metadata attributes easier from tools (e.g. extending what was done
|
||||
in smb-info tool).
|
||||
|
||||
l) encrypted file support
|
||||
l) encrypted file support (currently the attribute showing the file is
|
||||
encrypted on the server is reported, but changing the attribute is not
|
||||
supported).
|
||||
|
||||
m) improved stats gathering tools (perhaps integration with nfsometer?)
|
||||
to extend and make easier to use what is currently in /proc/fs/cifs/Stats
|
||||
|
@ -69,14 +73,13 @@ n) Add support for claims based ACLs ("DAC")
|
|||
|
||||
o) mount helper GUI (to simplify the various configuration options on mount)
|
||||
|
||||
p) Add support for witness protocol (perhaps ioctl to cifs.ko from user space
|
||||
tool listening on witness protocol RPC) to allow for notification of share
|
||||
move, server failover, and server adapter changes. And also improve other
|
||||
failover scenarios, e.g. when client knows multiple DFS entries point to
|
||||
different servers, and the server we are connected to has gone down.
|
||||
p) Expand support for witness protocol to allow for notification of share
|
||||
move, and server network adapter changes. Currently only notifications by
|
||||
the witness protocol for server move is supported by the Linux client.
|
||||
|
||||
q) Allow mount.cifs to be more verbose in reporting errors with dialect
|
||||
or unsupported feature errors.
|
||||
or unsupported feature errors. This would now be easier due to the
|
||||
implementation of the new mount API.
|
||||
|
||||
r) updating cifs documentation, and user guide.
|
||||
|
||||
|
@ -87,11 +90,10 @@ t) split cifs and smb3 support into separate modules so legacy (and less
|
|||
secure) CIFS dialect can be disabled in environments that don't need it
|
||||
and simplify the code.
|
||||
|
||||
v) POSIX Extensions for SMB3.1.1 (started, create and mkdir support added
|
||||
so far).
|
||||
v) Additional testing of POSIX Extensions for SMB3.1.1
|
||||
|
||||
w) Add support for additional strong encryption types, and additional spnego
|
||||
authentication mechanisms (see MS-SMB2)
|
||||
authentication mechanisms (see MS-SMB2). GCM-256 is now partially implemented.
|
||||
|
||||
x) Finish support for SMB3.1.1 compression
|
||||
|
||||
|
|
|
@ -83,7 +83,7 @@ and encrypted shares and stronger signing and authentication algorithms.
|
|||
There are additional mount options that may be helpful for SMB3 to get
|
||||
improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1):
|
||||
|
||||
``mfsymlinks`` and ``cifsacl`` and ``idsfromsid``
|
||||
``mfsymlinks`` and either ``cifsacl`` or ``modefromsid`` (usually with ``idsfromsid``)
|
||||
|
||||
Allowing User Mounts
|
||||
====================
|
||||
|
|
|
@ -107,7 +107,7 @@ will lead to quite erratic information inside ``/proc/stat``::
|
|||
References
|
||||
----------
|
||||
|
||||
- http://lkml.org/lkml/2007/2/12/6
|
||||
- https://lore.kernel.org/r/loom.20070212T063225-663@post.gmane.org
|
||||
- Documentation/filesystems/proc.rst (1.8)
|
||||
|
||||
|
||||
|
|
|
@ -67,7 +67,7 @@ Parameters::
|
|||
the value passed in <key_size>.
|
||||
|
||||
<key_type>
|
||||
Either 'logon', 'user' or 'encrypted' kernel key type.
|
||||
Either 'logon', 'user', 'encrypted' or 'trusted' kernel key type.
|
||||
|
||||
<key_description>
|
||||
The kernel keyring key description crypt target should look for
|
||||
|
|
|
@ -143,8 +143,8 @@ recalculate
|
|||
journal_crypt:algorithm(:key) (the key is optional)
|
||||
Encrypt the journal using given algorithm to make sure that the
|
||||
attacker can't read the journal. You can use a block cipher here
|
||||
(such as "cbc(aes)") or a stream cipher (for example "chacha20",
|
||||
"salsa20" or "ctr(aes)").
|
||||
(such as "cbc(aes)") or a stream cipher (for example "chacha20"
|
||||
or "ctr(aes)").
|
||||
|
||||
The journal contains history of last writes to the block device,
|
||||
an attacker reading the journal could see the last sector numbers
|
||||
|
@ -186,6 +186,17 @@ fix_padding
|
|||
space-efficient. If this option is not present, large padding is
|
||||
used - that is for compatibility with older kernels.
|
||||
|
||||
fix_hmac
|
||||
Improve security of internal_hash and journal_mac:
|
||||
|
||||
- the section number is mixed to the mac, so that an attacker can't
|
||||
copy sectors from one journal section to another journal section
|
||||
- the superblock is protected by journal_mac
|
||||
- a 16-byte salt stored in the superblock is mixed to the mac, so
|
||||
that the attacker can't detect that two disks have the same hmac
|
||||
key and also to disallow the attacker to move sectors from one
|
||||
disk to another
|
||||
|
||||
legacy_recalculate
|
||||
Allow recalculating of volumes with HMAC keys. This is disabled by
|
||||
default for security reasons - an attacker could modify the volume,
|
||||
|
|
|
@ -60,7 +60,7 @@ Note that for the special case of a range one can split the range into equal
|
|||
sized groups and for each group use some amount from the beginning of that
|
||||
group:
|
||||
|
||||
<cpu number>-cpu number>:<used size>/<group size>
|
||||
<cpu number>-<cpu number>:<used size>/<group size>
|
||||
|
||||
For example one can add to the command line following parameter:
|
||||
|
||||
|
|
|
@ -606,7 +606,7 @@
|
|||
kernel/dma/contiguous.c
|
||||
|
||||
cma_pernuma=nn[MG]
|
||||
[ARM64,KNL]
|
||||
[ARM64,KNL,CMA]
|
||||
Sets the size of kernel per-numa memory area for
|
||||
contiguous memory allocations. A value of 0 disables
|
||||
per-numa CMA altogether. And If this option is not
|
||||
|
@ -1434,6 +1434,11 @@
|
|||
to enforce probe and suspend/resume ordering.
|
||||
rpm -- Like "on", but also use to order runtime PM.
|
||||
|
||||
fw_devlink.strict=<bool>
|
||||
[KNL] Treat all inferred dependencies as mandatory
|
||||
dependencies. This only applies for fw_devlink=on|rpm.
|
||||
Format: <bool>
|
||||
|
||||
gamecon.map[2|3]=
|
||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||
support via parallel port (up to 5 devices per port)
|
||||
|
@ -1525,12 +1530,12 @@
|
|||
hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET
|
||||
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
|
||||
|
||||
hugetlb_cma= [HW] The size of a cma area used for allocation
|
||||
hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation
|
||||
of gigantic hugepages.
|
||||
Format: nn[KMGTPE]
|
||||
|
||||
Reserve a cma area of given size and allocate gigantic
|
||||
hugepages using the cma allocator. If enabled, the
|
||||
Reserve a CMA area of given size and allocate gigantic
|
||||
hugepages using the CMA allocator. If enabled, the
|
||||
boot-time allocation of gigantic hugepages is skipped.
|
||||
|
||||
hugepages= [HW] Number of HugeTLB pages to allocate at boot.
|
||||
|
@ -1674,6 +1679,12 @@
|
|||
In such case C2/C3 won't be used again.
|
||||
idle=nomwait: Disable mwait for CPU C-states
|
||||
|
||||
idxd.sva= [HW]
|
||||
Format: <bool>
|
||||
Allow force disabling of Shared Virtual Memory (SVA)
|
||||
support for the idxd driver. By default it is set to
|
||||
true (1).
|
||||
|
||||
ieee754= [MIPS] Select IEEE Std 754 conformance mode
|
||||
Format: { strict | legacy | 2008 | relaxed }
|
||||
Default: strict
|
||||
|
@ -1747,7 +1758,7 @@
|
|||
ima_policy= [IMA]
|
||||
The builtin policies to load during IMA setup.
|
||||
Format: "tcb | appraise_tcb | secure_boot |
|
||||
fail_securely"
|
||||
fail_securely | critical_data"
|
||||
|
||||
The "tcb" policy measures all programs exec'd, files
|
||||
mmap'd for exec, and all files opened with the read
|
||||
|
@ -1766,6 +1777,9 @@
|
|||
filesystems with the SB_I_UNVERIFIABLE_SIGNATURE
|
||||
flag.
|
||||
|
||||
The "critical_data" policy measures kernel integrity
|
||||
critical data.
|
||||
|
||||
ima_tcb [IMA] Deprecated. Use ima_policy= instead.
|
||||
Load a policy which meets the needs of the Trusted
|
||||
Computing Base. This means IMA will measure all
|
||||
|
@ -3270,9 +3284,14 @@
|
|||
parameter, xsave area per process might occupy more
|
||||
memory on xsaves enabled systems.
|
||||
|
||||
nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
|
||||
wfi(ARM) instruction doesn't work correctly and not to
|
||||
use it. This is also useful when using JTAG debugger.
|
||||
nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait
|
||||
in do_idle() and not use the arch_cpu_idle()
|
||||
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
|
||||
to be effective. This is useful on platforms where the
|
||||
sleep(SH) or wfi(ARM,ARM64) instructions do not work
|
||||
correctly or when doing power measurements to evalute
|
||||
the impact of the sleep instructions. This is also
|
||||
useful when using JTAG debugger.
|
||||
|
||||
no_file_caps Tells the kernel not to honor file capabilities. The
|
||||
only way then for a file to be executed with privilege
|
||||
|
@ -3285,6 +3304,21 @@
|
|||
in certain environments such as networked servers or
|
||||
real-time systems.
|
||||
|
||||
no_hash_pointers
|
||||
Force pointers printed to the console or buffers to be
|
||||
unhashed. By default, when a pointer is printed via %p
|
||||
format string, that pointer is "hashed", i.e. obscured
|
||||
by hashing the pointer value. This is a security feature
|
||||
that hides actual kernel addresses from unprivileged
|
||||
users, but it also makes debugging the kernel more
|
||||
difficult since unequal pointers can no longer be
|
||||
compared. However, if this command-line option is
|
||||
specified, then all normal pointers will have their true
|
||||
value printed. Pointers printed via %pK may still be
|
||||
hashed. This option should only be specified when
|
||||
debugging the kernel. Please do not use on production
|
||||
kernels.
|
||||
|
||||
nohibernate [HIBERNATION] Disable hibernation and resume.
|
||||
|
||||
nohz= [KNL] Boottime enable/disable dynamic ticks
|
||||
|
@ -4870,14 +4904,6 @@
|
|||
last alloc / free. For more information see
|
||||
Documentation/vm/slub.rst.
|
||||
|
||||
slub_memcg_sysfs= [MM, SLUB]
|
||||
Determines whether to enable sysfs directories for
|
||||
memory cgroup sub-caches. 1 to enable, 0 to disable.
|
||||
The default is determined by CONFIG_SLUB_MEMCG_SYSFS_ON.
|
||||
Enabling this can lead to a very high number of debug
|
||||
directories and files being created under
|
||||
/sys/kernel/slub.
|
||||
|
||||
slub_max_order= [MM, SLUB]
|
||||
Determines the maximum allowed order for slabs.
|
||||
A high setting may cause OOMs due to memory
|
||||
|
@ -5156,6 +5182,12 @@
|
|||
growing up) the main stack are reserved for no other
|
||||
mapping. Default value is 256 pages.
|
||||
|
||||
stack_depot_disable= [KNL]
|
||||
Setting this to true through kernel command line will
|
||||
disable the stack depot thereby saving the static memory
|
||||
consumed by the stack hash table. By default this is set
|
||||
to false.
|
||||
|
||||
stacktrace [FTRACE]
|
||||
Enabled the stack tracer on boot up.
|
||||
|
||||
|
@ -5956,12 +5988,6 @@
|
|||
default x2apic cluster mode on platforms
|
||||
supporting x2apic.
|
||||
|
||||
x86_intel_mid_timer= [X86-32,APBT]
|
||||
Choose timer option for x86 Intel MID platform.
|
||||
Two valid options are apbt timer only and lapic timer
|
||||
plus one apbt timer for broadcast timer.
|
||||
x86_intel_mid_timer=apbt_only | lapic_and_apbt
|
||||
|
||||
xen_512gb_limit [KNL,X86-64,XEN]
|
||||
Restricts the kernel running paravirtualized under Xen
|
||||
to use only up to 512 GB of RAM. The reason to do so is
|
||||
|
|
|
@ -273,7 +273,7 @@ To reduce its OS jitter, do any of the following:
|
|||
However, there is an RFC patch from Christoph Lameter
|
||||
(based on an earlier one from Gilad Ben-Yossef) that
|
||||
reduces or even eliminates vmstat overhead for some
|
||||
workloads at https://lkml.org/lkml/2013/9/4/379.
|
||||
workloads at https://lore.kernel.org/r/00000140e9dfd6bd-40db3d4f-c1be-434f-8132-7820f81bb586-000000@email.amazonses.com.
|
||||
e. If running on high-end powerpc servers, build with
|
||||
CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS
|
||||
daemon from running on each CPU every second or so.
|
||||
|
|
|
@ -51,6 +51,7 @@ detailed description):
|
|||
- UWB enable and disable
|
||||
- LCD Shadow (PrivacyGuard) enable and disable
|
||||
- Lap mode sensor
|
||||
- Setting keyboard language
|
||||
|
||||
A compatibility table by model and feature is maintained on the web
|
||||
site, http://ibm-acpi.sf.net/. I appreciate any success or failure
|
||||
|
@ -1466,6 +1467,30 @@ Sysfs notes
|
|||
rfkill controller switch "tpacpi_uwb_sw": refer to
|
||||
Documentation/driver-api/rfkill.rst for details.
|
||||
|
||||
|
||||
Setting keyboard language
|
||||
-------------------------
|
||||
|
||||
sysfs: keyboard_lang
|
||||
|
||||
This feature is used to set keyboard language to ECFW using ASL interface.
|
||||
Fewer thinkpads models like T580 , T590 , T15 Gen 1 etc.. has "=", "(',
|
||||
")" numeric keys, which are not displaying correctly, when keyboard language
|
||||
is other than "english". This is because the default keyboard language in ECFW
|
||||
is set as "english". Hence using this sysfs, user can set the correct keyboard
|
||||
language to ECFW and then these key's will work correctly.
|
||||
|
||||
Example of command to set keyboard language is mentioned below::
|
||||
|
||||
echo jp > /sys/devices/platform/thinkpad_acpi/keyboard_lang
|
||||
|
||||
Text corresponding to keyboard layout to be set in sysfs are: be(Belgian),
|
||||
cz(Czech), da(Danish), de(German), en(English), es(Spain), et(Estonian),
|
||||
fr(French), fr-ch(French(Switzerland)), hu(Hungarian), it(Italy), jp (Japan),
|
||||
nl(Dutch), nn(Norway), pl(Polish), pt(portugese), sl(Slovenian), sv(Sweden),
|
||||
tr(Turkey)
|
||||
|
||||
|
||||
Adaptive keyboard
|
||||
-----------------
|
||||
|
||||
|
|
|
@ -160,16 +160,16 @@ Under each memory block, you can see 5 files:
|
|||
|
||||
"online_movable", "online", "offline" command
|
||||
which will be performed on all sections in the block.
|
||||
``phys_device`` read-only: designed to show the name of physical memory
|
||||
device. This is not well implemented now.
|
||||
``removable`` read-only: contains an integer value indicating
|
||||
whether the memory block is removable or not
|
||||
removable. A value of 1 indicates that the memory
|
||||
block is removable and a value of 0 indicates that
|
||||
it is not removable. A memory block is removable only if
|
||||
every section in the block is removable.
|
||||
``valid_zones`` read-only: designed to show which zones this memory block
|
||||
can be onlined to.
|
||||
``phys_device`` read-only: legacy interface only ever used on s390x to
|
||||
expose the covered storage increment.
|
||||
``removable`` read-only: legacy interface that indicated whether a memory
|
||||
block was likely to be offlineable or not. Newer kernel
|
||||
versions return "1" if and only if the kernel supports
|
||||
memory offlining.
|
||||
``valid_zones`` read-only: designed to show by which zone memory provided by
|
||||
a memory block is managed, and to show by which zone memory
|
||||
provided by an offline memory block could be managed when
|
||||
onlining.
|
||||
|
||||
The first column shows it`s default zone.
|
||||
|
||||
|
|
|
@ -72,7 +72,7 @@ monitoring and observability operations, thus, bypass *scope* permissions
|
|||
checks in the kernel. CAP_PERFMON implements the principle of least
|
||||
privilege [13]_ (POSIX 1003.1e: 2.2.2.39) for performance monitoring and
|
||||
observability operations in the kernel and provides a secure approach to
|
||||
perfomance monitoring and observability in the system.
|
||||
performance monitoring and observability in the system.
|
||||
|
||||
For backward compatibility reasons the access to perf_events monitoring and
|
||||
observability operations is also open for CAP_SYS_ADMIN privileged
|
||||
|
|
|
@ -1033,7 +1033,9 @@ speakup + keypad 3, you would hear:
|
|||
The speakup key is depressed, so the name of the key state is speakup.
|
||||
This part of the message comes from the states collection.
|
||||
|
||||
14.2. Loading Your Own Messages
|
||||
14.2. Changing language
|
||||
|
||||
14.2.1. Loading Your Own Messages
|
||||
|
||||
The files under the i18n subdirectory all follow the same format.
|
||||
They consist of lines, with one message per line.
|
||||
|
@ -1066,8 +1068,50 @@ echo '1 azul' > /speakup/i18n/colors
|
|||
The next time that Speakup says message 1 from the colors group, it will
|
||||
say "azul", rather than "blue."
|
||||
|
||||
14.2.2. Choose a language
|
||||
|
||||
In the future, translations into various languages will be made available,
|
||||
and most users will just load the files necessary for their language.
|
||||
and most users will just load the files necessary for their language. So far,
|
||||
only French language is available beyond native Canadian English language.
|
||||
|
||||
French is only available after you are logged in.
|
||||
|
||||
Canadian English is the default language. To toggle another language,
|
||||
download the source of Speakup and untar it in your home directory. The
|
||||
following command should let you do this:
|
||||
|
||||
tar xvjf speakup-<version>.tar.bz2
|
||||
|
||||
where <version> is the version number of the application.
|
||||
|
||||
Next, change to the newly created directory, then into the tools/ directory, and
|
||||
run the script speakup_setlocale. You are asked the language that you want to
|
||||
use. Type the number associated to your language (e.g. fr for French) then press
|
||||
Enter. Needed files are copied in the i18n directory.
|
||||
|
||||
Note: the speakupconf must be installed on your system so that settings are saved.
|
||||
Otherwise, you will have an error: your language will be loaded but you will
|
||||
have to run the script again every time Speakup restarts.
|
||||
See section 16.1. for information about speakupconf.
|
||||
|
||||
You will have to repeat these steps for any change of locale, i.e. if you wish
|
||||
change the speakup's language or charset (iso-8859-15 ou UTF-8).
|
||||
|
||||
If you wish store the settings, note that at your next login, you will need to
|
||||
do:
|
||||
|
||||
speakup load
|
||||
|
||||
Alternatively, you can add the above line to your file
|
||||
~/.bashrc or ~/.bash_profile.
|
||||
|
||||
If your system administrator ran himself the script, all the users will be able
|
||||
to change from English to the language choosed by root and do directly
|
||||
speakupconf load (or add this to the ~/.bashrc or
|
||||
~/.bash_profile file). If there are several languages to handle, the
|
||||
administrator (or every user) will have to run the first steps until speakupconf
|
||||
save, choosing the appropriate language, in every user's home directory. Every
|
||||
user will then be able to do speakupconf load, Speakup will load his own settings.
|
||||
|
||||
14.3. No Support for Non-Western-European Languages
|
||||
|
||||
|
|
|
@ -380,5 +380,5 @@ This configuration option sets the maximum number of "watches" that are
|
|||
allowed for each user.
|
||||
Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes
|
||||
on a 64bit one.
|
||||
The current default value for max_user_watches is the 1/32 of the available
|
||||
low memory, divided for the "watch" cost in bytes.
|
||||
The current default value for max_user_watches is the 1/25 (4%) of the
|
||||
available low memory, divided for the "watch" cost in bytes.
|
||||
|
|
|
@ -983,11 +983,11 @@ that benefit from having their data cached, zone_reclaim_mode should be
|
|||
left disabled as the caching effect is likely to be more important than
|
||||
data locality.
|
||||
|
||||
zone_reclaim may be enabled if it's known that the workload is partitioned
|
||||
such that each partition fits within a NUMA node and that accessing remote
|
||||
memory would cause a measurable performance reduction. The page allocator
|
||||
will then reclaim easily reusable pages (those page cache pages that are
|
||||
currently not used) before allocating off node pages.
|
||||
Consider enabling one or more zone_reclaim mode bits if it's known that the
|
||||
workload is partitioned such that each partition fits within a NUMA node
|
||||
and that accessing remote memory would cause a measurable performance
|
||||
reduction. The page allocator will take additional actions before
|
||||
allocating off node pages.
|
||||
|
||||
Allowing zone reclaim to write out pages stops processes that are
|
||||
writing large amounts of data from dirtying pages on other nodes. Zone
|
||||
|
|
|
@ -284,6 +284,9 @@ The following sysctls are available for the XFS filesystem:
|
|||
removes unused preallocation from clean inodes and releases
|
||||
the unused space back to the free pool.
|
||||
|
||||
fs.xfs.speculative_cow_prealloc_lifetime
|
||||
This is an alias for speculative_prealloc_lifetime.
|
||||
|
||||
fs.xfs.error_level (Min: 0 Default: 3 Max: 11)
|
||||
A volume knob for error reporting when internal errors occur.
|
||||
This will generate detailed messages & backtraces for filesystem
|
||||
|
@ -356,12 +359,13 @@ The following sysctls are available for the XFS filesystem:
|
|||
Deprecated Sysctls
|
||||
==================
|
||||
|
||||
=========================== ================
|
||||
Name Removal Schedule
|
||||
=========================== ================
|
||||
fs.xfs.irix_sgid_inherit September 2025
|
||||
fs.xfs.irix_symlink_mode September 2025
|
||||
=========================== ================
|
||||
=========================================== ================
|
||||
Name Removal Schedule
|
||||
=========================================== ================
|
||||
fs.xfs.irix_sgid_inherit September 2025
|
||||
fs.xfs.irix_symlink_mode September 2025
|
||||
fs.xfs.speculative_cow_prealloc_lifetime September 2025
|
||||
=========================================== ================
|
||||
|
||||
|
||||
Removed Sysctls
|
||||
|
|
|
@ -128,7 +128,7 @@ it. The recommended placement is in the first 16KiB of RAM.
|
|||
|
||||
The boot loader must load a device tree image (dtb) into system ram
|
||||
at a 64bit aligned address and initialize it with the boot data. The
|
||||
dtb format is documented in Documentation/devicetree/booting-without-of.rst.
|
||||
dtb format is documented at https://www.devicetree.org/specifications/.
|
||||
The kernel will look for the dtb magic value of 0xd00dfeed at the dtb
|
||||
physical address to determine if a dtb has been passed instead of a
|
||||
tagged list.
|
||||
|
|
|
@ -33,7 +33,7 @@ SoC-specific documents
|
|||
|
||||
ixp4xx
|
||||
|
||||
marvel
|
||||
marvell
|
||||
microchip
|
||||
|
||||
netwinder
|
||||
|
|
|
@ -127,7 +127,7 @@ EBU Armada family
|
|||
- 88F6828 Armada 388
|
||||
|
||||
- Product infos: http://www.marvell.com/embedded-processors/armada-38x/
|
||||
- Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
|
||||
- Functional Spec: http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf
|
||||
|
||||
Core:
|
||||
ARM Cortex-A9
|
||||
|
@ -183,7 +183,10 @@ EBU Armada family ARMv8
|
|||
http://www.marvell.com/embedded-processors/armada-3700/
|
||||
|
||||
Product Brief:
|
||||
http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
|
||||
http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-product-brief-2016-01.pdf
|
||||
|
||||
Hardware Spec:
|
||||
http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf
|
||||
|
||||
Device tree files:
|
||||
arch/arm64/boot/dts/marvell/armada-37*
|
|
@ -182,8 +182,9 @@ API presented to device drivers
|
|||
|
||||
A :c:type:``struct blk_keyslot_manager`` should be set up by device drivers in
|
||||
the ``request_queue`` of the device. The device driver needs to call
|
||||
``blk_ksm_init`` on the ``blk_keyslot_manager``, which specifying the number of
|
||||
keyslots supported by the hardware.
|
||||
``blk_ksm_init`` (or its resource-managed variant ``devm_blk_ksm_init``) on the
|
||||
``blk_keyslot_manager``, while specifying the number of keyslots supported by
|
||||
the hardware.
|
||||
|
||||
The device driver also needs to tell the KSM how to actually manipulate the
|
||||
IE hardware in the device to do things like programming the crypto key into
|
||||
|
@ -202,10 +203,9 @@ needs each and every of its keyslots to be reprogrammed with the key it
|
|||
"should have" at the point in time when the function is called. This is useful
|
||||
e.g. if a device loses all its keys on runtime power down/up.
|
||||
|
||||
``blk_ksm_destroy`` should be called to free up all resources used by a keyslot
|
||||
manager upon ``blk_ksm_init``, once the ``blk_keyslot_manager`` is no longer
|
||||
needed.
|
||||
|
||||
If the driver used ``blk_ksm_init`` instead of ``devm_blk_ksm_init``, then
|
||||
``blk_ksm_destroy`` should be called to free up all resources used by a
|
||||
``blk_keyslot_manager`` once it is no longer needed.
|
||||
|
||||
Layered Devices
|
||||
===============
|
||||
|
|
|
@ -31,7 +31,7 @@ from load_config import loadConfig
|
|||
# -- General configuration ------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
needs_sphinx = '1.3'
|
||||
needs_sphinx = '1.7'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
|
@ -49,8 +49,7 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
|
|||
if major >= 3:
|
||||
sys.stderr.write('''WARNING: The kernel documentation build process
|
||||
support for Sphinx v3.0 and above is brand new. Be prepared for
|
||||
possible issues in the generated output.
|
||||
''')
|
||||
possible issues in the generated output.\n''')
|
||||
if (major > 3) or (minor > 0 or patch >= 2):
|
||||
# Sphinx c function parser is more pedantic with regards to type
|
||||
# checking. Due to that, having macros at c:function cause problems.
|
||||
|
@ -112,19 +111,12 @@ if major >= 3:
|
|||
|
||||
else:
|
||||
extensions.append('cdomain')
|
||||
if major == 1 and minor < 7:
|
||||
sys.stderr.write('WARNING: Sphinx 1.7 or greater will be required as of '
|
||||
'the 5.12 release\n')
|
||||
|
||||
# Ensure that autosectionlabel will produce unique names
|
||||
autosectionlabel_prefix_document = True
|
||||
autosectionlabel_maxdepth = 2
|
||||
|
||||
# The name of the math extension changed on Sphinx 1.4
|
||||
if (major == 1 and minor > 3) or (major > 1):
|
||||
extensions.append("sphinx.ext.imgmath")
|
||||
else:
|
||||
extensions.append("sphinx.ext.pngmath")
|
||||
extensions.append("sphinx.ext.imgmath")
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
@ -375,71 +367,9 @@ if cjk_cmd.find("Noto Sans CJK SC") >= 0:
|
|||
'''
|
||||
|
||||
# Fix reference escape troubles with Sphinx 1.4.x
|
||||
if major == 1 and minor > 3:
|
||||
if major == 1:
|
||||
latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
|
||||
|
||||
if major == 1 and minor <= 4:
|
||||
latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}'
|
||||
elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
|
||||
latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
|
||||
latex_elements['preamble'] += '\\fvset{fontsize=auto}\n'
|
||||
|
||||
# Customize notice background colors on Sphinx < 1.6:
|
||||
if major == 1 and minor < 6:
|
||||
latex_elements['preamble'] += '''
|
||||
\\usepackage{ifthen}
|
||||
|
||||
% Put notes in color and let them be inside a table
|
||||
\\definecolor{NoteColor}{RGB}{204,255,255}
|
||||
\\definecolor{WarningColor}{RGB}{255,204,204}
|
||||
\\definecolor{AttentionColor}{RGB}{255,255,204}
|
||||
\\definecolor{ImportantColor}{RGB}{192,255,204}
|
||||
\\definecolor{OtherColor}{RGB}{204,204,204}
|
||||
\\newlength{\\mynoticelength}
|
||||
\\makeatletter\\newenvironment{coloredbox}[1]{%
|
||||
\\setlength{\\fboxrule}{1pt}
|
||||
\\setlength{\\fboxsep}{7pt}
|
||||
\\setlength{\\mynoticelength}{\\linewidth}
|
||||
\\addtolength{\\mynoticelength}{-2\\fboxsep}
|
||||
\\addtolength{\\mynoticelength}{-2\\fboxrule}
|
||||
\\begin{lrbox}{\\@tempboxa}\\begin{minipage}{\\mynoticelength}}{\\end{minipage}\\end{lrbox}%
|
||||
\\ifthenelse%
|
||||
{\\equal{\\py@noticetype}{note}}%
|
||||
{\\colorbox{NoteColor}{\\usebox{\\@tempboxa}}}%
|
||||
{%
|
||||
\\ifthenelse%
|
||||
{\\equal{\\py@noticetype}{warning}}%
|
||||
{\\colorbox{WarningColor}{\\usebox{\\@tempboxa}}}%
|
||||
{%
|
||||
\\ifthenelse%
|
||||
{\\equal{\\py@noticetype}{attention}}%
|
||||
{\\colorbox{AttentionColor}{\\usebox{\\@tempboxa}}}%
|
||||
{%
|
||||
\\ifthenelse%
|
||||
{\\equal{\\py@noticetype}{important}}%
|
||||
{\\colorbox{ImportantColor}{\\usebox{\\@tempboxa}}}%
|
||||
{\\colorbox{OtherColor}{\\usebox{\\@tempboxa}}}%
|
||||
}%
|
||||
}%
|
||||
}%
|
||||
}\\makeatother
|
||||
|
||||
\\makeatletter
|
||||
\\renewenvironment{notice}[2]{%
|
||||
\\def\\py@noticetype{#1}
|
||||
\\begin{coloredbox}{#1}
|
||||
\\bf\\it
|
||||
\\par\\strong{#2}
|
||||
\\csname py@noticestart@#1\\endcsname
|
||||
}
|
||||
{
|
||||
\\csname py@noticeend@\\py@noticetype\\endcsname
|
||||
\\end{coloredbox}
|
||||
}
|
||||
\\makeatother
|
||||
|
||||
'''
|
||||
|
||||
# With Sphinx 1.6, it is possible to change the Bg color directly
|
||||
# by using:
|
||||
# \definecolor{sphinxnoteBgColor}{RGB}{204,255,255}
|
||||
|
|
|
@ -526,46 +526,6 @@ for the kernel vs the device.
|
|||
If you don't understand how cache line coherency works between a processor and
|
||||
an I/O device, you should not be using this part of the API.
|
||||
|
||||
::
|
||||
|
||||
void *
|
||||
dma_alloc_noncoherent(struct device *dev, size_t size,
|
||||
dma_addr_t *dma_handle, enum dma_data_direction dir,
|
||||
gfp_t gfp)
|
||||
|
||||
This routine allocates a region of <size> bytes of consistent memory. It
|
||||
returns a pointer to the allocated region (in the processor's virtual address
|
||||
space) or NULL if the allocation failed. The returned memory may or may not
|
||||
be in the kernel direct mapping. Drivers must not call virt_to_page on
|
||||
the returned memory region.
|
||||
|
||||
It also returns a <dma_handle> which may be cast to an unsigned integer the
|
||||
same width as the bus and given to the device as the DMA address base of
|
||||
the region.
|
||||
|
||||
The dir parameter specified if data is read and/or written by the device,
|
||||
see dma_map_single() for details.
|
||||
|
||||
The gfp parameter allows the caller to specify the ``GFP_`` flags (see
|
||||
kmalloc()) for the allocation, but rejects flags used to specify a memory
|
||||
zone such as GFP_DMA or GFP_HIGHMEM.
|
||||
|
||||
Before giving the memory to the device, dma_sync_single_for_device() needs
|
||||
to be called, and before reading memory written by the device,
|
||||
dma_sync_single_for_cpu(), just like for streaming DMA mappings that are
|
||||
reused.
|
||||
|
||||
::
|
||||
|
||||
void
|
||||
dma_free_noncoherent(struct device *dev, size_t size, void *cpu_addr,
|
||||
dma_addr_t dma_handle, enum dma_data_direction dir)
|
||||
|
||||
Free a region of memory previously allocated using dma_alloc_noncoherent().
|
||||
dev, size and dma_handle and dir must all be the same as those passed into
|
||||
dma_alloc_noncoherent(). cpu_addr must be the virtual address returned by
|
||||
dma_alloc_noncoherent().
|
||||
|
||||
::
|
||||
|
||||
struct page *
|
||||
|
@ -600,9 +560,29 @@ reused.
|
|||
dma_addr_t dma_handle, enum dma_data_direction dir)
|
||||
|
||||
Free a region of memory previously allocated using dma_alloc_pages().
|
||||
dev, size and dma_handle and dir must all be the same as those passed into
|
||||
dma_alloc_noncoherent(). page must be the pointer returned by
|
||||
dma_alloc_pages().
|
||||
dev, size, dma_handle and dir must all be the same as those passed into
|
||||
dma_alloc_pages(). page must be the pointer returned by dma_alloc_pages().
|
||||
|
||||
::
|
||||
|
||||
void *
|
||||
dma_alloc_noncoherent(struct device *dev, size_t size,
|
||||
dma_addr_t *dma_handle, enum dma_data_direction dir,
|
||||
gfp_t gfp)
|
||||
|
||||
This routine is a convenient wrapper around dma_alloc_pages that returns the
|
||||
kernel virtual address for the allocated memory instead of the page structure.
|
||||
|
||||
::
|
||||
|
||||
void
|
||||
dma_free_noncoherent(struct device *dev, size_t size, void *cpu_addr,
|
||||
dma_addr_t dma_handle, enum dma_data_direction dir)
|
||||
|
||||
Free a region of memory previously allocated using dma_alloc_noncoherent().
|
||||
dev, size, dma_handle and dir must all be the same as those passed into
|
||||
dma_alloc_noncoherent(). cpu_addr must be the virtual address returned by
|
||||
dma_alloc_noncoherent().
|
||||
|
||||
::
|
||||
|
||||
|
|
|
@ -19,11 +19,8 @@ User Space Memory Access
|
|||
Memory Allocation Controls
|
||||
==========================
|
||||
|
||||
Functions which need to allocate memory often use GFP flags to express
|
||||
how that memory should be allocated. The GFP acronym stands for "get
|
||||
free pages", the underlying memory allocation function. Not every GFP
|
||||
flag is allowed to every function which may allocate memory. Most
|
||||
users will want to use a plain ``GFP_KERNEL``.
|
||||
.. kernel-doc:: include/linux/gfp.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: include/linux/gfp.h
|
||||
:doc: Page mobility and placement hints
|
||||
|
|
|
@ -28,8 +28,8 @@ Symmetric Key Cipher Request Handle
|
|||
Single Block Cipher API
|
||||
-----------------------
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
.. kernel-doc:: include/crypto/internal/cipher.h
|
||||
:doc: Single Block Cipher API
|
||||
|
||||
.. kernel-doc:: include/linux/crypto.h
|
||||
.. kernel-doc:: include/crypto/internal/cipher.h
|
||||
:functions: crypto_alloc_cipher crypto_free_cipher crypto_has_cipher crypto_cipher_blocksize crypto_cipher_setkey crypto_cipher_encrypt_one crypto_cipher_decrypt_one
|
||||
|
|
|
@ -22,6 +22,7 @@ whole; patches welcome!
|
|||
ubsan
|
||||
kmemleak
|
||||
kcsan
|
||||
kfence
|
||||
gdb-kernel-debugging
|
||||
kgdb
|
||||
kselftest
|
||||
|
|
|
@ -147,16 +147,15 @@ negative values to distinguish between different kinds of inaccessible memory
|
|||
like redzones or freed memory (see mm/kasan/kasan.h).
|
||||
|
||||
In the report above the arrows point to the shadow byte 03, which means that
|
||||
the accessed address is partially accessible.
|
||||
|
||||
For tag-based KASAN this last report section shows the memory tags around the
|
||||
accessed address (see `Implementation details`_ section).
|
||||
the accessed address is partially accessible. For tag-based KASAN modes this
|
||||
last report section shows the memory tags around the accessed address
|
||||
(see the `Implementation details`_ section).
|
||||
|
||||
Boot parameters
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Hardware tag-based KASAN mode (see the section about different mode below) is
|
||||
intended for use in production as a security mitigation. Therefore it supports
|
||||
Hardware tag-based KASAN mode (see the section about various modes below) is
|
||||
intended for use in production as a security mitigation. Therefore, it supports
|
||||
boot parameters that allow to disable KASAN competely or otherwise control
|
||||
particular KASAN features.
|
||||
|
||||
|
@ -166,7 +165,8 @@ particular KASAN features.
|
|||
traces collection (default: ``on``).
|
||||
|
||||
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
|
||||
report or also panic the kernel (default: ``report``).
|
||||
report or also panic the kernel (default: ``report``). Note, that tag
|
||||
checking gets disabled after the first reported bug.
|
||||
|
||||
For developers
|
||||
~~~~~~~~~~~~~~
|
||||
|
@ -289,6 +289,16 @@ reserved to tag freed memory regions.
|
|||
Hardware tag-based KASAN currently only supports tagging of
|
||||
kmem_cache_alloc/kmalloc and page_alloc memory.
|
||||
|
||||
If the hardware doesn't support MTE (pre ARMv8.5), hardware tag-based KASAN
|
||||
won't be enabled. In this case all boot parameters are ignored.
|
||||
|
||||
Note, that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
|
||||
enabled. Even when kasan.mode=off is provided, or when the hardware doesn't
|
||||
support MTE (but supports TBI).
|
||||
|
||||
Hardware tag-based KASAN only reports the first found bug. After that MTE tag
|
||||
checking gets disabled.
|
||||
|
||||
What memory accesses are sanitised by KASAN?
|
||||
--------------------------------------------
|
||||
|
||||
|
@ -352,17 +362,17 @@ unmapped. This will require changes in arch-specific code.
|
|||
This allows ``VMAP_STACK`` support on x86, and can simplify support of
|
||||
architectures that do not have a fixed module region.
|
||||
|
||||
CONFIG_KASAN_KUNIT_TEST & CONFIG_TEST_KASAN_MODULE
|
||||
--------------------------------------------------
|
||||
CONFIG_KASAN_KUNIT_TEST and CONFIG_KASAN_MODULE_TEST
|
||||
----------------------------------------------------
|
||||
|
||||
KASAN tests consist on two parts:
|
||||
KASAN tests consist of two parts:
|
||||
|
||||
1. Tests that are integrated with the KUnit Test Framework. Enabled with
|
||||
``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
|
||||
automatically in a few different ways, see the instructions below.
|
||||
|
||||
2. Tests that are currently incompatible with KUnit. Enabled with
|
||||
``CONFIG_TEST_KASAN_MODULE`` and can only be run as a module. These tests can
|
||||
``CONFIG_KASAN_MODULE_TEST`` and can only be run as a module. These tests can
|
||||
only be verified manually, by loading the kernel module and inspecting the
|
||||
kernel log for KASAN reports.
|
||||
|
||||
|
|
|
@ -0,0 +1,298 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. Copyright (C) 2020, Google LLC.
|
||||
|
||||
Kernel Electric-Fence (KFENCE)
|
||||
==============================
|
||||
|
||||
Kernel Electric-Fence (KFENCE) is a low-overhead sampling-based memory safety
|
||||
error detector. KFENCE detects heap out-of-bounds access, use-after-free, and
|
||||
invalid-free errors.
|
||||
|
||||
KFENCE is designed to be enabled in production kernels, and has near zero
|
||||
performance overhead. Compared to KASAN, KFENCE trades performance for
|
||||
precision. The main motivation behind KFENCE's design, is that with enough
|
||||
total uptime KFENCE will detect bugs in code paths not typically exercised by
|
||||
non-production test workloads. One way to quickly achieve a large enough total
|
||||
uptime is when the tool is deployed across a large fleet of machines.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
To enable KFENCE, configure the kernel with::
|
||||
|
||||
CONFIG_KFENCE=y
|
||||
|
||||
To build a kernel with KFENCE support, but disabled by default (to enable, set
|
||||
``kfence.sample_interval`` to non-zero value), configure the kernel with::
|
||||
|
||||
CONFIG_KFENCE=y
|
||||
CONFIG_KFENCE_SAMPLE_INTERVAL=0
|
||||
|
||||
KFENCE provides several other configuration options to customize behaviour (see
|
||||
the respective help text in ``lib/Kconfig.kfence`` for more info).
|
||||
|
||||
Tuning performance
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The most important parameter is KFENCE's sample interval, which can be set via
|
||||
the kernel boot parameter ``kfence.sample_interval`` in milliseconds. The
|
||||
sample interval determines the frequency with which heap allocations will be
|
||||
guarded by KFENCE. The default is configurable via the Kconfig option
|
||||
``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0``
|
||||
disables KFENCE.
|
||||
|
||||
The KFENCE memory pool is of fixed size, and if the pool is exhausted, no
|
||||
further KFENCE allocations occur. With ``CONFIG_KFENCE_NUM_OBJECTS`` (default
|
||||
255), the number of available guarded objects can be controlled. Each object
|
||||
requires 2 pages, one for the object itself and the other one used as a guard
|
||||
page; object pages are interleaved with guard pages, and every object page is
|
||||
therefore surrounded by two guard pages.
|
||||
|
||||
The total memory dedicated to the KFENCE memory pool can be computed as::
|
||||
|
||||
( #objects + 1 ) * 2 * PAGE_SIZE
|
||||
|
||||
Using the default config, and assuming a page size of 4 KiB, results in
|
||||
dedicating 2 MiB to the KFENCE memory pool.
|
||||
|
||||
Note: On architectures that support huge pages, KFENCE will ensure that the
|
||||
pool is using pages of size ``PAGE_SIZE``. This will result in additional page
|
||||
tables being allocated.
|
||||
|
||||
Error reports
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
A typical out-of-bounds access looks like this::
|
||||
|
||||
==================================================================
|
||||
BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa3/0x22b
|
||||
|
||||
Out-of-bounds read at 0xffffffffb672efff (1B left of kfence-#17):
|
||||
test_out_of_bounds_read+0xa3/0x22b
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#17 [0xffffffffb672f000-0xffffffffb672f01f, size=32, cache=kmalloc-32] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
test_out_of_bounds_read+0x98/0x22b
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 107 Comm: kunit_try_catch Not tainted 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
==================================================================
|
||||
|
||||
The header of the report provides a short summary of the function involved in
|
||||
the access. It is followed by more detailed information about the access and
|
||||
its origin. Note that, real kernel addresses are only shown when using the
|
||||
kernel command line option ``no_hash_pointers``.
|
||||
|
||||
Use-after-free accesses are reported as::
|
||||
|
||||
==================================================================
|
||||
BUG: KFENCE: use-after-free read in test_use_after_free_read+0xb3/0x143
|
||||
|
||||
Use-after-free read at 0xffffffffb673dfe0 (in kfence-#24):
|
||||
test_use_after_free_read+0xb3/0x143
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#24 [0xffffffffb673dfe0-0xffffffffb673dfff, size=32, cache=kmalloc-32] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
test_use_after_free_read+0x76/0x143
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
freed by task 507:
|
||||
test_use_after_free_read+0xa8/0x143
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 109 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
==================================================================
|
||||
|
||||
KFENCE also reports on invalid frees, such as double-frees::
|
||||
|
||||
==================================================================
|
||||
BUG: KFENCE: invalid free in test_double_free+0xdc/0x171
|
||||
|
||||
Invalid free of 0xffffffffb6741000:
|
||||
test_double_free+0xdc/0x171
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#26 [0xffffffffb6741000-0xffffffffb674101f, size=32, cache=kmalloc-32] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
test_double_free+0x76/0x171
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
freed by task 507:
|
||||
test_double_free+0xa8/0x171
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 111 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
==================================================================
|
||||
|
||||
KFENCE also uses pattern-based redzones on the other side of an object's guard
|
||||
page, to detect out-of-bounds writes on the unprotected side of the object.
|
||||
These are reported on frees::
|
||||
|
||||
==================================================================
|
||||
BUG: KFENCE: memory corruption in test_kmalloc_aligned_oob_write+0xef/0x184
|
||||
|
||||
Corrupted memory at 0xffffffffb6797ff9 [ 0xac . . . . . . ] (in kfence-#69):
|
||||
test_kmalloc_aligned_oob_write+0xef/0x184
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#69 [0xffffffffb6797fb0-0xffffffffb6797ff8, size=73, cache=kmalloc-96] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
test_kmalloc_aligned_oob_write+0x57/0x184
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 120 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
==================================================================
|
||||
|
||||
For such errors, the address where the corruption occurred as well as the
|
||||
invalidly written bytes (offset from the address) are shown; in this
|
||||
representation, '.' denote untouched bytes. In the example above ``0xac`` is
|
||||
the value written to the invalid address at offset 0, and the remaining '.'
|
||||
denote that no following bytes have been touched. Note that, real values are
|
||||
only shown if the kernel was booted with ``no_hash_pointers``; to avoid
|
||||
information disclosure otherwise, '!' is used instead to denote invalidly
|
||||
written bytes.
|
||||
|
||||
And finally, KFENCE may also report on invalid accesses to any protected page
|
||||
where it was not possible to determine an associated object, e.g. if adjacent
|
||||
object pages had not yet been allocated::
|
||||
|
||||
==================================================================
|
||||
BUG: KFENCE: invalid read in test_invalid_access+0x26/0xe0
|
||||
|
||||
Invalid read at 0xffffffffb670b00a:
|
||||
test_invalid_access+0x26/0xe0
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 124 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
==================================================================
|
||||
|
||||
DebugFS interface
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some debugging information is exposed via debugfs:
|
||||
|
||||
* The file ``/sys/kernel/debug/kfence/stats`` provides runtime statistics.
|
||||
|
||||
* The file ``/sys/kernel/debug/kfence/objects`` provides a list of objects
|
||||
allocated via KFENCE, including those already freed but protected.
|
||||
|
||||
Implementation Details
|
||||
----------------------
|
||||
|
||||
Guarded allocations are set up based on the sample interval. After expiration
|
||||
of the sample interval, the next allocation through the main allocator (SLAB or
|
||||
SLUB) returns a guarded allocation from the KFENCE object pool (allocation
|
||||
sizes up to PAGE_SIZE are supported). At this point, the timer is reset, and
|
||||
the next allocation is set up after the expiration of the interval. To "gate" a
|
||||
KFENCE allocation through the main allocator's fast-path without overhead,
|
||||
KFENCE relies on static branches via the static keys infrastructure. The static
|
||||
branch is toggled to redirect the allocation to KFENCE.
|
||||
|
||||
KFENCE objects each reside on a dedicated page, at either the left or right
|
||||
page boundaries selected at random. The pages to the left and right of the
|
||||
object page are "guard pages", whose attributes are changed to a protected
|
||||
state, and cause page faults on any attempted access. Such page faults are then
|
||||
intercepted by KFENCE, which handles the fault gracefully by reporting an
|
||||
out-of-bounds access, and marking the page as accessible so that the faulting
|
||||
code can (wrongly) continue executing (set ``panic_on_warn`` to panic instead).
|
||||
|
||||
To detect out-of-bounds writes to memory within the object's page itself,
|
||||
KFENCE also uses pattern-based redzones. For each object page, a redzone is set
|
||||
up for all non-object memory. For typical alignments, the redzone is only
|
||||
required on the unguarded side of an object. Because KFENCE must honor the
|
||||
cache's requested alignment, special alignments may result in unprotected gaps
|
||||
on either side of an object, all of which are redzoned.
|
||||
|
||||
The following figure illustrates the page layout::
|
||||
|
||||
---+-----------+-----------+-----------+-----------+-----------+---
|
||||
| xxxxxxxxx | O : | xxxxxxxxx | : O | xxxxxxxxx |
|
||||
| xxxxxxxxx | B : | xxxxxxxxx | : B | xxxxxxxxx |
|
||||
| x GUARD x | J : RED- | x GUARD x | RED- : J | x GUARD x |
|
||||
| xxxxxxxxx | E : ZONE | xxxxxxxxx | ZONE : E | xxxxxxxxx |
|
||||
| xxxxxxxxx | C : | xxxxxxxxx | : C | xxxxxxxxx |
|
||||
| xxxxxxxxx | T : | xxxxxxxxx | : T | xxxxxxxxx |
|
||||
---+-----------+-----------+-----------+-----------+-----------+---
|
||||
|
||||
Upon deallocation of a KFENCE object, the object's page is again protected and
|
||||
the object is marked as freed. Any further access to the object causes a fault
|
||||
and KFENCE reports a use-after-free access. Freed objects are inserted at the
|
||||
tail of KFENCE's freelist, so that the least recently freed objects are reused
|
||||
first, and the chances of detecting use-after-frees of recently freed objects
|
||||
is increased.
|
||||
|
||||
Interface
|
||||
---------
|
||||
|
||||
The following describes the functions which are used by allocators as well as
|
||||
page handling code to set up and deal with KFENCE allocations.
|
||||
|
||||
.. kernel-doc:: include/linux/kfence.h
|
||||
:functions: is_kfence_address
|
||||
kfence_shutdown_cache
|
||||
kfence_alloc kfence_free __kfence_free
|
||||
kfence_ksize kfence_object_start
|
||||
kfence_handle_page_fault
|
||||
|
||||
Related Tools
|
||||
-------------
|
||||
|
||||
In userspace, a similar approach is taken by `GWP-ASan
|
||||
<http://llvm.org/docs/GwpAsan.html>`_. GWP-ASan also relies on guard pages and
|
||||
a sampling strategy to detect memory unsafety bugs at scale. KFENCE's design is
|
||||
directly influenced by GWP-ASan, and can be seen as its kernel sibling. Another
|
||||
similar but non-sampling approach, that also inspired the name "KFENCE", can be
|
||||
found in the userspace `Electric Fence Malloc Debugger
|
||||
<https://linux.die.net/man/3/efence>`_.
|
||||
|
||||
In the kernel, several tools exist to debug memory access errors, and in
|
||||
particular KASAN can detect all bug classes that KFENCE can detect. While KASAN
|
||||
is more precise, relying on compiler instrumentation, this comes at a
|
||||
performance cost.
|
||||
|
||||
It is worth highlighting that KASAN and KFENCE are complementary, with
|
||||
different target environments. For instance, KASAN is the better debugging-aid,
|
||||
where test cases or reproducers exists: due to the lower chance to detect the
|
||||
error, it would require more effort using KFENCE to debug. Deployments at scale
|
||||
that cannot afford to enable KASAN, however, would benefit from using KFENCE to
|
||||
discover bugs due to code paths not exercised by test cases or fuzzers.
|
|
@ -13,6 +13,7 @@ KUnit - Unit Testing for the Linux Kernel
|
|||
api/index
|
||||
style
|
||||
faq
|
||||
tips
|
||||
|
||||
What is KUnit?
|
||||
==============
|
||||
|
@ -88,6 +89,7 @@ How do I use it?
|
|||
================
|
||||
|
||||
* :doc:`start` - for new users of KUnit
|
||||
* :doc:`tips` - for short examples of best practices
|
||||
* :doc:`usage` - for a more detailed explanation of KUnit features
|
||||
* :doc:`api/index` - for the list of KUnit APIs used for testing
|
||||
* :doc:`kunit-tool` - for more information on the kunit_tool helper script
|
||||
|
|
|
@ -196,8 +196,9 @@ Now add the following to ``drivers/misc/Kconfig``:
|
|||
.. code-block:: kconfig
|
||||
|
||||
config MISC_EXAMPLE_TEST
|
||||
bool "Test for my example"
|
||||
tristate "Test for my example" if !KUNIT_ALL_TESTS
|
||||
depends on MISC_EXAMPLE && KUNIT=y
|
||||
default KUNIT_ALL_TESTS
|
||||
|
||||
and the following to ``drivers/misc/Makefile``:
|
||||
|
||||
|
@ -233,5 +234,7 @@ Congrats! You just wrote your first KUnit test!
|
|||
|
||||
Next Steps
|
||||
==========
|
||||
* Check out the :doc:`usage` page for a more
|
||||
* Check out the :doc:`tips` page for tips on
|
||||
writing idiomatic KUnit tests.
|
||||
* Optional: see the :doc:`usage` page for a more
|
||||
in-depth explanation of KUnit.
|
||||
|
|
|
@ -0,0 +1,115 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
============================
|
||||
Tips For Writing KUnit Tests
|
||||
============================
|
||||
|
||||
Exiting early on failed expectations
|
||||
------------------------------------
|
||||
|
||||
``KUNIT_EXPECT_EQ`` and friends will mark the test as failed and continue
|
||||
execution. In some cases, it's unsafe to continue and you can use the
|
||||
``KUNIT_ASSERT`` variant to exit on failure.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
void example_test_user_alloc_function(struct kunit *test)
|
||||
{
|
||||
void *object = alloc_some_object_for_me();
|
||||
|
||||
/* Make sure we got a valid pointer back. */
|
||||
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, object);
|
||||
do_something_with_object(object);
|
||||
}
|
||||
|
||||
Allocating memory
|
||||
-----------------
|
||||
|
||||
Where you would use ``kzalloc``, you should prefer ``kunit_kzalloc`` instead.
|
||||
KUnit will ensure the memory is freed once the test completes.
|
||||
|
||||
This is particularly useful since it lets you use the ``KUNIT_ASSERT_EQ``
|
||||
macros to exit early from a test without having to worry about remembering to
|
||||
call ``kfree``.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
void example_test_allocation(struct kunit *test)
|
||||
{
|
||||
char *buffer = kunit_kzalloc(test, 16, GFP_KERNEL);
|
||||
/* Ensure allocation succeeded. */
|
||||
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buffer);
|
||||
|
||||
KUNIT_ASSERT_STREQ(test, buffer, "");
|
||||
}
|
||||
|
||||
|
||||
Testing static functions
|
||||
------------------------
|
||||
|
||||
If you don't want to expose functions or variables just for testing, one option
|
||||
is to conditionally ``#include`` the test file at the end of your .c file, e.g.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* In my_file.c */
|
||||
|
||||
static int do_interesting_thing();
|
||||
|
||||
#ifdef CONFIG_MY_KUNIT_TEST
|
||||
#include "my_kunit_test.c"
|
||||
#endif
|
||||
|
||||
Injecting test-only code
|
||||
------------------------
|
||||
|
||||
Similarly to the above, it can be useful to add test-specific logic.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* In my_file.h */
|
||||
|
||||
#ifdef CONFIG_MY_KUNIT_TEST
|
||||
/* Defined in my_kunit_test.c */
|
||||
void test_only_hook(void);
|
||||
#else
|
||||
void test_only_hook(void) { }
|
||||
#endif
|
||||
|
||||
TODO(dlatypov@google.com): add an example of using ``current->kunit_test`` in
|
||||
such a hook when it's not only updated for ``CONFIG_KASAN=y``.
|
||||
|
||||
Customizing error messages
|
||||
--------------------------
|
||||
|
||||
Each of the ``KUNIT_EXPECT`` and ``KUNIT_ASSERT`` macros have a ``_MSG`` variant.
|
||||
These take a format string and arguments to provide additional context to the automatically generated error messages.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
char some_str[41];
|
||||
generate_sha1_hex_string(some_str);
|
||||
|
||||
/* Before. Not easy to tell why the test failed. */
|
||||
KUNIT_EXPECT_EQ(test, strlen(some_str), 40);
|
||||
|
||||
/* After. Now we see the offending string. */
|
||||
KUNIT_EXPECT_EQ_MSG(test, strlen(some_str), 40, "some_str='%s'", some_str);
|
||||
|
||||
Alternatively, one can take full control over the error message by using ``KUNIT_FAIL()``, e.g.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* Before */
|
||||
KUNIT_EXPECT_EQ(test, some_setup_function(), 0);
|
||||
|
||||
/* After: full control over the failure message. */
|
||||
if (some_setup_function())
|
||||
KUNIT_FAIL(test, "Failed to setup thing for testing");
|
||||
|
||||
Next Steps
|
||||
==========
|
||||
* Optional: see the :doc:`usage` page for a more
|
||||
in-depth explanation of KUnit.
|
|
@ -10,7 +10,7 @@ DT_SCHEMA_MIN_VERSION = 2020.8.1
|
|||
PHONY += check_dtschema_version
|
||||
check_dtschema_version:
|
||||
@{ echo $(DT_SCHEMA_MIN_VERSION); \
|
||||
$(DT_DOC_CHECKER) --version 2>/dev/null || echo 0; } | sort -VC || \
|
||||
$(DT_DOC_CHECKER) --version 2>/dev/null || echo 0; } | sort -Vc >/dev/null || \
|
||||
{ echo "ERROR: dtschema minimum version is v$(DT_SCHEMA_MIN_VERSION)" >&2; false; }
|
||||
|
||||
quiet_cmd_extract_ex = DTEX $@
|
||||
|
@ -78,10 +78,10 @@ $(obj)/processed-schema.json: $(DT_SCHEMA_FILES) check_dtschema_version FORCE
|
|||
|
||||
endif
|
||||
|
||||
extra-$(CHECK_DT_BINDING) += processed-schema-examples.json
|
||||
extra-$(CHECK_DTBS) += processed-schema.json
|
||||
extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
|
||||
extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES))
|
||||
always-$(CHECK_DT_BINDING) += processed-schema-examples.json
|
||||
always-$(CHECK_DTBS) += processed-schema.json
|
||||
always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
|
||||
always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES))
|
||||
|
||||
# Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of
|
||||
# build artifacts here before they are processed by scripts/Makefile.clean
|
||||
|
|
|
@ -91,7 +91,8 @@ SHDWC SAMA5D2-Compatible Shutdown Controller
|
|||
1) shdwc node
|
||||
|
||||
required properties:
|
||||
- compatible: should be "atmel,sama5d2-shdwc" or "microchip,sam9x60-shdwc".
|
||||
- compatible: should be "atmel,sama5d2-shdwc", "microchip,sam9x60-shdwc" or
|
||||
"microchip,sama7g5-shdwc"
|
||||
- reg: should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
- #address-cells: should be one. The cell is the wake-up input index.
|
||||
|
@ -103,7 +104,7 @@ optional properties:
|
|||
microseconds. It's usually a board-related property.
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up.
|
||||
|
||||
optional microchip,sam9x60-shdwc properties:
|
||||
optional microchip,sam9x60-shdwc or microchip,sama7g5-shdwc properties:
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
The node contains child nodes for each wake-up input that the platform uses.
|
||||
|
|
|
@ -34,9 +34,12 @@ its hardware characteristcs.
|
|||
Program Flow Trace Macrocell:
|
||||
"arm,coresight-etm3x", "arm,primecell";
|
||||
|
||||
- Embedded Trace Macrocell (version 4.x):
|
||||
- Embedded Trace Macrocell (version 4.x), with memory mapped access.
|
||||
"arm,coresight-etm4x", "arm,primecell";
|
||||
|
||||
- Embedded Trace Macrocell (version 4.x), with system register access only.
|
||||
"arm,coresight-etm4x-sysreg";
|
||||
|
||||
- Coresight programmable Replicator :
|
||||
"arm,coresight-dynamic-replicator", "arm,primecell";
|
||||
|
||||
|
|
|
@ -80,6 +80,11 @@ Required properties:
|
|||
|
||||
- offset: offset address inside the syscon block
|
||||
|
||||
Optional properties:
|
||||
|
||||
- marvell,pwm-offset: offset address of PWM duration control registers inside
|
||||
the syscon block
|
||||
|
||||
Example:
|
||||
ap_syscon: system-controller@6f4000 {
|
||||
compatible = "syscon", "simple-mfd";
|
||||
|
@ -101,6 +106,9 @@ ap_syscon: system-controller@6f4000 {
|
|||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-ranges = <&ap_pinctrl 0 0 19>;
|
||||
marvell,pwm-offset = <0x10c0>;
|
||||
#pwm-cells = <2>;
|
||||
clocks = <&ap_clk 3>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
@ -132,6 +132,7 @@ properties:
|
|||
- enum:
|
||||
- friendlyarm,nanopc-t4
|
||||
- friendlyarm,nanopi-m4
|
||||
- friendlyarm,nanopi-m4b
|
||||
- friendlyarm,nanopi-neo4
|
||||
- const: rockchip,rk3399
|
||||
|
||||
|
|
|
@ -30,8 +30,8 @@ properties:
|
|||
Interrupts can be used to notify the completion of cache operations.
|
||||
The number of interrupts should match to the number of CPU cores.
|
||||
The specified interrupts correspond to CPU0, CPU1, ... in this order.
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
cache-unified: true
|
||||
|
||||
|
|
|
@ -61,6 +61,7 @@ properties:
|
|||
maxItems: 8
|
||||
|
||||
calxeda,sgpio-gpio:
|
||||
maxItems: 3
|
||||
description: |
|
||||
phandle-gpio bank, bit offset, and default on or off, which indicates
|
||||
that the driver supports SGPIO indicator lights using the indicated
|
||||
|
|
|
@ -0,0 +1,77 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/auxdisplay/holtek,ht16k33.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Holtek HT16K33 RAM mapping 16*8 LED controller with keyscan
|
||||
|
||||
maintainers:
|
||||
- Robin van der Gracht <robin@protonic.nl>
|
||||
|
||||
allOf:
|
||||
- $ref: "/schemas/input/matrix-keymap.yaml#"
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: holtek,ht16k33
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
refresh-rate-hz:
|
||||
maxItems: 1
|
||||
description: Display update interval in Hertz
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
debounce-delay-ms:
|
||||
maxItems: 1
|
||||
description: Debouncing interval time in milliseconds
|
||||
|
||||
linux,keymap: true
|
||||
|
||||
linux,no-autorepeat:
|
||||
description: Disable keyrepeat
|
||||
|
||||
default-brightness-level:
|
||||
minimum: 1
|
||||
maximum: 16
|
||||
default: 16
|
||||
description: Initial brightness level
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- refresh-rate-hz
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/input/input.h>
|
||||
i2c1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ht16k33: ht16k33@70 {
|
||||
compatible = "holtek,ht16k33";
|
||||
reg = <0x70>;
|
||||
refresh-rate-hz = <20>;
|
||||
interrupt-parent = <&gpio4>;
|
||||
interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
|
||||
debounce-delay-ms = <50>;
|
||||
linux,keymap = <MATRIX_KEY(2, 0, KEY_F6)>,
|
||||
<MATRIX_KEY(3, 0, KEY_F8)>,
|
||||
<MATRIX_KEY(4, 0, KEY_F10)>,
|
||||
<MATRIX_KEY(5, 0, KEY_F4)>,
|
||||
<MATRIX_KEY(6, 0, KEY_F2)>,
|
||||
<MATRIX_KEY(2, 1, KEY_F5)>,
|
||||
<MATRIX_KEY(3, 1, KEY_F7)>,
|
||||
<MATRIX_KEY(4, 1, KEY_F9)>,
|
||||
<MATRIX_KEY(5, 1, KEY_F3)>,
|
||||
<MATRIX_KEY(6, 1, KEY_F1)>;
|
||||
};
|
||||
};
|
|
@ -20,6 +20,7 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- adi,axi-clkgen-2.00.a
|
||||
- adi,zynqmp-axi-clkgen-2.00.a
|
||||
|
||||
clocks:
|
||||
description:
|
||||
|
|
|
@ -41,6 +41,8 @@ properties:
|
|||
- allwinner,sun50i-h5-ccu
|
||||
- allwinner,sun50i-h6-ccu
|
||||
- allwinner,sun50i-h6-r-ccu
|
||||
- allwinner,sun50i-h616-ccu
|
||||
- allwinner,sun50i-h616-r-ccu
|
||||
- allwinner,suniv-f1c100s-ccu
|
||||
- nextthing,gr8-ccu
|
||||
|
||||
|
@ -82,6 +84,7 @@ if:
|
|||
- allwinner,sun50i-a64-r-ccu
|
||||
- allwinner,sun50i-a100-r-ccu
|
||||
- allwinner,sun50i-h6-r-ccu
|
||||
- allwinner,sun50i-h616-r-ccu
|
||||
|
||||
then:
|
||||
properties:
|
||||
|
@ -100,6 +103,7 @@ else:
|
|||
enum:
|
||||
- allwinner,sun50i-a100-ccu
|
||||
- allwinner,sun50i-h6-ccu
|
||||
- allwinner,sun50i-h616-ccu
|
||||
|
||||
then:
|
||||
properties:
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# SPDX-License-Identifier: GPL-2.0+
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-usb-clocks.yaml#
|
||||
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-usb-clks.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Allwinner A80 USB Clock Controller Device Tree Bindings
|
||||
|
@ -18,7 +18,7 @@ properties:
|
|||
const: 1
|
||||
|
||||
compatible:
|
||||
const: allwinner,sun9i-a80-usb-clocks
|
||||
const: allwinner,sun9i-a80-usb-clks
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
|
@ -66,8 +66,8 @@ properties:
|
|||
- arm,syscon-icst525-integratorcp-cm-mem
|
||||
- arm,integrator-cm-auxosc
|
||||
- arm,versatile-cm-auxosc
|
||||
- arm,impd-vco1
|
||||
- arm,impd-vco2
|
||||
- arm,impd1-vco1
|
||||
- arm,impd1-vco2
|
||||
|
||||
clocks:
|
||||
description: Parent clock for the ICST VCO
|
||||
|
|
|
@ -22,6 +22,7 @@ properties:
|
|||
const: canaan,k210-clk
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
description:
|
||||
Phandle of the SoC 26MHz fixed-rate oscillator clock.
|
||||
|
||||
|
|
|
@ -1,55 +0,0 @@
|
|||
* Clock and reset bindings for CSR atlas7
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "sirf,atlas7-car"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
- #reset-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell.
|
||||
The ID list atlas7_clks defined in drivers/clk/sirf/clk-atlas7.c
|
||||
|
||||
The reset consumer should specify the desired reset by having the reset
|
||||
ID in its "reset" phandle cell.
|
||||
The ID list atlas7_reset_unit defined in drivers/clk/sirf/clk-atlas7.c
|
||||
|
||||
Examples: Clock and reset controller node:
|
||||
|
||||
car: clock-controller@18620000 {
|
||||
compatible = "sirf,atlas7-car";
|
||||
reg = <0x18620000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Examples: Consumers using clock or reset:
|
||||
|
||||
timer@10dc0000 {
|
||||
compatible = "sirf,macro-tick";
|
||||
reg = <0x10dc0000 0x1000>;
|
||||
clocks = <&car 54>;
|
||||
interrupts = <0 0 0>,
|
||||
<0 1 0>,
|
||||
<0 2 0>,
|
||||
<0 49 0>,
|
||||
<0 50 0>,
|
||||
<0 51 0>;
|
||||
};
|
||||
|
||||
uart1: uart@18020000 {
|
||||
cell-index = <1>;
|
||||
compatible = "sirf,macro-uart";
|
||||
reg = <0x18020000 0x1000>;
|
||||
clocks = <&clks 95>;
|
||||
interrupts = <0 18 0>;
|
||||
fifosize = <32>;
|
||||
};
|
||||
|
||||
vpp@13110000 {
|
||||
compatible = "sirf,prima2-vpp";
|
||||
reg = <0x13110000 0x10000>;
|
||||
interrupts = <0 31 0>;
|
||||
clocks = <&car 85>;
|
||||
resets = <&car 29>;
|
||||
};
|
|
@ -59,6 +59,12 @@ properties:
|
|||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
idt,xtal-load-femtofarads:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 9000
|
||||
maximum: 22760
|
||||
description: Optional load capacitor for XTAL1 and XTAL2
|
||||
|
||||
patternProperties:
|
||||
"^OUT[1-4]$":
|
||||
type: object
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Clock bindings for Freescale i.MX27
|
||||
|
||||
maintainers:
|
||||
- Fabio Estevam <fabio.estevam@nxp.com>
|
||||
- Fabio Estevam <festevam@gmail.com>
|
||||
|
||||
description: |
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Clock bindings for Freescale i.MX31
|
||||
|
||||
maintainers:
|
||||
- Fabio Estevam <fabio.estevam@nxp.com>
|
||||
- Fabio Estevam <festevam@gmail.com>
|
||||
|
||||
description: |
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Clock bindings for Freescale i.MX5
|
||||
|
||||
maintainers:
|
||||
- Fabio Estevam <fabio.estevam@nxp.com>
|
||||
- Fabio Estevam <festevam@gmail.com>
|
||||
|
||||
description: |
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
|
|
|
@ -0,0 +1,46 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/intel,easic-n5x.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Intel SoCFPGA eASIC N5X platform clock controller binding
|
||||
|
||||
maintainers:
|
||||
- Dinh Nguyen <dinguyen@kernel.org>
|
||||
|
||||
description:
|
||||
The Intel eASIC N5X Clock controller is an integrated clock controller, which
|
||||
generates and supplies to all modules.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: intel,easic-n5x-clkmgr
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
# Clock controller node:
|
||||
- |
|
||||
clkmgr: clock-controller@ffd10000 {
|
||||
compatible = "intel,easic-n5x-clkmgr";
|
||||
reg = <0xffd10000 0x1000>;
|
||||
clocks = <&osc1>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -0,0 +1,46 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/mstar,msc313-mpll.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MStar/Sigmastar MSC313 MPLL
|
||||
|
||||
maintainers:
|
||||
- Daniel Palmer <daniel@thingy.jp>
|
||||
|
||||
description: |
|
||||
The MStar/SigmaStar MSC313 and later ARMv7 chips have an MPLL block that
|
||||
takes the external xtal input and multiplies it to create a high
|
||||
frequency clock and divides that down into a number of clocks that
|
||||
peripherals use.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: mstar,msc313-mpll
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- clocks
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
mpll@206000 {
|
||||
compatible = "mstar,msc313-mpll";
|
||||
reg = <0x206000 0x200>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&xtal>;
|
||||
};
|
|
@ -1,73 +0,0 @@
|
|||
* Clock bindings for CSR SiRFprimaII
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "sirf,prima2-clkc"
|
||||
- reg: Address and length of the register set
|
||||
- interrupts: Should contain clock controller interrupt
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. The following is a full list of prima2
|
||||
clocks and IDs.
|
||||
|
||||
Clock ID
|
||||
---------------------------
|
||||
rtc 0
|
||||
osc 1
|
||||
pll1 2
|
||||
pll2 3
|
||||
pll3 4
|
||||
mem 5
|
||||
sys 6
|
||||
security 7
|
||||
dsp 8
|
||||
gps 9
|
||||
mf 10
|
||||
io 11
|
||||
cpu 12
|
||||
uart0 13
|
||||
uart1 14
|
||||
uart2 15
|
||||
tsc 16
|
||||
i2c0 17
|
||||
i2c1 18
|
||||
spi0 19
|
||||
spi1 20
|
||||
pwmc 21
|
||||
efuse 22
|
||||
pulse 23
|
||||
dmac0 24
|
||||
dmac1 25
|
||||
nand 26
|
||||
audio 27
|
||||
usp0 28
|
||||
usp1 29
|
||||
usp2 30
|
||||
vip 31
|
||||
gfx 32
|
||||
mm 33
|
||||
lcd 34
|
||||
vpp 35
|
||||
mmc01 36
|
||||
mmc23 37
|
||||
mmc45 38
|
||||
usbpll 39
|
||||
usb0 40
|
||||
usb1 41
|
||||
|
||||
Examples:
|
||||
|
||||
clks: clock-controller@88000000 {
|
||||
compatible = "sirf,prima2-clkc";
|
||||
reg = <0x88000000 0x1000>;
|
||||
interrupts = <3>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
i2c0: i2c@b00e0000 {
|
||||
cell-index = <0>;
|
||||
compatible = "sirf,prima2-i2c";
|
||||
reg = <0xb00e0000 0x10000>;
|
||||
interrupts = <24>;
|
||||
clocks = <&clks 17>;
|
||||
};
|
|
@ -0,0 +1,51 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,a7pll.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm A7 PLL Binding
|
||||
|
||||
maintainers:
|
||||
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||
|
||||
description:
|
||||
The A7 PLL on the Qualcomm platforms like SDX55 is used to provide high
|
||||
frequency clock to the CPU.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sdx55-a7pll
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 0
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: board XO clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
a7pll: clock@17808000 {
|
||||
compatible = "qcom,sdx55-a7pll";
|
||||
reg = <0x17808000 0x1000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>;
|
||||
clock-names = "bi_tcxo";
|
||||
#clock-cells = <0>;
|
||||
};
|
|
@ -0,0 +1,92 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc7280.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller Binding for SC7280
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <tdas@codeaurora.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module which supports the clocks, resets and
|
||||
power domains on SC7280.
|
||||
|
||||
See also:
|
||||
- dt-bindings/clock/qcom,gcc-sc7280.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,gcc-sc7280
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Board active XO source
|
||||
- description: Sleep clock source
|
||||
- description: PCIE-0 pipe clock source
|
||||
- description: PCIE-1 pipe clock source
|
||||
- description: USF phy rx symbol 0 clock source
|
||||
- description: USF phy rx symbol 1 clock source
|
||||
- description: USF phy tx symbol 0 clock source
|
||||
- description: USB30 phy wrapper pipe clock source
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
- const: bi_tcxo_ao
|
||||
- const: sleep_clk
|
||||
- const: pcie_0_pipe_clk
|
||||
- const: pcie_1_pipe_clk
|
||||
- const: ufs_phy_rx_symbol_0_clk
|
||||
- const: ufs_phy_rx_symbol_1_clk
|
||||
- const: ufs_phy_tx_symbol_0_clk
|
||||
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@100000 {
|
||||
compatible = "qcom,gcc-sc7280";
|
||||
reg = <0x00100000 0x1f0000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK_A>,
|
||||
<&sleep_clk>,
|
||||
<&pcie_0_pipe_clk>, <&pcie_1_pipe_clk>,
|
||||
<&ufs_phy_rx_symbol_0_clk>, <&ufs_phy_rx_symbol_1_clk>,
|
||||
<&ufs_phy_tx_symbol_0_clk>,
|
||||
<&usb3_phy_wrapper_gcc_usb30_pipe_clk>;
|
||||
|
||||
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk", "pcie_0_pipe_clk",
|
||||
"pcie_1_pipe_clk", "ufs_phy_rx_symbol_0_clk",
|
||||
"ufs_phy_rx_symbol_1_clk", "ufs_phy_tx_symbol_0_clk",
|
||||
"usb3_phy_wrapper_gcc_usb30_pipe_clk";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -0,0 +1,76 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc8180x.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller Binding for SC8180x
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module which supports the clocks, resets and
|
||||
power domains on SC8180x.
|
||||
|
||||
See also:
|
||||
- dt-bindings/clock/qcom,gcc-sc8180x.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,gcc-sc8180x
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Board active XO source
|
||||
- description: Sleep clock source
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
- const: bi_tcxo_ao
|
||||
- const: sleep_clk
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
protected-clocks:
|
||||
description:
|
||||
Protected clock specifier list as per common clock binding.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@100000 {
|
||||
compatible = "qcom,gcc-sc8180x";
|
||||
reg = <0x00100000 0x1f0000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK_A>,
|
||||
<&sleep_clk>;
|
||||
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -0,0 +1,96 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8350.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller Binding for SM8350
|
||||
|
||||
maintainers:
|
||||
- Vinod Koul <vkoul@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module which supports the clocks, resets and
|
||||
power domains on SM8350.
|
||||
|
||||
See also:
|
||||
- dt-bindings/clock/qcom,gcc-sm8350.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,gcc-sm8350
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Sleep clock source
|
||||
- description: PLL test clock source (Optional clock)
|
||||
- description: PCIE 0 Pipe clock source (Optional clock)
|
||||
- description: PCIE 1 Pipe clock source (Optional clock)
|
||||
- description: UFS card Rx symbol 0 clock source (Optional clock)
|
||||
- description: UFS card Rx symbol 1 clock source (Optional clock)
|
||||
- description: UFS card Tx symbol 0 clock source (Optional clock)
|
||||
- description: UFS phy Rx symbol 0 clock source (Optional clock)
|
||||
- description: UFS phy Rx symbol 1 clock source (Optional clock)
|
||||
- description: UFS phy Tx symbol 0 clock source (Optional clock)
|
||||
- description: USB3 phy wrapper pipe clock source (Optional clock)
|
||||
- description: USB3 phy sec pipe clock source (Optional clock)
|
||||
minItems: 2
|
||||
maxItems: 13
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
- const: sleep_clk
|
||||
- const: core_bi_pll_test_se # Optional clock
|
||||
- const: pcie_0_pipe_clk # Optional clock
|
||||
- const: pcie_1_pipe_clk # Optional clock
|
||||
- const: ufs_card_rx_symbol_0_clk # Optional clock
|
||||
- const: ufs_card_rx_symbol_1_clk # Optional clock
|
||||
- const: ufs_card_tx_symbol_0_clk # Optional clock
|
||||
- const: ufs_phy_rx_symbol_0_clk # Optional clock
|
||||
- const: ufs_phy_rx_symbol_1_clk # Optional clock
|
||||
- const: ufs_phy_tx_symbol_0_clk # Optional clock
|
||||
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock
|
||||
- const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock
|
||||
minItems: 2
|
||||
maxItems: 13
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@100000 {
|
||||
compatible = "qcom,gcc-sm8350";
|
||||
reg = <0x00100000 0x1f0000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&sleep_clk>;
|
||||
clock-names = "bi_tcxo", "sleep_clk";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
...
|
|
@ -0,0 +1,76 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gpucc-sdm660.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Graphics Clock & Reset Controller Binding for SDM630 and SDM660
|
||||
|
||||
maintainers:
|
||||
- AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module which supports the clocks, resets and
|
||||
power domains on SDM630 and SDM660.
|
||||
|
||||
See also dt-bindings/clock/qcom,gpucc-sdm660.h.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,gpucc-sdm630
|
||||
- qcom,gpucc-sdm660
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: GPLL0 main gpu branch
|
||||
- description: GPLL0 divider gpu branch
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: xo
|
||||
- const: gcc_gpu_gpll0_clk
|
||||
- const: gcc_gpu_gpll0_div_clk
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-sdm660.h>
|
||||
#include <dt-bindings/clock/qcom,rpmcc.h>
|
||||
|
||||
clock-controller@5065000 {
|
||||
compatible = "qcom,gpucc-sdm660";
|
||||
reg = <0x05065000 0x9038>;
|
||||
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
|
||||
<&gcc GCC_GPU_GPLL0_CLK>,
|
||||
<&gcc GCC_GPU_GPLL0_DIV_CLK>;
|
||||
clock-names = "xo", "gcc_gpu_gpll0_clk",
|
||||
"gcc_gpu_gpll0_div_clk";
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -24,6 +24,8 @@ properties:
|
|||
- qcom,mmcc-msm8974
|
||||
- qcom,mmcc-msm8996
|
||||
- qcom,mmcc-msm8998
|
||||
- qcom,mmcc-sdm630
|
||||
- qcom,mmcc-sdm660
|
||||
|
||||
clocks:
|
||||
items:
|
||||
|
|
|
@ -18,6 +18,8 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- qcom,sc7180-rpmh-clk
|
||||
- qcom,sc7280-rpmh-clk
|
||||
- qcom,sc8180x-rpmh-clk
|
||||
- qcom,sdm845-rpmh-clk
|
||||
- qcom,sdx55-rpmh-clk
|
||||
- qcom,sm8150-rpmh-clk
|
||||
|
|
|
@ -35,6 +35,9 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- renesas,r8a774a1-rcar-usb2-clock-sel # RZ/G2M
|
||||
- renesas,r8a774b1-rcar-usb2-clock-sel # RZ/G2N
|
||||
- renesas,r8a774e1-rcar-usb2-clock-sel # RZ/G2H
|
||||
- renesas,r8a7795-rcar-usb2-clock-sel # R-Car H3
|
||||
- renesas,r8a7796-rcar-usb2-clock-sel # R-Car M3-W
|
||||
- renesas,r8a77961-rcar-usb2-clock-sel # R-Car M3-W+
|
||||
|
|
|
@ -28,6 +28,8 @@ Optional properties:
|
|||
- clock-frequency: Output frequency to generate. This defines the output
|
||||
frequency set during boot. It can be reprogrammed during
|
||||
runtime through the common clock framework.
|
||||
- silabs,skip-recall: Do not perform NVM->RAM recall operation. It will rely
|
||||
on hardware loading of RAM from NVM at power on.
|
||||
|
||||
Example:
|
||||
si570: clock-generator@5d {
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue