Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready
Merge the GPIO tree "ib-aspeed" topic branch which contains pre-requisites for subsequent changes. This branch is also in gpio "next".
This commit is contained in:
Benjamin Herrenschmidt
commit
d5e748ff2b
|
|
@ -11,7 +11,7 @@ Description:
|
|||
Kernel code may export it for complete or partial access.
|
||||
|
||||
GPIOs are identified as they are inside the kernel, using integers in
|
||||
the range 0..INT_MAX. See Documentation/gpio/gpio.txt for more information.
|
||||
the range 0..INT_MAX. See Documentation/gpio for more information.
|
||||
|
||||
/sys/class/gpio
|
||||
/export ... asks the kernel to export a GPIO to userspace
|
||||
|
|
|
|||
|
|
@ -238,9 +238,6 @@ Description: Discover and change clock speed of CPUs
|
|||
|
||||
See files in Documentation/cpu-freq/ for more information.
|
||||
|
||||
In particular, read Documentation/cpu-freq/user-guide.txt
|
||||
to learn how to control the knobs.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus
|
||||
Date: June 2013
|
||||
|
|
|
|||
|
|
@ -25,3 +25,16 @@ Description:
|
|||
Control touchpad mode.
|
||||
* 1 -> Switched On
|
||||
* 0 -> Switched Off
|
||||
|
||||
What: /sys/bus/pci/devices/<bdf>/<device>/VPC2004:00/fn_lock
|
||||
Date: May 2018
|
||||
KernelVersion: 4.18
|
||||
Contact: "Oleg Keri <ezhi99@gmail.com>"
|
||||
Description:
|
||||
Control fn-lock mode.
|
||||
* 1 -> Switched On
|
||||
* 0 -> Switched Off
|
||||
|
||||
For example:
|
||||
# echo "0" > \
|
||||
/sys/bus/pci/devices/0000:00:1f.0/PNP0C09:00/VPC2004:00/fn_lock
|
||||
|
|
|
|||
|
|
@ -16,7 +16,8 @@ control method rather than override the entire DSDT, because kernel
|
|||
rebuild/reboot is not needed and test result can be got in minutes.
|
||||
|
||||
Note: Only ACPI METHOD can be overridden, any other object types like
|
||||
"Device", "OperationRegion", are not recognized.
|
||||
"Device", "OperationRegion", are not recognized. Methods
|
||||
declared inside scope operators are also not supported.
|
||||
Note: The same ACPI control method can be overridden for many times,
|
||||
and it's always the latest one that used by Linux/kernel.
|
||||
Note: To get the ACPI debug object output (Store (AAAA, Debug)),
|
||||
|
|
@ -32,8 +33,6 @@ Note: To get the ACPI debug object output (Store (AAAA, Debug)),
|
|||
|
||||
DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715)
|
||||
{
|
||||
External (ACON)
|
||||
|
||||
Method (\_SB_.AC._PSR, 0, NotSerialized)
|
||||
{
|
||||
Store ("In AC _PSR", Debug)
|
||||
|
|
@ -42,9 +41,10 @@ Note: To get the ACPI debug object output (Store (AAAA, Debug)),
|
|||
}
|
||||
Note that the full pathname of the method in ACPI namespace
|
||||
should be used.
|
||||
And remember to use "External" to declare external objects.
|
||||
e) assemble the file to generate the AML code of the method.
|
||||
e.g. "iasl psr.asl" (psr.aml is generated as a result)
|
||||
e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result)
|
||||
If parameter "-vw 6084" is not supported by your iASL compiler,
|
||||
please try a newer version.
|
||||
f) mount debugfs by "mount -t debugfs none /sys/kernel/debug"
|
||||
g) override the old method via the debugfs by running
|
||||
"cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method"
|
||||
|
|
|
|||
|
|
@ -44,8 +44,8 @@ Links
|
|||
|
||||
Mailing List - apparmor@lists.ubuntu.com
|
||||
|
||||
Wiki - http://apparmor.wiki.kernel.org/
|
||||
Wiki - http://wiki.apparmor.net
|
||||
|
||||
User space tools - https://launchpad.net/apparmor
|
||||
User space tools - https://gitlab.com/apparmor
|
||||
|
||||
Kernel module - git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
|
||||
Kernel module - git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
|
||||
|
|
|
|||
|
|
@ -256,7 +256,7 @@
|
|||
(may crash computer or cause data corruption)
|
||||
|
||||
ALSA [HW,ALSA]
|
||||
See Documentation/sound/alsa/alsa-parameters.txt
|
||||
See Documentation/sound/alsa-configuration.rst
|
||||
|
||||
alignment= [KNL,ARM]
|
||||
Allow the default userspace alignment fault handler
|
||||
|
|
@ -2926,9 +2926,6 @@
|
|||
This will also cause panics on machine check exceptions.
|
||||
Useful together with panic=30 to trigger a reboot.
|
||||
|
||||
OSS [HW,OSS]
|
||||
See Documentation/sound/oss/oss-parameters.txt
|
||||
|
||||
page_owner= [KNL] Boot-time page_owner enabling option.
|
||||
Storage of the information about who allocated
|
||||
each page is disabled in default. With this switch,
|
||||
|
|
@ -4335,7 +4332,7 @@
|
|||
[FTRACE] Set and start specified trace events in order
|
||||
to facilitate early boot debugging. The event-list is a
|
||||
comma separated list of trace events to enable. See
|
||||
also Documentation/trace/events.txt
|
||||
also Documentation/trace/events.rst
|
||||
|
||||
trace_options=[option-list]
|
||||
[FTRACE] Enable or disable tracer options at boot.
|
||||
|
|
@ -4350,7 +4347,7 @@
|
|||
|
||||
trace_options=stacktrace
|
||||
|
||||
See also Documentation/trace/ftrace.txt "trace options"
|
||||
See also Documentation/trace/ftrace.rst "trace options"
|
||||
section.
|
||||
|
||||
tp_printk[FTRACE]
|
||||
|
|
|
|||
|
|
@ -752,18 +752,6 @@ completion of the request to the block layer. This means ending tag
|
|||
operations before calling end_that_request_last()! For an example of a user
|
||||
of these helpers, see the IDE tagged command queueing support.
|
||||
|
||||
Certain hardware conditions may dictate a need to invalidate the block tag
|
||||
queue. For instance, on IDE any tagged request error needs to clear both
|
||||
the hardware and software block queue and enable the driver to sanely restart
|
||||
all the outstanding requests. There's a third helper to do that:
|
||||
|
||||
blk_queue_invalidate_tags(struct request_queue *q)
|
||||
|
||||
Clear the internal block tag queue and re-add all the pending requests
|
||||
to the request queue. The driver will receive them again on the
|
||||
next request_fn run, just like it did the first time it encountered
|
||||
them.
|
||||
|
||||
3.2.5.2 Tag info
|
||||
|
||||
Some block functions exist to query current tag status or to go from a
|
||||
|
|
@ -805,8 +793,7 @@ Internally, block manages tags in the blk_queue_tag structure:
|
|||
Most of the above is simple and straight forward, however busy_list may need
|
||||
a bit of explaining. Normally we don't care too much about request ordering,
|
||||
but in the event of any barrier requests in the tag queue we need to ensure
|
||||
that requests are restarted in the order they were queue. This may happen
|
||||
if the driver needs to use blk_queue_invalidate_tags().
|
||||
that requests are restarted in the order they were queue.
|
||||
|
||||
3.3 I/O Submission
|
||||
|
||||
|
|
|
|||
|
|
@ -8,11 +8,13 @@ The crypto engine API (CE), is a crypto queue manager.
|
|||
|
||||
Requirement
|
||||
-----------
|
||||
You have to put at start of your tfm_ctx the struct crypto_engine_ctx
|
||||
struct your_tfm_ctx {
|
||||
You have to put at start of your tfm_ctx the struct crypto_engine_ctx::
|
||||
|
||||
struct your_tfm_ctx {
|
||||
struct crypto_engine_ctx enginectx;
|
||||
...
|
||||
};
|
||||
};
|
||||
|
||||
Why: Since CE manage only crypto_async_request, it cannot know the underlying
|
||||
request_type and so have access only on the TFM.
|
||||
So using container_of for accessing __ctx is impossible.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,68 @@
|
|||
The writecache target caches writes on persistent memory or on SSD. It
|
||||
doesn't cache reads because reads are supposed to be cached in page cache
|
||||
in normal RAM.
|
||||
|
||||
When the device is constructed, the first sector should be zeroed or the
|
||||
first sector should contain valid superblock from previous invocation.
|
||||
|
||||
Constructor parameters:
|
||||
1. type of the cache device - "p" or "s"
|
||||
p - persistent memory
|
||||
s - SSD
|
||||
2. the underlying device that will be cached
|
||||
3. the cache device
|
||||
4. block size (4096 is recommended; the maximum block size is the page
|
||||
size)
|
||||
5. the number of optional parameters (the parameters with an argument
|
||||
count as two)
|
||||
high_watermark n (default: 50)
|
||||
start writeback when the number of used blocks reach this
|
||||
watermark
|
||||
low_watermark x (default: 45)
|
||||
stop writeback when the number of used blocks drops below
|
||||
this watermark
|
||||
writeback_jobs n (default: unlimited)
|
||||
limit the number of blocks that are in flight during
|
||||
writeback. Setting this value reduces writeback
|
||||
throughput, but it may improve latency of read requests
|
||||
autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
|
||||
when the application writes this amount of blocks without
|
||||
issuing the FLUSH request, the blocks are automatically
|
||||
commited
|
||||
autocommit_time ms (default: 1000)
|
||||
autocommit time in milliseconds. The data is automatically
|
||||
commited if this time passes and no FLUSH request is
|
||||
received
|
||||
fua (by default on)
|
||||
applicable only to persistent memory - use the FUA flag
|
||||
when writing data from persistent memory back to the
|
||||
underlying device
|
||||
nofua
|
||||
applicable only to persistent memory - don't use the FUA
|
||||
flag when writing back data and send the FLUSH request
|
||||
afterwards
|
||||
- some underlying devices perform better with fua, some
|
||||
with nofua. The user should test it
|
||||
|
||||
Status:
|
||||
1. error indicator - 0 if there was no error, otherwise error number
|
||||
2. the number of blocks
|
||||
3. the number of free blocks
|
||||
4. the number of blocks under writeback
|
||||
|
||||
Messages:
|
||||
flush
|
||||
flush the cache device. The message returns successfully
|
||||
if the cache device was flushed without an error
|
||||
flush_on_suspend
|
||||
flush the cache device on next suspend. Use this message
|
||||
when you are going to remove the cache device. The proper
|
||||
sequence for removing the cache device is:
|
||||
1. send the "flush_on_suspend" message
|
||||
2. load an inactive table with a linear target that maps
|
||||
to the underlying device
|
||||
3. suspend the device
|
||||
4. ask for status and verify that there are no errors
|
||||
5. resume the device, so that it will use the linear
|
||||
target
|
||||
6. the cache device is now inactive and it can be deleted
|
||||
|
|
@ -31,10 +31,10 @@ This binding uses the common clock binding[1].
|
|||
Each subnode should use the binding described in [2]..[7]
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt
|
||||
[4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt
|
||||
[7] Documentation/devicetree/bindings/clock/st,quadfs.txt
|
||||
[8] Documentation/devicetree/bindings/clock/st,flexgen.txt
|
||||
[3] Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
|
||||
[4] Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
|
||||
[7] Documentation/devicetree/bindings/clock/st/st,quadfs.txt
|
||||
[8] Documentation/devicetree/bindings/clock/st/st,flexgen.txt
|
||||
|
||||
|
||||
Required properties:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ will be controlled instead and the corresponding hw-ops for
|
|||
that is used.
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/clock/gate-clock.txt
|
||||
[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
|
||||
[3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
|
||||
|
||||
Required properties:
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ companion clock finding (match corresponding functional gate
|
|||
clock) and hardware autoidle enable / disable.
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/clock/gate-clock.txt
|
||||
[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be one of:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Required properties:
|
|||
"intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
|
||||
source (usually MAINPLL) when the original CPU PLL is under
|
||||
transition and not stable yet.
|
||||
Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for
|
||||
Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
|
||||
generic clock consumer properties.
|
||||
- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt
|
||||
for detail.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Required properties:
|
|||
- clocks: Phandles for clock specified in "clock-names" property
|
||||
- clock-names : The name of clock used by the DFI, must be
|
||||
"pclk_ddr_mon";
|
||||
- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt
|
||||
- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp.txt
|
||||
for details.
|
||||
- center-supply: DMC supply node.
|
||||
- status: Marks the node enabled/disabled.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Optional properties:
|
|||
- nxp,calib-gpios: calibration GPIO, which must correspond with the
|
||||
gpio used for the TDA998x interrupt pin.
|
||||
|
||||
[1] Documentation/sound/alsa/soc/DAI.txt
|
||||
[1] Documentation/sound/soc/dai.rst
|
||||
[2] include/dt-bindings/display/tda998x.h
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Optional properties:
|
|||
- mali-supply : Phandle to regulator for the Mali device. Refer to
|
||||
Documentation/devicetree/bindings/regulator/regulator.txt for details.
|
||||
|
||||
- operating-points-v2 : Refer to Documentation/devicetree/bindings/power/opp.txt
|
||||
- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
|
||||
for details.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ Optional properties:
|
|||
|
||||
- memory-region:
|
||||
Memory region to allocate from, as defined in
|
||||
Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt
|
||||
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
|
||||
|
||||
- mali-supply:
|
||||
Phandle to regulator for the Mali device, as defined in
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Recommended properties :
|
|||
- clock-frequency : desired I2C bus clock frequency in Hz.
|
||||
- ti,has-pfunc: boolean; if defined, it indicates that SoC supports PFUNC
|
||||
registers. PFUNC registers allow to switch I2C pins to function as
|
||||
GPIOs, so they can by toggled manually.
|
||||
GPIOs, so they can be toggled manually.
|
||||
|
||||
Example (enbw_cmc board):
|
||||
i2c@1c22000 {
|
||||
|
|
|
|||
|
|
@ -15,6 +15,7 @@ Required properties:
|
|||
"renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
|
||||
"renesas,i2c-r8a77965" if the device is a part of a R8A77965 SoC.
|
||||
"renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC.
|
||||
"renesas,i2c-r8a77980" if the device is a part of a R8A77980 SoC.
|
||||
"renesas,i2c-r8a77995" if the device is a part of a R8A77995 SoC.
|
||||
"renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
|
||||
"renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible
|
||||
|
|
|
|||
|
|
@ -8,9 +8,7 @@ Required properties:
|
|||
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
|
||||
(c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
|
||||
inside HDMIPHY block found on several samsung SoCs
|
||||
(d) "samsung, exynos5440-i2c", for s3c2440-like i2c used
|
||||
on EXYNOS5440 which does not need GPIO configuration.
|
||||
(e) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as
|
||||
(d) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as
|
||||
a host to SATA PHY controller on an internal bus.
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Additional documentation for F11 can be found at:
|
|||
http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
|
||||
|
||||
Optional Touch Properties:
|
||||
Description in Documentation/devicetree/bindings/input/touch
|
||||
Description in Documentation/devicetree/bindings/input/touchscreen
|
||||
- touchscreen-inverted-x
|
||||
- touchscreen-inverted-y
|
||||
- touchscreen-swapped-x-y
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Deprecated properties:
|
|||
This property is deprecated. Instead, a 'steps-per-period ' value should
|
||||
be used, such as "rotary-encoder,steps-per-period = <2>".
|
||||
|
||||
See Documentation/input/rotary-encoder.txt for more information.
|
||||
See Documentation/input/devices/rotary-encoder.rst for more information.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ See: Documentation/devicetree/bindings/clock/clock-bindings.txt
|
|||
- pinctrl-names : a pinctrl state named tsin%d-serial or tsin%d-parallel (where %d is tsin-num)
|
||||
must be defined for each tsin child node.
|
||||
- pinctrl-0 : phandle referencing pin configuration for this tsin configuration
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
||||
|
||||
|
||||
Required properties (tsin (child) node):
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ is required:
|
|||
Following properties are require if pin control setting is required
|
||||
at boot.
|
||||
- pinctrl-names: A pinctrl state named "default" be defined, using the
|
||||
bindings in pinctrl/pinctrl-binding.txt.
|
||||
bindings in pinctrl/pinctrl-bindings.txt.
|
||||
- pinctrl[0...n]: Properties to contain the phandle that refer to
|
||||
different nodes of pin control settings. These nodes represents
|
||||
the pin control setting of state 0 to state n. Each of these
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ MT6397/MT6323 is a multifunction device with the following sub modules:
|
|||
It is interfaced to host controller using SPI interface by a proprietary hardware
|
||||
called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
|
||||
See the following for pwarp node definitions:
|
||||
Documentation/devicetree/bindings/soc/pwrap.txt
|
||||
Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
|
||||
|
||||
This document describes the binding for MFD device and its sub module.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,11 @@ Required parameters:
|
|||
Optional parameters:
|
||||
- resets: Phandle to the parent reset controller.
|
||||
See ../reset/st,stm32-rcc.txt
|
||||
- dmas: List of phandle to dma channels that can be used for
|
||||
this timer instance. There may be up to 7 dma channels.
|
||||
- dma-names: List of dma names. Must match 'dmas' property. Valid
|
||||
names are: "ch1", "ch2", "ch3", "ch4", "up", "trig",
|
||||
"com".
|
||||
|
||||
Optional subnodes:
|
||||
- pwm: See ../pwm/pwm-stm32.txt
|
||||
|
|
@ -44,3 +49,18 @@ Example:
|
|||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
Example with all dmas:
|
||||
timer@40010000 {
|
||||
...
|
||||
dmas = <&dmamux1 11 0x400 0x0>,
|
||||
<&dmamux1 12 0x400 0x0>,
|
||||
<&dmamux1 13 0x400 0x0>,
|
||||
<&dmamux1 14 0x400 0x0>,
|
||||
<&dmamux1 15 0x400 0x0>,
|
||||
<&dmamux1 16 0x400 0x0>,
|
||||
<&dmamux1 17 0x400 0x0>;
|
||||
dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig", "com";
|
||||
...
|
||||
child nodes...
|
||||
};
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ Required properties:
|
|||
- reg: The PRCM registers range
|
||||
|
||||
The prcm node may contain several subdevices definitions:
|
||||
- see Documentation/devicetree/clk/sunxi.txt for clock devices
|
||||
- see Documentation/devicetree/reset/allwinner,sunxi-clock-reset.txt for reset
|
||||
- see Documentation/devicetree/bindings/clock/sunxi.txt for clock devices
|
||||
- see Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt for reset
|
||||
controller devices
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ Required properties for a slot (Deprecated - Recommend to use one slot per host)
|
|||
rest of the gpios (depending on the bus-width property) are the data lines in
|
||||
no particular order. The format of the gpio specifier depends on the gpio
|
||||
controller.
|
||||
(Deprecated - Refer to Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)
|
||||
(Deprecated - Refer to Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt)
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Required properties:
|
|||
See: Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
- pinctrl-names: A pinctrl state names "default" must be defined.
|
||||
- pinctrl-0: Phandle referencing pin configuration of the SDHCI controller.
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Required properties:
|
|||
|
||||
- pinctrl-names: A pinctrl state names "default" must be defined.
|
||||
- pinctrl-0: Phandle referencing pin configuration of the sd/emmc controller.
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
||||
|
||||
- reg: This must provide the host controller base address and it can also
|
||||
contain the FlashSS Top register for TX/RX delay used by the driver
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Required properties:
|
|||
- compatible: For external switch chips, compatible string must be exactly one
|
||||
of: "microchip,ksz9477"
|
||||
|
||||
See Documentation/devicetree/bindings/dsa/dsa.txt for a list of additional
|
||||
See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
|
||||
required and optional properties.
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Required properties for the child nodes within ports container:
|
|||
- phy-mode: String, must be either "trgmii" or "rgmii" for port labeled
|
||||
"cpu".
|
||||
|
||||
See Documentation/devicetree/bindings/dsa/dsa.txt for a list of additional
|
||||
See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
|
||||
required, optional properties and how the integrated switch subnodes must
|
||||
be specified.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Optional properties:
|
|||
Data cells:
|
||||
|
||||
Data cells are child nodes of eerpom node, bindings for which are
|
||||
documented in Documentation/bindings/nvmem/nvmem.txt
|
||||
documented in Documentation/devicetree/bindings/nvmem/nvmem.txt
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ HiSilicon Hip05 and Hip06 PCIe host bridge DT description
|
|||
HiSilicon PCIe host controller is based on the Synopsys DesignWare PCI core.
|
||||
It shares common functions with the PCIe DesignWare core driver and inherits
|
||||
common properties defined in
|
||||
Documentation/devicetree/bindings/pci/designware-pci.txt.
|
||||
Documentation/devicetree/bindings/pci/designware-pcie.txt.
|
||||
|
||||
Additional properties are described here:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ HiSilicon Kirin SoCs PCIe host DT description
|
|||
Kirin PCIe host controller is based on the Synopsys DesignWare PCI core.
|
||||
It shares common functions with the PCIe DesignWare core driver and
|
||||
inherits common properties defined in
|
||||
Documentation/devicetree/bindings/pci/designware-pci.txt.
|
||||
Documentation/devicetree/bindings/pci/designware-pcie.txt.
|
||||
|
||||
Additional properties are described here:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ TI Keystone PCIe interface
|
|||
Keystone PCI host Controller is based on the Synopsys DesignWare PCI
|
||||
hardware version 3.65. It shares common functions with the PCIe DesignWare
|
||||
core driver and inherits common properties defined in
|
||||
Documentation/devicetree/bindings/pci/designware-pci.txt
|
||||
Documentation/devicetree/bindings/pci/designware-pcie.txt
|
||||
|
||||
Please refer to Documentation/devicetree/bindings/pci/designware-pci.txt
|
||||
Please refer to Documentation/devicetree/bindings/pci/designware-pcie.txt
|
||||
for the details of DesignWare DT bindings. Additional properties are
|
||||
described here as well as properties that are not applicable.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ Optional Pinmux properties:
|
|||
--------------------------
|
||||
Following properties are required if default setting of pins are required
|
||||
at boot.
|
||||
- pinctrl-names: A pinctrl state named per <pinctrl-binding.txt>.
|
||||
- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
|
||||
- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
|
||||
<pinctrl-binding.txt>.
|
||||
<pinctrl-bindings.txt>.
|
||||
|
||||
The pin configurations are defined as child of the pinctrl states node. Each
|
||||
sub-node have following properties:
|
||||
|
|
|
|||
|
|
@ -101,9 +101,9 @@ Optional Pinmux properties:
|
|||
--------------------------
|
||||
Following properties are required if default setting of pins are required
|
||||
at boot.
|
||||
- pinctrl-names: A pinctrl state named per <pinctrl-binding.txt>.
|
||||
- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
|
||||
- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
|
||||
<pinctrl-binding.txt>.
|
||||
<pinctrl-bindings.txt>.
|
||||
|
||||
The pin configurations are defined as child of the pinctrl states node. Each
|
||||
sub-node have following properties:
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ Optional Pinmux properties:
|
|||
--------------------------
|
||||
Following properties are required if default setting of pins are required
|
||||
at boot.
|
||||
- pinctrl-names: A pinctrl state named per <pinctrl-binding.txt>.
|
||||
- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
|
||||
- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
|
||||
<pinctrl-binding.txt>.
|
||||
<pinctrl-bindings.txt>.
|
||||
|
||||
The pin configurations are defined as child of the pinctrl states node. Each
|
||||
sub-node have following properties:
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Required properties:
|
|||
datasheet
|
||||
- interrupts: Should contain one interrupt specifier for the GPC interrupt
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
|
||||
See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- ipg
|
||||
|
||||
|
|
|
|||
|
|
@ -111,8 +111,8 @@ Example 3:
|
|||
==PM domain consumers==
|
||||
|
||||
Required properties:
|
||||
- power-domains : A phandle and PM domain specifier as defined by bindings of
|
||||
the power controller specified by phandle.
|
||||
- power-domains : A list of PM domain specifiers, as defined by bindings of
|
||||
the power controller that is the PM domain provider.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -122,9 +122,18 @@ Example:
|
|||
power-domains = <&power 0>;
|
||||
};
|
||||
|
||||
The node above defines a typical PM domain consumer device, which is located
|
||||
inside a PM domain with index 0 of a power controller represented by a node
|
||||
with the label "power".
|
||||
leaky-device@12351000 {
|
||||
compatible = "foo,i-leak-current";
|
||||
reg = <0x12351000 0x1000>;
|
||||
power-domains = <&power 0>, <&power 1> ;
|
||||
};
|
||||
|
||||
The first example above defines a typical PM domain consumer device, which is
|
||||
located inside a PM domain with index 0 of a power controller represented by a
|
||||
node with the label "power".
|
||||
In the second example the consumer device are partitioned across two PM domains,
|
||||
the first with index 0 and the second with index 1, of a power controller that
|
||||
is represented by a node with the label "power.
|
||||
|
||||
Optional properties:
|
||||
- required-opps: This contains phandle to an OPP node in another device's OPP
|
||||
|
|
|
|||
|
|
@ -13,4 +13,4 @@ Required Properties:
|
|||
};
|
||||
|
||||
For information on battery specific node, Ref:
|
||||
Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
|
||||
Documentation/devicetree/bindings/power/supply/ab8500/fg.txt
|
||||
|
|
|
|||
|
|
@ -13,4 +13,4 @@ ab8500_chargalg {
|
|||
};
|
||||
|
||||
For information on battery specific node, Ref:
|
||||
Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
|
||||
Documentation/devicetree/bindings/power/supply/ab8500/fg.txt
|
||||
|
|
|
|||
|
|
@ -22,4 +22,4 @@ Required Properties:
|
|||
};
|
||||
|
||||
For information on battery specific node, Ref:
|
||||
Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
|
||||
Documentation/devicetree/bindings/power/supply/ab8500/fg.txt
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ List of legacy properties and respective binding document
|
|||
3. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt
|
||||
4. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
|
||||
Documentation/devicetree/bindings/mfd/tc3589x.txt
|
||||
Documentation/devicetree/bindings/input/ads7846.txt
|
||||
Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
|
||||
5. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
|
||||
6. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt
|
||||
7. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Required properties:
|
|||
See: Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
- pinctrl-names: A pinctrl state names "default" must be defined.
|
||||
- pinctrl-0: Phandle referencing pin configuration of the UART peripheral.
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
|
||||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
||||
|
||||
Optional properties:
|
||||
- cts-gpios: CTS pin for UART
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Required properties:
|
|||
See Documentation/devicetree/bindings/dma/stm32-dma.txt.
|
||||
- dma-names: Identifier for each DMA request line. Must be "tx" and "rx".
|
||||
- pinctrl-names: should contain only value "default"
|
||||
- pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
|
||||
- pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
|
||||
|
||||
Optional properties:
|
||||
- resets: Reference to a reset controller asserting the reset controller
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ SAI subnodes required properties:
|
|||
"tx": if sai sub-block is configured as playback DAI
|
||||
"rx": if sai sub-block is configured as capture DAI
|
||||
- pinctrl-names: should contain only value "default"
|
||||
- pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
|
||||
- pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
|
||||
|
||||
SAI subnodes Optional properties:
|
||||
- st,sync: specify synchronization mode.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Required properties:
|
|||
- clocks : Must contain an entry for each name in clock-names
|
||||
See ../clk/*
|
||||
- pinctrl-names : Uses "default", can use "sleep" if provided
|
||||
See ../pinctrl/pinctrl-binding.txt
|
||||
See ../pinctrl/pinctrl-bindings.txt
|
||||
|
||||
Optional properties:
|
||||
- cs-gpios : List of GPIO chip selects
|
||||
|
|
|
|||
|
|
@ -12,7 +12,6 @@
|
|||
"samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
|
||||
Exynos5420 (Must pass triminfo base and triminfo clock)
|
||||
"samsung,exynos5433-tmu"
|
||||
"samsung,exynos5440-tmu"
|
||||
"samsung,exynos7-tmu"
|
||||
- interrupt-parent : The phandle for the interrupt controller
|
||||
- reg : Address range of the thermal registers. For soc's which has multiple
|
||||
|
|
@ -68,18 +67,7 @@ Example 1):
|
|||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
||||
Example 2):
|
||||
|
||||
tmuctrl_0: tmuctrl@160118 {
|
||||
compatible = "samsung,exynos5440-tmu";
|
||||
reg = <0x160118 0x230>, <0x160368 0x10>;
|
||||
interrupts = <0 58 0>;
|
||||
clocks = <&clock 21>;
|
||||
clock-names = "tmu_apbif";
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
||||
Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
|
||||
Example 2): (In case of Exynos5420 "with misplaced TRIMINFO register")
|
||||
tmu_cpu2: tmu@10068000 {
|
||||
compatible = "samsung,exynos5420-tmu-ext-triminfo";
|
||||
reg = <0x10068000 0x100>, <0x1006c000 0x4>;
|
||||
|
|
|
|||
|
|
@ -1,8 +1,13 @@
|
|||
* Temperature Monitor (TEMPMON) on Freescale i.MX SoCs
|
||||
|
||||
Required properties:
|
||||
- compatible : "fsl,imx6q-tempmon" for i.MX6Q, "fsl,imx6sx-tempmon" for i.MX6SX.
|
||||
i.MX6SX has two more IRQs than i.MX6Q, one is IRQ_LOW and the other is IRQ_PANIC,
|
||||
- compatible : must be one of following:
|
||||
- "fsl,imx6q-tempmon" for i.MX6Q,
|
||||
- "fsl,imx6sx-tempmon" for i.MX6SX,
|
||||
- "fsl,imx7d-tempmon" for i.MX7S/D.
|
||||
- interrupts : the interrupt output of the controller:
|
||||
i.MX6Q has one IRQ which will be triggered when temperature is higher than high threshold,
|
||||
i.MX6SX and i.MX7S/D have two more IRQs than i.MX6Q, one is IRQ_LOW and the other is IRQ_PANIC,
|
||||
when temperature is below than low threshold, IRQ_LOW will be triggered, when temperature
|
||||
is higher than panic threshold, system will auto reboot by SRC module.
|
||||
- fsl,tempmon : phandle pointer to system controller that contains TEMPMON
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@ Required properties:
|
|||
- "mediatek,mt8173-thermal" : For MT8173 family of SoCs
|
||||
- "mediatek,mt2701-thermal" : For MT2701 family of SoCs
|
||||
- "mediatek,mt2712-thermal" : For MT2712 family of SoCs
|
||||
- "mediatek,mt7622-thermal" : For MT7622 SoC
|
||||
- reg: Address range of the thermal controller
|
||||
- interrupts: IRQ for the thermal controller
|
||||
- clocks, clock-names: Clocks needed for the thermal controller. required
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required properties:
|
|||
|
||||
- reg: Address range of the thermal registers
|
||||
- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
|
||||
- #qcom,sensors: Number of sensors in tsens block
|
||||
- Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how to specify
|
||||
nvmem cells
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Required properties:
|
|||
Examples with soctypes are:
|
||||
- "renesas,r8a7795-thermal" (R-Car H3)
|
||||
- "renesas,r8a7796-thermal" (R-Car M3-W)
|
||||
- "renesas,r8a77965-thermal" (R-Car M3-N)
|
||||
- reg : Address ranges of the thermal registers. Each sensor
|
||||
needs one address range. Sorting must be done in
|
||||
increasing order according to datasheet, i.e.
|
||||
|
|
@ -18,7 +19,7 @@ Required properties:
|
|||
|
||||
Optional properties:
|
||||
|
||||
- interrupts : interrupts routed to the TSC (3 for H3 and M3-W)
|
||||
- interrupts : interrupts routed to the TSC (3 for H3, M3-W and M3-N)
|
||||
- power-domain : Must contain a reference to the power domain. This
|
||||
property is mandatory if the thermal sensor instance
|
||||
is part of a controllable power domain.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,8 @@
|
|||
Required properties:
|
||||
- compatible : "renesas,thermal-<soctype>",
|
||||
"renesas,rcar-gen2-thermal" (with thermal-zone) or
|
||||
"renesas,rcar-thermal" (without thermal-zone) as fallback.
|
||||
"renesas,rcar-thermal" (without thermal-zone) as
|
||||
fallback except R-Car D3.
|
||||
Examples with soctypes are:
|
||||
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
|
||||
- "renesas,thermal-r8a7743" (RZ/G1M)
|
||||
|
|
@ -12,13 +13,15 @@ Required properties:
|
|||
- "renesas,thermal-r8a7791" (R-Car M2-W)
|
||||
- "renesas,thermal-r8a7792" (R-Car V2H)
|
||||
- "renesas,thermal-r8a7793" (R-Car M2-N)
|
||||
- "renesas,thermal-r8a77995" (R-Car D3)
|
||||
- reg : Address range of the thermal registers.
|
||||
The 1st reg will be recognized as common register
|
||||
if it has "interrupts".
|
||||
|
||||
Option properties:
|
||||
|
||||
- interrupts : use interrupt
|
||||
- interrupts : If present should contain 3 interrupts for
|
||||
R-Car D3 or 1 interrupt otherwise.
|
||||
|
||||
Example (non interrupt support):
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required properties:
|
|||
- compatible :
|
||||
- "socionext,uniphier-pxs2-thermal" : For UniPhier PXs2 SoC
|
||||
- "socionext,uniphier-ld20-thermal" : For UniPhier LD20 SoC
|
||||
- "socionext,uniphier-pxs3-thermal" : For UniPhier PXs3 SoC
|
||||
- interrupts : IRQ for the temperature alarm
|
||||
- #thermal-sensor-cells : Should be 0. See ./thermal.txt for details.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ A child node must exist to represent the core DWC3 IP block. The name of
|
|||
the node is not important. The content of the node is defined in dwc3.txt.
|
||||
|
||||
Phy documentation is provided in the following places:
|
||||
Documentation/devicetree/bindings/phy/rockchip,dwc3-usb-phy.txt
|
||||
Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
|
||||
|
||||
Example device nodes:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,10 +3,15 @@ Ingenic Watchdog Timer (WDT) Controller for JZ4740 & JZ4780
|
|||
Required properties:
|
||||
compatible: "ingenic,jz4740-watchdog" or "ingenic,jz4780-watchdog"
|
||||
reg: Register address and length for watchdog registers
|
||||
clocks: phandle to the RTC clock
|
||||
clock-names: should be "rtc"
|
||||
|
||||
Example:
|
||||
|
||||
watchdog: jz4740-watchdog@10002000 {
|
||||
compatible = "ingenic,jz4740-watchdog";
|
||||
reg = <0x10002000 0x100>;
|
||||
reg = <0x10002000 0x10>;
|
||||
|
||||
clocks = <&cgu JZ4740_CLK_RTC>;
|
||||
clock-names = "rtc";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ device that displays digits), an additional index argument can be specified::
|
|||
enum gpiod_flags flags)
|
||||
|
||||
For a more detailed description of the con_id parameter in the DeviceTree case
|
||||
see Documentation/gpio/board.txt
|
||||
see Documentation/driver-api/gpio/board.rst
|
||||
|
||||
The flags parameter is used to optionally specify a direction and initial value
|
||||
for the GPIO. Values can be:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
#
|
||||
# Feature name: stackprotector
|
||||
# Kconfig: HAVE_CC_STACKPROTECTOR
|
||||
# Kconfig: HAVE_STACKPROTECTOR
|
||||
# description: arch supports compiler driven stack overflow protection
|
||||
#
|
||||
-----------------------
|
||||
|
|
|
|||
|
|
@ -105,15 +105,13 @@ Mount Options
|
|||
address its connection to the monitor originates from.
|
||||
|
||||
wsize=X
|
||||
Specify the maximum write size in bytes. By default there is no
|
||||
maximum. Ceph will normally size writes based on the file stripe
|
||||
size.
|
||||
Specify the maximum write size in bytes. Default: 16 MB.
|
||||
|
||||
rsize=X
|
||||
Specify the maximum read size in bytes. Default: 64 MB.
|
||||
Specify the maximum read size in bytes. Default: 16 MB.
|
||||
|
||||
rasize=X
|
||||
Specify the maximum readahead. Default: 8 MB.
|
||||
Specify the maximum readahead size in bytes. Default: 8 MB.
|
||||
|
||||
mount_timeout=X
|
||||
Specify the timeout value for mount (in seconds), in the case
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ bus supply voltage.
|
|||
|
||||
The shunt value in micro-ohms can be set via platform data or device tree at
|
||||
compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
|
||||
refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
|
||||
refer to the Documentation/devicetree/bindings/hwmon/ina2xx.txt for bindings
|
||||
if the device tree is used.
|
||||
|
||||
Additionally ina226 supports update_interval attribute as described in
|
||||
|
|
|
|||
|
|
@ -20,6 +20,10 @@ The next transaction types are supported:
|
|||
- Write Byte/Block.
|
||||
|
||||
Registers:
|
||||
CPBLTY 0x0 - capability reg.
|
||||
Bits [6:5] - transaction length. b01 - 72B is supported,
|
||||
36B in other case.
|
||||
Bit 7 - SMBus block read support.
|
||||
CTRL 0x1 - control reg.
|
||||
Resets all the registers.
|
||||
HALF_CYC 0x4 - cycle reg.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Usage
|
|||
i2c-ocores uses the platform bus, so you need to provide a struct
|
||||
platform_device with the base address and interrupt number. The
|
||||
dev.platform_data of the device should also point to a struct
|
||||
ocores_i2c_platform_data (see linux/i2c-ocores.h) describing the
|
||||
ocores_i2c_platform_data (see linux/platform_data/i2c-ocores.h) describing the
|
||||
distance between registers and the input clock speed.
|
||||
There is also a possibility to attach a list of i2c_board_info which
|
||||
the i2c-ocores driver will add to the bus upon creation.
|
||||
|
|
|
|||
|
|
@ -30,12 +30,12 @@ i2c-mux-gpio uses the platform bus, so you need to provide a struct
|
|||
platform_device with the platform_data pointing to a struct
|
||||
i2c_mux_gpio_platform_data with the I2C adapter number of the master
|
||||
bus, the number of bus segments to create and the GPIO pins used
|
||||
to control it. See include/linux/i2c-mux-gpio.h for details.
|
||||
to control it. See include/linux/platform_data/i2c-mux-gpio.h for details.
|
||||
|
||||
E.G. something like this for a MUX providing 4 bus segments
|
||||
controlled through 3 GPIO pins:
|
||||
|
||||
#include <linux/i2c-mux-gpio.h>
|
||||
#include <linux/platform_data/i2c-mux-gpio.h>
|
||||
#include <linux/platform_device.h>
|
||||
|
||||
static const unsigned myboard_gpiomux_gpios[] = {
|
||||
|
|
|
|||
|
|
@ -473,6 +473,24 @@ config option to 'y' no matter the dependencies.
|
|||
The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the
|
||||
situation where select forces a symbol equals to 'y'.
|
||||
|
||||
Adding features that need compiler support
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are several features that need compiler support. The recommended way
|
||||
to describe the dependency on the compiler feature is to use "depends on"
|
||||
followed by a test macro.
|
||||
|
||||
config STACKPROTECTOR
|
||||
bool "Stack Protector buffer overflow detection"
|
||||
depends on $(cc-option,-fstack-protector)
|
||||
...
|
||||
|
||||
If you need to expose a compiler capability to makefiles and/or C source files,
|
||||
CC_HAS_ is the recommended prefix for the config option.
|
||||
|
||||
config CC_HAS_STACKPROTECTOR_NONE
|
||||
def_bool $(cc-option,-fno-stack-protector)
|
||||
|
||||
Build as module only
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
To restrict a component build to module-only, qualify its config symbol
|
||||
|
|
|
|||
|
|
@ -724,8 +724,8 @@ migrate your tool to one of the following options:
|
|||
|
||||
See following documents:
|
||||
|
||||
- Documentation/trace/kprobetrace.txt
|
||||
- Documentation/trace/events.txt
|
||||
- Documentation/trace/kprobetrace.rst
|
||||
- Documentation/trace/events.rst
|
||||
- tools/perf/Documentation/perf-probe.txt
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -540,8 +540,10 @@ Events that are propagated by the driver to userspace:
|
|||
0x6021 ALARM: a sensor is too hot
|
||||
0x6022 ALARM: a sensor is extremely hot
|
||||
0x6030 System thermal table changed
|
||||
0x6032 Thermal Control command set completion (DYTC, Windows)
|
||||
0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED)
|
||||
0x60C0 X1 Yoga 2016, Tablet mode status changed
|
||||
0x60F0 Thermal Transformation changed (GMTS, Windows)
|
||||
|
||||
Battery nearly empty alarms are a last resort attempt to get the
|
||||
operating system to hibernate or shutdown cleanly (0x2313), or shutdown
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ named ``char-misc-next``, you would be using the following command::
|
|||
|
||||
that will create a signed tag called ``char-misc-4.15-rc1`` based on the
|
||||
last commit in the ``char-misc-next`` branch, and sign it with your gpg key
|
||||
(see :ref:`Documentation/maintainer/configure_git.rst <configuregit>`).
|
||||
(see :ref:`Documentation/maintainer/configure-git.rst <configuregit>`).
|
||||
|
||||
Linus will only accept pull requests based on a signed tag. Other
|
||||
maintainers may differ.
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ The Linux network devices (by default) just can handle the
|
|||
transmission and reception of media dependent frames. Due to the
|
||||
arbitration on the CAN bus the transmission of a low prio CAN-ID
|
||||
may be delayed by the reception of a high prio CAN frame. To
|
||||
reflect the correct [*]_ traffic on the node the loopback of the sent
|
||||
reflect the correct [#f1]_ traffic on the node the loopback of the sent
|
||||
data has to be performed right after a successful transmission. If
|
||||
the CAN network interface is not capable of performing the loopback for
|
||||
some reason the SocketCAN core can do this task as a fallback solution.
|
||||
|
|
@ -175,7 +175,7 @@ networking behaviour for CAN applications. Due to some requests from
|
|||
the RT-SocketCAN group the loopback optionally may be disabled for each
|
||||
separate socket. See sockopts from the CAN RAW sockets in :ref:`socketcan-raw-sockets`.
|
||||
|
||||
.. [*] you really like to have this when you're running analyser
|
||||
.. [#f1] you really like to have this when you're running analyser
|
||||
tools like 'candump' or 'cansniffer' on the (same) node.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,249 @@
|
|||
Supporting PMUs on RISC-V platforms
|
||||
==========================================
|
||||
Alan Kao <alankao@andestech.com>, Mar 2018
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
As of this writing, perf_event-related features mentioned in The RISC-V ISA
|
||||
Privileged Version 1.10 are as follows:
|
||||
(please check the manual for more details)
|
||||
|
||||
* [m|s]counteren
|
||||
* mcycle[h], cycle[h]
|
||||
* minstret[h], instret[h]
|
||||
* mhpeventx, mhpcounterx[h]
|
||||
|
||||
With such function set only, porting perf would require a lot of work, due to
|
||||
the lack of the following general architectural performance monitoring features:
|
||||
|
||||
* Enabling/Disabling counters
|
||||
Counters are just free-running all the time in our case.
|
||||
* Interrupt caused by counter overflow
|
||||
No such feature in the spec.
|
||||
* Interrupt indicator
|
||||
It is not possible to have many interrupt ports for all counters, so an
|
||||
interrupt indicator is required for software to tell which counter has
|
||||
just overflowed.
|
||||
* Writing to counters
|
||||
There will be an SBI to support this since the kernel cannot modify the
|
||||
counters [1]. Alternatively, some vendor considers to implement
|
||||
hardware-extension for M-S-U model machines to write counters directly.
|
||||
|
||||
This document aims to provide developers a quick guide on supporting their
|
||||
PMUs in the kernel. The following sections briefly explain perf' mechanism
|
||||
and todos.
|
||||
|
||||
You may check previous discussions here [1][2]. Also, it might be helpful
|
||||
to check the appendix for related kernel structures.
|
||||
|
||||
|
||||
1. Initialization
|
||||
-----------------
|
||||
|
||||
*riscv_pmu* is a global pointer of type *struct riscv_pmu*, which contains
|
||||
various methods according to perf's internal convention and PMU-specific
|
||||
parameters. One should declare such instance to represent the PMU. By default,
|
||||
*riscv_pmu* points to a constant structure *riscv_base_pmu*, which has very
|
||||
basic support to a baseline QEMU model.
|
||||
|
||||
Then he/she can either assign the instance's pointer to *riscv_pmu* so that
|
||||
the minimal and already-implemented logic can be leveraged, or invent his/her
|
||||
own *riscv_init_platform_pmu* implementation.
|
||||
|
||||
In other words, existing sources of *riscv_base_pmu* merely provide a
|
||||
reference implementation. Developers can flexibly decide how many parts they
|
||||
can leverage, and in the most extreme case, they can customize every function
|
||||
according to their needs.
|
||||
|
||||
|
||||
2. Event Initialization
|
||||
-----------------------
|
||||
|
||||
When a user launches a perf command to monitor some events, it is first
|
||||
interpreted by the userspace perf tool into multiple *perf_event_open*
|
||||
system calls, and then each of them calls to the body of *event_init*
|
||||
member function that was assigned in the previous step. In *riscv_base_pmu*'s
|
||||
case, it is *riscv_event_init*.
|
||||
|
||||
The main purpose of this function is to translate the event provided by user
|
||||
into bitmap, so that HW-related control registers or counters can directly be
|
||||
manipulated. The translation is based on the mappings and methods provided in
|
||||
*riscv_pmu*.
|
||||
|
||||
Note that some features can be done in this stage as well:
|
||||
|
||||
(1) interrupt setting, which is stated in the next section;
|
||||
(2) privilege level setting (user space only, kernel space only, both);
|
||||
(3) destructor setting. Normally it is sufficient to apply *riscv_destroy_event*;
|
||||
(4) tweaks for non-sampling events, which will be utilized by functions such as
|
||||
*perf_adjust_period*, usually something like the follows:
|
||||
|
||||
if (!is_sampling_event(event)) {
|
||||
hwc->sample_period = x86_pmu.max_period;
|
||||
hwc->last_period = hwc->sample_period;
|
||||
local64_set(&hwc->period_left, hwc->sample_period);
|
||||
}
|
||||
|
||||
In the case of *riscv_base_pmu*, only (3) is provided for now.
|
||||
|
||||
|
||||
3. Interrupt
|
||||
------------
|
||||
|
||||
3.1. Interrupt Initialization
|
||||
|
||||
This often occurs at the beginning of the *event_init* method. In common
|
||||
practice, this should be a code segment like
|
||||
|
||||
int x86_reserve_hardware(void)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
if (!atomic_inc_not_zero(&pmc_refcount)) {
|
||||
mutex_lock(&pmc_reserve_mutex);
|
||||
if (atomic_read(&pmc_refcount) == 0) {
|
||||
if (!reserve_pmc_hardware())
|
||||
err = -EBUSY;
|
||||
else
|
||||
reserve_ds_buffers();
|
||||
}
|
||||
if (!err)
|
||||
atomic_inc(&pmc_refcount);
|
||||
mutex_unlock(&pmc_reserve_mutex);
|
||||
}
|
||||
|
||||
return err;
|
||||
}
|
||||
|
||||
And the magic is in *reserve_pmc_hardware*, which usually does atomic
|
||||
operations to make implemented IRQ accessible from some global function pointer.
|
||||
*release_pmc_hardware* serves the opposite purpose, and it is used in event
|
||||
destructors mentioned in previous section.
|
||||
|
||||
(Note: From the implementations in all the architectures, the *reserve/release*
|
||||
pair are always IRQ settings, so the *pmc_hardware* seems somehow misleading.
|
||||
It does NOT deal with the binding between an event and a physical counter,
|
||||
which will be introduced in the next section.)
|
||||
|
||||
3.2. IRQ Structure
|
||||
|
||||
Basically, a IRQ runs the following pseudo code:
|
||||
|
||||
for each hardware counter that triggered this overflow
|
||||
|
||||
get the event of this counter
|
||||
|
||||
// following two steps are defined as *read()*,
|
||||
// check the section Reading/Writing Counters for details.
|
||||
count the delta value since previous interrupt
|
||||
update the event->count (# event occurs) by adding delta, and
|
||||
event->hw.period_left by subtracting delta
|
||||
|
||||
if the event overflows
|
||||
sample data
|
||||
set the counter appropriately for the next overflow
|
||||
|
||||
if the event overflows again
|
||||
too frequently, throttle this event
|
||||
fi
|
||||
fi
|
||||
|
||||
end for
|
||||
|
||||
However as of this writing, none of the RISC-V implementations have designed an
|
||||
interrupt for perf, so the details are to be completed in the future.
|
||||
|
||||
4. Reading/Writing Counters
|
||||
---------------------------
|
||||
|
||||
They seem symmetric but perf treats them quite differently. For reading, there
|
||||
is a *read* interface in *struct pmu*, but it serves more than just reading.
|
||||
According to the context, the *read* function not only reads the content of the
|
||||
counter (event->count), but also updates the left period to the next interrupt
|
||||
(event->hw.period_left).
|
||||
|
||||
But the core of perf does not need direct write to counters. Writing counters
|
||||
is hidden behind the abstraction of 1) *pmu->start*, literally start counting so one
|
||||
has to set the counter to a good value for the next interrupt; 2) inside the IRQ
|
||||
it should set the counter to the same resonable value.
|
||||
|
||||
Reading is not a problem in RISC-V but writing would need some effort, since
|
||||
counters are not allowed to be written by S-mode.
|
||||
|
||||
|
||||
5. add()/del()/start()/stop()
|
||||
-----------------------------
|
||||
|
||||
Basic idea: add()/del() adds/deletes events to/from a PMU, and start()/stop()
|
||||
starts/stop the counter of some event in the PMU. All of them take the same
|
||||
arguments: *struct perf_event *event* and *int flag*.
|
||||
|
||||
Consider perf as a state machine, then you will find that these functions serve
|
||||
as the state transition process between those states.
|
||||
Three states (event->hw.state) are defined:
|
||||
|
||||
* PERF_HES_STOPPED: the counter is stopped
|
||||
* PERF_HES_UPTODATE: the event->count is up-to-date
|
||||
* PERF_HES_ARCH: arch-dependent usage ... we don't need this for now
|
||||
|
||||
A normal flow of these state transitions are as follows:
|
||||
|
||||
* A user launches a perf event, resulting in calling to *event_init*.
|
||||
* When being context-switched in, *add* is called by the perf core, with a flag
|
||||
PERF_EF_START, which means that the event should be started after it is added.
|
||||
At this stage, a general event is bound to a physical counter, if any.
|
||||
The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, because it is now
|
||||
stopped, and the (software) event count does not need updating.
|
||||
** *start* is then called, and the counter is enabled.
|
||||
With flag PERF_EF_RELOAD, it writes an appropriate value to the counter (check
|
||||
previous section for detail).
|
||||
Nothing is written if the flag does not contain PERF_EF_RELOAD.
|
||||
The state now is reset to none, because it is neither stopped nor updated
|
||||
(the counting already started)
|
||||
* When being context-switched out, *del* is called. It then checks out all the
|
||||
events in the PMU and calls *stop* to update their counts.
|
||||
** *stop* is called by *del*
|
||||
and the perf core with flag PERF_EF_UPDATE, and it often shares the same
|
||||
subroutine as *read* with the same logic.
|
||||
The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, again.
|
||||
|
||||
** Life cycle of these two pairs: *add* and *del* are called repeatedly as
|
||||
tasks switch in-and-out; *start* and *stop* is also called when the perf core
|
||||
needs a quick stop-and-start, for instance, when the interrupt period is being
|
||||
adjusted.
|
||||
|
||||
Current implementation is sufficient for now and can be easily extended to
|
||||
features in the future.
|
||||
|
||||
A. Related Structures
|
||||
---------------------
|
||||
|
||||
* struct pmu: include/linux/perf_event.h
|
||||
* struct riscv_pmu: arch/riscv/include/asm/perf_event.h
|
||||
|
||||
Both structures are designed to be read-only.
|
||||
|
||||
*struct pmu* defines some function pointer interfaces, and most of them take
|
||||
*struct perf_event* as a main argument, dealing with perf events according to
|
||||
perf's internal state machine (check kernel/events/core.c for details).
|
||||
|
||||
*struct riscv_pmu* defines PMU-specific parameters. The naming follows the
|
||||
convention of all other architectures.
|
||||
|
||||
* struct perf_event: include/linux/perf_event.h
|
||||
* struct hw_perf_event
|
||||
|
||||
The generic structure that represents perf events, and the hardware-related
|
||||
details.
|
||||
|
||||
* struct riscv_hw_events: arch/riscv/include/asm/perf_event.h
|
||||
|
||||
The structure that holds the status of events, has two fixed members:
|
||||
the number of events and the array of the events.
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
[1] https://github.com/riscv/riscv-linux/pull/124
|
||||
[2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/f19TmCNP6yA
|
||||
|
|
@ -156,7 +156,7 @@ The classic stack buffer overflow involves writing past the expected end
|
|||
of a variable stored on the stack, ultimately writing a controlled value
|
||||
to the stack frame's stored return address. The most widely used defense
|
||||
is the presence of a stack canary between the stack variables and the
|
||||
return address (``CONFIG_CC_STACKPROTECTOR``), which is verified just before
|
||||
return address (``CONFIG_STACKPROTECTOR``), which is verified just before
|
||||
the function returns. Other defenses include things like shadow stacks.
|
||||
|
||||
Stack depth overflow
|
||||
|
|
|
|||
|
|
@ -53,8 +53,6 @@ from docutils.utils import SystemMessagePropagation
|
|||
# common globals
|
||||
# ==============================================================================
|
||||
|
||||
# The version numbering follows numbering of the specification
|
||||
# (Documentation/books/kernel-doc-HOWTO).
|
||||
__version__ = '1.0'
|
||||
|
||||
PY3 = sys.version_info[0] == 3
|
||||
|
|
|
|||
|
|
@ -426,5 +426,5 @@ root@genericarmv8:~#
|
|||
Details on how to use the generic STM API can be found here [2].
|
||||
|
||||
[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
|
||||
[2]. Documentation/trace/stm.txt
|
||||
[2]. Documentation/trace/stm.rst
|
||||
[3]. https://github.com/Linaro/perf-opencsd
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Event Tracing
|
|||
1. Introduction
|
||||
===============
|
||||
|
||||
Tracepoints (see Documentation/trace/tracepoints.txt) can be used
|
||||
Tracepoints (see Documentation/trace/tracepoints.rst) can be used
|
||||
without creating custom kernel modules to register probe functions
|
||||
using the event tracing infrastructure.
|
||||
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ If @buf is NULL and reset is set, all functions will be enabled for tracing.
|
|||
The @buf can also be a glob expression to enable all functions that
|
||||
match a specific pattern.
|
||||
|
||||
See Filter Commands in :file:`Documentation/trace/ftrace.txt`.
|
||||
See Filter Commands in :file:`Documentation/trace/ftrace.rst`.
|
||||
|
||||
To just trace the schedule function:
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
|
||||
Histogram triggers are special event triggers that can be used to
|
||||
aggregate trace event data into histograms. For information on
|
||||
trace events and event triggers, see Documentation/trace/events.txt.
|
||||
trace events and event triggers, see Documentation/trace/events.rst.
|
||||
|
||||
|
||||
2. Histogram Trigger Command
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ description is at Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth.
|
|||
|
||||
STH registers an stm class device, through which it provides interface
|
||||
to userspace and kernelspace software trace sources. See
|
||||
Documentation/trace/stm.txt for more information on that.
|
||||
Documentation/trace/stm.rst for more information on that.
|
||||
|
||||
MSU can be configured to collect trace data into a system memory
|
||||
buffer, which can later on be read from its device nodes via read() or
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Notes on Analysing Behaviour Using Events and Tracepoints
|
|||
1. Introduction
|
||||
===============
|
||||
|
||||
Tracepoints (see Documentation/trace/tracepoints.txt) can be used without
|
||||
Tracepoints (see Documentation/trace/tracepoints.rst) can be used without
|
||||
creating custom kernel modules to register probe functions using the event
|
||||
tracing infrastructure.
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ simple case of::
|
|||
3.1 System-Wide Event Enabling
|
||||
------------------------------
|
||||
|
||||
See Documentation/trace/events.txt for a proper description on how events
|
||||
See Documentation/trace/events.rst for a proper description on how events
|
||||
can be enabled system-wide. A short example of enabling all events related
|
||||
to page allocation would look something like::
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ at that point.
|
|||
3.4 Local Event Enabling
|
||||
------------------------
|
||||
|
||||
Documentation/trace/ftrace.txt describes how to enable events on a per-thread
|
||||
Documentation/trace/ftrace.rst describes how to enable events on a per-thread
|
||||
basis using set_ftrace_pid.
|
||||
|
||||
3.5 Local Event Enablement with PCL
|
||||
|
|
@ -137,7 +137,7 @@ basis using PCL such as follows.
|
|||
4. Event Filtering
|
||||
==================
|
||||
|
||||
Documentation/trace/ftrace.txt covers in-depth how to filter events in
|
||||
Documentation/trace/ftrace.rst covers in-depth how to filter events in
|
||||
ftrace. Obviously using grep and awk of trace_pipe is an option as well
|
||||
as any script reading trace_pipe.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
NOTE:
|
||||
This is a version of Documentation/HOWTO translated into Japanese.
|
||||
This is a version of Documentation/process/howto.rst translated into Japanese.
|
||||
This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
|
||||
If you find any difference between this document and the original file or
|
||||
a problem with the translation, please contact the maintainer of this file.
|
||||
|
|
@ -109,7 +109,7 @@ linux-api@vger.kernel.org に送ることを勧めます。
|
|||
ています。 カーネルに関して初めての人はここからスタートすると良い
|
||||
でしょう。
|
||||
|
||||
:ref:`Documentation/Process/changes.rst <changes>`
|
||||
:ref:`Documentation/process/changes.rst <changes>`
|
||||
このファイルはカーネルをうまく生成(訳注 build )し、走らせるのに最
|
||||
小限のレベルで必要な数々のソフトウェアパッケージの一覧を示してい
|
||||
ます。
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
|
|||
독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기
|
||||
때문이다.
|
||||
|
||||
:ref:`Documentation/process/stable_kernel_rules.rst <stable_kernel_rules>`
|
||||
:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
|
||||
이 문서는 안정적인 커널 배포가 이루어지는 규칙을 설명하고 있으며
|
||||
여러분들이 이러한 배포들 중 하나에 변경을 하길 원한다면
|
||||
무엇을 해야 하는지를 설명한다.
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ Linux 2.6:
|
|||
程序测试的指导，请参阅
|
||||
Documentation/power/drivers-testing.txt。有关驱动程序电
|
||||
源管理问题相对全面的概述，请参阅
|
||||
Documentation/power/admin-guide/devices.rst。
|
||||
Documentation/driver-api/pm/devices.rst。
|
||||
|
||||
管理： 如果一个驱动程序的作者还在进行有效的维护，那么通常除了那
|
||||
些明显正确且不需要任何检查的补丁以外，其他所有的补丁都会
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Chinese translated version of Documentation/gpio.txt
|
||||
Chinese translated version of Documentation/gpio
|
||||
|
||||
If you have any comment or update to the content, please contact the
|
||||
original document maintainer directly. However, if you have a problem
|
||||
|
|
@ -10,7 +10,7 @@ Maintainer: Grant Likely <grant.likely@secretlab.ca>
|
|||
Linus Walleij <linus.walleij@linaro.org>
|
||||
Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/gpio.txt 的中文翻译
|
||||
Documentation/gpio 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Chinese translated version of Documentation/io_orderings.txt
|
||||
Chinese translated version of Documentation/io_ordering.txt
|
||||
|
||||
If you have any comment or update to the content, please contact the
|
||||
original document maintainer directly. However, if you have a problem
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Chinese translated version of Documentation/magic-number.txt
|
||||
Chinese translated version of Documentation/process/magic-number.rst
|
||||
|
||||
If you have any comment or update to the content, please post to LKML directly.
|
||||
However, if you have problem communicating in English you can also ask the
|
||||
|
|
@ -7,7 +7,7 @@ translation is outdated or there is problem with translation.
|
|||
|
||||
Chinese maintainer: Jia Wei Wei <harryxiyou@gmail.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/magic-number.txt的中文翻译
|
||||
Documentation/process/magic-number.rst的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接发信到LKML。如果你使用英文交流有困难的话，也可
|
||||
以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版维护者。
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Chinese translated version of Documentation/video4linux/omap3isp.txt
|
||||
Chinese translated version of Documentation/media/v4l-drivers/omap3isp.rst
|
||||
|
||||
If you have any comment or update to the content, please contact the
|
||||
original document maintainer directly. However, if you have a problem
|
||||
|
|
@ -11,7 +11,7 @@ Maintainer: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|||
David Cohen <dacohen@gmail.com>
|
||||
Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/video4linux/omap3isp.txt 的中文翻译
|
||||
Documentation/media/v4l-drivers/omap3isp.rst 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Chinese translated version of Documentation/video4linux/v4l2-framework.txt
|
||||
Chinese translated version of Documentation/media/media_kapi.rst
|
||||
|
||||
If you have any comment or update to the content, please contact the
|
||||
original document maintainer directly. However, if you have a problem
|
||||
|
|
@ -9,7 +9,7 @@ or if there is a problem with the translation.
|
|||
Maintainer: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/video4linux/v4l2-framework.txt 的中文翻译
|
||||
Documentation/media/media_kapi.rst 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
|
|
@ -777,7 +777,7 @@ v4l2 核心 API 提供了一个处理视频缓冲的标准方法(称为“videob
|
|||
线性 DMA(videobuf-dma-contig)以及大多用于 USB 设备的用 vmalloc
|
||||
分配的缓冲(videobuf-vmalloc)。
|
||||
|
||||
请参阅 Documentation/video4linux/videobuf，以获得更多关于 videobuf
|
||||
请参阅 Documentation/media/kapi/v4l2-videobuf.rst，以获得更多关于 videobuf
|
||||
层的使用信息。
|
||||
|
||||
v4l2_fh 结构体
|
||||
|
|
|
|||
|
|
@ -145,6 +145,11 @@ The functions in the mdev_parent_ops structure are as follows:
|
|||
* create: allocate basic resources in a driver for a mediated device
|
||||
* remove: free resources in a driver when a mediated device is destroyed
|
||||
|
||||
(Note that mdev-core provides no implicit serialization of create/remove
|
||||
callbacks per mdev parent device, per mdev type, or any other categorization.
|
||||
Vendor drivers are expected to be fully asynchronous in this respect or
|
||||
provide their own internal resource protection.)
|
||||
|
||||
The callbacks in the mdev_parent_ops structure are as follows:
|
||||
|
||||
* open: open callback of mediated device
|
||||
|
|
|
|||
|
|
@ -1269,12 +1269,18 @@ struct kvm_cpuid_entry2 {
|
|||
__u32 padding[3];
|
||||
};
|
||||
|
||||
This ioctl returns x86 cpuid features which are supported by both the hardware
|
||||
and kvm. Userspace can use the information returned by this ioctl to
|
||||
construct cpuid information (for KVM_SET_CPUID2) that is consistent with
|
||||
hardware, kernel, and userspace capabilities, and with user requirements (for
|
||||
example, the user may wish to constrain cpuid to emulate older hardware,
|
||||
or for feature consistency across a cluster).
|
||||
This ioctl returns x86 cpuid features which are supported by both the
|
||||
hardware and kvm in its default configuration. Userspace can use the
|
||||
information returned by this ioctl to construct cpuid information (for
|
||||
KVM_SET_CPUID2) that is consistent with hardware, kernel, and
|
||||
userspace capabilities, and with user requirements (for example, the
|
||||
user may wish to constrain cpuid to emulate older hardware, or for
|
||||
feature consistency across a cluster).
|
||||
|
||||
Note that certain capabilities, such as KVM_CAP_X86_DISABLE_EXITS, may
|
||||
expose cpuid features (e.g. MONITOR) which are not supported by kvm in
|
||||
its default configuration. If userspace enables such capabilities, it
|
||||
is responsible for modifying the results of this ioctl appropriately.
|
||||
|
||||
Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure
|
||||
with the 'nent' field indicating the number of entries in the variable-size
|
||||
|
|
@ -4603,3 +4609,12 @@ Architectures: s390
|
|||
This capability indicates that kvm will implement the interfaces to handle
|
||||
reset, migration and nested KVM for branch prediction blocking. The stfle
|
||||
facility 82 should not be provided to the guest without this capability.
|
||||
|
||||
8.14 KVM_CAP_HYPERV_TLBFLUSH
|
||||
|
||||
Architectures: x86
|
||||
|
||||
This capability indicates that KVM supports paravirtualized Hyper-V TLB Flush
|
||||
hypercalls:
|
||||
HvFlushVirtualAddressSpace, HvFlushVirtualAddressSpaceEx,
|
||||
HvFlushVirtualAddressList, HvFlushVirtualAddressListEx.
|
||||
|
|
|
|||
|
|
@ -27,16 +27,42 @@ Groups:
|
|||
VCPU and all of the redistributor pages are contiguous.
|
||||
Only valid for KVM_DEV_TYPE_ARM_VGIC_V3.
|
||||
This address needs to be 64K aligned.
|
||||
|
||||
KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION (rw, 64-bit)
|
||||
The attribute data pointed to by kvm_device_attr.addr is a __u64 value:
|
||||
bits: | 63 .... 52 | 51 .... 16 | 15 - 12 |11 - 0
|
||||
values: | count | base | flags | index
|
||||
- index encodes the unique redistributor region index
|
||||
- flags: reserved for future use, currently 0
|
||||
- base field encodes bits [51:16] of the guest physical base address
|
||||
of the first redistributor in the region.
|
||||
- count encodes the number of redistributors in the region. Must be
|
||||
greater than 0.
|
||||
There are two 64K pages for each redistributor in the region and
|
||||
redistributors are laid out contiguously within the region. Regions
|
||||
are filled with redistributors in the index order. The sum of all
|
||||
region count fields must be greater than or equal to the number of
|
||||
VCPUs. Redistributor regions must be registered in the incremental
|
||||
index order, starting from index 0.
|
||||
The characteristics of a specific redistributor region can be read
|
||||
by presetting the index field in the attr data.
|
||||
Only valid for KVM_DEV_TYPE_ARM_VGIC_V3.
|
||||
|
||||
It is invalid to mix calls with KVM_VGIC_V3_ADDR_TYPE_REDIST and
|
||||
KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attributes.
|
||||
|
||||
Errors:
|
||||
-E2BIG: Address outside of addressable IPA range
|
||||
-EINVAL: Incorrectly aligned address
|
||||
-EINVAL: Incorrectly aligned address, bad redistributor region
|
||||
count/index, mixed redistributor region attribute usage
|
||||
-EEXIST: Address already configured
|
||||
-ENOENT: Attempt to read the characteristics of a non existing
|
||||
redistributor region
|
||||
-ENXIO: The group or attribute is unknown/unsupported for this device
|
||||
or hardware support is missing.
|
||||
-EFAULT: Invalid user pointer for attr->addr.
|
||||
|
||||
|
||||
|
||||
KVM_DEV_ARM_VGIC_GRP_DIST_REGS
|
||||
KVM_DEV_ARM_VGIC_GRP_REDIST_REGS
|
||||
Attributes:
|
||||
|
|
|
|||
|
|
@ -49,8 +49,8 @@ The mmu supports first-generation mmu hardware, which allows an atomic switch
|
|||
of the current paging mode and cr3 during guest entry, as well as
|
||||
two-dimensional paging (AMD's NPT and Intel's EPT). The emulated hardware
|
||||
it exposes is the traditional 2/3/4 level x86 mmu, with support for global
|
||||
pages, pae, pse, pse36, cr0.wp, and 1GB pages. Work is in progress to support
|
||||
exposing NPT capable hardware on NPT capable hosts.
|
||||
pages, pae, pse, pse36, cr0.wp, and 1GB pages. Emulated hardware also
|
||||
able to expose NPT capable hardware on NPT capable hosts.
|
||||
|
||||
Translation
|
||||
===========
|
||||
|
|
@ -465,5 +465,5 @@ Further reading
|
|||
===============
|
||||
|
||||
- NPT presentation from KVM Forum 2008
|
||||
http://www.linux-kvm.org/wiki/images/c/c8/KvmForum2008%24kdf2008_21.pdf
|
||||
http://www.linux-kvm.org/images/c/c8/KvmForum2008%24kdf2008_21.pdf
|
||||
|
||||
|
|
|
|||
|
|
@ -31,17 +31,6 @@ L0, the guest hypervisor, which we call L1, and its nested guest, which we
|
|||
call L2.
|
||||
|
||||
|
||||
Known limitations
|
||||
-----------------
|
||||
|
||||
The current code supports running Linux guests under KVM guests.
|
||||
Only 64-bit guest hypervisors are supported.
|
||||
|
||||
Additional patches for running Windows under guest KVM, and Linux under
|
||||
guest VMware server, and support for nested EPT, are currently running in
|
||||
the lab, and will be sent as follow-on patchsets.
|
||||
|
||||
|
||||
Running nested VMX
|
||||
------------------
|
||||
|
||||
|
|
|
|||
157
MAINTAINERS
157
MAINTAINERS
|
|
@ -1732,7 +1732,8 @@ F: arch/arm/mach-npcm/
|
|||
F: arch/arm/boot/dts/nuvoton-npcm*
|
||||
F: include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
|
||||
F: drivers/*/*npcm*
|
||||
F: Documentation/*/*npcm*
|
||||
F: Documentation/devicetree/bindings/*/*npcm*
|
||||
F: Documentation/devicetree/bindings/*/*/*npcm*
|
||||
|
||||
ARM/NUVOTON W90X900 ARM ARCHITECTURE
|
||||
M: Wan ZongShun <mcuos.com@gmail.com>
|
||||
|
|
@ -3079,7 +3080,7 @@ M: Clemens Ladisch <clemens@ladisch.de>
|
|||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
T: git git://git.alsa-project.org/alsa-kernel.git
|
||||
S: Maintained
|
||||
F: Documentation/sound/alsa/Bt87x.txt
|
||||
F: Documentation/sound/cards/bt87x.rst
|
||||
F: sound/pci/bt87x.c
|
||||
|
||||
BT8XXGPIO DRIVER
|
||||
|
|
@ -3375,7 +3376,7 @@ M: David Howells <dhowells@redhat.com>
|
|||
M: David Woodhouse <dwmw2@infradead.org>
|
||||
L: keyrings@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/module-signing.txt
|
||||
F: Documentation/admin-guide/module-signing.rst
|
||||
F: certs/
|
||||
F: scripts/sign-file.c
|
||||
F: scripts/extract-cert.c
|
||||
|
|
@ -4513,7 +4514,7 @@ DRM DRIVER FOR ILITEK ILI9225 PANELS
|
|||
M: David Lechner <david@lechnology.com>
|
||||
S: Maintained
|
||||
F: drivers/gpu/drm/tinydrm/ili9225.c
|
||||
F: Documentation/devicetree/bindings/display/ili9225.txt
|
||||
F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
|
||||
|
||||
DRM DRIVER FOR INTEL I810 VIDEO CARDS
|
||||
S: Orphan / Obsolete
|
||||
|
|
@ -4599,13 +4600,13 @@ DRM DRIVER FOR SITRONIX ST7586 PANELS
|
|||
M: David Lechner <david@lechnology.com>
|
||||
S: Maintained
|
||||
F: drivers/gpu/drm/tinydrm/st7586.c
|
||||
F: Documentation/devicetree/bindings/display/st7586.txt
|
||||
F: Documentation/devicetree/bindings/display/sitronix,st7586.txt
|
||||
|
||||
DRM DRIVER FOR SITRONIX ST7735R PANELS
|
||||
M: David Lechner <david@lechnology.com>
|
||||
S: Maintained
|
||||
F: drivers/gpu/drm/tinydrm/st7735r.c
|
||||
F: Documentation/devicetree/bindings/display/st7735r.txt
|
||||
F: Documentation/devicetree/bindings/display/sitronix,st7735r.txt
|
||||
|
||||
DRM DRIVER FOR TDFX VIDEO CARDS
|
||||
S: Orphan / Obsolete
|
||||
|
|
@ -4638,7 +4639,6 @@ F: drivers/gpu/drm/
|
|||
F: drivers/gpu/vga/
|
||||
F: Documentation/devicetree/bindings/display/
|
||||
F: Documentation/devicetree/bindings/gpu/
|
||||
F: Documentation/devicetree/bindings/video/
|
||||
F: Documentation/gpu/
|
||||
F: include/drm/
|
||||
F: include/uapi/drm/
|
||||
|
|
@ -4683,7 +4683,7 @@ M: Boris Brezillon <boris.brezillon@bootlin.com>
|
|||
L: dri-devel@lists.freedesktop.org
|
||||
S: Supported
|
||||
F: drivers/gpu/drm/atmel-hlcdc/
|
||||
F: Documentation/devicetree/bindings/drm/atmel/
|
||||
F: Documentation/devicetree/bindings/display/atmel/
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
|
||||
DRM DRIVERS FOR BRIDGE CHIPS
|
||||
|
|
@ -4714,7 +4714,7 @@ S: Supported
|
|||
F: drivers/gpu/drm/fsl-dcu/
|
||||
F: Documentation/devicetree/bindings/display/fsl,dcu.txt
|
||||
F: Documentation/devicetree/bindings/display/fsl,tcon.txt
|
||||
F: Documentation/devicetree/bindings/display/panel/nec,nl4827hc19_05b.txt
|
||||
F: Documentation/devicetree/bindings/display/panel/nec,nl4827hc19-05b.txt
|
||||
|
||||
DRM DRIVERS FOR FREESCALE IMX
|
||||
M: Philipp Zabel <p.zabel@pengutronix.de>
|
||||
|
|
@ -4824,7 +4824,7 @@ M: Eric Anholt <eric@anholt.net>
|
|||
S: Supported
|
||||
F: drivers/gpu/drm/v3d/
|
||||
F: include/uapi/drm/v3d_drm.h
|
||||
F: Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
|
||||
F: Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
|
||||
DRM DRIVERS FOR VC4
|
||||
|
|
@ -5735,7 +5735,7 @@ M: Madalin Bucur <madalin.bucur@nxp.com>
|
|||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/ethernet/freescale/fman
|
||||
F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
|
||||
F: Documentation/devicetree/bindings/net/fsl-fman.txt
|
||||
|
||||
FREESCALE QORIQ PTP CLOCK DRIVER
|
||||
M: Yangbo Lu <yangbo.lu@nxp.com>
|
||||
|
|
@ -5953,14 +5953,14 @@ GENERIC GPIO I2C DRIVER
|
|||
M: Haavard Skinnemoen <hskinnemoen@gmail.com>
|
||||
S: Supported
|
||||
F: drivers/i2c/busses/i2c-gpio.c
|
||||
F: include/linux/i2c-gpio.h
|
||||
F: include/linux/platform_data/i2c-gpio.h
|
||||
|
||||
GENERIC GPIO I2C MULTIPLEXER DRIVER
|
||||
M: Peter Korsgaard <peter.korsgaard@barco.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/i2c/muxes/i2c-mux-gpio.c
|
||||
F: include/linux/i2c-mux-gpio.h
|
||||
F: include/linux/platform_data/i2c-mux-gpio.h
|
||||
F: Documentation/i2c/muxes/i2c-mux-gpio
|
||||
|
||||
GENERIC HDLC (WAN) DRIVERS
|
||||
|
|
@ -6501,7 +6501,7 @@ L: linux-mm@kvack.org
|
|||
S: Maintained
|
||||
F: mm/hmm*
|
||||
F: include/linux/hmm*
|
||||
F: Documentation/vm/hmm.txt
|
||||
F: Documentation/vm/hmm.rst
|
||||
|
||||
HOST AP DRIVER
|
||||
M: Jouni Malinen <j@w1.fi>
|
||||
|
|
@ -6620,7 +6620,7 @@ F: arch/x86/hyperv
|
|||
F: drivers/hid/hid-hyperv.c
|
||||
F: drivers/hv/
|
||||
F: drivers/input/serio/hyperv-keyboard.c
|
||||
F: drivers/pci/host/pci-hyperv.c
|
||||
F: drivers/pci/controller/pci-hyperv.c
|
||||
F: drivers/net/hyperv/
|
||||
F: drivers/scsi/storvsc_drv.c
|
||||
F: drivers/uio/uio_hv_generic.c
|
||||
|
|
@ -6966,7 +6966,7 @@ IIO MULTIPLEXER
|
|||
M: Peter Rosin <peda@axentia.se>
|
||||
L: linux-iio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
|
||||
F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
|
||||
F: drivers/iio/multiplexer/iio-mux.c
|
||||
|
||||
IIO SUBSYSTEM AND DRIVERS
|
||||
|
|
@ -7401,7 +7401,7 @@ F: drivers/platform/x86/intel-wmi-thunderbolt.c
|
|||
INTEL(R) TRACE HUB
|
||||
M: Alexander Shishkin <alexander.shishkin@linux.intel.com>
|
||||
S: Supported
|
||||
F: Documentation/trace/intel_th.txt
|
||||
F: Documentation/trace/intel_th.rst
|
||||
F: drivers/hwtracing/intel_th/
|
||||
|
||||
INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
|
||||
|
|
@ -7425,7 +7425,7 @@ M: Linus Walleij <linus.walleij@linaro.org>
|
|||
L: linux-iio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/iio/gyro/mpu3050*
|
||||
F: Documentation/devicetree/bindings/iio/gyroscope/inv,mpu3050.txt
|
||||
F: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.txt
|
||||
|
||||
IOC3 ETHERNET DRIVER
|
||||
M: Ralf Baechle <ralf@linux-mips.org>
|
||||
|
|
@ -8700,7 +8700,7 @@ M: Guenter Roeck <linux@roeck-us.net>
|
|||
L: linux-hwmon@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/hwmon/max6697
|
||||
F: Documentation/devicetree/bindings/i2c/max6697.txt
|
||||
F: Documentation/devicetree/bindings/hwmon/max6697.txt
|
||||
F: drivers/hwmon/max6697.c
|
||||
F: include/linux/platform_data/max6697.h
|
||||
|
||||
|
|
@ -9080,7 +9080,7 @@ M: Martin Donnelly <martin.donnelly@ge.com>
|
|||
M: Martyn Welch <martyn.welch@collabora.co.uk>
|
||||
S: Maintained
|
||||
F: drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c
|
||||
F: Documentation/devicetree/bindings/video/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
|
||||
F: Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
|
||||
|
||||
MEGARAID SCSI/SAS DRIVERS
|
||||
M: Kashyap Desai <kashyap.desai@broadcom.com>
|
||||
|
|
@ -9417,10 +9417,12 @@ F: drivers/usb/image/microtek.*
|
|||
|
||||
MIPS
|
||||
M: Ralf Baechle <ralf@linux-mips.org>
|
||||
M: Paul Burton <paul.burton@mips.com>
|
||||
M: James Hogan <jhogan@kernel.org>
|
||||
L: linux-mips@linux-mips.org
|
||||
W: http://www.linux-mips.org/
|
||||
T: git git://git.linux-mips.org/pub/scm/ralf/linux.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git
|
||||
Q: http://patchwork.linux-mips.org/project/linux-mips/list/
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/mips/
|
||||
|
|
@ -9522,7 +9524,7 @@ M: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/pci/mobiveil-pcie.txt
|
||||
F: drivers/pci/host/pcie-mobiveil.c
|
||||
F: drivers/pci/controller/pcie-mobiveil.c
|
||||
|
||||
MODULE SUPPORT
|
||||
M: Jessica Yu <jeyu@kernel.org>
|
||||
|
|
@ -9663,7 +9665,7 @@ F: include/uapi/linux/mmc/
|
|||
MULTIPLEXER SUBSYSTEM
|
||||
M: Peter Rosin <peda@axentia.se>
|
||||
S: Maintained
|
||||
F: Documentation/ABI/testing/mux/sysfs-class-mux*
|
||||
F: Documentation/ABI/testing/sysfs-class-mux*
|
||||
F: Documentation/devicetree/bindings/mux/
|
||||
F: include/linux/dt-bindings/mux/
|
||||
F: include/linux/mux/
|
||||
|
|
@ -9694,7 +9696,7 @@ MXSFB DRM DRIVER
|
|||
M: Marek Vasut <marex@denx.de>
|
||||
S: Supported
|
||||
F: drivers/gpu/drm/mxsfb/
|
||||
F: Documentation/devicetree/bindings/display/mxsfb-drm.txt
|
||||
F: Documentation/devicetree/bindings/display/mxsfb.txt
|
||||
|
||||
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
|
||||
M: Chris Lee <christopher.lee@cspi.com>
|
||||
|
|
@ -10242,7 +10244,7 @@ F: arch/powerpc/include/asm/pnv-ocxl.h
|
|||
F: drivers/misc/ocxl/
|
||||
F: include/misc/ocxl*
|
||||
F: include/uapi/misc/ocxl.h
|
||||
F: Documentation/accelerators/ocxl.txt
|
||||
F: Documentation/accelerators/ocxl.rst
|
||||
|
||||
OMAP AUDIO SUPPORT
|
||||
M: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
|
|
@ -10271,18 +10273,16 @@ F: arch/arm/boot/dts/*am5*
|
|||
F: arch/arm/boot/dts/*dra7*
|
||||
|
||||
OMAP DISPLAY SUBSYSTEM and FRAMEBUFFER SUPPORT (DSS2)
|
||||
M: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: drivers/video/fbdev/omap2/
|
||||
F: Documentation/arm/OMAP/DSS
|
||||
|
||||
OMAP FRAMEBUFFER SUPPORT
|
||||
M: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: drivers/video/fbdev/omap/
|
||||
|
||||
OMAP GENERAL PURPOSE MEMORY CONTROLLER SUPPORT
|
||||
|
|
@ -10390,7 +10390,7 @@ F: arch/arm/mach-omap1/
|
|||
F: arch/arm/plat-omap/
|
||||
F: arch/arm/configs/omap1_defconfig
|
||||
F: drivers/i2c/busses/i2c-omap.c
|
||||
F: include/linux/i2c-omap.h
|
||||
F: include/linux/platform_data/i2c-omap.h
|
||||
|
||||
OMAP2+ SUPPORT
|
||||
M: Tony Lindgren <tony@atomide.com>
|
||||
|
|
@ -10422,7 +10422,7 @@ F: drivers/regulator/tps65218-regulator.c
|
|||
F: drivers/regulator/tps65910-regulator.c
|
||||
F: drivers/regulator/twl-regulator.c
|
||||
F: drivers/regulator/twl6030-regulator.c
|
||||
F: include/linux/i2c-omap.h
|
||||
F: include/linux/platform_data/i2c-omap.h
|
||||
|
||||
ONION OMEGA2+ BOARD
|
||||
M: Harvey Hunt <harveyhuntnexus@gmail.com>
|
||||
|
|
@ -10726,7 +10726,7 @@ PARALLEL LCD/KEYPAD PANEL DRIVER
|
|||
M: Willy Tarreau <willy@haproxy.com>
|
||||
M: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
|
||||
S: Odd Fixes
|
||||
F: Documentation/misc-devices/lcd-panel-cgram.txt
|
||||
F: Documentation/auxdisplay/lcd-panel-cgram.txt
|
||||
F: drivers/misc/panel.c
|
||||
|
||||
PARALLEL PORT SUBSYSTEM
|
||||
|
|
@ -10827,7 +10827,7 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
|
||||
F: drivers/pci/host/pci-aardvark.c
|
||||
F: drivers/pci/controller/pci-aardvark.c
|
||||
|
||||
PCI DRIVER FOR ALTERA PCIE IP
|
||||
M: Ley Foon Tan <lftan@altera.com>
|
||||
|
|
@ -10835,7 +10835,7 @@ L: rfi@lists.rocketboards.org (moderated for non-subscribers)
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/pci/altera-pcie.txt
|
||||
F: drivers/pci/host/pcie-altera.c
|
||||
F: drivers/pci/controller/pcie-altera.c
|
||||
|
||||
PCI DRIVER FOR APPLIEDMICRO XGENE
|
||||
M: Tanmay Inamdar <tinamdar@apm.com>
|
||||
|
|
@ -10843,7 +10843,7 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/xgene-pci.txt
|
||||
F: drivers/pci/host/pci-xgene.c
|
||||
F: drivers/pci/controller/pci-xgene.c
|
||||
|
||||
PCI DRIVER FOR ARM VERSATILE PLATFORM
|
||||
M: Rob Herring <robh@kernel.org>
|
||||
|
|
@ -10851,7 +10851,7 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/versatile.txt
|
||||
F: drivers/pci/host/pci-versatile.c
|
||||
F: drivers/pci/controller/pci-versatile.c
|
||||
|
||||
PCI DRIVER FOR ARMADA 8K
|
||||
M: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
||||
|
|
@ -10859,14 +10859,14 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/pci-armada8k.txt
|
||||
F: drivers/pci/dwc/pcie-armada8k.c
|
||||
F: drivers/pci/controller/dwc/pcie-armada8k.c
|
||||
|
||||
PCI DRIVER FOR CADENCE PCIE IP
|
||||
M: Alan Douglas <adouglas@cadence.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/cdns,*.txt
|
||||
F: drivers/pci/cadence/pcie-cadence*
|
||||
F: drivers/pci/controller/pcie-cadence*
|
||||
|
||||
PCI DRIVER FOR FREESCALE LAYERSCAPE
|
||||
M: Minghuan Lian <minghuan.Lian@nxp.com>
|
||||
|
|
@ -10876,7 +10876,7 @@ L: linuxppc-dev@lists.ozlabs.org
|
|||
L: linux-pci@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
S: Maintained
|
||||
F: drivers/pci/dwc/*layerscape*
|
||||
F: drivers/pci/controller/dwc/*layerscape*
|
||||
|
||||
PCI DRIVER FOR GENERIC OF HOSTS
|
||||
M: Will Deacon <will.deacon@arm.com>
|
||||
|
|
@ -10884,8 +10884,8 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/host-generic-pci.txt
|
||||
F: drivers/pci/host/pci-host-common.c
|
||||
F: drivers/pci/host/pci-host-generic.c
|
||||
F: drivers/pci/controller/pci-host-common.c
|
||||
F: drivers/pci/controller/pci-host-generic.c
|
||||
|
||||
PCI DRIVER FOR IMX6
|
||||
M: Richard Zhu <hongxing.zhu@nxp.com>
|
||||
|
|
@ -10894,14 +10894,14 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
|
||||
F: drivers/pci/dwc/*imx6*
|
||||
F: drivers/pci/controller/dwc/*imx6*
|
||||
|
||||
PCI DRIVER FOR INTEL VOLUME MANAGEMENT DEVICE (VMD)
|
||||
M: Keith Busch <keith.busch@intel.com>
|
||||
M: Jonathan Derrick <jonathan.derrick@intel.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/pci/host/vmd.c
|
||||
F: drivers/pci/controller/vmd.c
|
||||
|
||||
PCI DRIVER FOR MICROSEMI SWITCHTEC
|
||||
M: Kurt Schwemmer <kurt.schwemmer@microsemi.com>
|
||||
|
|
@ -10921,7 +10921,7 @@ M: Jason Cooper <jason@lakedaemon.net>
|
|||
L: linux-pci@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: drivers/pci/host/*mvebu*
|
||||
F: drivers/pci/controller/*mvebu*
|
||||
|
||||
PCI DRIVER FOR NVIDIA TEGRA
|
||||
M: Thierry Reding <thierry.reding@gmail.com>
|
||||
|
|
@ -10929,14 +10929,14 @@ L: linux-tegra@vger.kernel.org
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
|
||||
F: drivers/pci/host/pci-tegra.c
|
||||
F: drivers/pci/controller/pci-tegra.c
|
||||
|
||||
PCI DRIVER FOR RENESAS R-CAR
|
||||
M: Simon Horman <horms@verge.net.au>
|
||||
L: linux-pci@vger.kernel.org
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/pci/host/*rcar*
|
||||
F: drivers/pci/controller/*rcar*
|
||||
|
||||
PCI DRIVER FOR SAMSUNG EXYNOS
|
||||
M: Jingoo Han <jingoohan1@gmail.com>
|
||||
|
|
@ -10944,7 +10944,7 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: drivers/pci/dwc/pci-exynos.c
|
||||
F: drivers/pci/controller/dwc/pci-exynos.c
|
||||
|
||||
PCI DRIVER FOR SYNOPSYS DESIGNWARE
|
||||
M: Jingoo Han <jingoohan1@gmail.com>
|
||||
|
|
@ -10952,7 +10952,7 @@ M: Joao Pinto <Joao.Pinto@synopsys.com>
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/designware-pcie.txt
|
||||
F: drivers/pci/dwc/*designware*
|
||||
F: drivers/pci/controller/dwc/*designware*
|
||||
|
||||
PCI DRIVER FOR TI DRA7XX
|
||||
M: Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
|
@ -10960,14 +10960,14 @@ L: linux-omap@vger.kernel.org
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/pci/ti-pci.txt
|
||||
F: drivers/pci/dwc/pci-dra7xx.c
|
||||
F: drivers/pci/controller/dwc/pci-dra7xx.c
|
||||
|
||||
PCI DRIVER FOR TI KEYSTONE
|
||||
M: Murali Karicheri <m-karicheri2@ti.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: drivers/pci/dwc/*keystone*
|
||||
F: drivers/pci/controller/dwc/*keystone*
|
||||
|
||||
PCI ENDPOINT SUBSYSTEM
|
||||
M: Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
|
@ -11000,7 +11000,7 @@ L: rfi@lists.rocketboards.org (moderated for non-subscribers)
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
|
||||
F: drivers/pci/host/pcie-altera-msi.c
|
||||
F: drivers/pci/controller/pcie-altera-msi.c
|
||||
|
||||
PCI MSI DRIVER FOR APPLIEDMICRO XGENE
|
||||
M: Duc Dang <dhdang@apm.com>
|
||||
|
|
@ -11008,7 +11008,7 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
|
||||
F: drivers/pci/host/pci-xgene-msi.c
|
||||
F: drivers/pci/controller/pci-xgene-msi.c
|
||||
|
||||
PCI SUBSYSTEM
|
||||
M: Bjorn Helgaas <bhelgaas@google.com>
|
||||
|
|
@ -11034,9 +11034,7 @@ L: linux-pci@vger.kernel.org
|
|||
Q: http://patchwork.ozlabs.org/project/linux-pci/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/
|
||||
S: Supported
|
||||
F: drivers/pci/cadence/
|
||||
F: drivers/pci/host/
|
||||
F: drivers/pci/dwc/
|
||||
F: drivers/pci/controller/
|
||||
|
||||
PCIE DRIVER FOR AXIS ARTPEC
|
||||
M: Jesper Nilsson <jesper.nilsson@axis.com>
|
||||
|
|
@ -11044,7 +11042,7 @@ L: linux-arm-kernel@axis.com
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/axis,artpec*
|
||||
F: drivers/pci/dwc/*artpec*
|
||||
F: drivers/pci/controller/dwc/*artpec*
|
||||
|
||||
PCIE DRIVER FOR CAVIUM THUNDERX
|
||||
M: David Daney <david.daney@cavium.com>
|
||||
|
|
@ -11052,22 +11050,22 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/pci/pci-thunder-*
|
||||
F: drivers/pci/host/pci-thunder-*
|
||||
F: drivers/pci/controller/pci-thunder-*
|
||||
|
||||
PCIE DRIVER FOR HISILICON
|
||||
M: Zhou Wang <wangzhou1@hisilicon.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
|
||||
F: drivers/pci/dwc/pcie-hisi.c
|
||||
F: drivers/pci/controller/dwc/pcie-hisi.c
|
||||
|
||||
PCIE DRIVER FOR HISILICON KIRIN
|
||||
M: Xiaowei Song <songxiaowei@hisilicon.com>
|
||||
M: Binghui Wang <wangbinghui@hisilicon.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/pcie-kirin.txt
|
||||
F: drivers/pci/dwc/pcie-kirin.c
|
||||
F: Documentation/devicetree/bindings/pci/kirin-pcie.txt
|
||||
F: drivers/pci/controller/dwc/pcie-kirin.c
|
||||
|
||||
PCIE DRIVER FOR HISILICON STB
|
||||
M: Jianguo Sun <sunjianguo1@huawei.com>
|
||||
|
|
@ -11075,7 +11073,7 @@ M: Shawn Guo <shawn.guo@linaro.org>
|
|||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt
|
||||
F: drivers/pci/dwc/pcie-histb.c
|
||||
F: drivers/pci/controller/dwc/pcie-histb.c
|
||||
|
||||
PCIE DRIVER FOR MEDIATEK
|
||||
M: Ryder Lee <ryder.lee@mediatek.com>
|
||||
|
|
@ -11083,14 +11081,14 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-mediatek@lists.infradead.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/pci/mediatek*
|
||||
F: drivers/pci/host/*mediatek*
|
||||
F: drivers/pci/controller/*mediatek*
|
||||
|
||||
PCIE DRIVER FOR QUALCOMM MSM
|
||||
M: Stanimir Varbanov <svarbanov@mm-sol.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/pci/dwc/*qcom*
|
||||
F: drivers/pci/controller/dwc/*qcom*
|
||||
|
||||
PCIE DRIVER FOR ROCKCHIP
|
||||
M: Shawn Lin <shawn.lin@rock-chips.com>
|
||||
|
|
@ -11098,20 +11096,20 @@ L: linux-pci@vger.kernel.org
|
|||
L: linux-rockchip@lists.infradead.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/rockchip-pcie*
|
||||
F: drivers/pci/host/pcie-rockchip*
|
||||
F: drivers/pci/controller/pcie-rockchip*
|
||||
|
||||
PCI DRIVER FOR V3 SEMICONDUCTOR V360EPC
|
||||
M: Linus Walleij <linus.walleij@linaro.org>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
|
||||
F: drivers/pci/host/pci-v3-semi.c
|
||||
F: drivers/pci/controller/pci-v3-semi.c
|
||||
|
||||
PCIE DRIVER FOR ST SPEAR13XX
|
||||
M: Pratyush Anand <pratyush.anand@gmail.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/pci/dwc/*spear*
|
||||
F: drivers/pci/controller/dwc/*spear*
|
||||
|
||||
PCMCIA SUBSYSTEM
|
||||
M: Dominik Brodowski <linux@dominikbrodowski.net>
|
||||
|
|
@ -12179,7 +12177,7 @@ F: drivers/mtd/nand/raw/r852.h
|
|||
|
||||
RISC-V ARCHITECTURE
|
||||
M: Palmer Dabbelt <palmer@sifive.com>
|
||||
M: Albert Ou <albert@sifive.com>
|
||||
M: Albert Ou <aou@eecs.berkeley.edu>
|
||||
L: linux-riscv@lists.infradead.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
|
||||
S: Supported
|
||||
|
|
@ -12457,7 +12455,7 @@ L: linux-crypto@vger.kernel.org
|
|||
L: linux-samsung-soc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/crypto/exynos-rng.c
|
||||
F: Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
|
||||
F: Documentation/devicetree/bindings/rng/samsung,exynos4-rng.txt
|
||||
|
||||
SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
|
||||
M: Łukasz Stelmach <l.stelmach@samsung.com>
|
||||
|
|
@ -12939,6 +12937,14 @@ F: drivers/media/usb/siano/
|
|||
F: drivers/media/usb/siano/
|
||||
F: drivers/media/mmc/siano/
|
||||
|
||||
SIFIVE DRIVERS
|
||||
M: Palmer Dabbelt <palmer@sifive.com>
|
||||
L: linux-riscv@lists.infradead.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
|
||||
S: Supported
|
||||
K: sifive
|
||||
N: sifive
|
||||
|
||||
SILEAD TOUCHSCREEN DRIVER
|
||||
M: Hans de Goede <hdegoede@redhat.com>
|
||||
L: linux-input@vger.kernel.org
|
||||
|
|
@ -13291,7 +13297,7 @@ M: Vinod Koul <vkoul@kernel.org>
|
|||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
S: Supported
|
||||
F: Documentation/sound/alsa/compress_offload.txt
|
||||
F: Documentation/sound/designs/compress-offload.rst
|
||||
F: include/sound/compress_driver.h
|
||||
F: include/uapi/sound/compress_*
|
||||
F: sound/core/compress_offload.c
|
||||
|
|
@ -13312,7 +13318,7 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
|||
W: http://alsa-project.org/main/index.php/ASoC
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/sound/
|
||||
F: Documentation/sound/alsa/soc/
|
||||
F: Documentation/sound/soc/
|
||||
F: sound/soc/
|
||||
F: include/sound/soc*
|
||||
|
||||
|
|
@ -13571,7 +13577,7 @@ F: drivers/*/stm32-*timer*
|
|||
F: drivers/pwm/pwm-stm32*
|
||||
F: include/linux/*/stm32-*tim*
|
||||
F: Documentation/ABI/testing/*timer-stm32
|
||||
F: Documentation/devicetree/bindings/*/stm32-*timer
|
||||
F: Documentation/devicetree/bindings/*/stm32-*timer*
|
||||
F: Documentation/devicetree/bindings/pwm/pwm-stm32*
|
||||
|
||||
STMMAC ETHERNET DRIVER
|
||||
|
|
@ -13794,7 +13800,7 @@ SYSTEM TRACE MODULE CLASS
|
|||
M: Alexander Shishkin <alexander.shishkin@linux.intel.com>
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git
|
||||
F: Documentation/trace/stm.txt
|
||||
F: Documentation/trace/stm.rst
|
||||
F: drivers/hwtracing/stm/
|
||||
F: include/linux/stm.h
|
||||
F: include/uapi/linux/stm.h
|
||||
|
|
@ -14471,7 +14477,7 @@ M: Steven Rostedt <rostedt@goodmis.org>
|
|||
M: Ingo Molnar <mingo@redhat.com>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core
|
||||
S: Maintained
|
||||
F: Documentation/trace/ftrace.txt
|
||||
F: Documentation/trace/ftrace.rst
|
||||
F: arch/*/*/*/ftrace.h
|
||||
F: arch/*/kernel/ftrace.c
|
||||
F: include/*/ftrace.h
|
||||
|
|
@ -14940,7 +14946,7 @@ M: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
|||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/ABI/testing/sysfs-class-typec
|
||||
F: Documentation/usb/typec.rst
|
||||
F: Documentation/driver-api/usb/typec.rst
|
||||
F: drivers/usb/typec/
|
||||
F: include/linux/usb/typec.h
|
||||
|
||||
|
|
@ -15007,8 +15013,7 @@ F: drivers/media/usb/zr364xx/
|
|||
USER-MODE LINUX (UML)
|
||||
M: Jeff Dike <jdike@addtoit.com>
|
||||
M: Richard Weinberger <richard@nod.at>
|
||||
L: user-mode-linux-devel@lists.sourceforge.net
|
||||
L: user-mode-linux-user@lists.sourceforge.net
|
||||
L: linux-um@lists.infradead.org
|
||||
W: http://user-mode-linux.sourceforge.net
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
|
||||
S: Maintained
|
||||
|
|
@ -15770,7 +15775,7 @@ YEALINK PHONE DRIVER
|
|||
M: Henk Vergonet <Henk.Vergonet@gmail.com>
|
||||
L: usbb2k-api-dev@nongnu.org
|
||||
S: Maintained
|
||||
F: Documentation/input/yealink.rst
|
||||
F: Documentation/input/devices/yealink.rst
|
||||
F: drivers/input/misc/yealink.*
|
||||
|
||||
Z8530 DRIVER FOR AX.25
|
||||
|
|
|
|||
151
Makefile
151
Makefile
|
|
@ -1,8 +1,8 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
VERSION = 4
|
||||
PATCHLEVEL = 17
|
||||
PATCHLEVEL = 18
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION =
|
||||
EXTRAVERSION = -rc1
|
||||
NAME = Merciless Moray
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -442,8 +442,6 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
|
|||
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
|
||||
export KBUILD_ARFLAGS
|
||||
|
||||
export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1)
|
||||
|
||||
# When compiling out-of-tree modules, put MODVERDIR in the module
|
||||
# tree rather than in the kernel tree. The kernel tree might
|
||||
# even be read-only.
|
||||
|
|
@ -514,6 +512,12 @@ ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/cc-can-link.sh $(CC)), y)
|
|||
export CC_CAN_LINK
|
||||
endif
|
||||
|
||||
# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
|
||||
# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
|
||||
# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
|
||||
# and from include/config/auto.conf.cmd to detect the compiler upgrade.
|
||||
CC_VERSION_TEXT = $(shell $(CC) --version | head -n 1)
|
||||
|
||||
ifeq ($(config-targets),1)
|
||||
# ===========================================================================
|
||||
# *config targets only - make sure prerequisites are updated, and descend
|
||||
|
|
@ -523,7 +527,7 @@ ifeq ($(config-targets),1)
|
|||
# KBUILD_DEFCONFIG may point out an alternative default configuration
|
||||
# used for 'make defconfig'
|
||||
include arch/$(SRCARCH)/Makefile
|
||||
export KBUILD_DEFCONFIG KBUILD_KCONFIG
|
||||
export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
|
||||
|
||||
config: scripts_basic outputmakefile FORCE
|
||||
$(Q)$(MAKE) $(build)=scripts/kconfig $@
|
||||
|
|
@ -585,12 +589,32 @@ virt-y := virt/
|
|||
endif # KBUILD_EXTMOD
|
||||
|
||||
ifeq ($(dot-config),1)
|
||||
# Read in config
|
||||
-include include/config/auto.conf
|
||||
endif
|
||||
|
||||
# The all: target is the default when no target is given on the
|
||||
# command line.
|
||||
# This allow a user to issue only 'make' to build a kernel including modules
|
||||
# Defaults to vmlinux, but the arch makefile usually adds further targets
|
||||
all: vmlinux
|
||||
|
||||
CFLAGS_GCOV := -fprofile-arcs -ftest-coverage \
|
||||
$(call cc-option,-fno-tree-loop-im) \
|
||||
$(call cc-disable-warning,maybe-uninitialized,)
|
||||
export CFLAGS_GCOV
|
||||
|
||||
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
|
||||
# values of the respective KBUILD_* variables
|
||||
ARCH_CPPFLAGS :=
|
||||
ARCH_AFLAGS :=
|
||||
ARCH_CFLAGS :=
|
||||
include arch/$(SRCARCH)/Makefile
|
||||
|
||||
ifeq ($(dot-config),1)
|
||||
ifeq ($(KBUILD_EXTMOD),)
|
||||
# Read in dependencies to all Kconfig* files, make sure to run
|
||||
# oldconfig if changes are detected.
|
||||
# Read in dependencies to all Kconfig* files, make sure to run syncconfig if
|
||||
# changes are detected. This should be included after arch/$(SRCARCH)/Makefile
|
||||
# because some architectures define CROSS_COMPILE there.
|
||||
-include include/config/auto.conf.cmd
|
||||
|
||||
# To avoid any implicit rule to kick in, define an empty command
|
||||
|
|
@ -622,24 +646,6 @@ else
|
|||
include/config/auto.conf: ;
|
||||
endif # $(dot-config)
|
||||
|
||||
# The all: target is the default when no target is given on the
|
||||
# command line.
|
||||
# This allow a user to issue only 'make' to build a kernel including modules
|
||||
# Defaults to vmlinux, but the arch makefile usually adds further targets
|
||||
all: vmlinux
|
||||
|
||||
CFLAGS_GCOV := -fprofile-arcs -ftest-coverage \
|
||||
$(call cc-option,-fno-tree-loop-im) \
|
||||
$(call cc-disable-warning,maybe-uninitialized,)
|
||||
export CFLAGS_GCOV CFLAGS_KCOV
|
||||
|
||||
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
|
||||
# values of the respective KBUILD_* variables
|
||||
ARCH_CPPFLAGS :=
|
||||
ARCH_AFLAGS :=
|
||||
ARCH_CFLAGS :=
|
||||
include arch/$(SRCARCH)/Makefile
|
||||
|
||||
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
|
||||
|
|
@ -680,55 +686,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
|
|||
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
|
||||
endif
|
||||
|
||||
# This selects the stack protector compiler flag. Testing it is delayed
|
||||
# until after .config has been reprocessed, in the prepare-compiler-check
|
||||
# target.
|
||||
ifdef CONFIG_CC_STACKPROTECTOR_AUTO
|
||||
stackp-flag := $(call cc-option,-fstack-protector-strong,$(call cc-option,-fstack-protector))
|
||||
stackp-name := AUTO
|
||||
else
|
||||
ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
|
||||
stackp-flag := -fstack-protector
|
||||
stackp-name := REGULAR
|
||||
else
|
||||
ifdef CONFIG_CC_STACKPROTECTOR_STRONG
|
||||
stackp-flag := -fstack-protector-strong
|
||||
stackp-name := STRONG
|
||||
else
|
||||
# If either there is no stack protector for this architecture or
|
||||
# CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name)
|
||||
# is empty, skipping all remaining stack protector tests.
|
||||
#
|
||||
# Force off for distro compilers that enable stack protector by default.
|
||||
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
|
||||
endif
|
||||
endif
|
||||
endif
|
||||
# Find arch-specific stack protector compiler sanity-checking script.
|
||||
ifdef stackp-name
|
||||
ifneq ($(stackp-flag),)
|
||||
stackp-path := $(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh
|
||||
stackp-check := $(wildcard $(stackp-path))
|
||||
# If the wildcard test matches a test script, run it to check functionality.
|
||||
ifdef stackp-check
|
||||
ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS) $(biarch)),y)
|
||||
stackp-broken := y
|
||||
endif
|
||||
endif
|
||||
ifndef stackp-broken
|
||||
# If the stack protector is functional, enable code that depends on it.
|
||||
KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR
|
||||
# Either we've already detected the flag (for AUTO) or we'll fail the
|
||||
# build in the prepare-compiler-check rule (for specific flag).
|
||||
KBUILD_CFLAGS += $(stackp-flag)
|
||||
else
|
||||
# We have to make sure stack protector is unconditionally disabled if
|
||||
# the compiler is broken (in case we're going to continue the build in
|
||||
# AUTO mode).
|
||||
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
|
||||
endif
|
||||
endif
|
||||
endif
|
||||
stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
|
||||
stackp-flags-$(CONFIG_STACKPROTECTOR) := -fstack-protector
|
||||
stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong
|
||||
|
||||
KBUILD_CFLAGS += $(stackp-flags-y)
|
||||
|
||||
ifeq ($(cc-name),clang)
|
||||
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
|
||||
|
|
@ -1112,7 +1074,7 @@ endif
|
|||
# prepare2 creates a makefile if using a separate output directory.
|
||||
# From this point forward, .config has been reprocessed, so any rules
|
||||
# that need to depend on updated CONFIG_* values can be checked here.
|
||||
prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic
|
||||
prepare2: prepare3 outputmakefile asm-generic
|
||||
|
||||
prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
|
||||
include/config/auto.conf
|
||||
|
|
@ -1138,43 +1100,6 @@ uapi-asm-generic:
|
|||
PHONY += prepare-objtool
|
||||
prepare-objtool: $(objtool_target)
|
||||
|
||||
# Check for CONFIG flags that require compiler support. Abort the build
|
||||
# after .config has been processed, but before the kernel build starts.
|
||||
#
|
||||
# For security-sensitive CONFIG options, we don't want to fallback and/or
|
||||
# silently change which compiler flags will be used, since that leads to
|
||||
# producing kernels with different security feature characteristics
|
||||
# depending on the compiler used. (For example, "But I selected
|
||||
# CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!")
|
||||
PHONY += prepare-compiler-check
|
||||
prepare-compiler-check: FORCE
|
||||
# Make sure compiler supports requested stack protector flag.
|
||||
ifdef stackp-name
|
||||
# Warn about CONFIG_CC_STACKPROTECTOR_AUTO having found no option.
|
||||
ifeq ($(stackp-flag),)
|
||||
@echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
|
||||
Compiler does not support any known stack-protector >&2
|
||||
else
|
||||
# Fail if specifically requested stack protector is missing.
|
||||
ifeq ($(call cc-option, $(stackp-flag)),)
|
||||
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
|
||||
$(stackp-flag) not supported by compiler >&2 && exit 1
|
||||
endif
|
||||
endif
|
||||
endif
|
||||
# Make sure compiler does not have buggy stack-protector support. If a
|
||||
# specific stack-protector was requested, fail the build, otherwise warn.
|
||||
ifdef stackp-broken
|
||||
ifeq ($(stackp-name),AUTO)
|
||||
@echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
|
||||
$(stackp-flag) available but compiler is broken: disabling >&2
|
||||
else
|
||||
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
|
||||
$(stackp-flag) available but compiler is broken >&2 && exit 1
|
||||
endif
|
||||
endif
|
||||
@:
|
||||
|
||||
# Generate some files
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
58
arch/Kconfig
58
arch/Kconfig
|
|
@ -403,7 +403,16 @@ config SECCOMP_FILTER
|
|||
in terms of Berkeley Packet Filter programs which implement
|
||||
task-defined system call filtering polices.
|
||||
|
||||
See Documentation/prctl/seccomp_filter.txt for details.
|
||||
See Documentation/userspace-api/seccomp_filter.rst for details.
|
||||
|
||||
preferred-plugin-hostcc := $(if-success,[ $(gcc-version) -ge 40800 ],$(HOSTCXX),$(HOSTCC))
|
||||
|
||||
config PLUGIN_HOSTCC
|
||||
string
|
||||
default "$(shell,$(srctree)/scripts/gcc-plugin.sh "$(preferred-plugin-hostcc)" "$(HOSTCXX)" "$(CC)")"
|
||||
help
|
||||
Host compiler used to build GCC plugins. This can be $(HOSTCXX),
|
||||
$(HOSTCC), or a null string if GCC plugin is unsupported.
|
||||
|
||||
config HAVE_GCC_PLUGINS
|
||||
bool
|
||||
|
|
@ -414,7 +423,7 @@ config HAVE_GCC_PLUGINS
|
|||
menuconfig GCC_PLUGINS
|
||||
bool "GCC plugins"
|
||||
depends on HAVE_GCC_PLUGINS
|
||||
depends on !COMPILE_TEST
|
||||
depends on PLUGIN_HOSTCC != ""
|
||||
help
|
||||
GCC plugins are loadable modules that provide extra features to the
|
||||
compiler. They are useful for runtime instrumentation and static analysis.
|
||||
|
|
@ -424,7 +433,7 @@ menuconfig GCC_PLUGINS
|
|||
config GCC_PLUGIN_CYC_COMPLEXITY
|
||||
bool "Compute the cyclomatic complexity of a function" if EXPERT
|
||||
depends on GCC_PLUGINS
|
||||
depends on !COMPILE_TEST
|
||||
depends on !COMPILE_TEST # too noisy
|
||||
help
|
||||
The complexity M of a function's control flow graph is defined as:
|
||||
M = E - N + 2P
|
||||
|
|
@ -484,6 +493,7 @@ config GCC_PLUGIN_STRUCTLEAK
|
|||
config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
|
||||
bool "Force initialize all struct type variables passed by reference"
|
||||
depends on GCC_PLUGIN_STRUCTLEAK
|
||||
depends on !COMPILE_TEST
|
||||
help
|
||||
Zero initialize any struct type local variable that may be passed by
|
||||
reference without having been initialized.
|
||||
|
|
@ -491,7 +501,7 @@ config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
|
|||
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
|
||||
bool "Report forcefully initialized variables"
|
||||
depends on GCC_PLUGIN_STRUCTLEAK
|
||||
depends on !COMPILE_TEST
|
||||
depends on !COMPILE_TEST # too noisy
|
||||
help
|
||||
This option will cause a warning to be printed each time the
|
||||
structleak plugin finds a variable it thinks needs to be
|
||||
|
|
@ -531,7 +541,7 @@ config GCC_PLUGIN_RANDSTRUCT
|
|||
config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
|
||||
bool "Use cacheline-aware structure randomization"
|
||||
depends on GCC_PLUGIN_RANDSTRUCT
|
||||
depends on !COMPILE_TEST
|
||||
depends on !COMPILE_TEST # do not reduce test coverage
|
||||
help
|
||||
If you say Y here, the RANDSTRUCT randomization will make a
|
||||
best effort at restricting randomization to cacheline-sized
|
||||
|
|
@ -539,17 +549,20 @@ config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
|
|||
in structures. This reduces the performance hit of RANDSTRUCT
|
||||
at the cost of weakened randomization.
|
||||
|
||||
config HAVE_CC_STACKPROTECTOR
|
||||
config HAVE_STACKPROTECTOR
|
||||
bool
|
||||
help
|
||||
An arch should select this symbol if:
|
||||
- its compiler supports the -fstack-protector option
|
||||
- it has implemented a stack canary (e.g. __stack_chk_guard)
|
||||
|
||||
choice
|
||||
prompt "Stack Protector buffer overflow detection"
|
||||
depends on HAVE_CC_STACKPROTECTOR
|
||||
default CC_STACKPROTECTOR_AUTO
|
||||
config CC_HAS_STACKPROTECTOR_NONE
|
||||
def_bool $(cc-option,-fno-stack-protector)
|
||||
|
||||
config STACKPROTECTOR
|
||||
bool "Stack Protector buffer overflow detection"
|
||||
depends on HAVE_STACKPROTECTOR
|
||||
depends on $(cc-option,-fstack-protector)
|
||||
default y
|
||||
help
|
||||
This option turns on the "stack-protector" GCC feature. This
|
||||
feature puts, at the beginning of functions, a canary value on
|
||||
|
|
@ -559,14 +572,6 @@ choice
|
|||
overwrite the canary, which gets detected and the attack is then
|
||||
neutralized via a kernel panic.
|
||||
|
||||
config CC_STACKPROTECTOR_NONE
|
||||
bool "None"
|
||||
help
|
||||
Disable "stack-protector" GCC feature.
|
||||
|
||||
config CC_STACKPROTECTOR_REGULAR
|
||||
bool "Regular"
|
||||
help
|
||||
Functions will have the stack-protector canary logic added if they
|
||||
have an 8-byte or larger character array on the stack.
|
||||
|
||||
|
|
@ -577,8 +582,11 @@ config CC_STACKPROTECTOR_REGULAR
|
|||
about 3% of all kernel functions, which increases kernel code size
|
||||
by about 0.3%.
|
||||
|
||||
config CC_STACKPROTECTOR_STRONG
|
||||
bool "Strong"
|
||||
config STACKPROTECTOR_STRONG
|
||||
bool "Strong Stack Protector"
|
||||
depends on STACKPROTECTOR
|
||||
depends on $(cc-option,-fstack-protector-strong)
|
||||
default y
|
||||
help
|
||||
Functions will have the stack-protector canary logic added in any
|
||||
of the following conditions:
|
||||
|
|
@ -596,14 +604,6 @@ config CC_STACKPROTECTOR_STRONG
|
|||
about 20% of all kernel functions, which increases the kernel code
|
||||
size by about 2%.
|
||||
|
||||
config CC_STACKPROTECTOR_AUTO
|
||||
bool "Automatic"
|
||||
help
|
||||
If the compiler supports it, the best available stack-protector
|
||||
option will be chosen.
|
||||
|
||||
endchoice
|
||||
|
||||
config HAVE_ARCH_WITHIN_STACK_FRAMES
|
||||
bool
|
||||
help
|
||||
|
|
|
|||
|
|
@ -8,9 +8,10 @@ config ARM
|
|||
select ARCH_HAS_DEVMEM_IS_ALLOWED
|
||||
select ARCH_HAS_ELF_RANDOMIZE
|
||||
select ARCH_HAS_FORTIFY_SOURCE
|
||||
select ARCH_HAS_KCOV
|
||||
select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
|
||||
select ARCH_HAS_SET_MEMORY
|
||||
select ARCH_HAS_PHYS_TO_DMA
|
||||
select ARCH_HAS_SET_MEMORY
|
||||
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
|
||||
select ARCH_HAS_STRICT_MODULE_RWX if MMU
|
||||
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
|
||||
|
|
@ -57,7 +58,6 @@ config ARM
|
|||
select HAVE_ARCH_TRACEHOOK
|
||||
select HAVE_ARM_SMCCC if CPU_V7
|
||||
select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32
|
||||
select HAVE_CC_STACKPROTECTOR
|
||||
select HAVE_CONTEXT_TRACKING
|
||||
select HAVE_C_RECORDMCOUNT
|
||||
select HAVE_DEBUG_KMEMLEAK
|
||||
|
|
@ -92,6 +92,7 @@ config ARM
|
|||
select HAVE_RCU_TABLE_FREE if (SMP && ARM_LPAE)
|
||||
select HAVE_REGS_AND_STACK_ACCESS_API
|
||||
select HAVE_RSEQ
|
||||
select HAVE_STACKPROTECTOR
|
||||
select HAVE_SYSCALL_TRACEPOINTS
|
||||
select HAVE_UID16
|
||||
select HAVE_VIRT_CPU_ACCOUNTING_GEN
|
||||
|
|
@ -1301,7 +1302,7 @@ config SMP
|
|||
will run faster if you say N here.
|
||||
|
||||
See also <file:Documentation/x86/i386/IO-APIC.txt>,
|
||||
<file:Documentation/nmi_watchdog.txt> and the SMP-HOWTO available at
|
||||
<file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO available at
|
||||
<http://tldp.org/HOWTO/SMP-HOWTO.html>.
|
||||
|
||||
If you don't know what to do here, say N.
|
||||
|
|
|
|||
|
|
@ -25,6 +25,9 @@ endif
|
|||
|
||||
GCOV_PROFILE := n
|
||||
|
||||
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
|
||||
KCOV_INSTRUMENT := n
|
||||
|
||||
#
|
||||
# Architecture dependencies
|
||||
#
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@
|
|||
* Start addresses are inclusive and end addresses are exclusive;
|
||||
* start addresses should be rounded down, end addresses up.
|
||||
*
|
||||
* See Documentation/cachetlb.txt for more information.
|
||||
* See Documentation/core-api/cachetlb.rst for more information.
|
||||
* Please note that the implementation of these, and the required
|
||||
* effects are cache-type (VIVT/VIPT/PIPT) specific.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -281,6 +281,7 @@ void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
|
|||
|
||||
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
|
||||
|
||||
static inline bool kvm_arch_check_sve_has_vhe(void) { return true; }
|
||||
static inline void kvm_arch_hardware_unsetup(void) {}
|
||||
static inline void kvm_arch_sync_events(struct kvm *kvm) {}
|
||||
static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
|
||||
|
|
@ -304,8 +305,13 @@ int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
|
|||
int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
|
||||
struct kvm_device_attr *attr);
|
||||
|
||||
/* All host FP/SIMD state is restored on guest exit, so nothing to save: */
|
||||
static inline void kvm_fpsimd_flush_cpu_state(void) {}
|
||||
/*
|
||||
* VFP/NEON switching is all done by the hyp switch code, so no need to
|
||||
* coordinate with host context handling for this state:
|
||||
*/
|
||||
static inline void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu) {}
|
||||
static inline void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu) {}
|
||||
static inline void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu) {}
|
||||
|
||||
static inline void kvm_arm_vhe_guest_enter(void) {}
|
||||
static inline void kvm_arm_vhe_guest_exit(void) {}
|
||||
|
|
@ -340,4 +346,8 @@ static inline int kvm_arm_have_ssbd(void)
|
|||
static inline void kvm_vcpu_load_sysregs(struct kvm_vcpu *vcpu) {}
|
||||
static inline void kvm_vcpu_put_sysregs(struct kvm_vcpu *vcpu) {}
|
||||
|
||||
#define __KVM_HAVE_ARCH_VM_ALLOC
|
||||
struct kvm *kvm_arch_alloc_vm(void);
|
||||
void kvm_arch_free_vm(struct kvm *kvm);
|
||||
|
||||
#endif /* __ARM_KVM_HOST_H__ */
|
||||
|
|
|
|||
|
|
@ -91,6 +91,7 @@ struct kvm_regs {
|
|||
#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
|
||||
#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
|
||||
#define KVM_VGIC_ITS_ADDR_TYPE 4
|
||||
#define KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION 5
|
||||
|
||||
#define KVM_VGIC_V3_DIST_SIZE SZ_64K
|
||||
#define KVM_VGIC_V3_REDIST_SIZE (2 * SZ_64K)
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue