Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Corey Minyard <tcminyard@gmail.com>
Date:   Mon, 8 Aug 2022 07:26:52 -0500
From:   Corey Minyard <minyard@acm.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Tomer Maimon <tmaimon77@gmail.com>, avifishman70@gmail.com,
        tali.perry1@gmail.com, joel@jms.id.au, venture@google.com,
        yuenn@google.com, benjaminfair@google.com, jic23@kernel.org,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        openbmc@lists.ozlabs.org, openipmi-developer@lists.sourceforge.net,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3] dt-binding: ipmi: add fallback to npcm845 compatible
Message-ID: <20220808122652.GO3834@minyard.net>
Reply-To: minyard@acm.org
References: <20220808075452.115907-1-tmaimon77@gmail.com>
 <da83671e-08b9-2d68-e5d3-d9b09c105bb4@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <da83671e-08b9-2d68-e5d3-d9b09c105bb4@linaro.org>
Precedence: bulk

On Mon, Aug 08, 2022 at 11:11:16AM +0300, Krzysztof Kozlowski wrote:
> On 08/08/2022 09:54, Tomer Maimon wrote:
> > Add to npcm845 KCS compatible string a fallback to npcm750 KCS compatible
> > string becuase NPCM845 and NPCM750 BMCs are using identical KCS modules.
> > 
> > Fixes: 84261749e58a ("dt-bindings: ipmi: Add npcm845 compatible")
> > Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> 
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Ok, I think I understand how this is supposed to work.  It's not
altogether clear from the device tree documentation.  It says in
Documentation/devicetree/bindings/writing-bindings.rst:

- DO make 'compatible' properties specific. DON'T use wildcards in compatible
  strings. DO use fallback compatibles when devices are the same as or a subset
  of prior implementations. DO add new compatibles in case there are new
  features or bugs.

AFAICT, there are no new features or bugs, just a new SOC with the same
device.  In general usage I have seen, you would just use the same
compatible.  However, if I understand this, that last sentence should say:

  DO add new compatibles in case there is a new version of hardware with
  the possibility of new features and/or bugs.

Also, the term "specific" is, ironically, vague.  Specific to what?

It would be nice to have something added to "Typical cases and caveats"
that says:

- If you are writing a binding for a new device that is the same as, or
  a superset of another existing device, add a new specific compatible
  for the new device followed by a compatible for the existing device.
  That way, if the device has new bugs or new specific features are
  added, you can add workarounds without modifying the device tree.

Anyway, I have added this to my tree with your ack.

-corey

> 
> 
> Best regards,
> Krzysztof