| /linux/drivers/clk/bcm/ |
| H A D | Kconfig | 11 Enable common clock framework support for the Broadcom BCM2711
20 Enable common clock framework support for Broadcom BCM2835
29 Enable common clock framework support for Broadcom BCM63xx DSL SoCs
37 Enable common clock framework support for Broadcom BCM63xx DSL SoCs
54 Enable common clock framework support for Broadcom SoCs
61 Enable common clock framework support for Broadcom SoCs
70 Enable common clock framework support for the Broadcom Cygnus SoC
78 Enable common clock framework support for the Broadcom Hurricane 2
87 Enable common clock framework support for the Broadcom Northstar and
96 Enable common clock framework support for the Broadcom Northstar 2 SoC
[all …]
|
| /linux/Documentation/security/ |
| H A D | lsm.rst | 28 remarks that described a security framework he would be willing to
30 general framework that would provide a set of security hooks to control
33 framework could then be used by loadable kernel modules to implement any
38 such a framework. LSM was a joint development effort by several security
41 Linux kernel patch that implements this framework. The work was
43 report provides an overview of the framework and the capabilities
46 LSM Framework
49 The LSM framework provides a general kernel framework to support
50 security modules. In particular, the LSM framework is primarily focused
53 framework does not provide any additional security; it merely provides
[all …]
|
| /linux/Documentation/driver-api/media/ |
| H A D | v4l2-intro.rst | 17 For a long time the framework was limited to the video_device struct for
19 (note that this document does not discuss the video_buf framework).
26 the lack of a framework.
28 So this framework sets up the basic building blocks that all drivers
29 need and this same framework should make it much easier to refactor
35 framework. It can be used as a template for real PCI video capture driver.
66 Structure of the V4L2 framework
69 The framework closely resembles the driver structure: it has a v4l2_device
74 The V4L2 framework also optionally integrates with the media framework. If a
76 will automatically appear in the media framework as entities.
|
| H A D | cec-core.rst | 6 The CEC framework provides a unified kernel interface for use with HDMI CEC
8 transmitters, USB dongles). The framework also gives the option to decide
11 feature into the kernel's remote control framework.
24 The CEC framework described here is up to date with the CEC 2.0 specification.
49 adapter operations which are called by the CEC framework and that you
239 driven) by calling into the framework in the following situations:
280 retrying messages. If set, then the framework assumes that it
318 handling the receive interrupt. The framework expects to see the cec_transmit_done
348 This basic parsing is done in the CEC Framework. It is up to the driver to decide
421 -ENOMSG, otherwise the CEC framework assumes it processed this message and
[all …]
|
| /linux/Documentation/power/ |
| H A D | opp.rst | 52 Instrument's OMAP framework allows to optionally boot at a certain OPP without
58 SoC framework -> modifies on required cases certain OPPs -> OPP layer
62 framework registers a set of initial OPPs per device with the OPP layer. This
64 This initial list contains a set of OPPs that the framework expects to be safely
70 As the system proceeds to operate, SoC framework may choose to make certain
73 SoC framework might choose to disable a higher frequency OPP to safely continue
89 the SoC specific framework which uses the OPP library. Similar care needs
95 device. It is expected that the SoC framework will register the OPP entries
98 operation. The SoC framework can subsequently control the availability of the
107 This function may be used by SoC framework to define a optimal list
[all …]
|
| /linux/Documentation/driver-api/fpga/ |
| H A D | intro.rst | 15 framework functionality that can be added that will benefit
17 seek out a solution that expands the framework for broad reuse.
21 The framework in the kernel is divided into:
29 includes the framework in fpga-mgr.c and the low level drivers that
46 If you are adding a new interface to the FPGA framework, add it on top
49 The FPGA Region framework (fpga-region.c) associates managers and
|
| /linux/drivers/thermal/renesas/ |
| H A D | Kconfig | 10 thermal framework.
19 driver into the Linux thermal framework.
28 thermal framework.
35 thermal framework.
43 thermal framework.
|
| /linux/drivers/acpi/dptf/ |
| H A D | Kconfig | 4 bool "Intel DPTF (Dynamic Platform and Thermal Framework) Support"
7 Intel Dynamic Platform and Thermal Framework (DPTF) is a platform
20 This driver adds support for Dynamic Platform and Thermal Framework
36 This driver adds support for Dynamic Platform and Thermal Framework
|
| /linux/tools/testing/selftests/resctrl/ |
| H A D | README | 15 resctrl_tests can be run with or without kselftest framework.
17 WITH KSELFTEST FRAMEWORK
31 Using kselftest framework will run all supported tests within resctrl_tests:
35 More details about kselftest framework can be found in
38 WITHOUT KSELFTEST FRAMEWORK
|
| /linux/tools/build/Documentation/ |
| H A D | Build.txt | 1 Build Framework
4 The perf build framework was adopted from the kernel build system, hence the
15 Build framework makefiles
18 The build framework consists of 2 Makefiles:
63 The build framework does not create the 'ex' and 'libex.a' binaries for you, it
126 The build framework provides standard compilation rules to handle .S and .c
|
| /linux/Documentation/power/powercap/ |
| H A D | dtpm.rst | 4 Dynamic Thermal Power Management framework
26 The DTPM framework provides an unified interface to act on the
32 The DTPM framework relies on the powercap framework to create the
125 As stated in the overview, the DTPM framework is built on top of the
126 powercap framework. Thus the sysfs interface is the same, please refer
164 The DTPM framework has no power limiting backend support. It is
|
| /linux/drivers/thermal/st/ |
| H A D | Kconfig | 16 tristate "Thermal framework support on STMicroelectronics STM32 series of SoCs"
20 Support for thermal framework on STMicroelectronics STM32 series of
21 SoCs. This thermal driver allows to access to general thermal framework
|
| /linux/tools/perf/Documentation/ |
| H A D | Build.txt | 22 main makefile of the build framework
25 build framework generic definitions
31 information about build framework.
36 The Makefile.perf triggers the build framework for build objects:
49 focusing on build framework outcomes
|
| /linux/Documentation/driver-api/ |
| H A D | nvmem.rst | 9 This document explains the NVMEM Framework along with the APIs provided,
18 Before this framework existed, NVMEM drivers like eeprom were stored in
27 This framework aims at solve these problems. It also introduces DT
76 them with the nvmem framework from machine code as shown in the example below::
97 The NVMEM framework provides 3 APIs to read/write NVMEM cells::
117 To facilitate such consumers NVMEM framework provides below apis::
145 The NVMEM framework provides 2 APIs to release a reference to the NVMEM::
|
| /linux/Documentation/dev-tools/kunit/ |
| H A D | index.rst | 21 This section details the kernel unit testing framework.
26 KUnit (Kernel unit testing framework) provides a common framework for
33 (C++ unit testing framework).
55 - Provides a framework for writing unit tests.
|
| /linux/Documentation/userspace-api/media/cec/ |
| H A D | cec-ioc-g-mode.rst | 47 When a CEC message is received, then the CEC framework will decide how
50 is waiting for it. In addition the CEC framework will process it.
52 If the message is not a reply, then the CEC framework will process it
54 feature abort is sent back to the initiator if the framework couldn't
57 the new message. The framework expects the follower to make the right
60 The CEC framework will process core messages unless requested otherwise
62 case, the CEC framework will pass on most core messages without
151 framework for that. If someone else is already the exclusive
272 - The CEC framework will make note of the reported physical address
|
| /linux/drivers/net/wan/framer/ |
| H A D | Kconfig | 14 This framework is designed to provide a generic interface for framer
17 framework and framer users can obtain reference to the framer.
18 All the users of this framework should select this config.
|
| /linux/drivers/iio/ |
| H A D | Kconfig | 9 The industrial I/O subsystem provides a unified framework for
78 Framework to handle complex IIO aggregate devices. The typical
79 architecture that can make use of this framework is to have one
81 multiple backend devices. The framework then makes it easy to get
|
| /linux/arch/sh/kernel/cpu/ |
| H A D | clock.c | 3 * arch/sh/kernel/cpu/clock.c - SuperH clock framework
7 * This clock framework is derived from the OMAP version by:
12 * Modified for omap shared clock framework by Tony Lindgren <tony@atomide.com>
|
| /linux/Documentation/driver-api/hte/ |
| H A D | hte.rst | 21 engine (HTE) framework. Both consumers and providers must include
24 The HTE framework APIs for the providers
30 The HTE framework APIs for the consumers
36 The HTE framework public structures
|
| /linux/lib/kunit/ |
| H A D | Kconfig | 10 testing and mocking framework for the Linux kernel. These tests are
34 Enables fault handling tests for the KUnit framework. These tests may
43 Enables the unit tests for the KUnit test framework. These tests test
44 the KUnit test framework itself; the tests are both written using
|
| /linux/Documentation/timers/ |
| H A D | highres.rst | 47 John Stultz's Generic Time Of Day (GTOD) framework moves a large portion of
49 framework, as illustrated in figure #3 (OLS slides p. 18). The architecture
51 sources, which are registered in the framework and selected on a quality based
58 Further information about the Generic Time Of Day framework is available in the
125 The framework adds about 700 lines of code which results in a 2KB increase of
147 useful function. The initialization of the clock event device framework, the
148 clock source framework (GTOD) and hrtimers itself has to be done and
|
| /linux/Documentation/devicetree/bindings/sound/ |
| H A D | ti,tlv320adc3xxx.yaml | 62 GPIO framework, as pin number 0 on the device.
80 GPIO framework, as pin number 1 on the device.
88 When set, the MICBIAS1 pin may be controlled via the GPIO framework,
98 When set, the MICBIAS2 pin may be controlled via the GPIO framework,
|
| /linux/drivers/nfc/st95hf/ |
| H A D | Kconfig | 7 This makes use of SPI framework to communicate with transceiver
8 and registered with NFC digital core to support Linux NFC framework.
|
| /linux/Documentation/arch/s390/ |
| H A D | vfio-ccw.rst | 23 vfio framework. And we add read/write callbacks for special vfio I/O
40 For vfio mediated device framework:
60 devices via the vfio mediated device framework and the subchannel device
117 realizes a group of callbacks and registers to the mdev framework as a
128 This is provided by the mdev framework. It is a vfio device driver for
131 vfio group, and registers itself to the mdev framework as a mdev
141 VFIO_IOMMU_MAP_DMA ioctl. Mdev framework will only maintain a database
169 physical device (with callbacks) to mdev framework.
171 pointer and callbacks to the mdev framework. Mdev related file nodes
|