From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA4DDC433FE for ; Wed, 5 Oct 2022 11:51:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230366AbiJELvH (ORCPT ); Wed, 5 Oct 2022 07:51:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230165AbiJELuv (ORCPT ); Wed, 5 Oct 2022 07:50:51 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5374F7C1F0 for ; Wed, 5 Oct 2022 04:48:29 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id f9so185403ljk.12 for ; Wed, 05 Oct 2022 04:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=OjaIFXk+WQHSl86U9o21WzF2QtQNwYjjD834VFUBTn8=; b=nLdk8dMBlw6MOm9yGPZ3KDUtktkbxxJ8Ns5q0qExDPKvA3B7r+LLGKx+fxQ1gSDr36 twQCLXYP9Xd+eFMmaFiE3Ng4Daon9iSFlefcQ2Z4E92whUuumQpe8iAB8zaFMzLH+r3/ nrzdSjiz+gSqoVAN4h9wo+dVq0aRnHv/Vrf42XLxQmQ8wDi85KKYaUv66mCRFe0JkwKB RLYXt739P8WJxkiSDr0iOlp1+/oMGF/98+yy+JxSZ/3ygGfBqontT4hdtF4XMy87uaMj H0Wu0AamZUQlhV715cPaN8NLyB2Vx32tMNFdpyZ/I3gck1wKACkzRBUt+MMwDEE1F3mo 1bqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=OjaIFXk+WQHSl86U9o21WzF2QtQNwYjjD834VFUBTn8=; b=adWzusHylf4I42Ih/XaUhmixhzTlc0slMNq163OeggyESmWKoaetBpBVBz/DHsqVd1 bIN1+P1SzNQsdmnc2ZuAoBkTCyvvkx2sROmKWF/iamY1XhRPiHukL6crbE3Frx97tZPJ B6ts81Qx/MxUC8AoGg/EJkDRWeKmQDaI1iRLM7XXX6/Jx7N7Ye4/4GY0BU2emBOMBY+e M+q+wtMZKggW9znMYgS5pzpD7kWS2aebMAe3L5RecNUsZQH4w586anMgqRbiT2Jyua0x MpcpAgg1FxLU01gnOc8hVdoEpuhOQUqbxOk0IvB6/VajRjqvNjg4T3TNPqM3LSXaMogx 1Vxw== X-Gm-Message-State: ACrzQf2zXzxbMzoddlQYQ8XwfowZfERV8q59SgRaB4LLcB3QcjpAAh+y QIb1ycaA+7qTIUOHGrbQL5RiFw== X-Google-Smtp-Source: AMsMyM5kiaWHmTkdKpMUpg26BD7/GxOdta2rHlxydwaHv04d409KowZs0sTktcuzHE2EFOuJVo95xA== X-Received: by 2002:a2e:a98f:0:b0:26c:4f1b:e997 with SMTP id x15-20020a2ea98f000000b0026c4f1be997mr9301100ljq.27.1664970506879; Wed, 05 Oct 2022 04:48:26 -0700 (PDT) Received: from [192.168.0.21] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id k10-20020a2eb74a000000b0026c40bfe926sm1579755ljo.76.2022.10.05.04.48.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Oct 2022 04:48:26 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2022 13:48:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v6 2/2] dt-bindings: memory-controllers: gpmc-child: add wait-pin polarity Content-Language: en-US To: "Niedermayr, BENEDIKT" , "robh@kernel.org" Cc: "rogerq@kernel.org" , "tony@atomide.com" , "devicetree@vger.kernel.org" , "linux-omap@vger.kernel.org" References: <20220929125639.143953-1-benedikt.niedermayr@siemens.com> <20220929125639.143953-3-benedikt.niedermayr@siemens.com> <20220930194257.GA756240-robh@kernel.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 05/10/2022 13:15, Niedermayr, BENEDIKT wrote: > On Wed, 2022-10-05 at 13:00 +0200, Krzysztof Kozlowski wrote: >> On 05/10/2022 12:13, Niedermayr, BENEDIKT wrote: >>>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc- >>>>> child.yaml >>>>> index 6e3995bb1630..477189973334 100644 >>>>> --- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml >>>>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml >>>>> @@ -230,6 +230,13 @@ properties: >>>>> Wait-pin used by client. Must be less than "gpmc,num-waitpins". >>>>> $ref: /schemas/types.yaml#/definitions/uint32 >>>>> >>>>> + gpmc,wait-pin-polarity: >>>> >>>> 'gpmc' is not a vendor. Don't continue this bad pattern, use 'ti'. >>> >>> You are right. But nevertheless I can't agree with that in this patch series. >>> I don't want to break consistency, since all bindings currently use 'gpmc'. At least this applies >>> to the "ti,gpmc-child.yaml". >>> >>> I think it makes more sense to create a complete new patch series for that specific change? This change >>> wouldn't fit thematically the current patch series. >>> >> >> So you want to add new property incorrectly named and immediately new >> patch which fixes the name? No, please squash this new patch into this. >> > No that's not what I meant. Currently all bindings in "ti,gpmc-child.yaml" start with "gpmc," and introducing > a single binding in this file with "ti," feels like breaking consistency. > > The "new" patch series should address **all** bindings in this file and all device trees currently using "gpmc," > bindings. So finally we have the current patch series introducing the wait pin handling in a consisten way and then another > patch series which changes all "gpmc," to "ti,". Isn't this exactly what I said? First add gpmc (so incorrectly named property) and then fix it to proper name (TI)? So squash that part of second patch which relates to this one, into this patch. Please do not commit incorrect properties, just because they are consistent. > If it makes more sense to directly introduce the "ti,wait-pin-polarity" instead of "gpmc,wait-pin-polarity" then I will do. Just > give me a short feedback. > You got it already: 'gpmc' is not a vendor. Don't continue this bad pattern, use 'ti'. Best regards, Krzysztof