public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan@gerhold.net>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Konrad Dybcio <konrad.dybcio@somainline.org>,
	agross@kernel.org, arnd@arndb.de, devicetree@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	olof@lixom.net, robh@kernel.org, sboyd@kernel.org
Subject: Re: Removal of qcom,board-id and qcom,msm-id
Date: Wed, 25 May 2022 19:36:53 +0200	[thread overview]
Message-ID: <Yo5pNRq/vBaamk0q@gerhold.net> (raw)
In-Reply-To: <CAA8EJprArSF_363FyS+63XfB=ZK657X81u8TJLTRx5AbTYy1ag@mail.gmail.com>

On Tue, May 24, 2022 at 01:18:53AM +0300, Dmitry Baryshkov wrote:
> > We're following the bindings and don't pick board-id or msm-id unless
> > there's a particular reason for it - which typically is that the
> > downstream bootloader requires it - we don't use the properties on the
> > kernel side.
> 
> Or unless we have another reason (like handling a single RB3+RB5 image).
> I suspect PmOS might also like shipping a single image for some/all of
> the supported devices. Or we might use that for the qcom-armv8a OE
> machine.
> 

On a larger scale the qcom,msm-id/board-id properties are not very
useful for automatic DTB selection. This is simply because they are not
unique when you look beyond just the Qualcomm reference boards. I know
at least 3 totally different smartphones (from different vendors) where
the bootloader picks "msm8916-mtp", even though they have little in
common with Qualcomm's original MTP board.

There are also vendors who made up their own broken numbering scheme,
broken bootloaders that pick seemingly random DTBs or start modifying
random properties etc etc. Perhaps it has improved on more recent
devices but somehow I doubt it...

This means that the qcom,msm-id/board-id properties are really just
useful for making the bootloader happy, or if you have a number of
devices in full control. It's not the consistently implemented standard
that would actually be worth promoting for automatic DTB selection.

> >
> > > If the dtbTool support for the bindings is there, then there is no
> > > breakage, because you had to use dtbTool before so you have to use now.
> > >
> >
> > Among all the platforms I maintain, MSM8916 (db410c) is the only one
> > where I use dtbTool - because it refuses to accept the concatenated
> > dtb.
> 
> It's strange, I have been using concatenated dtb with db410c for ages.
> 

There is a patch in Linaro's LK fork for DB410c that selects the
appended DTB even if the qcom,msm-id/board-id properties are missing:
https://git.linaro.org/landing-teams/working/qualcomm/lk.git/commit/?id=3be1d459a546a24f2bf10b9551663a3e69a8214e

If you don't have this commit or something equivalent, appended DTBs
must have the qcom,msm-id/board-id properties for LK to accept them.

Stephan

  reply	other threads:[~2022-05-25 17:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19 10:44 Removal of qcom,board-id and qcom,msm-id Krzysztof Kozlowski
2022-05-19 11:39 ` Dmitry Baryshkov
2022-05-19 11:53   ` Krzysztof Kozlowski
2022-05-19 12:46     ` Dmitry Baryshkov
     [not found]       ` <20220519221227.B66D3C385AA@smtp.kernel.org>
2022-05-20  1:39         ` Dmitry Baryshkov
2022-05-20  7:00           ` Krzysztof Kozlowski
2022-05-22 10:26           ` Krzysztof Kozlowski
2022-05-22 10:50             ` Dmitry Baryshkov
2022-05-22 19:51 ` Konrad Dybcio
2022-05-23  5:41   ` Amit Pundir
2022-05-23  7:21   ` Krzysztof Kozlowski
2022-05-23 12:02     ` Konrad Dybcio
2022-05-23 12:14       ` Krzysztof Kozlowski
2022-05-23 15:29         ` Konrad Dybcio
2022-05-23 16:41         ` Trilok Soni
2022-05-23 21:34           ` Bjorn Andersson
2022-05-23 22:13             ` Trilok Soni
2022-05-23 21:29     ` Rob Clark
2022-05-23 21:50     ` Bjorn Andersson
2022-05-23 22:18       ` Dmitry Baryshkov
2022-05-25 17:36         ` Stephan Gerhold [this message]
2022-05-26  7:16       ` Krzysztof Kozlowski
2022-06-22  8:21   ` Dmitry Baryshkov
2022-06-22 11:53     ` Konrad Dybcio
2022-06-23  9:55       ` Dmitry Baryshkov

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=Yo5pNRq/vBaamk0q@gerhold.net \
    --to=stephan@gerhold.net \
    --cc=agross@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.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