linux-kernel - Re: Removal of qcom,board-id and qcom,msm-id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 May 2022 01:18:53 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        agross@...nel.org, arnd@...db.de, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        olof@...om.net, robh@...nel.org, sboyd@...nel.org
Subject: Re: Removal of qcom,board-id and qcom,msm-id

On Tue, 24 May 2022 at 00:50, Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
>
> On Mon 23 May 02:21 CDT 2022, Krzysztof Kozlowski wrote:
>
> > On 22/05/2022 21:51, Konrad Dybcio wrote:
> > I actually wonder why do you need these properties for community work on
> > such boards? You ship kernel with one concatenated DTB and the
> > bootloader does not need the board-id/msm-id fields, doesn't it?

You know, this reminds me of an old argument dating 2005-7: why do we
need to support multi-platform kernels, while we can boot a good plain
single-mach (or a single-board) kernel on a particular board.
Supporting msm-id/board-id/pmic-id gives us flexibility. Dropping them
would remove flexibility.

> > Not mentioning that in the past bootloader was actually not using these
> > properties at all, because it was the dtbTool who was parsing them. So
> > in any case either your device works fine without these properties or
> > you have to use dtbTool, right?

I think it was supposed to be done in an opposite way: to let dtbTool
process compat strings and generate the properties in question.

> > >
> > > One solution is to chainload another, (n+1)-stage bootloader, but this is
> > > not ideal, as:
> > >
> > > 1) the stock bootloader can boot Linux just fine on most devices (except
> > > for single exceptions, where beloved OEMs didn't implement arm64 booting or
> > > something)
> > >
> > > 2) the boot chain on MSM is already 3- or 4- stage and adding to that will
> > > only create an unnecessary mess
> > >
> > > 3) the job of kernel people is not to break userspace. If the
> > > device can not even exit bootloader after a kernel upgrade, it's a big
> > > failure.
> >
> > The job of kernel people is to follow bindings and since they were
> > introduced 7 years ago, I would say there was plenty of time for that.
> >
>
> 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.

>
> > 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.


-- 
With best wishes
Dmitry