You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'linus/master' into rdma.git for-next
rdma.git merge resolution for the 4.19 merge window
Conflicts:
drivers/infiniband/core/rdma_core.c
- Use the rdma code and revise with the new spelling for
atomic_fetch_add_unless
drivers/nvme/host/rdma.c
- Replace max_sge with max_send_sge in new blk code
drivers/nvme/target/rdma.c
- Use the blk code and revise to use NULL for ib_post_recv when
appropriate
- Replace max_sge with max_recv_sge in new blk code
net/rds/ib_send.c
- Use the net code and revise to use NULL for ib_post_recv when
appropriate
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
This commit is contained in:
Jason Gunthorpe
+1
-1
@@ -382,7 +382,7 @@ IncludeIsMainRegex: '(Test)?$'
|
||||
IndentCaseLabels: false
|
||||
#IndentPPDirectives: None # Unknown to clang-format-5.0
|
||||
IndentWidth: 8
|
||||
IndentWrappedFunctionNames: true
|
||||
IndentWrappedFunctionNames: false
|
||||
JavaScriptQuotes: Leave
|
||||
JavaScriptWrapImports: true
|
||||
KeepEmptyLinesAtTheStartOfBlocks: false
|
||||
|
||||
@@ -83,6 +83,9 @@ Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
||||
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||
|
||||
@@ -11,7 +11,7 @@ KernelVersion: v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org,
|
||||
Description: The rfkill class subsystem folder.
|
||||
Each registered rfkill driver is represented by an rfkillX
|
||||
subfolder (X being an integer > 0).
|
||||
subfolder (X being an integer >= 0).
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/name
|
||||
@@ -48,8 +48,8 @@ Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file was scheduled to be removed in 2014, but due to its
|
||||
large number of users it will be sticking around for a bit
|
||||
longer. Despite it being marked as stabe, the newer "hard" and
|
||||
"soft" interfaces should be preffered, since it is not possible
|
||||
longer. Despite it being marked as stable, the newer "hard" and
|
||||
"soft" interfaces should be preferred, since it is not possible
|
||||
to express the 'soft and hard block' state of the rfkill driver
|
||||
through this interface. There will likely be another attempt to
|
||||
remove it in the future.
|
||||
|
||||
@@ -5,6 +5,7 @@ Description:
|
||||
The /proc/diskstats file displays the I/O statistics
|
||||
of block devices. Each line contains the following 14
|
||||
fields:
|
||||
|
||||
1 - major number
|
||||
2 - minor mumber
|
||||
3 - device name
|
||||
@@ -19,4 +20,13 @@ Description:
|
||||
12 - I/Os currently in progress
|
||||
13 - time spent doing I/Os (ms)
|
||||
14 - weighted time spent doing I/Os (ms)
|
||||
|
||||
Kernel 4.18+ appends four more fields for discard
|
||||
tracking putting the total at 18:
|
||||
|
||||
15 - discards completed successfully
|
||||
16 - discards merged
|
||||
17 - sectors discarded
|
||||
18 - time spent discarding
|
||||
|
||||
For more details refer to Documentation/iostats.txt
|
||||
|
||||
@@ -0,0 +1,122 @@
|
||||
==========================
|
||||
PCIe Device AER statistics
|
||||
==========================
|
||||
These attributes show up under all the devices that are AER capable. These
|
||||
statistical counters indicate the errors "as seen/reported by the device".
|
||||
Note that this may mean that if an endpoint is causing problems, the AER
|
||||
counters may increment at its link partner (e.g. root port) because the
|
||||
errors may be "seen" / reported by the link partner and not the
|
||||
problematic endpoint itself (which may report all counters as 0 as it never
|
||||
saw any problems).
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_dev_correctable
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: List of correctable errors seen and reported by this
|
||||
PCI device using ERR_COR. Note that since multiple errors may
|
||||
be reported using a single ERR_COR message, thus
|
||||
TOTAL_ERR_COR at the end of the file may not match the actual
|
||||
total of all the errors in the file. Sample output:
|
||||
-------------------------------------------------------------------------
|
||||
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_correctable
|
||||
Receiver Error 2
|
||||
Bad TLP 0
|
||||
Bad DLLP 0
|
||||
RELAY_NUM Rollover 0
|
||||
Replay Timer Timeout 0
|
||||
Advisory Non-Fatal 0
|
||||
Corrected Internal Error 0
|
||||
Header Log Overflow 0
|
||||
TOTAL_ERR_COR 2
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_dev_fatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: List of uncorrectable fatal errors seen and reported by this
|
||||
PCI device using ERR_FATAL. Note that since multiple errors may
|
||||
be reported using a single ERR_FATAL message, thus
|
||||
TOTAL_ERR_FATAL at the end of the file may not match the actual
|
||||
total of all the errors in the file. Sample output:
|
||||
-------------------------------------------------------------------------
|
||||
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_fatal
|
||||
Undefined 0
|
||||
Data Link Protocol 0
|
||||
Surprise Down Error 0
|
||||
Poisoned TLP 0
|
||||
Flow Control Protocol 0
|
||||
Completion Timeout 0
|
||||
Completer Abort 0
|
||||
Unexpected Completion 0
|
||||
Receiver Overflow 0
|
||||
Malformed TLP 0
|
||||
ECRC 0
|
||||
Unsupported Request 0
|
||||
ACS Violation 0
|
||||
Uncorrectable Internal Error 0
|
||||
MC Blocked TLP 0
|
||||
AtomicOp Egress Blocked 0
|
||||
TLP Prefix Blocked Error 0
|
||||
TOTAL_ERR_FATAL 0
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_dev_nonfatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: List of uncorrectable nonfatal errors seen and reported by this
|
||||
PCI device using ERR_NONFATAL. Note that since multiple errors
|
||||
may be reported using a single ERR_FATAL message, thus
|
||||
TOTAL_ERR_NONFATAL at the end of the file may not match the
|
||||
actual total of all the errors in the file. Sample output:
|
||||
-------------------------------------------------------------------------
|
||||
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_nonfatal
|
||||
Undefined 0
|
||||
Data Link Protocol 0
|
||||
Surprise Down Error 0
|
||||
Poisoned TLP 0
|
||||
Flow Control Protocol 0
|
||||
Completion Timeout 0
|
||||
Completer Abort 0
|
||||
Unexpected Completion 0
|
||||
Receiver Overflow 0
|
||||
Malformed TLP 0
|
||||
ECRC 0
|
||||
Unsupported Request 0
|
||||
ACS Violation 0
|
||||
Uncorrectable Internal Error 0
|
||||
MC Blocked TLP 0
|
||||
AtomicOp Egress Blocked 0
|
||||
TLP Prefix Blocked Error 0
|
||||
TOTAL_ERR_NONFATAL 0
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
============================
|
||||
PCIe Rootport AER statistics
|
||||
============================
|
||||
These attributes show up under only the rootports (or root complex event
|
||||
collectors) that are AER capable. These indicate the number of error messages as
|
||||
"reported to" the rootport. Please note that the rootports also transmit
|
||||
(internally) the ERR_* messages for errors seen by the internal rootport PCI
|
||||
device, so these counters include them and are thus cumulative of all the error
|
||||
messages on the PCI hierarchy originating at that root port.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_cor
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: Total number of ERR_COR messages reported to rootport.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_fatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: Total number of ERR_FATAL messages reported to rootport.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_nonfatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: Total number of ERR_NONFATAL messages reported to rootport.
|
||||
@@ -42,6 +42,17 @@ Description:
|
||||
network device transmit queue. Possible vaules depend on the
|
||||
number of available CPU(s) in the system.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs
|
||||
Date: June 2018
|
||||
KernelVersion: 4.18.0
|
||||
Contact: netdev@vger.kernel.org
|
||||
Description:
|
||||
Mask of the receive queue(s) currently enabled to participate
|
||||
into the Transmit Packet Steering packet processing flow for this
|
||||
network device transmit queue. Possible values depend on the
|
||||
number of available receive queue(s) in the network device.
|
||||
Default is disabled.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
|
||||
Date: November 2011
|
||||
KernelVersion: 3.3
|
||||
|
||||
@@ -476,6 +476,7 @@ What: /sys/devices/system/cpu/vulnerabilities
|
||||
/sys/devices/system/cpu/vulnerabilities/spectre_v1
|
||||
/sys/devices/system/cpu/vulnerabilities/spectre_v2
|
||||
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
|
||||
/sys/devices/system/cpu/vulnerabilities/l1tf
|
||||
Date: January 2018
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Information about CPU vulnerabilities
|
||||
@@ -487,3 +488,26 @@ Description: Information about CPU vulnerabilities
|
||||
"Not affected" CPU is not affected by the vulnerability
|
||||
"Vulnerable" CPU is affected and no mitigation in effect
|
||||
"Mitigation: $M" CPU is affected and mitigation $M is in effect
|
||||
|
||||
Details about the l1tf file can be found in
|
||||
Documentation/admin-guide/l1tf.rst
|
||||
|
||||
What: /sys/devices/system/cpu/smt
|
||||
/sys/devices/system/cpu/smt/active
|
||||
/sys/devices/system/cpu/smt/control
|
||||
Date: June 2018
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Control Symetric Multi Threading (SMT)
|
||||
|
||||
active: Tells whether SMT is active (enabled and siblings online)
|
||||
|
||||
control: Read/write interface to control SMT. Possible
|
||||
values:
|
||||
|
||||
"on" SMT is enabled
|
||||
"off" SMT is disabled
|
||||
"forceoff" SMT is force disabled. Cannot be changed.
|
||||
"notsupported" SMT is not supported by the CPU
|
||||
|
||||
If control status is "forceoff" or "notsupported" writes
|
||||
are rejected.
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
What: /sys/bus/i2c/devices/.../bd9571mwv-regulator.*.auto/backup_mode
|
||||
Date: Jul 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Geert Uytterhoeven <geert+renesas@glider.be>
|
||||
Description: Read/write the current state of DDR Backup Mode, which controls
|
||||
if DDR power rails will be kept powered during system suspend.
|
||||
("on"/"1" = enabled, "off"/"0" = disabled).
|
||||
Two types of power switches (or control signals) can be used:
|
||||
A. With a momentary power switch (or pulse signal), DDR
|
||||
Backup Mode is enabled by default when available, as the
|
||||
PMIC will be configured only during system suspend.
|
||||
B. With a toggle power switch (or level signal), the
|
||||
following steps must be followed exactly:
|
||||
1. Configure PMIC for backup mode, to change the role of
|
||||
the accessory power switch from a power switch to a
|
||||
wake-up switch,
|
||||
2. Switch accessory power switch off, to prepare for
|
||||
system suspend, which is a manual step not controlled
|
||||
by software,
|
||||
3. Suspend system,
|
||||
4. Switch accessory power switch on, to resume the
|
||||
system.
|
||||
DDR Backup Mode must be explicitly enabled by the user,
|
||||
to invoke step 1.
|
||||
See also Documentation/devicetree/bindings/mfd/bd9571mwv.txt.
|
||||
Users: User space applications for embedded boards equipped with a
|
||||
BD9571MWV PMIC.
|
||||
@@ -1,5 +1,7 @@
|
||||
00-INDEX
|
||||
- this file
|
||||
acpi-info.txt
|
||||
- info on how PCI host bridges are represented in ACPI
|
||||
MSI-HOWTO.txt
|
||||
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
|
||||
PCIEBUS-HOWTO.txt
|
||||
|
||||
@@ -0,0 +1,187 @@
|
||||
ACPI considerations for PCI host bridges
|
||||
|
||||
The general rule is that the ACPI namespace should describe everything the
|
||||
OS might use unless there's another way for the OS to find it [1, 2].
|
||||
|
||||
For example, there's no standard hardware mechanism for enumerating PCI
|
||||
host bridges, so the ACPI namespace must describe each host bridge, the
|
||||
method for accessing PCI config space below it, the address space windows
|
||||
the host bridge forwards to PCI (using _CRS), and the routing of legacy
|
||||
INTx interrupts (using _PRT).
|
||||
|
||||
PCI devices, which are below the host bridge, generally do not need to be
|
||||
described via ACPI. The OS can discover them via the standard PCI
|
||||
enumeration mechanism, using config accesses to discover and identify
|
||||
devices and read and size their BARs. However, ACPI may describe PCI
|
||||
devices if it provides power management or hotplug functionality for them
|
||||
or if the device has INTx interrupts connected by platform interrupt
|
||||
controllers and a _PRT is needed to describe those connections.
|
||||
|
||||
ACPI resource description is done via _CRS objects of devices in the ACPI
|
||||
namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
|
||||
_CRS and figure out what resource is being consumed even if it doesn't have
|
||||
a driver for the device [3]. That's important because it means an old OS
|
||||
can work correctly even on a system with new devices unknown to the OS.
|
||||
The new devices might not do anything, but the OS can at least make sure no
|
||||
resources conflict with them.
|
||||
|
||||
Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
|
||||
reserving address space. The static tables are for things the OS needs to
|
||||
know early in boot, before it can parse the ACPI namespace. If a new table
|
||||
is defined, an old OS needs to operate correctly even though it ignores the
|
||||
table. _CRS allows that because it is generic and understood by the old
|
||||
OS; a static table does not.
|
||||
|
||||
If the OS is expected to manage a non-discoverable device described via
|
||||
ACPI, that device will have a specific _HID/_CID that tells the OS what
|
||||
driver to bind to it, and the _CRS tells the OS and the driver where the
|
||||
device's registers are.
|
||||
|
||||
PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
|
||||
describe all the address space they consume. This includes all the windows
|
||||
they forward down to the PCI bus, as well as registers of the host bridge
|
||||
itself that are not forwarded to PCI. The host bridge registers include
|
||||
things like secondary/subordinate bus registers that determine the bus
|
||||
range below the bridge, window registers that describe the apertures, etc.
|
||||
These are all device-specific, non-architected things, so the only way a
|
||||
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
|
||||
the device-specific details. The host bridge registers also include ECAM
|
||||
space, since it is consumed by the host bridge.
|
||||
|
||||
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
|
||||
("Consumer") from the bridge apertures ("Producer") [4, 5], but early
|
||||
BIOSes didn't use that bit correctly. The result is that the current ACPI
|
||||
spec defines Consumer/Producer only for the Extended Address Space
|
||||
descriptors; the bit should be ignored in the older QWord/DWord/Word
|
||||
Address Space descriptors. Consequently, OSes have to assume all
|
||||
QWord/DWord/Word descriptors are windows.
|
||||
|
||||
Prior to the addition of Extended Address Space descriptors, the failure of
|
||||
Consumer/Producer meant there was no way to describe bridge registers in
|
||||
the PNP0A03/PNP0A08 device itself. The workaround was to describe the
|
||||
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
|
||||
With the exception of ECAM, the bridge register space is device-specific
|
||||
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
|
||||
know about it.
|
||||
|
||||
New architectures should be able to use "Consumer" Extended Address Space
|
||||
descriptors in the PNP0A03 device for bridge registers, including ECAM,
|
||||
although a strict interpretation of [6] might prohibit this. Old x86 and
|
||||
ia64 kernels assume all address space descriptors, including "Consumer"
|
||||
Extended Address Space ones, are windows, so it would not be safe to
|
||||
describe bridge registers this way on those architectures.
|
||||
|
||||
PNP0C02 "motherboard" devices are basically a catch-all. There's no
|
||||
programming model for them other than "don't use these resources for
|
||||
anything else." So a PNP0C02 _CRS should claim any address space that is
|
||||
(1) not claimed by _CRS under any other device object in the ACPI namespace
|
||||
and (2) should not be assigned by the OS to something else.
|
||||
|
||||
The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
|
||||
unless there's a standard firmware interface for config access, e.g., the
|
||||
ia64 SAL interface [7]. A host bridge consumes ECAM memory address space
|
||||
and converts memory accesses into PCI configuration accesses. The spec
|
||||
defines the ECAM address space layout and functionality; only the base of
|
||||
the address space is device-specific. An ACPI OS learns the base address
|
||||
from either the static MCFG table or a _CBA method in the PNP0A03 device.
|
||||
|
||||
The MCFG table must describe the ECAM space of non-hot pluggable host
|
||||
bridges [8]. Since MCFG is a static table and can't be updated by hotplug,
|
||||
a _CBA method in the PNP0A03 device describes the ECAM space of a
|
||||
hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base
|
||||
address always corresponds to bus 0, even if the bus range below the bridge
|
||||
(which is reported via _CRS) doesn't start at 0.
|
||||
|
||||
|
||||
[1] ACPI 6.2, sec 6.1:
|
||||
For any device that is on a non-enumerable type of bus (for example, an
|
||||
ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
|
||||
system firmware must supply an _HID object ... for each device to
|
||||
enable OSPM to do that.
|
||||
|
||||
[2] ACPI 6.2, sec 3.7:
|
||||
The OS enumerates motherboard devices simply by reading through the
|
||||
ACPI Namespace looking for devices with hardware IDs.
|
||||
|
||||
Each device enumerated by ACPI includes ACPI-defined objects in the
|
||||
ACPI Namespace that report the hardware resources the device could
|
||||
occupy [_PRS], an object that reports the resources that are currently
|
||||
used by the device [_CRS], and objects for configuring those resources
|
||||
[_SRS]. The information is used by the Plug and Play OS (OSPM) to
|
||||
configure the devices.
|
||||
|
||||
[3] ACPI 6.2, sec 6.2:
|
||||
OSPM uses device configuration objects to configure hardware resources
|
||||
for devices enumerated via ACPI. Device configuration objects provide
|
||||
information about current and possible resource requirements, the
|
||||
relationship between shared resources, and methods for configuring
|
||||
hardware resources.
|
||||
|
||||
When OSPM enumerates a device, it calls _PRS to determine the resource
|
||||
requirements of the device. It may also call _CRS to find the current
|
||||
resource settings for the device. Using this information, the Plug and
|
||||
Play system determines what resources the device should consume and
|
||||
sets those resources by calling the device’s _SRS control method.
|
||||
|
||||
In ACPI, devices can consume resources (for example, legacy keyboards),
|
||||
provide resources (for example, a proprietary PCI bridge), or do both.
|
||||
Unless otherwise specified, resources for a device are assumed to be
|
||||
taken from the nearest matching resource above the device in the device
|
||||
hierarchy.
|
||||
|
||||
[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
|
||||
QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
|
||||
General Flags: Bit [0] Ignored
|
||||
|
||||
Extended Address Space Descriptor (.4)
|
||||
General Flags: Bit [0] Consumer/Producer:
|
||||
1–This device consumes this resource
|
||||
0–This device produces and consumes this resource
|
||||
|
||||
[5] ACPI 6.2, sec 19.6.43:
|
||||
ResourceUsage specifies whether the Memory range is consumed by
|
||||
this device (ResourceConsumer) or passed on to child devices
|
||||
(ResourceProducer). If nothing is specified, then
|
||||
ResourceConsumer is assumed.
|
||||
|
||||
[6] PCI Firmware 3.2, sec 4.1.2:
|
||||
If the operating system does not natively comprehend reserving the
|
||||
MMCFG region, the MMCFG region must be reserved by firmware. The
|
||||
address range reported in the MCFG table or by _CBA method (see Section
|
||||
4.1.3) must be reserved by declaring a motherboard resource. For most
|
||||
systems, the motherboard resource would appear at the root of the ACPI
|
||||
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
|
||||
the resources in this case should not be claimed in the root PCI bus’s
|
||||
_CRS. The resources can optionally be returned in Int15 E820 or
|
||||
EFIGetMemoryMap as reserved memory but must always be reported through
|
||||
ACPI as a motherboard resource.
|
||||
|
||||
[7] PCI Express 4.0, sec 7.2.2:
|
||||
For systems that are PC-compatible, or that do not implement a
|
||||
processor-architecture-specific firmware interface standard that allows
|
||||
access to the Configuration Space, the ECAM is required as defined in
|
||||
this section.
|
||||
|
||||
[8] PCI Firmware 3.2, sec 4.1.2:
|
||||
The MCFG table is an ACPI table that is used to communicate the base
|
||||
addresses corresponding to the non-hot removable PCI Segment Groups
|
||||
range within a PCI Segment Group available to the operating system at
|
||||
boot. This is required for the PC-compatible systems.
|
||||
|
||||
The MCFG table is only used to communicate the base addresses
|
||||
corresponding to the PCI Segment Groups available to the system at
|
||||
boot.
|
||||
|
||||
[9] PCI Firmware 3.2, sec 4.1.3:
|
||||
The _CBA (Memory mapped Configuration Base Address) control method is
|
||||
an optional ACPI object that returns the 64-bit memory mapped
|
||||
configuration base address for the hot plug capable host bridge. The
|
||||
base address returned by _CBA is processor-relative address. The _CBA
|
||||
control method evaluates to an Integer.
|
||||
|
||||
This control method appears under a host bridge object. When the _CBA
|
||||
method appears under an active host bridge object, the operating system
|
||||
evaluates this structure to identify the memory mapped configuration
|
||||
base address corresponding to the PCI Segment Group for the bus number
|
||||
range specified in _CRS method. An ACPI name space object that contains
|
||||
the _CBA method must also contain a corresponding _SEG method.
|
||||
@@ -15,3 +15,5 @@ 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
|
||||
msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X
|
||||
interrupts to test
|
||||
|
||||
@@ -44,7 +44,7 @@ by the PCI controller driver.
|
||||
* 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
|
||||
* raise_irq: ops to raise a legacy, MSI or MSI-X interrupt
|
||||
* start: ops to start the PCI link
|
||||
* stop: ops to stop the PCI link
|
||||
|
||||
@@ -96,7 +96,7 @@ by the PCI endpoint function driver.
|
||||
*) pci_epc_raise_irq()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
|
||||
Legacy Interrupt or MSI Interrupt.
|
||||
Legacy Interrupt, MSI or MSI-X Interrupt.
|
||||
|
||||
*) pci_epc_mem_alloc_addr()
|
||||
|
||||
|
||||
@@ -20,6 +20,8 @@ The PCI endpoint test device has the following registers:
|
||||
5) PCI_ENDPOINT_TEST_DST_ADDR
|
||||
6) PCI_ENDPOINT_TEST_SIZE
|
||||
7) PCI_ENDPOINT_TEST_CHECKSUM
|
||||
8) PCI_ENDPOINT_TEST_IRQ_TYPE
|
||||
9) PCI_ENDPOINT_TEST_IRQ_NUMBER
|
||||
|
||||
*) PCI_ENDPOINT_TEST_MAGIC
|
||||
|
||||
@@ -34,10 +36,10 @@ 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
|
||||
Bit 2 : raise MSI-X IRQ
|
||||
Bit 3 : read command (read data from RC buffer)
|
||||
Bit 4 : write command (write data to RC buffer)
|
||||
Bit 5 : copy command (copy data from one RC buffer to another
|
||||
RC buffer)
|
||||
|
||||
*) PCI_ENDPOINT_TEST_STATUS
|
||||
@@ -64,3 +66,22 @@ COPY/READ command.
|
||||
|
||||
This register contains the destination address (RC buffer address) for
|
||||
the COPY/WRITE command.
|
||||
|
||||
*) PCI_ENDPOINT_TEST_IRQ_TYPE
|
||||
|
||||
This register contains the interrupt type (Legacy/MSI) triggered
|
||||
for the READ/WRITE/COPY and raise IRQ (Legacy/MSI) commands.
|
||||
|
||||
Possible types:
|
||||
- Legacy : 0
|
||||
- MSI : 1
|
||||
- MSI-X : 2
|
||||
|
||||
*) PCI_ENDPOINT_TEST_IRQ_NUMBER
|
||||
|
||||
This register contains the triggered ID interrupt.
|
||||
|
||||
Admissible values:
|
||||
- Legacy : 0
|
||||
- MSI : [1 .. 32]
|
||||
- MSI-X : [1 .. 2048]
|
||||
|
||||
@@ -45,9 +45,9 @@ 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
|
||||
baseclass_code interrupt_pin progif_code subsys_id
|
||||
cache_line_size msi_interrupts revid subsys_vendorid
|
||||
deviceid msix_interrupts subclass_code vendorid
|
||||
|
||||
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
|
||||
@@ -67,6 +67,7 @@ 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
|
||||
# echo 8 > functions/pci_epf_test/func1/msix_interrupts
|
||||
|
||||
1.5 Binding pci-epf-test Device to EP Controller
|
||||
|
||||
@@ -120,7 +121,9 @@ following commands.
|
||||
|
||||
Interrupt tests
|
||||
|
||||
SET IRQ TYPE TO LEGACY: OKAY
|
||||
LEGACY IRQ: NOT OKAY
|
||||
SET IRQ TYPE TO MSI: OKAY
|
||||
MSI1: OKAY
|
||||
MSI2: OKAY
|
||||
MSI3: OKAY
|
||||
@@ -153,9 +156,30 @@ following commands.
|
||||
MSI30: NOT OKAY
|
||||
MSI31: NOT OKAY
|
||||
MSI32: NOT OKAY
|
||||
SET IRQ TYPE TO MSI-X: OKAY
|
||||
MSI-X1: OKAY
|
||||
MSI-X2: OKAY
|
||||
MSI-X3: OKAY
|
||||
MSI-X4: OKAY
|
||||
MSI-X5: OKAY
|
||||
MSI-X6: OKAY
|
||||
MSI-X7: OKAY
|
||||
MSI-X8: OKAY
|
||||
MSI-X9: NOT OKAY
|
||||
MSI-X10: NOT OKAY
|
||||
MSI-X11: NOT OKAY
|
||||
MSI-X12: NOT OKAY
|
||||
MSI-X13: NOT OKAY
|
||||
MSI-X14: NOT OKAY
|
||||
MSI-X15: NOT OKAY
|
||||
MSI-X16: NOT OKAY
|
||||
[...]
|
||||
MSI-X2047: NOT OKAY
|
||||
MSI-X2048: NOT OKAY
|
||||
|
||||
Read Tests
|
||||
|
||||
SET IRQ TYPE TO MSI: OKAY
|
||||
READ ( 1 bytes): OKAY
|
||||
READ ( 1024 bytes): OKAY
|
||||
READ ( 1025 bytes): OKAY
|
||||
|
||||
@@ -73,6 +73,11 @@ In the example, 'Requester ID' means the ID of the device who sends
|
||||
the error message to root port. Pls. refer to pci express specs for
|
||||
other fields.
|
||||
|
||||
2.4 AER Statistics / Counters
|
||||
|
||||
When PCIe AER errors are captured, the counters / statistics are also exposed
|
||||
in the form of sysfs attributes which are documented at
|
||||
Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
|
||||
|
||||
3. Developer Guide
|
||||
|
||||
|
||||
@@ -380,31 +380,26 @@ and therefore need no protection.
|
||||
as follows:
|
||||
|
||||
<pre>
|
||||
1 unsigned long gpnum;
|
||||
2 unsigned long completed;
|
||||
1 unsigned long gp_seq;
|
||||
</pre>
|
||||
|
||||
<p>RCU grace periods are numbered, and
|
||||
the <tt>->gpnum</tt> field contains the number of the grace
|
||||
period that started most recently.
|
||||
The <tt>->completed</tt> field contains the number of the
|
||||
grace period that completed most recently.
|
||||
If the two fields are equal, the RCU grace period that most recently
|
||||
started has already completed, and therefore the corresponding
|
||||
flavor of RCU is idle.
|
||||
If <tt>->gpnum</tt> is one greater than <tt>->completed</tt>,
|
||||
then <tt>->gpnum</tt> gives the number of the current RCU
|
||||
grace period, which has not yet completed.
|
||||
Any other combination of values indicates that something is broken.
|
||||
These two fields are protected by the root <tt>rcu_node</tt>'s
|
||||
the <tt>->gp_seq</tt> field contains the current grace-period
|
||||
sequence number.
|
||||
The bottom two bits are the state of the current grace period,
|
||||
which can be zero for not yet started or one for in progress.
|
||||
In other words, if the bottom two bits of <tt>->gp_seq</tt> are
|
||||
zero, the corresponding flavor of RCU is idle.
|
||||
Any other value in the bottom two bits indicates that something is broken.
|
||||
This field is protected by the root <tt>rcu_node</tt> structure's
|
||||
<tt>->lock</tt> field.
|
||||
|
||||
</p><p>There are <tt>->gpnum</tt> and <tt>->completed</tt> fields
|
||||
</p><p>There are <tt>->gp_seq</tt> fields
|
||||
in the <tt>rcu_node</tt> and <tt>rcu_data</tt> structures
|
||||
as well.
|
||||
The fields in the <tt>rcu_state</tt> structure represent the
|
||||
most current values, and those of the other structures are compared
|
||||
in order to detect the start of a new grace period in a distributed
|
||||
most current value, and those of the other structures are compared
|
||||
in order to detect the beginnings and ends of grace periods in a distributed
|
||||
fashion.
|
||||
The values flow from <tt>rcu_state</tt> to <tt>rcu_node</tt>
|
||||
(down the tree from the root to the leaves) to <tt>rcu_data</tt>.
|
||||
@@ -512,27 +507,47 @@ than to be heisenbugged out of existence.
|
||||
as follows:
|
||||
|
||||
<pre>
|
||||
1 unsigned long gpnum;
|
||||
2 unsigned long completed;
|
||||
1 unsigned long gp_seq;
|
||||
2 unsigned long gp_seq_needed;
|
||||
</pre>
|
||||
|
||||
<p>These fields are the counterparts of the fields of the same name in
|
||||
the <tt>rcu_state</tt> structure.
|
||||
They each may lag up to one behind their <tt>rcu_state</tt>
|
||||
counterparts.
|
||||
If a given <tt>rcu_node</tt> structure's <tt>->gpnum</tt> and
|
||||
<tt>->complete</tt> fields are equal, then this <tt>rcu_node</tt>
|
||||
<p>The <tt>rcu_node</tt> structures' <tt>->gp_seq</tt> fields are
|
||||
the counterparts of the field of the same name in the <tt>rcu_state</tt>
|
||||
structure.
|
||||
They each may lag up to one step behind their <tt>rcu_state</tt>
|
||||
counterpart.
|
||||
If the bottom two bits of a given <tt>rcu_node</tt> structure's
|
||||
<tt>->gp_seq</tt> field is zero, then this <tt>rcu_node</tt>
|
||||
structure believes that RCU is idle.
|
||||
Otherwise, as with the <tt>rcu_state</tt> structure,
|
||||
the <tt>->gpnum</tt> field will be one greater than the
|
||||
<tt>->complete</tt> fields, with <tt>->gpnum</tt>
|
||||
indicating which grace period this <tt>rcu_node</tt> believes
|
||||
is still being waited for.
|
||||
</p><p>The <tt>>gp_seq</tt> field of each <tt>rcu_node</tt>
|
||||
structure is updated at the beginning and the end
|
||||
of each grace period.
|
||||
|
||||
</p><p>The <tt>>gpnum</tt> field of each <tt>rcu_node</tt>
|
||||
structure is updated at the beginning
|
||||
of each grace period, and the <tt>->completed</tt> fields are
|
||||
updated at the end of each grace period.
|
||||
<p>The <tt>->gp_seq_needed</tt> fields record the
|
||||
furthest-in-the-future grace period request seen by the corresponding
|
||||
<tt>rcu_node</tt> structure. The request is considered fulfilled when
|
||||
the value of the <tt>->gp_seq</tt> field equals or exceeds that of
|
||||
the <tt>->gp_seq_needed</tt> field.
|
||||
|
||||
<table>
|
||||
<tr><th> </th></tr>
|
||||
<tr><th align="left">Quick Quiz:</th></tr>
|
||||
<tr><td>
|
||||
Suppose that this <tt>rcu_node</tt> structure doesn't see
|
||||
a request for a very long time.
|
||||
Won't wrapping of the <tt>->gp_seq</tt> field cause
|
||||
problems?
|
||||
</td></tr>
|
||||
<tr><th align="left">Answer:</th></tr>
|
||||
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
||||
No, because if the <tt>->gp_seq_needed</tt> field lags behind the
|
||||
<tt>->gp_seq</tt> field, the <tt>->gp_seq_needed</tt> field
|
||||
will be updated at the end of the grace period.
|
||||
Modulo-arithmetic comparisons therefore will always get the
|
||||
correct answer, even with wrapping.
|
||||
</font></td></tr>
|
||||
<tr><td> </td></tr>
|
||||
</table>
|
||||
|
||||
<h5>Quiescent-State Tracking</h5>
|
||||
|
||||
@@ -626,9 +641,8 @@ normal and expedited grace periods, respectively.
|
||||
</ol>
|
||||
|
||||
<p><font color="ffffff">So the locking is absolutely required in
|
||||
order to coordinate
|
||||
clearing of the bits with the grace-period numbers in
|
||||
<tt>->gpnum</tt> and <tt>->completed</tt>.
|
||||
order to coordinate clearing of the bits with updating of the
|
||||
grace-period sequence number in <tt>->gp_seq</tt>.
|
||||
</font></td></tr>
|
||||
<tr><td> </td></tr>
|
||||
</table>
|
||||
@@ -1038,15 +1052,15 @@ out any <tt>rcu_data</tt> structure for which this flag is not set.
|
||||
as follows:
|
||||
|
||||
<pre>
|
||||
1 unsigned long completed;
|
||||
2 unsigned long gpnum;
|
||||
1 unsigned long gp_seq;
|
||||
2 unsigned long gp_seq_needed;
|
||||
3 bool cpu_no_qs;
|
||||
4 bool core_needs_qs;
|
||||
5 bool gpwrap;
|
||||
6 unsigned long rcu_qs_ctr_snap;
|
||||
</pre>
|
||||
|
||||
<p>The <tt>completed</tt> and <tt>gpnum</tt>
|
||||
<p>The <tt>->gp_seq</tt> and <tt>->gp_seq_needed</tt>
|
||||
fields are the counterparts of the fields of the same name
|
||||
in the <tt>rcu_state</tt> and <tt>rcu_node</tt> structures.
|
||||
They may each lag up to one behind their <tt>rcu_node</tt>
|
||||
@@ -1054,15 +1068,9 @@ counterparts, but in <tt>CONFIG_NO_HZ_IDLE</tt> and
|
||||
<tt>CONFIG_NO_HZ_FULL</tt> kernels can lag
|
||||
arbitrarily far behind for CPUs in dyntick-idle mode (but these counters
|
||||
will catch up upon exit from dyntick-idle mode).
|
||||
If a given <tt>rcu_data</tt> structure's <tt>->gpnum</tt> and
|
||||
<tt>->complete</tt> fields are equal, then this <tt>rcu_data</tt>
|
||||
If the lower two bits of a given <tt>rcu_data</tt> structure's
|
||||
<tt>->gp_seq</tt> are zero, then this <tt>rcu_data</tt>
|
||||
structure believes that RCU is idle.
|
||||
Otherwise, as with the <tt>rcu_state</tt> and <tt>rcu_node</tt>
|
||||
structure,
|
||||
the <tt>->gpnum</tt> field will be one greater than the
|
||||
<tt>->complete</tt> fields, with <tt>->gpnum</tt>
|
||||
indicating which grace period this <tt>rcu_data</tt> believes
|
||||
is still being waited for.
|
||||
|
||||
<table>
|
||||
<tr><th> </th></tr>
|
||||
@@ -1070,13 +1078,13 @@ is still being waited for.
|
||||
<tr><td>
|
||||
All this replication of the grace period numbers can only cause
|
||||
massive confusion.
|
||||
Why not just keep a global pair of counters and be done with it???
|
||||
Why not just keep a global sequence number and be done with it???
|
||||
</td></tr>
|
||||
<tr><th align="left">Answer:</th></tr>
|
||||
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
||||
Because if there was only a single global pair of grace-period
|
||||
Because if there was only a single global sequence
|
||||
numbers, there would need to be a single global lock to allow
|
||||
safely accessing and updating them.
|
||||
safely accessing and updating it.
|
||||
And if we are not going to have a single global lock, we need
|
||||
to carefully manage the numbers on a per-node basis.
|
||||
Recall from the answer to a previous Quick Quiz that the consequences
|
||||
@@ -1091,8 +1099,8 @@ CPU has not yet passed through a quiescent state,
|
||||
while the <tt>->core_needs_qs</tt> flag indicates that the
|
||||
RCU core needs a quiescent state from the corresponding CPU.
|
||||
The <tt>->gpwrap</tt> field indicates that the corresponding
|
||||
CPU has remained idle for so long that the <tt>completed</tt>
|
||||
and <tt>gpnum</tt> counters are in danger of overflow, which
|
||||
CPU has remained idle for so long that the
|
||||
<tt>gp_seq</tt> counter is in danger of overflow, which
|
||||
will cause the CPU to disregard the values of its counters on
|
||||
its next exit from idle.
|
||||
Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
|
||||
@@ -1130,10 +1138,10 @@ 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
|
||||
that the value of its <tt>rcu_data</tt> structure's
|
||||
<tt>->completed</tt> field differs from that of its leaf
|
||||
<tt>->gp_seq</tt> field differs from that of its leaf
|
||||
<tt>rcu_node</tt> structure.
|
||||
Recall that each <tt>rcu_node</tt> structure's
|
||||
<tt>->completed</tt> field is updated at the end of each
|
||||
<tt>->gp_seq</tt> field is updated at the beginnings and ends of each
|
||||
grace period.
|
||||
|
||||
<p>
|
||||
|
||||
@@ -357,7 +357,7 @@ parts, starting in this section with the various phases of
|
||||
grace-period initialization.
|
||||
|
||||
<p>The first ordering-related grace-period initialization action is to
|
||||
increment the <tt>rcu_state</tt> structure's <tt>->gpnum</tt>
|
||||
advance the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt>
|
||||
grace-period-number counter, as shown below:
|
||||
|
||||
</p><p><img src="TreeRCU-gp-init-1.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
||||
@@ -388,7 +388,7 @@ its last CPU and if the next <tt>rcu_node</tt> structure has no online CPUs).
|
||||
|
||||
<p>The final <tt>rcu_gp_init()</tt> pass through the <tt>rcu_node</tt>
|
||||
tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
|
||||
<tt>->gpnum</tt> field to the newly incremented value from the
|
||||
<tt>->gp_seq</tt> field to the newly advanced value from the
|
||||
<tt>rcu_state</tt> structure, as shown in the following diagram.
|
||||
|
||||
</p><p><img src="TreeRCU-gp-init-3.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
||||
@@ -398,9 +398,9 @@ tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
|
||||
to notice that a new grace period has started, as described in the next
|
||||
section.
|
||||
But because the grace-period kthread started the grace period at the
|
||||
root (with the increment of the <tt>rcu_state</tt> structure's
|
||||
<tt>->gpnum</tt> field) before setting each leaf <tt>rcu_node</tt>
|
||||
structure's <tt>->gpnum</tt> field, each CPU's observation of
|
||||
root (with the advancing of the <tt>rcu_state</tt> structure's
|
||||
<tt>->gp_seq</tt> field) before setting each leaf <tt>rcu_node</tt>
|
||||
structure's <tt>->gp_seq</tt> field, each CPU's observation of
|
||||
the start of the grace period will happen after the actual start
|
||||
of the grace period.
|
||||
|
||||
@@ -466,7 +466,7 @@ section that the grace period must wait on.
|
||||
<tr><td>
|
||||
But a RCU read-side critical section might have started
|
||||
after the beginning of the grace period
|
||||
(the <tt>->gpnum++</tt> from earlier), so why should
|
||||
(the advancing of <tt>->gp_seq</tt> from earlier), so why should
|
||||
the grace period wait on such a critical section?
|
||||
</td></tr>
|
||||
<tr><th align="left">Answer:</th></tr>
|
||||
@@ -609,10 +609,8 @@ states outstanding from other CPUs.
|
||||
<h4><a name="Grace-Period Cleanup">Grace-Period Cleanup</a></h4>
|
||||
|
||||
<p>Grace-period cleanup first scans the <tt>rcu_node</tt> tree
|
||||
breadth-first setting all the <tt>->completed</tt> fields equal
|
||||
to the number of the newly completed grace period, then it sets
|
||||
the <tt>rcu_state</tt> structure's <tt>->completed</tt> field,
|
||||
again to the number of the newly completed grace period.
|
||||
breadth-first advancing all the <tt>->gp_seq</tt> fields, then it
|
||||
advances the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt> field.
|
||||
The ordering effects are shown below:
|
||||
|
||||
</p><p><img src="TreeRCU-gp-cleanup.svg" alt="TreeRCU-gp-cleanup.svg" width="75%">
|
||||
@@ -634,7 +632,7 @@ grace-period cleanup is complete, the next grace period can begin.
|
||||
CPU has reported its quiescent state, but it may be some
|
||||
milliseconds before RCU becomes aware of this.
|
||||
The latest reasonable candidate is once the <tt>rcu_state</tt>
|
||||
structure's <tt>->completed</tt> field has been updated,
|
||||
structure's <tt>->gp_seq</tt> field has been updated,
|
||||
but it is quite possible that some CPUs have already completed
|
||||
phase two of their updates by that time.
|
||||
In short, if you are going to work with RCU, you need to
|
||||
@@ -647,7 +645,7 @@ grace-period cleanup is complete, the next grace period can begin.
|
||||
<h4><a name="Callback Invocation">Callback Invocation</a></h4>
|
||||
|
||||
<p>Once a given CPU's leaf <tt>rcu_node</tt> structure's
|
||||
<tt>->completed</tt> field has been updated, that CPU can begin
|
||||
<tt>->gp_seq</tt> field has been updated, that CPU can begin
|
||||
invoking its RCU callbacks that were waiting for this grace period
|
||||
to end.
|
||||
These callbacks are identified by <tt>rcu_advance_cbs()</tt>,
|
||||
|
||||
@@ -384,11 +384,11 @@
|
||||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.70710678"
|
||||
inkscape:cx="617.89017"
|
||||
inkscape:cy="542.52419"
|
||||
inkscape:window-x="86"
|
||||
inkscape:window-y="28"
|
||||
inkscape:zoom="0.78716603"
|
||||
inkscape:cx="513.06403"
|
||||
inkscape:cy="623.1214"
|
||||
inkscape:window-x="102"
|
||||
inkscape:window-y="38"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="g3188-3"
|
||||
fit-margin-top="5"
|
||||
@@ -417,13 +417,15 @@
|
||||
id="g3188">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3199.1516"
|
||||
x="3145.9592"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->completed = ->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3143">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
<g
|
||||
id="g3107"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
@@ -502,13 +504,15 @@
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5324.5371"
|
||||
y="15414.598"
|
||||
x="5264.4731"
|
||||
y="15428.84"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-753"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-7"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-5">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
@@ -547,15 +551,6 @@
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7479.5796"
|
||||
y="17699.943"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-9"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
<path
|
||||
sodipodi:nodetypes="cc"
|
||||
inkscape:connector-curvature="0"
|
||||
@@ -566,15 +561,6 @@
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(-737.93887,7732.6672)"
|
||||
id="g3188-3">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3225.7478"
|
||||
y="13175.802"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-60"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->completed =</text>
|
||||
<g
|
||||
id="g3107-62"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
@@ -607,15 +593,6 @@
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-7">Root</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3225.7478"
|
||||
y="13390.038"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-60-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"> rnp->completed</text>
|
||||
<flowRoot
|
||||
xml:space="preserve"
|
||||
id="flowRoot3356"
|
||||
@@ -627,7 +604,18 @@
|
||||
height="63.63961"
|
||||
x="332.34018"
|
||||
y="681.87292" /></flowRegion><flowPara
|
||||
id="flowPara3362" /></flowRoot> </g>
|
||||
id="flowPara3362" /></flowRoot> <text
|
||||
xml:space="preserve"
|
||||
x="3156.6121"
|
||||
y="13317.754"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-0">rcu_seq_end(&rsp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(-858.40227,7769.0342)"
|
||||
@@ -859,6 +847,17 @@
|
||||
id="path3414-8-3-6-6"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7418.769"
|
||||
y="17646.104"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-70"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-93">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-1642.5377,-11611.245)"
|
||||
@@ -887,13 +886,15 @@
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5327.3057"
|
||||
x="5274.1133"
|
||||
y="15428.84"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-151.71746,-11647.612)"
|
||||
@@ -972,13 +973,15 @@
|
||||
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7486.4907"
|
||||
y="17670.119"
|
||||
x="7408.5918"
|
||||
y="17619.504"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-9">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-6817.1997,-11647.612)"
|
||||
@@ -1019,13 +1022,15 @@
|
||||
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7474.1382"
|
||||
y="17688.926"
|
||||
x="7416.8003"
|
||||
y="17619.504"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-5"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-56">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||
@@ -1059,15 +1064,6 @@
|
||||
id="path3414-8-3-6"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7318.9653"
|
||||
y="6031.6353"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
id="g4504-3-9"
|
||||
@@ -1123,4 +1119,15 @@
|
||||
id="path3134-9-0-3-5"
|
||||
d="m 6875.6003,15833.906 1595.7755,0"
|
||||
style="fill:none;stroke:#969696;stroke-width:53.19251633;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send-36)" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7275.2612"
|
||||
y="5971.8916"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-2">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</svg>
|
||||
|
||||
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
@@ -272,13 +272,13 @@
|
||||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.70710678"
|
||||
inkscape:cx="617.89019"
|
||||
inkscape:cy="636.57143"
|
||||
inkscape:window-x="697"
|
||||
inkscape:zoom="2.6330492"
|
||||
inkscape:cx="524.82797"
|
||||
inkscape:cy="519.31194"
|
||||
inkscape:window-x="79"
|
||||
inkscape:window-y="28"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="svg2"
|
||||
inkscape:current-layer="g3188"
|
||||
fit-margin-top="5"
|
||||
fit-margin-right="5"
|
||||
fit-margin-left="5"
|
||||
@@ -305,13 +305,15 @@
|
||||
id="g3188">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3305.5364"
|
||||
x="3119.363"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->gpnum++</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3071">rcu_seq_start(rsp->gp_seq)</tspan></text>
|
||||
<g
|
||||
id="g3107"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
||||
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 24 KiB |
@@ -19,7 +19,7 @@
|
||||
id="svg2"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="TreeRCU-gp-init-2.svg">
|
||||
sodipodi:docname="TreeRCU-gp-init-3.svg">
|
||||
<metadata
|
||||
id="metadata212">
|
||||
<rdf:RDF>
|
||||
@@ -257,18 +257,22 @@
|
||||
inkscape:window-width="1087"
|
||||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="false"
|
||||
inkscape:zoom="0.70710678"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.68224756"
|
||||
inkscape:cx="617.89019"
|
||||
inkscape:cy="625.84293"
|
||||
inkscape:window-x="697"
|
||||
inkscape:window-x="54"
|
||||
inkscape:window-y="28"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="svg2"
|
||||
inkscape:current-layer="g3153"
|
||||
fit-margin-top="5"
|
||||
fit-margin-right="5"
|
||||
fit-margin-left="5"
|
||||
fit-margin-bottom="5" />
|
||||
fit-margin-bottom="5">
|
||||
<inkscape:grid
|
||||
type="xygrid"
|
||||
id="grid3090" />
|
||||
</sodipodi:namedview>
|
||||
<path
|
||||
sodipodi:nodetypes="cccccccccccccccccccccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
@@ -281,13 +285,13 @@
|
||||
id="g3188">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3305.5364"
|
||||
x="3145.9592"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
<g
|
||||
id="g3107"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
@@ -366,13 +370,13 @@
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5392.3345"
|
||||
y="15407.104"
|
||||
x="5253.6904"
|
||||
y="15407.032"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
@@ -413,13 +417,13 @@
|
||||
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7536.4883"
|
||||
y="17640.934"
|
||||
x="7415.4365"
|
||||
y="17670.572"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-9"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-1642.5375,-11610.962)"
|
||||
@@ -448,13 +452,13 @@
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5378.4146"
|
||||
y="15436.927"
|
||||
x="5258.0688"
|
||||
y="15412.313"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-151.71726,-11647.329)"
|
||||
@@ -533,13 +537,13 @@
|
||||
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7520.1294"
|
||||
y="17673.639"
|
||||
x="7405.2607"
|
||||
y="17670.572"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-35"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-6817.1998,-11647.329)"
|
||||
@@ -580,13 +584,13 @@
|
||||
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7521.4663"
|
||||
y="17666.062"
|
||||
x="7413.4688"
|
||||
y="17670.566"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-75"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||
@@ -622,11 +626,11 @@
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7370.856"
|
||||
y="5997.5972"
|
||||
x="7271.9297"
|
||||
y="6023.2412"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-62"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</svg>
|
||||
|
||||
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 23 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user