openbmc/docs/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
66 ### Hardware Specific Feature
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
85 ### Vendor Specific Feature
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
94 To add a vendor-specific repository to OpenBMC, it should meet the following
103 specific hardware families. For example, [OpenPOWER][openpower] was one of the
109 not always possible due to specific features or functions only provided by
121 for hosting a hardware/vendor specific repository within the openbmc github
139 Within OpenBMC there are two areas of "vendor specific" repositories:
141 - A Hardware specific feature (implementation for a driver, support for
143 - Support for a vendor-specific feature. (OEM extensions, debug APIs, Redfish,
171 In a perfect world, only hardware-specific features would be in the meta machine
172 layers, and vendor specific features should be in distro features. OpenBMC is
178 vendor specific features and also as a reference for the TOF team to review when
179 assessing a request for a vendor specific repository within OpenBMC.