Merge branch 'for-5.18/apple' into for-linus
- Apple magic keyboard support improvements for newer models (José Expósito) - Apple T2 Macs support improvements (Aun-Ali Zaidi, Paul Pawlowski)
This commit is contained in:
commit
412370414c
4
.mailmap
4
.mailmap
|
@ -70,6 +70,7 @@ Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
|
|||
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
|
||||
Brian Avery <b.avery@hp.com>
|
||||
Brian King <brking@us.ibm.com>
|
||||
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
|
@ -79,6 +80,9 @@ Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
|
|||
Christian Borntraeger <borntraeger@linux.ibm.com> <borntraeger@de.ibm.com>
|
||||
Christian Borntraeger <borntraeger@linux.ibm.com> <cborntra@de.ibm.com>
|
||||
Christian Borntraeger <borntraeger@linux.ibm.com> <borntrae@de.ibm.com>
|
||||
Christian Brauner <brauner@kernel.org> <christian@brauner.io>
|
||||
Christian Brauner <brauner@kernel.org> <christian.brauner@canonical.com>
|
||||
Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
|
||||
Christophe Ricard <christophe.ricard@gmail.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Colin Ian King <colin.king@intel.com> <colin.king@canonical.com>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
What: /sys/bus/platform/drivers/aspeed-uart-routing/*/uart*
|
||||
What: /sys/bus/platform/drivers/aspeed-uart-routing/\*/uart\*
|
||||
Date: September 2021
|
||||
Contact: Oskar Senft <osk@google.com>
|
||||
Chia-Wei Wang <chiawei_wang@aspeedtech.com>
|
||||
|
@ -9,7 +9,7 @@ Description: Selects the RX source of the UARTx device.
|
|||
depends on the selected file.
|
||||
|
||||
e.g.
|
||||
cat /sys/bus/platform/drivers/aspeed-uart-routing/*.uart_routing/uart1
|
||||
cat /sys/bus/platform/drivers/aspeed-uart-routing/\*.uart_routing/uart1
|
||||
[io1] io2 io3 io4 uart2 uart3 uart4 io6
|
||||
|
||||
In this case, UART1 gets its input from IO1 (physical serial port 1).
|
||||
|
@ -17,7 +17,7 @@ Description: Selects the RX source of the UARTx device.
|
|||
Users: OpenBMC. Proposed changes should be mailed to
|
||||
openbmc@lists.ozlabs.org
|
||||
|
||||
What: /sys/bus/platform/drivers/aspeed-uart-routing/*/io*
|
||||
What: /sys/bus/platform/drivers/aspeed-uart-routing/\*/io\*
|
||||
Date: September 2021
|
||||
Contact: Oskar Senft <osk@google.com>
|
||||
Chia-Wei Wang <chiawei_wang@aspeedtech.com>
|
||||
|
|
|
@ -92,7 +92,8 @@ Triggers can be set on more than one psi metric and more than one trigger
|
|||
for the same psi metric can be specified. However for each trigger a separate
|
||||
file descriptor is required to be able to poll it separately from others,
|
||||
therefore for each trigger a separate open() syscall should be made even
|
||||
when opening the same psi interface file.
|
||||
when opening the same psi interface file. Write operations to a file descriptor
|
||||
with an already existing psi trigger will fail with EBUSY.
|
||||
|
||||
Monitors activate only when system enters stall state for the monitored
|
||||
psi metric and deactivates upon exit from the stall state. While system is
|
||||
|
|
|
@ -10,6 +10,7 @@ gpio
|
|||
gpio-aggregator
|
||||
sysfs
|
||||
gpio-mockup
|
||||
gpio-sim
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
|
|
@ -266,10 +266,12 @@ Avanta family
|
|||
-------------
|
||||
|
||||
Flavors:
|
||||
- 88F6500
|
||||
- 88F6510
|
||||
- 88F6530P
|
||||
- 88F6550
|
||||
- 88F6560
|
||||
- 88F6601
|
||||
|
||||
Homepage:
|
||||
https://web.archive.org/web/20181005145041/http://www.marvell.com/broadband/
|
||||
|
|
|
@ -52,6 +52,12 @@ stable kernels.
|
|||
| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
|
||||
|
@ -92,12 +98,20 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1349291 | N/A |
|
||||
|
|
|
@ -7,6 +7,14 @@ directory. These are intended to be small tests to exercise individual code
|
|||
paths in the kernel. Tests are intended to be run after building, installing
|
||||
and booting a kernel.
|
||||
|
||||
Kselftest from mainline can be run on older stable kernels. Running tests
|
||||
from mainline offers the best coverage. Several test rings run mainline
|
||||
kselftest suite on stable releases. The reason is that when a new test
|
||||
gets added to test existing code to regression test a bug, we should be
|
||||
able to run that test on an older kernel. Hence, it is important to keep
|
||||
code that can still test an older kernel and make sure it skips the test
|
||||
gracefully on newer releases.
|
||||
|
||||
You can find additional information on Kselftest framework, how to
|
||||
write new tests using the framework on Kselftest wiki:
|
||||
|
||||
|
|
|
@ -242,7 +242,7 @@ example:
|
|||
|
||||
int rectangle_area(struct shape *this)
|
||||
{
|
||||
struct rectangle *self = container_of(this, struct shape, parent);
|
||||
struct rectangle *self = container_of(this, struct rectangle, parent);
|
||||
|
||||
return self->length * self->width;
|
||||
};
|
||||
|
|
|
@ -119,6 +119,9 @@ Boards (incomplete list of examples):
|
|||
- OMAP3 BeagleBoard : Low cost community board
|
||||
compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
|
||||
|
||||
- OMAP3 BeagleBoard A to B4 : Early BeagleBoard revisions A to B4 with a timer quirk
|
||||
compatible = "ti,omap3-beagle-ab4", "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
|
||||
|
||||
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
|
||||
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"
|
||||
|
||||
|
|
|
@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Analogix ANX7814 SlimPort (Full-HD Transmitter)
|
||||
|
||||
maintainers:
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
- Andrzej Hajda <andrzej.hajda@intel.com>
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Robert Foss <robert.foss@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -8,7 +8,6 @@ title: ChromeOS EC ANX7688 HDMI to DP Converter through Type-C Port
|
|||
|
||||
maintainers:
|
||||
- Nicolas Boichat <drinkcat@chromium.org>
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
|
||||
description: |
|
||||
ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
|
||||
|
|
|
@ -8,7 +8,6 @@ title: MIPI DSI to eDP Video Format Converter Device Tree Bindings
|
|||
|
||||
maintainers:
|
||||
- Nicolas Boichat <drinkcat@chromium.org>
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
|
||||
description: |
|
||||
The PS8640 is a low power MIPI-to-eDP video format converter supporting
|
||||
|
|
|
@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS LCD panel
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Paul Cercueil <paul@crapouillou.net>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -15,11 +15,9 @@ description: |
|
|||
960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and
|
||||
VCOMH outputs.
|
||||
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: Innolux EJ030NA 3.0" (320x480 pixels) 24-bit TFT LCD panel
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Paul Cercueil <paul@crapouillou.net>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Paul Cercueil <paul@crapouillou.net>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: LG.Philips LB035Q02 Panel
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Tomi Valkeinen <tomi.valkeinen@ti.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Andrzej Hajda <a.hajda@samsung.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -63,8 +60,6 @@ examples:
|
|||
|
||||
lcd@0 {
|
||||
compatible = "samsung,ld9040";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
reg = <0>;
|
||||
vdd3-supply = <&ldo7_reg>;
|
||||
|
|
|
@ -12,6 +12,7 @@ maintainers:
|
|||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/leds/backlight/common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: Sitronix ST7789V RGB panel with SPI control bus
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: Sony ACX565AKM SDI Panel
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Tomi Valkeinen <tomi.valkeinen@ti.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -6,16 +6,13 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
|
||||
title: Toppoly TD Panels
|
||||
|
||||
description: |
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-controller.yaml
|
||||
|
||||
maintainers:
|
||||
- Marek Belisko <marek@goldelico.com>
|
||||
- H. Nikolaus Schaller <hns@goldelico.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -26,14 +26,6 @@ properties:
|
|||
clock-names:
|
||||
const: hclk
|
||||
|
||||
pinctrl-0:
|
||||
maxItems: 2
|
||||
|
||||
pinctrl-names:
|
||||
const: default
|
||||
description:
|
||||
Switch the iomux for the HPD/I2C pins to HDMI function.
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
|
|
|
@ -8,7 +8,6 @@ title: ChromeOS EC USB Type-C cable and accessories detection
|
|||
|
||||
maintainers:
|
||||
- Benson Leung <bleung@chromium.org>
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
|
||||
description: |
|
||||
On ChromeOS systems with USB Type C ports, the ChromeOS Embedded Controller is
|
||||
|
|
|
@ -10,7 +10,6 @@ title: I2C bus that tunnels through the ChromeOS EC (cros-ec)
|
|||
maintainers:
|
||||
- Doug Anderson <dianders@chromium.org>
|
||||
- Benson Leung <bleung@chromium.org>
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
|
||||
description: |
|
||||
On some ChromeOS board designs we've got a connection to the EC
|
||||
|
|
|
@ -10,7 +10,6 @@ title: ChromeOS EC MKBP Proximity Sensor
|
|||
maintainers:
|
||||
- Stephen Boyd <swboyd@chromium.org>
|
||||
- Benson Leung <bleung@chromium.org>
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
|
||||
description: |
|
||||
Google's ChromeOS EC sometimes has the ability to detect user proximity.
|
||||
|
|
|
@ -10,7 +10,6 @@ title: ChromeOS EC Keyboard
|
|||
maintainers:
|
||||
- Simon Glass <sjg@chromium.org>
|
||||
- Benson Leung <bleung@chromium.org>
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
|
||||
description: |
|
||||
Google's ChromeOS EC Keyboard is a simple matrix keyboard
|
||||
|
|
|
@ -88,12 +88,6 @@ patternProperties:
|
|||
which can be disabled to suppress events from the button.
|
||||
type: boolean
|
||||
|
||||
pinctrl-0:
|
||||
maxItems: 1
|
||||
|
||||
pinctrl-names:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- linux,code
|
||||
|
||||
|
|
|
@ -36,6 +36,7 @@ properties:
|
|||
- renesas,intc-ex-r8a77980 # R-Car V3H
|
||||
- renesas,intc-ex-r8a77990 # R-Car E3
|
||||
- renesas,intc-ex-r8a77995 # R-Car D3
|
||||
- renesas,intc-ex-r8a779a0 # R-Car V3U
|
||||
- const: renesas,irqc
|
||||
|
||||
'#interrupt-cells':
|
||||
|
|
|
@ -35,6 +35,10 @@ description:
|
|||
contains a specific memory layout, which is documented in chapter 8 of the
|
||||
SiFive U5 Coreplex Series Manual <https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf>.
|
||||
|
||||
The thead,c900-plic is different from sifive,plic-1.0.0 in opensbi, the
|
||||
T-HEAD PLIC implementation requires setting a delegation bit to allow access
|
||||
from S-mode. So add thead,c900-plic to distinguish them.
|
||||
|
||||
maintainers:
|
||||
- Sagar Kadam <sagar.kadam@sifive.com>
|
||||
- Paul Walmsley <paul.walmsley@sifive.com>
|
||||
|
@ -42,12 +46,17 @@ maintainers:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- sifive,fu540-c000-plic
|
||||
- starfive,jh7100-plic
|
||||
- canaan,k210-plic
|
||||
- const: sifive,plic-1.0.0
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- sifive,fu540-c000-plic
|
||||
- starfive,jh7100-plic
|
||||
- canaan,k210-plic
|
||||
- const: sifive,plic-1.0.0
|
||||
- items:
|
||||
- enum:
|
||||
- allwinner,sun20i-d1-plic
|
||||
- const: thead,c900-plic
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
@ -62,6 +71,7 @@ properties:
|
|||
|
||||
interrupts-extended:
|
||||
minItems: 1
|
||||
maxItems: 15872
|
||||
description:
|
||||
Specifies which contexts are connected to the PLIC, with "-1" specifying
|
||||
that a context is not present. Each node pointed to should be a
|
||||
|
@ -90,12 +100,11 @@ examples:
|
|||
#interrupt-cells = <1>;
|
||||
compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
|
||||
interrupt-controller;
|
||||
interrupts-extended = <
|
||||
&cpu0_intc 11
|
||||
&cpu1_intc 11 &cpu1_intc 9
|
||||
&cpu2_intc 11 &cpu2_intc 9
|
||||
&cpu3_intc 11 &cpu3_intc 9
|
||||
&cpu4_intc 11 &cpu4_intc 9>;
|
||||
interrupts-extended = <&cpu0_intc 11>,
|
||||
<&cpu1_intc 11>, <&cpu1_intc 9>,
|
||||
<&cpu2_intc 11>, <&cpu2_intc 9>,
|
||||
<&cpu3_intc 11>, <&cpu3_intc 9>,
|
||||
<&cpu4_intc 11>, <&cpu4_intc 9>;
|
||||
reg = <0xc000000 0x4000000>;
|
||||
riscv,ndev = <10>;
|
||||
};
|
||||
|
|
|
@ -81,14 +81,12 @@ properties:
|
|||
data-lanes:
|
||||
description:
|
||||
Note that 'fsl,imx7-mipi-csi2' only supports up to 2 data lines.
|
||||
minItems: 1
|
||||
items:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
|
|
|
@ -87,14 +87,12 @@ properties:
|
|||
|
||||
properties:
|
||||
data-lanes:
|
||||
minItems: 1
|
||||
items:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
|
|
|
@ -245,8 +245,7 @@ examples:
|
|||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <&host_irq1>;
|
||||
interrupt-parent = <&gic>;
|
||||
interrupts = <4 1 0>;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
|
|
@ -8,7 +8,6 @@ title: ChromeOS Embedded Controller
|
|||
|
||||
maintainers:
|
||||
- Benson Leung <bleung@chromium.org>
|
||||
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
||||
- Guenter Roeck <groeck@chromium.org>
|
||||
|
||||
description:
|
||||
|
|
|
@ -185,6 +185,9 @@ examples:
|
|||
clock-names = "mclk", "apb_pclk";
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
mmc@80126000 {
|
||||
compatible = "arm,pl18x", "arm,primecell";
|
||||
reg = <0x80126000 0x1000>;
|
||||
|
@ -206,12 +209,12 @@ examples:
|
|||
vqmmc-supply = <&vmmci>;
|
||||
};
|
||||
|
||||
- |
|
||||
mmc@101f6000 {
|
||||
compatible = "arm,pl18x", "arm,primecell";
|
||||
reg = <0x101f6000 0x1000>;
|
||||
clocks = <&sdiclk>, <&pclksdi>;
|
||||
clock-names = "mclk", "apb_pclk";
|
||||
interrupt-parent = <&vica>;
|
||||
interrupts = <22>;
|
||||
max-frequency = <400000>;
|
||||
bus-width = <4>;
|
||||
|
@ -226,6 +229,7 @@ examples:
|
|||
vmmc-supply = <&vmmc_regulator>;
|
||||
};
|
||||
|
||||
- |
|
||||
mmc@52007000 {
|
||||
compatible = "arm,pl18x", "arm,primecell";
|
||||
arm,primecell-periphid = <0x10153180>;
|
||||
|
|
|
@ -76,33 +76,31 @@ properties:
|
|||
M_CAN user manual for details.
|
||||
$ref: /schemas/types.yaml#/definitions/int32-array
|
||||
items:
|
||||
items:
|
||||
- description: The 'offset' is an address offset of the Message RAM where
|
||||
the following elements start from. This is usually set to 0x0 if
|
||||
you're using a private Message RAM.
|
||||
default: 0
|
||||
- description: 11-bit Filter 0-128 elements / 0-128 words
|
||||
minimum: 0
|
||||
maximum: 128
|
||||
- description: 29-bit Filter 0-64 elements / 0-128 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Rx FIFO 0 0-64 elements / 0-1152 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Rx FIFO 1 0-64 elements / 0-1152 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Rx Buffers 0-64 elements / 0-1152 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Tx Event FIFO 0-32 elements / 0-64 words
|
||||
minimum: 0
|
||||
maximum: 32
|
||||
- description: Tx Buffers 0-32 elements / 0-576 words
|
||||
minimum: 0
|
||||
maximum: 32
|
||||
maxItems: 1
|
||||
- description: The 'offset' is an address offset of the Message RAM where
|
||||
the following elements start from. This is usually set to 0x0 if
|
||||
you're using a private Message RAM.
|
||||
default: 0
|
||||
- description: 11-bit Filter 0-128 elements / 0-128 words
|
||||
minimum: 0
|
||||
maximum: 128
|
||||
- description: 29-bit Filter 0-64 elements / 0-128 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Rx FIFO 0 0-64 elements / 0-1152 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Rx FIFO 1 0-64 elements / 0-1152 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Rx Buffers 0-64 elements / 0-1152 words
|
||||
minimum: 0
|
||||
maximum: 64
|
||||
- description: Tx Event FIFO 0-32 elements / 0-64 words
|
||||
minimum: 0
|
||||
maximum: 32
|
||||
- description: Tx Buffers 0-32 elements / 0-576 words
|
||||
minimum: 0
|
||||
maximum: 32
|
||||
|
||||
power-domains:
|
||||
description:
|
||||
|
|
|
@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 {
|
|||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
spi-max-frequency = <10000000>;
|
||||
bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
|
||||
bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
|
||||
device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
|
||||
|
|
|
@ -17,9 +17,8 @@ properties:
|
|||
description:
|
||||
Specifies the MAC address that was assigned to the network device.
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
items:
|
||||
- minItems: 6
|
||||
maxItems: 6
|
||||
minItems: 6
|
||||
maxItems: 6
|
||||
|
||||
mac-address:
|
||||
description:
|
||||
|
@ -28,9 +27,8 @@ properties:
|
|||
to the device by the boot program is different from the
|
||||
local-mac-address property.
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
items:
|
||||
- minItems: 6
|
||||
maxItems: 6
|
||||
minItems: 6
|
||||
maxItems: 6
|
||||
|
||||
max-frame-size:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
@ -164,33 +162,30 @@ properties:
|
|||
type: array
|
||||
then:
|
||||
deprecated: true
|
||||
minItems: 1
|
||||
maxItems: 1
|
||||
items:
|
||||
items:
|
||||
- minimum: 0
|
||||
maximum: 31
|
||||
description:
|
||||
Emulated PHY ID, choose any but unique to the all
|
||||
specified fixed-links
|
||||
- minimum: 0
|
||||
maximum: 31
|
||||
description:
|
||||
Emulated PHY ID, choose any but unique to the all
|
||||
specified fixed-links
|
||||
|
||||
- enum: [0, 1]
|
||||
description:
|
||||
Duplex configuration. 0 for half duplex or 1 for
|
||||
full duplex
|
||||
- enum: [0, 1]
|
||||
description:
|
||||
Duplex configuration. 0 for half duplex or 1 for
|
||||
full duplex
|
||||
|
||||
- enum: [10, 100, 1000, 2500, 10000]
|
||||
description:
|
||||
Link speed in Mbits/sec.
|
||||
- enum: [10, 100, 1000, 2500, 10000]
|
||||
description:
|
||||
Link speed in Mbits/sec.
|
||||
|
||||
- enum: [0, 1]
|
||||
description:
|
||||
Pause configuration. 0 for no pause, 1 for pause
|
||||
- enum: [0, 1]
|
||||
description:
|
||||
Pause configuration. 0 for no pause, 1 for pause
|
||||
|
||||
- enum: [0, 1]
|
||||
description:
|
||||
Asymmetric pause configuration. 0 for no asymmetric
|
||||
pause, 1 for asymmetric pause
|
||||
- enum: [0, 1]
|
||||
description:
|
||||
Asymmetric pause configuration. 0 for no asymmetric
|
||||
pause, 1 for asymmetric pause
|
||||
|
||||
|
||||
- if:
|
||||
|
|
|
@ -107,6 +107,10 @@ properties:
|
|||
- const: imem
|
||||
- const: config
|
||||
|
||||
qcom,qmp:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the AOSS side-channel message RAM
|
||||
|
||||
qcom,smem-states:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description: State bits used in by the AP to signal the modem.
|
||||
|
@ -222,6 +226,8 @@ examples:
|
|||
"imem",
|
||||
"config";
|
||||
|
||||
qcom,qmp = <&aoss_qmp>;
|
||||
|
||||
qcom,smem-states = <&ipa_smp2p_out 0>,
|
||||
<&ipa_smp2p_out 1>;
|
||||
qcom,smem-state-names = "ipa-clock-enabled-valid",
|
||||
|
|
|
@ -50,16 +50,15 @@ patternProperties:
|
|||
Offset and size in bytes within the storage device.
|
||||
|
||||
bits:
|
||||
maxItems: 1
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
items:
|
||||
items:
|
||||
- minimum: 0
|
||||
maximum: 7
|
||||
description:
|
||||
Offset in bit within the address range specified by reg.
|
||||
- minimum: 1
|
||||
description:
|
||||
Size in bit within the address range specified by reg.
|
||||
- minimum: 0
|
||||
maximum: 7
|
||||
description:
|
||||
Offset in bit within the address range specified by reg.
|
||||
- minimum: 1
|
||||
description:
|
||||
Size in bit within the address range specified by reg.
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
|
|
@ -51,15 +51,6 @@ properties:
|
|||
appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, see [3].
|
||||
maxItems: 1
|
||||
|
||||
pinctrl-0:
|
||||
description:
|
||||
A phandle to the default pinctrl state.
|
||||
|
||||
pinctrl-names:
|
||||
description:
|
||||
A pinctrl state named "default" must be defined.
|
||||
const: default
|
||||
|
||||
pin-settings:
|
||||
type: object
|
||||
patternProperties:
|
||||
|
|
|
@ -30,16 +30,6 @@ description: |
|
|||
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
||||
|
||||
properties:
|
||||
pinctrl-0:
|
||||
description:
|
||||
A phandle to the node containing the subnodes containing default
|
||||
configurations.
|
||||
|
||||
pinctrl-names:
|
||||
description:
|
||||
A pinctrl state named "default" must be defined.
|
||||
const: default
|
||||
|
||||
pin-settings:
|
||||
description:
|
||||
One subnode is required to contain the default settings. It
|
||||
|
|
|
@ -43,7 +43,7 @@ properties:
|
|||
priority:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
A priority ranging from 0 to 255 (default 128) according to the following guidelines:
|
||||
A priority ranging from 0 to 255 (default 129) according to the following guidelines:
|
||||
|
||||
0: Restart handler of last resort, with limited restart capabilities.
|
||||
128: Default restart handler; use if no other restart handler is expected to be available,
|
||||
|
@ -51,7 +51,7 @@ properties:
|
|||
255: Highest priority restart handler, will preempt all other restart handlers.
|
||||
minimum: 0
|
||||
maximum: 255
|
||||
default: 128
|
||||
default: 129
|
||||
|
||||
active-delay:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
|
|
@ -127,6 +127,7 @@ examples:
|
|||
st,syscfg = <&pwrcfg 0x00 0x100>;
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/stm32mp1-clks.h>
|
||||
rtc@5c004000 {
|
||||
|
|
|
@ -110,12 +110,6 @@ properties:
|
|||
Internal DMA register base address of the audio
|
||||
subsystem (used in secondary sound source).
|
||||
|
||||
pinctrl-0:
|
||||
description: Should specify pin control groups used for this controller.
|
||||
|
||||
pinctrl-names:
|
||||
const: default
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
|
|
|
@ -23,8 +23,9 @@ properties:
|
|||
minItems: 1
|
||||
maxItems: 256
|
||||
items:
|
||||
minimum: 0
|
||||
maximum: 256
|
||||
items:
|
||||
- minimum: 0
|
||||
maximum: 256
|
||||
description:
|
||||
Chip select used by the device.
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ properties:
|
|||
- enum:
|
||||
# SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin
|
||||
- ad,ad7414
|
||||
# ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems
|
||||
# ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems
|
||||
- ad,adm9240
|
||||
# AD5110 - Nonvolatile Digital Potentiometer
|
||||
- adi,ad5110
|
||||
|
@ -43,7 +43,7 @@ properties:
|
|||
- adi,adp5589
|
||||
# AMS iAQ-Core VOC Sensor
|
||||
- ams,iaq-core
|
||||
# i2c serial eeprom (24cxx)
|
||||
# i2c serial eeprom (24cxx)
|
||||
- at,24c08
|
||||
# i2c trusted platform module (TPM)
|
||||
- atmel,at97sc3204t
|
||||
|
@ -303,9 +303,9 @@ properties:
|
|||
- skyworks,sky81452
|
||||
# Socionext SynQuacer TPM MMIO module
|
||||
- socionext,synquacer-tpm-mmio
|
||||
# i2c serial eeprom (24cxx)
|
||||
- sparkfun,qwiic-joystick
|
||||
# SparkFun Qwiic Joystick (COM-15168) with i2c interface
|
||||
- sparkfun,qwiic-joystick
|
||||
# i2c serial eeprom (24cxx)
|
||||
- st,24c256
|
||||
# Ambient Light Sensor with SMBUS/Two Wire Serial Interface
|
||||
- taos,tsl2550
|
||||
|
|
|
@ -25,6 +25,8 @@ patternProperties:
|
|||
# Keep list in alphabetical order.
|
||||
"^70mai,.*":
|
||||
description: 70mai Co., Ltd.
|
||||
"^8dev,.*":
|
||||
description: 8devices, UAB
|
||||
"^abb,.*":
|
||||
description: ABB
|
||||
"^abilis,.*":
|
||||
|
@ -441,6 +443,8 @@ patternProperties:
|
|||
description: Freescale Semiconductor
|
||||
"^fujitsu,.*":
|
||||
description: Fujitsu Ltd.
|
||||
"^fxtec,.*":
|
||||
description: FX Technology Ltd.
|
||||
"^gardena,.*":
|
||||
description: GARDENA GmbH
|
||||
"^gateworks,.*":
|
||||
|
@ -515,6 +519,8 @@ patternProperties:
|
|||
description: HannStar Display Co.
|
||||
"^holtek,.*":
|
||||
description: Holtek Semiconductor, Inc.
|
||||
"^huawei,.*":
|
||||
description: Huawei Technologies Co., Ltd.
|
||||
"^hugsun,.*":
|
||||
description: Shenzhen Hugsun Technology Co. Ltd.
|
||||
"^hwacom,.*":
|
||||
|
@ -1207,6 +1213,8 @@ patternProperties:
|
|||
description: THine Electronics, Inc.
|
||||
"^thingyjp,.*":
|
||||
description: thingy.jp
|
||||
"^thundercomm,.*":
|
||||
description: Thundercomm Technology Co., Ltd.
|
||||
"^ti,.*":
|
||||
description: Texas Instruments
|
||||
"^tianma,.*":
|
||||
|
@ -1334,6 +1342,8 @@ patternProperties:
|
|||
description: Wiligear, Ltd.
|
||||
"^winbond,.*":
|
||||
description: Winbond Electronics corp.
|
||||
"^wingtech,.*":
|
||||
description: Wingtech Technology Co., Ltd.
|
||||
"^winlink,.*":
|
||||
description: WinLink Co., Ltd
|
||||
"^winstar,.*":
|
||||
|
|
|
@ -19,7 +19,7 @@ of kernel interfaces is available via exported symbols in `firewire-core` module
|
|||
Firewire char device data structures
|
||||
====================================
|
||||
|
||||
.. include:: /ABI/stable/firewire-cdev
|
||||
.. include:: ../ABI/stable/firewire-cdev
|
||||
:literal:
|
||||
|
||||
.. kernel-doc:: include/uapi/linux/firewire-cdev.h
|
||||
|
@ -28,7 +28,7 @@ Firewire char device data structures
|
|||
Firewire device probing and sysfs interfaces
|
||||
============================================
|
||||
|
||||
.. include:: /ABI/stable/sysfs-bus-firewire
|
||||
.. include:: ../ABI/stable/sysfs-bus-firewire
|
||||
:literal:
|
||||
|
||||
.. kernel-doc:: drivers/firewire/core-device.c
|
||||
|
|
|
@ -462,6 +462,10 @@ operation table looks like the following::
|
|||
struct iov_iter *iter,
|
||||
netfs_io_terminated_t term_func,
|
||||
void *term_func_priv);
|
||||
|
||||
int (*query_occupancy)(struct netfs_cache_resources *cres,
|
||||
loff_t start, size_t len, size_t granularity,
|
||||
loff_t *_data_start, size_t *_data_len);
|
||||
};
|
||||
|
||||
With a termination handler function pointer::
|
||||
|
@ -536,6 +540,18 @@ The methods defined in the table are:
|
|||
indicating whether the termination is definitely happening in the caller's
|
||||
context.
|
||||
|
||||
* ``query_occupancy()``
|
||||
|
||||
[Required] Called to find out where the next piece of data is within a
|
||||
particular region of the cache. The start and length of the region to be
|
||||
queried are passed in, along with the granularity to which the answer needs
|
||||
to be aligned. The function passes back the start and length of the data,
|
||||
if any, available within that region. Note that there may be a hole at the
|
||||
front.
|
||||
|
||||
It returns 0 if some data was found, -ENODATA if there was no usable data
|
||||
within the region or -ENOBUFS if there is no caching on this file.
|
||||
|
||||
Note that these methods are passed a pointer to the cache resource structure,
|
||||
not the read request structure as they could be used in other situations where
|
||||
there isn't a read request structure as well, such as writing dirty data to the
|
||||
|
|
|
@ -300,30 +300,6 @@ Contact: Daniel Vetter, Noralf Tronnes
|
|||
|
||||
Level: Advanced
|
||||
|
||||
Garbage collect fbdev scrolling acceleration
|
||||
--------------------------------------------
|
||||
|
||||
Scroll acceleration has been disabled in fbcon. Now it works as the old
|
||||
SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was
|
||||
removed from fbcon_ops.
|
||||
Remaining tasks:
|
||||
|
||||
- a bunch of the hooks in fbcon_ops could be removed or simplified by calling
|
||||
directly instead of the function table (with a switch on p->rotate)
|
||||
|
||||
- fb_copyarea is unused after this, and can be deleted from all drivers
|
||||
|
||||
- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as
|
||||
well as cfb_copyarea
|
||||
|
||||
Note that not all acceleration code can be deleted, since clearing and cursor
|
||||
support is still accelerated, which might be good candidates for further
|
||||
deletion projects.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Level: Intermediate
|
||||
|
||||
idr_init_base()
|
||||
---------------
|
||||
|
||||
|
|
|
@ -166,6 +166,7 @@ to ReStructured Text format, or are simply too old.
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
tools/index
|
||||
staging/index
|
||||
watch_queue
|
||||
|
||||
|
|
|
@ -295,7 +295,7 @@ Pete Zaitcev gives the following summary:
|
|||
|
||||
- If you are in a process context (any syscall) and want to lock other
|
||||
process out, use a mutex. You can take a mutex and sleep
|
||||
(``copy_from_user*(`` or ``kmalloc(x,GFP_KERNEL)``).
|
||||
(``copy_from_user()`` or ``kmalloc(x,GFP_KERNEL)``).
|
||||
|
||||
- Otherwise (== data can be touched in an interrupt), use
|
||||
spin_lock_irqsave() and
|
||||
|
|
|
@ -47,12 +47,12 @@ RISC-V Linux Kernel SV39
|
|||
| Kernel-space virtual memory, shared between all processes:
|
||||
____________________________________________________________|___________________________________________________________
|
||||
| | | |
|
||||
ffffffc000000000 | -256 GB | ffffffc7ffffffff | 32 GB | kasan
|
||||
ffffffcefee00000 | -196 GB | ffffffcefeffffff | 2 MB | fixmap
|
||||
ffffffceff000000 | -196 GB | ffffffceffffffff | 16 MB | PCI io
|
||||
ffffffcf00000000 | -196 GB | ffffffcfffffffff | 4 GB | vmemmap
|
||||
ffffffd000000000 | -192 GB | ffffffdfffffffff | 64 GB | vmalloc/ioremap space
|
||||
ffffffe000000000 | -128 GB | ffffffff7fffffff | 124 GB | direct mapping of all physical memory
|
||||
ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap
|
||||
ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io
|
||||
ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap
|
||||
ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space
|
||||
ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory
|
||||
fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan
|
||||
__________________|____________|__________________|_________|____________________________________________________________
|
||||
|
|
||||
|
|
||||
|
|
|
@ -255,7 +255,7 @@ The following picture shows a high level overview of AMD-TEE::
|
|||
+--------------------------+ +---------+--------------------+
|
||||
|
||||
At the lowest level (in x86), the AMD Secure Processor (ASP) driver uses the
|
||||
CPU to PSP mailbox regsister to submit commands to the PSP. The format of the
|
||||
CPU to PSP mailbox register to submit commands to the PSP. The format of the
|
||||
command buffer is opaque to the ASP driver. It's role is to submit commands to
|
||||
the secure processor and return results to AMD-TEE driver. The interface
|
||||
between AMD-TEE driver and AMD Secure Processor driver can be found in [6].
|
||||
|
@ -290,7 +290,7 @@ cancel_req driver callback is not supported by AMD-TEE.
|
|||
|
||||
The GlobalPlatform TEE Client API [5] can be used by the user space (client) to
|
||||
talk to AMD's TEE. AMD's TEE provides a secure environment for loading, opening
|
||||
a session, invoking commands and clossing session with TA.
|
||||
a session, invoking commands and closing session with TA.
|
||||
|
||||
References
|
||||
==========
|
||||
|
|
|
@ -0,0 +1,20 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
============
|
||||
Kernel tools
|
||||
============
|
||||
|
||||
This book covers user-space tools that are shipped with the kernel source;
|
||||
more additions are needed here:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
rtla/index
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
=======
|
||||
|
||||
* :ref:`genindex`
|
|
@ -0,0 +1,26 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
================================
|
||||
The realtime Linux analysis tool
|
||||
================================
|
||||
|
||||
RTLA provides a set of tools for the analysis of the kernel's realtime
|
||||
behavior on specific hardware.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
rtla
|
||||
rtla-osnoise
|
||||
rtla-osnoise-hist
|
||||
rtla-osnoise-top
|
||||
rtla-timerlat
|
||||
rtla-timerlat-hist
|
||||
rtla-timerlat-top
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
=======
|
||||
|
||||
* :ref:`genindex`
|
|
@ -3370,7 +3370,7 @@ one of the latency tracers, you will get the following results.
|
|||
|
||||
Instances
|
||||
---------
|
||||
In the tracefs tracing directory is a directory called "instances".
|
||||
In the tracefs tracing directory, there is a directory called "instances".
|
||||
This directory can have new directories created inside of it using
|
||||
mkdir, and removing directories with rmdir. The directory created
|
||||
with mkdir in this directory will already contain files and other
|
||||
|
|
|
@ -115,6 +115,7 @@ Code Seq# Include File Comments
|
|||
'B' 00-1F linux/cciss_ioctl.h conflict!
|
||||
'B' 00-0F include/linux/pmu.h conflict!
|
||||
'B' C0-FF advanced bbus <mailto:maassen@uni-freiburg.de>
|
||||
'B' 00-0F xen/xenbus_dev.h conflict!
|
||||
'C' all linux/soundcard.h conflict!
|
||||
'C' 01-2F linux/capi.h conflict!
|
||||
'C' F0-FF drivers/net/wan/cosa.h conflict!
|
||||
|
@ -134,6 +135,7 @@ Code Seq# Include File Comments
|
|||
'F' 80-8F linux/arcfb.h conflict!
|
||||
'F' DD video/sstfb.h conflict!
|
||||
'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict!
|
||||
'G' 00-0F xen/gntalloc.h, xen/gntdev.h conflict!
|
||||
'H' 00-7F linux/hiddev.h conflict!
|
||||
'H' 00-0F linux/hidraw.h conflict!
|
||||
'H' 01 linux/mei.h conflict!
|
||||
|
@ -176,6 +178,7 @@ Code Seq# Include File Comments
|
|||
'P' 60-6F sound/sscape_ioctl.h conflict!
|
||||
'P' 00-0F drivers/usb/class/usblp.c conflict!
|
||||
'P' 01-09 drivers/misc/pci_endpoint_test.c conflict!
|
||||
'P' 00-0F xen/privcmd.h conflict!
|
||||
'Q' all linux/soundcard.h
|
||||
'R' 00-1F linux/random.h conflict!
|
||||
'R' 01 linux/rfkill.h conflict!
|
||||
|
|
|
@ -3268,6 +3268,7 @@ number.
|
|||
|
||||
:Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
|
||||
KVM_CAP_VCPU_ATTRIBUTES for vcpu device
|
||||
KVM_CAP_SYS_ATTRIBUTES for system (/dev/kvm) device (no set)
|
||||
:Type: device ioctl, vm ioctl, vcpu ioctl
|
||||
:Parameters: struct kvm_device_attr
|
||||
:Returns: 0 on success, -1 on error
|
||||
|
@ -3302,7 +3303,8 @@ transferred is defined by the particular attribute.
|
|||
------------------------
|
||||
|
||||
:Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
|
||||
KVM_CAP_VCPU_ATTRIBUTES for vcpu device
|
||||
KVM_CAP_VCPU_ATTRIBUTES for vcpu device
|
||||
KVM_CAP_SYS_ATTRIBUTES for system (/dev/kvm) device
|
||||
:Type: device ioctl, vm ioctl, vcpu ioctl
|
||||
:Parameters: struct kvm_device_attr
|
||||
:Returns: 0 on success, -1 on error
|
||||
|
@ -5545,8 +5547,8 @@ the trailing ``'\0'``, is indicated by ``name_size`` in the header.
|
|||
The Stats Data block contains an array of 64-bit values in the same order
|
||||
as the descriptors in Descriptors block.
|
||||
|
||||
4.42 KVM_GET_XSAVE2
|
||||
------------------
|
||||
4.134 KVM_GET_XSAVE2
|
||||
--------------------
|
||||
|
||||
:Capability: KVM_CAP_XSAVE2
|
||||
:Architectures: x86
|
||||
|
@ -7363,7 +7365,7 @@ trap and emulate MSRs that are outside of the scope of KVM as well as
|
|||
limit the attack surface on KVM's MSR emulation code.
|
||||
|
||||
8.28 KVM_CAP_ENFORCE_PV_FEATURE_CPUID
|
||||
-----------------------------
|
||||
-------------------------------------
|
||||
|
||||
Architectures: x86
|
||||
|
||||
|
|
|
@ -1,296 +0,0 @@
|
|||
.. _cleancache:
|
||||
|
||||
==========
|
||||
Cleancache
|
||||
==========
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Cleancache is a new optional feature provided by the VFS layer that
|
||||
potentially dramatically increases page cache effectiveness for
|
||||
many workloads in many environments at a negligible cost.
|
||||
|
||||
Cleancache can be thought of as a page-granularity victim cache for clean
|
||||
pages that the kernel's pageframe replacement algorithm (PFRA) would like
|
||||
to keep around, but can't since there isn't enough memory. So when the
|
||||
PFRA "evicts" a page, it first attempts to use cleancache code to
|
||||
put the data contained in that page into "transcendent memory", memory
|
||||
that is not directly accessible or addressable by the kernel and is
|
||||
of unknown and possibly time-varying size.
|
||||
|
||||
Later, when a cleancache-enabled filesystem wishes to access a page
|
||||
in a file on disk, it first checks cleancache to see if it already
|
||||
contains it; if it does, the page of data is copied into the kernel
|
||||
and a disk access is avoided.
|
||||
|
||||
Transcendent memory "drivers" for cleancache are currently implemented
|
||||
in Xen (using hypervisor memory) and zcache (using in-kernel compressed
|
||||
memory) and other implementations are in development.
|
||||
|
||||
:ref:`FAQs <faq>` are included below.
|
||||
|
||||
Implementation Overview
|
||||
=======================
|
||||
|
||||
A cleancache "backend" that provides transcendent memory registers itself
|
||||
to the kernel's cleancache "frontend" by calling cleancache_register_ops,
|
||||
passing a pointer to a cleancache_ops structure with funcs set appropriately.
|
||||
The functions provided must conform to certain semantics as follows:
|
||||
|
||||
Most important, cleancache is "ephemeral". Pages which are copied into
|
||||
cleancache have an indefinite lifetime which is completely unknowable
|
||||
by the kernel and so may or may not still be in cleancache at any later time.
|
||||
Thus, as its name implies, cleancache is not suitable for dirty pages.
|
||||
Cleancache has complete discretion over what pages to preserve and what
|
||||
pages to discard and when.
|
||||
|
||||
Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a
|
||||
pool id which, if positive, must be saved in the filesystem's superblock;
|
||||
a negative return value indicates failure. A "put_page" will copy a
|
||||
(presumably about-to-be-evicted) page into cleancache and associate it with
|
||||
the pool id, a file key, and a page index into the file. (The combination
|
||||
of a pool id, a file key, and an index is sometimes called a "handle".)
|
||||
A "get_page" will copy the page, if found, from cleancache into kernel memory.
|
||||
An "invalidate_page" will ensure the page no longer is present in cleancache;
|
||||
an "invalidate_inode" will invalidate all pages associated with the specified
|
||||
file; and, when a filesystem is unmounted, an "invalidate_fs" will invalidate
|
||||
all pages in all files specified by the given pool id and also surrender
|
||||
the pool id.
|
||||
|
||||
An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache
|
||||
to treat the pool as shared using a 128-bit UUID as a key. On systems
|
||||
that may run multiple kernels (such as hard partitioned or virtualized
|
||||
systems) that may share a clustered filesystem, and where cleancache
|
||||
may be shared among those kernels, calls to init_shared_fs that specify the
|
||||
same UUID will receive the same pool id, thus allowing the pages to
|
||||
be shared. Note that any security requirements must be imposed outside
|
||||
of the kernel (e.g. by "tools" that control cleancache). Or a
|
||||
cleancache implementation can simply disable shared_init by always
|
||||
returning a negative value.
|
||||
|
||||
If a get_page is successful on a non-shared pool, the page is invalidated
|
||||
(thus making cleancache an "exclusive" cache). On a shared pool, the page
|
||||
is NOT invalidated on a successful get_page so that it remains accessible to
|
||||
other sharers. The kernel is responsible for ensuring coherency between
|
||||
cleancache (shared or not), the page cache, and the filesystem, using
|
||||
cleancache invalidate operations as required.
|
||||
|
||||
Note that cleancache must enforce put-put-get coherency and get-get
|
||||
coherency. For the former, if two puts are made to the same handle but
|
||||
with different data, say AAA by the first put and BBB by the second, a
|
||||
subsequent get can never return the stale data (AAA). For get-get coherency,
|
||||
if a get for a given handle fails, subsequent gets for that handle will
|
||||
never succeed unless preceded by a successful put with that handle.
|
||||
|
||||
Last, cleancache provides no SMP serialization guarantees; if two
|
||||
different Linux threads are simultaneously putting and invalidating a page
|
||||
with the same handle, the results are indeterminate. Callers must
|
||||
lock the page to ensure serial behavior.
|
||||
|
||||
Cleancache Performance Metrics
|
||||
==============================
|
||||
|
||||
If properly configured, monitoring of cleancache is done via debugfs in
|
||||
the `/sys/kernel/debug/cleancache` directory. The effectiveness of cleancache
|
||||
can be measured (across all filesystems) with:
|
||||
|
||||
``succ_gets``
|
||||
number of gets that were successful
|
||||
|
||||
``failed_gets``
|
||||
number of gets that failed
|
||||
|
||||
``puts``
|
||||
number of puts attempted (all "succeed")
|
||||
|
||||
``invalidates``
|
||||
number of invalidates attempted
|
||||
|
||||
A backend implementation may provide additional metrics.
|
||||
|
||||
.. _faq:
|
||||
|
||||
FAQ
|
||||
===
|
||||
|
||||
* Where's the value? (Andrew Morton)
|
||||
|
||||
Cleancache provides a significant performance benefit to many workloads
|
||||
in many environments with negligible overhead by improving the
|
||||
effectiveness of the pagecache. Clean pagecache pages are
|
||||
saved in transcendent memory (RAM that is otherwise not directly
|
||||
addressable to the kernel); fetching those pages later avoids "refaults"
|
||||
and thus disk reads.
|
||||
|
||||
Cleancache (and its sister code "frontswap") provide interfaces for
|
||||
this transcendent memory (aka "tmem"), which conceptually lies between
|
||||
fast kernel-directly-addressable RAM and slower DMA/asynchronous devices.
|
||||
Disallowing direct kernel or userland reads/writes to tmem
|
||||
is ideal when data is transformed to a different form and size (such
|
||||
as with compression) or secretly moved (as might be useful for write-
|
||||
balancing for some RAM-like devices). Evicted page-cache pages (and
|
||||
swap pages) are a great use for this kind of slower-than-RAM-but-much-
|
||||
faster-than-disk transcendent memory, and the cleancache (and frontswap)
|
||||
"page-object-oriented" specification provides a nice way to read and
|
||||
write -- and indirectly "name" -- the pages.
|
||||
|
||||
In the virtual case, the whole point of virtualization is to statistically
|
||||
multiplex physical resources across the varying demands of multiple
|
||||
virtual machines. This is really hard to do with RAM and efforts to
|
||||
do it well with no kernel change have essentially failed (except in some
|
||||
well-publicized special-case workloads). Cleancache -- and frontswap --
|
||||
with a fairly small impact on the kernel, provide a huge amount
|
||||
of flexibility for more dynamic, flexible RAM multiplexing.
|
||||
Specifically, the Xen Transcendent Memory backend allows otherwise
|
||||
"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
|
||||
virtual machines, but the pages can be compressed and deduplicated to
|
||||
optimize RAM utilization. And when guest OS's are induced to surrender
|
||||
underutilized RAM (e.g. with "self-ballooning"), page cache pages
|
||||
are the first to go, and cleancache allows those pages to be
|
||||
saved and reclaimed if overall host system memory conditions allow.
|
||||
|
||||
And the identical interface used for cleancache can be used in
|
||||
physical systems as well. The zcache driver acts as a memory-hungry
|
||||
device that stores pages of data in a compressed state. And
|
||||
the proposed "RAMster" driver shares RAM across multiple physical
|
||||
systems.
|
||||
|
||||
* Why does cleancache have its sticky fingers so deep inside the
|
||||
filesystems and VFS? (Andrew Morton and Christoph Hellwig)
|
||||
|
||||
The core hooks for cleancache in VFS are in most cases a single line
|
||||
and the minimum set are placed precisely where needed to maintain
|
||||
coherency (via cleancache_invalidate operations) between cleancache,
|
||||
the page cache, and disk. All hooks compile into nothingness if
|
||||
cleancache is config'ed off and turn into a function-pointer-
|
||||
compare-to-NULL if config'ed on but no backend claims the ops
|
||||
functions, or to a compare-struct-element-to-negative if a
|
||||
backend claims the ops functions but a filesystem doesn't enable
|
||||
cleancache.
|
||||
|
||||
Some filesystems are built entirely on top of VFS and the hooks
|
||||
in VFS are sufficient, so don't require an "init_fs" hook; the
|
||||
initial implementation of cleancache didn't provide this hook.
|
||||
But for some filesystems (such as btrfs), the VFS hooks are
|
||||
incomplete and one or more hooks in fs-specific code are required.
|
||||
And for some other filesystems, such as tmpfs, cleancache may
|
||||
be counterproductive. So it seemed prudent to require a filesystem
|
||||
to "opt in" to use cleancache, which requires adding a hook in
|
||||
each filesystem. Not all filesystems are supported by cleancache
|
||||
only because they haven't been tested. The existing set should
|
||||
be sufficient to validate the concept, the opt-in approach means
|
||||
that untested filesystems are not affected, and the hooks in the
|
||||
existing filesystems should make it very easy to add more
|
||||
filesystems in the future.
|
||||
|
||||
The total impact of the hooks to existing fs and mm files is only
|
||||
about 40 lines added (not counting comments and blank lines).
|
||||
|
||||
* Why not make cleancache asynchronous and batched so it can more
|
||||
easily interface with real devices with DMA instead of copying each
|
||||
individual page? (Minchan Kim)
|
||||
|
||||
The one-page-at-a-time copy semantics simplifies the implementation
|
||||
on both the frontend and backend and also allows the backend to
|
||||
do fancy things on-the-fly like page compression and
|
||||
page deduplication. And since the data is "gone" (copied into/out
|
||||
of the pageframe) before the cleancache get/put call returns,
|
||||
a great deal of race conditions and potential coherency issues
|
||||
are avoided. While the interface seems odd for a "real device"
|
||||
or for real kernel-addressable RAM, it makes perfect sense for
|
||||
transcendent memory.
|
||||
|
||||
* Why is non-shared cleancache "exclusive"? And where is the
|
||||
page "invalidated" after a "get"? (Minchan Kim)
|
||||
|
||||
The main reason is to free up space in transcendent memory and
|
||||
to avoid unnecessary cleancache_invalidate calls. If you want inclusive,
|
||||
the page can be "put" immediately following the "get". If
|
||||
put-after-get for inclusive becomes common, the interface could
|
||||
be easily extended to add a "get_no_invalidate" call.
|
||||
|
||||
The invalidate is done by the cleancache backend implementation.
|
||||
|
||||
* What's the performance impact?
|
||||
|
||||
Performance analysis has been presented at OLS'09 and LCA'10.
|
||||
Briefly, performance gains can be significant on most workloads,
|
||||
especially when memory pressure is high (e.g. when RAM is
|
||||
overcommitted in a virtual workload); and because the hooks are
|
||||
invoked primarily in place of or in addition to a disk read/write,
|
||||
overhead is negligible even in worst case workloads. Basically
|
||||
cleancache replaces I/O with memory-copy-CPU-overhead; on older
|
||||
single-core systems with slow memory-copy speeds, cleancache
|
||||
has little value, but in newer multicore machines, especially
|
||||
consolidated/virtualized machines, it has great value.
|
||||
|
||||
* How do I add cleancache support for filesystem X? (Boaz Harrash)
|
||||
|
||||
Filesystems that are well-behaved and conform to certain
|
||||
restrictions can utilize cleancache simply by making a call to
|
||||
cleancache_init_fs at mount time. Unusual, misbehaving, or
|
||||
poorly layered filesystems must either add additional hooks
|
||||
and/or undergo extensive additional testing... or should just
|
||||
not enable the optional cleancache.
|
||||
|
||||
Some points for a filesystem to consider:
|
||||
|
||||
- The FS should be block-device-based (e.g. a ram-based FS such
|
||||
as tmpfs should not enable cleancache)
|
||||
- To ensure coherency/correctness, the FS must ensure that all
|
||||
file removal or truncation operations either go through VFS or
|
||||
add hooks to do the equivalent cleancache "invalidate" operations
|
||||
- To ensure coherency/correctness, either inode numbers must
|
||||
be unique across the lifetime of the on-disk file OR the
|
||||
FS must provide an "encode_fh" function.
|
||||
- The FS must call the VFS superblock alloc and deactivate routines
|
||||
or add hooks to do the equivalent cleancache calls done there.
|
||||
- To maximize performance, all pages fetched from the FS should
|
||||
go through the do_mpag_readpage routine or the FS should add
|
||||
hooks to do the equivalent (cf. btrfs)
|
||||
- Currently, the FS blocksize must be the same as PAGESIZE. This
|
||||
is not an architectural restriction, but no backends currently
|
||||
support anything different.
|
||||
- A clustered FS should invoke the "shared_init_fs" cleancache
|
||||
hook to get best performance for some backends.
|
||||
|
||||
* Why not use the KVA of the inode as the key? (Christoph Hellwig)
|
||||
|
||||
If cleancache would use the inode virtual address instead of
|
||||
inode/filehandle, the pool id could be eliminated. But, this
|
||||
won't work because cleancache retains pagecache data pages
|
||||
persistently even when the inode has been pruned from the
|
||||
inode unused list, and only invalidates the data page if the file
|
||||
gets removed/truncated. So if cleancache used the inode kva,
|
||||
there would be potential coherency issues if/when the inode
|
||||
kva is reused for a different file. Alternately, if cleancache
|
||||
invalidated the pages when the inode kva was freed, much of the value
|
||||
of cleancache would be lost because the cache of pages in cleanache
|
||||
is potentially much larger than the kernel pagecache and is most
|
||||
useful if the pages survive inode cache removal.
|
||||
|
||||
* Why is a global variable required?
|
||||
|
||||
The cleancache_enabled flag is checked in all of the frequently-used
|
||||
cleancache hooks. The alternative is a function call to check a static
|
||||
variable. Since cleancache is enabled dynamically at runtime, systems
|
||||
that don't enable cleancache would suffer thousands (possibly
|
||||
tens-of-thousands) of unnecessary function calls per second. So the
|
||||
global variable allows cleancache to be enabled by default at compile
|
||||
time, but have insignificant performance impact when cleancache remains
|
||||
disabled at runtime.
|
||||
|
||||
* Does cleanache work with KVM?
|
||||
|
||||
The memory model of KVM is sufficiently different that a cleancache
|
||||
backend may have less value for KVM. This remains to be tested,
|
||||
especially in an overcommitted system.
|
||||
|
||||
* Does cleancache work in userspace? It sounds useful for
|
||||
memory hungry caches like web browsers. (Jamie Lokier)
|
||||
|
||||
No plans yet, though we agree it sounds useful, at least for
|
||||
apps that bypass the page cache (e.g. O_DIRECT).
|
||||
|
||||
Last updated: Dan Magenheimer, April 13 2011
|
|
@ -8,12 +8,6 @@ Frontswap provides a "transcendent memory" interface for swap pages.
|
|||
In some environments, dramatic performance savings may be obtained because
|
||||
swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
|
||||
|
||||
(Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends"
|
||||
and the only necessary changes to the core kernel for transcendent memory;
|
||||
all other supporting code -- the "backends" -- is implemented as drivers.
|
||||
See the LWN.net article `Transcendent memory in a nutshell`_
|
||||
for a detailed overview of frontswap and related kernel parts)
|
||||
|
||||
.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
|
||||
|
||||
Frontswap is so named because it can be thought of as the opposite of
|
||||
|
@ -45,12 +39,6 @@ a disk write and, if the data is later read back, a disk read are avoided.
|
|||
If a store returns failure, transcendent memory has rejected the data, and the
|
||||
page can be written to swap as usual.
|
||||
|
||||
If a backend chooses, frontswap can be configured as a "writethrough
|
||||
cache" by calling frontswap_writethrough(). In this mode, the reduction
|
||||
in swap device writes is lost (and also a non-trivial performance advantage)
|
||||
in order to allow the backend to arbitrarily "reclaim" space used to
|
||||
store frontswap pages to more completely manage its memory usage.
|
||||
|
||||
Note that if a page is stored and the page already exists in transcendent memory
|
||||
(a "duplicate" store), either the store succeeds and the data is overwritten,
|
||||
or the store fails AND the page is invalidated. This ensures stale data may
|
||||
|
@ -87,11 +75,9 @@ This interface is ideal when data is transformed to a different form
|
|||
and size (such as with compression) or secretly moved (as might be
|
||||
useful for write-balancing for some RAM-like devices). Swap pages (and
|
||||
evicted page-cache pages) are a great use for this kind of slower-than-RAM-
|
||||
but-much-faster-than-disk "pseudo-RAM device" and the frontswap (and
|
||||
cleancache) interface to transcendent memory provides a nice way to read
|
||||
and write -- and indirectly "name" -- the pages.
|
||||
but-much-faster-than-disk "pseudo-RAM device".
|
||||
|
||||
Frontswap -- and cleancache -- with a fairly small impact on the kernel,
|
||||
Frontswap with a fairly small impact on the kernel,
|
||||
provides a huge amount of flexibility for more dynamic, flexible RAM
|
||||
utilization in various system configurations:
|
||||
|
||||
|
@ -269,19 +255,6 @@ the old data and ensure that it is no longer accessible. Since the
|
|||
swap subsystem then writes the new data to the read swap device,
|
||||
this is the correct course of action to ensure coherency.
|
||||
|
||||
* What is frontswap_shrink for?
|
||||
|
||||
When the (non-frontswap) swap subsystem swaps out a page to a real
|
||||
swap device, that page is only taking up low-value pre-allocated disk
|
||||
space. But if frontswap has placed a page in transcendent memory, that
|
||||
page may be taking up valuable real estate. The frontswap_shrink
|
||||
routine allows code outside of the swap subsystem to force pages out
|
||||
of the memory managed by frontswap and back into kernel-addressable memory.
|
||||
For example, in RAMster, a "suction driver" thread will attempt
|
||||
to "repatriate" pages sent to a remote machine back to the local machine;
|
||||
this is driven using the frontswap_shrink mechanism when memory pressure
|
||||
subsides.
|
||||
|
||||
* Why does the frontswap patch create the new include file swapfile.h?
|
||||
|
||||
The frontswap code depends on some swap-subsystem-internal data
|
||||
|
|
|
@ -15,7 +15,6 @@ algorithms. If you are looking for advice on simply allocating memory, see the
|
|||
active_mm
|
||||
arch_pgtable_helpers
|
||||
balance
|
||||
cleancache
|
||||
damon/index
|
||||
free_page_reporting
|
||||
frontswap
|
||||
|
|
|
@ -9,7 +9,7 @@ Page Table Check
|
|||
Introduction
|
||||
============
|
||||
|
||||
Page table check allows to hardern the kernel by ensuring that some types of
|
||||
Page table check allows to harden the kernel by ensuring that some types of
|
||||
the memory corruptions are prevented.
|
||||
|
||||
Page table check performs extra verifications at the time when new pages become
|
||||
|
|
120
MAINTAINERS
120
MAINTAINERS
|
@ -190,8 +190,9 @@ M: Johannes Berg <johannes@sipsolutions.net>
|
|||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://wireless.wiki.kernel.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
|
||||
Q: https://patchwork.kernel.org/project/linux-wireless/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
|
||||
F: Documentation/driver-api/80211/cfg80211.rst
|
||||
F: Documentation/networking/regulatory.rst
|
||||
F: include/linux/ieee80211.h
|
||||
|
@ -1619,6 +1620,7 @@ M: Olof Johansson <olof@lixom.net>
|
|||
M: soc@kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
C: irc://irc.libera.chat/armlinux
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
|
||||
F: arch/arm/boot/dts/Makefile
|
||||
F: arch/arm64/boot/dts/Makefile
|
||||
|
@ -1626,6 +1628,7 @@ F: arch/arm64/boot/dts/Makefile
|
|||
ARM SUB-ARCHITECTURES
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
C: irc://irc.libera.chat/armlinux
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
|
||||
F: arch/arm/mach-*/
|
||||
F: arch/arm/plat-*/
|
||||
|
@ -1779,6 +1782,7 @@ F: drivers/irqchip/irq-apple-aic.c
|
|||
F: drivers/mailbox/apple-mailbox.c
|
||||
F: drivers/pinctrl/pinctrl-apple-gpio.c
|
||||
F: drivers/soc/apple/*
|
||||
F: drivers/watchdog/apple_wdt.c
|
||||
F: include/dt-bindings/interrupt-controller/apple-aic.h
|
||||
F: include/dt-bindings/pinctrl/apple.h
|
||||
F: include/linux/apple-mailbox.h
|
||||
|
@ -2569,10 +2573,13 @@ N: rockchip
|
|||
|
||||
ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES
|
||||
M: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
R: Alim Akhtar <alim.akhtar@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-samsung-soc@vger.kernel.org
|
||||
S: Maintained
|
||||
C: irc://irc.libera.chat/linux-exynos
|
||||
Q: https://patchwork.kernel.org/project/linux-samsung-soc/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
|
||||
F: Documentation/arm/samsung/
|
||||
F: Documentation/devicetree/bindings/arm/samsung/
|
||||
F: Documentation/devicetree/bindings/power/pd-samsung.yaml
|
||||
|
@ -3410,14 +3417,14 @@ M: Yury Norov <yury.norov@gmail.com>
|
|||
R: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
||||
R: Rasmus Villemoes <linux@rasmusvillemoes.dk>
|
||||
S: Maintained
|
||||
F: include/asm-generic/bitops/find.h
|
||||
F: include/linux/bitmap.h
|
||||
F: include/linux/find.h
|
||||
F: lib/bitmap.c
|
||||
F: lib/find_bit.c
|
||||
F: lib/find_bit_benchmark.c
|
||||
F: lib/test_bitmap.c
|
||||
F: tools/include/asm-generic/bitops/find.h
|
||||
F: tools/include/linux/bitmap.h
|
||||
F: tools/include/linux/find.h
|
||||
F: tools/lib/bitmap.c
|
||||
F: tools/lib/find_bit.c
|
||||
|
||||
|
@ -4156,9 +4163,8 @@ N: csky
|
|||
K: csky
|
||||
|
||||
CA8210 IEEE-802.15.4 RADIO DRIVER
|
||||
M: Harry Morris <h.morris@cascoda.com>
|
||||
L: linux-wpan@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
W: https://github.com/Cascoda/ca8210-linux.git
|
||||
F: Documentation/devicetree/bindings/net/ieee802154/ca8210.txt
|
||||
F: drivers/net/ieee802154/ca8210.c
|
||||
|
@ -4705,13 +4711,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/cla
|
|||
F: include/linux/cfi.h
|
||||
F: kernel/cfi.c
|
||||
|
||||
CLEANCACHE API
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: include/linux/cleancache.h
|
||||
F: mm/cleancache.c
|
||||
|
||||
CLK API
|
||||
M: Russell King <linux@armlinux.org.uk>
|
||||
L: linux-clk@vger.kernel.org
|
||||
|
@ -5779,7 +5778,7 @@ F: tools/testing/selftests/dma/
|
|||
|
||||
DMA-BUF HEAPS FRAMEWORK
|
||||
M: Sumit Semwal <sumit.semwal@linaro.org>
|
||||
R: Benjamin Gaignard <benjamin.gaignard@linaro.org>
|
||||
R: Benjamin Gaignard <benjamin.gaignard@collabora.com>
|
||||
R: Liam Mark <lmark@codeaurora.org>
|
||||
R: Laura Abbott <labbott@redhat.com>
|
||||
R: Brian Starkey <Brian.Starkey@arm.com>
|
||||
|
@ -6509,7 +6508,7 @@ F: Documentation/devicetree/bindings/display/rockchip/
|
|||
F: drivers/gpu/drm/rockchip/
|
||||
|
||||
DRM DRIVERS FOR STI
|
||||
M: Benjamin Gaignard <benjamin.gaignard@linaro.org>
|
||||
M: Alain Volmat <alain.volmat@foss.st.com>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Maintained
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
|
@ -6518,8 +6517,8 @@ F: drivers/gpu/drm/sti
|
|||
|
||||
DRM DRIVERS FOR STM
|
||||
M: Yannick Fertre <yannick.fertre@foss.st.com>
|
||||
M: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
|
||||
M: Philippe Cornu <philippe.cornu@foss.st.com>
|
||||
M: Benjamin Gaignard <benjamin.gaignard@linaro.org>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Maintained
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
|
@ -7215,8 +7214,10 @@ F: drivers/net/mdio/of_mdio.c
|
|||
F: drivers/net/pcs/
|
||||
F: drivers/net/phy/
|
||||
F: include/dt-bindings/net/qca-ar803x.h
|
||||
F: include/linux/linkmode.h
|
||||
F: include/linux/*mdio*.h
|
||||
F: include/linux/mdio/*.h
|
||||
F: include/linux/mii.h
|
||||
F: include/linux/of_net.h
|
||||
F: include/linux/phy.h
|
||||
F: include/linux/phy_fixed.h
|
||||
|
@ -7580,6 +7581,12 @@ S: Maintained
|
|||
W: http://floatingpoint.sourceforge.net/emulator/index.html
|
||||
F: arch/x86/math-emu/
|
||||
|
||||
FRAMEBUFFER CORE
|
||||
M: Daniel Vetter <daniel@ffwll.ch>
|
||||
F: drivers/video/fbdev/core/
|
||||
S: Odd Fixes
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
|
||||
FRAMEBUFFER LAYER
|
||||
M: Helge Deller <deller@gmx.de>
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
|
@ -10884,6 +10891,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
|||
F: drivers/ata/pata_arasan_cf.c
|
||||
F: include/linux/pata_arasan_cf_data.h
|
||||
|
||||
LIBATA PATA DRIVERS
|
||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
||||
L: linux-ide@vger.kernel.org
|
||||
F: drivers/ata/ata_*.c
|
||||
F: drivers/ata/pata_*.c
|
||||
|
||||
LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
|
||||
M: Linus Walleij <linus.walleij@linaro.org>
|
||||
L: linux-ide@vger.kernel.org
|
||||
|
@ -11373,8 +11386,9 @@ M: Johannes Berg <johannes@sipsolutions.net>
|
|||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://wireless.wiki.kernel.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
|
||||
Q: https://patchwork.kernel.org/project/linux-wireless/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
|
||||
F: Documentation/networking/mac80211-injection.rst
|
||||
F: Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
|
||||
F: drivers/net/wireless/mac80211_hwsim.[ch]
|
||||
|
@ -12403,7 +12417,7 @@ F: include/uapi/linux/membarrier.h
|
|||
F: kernel/sched/membarrier.c
|
||||
|
||||
MEMBLOCK
|
||||
M: Mike Rapoport <rppt@linux.ibm.com>
|
||||
M: Mike Rapoport <rppt@kernel.org>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: Documentation/core-api/boot-time-mm.rst
|
||||
|
@ -13301,8 +13315,8 @@ W: http://www.iptables.org/
|
|||
W: http://www.nftables.org/
|
||||
Q: http://patchwork.ozlabs.org/project/netfilter-devel/list/
|
||||
C: irc://irc.libera.chat/netfilter
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git
|
||||
F: include/linux/netfilter*
|
||||
F: include/linux/netfilter/
|
||||
F: include/net/netfilter/
|
||||
|
@ -13381,9 +13395,10 @@ NETWORKING DRIVERS (WIRELESS)
|
|||
M: Kalle Valo <kvalo@kernel.org>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
Q: http://patchwork.kernel.org/project/linux-wireless/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
|
||||
W: https://wireless.wiki.kernel.org/
|
||||
Q: https://patchwork.kernel.org/project/linux-wireless/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
|
||||
F: Documentation/devicetree/bindings/net/wireless/
|
||||
F: drivers/net/wireless/
|
||||
|
||||
|
@ -13456,7 +13471,11 @@ L: netdev@vger.kernel.org
|
|||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
|
||||
F: arch/x86/net/*
|
||||
F: include/linux/ip.h
|
||||
F: include/linux/ipv6*
|
||||
F: include/net/fib*
|
||||
F: include/net/ip*
|
||||
F: include/net/route.h
|
||||
F: net/ipv4/
|
||||
F: net/ipv6/
|
||||
|
||||
|
@ -13517,10 +13536,6 @@ F: include/net/tls.h
|
|||
F: include/uapi/linux/tls.h
|
||||
F: net/tls/*
|
||||
|
||||
NETWORKING [WIRELESS]
|
||||
L: linux-wireless@vger.kernel.org
|
||||
Q: http://patchwork.kernel.org/project/linux-wireless/list/
|
||||
|
||||
NETXEN (1/10) GbE SUPPORT
|
||||
M: Manish Chopra <manishc@marvell.com>
|
||||
M: Rahul Verma <rahulv@marvell.com>
|
||||
|
@ -13568,7 +13583,7 @@ F: tools/testing/selftests/nci/
|
|||
|
||||
NFS, SUNRPC, AND LOCKD CLIENTS
|
||||
M: Trond Myklebust <trond.myklebust@hammerspace.com>
|
||||
M: Anna Schumaker <anna.schumaker@netapp.com>
|
||||
M: Anna Schumaker <anna@kernel.org>
|
||||
L: linux-nfs@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://client.linux-nfs.org
|
||||
|
@ -14386,6 +14401,7 @@ M: Rob Herring <robh+dt@kernel.org>
|
|||
M: Frank Rowand <frowand.list@gmail.com>
|
||||
L: devicetree@vger.kernel.org
|
||||
S: Maintained
|
||||
C: irc://irc.libera.chat/devicetree
|
||||
W: http://www.devicetree.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
|
||||
F: Documentation/ABI/testing/sysfs-firmware-ofw
|
||||
|
@ -14397,6 +14413,7 @@ OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
|
|||
M: Rob Herring <robh+dt@kernel.org>
|
||||
L: devicetree@vger.kernel.org
|
||||
S: Maintained
|
||||
C: irc://irc.libera.chat/devicetree
|
||||
Q: http://patchwork.ozlabs.org/project/devicetree-bindings/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
|
||||
F: Documentation/devicetree/
|
||||
|
@ -15287,9 +15304,11 @@ PIN CONTROLLER - SAMSUNG
|
|||
M: Tomasz Figa <tomasz.figa@gmail.com>
|
||||
M: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
R: Alim Akhtar <alim.akhtar@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-samsung-soc@vger.kernel.org
|
||||
S: Maintained
|
||||
C: irc://irc.libera.chat/linux-exynos
|
||||
Q: https://patchwork.kernel.org/project/linux-samsung-soc/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git
|
||||
F: Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
|
||||
|
@ -16471,6 +16490,14 @@ F: Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml
|
|||
F: drivers/i2c/busses/i2c-rcar.c
|
||||
F: drivers/i2c/busses/i2c-sh_mobile.c
|
||||
|
||||
RENESAS R-CAR SATA DRIVER
|
||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
||||
S: Supported
|
||||
L: linux-ide@vger.kernel.org
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
F: Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
|
||||
F: drivers/ata/sata_rcar.c
|
||||
|
||||
RENESAS R-CAR THERMAL DRIVERS
|
||||
M: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
|
@ -16539,8 +16566,9 @@ M: Johannes Berg <johannes@sipsolutions.net>
|
|||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://wireless.wiki.kernel.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
|
||||
Q: https://patchwork.kernel.org/project/linux-wireless/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
|
||||
F: Documentation/ABI/stable/sysfs-class-rfkill
|
||||
F: Documentation/driver-api/rfkill.rst
|
||||
F: include/linux/rfkill.h
|
||||
|
@ -16805,8 +16833,8 @@ F: drivers/video/fbdev/savage/
|
|||
S390
|
||||
M: Heiko Carstens <hca@linux.ibm.com>
|
||||
M: Vasily Gorbik <gor@linux.ibm.com>
|
||||
M: Christian Borntraeger <borntraeger@linux.ibm.com>
|
||||
R: Alexander Gordeev <agordeev@linux.ibm.com>
|
||||
M: Alexander Gordeev <agordeev@linux.ibm.com>
|
||||
R: Christian Borntraeger <borntraeger@linux.ibm.com>
|
||||
R: Sven Schnelle <svens@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
S: Supported
|
||||
|
@ -17077,6 +17105,7 @@ SAMSUNG SOC CLOCK DRIVERS
|
|||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
M: Tomasz Figa <tomasz.figa@gmail.com>
|
||||
M: Chanwoo Choi <cw00.choi@samsung.com>
|
||||
R: Alim Akhtar <alim.akhtar@samsung.com>
|
||||
L: linux-samsung-soc@vger.kernel.org
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk.git
|
||||
|
@ -17713,6 +17742,21 @@ S: Maintained
|
|||
W: http://www.winischhofer.at/linuxsisusbvga.shtml
|
||||
F: drivers/usb/misc/sisusbvga/
|
||||
|
||||
SL28 CPLD MFD DRIVER
|
||||
M: Michael Walle <michael@walle.cc>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
|
||||
F: Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
|
||||
F: Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
|
||||
F: Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml
|
||||
F: Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
|
||||
F: Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
|
||||
F: drivers/gpio/gpio-sl28cpld.c
|
||||
F: drivers/hwmon/sl28cpld-hwmon.c
|
||||
F: drivers/irqchip/irq-sl28cpld.c
|
||||
F: drivers/pwm/pwm-sl28cpld.c
|
||||
F: drivers/watchdog/sl28cpld_wdt.c
|
||||
|
||||
SLAB ALLOCATOR
|
||||
M: Christoph Lameter <cl@linux.com>
|
||||
M: Pekka Enberg <penberg@kernel.org>
|
||||
|
@ -18429,7 +18473,7 @@ F: Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt
|
|||
F: sound/soc/sti/
|
||||
|
||||
STI CEC DRIVER
|
||||
M: Benjamin Gaignard <benjamin.gaignard@linaro.org>
|
||||
M: Alain Volmat <alain.volmat@foss.st.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/media/stih-cec.txt
|
||||
F: drivers/media/cec/platform/sti/
|
||||
|
@ -19583,6 +19627,14 @@ F: Documentation/trace/timerlat-tracer.rst
|
|||
F: Documentation/trace/hwlat_detector.rst
|
||||
F: arch/*/kernel/trace.c
|
||||
|
||||
Real-time Linux Analysis (RTLA) tools
|
||||
M: Daniel Bristot de Oliveira <bristot@kernel.org>
|
||||
M: Steven Rostedt <rostedt@goodmis.org>
|
||||
L: linux-trace-devel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/tools/rtla/
|
||||
F: tools/tracing/rtla/
|
||||
|
||||
TRADITIONAL CHINESE DOCUMENTATION
|
||||
M: Hu Haowen <src.res@email.cn>
|
||||
L: linux-doc-tw-discuss@lists.sourceforge.net
|
||||
|
|
8
Makefile
8
Makefile
|
@ -1,9 +1,9 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
VERSION = 5
|
||||
PATCHLEVEL = 16
|
||||
PATCHLEVEL = 17
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION =
|
||||
NAME = Gobble Gobble
|
||||
EXTRAVERSION = -rc4
|
||||
NAME = Superb Owl
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
@ -778,7 +778,7 @@ stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong
|
|||
KBUILD_CFLAGS += $(stackp-flags-y)
|
||||
|
||||
KBUILD_CFLAGS-$(CONFIG_WERROR) += -Werror
|
||||
KBUILD_CFLAGS += $(KBUILD_CFLAGS-y) $(CONFIG_CC_IMPLICIT_FALLTHROUGH:"%"=%)
|
||||
KBUILD_CFLAGS += $(KBUILD_CFLAGS-y) $(CONFIG_CC_IMPLICIT_FALLTHROUGH)
|
||||
|
||||
ifdef CONFIG_CC_IS_CLANG
|
||||
KBUILD_CPPFLAGS += -Qunused-arguments
|
||||
|
|
|
@ -430,8 +430,6 @@ static inline unsigned int __arch_hweight8(unsigned int w)
|
|||
|
||||
#endif /* __KERNEL__ */
|
||||
|
||||
#include <asm-generic/bitops/find.h>
|
||||
|
||||
#ifdef __KERNEL__
|
||||
|
||||
/*
|
||||
|
|
|
@ -83,14 +83,14 @@ static int srm_env_proc_show(struct seq_file *m, void *v)
|
|||
|
||||
static int srm_env_proc_open(struct inode *inode, struct file *file)
|
||||
{
|
||||
return single_open(file, srm_env_proc_show, PDE_DATA(inode));
|
||||
return single_open(file, srm_env_proc_show, pde_data(inode));
|
||||
}
|
||||
|
||||
static ssize_t srm_env_proc_write(struct file *file, const char __user *buffer,
|
||||
size_t count, loff_t *pos)
|
||||
{
|
||||
int res;
|
||||
unsigned long id = (unsigned long)PDE_DATA(file_inode(file));
|
||||
unsigned long id = (unsigned long)pde_data(file_inode(file));
|
||||
char *buf = (char *) __get_free_page(GFP_USER);
|
||||
unsigned long ret1, ret2;
|
||||
|
||||
|
|
|
@ -20,7 +20,6 @@ config ARC
|
|||
select COMMON_CLK
|
||||
select DMA_DIRECT_REMAP
|
||||
select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
|
||||
select GENERIC_FIND_FIRST_BIT
|
||||
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
|
||||
select GENERIC_IRQ_SHOW
|
||||
select GENERIC_PCI_IOMAP
|
||||
|
|
|
@ -189,7 +189,6 @@ static inline __attribute__ ((const)) unsigned long __ffs(unsigned long x)
|
|||
#include <asm-generic/bitops/atomic.h>
|
||||
#include <asm-generic/bitops/non-atomic.h>
|
||||
|
||||
#include <asm-generic/bitops/find.h>
|
||||
#include <asm-generic/bitops/le.h>
|
||||
#include <asm-generic/bitops/ext2-atomic-setbit.h>
|
||||
|
||||
|
|
|
@ -83,6 +83,7 @@ config ARM
|
|||
select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32
|
||||
select HAVE_CONTEXT_TRACKING
|
||||
select HAVE_C_RECORDMCOUNT
|
||||
select HAVE_BUILDTIME_MCOUNT_SORT
|
||||
select HAVE_DEBUG_KMEMLEAK if !XIP_KERNEL
|
||||
select HAVE_DMA_CONTIGUOUS if MMU
|
||||
select HAVE_DYNAMIC_FTRACE if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
|
||||
|
|
|
@ -806,6 +806,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
|
|||
logicpd-som-lv-37xx-devkit.dtb \
|
||||
omap3430-sdp.dtb \
|
||||
omap3-beagle.dtb \
|
||||
omap3-beagle-ab4.dtb \
|
||||
omap3-beagle-xm.dtb \
|
||||
omap3-beagle-xm-ab.dtb \
|
||||
omap3-cm-t3517.dtb \
|
||||
|
|
|
@ -55,7 +55,7 @@
|
|||
2 1 0 0 /* # 0: INACTIVE, 1: TX, 2: RX */
|
||||
>;
|
||||
tx-num-evt = <16>;
|
||||
rt-num-evt = <16>;
|
||||
rx-num-evt = <16>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
|
|
@ -160,7 +160,7 @@
|
|||
target-module@48210000 {
|
||||
compatible = "ti,sysc-omap4-simple", "ti,sysc";
|
||||
power-domains = <&prm_mpu>;
|
||||
clocks = <&mpu_clkctrl DRA7_MPU_CLKCTRL 0>;
|
||||
clocks = <&mpu_clkctrl DRA7_MPU_MPU_CLKCTRL 0>;
|
||||
clock-names = "fck";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
@ -875,10 +875,10 @@
|
|||
<0x58000014 4>;
|
||||
reg-names = "rev", "syss";
|
||||
ti,syss-mask = <1>;
|
||||
clocks = <&dss_clkctrl DRA7_DSS_CORE_CLKCTRL 0>,
|
||||
<&dss_clkctrl DRA7_DSS_CORE_CLKCTRL 9>,
|
||||
<&dss_clkctrl DRA7_DSS_CORE_CLKCTRL 10>,
|
||||
<&dss_clkctrl DRA7_DSS_CORE_CLKCTRL 11>;
|
||||
clocks = <&dss_clkctrl DRA7_DSS_DSS_CORE_CLKCTRL 0>,
|
||||
<&dss_clkctrl DRA7_DSS_DSS_CORE_CLKCTRL 9>,
|
||||
<&dss_clkctrl DRA7_DSS_DSS_CORE_CLKCTRL 10>,
|
||||
<&dss_clkctrl DRA7_DSS_DSS_CORE_CLKCTRL 11>;
|
||||
clock-names = "fck", "hdmi_clk", "sys_clk", "tv_clk";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
@ -912,7 +912,7 @@
|
|||
SYSC_OMAP2_SOFTRESET |
|
||||
SYSC_OMAP2_AUTOIDLE)>;
|
||||
ti,syss-mask = <1>;
|
||||
clocks = <&dss_clkctrl DRA7_DSS_CORE_CLKCTRL 8>;
|
||||
clocks = <&dss_clkctrl DRA7_DSS_DSS_CORE_CLKCTRL 8>;
|
||||
clock-names = "fck";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
@ -939,8 +939,8 @@
|
|||
<SYSC_IDLE_SMART>,
|
||||
<SYSC_IDLE_SMART_WKUP>;
|
||||
ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET)>;
|
||||
clocks = <&dss_clkctrl DRA7_DSS_CORE_CLKCTRL 9>,
|
||||
<&dss_clkctrl DRA7_DSS_CORE_CLKCTRL 8>;
|
||||
clocks = <&dss_clkctrl DRA7_DSS_DSS_CORE_CLKCTRL 9>,
|
||||
<&dss_clkctrl DRA7_DSS_DSS_CORE_CLKCTRL 8>;
|
||||
clock-names = "fck", "dss_clk";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
@ -979,7 +979,7 @@
|
|||
compatible = "vivante,gc";
|
||||
reg = <0x0 0x700>;
|
||||
interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&dss_clkctrl DRA7_BB2D_CLKCTRL 0>;
|
||||
clocks = <&dss_clkctrl DRA7_DSS_BB2D_CLKCTRL 0>;
|
||||
clock-names = "core";
|
||||
};
|
||||
};
|
||||
|
@ -1333,7 +1333,7 @@
|
|||
ti,no-reset-on-init;
|
||||
ti,no-idle;
|
||||
timer@0 {
|
||||
assigned-clocks = <&wkupaon_clkctrl DRA7_TIMER1_CLKCTRL 24>;
|
||||
assigned-clocks = <&wkupaon_clkctrl DRA7_WKUPAON_TIMER1_CLKCTRL 24>;
|
||||
assigned-clock-parents = <&sys_32k_ck>;
|
||||
};
|
||||
};
|
||||
|
|
|
@ -79,7 +79,6 @@
|
|||
MX23_PAD_LCD_RESET__GPIO_1_18
|
||||
MX23_PAD_PWM3__GPIO_1_29
|
||||
MX23_PAD_PWM4__GPIO_1_30
|
||||
MX23_PAD_SSP1_DETECT__SSP1_DETECT
|
||||
>;
|
||||
fsl,drive-strength = <MXS_DRIVE_4mA>;
|
||||
fsl,voltage = <MXS_VOLTAGE_HIGH>;
|
||||
|
|
|
@ -5,6 +5,8 @@
|
|||
* Author: Fabio Estevam <fabio.estevam@freescale.com>
|
||||
*/
|
||||
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
/ {
|
||||
aliases {
|
||||
backlight = &backlight;
|
||||
|
@ -226,6 +228,7 @@
|
|||
MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
|
||||
MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
|
||||
MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
|
||||
MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1b0b0
|
||||
>;
|
||||
};
|
||||
|
||||
|
@ -304,7 +307,7 @@
|
|||
&usdhc3 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_usdhc3>;
|
||||
non-removable;
|
||||
cd-gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
|
|
@ -259,7 +259,7 @@
|
|||
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
|
||||
assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
|
||||
assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
|
||||
assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
|
||||
timeout-sec = <40>;
|
||||
};
|
||||
|
||||
|
|
|
@ -59,7 +59,7 @@
|
|||
};
|
||||
|
||||
uart_A: serial@84c0 {
|
||||
compatible = "amlogic,meson6-uart", "amlogic,meson-uart";
|
||||
compatible = "amlogic,meson6-uart";
|
||||
reg = <0x84c0 0x18>;
|
||||
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
|
||||
fifo-size = <128>;
|
||||
|
@ -67,7 +67,7 @@
|
|||
};
|
||||
|
||||
uart_B: serial@84dc {
|
||||
compatible = "amlogic,meson6-uart", "amlogic,meson-uart";
|
||||
compatible = "amlogic,meson6-uart";
|
||||
reg = <0x84dc 0x18>;
|
||||
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
|
||||
status = "disabled";
|
||||
|
@ -105,7 +105,7 @@
|
|||
};
|
||||
|
||||
uart_C: serial@8700 {
|
||||
compatible = "amlogic,meson6-uart", "amlogic,meson-uart";
|
||||
compatible = "amlogic,meson6-uart";
|
||||
reg = <0x8700 0x18>;
|
||||
interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
|
||||
status = "disabled";
|
||||
|
@ -228,7 +228,7 @@
|
|||
};
|
||||
|
||||
uart_AO: serial@4c0 {
|
||||
compatible = "amlogic,meson6-uart", "amlogic,meson-ao-uart", "amlogic,meson-uart";
|
||||
compatible = "amlogic,meson6-uart", "amlogic,meson-ao-uart";
|
||||
reg = <0x4c0 0x18>;
|
||||
interrupts = <GIC_SPI 90 IRQ_TYPE_EDGE_RISING>;
|
||||
status = "disabled";
|
||||
|
|
|
@ -736,27 +736,27 @@
|
|||
};
|
||||
|
||||
&uart_AO {
|
||||
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8-uart", "amlogic,meson-ao-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&uart_A {
|
||||
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART0>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&uart_B {
|
||||
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART1>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&uart_C {
|
||||
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART2>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&usb0 {
|
||||
|
|
|
@ -724,27 +724,27 @@
|
|||
};
|
||||
|
||||
&uart_AO {
|
||||
compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8b-uart", "amlogic,meson-ao-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&uart_A {
|
||||
compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART0>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8b-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&uart_B {
|
||||
compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART1>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8b-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&uart_C {
|
||||
compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
|
||||
clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART2>;
|
||||
clock-names = "baud", "xtal", "pclk";
|
||||
compatible = "amlogic,meson8b-uart";
|
||||
clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "pclk", "baud";
|
||||
};
|
||||
|
||||
&usb0 {
|
||||
|
|
|
@ -0,0 +1,47 @@
|
|||
// SPDX-License-Identifier: GPL-2.0-only
|
||||
/dts-v1/;
|
||||
|
||||
#include "omap3-beagle.dts"
|
||||
|
||||
/ {
|
||||
model = "TI OMAP3 BeagleBoard A to B4";
|
||||
compatible = "ti,omap3-beagle-ab4", "ti,omap3-beagle", "ti,omap3430", "ti,omap3";
|
||||
};
|
||||
|
||||
/*
|
||||
* Workaround for capacitor C70 issue, see "Boards revision A and < B5"
|
||||
* section at https://elinux.org/BeagleBoard_Community
|
||||
*/
|
||||
|
||||
/* Unusable as clocksource because of unreliable oscillator */
|
||||
&counter32k {
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
/* Unusable as clockevent because of unreliable oscillator, allow to idle */
|
||||
&timer1_target {
|
||||
/delete-property/ti,no-reset-on-init;
|
||||
/delete-property/ti,no-idle;
|
||||
timer@0 {
|
||||
/delete-property/ti,timer-alwon;
|
||||
};
|
||||
};
|
||||
|
||||
/* Preferred always-on timer for clocksource */
|
||||
&timer12_target {
|
||||
ti,no-reset-on-init;
|
||||
ti,no-idle;
|
||||
timer@0 {
|
||||
/* Always clocked by secure_32k_fck */
|
||||
};
|
||||
};
|
||||
|
||||
/* Preferred timer for clockevent */
|
||||
&timer2_target {
|
||||
ti,no-reset-on-init;
|
||||
ti,no-idle;
|
||||
timer@0 {
|
||||
assigned-clocks = <&gpt2_fck>;
|
||||
assigned-clock-parents = <&sys_ck>;
|
||||
};
|
||||
};
|
|
@ -304,39 +304,6 @@
|
|||
phys = <0 &hsusb2_phy>;
|
||||
};
|
||||
|
||||
/* Unusable as clocksource because of unreliable oscillator */
|
||||
&counter32k {
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
/* Unusable as clockevent because if unreliable oscillator, allow to idle */
|
||||
&timer1_target {
|
||||
/delete-property/ti,no-reset-on-init;
|
||||
/delete-property/ti,no-idle;
|
||||
timer@0 {
|
||||
/delete-property/ti,timer-alwon;
|
||||
};
|
||||
};
|
||||
|
||||
/* Preferred always-on timer for clocksource */
|
||||
&timer12_target {
|
||||
ti,no-reset-on-init;
|
||||
ti,no-idle;
|
||||
timer@0 {
|
||||
/* Always clocked by secure_32k_fck */
|
||||
};
|
||||
};
|
||||
|
||||
/* Preferred timer for clockevent */
|
||||
&timer2_target {
|
||||
ti,no-reset-on-init;
|
||||
ti,no-idle;
|
||||
timer@0 {
|
||||
assigned-clocks = <&gpt2_fck>;
|
||||
assigned-clock-parents = <&sys_ck>;
|
||||
};
|
||||
};
|
||||
|
||||
&twl_gpio {
|
||||
ti,use-leds;
|
||||
/* pullups: BIT(1) */
|
||||
|
|
|
@ -235,7 +235,6 @@
|
|||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x41>;
|
||||
irq-over-gpio;
|
||||
irq-gpios = <&gpiopinctrl 29 0x4>;
|
||||
id = <0>;
|
||||
blocks = <0x5>;
|
||||
|
|
|
@ -185,10 +185,6 @@
|
|||
cap-sd-highspeed;
|
||||
cap-mmc-highspeed;
|
||||
/* All direction control is used */
|
||||
st,sig-dir-cmd;
|
||||
st,sig-dir-dat0;
|
||||
st,sig-dir-dat2;
|
||||
st,sig-dir-dat31;
|
||||
st,sig-pin-fbclk;
|
||||
full-pwr-cycle;
|
||||
vmmc-supply = <&ab8500_ldo_aux3_reg>;
|
||||
|
|
|
@ -31,7 +31,6 @@ CONFIG_ARCH_BCM2835=y
|
|||
CONFIG_PREEMPT_VOLUNTARY=y
|
||||
CONFIG_AEABI=y
|
||||
CONFIG_KSM=y
|
||||
CONFIG_CLEANCACHE=y
|
||||
CONFIG_CMA=y
|
||||
CONFIG_SECCOMP=y
|
||||
CONFIG_KEXEC=y
|
||||
|
|
|
@ -27,7 +27,6 @@ CONFIG_PCIE_QCOM=y
|
|||
CONFIG_SMP=y
|
||||
CONFIG_PREEMPT=y
|
||||
CONFIG_HIGHMEM=y
|
||||
CONFIG_CLEANCACHE=y
|
||||
CONFIG_ARM_APPENDED_DTB=y
|
||||
CONFIG_ARM_ATAG_DTB_COMPAT=y
|
||||
CONFIG_CPU_IDLE=y
|
||||
|
|
|
@ -13,12 +13,12 @@
|
|||
static int crypto_blake2s_update_arm(struct shash_desc *desc,
|
||||
const u8 *in, unsigned int inlen)
|
||||
{
|
||||
return crypto_blake2s_update(desc, in, inlen, blake2s_compress);
|
||||
return crypto_blake2s_update(desc, in, inlen, false);
|
||||
}
|
||||
|
||||
static int crypto_blake2s_final_arm(struct shash_desc *desc, u8 *out)
|
||||
{
|
||||
return crypto_blake2s_final(desc, out, blake2s_compress);
|
||||
return crypto_blake2s_final(desc, out, false);
|
||||
}
|
||||
|
||||
#define BLAKE2S_ALG(name, driver_name, digest_size) \
|
||||
|
|
|
@ -288,6 +288,7 @@
|
|||
*/
|
||||
#define ALT_UP(instr...) \
|
||||
.pushsection ".alt.smp.init", "a" ;\
|
||||
.align 2 ;\
|
||||
.long 9998b - . ;\
|
||||
9997: instr ;\
|
||||
.if . - 9997b == 2 ;\
|
||||
|
@ -299,6 +300,7 @@
|
|||
.popsection
|
||||
#define ALT_UP_B(label) \
|
||||
.pushsection ".alt.smp.init", "a" ;\
|
||||
.align 2 ;\
|
||||
.long 9998b - . ;\
|
||||
W(b) . + (label - 9998b) ;\
|
||||
.popsection
|
||||
|
|
|
@ -264,7 +264,6 @@ static inline int find_next_bit_le(const void *p, int size, int offset)
|
|||
|
||||
#endif
|
||||
|
||||
#include <asm-generic/bitops/find.h>
|
||||
#include <asm-generic/bitops/le.h>
|
||||
|
||||
/*
|
||||
|
|
|
@ -96,6 +96,7 @@ unsigned long __get_wchan(struct task_struct *p);
|
|||
#define __ALT_SMP_ASM(smp, up) \
|
||||
"9998: " smp "\n" \
|
||||
" .pushsection \".alt.smp.init\", \"a\"\n" \
|
||||
" .align 2\n" \
|
||||
" .long 9998b - .\n" \
|
||||
" " up "\n" \
|
||||
" .popsection\n"
|
||||
|
|
|
@ -11,6 +11,7 @@
|
|||
#include <linux/string.h>
|
||||
#include <asm/memory.h>
|
||||
#include <asm/domain.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <asm/unified.h>
|
||||
#include <asm/compiler.h>
|
||||
|
||||
|
@ -497,7 +498,10 @@ do { \
|
|||
} \
|
||||
default: __err = __get_user_bad(); break; \
|
||||
} \
|
||||
*(type *)(dst) = __val; \
|
||||
if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)) \
|
||||
put_unaligned(__val, (type *)(dst)); \
|
||||
else \
|
||||
*(type *)(dst) = __val; /* aligned by caller */ \
|
||||
if (__err) \
|
||||
goto err_label; \
|
||||
} while (0)
|
||||
|
@ -507,7 +511,9 @@ do { \
|
|||
const type *__pk_ptr = (dst); \
|
||||
unsigned long __dst = (unsigned long)__pk_ptr; \
|
||||
int __err = 0; \
|
||||
type __val = *(type *)src; \
|
||||
type __val = IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) \
|
||||
? get_unaligned((type *)(src)) \
|
||||
: *(type *)(src); /* aligned by caller */ \
|
||||
switch (sizeof(type)) { \
|
||||
case 1: __put_user_asm_byte(__val, __dst, __err, ""); break; \
|
||||
case 2: __put_user_asm_half(__val, __dst, __err, ""); break; \
|
||||
|
|
|
@ -13,7 +13,7 @@ struct buffer {
|
|||
static ssize_t atags_read(struct file *file, char __user *buf,
|
||||
size_t count, loff_t *ppos)
|
||||
{
|
||||
struct buffer *b = PDE_DATA(file_inode(file));
|
||||
struct buffer *b = pde_data(file_inode(file));
|
||||
return simple_read_from_buffer(buf, count, ppos, b->data, b->size);
|
||||
}
|
||||
|
||||
|
|
|
@ -263,9 +263,9 @@ static int __init omapdss_init_of(void)
|
|||
}
|
||||
|
||||
r = of_platform_populate(node, NULL, NULL, &pdev->dev);
|
||||
put_device(&pdev->dev);
|
||||
if (r) {
|
||||
pr_err("Unable to populate DSS submodule devices\n");
|
||||
put_device(&pdev->dev);
|
||||
return r;
|
||||
}
|
||||
|
||||
|
|
|
@ -752,8 +752,10 @@ static int __init _init_clkctrl_providers(void)
|
|||
|
||||
for_each_matching_node(np, ti_clkctrl_match_table) {
|
||||
ret = _setup_clkctrl_provider(np);
|
||||
if (ret)
|
||||
if (ret) {
|
||||
of_node_put(np);
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
return ret;
|
||||
|
|
|
@ -2,6 +2,7 @@
|
|||
menuconfig ARCH_INTEL_SOCFPGA
|
||||
bool "Altera SOCFPGA family"
|
||||
depends on ARCH_MULTI_V7
|
||||
select ARCH_HAS_RESET_CONTROLLER
|
||||
select ARCH_SUPPORTS_BIG_ENDIAN
|
||||
select ARM_AMBA
|
||||
select ARM_GIC
|
||||
|
@ -18,6 +19,7 @@ menuconfig ARCH_INTEL_SOCFPGA
|
|||
select PL310_ERRATA_727915
|
||||
select PL310_ERRATA_753970 if PL310
|
||||
select PL310_ERRATA_769419
|
||||
select RESET_CONTROLLER
|
||||
|
||||
if ARCH_INTEL_SOCFPGA
|
||||
config SOCFPGA_SUSPEND
|
||||
|
|
|
@ -1005,7 +1005,7 @@ static int __init noalign_setup(char *__unused)
|
|||
__setup("noalign", noalign_setup);
|
||||
|
||||
/*
|
||||
* This needs to be done after sysctl_init, otherwise sys/ will be
|
||||
* This needs to be done after sysctl_init_bases(), otherwise sys/ will be
|
||||
* overwritten. Actually, this shouldn't be in sys/ at all since
|
||||
* it isn't a sysctl, and it doesn't contain sysctl information.
|
||||
* We now locate it in /proc/cpu/alignment instead.
|
||||
|
|
|
@ -1,4 +1,7 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
KASAN_SANITIZE_actions-common.o := n
|
||||
KASAN_SANITIZE_actions-arm.o := n
|
||||
KASAN_SANITIZE_actions-thumb.o := n
|
||||
obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o
|
||||
obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o
|
||||
test-kprobes-objs := test-core.o
|
||||
|
|
|
@ -120,7 +120,6 @@ config ARM64
|
|||
select GENERIC_CPU_AUTOPROBE
|
||||
select GENERIC_CPU_VULNERABILITIES
|
||||
select GENERIC_EARLY_IOREMAP
|
||||
select GENERIC_FIND_FIRST_BIT
|
||||
select GENERIC_IDLE_POLL_SETUP
|
||||
select GENERIC_IRQ_IPI
|
||||
select GENERIC_IRQ_PROBE
|
||||
|
@ -671,15 +670,42 @@ config ARM64_ERRATUM_1508412
|
|||
config ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE
|
||||
bool
|
||||
|
||||
config ARM64_ERRATUM_2051678
|
||||
bool "Cortex-A510: 2051678: disable Hardware Update of the page table dirty bit"
|
||||
default y
|
||||
help
|
||||
This options adds the workaround for ARM Cortex-A510 erratum ARM64_ERRATUM_2051678.
|
||||
Affected Coretex-A510 might not respect the ordering rules for
|
||||
hardware update of the page table's dirty bit. The workaround
|
||||
is to not enable the feature on affected CPUs.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_2077057
|
||||
bool "Cortex-A510: 2077057: workaround software-step corrupting SPSR_EL2"
|
||||
help
|
||||
This option adds the workaround for ARM Cortex-A510 erratum 2077057.
|
||||
Affected Cortex-A510 may corrupt SPSR_EL2 when the a step exception is
|
||||
expected, but a Pointer Authentication trap is taken instead. The
|
||||
erratum causes SPSR_EL1 to be copied to SPSR_EL2, which could allow
|
||||
EL1 to cause a return to EL2 with a guest controlled ELR_EL2.
|
||||
|
||||
This can only happen when EL2 is stepping EL1.
|
||||
|
||||
When these conditions occur, the SPSR_EL2 value is unchanged from the
|
||||
previous guest entry, and can be restored from the in-memory copy.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_2119858
|
||||
bool "Cortex-A710: 2119858: workaround TRBE overwriting trace data in FILL mode"
|
||||
bool "Cortex-A710/X2: 2119858: workaround TRBE overwriting trace data in FILL mode"
|
||||
default y
|
||||
depends on CORESIGHT_TRBE
|
||||
select ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE
|
||||
help
|
||||
This option adds the workaround for ARM Cortex-A710 erratum 2119858.
|
||||
This option adds the workaround for ARM Cortex-A710/X2 erratum 2119858.
|
||||
|
||||
Affected Cortex-A710 cores could overwrite up to 3 cache lines of trace
|
||||
Affected Cortex-A710/X2 cores could overwrite up to 3 cache lines of trace
|
||||
data at the base of the buffer (pointed to by TRBASER_EL1) in FILL mode in
|
||||
the event of a WRAP event.
|
||||
|
||||
|
@ -762,14 +788,14 @@ config ARM64_ERRATUM_2253138
|
|||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_2224489
|
||||
bool "Cortex-A710: 2224489: workaround TRBE writing to address out-of-range"
|
||||
bool "Cortex-A710/X2: 2224489: workaround TRBE writing to address out-of-range"
|
||||
depends on CORESIGHT_TRBE
|
||||
default y
|
||||
select ARM64_WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
|
||||
help
|
||||
This option adds the workaround for ARM Cortex-A710 erratum 2224489.
|
||||
This option adds the workaround for ARM Cortex-A710/X2 erratum 2224489.
|
||||
|
||||
Affected Cortex-A710 cores might write to an out-of-range address, not reserved
|
||||
Affected Cortex-A710/X2 cores might write to an out-of-range address, not reserved
|
||||
for TRBE. Under some conditions, the TRBE might generate a write to the next
|
||||
virtually addressed page following the last page of the TRBE address space
|
||||
(i.e., the TRBLIMITR_EL1.LIMIT), instead of wrapping around to the base.
|
||||
|
@ -779,6 +805,65 @@ config ARM64_ERRATUM_2224489
|
|||
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_2064142
|
||||
bool "Cortex-A510: 2064142: workaround TRBE register writes while disabled"
|
||||
depends on COMPILE_TEST # Until the CoreSight TRBE driver changes are in
|
||||
default y
|
||||
help
|
||||
This option adds the workaround for ARM Cortex-A510 erratum 2064142.
|
||||
|
||||
Affected Cortex-A510 core might fail to write into system registers after the
|
||||
TRBE has been disabled. Under some conditions after the TRBE has been disabled
|
||||
writes into TRBE registers TRBLIMITR_EL1, TRBPTR_EL1, TRBBASER_EL1, TRBSR_EL1,
|
||||
and TRBTRG_EL1 will be ignored and will not be effected.
|
||||
|
||||
Work around this in the driver by executing TSB CSYNC and DSB after collection
|
||||
is stopped and before performing a system register write to one of the affected
|
||||
registers.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_2038923
|
||||
bool "Cortex-A510: 2038923: workaround TRBE corruption with enable"
|
||||
depends on COMPILE_TEST # Until the CoreSight TRBE driver changes are in
|
||||
default y
|
||||
help
|
||||
This option adds the workaround for ARM Cortex-A510 erratum 2038923.
|
||||
|
||||
Affected Cortex-A510 core might cause an inconsistent view on whether trace is
|
||||
prohibited within the CPU. As a result, the trace buffer or trace buffer state
|
||||
might be corrupted. This happens after TRBE buffer has been enabled by setting
|
||||
TRBLIMITR_EL1.E, followed by just a single context synchronization event before
|
||||
execution changes from a context, in which trace is prohibited to one where it
|
||||
isn't, or vice versa. In these mentioned conditions, the view of whether trace
|
||||
is prohibited is inconsistent between parts of the CPU, and the trace buffer or
|
||||
the trace buffer state might be corrupted.
|
||||
|
||||
Work around this in the driver by preventing an inconsistent view of whether the
|
||||
trace is prohibited or not based on TRBLIMITR_EL1.E by immediately following a
|
||||
change to TRBLIMITR_EL1.E with at least one ISB instruction before an ERET, or
|
||||
two ISB instructions if no ERET is to take place.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_1902691
|
||||
bool "Cortex-A510: 1902691: workaround TRBE trace corruption"
|
||||
depends on COMPILE_TEST # Until the CoreSight TRBE driver changes are in
|
||||
default y
|
||||
help
|
||||
This option adds the workaround for ARM Cortex-A510 erratum 1902691.
|
||||
|
||||
Affected Cortex-A510 core might cause trace data corruption, when being written
|
||||
into the memory. Effectively TRBE is broken and hence cannot be used to capture
|
||||
trace data.
|
||||
|
||||
Work around this problem in the driver by just preventing TRBE initialization on
|
||||
affected cpus. The firmware must have disabled the access to TRBE for the kernel
|
||||
on such implementations. This will cover the kernel for any firmware that doesn't
|
||||
do this already.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config CAVIUM_ERRATUM_22375
|
||||
bool "Cavium erratum 22375, 24313"
|
||||
default y
|
||||
|
|
|
@ -309,9 +309,6 @@ config ARCH_VISCONTI
|
|||
help
|
||||
This enables support for Toshiba Visconti SoCs Family.
|
||||
|
||||
config ARCH_VULCAN
|
||||
def_bool n
|
||||
|
||||
config ARCH_XGENE
|
||||
bool "AppliedMicro X-Gene SOC Family"
|
||||
help
|
||||
|
|
|
@ -107,6 +107,12 @@
|
|||
no-map;
|
||||
};
|
||||
|
||||
/* 32 MiB reserved for ARM Trusted Firmware (BL32) */
|
||||
secmon_reserved_bl32: secmon@5300000 {
|
||||
reg = <0x0 0x05300000 0x0 0x2000000>;
|
||||
no-map;
|
||||
};
|
||||
|
||||
linux,cma {
|
||||
compatible = "shared-dma-pool";
|
||||
reusable;
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue