Linux 6.2-rc6
-----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmPW7E8eHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGf7MIAI0JnHN9WvtEukSZ E6j6+cEGWxsvD6q0g3GPolaKOCw7hlv0pWcFJFcUAt0jebspMdxV2oUGJ8RYW7Lg nCcHvEVswGKLAQtQSWw52qotW6fUfMPsNYYB5l31sm1sKH4Cgss0W7l2HxO/1LvG TSeNHX53vNAZ8pVnFYEWCSXC9bzrmU/VALF2EV00cdICmfvjlgkELGXoLKJJWzUp s63fBHYGGURSgwIWOKStoO6HNo0j/F/wcSMx8leY8qDUtVKHj4v24EvSgxUSDBER ch3LiSQ6qf4sw/z7pqruKFthKOrlNmcc0phjiES0xwwGiNhLv0z3rAhc4OM2cgYh SDc/Y/c= =zpaD -----END PGP SIGNATURE----- Merge tag 'v6.2-rc6' into sched/core, to pick up fixes Pick up fixes before merging another batch of cpuidle updates. Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
commit
57a30218fa
|
|
@ -39,6 +39,7 @@
|
|||
*.o.*
|
||||
*.patch
|
||||
*.rmeta
|
||||
*.rpm
|
||||
*.rsi
|
||||
*.s
|
||||
*.so
|
||||
|
|
|
|||
2
.mailmap
2
.mailmap
|
|
@ -371,6 +371,7 @@ Rémi Denis-Courmont <rdenis@simphalempin.com>
|
|||
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>
|
||||
Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>
|
||||
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
|
||||
Robert Foss <rfoss@kernel.org> <robert.foss@linaro.org>
|
||||
Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>
|
||||
Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>
|
||||
Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru>
|
||||
|
|
@ -422,6 +423,7 @@ Tony Luck <tony.luck@intel.com>
|
|||
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
|
||||
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Tudor Ambarus <tudor.ambarus@linaro.org> <tudor.ambarus@microchip.com>
|
||||
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
|
||||
Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
|
|
|
|||
7
CREDITS
7
CREDITS
|
|
@ -2489,6 +2489,13 @@ D: XF86_Mach8
|
|||
D: XF86_8514
|
||||
D: cfdisk (curses based disk partitioning program)
|
||||
|
||||
N: Mat Martineau
|
||||
E: mat@martineau.name
|
||||
D: MPTCP subsystem co-maintainer 2020-2023
|
||||
D: Keyctl restricted keyring and Diffie-Hellman UAPI
|
||||
D: Bluetooth L2CAP ERTM mode and AMP
|
||||
S: USA
|
||||
|
||||
N: John S. Marvin
|
||||
E: jsm@fc.hp.com
|
||||
D: PA-RISC port
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
What: /sys/kernel/debug/pktcdvd/pktcdvd[0-7]
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
Description:
|
||||
|
||||
The pktcdvd module (packet writing driver) creates
|
||||
these files in debugfs:
|
||||
|
||||
/sys/kernel/debug/pktcdvd/pktcdvd[0-7]/
|
||||
|
||||
==== ====== ====================================
|
||||
info 0444 Lots of driver statistics and infos.
|
||||
==== ====== ====================================
|
||||
|
||||
Example::
|
||||
|
||||
cat /sys/kernel/debug/pktcdvd/pktcdvd0/info
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
sysfs interface
|
||||
---------------
|
||||
The pktcdvd module (packet writing driver) creates the following files in the
|
||||
sysfs: (<devid> is in the format major:minor)
|
||||
|
||||
What: /sys/class/pktcdvd/add
|
||||
What: /sys/class/pktcdvd/remove
|
||||
What: /sys/class/pktcdvd/device_map
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
Description:
|
||||
|
||||
========== ==============================================
|
||||
add (WO) Write a block device id (major:minor) to
|
||||
create a new pktcdvd device and map it to the
|
||||
block device.
|
||||
|
||||
remove (WO) Write the pktcdvd device id (major:minor)
|
||||
to remove the pktcdvd device.
|
||||
|
||||
device_map (RO) Shows the device mapping in format:
|
||||
pktcdvd[0-7] <pktdevid> <blkdevid>
|
||||
========== ==============================================
|
||||
|
||||
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/dev
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/uevent
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
Description:
|
||||
dev: (RO) Device id
|
||||
|
||||
uevent: (WO) To send a uevent
|
||||
|
||||
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_started
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_finished
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_written
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read_gather
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/reset
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
Description:
|
||||
packets_started: (RO) Number of started packets.
|
||||
|
||||
packets_finished: (RO) Number of finished packets.
|
||||
|
||||
kb_written: (RO) kBytes written.
|
||||
|
||||
kb_read: (RO) kBytes read.
|
||||
|
||||
kb_read_gather: (RO) kBytes read to fill write packets.
|
||||
|
||||
reset: (WO) Write any value to it to reset
|
||||
pktcdvd device statistic values, like
|
||||
bytes read/written.
|
||||
|
||||
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/size
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_off
|
||||
What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_on
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
Description:
|
||||
============== ================================================
|
||||
size (RO) Contains the size of the bio write queue.
|
||||
|
||||
congestion_off (RW) If bio write queue size is below this mark,
|
||||
accept new bio requests from the block layer.
|
||||
|
||||
congestion_on (RW) If bio write queue size is higher as this
|
||||
mark, do no longer accept bio write requests
|
||||
from the block layer and wait till the pktcdvd
|
||||
device has processed enough bio's so that bio
|
||||
write queue size is below congestion off mark.
|
||||
A value of <= 0 disables congestion control.
|
||||
============== ================================================
|
||||
|
||||
|
||||
Example:
|
||||
--------
|
||||
To use the pktcdvd sysfs interface directly, you can do::
|
||||
|
||||
# create a new pktcdvd device mapped to /dev/hdc
|
||||
echo "22:0" >/sys/class/pktcdvd/add
|
||||
cat /sys/class/pktcdvd/device_map
|
||||
# assuming device pktcdvd0 was created, look at stat's
|
||||
cat /sys/class/pktcdvd/pktcdvd0/stat/kb_written
|
||||
# print the device id of the mapped block device
|
||||
fgrep pktcdvd0 /sys/class/pktcdvd/device_map
|
||||
# remove device, using pktcdvd0 device id 253:0
|
||||
echo "253:0" >/sys/class/pktcdvd/remove
|
||||
|
|
@ -70,9 +70,7 @@ e.g. ``zswap.zpool=zbud``. It can also be changed at runtime using the sysfs
|
|||
The zbud type zpool allocates exactly 1 page to store 2 compressed pages, which
|
||||
means the compression ratio will always be 2:1 or worse (because of half-full
|
||||
zbud pages). The zsmalloc type zpool has a more complex compressed page
|
||||
storage method, and it can achieve greater storage densities. However,
|
||||
zsmalloc does not implement compressed page eviction, so once zswap fills it
|
||||
cannot evict the oldest page, it can only reject new pages.
|
||||
storage method, and it can achieve greater storage densities.
|
||||
|
||||
When a swap page is passed from frontswap to zswap, zswap maintains a mapping
|
||||
of the swap entry, a combination of the swap type and swap offset, to the zpool
|
||||
|
|
|
|||
|
|
@ -120,6 +120,8 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
|
|
|
|||
|
|
@ -31,6 +31,12 @@ def have_command(cmd):
|
|||
# Get Sphinx version
|
||||
major, minor, patch = sphinx.version_info[:3]
|
||||
|
||||
#
|
||||
# Warn about older versions that we don't want to support for much
|
||||
# longer.
|
||||
#
|
||||
if (major < 2) or (major == 2 and minor < 4):
|
||||
print('WARNING: support for Sphinx < 2.4 will be removed soon.')
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
|
|
@ -339,7 +345,11 @@ html_use_smartypants = False
|
|||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
# Note that the RTD theme ignores this
|
||||
html_sidebars = { '**': ["about.html", 'searchbox.html', 'localtoc.html', 'sourcelink.html']}
|
||||
html_sidebars = { '**': ['searchbox.html', 'localtoc.html', 'sourcelink.html']}
|
||||
|
||||
# about.html is available for alabaster theme. Add it at the front.
|
||||
if html_theme == 'alabaster':
|
||||
html_sidebars['**'].insert(0, 'about.html')
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'TheLinuxKerneldoc'
|
||||
|
|
|
|||
|
|
@ -54,6 +54,17 @@ properties:
|
|||
- const: xo
|
||||
- const: alternate
|
||||
|
||||
interrupts:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
interrupt-names:
|
||||
minItems: 1
|
||||
items:
|
||||
- const: dcvsh-irq-0
|
||||
- const: dcvsh-irq-1
|
||||
- const: dcvsh-irq-2
|
||||
|
||||
'#freq-domain-cells':
|
||||
const: 1
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Atmel Advanced Encryption Standard (AES) HW cryptographic accelerator
|
||||
|
||||
maintainers:
|
||||
- Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
- Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Atmel Secure Hash Algorithm (SHA) HW cryptographic accelerator
|
||||
|
||||
maintainers:
|
||||
- Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
- Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Atmel Triple Data Encryption Standard (TDES) HW cryptographic accelerator
|
||||
|
||||
maintainers:
|
||||
- Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
- Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ properties:
|
|||
- description: Display byte clock
|
||||
- description: Display byte interface clock
|
||||
- description: Display pixel clock
|
||||
- description: Display escape clock
|
||||
- description: Display core clock
|
||||
- description: Display AHB clock
|
||||
- description: Display AXI clock
|
||||
|
||||
|
|
@ -137,8 +137,6 @@ required:
|
|||
- phys
|
||||
- assigned-clocks
|
||||
- assigned-clock-parents
|
||||
- power-domains
|
||||
- operating-points-v2
|
||||
- ports
|
||||
|
||||
additionalProperties: false
|
||||
|
|
|
|||
|
|
@ -69,7 +69,6 @@ required:
|
|||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- vdds-supply
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,6 @@ required:
|
|||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- vcca-supply
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -34,6 +34,10 @@ properties:
|
|||
vddio-supply:
|
||||
description: Phandle to vdd-io regulator device node.
|
||||
|
||||
qcom,dsi-phy-regulator-ldo-mode:
|
||||
type: boolean
|
||||
description: Indicates if the LDO mode PHY regulator is wanted.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ examples:
|
|||
#include <dt-bindings/interconnect/qcom,qcm2290.h>
|
||||
#include <dt-bindings/power/qcom-rpmpd.h>
|
||||
|
||||
mdss@5e00000 {
|
||||
display-subsystem@5e00000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "qcom,qcm2290-mdss";
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ examples:
|
|||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/power/qcom-rpmpd.h>
|
||||
|
||||
mdss@5e00000 {
|
||||
display-subsystem@5e00000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "qcom,sm6115-mdss";
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- renesas,i2c-r9a09g011 # RZ/V2M
|
||||
- renesas,r9a09g011-i2c # RZ/V2M
|
||||
- const: renesas,rzv2m-i2c
|
||||
|
||||
reg:
|
||||
|
|
@ -66,7 +66,7 @@ examples:
|
|||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
i2c0: i2c@a4030000 {
|
||||
compatible = "renesas,i2c-r9a09g011", "renesas,rzv2m-i2c";
|
||||
compatible = "renesas,r9a09g011-i2c", "renesas,rzv2m-i2c";
|
||||
reg = <0xa4030000 0x80>;
|
||||
interrupts = <GIC_SPI 232 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 236 IRQ_TYPE_EDGE_RISING>;
|
||||
|
|
|
|||
|
|
@ -84,7 +84,6 @@ allOf:
|
|||
- qcom,msm8939-pcnoc
|
||||
- qcom,msm8939-snoc
|
||||
- qcom,msm8996-a1noc
|
||||
- qcom,msm8996-a2noc
|
||||
- qcom,msm8996-bimc
|
||||
- qcom,msm8996-cnoc
|
||||
- qcom,msm8996-pnoc
|
||||
|
|
@ -186,6 +185,29 @@ allOf:
|
|||
required:
|
||||
- power-domains
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,msm8996-a2noc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
- const: aggre2_ufs_axi
|
||||
- const: ufs_axi
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock
|
||||
- description: Bus A Clock
|
||||
- description: Aggregate2 NoC UFS AXI Clock
|
||||
- description: UFS AXI Clock
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -40,6 +40,9 @@ properties:
|
|||
clock-names:
|
||||
const: stmmaceth
|
||||
|
||||
phy-supply:
|
||||
description: PHY regulator
|
||||
|
||||
syscon:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
|
|
|
|||
|
|
@ -16,9 +16,6 @@ description: |
|
|||
8k has a second unit which provides an interface with the xMDIO bus. This
|
||||
driver handles these interfaces.
|
||||
|
||||
allOf:
|
||||
- $ref: "mdio.yaml#"
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
|
|
@ -39,13 +36,38 @@ required:
|
|||
- compatible
|
||||
- reg
|
||||
|
||||
allOf:
|
||||
- $ref: mdio.yaml#
|
||||
|
||||
- if:
|
||||
required:
|
||||
- interrupts
|
||||
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- items:
|
||||
- $ref: /schemas/types.yaml#/definitions/cell
|
||||
- const: 0x84
|
||||
|
||||
else:
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- items:
|
||||
- $ref: /schemas/types.yaml#/definitions/cell
|
||||
- enum:
|
||||
- 0x4
|
||||
- 0x10
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
mdio@d0072004 {
|
||||
compatible = "marvell,orion-mdio";
|
||||
reg = <0xd0072004 0x4>;
|
||||
reg = <0xd0072004 0x84>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
interrupts = <30>;
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
# Copyright 2019 BayLibre, SAS
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb2-phy.yaml#"
|
||||
$id: "http://devicetree.org/schemas/phy/amlogic,g12a-usb2-phy.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Amlogic G12A USB2 PHY
|
||||
|
|
@ -13,8 +13,8 @@ maintainers:
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- amlogic,meson-g12a-usb2-phy
|
||||
- amlogic,meson-a1-usb2-phy
|
||||
- amlogic,g12a-usb2-phy
|
||||
- amlogic,a1-usb2-phy
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -68,7 +68,7 @@ additionalProperties: false
|
|||
examples:
|
||||
- |
|
||||
phy@36000 {
|
||||
compatible = "amlogic,meson-g12a-usb2-phy";
|
||||
compatible = "amlogic,g12a-usb2-phy";
|
||||
reg = <0x36000 0x2000>;
|
||||
clocks = <&xtal>;
|
||||
clock-names = "xtal";
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
# Copyright 2019 BayLibre, SAS
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml#"
|
||||
$id: "http://devicetree.org/schemas/phy/amlogic,g12a-usb3-pcie-phy.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Amlogic G12A USB3 + PCIE Combo PHY
|
||||
|
|
@ -13,7 +13,7 @@ maintainers:
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- amlogic,meson-g12a-usb3-pcie-phy
|
||||
- amlogic,g12a-usb3-pcie-phy
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -49,7 +49,7 @@ additionalProperties: false
|
|||
examples:
|
||||
- |
|
||||
phy@46000 {
|
||||
compatible = "amlogic,meson-g12a-usb3-pcie-phy";
|
||||
compatible = "amlogic,g12a-usb3-pcie-phy";
|
||||
reg = <0x46000 0x2000>;
|
||||
clocks = <&ref_clk>;
|
||||
clock-names = "ref_clk";
|
||||
|
|
@ -16,7 +16,6 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- qcom,usb-hs-28nm-femtophy
|
||||
- qcom,usb-hs-28nm-mdm9607
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -19,8 +19,8 @@ description: |
|
|||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 25 LDOs
|
||||
"^LDO([1-9]|[1][0-9]|2[0-5])$":
|
||||
# 25 LDOs, without LDO10-12
|
||||
"^LDO([1-9]|1[3-9]|2[0-5])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
|
@ -30,6 +30,23 @@ patternProperties:
|
|||
required:
|
||||
- regulator-name
|
||||
|
||||
"^LDO(1[0-2])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
properties:
|
||||
samsung,ext-control-gpios:
|
||||
maxItems: 1
|
||||
description:
|
||||
LDO10, LDO11 and LDO12 can be configured to external control over
|
||||
GPIO.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 5 bucks
|
||||
"^BUCK[1-5]$":
|
||||
type: object
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ properties:
|
|||
insensitive, letters in the riscv,isa string must be all
|
||||
lowercase to simplify parsing.
|
||||
$ref: "/schemas/types.yaml#/definitions/string"
|
||||
pattern: ^rv(?:64|32)imaf?d?q?c?b?v?k?h?(?:_[hsxz](?:[a-z])+)*$
|
||||
pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
|
||||
|
||||
# RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
|
||||
timebase-frequency: false
|
||||
|
|
|
|||
|
|
@ -39,8 +39,8 @@ properties:
|
|||
qcom,protection-domain:
|
||||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
description: |
|
||||
Protection domain service name and path for APR service
|
||||
possible values are::
|
||||
Protection domain service name and path for APR service (if supported).
|
||||
Possible values are::
|
||||
"avs/audio", "msm/adsp/audio_pd".
|
||||
"kernel/elf_loader", "msm/modem/wlan_pd".
|
||||
"tms/servreg", "msm/adsp/audio_pd".
|
||||
|
|
@ -49,6 +49,5 @@ properties:
|
|||
|
||||
required:
|
||||
- reg
|
||||
- qcom,protection-domain
|
||||
|
||||
additionalProperties: true
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- mediatek,mt8186-mt6366-rt1019-rt5682s-sound
|
||||
- mediatek,mt8186-mt6366-rt5682s-max98360-sound
|
||||
|
||||
mediatek,platform:
|
||||
$ref: "/schemas/types.yaml#/definitions/phandle"
|
||||
|
|
|
|||
|
|
@ -30,7 +30,9 @@ properties:
|
|||
const: 0
|
||||
|
||||
clocks:
|
||||
maxItems: 5
|
||||
oneOf:
|
||||
- maxItems: 3
|
||||
- maxItems: 5
|
||||
|
||||
clock-names:
|
||||
oneOf:
|
||||
|
|
|
|||
|
|
@ -9,9 +9,6 @@ title: LPASS(Low Power Audio Subsystem) VA Macro audio codec
|
|||
maintainers:
|
||||
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: dai-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
|
|
@ -30,15 +27,12 @@ properties:
|
|||
const: 0
|
||||
|
||||
clocks:
|
||||
maxItems: 5
|
||||
minItems: 5
|
||||
maxItems: 6
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: mclk
|
||||
- const: npl
|
||||
- const: macro
|
||||
- const: dcodec
|
||||
- const: fsgen
|
||||
minItems: 5
|
||||
maxItems: 6
|
||||
|
||||
clock-output-names:
|
||||
maxItems: 1
|
||||
|
|
@ -55,10 +49,51 @@ required:
|
|||
- reg
|
||||
- "#sound-dai-cells"
|
||||
|
||||
allOf:
|
||||
- $ref: dai-common.yaml#
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sc7280-lpass-wsa-macro
|
||||
- qcom,sm8450-lpass-wsa-macro
|
||||
- qcom,sc8280xp-lpass-wsa-macro
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 5
|
||||
clock-names:
|
||||
items:
|
||||
- const: mclk
|
||||
- const: npl
|
||||
- const: macro
|
||||
- const: dcodec
|
||||
- const: fsgen
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sm8250-lpass-wsa-macro
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 6
|
||||
clock-names:
|
||||
items:
|
||||
- const: mclk
|
||||
- const: npl
|
||||
- const: macro
|
||||
- const: dcodec
|
||||
- const: va
|
||||
- const: fsgen
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,sm8250-lpass-aoncc.h>
|
||||
#include <dt-bindings/sound/qcom,q6afe.h>
|
||||
codec@3240000 {
|
||||
compatible = "qcom,sm8250-lpass-wsa-macro";
|
||||
|
|
@ -69,7 +104,8 @@ examples:
|
|||
<&audiocc 0>,
|
||||
<&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
|
||||
<&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
|
||||
<&aoncc LPASS_CDC_VA_MCLK>,
|
||||
<&vamacro>;
|
||||
clock-names = "mclk", "npl", "macro", "dcodec", "fsgen";
|
||||
clock-names = "mclk", "npl", "macro", "dcodec", "va", "fsgen";
|
||||
clock-output-names = "mclk";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ properties:
|
|||
or applicable for the respective data port.
|
||||
More info in MIPI Alliance SoundWire 1.0 Specifications.
|
||||
minItems: 3
|
||||
maxItems: 5
|
||||
maxItems: 8
|
||||
|
||||
qcom,ports-sinterval-low:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
|
|
@ -124,7 +124,7 @@ properties:
|
|||
or applicable for the respective data port.
|
||||
More info in MIPI Alliance SoundWire 1.0 Specifications.
|
||||
minItems: 3
|
||||
maxItems: 5
|
||||
maxItems: 8
|
||||
|
||||
qcom,ports-block-pack-mode:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
|
|
@ -154,7 +154,7 @@ properties:
|
|||
or applicable for the respective data port.
|
||||
More info in MIPI Alliance SoundWire 1.0 Specifications.
|
||||
minItems: 3
|
||||
maxItems: 5
|
||||
maxItems: 8
|
||||
items:
|
||||
oneOf:
|
||||
- minimum: 0
|
||||
|
|
@ -171,7 +171,7 @@ properties:
|
|||
or applicable for the respective data port.
|
||||
More info in MIPI Alliance SoundWire 1.0 Specifications.
|
||||
minItems: 3
|
||||
maxItems: 5
|
||||
maxItems: 8
|
||||
items:
|
||||
oneOf:
|
||||
- minimum: 0
|
||||
|
|
@ -187,7 +187,7 @@ properties:
|
|||
or applicable for the respective data port.
|
||||
More info in MIPI Alliance SoundWire 1.0 Specifications.
|
||||
minItems: 3
|
||||
maxItems: 5
|
||||
maxItems: 8
|
||||
items:
|
||||
oneOf:
|
||||
- minimum: 0
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Atmel SPI device
|
||||
|
||||
maintainers:
|
||||
- Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
- Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: spi-controller.yaml#
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Atmel Quad Serial Peripheral Interface (QSPI)
|
||||
|
||||
maintainers:
|
||||
- Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
- Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: spi-controller.yaml#
|
||||
|
|
|
|||
|
|
@ -44,9 +44,9 @@ properties:
|
|||
description:
|
||||
Maximum SPI clocking speed of the device in Hz.
|
||||
|
||||
spi-cs-setup-ns:
|
||||
spi-cs-setup-delay-ns:
|
||||
description:
|
||||
Delay in nanosecods to be introduced by the controller after CS is
|
||||
Delay in nanoseconds to be introduced by the controller after CS is
|
||||
asserted.
|
||||
|
||||
spi-rx-bus-width:
|
||||
|
|
|
|||
|
|
@ -120,6 +120,8 @@ dax={always,never} Use direct access (no page cache). See
|
|||
dax A legacy option which is an alias for ``dax=always``.
|
||||
device=%s Specify a path to an extra device to be used together.
|
||||
fsid=%s Specify a filesystem image ID for Fscache back-end.
|
||||
domain_id=%s Specify a domain ID in fscache mode so that different images
|
||||
with the same blobs under a given domain ID can share storage.
|
||||
=================== =========================================================
|
||||
|
||||
Sysfs Entries
|
||||
|
|
|
|||
|
|
@ -1042,7 +1042,7 @@ $(clean-files).
|
|||
|
||||
When executing "make clean", the file "crc32table.h" will be deleted.
|
||||
Kbuild will assume files to be in the same relative directory as the
|
||||
Makefile, except if prefixed with $(objtree).
|
||||
Makefile.
|
||||
|
||||
To exclude certain files or directories from make clean, use the
|
||||
$(no-clean-files) variable.
|
||||
|
|
|
|||
|
|
@ -104,3 +104,4 @@ to do something different in the near future.
|
|||
../riscv/patch-acceptance
|
||||
../driver-api/media/maintainer-entry-profile
|
||||
../driver-api/vfio-pci-device-specific-driver-acceptance
|
||||
../nvme/feature-and-quirk-policy
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ In order to use the Ethernet bridging functionality, you'll need the
|
|||
userspace tools.
|
||||
|
||||
Documentation for Linux bridging is on:
|
||||
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
|
||||
https://wiki.linuxfoundation.org/networking/bridge
|
||||
|
||||
The bridge-utilities are maintained at:
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
|
||||
|
|
|
|||
|
|
@ -173,7 +173,9 @@ nf_conntrack_sctp_timeout_cookie_echoed - INTEGER (seconds)
|
|||
default 3
|
||||
|
||||
nf_conntrack_sctp_timeout_established - INTEGER (seconds)
|
||||
default 432000 (5 days)
|
||||
default 210
|
||||
|
||||
Default is set to (hb_interval * path_max_retrans + rto_max)
|
||||
|
||||
nf_conntrack_sctp_timeout_shutdown_sent - INTEGER (seconds)
|
||||
default 0.3
|
||||
|
|
@ -190,12 +192,6 @@ nf_conntrack_sctp_timeout_heartbeat_sent - INTEGER (seconds)
|
|||
This timeout is used to setup conntrack entry on secondary paths.
|
||||
Default is set to hb_interval.
|
||||
|
||||
nf_conntrack_sctp_timeout_heartbeat_acked - INTEGER (seconds)
|
||||
default 210
|
||||
|
||||
This timeout is used to setup conntrack entry on secondary paths.
|
||||
Default is set to (hb_interval * path_max_retrans + rto_max)
|
||||
|
||||
nf_conntrack_udp_timeout - INTEGER (seconds)
|
||||
default 30
|
||||
|
||||
|
|
|
|||
|
|
@ -880,8 +880,8 @@ The kernel interface functions are as follows:
|
|||
|
||||
notify_end_rx can be NULL or it can be used to specify a function to be
|
||||
called when the call changes state to end the Tx phase. This function is
|
||||
called with the call-state spinlock held to prevent any reply or final ACK
|
||||
from being delivered first.
|
||||
called with a spinlock held to prevent the last DATA packet from being
|
||||
transmitted until the function returns.
|
||||
|
||||
(#) Receive data from a call::
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,77 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=======================================
|
||||
Linux NVMe feature and and quirk policy
|
||||
=======================================
|
||||
|
||||
This file explains the policy used to decide what is supported by the
|
||||
Linux NVMe driver and what is not.
|
||||
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
NVM Express is an open collection of standards and information.
|
||||
|
||||
The Linux NVMe host driver in drivers/nvme/host/ supports devices
|
||||
implementing the NVM Express (NVMe) family of specifications, which
|
||||
currently consists of a number of documents:
|
||||
|
||||
- the NVMe Base specification
|
||||
- various Command Set specifications (e.g. NVM Command Set)
|
||||
- various Transport specifications (e.g. PCIe, Fibre Channel, RDMA, TCP)
|
||||
- the NVMe Management Interface specification
|
||||
|
||||
See https://nvmexpress.org/developers/ for the NVMe specifications.
|
||||
|
||||
|
||||
Supported features
|
||||
==================
|
||||
|
||||
NVMe is a large suite of specifications, and contains features that are only
|
||||
useful or suitable for specific use-cases. It is important to note that Linux
|
||||
does not aim to implement every feature in the specification. Every additional
|
||||
feature implemented introduces more code, more maintenance and potentially more
|
||||
bugs. Hence there is an inherent tradeoff between functionality and
|
||||
maintainability of the NVMe host driver.
|
||||
|
||||
Any feature implemented in the Linux NVMe host driver must support the
|
||||
following requirements:
|
||||
|
||||
1. The feature is specified in a release version of an official NVMe
|
||||
specification, or in a ratified Technical Proposal (TP) that is
|
||||
available on NVMe website. Or if it is not directly related to the
|
||||
on-wire protocol, does not contradict any of the NVMe specifications.
|
||||
2. Does not conflict with the Linux architecture, nor the design of the
|
||||
NVMe host driver.
|
||||
3. Has a clear, indisputable value-proposition and a wide consensus across
|
||||
the community.
|
||||
|
||||
Vendor specific extensions are generally not supported in the NVMe host
|
||||
driver.
|
||||
|
||||
It is strongly recommended to work with the Linux NVMe and block layer
|
||||
maintainers and get feedback on specification changes that are intended
|
||||
to be used by the Linux NVMe host driver in order to avoid conflict at a
|
||||
later stage.
|
||||
|
||||
|
||||
Quirks
|
||||
======
|
||||
|
||||
Sometimes implementations of open standards fail to correctly implement parts
|
||||
of the standards. Linux uses identifier-based quirks to work around such
|
||||
implementation bugs. The intent of quirks is to deal with widely available
|
||||
hardware, usually consumer, which Linux users can't use without these quirks.
|
||||
Typically these implementations are not or only superficially tested with Linux
|
||||
by the hardware manufacturer.
|
||||
|
||||
The Linux NVMe maintainers decide ad hoc whether to quirk implementations
|
||||
based on the impact of the problem to Linux users and how it impacts
|
||||
maintainability of the driver. In general quirks are a last resort, if no
|
||||
firmware updates or other workarounds are available from the vendor.
|
||||
|
||||
Quirks will not be added to the Linux kernel for hardware that isn't available
|
||||
on the mass market. Hardware that fails qualification for enterprise Linux
|
||||
distributions, ChromeOS, Android or other consumers of the Linux kernel
|
||||
should be fixed before it is shipped instead of relying on Linux quirks.
|
||||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
.. _netdev-FAQ:
|
||||
|
||||
==========
|
||||
netdev FAQ
|
||||
==========
|
||||
=============================
|
||||
Networking subsystem (netdev)
|
||||
=============================
|
||||
|
||||
tl;dr
|
||||
-----
|
||||
|
|
@ -15,14 +15,15 @@ tl;dr
|
|||
- don't repost your patches within one 24h period
|
||||
- reverse xmas tree
|
||||
|
||||
What is netdev?
|
||||
---------------
|
||||
It is a mailing list for all network-related Linux stuff. This
|
||||
netdev
|
||||
------
|
||||
|
||||
netdev is a mailing list for all network-related Linux stuff. This
|
||||
includes anything found under net/ (i.e. core code like IPv6) and
|
||||
drivers/net (i.e. hardware specific drivers) in the Linux source tree.
|
||||
|
||||
Note that some subsystems (e.g. wireless drivers) which have a high
|
||||
volume of traffic have their own specific mailing lists.
|
||||
volume of traffic have their own specific mailing lists and trees.
|
||||
|
||||
The netdev list is managed (like many other Linux mailing lists) through
|
||||
VGER (http://vger.kernel.org/) with archives available at
|
||||
|
|
@ -32,32 +33,10 @@ Aside from subsystems like those mentioned above, all network-related
|
|||
Linux development (i.e. RFC, review, comments, etc.) takes place on
|
||||
netdev.
|
||||
|
||||
How do the changes posted to netdev make their way into Linux?
|
||||
--------------------------------------------------------------
|
||||
There are always two trees (git repositories) in play. Both are
|
||||
driven by David Miller, the main network maintainer. There is the
|
||||
``net`` tree, and the ``net-next`` tree. As you can probably guess from
|
||||
the names, the ``net`` tree is for fixes to existing code already in the
|
||||
mainline tree from Linus, and ``net-next`` is where the new code goes
|
||||
for the future release. You can find the trees here:
|
||||
Development cycle
|
||||
-----------------
|
||||
|
||||
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
|
||||
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
|
||||
|
||||
How do I indicate which tree (net vs. net-next) my patch should be in?
|
||||
----------------------------------------------------------------------
|
||||
To help maintainers and CI bots you should explicitly mark which tree
|
||||
your patch is targeting. Assuming that you use git, use the prefix
|
||||
flag::
|
||||
|
||||
git format-patch --subject-prefix='PATCH net-next' start..finish
|
||||
|
||||
Use ``net`` instead of ``net-next`` (always lower case) in the above for
|
||||
bug-fix ``net`` content.
|
||||
|
||||
How often do changes from these trees make it to the mainline Linus tree?
|
||||
-------------------------------------------------------------------------
|
||||
To understand this, you need to know a bit of background information on
|
||||
Here is a bit of background information on
|
||||
the cadence of Linux development. Each new release starts off with a
|
||||
two week "merge window" where the main maintainers feed their new stuff
|
||||
to Linus for merging into the mainline tree. After the two weeks, the
|
||||
|
|
@ -69,9 +48,33 @@ rc2 is released. This repeats on a roughly weekly basis until rc7
|
|||
state of churn), and a week after the last vX.Y-rcN was done, the
|
||||
official vX.Y is released.
|
||||
|
||||
Relating that to netdev: At the beginning of the 2-week merge window,
|
||||
the ``net-next`` tree will be closed - no new changes/features. The
|
||||
accumulated new content of the past ~10 weeks will be passed onto
|
||||
To find out where we are now in the cycle - load the mainline (Linus)
|
||||
page here:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
|
||||
|
||||
and note the top of the "tags" section. If it is rc1, it is early in
|
||||
the dev cycle. If it was tagged rc7 a week ago, then a release is
|
||||
probably imminent. If the most recent tag is a final release tag
|
||||
(without an ``-rcN`` suffix) - we are most likely in a merge window
|
||||
and ``net-next`` is closed.
|
||||
|
||||
git trees and patch flow
|
||||
------------------------
|
||||
|
||||
There are two networking trees (git repositories) in play. Both are
|
||||
driven by David Miller, the main network maintainer. There is the
|
||||
``net`` tree, and the ``net-next`` tree. As you can probably guess from
|
||||
the names, the ``net`` tree is for fixes to existing code already in the
|
||||
mainline tree from Linus, and ``net-next`` is where the new code goes
|
||||
for the future release. You can find the trees here:
|
||||
|
||||
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
|
||||
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
|
||||
|
||||
Relating that to kernel development: At the beginning of the 2-week
|
||||
merge window, the ``net-next`` tree will be closed - no new changes/features.
|
||||
The accumulated new content of the past ~10 weeks will be passed onto
|
||||
mainline/Linus via a pull request for vX.Y -- at the same time, the
|
||||
``net`` tree will start accumulating fixes for this pulled content
|
||||
relating to vX.Y
|
||||
|
|
@ -103,22 +106,14 @@ focus for ``net`` is on stabilization and bug fixes.
|
|||
|
||||
Finally, the vX.Y gets released, and the whole cycle starts over.
|
||||
|
||||
So where are we now in this cycle?
|
||||
----------------------------------
|
||||
netdev patch review
|
||||
-------------------
|
||||
|
||||
Load the mainline (Linus) page here:
|
||||
Patch status
|
||||
~~~~~~~~~~~~
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
|
||||
|
||||
and note the top of the "tags" section. If it is rc1, it is early in
|
||||
the dev cycle. If it was tagged rc7 a week ago, then a release is
|
||||
probably imminent. If the most recent tag is a final release tag
|
||||
(without an ``-rcN`` suffix) - we are most likely in a merge window
|
||||
and ``net-next`` is closed.
|
||||
|
||||
How can I tell the status of a patch I've sent?
|
||||
-----------------------------------------------
|
||||
Start by looking at the main patchworks queue for netdev:
|
||||
Status of a patch can be checked by looking at the main patchwork
|
||||
queue for netdev:
|
||||
|
||||
https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
|
||||
|
|
@ -127,8 +122,20 @@ patch. Patches are indexed by the ``Message-ID`` header of the emails
|
|||
which carried them so if you have trouble finding your patch append
|
||||
the value of ``Message-ID`` to the URL above.
|
||||
|
||||
How long before my patch is accepted?
|
||||
-------------------------------------
|
||||
Updating patch status
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It may be tempting to help the maintainers and update the state of your
|
||||
own patches when you post a new version or spot a bug. Please **do not**
|
||||
do that.
|
||||
Interfering with the patch status on patchwork will only cause confusion. Leave
|
||||
it to the maintainer to figure out what is the most recent and current
|
||||
version that should be applied. If there is any doubt, the maintainer
|
||||
will reply and ask what should be done.
|
||||
|
||||
Review timelines
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Generally speaking, the patches get triaged quickly (in less than
|
||||
48h). But be patient, if your patch is active in patchwork (i.e. it's
|
||||
listed on the project's patch list) the chances it was missed are close to zero.
|
||||
|
|
@ -136,116 +143,47 @@ Asking the maintainer for status updates on your
|
|||
patch is a good way to ensure your patch is ignored or pushed to the
|
||||
bottom of the priority list.
|
||||
|
||||
Should I directly update patchwork state of my own patches?
|
||||
-----------------------------------------------------------
|
||||
It may be tempting to help the maintainers and update the state of your
|
||||
own patches when you post a new version or spot a bug. Please do not do that.
|
||||
Interfering with the patch status on patchwork will only cause confusion. Leave
|
||||
it to the maintainer to figure out what is the most recent and current
|
||||
version that should be applied. If there is any doubt, the maintainer
|
||||
will reply and ask what should be done.
|
||||
Partial resends
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
How do I divide my work into patches?
|
||||
-------------------------------------
|
||||
|
||||
Put yourself in the shoes of the reviewer. Each patch is read separately
|
||||
and therefore should constitute a comprehensible step towards your stated
|
||||
goal.
|
||||
|
||||
Avoid sending series longer than 15 patches. Larger series takes longer
|
||||
to review as reviewers will defer looking at it until they find a large
|
||||
chunk of time. A small series can be reviewed in a short time, so Maintainers
|
||||
just do it. As a result, a sequence of smaller series gets merged quicker and
|
||||
with better review coverage. Re-posting large series also increases the mailing
|
||||
list traffic.
|
||||
|
||||
I made changes to only a few patches in a patch series should I resend only those changed?
|
||||
------------------------------------------------------------------------------------------
|
||||
No, please resend the entire patch series and make sure you do number your
|
||||
Please always resend the entire patch series and make sure you do number your
|
||||
patches such that it is clear this is the latest and greatest set of patches
|
||||
that can be applied.
|
||||
that can be applied. Do not try to resend just the patches which changed.
|
||||
|
||||
I have received review feedback, when should I post a revised version of the patches?
|
||||
-------------------------------------------------------------------------------------
|
||||
Allow at least 24 hours to pass between postings. This will ensure reviewers
|
||||
from all geographical locations have a chance to chime in. Do not wait
|
||||
too long (weeks) between postings either as it will make it harder for reviewers
|
||||
to recall all the context.
|
||||
Handling misapplied patches
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Make sure you address all the feedback in your new posting. Do not post a new
|
||||
version of the code if the discussion about the previous version is still
|
||||
ongoing, unless directly instructed by a reviewer.
|
||||
|
||||
I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do?
|
||||
----------------------------------------------------------------------------------------------------------------------------------------
|
||||
Occasionally a patch series gets applied before receiving critical feedback,
|
||||
or the wrong version of a series gets applied.
|
||||
There is no revert possible, once it is pushed out, it stays like that.
|
||||
Please send incremental versions on top of what has been merged in order to fix
|
||||
the patches the way they would look like if your latest patch series was to be
|
||||
merged.
|
||||
|
||||
Are there special rules regarding stable submissions on netdev?
|
||||
---------------------------------------------------------------
|
||||
Stable tree
|
||||
~~~~~~~~~~~
|
||||
|
||||
While it used to be the case that netdev submissions were not supposed
|
||||
to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer
|
||||
the case today. Please follow the standard stable rules in
|
||||
:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
|
||||
and make sure you include appropriate Fixes tags!
|
||||
|
||||
Is the comment style convention different for the networking content?
|
||||
---------------------------------------------------------------------
|
||||
Yes, in a largely trivial way. Instead of this::
|
||||
Security fixes
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
/*
|
||||
* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
it is requested that you make it look like this::
|
||||
|
||||
/* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
What is "reverse xmas tree"?
|
||||
----------------------------
|
||||
|
||||
Netdev has a convention for ordering local variables in functions.
|
||||
Order the variable declaration lines longest to shortest, e.g.::
|
||||
|
||||
struct scatterlist *sg;
|
||||
struct sk_buff *skb;
|
||||
int err, i;
|
||||
|
||||
If there are dependencies between the variables preventing the ordering
|
||||
move the initialization out of line.
|
||||
|
||||
I am working in existing code which uses non-standard formatting. Which formatting should I use?
|
||||
------------------------------------------------------------------------------------------------
|
||||
Make your code follow the most recent guidelines, so that eventually all code
|
||||
in the domain of netdev is in the preferred format.
|
||||
|
||||
I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list?
|
||||
---------------------------------------------------------------------------------------------------------------------------
|
||||
No. The current netdev maintainer has consistently requested that
|
||||
Do not email netdev maintainers directly if you think you discovered
|
||||
a bug that might have possible security implications.
|
||||
The current netdev maintainer has consistently requested that
|
||||
people use the mailing lists and not reach out directly. If you aren't
|
||||
OK with that, then perhaps consider mailing security@kernel.org or
|
||||
reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
|
||||
as possible alternative mechanisms.
|
||||
|
||||
What level of testing is expected before I submit my change?
|
||||
------------------------------------------------------------
|
||||
At the very minimum your changes must survive an ``allyesconfig`` and an
|
||||
``allmodconfig`` build with ``W=1`` set without new warnings or failures.
|
||||
|
||||
Ideally you will have done run-time testing specific to your change,
|
||||
and the patch series contains a set of kernel selftest for
|
||||
``tools/testing/selftests/net`` or using the KUnit framework.
|
||||
Co-posting changes to user space components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You are expected to test your changes on top of the relevant networking
|
||||
tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``.
|
||||
|
||||
How do I post corresponding changes to user space components?
|
||||
-------------------------------------------------------------
|
||||
User space code exercising kernel features should be posted
|
||||
alongside kernel patches. This gives reviewers a chance to see
|
||||
how any new interface is used and how well it works.
|
||||
|
|
@ -270,42 +208,10 @@ to the mailing list, e.g.::
|
|||
Posting as one thread is discouraged because it confuses patchwork
|
||||
(as of patchwork 2.2.2).
|
||||
|
||||
Can I reproduce the checks from patchwork on my local machine?
|
||||
--------------------------------------------------------------
|
||||
Preparing changes
|
||||
-----------------
|
||||
|
||||
Checks in patchwork are mostly simple wrappers around existing kernel
|
||||
scripts, the sources are available at:
|
||||
|
||||
https://github.com/kuba-moo/nipa/tree/master/tests
|
||||
|
||||
Running all the builds and checks locally is a pain, can I post my patches and have the patchwork bot validate them?
|
||||
--------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
No, you must ensure that your patches are ready by testing them locally
|
||||
before posting to the mailing list. The patchwork build bot instance
|
||||
gets overloaded very easily and netdev@vger really doesn't need more
|
||||
traffic if we can help it.
|
||||
|
||||
netdevsim is great, can I extend it for my out-of-tree tests?
|
||||
-------------------------------------------------------------
|
||||
|
||||
No, ``netdevsim`` is a test vehicle solely for upstream tests.
|
||||
(Please add your tests under ``tools/testing/selftests/``.)
|
||||
|
||||
We also give no guarantees that ``netdevsim`` won't change in the future
|
||||
in a way which would break what would normally be considered uAPI.
|
||||
|
||||
Is netdevsim considered a "user" of an API?
|
||||
-------------------------------------------
|
||||
|
||||
Linux kernel has a long standing rule that no API should be added unless
|
||||
it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are
|
||||
strongly encouraged when adding new APIs, but ``netdevsim`` in itself
|
||||
is **not** considered a use case/user.
|
||||
|
||||
Any other tips to help ensure my net/net-next patch gets OK'd?
|
||||
--------------------------------------------------------------
|
||||
Attention to detail. Re-read your own work as if you were the
|
||||
Attention to detail is important. Re-read your own work as if you were the
|
||||
reviewer. You can start with using ``checkpatch.pl``, perhaps even with
|
||||
the ``--strict`` flag. But do not be mindlessly robotic in doing so.
|
||||
If your change is a bug fix, make sure your commit log indicates the
|
||||
|
|
@ -320,10 +226,133 @@ Finally, go back and read
|
|||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
to be sure you are not repeating some common mistake documented there.
|
||||
|
||||
My company uses peer feedback in employee performance reviews. Can I ask netdev maintainers for feedback?
|
||||
---------------------------------------------------------------------------------------------------------
|
||||
Indicating target tree
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Yes, especially if you spend significant amount of time reviewing code
|
||||
To help maintainers and CI bots you should explicitly mark which tree
|
||||
your patch is targeting. Assuming that you use git, use the prefix
|
||||
flag::
|
||||
|
||||
git format-patch --subject-prefix='PATCH net-next' start..finish
|
||||
|
||||
Use ``net`` instead of ``net-next`` (always lower case) in the above for
|
||||
bug-fix ``net`` content.
|
||||
|
||||
Dividing work into patches
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Put yourself in the shoes of the reviewer. Each patch is read separately
|
||||
and therefore should constitute a comprehensible step towards your stated
|
||||
goal.
|
||||
|
||||
Avoid sending series longer than 15 patches. Larger series takes longer
|
||||
to review as reviewers will defer looking at it until they find a large
|
||||
chunk of time. A small series can be reviewed in a short time, so Maintainers
|
||||
just do it. As a result, a sequence of smaller series gets merged quicker and
|
||||
with better review coverage. Re-posting large series also increases the mailing
|
||||
list traffic.
|
||||
|
||||
Multi-line comments
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Comment style convention is slightly different for networking and most of
|
||||
the tree. Instead of this::
|
||||
|
||||
/*
|
||||
* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
it is requested that you make it look like this::
|
||||
|
||||
/* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
Local variable ordering ("reverse xmas tree", "RCS")
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Netdev has a convention for ordering local variables in functions.
|
||||
Order the variable declaration lines longest to shortest, e.g.::
|
||||
|
||||
struct scatterlist *sg;
|
||||
struct sk_buff *skb;
|
||||
int err, i;
|
||||
|
||||
If there are dependencies between the variables preventing the ordering
|
||||
move the initialization out of line.
|
||||
|
||||
Format precedence
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
When working in existing code which uses nonstandard formatting make
|
||||
your code follow the most recent guidelines, so that eventually all code
|
||||
in the domain of netdev is in the preferred format.
|
||||
|
||||
Resending after review
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Allow at least 24 hours to pass between postings. This will ensure reviewers
|
||||
from all geographical locations have a chance to chime in. Do not wait
|
||||
too long (weeks) between postings either as it will make it harder for reviewers
|
||||
to recall all the context.
|
||||
|
||||
Make sure you address all the feedback in your new posting. Do not post a new
|
||||
version of the code if the discussion about the previous version is still
|
||||
ongoing, unless directly instructed by a reviewer.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Expected level of testing
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At the very minimum your changes must survive an ``allyesconfig`` and an
|
||||
``allmodconfig`` build with ``W=1`` set without new warnings or failures.
|
||||
|
||||
Ideally you will have done run-time testing specific to your change,
|
||||
and the patch series contains a set of kernel selftest for
|
||||
``tools/testing/selftests/net`` or using the KUnit framework.
|
||||
|
||||
You are expected to test your changes on top of the relevant networking
|
||||
tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``.
|
||||
|
||||
patchwork checks
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Checks in patchwork are mostly simple wrappers around existing kernel
|
||||
scripts, the sources are available at:
|
||||
|
||||
https://github.com/kuba-moo/nipa/tree/master/tests
|
||||
|
||||
**Do not** post your patches just to run them through the checks.
|
||||
You must ensure that your patches are ready by testing them locally
|
||||
before posting to the mailing list. The patchwork build bot instance
|
||||
gets overloaded very easily and netdev@vger really doesn't need more
|
||||
traffic if we can help it.
|
||||
|
||||
netdevsim
|
||||
~~~~~~~~~
|
||||
|
||||
``netdevsim`` is a test driver which can be used to exercise driver
|
||||
configuration APIs without requiring capable hardware.
|
||||
Mock-ups and tests based on ``netdevsim`` are strongly encouraged when
|
||||
adding new APIs, but ``netdevsim`` in itself is **not** considered
|
||||
a use case/user. You must also implement the new APIs in a real driver.
|
||||
|
||||
We give no guarantees that ``netdevsim`` won't change in the future
|
||||
in a way which would break what would normally be considered uAPI.
|
||||
|
||||
``netdevsim`` is reserved for use by upstream tests only, so any
|
||||
new ``netdevsim`` features must be accompanied by selftests under
|
||||
``tools/testing/selftests/``.
|
||||
|
||||
Testimonials / feedback
|
||||
-----------------------
|
||||
|
||||
Some companies use peer feedback in employee performance reviews.
|
||||
Please feel free to request feedback from netdev maintainers,
|
||||
especially if you spend significant amount of time reviewing code
|
||||
and go out of your way to improve shared infrastructure.
|
||||
|
||||
The feedback must be requested by you, the contributor, and will always
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
import os
|
||||
import sys
|
||||
from sphinx.util.pycompat import execfile_
|
||||
from sphinx.util.osutil import fs_encoding
|
||||
|
||||
# ------------------------------------------------------------------------------
|
||||
def loadConfig(namespace):
|
||||
|
|
@ -48,7 +48,9 @@ def loadConfig(namespace):
|
|||
sys.stdout.write("load additional sphinx-config: %s\n" % config_file)
|
||||
config = namespace.copy()
|
||||
config['__file__'] = config_file
|
||||
execfile_(config_file, config)
|
||||
with open(config_file, 'rb') as f:
|
||||
code = compile(f.read(), fs_encoding, 'exec')
|
||||
exec(code, config)
|
||||
del config['__file__']
|
||||
namespace.update(config)
|
||||
else:
|
||||
|
|
|
|||
|
|
@ -1354,6 +1354,14 @@ the memory region are automatically reflected into the guest. For example, an
|
|||
mmap() that affects the region will be made visible immediately. Another
|
||||
example is madvise(MADV_DROP).
|
||||
|
||||
Note: On arm64, a write generated by the page-table walker (to update
|
||||
the Access and Dirty flags, for example) never results in a
|
||||
KVM_EXIT_MMIO exit when the slot has the KVM_MEM_READONLY flag. This
|
||||
is because KVM cannot provide the data that would be written by the
|
||||
page-table walker, making it impossible to emulate the access.
|
||||
Instead, an abort (data abort if the cause of the page-table update
|
||||
was a load or a store, instruction abort if it was an instruction
|
||||
fetch) is injected in the guest.
|
||||
|
||||
4.36 KVM_SET_TSS_ADDR
|
||||
---------------------
|
||||
|
|
@ -5343,9 +5351,9 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO
|
|||
32 vCPUs in the shared_info page, KVM does not automatically do so
|
||||
and instead requires that KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO be used
|
||||
explicitly even when the vcpu_info for a given vCPU resides at the
|
||||
"default" location in the shared_info page. This is because KVM is
|
||||
not aware of the Xen CPU id which is used as the index into the
|
||||
vcpu_info[] array, so cannot know the correct default location.
|
||||
"default" location in the shared_info page. This is because KVM may
|
||||
not be aware of the Xen CPU id which is used as the index into the
|
||||
vcpu_info[] array, so may know the correct default location.
|
||||
|
||||
Note that the shared info page may be constantly written to by KVM;
|
||||
it contains the event channel bitmap used to deliver interrupts to
|
||||
|
|
@ -5356,23 +5364,29 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO
|
|||
any vCPU has been running or any event channel interrupts can be
|
||||
routed to the guest.
|
||||
|
||||
Setting the gfn to KVM_XEN_INVALID_GFN will disable the shared info
|
||||
page.
|
||||
|
||||
KVM_XEN_ATTR_TYPE_UPCALL_VECTOR
|
||||
Sets the exception vector used to deliver Xen event channel upcalls.
|
||||
This is the HVM-wide vector injected directly by the hypervisor
|
||||
(not through the local APIC), typically configured by a guest via
|
||||
HVM_PARAM_CALLBACK_IRQ.
|
||||
HVM_PARAM_CALLBACK_IRQ. This can be disabled again (e.g. for guest
|
||||
SHUTDOWN_soft_reset) by setting it to zero.
|
||||
|
||||
KVM_XEN_ATTR_TYPE_EVTCHN
|
||||
This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates
|
||||
support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It configures
|
||||
an outbound port number for interception of EVTCHNOP_send requests
|
||||
from the guest. A given sending port number may be directed back
|
||||
to a specified vCPU (by APIC ID) / port / priority on the guest,
|
||||
or to trigger events on an eventfd. The vCPU and priority can be
|
||||
changed by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call,
|
||||
but other fields cannot change for a given sending port. A port
|
||||
mapping is removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags
|
||||
field.
|
||||
from the guest. A given sending port number may be directed back to
|
||||
a specified vCPU (by APIC ID) / port / priority on the guest, or to
|
||||
trigger events on an eventfd. The vCPU and priority can be changed
|
||||
by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call, but but other
|
||||
fields cannot change for a given sending port. A port mapping is
|
||||
removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags field. Passing
|
||||
KVM_XEN_EVTCHN_RESET in the flags field removes all interception of
|
||||
outbound event channels. The values of the flags field are mutually
|
||||
exclusive and cannot be combined as a bitmask.
|
||||
|
||||
KVM_XEN_ATTR_TYPE_XEN_VERSION
|
||||
This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates
|
||||
|
|
@ -5388,7 +5402,7 @@ KVM_XEN_ATTR_TYPE_RUNSTATE_UPDATE_FLAG
|
|||
support for KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG. It enables the
|
||||
XEN_RUNSTATE_UPDATE flag which allows guest vCPUs to safely read
|
||||
other vCPUs' vcpu_runstate_info. Xen guests enable this feature via
|
||||
the VM_ASST_TYPE_runstate_update_flag of the HYPERVISOR_vm_assist
|
||||
the VMASST_TYPE_runstate_update_flag of the HYPERVISOR_vm_assist
|
||||
hypercall.
|
||||
|
||||
4.127 KVM_XEN_HVM_GET_ATTR
|
||||
|
|
@ -5446,15 +5460,18 @@ KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO
|
|||
As with the shared_info page for the VM, the corresponding page may be
|
||||
dirtied at any time if event channel interrupt delivery is enabled, so
|
||||
userspace should always assume that the page is dirty without relying
|
||||
on dirty logging.
|
||||
on dirty logging. Setting the gpa to KVM_XEN_INVALID_GPA will disable
|
||||
the vcpu_info.
|
||||
|
||||
KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO
|
||||
Sets the guest physical address of an additional pvclock structure
|
||||
for a given vCPU. This is typically used for guest vsyscall support.
|
||||
Setting the gpa to KVM_XEN_INVALID_GPA will disable the structure.
|
||||
|
||||
KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR
|
||||
Sets the guest physical address of the vcpu_runstate_info for a given
|
||||
vCPU. This is how a Xen guest tracks CPU state such as steal time.
|
||||
Setting the gpa to KVM_XEN_INVALID_GPA will disable the runstate area.
|
||||
|
||||
KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_CURRENT
|
||||
Sets the runstate (RUNSTATE_running/_runnable/_blocked/_offline) of
|
||||
|
|
@ -5487,7 +5504,8 @@ KVM_XEN_VCPU_ATTR_TYPE_TIMER
|
|||
This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates
|
||||
support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the
|
||||
event channel port/priority for the VIRQ_TIMER of the vCPU, as well
|
||||
as allowing a pending timer to be saved/restored.
|
||||
as allowing a pending timer to be saved/restored. Setting the timer
|
||||
port to zero disables kernel handling of the singleshot timer.
|
||||
|
||||
KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR
|
||||
This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates
|
||||
|
|
@ -5495,7 +5513,8 @@ KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR
|
|||
per-vCPU local APIC upcall vector, configured by a Xen guest with
|
||||
the HVMOP_set_evtchn_upcall_vector hypercall. This is typically
|
||||
used by Windows guests, and is distinct from the HVM-wide upcall
|
||||
vector configured with HVM_PARAM_CALLBACK_IRQ.
|
||||
vector configured with HVM_PARAM_CALLBACK_IRQ. It is disabled by
|
||||
setting the vector to zero.
|
||||
|
||||
|
||||
4.129 KVM_XEN_VCPU_GET_ATTR
|
||||
|
|
@ -6577,11 +6596,6 @@ Please note that the kernel is allowed to use the kvm_run structure as the
|
|||
primary storage for certain register types. Therefore, the kernel may use the
|
||||
values in kvm_run even if the corresponding bit in kvm_dirty_regs is not set.
|
||||
|
||||
::
|
||||
|
||||
};
|
||||
|
||||
|
||||
|
||||
6. Capabilities that can be enabled on vCPUs
|
||||
============================================
|
||||
|
|
@ -8304,6 +8318,20 @@ CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by ``KVM_GET_SUPPORTED_CPUID``
|
|||
It can be enabled if ``KVM_CAP_TSC_DEADLINE_TIMER`` is present and the kernel
|
||||
has enabled in-kernel emulation of the local APIC.
|
||||
|
||||
CPU topology
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Several CPUID values include topology information for the host CPU:
|
||||
0x0b and 0x1f for Intel systems, 0x8000001e for AMD systems. Different
|
||||
versions of KVM return different values for this information and userspace
|
||||
should not rely on it. Currently they return all zeroes.
|
||||
|
||||
If userspace wishes to set up a guest topology, it should be careful that
|
||||
the values of these three leaves differ for each CPU. In particular,
|
||||
the APIC ID is found in EDX for all subleaves of 0x0b and 0x1f, and in EAX
|
||||
for 0x8000001e; the latter also encodes the core id and node id in bits
|
||||
7:0 of EBX and ECX respectively.
|
||||
|
||||
Obsolete ioctls and capabilities
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
|
|||
|
|
@ -16,20 +16,30 @@ The acquisition orders for mutexes are as follows:
|
|||
- kvm->slots_lock is taken outside kvm->irq_lock, though acquiring
|
||||
them together is quite rare.
|
||||
|
||||
- Unlike kvm->slots_lock, kvm->slots_arch_lock is released before
|
||||
synchronize_srcu(&kvm->srcu). Therefore kvm->slots_arch_lock
|
||||
can be taken inside a kvm->srcu read-side critical section,
|
||||
while kvm->slots_lock cannot.
|
||||
|
||||
- kvm->mn_active_invalidate_count ensures that pairs of
|
||||
invalidate_range_start() and invalidate_range_end() callbacks
|
||||
use the same memslots array. kvm->slots_lock and kvm->slots_arch_lock
|
||||
are taken on the waiting side in install_new_memslots, so MMU notifiers
|
||||
must not take either kvm->slots_lock or kvm->slots_arch_lock.
|
||||
|
||||
For SRCU:
|
||||
|
||||
- ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
|
||||
for kvm->lock, vcpu->mutex and kvm->slots_lock. These locks _cannot_
|
||||
be taken inside a kvm->srcu read-side critical section; that is, the
|
||||
following is broken::
|
||||
|
||||
srcu_read_lock(&kvm->srcu);
|
||||
mutex_lock(&kvm->slots_lock);
|
||||
|
||||
- kvm->slots_arch_lock instead is released before the call to
|
||||
``synchronize_srcu()``. It _can_ therefore be taken inside a
|
||||
kvm->srcu read-side critical section, for example while processing
|
||||
a vmexit.
|
||||
|
||||
On x86:
|
||||
|
||||
- vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock
|
||||
- vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock and kvm->arch.xen.xen_lock
|
||||
|
||||
- kvm->arch.mmu_lock is an rwlock. kvm->arch.tdp_mmu_pages_lock and
|
||||
kvm->arch.mmu_unsync_pages_lock are taken inside kvm->arch.mmu_lock, and
|
||||
|
|
|
|||
|
|
@ -95,3 +95,39 @@ by supplying mem_encrypt=on on the kernel command line. However, if BIOS does
|
|||
not enable SME, then Linux will not be able to activate memory encryption, even
|
||||
if configured to do so by default or the mem_encrypt=on command line parameter
|
||||
is specified.
|
||||
|
||||
Secure Nested Paging (SNP)
|
||||
==========================
|
||||
|
||||
SEV-SNP introduces new features (SEV_FEATURES[1:63]) which can be enabled
|
||||
by the hypervisor for security enhancements. Some of these features need
|
||||
guest side implementation to function correctly. The below table lists the
|
||||
expected guest behavior with various possible scenarios of guest/hypervisor
|
||||
SNP feature support.
|
||||
|
||||
+-----------------+---------------+---------------+------------------+
|
||||
| Feature Enabled | Guest needs | Guest has | Guest boot |
|
||||
| by the HV | implementation| implementation| behaviour |
|
||||
+=================+===============+===============+==================+
|
||||
| No | No | No | Boot |
|
||||
| | | | |
|
||||
+-----------------+---------------+---------------+------------------+
|
||||
| No | Yes | No | Boot |
|
||||
| | | | |
|
||||
+-----------------+---------------+---------------+------------------+
|
||||
| No | Yes | Yes | Boot |
|
||||
| | | | |
|
||||
+-----------------+---------------+---------------+------------------+
|
||||
| Yes | No | No | Boot with |
|
||||
| | | | feature enabled |
|
||||
+-----------------+---------------+---------------+------------------+
|
||||
| Yes | Yes | No | Graceful boot |
|
||||
| | | | failure |
|
||||
+-----------------+---------------+---------------+------------------+
|
||||
| Yes | Yes | Yes | Boot with |
|
||||
| | | | feature enabled |
|
||||
+-----------------+---------------+---------------+------------------+
|
||||
|
||||
More details in AMD64 APM[1] Vol 2: 15.34.10 SEV_STATUS MSR
|
||||
|
||||
[1] https://www.amd.com/system/files/TechDocs/40332.pdf
|
||||
|
|
|
|||
80
MAINTAINERS
80
MAINTAINERS
|
|
@ -383,7 +383,7 @@ ACPI COMPONENT ARCHITECTURE (ACPICA)
|
|||
M: Robert Moore <robert.moore@intel.com>
|
||||
M: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
|
||||
L: linux-acpi@vger.kernel.org
|
||||
L: devel@acpica.org
|
||||
L: acpica-devel@lists.linuxfoundation.org
|
||||
S: Supported
|
||||
W: https://acpica.org/
|
||||
W: https://github.com/acpica/acpica/
|
||||
|
|
@ -1104,7 +1104,6 @@ S: Supported
|
|||
F: arch/arm64/boot/dts/amd/
|
||||
|
||||
AMD XGBE DRIVER
|
||||
M: Tom Lendacky <thomas.lendacky@amd.com>
|
||||
M: "Shyam Sundar S K" <Shyam-sundar.S-k@amd.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -6948,7 +6947,7 @@ F: drivers/gpu/drm/atmel-hlcdc/
|
|||
DRM DRIVERS FOR BRIDGE CHIPS
|
||||
M: Andrzej Hajda <andrzej.hajda@intel.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
M: Robert Foss <robert.foss@linaro.org>
|
||||
M: Robert Foss <rfoss@kernel.org>
|
||||
R: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
|
||||
R: Jonas Karlman <jonas@kwiboo.se>
|
||||
R: Jernej Skrabec <jernej.skrabec@gmail.com>
|
||||
|
|
@ -7616,7 +7615,6 @@ S: Maintained
|
|||
F: drivers/firmware/efi/test/
|
||||
|
||||
EFI VARIABLE FILESYSTEM
|
||||
M: Matthew Garrett <matthew.garrett@nebula.com>
|
||||
M: Jeremy Kerr <jk@ozlabs.org>
|
||||
M: Ard Biesheuvel <ardb@kernel.org>
|
||||
L: linux-efi@vger.kernel.org
|
||||
|
|
@ -7895,7 +7893,11 @@ F: include/linux/extcon/
|
|||
|
||||
EXTRA BOOT CONFIG
|
||||
M: Masami Hiramatsu <mhiramat@kernel.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: linux-trace-kernel@vger.kernel.org
|
||||
Q: https://patchwork.kernel.org/project/linux-trace-kernel/list/
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
|
||||
F: Documentation/admin-guide/bootconfig.rst
|
||||
F: fs/proc/bootconfig.c
|
||||
F: include/linux/bootconfig.h
|
||||
|
|
@ -8468,16 +8470,16 @@ F: fs/fscache/
|
|||
F: include/linux/fscache*.h
|
||||
|
||||
FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT
|
||||
M: Eric Biggers <ebiggers@kernel.org>
|
||||
M: Theodore Y. Ts'o <tytso@mit.edu>
|
||||
M: Jaegeuk Kim <jaegeuk@kernel.org>
|
||||
M: Eric Biggers <ebiggers@kernel.org>
|
||||
L: linux-fscrypt@vger.kernel.org
|
||||
S: Supported
|
||||
Q: https://patchwork.kernel.org/project/linux-fscrypt/list/
|
||||
T: git git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git
|
||||
T: git https://git.kernel.org/pub/scm/fs/fscrypt/linux.git
|
||||
F: Documentation/filesystems/fscrypt.rst
|
||||
F: fs/crypto/
|
||||
F: include/linux/fscrypt*.h
|
||||
F: include/linux/fscrypt.h
|
||||
F: include/uapi/linux/fscrypt.h
|
||||
|
||||
FSI SUBSYSTEM
|
||||
|
|
@ -8520,10 +8522,10 @@ F: include/linux/fsnotify*.h
|
|||
FSVERITY: READ-ONLY FILE-BASED AUTHENTICITY PROTECTION
|
||||
M: Eric Biggers <ebiggers@kernel.org>
|
||||
M: Theodore Y. Ts'o <tytso@mit.edu>
|
||||
L: linux-fscrypt@vger.kernel.org
|
||||
L: fsverity@lists.linux.dev
|
||||
S: Supported
|
||||
Q: https://patchwork.kernel.org/project/linux-fscrypt/list/
|
||||
T: git git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git fsverity
|
||||
Q: https://patchwork.kernel.org/project/fsverity/list/
|
||||
T: git https://git.kernel.org/pub/scm/fs/fsverity/linux.git
|
||||
F: Documentation/filesystems/fsverity.rst
|
||||
F: fs/verity/
|
||||
F: include/linux/fsverity.h
|
||||
|
|
@ -8571,6 +8573,7 @@ F: kernel/trace/fgraph.c
|
|||
F: arch/*/*/*/*ftrace*
|
||||
F: arch/*/*/*ftrace*
|
||||
F: include/*/ftrace.h
|
||||
F: samples/ftrace
|
||||
|
||||
FUNGIBLE ETHERNET DRIVERS
|
||||
M: Dimitris Michailidis <dmichail@fungible.com>
|
||||
|
|
@ -9299,7 +9302,7 @@ F: net/dsa/tag_hellcreek.c
|
|||
|
||||
HISILICON DMA DRIVER
|
||||
M: Zhou Wang <wangzhou1@hisilicon.com>
|
||||
M: Jie Hai <haijie1@hisilicon.com>
|
||||
M: Jie Hai <haijie1@huawei.com>
|
||||
L: dmaengine@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/dma/hisi_dma.c
|
||||
|
|
@ -11356,9 +11359,9 @@ F: virt/kvm/*
|
|||
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
|
||||
M: Marc Zyngier <maz@kernel.org>
|
||||
R: James Morse <james.morse@arm.com>
|
||||
R: Alexandru Elisei <alexandru.elisei@arm.com>
|
||||
R: Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
R: Oliver Upton <oliver.upton@linux.dev>
|
||||
R: Zenghui Yu <yuzenghui@huawei.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: kvmarm@lists.linux.dev
|
||||
L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
|
||||
|
|
@ -11468,7 +11471,7 @@ F: arch/x86/kvm/hyperv.*
|
|||
F: arch/x86/kvm/kvm_onhyperv.*
|
||||
F: arch/x86/kvm/svm/hyperv.*
|
||||
F: arch/x86/kvm/svm/svm_onhyperv.*
|
||||
F: arch/x86/kvm/vmx/evmcs.*
|
||||
F: arch/x86/kvm/vmx/hyperv.*
|
||||
|
||||
KVM X86 Xen (KVM/Xen)
|
||||
M: David Woodhouse <dwmw2@infradead.org>
|
||||
|
|
@ -13620,7 +13623,7 @@ F: arch/microblaze/
|
|||
|
||||
MICROCHIP AT91 DMA DRIVERS
|
||||
M: Ludovic Desroches <ludovic.desroches@microchip.com>
|
||||
M: Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
M: Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: dmaengine@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -13665,7 +13668,7 @@ F: Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
|
|||
F: drivers/media/platform/microchip/microchip-csi2dc.c
|
||||
|
||||
MICROCHIP ECC DRIVER
|
||||
M: Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
M: Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
L: linux-crypto@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/crypto/atmel-ecc.*
|
||||
|
|
@ -13762,7 +13765,7 @@ S: Maintained
|
|||
F: drivers/mmc/host/atmel-mci.c
|
||||
|
||||
MICROCHIP NAND DRIVER
|
||||
M: Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
M: Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
L: linux-mtd@lists.infradead.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
|
||||
|
|
@ -13814,7 +13817,7 @@ S: Supported
|
|||
F: drivers/power/reset/at91-sama5d2_shdwc.c
|
||||
|
||||
MICROCHIP SPI DRIVER
|
||||
M: Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
M: Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
S: Supported
|
||||
F: drivers/spi/spi-atmel.*
|
||||
|
||||
|
|
@ -14634,7 +14637,6 @@ F: net/netfilter/xt_SECMARK.c
|
|||
F: net/netlabel/
|
||||
|
||||
NETWORKING [MPTCP]
|
||||
M: Mat Martineau <mathew.j.martineau@linux.intel.com>
|
||||
M: Matthieu Baerts <matthieu.baerts@tessares.net>
|
||||
L: netdev@vger.kernel.org
|
||||
L: mptcp@lists.linux.dev
|
||||
|
|
@ -14916,9 +14918,11 @@ L: linux-nvme@lists.infradead.org
|
|||
S: Supported
|
||||
W: http://git.infradead.org/nvme.git
|
||||
T: git://git.infradead.org/nvme.git
|
||||
F: Documentation/nvme/
|
||||
F: drivers/nvme/host/
|
||||
F: drivers/nvme/common/
|
||||
F: include/linux/nvme*
|
||||
F: include/linux/nvme.h
|
||||
F: include/linux/nvme-*.h
|
||||
F: include/uapi/linux/nvme_ioctl.h
|
||||
|
||||
NVM EXPRESS FABRICS AUTHENTICATION
|
||||
|
|
@ -15748,6 +15752,12 @@ S: Maintained
|
|||
W: https://wireless.wiki.kernel.org/en/users/Drivers/p54
|
||||
F: drivers/net/wireless/intersil/p54/
|
||||
|
||||
PACKET SOCKETS
|
||||
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
|
||||
S: Maintained
|
||||
F: include/uapi/linux/if_packet.h
|
||||
F: net/packet/af_packet.c
|
||||
|
||||
PACKING
|
||||
M: Vladimir Oltean <olteanv@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
|
|
@ -16609,6 +16619,13 @@ S: Supported
|
|||
F: Documentation/devicetree/bindings/input/pine64,pinephone-keyboard.yaml
|
||||
F: drivers/input/keyboard/pinephone-keyboard.c
|
||||
|
||||
PKTCDVD DRIVER
|
||||
M: linux-block@vger.kernel.org
|
||||
S: Orphan
|
||||
F: drivers/block/pktcdvd.c
|
||||
F: include/linux/pktcdvd.h
|
||||
F: include/uapi/linux/pktcdvd.h
|
||||
|
||||
PLANTOWER PMS7003 AIR POLLUTION SENSOR DRIVER
|
||||
M: Tomasz Duszynski <tduszyns@gmail.com>
|
||||
S: Maintained
|
||||
|
|
@ -17229,7 +17246,7 @@ F: Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
|
|||
F: drivers/net/wwan/qcom_bam_dmux.c
|
||||
|
||||
QUALCOMM CAMERA SUBSYSTEM DRIVER
|
||||
M: Robert Foss <robert.foss@linaro.org>
|
||||
M: Robert Foss <rfoss@kernel.org>
|
||||
M: Todor Tomov <todor.too@gmail.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Maintained
|
||||
|
|
@ -17309,7 +17326,7 @@ F: drivers/dma/qcom/hidma*
|
|||
|
||||
QUALCOMM I2C CCI DRIVER
|
||||
M: Loic Poulain <loic.poulain@linaro.org>
|
||||
M: Robert Foss <robert.foss@linaro.org>
|
||||
M: Robert Foss <rfoss@kernel.org>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
|
|
@ -17948,6 +17965,7 @@ M: Albert Ou <aou@eecs.berkeley.edu>
|
|||
L: linux-riscv@lists.infradead.org
|
||||
S: Supported
|
||||
Q: https://patchwork.kernel.org/project/linux-riscv/list/
|
||||
C: irc://irc.libera.chat/riscv
|
||||
P: Documentation/riscv/patch-acceptance.rst
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
|
||||
F: arch/riscv/
|
||||
|
|
@ -19317,6 +19335,13 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
|||
S: Orphan
|
||||
F: sound/soc/uniphier/
|
||||
|
||||
SOCKET TIMESTAMPING
|
||||
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
|
||||
S: Maintained
|
||||
F: Documentation/networking/timestamping.rst
|
||||
F: include/uapi/linux/net_tstamp.h
|
||||
F: tools/testing/selftests/net/so_txtime.c
|
||||
|
||||
SOEKRIS NET48XX LED SUPPORT
|
||||
M: Chris Boot <bootc@bootc.net>
|
||||
S: Maintained
|
||||
|
|
@ -19664,7 +19689,7 @@ F: drivers/clk/spear/
|
|||
F: drivers/pinctrl/spear/
|
||||
|
||||
SPI NOR SUBSYSTEM
|
||||
M: Tudor Ambarus <tudor.ambarus@microchip.com>
|
||||
M: Tudor Ambarus <tudor.ambarus@linaro.org>
|
||||
M: Pratyush Yadav <pratyush@kernel.org>
|
||||
R: Michael Walle <michael@walle.cc>
|
||||
L: linux-mtd@lists.infradead.org
|
||||
|
|
@ -21737,6 +21762,13 @@ T: git git://linuxtv.org/media_tree.git
|
|||
F: Documentation/admin-guide/media/zr364xx*
|
||||
F: drivers/staging/media/deprecated/zr364xx/
|
||||
|
||||
USER DATAGRAM PROTOCOL (UDP)
|
||||
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
|
||||
S: Maintained
|
||||
F: include/linux/udp.h
|
||||
F: net/ipv4/udp.c
|
||||
F: net/ipv6/udp.c
|
||||
|
||||
USER-MODE LINUX (UML)
|
||||
M: Richard Weinberger <richard@nod.at>
|
||||
M: Anton Ivanov <anton.ivanov@cambridgegreys.com>
|
||||
|
|
@ -22245,7 +22277,9 @@ F: drivers/scsi/vmw_pvscsi.c
|
|||
F: drivers/scsi/vmw_pvscsi.h
|
||||
|
||||
VMWARE VIRTUAL PTP CLOCK DRIVER
|
||||
M: Vivek Thampi <vithampi@vmware.com>
|
||||
M: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
|
||||
M: Deep Shah <sdeep@vmware.com>
|
||||
R: Alexey Makhalov <amakhalov@vmware.com>
|
||||
R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
|
|||
21
Makefile
21
Makefile
|
|
@ -2,7 +2,7 @@
|
|||
VERSION = 6
|
||||
PATCHLEVEL = 2
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc6
|
||||
NAME = Hurr durr I'ma ninja sloth
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -297,7 +297,7 @@ no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
|
|||
headers_install modules_install kernelrelease image_name
|
||||
no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \
|
||||
image_name
|
||||
single-targets := %.a %.i %.rsi %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
|
||||
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.rsi %.s %.symtypes %/
|
||||
|
||||
config-build :=
|
||||
mixed-build :=
|
||||
|
|
@ -549,7 +549,7 @@ LDFLAGS_MODULE =
|
|||
CFLAGS_KERNEL =
|
||||
RUSTFLAGS_KERNEL =
|
||||
AFLAGS_KERNEL =
|
||||
export LDFLAGS_vmlinux =
|
||||
LDFLAGS_vmlinux =
|
||||
|
||||
# Use USERINCLUDE when you must reference the UAPI directories only.
|
||||
USERINCLUDE := \
|
||||
|
|
@ -1248,6 +1248,18 @@ vmlinux.o modules.builtin.modinfo modules.builtin: vmlinux_o
|
|||
@:
|
||||
|
||||
PHONY += vmlinux
|
||||
# LDFLAGS_vmlinux in the top Makefile defines linker flags for the top vmlinux,
|
||||
# not for decompressors. LDFLAGS_vmlinux in arch/*/boot/compressed/Makefile is
|
||||
# unrelated; the decompressors just happen to have the same base name,
|
||||
# arch/*/boot/compressed/vmlinux.
|
||||
# Export LDFLAGS_vmlinux only to scripts/Makefile.vmlinux.
|
||||
#
|
||||
# _LDFLAGS_vmlinux is a workaround for the 'private export' bug:
|
||||
# https://savannah.gnu.org/bugs/?61463
|
||||
# For Make > 4.4, the following simple code will work:
|
||||
# vmlinux: private export LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
|
||||
vmlinux: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
|
||||
vmlinux: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
|
||||
vmlinux: vmlinux.o $(KBUILD_LDS) modpost
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux
|
||||
|
||||
|
|
@ -1533,6 +1545,7 @@ endif
|
|||
# *.ko are usually independent of vmlinux, but CONFIG_DEBUG_INFOBTF_MODULES
|
||||
# is an exception.
|
||||
ifdef CONFIG_DEBUG_INFO_BTF_MODULES
|
||||
KBUILD_BUILTIN := 1
|
||||
modules: vmlinux
|
||||
endif
|
||||
|
||||
|
|
@ -1986,7 +1999,7 @@ $(single-no-ko): $(build-dir)
|
|||
# Remove MODORDER when done because it is not the real one.
|
||||
PHONY += single_modules
|
||||
single_modules: $(single-no-ko) modules_prepare
|
||||
$(Q){ $(foreach m, $(single-ko), echo $(extmod_prefix)$m;) } > $(MODORDER)
|
||||
$(Q){ $(foreach m, $(single-ko), echo $(extmod_prefix)$(m:%.ko=%.o);) } > $(MODORDER)
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
||||
ifneq ($(KBUILD_MODPOST_NOFINAL),1)
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modfinal
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
|
|||
|
||||
ifeq ($(CONFIG_THUMB2_KERNEL),y)
|
||||
CFLAGS_ISA :=-Wa,-mimplicit-it=always $(AFLAGS_NOWARN)
|
||||
AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb -D__thumb2__=2
|
||||
AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb
|
||||
CFLAGS_ISA +=-mthumb
|
||||
else
|
||||
CFLAGS_ISA :=$(call cc-option,-marm,) $(AFLAGS_NOWARN)
|
||||
|
|
|
|||
|
|
@ -304,7 +304,7 @@
|
|||
};
|
||||
|
||||
gpio0: gpio@18100 {
|
||||
compatible = "marvell,armadaxp-gpio",
|
||||
compatible = "marvell,armada-370-gpio",
|
||||
"marvell,orion-gpio";
|
||||
reg = <0x18100 0x40>, <0x181c0 0x08>;
|
||||
reg-names = "gpio", "pwm";
|
||||
|
|
@ -323,7 +323,7 @@
|
|||
};
|
||||
|
||||
gpio1: gpio@18140 {
|
||||
compatible = "marvell,armadaxp-gpio",
|
||||
compatible = "marvell,armada-370-gpio",
|
||||
"marvell,orion-gpio";
|
||||
reg = <0x18140 0x40>, <0x181c8 0x08>;
|
||||
reg-names = "gpio", "pwm";
|
||||
|
|
|
|||
|
|
@ -213,7 +213,7 @@
|
|||
};
|
||||
|
||||
gpio0: gpio@18100 {
|
||||
compatible = "marvell,armadaxp-gpio", "marvell,orion-gpio";
|
||||
compatible = "marvell,orion-gpio";
|
||||
reg = <0x18100 0x40>;
|
||||
ngpios = <32>;
|
||||
gpio-controller;
|
||||
|
|
@ -227,7 +227,7 @@
|
|||
};
|
||||
|
||||
gpio1: gpio@18140 {
|
||||
compatible = "marvell,armadaxp-gpio", "marvell,orion-gpio";
|
||||
compatible = "marvell,orion-gpio";
|
||||
reg = <0x18140 0x40>;
|
||||
ngpios = <28>;
|
||||
gpio-controller;
|
||||
|
|
|
|||
|
|
@ -488,7 +488,7 @@
|
|||
scl-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
|
||||
status = "okay";
|
||||
|
||||
i2c-switch@70 {
|
||||
i2c-mux@70 {
|
||||
compatible = "nxp,pca9547";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -632,7 +632,6 @@
|
|||
&uart1 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_uart1>;
|
||||
uart-has-rtscts;
|
||||
rts-gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>;
|
||||
status = "okay";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
};
|
||||
|
||||
&i2c2 {
|
||||
clock_frequency = <100000>;
|
||||
clock-frequency = <100000>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_i2c2>;
|
||||
status = "okay";
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
};
|
||||
|
||||
&i2c1 {
|
||||
clock_frequency = <100000>;
|
||||
clock-frequency = <100000>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_i2c1>;
|
||||
status = "okay";
|
||||
|
|
@ -52,7 +52,7 @@
|
|||
};
|
||||
|
||||
&i2c4 {
|
||||
clock_frequency = <100000>;
|
||||
clock-frequency = <100000>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_i2c1>;
|
||||
status = "okay";
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@
|
|||
};
|
||||
|
||||
&i2c1 {
|
||||
clock_frequency = <100000>;
|
||||
clock-frequency = <100000>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_i2c1>;
|
||||
status = "okay";
|
||||
|
|
@ -64,7 +64,7 @@
|
|||
};
|
||||
|
||||
&i2c2 {
|
||||
clock_frequency = <100000>;
|
||||
clock-frequency = <100000>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_i2c2>;
|
||||
status = "okay";
|
||||
|
|
|
|||
|
|
@ -19,16 +19,16 @@
|
|||
serial@f995e000 {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
sdhci@f9824900 {
|
||||
bus-width = <8>;
|
||||
non-removable;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
sdhci@f98a4900 {
|
||||
cd-gpios = <&tlmm 122 GPIO_ACTIVE_LOW>;
|
||||
bus-width = <4>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
&sdhc_1 {
|
||||
bus-width = <8>;
|
||||
non-removable;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&sdhc_2 {
|
||||
cd-gpios = <&tlmm 122 GPIO_ACTIVE_LOW>;
|
||||
bus-width = <4>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -421,7 +421,7 @@
|
|||
status = "disabled";
|
||||
};
|
||||
|
||||
mmc@f9824900 {
|
||||
sdhc_1: mmc@f9824900 {
|
||||
compatible = "qcom,apq8084-sdhci", "qcom,sdhci-msm-v4";
|
||||
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
|
||||
reg-names = "hc", "core";
|
||||
|
|
@ -434,7 +434,7 @@
|
|||
status = "disabled";
|
||||
};
|
||||
|
||||
mmc@f98a4900 {
|
||||
sdhc_2: mmc@f98a4900 {
|
||||
compatible = "qcom,apq8084-sdhci", "qcom,sdhci-msm-v4";
|
||||
reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
|
||||
reg-names = "hc", "core";
|
||||
|
|
|
|||
|
|
@ -564,7 +564,7 @@
|
|||
mpddrc: mpddrc@ffffe800 {
|
||||
compatible = "microchip,sam9x60-ddramc", "atmel,sama5d3-ddramc";
|
||||
reg = <0xffffe800 0x200>;
|
||||
clocks = <&pmc PMC_TYPE_SYSTEM 2>, <&pmc PMC_TYPE_CORE PMC_MCK>;
|
||||
clocks = <&pmc PMC_TYPE_SYSTEM 2>, <&pmc PMC_TYPE_PERIPHERAL 49>;
|
||||
clock-names = "ddrck", "mpddr";
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -101,8 +101,12 @@
|
|||
|
||||
&qspi {
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a>;
|
||||
pinctrl-0 = <&qspi_clk_pins_a
|
||||
&qspi_bk1_pins_a
|
||||
&qspi_cs1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a
|
||||
&qspi_bk1_sleep_pins_a
|
||||
&qspi_cs1_sleep_pins_a>;
|
||||
reg = <0x58003000 0x1000>, <0x70000000 0x4000000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -391,8 +391,12 @@
|
|||
|
||||
&qspi {
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a>;
|
||||
pinctrl-0 = <&qspi_clk_pins_a
|
||||
&qspi_bk1_pins_a
|
||||
&qspi_cs1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a
|
||||
&qspi_bk1_sleep_pins_a
|
||||
&qspi_cs1_sleep_pins_a>;
|
||||
reg = <0x58003000 0x1000>, <0x70000000 0x4000000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -428,8 +428,12 @@
|
|||
|
||||
&qspi {
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a>;
|
||||
pinctrl-0 = <&qspi_clk_pins_a
|
||||
&qspi_bk1_pins_a
|
||||
&qspi_cs1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a
|
||||
&qspi_bk1_sleep_pins_a
|
||||
&qspi_cs1_sleep_pins_a>;
|
||||
reg = <0x58003000 0x1000>, <0x70000000 0x4000000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -247,8 +247,12 @@
|
|||
|
||||
&qspi {
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a>;
|
||||
pinctrl-0 = <&qspi_clk_pins_a
|
||||
&qspi_bk1_pins_a
|
||||
&qspi_cs1_pins_a>;
|
||||
pinctrl-1 = <&qspi_clk_sleep_pins_a
|
||||
&qspi_bk1_sleep_pins_a
|
||||
&qspi_cs1_sleep_pins_a>;
|
||||
reg = <0x58003000 0x1000>, <0x70000000 0x200000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -345,7 +345,7 @@
|
|||
};
|
||||
|
||||
&i2c2 {
|
||||
tca9548@70 {
|
||||
i2c-mux@70 {
|
||||
compatible = "nxp,pca9548";
|
||||
pinctrl-0 = <&pinctrl_i2c_mux_reset>;
|
||||
pinctrl-names = "default";
|
||||
|
|
|
|||
|
|
@ -340,7 +340,7 @@
|
|||
};
|
||||
|
||||
&i2c2 {
|
||||
tca9548@70 {
|
||||
i2c-mux@70 {
|
||||
compatible = "nxp,pca9548";
|
||||
pinctrl-0 = <&pinctrl_i2c_mux_reset>;
|
||||
pinctrl-names = "default";
|
||||
|
|
|
|||
|
|
@ -53,7 +53,12 @@ $(obj)/%-core.S: $(src)/%-armv4.pl
|
|||
|
||||
clean-files += poly1305-core.S sha256-core.S sha512-core.S
|
||||
|
||||
aflags-thumb2-$(CONFIG_THUMB2_KERNEL) := -U__thumb2__ -D__thumb2__=1
|
||||
|
||||
AFLAGS_sha256-core.o += $(aflags-thumb2-y)
|
||||
AFLAGS_sha512-core.o += $(aflags-thumb2-y)
|
||||
|
||||
# massage the perlasm code a bit so we only get the NEON routine if we need it
|
||||
poly1305-aflags-$(CONFIG_CPU_V7) := -U__LINUX_ARM_ARCH__ -D__LINUX_ARM_ARCH__=5
|
||||
poly1305-aflags-$(CONFIG_KERNEL_MODE_NEON) := -U__LINUX_ARM_ARCH__ -D__LINUX_ARM_ARCH__=7
|
||||
AFLAGS_poly1305-core.o += $(poly1305-aflags-y)
|
||||
AFLAGS_poly1305-core.o += $(poly1305-aflags-y) $(aflags-thumb2-y)
|
||||
|
|
|
|||
|
|
@ -128,15 +128,16 @@ extern int vfp_restore_user_hwstate(struct user_vfp *,
|
|||
#define TIF_NEED_RESCHED 1 /* rescheduling necessary */
|
||||
#define TIF_NOTIFY_RESUME 2 /* callback before returning to user */
|
||||
#define TIF_UPROBE 3 /* breakpointed or singlestepping */
|
||||
#define TIF_SYSCALL_TRACE 4 /* syscall trace active */
|
||||
#define TIF_SYSCALL_AUDIT 5 /* syscall auditing active */
|
||||
#define TIF_SYSCALL_TRACEPOINT 6 /* syscall tracepoint instrumentation */
|
||||
#define TIF_SECCOMP 7 /* seccomp syscall filtering active */
|
||||
#define TIF_NOTIFY_SIGNAL 8 /* signal notifications exist */
|
||||
#define TIF_NOTIFY_SIGNAL 4 /* signal notifications exist */
|
||||
|
||||
#define TIF_USING_IWMMXT 17
|
||||
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
|
||||
#define TIF_RESTORE_SIGMASK 20
|
||||
#define TIF_RESTORE_SIGMASK 19
|
||||
#define TIF_SYSCALL_TRACE 20 /* syscall trace active */
|
||||
#define TIF_SYSCALL_AUDIT 21 /* syscall auditing active */
|
||||
#define TIF_SYSCALL_TRACEPOINT 22 /* syscall tracepoint instrumentation */
|
||||
#define TIF_SECCOMP 23 /* seccomp syscall filtering active */
|
||||
|
||||
|
||||
#define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
|
||||
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
|
||||
|
|
|
|||
|
|
@ -20,7 +20,6 @@
|
|||
|
||||
#include <linux/init.h>
|
||||
#include <linux/mc146818rtc.h>
|
||||
#include <linux/bcd.h>
|
||||
#include <linux/io.h>
|
||||
|
||||
#include "common.h"
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ static int mx25_read_cpu_rev(void)
|
|||
|
||||
np = of_find_compatible_node(NULL, NULL, "fsl,imx25-iim");
|
||||
iim_base = of_iomap(np, 0);
|
||||
of_node_put(np);
|
||||
BUG_ON(!iim_base);
|
||||
rev = readl(iim_base + MXC_IIMSREV);
|
||||
iounmap(iim_base);
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@ static int mx27_read_cpu_rev(void)
|
|||
|
||||
np = of_find_compatible_node(NULL, NULL, "fsl,imx27-ccm");
|
||||
ccm_base = of_iomap(np, 0);
|
||||
of_node_put(np);
|
||||
BUG_ON(!ccm_base);
|
||||
/*
|
||||
* now we have access to the IO registers. As we need
|
||||
|
|
|
|||
|
|
@ -39,6 +39,7 @@ static int mx31_read_cpu_rev(void)
|
|||
|
||||
np = of_find_compatible_node(NULL, NULL, "fsl,imx31-iim");
|
||||
iim_base = of_iomap(np, 0);
|
||||
of_node_put(np);
|
||||
BUG_ON(!iim_base);
|
||||
|
||||
/* read SREV register from IIM module */
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ static int mx35_read_cpu_rev(void)
|
|||
|
||||
np = of_find_compatible_node(NULL, NULL, "fsl,imx35-iim");
|
||||
iim_base = of_iomap(np, 0);
|
||||
of_node_put(np);
|
||||
BUG_ON(!iim_base);
|
||||
|
||||
rev = imx_readl(iim_base + MXC_IIMSREV);
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@ static u32 imx5_read_srev_reg(const char *compat)
|
|||
|
||||
np = of_find_compatible_node(NULL, NULL, compat);
|
||||
iim_base = of_iomap(np, 0);
|
||||
of_node_put(np);
|
||||
WARN_ON(!iim_base);
|
||||
|
||||
srev = readl(iim_base + IIM_SREV) & 0xff;
|
||||
|
|
|
|||
|
|
@ -4,6 +4,7 @@ menuconfig ARCH_OMAP1
|
|||
depends on ARCH_MULTI_V4T || ARCH_MULTI_V5
|
||||
depends on CPU_LITTLE_ENDIAN
|
||||
depends on ATAGS
|
||||
select ARCH_OMAP
|
||||
select ARCH_HAS_HOLES_MEMORYMODEL
|
||||
select ARCH_OMAP
|
||||
select CLKSRC_MMIO
|
||||
|
|
@ -45,10 +46,6 @@ config ARCH_OMAP16XX
|
|||
select CPU_ARM926T
|
||||
select OMAP_DM_TIMER
|
||||
|
||||
config ARCH_OMAP1_ANY
|
||||
select ARCH_OMAP
|
||||
def_bool ARCH_OMAP730 || ARCH_OMAP850 || ARCH_OMAP15XX || ARCH_OMAP16XX
|
||||
|
||||
config ARCH_OMAP
|
||||
bool
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
# Makefile for the linux kernel.
|
||||
#
|
||||
|
||||
ifdef CONFIG_ARCH_OMAP1_ANY
|
||||
|
||||
# Common support
|
||||
obj-y := io.o id.o sram-init.o sram.o time.o irq.o mux.o flash.o \
|
||||
serial.o devices.o dma.o omap-dma.o fb.o
|
||||
|
|
@ -59,5 +57,3 @@ obj-$(CONFIG_ARCH_OMAP730) += gpio7xx.o
|
|||
obj-$(CONFIG_ARCH_OMAP850) += gpio7xx.o
|
||||
obj-$(CONFIG_ARCH_OMAP15XX) += gpio15xx.o
|
||||
obj-$(CONFIG_ARCH_OMAP16XX) += gpio16xx.o
|
||||
|
||||
endif
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@
|
|||
#include <linux/gpio.h>
|
||||
#include <linux/platform_data/gpio-omap.h>
|
||||
#include <linux/soc/ti/omap1-soc.h>
|
||||
#include <asm/irq.h>
|
||||
|
||||
#include "irqs.h"
|
||||
|
||||
|
|
|
|||
|
|
@ -22,17 +22,14 @@
|
|||
* The machine specific code may provide the extra mapping besides the
|
||||
* default mapping provided here.
|
||||
*/
|
||||
static struct map_desc omap_io_desc[] __initdata = {
|
||||
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
|
||||
static struct map_desc omap7xx_io_desc[] __initdata = {
|
||||
{
|
||||
.virtual = OMAP1_IO_VIRT,
|
||||
.pfn = __phys_to_pfn(OMAP1_IO_PHYS),
|
||||
.length = OMAP1_IO_SIZE,
|
||||
.type = MT_DEVICE
|
||||
}
|
||||
};
|
||||
|
||||
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
|
||||
static struct map_desc omap7xx_io_desc[] __initdata = {
|
||||
},
|
||||
{
|
||||
.virtual = OMAP7XX_DSP_BASE,
|
||||
.pfn = __phys_to_pfn(OMAP7XX_DSP_START),
|
||||
|
|
@ -49,6 +46,12 @@ static struct map_desc omap7xx_io_desc[] __initdata = {
|
|||
|
||||
#ifdef CONFIG_ARCH_OMAP15XX
|
||||
static struct map_desc omap1510_io_desc[] __initdata = {
|
||||
{
|
||||
.virtual = OMAP1_IO_VIRT,
|
||||
.pfn = __phys_to_pfn(OMAP1_IO_PHYS),
|
||||
.length = OMAP1_IO_SIZE,
|
||||
.type = MT_DEVICE
|
||||
},
|
||||
{
|
||||
.virtual = OMAP1510_DSP_BASE,
|
||||
.pfn = __phys_to_pfn(OMAP1510_DSP_START),
|
||||
|
|
@ -65,6 +68,12 @@ static struct map_desc omap1510_io_desc[] __initdata = {
|
|||
|
||||
#if defined(CONFIG_ARCH_OMAP16XX)
|
||||
static struct map_desc omap16xx_io_desc[] __initdata = {
|
||||
{
|
||||
.virtual = OMAP1_IO_VIRT,
|
||||
.pfn = __phys_to_pfn(OMAP1_IO_PHYS),
|
||||
.length = OMAP1_IO_SIZE,
|
||||
.type = MT_DEVICE
|
||||
},
|
||||
{
|
||||
.virtual = OMAP16XX_DSP_BASE,
|
||||
.pfn = __phys_to_pfn(OMAP16XX_DSP_START),
|
||||
|
|
@ -79,18 +88,9 @@ static struct map_desc omap16xx_io_desc[] __initdata = {
|
|||
};
|
||||
#endif
|
||||
|
||||
/*
|
||||
* Maps common IO regions for omap1
|
||||
*/
|
||||
static void __init omap1_map_common_io(void)
|
||||
{
|
||||
iotable_init(omap_io_desc, ARRAY_SIZE(omap_io_desc));
|
||||
}
|
||||
|
||||
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
|
||||
void __init omap7xx_map_io(void)
|
||||
{
|
||||
omap1_map_common_io();
|
||||
iotable_init(omap7xx_io_desc, ARRAY_SIZE(omap7xx_io_desc));
|
||||
}
|
||||
#endif
|
||||
|
|
@ -98,7 +98,6 @@ void __init omap7xx_map_io(void)
|
|||
#ifdef CONFIG_ARCH_OMAP15XX
|
||||
void __init omap15xx_map_io(void)
|
||||
{
|
||||
omap1_map_common_io();
|
||||
iotable_init(omap1510_io_desc, ARRAY_SIZE(omap1510_io_desc));
|
||||
}
|
||||
#endif
|
||||
|
|
@ -106,7 +105,6 @@ void __init omap15xx_map_io(void)
|
|||
#if defined(CONFIG_ARCH_OMAP16XX)
|
||||
void __init omap16xx_map_io(void)
|
||||
{
|
||||
omap1_map_common_io();
|
||||
iotable_init(omap16xx_io_desc, ARRAY_SIZE(omap16xx_io_desc));
|
||||
}
|
||||
#endif
|
||||
|
|
|
|||
|
|
@ -89,7 +89,6 @@ static struct omap_mcbsp_ops omap1_mcbsp_ops = {
|
|||
#define OMAP1610_MCBSP2_BASE 0xfffb1000
|
||||
#define OMAP1610_MCBSP3_BASE 0xe1017000
|
||||
|
||||
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
|
||||
struct resource omap7xx_mcbsp_res[][6] = {
|
||||
{
|
||||
{
|
||||
|
|
@ -159,14 +158,7 @@ static struct omap_mcbsp_platform_data omap7xx_mcbsp_pdata[] = {
|
|||
};
|
||||
#define OMAP7XX_MCBSP_RES_SZ ARRAY_SIZE(omap7xx_mcbsp_res[1])
|
||||
#define OMAP7XX_MCBSP_COUNT ARRAY_SIZE(omap7xx_mcbsp_res)
|
||||
#else
|
||||
#define omap7xx_mcbsp_res_0 NULL
|
||||
#define omap7xx_mcbsp_pdata NULL
|
||||
#define OMAP7XX_MCBSP_RES_SZ 0
|
||||
#define OMAP7XX_MCBSP_COUNT 0
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_ARCH_OMAP15XX
|
||||
struct resource omap15xx_mcbsp_res[][6] = {
|
||||
{
|
||||
{
|
||||
|
|
@ -266,14 +258,7 @@ static struct omap_mcbsp_platform_data omap15xx_mcbsp_pdata[] = {
|
|||
};
|
||||
#define OMAP15XX_MCBSP_RES_SZ ARRAY_SIZE(omap15xx_mcbsp_res[1])
|
||||
#define OMAP15XX_MCBSP_COUNT ARRAY_SIZE(omap15xx_mcbsp_res)
|
||||
#else
|
||||
#define omap15xx_mcbsp_res_0 NULL
|
||||
#define omap15xx_mcbsp_pdata NULL
|
||||
#define OMAP15XX_MCBSP_RES_SZ 0
|
||||
#define OMAP15XX_MCBSP_COUNT 0
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_ARCH_OMAP16XX
|
||||
struct resource omap16xx_mcbsp_res[][6] = {
|
||||
{
|
||||
{
|
||||
|
|
@ -373,12 +358,6 @@ static struct omap_mcbsp_platform_data omap16xx_mcbsp_pdata[] = {
|
|||
};
|
||||
#define OMAP16XX_MCBSP_RES_SZ ARRAY_SIZE(omap16xx_mcbsp_res[1])
|
||||
#define OMAP16XX_MCBSP_COUNT ARRAY_SIZE(omap16xx_mcbsp_res)
|
||||
#else
|
||||
#define omap16xx_mcbsp_res_0 NULL
|
||||
#define omap16xx_mcbsp_pdata NULL
|
||||
#define OMAP16XX_MCBSP_RES_SZ 0
|
||||
#define OMAP16XX_MCBSP_COUNT 0
|
||||
#endif
|
||||
|
||||
static void omap_mcbsp_register_board_cfg(struct resource *res, int res_count,
|
||||
struct omap_mcbsp_platform_data *config, int size)
|
||||
|
|
|
|||
|
|
@ -106,13 +106,6 @@
|
|||
#define OMAP7XX_IDLECT3 0xfffece24
|
||||
#define OMAP7XX_IDLE_LOOP_REQUEST 0x0C00
|
||||
|
||||
#if !defined(CONFIG_ARCH_OMAP730) && \
|
||||
!defined(CONFIG_ARCH_OMAP850) && \
|
||||
!defined(CONFIG_ARCH_OMAP15XX) && \
|
||||
!defined(CONFIG_ARCH_OMAP16XX)
|
||||
#warning "Power management for this processor not implemented yet"
|
||||
#endif
|
||||
|
||||
#ifndef __ASSEMBLER__
|
||||
|
||||
#include <linux/clk.h>
|
||||
|
|
|
|||
|
|
@ -45,6 +45,8 @@ config MACH_PXA27X_DT
|
|||
config MACH_PXA3XX_DT
|
||||
bool "Support PXA3xx platforms from device tree"
|
||||
select CPU_PXA300
|
||||
select CPU_PXA310
|
||||
select CPU_PXA320
|
||||
select PINCTRL
|
||||
select POWER_SUPPLY
|
||||
select PXA3xx
|
||||
|
|
|
|||
|
|
@ -161,7 +161,7 @@ void __init paging_init(const struct machine_desc *mdesc)
|
|||
mpu_setup();
|
||||
|
||||
/* allocate the zero page. */
|
||||
zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
|
||||
zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
|
||||
if (!zero_page)
|
||||
panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
|
||||
__func__, PAGE_SIZE, PAGE_SIZE);
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@
|
|||
* VM_EXEC
|
||||
*/
|
||||
#include <asm/asm-offsets.h>
|
||||
#include <asm/pgtable.h>
|
||||
#include <asm/thread_info.h>
|
||||
|
||||
#ifdef CONFIG_CPU_V7M
|
||||
|
|
|
|||
|
|
@ -184,8 +184,6 @@ config ARM64
|
|||
select HAVE_DEBUG_KMEMLEAK
|
||||
select HAVE_DMA_CONTIGUOUS
|
||||
select HAVE_DYNAMIC_FTRACE
|
||||
select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
|
||||
if $(cc-option,-fpatchable-function-entry=2)
|
||||
select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
|
||||
if DYNAMIC_FTRACE_WITH_ARGS
|
||||
select HAVE_EFFICIENT_UNALIGNED_ACCESS
|
||||
|
|
@ -972,6 +970,22 @@ config ARM64_ERRATUM_2457168
|
|||
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_2645198
|
||||
bool "Cortex-A715: 2645198: Workaround possible [ESR|FAR]_ELx corruption"
|
||||
default y
|
||||
help
|
||||
This option adds the workaround for ARM Cortex-A715 erratum 2645198.
|
||||
|
||||
If a Cortex-A715 cpu sees a page mapping permissions change from executable
|
||||
to non-executable, it may corrupt the ESR_ELx and FAR_ELx registers on the
|
||||
next instruction abort caused by permission fault.
|
||||
|
||||
Only user-space does executable to non-executable permission transition via
|
||||
mprotect() system call. Workaround the problem by doing a break-before-make
|
||||
TLB invalidation, for all changes to executable user space mappings.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
config CAVIUM_ERRATUM_22375
|
||||
bool "Cavium erratum 22375, 24313"
|
||||
default y
|
||||
|
|
|
|||
|
|
@ -131,10 +131,6 @@
|
|||
};
|
||||
|
||||
&usb {
|
||||
phys = <&usb2_phy1>;
|
||||
phy-names = "usb2-phy1";
|
||||
};
|
||||
|
||||
&usb2_phy0 {
|
||||
status = "disabled";
|
||||
phys = <&usb2_phy0>, <&usb2_phy1>;
|
||||
phy-names = "usb2-phy0", "usb2-phy1";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@
|
|||
&i2c0 {
|
||||
status = "okay";
|
||||
|
||||
pca9547@77 {
|
||||
i2c-mux@77 {
|
||||
compatible = "nxp,pca9547";
|
||||
reg = <0x77>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@
|
|||
&i2c0 {
|
||||
status = "okay";
|
||||
|
||||
pca9547@77 {
|
||||
i2c-mux@77 {
|
||||
compatible = "nxp,pca9547";
|
||||
reg = <0x77>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@
|
|||
&i2c0 {
|
||||
status = "okay";
|
||||
|
||||
pca9547@77 {
|
||||
i2c-mux@77 {
|
||||
compatible = "nxp,pca9547";
|
||||
reg = <0x77>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@
|
|||
&i2c0 {
|
||||
status = "okay";
|
||||
|
||||
i2c-switch@77 {
|
||||
i2c-mux@77 {
|
||||
compatible = "nxp,pca9547";
|
||||
reg = <0x77>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@
|
|||
&i2c0 {
|
||||
status = "okay";
|
||||
|
||||
i2c-switch@77 {
|
||||
i2c-mux@77 {
|
||||
compatible = "nxp,pca9547";
|
||||
reg = <0x77>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -245,7 +245,7 @@
|
|||
&i2c3 {
|
||||
status = "okay";
|
||||
|
||||
i2c-switch@70 {
|
||||
i2c-mux@70 {
|
||||
compatible = "nxp,pca9540";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@
|
|||
|
||||
&i2c0 {
|
||||
status = "okay";
|
||||
pca9547@77 {
|
||||
i2c-mux@77 {
|
||||
compatible = "nxp,pca9547";
|
||||
reg = <0x77>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@
|
|||
|
||||
&i2c0 {
|
||||
status = "okay";
|
||||
pca9547@75 {
|
||||
i2c-mux@75 {
|
||||
compatible = "nxp,pca9547";
|
||||
reg = <0x75>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@
|
|||
&i2c0 {
|
||||
status = "okay";
|
||||
|
||||
i2c-switch@77 {
|
||||
i2c-mux@77 {
|
||||
compatible = "nxp,pca9547";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@
|
|||
&ecspi2 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_espi2>;
|
||||
cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
|
||||
cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
|
||||
status = "okay";
|
||||
|
||||
eeprom@0 {
|
||||
|
|
@ -316,7 +316,7 @@
|
|||
MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0x82
|
||||
MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI 0x82
|
||||
MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO 0x82
|
||||
MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x41
|
||||
MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0x41
|
||||
>;
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -275,7 +275,7 @@
|
|||
compatible = "rohm,bd71847";
|
||||
reg = <0x4b>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&clk_xtal32k 0>;
|
||||
clocks = <&clk_xtal32k>;
|
||||
clock-output-names = "clk-32k-out";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@
|
|||
pinctrl-0 = <&pinctrl_i2c3>;
|
||||
status = "okay";
|
||||
|
||||
i2cmux@70 {
|
||||
i2c-mux@70 {
|
||||
compatible = "nxp,pca9540";
|
||||
reg = <0x70>;
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -771,6 +771,7 @@
|
|||
&usbotg2 {
|
||||
dr_mode = "host";
|
||||
vbus-supply = <®_usb2_vbus>;
|
||||
over-current-active-low;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
simple-audio-card,bitclock-master = <&dailink_master>;
|
||||
simple-audio-card,format = "i2s";
|
||||
simple-audio-card,frame-master = <&dailink_master>;
|
||||
simple-audio-card,mclk-fs = <256>;
|
||||
simple-audio-card,name = "imx8mm-wm8904";
|
||||
simple-audio-card,routing =
|
||||
"Headphone Jack", "HPOUTL",
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue