From: Elliot Berman <quic_eberman@quicinc.com>
To: Caleb Connolly <caleb.connolly@linaro.org>
Cc: Amrit Anand <quic_amrianan@quicinc.com>, <robh@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
<agross@kernel.org>, <andersson@kernel.org>,
<konrad.dybcio@linaro.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<kernel@quicinc.com>, <peter.griffin@linaro.org>,
<linux-riscv@lists.infradead.org>,
<chrome-platform@lists.linux.dev>,
<linux-mediatek@lists.infradead.org>,
Simon Glass <sjg@chromium.org>
Subject: Re: Re: [PATCH v2 2/2] dt-bindings: qcom: Update DT bindings for multiple DT
Date: Thu, 14 Mar 2024 13:07:40 -0700 [thread overview]
Message-ID: <20240314113908471-0700.eberman@hu-eberman-lv.qualcomm.com> (raw)
In-Reply-To: <f6f317d9-830d-4c38-998f-b229b3d9f95a@linaro.org>
On Thu, Mar 14, 2024 at 02:20:38PM +0000, Caleb Connolly wrote:
> Hi Amrit,
>
> On 14/03/2024 12:11, Amrit Anand wrote:
...
> >
> > +examples:
> > + - |
> > + #include <dt-bindings/arm/qcom,ids.h>
> > + / {
> > + model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform";
> > + compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280";
> > +
> > + #board-id-cells = <2>;
> > + board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>,
> > + <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>,
> > + <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>;
> > + board-id-types = "qcom,soc-id",
> > + "qcom,soc-id",
> > + "qcom,board-id";
> Forgive me if this is a particularly cynical view, but this seems
> incredibly blatant, the "qcom,board-id" property is deprecated for
> various good reasons, just using a key/value map where "qcom,board-id"
> is a key doesn't change that. There are two main issues I have with the
> proposal here:
>
> 1. This breaks backwards compatibility, millions of production devices
> with bootloaders that will never receive another update might be
> compatible with the downstream "qcom,board-id" property, but they won't
> work with this.
> 2. A top level board-id property that isn't namespaced implies that it
> isn't vendor specific, but the proposed implementation doesn't even
> pretend to be vendor agnostic.
>
I agree with the concerns you listed.
One point I wanted to bring is that if you provide a boot image that has
only one DTB, all production Qualcomm bootloaders I'm aware of will use
that DTB so long as "qcom,board-id" isn't a mismatch. I believe this is
what most everyone is doing if using the DTBs from kernel.org. We'd like
to use an open standard for DTB selection and that would very likely be
incompatible with existing bootloaders that don't have whatever that
standard is.
> U-Boot also has some ideas around this issue, there you can pass in
> multiple DTBs and provide some board specific "best match" function.
> I think there's definitely some value in exposing this information, but
> there's no good reason to define the same data as `qcom,board-id` while
> breaking production bootloaders.
One concern we have with U-Boot's approach is that it's based on
metadata external to the DTB and, in our experience, makes it hard to
track which board goes to which DTB. This approach also isn't
necessarily portable to other image types/boot flows.
Thanks,
Elliot
next prev parent reply other threads:[~2024-03-14 20:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 12:11 [PATCH v2 0/2] Add board-id support for multiple DT selection Amrit Anand
2024-03-14 12:11 ` [PATCH v2 1/2] dt-bindings: arm: qcom: Update Devicetree identifiers Amrit Anand
2024-03-14 14:29 ` Caleb Connolly
2024-05-07 5:07 ` Amrit Anand
2024-03-14 12:11 ` [PATCH v2 2/2] dt-bindings: qcom: Update DT bindings for multiple DT Amrit Anand
2024-03-14 13:35 ` Rob Herring
2024-03-14 14:20 ` Caleb Connolly
2024-03-14 14:35 ` Caleb Connolly
2024-05-14 3:14 ` Amrit Anand
2024-03-14 20:07 ` Elliot Berman [this message]
2024-03-16 16:20 ` Conor Dooley
2024-03-16 16:51 ` Conor Dooley
2024-03-18 21:36 ` Doug Anderson
2024-03-28 5:49 ` Chen-Yu Tsai
2024-03-28 8:50 ` [PATCH v2 0/2] Add board-id support for multiple DT selection Krzysztof Kozlowski
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=20240314113908471-0700.eberman@hu-eberman-lv.qualcomm.com \
--to=quic_eberman@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=caleb.connolly@linaro.org \
--cc=chrome-platform@lists.linux.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@quicinc.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-riscv@lists.infradead.org \
--cc=peter.griffin@linaro.org \
--cc=quic_amrianan@quicinc.com \
--cc=robh@kernel.org \
--cc=sjg@chromium.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).