From patchwork Thu Nov 7 18:53:32 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Cooper X-Patchwork-Id: 289457 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 5A14E2C00BD for ; Fri, 8 Nov 2013 05:53:48 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752448Ab3KGSxr (ORCPT ); Thu, 7 Nov 2013 13:53:47 -0500 Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:57774 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940Ab3KGSxq (ORCPT ); Thu, 7 Nov 2013 13:53:46 -0500 Received: from pool-108-39-110-144.nrflva.fios.verizon.net ([108.39.110.144] helo=titan) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VeUi6-00065d-S1; Thu, 07 Nov 2013 18:53:43 +0000 Received: from triton.localdomain (omega.lakedaemon.net [10.16.5.5]) by titan (Postfix) with ESMTP id 7000A4D228C; Thu, 7 Nov 2013 13:53:40 -0500 (EST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.39.110.144 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+FOArZoaiZoX4jxhmB/GllcEgY8g1L8xs= From: Jason Cooper To: Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , Rob Landley Cc: Jason Cooper , devicetree@vger.kernel.org Subject: [PATCH RFC V2] dt: bindings: submitting patches document Date: Thu, 7 Nov 2013 18:53:32 +0000 Message-Id: <1383850412-18744-1-git-send-email-jason@lakedaemon.net> X-Mailer: git-send-email 1.8.4.2 In-Reply-To: <1383759120-21571-1-git-send-email-jason@lakedaemon.net> References: <1383759120-21571-1-git-send-email-jason@lakedaemon.net> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Signed-off-by: Jason Cooper --- Changes since V1: - clarified III.1. as speaking to maintainers - quoted Grant's ARM mini-summit document regarding DT as stable ABI (IV.2.) All, Since I've now had to answer this question a couple of times, I thought it might be worth trying to put it in a document. I don't like long documents, so this is pretty concise, and most likely wrong. Hence, RFC. :) I also dislike quoting people from my imperfect memory, much better to have an agreed upon document we can point people towards. thx, Jason. .../devicetree/bindings/submitting-patches.txt | 68 ++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/submitting-patches.txt diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt new file mode 100644 index 000000000000..82ffdabd22cc --- /dev/null +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -0,0 +1,68 @@ + + Submitting devicetree (DT) binding patches + +I. For patch submitters + + 0) Normal patch submission rules from Documentation/SubmittingPatches + applies. + + 1) The Documentation/ portion of the patch should be a separate patch + and clearly labelled as such. For example: + + [PATCH X/Y] dt: binding: mvebu mbus driver + + This makes the binding portion easy to find among large patch series. + + 2) Submit the entire series to the devicetree mailinglist at + + devicetree@vger.kernel.org + +II. For sub-system maintainers + + 1) If you aren't comfortable reviewing a given binding, reply to it and ask + the devicetree maintainers for guidance. This will help them prioritize + which ones to review and which ones are ok to let go. + + 2) If you are comfortable with the binding, and it hasn't received an + Acked-by from the devicetree maintainers after a few weeks, go ahead and + take it. + + 3) For a series going though multiple trees, the binding patch should be + kept with the driver using the binding. + +III. General binding rules + + 1) Maintainers, don't let perfect be the enemy of good. Don't hold up a + binding because it isn't perfect. + + 2) Use specific compatible strings so that if we need to add a feature (DMA) + in the future, we can create a new compatible string. See IV.2. + + 3) Ideally, all bindings receive sufficient review. In the real world, we + need to prioritize. Bindings for a specific block of IP aren't as + critical as a binding for a common subsystem, like PCI. + + 4) Don't submit bindings for staging or unstable. That will be decided by + the devicetree maintainers *after* discussion on the mailinglist. + +IV. Notes + + 1) This document is intended as a general familiarization with the process as + decided at the 2013 Kernel Summit. When in doubt, the current word of the + devicetree maintainers overrules this document. In that situation, a patch + updating this document would be appreciated. + + 2) Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit + summary document: + + "That still leaves the question of, what does a stable binding look + like? Certainly a stable binding means that a newer kernel will not + break on an older device tree, but that doesn't mean the binding is + frozen for all time. Grant said there are ways to change bindings that + don't result in breakage. For instance, if a new property is added, + then default to the previous behaviour if it is missing. If a binding + truly needs an incompatible change, then change the compatible string + at the same time. The driver can bind against both the old and the + new. These guidelines aren't new, but they desperately need to be + documented." +