Searched full:system (Results 1 – 25 of 5509) sorted by relevance
12345678910>>...221
| /Linux-v6.1/drivers/eisa/ |
| D | eisa.ids | 18 ACE1010 "ACME Super Fast System Board"
26 ACR1201 "Acer 1200 486/25 EISA System Board"
27 ACR1211 "AcerFrame 3000SP33 486/33 EISA System Board"
39 ACR1711 "AcerFrame 1000 486/33 SYSTEM-2"
40 ACR1801 "Acer P43WE EISA System Board"
41 ACR3211 "AcerFrame 3000MP 486 SYSTEM-1"
42 ACR3221 "AcerFrame 486 Series SYSTEM-2"
43 ACR3231 "AcerFrame 486 Series SYSTEM-3"
44 ACR3241 "AcerFrame 486 Series SYSTEM-4"
45 ACR3261 "AcerFrame 3000MP 486 SYSTEM-1"
[all …]
|
| /Linux-v6.1/Documentation/ABI/testing/ |
| D | sysfs-devices-system-cpu | 1 What: /sys/devices/system/cpu/
10 /sys/devices/system/cpu/cpuX/
12 What: /sys/devices/system/cpu/kernel_max
13 /sys/devices/system/cpu/offline
14 /sys/devices/system/cpu/online
15 /sys/devices/system/cpu/possible
16 /sys/devices/system/cpu/present
35 the system.
40 What: /sys/devices/system/cpu/probe
41 /sys/devices/system/cpu/release
[all …]
|
| D | sysfs-devices-memory | 1 What: /sys/devices/system/memory
5 The /sys/devices/system/memory contains a snapshot of the
12 What: /sys/devices/system/memory/memoryX/removable
16 The file /sys/devices/system/memory/memoryX/removable is a
24 What: /sys/devices/system/memory/memoryX/phys_device
28 The file /sys/devices/system/memory/memoryX/phys_device
33 What: /sys/devices/system/memory/memoryX/phys_index
37 The file /sys/devices/system/memory/memoryX/phys_index
42 What: /sys/devices/system/memory/memoryX/state
46 The file /sys/devices/system/memory/memoryX/state
[all …]
|
| D | sysfs-devices-edac | 1 What: /sys/devices/system/edac/mc/mc*/reset_counters
12 What: /sys/devices/system/edac/mc/mc*/seconds_since_reset
19 What: /sys/devices/system/edac/mc/mc*/mc_name
25 What: /sys/devices/system/edac/mc/mc*/size_mb
31 What: /sys/devices/system/edac/mc/mc*/ue_count
37 increment, since EDAC will panic the system
39 What: /sys/devices/system/edac/mc/mc*/ue_noinfo_count
46 What: /sys/devices/system/edac/mc/mc*/ce_count
54 such information to the system administrator.
56 What: /sys/devices/system/edac/mc/mc*/ce_noinfo_count
[all …]
|
| /Linux-v6.1/Documentation/admin-guide/pm/ |
| D | sleep-states.rst | 5 System Sleep States
13 Sleep states are global low-power states of the entire system in which user
14 space code cannot be executed and the overall system activity is significantly
22 the Linux kernel can support up to four system sleep states, including
23 hibernation and up to three variants of system suspend. The sleep states that
31 This is a generic, pure software, light-weight variant of system suspend (also
36 states while the system is suspended.
38 The system is woken up from this state by in-band interrupts, so theoretically
44 deeper system suspend variants to provide reduced resume latency. It is always
54 operating state is lost (the system core logic retains power), so the system can
[all …]
|
| D | suspend-flows.rst | 5 System Suspend Code Flows
12 At least one global system-wide transition needs to be carried out for the
13 system to get from the working state into one of the supported
16 referred to as *system-wide suspend* (or simply *system suspend*) states, need
19 For those sleep states, the transition from the working state of the system into
20 the target sleep state is referred to as *system suspend* too (in the majority
21 of cases, whether this means a transition or a sleep state of the system should
23 working state is referred to as *system resume*.
26 different sleep states of the system are quite similar, but there are some
45 The following steps are taken in order to transition the system from the working
[all …]
|
| D | strategies.rst | 15 One of them is based on using global low-power states of the whole system in
16 which user space code cannot be executed and the overall system activity is
18 kernel puts the system into one of these states when requested by user space
19 and the system stays in it until a special signal is received from one of
21 user space code can run. Because sleep states are global and the whole system
23 :doc:`system-wide power management <system-wide>`.
27 components of the system, as needed, in the working state. In consequence, if
28 this strategy is in use, the working state of the system usually does not
30 a metastate covering a range of different power states of the system in which
37 If all of the system components are active, the system as a whole is regarded as
[all …]
|
| /Linux-v6.1/arch/powerpc/include/asm/ |
| D | ipic.h | 26 #define IPIC_SICFR 0x00 /* System Global Interrupt Configuration Register */
27 #define IPIC_SIVCR 0x04 /* System Global Interrupt Vector Register */
28 #define IPIC_SIPNR_H 0x08 /* System Internal Interrupt Pending Register (HIGH) */
29 #define IPIC_SIPNR_L 0x0C /* System Internal Interrupt Pending Register (LOW) */
30 #define IPIC_SIPRR_A 0x10 /* System Internal Interrupt group A Priority Register */
31 #define IPIC_SIPRR_B 0x14 /* System Internal Interrupt group B Priority Register */
32 #define IPIC_SIPRR_C 0x18 /* System Internal Interrupt group C Priority Register */
33 #define IPIC_SIPRR_D 0x1C /* System Internal Interrupt group D Priority Register */
34 #define IPIC_SIMSR_H 0x20 /* System Internal Interrupt Mask Register (HIGH) */
35 #define IPIC_SIMSR_L 0x24 /* System Internal Interrupt Mask Register (LOW) */
[all …]
|
| /Linux-v6.1/include/asm-generic/ |
| D | syscall.h | 3 * Access to user system call parameters and results
23 * syscall_get_nr - find what system call a task is executing
27 * If @task is executing a system call or is at system call
28 * tracing about to attempt one, returns the system call number.
29 * If @task is not executing a system call, i.e. it's blocked
33 * system call number can be meaningful. If the actual arch value
41 * syscall_rollback - roll back registers after an aborted system call
42 * @task: task of interest, must be in system call exit tracing
45 * It's only valid to call this when @task is stopped for system
48 * returned nonzero to prevent the system call from taking place.
[all …]
|
| /Linux-v6.1/Documentation/process/ |
| D | adding-syscalls.rst | 4 Adding a New System Call
7 This document describes what's involved in adding a new system call to the
12 System Call Alternatives
15 The first thing to consider when adding a new system call is whether one of
16 the alternatives might be suitable instead. Although system calls are the
35 - If you're just exposing runtime system information, a new node in sysfs
43 :manpage:`fcntl(2)` is a multiplexing system call that hides a lot of complexity, so
49 with :manpage:`fcntl(2)`, this system call is a complicated multiplexor so
57 A new system call forms part of the API of the kernel, and has to be supported
63 together with the corresponding follow-up system calls --
[all …]
|
| /Linux-v6.1/Documentation/devicetree/bindings/arm/hisilicon/controller/ |
| D | sysctrl.yaml | 7 title: Hisilicon system controller
13 The Hisilicon system controller is used on many Hisilicon boards, it can be
14 used to assist the slave core startup, reboot the system, etc.
16 There are some variants of the Hisilicon system controller, such as HiP01,
17 Hi3519, Hi6220 system controller, each of them is mostly compatible with the
18 Hisilicon system controller, but some same registers located at different
19 offset. In addition, the HiP01 system controller has some specific control
22 The compatible names of each system controller are as follows:
23 Hisilicon system controller --> hisilicon,sysctrl
24 HiP01 system controller --> hisilicon,hip01-sysctrl
[all …]
|
| /Linux-v6.1/Documentation/livepatch/ |
| D | system-state.rst | 2 System State Changes
5 Some users are really reluctant to reboot a system. This brings the need
14 change the system behavior or state so that it is no longer safe to
19 This is where the livepatch system state tracking gets useful. It
22 - store data needed to manipulate and restore the system state
28 1. Livepatch system state API
31 The state of the system might get modified either by several livepatch callbacks
46 - Non-zero number used to identify the affected system state.
50 - Number describing the variant of the system state change that
68 The system state version is used to prevent loading incompatible livepatches.
[all …]
|
| /Linux-v6.1/Documentation/ABI/stable/ |
| D | sysfs-devices-node | 1 What: /sys/devices/system/node/possible
7 What: /sys/devices/system/node/online
13 What: /sys/devices/system/node/has_normal_memory
19 What: /sys/devices/system/node/has_cpu
25 What: /sys/devices/system/node/has_high_memory
32 What: /sys/devices/system/node/nodeX
40 What: /sys/devices/system/node/nodeX/cpumap
46 What: /sys/devices/system/node/nodeX/cpulist
52 What: /sys/devices/system/node/nodeX/meminfo
59 What: /sys/devices/system/node/nodeX/numastat
[all …]
|
| D | sysfs-devices-system-cpu | 1 What: /sys/devices/system/cpu/dscr_default
6 /sys/devices/system/cpu/cpuN/dscr on all CPUs.
12 What: /sys/devices/system/cpu/cpu[0-9]+/dscr
27 What: /sys/devices/system/cpu/cpuX/topology/physical_package_id
33 What: /sys/devices/system/cpu/cpuX/topology/die_id
39 What: /sys/devices/system/cpu/cpuX/topology/core_id
45 What: /sys/devices/system/cpu/cpuX/topology/cluster_id
51 What: /sys/devices/system/cpu/cpuX/topology/book_id
57 What: /sys/devices/system/cpu/cpuX/topology/drawer_id
63 What: /sys/devices/system/cpu/cpuX/topology/core_cpus
[all …]
|
| /Linux-v6.1/Documentation/devicetree/bindings/sram/ |
| D | allwinner,sun4i-a10-system-control.yaml | 4 $id: http://devicetree.org/schemas/sram/allwinner,sun4i-a10-system-control.yaml#
7 title: Allwinner A10 System Control
32 - allwinner,sun4i-a10-system-control
33 - allwinner,sun5i-a13-system-control
34 - allwinner,sun8i-a23-system-control
35 - allwinner,sun8i-h3-system-control
36 - allwinner,sun20i-d1-system-control
37 - allwinner,sun50i-a64-system-control
38 - allwinner,sun50i-h5-system-control
39 - allwinner,sun50i-h616-system-control
[all …]
|
| /Linux-v6.1/Documentation/devicetree/bindings/iommu/ |
| D | samsung,sysmmu.yaml | 7 title: Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit)
13 Samsung's Exynos architecture contains System MMUs that enables scattered
17 System MMU is an IOMMU and supports identical translation table format to
19 permissions, shareability and security protection. In addition, System MMU has
23 System MMUs are in many to one relation with peripheral devices, i.e. single
24 peripheral device might have multiple System MMUs (usually one for each bus
25 master), but one System MMU can handle transactions from only one peripheral
26 device. The relation between a System MMU and the peripheral device needs to be
29 MFC in all Exynos SoCs and FIMD, M2M Scalers and G2D in Exynos5420 has 2 System
31 * MFC has one System MMU on its left and right bus.
[all …]
|
| /Linux-v6.1/drivers/soc/renesas/ |
| D | Kconfig | 57 #comment "Renesas ARM SoCs System Type"
350 bool "System Controller support for R-Car" if COMPILE_TEST
353 bool "System Controller support for R-Car Gen4" if COMPILE_TEST
356 bool "System Controller support for R-Car D3" if COMPILE_TEST
360 bool "System Controller support for R-Car E2" if COMPILE_TEST
364 bool "System Controller support for R-Car E3" if COMPILE_TEST
368 bool "System Controller support for R-Car H1" if COMPILE_TEST
372 bool "System Controller support for R-Car H2" if COMPILE_TEST
376 bool "System Controller support for R-Car H3" if COMPILE_TEST
380 bool "System Controller support for R-Car M2-W/N" if COMPILE_TEST
[all …]
|
| /Linux-v6.1/Documentation/admin-guide/ |
| D | initrd.rst | 9 This RAM disk can then be mounted as the root file system and programs
10 can be run from it. Afterwards, a new root file system can be mounted
14 initrd is mainly designed to allow system startup to occur in two phases,
25 When using initrd, the system typically boots as follows:
38 6) init mounts the "real" root file system
39 7) init places the root file system at the root directory using the
40 pivot_root system call
43 9) the initrd file system is removed
65 the "normal" root file system is mounted. initrd data can be read
67 in this case and doesn't necessarily have to be a file system image.
[all …]
|
| /Linux-v6.1/tools/testing/selftests/ftrace/test.d/dynevent/ |
| D | add_remove_eprobe.tc | 10 SYSTEM="syscalls"
15 echo "e:$EPROBE $SYSTEM/$EVENT $OPTIONS" >> dynamic_events
43 echo "e:$EPROBE $SYSTEM/$EVENT $OPTIONS" >> dynamic_events
50 # With group name and system/event
51 echo "e:$EPROBE $SYSTEM/$EVENT $OPTIONS" >> dynamic_events
54 echo "-:eprobes/$EPROBE $SYSTEM/$EVENT" >> dynamic_events
58 # With just event name and system/event
59 echo "e:$EPROBE $SYSTEM/$EVENT $OPTIONS" >> dynamic_events
62 echo "-:$EPROBE $SYSTEM/$EVENT" >> dynamic_events
66 # With just event name and system/event and options
[all …]
|
| /Linux-v6.1/Documentation/crypto/ |
| D | userspace-if.rst | 62 send()/write() system call family. The result of the cipher operation is
63 obtained with the read()/recv() system call family.
77 3. Invoke accept with the socket descriptor. The accept system call
80 system calls to send data to the kernel or obtain data from the
88 the input buffer used for the send/write system call and the output
89 buffer used by the read/recv system call may be one and the same. This
120 Using the send() system call, the application provides the data that
121 should be processed with the message digest. The send system call allows
124 - MSG_MORE: If this flag is set, the send system call acts like a
126 calculated. If the flag is not set, the send system call calculates
[all …]
|
| /Linux-v6.1/Documentation/userspace-api/ |
| D | seccomp_filter.rst | 8 A large number of system calls are exposed to every userland process
10 As system calls change and mature, bugs are found and eradicated. A
12 of available system calls. The resulting set reduces the total kernel
13 surface exposed to the application. System call filtering is meant for
17 incoming system calls. The filter is expressed as a Berkeley Packet
19 operated on is related to the system call being made: system call
20 number and the system call arguments. This allows for expressive
21 filtering of system calls using a filter program language with a long
25 to time-of-check-time-of-use (TOCTOU) attacks that are common in system
27 pointers which constrains all filters to solely evaluating the system
[all …]
|
| /Linux-v6.1/Documentation/admin-guide/mm/ |
| D | numaperf.rst | 12 A system supports such heterogeneous memory by grouping each memory type
47 # symlinks -v /sys/devices/system/node/nodeX/access0/targets/
48 relative: /sys/devices/system/node/nodeX/access0/targets/nodeY -> ../../nodeY
50 # symlinks -v /sys/devices/system/node/nodeY/access0/initiators/
51 relative: /sys/devices/system/node/nodeY/access0/initiators/nodeX -> ../../nodeX
70 the system provides these attributes, the kernel exports them under the
74 /sys/devices/system/node/nodeY/access0/initiators/
82 # tree -P "read*|write*" /sys/devices/system/node/nodeY/access0/initiators/
83 /sys/devices/system/node/nodeY/access0/initiators/
103 System memory may be constructed in a hierarchy of elements with various
[all …]
|
| /Linux-v6.1/Documentation/power/ |
| D | suspend-and-interrupts.rst | 2 System Suspend and Device Interrupts
12 Device interrupt request lines (IRQs) are generally disabled during system
29 Device IRQs are re-enabled during system resume, right before the "early" phase
37 There are interrupts that can legitimately trigger during the entire system
47 interrupt will wake the system from a suspended state -- for such cases it is
58 System Wakeup Interrupts, enable_irq_wake() and disable_irq_wake()
61 System wakeup interrupts generally need to be configured to wake up the system
67 during system sleep so as to trigger a system wakeup when needed. For example,
69 handling system wakeup events. Then, if a given interrupt line is supposed to
70 wake up the system from sleep sates, the corresponding input of that interrupt
[all …]
|
| /Linux-v6.1/arch/m68k/include/asm/ |
| D | mcfpit.h | 25 #define MCFPIT_PCSR_CLK1 0x0000 /* System clock divisor */
26 #define MCFPIT_PCSR_CLK2 0x0100 /* System clock divisor */
27 #define MCFPIT_PCSR_CLK4 0x0200 /* System clock divisor */
28 #define MCFPIT_PCSR_CLK8 0x0300 /* System clock divisor */
29 #define MCFPIT_PCSR_CLK16 0x0400 /* System clock divisor */
30 #define MCFPIT_PCSR_CLK32 0x0500 /* System clock divisor */
31 #define MCFPIT_PCSR_CLK64 0x0600 /* System clock divisor */
32 #define MCFPIT_PCSR_CLK128 0x0700 /* System clock divisor */
33 #define MCFPIT_PCSR_CLK256 0x0800 /* System clock divisor */
34 #define MCFPIT_PCSR_CLK512 0x0900 /* System clock divisor */
[all …]
|
| /Linux-v6.1/Documentation/driver-api/pm/ |
| D | devices.rst | 22 This writeup gives an overview of how drivers interact with system-wide
34 System Sleep model:
36 Drivers can enter low-power states as part of entering system-wide
46 Some drivers can manage hardware wakeup events, which make the system
51 whole system enter low-power states more often.
55 Devices may also be put into low-power states while the system is
62 states at run time may require special handling during system-wide power
67 the PM core are involved in runtime power management. As in the system
73 very system-specific, and often device-specific. Also, that if enough devices
75 to entering some system-wide low-power state (system sleep) ... and that
[all …]
|
12345678910>>...221
