/linux-6.6.21/Documentation/devicetree/bindings/leds/ |
D | leds-bcm6328.yaml | 14 In these SoCs it's possible to control LEDs both as GPIOs or by hardware. 18 Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml), or by hardware 20 Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and 21 exporting the 74x164 as spi-gpio prevents those LEDs to be hardware 25 should be controlled by a hardware signal instead of the MODE register value, 26 with 0 meaning hardware control enabled and 1 hardware control disabled. This 27 is usually 1:1 for hardware to LED signals, but through the activity/link 29 explained later in brcm,link-signal-sources). Even if a LED is hardware 31 but you can't turn it off if the hardware decides to light it up. For this 32 reason, hardware controlled LEDs aren't registered as LED class devices. [all …]
|
/linux-6.6.21/Documentation/devicetree/bindings/spi/ |
D | sprd,spi-adi.yaml | 17 framework for its hardware implementation is alike to SPI bus and its timing 21 48 hardware channels to access analog chip. For 2 software read/write channels, 22 users should set ADI registers to access analog chip. For hardware channels, 23 we can configure them to allow other hardware components to use it independently, 24 which means we can just link one analog chip address to one hardware channel, 25 then users can access the mapped analog chip address by this hardware channel 26 triggered by hardware components instead of ADI software channels. 28 Thus we introduce one property named "sprd,hw-channels" to configure hardware 29 channels, the first value specifies the hardware channel id which is used to 30 transfer data triggered by hardware automatically, and the second value specifies [all …]
|
/linux-6.6.21/drivers/media/rc/ |
D | serial_ir.c | 66 static struct serial_ir_hw hardware[] = { variable 68 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_HOMEBREW].lock), 82 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_IRDEO].lock), 93 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_IRDEO_REMOTE].lock), 104 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_ANIMAX].lock), 112 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_IGOR].lock), 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() [all …]
|
/linux-6.6.21/arch/mips/boot/dts/brcm/ |
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-6.6.21/sound/isa/sb/ |
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-6.6.21/sound/isa/wss/ |
D | wss_lib.c | 409 if ((timeout & CS4231_MCE) == 0 || !(chip->hardware & hw_mask)) in snd_wss_mce_down() 589 if (!(chip->hardware & WSS_HW_AD1848_MASK)) { in snd_wss_calibrate_mute() 597 if (chip->hardware == WSS_HW_INTERWAVE) { in snd_wss_calibrate_mute() 619 if (chip->hardware == WSS_HW_CS4231A || in snd_wss_playback_format() 620 (chip->hardware & WSS_HW_CS4232_MASK)) { in snd_wss_playback_format() 634 } else if (chip->hardware == WSS_HW_AD1845) { in snd_wss_playback_format() 656 if (chip->hardware != WSS_HW_INTERWAVE && !chip->single_dma) { in snd_wss_playback_format() 665 if (chip->hardware == WSS_HW_OPL3SA2) in snd_wss_playback_format() 680 if (chip->hardware == WSS_HW_CS4231A || in snd_wss_capture_format() 681 (chip->hardware & WSS_HW_CS4232_MASK)) { in snd_wss_capture_format() [all …]
|
/linux-6.6.21/drivers/hwmon/pmbus/ |
D | Kconfig | 21 If you say yes here you get hardware monitoring support for generic 33 If you say yes here you get hardware monitoring support for the ACBEL 44 If you say yes here you get hardware monitoring support for Analog 53 If you say yes here you get hardware monitoring support for Analog 63 If you say yes here you get hardware monitoring support for BEL 72 If you say yes here you get hardware monitoring support for BluTek 81 If you say yes here you get hardware monitoring support for 91 If you say yes here you get hardware monitoring support for 102 If you say yes here you get hardware monitoring support for the IBM 111 If you say yes here you get hardware monitoring support for Delta [all …]
|
/linux-6.6.21/Documentation/devicetree/bindings/crypto/ |
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-6.6.21/drivers/tty/ipwireless/ |
D | tty.c | 49 struct ipw_hardware *hardware; member 216 ret = ipwireless_send_packet(tty->hardware, IPW_CHANNEL_RAS, in ipw_write() 310 ret = ipwireless_set_RTS(tty->hardware, tty->channel_idx, 1); in set_control_lines() 314 ret = ipwireless_set_RTS(tty->hardware, in set_control_lines() 321 ret = ipwireless_set_DTR(tty->hardware, tty->channel_idx, 1); in set_control_lines() 325 ret = ipwireless_set_DTR(tty->hardware, in set_control_lines() 332 ret = ipwireless_set_RTS(tty->hardware, tty->channel_idx, 0); in set_control_lines() 334 ret = ipwireless_set_RTS(tty->hardware, in set_control_lines() 341 ret = ipwireless_set_DTR(tty->hardware, tty->channel_idx, 0); in set_control_lines() 343 ret = ipwireless_set_DTR(tty->hardware, in set_control_lines() [all …]
|
/linux-6.6.21/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ |
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 | 69 DPBPs represent hardware buffer pools. Packet I/O is performed in the context 71 hardware resources. 90 | | | | | hardware 92 | I/O hardware portals | [all …]
|
/linux-6.6.21/Documentation/driver-api/iio/ |
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-6.6.21/Documentation/networking/devlink/ |
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 32 greatly to the hardware implementation. The configuration API is the same, 34 Level Path Compression trie (LPC-trie) in hardware. 38 information about the underlying hardware, this debugging can be made 45 The ``devlink-dpipe`` interface closes this gap. The hardware's pipeline is [all …]
|
/linux-6.6.21/drivers/isdn/mISDN/ |
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-6.6.21/Documentation/ABI/testing/ |
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
|
D | sysfs-platform-dfl-fme | 101 hardware. 108 hardware. 133 Description: Read-Only. It returns hardware threshold1 temperature in 135 threshold, hardware starts 50% or 90% throttling (see 142 Description: Read-Only. It returns hardware threshold2 temperature in 144 threshold, hardware starts 100% throttling. 150 Description: Read-Only. It returns hardware trip threshold temperature in 160 hardware threshold1 (see 'temp1_max'), otherwise 0. 167 hardware threshold2 (see 'temp1_crit'), otherwise 0. 173 Description: Read-Only. Read this file to get the policy of hardware threshold1 [all …]
|
D | debugfs-pfo-nx-crypto | 33 The total number of AES operations submitted to the hardware. 36 The total number of bytes hashed by the hardware using SHA-256. 39 The total number of SHA-256 operations submitted to the hardware. 42 The total number of bytes hashed by the hardware using SHA-512. 45 The total number of SHA-512 operations submitted to the hardware.
|
D | sysfs-ptp | 7 features of PTP hardware clocks. 14 hardware clock registered into the PTP class driver 21 This file contains the name of the PTP hardware clock 32 This file contains the PTP hardware clock's maximum 48 alarms offer by the PTP hardware clock. 55 channels offered by the PTP hardware clock. 62 output channels offered by the PTP hardware clock. 69 offered by the PTP hardware clock. 89 pin offered by the PTP hardware clock. The file name 90 is the hardware dependent pin name. Reading from this [all …]
|
/linux-6.6.21/Documentation/powerpc/ |
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-6.6.21/drivers/char/hw_random/ |
D | Kconfig | 15 of possibly several hardware random number generators. 17 These hardware random number generators do feed into the 44 Generator hardware found on Intel i8xx-based motherboards. 58 Generator hardware found on AMD 76x-based motherboards. 71 Generator hardware found on Atmel AT91 devices. 83 Generator hardware based on Silex Insight BA431 IP. 95 Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs. 108 hardware found on the Broadcom iProc and STB SoCs. 122 Generator hardware found on the AMD Geode LX. 135 Generator hardware found on Niagara2 cpus. [all …]
|
/linux-6.6.21/drivers/clk/ingenic/ |
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 JZ4755 33 Support the clocks provided by the CGU hardware on Ingenic JZ4725B 43 Support the clocks provided by the CGU hardware on Ingenic JZ4760 53 Support the clocks provided by the CGU hardware on Ingenic JZ4770 63 Support the clocks provided by the CGU hardware on Ingenic JZ4780 73 Support the clocks provided by the CGU hardware on Ingenic X1000 83 Support the clocks provided by the CGU hardware on Ingenic X1830
|
/linux-6.6.21/drivers/acpi/apei/ |
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-6.6.21/Documentation/process/ |
D | embargoed-hardware-issues.rst | 3 Embargoed hardware issues 16 hardware vendors and other parties. For some of the issues, software 25 The Linux kernel hardware security team is separate from the regular Linux 28 The team only handles developing fixes for embargoed hardware security 34 The team can be contacted by email at <hardware-security@kernel.org>. This 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: [all …]
|
/linux-6.6.21/sound/isa/opti9xx/ |
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() 173 strcpy(chip->name, snd_opti9xx_names[hardware]); in snd_opti9xx_init() 188 chip->mc_base_size = opti9xx_mc_size[hardware]; in snd_opti9xx_init() 191 chip->mc_base_size = opti9xx_mc_size[hardware]; in snd_opti9xx_init() 194 switch (hardware) { in snd_opti9xx_init() 198 chip->password = (hardware == OPTi9XX_HW_82C928) ? 0xe2 : 0xe3; in snd_opti9xx_init() 212 chip->mc_base = (hardware == OPTi9XX_HW_82C930) ? 0xf8f : 0xf8d; in snd_opti9xx_init() 221 snd_printk(KERN_ERR "chip %d not supported\n", hardware); in snd_opti9xx_init() [all …]
|
/linux-6.6.21/Documentation/driver-api/media/ |
D | cec-core.rst | 7 hardware. It is designed to handle a multiple types of hardware (receivers, 35 The struct cec_adapter represents the CEC adapter hardware. It is created by 61 capabilities of the hardware and which parts are to be handled 128 hardware. They are all called with the mutex adap->lock held. 131 To enable/disable the hardware:: 135 This callback enables or disables the CEC hardware. Enabling the CEC hardware 139 hardware is enabled. CEC drivers should not set CEC_CAP_NEEDS_HPD unless 140 the hardware design requires that as this will make it impossible to wake 152 that are not for us. Not all hardware supports this and this function is only 154 (some hardware may always be in 'monitor all' mode). [all …]
|
/linux-6.6.21/Documentation/devicetree/bindings/timestamp/ |
D | hardware-timestamps-common.yaml | 4 $id: http://devicetree.org/schemas/timestamp/hardware-timestamps-common.yaml# 13 Some devices/SoCs have hardware timestamp engines (HTE) which can use 14 hardware means to timestamp entity in realtime. The entity could be anything 15 from GPIOs, IRQs, Bus and so on. The hardware timestamp engine present
|