openbmc/docs/kernel-development.md

4 general development policy is that code must be upstream first. This is a strong
10 carried, as everything should be upstream.
15 1. When the OpenBMC kernel moves to a new upstream release
16 2. By backporting upstream commits from a newer kernel version to the OpenBMC
24 1. Submit your patch upstream. It doesn't need to be upstream, but it should be
32 When developing a new driver, your goal is to have the code accepted upstream.
34 hardware you wish to support. Check the OpenBMC `-dev` tree, check upstream, and
38 driver, before sending it upstream to the relevant maintainers. You should feel
39 welcome to cc the OpenBMC list when sending upstream, so other kernel developers
40 can provide input where appropriate. Be sure to follow the (upstream development
48 Once the driver has been accepted upstream, send the good news to the OpenBMC
49 list with a reference to the upstream tree. This may be Linus' tree, or it might
55 There are cases where waiting for upstream acceptance will delay the bring-up of
57 development of the features upstream, but where this has not happened we can
58 chose to carry the patches in the OpenBMC tree while the upstream development is
61 Another exception to the upstream first rule is where patches are modifying
62 files that are not upstream. This currently includes the aspeed board file
74 The OpenBMC kernel is currently based on the 4.7 series. If there is upstream
76 upstream commit SHA in the commit message.