On Tue, 20 Feb 2024 at 23:11, Stephan Gerhold <stephan@xxxxxxxxxxx> wrote:
>
> On Tue, Feb 20, 2024 at 11:11:15AM +0200, Dmitry Baryshkov wrote:
> > On Sun, 11 Feb 2024 at 12:36, Stephan Gerhold <stephan@xxxxxxxxxxx> wrote:
> > > On Sun, Feb 04, 2024 at 06:56:35PM +0200, Dmitry Baryshkov wrote:
> > > > The idea impressed in the commit b32e592d3c28 ("devicetree: bindings:
> > > > Document qcom board compatible format") never got actually adopted. As
> > > > can be seen from the existing board DT files, no device actually used
> > > > the PMIC / foundry / version parts of the compatible string. Drop this
> > > > compatibility string description to avoid possible confusion and keep
> > > > just the generic terms and the SoC list.
> > > >
> > > > Fixes: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format")
> > >
> > > FWIW: It's not correct that no device uses the version parts of the
> > > compatible string. There are actually two boards documented in qcom.yaml
> > > that follow this scheme:
> > >
> > > compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1", "qcom,msm8916";
> > > compatible = "longcheer,l8150", "qcom,msm8916-v1-qrd/9-v1", "qcom,msm8916";
> > >
> > > I don't think anyone is actively relying on those, though. I guess we
> > > can just ignore them or even remove them.
> >
> > Excuse me for the long delay. As it was you who added the
> > longcheer-l8150 support, does it require any of the msm-id options or
> > dtbTool (original or modified) processing?
> > If it can work with no additional tags, we can drop these compatibility strings.
> >
>
> I think we added it back then to allow booting mainline with the
> original bootloader. Together with the "skales" dtbTool (used to be at
> https://source.codeaurora.org/quic/kernel/skales) the compatible does
> result in a correct QCDT that is accepted by the bootloader.
>
> I doubt anyone still uses this way of booting nowadays. In postmarketOS
> we strongly recommend everyone to boot MSM8916 devices using lk2nd [1]
> which supports plain appended DTB without special properties and other
> more reliable forms of DTB selection. I have not tested booting mainline
> with the original bootloader for many years.
If I remember correctly, if somebody wants to boot msm8916 with the
'original' bootloader, they will also face issues with SMP support,
etc. So let's drop that.
> Dropping the extra compatible would be fine for me. Personally I don't
> consider booting via weird/broken bootloaders worth supporting (at least
> if better workarounds exist). Having to boot with "custom" bootloaders
> tends to be a somewhat subjective topic though so others might disagree.
I usually prefer to stick to the original as much as possible,
especially for the end-user devices. But in this case I think it's
beyond possible.
--
With best wishes
Dmitry
