| /linux/Documentation/dev-tools/kunit/ |
| H A D | style.rst | 24 suite is a group of tests which test a related area of the kernel. A subsystem
25 is a set of test suites which test different parts of a kernel subsystem
31 Every test suite must belong to a subsystem. A subsystem is a collection of one
33 test subsystem should match a single kernel module. If the code being tested
34 cannot be compiled as a module, in many cases the subsystem should correspond to
42 If a test subsystem name has multiple components, they should be separated by
43 underscores. *Do not* include "test" or "kunit" directly in the subsystem name
64 suffix. ``qos`` is also ambiguous as a subsystem name, because several parts
65 of the kernel have a ``qos`` subsystem. ``power_qos`` would be a better name.
67 The corresponding module name is ``parport_pc``, so this subsystem should also
[all …]
|
| /linux/Documentation/filesystems/ |
| H A D | configfs.rst | 50 subsystems. Once a client subsystem is loaded, it will appear as a
122 object in the subsystem. It has attributes that match values on that
124 and its attributes, allowing the subsystem to ignore all but the
132 A subsystem is the top level of a client module. During initialization,
133 the client module registers the subsystem with configfs, the subsystem
135 subsystem is also a config_group, and can do everything a config_group
162 structure that actually represents what the subsystem is doing. The
176 Usually a subsystem wants the item to display and/or store attributes,
300 mkdir(2) in the group's directory. The subsystem allocates a new
305 If the subsystem wants the child to be a group itself, the subsystem
[all …]
|
| /linux/Documentation/driver-api/rapidio/ |
| H A D | rapidio.rst | 10 This document describes the basics of the Linux RapidIO subsystem and provides
16 Because the RapidIO subsystem follows the Linux device model it is integrated
20 The Linux RapidIO subsystem is architecture independent and therefore defines
22 subsystem operations.
28 Each of these components is represented in the subsystem by an associated data
29 structure. The core logical components of the RapidIO subsystem are defined
37 packets (transactions). In the RapidIO subsystem each master port is represented
43 RapidIO master ports are serviced by subsystem specific mport device drivers
44 that provide functionality defined for this subsystem. To provide a hardware
45 independent interface for RapidIO subsystem operations, rio_mport structure
[all …]
|
| H A D | mport_cdev.rst | 2 RapidIO subsystem mport character device driver (rio_mport_cdev.c)
16 This driver (MPORT_CDEV) provides access to basic RapidIO subsystem operations
25 following RapidIO bus and subsystem operations:
56 - Manage device objects supported by RapidIO subsystem (RIO_DEV_ADD/RIO_DEV_DEL).
59 kernel RapidIO subsystem.
64 This device driver uses standard interfaces defined by kernel RapidIO subsystem
66 subsystem with limitations set by available mport implementation.
|
| /linux/Documentation/admin-guide/ |
| H A D | video-output.rst | 17 | |-- subsystem -> ../../../class/video_output
22 | |-- subsystem -> ../../../class/video_output
27 | |-- subsystem -> ../../../class/video_output
32 |-- subsystem -> ../../../class/video_output
|
| H A D | sysfs-rules.rst | 68 - subsystem (``block``, ``tty``, ``pci``, ...)
71 - retrieved by reading the "subsystem"-link and using only the
108 - Classification by subsystem
115 classification directories into one place at ``/sys/subsystem``,
117 classes, including the converted block subsystem, will show up
119 The devices belonging to a subsystem will create a symlink in the
120 "devices" directory at ``/sys/subsystem/<name>/devices``,
122 If ``/sys/subsystem`` exists, ``/sys/bus``, ``/sys/class`` and ``/sys/block``
124 places, as the kernel is free to move a subsystem from one place to
126 subsystem name.
[all …]
|
| H A D | rapidio.rst | 18 subsystem internals.
39 subsystem to gather info on devices, request/map memory region
58 subsystem.
96 The following people have contributed to the RapidIO subsystem directly
|
| /linux/drivers/target/ |
| H A D | Kconfig | 14 subsystem logic for virtual LUN 0 access
22 Say Y here to enable the TCM/IBLOCK subsystem plugin for non-buffered
28 Say Y here to enable the TCM/FILEIO subsystem plugin for buffered
35 Say Y here to enable the TCM/pSCSI subsystem plugin for non-buffered
42 Say Y here to enable the TCM/USER subsystem plugin for a userspace
|
| /linux/Documentation/driver-api/fpga/ |
| H A D | intro.rst | 4 The FPGA subsystem supports reprogramming FPGAs dynamically under
7 * The FPGA subsystem is vendor agnostic.
9 * The FPGA subsystem separates upper layers (userspace interfaces and
27 this is the subsystem for you. Low level FPGA manager drivers contain
28 the knowledge of how to program a specific device. This subsystem
40 of an FPGA. This subsystem includes fpga-bridge.c and the low level
|
| /linux/Documentation/doc-guide/ |
| H A D | maintainer-profile.rst | 3 Documentation subsystem maintainer entry profile
6 The documentation "subsystem" is the central coordinating point for the
12 It's worth noting, though, that the boundaries of this subsystem are rather
13 fuzzier than normal. Many other subsystem maintainers like to keep control
17 always) maintained by the relevant subsystem maintainer.
48 I am the sole maintainer for the documentation subsystem, and I am doing
|
| /linux/Documentation/admin-guide/cgroup-v1/ |
| H A D | cgroups.rst | 53 A *subsystem* is a module that makes use of the task grouping
55 particular ways. A subsystem is typically a "resource controller" that
58 virtualization subsystem.
62 hierarchy, and a set of subsystems; each subsystem has system-specific
109 At one extreme, each resource controller or subsystem could be in a
181 cgroup_subsys_state objects, one for each cgroup subsystem
186 subsystem state is something that's expected to happen frequently
219 It's not currently possible to bind a new subsystem to an active
220 cgroup hierarchy, or to unbind a subsystem from an active cgroup
233 for each active hierarchy, the subsystem names and the cgroup name
[all …]
|
| /linux/drivers/remoteproc/ |
| H A D | qcom_common.c | 106 static int qcom_add_minidump_segments(struct rproc *rproc, struct minidump_subsystem *subsystem, in qcom_add_minidump_segments() argument
122 seg_cnt = le32_to_cpu(subsystem->region_count); in qcom_add_minidump_segments()
123 ptr = ioremap((unsigned long)le64_to_cpu(subsystem->regions_baseptr), in qcom_add_minidump_segments()
152 struct minidump_subsystem *subsystem; in qcom_minidump() local
165 subsystem = &toc->subsystems[minidump_id]; in qcom_minidump()
171 if (subsystem->regions_baseptr == 0 || in qcom_minidump()
172 le32_to_cpu(subsystem->status) != 1 || in qcom_minidump()
173 le32_to_cpu(subsystem->enabled) != MINIDUMP_SS_ENABLED) { in qcom_minidump()
177 if (le32_to_cpu(subsystem->encryption_status) != MINIDUMP_SS_ENCR_DONE) { in qcom_minidump()
188 ret = qcom_add_minidump_segments(rproc, subsystem, rproc_dumpfn_t); in qcom_minidump()
|
| /linux/Documentation/leds/ |
| H A D | leds-class-flash.rst | 5 Some LED devices provide two modes - torch and flash. In the LED subsystem
13 registered in the LED subsystem with led_classdev_flash_register function.
29 A LED subsystem driver can be controlled also from the level of VideoForLinux2
30 subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to
34 V4L2 subsystem. The function takes six arguments:
88 Opening the V4L2 flash sub-device makes the LED subsystem sysfs interface
|
| /linux/sound/pci/ctxfi/ |
| H A D | xfi.c | 32 static unsigned int subsystem[SNDRV_CARDS]; variable
40 module_param_array(subsystem, int, NULL, 0444);
41 MODULE_PARM_DESC(subsystem, "Override subsystem ID for Creative X-Fi driver");
90 pci_id->driver_data, subsystem[dev], &atc); in ct_card_probe()
|
| /linux/Documentation/nvme/ |
| H A D | nvme-pci-endpoint-target.rst | 19 subsystem using a port. The port transfer type must be configured to be
20 "pci". The subsystem can be configured to have namespaces backed by regular
154 as a subsystem namespace can be used.
181 subsystem and port must be defined. Second, the NVMe PCI endpoint device must
182 be setup and bound to the subsystem and port created.
187 Details about how to configure an NVMe target subsystem and port are outside the
189 and subsystem with a single namespace backed by a null_blk device.
210 Now, create a subsystem and a port that we will use to create a PCI target
222 Next, create and enable the subsystem namespace using the null_blk block
229 Finally, create the target port and link it to the subsystem::
[all …]
|
| /linux/net/bluetooth/ |
| H A D | Kconfig | 3 # Bluetooth subsystem configuration
7 tristate "Bluetooth subsystem support"
26 Linux Bluetooth subsystem consist of several layers:
42 To use Linux Bluetooth subsystem, you will need several user-space
125 Run self tests when initializing the Bluetooth subsystem. This
129 When the Bluetooth subsystem is built as module, then the test
131 subsystem is compiled into the kernel image, then the test cases
|
| /linux/Documentation/driver-api/usb/ |
| H A D | writing_usb_driver.rst | 12 The Linux USB subsystem has grown from supporting only two different
44 excellent introduction to the Linux USB subsystem can be found at the
46 subsystem is structured and introduces the reader to the concept of USB
50 the Linux USB subsystem, giving it some information about which devices
53 information is passed to the USB subsystem in the :c:type:`usb_driver`
76 another kernel subsystem, such as the SCSI, network or TTY subsystem.
78 subsystem, and any user-space interactions are provided through that
79 interface. But for drivers that do not have a matching kernel subsystem,
81 is needed. The USB subsystem provides a way to register a minor device
94 /* register this driver with the USB subsystem */
[all …]
|
| /linux/Documentation/devicetree/bindings/display/ |
| H A D | st,stih4xx.txt | 21 - sti-display-subsystem: Master device for DRM sub-components
25 - compatible: "st,sti-display-subsystem"
29 must be a child of sti-display-subsystem
45 must be a child of sti-display-subsystem
57 must be a child of sti-display-subsystem
74 must be a child of sti-display-subsystem
87 must be a child of sti-display-subsystem
102 must be a child of sti-display-subsystem
175 sti-display-subsystem {
176 compatible = "st,sti-display-subsystem";
|
| /linux/Documentation/maintainer/ |
| H A D | feature-and-driver-maintainers.rst | 17 subsystem.
28 a subsystem could well have a hundred such drivers. Subsystem
31 The exact expectations on the response time will vary by subsystem.
32 The patch review SLA the subsystem had set for itself can sometimes
33 be found in the subsystem documentation. Failing that as a rule of thumb
35 review delay of the subsystem maintainer. The resulting expectations
43 Maintainers must be subscribed and follow the appropriate subsystem-wide
63 than the expected review timeline for the subsystem, maintainer should
90 should be conducted in a manner typical for the larger subsystem.
160 to remember to include the maintainers in discussions and subsystem
|
| H A D | maintainer-entry-profile.rst | 8 subsystem/device-driver-local customs as well as details about the patch
17 Provide an introduction to how the subsystem operates. While MAINTAINERS
19 convey other subsystem-local infrastructure and mechanisms that aid
26 - Does the subsystem have a patchwork instance? Are patchwork state
29 testing feedback that the subsystem uses to gate acceptance?
33 device-driver may point to an entry for its parent subsystem. This makes
46 of related hardware specifications. For example, does the subsystem
|
| /linux/Documentation/accel/ |
| H A D | introduction.rst | 7 The Linux compute accelerators subsystem is designed to expose compute
47 characteristics as those of GPUs, the accel subsystem will use the
48 DRM subsystem's code and functionality. i.e. the accel core code will
49 be part of the DRM subsystem and an accel device will be a new type of DRM
81 accel subsystem.
104 * `Initial discussion on the New subsystem for acceleration devices <https://lore.kernel.org/lkml/C…
105 * `patch-set to add the new subsystem <https://lore.kernel.org/lkml/20221022214622.18042-1-ogabbay@…
|
| /linux/Documentation/timers/ |
| H A D | hrtimers.rst | 2 hrtimers - subsystem for high-resolution kernel timers
5 This patch introduces a new subsystem for high-resolution kernel timers.
7 One might ask the question: we already have a timer subsystem
36 - the implementation of the current posix-timer subsystem on top of
51 largely expect the timer subsystem to have near-zero overhead.
62 high-resolution timer subsystem as well.
64 While this subsystem does not offer high-resolution clock sources just
65 yet, the hrtimer subsystem can be easily extended with high-resolution
75 hrtimers. E.g. we could decrease the frequency of the timeout subsystem
78 hrtimer subsystem implementation details
[all …]
|
| /linux/Documentation/driver-api/media/ |
| H A D | index.rst | 6 Media subsystem kernel internal API
9 This section contains usage information about media subsystem and
16 - for usage information about media subsystem and supported drivers;
|
| /linux/lib/ |
| H A D | kobject_uevent.c | 251 static int init_uevent_argv(struct kobj_uevent_env *env, const char *subsystem) in init_uevent_argv() argument
256 len = strscpy(&env->buf[env->buflen], subsystem, buffer_size); in init_uevent_argv()
259 __func__, buffer_size, subsystem); in init_uevent_argv()
479 const char *subsystem; in kobject_uevent_env() local
529 subsystem = uevent_ops->name(kobj); in kobject_uevent_env()
531 subsystem = kobject_name(&kset->kobj); in kobject_uevent_env()
532 if (!subsystem) { in kobject_uevent_env()
558 retval = add_uevent_var(env, "SUBSYSTEM=%s", subsystem); in kobject_uevent_env()
623 retval = init_uevent_argv(env, subsystem); in kobject_uevent_env()
|
| /linux/Documentation/scsi/ |
| H A D | scsi.rst | 4 SCSI subsystem documentation
8 the SCSI subsystem in the Linux kernel (lk) 2.4 series. See:
12 Notes on using modules in the SCSI subsystem
25 the SCSI subsystem.
|