Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752094Ab3FXKBI (ORCPT ); Mon, 24 Jun 2013 06:01:08 -0400 Received: from mail-oa0-f50.google.com ([209.85.219.50]:64560 "EHLO mail-oa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157Ab3FXKBG (ORCPT ); Mon, 24 Jun 2013 06:01:06 -0400 MIME-Version: 1.0 In-Reply-To: <51C2F1A7.3030805@monstr.eu> References: <4b90b06fce0475b579cfba4d968b4778359154f6.1369826814.git.michal.simek@xilinx.com> <51A8387C.4030704@monstr.eu> <51A852A1.7020505@monstr.eu> <51C2B47A.6010906@monstr.eu> <51C2E0AF.7040702@monstr.eu> <51C2F1A7.3030805@monstr.eu> Date: Mon, 24 Jun 2013 12:01:05 +0200 Message-ID: Subject: Re: [PATCH 1/2] GPIO: Add support for dual channel in gpio-xilinx.c From: Linus Walleij To: Michal Simek , Arnd Bergmann Cc: Michal Simek , "linux-kernel@vger.kernel.org" , Grant Likely , Rob Herring , "devicetree-discuss@lists.ozlabs.org" , Jean-Christophe PLAGNIOL-VILLARD 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: 2145 Lines: 55 On Thu, Jun 20, 2013 at 2:12 PM, Michal Simek wrote: > xlnx,is-dual is always present in the HW and in all DTSes and it > is generated for several years > > Based on my experience with hardware guys what happen when they add > new channel is that they will use xlnx,is-dual = 2 for 3 channels, > xlnx,is-dual = 3 for 4 channels, etc. They won't care about names > but they are working like that. > > It means for me is really problematic it try to work with this > value as boolean even that name is confusing. OK I will have to live with this. The problem with reviewing DT bindings is that for me as a subsystem maintainer I'm interacting with a quite complex universe: 1. Bindings from people like the MIPS camp where some people obviously sat down in a committee meeting and tried to define a binding in advance, which is then deployed and we have to support. Sometimes a real nice piece of work such as the PCI hose mappings. 2. Bindings that we need to evolve as part of this community review process, where the judgement of a mapping's applicability and sanity is very much up to the subsystem maintainer. (This is the vast class of bindings.) 3. Bindings that John Doe from Idaho came up with in his basement and then deployed to the entire world, so that we cannot review or amend it but just have to support as they are because they are already live in numerous systems. This would be a case of (3) whereas I'm mostly used to a binding discussion of type (2) and that is why this gets so locked up. > That's why it is much easier for me to start to use new property > which will describe number of channels but this value is not > used in design tools. Let's say number-of-channels = 1 or 2 > in DT binding which will describe number channels in this IP. > Is this acceptable for you? This is much nicer and readable. Yours, Linus Walleij -- 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/