From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759317AbcIMPrw (ORCPT ); Tue, 13 Sep 2016 11:47:52 -0400 Received: from foss.arm.com ([217.140.101.70]:52432 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756545AbcIMPrv (ORCPT ); Tue, 13 Sep 2016 11:47:51 -0400 Date: Tue, 13 Sep 2016 16:47:30 +0100 From: Mark Rutland To: Sebastian Frias Cc: devicetree , Mason , Timur Tabi , Linux ARM , LKML Subject: Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers Message-ID: <20160913154722.GD23336@leverpostej> References: <57D69FB1.2020801@laposte.net> <20160912123809.GB13741@leverpostej> <57D6AA54.6000208@laposte.net> <20160912135549.GA14165@leverpostej> <57D6D2A9.3010006@laposte.net> <20160912165637.GF14165@leverpostej> <57D7CF17.2050905@laposte.net> <20160913131208.GA23336@leverpostej> <57D8137F.8040508@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57D8137F.8040508@laposte.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 13, 2016 at 04:55:59PM +0200, Sebastian Frias wrote: > On 09/13/2016 03:12 PM, Mark Rutland wrote: > >> Exactly, that is why I was thinking it would take less "review" time. > >> Indeed, if there is no driver, why would it matter what those bindings > >> are? > > > > If you believe that the bindings don't matter, then there is absolutely > > no reason for them to exist in the first place. > > > > If those binding matter to *anyone*, then those collating the bindings > > have some responsibility of stewardship, and that includes > > review/maintenance/etc. > > The thing is that right now it seems the "responsibility of stewardship" > lies only within "Linux", whereas DT is proposed as open for everybody, > Bootloaders, FreeBSD, etc. > > In that case, shouldn't the "responsibility" be shared? Ideally, yes. Which is one of the reasons devicetree.org was set up as a common forum for projects to collaborate on devicetree. Thanks, Mark.