Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
提交 eadcbfa5 编写于 作者: D Dmitry Torokhov
浏览文件
操作

Merge tag 'v4.12-rc3' into for-linus 

Merge with mainline to get acpi_dev_present() needed by patches to
axp20x-pek driver.
上级 c4beedb8 5ed02dbb
展开全部 隐藏空白更改
内联 并排
Showing with 40741 addition and 15337 deletion

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
文本差异 电子邮件补丁
.gitignore
浏览文件 @ eadcbfa5
......@@ -33,6 +33,7 @@
*.lzo
*.patch
*.gcno
*.ll
modules.builtin
Module.symvers
*.dwo
......
.mailmap
浏览文件 @ eadcbfa5
......@@ -99,6 +99,8 @@ Linas Vepstas <linas@austin.ibm.com>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
Mark Brown <broonie@sirena.org.uk>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
Matthieu CASTET <castet.matthieu@free.fr>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
......@@ -109,6 +111,7 @@ Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
Matt Ranostay <mranostay@gmail.com> Matthew Ranostay <mranostay@embeddedalley.com>
Matt Ranostay <mranostay@gmail.com> <matt.ranostay@intel.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
Mayuresh Janorkar <mayur@ti.com>
Michael Buesch <m@bues.ch>
Michel Dänzer <michel@tungstengraphics.com>
......@@ -143,6 +146,8 @@ Santosh Shilimkar <ssantosh@kernel.org>
Santosh Shilimkar <santosh.shilimkar@oracle.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>
......@@ -171,6 +176,7 @@ Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
Yusuke Goda <goda.yusuke@renesas.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>
Gustavo Padovan <padovan@profusion.mobi>
CREDITS
浏览文件 @ eadcbfa5
......@@ -1034,6 +1034,10 @@ S: 2037 Walnut #6
S: Boulder, Colorado 80302
S: USA
N: Hans-Christian Noren Egtvedt
E: egtvedt@samfundet.no
D: AVR32 architecture maintainer.
N: Heiko Eißfeldt
E: heiko@colossus.escape.de heiko@unifix.de
D: verify_area stuff, generic SCSI fixes
......@@ -3398,6 +3402,10 @@ S: Suite 101
S: Markham, Ontario L3R 2Z6
S: Canada
N: Haavard Skinnemoen
M: Haavard Skinnemoen <hskinnemoen@gmail.com>
D: AVR32 architecture port to Linux and maintainer.
N: Rick Sladkey
E: jrs@world.std.com
D: utility hacker: Emacs, NFS server, mount, kmem-ps, UPS debugger, strace, GDB
......
Documentation/00-INDEX
浏览文件 @ eadcbfa5
......@@ -412,6 +412,8 @@ sysctl/
- directory with info on the /proc/sys/* files.
target/
- directory with info on generating TCM v4 fabric .ko modules
tee.txt
- info on the TEE subsystem and drivers
this_cpu_ops.txt
- List rationale behind and the way to use this_cpu operations.
thermal/
......
Documentation/ABI/obsolete/sysfs-firmware-acpi 0 → 100644
浏览文件 @ eadcbfa5
What: /sys/firmware/acpi/hotplug/force_remove
Date: Mar 2017
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
Since the force_remove is inherently broken and dangerous to
use for some hotplugable resources like memory (because ignoring
the offline failure might lead to memory corruption and crashes)
enabling this knob is not safe and thus unsupported.
Documentation/ABI/stable/sysfs-bus-usb
浏览文件 @ eadcbfa5
......@@ -9,7 +9,7 @@ Description:
hubs this facility is always enabled and their device
directories will not contain this file.
For more information, see Documentation/usb/persist.txt.
For more information, see Documentation/driver-api/usb/persist.rst.
What: /sys/bus/usb/devices/.../power/autosuspend
Date: March 2007
......
Documentation/ABI/stable/vdso
浏览文件 @ eadcbfa5
......@@ -16,7 +16,8 @@ The vDSO uses symbol versioning; whenever you request a symbol from the
vDSO, specify the version you are expecting.
Programs that dynamically link to glibc will use the vDSO automatically.
Otherwise, you can use the reference parser in Documentation/vDSO/parse_vdso.c.
Otherwise, you can use the reference parser in
tools/testing/selftests/vDSO/parse_vdso.c.
Unless otherwise noted, the set of symbols with any given version and the
ABI of those symbols is considered stable. It may vary across architectures,
......
Documentation/ABI/testing/sysfs-block
浏览文件 @ eadcbfa5
......@@ -213,14 +213,8 @@ What: /sys/block/<disk>/queue/discard_zeroes_data
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may return
stale or random data when a previously discarded block
is read back. This can cause problems if the filesystem
expects discarded blocks to be explicitly cleared. If a
device reports that it deterministically returns zeroes
when a discarded area is read the discard_zeroes_data
parameter will be set to one. Otherwise it will be 0 and
the result of reading a discarded area is undefined.
Will always return 0. Don't rely on any specific behavior
for discards, and don't read this file.
What: /sys/block/<disk>/queue/write_same_max_bytes
Date: January 2012
......
Documentation/ABI/testing/sysfs-bus-iio
浏览文件 @ eadcbfa5
......@@ -55,6 +55,7 @@ Description:
then it is to be found in the base device directory.
What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency_available
What: /sys/bus/iio/devices/iio:deviceX/in_proximity_sampling_frequency_available
What: /sys/.../iio:deviceX/buffer/sampling_frequency_available
What: /sys/bus/iio/devices/triggerX/sampling_frequency_available
KernelVersion: 2.6.35
......@@ -1593,7 +1594,7 @@ Description:
can be processed to siemens per meter.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_raw
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Raw counter device counts from channel Y. For quadrature
......@@ -1601,10 +1602,24 @@ Description:
the counts of a single quadrature signal phase from channel Y.
What: /sys/bus/iio/devices/iio:deviceX/in_indexY_raw
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Raw counter device index value from channel Y. This attribute
provides an absolute positional reference (e.g. a pulse once per
revolution) which may be used to home positional systems as
required.
What: /sys/bus/iio/devices/iio:deviceX/in_count_count_direction_available
KernelVersion: 4.12
Contact: linux-iio@vger.kernel.org
Description:
A list of possible counting directions which are:
- "up" : counter device is increasing.
- "down": counter device is decreasing.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_count_direction
KernelVersion: 4.12
Contact: linux-iio@vger.kernel.org
Description:
Raw counter device counters direction for channel Y.
Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 0 → 100644
浏览文件 @ eadcbfa5
What: /sys/bus/iio/devices/iio:deviceX/in_power_shunt_resistor
Date: March 2017
KernelVersion: 4.12
Contact: linux-iio@vger.kernel.org
Description: The value of the shunt resistor used to compute power drain on
common input voltage pin (RS+). In Ohms.
What: /sys/bus/iio/devices/iio:deviceX/in_current_shunt_resistor
Date: March 2017
KernelVersion: 4.12
Contact: linux-iio@vger.kernel.org
Description: The value of the shunt resistor used to compute current flowing
between RS+ and RS- voltage sense inputs. In Ohms.
These attributes describe a single physical component, exposed as two distinct
attributes as it is used to calculate two different values: power load and
current flowing between RS+ and RS- inputs.
Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
浏览文件 @ eadcbfa5
What: /sys/bus/iio/devices/iio:deviceX/in_count_count_direction_available
What: /sys/bus/iio/devices/iio:deviceX/in_count_count_mode_available
What: /sys/bus/iio/devices/iio:deviceX/in_count_noise_error_available
What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
What: /sys/bus/iio/devices/iio:deviceX/in_index_index_polarity_available
What: /sys/bus/iio/devices/iio:deviceX/in_index_synchronous_mode_available
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Discrete set of available values for the respective counter
configuration are listed in this file.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_count_direction
KernelVersion: 4.9
Contact: linux-iio@vger.kernel.org
Description:
Read-only attribute that indicates whether the counter for
channel Y is counting up or down.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_count_mode
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Count mode for channel Y. Four count modes are available:
......@@ -52,7 +44,7 @@ Description:
continuously throughout.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_noise_error
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Read-only attribute that indicates whether excessive noise is
......@@ -60,14 +52,14 @@ Description:
irrelevant in non-quadrature clock mode.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_preset
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
If the counter device supports preset registers, the preset
count for channel Y is provided by this attribute.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_quadrature_mode
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Configure channel Y counter for non-quadrature or quadrature
......@@ -88,7 +80,7 @@ Description:
decoded for UP/DN clock.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_set_to_preset_on_index
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Whether to set channel Y counter with channel Y preset value
......@@ -96,14 +88,14 @@ Description:
Valid attribute values are boolean.
What: /sys/bus/iio/devices/iio:deviceX/in_indexY_index_polarity
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Active level of channel Y index input; irrelevant in
non-synchronous load mode.
What: /sys/bus/iio/devices/iio:deviceX/in_indexY_synchronous_mode
KernelVersion: 4.9
KernelVersion: 4.10
Contact: linux-iio@vger.kernel.org
Description:
Configure channel Y counter for non-synchronous or synchronous
......
Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
浏览文件 @ eadcbfa5
......@@ -3,11 +3,15 @@ KernelVersion: 4.11
Contact: benjamin.gaignard@st.com
Description:
Reading returns the list possible master modes which are:
- "reset" : The UG bit from the TIMx_EGR register is used as trigger output (TRGO).
- "enable" : The Counter Enable signal CNT_EN is used as trigger output.
- "reset" : The UG bit from the TIMx_EGR register is
used as trigger output (TRGO).
- "enable" : The Counter Enable signal CNT_EN is used
as trigger output.
- "update" : The update event is selected as trigger output.
For instance a master timer can then be used as a prescaler for a slave timer.
- "compare_pulse" : The trigger output send a positive pulse when the CC1IF flag is to be set.
For instance a master timer can then be used
as a prescaler for a slave timer.
- "compare_pulse" : The trigger output send a positive pulse
when the CC1IF flag is to be set.
- "OC1REF" : OC1REF signal is used as trigger output.
- "OC2REF" : OC2REF signal is used as trigger output.
- "OC3REF" : OC3REF signal is used as trigger output.
......@@ -27,3 +31,62 @@ Description:
Reading returns the current sampling frequency.
Writing an value different of 0 set and start sampling.
Writing 0 stop sampling.
What: /sys/bus/iio/devices/iio:deviceX/in_count0_preset
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
Description:
Reading returns the current preset value.
Writing sets the preset value.
When counting up the counter starts from 0 and fires an
event when reach preset value.
When counting down the counter start from preset value
and fire event when reach 0.
What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
Description:
Reading returns the list possible quadrature modes.
What: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
Description:
Configure the device counter quadrature modes:
channel_A:
Encoder A input servers as the count input and B as
the UP/DOWN direction control input.
channel_B:
Encoder B input serves as the count input and A as
the UP/DOWN direction control input.
quadrature:
Encoder A and B inputs are mixed to get direction
and count with a scale of 0.25.
What: /sys/bus/iio/devices/iio:deviceX/in_count_enable_mode_available
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
Description:
Reading returns the list possible enable modes.
What: /sys/bus/iio/devices/iio:deviceX/in_count0_enable_mode
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
Description:
Configure the device counter enable modes, in all case
counting direction is set by in_count0_count_direction
attribute and the counter is clocked by the internal clock.
always:
Counter is always ON.
gated:
Counting is enabled when connected trigger signal
level is high else counting is disabled.
triggered:
Counting is enabled on rising edge of the connected
trigger, and remains enabled for the duration of this
selected mode.
Documentation/ABI/testing/sysfs-bus-pci
浏览文件 @ eadcbfa5
......@@ -299,5 +299,27 @@ What: /sys/bus/pci/devices/.../revision
Date: November 2016
Contact: Emil Velikov <emil.l.velikov@gmail.com>
Description:
This file contains the revision field of the the PCI device.
This file contains the revision field of the PCI device.
The value comes from device config space. The file is read only.
What: /sys/bus/pci/devices/.../sriov_drivers_autoprobe
Date: April 2017
Contact: Bodong Wang<bodong@mellanox.com>
Description:
This file is associated with the PF of a device that
supports SR-IOV. It determines whether newly-enabled VFs
are immediately bound to a driver. It initially contains
1, which means the kernel automatically binds VFs to a
compatible driver immediately after they are enabled. If
an application writes 0 to the file before enabling VFs,
the kernel will not bind VFs to a driver.
A typical use case is to write 0 to this file, then enable
VFs, then assign the newly-created VFs to virtual machines.
Note that changing this file does not affect already-
enabled VFs. In this scenario, the user must first disable
the VFs, write 0 to sriov_drivers_autoprobe, then re-enable
the VFs.
This is similar to /sys/bus/pci/drivers_autoprobe, but
affects only the VFs associated with a specific PF.
Documentation/ABI/testing/sysfs-class-net-qmi
浏览文件 @ eadcbfa5
......@@ -21,3 +21,30 @@ Description:
is responsible for coordination of driver and firmware
link framing mode, changing this setting to 'Y' if the
firmware is configured for 'raw-ip' mode.
What: /sys/class/net/<iface>/qmi/add_mux
Date: March 2017
KernelVersion: 4.11
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Unsigned integer.
Write a number ranging from 1 to 127 to add a qmap mux
based network device, supported by recent Qualcomm based
modems.
The network device will be called qmimux.
Userspace is in charge of managing the qmux network device
activation and data stream setup on the modem side by
using the proper QMI protocol requests.
What: /sys/class/net/<iface>/qmi/del_mux
Date: March 2017
KernelVersion: 4.11
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Unsigned integer.
Write a number ranging from 1 to 127 to delete a previously
created qmap mux based network device.
Documentation/ABI/testing/sysfs-class-switchtec 0 → 100644
浏览文件 @ eadcbfa5
switchtec - Microsemi Switchtec PCI Switch Management Endpoint
For details on this subsystem look at Documentation/switchtec.txt.
What: /sys/class/switchtec
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: The switchtec class subsystem folder.
Each registered switchtec driver is represented by a switchtecX
subfolder (X being an integer >= 0).
What: /sys/class/switchtec/switchtec[0-9]+/component_id
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Component identifier as stored in the hardware (eg. PM8543)
(read only)
Values: arbitrary string.
What: /sys/class/switchtec/switchtec[0-9]+/component_revision
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Component revision stored in the hardware (read only)
Values: integer.
What: /sys/class/switchtec/switchtec[0-9]+/component_vendor
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Component vendor as stored in the hardware (eg. MICROSEM)
(read only)
Values: arbitrary string.
What: /sys/class/switchtec/switchtec[0-9]+/device_version
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Device version as stored in the hardware (read only)
Values: integer.
What: /sys/class/switchtec/switchtec[0-9]+/fw_version
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Currently running firmware version (read only)
Values: integer (in hexadecimal).
What: /sys/class/switchtec/switchtec[0-9]+/partition
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Partition number for this device in the switch (read only)
Values: integer.
What: /sys/class/switchtec/switchtec[0-9]+/partition_count
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Total number of partitions in the switch (read only)
Values: integer.
What: /sys/class/switchtec/switchtec[0-9]+/product_id
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Product identifier as stored in the hardware (eg. PSX 48XG3)
(read only)
Values: arbitrary string.
What: /sys/class/switchtec/switchtec[0-9]+/product_revision
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Product revision stored in the hardware (eg. RevB)
(read only)
Values: arbitrary string.
What: /sys/class/switchtec/switchtec[0-9]+/product_vendor
Date: 05-Jan-2017
KernelVersion: v4.11
Contact: Logan Gunthorpe <logang@deltatee.com>
Description: Product vendor as stored in the hardware (eg. MICROSEM)
(read only)
Values: arbitrary string.
Documentation/ABI/testing/sysfs-class-typec 0 → 100644
浏览文件 @ eadcbfa5
USB Type-C port devices (eg. /sys/class/typec/port0/)
What: /sys/class/typec/<port>/data_role
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The supported USB data roles. This attribute can be used for
requesting data role swapping on the port. Swapping is supported
as synchronous operation, so write(2) to the attribute will not
return until the operation has finished. The attribute is
notified about role changes so that poll(2) on the attribute
wakes up. Change on the role will also generate uevent
KOBJ_CHANGE on the port. The current role is show in brackets,
for example "[host] device" when DRP port is in host mode.
Valid values: host, device
What: /sys/class/typec/<port>/power_role
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The supported power roles. This attribute can be used to request
power role swap on the port when the port supports USB Power
Delivery. Swapping is supported as synchronous operation, so
write(2) to the attribute will not return until the operation
has finished. The attribute is notified about role changes so
that poll(2) on the attribute wakes up. Change on the role will
also generate uevent KOBJ_CHANGE. The current role is show in
brackets, for example "[source] sink" when in source mode.
Valid values: source, sink
What: /sys/class/typec/<port>/vconn_source
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows is the port VCONN Source. This attribute can be used to
request VCONN swap to change the VCONN Source during connection
when both the port and the partner support USB Power Delivery.
Swapping is supported as synchronous operation, so write(2) to
the attribute will not return until the operation has finished.
The attribute is notified about VCONN source changes so that
poll(2) on the attribute wakes up. Change on VCONN source also
generates uevent KOBJ_CHANGE.
Valid values:
- "no" when the port is not the VCONN Source
- "yes" when the port is the VCONN Source
What: /sys/class/typec/<port>/power_operation_mode
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows the current power operational mode the port is in. The
power operation mode means current level for VBUS. In case USB
Power Delivery communication is used for negotiating the levels,
power operation mode should show "usb_power_delivery".
Valid values:
- default
- 1.5A
- 3.0A
- usb_power_delivery
What: /sys/class/typec/<port>/preferred_role
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The user space can notify the driver about the preferred role.
It should be handled as enabling of Try.SRC or Try.SNK, as
defined in USB Type-C specification, in the port drivers. By
default the preferred role should come from the platform.
Valid values: source, sink, none (to remove preference)
What: /sys/class/typec/<port>/supported_accessory_modes
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Space separated list of accessory modes, defined in the USB
Type-C specification, the port supports.
What: /sys/class/typec/<port>/usb_power_delivery_revision
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Revision number of the supported USB Power Delivery
specification, or 0 when USB Power Delivery is not supported.
What: /sys/class/typec/<port>/usb_typec_revision
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Revision number of the supported USB Type-C specification.
USB Type-C partner devices (eg. /sys/class/typec/port0-partner/)
What: /sys/class/typec/<port>-partner/accessory_mode
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows the Accessory Mode name when the partner is an Accessory.
The Accessory Modes are defined in USB Type-C Specification.
What: /sys/class/typec/<port>-partner/supports_usb_power_delivery
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows if the partner supports USB Power Delivery communication:
Valid values: yes, no
What: /sys/class/typec/<port>-partner>/identity/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This directory appears only if the port device driver is capable
of showing the result of Discover Identity USB power delivery
command. That will not always be possible even when USB power
delivery is supported, for example when USB power delivery
communication for the port is mostly handled in firmware. If the
directory exists, it will have an attribute file for every VDO
in Discover Identity command result.
What: /sys/class/typec/<port>-partner/identity/id_header
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
ID Header VDO part of Discover Identity command result. The
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-partner/identity/cert_stat
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Cert Stat VDO part of Discover Identity command result. The
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-partner/identity/product
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Product VDO part of Discover Identity command result. The value
will show 0 until Discover Identity command result becomes
available. The value can be polled.
USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)
Note: Electronically Marked Cables will have a device also for one cable plug
(eg. /sys/class/typec/port0-plug0). If the cable is active and has also SOP
Double Prime controller (USB Power Deliver specification ch. 2.4) it will have
second device also for the other plug. Both plugs may have alternate modes as
described in USB Type-C and USB Power Delivery specifications.
What: /sys/class/typec/<port>-cable/type
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows if the cable is active.
Valid values: active, passive
What: /sys/class/typec/<port>-cable/plug_type
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows type of the plug on the cable:
- type-a - Standard A
- type-b - Standard B
- type-c
- captive
What: /sys/class/typec/<port>-cable/identity/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This directory appears only if the port device driver is capable
of showing the result of Discover Identity USB power delivery
command. That will not always be possible even when USB power
delivery is supported. If the directory exists, it will have an
attribute for every VDO returned by Discover Identity command.
What: /sys/class/typec/<port>-cable/identity/id_header
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
ID Header VDO part of Discover Identity command result. The
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-cable/identity/cert_stat
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Cert Stat VDO part of Discover Identity command result. The
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
What: /sys/class/typec/<port>-cable/identity/product
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Product VDO part of Discover Identity command result. The value
will show 0 until Discover Identity command result becomes
available. The value can be polled.
Alternate Mode devices.
The alternate modes will have Standard or Vendor ID (SVID) assigned by USB-IF.
The ports, partners and cable plugs can have alternate modes. A supported SVID
will consist of a set of modes. Every SVID a port/partner/plug supports will
have a device created for it, and every supported mode for a supported SVID will
have its own directory under that device. Below <dev> refers to the device for
the alternate mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/svid
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The SVID (Standard or Vendor ID) assigned by USB-IF for this
alternate mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Every supported mode will have its own directory. The name of
a mode will be "mode<index>" (for example mode1), where <index>
is the actual index to the mode VDO returned by Discover Modes
USB power delivery command.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/description
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows description of the mode. The description is optional for
the drivers, just like with the Billboard Devices.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/vdo
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows the VDO in hexadecimal returned by Discover Modes command
for this mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/active
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows if the mode is active or not. The attribute can be used
for entering/exiting the mode with partners and cable plugs, and
with the port alternate modes it can be used for disabling
support for specific alternate modes. Entering/exiting modes is
supported as synchronous operation so write(2) to the attribute
does not return until the enter/exit mode operation has
finished. The attribute is notified when the mode is
entered/exited so poll(2) on the attribute wakes up.
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
Valid values: yes, no
What: /sys/class/typec/<port>/<dev>/mode<index>/supported_roles
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Space separated list of the supported roles.
This attribute is available for the devices describing the
alternate modes a port supports, and it will not be exposed with
the devices presenting the alternate modes the partners or cable
plugs support.
Valid values: source, sink
Documentation/ABI/testing/sysfs-devices-system-cpu
浏览文件 @ eadcbfa5
......@@ -366,3 +366,10 @@ Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>
Description: AArch64 CPU registers
'identification' directory exposes the CPU ID registers for
identifying model and revision of the CPU.
What: /sys/devices/system/cpu/cpu#/cpu_capacity
Date: December 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: information about CPUs heterogeneity.
cpu_capacity: capacity of cpu#.
Documentation/ABI/testing/sysfs-firmware-acpi
浏览文件 @ eadcbfa5
......@@ -44,16 +44,6 @@ Description:
or 0 (unset). Attempts to write any other values to it will
cause -EINVAL to be returned.
What: /sys/firmware/acpi/hotplug/force_remove
Date: May 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The number in this file (0 or 1) determines whether (1) or not
(0) the ACPI subsystem will allow devices to be hot-removed even
if they cannot be put offline gracefully (from the kernel's
viewpoint). That number can be changed by writing a boolean
value to this file.
What: /sys/firmware/acpi/interrupts/
Date: February 2008
Contact: Len Brown <lenb@kernel.org>
......
Documentation/ABI/testing/sysfs-kernel-livepatch
浏览文件 @ eadcbfa5
......@@ -25,6 +25,14 @@ Description:
code is currently applied. Writing 0 will disable the patch
while writing 1 will re-enable the patch.
What: /sys/kernel/livepatch/<patch>/transition
Date: Feb 2017
KernelVersion: 4.12.0
Contact: live-patching@vger.kernel.org
Description:
An attribute which indicates whether the patch is currently in
transition.
What: /sys/kernel/livepatch/<patch>/<object>
Date: Nov 2014
KernelVersion: 3.19.0
......
Documentation/ABI/testing/sysfs-platform-chipidea-usb2 0 → 100644
浏览文件 @ eadcbfa5
What: /sys/bus/platform/devices/ci_hdrc.0/role
Date: Mar 2017
Contact: Peter Chen <peter.chen@nxp.com>
Description:
It returns string "gadget" or "host" when read it, it indicates
current controller role.
It will do role switch when write "gadget" or "host" to it.
Only controller at dual-role configuration supports writing.
Documentation/ABI/testing/sysfs-platform-renesas_usb3 0 → 100644
浏览文件 @ eadcbfa5
What: /sys/devices/platform/<renesas_usb3's name>/role
Date: March 2017
KernelVersion: 4.13
Contact: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Description:
This file can be read and write.
The file can show/change the drd mode of usb.
Write the following string to change the mode:
"host" - switching mode from peripheral to host.
"peripheral" - switching mode from host to peripheral.
Read the file, then it shows the following strings:
"host" - The mode is host now.
"peripheral" - The mode is peripheral now.
Documentation/DocBook/Makefile
浏览文件 @ eadcbfa5
......@@ -8,12 +8,11 @@
DOCBOOKS := z8530book.xml \
kernel-hacking.xml kernel-locking.xml \
writing_usb_driver.xml networking.xml \
kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml scsi.xml \
sh.xml w1.xml \
writing_musb_glue_layer.xml
networking.xml \
filesystems.xml lsm.xml kgdb.xml \
libata.xml mtdnand.xml librs.xml rapidio.xml \
s390-drivers.xml scsi.xml \
sh.xml w1.xml
ifeq ($(DOCBOOKS),)
......@@ -62,11 +61,14 @@ MAN := $(patsubst %.xml, %.9, $(BOOKS))
mandocs: $(MAN)
find $(obj)/man -name '*.9' | xargs gzip -nf
# Default location for installed man pages
export INSTALL_MAN_PATH = $(objtree)/usr
installmandocs: mandocs
mkdir -p /usr/local/man/man9/
mkdir -p $(INSTALL_MAN_PATH)/man/man9/
find $(obj)/man -name '*.9.gz' -printf '%h %f\n' | \
sort -k 2 -k 1 | uniq -f 1 | sed -e 's: :/:' | \
xargs install -m 644 -t /usr/local/man/man9/
xargs install -m 644 -t $(INSTALL_MAN_PATH)/man/man9/
# no-op for the DocBook toolchain
epubdocs:
......@@ -238,7 +240,9 @@ dochelp:
@echo ' psdocs - Postscript'
@echo ' xmldocs - XML DocBook'
@echo ' mandocs - man pages'
@echo ' installmandocs - install man pages generated by mandocs'
@echo ' installmandocs - install man pages generated by mandocs to INSTALL_MAN_PATH'; \
echo ' (default: $(INSTALL_MAN_PATH))'; \
echo ''
@echo ' cleandocs - clean all generated DocBook files'
@echo
@echo ' make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs s1.xml s2.xml'
......
Documentation/DocBook/gadget.tmpl 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/DocBook/genericirq.tmpl 已删除 100644 → 0
浏览文件 @ c4beedb8
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="Generic-IRQ-Guide">
<bookinfo>
<title>Linux generic IRQ handling</title>
<authorgroup>
<author>
<firstname>Thomas</firstname>
<surname>Gleixner</surname>
<affiliation>
<address>
<email>tglx@linutronix.de</email>
</address>
</affiliation>
</author>
<author>
<firstname>Ingo</firstname>
<surname>Molnar</surname>
<affiliation>
<address>
<email>mingo@elte.hu</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2005-2010</year>
<holder>Thomas Gleixner</holder>
</copyright>
<copyright>
<year>2005-2006</year>
<holder>Ingo Molnar</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="intro">
<title>Introduction</title>
<para>
The generic interrupt handling layer is designed to provide a
complete abstraction of interrupt handling for device drivers.
It is able to handle all the different types of interrupt controller
hardware. Device drivers use generic API functions to request, enable,
disable and free interrupts. The drivers do not have to know anything
about interrupt hardware details, so they can be used on different
platforms without code changes.
</para>
<para>
This documentation is provided to developers who want to implement
an interrupt subsystem based for their architecture, with the help
of the generic IRQ handling layer.
</para>
</chapter>
<chapter id="rationale">
<title>Rationale</title>
<para>
The original implementation of interrupt handling in Linux uses
the __do_IRQ() super-handler, which is able to deal with every
type of interrupt logic.
</para>
<para>
Originally, Russell King identified different types of handlers to
build a quite universal set for the ARM interrupt handler
implementation in Linux 2.5/2.6. He distinguished between:
<itemizedlist>
<listitem><para>Level type</para></listitem>
<listitem><para>Edge type</para></listitem>
<listitem><para>Simple type</para></listitem>
</itemizedlist>
During the implementation we identified another type:
<itemizedlist>
<listitem><para>Fast EOI type</para></listitem>
</itemizedlist>
In the SMP world of the __do_IRQ() super-handler another type
was identified:
<itemizedlist>
<listitem><para>Per CPU type</para></listitem>
</itemizedlist>
</para>
<para>
This split implementation of high-level IRQ handlers allows us to
optimize the flow of the interrupt handling for each specific
interrupt type. This reduces complexity in that particular code path
and allows the optimized handling of a given type.
</para>
<para>
The original general IRQ implementation used hw_interrupt_type
structures and their ->ack(), ->end() [etc.] callbacks to
differentiate the flow control in the super-handler. This leads to
a mix of flow logic and low-level hardware logic, and it also leads
to unnecessary code duplication: for example in i386, there is an
ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
of the low-level details but have different flow handling.
</para>
<para>
A more natural abstraction is the clean separation of the
'irq flow' and the 'chip details'.
</para>
<para>
Analysing a couple of architecture's IRQ subsystem implementations
reveals that most of them can use a generic set of 'irq flow'
methods and only need to add the chip-level specific code.
The separation is also valuable for (sub)architectures
which need specific quirks in the IRQ flow itself but not in the
chip details - and thus provides a more transparent IRQ subsystem
design.
</para>
<para>
Each interrupt descriptor is assigned its own high-level flow
handler, which is normally one of the generic
implementations. (This high-level flow handler implementation also
makes it simple to provide demultiplexing handlers which can be
found in embedded platforms on various architectures.)
</para>
<para>
The separation makes the generic interrupt handling layer more
flexible and extensible. For example, an (sub)architecture can
use a generic IRQ-flow implementation for 'level type' interrupts
and add a (sub)architecture specific 'edge type' implementation.
</para>
<para>
To make the transition to the new model easier and prevent the
breakage of existing implementations, the __do_IRQ() super-handler
is still available. This leads to a kind of duality for the time
being. Over time the new model should be used in more and more
architectures, as it enables smaller and cleaner IRQ subsystems.
It's deprecated for three years now and about to be removed.
</para>
</chapter>
<chapter id="bugs">
<title>Known Bugs And Assumptions</title>
<para>
None (knock on wood).
</para>
</chapter>
<chapter id="Abstraction">
<title>Abstraction layers</title>
<para>
There are three main levels of abstraction in the interrupt code:
<orderedlist>
<listitem><para>High-level driver API</para></listitem>
<listitem><para>High-level IRQ flow handlers</para></listitem>
<listitem><para>Chip-level hardware encapsulation</para></listitem>
</orderedlist>
</para>
<sect1 id="Interrupt_control_flow">
<title>Interrupt control flow</title>
<para>
Each interrupt is described by an interrupt descriptor structure
irq_desc. The interrupt is referenced by an 'unsigned int' numeric
value which selects the corresponding interrupt description structure
in the descriptor structures array.
The descriptor structure contains status information and pointers
to the interrupt flow method and the interrupt chip structure
which are assigned to this interrupt.
</para>
<para>
Whenever an interrupt triggers, the low-level architecture code calls
into the generic interrupt code by calling desc->handle_irq().
This high-level IRQ handling function only uses desc->irq_data.chip
primitives referenced by the assigned chip descriptor structure.
</para>
</sect1>
<sect1 id="Highlevel_Driver_API">
<title>High-level Driver API</title>
<para>
The high-level Driver API consists of following functions:
<itemizedlist>
<listitem><para>request_irq()</para></listitem>
<listitem><para>free_irq()</para></listitem>
<listitem><para>disable_irq()</para></listitem>
<listitem><para>enable_irq()</para></listitem>
<listitem><para>disable_irq_nosync() (SMP only)</para></listitem>
<listitem><para>synchronize_irq() (SMP only)</para></listitem>
<listitem><para>irq_set_irq_type()</para></listitem>
<listitem><para>irq_set_irq_wake()</para></listitem>
<listitem><para>irq_set_handler_data()</para></listitem>
<listitem><para>irq_set_chip()</para></listitem>
<listitem><para>irq_set_chip_data()</para></listitem>
</itemizedlist>
See the autogenerated function documentation for details.
</para>
</sect1>
<sect1 id="Highlevel_IRQ_flow_handlers">
<title>High-level IRQ flow handlers</title>
<para>
The generic layer provides a set of pre-defined irq-flow methods:
<itemizedlist>
<listitem><para>handle_level_irq</para></listitem>
<listitem><para>handle_edge_irq</para></listitem>
<listitem><para>handle_fasteoi_irq</para></listitem>
<listitem><para>handle_simple_irq</para></listitem>
<listitem><para>handle_percpu_irq</para></listitem>
<listitem><para>handle_edge_eoi_irq</para></listitem>
<listitem><para>handle_bad_irq</para></listitem>
</itemizedlist>
The interrupt flow handlers (either pre-defined or architecture
specific) are assigned to specific interrupts by the architecture
either during bootup or during device initialization.
</para>
<sect2 id="Default_flow_implementations">
<title>Default flow implementations</title>
<sect3 id="Helper_functions">
<title>Helper functions</title>
<para>
The helper functions call the chip primitives and
are used by the default flow implementations.
The following helper functions are implemented (simplified excerpt):
<programlisting>
default_enable(struct irq_data *data)
{
desc->irq_data.chip->irq_unmask(data);
}
default_disable(struct irq_data *data)
{
if (!delay_disable(data))
desc->irq_data.chip->irq_mask(data);
}
default_ack(struct irq_data *data)
{
chip->irq_ack(data);
}
default_mask_ack(struct irq_data *data)
{
if (chip->irq_mask_ack) {
chip->irq_mask_ack(data);
} else {
chip->irq_mask(data);
chip->irq_ack(data);
}
}
noop(struct irq_data *data))
{
}
</programlisting>
</para>
</sect3>
</sect2>
<sect2 id="Default_flow_handler_implementations">
<title>Default flow handler implementations</title>
<sect3 id="Default_Level_IRQ_flow_handler">
<title>Default Level IRQ flow handler</title>
<para>
handle_level_irq provides a generic implementation
for level-triggered interrupts.
</para>
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
desc->irq_data.chip->irq_mask_ack();
handle_irq_event(desc->action);
desc->irq_data.chip->irq_unmask();
</programlisting>
</para>
</sect3>
<sect3 id="Default_FASTEOI_IRQ_flow_handler">
<title>Default Fast EOI IRQ flow handler</title>
<para>
handle_fasteoi_irq provides a generic implementation
for interrupts, which only need an EOI at the end of
the handler.
</para>
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_irq_event(desc->action);
desc->irq_data.chip->irq_eoi();
</programlisting>
</para>
</sect3>
<sect3 id="Default_Edge_IRQ_flow_handler">
<title>Default Edge IRQ flow handler</title>
<para>
handle_edge_irq provides a generic implementation
for edge-triggered interrupts.
</para>
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
if (desc->status &amp; running) {
desc->irq_data.chip->irq_mask_ack();
desc->status |= pending | masked;
return;
}
desc->irq_data.chip->irq_ack();
desc->status |= running;
do {
if (desc->status &amp; masked)
desc->irq_data.chip->irq_unmask();
desc->status &amp;= ~pending;
handle_irq_event(desc->action);
} while (status &amp; pending);
desc->status &amp;= ~running;
</programlisting>
</para>
</sect3>
<sect3 id="Default_simple_IRQ_flow_handler">
<title>Default simple IRQ flow handler</title>
<para>
handle_simple_irq provides a generic implementation
for simple interrupts.
</para>
<para>
Note: The simple flow handler does not call any
handler/chip primitives.
</para>
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_irq_event(desc->action);
</programlisting>
</para>
</sect3>
<sect3 id="Default_per_CPU_flow_handler">
<title>Default per CPU flow handler</title>
<para>
handle_percpu_irq provides a generic implementation
for per CPU interrupts.
</para>
<para>
Per CPU interrupts are only available on SMP and
the handler provides a simplified version without
locking.
</para>
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
if (desc->irq_data.chip->irq_ack)
desc->irq_data.chip->irq_ack();
handle_irq_event(desc->action);
if (desc->irq_data.chip->irq_eoi)
desc->irq_data.chip->irq_eoi();
</programlisting>
</para>
</sect3>
<sect3 id="EOI_Edge_IRQ_flow_handler">
<title>EOI Edge IRQ flow handler</title>
<para>
handle_edge_eoi_irq provides an abnomination of the edge
handler which is solely used to tame a badly wreckaged
irq controller on powerpc/cell.
</para>
</sect3>
<sect3 id="BAD_IRQ_flow_handler">
<title>Bad IRQ flow handler</title>
<para>
handle_bad_irq is used for spurious interrupts which
have no real handler assigned..
</para>
</sect3>
</sect2>
<sect2 id="Quirks_and_optimizations">
<title>Quirks and optimizations</title>
<para>
The generic functions are intended for 'clean' architectures and chips,
which have no platform-specific IRQ handling quirks. If an architecture
needs to implement quirks on the 'flow' level then it can do so by
overriding the high-level irq-flow handler.
</para>
</sect2>
<sect2 id="Delayed_interrupt_disable">
<title>Delayed interrupt disable</title>
<para>
This per interrupt selectable feature, which was introduced by Russell
King in the ARM interrupt implementation, does not mask an interrupt
at the hardware level when disable_irq() is called. The interrupt is
kept enabled and is masked in the flow handler when an interrupt event
happens. This prevents losing edge interrupts on hardware which does
not store an edge interrupt event while the interrupt is disabled at
the hardware level. When an interrupt arrives while the IRQ_DISABLED
flag is set, then the interrupt is masked at the hardware level and
the IRQ_PENDING bit is set. When the interrupt is re-enabled by
enable_irq() the pending bit is checked and if it is set, the
interrupt is resent either via hardware or by a software resend
mechanism. (It's necessary to enable CONFIG_HARDIRQS_SW_RESEND when
you want to use the delayed interrupt disable feature and your
hardware is not capable of retriggering an interrupt.)
The delayed interrupt disable is not configurable.
</para>
</sect2>
</sect1>
<sect1 id="Chiplevel_hardware_encapsulation">
<title>Chip-level hardware encapsulation</title>
<para>
The chip-level hardware descriptor structure irq_chip
contains all the direct chip relevant functions, which
can be utilized by the irq flow implementations.
<itemizedlist>
<listitem><para>irq_ack()</para></listitem>
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
<listitem><para>irq_mask()</para></listitem>
<listitem><para>irq_unmask()</para></listitem>
<listitem><para>irq_eoi() - Optional, required for EOI flow handlers</para></listitem>
<listitem><para>irq_retrigger() - Optional</para></listitem>
<listitem><para>irq_set_type() - Optional</para></listitem>
<listitem><para>irq_set_wake() - Optional</para></listitem>
</itemizedlist>
These primitives are strictly intended to mean what they say: ack means
ACK, masking means masking of an IRQ line, etc. It is up to the flow
handler(s) to use these basic units of low-level functionality.
</para>
</sect1>
</chapter>
<chapter id="doirq">
<title>__do_IRQ entry point</title>
<para>
The original implementation __do_IRQ() was an alternative entry
point for all types of interrupts. It no longer exists.
</para>
<para>
This handler turned out to be not suitable for all
interrupt hardware and was therefore reimplemented with split
functionality for edge/level/simple/percpu interrupts. This is not
only a functional optimization. It also shortens code paths for
interrupts.
</para>
</chapter>
<chapter id="locking">
<title>Locking on SMP</title>
<para>
The locking of chip registers is up to the architecture that
defines the chip primitives. The per-irq structure is
protected via desc->lock, by the generic layer.
</para>
</chapter>
<chapter id="genericchip">
<title>Generic interrupt chip</title>
<para>
To avoid copies of identical implementations of IRQ chips the
core provides a configurable generic interrupt chip
implementation. Developers should check carefully whether the
generic chip fits their needs before implementing the same
functionality slightly differently themselves.
</para>
!Ekernel/irq/generic-chip.c
</chapter>
<chapter id="structs">
<title>Structures</title>
<para>
This chapter contains the autogenerated documentation of the structures which are
used in the generic IRQ layer.
</para>
!Iinclude/linux/irq.h
!Iinclude/linux/interrupt.h
</chapter>
<chapter id="pubfunctions">
<title>Public Functions Provided</title>
<para>
This chapter contains the autogenerated documentation of the kernel API functions
which are exported.
</para>
!Ekernel/irq/manage.c
!Ekernel/irq/chip.c
</chapter>
<chapter id="intfunctions">
<title>Internal Functions Provided</title>
<para>
This chapter contains the autogenerated documentation of the internal functions.
</para>
!Ikernel/irq/irqdesc.c
!Ikernel/irq/handle.c
!Ikernel/irq/chip.c
</chapter>
<chapter id="credits">
<title>Credits</title>
<para>
The following people have contributed to this document:
<orderedlist>
<listitem><para>Thomas Gleixner<email>tglx@linutronix.de</email></para></listitem>
<listitem><para>Ingo Molnar<email>mingo@elte.hu</email></para></listitem>
</orderedlist>
</para>
</chapter>
</book>
Documentation/DocBook/kernel-api.tmpl 已删除 100644 → 0
浏览文件 @ c4beedb8
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="LinuxKernelAPI">
<bookinfo>
<title>The Linux Kernel API</title>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="adt">
<title>Data Types</title>
<sect1><title>Doubly Linked Lists</title>
!Iinclude/linux/list.h
</sect1>
</chapter>
<chapter id="libc">
<title>Basic C Library Functions</title>
<para>
When writing drivers, you cannot in general use routines which are
from the C Library. Some of the functions have been found generally
useful and they are listed below. The behaviour of these functions
may vary slightly from those defined by ANSI, and these deviations
are noted in the text.
</para>
<sect1><title>String Conversions</title>
!Elib/vsprintf.c
!Finclude/linux/kernel.h kstrtol
!Finclude/linux/kernel.h kstrtoul
!Elib/kstrtox.c
</sect1>
<sect1><title>String Manipulation</title>
<!-- All functions are exported at now
X!Ilib/string.c
-->
!Elib/string.c
</sect1>
<sect1><title>Bit Operations</title>
!Iarch/x86/include/asm/bitops.h
</sect1>
</chapter>
<chapter id="kernel-lib">
<title>Basic Kernel Library Functions</title>
<para>
The Linux kernel provides more basic utility functions.
</para>
<sect1><title>Bitmap Operations</title>
!Elib/bitmap.c
!Ilib/bitmap.c
</sect1>
<sect1><title>Command-line Parsing</title>
!Elib/cmdline.c
</sect1>
<sect1 id="crc"><title>CRC Functions</title>
!Elib/crc7.c
!Elib/crc16.c
!Elib/crc-itu-t.c
!Elib/crc32.c
!Elib/crc-ccitt.c
</sect1>
<sect1 id="idr"><title>idr/ida Functions</title>
!Pinclude/linux/idr.h idr sync
!Plib/idr.c IDA description
!Elib/idr.c
</sect1>
</chapter>
<chapter id="mm">
<title>Memory Management in Linux</title>
<sect1><title>The Slab Cache</title>
!Iinclude/linux/slab.h
!Emm/slab.c
!Emm/util.c
</sect1>
<sect1><title>User Space Memory Access</title>
!Iarch/x86/include/asm/uaccess_32.h
!Earch/x86/lib/usercopy_32.c
</sect1>
<sect1><title>More Memory Management Functions</title>
!Emm/readahead.c
!Emm/filemap.c
!Emm/memory.c
!Emm/vmalloc.c
!Imm/page_alloc.c
!Emm/mempool.c
!Emm/dmapool.c
!Emm/page-writeback.c
!Emm/truncate.c
</sect1>
</chapter>
<chapter id="ipc">
<title>Kernel IPC facilities</title>
<sect1><title>IPC utilities</title>
!Iipc/util.c
</sect1>
</chapter>
<chapter id="kfifo">
<title>FIFO Buffer</title>
<sect1><title>kfifo interface</title>
!Iinclude/linux/kfifo.h
</sect1>
</chapter>
<chapter id="relayfs">
<title>relay interface support</title>
<para>
Relay interface support
is designed to provide an efficient mechanism for tools and
facilities to relay large amounts of data from kernel space to
user space.
</para>
<sect1><title>relay interface</title>
!Ekernel/relay.c
!Ikernel/relay.c
</sect1>
</chapter>
<chapter id="modload">
<title>Module Support</title>
<sect1><title>Module Loading</title>
!Ekernel/kmod.c
</sect1>
<sect1><title>Inter Module support</title>
<para>
Refer to the file kernel/module.c for more information.
</para>
<!-- FIXME: Removed for now since no structured comments in source
X!Ekernel/module.c
-->
</sect1>
</chapter>
<chapter id="hardware">
<title>Hardware Interfaces</title>
<sect1><title>Interrupt Handling</title>
!Ekernel/irq/manage.c
</sect1>
<sect1><title>DMA Channels</title>
!Ekernel/dma.c
</sect1>
<sect1><title>Resources Management</title>
!Ikernel/resource.c
!Ekernel/resource.c
</sect1>
<sect1><title>MTRR Handling</title>
!Earch/x86/kernel/cpu/mtrr/main.c
</sect1>
<sect1><title>PCI Support Library</title>
!Edrivers/pci/pci.c
!Edrivers/pci/pci-driver.c
!Edrivers/pci/remove.c
!Edrivers/pci/search.c
!Edrivers/pci/msi.c
!Edrivers/pci/bus.c
!Edrivers/pci/access.c
!Edrivers/pci/irq.c
!Edrivers/pci/htirq.c
<!-- FIXME: Removed for now since no structured comments in source
X!Edrivers/pci/hotplug.c
-->
!Edrivers/pci/probe.c
!Edrivers/pci/slot.c
!Edrivers/pci/rom.c
!Edrivers/pci/iov.c
!Idrivers/pci/pci-sysfs.c
</sect1>
<sect1><title>PCI Hotplug Support Library</title>
!Edrivers/pci/hotplug/pci_hotplug_core.c
</sect1>
</chapter>
<chapter id="firmware">
<title>Firmware Interfaces</title>
<sect1><title>DMI Interfaces</title>
!Edrivers/firmware/dmi_scan.c
</sect1>
<sect1><title>EDD Interfaces</title>
!Idrivers/firmware/edd.c
</sect1>
</chapter>
<chapter id="security">
<title>Security Framework</title>
!Isecurity/security.c
!Esecurity/inode.c
</chapter>
<chapter id="audit">
<title>Audit Interfaces</title>
!Ekernel/audit.c
!Ikernel/auditsc.c
!Ikernel/auditfilter.c
</chapter>
<chapter id="accounting">
<title>Accounting Framework</title>
!Ikernel/acct.c
</chapter>
<chapter id="blkdev">
<title>Block Devices</title>
!Eblock/blk-core.c
!Iblock/blk-core.c
!Eblock/blk-map.c
!Iblock/blk-sysfs.c
!Eblock/blk-settings.c
!Eblock/blk-exec.c
!Eblock/blk-flush.c
!Eblock/blk-lib.c
!Eblock/blk-tag.c
!Iblock/blk-tag.c
!Eblock/blk-integrity.c
!Ikernel/trace/blktrace.c
!Iblock/genhd.c
!Eblock/genhd.c
</chapter>
<chapter id="chrdev">
<title>Char devices</title>
!Efs/char_dev.c
</chapter>
<chapter id="miscdev">
<title>Miscellaneous Devices</title>
!Edrivers/char/misc.c
</chapter>
<chapter id="clk">
<title>Clock Framework</title>
<para>
The clock framework defines programming interfaces to support
software management of the system clock tree.
This framework is widely used with System-On-Chip (SOC) platforms
to support power management and various devices which may need
custom clock rates.
Note that these "clocks" don't relate to timekeeping or real
time clocks (RTCs), each of which have separate frameworks.
These <structname>struct clk</structname> instances may be used
to manage for example a 96 MHz signal that is used to shift bits
into and out of peripherals or busses, or otherwise trigger
synchronous state machine transitions in system hardware.
</para>
<para>
Power management is supported by explicit software clock gating:
unused clocks are disabled, so the system doesn't waste power
changing the state of transistors that aren't in active use.
On some systems this may be backed by hardware clock gating,
where clocks are gated without being disabled in software.
Sections of chips that are powered but not clocked may be able
to retain their last state.
This low power state is often called a <emphasis>retention
mode</emphasis>.
This mode still incurs leakage currents, especially with finer
circuit geometries, but for CMOS circuits power is mostly used
by clocked state changes.
</para>
<para>
Power-aware drivers only enable their clocks when the device
they manage is in active use. Also, system sleep states often
differ according to which clock domains are active: while a
"standby" state may allow wakeup from several active domains, a
"mem" (suspend-to-RAM) state may require a more wholesale shutdown
of clocks derived from higher speed PLLs and oscillators, limiting
the number of possible wakeup event sources. A driver's suspend
method may need to be aware of system-specific clock constraints
on the target sleep state.
</para>
<para>
Some platforms support programmable clock generators. These
can be used by external chips of various kinds, such as other
CPUs, multimedia codecs, and devices with strict requirements
for interface clocking.
</para>
!Iinclude/linux/clk.h
</chapter>
</book>
Documentation/DocBook/rapidio.tmpl
浏览文件 @ eadcbfa5
......@@ -128,9 +128,6 @@
</sect1>
<sect1 id="Device_model_support"><title>Device model support</title>
!Idrivers/rapidio/rio-driver.c
</sect1>
<sect1 id="Sysfs_support"><title>Sysfs support</title>
!Idrivers/rapidio/rio-sysfs.c
</sect1>
<sect1 id="PPC32_support"><title>PPC32 support</title>
!Iarch/powerpc/sysdev/fsl_rio.c
......
Documentation/DocBook/writing_usb_driver.tmpl 已删除 100644 → 0
浏览文件 @ c4beedb8
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="USBDeviceDriver">
<bookinfo>
<title>Writing USB Device Drivers</title>
<authorgroup>
<author>
<firstname>Greg</firstname>
<surname>Kroah-Hartman</surname>
<affiliation>
<address>
<email>greg@kroah.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2001-2002</year>
<holder>Greg Kroah-Hartman</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
<para>
This documentation is based on an article published in
Linux Journal Magazine, October 2001, Issue 90.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="intro">
<title>Introduction</title>
<para>
The Linux USB subsystem has grown from supporting only two different
types of devices in the 2.2.7 kernel (mice and keyboards), to over 20
different types of devices in the 2.4 kernel. Linux currently supports
almost all USB class devices (standard types of devices like keyboards,
mice, modems, printers and speakers) and an ever-growing number of
vendor-specific devices (such as USB to serial converters, digital
cameras, Ethernet devices and MP3 players). For a full list of the
different USB devices currently supported, see Resources.
</para>
<para>
The remaining kinds of USB devices that do not have support on Linux are
almost all vendor-specific devices. Each vendor decides to implement a
custom protocol to talk to their device, so a custom driver usually needs
to be created. Some vendors are open with their USB protocols and help
with the creation of Linux drivers, while others do not publish them, and
developers are forced to reverse-engineer. See Resources for some links
to handy reverse-engineering tools.
</para>
<para>
Because each different protocol causes a new driver to be created, I have
written a generic USB driver skeleton, modelled after the pci-skeleton.c
file in the kernel source tree upon which many PCI network drivers have
been based. This USB skeleton can be found at drivers/usb/usb-skeleton.c
in the kernel source tree. In this article I will walk through the basics
of the skeleton driver, explaining the different pieces and what needs to
be done to customize it to your specific device.
</para>
</chapter>
<chapter id="basics">
<title>Linux USB Basics</title>
<para>
If you are going to write a Linux USB driver, please become familiar with
the USB protocol specification. It can be found, along with many other
useful documents, at the USB home page (see Resources). An excellent
introduction to the Linux USB subsystem can be found at the USB Working
Devices List (see Resources). It explains how the Linux USB subsystem is
structured and introduces the reader to the concept of USB urbs
(USB Request Blocks), which are essential to USB drivers.
</para>
<para>
The first thing a Linux USB driver needs to do is register itself with
the Linux USB subsystem, giving it some information about which devices
the driver supports and which functions to call when a device supported
by the driver is inserted or removed from the system. All of this
information is passed to the USB subsystem in the usb_driver structure.
The skeleton driver declares a usb_driver as:
</para>
<programlisting>
static struct usb_driver skel_driver = {
.name = "skeleton",
.probe = skel_probe,
.disconnect = skel_disconnect,
.fops = &amp;skel_fops,
.minor = USB_SKEL_MINOR_BASE,
.id_table = skel_table,
};
</programlisting>
<para>
The variable name is a string that describes the driver. It is used in
informational messages printed to the system log. The probe and
disconnect function pointers are called when a device that matches the
information provided in the id_table variable is either seen or removed.
</para>
<para>
The fops and minor variables are optional. Most USB drivers hook into
another kernel subsystem, such as the SCSI, network or TTY subsystem.
These types of drivers register themselves with the other kernel
subsystem, and any user-space interactions are provided through that
interface. But for drivers that do not have a matching kernel subsystem,
such as MP3 players or scanners, a method of interacting with user space
is needed. The USB subsystem provides a way to register a minor device
number and a set of file_operations function pointers that enable this
user-space interaction. The skeleton driver needs this kind of interface,
so it provides a minor starting number and a pointer to its
file_operations functions.
</para>
<para>
The USB driver is then registered with a call to usb_register, usually in
the driver's init function, as shown here:
</para>
<programlisting>
static int __init usb_skel_init(void)
{
int result;
/* register this driver with the USB subsystem */
result = usb_register(&amp;skel_driver);
if (result &lt; 0) {
err(&quot;usb_register failed for the &quot;__FILE__ &quot;driver.&quot;
&quot;Error number %d&quot;, result);
return -1;
}
return 0;
}
module_init(usb_skel_init);
</programlisting>
<para>
When the driver is unloaded from the system, it needs to deregister
itself with the USB subsystem. This is done with the usb_deregister
function:
</para>
<programlisting>
static void __exit usb_skel_exit(void)
{
/* deregister this driver with the USB subsystem */
usb_deregister(&amp;skel_driver);
}
module_exit(usb_skel_exit);
</programlisting>
<para>
To enable the linux-hotplug system to load the driver automatically when
the device is plugged in, you need to create a MODULE_DEVICE_TABLE. The
following code tells the hotplug scripts that this module supports a
single device with a specific vendor and product ID:
</para>
<programlisting>
/* table of devices that work with this driver */
static struct usb_device_id skel_table [] = {
{ USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, skel_table);
</programlisting>
<para>
There are other macros that can be used in describing a usb_device_id for
drivers that support a whole class of USB drivers. See usb.h for more
information on this.
</para>
</chapter>
<chapter id="device">
<title>Device operation</title>
<para>
When a device is plugged into the USB bus that matches the device ID
pattern that your driver registered with the USB core, the probe function
is called. The usb_device structure, interface number and the interface ID
are passed to the function:
</para>
<programlisting>
static int skel_probe(struct usb_interface *interface,
const struct usb_device_id *id)
</programlisting>
<para>
The driver now needs to verify that this device is actually one that it
can accept. If so, it returns 0.
If not, or if any error occurs during initialization, an errorcode
(such as <literal>-ENOMEM</literal> or <literal>-ENODEV</literal>)
is returned from the probe function.
</para>
<para>
In the skeleton driver, we determine what end points are marked as bulk-in
and bulk-out. We create buffers to hold the data that will be sent and
received from the device, and a USB urb to write data to the device is
initialized.
</para>
<para>
Conversely, when the device is removed from the USB bus, the disconnect
function is called with the device pointer. The driver needs to clean any
private data that has been allocated at this time and to shut down any
pending urbs that are in the USB system.
</para>
<para>
Now that the device is plugged into the system and the driver is bound to
the device, any of the functions in the file_operations structure that
were passed to the USB subsystem will be called from a user program trying
to talk to the device. The first function called will be open, as the
program tries to open the device for I/O. We increment our private usage
count and save a pointer to our internal structure in the file
structure. This is done so that future calls to file operations will
enable the driver to determine which device the user is addressing. All
of this is done with the following code:
</para>
<programlisting>
/* increment our usage count for the module */
++skel->open_count;
/* save our object in the file's private structure */
file->private_data = dev;
</programlisting>
<para>
After the open function is called, the read and write functions are called
to receive and send data to the device. In the skel_write function, we
receive a pointer to some data that the user wants to send to the device
and the size of the data. The function determines how much data it can
send to the device based on the size of the write urb it has created (this
size depends on the size of the bulk out end point that the device has).
Then it copies the data from user space to kernel space, points the urb to
the data and submits the urb to the USB subsystem. This can be seen in
the following code:
</para>
<programlisting>
/* we can only write as much as 1 urb will hold */
bytes_written = (count > skel->bulk_out_size) ? skel->bulk_out_size : count;
/* copy the data from user space into our urb */
copy_from_user(skel->write_urb->transfer_buffer, buffer, bytes_written);
/* set up our urb */
usb_fill_bulk_urb(skel->write_urb,
skel->dev,
usb_sndbulkpipe(skel->dev, skel->bulk_out_endpointAddr),
skel->write_urb->transfer_buffer,
bytes_written,
skel_write_bulk_callback,
skel);
/* send the data out the bulk port */
result = usb_submit_urb(skel->write_urb);
if (result) {
err(&quot;Failed submitting write urb, error %d&quot;, result);
}
</programlisting>
<para>
When the write urb is filled up with the proper information using the
usb_fill_bulk_urb function, we point the urb's completion callback to call our
own skel_write_bulk_callback function. This function is called when the
urb is finished by the USB subsystem. The callback function is called in
interrupt context, so caution must be taken not to do very much processing
at that time. Our implementation of skel_write_bulk_callback merely
reports if the urb was completed successfully or not and then returns.
</para>
<para>
The read function works a bit differently from the write function in that
we do not use an urb to transfer data from the device to the driver.
Instead we call the usb_bulk_msg function, which can be used to send or
receive data from a device without having to create urbs and handle
urb completion callback functions. We call the usb_bulk_msg function,
giving it a buffer into which to place any data received from the device
and a timeout value. If the timeout period expires without receiving any
data from the device, the function will fail and return an error message.
This can be shown with the following code:
</para>
<programlisting>
/* do an immediate bulk read to get data from the device */
retval = usb_bulk_msg (skel->dev,
usb_rcvbulkpipe (skel->dev,
skel->bulk_in_endpointAddr),
skel->bulk_in_buffer,
skel->bulk_in_size,
&amp;count, HZ*10);
/* if the read was successful, copy the data to user space */
if (!retval) {
if (copy_to_user (buffer, skel->bulk_in_buffer, count))
retval = -EFAULT;
else
retval = count;
}
</programlisting>
<para>
The usb_bulk_msg function can be very useful for doing single reads or
writes to a device; however, if you need to read or write constantly to a
device, it is recommended to set up your own urbs and submit them to the
USB subsystem.
</para>
<para>
When the user program releases the file handle that it has been using to
talk to the device, the release function in the driver is called. In this
function we decrement our private usage count and wait for possible
pending writes:
</para>
<programlisting>
/* decrement our usage count for the device */
--skel->open_count;
</programlisting>
<para>
One of the more difficult problems that USB drivers must be able to handle
smoothly is the fact that the USB device may be removed from the system at
any point in time, even if a program is currently talking to it. It needs
to be able to shut down any current reads and writes and notify the
user-space programs that the device is no longer there. The following
code (function <function>skel_delete</function>)
is an example of how to do this: </para>
<programlisting>
static inline void skel_delete (struct usb_skel *dev)
{
kfree (dev->bulk_in_buffer);
if (dev->bulk_out_buffer != NULL)
usb_free_coherent (dev->udev, dev->bulk_out_size,
dev->bulk_out_buffer,
dev->write_urb->transfer_dma);
usb_free_urb (dev->write_urb);
kfree (dev);
}
</programlisting>
<para>
If a program currently has an open handle to the device, we reset the flag
<literal>device_present</literal>. For
every read, write, release and other functions that expect a device to be
present, the driver first checks this flag to see if the device is
still present. If not, it releases that the device has disappeared, and a
-ENODEV error is returned to the user-space program. When the release
function is eventually called, it determines if there is no device
and if not, it does the cleanup that the skel_disconnect
function normally does if there are no open files on the device (see
Listing 5).
</para>
</chapter>
<chapter id="iso">
<title>Isochronous Data</title>
<para>
This usb-skeleton driver does not have any examples of interrupt or
isochronous data being sent to or from the device. Interrupt data is sent
almost exactly as bulk data is, with a few minor exceptions. Isochronous
data works differently with continuous streams of data being sent to or
from the device. The audio and video camera drivers are very good examples
of drivers that handle isochronous data and will be useful if you also
need to do this.
</para>
</chapter>
<chapter id="Conclusion">
<title>Conclusion</title>
<para>
Writing Linux USB device drivers is not a difficult task as the
usb-skeleton driver shows. This driver, combined with the other current
USB drivers, should provide enough examples to help a beginning author
create a working driver in a minimal amount of time. The linux-usb-devel
mailing list archives also contain a lot of helpful information.
</para>
</chapter>
<chapter id="resources">
<title>Resources</title>
<para>
The Linux USB Project: <ulink url="http://www.linux-usb.org">http://www.linux-usb.org/</ulink>
</para>
<para>
Linux Hotplug Project: <ulink url="http://linux-hotplug.sourceforge.net">http://linux-hotplug.sourceforge.net/</ulink>
</para>
<para>
Linux USB Working Devices List: <ulink url="http://www.qbik.ch/usb/devices">http://www.qbik.ch/usb/devices/</ulink>
</para>
<para>
linux-usb-devel Mailing List Archives: <ulink url="http://marc.theaimsgroup.com/?l=linux-usb-devel">http://marc.theaimsgroup.com/?l=linux-usb-devel</ulink>
</para>
<para>
Programming Guide for Linux USB Device Drivers: <ulink url="http://usb.cs.tum.edu/usbdoc">http://usb.cs.tum.edu/usbdoc</ulink>
</para>
<para>
USB Home Page: <ulink url="http://www.usb.org">http://www.usb.org</ulink>
</para>
</chapter>
</book>
Documentation/EDID/edid.S
浏览文件 @ eadcbfa5
......@@ -59,9 +59,9 @@
/* Fixed header pattern */
header: .byte 0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00
mfg_id: .word swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
mfg_id: .hword swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
prod_code: .word 0
prod_code: .hword 0
/* Serial number. 32 bits, little endian. */
serial_number: .long SERIAL
......@@ -177,7 +177,7 @@ std_vres: .byte (XY_RATIO<<6)+VFREQ-60
descriptor1:
/* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */
clock: .word CLOCK/10
clock: .hword CLOCK/10
/* Horizontal active pixels 8 lsbits (0-4095) */
x_act_lsb: .byte XPIX&0xff
......
Documentation/PCI/00-INDEX
浏览文件 @ eadcbfa5
......@@ -12,3 +12,13 @@ pci.txt
- info on the PCI subsystem for device driver authors
pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
endpoint/pci-endpoint.txt
- guide to add endpoint controller driver and endpoint function driver.
endpoint/pci-endpoint-cfs.txt
- guide to use configfs to configure the PCI endpoint function.
endpoint/pci-test-function.txt
- specification of *PCI test* function device.
endpoint/pci-test-howto.txt
- userguide for PCI endpoint test function.
endpoint/function/binding/
- binding documentation for PCI endpoint function
Documentation/PCI/endpoint/function/binding/pci-test.txt 0 → 100644
浏览文件 @ eadcbfa5
PCI TEST ENDPOINT FUNCTION
name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
Configurable Fields:
vendorid : should be 0x104c
deviceid : should be 0xb500 for DRA74x and 0xb501 for DRA72x
revid : don't care
progif_code : don't care
subclass_code : don't care
baseclass_code : should be 0xff
cache_line_size : don't care
subsys_vendor_id : don't care
subsys_id : don't care
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
to test
Documentation/PCI/endpoint/pci-endpoint-cfs.txt 0 → 100644
浏览文件 @ eadcbfa5
CONFIGURING PCI ENDPOINT USING CONFIGFS
Kishon Vijay Abraham I <kishon@ti.com>
The PCI Endpoint Core exposes configfs entry (pci_ep) to configure the
PCI endpoint function and to bind the endpoint function
with the endpoint controller. (For introducing other mechanisms to
configure the PCI Endpoint Function refer to [1]).
*) Mounting configfs
The PCI Endpoint Core layer creates pci_ep directory in the mounted configfs
directory. configfs can be mounted using the following command.
mount -t configfs none /sys/kernel/config
*) Directory Structure
The pci_ep configfs has two directories at its root: controllers and
functions. Every EPC device present in the system will have an entry in
the *controllers* directory and and every EPF driver present in the system
will have an entry in the *functions* directory.
/sys/kernel/config/pci_ep/
.. controllers/
.. functions/
*) Creating EPF Device
Every registered EPF driver will be listed in controllers directory. The
entries corresponding to EPF driver will be created by the EPF core.
/sys/kernel/config/pci_ep/functions/
.. <EPF Driver1>/
... <EPF Device 11>/
... <EPF Device 21>/
.. <EPF Driver2>/
... <EPF Device 12>/
... <EPF Device 22>/
In order to create a <EPF device> of the type probed by <EPF Driver>, the
user has to create a directory inside <EPF DriverN>.
Every <EPF device> directory consists of the following entries that can be
used to configure the standard configuration header of the endpoint function.
(These entries are created by the framework when any new <EPF Device> is
created)
.. <EPF Driver1>/
... <EPF Device 11>/
... vendorid
... deviceid
... revid
... progif_code
... subclass_code
... baseclass_code
... cache_line_size
... subsys_vendor_id
... subsys_id
... interrupt_pin
*) EPC Device
Every registered EPC device will be listed in controllers directory. The
entries corresponding to EPC device will be created by the EPC core.
/sys/kernel/config/pci_ep/controllers/
.. <EPC Device1>/
... <Symlink EPF Device11>/
... <Symlink EPF Device12>/
... start
.. <EPC Device2>/
... <Symlink EPF Device21>/
... <Symlink EPF Device22>/
... start
The <EPC Device> directory will have a list of symbolic links to
<EPF Device>. These symbolic links should be created by the user to
represent the functions present in the endpoint device.
The <EPC Device> directory will also have a *start* field. Once
"1" is written to this field, the endpoint device will be ready to
establish the link with the host. This is usually done after
all the EPF devices are created and linked with the EPC device.
| controllers/
| <Directory: EPC name>/
| <Symbolic Link: Function>
| start
| functions/
| <Directory: EPF driver>/
| <Directory: EPF device>/
| vendorid
| deviceid
| revid
| progif_code
| subclass_code
| baseclass_code
| cache_line_size
| subsys_vendor_id
| subsys_id
| interrupt_pin
| function
[1] -> Documentation/PCI/endpoint/pci-endpoint.txt
Documentation/PCI/endpoint/pci-endpoint.txt 0 → 100644
浏览文件 @ eadcbfa5
PCI ENDPOINT FRAMEWORK
Kishon Vijay Abraham I <kishon@ti.com>
This document is a guide to use the PCI Endpoint Framework in order to create
endpoint controller driver, endpoint function driver, and using configfs
interface to bind the function driver to the controller driver.
1. Introduction
Linux has a comprehensive PCI subsystem to support PCI controllers that
operates in Root Complex mode. The subsystem has capability to scan PCI bus,
assign memory resources and IRQ resources, load PCI driver (based on
vendor ID, device ID), support other services like hot-plug, power management,
advanced error reporting and virtual channels.
However the PCI controller IP integrated in some SoCs is capable of operating
either in Root Complex mode or Endpoint mode. PCI Endpoint Framework will
add endpoint mode support in Linux. This will help to run Linux in an
EP system which can have a wide variety of use cases from testing or
validation, co-processor accelerator, etc.
2. PCI Endpoint Core
The PCI Endpoint Core layer comprises 3 components: the Endpoint Controller
library, the Endpoint Function library, and the configfs layer to bind the
endpoint function with the endpoint controller.
2.1 PCI Endpoint Controller(EPC) Library
The EPC library provides APIs to be used by the controller that can operate
in endpoint mode. It also provides APIs to be used by function driver/library
in order to implement a particular endpoint function.
2.1.1 APIs for the PCI controller Driver
This section lists the APIs that the PCI Endpoint core provides to be used
by the PCI controller driver.
*) devm_pci_epc_create()/pci_epc_create()
The PCI controller driver should implement the following ops:
* write_header: ops to populate configuration space header
* set_bar: ops to configure the BAR
* clear_bar: ops to reset the BAR
* alloc_addr_space: ops to allocate in PCI controller address space
* free_addr_space: ops to free the allocated address space
* raise_irq: ops to raise a legacy or MSI interrupt
* start: ops to start the PCI link
* stop: ops to stop the PCI link
The PCI controller driver can then create a new EPC device by invoking
devm_pci_epc_create()/pci_epc_create().
*) devm_pci_epc_destroy()/pci_epc_destroy()
The PCI controller driver can destroy the EPC device created by either
devm_pci_epc_create() or pci_epc_create() using devm_pci_epc_destroy() or
pci_epc_destroy().
*) pci_epc_linkup()
In order to notify all the function devices that the EPC device to which
they are linked has established a link with the host, the PCI controller
driver should invoke pci_epc_linkup().
*) pci_epc_mem_init()
Initialize the pci_epc_mem structure used for allocating EPC addr space.
*) pci_epc_mem_exit()
Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init().
2.1.2 APIs for the PCI Endpoint Function Driver
This section lists the APIs that the PCI Endpoint core provides to be used
by the PCI endpoint function driver.
*) pci_epc_write_header()
The PCI endpoint function driver should use pci_epc_write_header() to
write the standard configuration header to the endpoint controller.
*) pci_epc_set_bar()
The PCI endpoint function driver should use pci_epc_set_bar() to configure
the Base Address Register in order for the host to assign PCI addr space.
Register space of the function driver is usually configured
using this API.
*) pci_epc_clear_bar()
The PCI endpoint function driver should use pci_epc_clear_bar() to reset
the BAR.
*) pci_epc_raise_irq()
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
Legacy Interrupt or MSI Interrupt.
*) pci_epc_mem_alloc_addr()
The PCI endpoint function driver should use pci_epc_mem_alloc_addr(), to
allocate memory address from EPC addr space which is required to access
RC's buffer
*) pci_epc_mem_free_addr()
The PCI endpoint function driver should use pci_epc_mem_free_addr() to
free the memory space allocated using pci_epc_mem_alloc_addr().
2.1.3 Other APIs
There are other APIs provided by the EPC library. These are used for binding
the EPF device with EPC device. pci-ep-cfs.c can be used as reference for
using these APIs.
*) pci_epc_get()
Get a reference to the PCI endpoint controller based on the device name of
the controller.
*) pci_epc_put()
Release the reference to the PCI endpoint controller obtained using
pci_epc_get()
*) pci_epc_add_epf()
Add a PCI endpoint function to a PCI endpoint controller. A PCIe device
can have up to 8 functions according to the specification.
*) pci_epc_remove_epf()
Remove the PCI endpoint function from PCI endpoint controller.
*) pci_epc_start()
The PCI endpoint function driver should invoke pci_epc_start() once it
has configured the endpoint function and wants to start the PCI link.
*) pci_epc_stop()
The PCI endpoint function driver should invoke pci_epc_stop() to stop
the PCI LINK.
2.2 PCI Endpoint Function(EPF) Library
The EPF library provides APIs to be used by the function driver and the EPC
library to provide endpoint mode functionality.
2.2.1 APIs for the PCI Endpoint Function Driver
This section lists the APIs that the PCI Endpoint core provides to be used
by the PCI endpoint function driver.
*) pci_epf_register_driver()
The PCI Endpoint Function driver should implement the following ops:
* bind: ops to perform when a EPC device has been bound to EPF device
* unbind: ops to perform when a binding has been lost between a EPC
device and EPF device
* linkup: ops to perform when the EPC device has established a
connection with a host system
The PCI Function driver can then register the PCI EPF driver by using
pci_epf_register_driver().
*) pci_epf_unregister_driver()
The PCI Function driver can unregister the PCI EPF driver by using
pci_epf_unregister_driver().
*) pci_epf_alloc_space()
The PCI Function driver can allocate space for a particular BAR using
pci_epf_alloc_space().
*) pci_epf_free_space()
The PCI Function driver can free the allocated space
(using pci_epf_alloc_space) by invoking pci_epf_free_space().
2.2.2 APIs for the PCI Endpoint Controller Library
This section lists the APIs that the PCI Endpoint core provides to be used
by the PCI endpoint controller library.
*) pci_epf_linkup()
The PCI endpoint controller library invokes pci_epf_linkup() when the
EPC device has established the connection to the host.
2.2.2 Other APIs
There are other APIs provided by the EPF library. These are used to notify
the function driver when the EPF device is bound to the EPC device.
pci-ep-cfs.c can be used as reference for using these APIs.
*) pci_epf_create()
Create a new PCI EPF device by passing the name of the PCI EPF device.
This name will be used to bind the the EPF device to a EPF driver.
*) pci_epf_destroy()
Destroy the created PCI EPF device.
*) pci_epf_bind()
pci_epf_bind() should be invoked when the EPF device has been bound to
a EPC device.
*) pci_epf_unbind()
pci_epf_unbind() should be invoked when the binding between EPC device
and EPF device is lost.
Documentation/PCI/endpoint/pci-test-function.txt 0 → 100644
浏览文件 @ eadcbfa5
PCI TEST
Kishon Vijay Abraham I <kishon@ti.com>
Traditionally PCI RC has always been validated by using standard
PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
However with the addition of EP-core in linux kernel, it is possible
to configure a PCI controller that can operate in EP mode to work as
a test device.
The PCI endpoint test device is a virtual device (defined in software)
used to test the endpoint functionality and serve as a sample driver
for other PCI endpoint devices (to use the EP framework).
The PCI endpoint test device has the following registers:
1) PCI_ENDPOINT_TEST_MAGIC
2) PCI_ENDPOINT_TEST_COMMAND
3) PCI_ENDPOINT_TEST_STATUS
4) PCI_ENDPOINT_TEST_SRC_ADDR
5) PCI_ENDPOINT_TEST_DST_ADDR
6) PCI_ENDPOINT_TEST_SIZE
7) PCI_ENDPOINT_TEST_CHECKSUM
*) PCI_ENDPOINT_TEST_MAGIC
This register will be used to test BAR0. A known pattern will be written
and read back from MAGIC register to verify BAR0.
*) PCI_ENDPOINT_TEST_COMMAND:
This register will be used by the host driver to indicate the function
that the endpoint device must perform.
Bitfield Description:
Bit 0 : raise legacy IRQ
Bit 1 : raise MSI IRQ
Bit 2 - 7 : MSI interrupt number
Bit 8 : read command (read data from RC buffer)
Bit 9 : write command (write data to RC buffer)
Bit 10 : copy command (copy data from one RC buffer to another
RC buffer)
*) PCI_ENDPOINT_TEST_STATUS
This register reflects the status of the PCI endpoint device.
Bitfield Description:
Bit 0 : read success
Bit 1 : read fail
Bit 2 : write success
Bit 3 : write fail
Bit 4 : copy success
Bit 5 : copy fail
Bit 6 : IRQ raised
Bit 7 : source address is invalid
Bit 8 : destination address is invalid
*) PCI_ENDPOINT_TEST_SRC_ADDR
This register contains the source address (RC buffer address) for the
COPY/READ command.
*) PCI_ENDPOINT_TEST_DST_ADDR
This register contains the destination address (RC buffer address) for
the COPY/WRITE command.
Documentation/PCI/endpoint/pci-test-howto.txt 0 → 100644
浏览文件 @ eadcbfa5
PCI TEST USERGUIDE
Kishon Vijay Abraham I <kishon@ti.com>
This document is a guide to help users use pci-epf-test function driver
and pci_endpoint_test host driver for testing PCI. The list of steps to
be followed in the host side and EP side is given below.
1. Endpoint Device
1.1 Endpoint Controller Devices
To find the list of endpoint controller devices in the system:
# ls /sys/class/pci_epc/
51000000.pcie_ep
If PCI_ENDPOINT_CONFIGFS is enabled
# ls /sys/kernel/config/pci_ep/controllers
51000000.pcie_ep
1.2 Endpoint Function Drivers
To find the list of endpoint function drivers in the system:
# ls /sys/bus/pci-epf/drivers
pci_epf_test
If PCI_ENDPOINT_CONFIGFS is enabled
# ls /sys/kernel/config/pci_ep/functions
pci_epf_test
1.3 Creating pci-epf-test Device
PCI endpoint function device can be created using the configfs. To create
pci-epf-test device, the following commands can be used
# mount -t configfs none /sys/kernel/config
# cd /sys/kernel/config/pci_ep/
# mkdir functions/pci_epf_test/func1
The "mkdir func1" above creates the pci-epf-test function device that will
be probed by pci_epf_test driver.
The PCI endpoint framework populates the directory with the following
configurable fields.
# ls functions/pci_epf_test/func1
baseclass_code interrupt_pin revid subsys_vendor_id
cache_line_size msi_interrupts subclass_code vendorid
deviceid progif_code subsys_id
The PCI endpoint function driver populates these entries with default values
when the device is bound to the driver. The pci-epf-test driver populates
vendorid with 0xffff and interrupt_pin with 0x0001
# cat functions/pci_epf_test/func1/vendorid
0xffff
# cat functions/pci_epf_test/func1/interrupt_pin
0x0001
1.4 Configuring pci-epf-test Device
The user can configure the pci-epf-test device using configfs entry. In order
to change the vendorid and the number of MSI interrupts used by the function
device, the following commands can be used.
# echo 0x104c > functions/pci_epf_test/func1/vendorid
# echo 0xb500 > functions/pci_epf_test/func1/deviceid
# echo 16 > functions/pci_epf_test/func1/msi_interrupts
1.5 Binding pci-epf-test Device to EP Controller
In order for the endpoint function device to be useful, it has to be bound to
a PCI endpoint controller driver. Use the configfs to bind the function
device to one of the controller driver present in the system.
# ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/
Once the above step is completed, the PCI endpoint is ready to establish a link
with the host.
1.6 Start the Link
In order for the endpoint device to establish a link with the host, the _start_
field should be populated with '1'.
# echo 1 > controllers/51000000.pcie_ep/start
2. RootComplex Device
2.1 lspci Output
Note that the devices listed here correspond to the value populated in 1.4 above
00:00.0 PCI bridge: Texas Instruments Device 8888 (rev 01)
01:00.0 Unassigned class [ff00]: Texas Instruments Device b500
2.2 Using Endpoint Test function Device
pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
tests. Before pcitest.sh can be used pcitest.c should be compiled using the
following commands.
cd <kernel-dir>
make headers_install ARCH=arm
arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest
cp pcitest <rootfs>/usr/sbin/
cp tools/pci/pcitest.sh <rootfs>
2.2.1 pcitest.sh Output
# ./pcitest.sh
BAR tests
BAR0: OKAY
BAR1: OKAY
BAR2: OKAY
BAR3: OKAY
BAR4: NOT OKAY
BAR5: NOT OKAY
Interrupt tests
LEGACY IRQ: NOT OKAY
MSI1: OKAY
MSI2: OKAY
MSI3: OKAY
MSI4: OKAY
MSI5: OKAY
MSI6: OKAY
MSI7: OKAY
MSI8: OKAY
MSI9: OKAY
MSI10: OKAY
MSI11: OKAY
MSI12: OKAY
MSI13: OKAY
MSI14: OKAY
MSI15: OKAY
MSI16: OKAY
MSI17: NOT OKAY
MSI18: NOT OKAY
MSI19: NOT OKAY
MSI20: NOT OKAY
MSI21: NOT OKAY
MSI22: NOT OKAY
MSI23: NOT OKAY
MSI24: NOT OKAY
MSI25: NOT OKAY
MSI26: NOT OKAY
MSI27: NOT OKAY
MSI28: NOT OKAY
MSI29: NOT OKAY
MSI30: NOT OKAY
MSI31: NOT OKAY
MSI32: NOT OKAY
Read Tests
READ ( 1 bytes): OKAY
READ ( 1024 bytes): OKAY
READ ( 1025 bytes): OKAY
READ (1024000 bytes): OKAY
READ (1024001 bytes): OKAY
Write Tests
WRITE ( 1 bytes): OKAY
WRITE ( 1024 bytes): OKAY
WRITE ( 1025 bytes): OKAY
WRITE (1024000 bytes): OKAY
WRITE (1024001 bytes): OKAY
Copy Tests
COPY ( 1 bytes): OKAY
COPY ( 1024 bytes): OKAY
COPY ( 1025 bytes): OKAY
COPY (1024000 bytes): OKAY
COPY (1024001 bytes): OKAY
Documentation/PCI/pci-error-recovery.txt
浏览文件 @ eadcbfa5
......@@ -11,7 +11,7 @@
Many PCI bus controllers are able to detect a variety of hardware
PCI errors on the bus, such as parity errors on the data and address
busses, as well as SERR and PERR errors. Some of the more advanced
buses, as well as SERR and PERR errors. Some of the more advanced
chipsets are able to deal with these errors; these include PCI-E chipsets,
and the PCI-host bridges found on IBM Power4, Power5 and Power6-based
pSeries boxes. A typical action taken is to disconnect the affected device,
......@@ -173,7 +173,7 @@ is STEP 6 (Permanent Failure).
>>> a value of 0xff on read, and writes will be dropped. If more than
>>> EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH
>>> assumes that the device driver has gone into an infinite loop
>>> and prints an error to syslog. A reboot is then required to
>>> and prints an error to syslog. A reboot is then required to
>>> get the device working again.
STEP 2: MMIO Enabled
......@@ -231,14 +231,14 @@ proceeds to STEP 4 (Slot Reset)
STEP 3: Link Reset
------------------
The platform resets the link. This is a PCI-Express specific step
and is done whenever a non-fatal error has been detected that can be
and is done whenever a fatal error has been detected that can be
"solved" by resetting the link.
STEP 4: Slot Reset
------------------
In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
the platform will perform a slot reset on the requesting PCI device(s).
the platform will perform a slot reset on the requesting PCI device(s).
The actual steps taken by a platform to perform a slot reset
will be platform-dependent. Upon completion of slot reset, the
platform will call the device slot_reset() callback.
......@@ -258,7 +258,7 @@ configuration registers to initialize to their default conditions.
For most PCI devices, a soft reset will be sufficient for recovery.
Optional fundamental reset is provided to support a limited number
of PCI Express PCI devices for which a soft reset is not sufficient
of PCI Express devices for which a soft reset is not sufficient
for recovery.
If the platform supports PCI hotplug, then the reset might be
......@@ -303,7 +303,7 @@ driver performs device init only from PCI function 0:
Same as above.
Drivers for PCI Express cards that require a fundamental reset must
set the needs_freset bit in the pci_dev structure in their probe function.
set the needs_freset bit in the pci_dev structure in their probe function.
For example, the QLogic qla2xxx driver sets the needs_freset bit for certain
PCI card types:
......
Documentation/PCI/pci-iov-howto.txt
浏览文件 @ eadcbfa5
......@@ -68,6 +68,18 @@ To disable SR-IOV capability:
echo 0 > \
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
To enable auto probing VFs by a compatible driver on the host, run
command below before enabling SR-IOV capabilities. This is the
default behavior.
echo 1 > \
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe
To disable auto probing VFs by a compatible driver on the host, run
command below before enabling SR-IOV capabilities. Updating this
entry will not affect VFs which are already probed.
echo 0 > \
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe
3.2 Usage example
Following piece of code illustrates the usage of the SR-IOV API.
......
Documentation/RCU/00-INDEX
浏览文件 @ eadcbfa5
......@@ -17,7 +17,7 @@ rcu_dereference.txt
rcubarrier.txt
- RCU and Unloadable Modules
rculist_nulls.txt
- RCU list primitives for use with SLAB_DESTROY_BY_RCU
- RCU list primitives for use with SLAB_TYPESAFE_BY_RCU
rcuref.txt
- Reference-count design for elements of lists/arrays protected by RCU
rcu.txt
......
Documentation/RCU/Design/Data-Structures/Data-Structures.html
浏览文件 @ eadcbfa5
......@@ -19,6 +19,8 @@ to each other.
The <tt>rcu_state</tt> Structure</a>
<li> <a href="#The rcu_node Structure">
The <tt>rcu_node</tt> Structure</a>
<li> <a href="#The rcu_segcblist Structure">
The <tt>rcu_segcblist</tt> Structure</a>
<li> <a href="#The rcu_data Structure">
The <tt>rcu_data</tt> Structure</a>
<li> <a href="#The rcu_dynticks Structure">
......@@ -841,6 +843,134 @@ for lockdep lock-class names.
Finally, lines&nbsp;64-66 produce an error if the maximum number of
CPUs is too large for the specified fanout.
<h3><a name="The rcu_segcblist Structure">
The <tt>rcu_segcblist</tt> Structure</a></h3>
The <tt>rcu_segcblist</tt> structure maintains a segmented list of
callbacks as follows:
<pre>
1 #define RCU_DONE_TAIL 0
2 #define RCU_WAIT_TAIL 1
3 #define RCU_NEXT_READY_TAIL 2
4 #define RCU_NEXT_TAIL 3
5 #define RCU_CBLIST_NSEGS 4
6
7 struct rcu_segcblist {
8 struct rcu_head *head;
9 struct rcu_head **tails[RCU_CBLIST_NSEGS];
10 unsigned long gp_seq[RCU_CBLIST_NSEGS];
11 long len;
12 long len_lazy;
13 };
</pre>
<p>
The segments are as follows:
<ol>
<li> <tt>RCU_DONE_TAIL</tt>: Callbacks whose grace periods have elapsed.
These callbacks are ready to be invoked.
<li> <tt>RCU_WAIT_TAIL</tt>: Callbacks that are waiting for the
current grace period.
Note that different CPUs can have different ideas about which
grace period is current, hence the <tt>-&gt;gp_seq</tt> field.
<li> <tt>RCU_NEXT_READY_TAIL</tt>: Callbacks waiting for the next
grace period to start.
<li> <tt>RCU_NEXT_TAIL</tt>: Callbacks that have not yet been
associated with a grace period.
</ol>
<p>
The <tt>-&gt;head</tt> pointer references the first callback or
is <tt>NULL</tt> if the list contains no callbacks (which is
<i>not</i> the same as being empty).
Each element of the <tt>-&gt;tails[]</tt> array references the
<tt>-&gt;next</tt> pointer of the last callback in the corresponding
segment of the list, or the list's <tt>-&gt;head</tt> pointer if
that segment and all previous segments are empty.
If the corresponding segment is empty but some previous segment is
not empty, then the array element is identical to its predecessor.
Older callbacks are closer to the head of the list, and new callbacks
are added at the tail.
This relationship between the <tt>-&gt;head</tt> pointer, the
<tt>-&gt;tails[]</tt> array, and the callbacks is shown in this
diagram:
</p><p><img src="nxtlist.svg" alt="nxtlist.svg" width="40%">
</p><p>In this figure, the <tt>-&gt;head</tt> pointer references the
first
RCU callback in the list.
The <tt>-&gt;tails[RCU_DONE_TAIL]</tt> array element references
the <tt>-&gt;head</tt> pointer itself, indicating that none
of the callbacks is ready to invoke.
The <tt>-&gt;tails[RCU_WAIT_TAIL]</tt> array element references callback
CB&nbsp;2's <tt>-&gt;next</tt> pointer, which indicates that
CB&nbsp;1 and CB&nbsp;2 are both waiting on the current grace period,
give or take possible disagreements about exactly which grace period
is the current one.
The <tt>-&gt;tails[RCU_NEXT_READY_TAIL]</tt> array element
references the same RCU callback that <tt>-&gt;tails[RCU_WAIT_TAIL]</tt>
does, which indicates that there are no callbacks waiting on the next
RCU grace period.
The <tt>-&gt;tails[RCU_NEXT_TAIL]</tt> array element references
CB&nbsp;4's <tt>-&gt;next</tt> pointer, indicating that all the
remaining RCU callbacks have not yet been assigned to an RCU grace
period.
Note that the <tt>-&gt;tails[RCU_NEXT_TAIL]</tt> array element
always references the last RCU callback's <tt>-&gt;next</tt> pointer
unless the callback list is empty, in which case it references
the <tt>-&gt;head</tt> pointer.
<p>
There is one additional important special case for the
<tt>-&gt;tails[RCU_NEXT_TAIL]</tt> array element: It can be <tt>NULL</tt>
when this list is <i>disabled</i>.
Lists are disabled when the corresponding CPU is offline or when
the corresponding CPU's callbacks are offloaded to a kthread,
both of which are described elsewhere.
</p><p>CPUs advance their callbacks from the
<tt>RCU_NEXT_TAIL</tt> to the <tt>RCU_NEXT_READY_TAIL</tt> to the
<tt>RCU_WAIT_TAIL</tt> to the <tt>RCU_DONE_TAIL</tt> list segments
as grace periods advance.
</p><p>The <tt>-&gt;gp_seq[]</tt> array records grace-period
numbers corresponding to the list segments.
This is what allows different CPUs to have different ideas as to
which is the current grace period while still avoiding premature
invocation of their callbacks.
In particular, this allows CPUs that go idle for extended periods
to determine which of their callbacks are ready to be invoked after
reawakening.
</p><p>The <tt>-&gt;len</tt> counter contains the number of
callbacks in <tt>-&gt;head</tt>, and the
<tt>-&gt;len_lazy</tt> contains the number of those callbacks that
are known to only free memory, and whose invocation can therefore
be safely deferred.
<p><b>Important note</b>: It is the <tt>-&gt;len</tt> field that
determines whether or not there are callbacks associated with
this <tt>rcu_segcblist</tt> structure, <i>not</i> the <tt>-&gt;head</tt>
pointer.
The reason for this is that all the ready-to-invoke callbacks
(that is, those in the <tt>RCU_DONE_TAIL</tt> segment) are extracted
all at once at callback-invocation time.
If callback invocation must be postponed, for example, because a
high-priority process just woke up on this CPU, then the remaining
callbacks are placed back on the <tt>RCU_DONE_TAIL</tt> segment.
Either way, the <tt>-&gt;len</tt> and <tt>-&gt;len_lazy</tt> counts
are adjusted after the corresponding callbacks have been invoked, and so
again it is the <tt>-&gt;len</tt> count that accurately reflects whether
or not there are callbacks associated with this <tt>rcu_segcblist</tt>
structure.
Of course, off-CPU sampling of the <tt>-&gt;len</tt> count requires
the use of appropriate synchronization, for example, memory barriers.
This synchronization can be a bit subtle, particularly in the case
of <tt>rcu_barrier()</tt>.
<h3><a name="The rcu_data Structure">
The <tt>rcu_data</tt> Structure</a></h3>
......@@ -983,62 +1113,18 @@ choice.
as follows:
<pre>
1 struct rcu_head *nxtlist;
2 struct rcu_head **nxttail[RCU_NEXT_SIZE];
3 unsigned long nxtcompleted[RCU_NEXT_SIZE];
4 long qlen_lazy;
5 long qlen;
6 long qlen_last_fqs_check;
1 struct rcu_segcblist cblist;
2 long qlen_last_fqs_check;
3 unsigned long n_cbs_invoked;
4 unsigned long n_nocbs_invoked;
5 unsigned long n_cbs_orphaned;
6 unsigned long n_cbs_adopted;
7 unsigned long n_force_qs_snap;
8 unsigned long n_cbs_invoked;
9 unsigned long n_cbs_orphaned;
10 unsigned long n_cbs_adopted;
11 long blimit;
8 long blimit;
</pre>
<p>The <tt>-&gt;nxtlist</tt> pointer and the
<tt>-&gt;nxttail[]</tt> array form a four-segment list with
older callbacks near the head and newer ones near the tail.
Each segment contains callbacks with the corresponding relationship
to the current grace period.
The pointer out of the end of each of the four segments is referenced
by the element of the <tt>-&gt;nxttail[]</tt> array indexed by
<tt>RCU_DONE_TAIL</tt> (for callbacks handled by a prior grace period),
<tt>RCU_WAIT_TAIL</tt> (for callbacks waiting on the current grace period),
<tt>RCU_NEXT_READY_TAIL</tt> (for callbacks that will wait on the next
grace period), and
<tt>RCU_NEXT_TAIL</tt> (for callbacks that are not yet associated
with a specific grace period)
respectively, as shown in the following figure.
</p><p><img src="nxtlist.svg" alt="nxtlist.svg" width="40%">
</p><p>In this figure, the <tt>-&gt;nxtlist</tt> pointer references the
first
RCU callback in the list.
The <tt>-&gt;nxttail[RCU_DONE_TAIL]</tt> array element references
the <tt>-&gt;nxtlist</tt> pointer itself, indicating that none
of the callbacks is ready to invoke.
The <tt>-&gt;nxttail[RCU_WAIT_TAIL]</tt> array element references callback
CB&nbsp;2's <tt>-&gt;next</tt> pointer, which indicates that
CB&nbsp;1 and CB&nbsp;2 are both waiting on the current grace period.
The <tt>-&gt;nxttail[RCU_NEXT_READY_TAIL]</tt> array element
references the same RCU callback that <tt>-&gt;nxttail[RCU_WAIT_TAIL]</tt>
does, which indicates that there are no callbacks waiting on the next
RCU grace period.
The <tt>-&gt;nxttail[RCU_NEXT_TAIL]</tt> array element references
CB&nbsp;4's <tt>-&gt;next</tt> pointer, indicating that all the
remaining RCU callbacks have not yet been assigned to an RCU grace
period.
Note that the <tt>-&gt;nxttail[RCU_NEXT_TAIL]</tt> array element
always references the last RCU callback's <tt>-&gt;next</tt> pointer
unless the callback list is empty, in which case it references
the <tt>-&gt;nxtlist</tt> pointer.
</p><p>CPUs advance their callbacks from the
<tt>RCU_NEXT_TAIL</tt> to the <tt>RCU_NEXT_READY_TAIL</tt> to the
<tt>RCU_WAIT_TAIL</tt> to the <tt>RCU_DONE_TAIL</tt> list segments
as grace periods advance.
<p>The <tt>-&gt;cblist</tt> structure is the segmented callback list
described earlier.
The CPU advances the callbacks in its <tt>rcu_data</tt> structure
whenever it notices that another RCU grace period has completed.
The CPU detects the completion of an RCU grace period by noticing
......@@ -1049,16 +1135,7 @@ Recall that each <tt>rcu_node</tt> structure's
<tt>-&gt;completed</tt> field is updated at the end of each
grace period.
</p><p>The <tt>-&gt;nxtcompleted[]</tt> array records grace-period
numbers corresponding to the list segments.
This allows CPUs that go idle for extended periods to determine
which of their callbacks are ready to be invoked after reawakening.
</p><p>The <tt>-&gt;qlen</tt> counter contains the number of
callbacks in <tt>-&gt;nxtlist</tt>, and the
<tt>-&gt;qlen_lazy</tt> contains the number of those callbacks that
are known to only free memory, and whose invocation can therefore
be safely deferred.
<p>
The <tt>-&gt;qlen_last_fqs_check</tt> and
<tt>-&gt;n_force_qs_snap</tt> coordinate the forcing of quiescent
states from <tt>call_rcu()</tt> and friends when callback
......@@ -1069,6 +1146,10 @@ lists grow excessively long.
fields count the number of callbacks invoked,
sent to other CPUs when this CPU goes offline,
and received from other CPUs when those other CPUs go offline.
The <tt>-&gt;n_nocbs_invoked</tt> is used when the CPU's callbacks
are offloaded to a kthread.
<p>
Finally, the <tt>-&gt;blimit</tt> counter is the maximum number of
RCU callbacks that may be invoked at a given time.
......@@ -1104,6 +1185,9 @@ Its fields are as follows:
1 int dynticks_nesting;
2 int dynticks_nmi_nesting;
3 atomic_t dynticks;
4 bool rcu_need_heavy_qs;
5 unsigned long rcu_qs_ctr;
6 bool rcu_urgent_qs;
</pre>
<p>The <tt>-&gt;dynticks_nesting</tt> field counts the
......@@ -1117,11 +1201,32 @@ NMIs are counted by the <tt>-&gt;dynticks_nmi_nesting</tt>
field, except that NMIs that interrupt non-dyntick-idle execution
are not counted.
</p><p>Finally, the <tt>-&gt;dynticks</tt> field counts the corresponding
</p><p>The <tt>-&gt;dynticks</tt> field counts the corresponding
CPU's transitions to and from dyntick-idle mode, so that this counter
has an even value when the CPU is in dyntick-idle mode and an odd
value otherwise.
</p><p>The <tt>-&gt;rcu_need_heavy_qs</tt> field is used
to record the fact that the RCU core code would really like to
see a quiescent state from the corresponding CPU, so much so that
it is willing to call for heavy-weight dyntick-counter operations.
This flag is checked by RCU's context-switch and <tt>cond_resched()</tt>
code, which provide a momentary idle sojourn in response.
</p><p>The <tt>-&gt;rcu_qs_ctr</tt> field is used to record
quiescent states from <tt>cond_resched()</tt>.
Because <tt>cond_resched()</tt> can execute quite frequently, this
must be quite lightweight, as in a non-atomic increment of this
per-CPU field.
</p><p>Finally, the <tt>-&gt;rcu_urgent_qs</tt> field is used to record
the fact that the RCU core code would really like to see a quiescent
state from the corresponding CPU, with the various other fields indicating
just how badly RCU wants this quiescent state.
This flag is checked by RCU's context-switch and <tt>cond_resched()</tt>
code, which, if nothing else, non-atomically increment <tt>-&gt;rcu_qs_ctr</tt>
in response.
<table>
<tr><th>&nbsp;</th></tr>
<tr><th align="left">Quick Quiz:</th></tr>
......
Documentation/RCU/Design/Data-Structures/nxtlist.svg
浏览文件 @ eadcbfa5
......@@ -19,7 +19,7 @@
id="svg2"
version="1.1"
inkscape:version="0.48.4 r9939"
sodipodi:docname="nxtlist.fig">
sodipodi:docname="segcblist.svg">
<metadata
id="metadata94">
<rdf:RDF>
......@@ -28,7 +28,7 @@
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
......@@ -241,61 +241,51 @@
xml:space="preserve"
x="225"
y="675"
fill="#000000"
font-family="Courier"
font-style="normal"
font-weight="bold"
font-size="324"
text-anchor="start"
id="text64">nxtlist</text>
id="text64"
style="font-size:324px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;head</text>
<!-- Text -->
<text
xml:space="preserve"
x="225"
y="1800"
fill="#000000"
font-family="Courier"
font-style="normal"
font-weight="bold"
font-size="324"
text-anchor="start"
id="text66">nxttail[RCU_DONE_TAIL]</text>
id="text66"
style="font-size:324px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;tails[RCU_DONE_TAIL]</text>
<!-- Text -->
<text
xml:space="preserve"
x="225"
y="2925"
fill="#000000"
font-family="Courier"
font-style="normal"
font-weight="bold"
font-size="324"
text-anchor="start"
id="text68">nxttail[RCU_WAIT_TAIL]</text>
id="text68"
style="font-size:324px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;tails[RCU_WAIT_TAIL]</text>
<!-- Text -->
<text
xml:space="preserve"
x="225"
y="4050"
fill="#000000"
font-family="Courier"
font-style="normal"
font-weight="bold"
font-size="324"
text-anchor="start"
id="text70">nxttail[RCU_NEXT_READY_TAIL]</text>
id="text70"
style="font-size:324px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;tails[RCU_NEXT_READY_TAIL]</text>
<!-- Text -->
<text
xml:space="preserve"
x="225"
y="5175"
fill="#000000"
font-family="Courier"
font-style="normal"
font-weight="bold"
font-size="324"
text-anchor="start"
id="text72">nxttail[RCU_NEXT_TAIL]</text>
id="text72"
style="font-size:324px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;tails[RCU_NEXT_TAIL]</text>
<!-- Text -->
<text
xml:space="preserve"
......
Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html
浏览文件 @ eadcbfa5
......@@ -284,6 +284,7 @@ Expedited Grace Period Refinements</a></h2>
Funnel locking and wait/wakeup</a>.
<li> <a href="#Use of Workqueues">Use of Workqueues</a>.
<li> <a href="#Stall Warnings">Stall warnings</a>.
<li> <a href="#Mid-Boot Operation">Mid-boot operation</a>.
</ol>
<h3><a name="Idle-CPU Checks">Idle-CPU Checks</a></h3>
......@@ -524,7 +525,7 @@ their grace periods and carrying out their wakeups.
In earlier implementations, the task requesting the expedited
grace period also drove it to completion.
This straightforward approach had the disadvantage of needing to
account for signals sent to user tasks,
account for POSIX signals sent to user tasks,
so more recent implemementations use the Linux kernel's
<a href="https://www.kernel.org/doc/Documentation/workqueue.txt">workqueues</a>.
......@@ -533,8 +534,8 @@ The requesting task still does counter snapshotting and funnel-lock
processing, but the task reaching the top of the funnel lock
does a <tt>schedule_work()</tt> (from <tt>_synchronize_rcu_expedited()</tt>
so that a workqueue kthread does the actual grace-period processing.
Because workqueue kthreads do not accept signals, grace-period-wait
processing need not allow for signals.
Because workqueue kthreads do not accept POSIX signals, grace-period-wait
processing need not allow for POSIX signals.
In addition, this approach allows wakeups for the previous expedited
grace period to be overlapped with processing for the next expedited
......@@ -586,6 +587,46 @@ blocking the current grace period are printed.
Each stall warning results in another pass through the loop, but the
second and subsequent passes use longer stall times.
<h3><a name="Mid-Boot Operation">Mid-boot operation</a></h3>
<p>
The use of workqueues has the advantage that the expedited
grace-period code need not worry about POSIX signals.
Unfortunately, it has the
corresponding disadvantage that workqueues cannot be used until
they are initialized, which does not happen until some time after
the scheduler spawns the first task.
Given that there are parts of the kernel that really do want to
execute grace periods during this mid-boot &ldquo;dead zone&rdquo;,
expedited grace periods must do something else during thie time.
<p>
What they do is to fall back to the old practice of requiring that the
requesting task drive the expedited grace period, as was the case
before the use of workqueues.
However, the requesting task is only required to drive the grace period
during the mid-boot dead zone.
Before mid-boot, a synchronous grace period is a no-op.
Some time after mid-boot, workqueues are used.
<p>
Non-expedited non-SRCU synchronous grace periods must also operate
normally during mid-boot.
This is handled by causing non-expedited grace periods to take the
expedited code path during mid-boot.
<p>
The current code assumes that there are no POSIX signals during
the mid-boot dead zone.
However, if an overwhelming need for POSIX signals somehow arises,
appropriate adjustments can be made to the expedited stall-warning code.
One such adjustment would reinstate the pre-workqueue stall-warning
checks, but only during the mid-boot dead zone.
<p>
With this refinement, synchronous grace periods can now be used from
task context pretty much any time during the life of the kernel.
<h3><a name="Summary">
Summary</a></h3>
......
Documentation/RCU/rcu_dereference.txt
浏览文件 @ eadcbfa5
......@@ -138,6 +138,15 @@ o Be very careful about comparing pointers obtained from
This sort of comparison occurs frequently when scanning
RCU-protected circular linked lists.
Note that if checks for being within an RCU read-side
critical section are not required and the pointer is never
dereferenced, rcu_access_pointer() should be used in place
of rcu_dereference(). The rcu_access_pointer() primitive
does not require an enclosing read-side critical section,
and also omits the smp_read_barrier_depends() included in
rcu_dereference(), which in turn should provide a small
performance gain in some CPUs (e.g., the DEC Alpha).
o The comparison is against a pointer that references memory
that was initialized "a long time ago." The reason
this is safe is that even if misordering occurs, the
......
Documentation/RCU/rculist_nulls.txt
浏览文件 @ eadcbfa5
Using hlist_nulls to protect read-mostly linked lists and
objects using SLAB_DESTROY_BY_RCU allocations.
objects using SLAB_TYPESAFE_BY_RCU allocations.
Please read the basics in Documentation/RCU/listRCU.txt
......@@ -7,7 +7,7 @@ Using special makers (called 'nulls') is a convenient way
to solve following problem :
A typical RCU linked list managing objects which are
allocated with SLAB_DESTROY_BY_RCU kmem_cache can
allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can
use following algos :
1) Lookup algo
......@@ -96,7 +96,7 @@ unlock_chain(); // typically a spin_unlock()
3) Remove algo
--------------
Nothing special here, we can use a standard RCU hlist deletion.
But thanks to SLAB_DESTROY_BY_RCU, beware a deleted object can be reused
But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused
very very fast (before the end of RCU grace period)
if (put_last_reference_on(obj) {
......
Documentation/RCU/stallwarn.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/RCU/whatisRCU.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/acpi/acpi-lid.txt
浏览文件 @ eadcbfa5
......@@ -59,20 +59,28 @@ button driver uses the following 3 modes in order not to trigger issues.
If the userspace hasn't been prepared to ignore the unreliable "opened"
events and the unreliable initial state notification, Linux users can use
the following kernel parameters to handle the possible issues:
A. button.lid_init_state=open:
A. button.lid_init_state=method:
When this option is specified, the ACPI button driver reports the
initial lid state using the returning value of the _LID control method
and whether the "opened"/"closed" events are paired fully relies on the
firmware implementation.
This option can be used to fix some platforms where the returning value
of the _LID control method is reliable but the initial lid state
notification is missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
B. button.lid_init_state=open:
When this option is specified, the ACPI button driver always reports the
initial lid state as "opened" and whether the "opened"/"closed" events
are paired fully relies on the firmware implementation.
This may fix some platforms where the returning value of the _LID
control method is not reliable and the initial lid state notification is
missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
If the userspace has been prepared to ignore the unreliable "opened" events
and the unreliable initial state notification, Linux users should always
use the following kernel parameter:
B. button.lid_init_state=ignore:
C. button.lid_init_state=ignore:
When this option is specified, the ACPI button driver never reports the
initial lid state and there is a compensation mechanism implemented to
ensure that the reliable "closed" notifications can always be delievered
......
Documentation/acpi/aml-debugger.txt
浏览文件 @ eadcbfa5
......@@ -15,7 +15,7 @@ kernel.
CONFIG_ACPI_DEBUGGER=y
CONFIG_ACPI_DEBUGGER_USER=m
The userspace utlities can be built from the kernel source tree using
The userspace utilities can be built from the kernel source tree using
the following commands:
$ cd tools
......
Documentation/acpi/dsd/graph.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/acpi/enumeration.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/admin-guide/index.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/admin-guide/md.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/admin-guide/pm/cpufreq.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/admin-guide/pm/index.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/admin-guide/pm/intel_pstate.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/admin-guide/ras.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/admin-guide/sysrq.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/arm/mem_alignment
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/arm/stm32/stm32h743-overview.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/block/00-INDEX
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/block/bfq-iosched.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/block/kyber-iosched.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/block/queue-sysfs.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/blockdev/mflash.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/cgroup-v2.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/conf.py
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/core-api/flexible-arrays.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/core-api/genericirq.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/core-api/index.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/core-api/kernel-api.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/cpu-freq/boost.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/cpu-freq/governors.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/cpu-freq/index.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/cpu-freq/intel-pstate.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/cpu-freq/user-guide.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/cputopology.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/device-mapper/dm-integrity.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/arm/gemini.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/arm/i2se.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/ata/ahci-dm816.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/firmware/coreboot.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/fpga/altera-pr-ip.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/gpio/gpio-xra1403.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/hwmon/ads7828.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/hwmon/lm87.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/iio/accel/adxl345.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/iio/adc/cpcap-adc.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/iio/adc/ltc2497.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/iio/adc/max1118.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/iio/adc/max9611.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/iio/dac/ltc2632.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/iio/light/vl6180.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/leds/leds-cpcap.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/leds/leds-mt6323.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/media/i2c/ov5645.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/media/i2c/ov5647.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/media/i2c/ov7670.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/mfd/ti-lmu.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/mfd/wm831x.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/mmc/cavium-mmc.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/mtd/stm32-quadspi.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/net/can/ti_hecc.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/net/dsa/lan9303.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/net/dsa/mt7530.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/net/faraday,ftmac.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/net/ftgmac100.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/net/mdio.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/net/ti,wilink-st.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/nvmem/imx-iim.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/pwm/pwm-mediatek.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/regulator/vctrl.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/rng/mtk-rng.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/rtc/cpcap-rtc.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/rtc/rtc-sh.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/sound/cs35l35.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/sound/max9892x.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/sound/nau8824.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/sound/zte,tdm.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/spi/spi-bcm63xx.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/devicetree/bindings/trivial-devices.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/doc-guide/hello.dot 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/doc-guide/sphinx.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/doc-guide/svg_image.svg 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/basics.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/firmware/other_interfaces.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/index.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/misc_devices.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/pci.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb.rst 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/driver-api/usb/URB.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/anchors.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/bulk-streams.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/callbacks.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/dma.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/error-codes.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/gadget.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/hotplug.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/index.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/persist.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/power-management.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/usb.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/usb/writing_usb_driver.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/driver-api/vme.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/filesystems/Locking
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/filesystems/bfs.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/filesystems/ext4.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/filesystems/porting
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/filesystems/proc.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/filesystems/vfs.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpio/consumer.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/bridge/dw-hdmi.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/drm-internals.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/drm-kms.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/drm-mm.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/drm-uapi.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/i915.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/index.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/introduction.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/meson.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/todo.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/gpu/vc4.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/hid/hidraw.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/hwmon/aspeed-pwm-tacho 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/hwmon/tc654
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/index.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/infiniband/opa_vnic.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/input/event-codes.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/input/ff.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/kbuild/makefiles.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/kdump/kdump.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/kref.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/leds/leds-lp55xx.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/lightnvm/pblk.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/md/md-cluster.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/md/raid5-ppl.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/Makefile
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/intro.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/kapi/csi2.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/uapi/v4l/dev-meta.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/uapi/v4l/meta-formats.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/uapi/v4l/pixfmt-inzi.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/media/v4l-drivers/philips.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/memory-barriers.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/misc-devices/pci-endpoint-test.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/mmc/mmc-dev-attrs.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/e100.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/e1000.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/e1000e.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/filter.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/i40e.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/igb.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/igbvf.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/ixgb.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/networking/ixgbe.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/perf/qcom_l3_pmu.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/phy.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/pinctrl.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/power/runtime_pm.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/power/swsusp.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/powerpc/cxl.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/powerpc/cxlflash.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/process/4.Coding.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/process/changes.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/process/index.rst
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/s390/00-INDEX
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/s390/vfio-ccw.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/scheduler/sched-pelt.c 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/scsi/scsi_eh.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/security/keys.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/sphinx/cdomain.py
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/sphinx/kfigure.py 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/sphinx/tmplcvt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/static-keys.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/switchtec.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/sync_file.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/sysctl/net.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/target/target-export-device 0 → 100755
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/tee.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/thermal/sysfs-api.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/trace/ftrace.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/trace/kprobetrace.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/translations/ja_JP/HOWTO 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/translations/ja_JP/howto.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/translations/ja_JP/index.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/unshare.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/URB.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/acm.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/usb/anchors.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/bulk-streams.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/callbacks.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/dma.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/error-codes.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/gadget_serial.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/usb/hotplug.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/persist.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/power-management.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/proc_usb_info.txt 已删除 100644 → 0
浏览文件 @ c4beedb8
此差异已折叠。
Documentation/usb/typec.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/usb/usb3-debug-port.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/userspace-api/conf.py 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/userspace-api/index.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/userspace-api/unshare.rst 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/virtual/kvm/api.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/virtual/kvm/arm/hyp-abi.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/vm/00-INDEX
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/vm/hugetlbfs_reserv.txt 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/vm/transhuge.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/w1/slaves/00-INDEX
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/w1/slaves/w1_ds2413 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/w1/slaves/w1_ds2438 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/x86/intel_rdt_ui.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/x86/x86_64/mm.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/x86/zero-page.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Documentation/zorro.txt
浏览文件 @ eadcbfa5
此差异已折叠。
Kbuild
浏览文件 @ eadcbfa5
此差异已折叠。
MAINTAINERS
浏览文件 @ eadcbfa5
此差异已折叠。
Makefile
浏览文件 @ eadcbfa5
此差异已折叠。
arch/Kconfig
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/include/asm/extable.h 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/include/asm/futex.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/include/asm/uaccess.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/include/uapi/asm/Kbuild
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/kernel/osf_sys.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/kernel/traps.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/lib/Makefile
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/lib/clear_user.S
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/lib/copy_user.S
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/lib/csum_partial_copy.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/lib/ev6-clear_user.S
浏览文件 @ eadcbfa5
此差异已折叠。
arch/alpha/lib/ev6-copy_user.S
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/Kconfig
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/Makefile
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/boot/dts/axs10x_mb.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/Kbuild
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/atomic.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/cache.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/entry-arcv2.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/mmu.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/pgtable.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/ptrace.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/asm/uaccess.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/uapi/asm/Kbuild
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/uapi/asm/elf.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/include/uapi/asm/ptrace.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/kernel/ptrace.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/kernel/setup.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/kernel/unwind.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/mm/cache.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arc/mm/extable.c
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/Kconfig
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/Makefile
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/compressed/head.S
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/Makefile
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/alpine.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/am335x-baltos-leds.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/am335x-evmsk.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/am335x-icev2.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/am33xx.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/am3517.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/am4372.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/am437x-gp-evm.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/armada-385-linksys-shelby.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/armada-385-synology-ds116.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/armada-385.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/armada-388.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/armada-38x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/aspeed-g4.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/aspeed-g5.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/at91-tse850-3.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/at91sam9261.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/at91sam9x5ek.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/axp209.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/axp22x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm-cygnus.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm-nsp.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm2835-rpi.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm283x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm4708-linksys-ea6300-v1.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm4708.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm47081.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm4709-linksys-ea9200.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm47094-linksys-panamera.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm5301x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm53573.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm94708.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm94709.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm953012er.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm953012hr.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm953012k.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm958522er.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm958525er.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm958525xmc.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm958622hr.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm958623hr.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm958625hr.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm958625k.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/bcm988312hr.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/da850-evm.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/da850.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/dm8168-evm.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/dm816x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/dra7-evm.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/dra7.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/dra74x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos3250.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos4.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos4210.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos4412.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos5420.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos5440.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/exynos5800.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/gemini-nas4220b.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/gemini-rut1xx.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/gemini-sq201.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/gemini-wbd111.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/gemini-wbd222.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/gemini.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx25-pdk.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx25-pinfunc.h
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx25.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx28-duckbill-2-485.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx28-duckbill-2-enocean.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx28-duckbill-2-spi.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx28-duckbill-2.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx28-m28cu3.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx28.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx50.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx53-qsb.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx53-qsrb.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6dl-gw5903.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6dl-gw5904.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-b450v3.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-b650v3.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-b850v3.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-bx50v3.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-cm-fx6.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-gw5903.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-gw5904.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-icore-ofcap10.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-icore-ofcap12.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-icore.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6q-zii-rdu2.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6qdl-gw5903.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6qdl-gw5904.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6qdl.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6qp-zii-rdu2.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6qp.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6sx-sdb.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6sx.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6ul-geam.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6ul-isiot-common.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx6ul-isiot.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx7-colibri.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx7d-sdb-sht11.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/imx7s.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/include/dt-bindings 已删除 120000 → 0
浏览文件 @ c4beedb8
此差异已折叠。
arch/arm/boot/dts/meson8.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/meson8b.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/moxart.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/mt7623.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap3-cpu-thermal.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap3-gta04.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap3-igep.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap3-n900.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap34xx.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap36xx.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap443x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap4460.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/omap5.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/qcom-msm8660.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/qcom-msm8974.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r7s72100.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a73a4.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7743.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7745.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7778-bockw.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7790-lager.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7790.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7791.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7792.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7793-gose.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7793.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7794-alt.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7794-silk.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/r8a7794.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk1108.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3036.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3188.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk322x.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3288-miqi.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3288-phycore-rdk.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3288-phycore-som.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3288-tinker.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3288.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/rk3xxx.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/s3c64xx.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/s5pv210.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sama5d2.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/socfpga.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/socfpga_vt.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/spear600-evb.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/spear600.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/ste-dbx5x0.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/stih410.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/stm32f429.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/stm32f746.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/stm32h743-pinctrl.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/stm32h743.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/stm32h743i-eval.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun4i-a10.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun5i-a10s.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun5i-a13.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun5i-gr8-evb.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun5i-gr8.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun5i-r8-chip.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun5i-r8.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun5i.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun6i-a31-i7.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun6i-a31-m9.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun6i-a31.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun7i-a20-m3.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun7i-a20.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun8i-a23-evb.dts
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun8i-a33.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun8i-a83t.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun8i-h3.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sun9i-a80.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/sunxi-h3-h5.dtsi 0 → 100644
浏览文件 @ eadcbfa5
此差异已折叠。
arch/arm/boot/dts/uniphier-ld4.dtsi
浏览文件 @ eadcbfa5
此差异已折叠。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或