| /openbmc/linux/drivers/ufs/host/ |
| H A D | Kconfig | 45 This selects the Cadence-specific additions to UFSHCD platform driver.
58 tristate "QCOM specific hooks to UFS controller platform driver"
64 This selects the QCOM specific additions to UFSHCD platform driver.
65 UFS host on QCOM needs some vendor specific configuration before
67 specific registers.
73 tristate "Mediatek specific hooks to UFS controller platform driver"
79 This selects the Mediatek specific additions to UFSHCD platform driver.
80 UFS host on Mediatek needs some vendor specific configuration before
82 specific registers.
89 tristate "Hisilicon specific hooks to UFS controller platform driver"
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/hwlock/ |
| H A D | hwlock.txt | 4 Generic bindings that are common to all the hwlock platform specific driver
7 Please also look through the individual platform specific hwlock binding
8 documentations for identifying any additional properties specific to that
16 specific lock.
21 Consumers that require specific hwlock(s) should specify them using the
34 use the hwlock-names to match and get a specific hwlock.
37 1. Example of a node using a single specific hwlock:
49 2. Example of a node using multiple specific hwlocks:
|
| /openbmc/openbmc/poky/meta/recipes-kernel/linux/ |
| H A D | cve-exclusion.inc | 1 CVE_STATUS[CVE-1999-0656] = "not-applicable-config: specific to ugidd, part of the old user-mode NF…
3 CVE_STATUS[CVE-2006-2932] = "not-applicable-platform: specific to RHEL"
5 CVE_STATUS[CVE-2007-2764] = "not-applicable-platform: specific to Sun/Brocade SilkWorm switches"
17 CVE_STATUS[CVE-2016-3695] = "not-applicable-platform: specific to RHEL with securelevel patches"
19 CVE_STATUS[CVE-2016-3699] = "not-applicable-platform: specific to RHEL with securelevel patches"
21 CVE_STATUS[CVE-2017-6264] = "not-applicable-platform: Android specific"
23 CVE_STATUS[CVE-2017-1000377] = "not-applicable-platform: GRSecurity specific"
|
| /openbmc/docs/ |
| H A D | hw-vendor-repos-policy.md | 25 Both hardware-specific and vendor-specific repositories should meet the
63 Note that when a recipe is non-OpenBMC specific, but useful to OpenBMC, it
70 1. A function that is specific to the vendor hardware
71 - For example, PECI, FSI, hardware diagnostics (specific to the processor)
72 2. A device attached to the BMC (MCTP/PLDM/I2C/...) that is specific to the
75 To add a hardware specific repository to OpenBMC, it should meet the following
78 1. If it requires specific kernel APIs, they are available or in progress via
87 A vendor-specific feature is defined as one of the following:
89 1. A vendor-specific data format or protocol
92 2. A function that requires a specific hardware vendor feature
[all …]
|
| /openbmc/linux/drivers/gpu/drm/rockchip/ |
| H A D | Kconfig | 38 bool "Rockchip specific extensions for Analogix DP driver"
43 This selects support for Rockchip SoC specific extensions
53 This selects support for Rockchip SoC specific extensions
59 bool "Rockchip specific extensions for Synopsys DW HDMI"
61 This selects support for Rockchip SoC specific extensions
67 bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
70 This selects support for Rockchip SoC specific extensions
76 bool "Rockchip specific extensions for Innosilicon HDMI"
78 This selects support for Rockchip SoC specific extensions
103 bool "Rockchip specific extensions for RK3066 HDMI"
[all …]
|
| /openbmc/linux/lib/crypto/ |
| H A D | Kconfig | 26 Declares whether the architecture provides an arch-specific
35 fallback, e.g., for SIMD implementations. If no arch specific
42 Declares whether the architecture provides an arch-specific
52 fallback, e.g., for SIMD implementations. If no arch specific
62 by either the generic implementation or an arch-specific one, if one
68 Declares whether the architecture provides an arch-specific
77 fallback, e.g., for SIMD implementations. If no arch specific
88 fulfilled by either the generic implementation or an arch-specific
104 Declares whether the architecture provides an arch-specific
113 fallback, e.g., for SIMD implementations. If no arch specific
[all …]
|
| /openbmc/openbmc/poky/meta/conf/machine/include/arm/ |
| H A D | README | 11 A small set of ARM specific variables have been defined to allow
25 ARMPKGSFX_THUMB - This is the thumb specific suffix. Curently it is
28 ARMPKGSFX_DSP - This is the DSP specific suffix. Currently this is set
31 ARMPKGSFX_EABI - This is the eabi specific suffix. There are currently
36 ARMPKGSFX_ENDIAN - This is the endian specific suffix. It is defined in
39 ARMPKGSFX_FPU - This is the FPU specific suffix. The suffix indicates
40 specific FPU optimizations. 'vfp' and 'neon' are both defined.
|
| /openbmc/linux/drivers/edac/ |
| H A D | i5000_edac.c | 465 char *specific = NULL; in i5000_process_fatal_error_info() local
494 specific = "Alert on non-redundant retry or fast " in i5000_process_fatal_error_info()
498 specific = "Northbound CRC error on non-redundant " in i5000_process_fatal_error_info()
516 specific = ">Tmid Thermal event with intelligent " in i5000_process_fatal_error_info()
525 bank, ras, cas, allErrors, specific); in i5000_process_fatal_error_info()
546 char *specific = NULL; in i5000_process_nonfatal_error_info() local
588 specific = "Non-Aliased Uncorrectable Patrol Data ECC"; in i5000_process_nonfatal_error_info()
591 specific = "Non-Aliased Uncorrectable Spare-Copy " in i5000_process_nonfatal_error_info()
595 specific = "Non-Aliased Uncorrectable Mirrored Demand " in i5000_process_nonfatal_error_info()
599 specific = "Non-Aliased Uncorrectable Non-Mirrored " in i5000_process_nonfatal_error_info()
[all …]
|
| /openbmc/linux/Documentation/arch/sh/ |
| H A D | new-machine.rst | 18 of the board-specific code (with the exception of stboards) ended up
19 in arch/sh/kernel/ directly, with board-specific headers ending up in
24 Board-specific code::
31 | | `-- board-specific files
33 | | `-- board-specific files
40 | `-- board-specific headers
42 | `-- board-specific headers
54 `-- cchip-specific files
57 board-specific headers. Thus, include/asm-sh/hd64461 is home to all of the
58 hd64461-specific headers.
[all …]
|
| /openbmc/qemu/docs/devel/migration/ |
| H A D | virtio.rst | 18 transport specific state (msix vectors, indicators, ...)
43 - save transport-specific
50 - save transport-specific
53 - save device-specific
80 - load transport-specific
87 - load transport-specific
91 - load device-specific
114 added to the core for compatibility reasons. If transport or device specific
|
| /openbmc/qemu/tests/qemu-iotests/tests/ |
| H A D | qemu-img-bitmaps | 93 _img_info --format-specific | _filter_irrelevant_img_info
103 _img_info --format-specific | _filter_irrelevant_img_info
112 _img_info --format-specific --backing-chain | _filter_irrelevant_img_info
142 _img_info --format-specific | _filter_irrelevant_img_info
147 TEST_IMG="$TEST_IMG.copy" _img_info --format-specific \
153 TEST_IMG="$TEST_IMG.copy" _img_info --format-specific \
161 TEST_IMG="$TEST_IMG.copy" _img_info --format-specific \
|
| /openbmc/linux/drivers/bcma/ |
| H A D | README | 2 however from programming point of view there is nothing AMBA specific we use.
4 Standard AMBA drivers are platform specific, have hardcoded addresses and use
8 1) Broadcom specific AMBA device. It is put on AMBA bus, but can not be treated
12 devices is used for managing Broadcom specific core.
18 16 devices identified by Broadcom specific fields: manufacturer, id, revision
|
| /openbmc/u-boot/board/coreboot/coreboot/ |
| H A D | Kconfig | 23 hex "Board specific Cache-As-RAM (CAR) address"
26 This option specifies the board specific Cache-As-RAM (CAR) address.
29 hex "Board specific Cache-As-RAM (CAR) size"
32 This option specifies the board specific Cache-As-RAM (CAR) size.
|
| /openbmc/linux/arch/x86/configs/ |
| H A D | xen.config | 1 # global x86 required specific stuff
15 # x86 xen specific config options
21 # x86 specific backend drivers
23 # x86 specific frontend drivers
|
| /openbmc/linux/Documentation/driver-api/ |
| H A D | vfio-pci-device-specific-driver-acceptance.rst | 3 Acceptance criteria for vfio-pci device specific driver variants
11 vfio-pci driver does include some device specific support, further
12 extensions for yet more advanced device specific features are not
15 requiring device specific knowledge, ex. saving and loading device
18 In support of such features, it's expected that some device specific
29 documentation for reviewers to understand the device specific
|
| /openbmc/linux/Documentation/devicetree/bindings/sifive/ |
| H A D | sifive-blocks-ip-versioning.txt | 9 IP block-specific DT compatible strings are contained within the HDL,
26 match on these IP block-specific compatible strings.
29 continue to specify an SoC-specific compatible string value, such as
30 "sifive,fu540-c000-uart". This way, if SoC-specific
31 integration-specific bug fixes or workarounds are needed, the kernel
33 IP block-specific compatible string (such as "sifive,uart0") should
|
| /openbmc/linux/Documentation/devicetree/bindings/mmc/ |
| H A D | k3-dw-mshc.txt | 1 * Hisilicon specific extensions to the Synopsys Designware Mobile
9 by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
15 - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific extensions.
17 with hi3670 specific extensions.
18 - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions.
19 - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions.
|
| /openbmc/linux/Documentation/arch/arm/samsung/ |
| H A D | overview.rst | 26 - S5PC110 specific default configuration
28 - S5PV210 specific default configuration
35 several platform directories and then the machine specific directories
40 specific information. It contains the base clock, GPIO and device definitions
43 plat-s5p is for s5p specific builds, and contains common support for the
44 S5P specific systems. Not all S5Ps use all the features in this directory
|
| H A D | gpio.rst | 9 specific calls provided alongside the drivers/gpio core.
16 specific calls for the items that require Samsung specific handling, such
25 Pin configuration is specific to the Samsung architecture, with each SoC
|
| /openbmc/bmcweb/redfish-core/include/registries/ |
| H A D | openbmc_message_registry.readmefirst.md | 9 1. Messages should not be specific to a piece or type of hardware. Generally
11 message strings, unless that behavior is specific to that particular piece of
13 MemoryECCError (ECC is specific to memory, therefore class specific is
16 2. Messages should not use any proprietary, copyright, or company-specific
29 5. If you are changing this in your own downstream company-specific fork, please
|
| /openbmc/linux/Documentation/networking/devlink/ |
| H A D | octeontx2.rst | 13 The ``octeontx2 PF and VF`` drivers implement the following driver-specific parameters.
15 .. list-table:: Driver-specific parameters implemented
29 The ``octeontx2 AF`` driver implements the following driver-specific parameters.
31 .. list-table:: Driver-specific parameters implemented
|
| /openbmc/linux/Documentation/driver-api/usb/ |
| H A D | typec_bus.rst | 10 The communication is SVID (Standard or Vendor ID) specific, i.e. specific for
29 specific commands from the alternate mode drivers to the partner, and from the
30 partners to the alternate mode drivers. No direct SVID specific communication is
47 will be used to deliver all the SVID specific commands from the partner to the
49 the SVID specific commands to each other using :c:func:`typec_altmode_vdm()`.
51 If the communication with the partner using the SVID specific commands results
54 passes the negotiated SVID specific pin configuration value to the function as
58 NOTE: The SVID specific pin configuration values must always start from
67 An example of working definitions for SVID specific pin configurations would
|
| /openbmc/u-boot/arch/riscv/cpu/ax25/ |
| H A D | Kconfig | 4 Run U-Boot on AndeStar V5 platforms and use some specific features
10 bool "AndeStar V5 families specific cache support"
12 Provide Andes Technology AndeStar V5 families specific cache support.
|
| /openbmc/phosphor-power/phosphor-power-sequencer/docs/config_file/ |
| H A D | README.md | 22 general error when a pgood fault occurs. No specific rail will be identified.
33 A config file is normally system-specific. Each system type usually has a
42 system types. The types are ordered from most specific to least specific.
51 matches one of these compatible system types. It searches from most specific to
52 least specific. The first config file found, if any, will be used.
|
| /openbmc/docs/designs/ |
| H A D | psu-firmware-update.md | 50 avoid power loss. This shall be handled by PSU vendor-specific tools, but not in
53 Note: The "vendor-specific" referred below is the PSU vendor-specific.
55 So the below checks are optional and expected to be handled by vendor-specific
80 vendor-specific purpose, e.g. to indicate the PSU model.
99 its related vendor-specific tools.
100 - The service will find the matched vendor-specific tool to perform the code
101 update. For example, if a vendor specific tool `foo` is configured in
110 4. The vendor-specific tool shall run all the checks it needs to be run, before
113 5. When the vendor-specific tool returns errors, the PSU update will be aborted
134 3. If PSU update is needed, the service will find the matched vendor-specific
[all …]
|