| /openbmc/linux/Documentation/scsi/ |
| H A D | scsi-parameters.rst | 19 advansys= [HW,SCSI]
22 aha152x= [HW,SCSI]
25 aha1542= [HW,SCSI]
28 aic7xxx= [HW,SCSI]
31 aic79xx= [HW,SCSI]
34 atascsi= [HW,SCSI]
37 BusLogic= [HW,SCSI]
41 gvp11= [HW,SCSI]
43 ips= [HW,SCSI] Adaptec / IBM ServeRAID controller
46 mac5380= [HW,SCSI]
[all …]
|
| /openbmc/linux/Documentation/networking/device_drivers/ethernet/huawei/ |
| H A D | hinic.rst | 35 specific HW details about HW data structure formats.
37 hinic_hwdev - Implement the HW details of the device and include the components
43 HW Interface:
49 Configuration Status Registers Area that describes the HW Registers on the
63 card by AEQs. Also set the addresses of the IO CMDQs in HW.
78 used to set the QPs addresses in HW. The commands completion events are
82 Queue Pairs(QPs) - The HW Receive and Send queues for Receiving and Transmitting
87 HW device:
90 HW device - de/constructs the HW Interface, the MGMT components on the
101 Port Commands - Send commands to the HW device for port management
[all …]
|
| /openbmc/qemu/audio/ |
| H A D | audio_template.h | 29 #define HW HWVoiceOut macro
34 #define HW HWVoiceIn macro
78 static void glue (audio_pcm_hw_free_resources_, TYPE) (HW *hw) in glue()
86 static void glue(audio_pcm_hw_alloc_resources_, TYPE)(HW *hw) in glue()
117 HW *hw = sw->hw; in glue()
160 HW *hw, in glue()
209 static void glue (audio_pcm_hw_add_sw_, TYPE) (HW *hw, SW *sw) in glue()
219 static void glue (audio_pcm_hw_gc_, TYPE) (HW **hwp) in glue()
221 HW *hw = *hwp; in glue()
237 static HW *glue(audio_pcm_hw_find_any_, TYPE)(AudioState *s, HW *hw) in glue()
[all …]
|
| /openbmc/linux/Documentation/watchdog/ |
| H A D | mlx-wdt.rst | 13 There are 2 types of HW watchdog implementations.
16 Actual HW timeout can be defined as a power of 2 msec.
22 Actual HW timeout is defined in sec. and it's the same as
31 Type 1 HW watchdog implementation exist in old systems and
32 all new systems have type 2 HW watchdog.
33 Two types of HW implementation have also different register map.
35 Type 3 HW watchdog implementation can exist on all Mellanox systems
54 This mlx-wdt driver supports both HW watchdog implementations.
65 Access to HW registers is performed through a generic regmap interface.
|
| /openbmc/linux/Documentation/networking/dsa/ |
| H A D | lan9303.rst | 21 interfaces (which is the default state of a DSA device). Due to HW limitations,
22 no HW MAC learning takes place in this mode.
24 When both user ports are joined to the same bridge, the normal HW MAC learning
25 is enabled. This means that unicast traffic is forwarded in HW. Broadcast and
26 multicast is flooded in HW. STP is also supported in this mode. The driver
37 - The HW does not support VLAN-specific fdb entries
|
| /openbmc/linux/Documentation/translations/zh_CN/infiniband/ |
| H A D | opa_vnic.rst | 117 依赖于HW的VNIC功能是HFI1驱动的一部分。它实现了分配和释放OPA_VNIC RDMA
118 netdev的动作。它涉及VNIC功能的HW资源分配/管理。它与网络堆栈接口并实现所
120 并提供对它们的HW访问。在将数据包向上传递到网络堆栈之前，它把Omni-Path头
126 RDMA netdev设备。它在需要时覆盖由依赖HW的VNIC驱动设置的net_device_ops函数，
129 RDMA netdev控制操作将任何控制信息传递给依赖于HW的驱动程序::
|
| /openbmc/linux/Documentation/ABI/testing/ |
| H A D | sysfs-bus-coresight-devices-etb10 | 27 2. The value is read directly from HW register RDP, 0x004.
34 is read directly from HW register STS, 0x00C.
42 interface. The value is read directly from HW register RRP,
52 from HW register RWP, 0x018.
59 read directly from HW register TRG, 0x01C.
66 is read directly from HW register CTL, 0x020.
73 register. The value is read directly from HW register FFSR,
81 register. The value is read directly from HW register FFCR,
|
| H A D | sysfs-bus-coresight-devices-tmc | 15 The value is read directly from HW register RSZ, 0x004.
22 is read directly from HW register STS, 0x00C.
30 interface. The value is read directly from HW register RRP,
40 from HW register RWP, 0x018.
47 read directly from HW register TRG, 0x01C.
54 is read directly from HW register CTL, 0x020.
61 register. The value is read directly from HW register FFSR,
69 register. The value is read directly from HW register FFCR,
|
| H A D | sysfs-bus-coresight-devices-etm4x | 337 The value it taken directly from the HW.
344 (0x310). The value is taken directly from the HW.
351 (0x314). The value is taken directly from the HW.
358 (0xFB4). The value is taken directly from the HW.
365 (0xFB8). The value is taken directly from the HW.
372 (0xFC8). The value is taken directly from the HW.
380 from the HW.
387 (0xFCC). The value is taken directly from the HW.
394 (0xFE0). The value is taken directly from the HW.
401 (0xFE4). The value is taken directly from the HW.
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/clock/ti/ |
| H 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
|
| /openbmc/linux/Documentation/driver-api/iio/ |
| H A D | hw-consumer.rst | 2 HW consumer
6 The Industrial I/O HW consumer offers a way to bond these IIO devices without
18 HW consumer setup
22 A typical IIO HW consumer setup looks like this::
|
| /openbmc/linux/Documentation/infiniband/ |
| H A D | opa_vnic.rst | 104 OPA VNIC functionality has a HW dependent component and a HW
112 The HW dependent VNIC functionality is part of the HFI1 driver. It
114 It involves HW resource allocation/management for VNIC functionality.
117 packets in the transmit path and provides HW access to them. It strips
121 The OPA VNIC module implements the HW independent VNIC functionality.
127 set by HW dependent VNIC driver where required to accommodate any control
131 interface. It also passes any control information to the HW dependent driver
|
| /openbmc/linux/drivers/crypto/intel/keembay/ |
| H A D | Kconfig | 2 tristate "Support for Intel Keem Bay OCS AES/SM4 HW acceleration"
12 Provides HW acceleration for the following transformations:
20 bool "Support for Intel Keem Bay OCS AES/SM4 ECB HW acceleration"
31 bool "Support for Intel Keem Bay OCS AES/SM4 CTS HW acceleration"
43 tristate "Support for Intel Keem Bay OCS ECC HW acceleration"
62 tristate "Support for Intel Keem Bay OCS HCU HW acceleration"
|
| /openbmc/linux/net/tls/ |
| H A D | Kconfig | 21 bool "Transport Layer Security HW offload"
27 Enable kernel support for HW offload of the TLS protocol.
36 Enable kernel support for legacy HW offload of the TLS protocol,
|
| /openbmc/linux/Documentation/devicetree/bindings/dma/ |
| H A D | qcom_hidma_mgmt.txt | 7 Each HIDMA HW instance consists of multiple DMA channels. These channels
37 Once a reset is applied to the HW, HW starts a timer for reset operation
38 to confirm. If reset is not completed within this time, HW reports reset
50 - compatible: must contain "qcom,hidma-1.0" for initial HW or
51 "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
|
| /openbmc/linux/drivers/cpufreq/ |
| H A D | Kconfig.arm | 146 tristate "MediaTek CPUFreq HW driver"
150 Support for the CPUFreq HW driver.
151 Some MediaTek chipsets have a HW engine to offload the steps
154 The driver implements the cpufreq interface for this HW engine.
155 Say Y if you want to support CPUFreq HW.
174 tristate "QCOM CPUFreq HW driver"
178 Support for the CPUFreq HW driver.
179 Some QCOM chipsets have a HW engine to offload the steps
182 The driver implements the cpufreq interface for this HW engine.
183 Say Y if you want to support CPUFreq HW.
|
| /openbmc/linux/drivers/gpu/drm/sti/ |
| H A D | NOTES | 3 The STMicroelectronics stiH SoCs use a common chain of HW display IP blocks:
19 - The VTG (Video Timing Generators) build Vsync signals used by the other HW IP
20 Note that some stiH drivers support only a subset of thee HW IP.
37 2. DRM / HW mapping
|
| /openbmc/u-boot/board/toradex/apalis_imx6/ |
| H A D | Kconfig | 43 bool "Apalis iMX6 V1.0 HW"
45 Apalis iMX6 V1.0 HW has a different pinout for the UART.
49 option the config block stating V1.0 HW selects DCE mode,
|
| /openbmc/linux/Documentation/networking/device_drivers/ethernet/stmicro/ |
| H A D | stmmac.rst | 159 This parameter changes the default HW FIFO Threshold control value.
218 the reception on chips older than the 3.50. New chips have an HW RX Watchdog
263 checks to the HW using MAC and PHY loopback mechanisms::
305 supported. This is done by looking at both the DMA HW capability register and
326 available at run-time by looking at the HW capability register. This means
328 PHYLIB stuff. In fact, the HW provides a subset of extended registers to
372 7) HW uses the GMAC core::
380 9) Core is able to perform TX Checksum and/or RX Checksum in HW::
385 11) Some HWs are not able to perform the csum in HW for over-sized frames due
440 necessary on some platforms (e.g. ST boxes) where the HW needs to have set
[all …]
|
| /openbmc/linux/Documentation/virt/kvm/devices/ |
| H A D | xive.rst | 21 The KVM device exposes different MMIO ranges of the XIVE HW which
52 interrupts are from a different HW controller (PHB4) and the ESB
56 kvmppc_xive_clr_mapped() are called when the device HW irqs are
60 The handler will insert the ESB page corresponding to the HW
119 -ENXIO Could not allocate underlying HW interrupt
147 underlying HW interrupt failed
192 -EIO Configuration of the underlying HW failed
211 called the NVT. When a VP is not dispatched on a HW processor
212 thread, this structure can be updated by HW if the VP is the target
|
| /openbmc/linux/Documentation/arch/x86/ |
| H A D | tsx_async_abort.rst | 69 …0 0 0 HW default Yes Same as MDS Same as MDS
71 …0 1 0 HW default No Need ucode update Need ucode up…
84 … 0 0 0 HW default Yes Same as MDS Same as MDS
86 …0 1 0 HW default No Need ucode update Need ucode up…
99 …0 0 0 HW default Yes Same as MDS Same as MDS
101 …0 1 0 HW default No Need ucode update Need ucode up…
|
| /openbmc/linux/Documentation/powerpc/ |
| H A D | cpu_families.rst | 186 - e6500 adds HW loaded indirect TLB entries.
219 | e6500 (HW TLB) (Multithreaded) |
226 - Book3E, software loaded TLB + HW loaded indirect TLB entries.
|
| /openbmc/u-boot/doc/device-tree-bindings/reset/ |
| H A D | reset.txt | 21 in hardware for a reset signal to affect multiple logically separate HW blocks
23 the DT node of each affected HW block, since if activated, an unrelated block
26 children of the bus are affected by the reset signal, or an individual HW
28 appropriate software access to the reset signals in order to manage the HW,
29 rather than to slavishly enumerate the reset signal that affects each HW
|
| /openbmc/linux/Documentation/devicetree/bindings/reset/ |
| H A D | reset.txt | 21 in hardware for a reset signal to affect multiple logically separate HW blocks
23 the DT node of each affected HW block, since if activated, an unrelated block
26 children of the bus are affected by the reset signal, or an individual HW
28 appropriate software access to the reset signals in order to manage the HW,
29 rather than to slavishly enumerate the reset signal that affects each HW
|
| /openbmc/linux/Documentation/networking/ |
| H A D | xfrm_device.rst | 108 - enable the HW offload of the SA
138 set up HW for send
145 When a packet is received and the HW has indicated that it offloaded a
173 Driver will check packet seq number and update HW ESN state machine if needed.
176 HW adds and deletes XFRM headers. So in RX path, XFRM stack is bypassed if HW
178 and not encrypted, the HW is responsible to perform it.
192 Outcome of HW handling packets, the XFRM core can't count hard, soft limits.
193 The HW/driver are responsible to perform it and provide accurate data when
|