Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754126Ab3IYWWo (ORCPT ); Wed, 25 Sep 2013 18:22:44 -0400 Received: from mail-vc0-f180.google.com ([209.85.220.180]:44488 "EHLO mail-vc0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751151Ab3IYWWm (ORCPT ); Wed, 25 Sep 2013 18:22:42 -0400 MIME-Version: 1.0 In-Reply-To: References: <1378986619-26765-1-git-send-email-pekon@ti.com> <1378986619-26765-2-git-send-email-pekon@ti.com> <20980858CB6D3A4BAE95CA194937D5E73EA15ED7@DBDE04.ent.ti.com> <20130925134619.GG10746@radagast> <20130925175527.GA23337@ld-irv-0074.broadcom.com> <20980858CB6D3A4BAE95CA194937D5E73EA16884@DBDE04.ent.ti.com> <20130925200539.GH23337@ld-irv-0074.broadcom.com> <20130925212903.GI23337@ld-irv-0074.broadcom.com> Date: Wed, 25 Sep 2013 15:22:41 -0700 Message-ID: Subject: Re: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes From: Brian Norris To: Olof Johansson Cc: "Gupta, Pekon" , "benoit.cousson@linaro.org" , "devicetree@vger.kernel.org" , "arnd@arndb.de" , "dwmw2@infradead.org" , "tony@atomide.com" , "avinashphilipk@gmail.com" , "linux-mtd@lists.infradead.org" , "linux-omap@vger.kernel.org" , "dedekind1@gmail.com" , Andrew Morton , Linux Kernel Mailing List , "Balbi, Felipe" , Rob Herring , Pawel Moll , Ian Campbell , Stephen Warren , Mark Rutland Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2680 Lines: 58 On Wed, Sep 25, 2013 at 2:32 PM, Olof Johansson wrote: > On Wed, Sep 25, 2013 at 2:29 PM, Brian Norris > wrote: >> On Wed, Sep 25, 2013 at 01:33:27PM -0700, Olof Johansson wrote: >>> On Wed, Sep 25, 2013 at 1:05 PM, Brian Norris >>> wrote: >>> >>> > Olof has given good advice on your DT binding and has (slowly) been >>> > responding to other requests for DT review that make it to his list. I >>> > see that he hasn't followed up on your changes (this v6), so pinging him >>> > (as you did) is probably the correct approach. But please do recognize >>> > that the DT list is very high volume, so it's hard to get good timely >>> > responses there. >>> >>> I am not a DT mainainer, but sometimes when I see a binding that >>> appears to be wrong I speak up. In this case, the binding was one of >>> those. >> >> Whoops, my bad. I was deceived by the responses I've seen from you on >> other issues (thanks, BTW). In that case, I haven't seen any response >> from a proper DT binding maintainer :( >> >>> So, I have no more objections to it, and I hope you can get a quick >>> review from a DT maintainer on the rest of the binding. >> >> At this point, I'm comfortable going ahead without their ack, since they >> obviously don't care/don't have the manpower to review. > > No, that is not how we handle device tree bindings. They need to be > reviewed, since we are moving over to a model where they will be > considered ABI and can't be changed after the fact. We have a long > backlog of mostly-unreviewed old bindings that we're going to do a > pass through and then lock down, but it would be good to not add to > that backlog with newer bindings. > > In other words, there's a strong desire for actual acks on bindings > from those maintainers these days. This only works if we get a response. I'll repeat this fact: I have seen absolutely zero response from any DT maintainer regarding this binding, and they've been CC'd in some capacity since July: Old revision from July (cross-posted, including the old DT list): http://thread.gmane.org/gmane.linux.ports.arm.omap/100484/ New list: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95238.html All official DT binding maintainers are CC'd here: you can't say you want more review of bindings, yet fail to review them across 3 versions and almost 3 months. Ball's in your court. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/