/Linux-v5.4/Documentation/devicetree/bindings/leds/ |
D | leds-bcm6328.txt | 4 In these SoCs it's possible to control LEDs both as GPIOs or by hardware. 8 by hardware using this driver. 9 Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and 10 exporting the 74x164 as spi-gpio prevents those LEDs to be hardware 14 should be controlled by a hardware signal instead of the MODE register value, 15 with 0 meaning hardware control enabled and 1 hardware control disabled. This 16 is usually 1:1 for hardware to LED signals, but through the activity/link 18 explained later in brcm,link-signal-sources). Even if a LED is hardware 20 but you can't turn it off if the hardware decides to light it up. For this 21 reason, hardware controlled LEDs aren't registered as LED class devices. [all …]
|
/Linux-v5.4/Documentation/devicetree/bindings/spi/ |
D | spi-sprd-adi.txt | 5 framework for its hardware implementation is alike to SPI bus and its timing 9 48 hardware channels to access analog chip. For 2 software read/write channels, 10 users should set ADI registers to access analog chip. For hardware channels, 11 we can configure them to allow other hardware components to use it independently, 12 which means we can just link one analog chip address to one hardware channel, 13 then users can access the mapped analog chip address by this hardware channel 14 triggered by hardware components instead of ADI software channels. 16 Thus we introduce one property named "sprd,hw-channels" to configure hardware 17 channels, the first value specifies the hardware channel id which is used to 18 transfer data triggered by hardware automatically, and the second value specifies [all …]
|
/Linux-v5.4/drivers/hwspinlock/ |
D | Kconfig | 7 bool "Hardware Spinlock drivers" 10 tristate "OMAP Hardware Spinlock device" 14 Say y here to support the OMAP Hardware Spinlock device (firstly 20 tristate "Qualcomm Hardware Spinlock device" 25 Say y here to support the Qualcomm Hardware Mutex functionality, which 32 tristate "SIRF Hardware Spinlock device" 36 Say y here to support the SIRF Hardware Spinlock device, which 40 It's safe to say n here if you're not interested in SIRF hardware 44 tristate "SPRD Hardware Spinlock device" 48 Say y here to support the SPRD Hardware Spinlock device. [all …]
|
/Linux-v5.4/drivers/char/hw_random/ |
D | Kconfig | 3 # Hardware Random Number Generator (RNG) configuration 7 tristate "Hardware Random Number Generator Core support" 10 Hardware Random Number Generator Core infrastructure. 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. 57 Generator hardware found on AMD 76x-based motherboards. 70 Generator hardware found on Atmel AT91 devices. 84 Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs. 97 hardware found on the Broadcom iProc and STB SoCs. [all …]
|
/Linux-v5.4/drivers/hwmon/pmbus/ |
D | Kconfig | 21 If you say yes here you get hardware monitoring support for generic 32 If you say yes here you get hardware monitoring support for Analog 43 If you say yes here you get hardware monitoring support for the IBM 52 If you say yes here you get hardware monitoring support for the INSPUR 61 If you say yes here you get hardware monitoring support for the 70 If you say yes here you get hardware monitoring support for Infineon 79 If you say yes here you get hardware monitoring support for the 88 If you say yes here you get hardware monitoring support for Intersil 97 If you say yes here you get hardware monitoring support for National 106 If you say yes here you get hardware monitoring support for Linear [all …]
|
/Linux-v5.4/Documentation/process/ |
D | embargoed-hardware-issues.rst | 1 Embargoed hardware issues 7 Hardware issues which result in security problems are a different category 11 Hardware issues like Meltdown, Spectre, L1TF etc. must be treated 14 hardware vendors and other parties. For some of the issues, software 23 The Linux kernel hardware security team is separate from the regular Linux 26 The team only handles the coordination of embargoed hardware security 32 The team can be contacted by email at <hardware-security@kernel.org>. This 41 While hardware security issues are often handled by the affected hardware 43 identified a potential hardware flaw. 45 Hardware security officers [all …]
|
/Linux-v5.4/Documentation/driver-api/usb/ |
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 …]
|
D | writing_musb_glue_layer.rst | 35 hardware level. A couple of wiki pages by Texas Instruments and Analog 43 hardware sits at the lowest. The MUSB controller driver abstract the 44 MUSB controller hardware to the Linux USB stack:: 65 | MUSB Controller Hardware | 69 sitting in between the controller driver and the controller hardware. 97 goes through a few steps, basically allocating the controller hardware 256 * Set dyn_fifo to avoid reading EP config from hardware. 266 driver data of the MUSB controller hardware and pass it on to the MUSB 268 controller hardware responsible for sending/receiving the USB data. 287 PHY driver when the controller hardware itself is about to be released. [all …]
|
/Linux-v5.4/crypto/ |
D | crypto_engine.c | 3 * Handle async block request by crypto hardware engine. 20 * @engine: the hardware engine 58 * @engine: the hardware engine 62 * needs processing and if so call out to the driver to initialize hardware 104 dev_err(engine->dev, "failed to unprepare crypt hardware\n"); in crypto_pump_requests() 132 dev_err(engine->dev, "failed to prepare crypt hardware\n"); in crypto_pump_requests() 178 * @engine: the hardware engine 207 * @engine: the hardware engine 219 * @engine: the hardware engine 233 * @engine: the hardware engine [all …]
|
/Linux-v5.4/drivers/crypto/ |
D | Kconfig | 4 bool "Hardware crypto devices" 7 Say Y here to get to see options for hardware crypto devices and 86 down the use of the available crypto hardware. 112 This is the s390 hardware accelerated implementation of the 123 This is the s390 hardware accelerated implementation of the 133 This is the s390 hardware accelerated implementation of the 143 This is the s390 hardware accelerated implementation of the 153 This is the s390 hardware accelerated implementation of the 163 This is the s390 hardware accelerated implementation of the 175 This is the s390 hardware accelerated implementation of the [all …]
|
/Linux-v5.4/drivers/acpi/apei/ |
D | Kconfig | 21 bool "APEI Generic Hardware Error Source" 27 Generic Hardware Error Source provides a way to report 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-v5.4/drivers/iio/pressure/ |
D | zpa2326.c | 15 * A internal hardware trigger is also implemented to dispatch registered IIO 18 * ZPA2326 hardware supports 2 sampling mode: one shot and continuous. 29 * The continuous mode works according to a periodic hardware measurement 30 * process continuously pushing samples into an internal hardware FIFO (for 35 * - setup hardware sampling period, 37 * hardware FIFO and fetch temperature sample 41 * declares a valid interrupt line. In this case, the internal hardware trigger 44 * Note that hardware sampling frequency is taken into account only when 45 * internal hardware trigger is attached as the highest sampling rate seems to 51 * hardware samples averaging. [all …]
|
/Linux-v5.4/Documentation/media/kapi/ |
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 60 capabilities of the hardware and which parts are to be handled 123 hardware: 126 To enable/disable the hardware: 131 This callback enables or disables the CEC hardware. Enabling the CEC hardware 146 that not for us. Not all hardware supports this and this function is only 148 (some hardware may always be in 'monitor all' mode). 159 changes. Not all hardware supports this and this function is only called if 161 (some hardware may always be in 'monitor pin' mode). [all …]
|
/Linux-v5.4/Documentation/networking/device_drivers/toshiba/ |
D | spider_net.txt | 28 to receive data from the hardware. A "full" descriptor has data in it, 36 ring is handed off to the hardware, which sequentially fills in the 41 and "tail" pointers, managed by the OS, and a hardware current 43 currently being filled. When this descr is filled, the hardware 46 and everything in front of it should be "empty". If the hardware 50 The tail pointer tails or trails the hardware pointer. When the 51 hardware is ahead, the tail pointer will be pointing at a "full" 56 flowing, then the tail pointer can catch up to the hardware pointer. 64 dma-mapping it so as to make it visible to the hardware. The OS will 91 In the above, the hardware has filled in one descr, number 20. Both [all …]
|
/Linux-v5.4/Documentation/ABI/testing/ |
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 41 alarms offer by the PTP hardware clock. 48 channels offered by the PTP hardware clock. 55 output channels offered by the PTP hardware clock. 62 offered by the PTP hardware clock. 69 pin offered by the PTP hardware clock. The file name 70 is the hardware dependent pin name. Reading from this [all …]
|
/Linux-v5.4/drivers/mtd/nand/raw/ingenic/ |
D | Kconfig | 7 based boards, using the BCH controller for hardware error correction. 15 tristate "Hardware BCH support for JZ4740 SoC" 19 hardware present on the JZ4740 SoC from Ingenic. 25 tristate "Hardware BCH support for JZ4725B SoC" 28 Enable this driver to support the BCH error-correction hardware 35 tristate "Hardware BCH support for JZ4780 SoC" 38 Enable this driver to support the BCH error-correction hardware
|
/Linux-v5.4/include/net/ |
D | mac802154.h | 18 * enum ieee802154_hw_addr_filt_flags - hardware address filtering flags 21 * the stack to the hardware. 42 * struct ieee802154_hw_addr_filt - hardware address filtering settings 44 * @pan_id: pan_id which should be set to the hardware address filter. 46 * @short_addr: short_addr which should be set to the hardware address filter. 48 * @ieee_addr: extended address which should be set to the hardware address 51 * @pan_coord: boolean if hardware filtering should be operate as coordinator. 61 * struct ieee802154_hw - ieee802154 hardware 66 * @flags: hardware flags, see &enum ieee802154_hw_flags 68 * @parent: parent device of the hardware. [all …]
|
/Linux-v5.4/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 52 Sets a hardware breakpoint or watchpoint, according to the provided structure:: 85 With this GDB can ask for all kinds of hardware breakpoints and watchpoints [all …]
|
/Linux-v5.4/Documentation/networking/ |
D | netdev-features.txt | 33 hardware or software. 78 This callback should not modify hardware nor driver state (should be 88 Hardware should be reconfigured to match passed feature set. The set 91 should update netdev->features to match resulting hardware state. 113 NETIF_F_TSO_ECN means that hardware can properly split packets with CWR bit 139 * LLTX driver (deprecated for hardware drivers) 145 own locking, don't use it for new (hardware) drivers. 176 This requests that the NIC enables Hardware GRO (generic receive offload). 177 Hardware GRO is basically the exact reverse of TSO, and is generally 178 stricter than Hardware LRO. A packet stream merged by Hardware GRO must [all …]
|
/Linux-v5.4/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-v5.4/drivers/watchdog/ |
D | Kconfig | 18 reboot the machine) and a driver for hardware watchdog boards, which 66 care of pinging a hardware watchdog. A value of 0 means infinite. The 149 from some situations that the hardware watchdog will recover 332 This is the driver for the hardware watchdog on Mellanox systems. 362 the second one (WS1) is a real hardware reset. 436 boards have hardware problems that will cause the machine to simply 702 This is the driver for the hardware watchdog 732 This is the driver for the hardware watchdog on the Freescale 988 This is the driver for the hardware watchdog on Single Board 1011 This is the driver for the hardware watchdog on the ALi M1535 PMU. [all …]
|
/Linux-v5.4/Documentation/networking/device_drivers/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 57 . . . hardware 59 | MC hardware portals | 68 DPBPs represent hardware buffer pools. Packet I/O is performed in the context 70 hardware resources. 89 | | | | | hardware 91 | I/O hardware portals | [all …]
|
/Linux-v5.4/drivers/video/fbdev/ |
D | skeletonfb.c | 22 * hardware to that state. This allows a very clean separation of the fbdev 74 * This structure defines the hardware state of the graphics card. Normally 98 * Modern graphical hardware not only supports pipelines but some 103 * hardware state thus only one exist per card. In this case the 108 * aware of the entire hardware state that affects it because they share 116 * states. I hope this covers every possible hardware design. If not 129 * Each one represents the state of the hardware. Most hardware have 130 * just one hardware state. These here represent the default state(s). 145 * is used is to change from a text mode hardware state to a graphics 179 * Checks to see if the hardware supports the state requested by [all …]
|
/Linux-v5.4/Documentation/media/uapi/dvb/ |
D | intro.rst | 79 following main hardware components: 82 Here the raw signal reaches the digital TV hardware from a satellite dish or 89 Conditional Access (CA) hardware like CI adapters and smartcard slots 90 The complete TS is passed through the CA hardware. Programs to which 96 Not every digital TV hardware provides conditional access hardware. 111 Modern hardware usually doesn't have a separate decoder hardware, as 113 adapter of the system or by a signal processing hardware embedded on 129 The Linux Digital TV API lets you control these hardware components through 132 control the MPEG2 decoder hardware, the frontend device the tuner and 134 and section filters of the hardware. If the hardware does not support [all …]
|
/Linux-v5.4/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 …]
|