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
Date: Mon, 8 Aug 2022 07:26:52 -0500 [thread overview]
Message-ID: <20220808122652.GO3834@minyard.net> (raw)
In-Reply-To: <da83671e-08b9-2d68-e5d3-d9b09c105bb4@linaro.org>
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
next prev parent reply other threads:[~2022-08-08 12:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 7:54 [PATCH v3] dt-binding: ipmi: add fallback to npcm845 compatible Tomer Maimon
2022-08-08 8:11 ` Krzysztof Kozlowski
2022-08-08 12:26 ` Corey Minyard [this message]
2022-08-08 12:38 ` Krzysztof Kozlowski
2022-08-08 14:23 ` Corey Minyard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220808122652.GO3834@minyard.net \
--to=minyard@acm.org \
--cc=avifishman70@gmail.com \
--cc=benjaminfair@google.com \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=joel@jms.id.au \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=openipmi-developer@lists.sourceforge.net \
--cc=robh+dt@kernel.org \
--cc=tali.perry1@gmail.com \
--cc=tmaimon77@gmail.com \
--cc=venture@google.com \
--cc=yuenn@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).