Merge branch 'topic/apple-gmux' into for-next
Pull vga_switcheroo fix for Macs Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is contained in:
Takashi Iwai
commit
5661706efa
4
.mailmap
4
.mailmap
|
|
@ -130,6 +130,7 @@ Domen Puncer <domen@coderock.org>
|
|||
Douglas Gilbert <dougg@torque.net>
|
||||
Ed L. Cashin <ecashin@coraid.com>
|
||||
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
|
||||
Eugen Hristev <eugen.hristev@collabora.com> <eugen.hristev@microchip.com>
|
||||
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
|
||||
Felipe W Damasio <felipewd@terra.com.br>
|
||||
|
|
@ -214,6 +215,7 @@ Jisheng Zhang <jszhang@kernel.org> <jszhang@marvell.com>
|
|||
Jisheng Zhang <jszhang@kernel.org> <Jisheng.Zhang@synaptics.com>
|
||||
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||
Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
|
||||
John Crispin <john@phrozen.org> <blogic@openwrt.org>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
John Stultz <johnstul@us.ibm.com>
|
||||
Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
|
||||
|
|
@ -371,6 +373,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 +425,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>
|
||||
|
|
|
|||
15
CREDITS
15
CREDITS
|
|
@ -1173,6 +1173,10 @@ D: Future Domain TMC-16x0 SCSI driver (author)
|
|||
D: APM driver (early port)
|
||||
D: DRM drivers (author of several)
|
||||
|
||||
N: Veaceslav Falico
|
||||
E: vfalico@gmail.com
|
||||
D: Co-maintainer and co-author of the network bonding driver.
|
||||
|
||||
N: János Farkas
|
||||
E: chexum@shadow.banki.hu
|
||||
D: romfs, various (mostly networking) fixes
|
||||
|
|
@ -2489,6 +2493,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
|
||||
|
|
@ -4172,6 +4183,10 @@ S: B-1206 Jingmao Guojigongyu
|
|||
S: 16 Baliqiao Nanjie, Beijing 101100
|
||||
S: People's Repulic of China
|
||||
|
||||
N: Vlad Yasevich
|
||||
E: vyasevich@gmail.com
|
||||
D: SCTP protocol maintainer.
|
||||
|
||||
N: Aviad Yehezkel
|
||||
E: aviadye@nvidia.com
|
||||
D: Kernel TLS implementation and offload support.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -1245,13 +1245,17 @@ PAGE_SIZE multiple when read back.
|
|||
This is a simple interface to trigger memory reclaim in the
|
||||
target cgroup.
|
||||
|
||||
This file accepts a string which contains the number of bytes to
|
||||
reclaim.
|
||||
This file accepts a single key, the number of bytes to reclaim.
|
||||
No nested keys are currently supported.
|
||||
|
||||
Example::
|
||||
|
||||
echo "1G" > memory.reclaim
|
||||
|
||||
The interface can be later extended with nested keys to
|
||||
configure the reclaim behavior. For example, specify the
|
||||
type of memory to reclaim from (anon, file, ..).
|
||||
|
||||
Please note that the kernel can over or under reclaim from
|
||||
the target cgroup. If less bytes are reclaimed than the
|
||||
specified amount, -EAGAIN is returned.
|
||||
|
|
@ -1263,13 +1267,6 @@ PAGE_SIZE multiple when read back.
|
|||
This means that the networking layer will not adapt based on
|
||||
reclaim induced by memory.reclaim.
|
||||
|
||||
This file also allows the user to specify the nodes to reclaim from,
|
||||
via the 'nodes=' key, for example::
|
||||
|
||||
echo "1G nodes=0,1" > memory.reclaim
|
||||
|
||||
The above instructs the kernel to reclaim memory from nodes 0,1.
|
||||
|
||||
memory.peak
|
||||
A read-only single value file which exists on non-root
|
||||
cgroups.
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
|
|||
|
|
@ -2,3 +2,8 @@
|
|||
*.example.dts
|
||||
/processed-schema*.yaml
|
||||
/processed-schema*.json
|
||||
|
||||
#
|
||||
# We don't want to ignore the following even if they are dot-files
|
||||
#
|
||||
!.yamllint
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ properties:
|
|||
|
||||
msi-controller:
|
||||
description:
|
||||
Only present if the Message Based Interrupt functionnality is
|
||||
Only present if the Message Based Interrupt functionality is
|
||||
being exposed by the HW, and the mbi-ranges property present.
|
||||
|
||||
mbi-ranges:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -40,6 +40,8 @@ properties:
|
|||
description:
|
||||
Indicates that the setting of RTC time is allowed by the host CPU.
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -819,7 +819,7 @@ NAPI
|
|||
----
|
||||
This driver supports NAPI (Rx polling mode).
|
||||
For more information on NAPI, see
|
||||
https://www.linuxfoundation.org/collaborate/workgroups/networking/napi
|
||||
https://wiki.linuxfoundation.org/networking/napi
|
||||
|
||||
|
||||
MACVLAN
|
||||
|
|
|
|||
|
|
@ -16,5 +16,5 @@ Contents
|
|||
|
||||
Support
|
||||
=======
|
||||
If you got any problem, contact Wangxun support team via support@trustnetic.com
|
||||
If you got any problem, contact Wangxun support team via nic-support@net-swift.com
|
||||
and Cc: netdev.
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
---------------------
|
||||
|
|
@ -8062,9 +8070,13 @@ considering the state as complete. VMM needs to ensure that the dirty
|
|||
state is final and avoid missing dirty pages from another ioctl ordered
|
||||
after the bitmap collection.
|
||||
|
||||
NOTE: One example of using the backup bitmap is saving arm64 vgic/its
|
||||
tables through KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_SAVE_TABLES} command on
|
||||
KVM device "kvm-arm-vgic-its" when dirty ring is enabled.
|
||||
NOTE: Multiple examples of using the backup bitmap: (1) save vgic/its
|
||||
tables through command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_SAVE_TABLES} on
|
||||
KVM device "kvm-arm-vgic-its". (2) restore vgic/its tables through
|
||||
command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_RESTORE_TABLES} on KVM device
|
||||
"kvm-arm-vgic-its". VGICv3 LPI pending status is restored. (3) save
|
||||
vgic3 pending table through KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES}
|
||||
command on KVM device "kvm-arm-vgic-v3".
|
||||
|
||||
8.30 KVM_CAP_XEN_HVM
|
||||
--------------------
|
||||
|
|
@ -8310,6 +8322,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
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
|
|||
|
|
@ -24,21 +24,22 @@ The acquisition orders for mutexes are as follows:
|
|||
|
||||
For SRCU:
|
||||
|
||||
- ``synchronize_srcu(&kvm->srcu)`` is called _inside_
|
||||
the kvm->slots_lock critical section, therefore kvm->slots_lock
|
||||
cannot be taken inside a kvm->srcu read-side critical section.
|
||||
Instead, kvm->slots_arch_lock is released before the call
|
||||
to ``synchronize_srcu()`` and _can_ be taken inside a
|
||||
kvm->srcu read-side critical section.
|
||||
- ``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::
|
||||
|
||||
- kvm->lock is taken inside kvm->srcu, therefore
|
||||
``synchronize_srcu(&kvm->srcu)`` cannot be called inside
|
||||
a kvm->lock critical section. If you cannot delay the
|
||||
call until after kvm->lock is released, use ``call_srcu``.
|
||||
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
|
||||
|
|
|
|||
108
MAINTAINERS
108
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/
|
||||
|
|
@ -1097,14 +1097,12 @@ S: Maintained
|
|||
F: drivers/dma/ptdma/
|
||||
|
||||
AMD SEATTLE DEVICE TREE SUPPORT
|
||||
M: Brijesh Singh <brijeshkumar.singh@amd.com>
|
||||
M: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
|
||||
M: Tom Lendacky <thomas.lendacky@amd.com>
|
||||
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
|
||||
|
|
@ -2213,6 +2211,9 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
|
||||
X: drivers/media/i2c/
|
||||
F: arch/arm64/boot/dts/freescale/
|
||||
X: arch/arm64/boot/dts/freescale/fsl-*
|
||||
X: arch/arm64/boot/dts/freescale/qoriq-*
|
||||
N: imx
|
||||
N: mxs
|
||||
|
||||
|
|
@ -2451,11 +2452,14 @@ F: drivers/rtc/rtc-mt7622.c
|
|||
|
||||
ARM/Mediatek SoC support
|
||||
M: Matthias Brugger <matthias.bgg@gmail.com>
|
||||
R: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
W: https://mtk.wiki.kernel.org/
|
||||
C: irc://chat.freenode.net/linux-mediatek
|
||||
C: irc://irc.libera.chat/linux-mediatek
|
||||
F: arch/arm/boot/dts/mt2*
|
||||
F: arch/arm/boot/dts/mt6*
|
||||
F: arch/arm/boot/dts/mt7*
|
||||
F: arch/arm/boot/dts/mt8*
|
||||
|
|
@ -2463,7 +2467,7 @@ F: arch/arm/mach-mediatek/
|
|||
F: arch/arm64/boot/dts/mediatek/
|
||||
F: drivers/soc/mediatek/
|
||||
N: mtk
|
||||
N: mt[678]
|
||||
N: mt[2678]
|
||||
K: mediatek
|
||||
|
||||
ARM/Mediatek USB3 PHY DRIVER
|
||||
|
|
@ -3767,7 +3771,6 @@ F: net/bluetooth/
|
|||
|
||||
BONDING DRIVER
|
||||
M: Jay Vosburgh <j.vosburgh@gmail.com>
|
||||
M: Veaceslav Falico <vfalico@gmail.com>
|
||||
M: Andy Gospodarek <andy@greyhouse.net>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -6948,7 +6951,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 +7619,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 +7897,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 +8474,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 +8526,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 +8577,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 +9306,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 +11363,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)
|
||||
|
|
@ -13620,7 +13627,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 +13672,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 +13769,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 +13821,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.*
|
||||
|
||||
|
|
@ -14601,7 +14608,6 @@ F: tools/testing/selftests/net/ipsec.c
|
|||
|
||||
NETWORKING [IPv4/IPv6]
|
||||
M: "David S. Miller" <davem@davemloft.net>
|
||||
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
|
||||
M: David Ahern <dsahern@kernel.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
|
@ -14634,7 +14640,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
|
||||
|
|
@ -14919,7 +14924,8 @@ 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
|
||||
|
|
@ -15658,7 +15664,7 @@ OPENRISC ARCHITECTURE
|
|||
M: Jonas Bonn <jonas@southpole.se>
|
||||
M: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
|
||||
M: Stafford Horne <shorne@gmail.com>
|
||||
L: openrisc@lists.librecores.org
|
||||
L: linux-openrisc@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://openrisc.io
|
||||
T: git https://github.com/openrisc/linux.git
|
||||
|
|
@ -15749,6 +15755,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
|
||||
|
|
@ -16108,7 +16120,7 @@ F: drivers/pci/controller/pci-v3-semi.c
|
|||
|
||||
PCI ENDPOINT SUBSYSTEM
|
||||
M: Lorenzo Pieralisi <lpieralisi@kernel.org>
|
||||
R: Krzysztof Wilczyński <kw@linux.com>
|
||||
M: Krzysztof Wilczyński <kw@linux.com>
|
||||
R: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||
R: Kishon Vijay Abraham I <kishon@kernel.org>
|
||||
L: linux-pci@vger.kernel.org
|
||||
|
|
@ -16116,7 +16128,7 @@ S: Supported
|
|||
Q: https://patchwork.kernel.org/project/linux-pci/list/
|
||||
B: https://bugzilla.kernel.org
|
||||
C: irc://irc.oftc.net/linux-pci
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
||||
F: Documentation/PCI/endpoint/*
|
||||
F: Documentation/misc-devices/pci-endpoint-test.rst
|
||||
F: drivers/misc/pci_endpoint_test.c
|
||||
|
|
@ -16151,7 +16163,7 @@ S: Supported
|
|||
Q: https://patchwork.kernel.org/project/linux-pci/list/
|
||||
B: https://bugzilla.kernel.org
|
||||
C: irc://irc.oftc.net/linux-pci
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
||||
F: Documentation/driver-api/pci/p2pdma.rst
|
||||
F: drivers/pci/p2pdma.c
|
||||
F: include/linux/pci-p2pdma.h
|
||||
|
|
@ -16173,14 +16185,14 @@ F: drivers/pci/controller/pci-xgene-msi.c
|
|||
|
||||
PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS
|
||||
M: Lorenzo Pieralisi <lpieralisi@kernel.org>
|
||||
M: Krzysztof Wilczyński <kw@linux.com>
|
||||
R: Rob Herring <robh@kernel.org>
|
||||
R: Krzysztof Wilczyński <kw@linux.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
Q: https://patchwork.kernel.org/project/linux-pci/list/
|
||||
B: https://bugzilla.kernel.org
|
||||
C: irc://irc.oftc.net/linux-pci
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
||||
F: Documentation/devicetree/bindings/pci/
|
||||
F: drivers/pci/controller/
|
||||
F: drivers/pci/pci-bridge-emul.c
|
||||
|
|
@ -16193,7 +16205,7 @@ S: Supported
|
|||
Q: https://patchwork.kernel.org/project/linux-pci/list/
|
||||
B: https://bugzilla.kernel.org
|
||||
C: irc://irc.oftc.net/linux-pci
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
||||
F: Documentation/PCI/
|
||||
F: Documentation/devicetree/bindings/pci/
|
||||
F: arch/x86/kernel/early-quirks.c
|
||||
|
|
@ -16610,6 +16622,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
|
||||
|
|
@ -17230,7 +17249,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
|
||||
|
|
@ -17310,7 +17329,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
|
||||
|
|
@ -17949,6 +17968,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/
|
||||
|
|
@ -18670,9 +18690,9 @@ F: drivers/target/
|
|||
F: include/target/
|
||||
|
||||
SCTP PROTOCOL
|
||||
M: Vlad Yasevich <vyasevich@gmail.com>
|
||||
M: Neil Horman <nhorman@tuxdriver.com>
|
||||
M: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
|
||||
M: Xin Long <lucien.xin@gmail.com>
|
||||
L: linux-sctp@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://lksctp.sourceforge.net
|
||||
|
|
@ -19318,6 +19338,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
|
||||
|
|
@ -19665,7 +19692,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
|
||||
|
|
@ -20063,6 +20090,7 @@ F: drivers/watchdog/sunplus_wdt.c
|
|||
SUPERH
|
||||
M: Yoshinori Sato <ysato@users.sourceforge.jp>
|
||||
M: Rich Felker <dalias@libc.org>
|
||||
M: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
L: linux-sh@vger.kernel.org
|
||||
S: Maintained
|
||||
Q: http://patchwork.kernel.org/project/linux-sh/list/
|
||||
|
|
@ -21703,6 +21731,7 @@ F: include/uapi/linux/uvcvideo.h
|
|||
|
||||
USB WEBCAM GADGET
|
||||
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
M: Daniel Scally <dan.scally@ideasonboard.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/usb/gadget/function/*uvc*
|
||||
|
|
@ -21738,6 +21767,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>
|
||||
|
|
@ -22246,7 +22282,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
|
||||
|
|
|
|||
19
Makefile
19
Makefile
|
|
@ -2,7 +2,7 @@
|
|||
VERSION = 6
|
||||
PATCHLEVEL = 2
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc2
|
||||
EXTRAVERSION = -rc8
|
||||
NAME = Hurr durr I'ma ninja sloth
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -751,7 +751,7 @@
|
|||
};
|
||||
|
||||
pca9849@75 {
|
||||
compatible = "nxp,pca849";
|
||||
compatible = "nxp,pca9849";
|
||||
reg = <0x75>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
|
|||
|
|
@ -198,6 +198,7 @@
|
|||
&usbotg2 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_usbotg2>;
|
||||
over-current-active-low;
|
||||
dr_mode = "host";
|
||||
status = "okay";
|
||||
};
|
||||
|
|
@ -374,7 +375,7 @@
|
|||
|
||||
pinctrl_usbotg2: usbotg2grp {
|
||||
fsl,pins = <
|
||||
MX7D_PAD_UART3_RTS_B__USB_OTG2_OC 0x04
|
||||
MX7D_PAD_UART3_RTS_B__USB_OTG2_OC 0x5c
|
||||
>;
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -480,6 +480,7 @@
|
|||
reg = <0xc8000000 0x1000>, <0xc0000000 0x4000000>;
|
||||
reg-names = "control", "memory";
|
||||
clocks = <&clk 0>;
|
||||
nuvoton,shm = <&shm>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
|
|||
|
|
@ -1181,6 +1181,7 @@
|
|||
clock-names = "dp", "pclk";
|
||||
phys = <&edp_phy>;
|
||||
phy-names = "dp";
|
||||
power-domains = <&power RK3288_PD_VIO>;
|
||||
resets = <&cru SRST_EDP>;
|
||||
reset-names = "dp";
|
||||
rockchip,grf = <&grf>;
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@
|
|||
tsin-num = <0>;
|
||||
serial-not-parallel;
|
||||
i2c-bus = <&ssc2>;
|
||||
reset-gpios = <&pio15 4 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&pio15 4 GPIO_ACTIVE_LOW>;
|
||||
dvb-card = <STV0367_TDA18212_NIMA_1>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1886,7 +1886,7 @@
|
|||
sd_emmc_b: sd@5000 {
|
||||
compatible = "amlogic,meson-axg-mmc";
|
||||
reg = <0x0 0x5000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
clocks = <&clkc CLKID_SD_EMMC_B>,
|
||||
<&clkc CLKID_SD_EMMC_B_CLK0>,
|
||||
|
|
@ -1898,7 +1898,7 @@
|
|||
sd_emmc_c: mmc@7000 {
|
||||
compatible = "amlogic,meson-axg-mmc";
|
||||
reg = <0x0 0x7000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
clocks = <&clkc CLKID_SD_EMMC_C>,
|
||||
<&clkc CLKID_SD_EMMC_C_CLK0>,
|
||||
|
|
|
|||
|
|
@ -2324,7 +2324,7 @@
|
|||
sd_emmc_a: sd@ffe03000 {
|
||||
compatible = "amlogic,meson-axg-mmc";
|
||||
reg = <0x0 0xffe03000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 189 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
clocks = <&clkc CLKID_SD_EMMC_A>,
|
||||
<&clkc CLKID_SD_EMMC_A_CLK0>,
|
||||
|
|
@ -2336,7 +2336,7 @@
|
|||
sd_emmc_b: sd@ffe05000 {
|
||||
compatible = "amlogic,meson-axg-mmc";
|
||||
reg = <0x0 0xffe05000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 190 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
clocks = <&clkc CLKID_SD_EMMC_B>,
|
||||
<&clkc CLKID_SD_EMMC_B_CLK0>,
|
||||
|
|
@ -2348,7 +2348,7 @@
|
|||
sd_emmc_c: mmc@ffe07000 {
|
||||
compatible = "amlogic,meson-axg-mmc";
|
||||
reg = <0x0 0xffe07000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 191 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
clocks = <&clkc CLKID_SD_EMMC_C>,
|
||||
<&clkc CLKID_SD_EMMC_C_CLK0>,
|
||||
|
|
|
|||
|
|
@ -603,21 +603,21 @@
|
|||
sd_emmc_a: mmc@70000 {
|
||||
compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
|
||||
reg = <0x0 0x70000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
sd_emmc_b: mmc@72000 {
|
||||
compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
|
||||
reg = <0x0 0x72000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
sd_emmc_c: mmc@74000 {
|
||||
compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
|
||||
reg = <0x0 0x74000 0x0 0x800>;
|
||||
interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>;
|
||||
status = "disabled";
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue