| /linux/Documentation/devicetree/bindings/hwlock/ |
| A D | hwlock.txt | 4 Generic bindings that are common to all the hwlock platform specific driver
7 Please also look through the individual platform specific hwlock binding
8 documentations for identifying any additional properties specific to that
16 specific lock.
21 Consumers that require specific hwlock(s) should specify them using the
34 use the hwlock-names to match and get a specific hwlock.
37 1. Example of a node using a single specific hwlock:
49 2. Example of a node using multiple specific hwlocks:
|
| /linux/lib/crypto/ |
| A D | Kconfig | 14 Declares whether the architecture provides an arch-specific
23 fallback, e.g., for SIMD implementations. If no arch specific
33 by either the generic implementation or an arch-specific one, if one
39 Declares whether the architecture provides an arch-specific
49 fallback, e.g., for SIMD implementations. If no arch specific
59 by either the generic implementation or an arch-specific one, if one
65 Declares whether the architecture provides an arch-specific
74 fallback, e.g., for SIMD implementations. If no arch specific
84 fulfilled by either the generic implementation or an arch-specific
100 Declares whether the architecture provides an arch-specific
[all …]
|
| /linux/drivers/gpu/drm/rockchip/ |
| A D | Kconfig | 25 bool "Rockchip specific extensions for Analogix DP driver"
27 This selects support for Rockchip SoC specific extensions
35 This selects support for Rockchip SoC specific extensions
41 bool "Rockchip specific extensions for Synopsys DW HDMI"
43 This selects support for Rockchip SoC specific extensions
49 bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
52 This selects support for Rockchip SoC specific extensions
58 bool "Rockchip specific extensions for Innosilicon HDMI"
60 This selects support for Rockchip SoC specific extensions
85 bool "Rockchip specific extensions for RK3066 HDMI"
[all …]
|
| /linux/Documentation/arm/samsung/ |
| A D | overview.rst | 24 deals with the architecture and drivers specific to these devices.
27 on the implementation details and specific support.
37 - S5PC110 specific default configuration
39 - S5PV210 specific default configuration
46 several platform directories and then the machine specific directories
51 specific information. It contains the base clock, GPIO and device definitions
54 plat-s3c24xx is for s3c24xx specific builds, see the S3C24XX docs.
56 plat-s5p is for s5p specific builds, and contains common support for the
57 S5P specific systems. Not all S5Ps use all the features in this directory
|
| A D | gpio.rst | 9 specific calls provided alongside the drivers/gpio core.
24 specific calls for the items that require Samsung specific handling, such
33 Pin configuration is specific to the Samsung architecture, with each SoC
|
| /linux/drivers/edac/ |
| A D | i5000_edac.c | 465 char *specific = NULL; in i5000_process_fatal_error_info() local
525 bank, ras, cas, allErrors, specific); in i5000_process_fatal_error_info()
546 char *specific = NULL; in i5000_process_nonfatal_error_info() local
624 rank, bank, ras, cas, ue_errors, specific); in i5000_process_nonfatal_error_info()
669 specific = "Correctable Patrol Data ECC"; in i5000_process_nonfatal_error_info()
678 specific); in i5000_process_nonfatal_error_info()
707 specific = "FBD Northbound CRC error on " in i5000_process_nonfatal_error_info()
711 specific = "SPD protocol error"; in i5000_process_nonfatal_error_info()
714 specific = "DIMM-spare copy started"; in i5000_process_nonfatal_error_info()
717 specific = "DIMM-spare copy completed"; in i5000_process_nonfatal_error_info()
[all …]
|
| /linux/Documentation/sh/ |
| A D | new-machine.rst | 24 Board-specific code::
31 | | `-- board-specific files
33 | | `-- board-specific files
40 | `-- board-specific headers
42 | `-- board-specific headers
54 `-- cchip-specific files
58 hd64461-specific headers.
80 | `-- SH-2 specific headers
82 | `-- SH-3 specific headers
84 `-- SH-4 specific headers
[all …]
|
| /linux/Documentation/devicetree/bindings/mmc/ |
| A D | exynos-dw-mshc.txt | 1 * Samsung Exynos specific extensions to the Synopsys Designware Mobile
7 by synopsys-dw-mshc.txt and the properties used by the Samsung Exynos specific
14 specific extensions.
16 specific extensions.
18 specific extensions.
20 specific extensions.
22 specific extensions.
24 specific extensions having an SMU.
69 The MSHC controller node can be split into two portions, SoC specific and
70 board specific portions as listed below.
|
| A D | k3-dw-mshc.txt | 1 * Hisilicon specific extensions to the Synopsys Designware Mobile
9 by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
15 - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific extensions.
17 with hi3670 specific extensions.
18 - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions.
19 - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions.
|
| A D | samsung-sdhci.txt | 30 Note: This example shows both SoC specific and board specific properties
32 into SoC specific node and board specific node.
|
| A D | arm,pl18x.yaml | 86 description: ST Micro-specific property, bus signal direction pins used for
91 description: ST Micro-specific property, bus signal direction pins used for
96 description: ST Micro-specific property, bus signal direction pins used for
101 description: ST Micro-specific property, bus signal direction pins used for
106 description: ST Micro-specific property, CMD signal direction used for
111 description: ST Micro-specific property, feedback clock FBCLK signal pin
116 description: ST Micro-specific property, signal direction polarity used for
121 description: ST Micro-specific property, data and command phase relation,
126 description: ST Micro-specific property, use CKIN pin from an external
|
| /linux/drivers/bcma/ |
| A D | README | 2 however from programming point of view there is nothing AMBA specific we use.
4 Standard AMBA drivers are platform specific, have hardcoded addresses and use
8 1) Broadcom specific AMBA device. It is put on AMBA bus, but can not be treated
12 devices is used for managing Broadcom specific core.
18 16 devices identified by Broadcom specific fields: manufacturer, id, revision
|
| /linux/Documentation/devicetree/bindings/sifive/ |
| A D | sifive-blocks-ip-versioning.txt | 9 IP block-specific DT compatible strings are contained within the HDL,
26 match on these IP block-specific compatible strings.
29 continue to specify an SoC-specific compatible string value, such as
30 "sifive,fu540-c000-uart". This way, if SoC-specific
31 integration-specific bug fixes or workarounds are needed, the kernel
33 IP block-specific compatible string (such as "sifive,uart0") should
|
| /linux/arch/x86/configs/ |
| A D | xen.config | 1 # global x86 required specific stuff
15 # x86 xen specific config options
22 # x86 specific backend drivers
24 # x86 specific frontend drivers
|
| /linux/Documentation/driver-api/usb/ |
| A D | typec_bus.rst | 10 The communication is SVID (Standard or Vendor ID) specific, i.e. specific for
29 specific commands from the alternate mode drivers to the partner, and from the
30 partners to the alternate mode drivers. No direct SVID specific communication is
47 will be used to deliver all the SVID specific commands from the partner to the
49 the SVID specific commands to each other using :c:func:`typec_altmode_vdm()`.
51 If the communication with the partner using the SVID specific commands results
54 passes the negotiated SVID specific pin configuration value to the function as
58 NOTE: The SVID specific pin configuration values must always start from
67 An example of working definitions for SVID specific pin configurations would
|
| /linux/Documentation/networking/devlink/ |
| A D | octeontx2.rst | 13 The ``octeontx2 PF and VF`` drivers implement the following driver-specific parameters.
15 .. list-table:: Driver-specific parameters implemented
29 The ``octeontx2 AF`` driver implements the following driver-specific parameters.
31 .. list-table:: Driver-specific parameters implemented
|
| A D | devlink-dpipe.rst | 46 modeled as a graph of match/action tables. Each table represents a specific
75 the actual content of a specific table.
85 is hardware counting for a specific table.
112 ``devlink`` core API. On the other hand ASIC meta data is driver specific
113 and should be defined in the driver. Additionally, each driver-specific
114 devlink documentation file should document the driver-specific ``dpipe``
130 * ``field_exact``: Exact match on a specific field.
131 * ``field_exact_mask``: Exact match on a specific field after masking.
132 * ``field_range``: Match on a specific range.
135 identify the specific field. Furthermore, the header index should be
[all …]
|
| A D | netdevsim.rst | 20 The ``netdevsim`` driver also implements the following driver-specific
23 .. list-table:: Driver-specific parameters implemented
33 - Test parameter used to show how a driver-specific devlink parameter
86 Driver-specific Traps
89 .. list-table:: List of Driver-specific Traps Registered by ``netdevsim``
|
| /linux/drivers/scsi/ufs/ |
| A D | Kconfig | 88 This selects the Cadence-specific additions to UFSHCD platform driver.
101 tristate "QCOM specific hooks to UFS controller platform driver"
106 This selects the QCOM specific additions to UFSHCD platform driver.
107 UFS host on QCOM needs some vendor specific configuration before
109 specific registers.
115 tristate "Mediatek specific hooks to UFS controller platform driver"
121 UFS host on Mediatek needs some vendor specific configuration before
123 specific registers.
130 tristate "Hisilicon specific hooks to UFS controller platform driver"
168 tristate "Exynos specific hooks to UFS controller platform driver"
[all …]
|
| /linux/Documentation/userspace-api/media/v4l/ |
| A D | ext-ctrls-fm-tx.rst | 27 step are driver-specific.
107 useconds. Step and range are driver-specific.
111 are driver-specific.
121 range and step are driver-specific.
125 value. The range and step are driver-specific.
129 value. The range and step are driver-specific.
133 useconds value. The range and step are driver-specific.
140 range and step are driver-specific.
144 step are driver-specific.
173 dBuV. Range and step are driver-specific.
[all …]
|
| /linux/Documentation/admin-guide/media/ |
| A D | davinci-vpbe.rst | 29 board specific settings (specified in board-xxx-evm.c). This allows
32 API to set timings in VENC for a specific display resolution. As of this
41 is connected, the timings for a specific standard/preset is retrieved from
42 the board specific table and the values are used to set the timings in
48 add the available outputs as a board specific entry (i.e add the "LogicPD"
50 supported can be maintained in the board specific setup file to support
57 OSD module implements all OSD layer management and hardware specific
|
| /linux/Documentation/devicetree/bindings/clock/ti/ |
| A D | interface.txt | 19 "ti,omap3-hsotgusb-interface-clock" - interface clock with USB specific HW
21 "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling
22 "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling
23 "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling
24 "ti,omap2430-interface-clock" - interface clock with OMAP2430 specific HW
|
| /linux/Documentation/devicetree/bindings/powerpc/fsl/ |
| A D | mpic.txt | 39 specifiers do not contain the interrupt-type or type-specific
110 type-specific cell is undefined. The
123 the error interrupt. The type-specific
124 cell identifies the specific error
130 the MPIC IPI number. The type-specific
136 the MPIC timer number. The type-specific
139 <4th-cell> type-specific information
141 The type-specific cell is encoded as follows:
144 the type-specific cell contains the
223 * SoC interrupt number is 16 and the specific error
|
| /linux/Documentation/hwmon/ |
| A D | pmbus-core.rst | 29 device specific extensions in addition to the core PMBus driver, since it is
30 simply unknown what new device specific functionality PMBus device developers
35 split into core, generic, and device specific code. The core code (in
38 for device specific initialization and, if needed, maps device specific
65 The API between core and device specific PMBus code is defined in
85 to be implemented in device specific code.
110 for device specific drivers to pass information to the core PMBus driver.
122 command return values with device specific information.
132 specific command, but that a standard PMBus command may exist. Any other
250 This function calls the device specific write_byte function if defined.
[all …]
|
| /linux/Documentation/driver-api/rapidio/ |
| A D | rapidio.rst | 17 into the kernel similarly to other buses by defining RapidIO-specific device and
21 architecture-specific interfaces that provide support for common RapidIO
38 by a rio_mport data structure. This structure contains master port specific
43 RapidIO master ports are serviced by subsystem specific mport device drivers
46 includes rio_ops data structure which contains pointers to hardware specific
65 routing table and pointers to switch specific functions.
68 specific switch drivers that are designed to provide hardware-specific
83 RapidIO device-specific drivers follow Linux Kernel Driver Model and are
84 intended to support specific RapidIO devices attached to the RapidIO network.
96 the same device without blocking attachment of a device-specific driver.
[all …]
|