| /linux/drivers/media/rc/ |
| H A D | serial_ir.c | 67 static struct serial_ir_hw hardware[] = { variable 69 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_HOMEBREW].lock), 83 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_IRDEO].lock), 94 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_IRDEO_REMOTE].lock), 105 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_ANIMAX].lock), 113 .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_IGOR].lock), 164 soutp(UART_MCR, hardware[type].off); in on() 166 soutp(UART_MCR, hardware[type].on); in on() 172 soutp(UART_MCR, hardware[type].on); in off() 174 soutp(UART_MCR, hardware[type].off); in off() [all …]
|
| /linux/arch/mips/boot/dts/brcm/ |
| H 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/Documentation/block/ |
| H A D | inline-encryption.rst | 12 Inline encryption hardware sits logically between memory and disk, and can 14 can control exactly how the inline encryption hardware will en/decrypt the data 18 Some inline encryption hardware accepts all encryption parameters including raw 20 hardware instead has a fixed number of "keyslots" and requires that the key, 24 Note that inline encryption hardware is very different from traditional crypto 27 hardware operates on I/O requests. Thus, inline encryption hardware needs to be 30 Inline encryption hardware is also very different from "self-encrypting drives", 33 verify the correctness of the resulting ciphertext. Inline encryption hardware 42 encryption hardware is absent. We also want inline encryption to work with 44 the inline encryption hardware of the underlying devices if present, or else [all …]
|
| H A D | blk-mq.rst | 49 blk-mq has two group of queues: software staging queues and hardware dispatch 51 path possible: send it directly to the hardware queue. However, there are two 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 98 any reordering. When the device starts processing requests in the hardware 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 [all …]
|
| /linux/arch/riscv/ |
| H A D | Kconfig.socs | 8 This enables support for Andes SoC platform hardware. 13 This enables support for Anlogic SoC platform hardware. 18 This enables support for ESWIN SoC platform hardware, 38 This enables support for SiFive SoC platform hardware. 43 This enables support for Sophgo SoC platform hardware. 49 This enables support for SpacemiT SoC platform hardware. 60 This enables support for StarFive SoC platform hardware. 68 This enables support for Allwinner sun20i platform hardware, 103 This enables support for Canaan Kendryte series SoC platform hardware. 112 This enables support for Canaan Kendryte K210 SoC platform hardware.
|
| /linux/drivers/tty/ipwireless/ |
| H A 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 …]
|
| H A D | main.c | 184 ipwireless_init_hardware_v1(ipw->hardware, link->resource[0]->start, in config_ipwireless() 204 ipw->network = ipwireless_network_create(ipw->hardware); in config_ipwireless() 208 ipw->tty = ipwireless_tty_create(ipw->hardware, ipw->network); in config_ipwireless() 212 ipwireless_init_hardware_v2_v3(ipw->hardware); in config_ipwireless() 277 ipw->hardware = ipwireless_hardware_create(); in ipwireless_attach() 278 if (!ipw->hardware) { in ipwireless_attach() 310 if (ipw->hardware != NULL) in ipwireless_detach() 311 ipwireless_hardware_free(ipw->hardware); in ipwireless_detach()
|
| /linux/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ |
| H 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 | 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/Documentation/networking/devlink/ |
| H 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 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/arch/s390/crypto/ |
| H A D | Kconfig | 26 As of z9 the ECB and CBC modes are hardware accelerated 29 As of z10 the ECB and CBC modes are hardware accelerated 32 As of z196 the CTR mode is hardware accelerated for all AES 33 key sizes and XTS mode is hardware accelerated for 256 and 49 As of z990 the ECB and CBC mode are hardware accelerated. 50 As of z196 the CTR mode is hardware accelerated. 56 s390 specific HMAC hardware support for SHA224, SHA256, SHA384 and
|
| /linux/drivers/isdn/mISDN/ |
| H 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/driver-api/iio/ |
| H 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/Documentation/arch/powerpc/ |
| H 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/translations/sp_SP/process/ |
| H A D | embargoed-hardware-issues.rst | 4 :Original: Documentation/process/embargoed-hardware-issues.rst 7 Problemas de hardware embargados 13 Los problemas de hardware que resultan en problemas de seguridad son una 17 Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben 20 vendedores diferentes de OS, distribuciones, vendedores de hardware y 30 El equipo de seguridad de hardware del kernel de Linux es separado del 34 hardware embargados. Los informes de errores de seguridad de software puro 41 <hardware-security@kernel.org>. Esta es una lista privada de oficiales de 51 - PGP: https://www.kernel.org/static/files/hardware-security.asc 52 - S/MIME: https://www.kernel.org/static/files/hardware-security.crt [all …]
|
| /linux/drivers/clk/ingenic/ |
| H 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 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/Documentation/ABI/testing/ |
| H A 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 …]
|
| H A 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 …]
|
| H A 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.
|
| H A D | sysfs-class-switchtec | 18 Description: Component identifier as stored in the hardware (eg. PM8543) 27 Description: Component revision stored in the hardware (read only) 35 Description: Component vendor as stored in the hardware (eg. MICROSEM) 44 Description: Device version as stored in the hardware (read only) 76 Description: Product identifier as stored in the hardware (eg. PSX 48XG3) 85 Description: Product revision stored in the hardware (eg. RevB) 94 Description: Product vendor as stored in the hardware (eg. MICROSEM)
|
| /linux/Documentation/driver-api/media/ |
| H A 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/Documentation/driver-api/ |
| H A D | hw-recoverable-errors.rst | 11 and log recoverable hardware errors. These are hardware recoverable errors 17 correlating hardware events with kernel failures. This enables faster triage 19 environments where hardware issues are common. 24 - Facilitates correlation of hardware recoverable errors with kernel panics or 28 - Complements existing full hardware diagnostics without replacing them.
|
| /linux/Documentation/driver-api/usb/ |
| H A D | gadget.rst | 22 they're easy to port to new hardware. 36 - Minimalist, so it's easier to support new device controller hardware. 41 USB ``host`` hardware in a PC, workstation, or server. Linux users with 42 embedded systems are more likely to have USB peripheral hardware. To 43 distinguish drivers running inside such hardware from the more familiar 58 necessarily different (one side is a hardware-neutral master, the other 59 is a hardware-aware slave), the endpoint I/0 API used here should also 69 hardware). 75 to hardware, through registers, fifos, dma, irqs, and the like. The 77 endpoint hardware. That hardware is exposed through endpoint [all …]
|
| /linux/drivers/mtd/nand/ |
| H A D | Kconfig | 50 bool "Macronix external hardware ECC engine" 54 This enables support for the hardware ECC engine from Macronix. 57 tristate "Mediatek hardware ECC engine" 62 This enables support for the hardware ECC engine from Mediatek. 65 tristate "Realtek RTL93xx hardware ECC engine" 70 This enables support for the hardware ECC engine from Realtek.
|
| /linux/Documentation/arch/x86/ |
| H 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 56 command was accepted by hardware. This allows the submitter to know if the 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 94 platform hardware. ENQCMD uses the PASID stored in this MSR to tag requests 153 * Devices have a limited number (~10's to 1000's) of hardware workqueues. 154 The device driver manages allocating hardware workqueues. 155 * A single mmap() maps a single hardware workqueue as a "portal" and [all …]
|
| /linux/Documentation/process/ |
| H A D | embargoed-hardware-issues.rst | 3 Embargoed hardware issues 16 silicon vendors, hardware integrators, and other parties. For some of the 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 silicon 48 identified a potential hardware flaw. 53 The current team of hardware security officers: [all …]
|