From patchwork Wed Jul 24 19:03:15 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Cooper X-Patchwork-Id: 2832996 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1F48AC0319 for ; Wed, 24 Jul 2013 19:08:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CEC45204CB for ; Wed, 24 Jul 2013 19:08:48 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6B0F2204C7 for ; Wed, 24 Jul 2013 19:08:47 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1V24QW-0000BB-2A; Wed, 24 Jul 2013 19:08:44 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1V24Le-0004cm-DP; Wed, 24 Jul 2013 19:03:42 +0000 Received: from mho-02-ewr.mailhop.org ([204.13.248.72]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1V24Lb-0004cP-78 for linux-arm-kernel@lists.infradead.org; Wed, 24 Jul 2013 19:03:39 +0000 Received: from pool-72-84-113-162.nrflva.fios.verizon.net ([72.84.113.162] helo=titan) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V24LF-000Hvo-Em; Wed, 24 Jul 2013 19:03:17 +0000 Received: from titan.lakedaemon.net (localhost [127.0.0.1]) by titan (Postfix) with ESMTP id 5F85B47055E; Wed, 24 Jul 2013 15:03:15 -0400 (EDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 72.84.113.162 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+WYdEe1YRwW+akhZN/BPH7K94KUKKfgC4= Date: Wed, 24 Jul 2013 15:03:15 -0400 From: Jason Cooper To: Rob Herring Subject: Re: Do we have people interested in device tree janitoring / cleanup? Message-ID: <20130724190315.GC23879@titan.lakedaemon.net> References: <51F01D64.9060609@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51F01D64.9060609@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130724_150339_316196_953FB71A X-CRM114-Status: GOOD ( 25.52 ) X-Spam-Score: -1.9 (-) Cc: Olof Johansson , devicetree@vger.kernel.org, Samuel Ortiz , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Jul 24, 2013 at 01:31:00PM -0500, Rob Herring wrote: > On 07/24/2013 10:27 AM, Olof Johansson wrote: > > Every now and then I come across a binding that's just done Wrong(tm), > > merged through a submaintainer tree and hasn't seen proper review -- > > if it had, it wouldn't look the way it does. It's something we're > > starting to address now since there's more people stepping up to be > > maintainers, but there's a backlog of bad bindings already merged. > > > > Often they are produced by translating the platform_data structures > > directly over into device-tree properties without consideration to > > describing the hardware or usual conventions, using key/value pairs > > instead of boolean properties, etc. > > > > Getting involved in cleaning up these kind of bindings is a great way > > to learn "the ways of device tree" for someone that has interest in > > that. > > > > Latest find in this area is the Maxim 8925 bindings, that I came > > across since they caused a compile warning on some defconfig. I'll > > post a patch to address the warning but if someone else feels like > > fixing the bindings on top of it that would be appreciated! > > Are they documented typically? Can we at a minimum update the > documentation with a big fat warning to not use or propagate the crap. > Or move the binding doc file to a fixme directory. I agree, in order to do the janitorial work (which I'm not opposed to helping with), we need a way to mark stable bindings. fwiw, we could do a separate commit (like the kernel version commit) where the only change is marking a binding as stable, and is obvious from a 'git log --oneline'. eg: ---->8------ From 65c069678cdbd5aaa6aca0d4062dab6eb9f9904c Mon Sep 17 00:00:00 2001 From: Jason Cooper Date: Wed, 24 Jul 2013 18:49:28 +0000 Subject: [PATCH] DT: binding: stable: gpio-regulator A whole bunch of folks reviewed this and think it kicks ass. List-of-people-responsible-for-this-travesty: ... Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/regulator/gpio-regulator.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt index 63c6598..35ec635 100644 --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt @@ -1,3 +1,5 @@ +Binding status: Stable + GPIO controlled regulators Required properties: