| 1 | |
| 2 |
|
| 3 | ======================================
|
| 4 | Devicetree and Open Firmware Subsystem
|
| 5 | ======================================
|
| 6 |
|
| 7 | Other Process Documents
|
| 8 | -----------------------
|
| 9 |
|
| 10 | Please see the documents in Documentation/devicetree/bindings/ for information
|
| 11 | on how to write proper Devicetree bindings and how to submit patches.
|
| 12 |
|
| 13 | Patch Review and Handling
|
| 14 | -------------------------
|
| 15 |
|
| 16 | Patches handled by Devicetree maintainers are processed differently depending
|
| 17 | on the patch type:
|
| 18 |
|
| 19 | 1. Core OF driver code, e.g. drivers/of/:
|
| 20 | patches are reviewed and applied by DT maintainers.
|
| 21 |
|
| 22 | 2. Devicetree bindings:
|
| 23 | patches are reviewed by DT maintainers, but should be applied by subsystem
|
| 24 | maintainers except in certain cases. See also *For kernel maintainers* in
|
| 25 | Documentation/devicetree/bindings/submitting-patches.rst.
|
| 26 |
|
| 27 | 3. DTS and drivers:
|
| 28 | DT maintainers might provide comments, but review is generally not expected.
|
| 29 | DTS must pass schema checks (dtbs_check) or at least do not add any
|
| 30 | new warnings.
|
| 31 |
|
| 32 | Patchwork
|
| 33 | ~~~~~~~~~
|
| 34 |
|
| 35 | Devicetree maintainers review patches using Patchwork, so the current status of
|
| 36 | a patch can be checked there. For typical driver submissions, Patchwork
|
| 37 | receives the entire patch set, but only a few patches are usually Devicetree
|
| 38 | bindings that are reviewed by DT maintainers.
|
| 39 |
|
| 40 | Explanation of Patchwork statuses:
|
| 41 |
|
| 42 | - **New**: Not yet processed by the automation toolset.
|
| 43 | - **Needs ACK**: Waiting for review by DT maintainers.
|
| 44 | - **Handled Elsewhere**: Non-DT patch; not being reviewed here.
|
| 45 | - **RFC**: Patch was likely ignored because it was an incomplete RFC.
|
| 46 | - **Changes Requested**: Patch was reviewed and DT maintainers expect changes.
|
| 47 | - **Accepted**: Patch was reviewed and applied by DT maintainers to their tree.
|
| 48 | - **Not Applicable**: Patch was reviewed and is likely in good shape, with a
|
| 49 | *Reviewed-by* or *Acked-by* tag provided, but DT maintainers expect someone
|
| 50 | else to apply it.
|
| 51 |
|
| 52 | Patch Re-review and Pinging
|
| 53 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 54 |
|
| 55 | Due to the high volume of email traffic, Devicetree maintainers do not read
|
| 56 | every email they receive and instead rely on Patchwork during the review
|
| 57 | process. They also often skip patches that have already been reviewed.
|
| 58 |
|
| 59 | As a result, maintainers might miss:
|
| 60 |
|
| 61 | 1. Questions about already reviewed patches.
|
| 62 | 2. Pings, for example when a patch has been reviewed by DT maintainers but has
|
| 63 | not been picked up by subsystem maintainers.
|
| 64 |
|
| 65 | Such cases can be addressed by:
|
| 66 |
|
| 67 | 1. Pinging DT maintainers on the IRC channel.
|
| 68 | 2. Dropping the DT maintainer’s *Acked-by* or *Reviewed-by* tag when sending a new
|
| 69 | version of the patch set, together with an explanation in the patch
|
| 70 | changelog describing why the tag was removed and what is expected from DT
|
| 71 | maintainers.
|
| 72 |
|