| /linux/Documentation/devicetree/bindings/leds/ |
| A D | leds-bcm6328.txt | 8 or by hardware using this driver.
15 with 0 meaning hardware control enabled and 1 hardware control disabled. This
57 - brcm,hardware-controlled : Boolean, makes this LED hardware controlled.
98 brcm,hardware-controlled;
102 brcm,hardware-controlled;
106 brcm,hardware-controlled;
110 brcm,hardware-controlled;
126 brcm,hardware-controlled;
131 brcm,hardware-controlled;
161 brcm,hardware-controlled;
[all …]
|
| /linux/Documentation/devicetree/bindings/spi/ |
| A D | sprd,spi-adi.yaml | 18 framework for its hardware implementation is alike to SPI bus and its timing
23 users should set ADI registers to access analog chip. For hardware channels,
25 which means we can just link one analog chip address to one hardware channel,
26 then users can access the mapped analog chip address by this hardware channel
27 triggered by hardware components instead of ADI software channels.
30 channels, the first value specifies the hardware channel id which is used to
32 the analog chip address where user want to access by hardware components.
43 thus change the hardware spinlock support to be optional to keep backward
67 description: A list of hardware channels
74 use, 2-49 are hardware channels.
[all …]
|
| /linux/drivers/media/rc/ |
| A D | serial_ir.c | 66 static struct serial_ir_hw hardware[] = { variable
163 soutp(UART_MCR, hardware[type].off); in on()
165 soutp(UART_MCR, hardware[type].on); in on()
171 soutp(UART_MCR, hardware[type].on); in off()
173 soutp(UART_MCR, hardware[type].off); in off()
492 if (hardware[type].send_pulse && hardware[type].send_space) in serial_ir_probe()
494 if (hardware[type].set_send_carrier) in serial_ir_probe()
496 if (hardware[type].set_duty_cycle) in serial_ir_probe()
539 KBUILD_MODNAME, &hardware); in serial_ir_probe()
651 hardware[type].send_space(); in serial_ir_tx()
[all …]
|
| /linux/sound/isa/sb/ |
| A D | sb_common.c | 118 switch (chip->hardware) { in snd_sbdsp_probe()
122 chip->hardware = SB_HW_10; in snd_sbdsp_probe()
127 chip->hardware = SB_HW_201; in snd_sbdsp_probe()
130 chip->hardware = SB_HW_20; in snd_sbdsp_probe()
135 chip->hardware = SB_HW_PRO; in snd_sbdsp_probe()
139 chip->hardware = SB_HW_16; in snd_sbdsp_probe()
177 unsigned short hardware, in snd_sbdsp_create() argument
199 (hardware == SB_HW_ALS4000 || in snd_sbdsp_create()
200 hardware == SB_HW_CS5530) ? in snd_sbdsp_create()
209 if (hardware == SB_HW_ALS4000) in snd_sbdsp_create()
[all …]
|
| /linux/sound/isa/wss/ |
| A D | wss_lib.c | 1155 unsigned short hardware = 0; in snd_ad1848_probe() local
1177 hardware = WSS_HW_AD1847; in snd_ad1848_probe()
1196 if (hardware) { in snd_ad1848_probe()
1197 chip->hardware = hardware; in snd_ad1848_probe()
1243 hw = chip->hardware; in snd_wss_probe()
1296 switch (chip->hardware) { in snd_wss_probe()
1660 switch (chip->hardware) { in snd_wss_chip_id()
1704 unsigned short hardware, in snd_wss_new() argument
1714 chip->hardware = hardware; in snd_wss_new()
1743 unsigned short hardware, in snd_wss_create() argument
[all …]
|
| /linux/arch/mips/boot/dts/brcm/ |
| A D | bcm63268-comtrend-vr-3032u.dts | 29 brcm,hardware-controlled;
35 brcm,hardware-controlled;
66 brcm,hardware-controlled;
71 brcm,hardware-controlled;
76 brcm,hardware-controlled;
81 brcm,hardware-controlled;
86 brcm,hardware-controlled;
91 brcm,hardware-controlled;
96 brcm,hardware-controlled;
|
| /linux/drivers/hwmon/pmbus/ |
| A D | Kconfig | 21 If you say yes here you get hardware monitoring support for generic
35 If you say yes here you get hardware monitoring support for Analog
44 If you say yes here you get hardware monitoring support for Analog
54 If you say yes here you get hardware monitoring support for BEL
63 If you say yes here you get hardware monitoring support for BluTek
72 If you say yes here you get hardware monitoring support for
110 If you say yes here you get hardware monitoring support for the
137 If you say yes here you get hardware monitoring support for the
291 If you say yes here you get hardware monitoring support for ST
318 If you say yes here you get hardware monitoring support for ST
[all …]
|
| /linux/drivers/tty/ipwireless/ |
| A D | tty.c | 49 struct ipw_hardware *hardware; member
216 ret = ipwireless_send_packet(tty->hardware, IPW_CHANNEL_RAS, in ipw_write()
314 ret = ipwireless_set_RTS(tty->hardware, in set_control_lines()
325 ret = ipwireless_set_DTR(tty->hardware, in set_control_lines()
334 ret = ipwireless_set_RTS(tty->hardware, in set_control_lines()
343 ret = ipwireless_set_DTR(tty->hardware, in set_control_lines()
436 struct ipw_hardware *hardware, in add_tty() argument
444 ttys[j]->hardware = hardware; in add_tty()
486 if (add_tty(j, hardware, network, in ipwireless_tty_create()
492 if (add_tty(j, hardware, network, in ipwireless_tty_create()
[all …]
|
| /linux/drivers/char/hw_random/ |
| A D | Kconfig | 70 Generator hardware found on Atmel AT91 devices.
120 Generator hardware found on the AMD Geode LX.
133 Generator hardware found on Niagara2 cpus.
199 Generator hardware found on Octeon processors.
224 Generator hardware.
235 Generator hardware found on TX4939 SoC.
367 Generator hardware found on APM X-Gene SoC.
394 Generator hardware found on a PIC32.
421 Generator hardware found on Cavium SoCs.
435 Generator hardware found on Mediatek SoCs.
[all …]
|
| /linux/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ |
| A D | ethernet-driver.rst | 20 Unlike regular NICs, in the DPAA2 architecture there is no single hardware block
21 representing network interfaces; instead, several separate hardware resources
29 All hardware resources are allocated and configured through the Management
32 hardware resources, like queues, do not have a corresponding MC object and
58 . . . hardware
60 | MC hardware portals |
71 hardware resources.
90 | | | | | hardware
92 | I/O hardware portals |
159 options and associated hardware resources.
[all …]
|
| /linux/Documentation/devicetree/bindings/crypto/ |
| A D | brcm,spu-crypto.txt | 1 The Broadcom Secure Processing Unit (SPU) hardware supports symmetric
2 cryptographic offload for Broadcom SoCs. A SoC may have multiple SPU hardware
7 brcm,spum-crypto - for devices with SPU-M hardware
8 brcm,spu2-crypto - for devices with SPU2 hardware
9 brcm,spu2-v2-crypto - for devices with enhanced SPU2 hardware features like SHA3
11 brcm,spum-nsp-crypto - for the Northstar Plus variant of the SPU-M hardware
|
| /linux/Documentation/networking/devlink/ |
| A D | devlink-dpipe.rst | 10 While performing the hardware offloading process, much of the hardware
16 Linux kernel may differ from the hardware implementation. The pipeline debug
20 The hardware offload process is expected to be done in a way that the user
21 should not be able to distinguish between the hardware vs. software
22 implementation. In this process, hardware specifics are neglected. In
28 differences in the hardware and software models some processes cannot be
34 Level Path Compression trie (LPC-trie) in hardware.
38 information about the underlying hardware, this debugging can be made
49 Traditionally it has been used as an alternative model for hardware
85 is hardware counting for a specific table.
[all …]
|
| /linux/Documentation/process/ |
| A D | embargoed-hardware-issues.rst | 3 Embargoed hardware issues
16 hardware vendors and other parties. For some of the issues, software
28 The team only handles the coordination of embargoed hardware security
43 - PGP: https://www.kernel.org/static/files/hardware-security.asc
44 - S/MIME: https://www.kernel.org/static/files/hardware-security.crt
46 While hardware security issues are often handled by the affected hardware
48 identified a potential hardware flaw.
53 The current team of hardware security officers:
87 keep hardware security issues under embargo for coordination between
90 The Linux kernel community has successfully handled hardware security
[all …]
|
| /linux/drivers/isdn/mISDN/ |
| A D | dsp_dtmf.c | 52 int hardware = 1; in dsp_dtmf_hardware() local
58 hardware = 0; in dsp_dtmf_hardware()
66 hardware = 0; in dsp_dtmf_hardware()
73 hardware = 0; in dsp_dtmf_hardware()
81 hardware = 0; in dsp_dtmf_hardware()
89 hardware = 0; in dsp_dtmf_hardware()
92 dsp->dtmf.hardware = hardware; in dsp_dtmf_hardware()
93 dsp->dtmf.software = !hardware; in dsp_dtmf_hardware()
|
| /linux/Documentation/powerpc/ |
| A D | ptrace.rst | 5 GDB intends to support the following hardware debug features of BookE
8 4 hardware breakpoints (IAC)
9 2 hardware watchpoints (read, write and read-write) (DAC)
10 2 value conditions for the hardware watchpoints (DVC)
21 Query for GDB to discover the hardware debug features. The main info to
22 be returned here is the minimum alignment for the hardware watchpoints.
24 an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
28 GDB: this query will return the number of hardware breakpoints, hardware
53 Sets a hardware breakpoint or watchpoint, according to the provided structure::
86 With this GDB can ask for all kinds of hardware breakpoints and watchpoints
[all …]
|
| /linux/Documentation/driver-api/iio/ |
| A D | hw-consumer.rst | 4 An IIO device can be directly connected to another device in hardware. In this
5 case the buffers between IIO provider and IIO consumer are handled by hardware.
12 * :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer
13 * :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer
14 * :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer
15 * :c:func:`iio_hw_consumer_disable` — Disable IIO hardware consumer
|
| /linux/sound/isa/opti9xx/ |
| A D | opti92x-ad1848.c | 112 unsigned short hardware; member
168 unsigned short hardware) in snd_opti9xx_init() argument
172 chip->hardware = hardware; in snd_opti9xx_init()
194 switch (hardware) { in snd_opti9xx_init()
236 switch (chip->hardware) { in snd_opti9xx_read()
279 switch (chip->hardware) { in snd_opti9xx_write()
333 switch (chip->hardware) { in snd_opti9xx_configure()
494 if (chip->hardware > OPTi9XX_HW_82C928) { in snd_opti9xx_configure()
886 if (chip->hardware == OPTi9XX_HW_82C928 ||
887 chip->hardware == OPTi9XX_HW_82C929 ||
[all …]
|
| /linux/Documentation/ABI/testing/ |
| A D | sysfs-class-led-trigger-pattern | 19 Specify a hardware pattern for the LED, for LED hardware that
21 to some preprogrammed hardware patterns. It deactivates any active
24 Since different LED hardware can have different semantics of
25 hardware patterns, each driver is expected to provide its own
26 description for the hardware patterns in their documentation
|
| A D | sysfs-platform-dfl-fme | 101 hardware.
108 hardware.
135 threshold, hardware starts 50% or 90% throttling (see
144 threshold, hardware starts 100% throttling.
160 hardware threshold1 (see 'temp1_max'), otherwise 0.
167 hardware threshold2 (see 'temp1_crit'), otherwise 0.
193 this threshold, hardware starts 50% throttling.
195 As hardware only accepts values in Watts, so input value will
206 this threshold, hardware starts 90% throttling.
218 above hardware threshold1 (see 'power1_max'), otherwise 0.
[all …]
|
| /linux/Documentation/x86/ |
| A D | sva.rst | 36 Machines (VM's). This allows better hardware utilization vs. hard
38 allow the hardware to distinguish the context for which work is being
39 executed in the hardware by SWQ interface, SIOV uses Process Address Space
61 to the hardware and also permits hardware to be aware of application context
68 user processes and the rest of the hardware. When an application first
125 The device driver manages allocating hardware workqueues.
126 * A single mmap() maps a single hardware workqueue as a "portal" and
133 which case they still share one device hardware workqueue.
183 initialization of the hardware. User space only needs to worry about
189 hardware interfaces for virtualizing hardware. Hence, it's required to be
[all …]
|
| /linux/drivers/clk/ingenic/ |
| A D | Kconfig | 13 Support the clocks provided by the CGU hardware on Ingenic JZ4740
23 Support the clocks provided by the CGU hardware on Ingenic JZ4725B
33 Support the clocks provided by the CGU hardware on Ingenic JZ4760
43 Support the clocks provided by the CGU hardware on Ingenic JZ4770
53 Support the clocks provided by the CGU hardware on Ingenic JZ4780
63 Support the clocks provided by the CGU hardware on Ingenic X1000
73 Support the clocks provided by the CGU hardware on Ingenic X1830
|
| /linux/drivers/acpi/apei/ |
| A D | Kconfig | 28 platform hardware errors (such as that from chipset). It
29 works in so called "Firmware First" mode, that is, hardware
31 Linux by firmware. This way, some non-standard hardware
32 error registers or non-standard hardware link can be checked
33 by firmware to produce more valuable hardware error
59 EINJ provides a hardware error injection mechanism, it is
67 ERST is a way provided by APEI to save and retrieve hardware
|
| /linux/Documentation/driver-api/media/ |
| A D | cec-core.rst | 7 hardware. It is designed to handle a multiple types of hardware (receivers,
61 capabilities of the hardware and which parts are to be handled
125 hardware:
128 To enable/disable the hardware::
132 This callback enables or disables the CEC hardware. Enabling the CEC hardware
151 (some hardware may always be in 'monitor all' mode).
163 (some hardware may always be in 'monitor pin' mode).
199 To log the current CEC hardware status::
247 or LOW_DRIVE if the hardware cannot differentiate or something
248 else entirely. Some hardware only supports OK and FAIL as the
[all …]
|
| /linux/Documentation/block/ |
| A D | blk-mq.rst | 57 at the hardware queue, a second stage queue where the hardware has direct access
58 to process those requests. However, if the hardware does not have enough
60 queue, to be sent in the future, when the hardware is able.
95 eligible to be sent to the hardware. One of the possible schedulers to be
99 queue (a.k.a. run the hardware queue), the software queues mapped to that
100 hardware queue will be drained in sequence according to their mapping.
105 The hardware queue (represented by struct blk_mq_hw_ctx) is a struct
110 dispatch to the hardware.
116 requests that were ready to be sent first. The number of hardware queues
117 depends on the number of hardware contexts supported by the hardware and its
[all …]
|
| /linux/Documentation/userspace-api/media/dvb/ |
| A D | intro.rst | 72 following main hardware components:
75 Here the raw signal reaches the digital TV hardware from a satellite dish or
82 Conditional Access (CA) hardware like CI adapters and smartcard slots
83 The complete TS is passed through the CA hardware. Programs to which
89 Not every digital TV hardware provides conditional access hardware.
104 Modern hardware usually doesn't have a separate decoder hardware, as
106 adapter of the system or by a signal processing hardware embedded on
122 The Linux Digital TV API lets you control these hardware components through
125 control the MPEG2 decoder hardware, the frontend device the tuner and
127 and section filters of the hardware. If the hardware does not support
[all …]
|